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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@xxxxxxxxxx]
> Sent: Saturday, January 10, 2015 4:28 AM
> 
> 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 ? :-)
> 

so this is the extension to report-all, not just for reserved regions but for
all e820 entries. :-)

one thing I'm struggling here (w/ Jan in other threads) is whether reporting
all reserved regions on the host can be a default setting to simplify the 
overall rmrr implementations, given that fact that end user shouldn't set
expectation on actual reserved regions.

Thanks
Kevin

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