Re: [Xen-devel] (v2) Design proposal for RMRR fix

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Mon, Jan 12, 2015 at 12:12:50PM +0000, Ian Campbell wrote:
> On Fri, 2015-01-09 at 15:27 -0500, Konrad Rzeszutek Wilk wrote:
> > On Thu, Jan 08, 2015 at 06:02:04PM +0000, George Dunlap wrote:
> > > On Thu, Jan 8, 2015 at 4:10 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> > > >>>> On 08.01.15 at 16:59, <dunlapg@xxxxxxxxx> wrote:
> > > >> On Thu, Jan 8, 2015 at 1:54 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> > > >>>> the 1st invocation of this interface will save all reported reserved
> > > >>>> regions under domain structure, and later invocation (e.g. from
> > > >>>> hvmloader) gets saved content.
> > > >>>
> > > >>> Why would the reserved regions need attaching to the domain
> > > >>> structure? The combination of (to be) assigned devices and
> > > >>> global RMRR list always allow reproducing the intended set of
> > > >>> regions without any extra storage.
> > > >>
> > > >> So when you say "(to be) assigned devices", you mean any device which
> > > >> is currently assigned, *or may be assigned at some point in the
> > > >> future*?
> > > >
> > > > Yes.
> > > >
> > > >> Do you think the extra storage for "this VM might possibly be assigned
> > > >> this device at some point" wouldn't really be that much bigger than
> > > >> "this VM might possibly map this RMRR at some point in the future"?
> > > >
> > > > Since listing devices without RMRR association would be pointless,
> > > > I think a list of devices would require less storage. But see below.
> > > >
> > > >> It seems a lot cleaner to me to have the toolstack tell Xen what
> > > >> ranges are reserved for RMRR per VM, and then have Xen check again
> > > >> when assigning a device to make sure that the RMRRs have already been
> > > >> reserved.
> > > >
> > > > With an extra level of what can be got wrong by the admin.
> > > > However, I now realize that doing it this way would allow
> > > > specifying regions not associated with any device on the host
> > > > the guest boots on, but associated with one on a host the guest
> > > > may later migrate to.
> > > 
> > > I did say the toolstack, not the admin. :-)
> > > 
> > > At the xl level, I envisioned a single boolean that would say, "Make
> > > my memory layout resemble the host system" -- so the MMIO hole would
> > > be the same size, and all the RMRRs would be reserved.
> > 
> > Like the e820_host=1 ? :-)
> 
> I'd been thinking about that all the way down this thread ;-) It seems
> like a fairly reasonable approach, and the interfaces (e.g. get host
> memory e820) are mostly already there. But maybe there are HVM specific
> reasons why its not...

Originally the hypercall (when e820_host was added) could only run under PV
guests (Jan's huge split pv and hvm struct domain). That changed with Mukesh's
PVH patches which now make the e820 part of the struct domain so both PV
and HVM can use. In regards to using it under HVM (hvmloader) there are no
issues - exepth that of course if you map the E820 as the host, all the
hard-coded ACPI tables locations, etc have to become dynamic.
> 
> Ian.
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel