From: Igor Mammedov <imammedo@redhat.com>
To: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
qemu-devel@nongnu.org,
Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Subject: Re: [PATCH] pcie: enable Extended tag field capability
Date: Tue, 22 Oct 2024 09:34:49 +0200 [thread overview]
Message-ID: <20241022093449.04c007cb@imammedo.users.ipa.redhat.com> (raw)
In-Reply-To: <560a13ec-3954-45b6-a3b7-85c106b36eaf@linaro.org>
On Fri, 18 Oct 2024 12:24:05 +0200
Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org> wrote:
> W dniu 17.10.2024 o 18:58, Michael S. Tsirkin pisze:
> >> diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
> >> index 4b2f0805c6..54c0f1ec67 100644
> >> --- a/hw/pci/pcie.c
> >> +++ b/hw/pci/pcie.c
> >> @@ -86,7 +86,8 @@ pcie_cap_v1_fill(PCIDevice *dev, uint8_t port, uint8_t type, uint8_t version)
> >> * Specification, Revision 1.1., or subsequent PCI Express Base
> >> * Specification revisions.
> >> */
> >> - pci_set_long(exp_cap + PCI_EXP_DEVCAP, PCI_EXP_DEVCAP_RBER);
> >> + pci_set_long(exp_cap + PCI_EXP_DEVCAP, PCI_EXP_DEVCAP_RBER |
> >> + PCI_EXP_DEVCAP_EXT_TAG);
> >>
> >> pci_set_long(exp_cap + PCI_EXP_LNKCAP,
> >> (port << PCI_EXP_LNKCAP_PN_SHIFT) |
> >
> > We can't change capabilities unconditionally.
> > It needs at least a machine type compat thing.
>
> Started looking and wonder how to pass it from MachineClass level down
> to pcie.c/pcie_cap_v1_fill() level.
see as an example:
fa905f65c5549 hw/nvme: add machine compatibility parameter to enable msix exclusive bar
> hw/arm/sbsa-ref.c (the machine I know best) has create_pcie() which
> allocates PCI_HOST_BRIDGE and then creates 2 pcie devices (default_nic
> (e1000e) and bochs-display gfx).
>
> If I add "pcie_uses_ext_tags = true" to SBSAMachineState then I need to
> have it stored in PCIBus structure so pci_create_simple() will know.
> This function would copy it into "dev" (PCIDevice) to make it pass to
> pcie_cap_v1_fill() function.
>
> But that's not right way because other PCIe devices are created in other
> places.
>
> Need to dig deeper.
>
prev parent reply other threads:[~2024-10-22 7:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-17 13:33 [PATCH] pcie: enable Extended tag field capability Marcin Juszkiewicz
2024-10-17 16:58 ` Michael S. Tsirkin
2024-10-17 19:18 ` Marcin Juszkiewicz
2024-10-18 10:24 ` Marcin Juszkiewicz
2024-10-22 7:34 ` Igor Mammedov [this message]
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=20241022093449.04c007cb@imammedo.users.ipa.redhat.com \
--to=imammedo@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=marcin.juszkiewicz@linaro.org \
--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.