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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 01/13/2015 03:52 PM, Jan Beulich wrote:
>>>> On 13.01.15 at 13:03, <kevin.tian@xxxxxxxxx> wrote:
>>>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>>> Sent: Tuesday, January 13, 2015 7:56 PM
>>>>>> On 13.01.15 at 12:03, <kevin.tian@xxxxxxxxx> wrote:
>>>>    lowmem:         [0, 0x9fffffff]
>>>>    mmio hole:      [0xa0000000, 0xffffffff]
>>>>    highmem:        [0x100000000, 0x160000000]
>>>>
>>>>
>>>> For [0x40000000, 0x40003fff], leave it as a conflict since either
>>>> reducing lowmem to 1G is not nice to guest which doesn't use
>>>> highmem or we have to break lowmem into two trunks so more
>>>> structure changes are required.
>>>
>>> This makes no sense - if such an area was explicitly requested to
>>> be reserved, leaving it as a conflict is not an option.
>>
>> explicitly requested by libxl but leaving it as a conflict in domain
>> builder is just fine. later steps will actually catch conflicts when
>> relevant regions are actually used (e.g. in static assignment, in
>> hotplug, or in migration). 
> 
> But why do you think xl requested the region to be reserved?
> Presumably because the guest config file said so. And if the
> config file said so, there's no alternative to punching a hole
> there - failing device assignment later on is what the guest
> config file setting was added to avoid.

Yes -- the general principle should be: if the admin has asked for X,
and X cannot be done, then the entire operation should fail, so that the
admin can either make it possible for X to happen, or decide to do Y
instead.  Automatically doing Z when the admin has explicitly asked for
X is poor interface design.

That's why libxl will destroy the domain if the pci_add fails: if you've
asked for device A to be assigned (X), and it can't be assigned for
whatever reason, the domain creation should fail and the admin should be
told why, so he can ask for what he wants instead.

In the case of RMRRs, if the admin has asked for an RMRR to be made, and
it can't be made for whatever reason, the guest creation should fail.
For statically assigned devices this will fall out naturally from the
device assignment failing; but for RMRRs corresponding to hot-plug
regions, we'll have to fail somewhere else -- preferrably in libxc
rather than hvmloader?

We may want to make a special case for RMRRs that overlap guest BIOS I
guess.

 -George

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