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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.01.15 at 19:02, <George.Dunlap@xxxxxxxxxxxxx> 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:
>>> 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. :-)

You did, but the tool stack needs to take its knowledge from
somewhere, which I implied to be the guest config.

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

Right, that's an option where things can't go wrong, but not allowing
maximum flexibility (as mentioned before when considering migration).

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

"such a range" is pretty unspecific here: The main question is where the
tool stack would get the information on the set of ranges from. Of course
if it has this information, it can make sure no guest (unless marked
otherwise) uses any of these ranges. The hypervisor side verification
needs to be done in any case.

Jan


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