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

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

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 ? :-)

> 
> But xapi, for instance, has a concept of "hardware pools" containing
> individual hardware devices, which can be assigned to VMs.  You could
> imagine a toolstack like xapi keeping track of all devices which
> *might be* assigned to a guest, and supplying Xen with the RMRRs.  As
> you say, then this could include hardware across a pool of hosts, with
> the RMRRs of any device in the system reserved.
> 
> Alternately, could the toolstack could be responsible for making sure
> that nobody uses such a range; and then Xen when a device is assigned,
> Xen can check to make sure that the gpfn space is empty before adding
> the RMRRs?  That might be the most flexible.
> 
>  -George
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

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