From: Chao Gao <chao.gao@intel.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>,
"Jan Beulich" <JBeulich@suse.com>
Cc: Kevin Tian <kevin.tian@intel.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Wei Liu <wei.liu2@citrix.com>,
George Dunlap <George.Dunlap@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Tim Deegan <tim@xen.org>,
xen-devel@lists.xen.org,
Crawford Eric R <Eric.R.Crawford@intel.com>,
Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [PATCH v7] VT-d: use correct BDF for VF to search VT-d unit
Date: Wed, 23 Aug 2017 15:42:58 +0800 [thread overview]
Message-ID: <20170823074255.GA7205@op-computing> (raw)
In-Reply-To: <20170823080107.nxknoatkqyfczbik@dhcp-3-128.uk.xensource.com>
On Wed, Aug 23, 2017 at 09:01:07AM +0100, Roger Pau Monné wrote:
>On Wed, Aug 23, 2017 at 02:46:08PM +0800, Chao Gao wrote:
>> On Wed, Aug 23, 2017 at 08:31:51AM +0100, Roger Pau Monné wrote:
>> >On Wed, Aug 23, 2017 at 01:20:13AM -0600, Jan Beulich wrote:
>> >> >>> On 23.08.17 at 09:16, <roger.pau@citrix.com> 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@intel.com> 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?
>> >
>> >It is my understanding (which might be wrong), that an extended
>> >function simply uses 8 bits for the function number, which on a
>> >traditional device would be used for both the slot and the function
>> >number.
>> >
>> >So extended functions have no slot, but the bus number is the same for
>> >all of them, or else they would belong to different devices due to the
>> >difference in the bus numbers.
>> >
>> >Maybe what I'm missing is whether it is possible to have a device with
>> >virtual functions that expand across several buses?
>>
>> It is not true. Please refer to the 2.1.2 VF Discovery of SR-IOV spec.
>> The numbers of VF can be larger than 256 and so it is definite that
>> sometimes VF's bus number would be different from the PF's.
>
>So that's what I was missing, thanks.
>
>Then I would modify acpi_find_matched_drhd_unit so it's:
>
> if ( pdev->info.is_extfn )
> {
> bus = pdev->info.is_virtfn ? pdev->info.physfn.bus : pdev->bus;
> devfn = 0;
> }
>
>AFAICT that should work?
Fine to me.
Jan, What your opinion on this piece of code?
Thanks
Chao
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-08-23 7:42 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-21 21:52 [PATCH v7] VT-d: use correct BDF for VF to search VT-d unit Chao Gao
2017-08-22 7:29 ` Roger Pau Monné
2017-08-22 8:48 ` Chao Gao
2017-08-22 12:43 ` Jan Beulich
2017-08-23 1:05 ` Chao Gao
2017-08-23 7:16 ` Roger Pau Monné
2017-08-23 7:20 ` Jan Beulich
2017-08-23 7:31 ` Roger Pau Monné
2017-08-23 6:46 ` Chao Gao
2017-08-23 8:01 ` Roger Pau Monné
2017-08-23 7:42 ` Chao Gao [this message]
2017-08-23 8:52 ` Jan Beulich
2017-08-24 7:29 ` Tian, Kevin
2017-08-23 8:00 ` Jan Beulich
2017-08-23 8:04 ` Jan Beulich
2017-08-23 7:39 ` Chao Gao
2017-08-23 8:51 ` Jan Beulich
2017-08-24 7:22 ` Tian, Kevin
[not found] ` <AADFC41AFE54684AB9EE6CBC0274A5D190D80DD6@SHSMSX101.ccr.corp.intel.com>
2017-08-24 8:01 ` Tian, Kevin
2017-08-24 8:22 ` Jan Beulich
2017-08-24 9:36 ` Chao Gao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170823074255.GA7205@op-computing \
--to=chao.gao@intel.com \
--cc=Eric.R.Crawford@intel.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=kevin.tian@intel.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).