From: Knut Omang <knuto@ifi.uio.no>
To: "Łukasz Gieryk" <lukasz.gieryk@linux.intel.com>,
"Michael S. Tsirkin" <mst@redhat.com>
Cc: qemu-block@nongnu.org,
Lukasz Maniak <lukasz.maniak@linux.intel.com>,
qemu-devel@nongnu.org, Keith Busch <kbusch@kernel.org>,
Klaus Jensen <its@irrelevant.dk>
Subject: Re: [PATCH v3 01/15] pcie: Add support for Single Root I/O Virtualization (SR/IOV)
Date: Wed, 26 Jan 2022 14:32:04 +0100 [thread overview]
Message-ID: <ebbd32070c27ed088b54ddf2c35486d86e461f47.camel@ifi.uio.no> (raw)
In-Reply-To: <20220126132320.GA24682@lgieryk-VirtualBox>
On Wed, 2022-01-26 at 14:23 +0100, Łukasz Gieryk wrote:
> I'm sorry for the delayed response. We (I and the other Lukasz) somehow
> had hoped that Knut, the original author of this patch, would have
> responded.
Yes, sorry - this one flushed past me here for some reason,
>
> Let me address your questions, up to my best knowledge.
>
> > > -static pcibus_t pci_bar_address(PCIDevice *d,
> > > - int reg, uint8_t type, pcibus_t size)
> > > +static pcibus_t pci_config_get_bar_addr(PCIDevice *d, int reg,
> > > + uint8_t type, pcibus_t size)
> > > +{
> > > + pcibus_t new_addr;
> > > + if (!pci_is_vf(d)) {
> > > + int bar = pci_bar(d, reg);
> > > + if (type & PCI_BASE_ADDRESS_MEM_TYPE_64) {
> > > + new_addr = pci_get_quad(d->config + bar);
> > > + } else {
> > > + new_addr = pci_get_long(d->config + bar);
> > > + }
> > > + } else {
> > > + PCIDevice *pf = d->exp.sriov_vf.pf;
> > > + uint16_t sriov_cap = pf->exp.sriov_cap;
> > > + int bar = sriov_cap + PCI_SRIOV_BAR + reg * 4;
> > > + uint16_t vf_offset = pci_get_word(pf->config + sriov_cap +
> > > PCI_SRIOV_VF_OFFSET);
> > > + uint16_t vf_stride = pci_get_word(pf->config + sriov_cap +
> > > PCI_SRIOV_VF_STRIDE);
> > > + uint32_t vf_num = (d->devfn - (pf->devfn + vf_offset)) / vf_stride;
> > > +
> > > + if (type & PCI_BASE_ADDRESS_MEM_TYPE_64) {
> > > + new_addr = pci_get_quad(pf->config + bar);
> > > + } else {
> > > + new_addr = pci_get_long(pf->config + bar);
> > > + }
> > > + new_addr += vf_num * size;
> > > + }
> > > + if (reg != PCI_ROM_SLOT) {
> > > + /* Preserve the rom enable bit */
> > > + new_addr &= ~(size - 1);
> >
> > This comment puzzles me. How does clearing low bits preserve
> > any bits? Looks like this will clear low bits if any.
> >
>
> I think the comment applies to (reg != PCI_ROM_SLOT), i.e., the bits are
> cleared for BARs, but not for expansion ROM. I agree the placement of this
> comment is slightly misleading. We will move it up and rephrase slightly.
I agree - it's maybe better to just put the comment above the if(...)
other than that I believe it is correct.
Knut
>
> > > +pcibus_t pci_bar_address(PCIDevice *d,
> > > + int reg, uint8_t type, pcibus_t size)
> > > {
> > > pcibus_t new_addr, last_addr;
> > > - int bar = pci_bar(d, reg);
> > > uint16_t cmd = pci_get_word(d->config + PCI_COMMAND);
> > > Object *machine = qdev_get_machine();
> > > ObjectClass *oc = object_get_class(machine);
> > > @@ -1309,7 +1363,7 @@ static pcibus_t pci_bar_address(PCIDevice *d,
> > > if (!(cmd & PCI_COMMAND_IO)) {
> > > return PCI_BAR_UNMAPPED;
> > > }
> > > - new_addr = pci_get_long(d->config + bar) & ~(size - 1);
> > > + new_addr = pci_config_get_bar_addr(d, reg, type, size);
> > > last_addr = new_addr + size - 1;
> > > /* Check if 32 bit BAR wraps around explicitly.
> > > * TODO: make priorities correct and remove this work around.
> > > @@ -1324,11 +1378,7 @@ static pcibus_t pci_bar_address(PCIDevice *d,
> > > if (!(cmd & PCI_COMMAND_MEMORY)) {
> > > return PCI_BAR_UNMAPPED;
> > > }
> > > - if (type & PCI_BASE_ADDRESS_MEM_TYPE_64) {
> > > - new_addr = pci_get_quad(d->config + bar);
> > > - } else {
> > > - new_addr = pci_get_long(d->config + bar);
> > > - }
> > > + new_addr = pci_config_get_bar_addr(d, reg, type, size);
> > > /* the ROM slot has a specific enable bit */
> > > if (reg == PCI_ROM_SLOT && !(new_addr & PCI_ROM_ADDRESS_ENABLE)) {
> >
> > And in fact here we check the low bit and handle it specially.
>
> The code seems correct for me. The bit is preserved for ROM case.
>
> > > diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
> > > index d7d73a31e4..182a225054 100644
> > > --- a/hw/pci/pcie.c
> > > +++ b/hw/pci/pcie.c
> > > @@ -446,6 +446,11 @@ void pcie_cap_slot_plug_cb(HotplugHandler *hotplug_dev,
> > > DeviceState *dev,
> > > PCIDevice *pci_dev = PCI_DEVICE(dev);
> > > uint32_t lnkcap = pci_get_long(exp_cap + PCI_EXP_LNKCAP);
> > >
> > > + if(pci_is_vf(pci_dev)) {
> > > + /* We don't want to change any state in hotplug_dev for SR/IOV virtual
> > > functions */
> > > + return;
> > > + }
> > > +
> >
> > Coding style violation here. And pls document the why not the what.
> > E.g. IIRC the reason is that VFs don't have an express capability,
> > right?
>
> I think the reason is that virtual functions don’t exist physically, so
> they cannot be individually disconnected. Only PF should respond to
> hotplug events, implicitly disconnecting (thus: destroying) all child
> VFs.
>
> Anyway, we will update this comment to state *why* and add the missing
> space.
>
> V4 with the mentioned changes will happen really soon.
>
next prev parent reply other threads:[~2022-01-26 13:41 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-21 14:32 [PATCH v3 00/15] hw/nvme: SR-IOV with Virtualization Enhancements Lukasz Maniak
2021-12-21 14:32 ` [PATCH v3 01/15] pcie: Add support for Single Root I/O Virtualization (SR/IOV) Lukasz Maniak
2022-01-06 10:16 ` Michael S. Tsirkin
2022-01-26 13:23 ` Łukasz Gieryk
2022-01-26 13:32 ` Knut Omang [this message]
2021-12-21 14:32 ` [PATCH v3 02/15] pcie: Add some SR/IOV API documentation in docs/pcie_sriov.txt Lukasz Maniak
2021-12-21 14:32 ` [PATCH v3 03/15] pcie: Add a helper to the SR/IOV API Lukasz Maniak
2021-12-21 14:32 ` [PATCH v3 04/15] pcie: Add 1.2 version token for the Power Management Capability Lukasz Maniak
2021-12-21 14:32 ` [PATCH v3 05/15] hw/nvme: Add support for SR-IOV Lukasz Maniak
2021-12-21 14:32 ` [PATCH v3 06/15] hw/nvme: Add support for Primary Controller Capabilities Lukasz Maniak
2021-12-21 14:32 ` [PATCH v3 07/15] hw/nvme: Add support for Secondary Controller List Lukasz Maniak
2021-12-21 14:32 ` [PATCH v3 08/15] hw/nvme: Implement the Function Level Reset Lukasz Maniak
2021-12-21 14:32 ` [PATCH v3 09/15] hw/nvme: Make max_ioqpairs and msix_qsize configurable in runtime Lukasz Maniak
2021-12-21 14:32 ` [PATCH v3 10/15] hw/nvme: Remove reg_size variable and update BAR0 size calculation Lukasz Maniak
2021-12-21 14:32 ` [PATCH v3 11/15] hw/nvme: Calculate BAR attributes in a function Lukasz Maniak
2021-12-21 14:32 ` [PATCH v3 12/15] hw/nvme: Initialize capability structures for primary/secondary controllers Lukasz Maniak
2021-12-21 14:32 ` [PATCH v3 13/15] hw/nvme: Add support for the Virtualization Management command Lukasz Maniak
2021-12-21 14:32 ` [PATCH v3 14/15] docs: Add documentation for SR-IOV and Virtualization Enhancements Lukasz Maniak
2021-12-21 14:32 ` [PATCH v3 15/15] hw/nvme: Update the initalization place for the AER queue Lukasz Maniak
2022-01-26 8:58 ` [PATCH v3 00/15] hw/nvme: SR-IOV with Virtualization Enhancements Klaus Jensen
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=ebbd32070c27ed088b54ddf2c35486d86e461f47.camel@ifi.uio.no \
--to=knuto@ifi.uio.no \
--cc=its@irrelevant.dk \
--cc=kbusch@kernel.org \
--cc=lukasz.gieryk@linux.intel.com \
--cc=lukasz.maniak@linux.intel.com \
--cc=mst@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.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).