[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

There is e820_host= parameter for domUs already.. but currently it doesn't work 
for HVM guests afaik.


-- Pasi



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.