Re: [Xen-devel] [PATCH v7] VT-d: use correct BDF for VF to search VT-d unit

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.08.17 at 09:16, <roger.pau@xxxxxxxxxx> wrote:
> On Wed, Aug 23, 2017 at 09:05:14AM +0800, Chao Gao wrote:
>> On Tue, Aug 22, 2017 at 06:43:49AM -0600, Jan Beulich wrote:
>> >>>> On 21.08.17 at 23:52, <chao.gao@xxxxxxxxx> wrote:
>> >> --- a/xen/include/xen/pci.h
>> >> +++ b/xen/include/xen/pci.h
>> >> @@ -39,6 +39,10 @@
>> >>  #define PCI_SBDF3(s,b,df) ((((s) & 0xffff) << 16) | PCI_BDF2(b, df))
>> >>  
>> >>  struct pci_dev_info {
>> >> +    /*
>> >> +     * When 'is_virtfn' is set, 'is_extfn' is re-used to indicate whether
>> >> +     * the PF of this VF is an extended function.
>> >> +     */
>> >
>> >I'd be inclined to extend the comment by appending ", as a VF itself
>> >can never be an extended function." Is that correct? If so, would
>> 
>> Hi, Jan and Roger.
>> 
>> Strictly speaking, the VF can be an extended function. The definition is
>> within ARI device (in this kind of device, device field is treated as an
>> extension of function number) and function number is greater than 7. But
>> this field isn't used as we don't care about whether a VF is or not an
>> extended function (at least at present).
>> 
>> Eric reviewed this patch and told me we may match
>> 'if ( pdev->info.is_extfn )' in acpi_find_matched_drhd_unit.
>> So we may introduce a new field like what I do in v6 or check
>> 'pdev->info.is_virtfn' first in acpi_find_matched_drhd_unit (maybe other
>> places we check pdev->info.is_extfn).
>> 
>> Which one do you prefer?
> 
> Looking at this again I'm not sure why you need any modifications to
> acpi_find_matched_drhd_unit. If the virtual function is an extended
> function pdev->bus should be equal to pdev->info.physfn.bus, in which
> case the already existing is_extfn check will already DTRT?
> 
> Ie: an extended VF should always have the same bus as the PF it
> belongs to, unless I'm missing something.

Why would that be?

Jan


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