[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 4/4] iommu: add rmrr Xen command line option for extra rmrrs
> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |