All of lore.kernel.org
 help / color / mirror / Atom feed
From: Auger Eric <eric.auger@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: qemu-devel@nongnu.org, Geoffrey McRae <geoff@hostfission.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [for-4.0 PATCH v3 5/9] pcie: Fill PCIESlot link fields to support higher speeds and widths
Date: Thu, 6 Dec 2018 17:35:30 +0100	[thread overview]
Message-ID: <0ecea9bd-1f2c-ed23-5288-ea1595ebc99f@redhat.com> (raw)
In-Reply-To: <20181206090044.7f22a365@x1.home>

Hi Alex,

On 12/6/18 5:00 PM, Alex Williamson wrote:
> On Thu, 6 Dec 2018 12:08:09 +0100
> Auger Eric <eric.auger@redhat.com> wrote:
> 
>> Hi Alex,
>>
>> On 12/4/18 5:26 PM, Alex Williamson wrote:
>>> Make use of the PCIESlot speed and width fields to update link
>>> information beyond those configured in pcie_cap_v1_fill().  This is
>>> only called for devices supporting a version 2 capability and
>>> automatically skips any non-PCIESlot devices.  Only devices with
>>> increased link values generate any visible config space differences.
>>>
>>> Cc: Michael S. Tsirkin <mst@redhat.com>
>>> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
>>> Tested-by: Geoffrey McRae <geoff@hostfission.com>
>>> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
>>> ---
>>>  hw/pci/pcie.c |   72 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>  1 file changed, 72 insertions(+)
>>>
>>> diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
>>> index 61b7b96c52cd..556ec19925b9 100644
>>> --- a/hw/pci/pcie.c
>>> +++ b/hw/pci/pcie.c
>>> @@ -27,6 +27,7 @@
>>>  #include "hw/pci/msi.h"
>>>  #include "hw/pci/pci_bus.h"
>>>  #include "hw/pci/pcie_regs.h"
>>> +#include "hw/pci/pcie_port.h"
>>>  #include "qemu/range.h"
>>>  
>>>  //#define DEBUG_PCIE
>>> @@ -87,6 +88,74 @@ pcie_cap_v1_fill(PCIDevice *dev, uint8_t port, uint8_t type, uint8_t version)
>>>      pci_set_word(cmask + PCI_EXP_LNKSTA, 0);
>>>  }
>>>  
>>> +static void pcie_cap_fill_slot_lnk(PCIDevice *dev)
>>> +{
>>> +    PCIESlot *s = (PCIESlot *)object_dynamic_cast(OBJECT(dev), TYPE_PCIE_SLOT);
>>> +    uint8_t *exp_cap = dev->config + dev->exp.exp_cap;
>>> +
>>> +    /* Skip anything that isn't a PCIESlot */
>>> +    if (!s) {
>>> +        return;
>>> +    }
>>> +
>>> +    /* Clear and fill LNKCAP from what was configured above */
>>> +    pci_long_test_and_clear_mask(exp_cap + PCI_EXP_LNKCAP,
>>> +                                 PCI_EXP_LNKCAP_MLW | PCI_EXP_LNKCAP_SLS);
>>> +    pci_long_test_and_set_mask(exp_cap + PCI_EXP_LNKCAP,
>>> +                               QEMU_PCI_EXP_LNKCAP_MLW(s->width) |
>>> +                               QEMU_PCI_EXP_LNKCAP_MLS(s->speed));
>>> +
>>> +    /*
>>> +     * Link bandwidth notification is required for all root ports and
>>> +     * downstream ports supporting links wider than x1.  
>>
>>
>>> +     */
>>> +    if (s->width > QEMU_PCI_EXP_LNK_X1) {
>>> +        pci_long_test_and_set_mask(exp_cap + PCI_EXP_LNKCAP,
>>> +                                   PCI_EXP_LNKCAP_LBNC);  
>> spec also says "This capability is required for all Root
>> Ports and Switch Downstream Ports supporting Links wider than
>> x1 and/or multiple Link speeds."
>>
>> I see below you are likely to report several speed vectors if speed >
>> 5GT/s so you may also add a test on the speed.
> 
> Good catch, so I'll change the above test to:
> 
>     if (s->width > QEMU_PCI_EXP_LNK_X1 ||
>         s->speed > QEMU_PCI_EXP_LNK_2_5GT) {
> 
>> How are the device types checked?
> 
> Via the object_dynamic_cast() at the top of the function, we'll drop
> anything that isn't a descendant of TYPE_PCIE_SLOT.

Ah OK
> 
>>> +    }
>>> +
>>> +    if (s->speed > QEMU_PCI_EXP_LNK_2_5GT) {
>>> +        /*
>>> +         * Hot-plug capable downstream ports and downstream ports supporting
>>> +         * link speeds greater than 5GT/s must hardwire PCI_EXP_LNKCAP_DLLLARC
>>> +         * to 1b.  PCI_EXP_LNKCAP_DLLLARC implies PCI_EXP_LNKSTA_DLLLA, which
>>> +         * we also hardwire to 1b here.  2.5GT/s hot-plug slots should also
>>> +         * technically implement this, but it's not done here for compatibility.
>>> +         */
>>> +        pci_long_test_and_set_mask(exp_cap + PCI_EXP_LNKCAP,
>>> +                                   PCI_EXP_LNKCAP_DLLLARC);
>>> +        pci_word_test_and_set_mask(exp_cap + PCI_EXP_LNKSTA,
>>> +                                   PCI_EXP_LNKSTA_DLLLA);
>>> +
>>> +        /*
>>> +         * Target Link Speed defaults to the highest link speed supported by
>>> +         * the component.  2.5GT/s devices are permitted to hardwire to zero.
>>> +         */
>>> +        pci_word_test_and_clear_mask(exp_cap + PCI_EXP_LNKCTL2,
>>> +                                     PCI_EXP_LNKCTL2_TLS);
>>> +        pci_word_test_and_set_mask(exp_cap + PCI_EXP_LNKCTL2,
>>> +                                   QEMU_PCI_EXP_LNKCAP_MLS(s->speed) &
>>> +                                   PCI_EXP_LNKCTL2_TLS);
>>> +    }
>>> +
>>> +    /*
>>> +     * 2.5 & 5.0GT/s can be fully described by LNKCAP, but 8.0GT/s is
>>> +     * actually a reference to the highest bit supported in this register.
>>> +     * We assume the device supports all link speeds.
>>> +     */
>>> +    if (s->speed > QEMU_PCI_EXP_LNK_5GT) {
>>> +        pci_long_test_and_clear_mask(exp_cap + PCI_EXP_LNKCAP2, ~0U);
>>> +        pci_long_test_and_set_mask(exp_cap + PCI_EXP_LNKCAP2,
>>> +                                   PCI_EXP_LNKCAP2_SLS_2_5GB |
>>> +                                   PCI_EXP_LNKCAP2_SLS_5_0GB |
>>> +                                   PCI_EXP_LNKCAP2_SLS_8_0GB);
>>> +        if (s->speed > QEMU_PCI_EXP_LNK_8GT) {
>>> +            pci_long_test_and_set_mask(exp_cap + PCI_EXP_LNKCAP2,
>>> +                                       PCI_EXP_LNKCAP2_SLS_16_0GB);  
>> I fail to understand why for 5GB you don't see both 2.5 and 5 as well.
> 
> Because there was a bit of a glitch in the PCIe 2.0 spec where lnkcap2
> is listed as a placeholder, so a strictly gen2 device doesn't need to
> implement lnkcap2.  In gen1, lnkcap supported link speeds (SLS) vector
> defined 0001b for 2.5GT/s, gen2 came along and defined 0010b for
> 2.5GT/s AND 5GT/s, then in the 3.0 spec they decided to slightly
> re-purpose this and SLS became MLS (max link speed), and introduced
> lnkcap2 to indicate which speeds were supported.  So the original spec
> definition of SLS didn't really give hardware the flexibility if they
> should decide they don't want to validate intermediate link speeds.

OK Thanks

Eric
> Thanks,
> 
> Alex
> 
>>> +        }
>>> +    }
>>> +}
>>> +
>>>  int pcie_cap_init(PCIDevice *dev, uint8_t offset,
>>>                    uint8_t type, uint8_t port,
>>>                    Error **errp)
>>> @@ -108,6 +177,9 @@ int pcie_cap_init(PCIDevice *dev, uint8_t offset,
>>>      /* Filling values common with v1 */
>>>      pcie_cap_v1_fill(dev, port, type, PCI_EXP_FLAGS_VER2);
>>>  
>>> +    /* Fill link speed and width options */
>>> +    pcie_cap_fill_slot_lnk(dev);
>>> +
>>>      /* Filling v2 specific values */
>>>      pci_set_long(exp_cap + PCI_EXP_DEVCAP2,
>>>                   PCI_EXP_DEVCAP2_EFF | PCI_EXP_DEVCAP2_EETLPP);
>>>
>>>   
>>
>> Thanks
>>
>> Eric
> 

  reply	other threads:[~2018-12-06 16:35 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-04 16:25 [Qemu-devel] [for-4.0 PATCH v3 0/9] pcie: Enhanced link speed and width support Alex Williamson
2018-12-04 16:26 ` [Qemu-devel] [for-4.0 PATCH v3 1/9] pcie: Create enums for link speed and width Alex Williamson
2018-12-04 17:02   ` Philippe Mathieu-Daudé
2018-12-06 11:08   ` Auger Eric
2018-12-04 16:26 ` [Qemu-devel] [for-4.0 PATCH v3 2/9] pci: Sync PCIe downstream port LNKSTA on read Alex Williamson
2018-12-06 11:08   ` Auger Eric
2018-12-04 16:26 ` [Qemu-devel] [for-4.0 PATCH v3 3/9] qapi: Define PCIe link speed and width properties Alex Williamson
2018-12-05  9:09   ` Markus Armbruster
2018-12-05 15:53     ` Alex Williamson
2018-12-05 12:42   ` Auger Eric
2018-12-05 14:16     ` Markus Armbruster
2018-12-05 14:27       ` Auger Eric
2018-12-05 16:21         ` Markus Armbruster
2018-12-05 16:44       ` Alex Williamson
2018-12-06 16:04     ` Alex Williamson
2018-12-04 16:26 ` [Qemu-devel] [for-4.0 PATCH v3 4/9] pcie: Add link speed and width fields to PCIESlot Alex Williamson
2018-12-06 11:08   ` Auger Eric
2018-12-04 16:26 ` [Qemu-devel] [for-4.0 PATCH v3 5/9] pcie: Fill PCIESlot link fields to support higher speeds and widths Alex Williamson
2018-12-06 11:08   ` Auger Eric
2018-12-06 16:00     ` Alex Williamson
2018-12-06 16:35       ` Auger Eric [this message]
2018-12-04 16:26 ` [Qemu-devel] [for-4.0 PATCH v3 6/9] pcie: Allow generic PCIe root port to specify link speed and width Alex Williamson
2018-12-06 11:22   ` Auger Eric
2018-12-04 16:27 ` [Qemu-devel] [for-4.0 PATCH v3 7/9] vfio/pci: Remove PCIe Link Status emulation Alex Williamson
2018-12-06 11:17   ` Auger Eric
2018-12-04 16:27 ` [Qemu-devel] [for-4.0 PATCH v3 8/9] q35/440fx/arm/spapr: Add QEMU 4.0 machine type Alex Williamson
2018-12-04 19:04   ` [Qemu-devel] [for-4.0 PATCH v3.1 8/9] q35/440fx/arm/spapr/ccw: " Alex Williamson
2018-12-04 19:16     ` Christian Borntraeger
2018-12-04 19:26       ` Alex Williamson
2018-12-04 19:29         ` Peter Maydell
2018-12-04 19:56           ` Alex Williamson
2018-12-04 20:02             ` Christian Borntraeger
2018-12-05  8:32             ` Cornelia Huck
2018-12-05 15:42               ` Alex Williamson
2018-12-05 16:01                 ` Cornelia Huck
2018-12-06 12:52             ` Eduardo Habkost
2018-12-06 16:24               ` Alex Williamson
2018-12-04 19:39       ` Marc-André Lureau
2018-12-06 11:20   ` [Qemu-devel] [for-4.0 PATCH v3 8/9] q35/440fx/arm/spapr: " Auger Eric
2018-12-06 19:12   ` Eduardo Habkost
2018-12-06 19:27     ` Alex Williamson
2018-12-04 16:27 ` [Qemu-devel] [for-4.0 PATCH v3 9/9] pcie: Fast PCIe root ports for new machines Alex Williamson
2018-12-05 21:35   ` Alex Williamson
2018-12-06 11:22   ` Auger Eric

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=0ecea9bd-1f2c-ed23-5288-ea1595ebc99f@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=geoff@hostfission.com \
    --cc=mst@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.