[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> On 14.01.15 at 13:01, <george.dunlap@xxxxxxxxxxxxx> wrote:
> On 01/14/2015 10:24 AM, Jan Beulich wrote:
>>>>> On 14.01.15 at 10:43, <kevin.tian@xxxxxxxxx> wrote:
>>>>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>>>> Sent: Wednesday, January 14, 2015 5:00 PM
>>>>>>> On 14.01.15 at 09:06, <kevin.tian@xxxxxxxxx> wrote:
>>>>> Now the open is whether we want to fail domain creation for all of above
>>>>> conflicts. user may choose to bear with conflicts at his own disposal, or
>>>>> libxl doesn't want to fail conflicts as preparation for future
>>>>> hotplug/migration.
>>>>> One possible option is to add a per-region flag to specify whether 
>>>>> treating
>>>>> relevant conflict as an error, when libxl composes the list to domain
>>>>> builder.
>>>>> and this information will be saved in a user space database accessible to
>>>>> all components and also waterfall to Xen hypervisor when libxl requests
>>>>> actual device assignment.
>>>> That's certainly a possibility, albeit saying (in the guest config) that
>>>> a region to be reserved only when possible is about the same as
>>>> not stating that region. If at all, I'd see the rmrr-host value be a
>>>> tristate (don't, try, and force) to that effect.
>>> how about something like below with bi-state?
>>> for statically assigned device:
>>>     pci = [ "00:02.0, 0/1" ]
>>> where '0/1' represents try/force (or use 'try/force', or have a meaningful 
>>> attribute like rmrr_check=try/force?)
>> As said many times before, for statically assigned devices such a flag
>> makes no sense.
>>> for other usages like hotplug/migration:
>>>     reserved_regions = [ 'host, 0/1', 'start, end, 0/1', 'start, end, 0/1', 
>>> ...]
>>> If 'host' is specified, it implies rmrr_host, besides user can specific 
>>> explicit ranges according to his detail requirement.
>> For host the flag makes sense, but for the explicitly specified regions
>> - as said before - I don't think it does.
> You don't think there are any circumstances where an admin should be
> allowed to "shoot himself in the foot" by assigning a device which he
> knows the RMRRs conflict -- perhaps because he "knows" that the RMRRs
> won't actually be used?

I did advocate for allowing this, and continue to do so. But I think
the necessary override for this would apply at assignment time,
not when punching the holes (i.e. would need to be a different


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.