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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.01.15 at 13:03, <kevin.tian@xxxxxxxxx> wrote:
>>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Wednesday, January 14, 2015 6:24 PM
>> 
>> >>> 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.
> 
> why? seems we agreed in the very 1st place to allow admin provide
> per-device override for this (e.g. like you argument that user may 
> get confirmation from device vendor that though conflict exists but
> user may opt to ignore it...). alternatively this option replaces the 
> hackish USB code in Xen hypervisor but still preserve the opt.

As just said in another reply to George - making this possible is (to
me) independent of the try/force flag you suggest to be associated
with any of the reserved regions.

>> > 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.
>> 
> 
> I may miss your suggestion on this. what do you think is the right way
> for explicitly specified regions? 

Explicitly specified regions are unconditionally "force".

Jan


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