All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: <mst@redhat.com>, Markus Armbruster <armbru@redhat.com>,
	<qemu-devel@nongnu.org>, <ankita@nvidia.com>,
	<marcel.apfelbaum@gmail.com>, <philmd@linaro.org>,
	Richard Henderson <richard.henderson@linaro.org>,
	<linuxarm@huawei.com>, Dave Jiang <dave.jiang@intel.com>,
	Huang Ying <ying.huang@intel.com>,
	Paolo Bonzini <pbonzini@redhat.com>, <eduardo@habkost.net>,
	<linux-cxl@vger.kernel.org>, Michael Roth <michael.roth@amd.com>,
	Ani Sinha <anisinha@redhat.com>
Subject: Re: [PATCH v3 05/11] hw/pci: Add a bus property to pci_props and use for acpi/gi
Date: Mon, 1 Jul 2024 16:59:28 +0100	[thread overview]
Message-ID: <20240701165928.00006213@Huawei.com> (raw)
In-Reply-To: <20240628135804.12434f5e@imammedo.users.ipa.redhat.com>

On Fri, 28 Jun 2024 13:58:04 +0200
Igor Mammedov <imammedo@redhat.com> wrote:

> On Thu, 27 Jun 2024 15:09:12 +0200
> Igor Mammedov <imammedo@redhat.com> wrote:
> 
> > On Thu, 20 Jun 2024 17:03:13 +0100
> > Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:
> >   
> > > Using a property allows us to hide the internal details of the PCI device
> > > from the code to build a SRAT Generic Initiator Affinity Structure with
> > > PCI Device Handle.
> > > 
> > > Suggested-by: Igor Mammedov <imammedo@redhat.com>
> > > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > 
> > > ---
> > > V3: New patch
> > > ---
> > >  hw/acpi/acpi_generic_initiator.c | 11 ++++++-----
> > >  hw/pci/pci.c                     | 14 ++++++++++++++
> > >  2 files changed, 20 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/hw/acpi/acpi_generic_initiator.c b/hw/acpi/acpi_generic_initiator.c
> > > index 73bafaaaea..34284359f0 100644
> > > --- a/hw/acpi/acpi_generic_initiator.c
> > > +++ b/hw/acpi/acpi_generic_initiator.c
> > > @@ -9,6 +9,7 @@
> > >  #include "hw/boards.h"
> > >  #include "hw/pci/pci_device.h"
> > >  #include "qemu/error-report.h"
> > > +#include "qapi/error.h"
> > >  
> > >  typedef struct AcpiGenericInitiatorClass {
> > >      ObjectClass parent_class;
> > > @@ -79,7 +80,7 @@ static int build_acpi_generic_initiator(Object *obj, void *opaque)
> > >      MachineState *ms = MACHINE(qdev_get_machine());
> > >      AcpiGenericInitiator *gi;
> > >      GArray *table_data = opaque;
> > > -    PCIDevice *pci_dev;
> > > +    uint8_t bus, devfn;
> > >      Object *o;
> > >  
> > >      if (!object_dynamic_cast(obj, TYPE_ACPI_GENERIC_INITIATOR)) {
> > > @@ -100,10 +101,10 @@ static int build_acpi_generic_initiator(Object *obj, void *opaque)
> > >          exit(1);
> > >      }
> > >  
> > > -    pci_dev = PCI_DEVICE(o);
> > > -    build_srat_pci_generic_initiator(table_data, gi->node, 0,
> > > -                                     pci_bus_num(pci_get_bus(pci_dev)),
> > > -                                     pci_dev->devfn);
> > > +    bus = object_property_get_uint(o, "bus", &error_fatal);
> > > +    devfn = object_property_get_uint(o, "addr", &error_fatal);
> > > +
> > > +    build_srat_pci_generic_initiator(table_data, gi->node, 0, bus, devfn);
> > >  
> > >      return 0;
> > >  }
> > > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > > index 324c1302d2..b4b499b172 100644
> > > --- a/hw/pci/pci.c
> > > +++ b/hw/pci/pci.c
> > > @@ -67,6 +67,19 @@ static char *pcibus_get_fw_dev_path(DeviceState *dev);
> > >  static void pcibus_reset_hold(Object *obj, ResetType type);
> > >  static bool pcie_has_upstream_port(PCIDevice *dev);
> > >  
> > > +static void prop_pci_bus_get(Object *obj, Visitor *v, const char *name,
> > > +                             void *opaque, Error **errp)
> > > +{
> > > +    uint8_t bus = pci_dev_bus_num(PCI_DEVICE(obj));
> > > +
> > > +    visit_type_uint8(v, name, &bus, errp);
> > > +}
> > > +
> > > +static const PropertyInfo prop_pci_bus = {
> > > +    .name = "bus",    
> > 
> > /me confused,
> > didn't we have 'bus' property for PCI devices already?
> > 
> > i.e. I can add PCI device like this
> >   -device e1000,bus=pci.0,addr=0x6,...  
> 
> to avoid confusion, I'd suggest to name it to 'busnr'
> (or be more specific (primary|secondary)_busnr if applicable)
For generic initiators we are always dealing with an EP so I think
busnr alone is appropriate. If we need similar for bridges we
can add that later.


> 
> >   
> >   
> > > +    .get = prop_pci_bus_get,
> > > +};
> > > +
> > >  static Property pci_props[] = {
> > >      DEFINE_PROP_PCI_DEVFN("addr", PCIDevice, devfn, -1),
> > >      DEFINE_PROP_STRING("romfile", PCIDevice, romfile),
> > > @@ -85,6 +98,7 @@ static Property pci_props[] = {
> > >                      QEMU_PCIE_ERR_UNC_MASK_BITNR, true),
> > >      DEFINE_PROP_BIT("x-pcie-ari-nextfn-1", PCIDevice, cap_present,
> > >                      QEMU_PCIE_ARI_NEXTFN_1_BITNR, false),
> > > +    { .name = "bus", .info = &prop_pci_bus },
> > >      DEFINE_PROP_END_OF_LIST()
> > >  };
> > >      
> >   
> 
> 


WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: Igor Mammedov <imammedo@redhat.com>
Cc: <mst@redhat.com>, Markus Armbruster <armbru@redhat.com>,
	<qemu-devel@nongnu.org>, <ankita@nvidia.com>,
	<marcel.apfelbaum@gmail.com>, <philmd@linaro.org>,
	Richard Henderson <richard.henderson@linaro.org>,
	<linuxarm@huawei.com>, Dave Jiang <dave.jiang@intel.com>,
	Huang Ying <ying.huang@intel.com>,
	Paolo Bonzini <pbonzini@redhat.com>, <eduardo@habkost.net>,
	<linux-cxl@vger.kernel.org>, Michael Roth <michael.roth@amd.com>,
	Ani Sinha <anisinha@redhat.com>
Subject: Re: [PATCH v3 05/11] hw/pci: Add a bus property to pci_props and use for acpi/gi
Date: Mon, 1 Jul 2024 16:59:28 +0100	[thread overview]
Message-ID: <20240701165928.00006213@Huawei.com> (raw)
In-Reply-To: <20240628135804.12434f5e@imammedo.users.ipa.redhat.com>

On Fri, 28 Jun 2024 13:58:04 +0200
Igor Mammedov <imammedo@redhat.com> wrote:

> On Thu, 27 Jun 2024 15:09:12 +0200
> Igor Mammedov <imammedo@redhat.com> wrote:
> 
> > On Thu, 20 Jun 2024 17:03:13 +0100
> > Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:
> >   
> > > Using a property allows us to hide the internal details of the PCI device
> > > from the code to build a SRAT Generic Initiator Affinity Structure with
> > > PCI Device Handle.
> > > 
> > > Suggested-by: Igor Mammedov <imammedo@redhat.com>
> > > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > 
> > > ---
> > > V3: New patch
> > > ---
> > >  hw/acpi/acpi_generic_initiator.c | 11 ++++++-----
> > >  hw/pci/pci.c                     | 14 ++++++++++++++
> > >  2 files changed, 20 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/hw/acpi/acpi_generic_initiator.c b/hw/acpi/acpi_generic_initiator.c
> > > index 73bafaaaea..34284359f0 100644
> > > --- a/hw/acpi/acpi_generic_initiator.c
> > > +++ b/hw/acpi/acpi_generic_initiator.c
> > > @@ -9,6 +9,7 @@
> > >  #include "hw/boards.h"
> > >  #include "hw/pci/pci_device.h"
> > >  #include "qemu/error-report.h"
> > > +#include "qapi/error.h"
> > >  
> > >  typedef struct AcpiGenericInitiatorClass {
> > >      ObjectClass parent_class;
> > > @@ -79,7 +80,7 @@ static int build_acpi_generic_initiator(Object *obj, void *opaque)
> > >      MachineState *ms = MACHINE(qdev_get_machine());
> > >      AcpiGenericInitiator *gi;
> > >      GArray *table_data = opaque;
> > > -    PCIDevice *pci_dev;
> > > +    uint8_t bus, devfn;
> > >      Object *o;
> > >  
> > >      if (!object_dynamic_cast(obj, TYPE_ACPI_GENERIC_INITIATOR)) {
> > > @@ -100,10 +101,10 @@ static int build_acpi_generic_initiator(Object *obj, void *opaque)
> > >          exit(1);
> > >      }
> > >  
> > > -    pci_dev = PCI_DEVICE(o);
> > > -    build_srat_pci_generic_initiator(table_data, gi->node, 0,
> > > -                                     pci_bus_num(pci_get_bus(pci_dev)),
> > > -                                     pci_dev->devfn);
> > > +    bus = object_property_get_uint(o, "bus", &error_fatal);
> > > +    devfn = object_property_get_uint(o, "addr", &error_fatal);
> > > +
> > > +    build_srat_pci_generic_initiator(table_data, gi->node, 0, bus, devfn);
> > >  
> > >      return 0;
> > >  }
> > > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > > index 324c1302d2..b4b499b172 100644
> > > --- a/hw/pci/pci.c
> > > +++ b/hw/pci/pci.c
> > > @@ -67,6 +67,19 @@ static char *pcibus_get_fw_dev_path(DeviceState *dev);
> > >  static void pcibus_reset_hold(Object *obj, ResetType type);
> > >  static bool pcie_has_upstream_port(PCIDevice *dev);
> > >  
> > > +static void prop_pci_bus_get(Object *obj, Visitor *v, const char *name,
> > > +                             void *opaque, Error **errp)
> > > +{
> > > +    uint8_t bus = pci_dev_bus_num(PCI_DEVICE(obj));
> > > +
> > > +    visit_type_uint8(v, name, &bus, errp);
> > > +}
> > > +
> > > +static const PropertyInfo prop_pci_bus = {
> > > +    .name = "bus",    
> > 
> > /me confused,
> > didn't we have 'bus' property for PCI devices already?
> > 
> > i.e. I can add PCI device like this
> >   -device e1000,bus=pci.0,addr=0x6,...  
> 
> to avoid confusion, I'd suggest to name it to 'busnr'
> (or be more specific (primary|secondary)_busnr if applicable)
For generic initiators we are always dealing with an EP so I think
busnr alone is appropriate. If we need similar for bridges we
can add that later.


> 
> >   
> >   
> > > +    .get = prop_pci_bus_get,
> > > +};
> > > +
> > >  static Property pci_props[] = {
> > >      DEFINE_PROP_PCI_DEVFN("addr", PCIDevice, devfn, -1),
> > >      DEFINE_PROP_STRING("romfile", PCIDevice, romfile),
> > > @@ -85,6 +98,7 @@ static Property pci_props[] = {
> > >                      QEMU_PCIE_ERR_UNC_MASK_BITNR, true),
> > >      DEFINE_PROP_BIT("x-pcie-ari-nextfn-1", PCIDevice, cap_present,
> > >                      QEMU_PCIE_ARI_NEXTFN_1_BITNR, false),
> > > +    { .name = "bus", .info = &prop_pci_bus },
> > >      DEFINE_PROP_END_OF_LIST()
> > >  };
> > >      
> >   
> 
> 



  reply	other threads:[~2024-07-01 15:59 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-20 16:03 [PATCH v3 qemu 00/11] acpi: NUMA nodes for CXL HB as GP + complex NUMA test Jonathan Cameron
2024-06-20 16:03 ` Jonathan Cameron via
2024-06-20 16:03 ` [PATCH v3 01/11] hw/acpi: Fix ordering of BDF in Generic Initiator PCI Device Handle Jonathan Cameron
2024-06-20 16:03   ` Jonathan Cameron via
2024-06-27 12:44   ` Igor Mammedov
2024-06-20 16:03 ` [PATCH v3 02/11] hw/acpi/GI: Fix trivial parameter alignment issue Jonathan Cameron
2024-06-20 16:03   ` Jonathan Cameron via
2024-06-27 12:43   ` Igor Mammedov
2024-06-20 16:03 ` [PATCH v3 03/11] hw/acpi: Move AML building code for Generic Initiators to aml_build.c Jonathan Cameron
2024-06-20 16:03   ` Jonathan Cameron via
2024-06-27 12:42   ` Igor Mammedov
2024-06-27 12:44     ` Michael S. Tsirkin
2024-06-27 12:45       ` Igor Mammedov
2024-06-20 16:03 ` [PATCH v3 04/11] hw/acpi: Rename build_all_acpi_generic_initiators() to build_acpi_generic_initiator() Jonathan Cameron
2024-06-20 16:03   ` Jonathan Cameron via
2024-06-27 12:56   ` Igor Mammedov
2024-06-20 16:03 ` [PATCH v3 05/11] hw/pci: Add a bus property to pci_props and use for acpi/gi Jonathan Cameron
2024-06-20 16:03   ` Jonathan Cameron via
2024-06-27 13:09   ` Igor Mammedov
2024-06-28 11:58     ` Igor Mammedov
2024-07-01 15:59       ` Jonathan Cameron [this message]
2024-07-01 15:59         ` Jonathan Cameron via
2024-06-20 16:03 ` [PATCH v3 06/11] acpi/pci: Move Generic Initiator object handling into acpi/pci.* Jonathan Cameron
2024-06-20 16:03   ` Jonathan Cameron via
2024-06-20 16:03 ` [PATCH v3 07/11] hw/pci-bridge: Add acpi_uid property to CXL PXB Jonathan Cameron
2024-06-20 16:03   ` Jonathan Cameron via
2024-06-27 13:27   ` Igor Mammedov
2024-06-27 13:46     ` Jonathan Cameron
2024-06-27 13:46       ` Jonathan Cameron via
2024-06-28 11:55       ` Igor Mammedov
2024-07-01 17:52         ` Jonathan Cameron
2024-07-01 17:52           ` Jonathan Cameron via
2024-07-02 10:41           ` Jonathan Cameron
2024-07-02 10:41             ` Jonathan Cameron via
2024-06-20 16:03 ` [PATCH v3 08/11] hw/acpi: Generic Port Affinity Structure support Jonathan Cameron
2024-06-20 16:03   ` Jonathan Cameron via
2024-07-01  8:52   ` Igor Mammedov
2024-07-01 15:47     ` Jonathan Cameron
2024-07-01 15:47       ` Jonathan Cameron via
2024-06-20 16:03 ` [PATCH v3 09/11] bios-tables-test: Allow for new acpihmat-generic-x test data Jonathan Cameron
2024-06-20 16:03   ` Jonathan Cameron via
2024-06-27 12:51   ` Igor Mammedov
2024-06-27 13:50     ` Igor Mammedov
2024-06-20 16:03 ` [PATCH v3 10/11] bios-tables-test: Add complex SRAT / HMAT test for GI GP Jonathan Cameron
2024-06-20 16:03   ` Jonathan Cameron via
2024-06-20 16:03 ` [PATCH v3 11/11] bios-tables-test: Add data for complex numa test (GI, GP etc) Jonathan Cameron
2024-06-20 16:03   ` Jonathan Cameron via
2024-06-21  3:25 ` [PATCH v3 qemu 00/11] acpi: NUMA nodes for CXL HB as GP + complex NUMA test Huang, Ying
2024-06-21 16:20 ` Jonathan Cameron
2024-06-21 16:20   ` Jonathan Cameron via

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=20240701165928.00006213@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=anisinha@redhat.com \
    --cc=ankita@nvidia.com \
    --cc=armbru@redhat.com \
    --cc=dave.jiang@intel.com \
    --cc=eduardo@habkost.net \
    --cc=imammedo@redhat.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=michael.roth@amd.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=ying.huang@intel.com \
    /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.