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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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...

Ian.



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