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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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