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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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