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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

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

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

Thanks
Kevin

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