[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |