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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

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.

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