Re: [Xen-devel] [PATCH 4/4] iommu: add rmrr Xen command line option for extra rmrrs

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

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Monday, June 01, 2015 5:17 PM
> 
> >>> On 01.06.15 at 08:30, <kevin.tian@xxxxxxxxx> wrote:
> >>  From: elena.ufimtseva@xxxxxxxxxx
> [mailto:elena.ufimtseva@xxxxxxxxxx]
> >> --- a/docs/misc/xen-command-line.markdown
> >> +++ b/docs/misc/xen-command-line.markdown
> >> @@ -1185,6 +1185,19 @@ Specify the host reboot method.
> >>  'efi' instructs Xen to reboot using the EFI reboot call (in EFI mode by
> >>   default it will use that method first).
> >>
> >> +### rmrr
> >> +> '=
> start<-end>=[s1]bdf1[,[s1]bdf2[,...]];start<-end>=[s2]bdf1[,[s2]bdf2[,...]]
> >> +
> >> +Define RMRRs units that are missing from ACPI table along with device
> >> +they belong to and use them for 1:1 mapping. End addresses can be
> omitted
> >> +and one page will be mapped. The ranges are inclusive when start and
> end
> >> +are specified.If segement of the first device is not specified, segment 
> >> zero
> >> will be used.
> >> +If other segments are not specified, first device segment will be used.
> >> +If segments are specified for every device and not equal, an error will be
> >> reported.
> >
> > Since you only allow devices under same segment for a given rmrr range,
> > would it be simpler to enforce that explicitly in the format? e.g.:
> >
> > = start<-end>=[s1]bdf1[,bdf2[,...]];
> 
> While that might simplify the code, I think it's better to allow the
> user to specify canonical device coordinates, which would include
> a segment number. Plus ...
> 
> > Then you don't need to verify whether segment in later bdfs is specified and
> > different from 1st bdf.
> 
> ... verification could not be dropped, unless we altered parse_pci()
> to have a way to not accept a segment number at all.
> 

Is that already the case? otherwise below comment and earlier patch 3/4 is
meaningless:

+ If other segments are not specified, first device segment will be used.

Thanks
Kevin

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