Re: [SeaBIOS] [RFC v3] pciinit: setup mcfg for pxb-pcie to support multiple pci domains

[Zihan Yang]

Kevin O'Connor  于2018年9月28日周五 上午6:30写道：
>
> On Thu, Sep 27, 2018 at 11:05:13PM +0800, Zihan Yang wrote:
> > Laszlo Ersek  于2018年9月26日周三 上午1:17写道：
> > > First, I fail to see the use case where ~256 PCI bus numbers aren't
> > > enough. If I strain myself, perhaps I can imagine using ~200 PCIe root
> > > ports on Q35 (each of which requires a separate bus number), so that we
> > > can independently hot-plug 200 devices then. And that's supposedly not
> > > enough, because we want... 300? 400? A thousand? Doesn't sound realistic
> > > to me. (This is not meant to be a strawman argument, I really have no
> > > idea what the feature would be useful for.)
> >
> > It might not be very intuitive, but it indeed exists. The very
> > beginning discussion
> > about 4 months ago has mentioned a possible use case, and I paste it here
> [...]
> > Things might change in the future if we can figure out a better solution, 
> > and I
> > hope we can have an easier and more elegant solution in OVMF. But now
> > we are just trying to give a possible solution as a poc.
>
> Thanks.  I wasn't aware this was a proof of concept.  (Nor have I been
> following the discussions on the qemu list.)  I don't think it makes
> sense to merge this into the main SeaBIOS repository.  The
> QEMU/firmware interface is already complex and I don't think we should
> complicate it further without a more concrete use case.  In
> particular, it seems unclear if 256 buses is enough or if 1024 buses
> is too little.

Yes, 1024 is indeed an ambiguous bound for now, but can you elaborate how
concrete should the use case be? For example, do we need to know what
they are going to do with so many network/storage devices? Because I
think normal users rarely need so many devices, but those who really want
devices might not always be willing to tell us their internal project status.

Thanks
Zihan

> -Kevin

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

Re: [SeaBIOS] [RFC v3] pciinit: setup mcfg for pxb-pcie to support multiple pci domains

[Zihan Yang]

Dr. David Alan Gilbert  于2018年9月28日周五 上午1:53写道：
>
> * Zihan Yang (whois.zihan.y...@gmail.com) wrote:
> > HI Laszlo
> > Laszlo Ersek  于2018年9月26日周三 上午1:17写道：
> > >
> > > On 09/25/18 17:38, Kevin O'Connor wrote:
> > > > On Mon, Sep 17, 2018 at 11:02:59PM +0800, Zihan Yang wrote:
> > > >> To support multiple pci domains of pxb-pcie device in qemu, we need to 
> > > >> setup
> > > >> mcfg range in seabios. We use [0x8000, 0xb000) to hold new 
> > > >> domain mcfg
> > > >> table for now, and we need to retrieve the desired mcfg size of each 
> > > >> pxb-pcie
> > > >> from a hidden bar because they may not need the whole 256 busses, 
> > > >> which also
> > > >> enables us to support more domains within a limited range (768MB)
> > > >
> > > > At a highlevel, this looks okay to me.  I'd like to see additional
> > > > reviews from others more familiar with the QEMU PCI code, though.
> > > >
> > > > Is the plan to do the same thing for OVMF?
> > >
> > > I remain entirely unconvinced that this feature is useful. (I've stated
> > > so before.)
> > >
> > > I believe the latest QEMU RFC posting (v5) is here:
> > >
> > > [Qemu-devel] [RFC v5 0/6] pci_expander_brdige: support separate pci
> > > domain for pxb-pcie
> > >
> > > http://mid.mail-archive.com/1537196258-12581-1-git-send-email-whois.zihan.yang@gmail.com
> > >
> > > First, I fail to see the use case where ~256 PCI bus numbers aren't
> > > enough. If I strain myself, perhaps I can imagine using ~200 PCIe root
> > > ports on Q35 (each of which requires a separate bus number), so that we
> > > can independently hot-plug 200 devices then. And that's supposedly not
> > > enough, because we want... 300? 400? A thousand? Doesn't sound realistic
> > > to me. (This is not meant to be a strawman argument, I really have no
> > > idea what the feature would be useful for.)
> >
> > It might not be very intuitive, but it indeed exists. The very
> > beginning discussion
> > about 4 months ago has mentioned a possible use case, and I paste it here
> >
> > - We have Ray from Intel trying to use 1000 virtio-net devices
>
> why that many?

I think I'll cc Marcel for the details but I remember that he is not aware of
Intel's purpose either. A guess would be that Intel has NFV, DPDK projects,
maybe they are playing some magic on the network? I wish I knew, but I
doubt whether Intel would let us know their internal projects.

> > - We may have a VM managing some backups (tapes), we may have a lot of 
> > these.
>
> I'm curious; what does tape backup have to do with the number of PCI
> slots/busses?

I'm not very clear about how tape works in qemu, but the problem is pcie
devices under q35. The pcie topology requires one device per bus, therefore
the 256 bus might not be enough if we have many pcie devices. Current
pxb-pcie still resides in domain 0, and is limited by the number 256. I think
he means these tape devices would consume all the available busses
we have in domain 0.

Thanks
Zihan

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

Re: [SeaBIOS] [RFC v3] pciinit: setup mcfg for pxb-pcie to support multiple pci domains

[Zihan Yang]

HI Laszlo
Laszlo Ersek  于2018年9月26日周三 上午1:17写道：
>
> On 09/25/18 17:38, Kevin O'Connor wrote:
> > On Mon, Sep 17, 2018 at 11:02:59PM +0800, Zihan Yang wrote:
> >> To support multiple pci domains of pxb-pcie device in qemu, we need to 
> >> setup
> >> mcfg range in seabios. We use [0x8000, 0xb000) to hold new domain 
> >> mcfg
> >> table for now, and we need to retrieve the desired mcfg size of each 
> >> pxb-pcie
> >> from a hidden bar because they may not need the whole 256 busses, which 
> >> also
> >> enables us to support more domains within a limited range (768MB)
> >
> > At a highlevel, this looks okay to me.  I'd like to see additional
> > reviews from others more familiar with the QEMU PCI code, though.
> >
> > Is the plan to do the same thing for OVMF?
>
> I remain entirely unconvinced that this feature is useful. (I've stated
> so before.)
>
> I believe the latest QEMU RFC posting (v5) is here:
>
> [Qemu-devel] [RFC v5 0/6] pci_expander_brdige: support separate pci
> domain for pxb-pcie
>
> http://mid.mail-archive.com/1537196258-12581-1-git-send-email-whois.zihan.yang@gmail.com
>
> First, I fail to see the use case where ~256 PCI bus numbers aren't
> enough. If I strain myself, perhaps I can imagine using ~200 PCIe root
> ports on Q35 (each of which requires a separate bus number), so that we
> can independently hot-plug 200 devices then. And that's supposedly not
> enough, because we want... 300? 400? A thousand? Doesn't sound realistic
> to me. (This is not meant to be a strawman argument, I really have no
> idea what the feature would be useful for.)

It might not be very intuitive, but it indeed exists. The very
beginning discussion
about 4 months ago has mentioned a possible use case, and I paste it here

- We have Ray from Intel trying to use 1000 virtio-net devices
- We may have a VM managing some backups (tapes), we may have a lot of these.
- We may want indeed to create a nested solution as Michael mentioned.

The thread can be found in
https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg04667.html

Also, a later post from a person in Dell stated in the list that he would need
this feature for Intel VMD In Dell EMC? I have no idea about the details,
but since they went here for help, I guess they do can benefit from it somehow.

> Second, the v5 RFC doesn't actually address the alleged bus number
> shortage. IIUC, it supports a low number of ECAM ranges under 4GB, but
> those are (individually) limited in the bus number ranges they can
> accommodate (due to 32-bit address space shortage). So more or less the
> current approach just fragments the bus number space we already have, to
> multiple domains.
>
> Third, should a subsequent iteration of the QEMU series put those extra
> ECAMs above 4GB, with the intent to leave the enumeration of those
> hierarchies to the "guest OS", it would present an incredible
> implementation mess for OVMF. If people gained the ability to attach
> storage or network to those domains, on the QEMU command line, they
> would expect to boot off of them, using UEFI. Then OVMF would have to
> make sure the controllers could be bound by their respective UEFI
> drivers. That in turn would require functional config space access
> (ECAM) at semi-random 64-bit addresses.

I'm not familiar with OVMF, so I'm afraid I don't know how to make it easier
for OVMF, the division of 64bit space in OVMF is out of my purpose. There
is no plan to implement it in OVMF for now, we just want to make the
seabios/qemu patch a proof of concept.

As for the seabios, it access devices through port 0xcf8/0xcfc, which is binded
to q35 host in qemu. If we want to change the mmconfig size of pxb-pcie
(instead of using whole 256MB), we must know its desired size, which is passed
as a hidden bar. Unfortunately the configuration space of pxb-pcie device
cannot be accessed with 0xcf8/0xcfc because they are in different host bridge.
At this time the ECAM is not configured yet, so no able to use MMIO too.
In previous version, I tried to bind pxb host to other ports in qemu, so that we
can use port io to access the config space of pxb-pcie, but it seems a
little dirty,

Another issue is how seabios initialize things. It will first do pci_setup when
things like RSDP is not loaded. It is inconvenient to retrieve MCFG table and
other information, so we cannot infer the mmconfig addr and size from MCFG
table in seabios.

Therefore we fall back to an alternative that we support 4x of devices as the
first step, and let the guest os do the initialization. The inability to boot
from devices in another domain is indeed an issue, and we don't have very
good solution to it yet.

Things might change in the

[SeaBIOS] [RFC v3] Support multiple pci domain for pxb-pcie of qemu

[Zihan Yang]

The qemu part of this patch can be found in
https://lists.gnu.org/archive/html/qemu-devel/2018-09/msg01988.html

pxb-pcie device in qemu uses only one pci domain(0) so far, which means
there are at most 256 busses. However, pcie topology requires one bus per
device, which will use up the busses soon if there are more pcie devices.

To solve the problem, QEMU can put the pxb-pcie in separate pci domain so
we can get more devices. As QEMU relies on seabios to allocate space for
its mcfg table, we must modify the seabios to configure mcfg_base and
mcfg_size for qemu.

Since pxb-pcie may only uses a subset of all 256 busses in a domain,
we let qemu pass its desired mcfg_size as a hidden bar, seabios just
decides the mcfg_base for it.

Compared with previous design, mmconfig is not put above 4g anymore,
but inside [0x8000, 0xb000), and leaves the major part of
configuration to guest OS, which makes the whole part of code much
simpler.

Changelog:
v3 <- v2
- Refactor design so that seabios only does minimal mcfg configure, and
  leaves everything else to guest os. This makes the code much simpler.
- Does not put mcfg over 4g anymore, but inside [0x8000, 0xb000)
  Over 4g placement can be expected in future version.

v2 <- v1
- Fix bugs in filtering domains when traversing pci devices
- Reformat some hardcoded codes, such as probing the pci device in pci_setup

Zihan Yang (1):
  pciinit: setup mcfg for pxb-pcie to support multiple pci domains

 src/fw/dev-q35.h |  7 +++
 src/fw/pciinit.c | 32 
 src/hw/pci_ids.h |  1 +
 3 files changed, 40 insertions(+)

-- 
2.7.4


___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

[SeaBIOS] [RFC v3] pciinit: setup mcfg for pxb-pcie to support multiple pci domains

[Zihan Yang]

To support multiple pci domains of pxb-pcie device in qemu, we need to setup
mcfg range in seabios. We use [0x8000, 0xb000) to hold new domain mcfg
table for now, and we need to retrieve the desired mcfg size of each pxb-pcie
from a hidden bar because they may not need the whole 256 busses, which also
enables us to support more domains within a limited range (768MB)

Signed-off-by: Zihan Yang 
---
 src/fw/dev-q35.h |  7 +++
 src/fw/pciinit.c | 32 
 src/hw/pci_ids.h |  1 +
 3 files changed, 40 insertions(+)

diff --git a/src/fw/dev-q35.h b/src/fw/dev-q35.h
index 201825d..229cd81 100644
--- a/src/fw/dev-q35.h
+++ b/src/fw/dev-q35.h
@@ -49,4 +49,11 @@
 #define ICH9_APM_ACPI_ENABLE   0x2
 #define ICH9_APM_ACPI_DISABLE  0x3
 
+#define PXB_PCIE_HOST_BRIDGE_MCFG_BAR  0x50/* 64bit register */
+#define PXB_PCIE_HOST_BRIDGE_MCFG_SIZE 0x58/* 32bit register */
+#define PXB_PCIE_HOST_BRIDGE_ENABLEQ35_HOST_BRIDGE_PCIEXBAREN
+/* pxb-pcie can use [0x8000, 0xb000), be careful not to overflow */
+#define PXB_PCIE_HOST_BRIDGE_MCFG_SIZE_ADDR0x8000
+#define PXB_PCIE_HOST_BRIDGE_MCFG_SIZE_ADDR_UPPER Q35_HOST_BRIDGE_PCIEXBAR_ADDR
+
 #endif // dev-q35.h
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
index c0634bc..e0ac22c 100644
--- a/src/fw/pciinit.c
+++ b/src/fw/pciinit.c
@@ -51,6 +51,7 @@ u64 pcimem_end = BUILD_PCIMEM_END;
 u64 pcimem64_start = BUILD_PCIMEM64_START;
 u64 pcimem64_end   = BUILD_PCIMEM64_END;
 u64 pci_io_low_end = 0xa000;
+u64 pxb_pcie_mcfg_base = PXB_PCIE_HOST_BRIDGE_MCFG_SIZE_ADDR;
 
 struct pci_region_entry {
 struct pci_device *dev;
@@ -507,11 +508,42 @@ static void mch_mem_addr_setup(struct pci_device *dev, 
void *arg)
 pci_io_low_end = acpi_pm_base;
 }
 
+static void pxb_pcie_mem_addr_setup(struct pci_device *dev, void *arg)
+{
+u64 mcfg_base;
+u32 mcfg_size = pci_config_readl(dev->bdf, PXB_PCIE_HOST_BRIDGE_MCFG_SIZE);
+
+/* 0 means this pxb-pcie still resides in pci domain 0 */
+if (mcfg_size == 0)
+return;
+
+if (pxb_pcie_mcfg_base + mcfg_size >
+ PXB_PCIE_HOST_BRIDGE_MCFG_SIZE_ADDR_UPPER) {
+dprintf(1, "PCI: Not enough space to hold new pci domains\n");
+return;
+}
+
+mcfg_base = pxb_pcie_mcfg_base;
+pxb_pcie_mcfg_base += mcfg_size;
+
+/* First clear old mmio, taken care of by QEMU */
+pci_config_writel(dev->bdf, PXB_PCIE_HOST_BRIDGE_MCFG_BAR, 0);
+/* Update MCFG base */
+pci_config_writel(dev->bdf, PXB_PCIE_HOST_BRIDGE_MCFG_BAR + 4,
+  mcfg_base >> 32);
+pci_config_writel(dev->bdf, PXB_PCIE_HOST_BRIDGE_MCFG_BAR,
+  (mcfg_base & 0x) | PXB_PCIE_HOST_BRIDGE_ENABLE);
+
+e820_add(mcfg_base, mcfg_size, E820_RESERVED);
+}
+
 static const struct pci_device_id pci_platform_tbl[] = {
 PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82441,
i440fx_mem_addr_setup),
 PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_Q35_MCH,
mch_mem_addr_setup),
+PCI_DEVICE(PCI_VENDOR_ID_REDHAT, PCI_DEVICE_ID_REDHAT_PXB_HOST,
+   pxb_pcie_mem_addr_setup),
 PCI_DEVICE_END
 };
 
diff --git a/src/hw/pci_ids.h b/src/hw/pci_ids.h
index 1096461..b495920 100644
--- a/src/hw/pci_ids.h
+++ b/src/hw/pci_ids.h
@@ -2266,6 +2266,7 @@
 #define PCI_VENDOR_ID_REDHAT   0x1b36
 #define PCI_DEVICE_ID_REDHAT_ROOT_PORT 0x000C
 #define PCI_DEVICE_ID_REDHAT_BRIDGE0x0001
+#define PCI_DEVICE_ID_REDHAT_PXB_HOST   0x000B
 
 #define PCI_VENDOR_ID_TEKRAM   0x1de1
 #define PCI_DEVICE_ID_TEKRAM_DC290 0xdc29
-- 
2.7.4


___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

Re: [SeaBIOS] [RFC v2 0/3] Support multiple pci domains in pci_device

[Zihan Yang]

Gerd Hoffmann  于2018年8月28日周二 上午10:15写道：
>
>   Hi,
>
> > > Where is the pxb-pcie device?  :$somewhere?  Or $domain:00:00.0?
> >
> >  :$somewhere (On PCI domain 0)
>
> Cool, so we don't have an chicken-and-egg issue.
>
> > > If we can access pxb-pcie registers before configuring MMCFG then yes,
> > > we should use pxb-pcie registers for that.
> >
> > Yes, we can.
>
> Ok, so we can configure mmcfg as hidden pci bar, simliar to the q35
> mmcfg.  Any configuration hints can be passed as pci vendor capability
> (simliar to the bridge window size hints), if needed.

That sounds workable, I will modify the implementation.

> cheers,
>   Gerd
>

Thanks.
Zihan

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

[SeaBIOS] Fwd: [RFC v2 0/3] Support multiple pci domains in pci_device

[Zihan Yang]

CCed to the wrong mailing list... resend here

-- Forwarded message -
From: Zihan Yang 
Date: 2018年8月28日周二 上午4:12
Subject: Re: [SeaBIOS] [RFC v2 0/3] Support multiple pci domains in pci_device
To: Gerd Hoffmann 
Cc: , Marcel Apfelbaum 


Gerd Hoffmann  于2018年8月27日周一 上午7:04写道：
>
>   Hi,
>
> > >   However, QEMU only binds port 0xcf8 and 0xcfc to
> > > bus pcie.0. To avoid bus confliction, we should use other port pairs for
> > > busses under new domains.
> >
> > I would skip support for IO based configuration and use only MMCONFIG
> > for extra root buses.
> >
> > The question remains: how do we assign MMCONFIG space for
> > each PCI domain.
>
> Allocation-wise it would be easiest to place them above 4G.  Right after
> memory, or after etc/reserved-memory-end (if that fw_cfg file is
> present), where the 64bit pci bars would have been placed.  Move the pci
> bars up in address space to make room.
>
> Only problem is that seabios wouldn't be able to access mmconfig then.
>
> Placing them below 4G would work at least for a few pci domains.  q35
> mmconfig bar is placed at 0xb000 -> 0xbfff, basically for
> historical reasons.  Old qemu versions had 2.75G low memory on q35 (up
> to 0xafff), and I think old machine types still have that for live
> migration compatibility reasons.  Modern qemu uses 2G only, to make
> gigabyte alignment work.
>
> 32bit pci bars are placed above 0xc000.  The address space from 2G
> to 2.75G (0x800 -> 0xafff) is unused on new machine types.
> Enough room for three additional mmconfig bars (full size), so four
> pci domains total if you add the q35 one.

Maybe we can support 4 domains first before we come up
with a better solution. But I'm not sure if four domains are
enough for those who want too many devices?

> cheers,
>   Gerd
>

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

Re: [SeaBIOS] [RFC v2 1/3] fw/pciinit: Recognize pxb-pcie-dev device

[Zihan Yang]

Marcel Apfelbaum  于2018年8月25日周六 下午4:11写道：
>
>
>
> On 08/09/2018 08:43 AM, Zihan Yang wrote:
> > QEMU q35 uses pxb-pcie-dev to enable multiple host bridges, this patch
> > recognizes such devices in seabios and add corresponding e820 entry.
> >
> > MCFG base and size are already setup in QEMU, we just need to read it
> >
> > Signed-off-by: Zihan Yang 
> > ---
> >   src/fw/paravirt.c |  1 -
> >   src/fw/pciinit.c  | 17 +
> >   src/hw/pci_ids.h  |  1 +
> >   3 files changed, 18 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c
> > index 0770c47..6b14542 100644
> > --- a/src/fw/paravirt.c
> > +++ b/src/fw/paravirt.c
> > @@ -197,7 +197,6 @@ qemu_platform_setup(void)
> >   if (!loader_err)
> >   warn_internalerror();
> >   }
> > -
>
> No need for this chunk.
>
> >   acpi_setup();
> >   }
> >
> > diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
> > index 3a2f747..6e6a434 100644
> > --- a/src/fw/pciinit.c
> > +++ b/src/fw/pciinit.c
> > @@ -507,11 +507,28 @@ static void mch_mem_addr_setup(struct pci_device 
> > *dev, void *arg)
> >   pci_io_low_end = acpi_pm_base;
> >   }
> >
> > +static void pxb_mem_addr_setup(struct pci_device *dev, void *arg)
> > +{
> > +union u64_u32_u mcfg_base;
> > +mcfg_base.lo = pci_config_readl(dev->bdf, Q35_HOST_BRIDGE_PCIEXBAR);
> > +mcfg_base.hi = pci_config_readl(dev->bdf, Q35_HOST_BRIDGE_PCIEXBAR + 
> > 4);
> > +
> > +// Fix me! Use another meaningful macro
> > +u32 mcfg_size = pci_config_readl(dev->bdf, Q35_HOST_BRIDGE_PCIEXBAR + 
> > 8);
>
> That is indeed strange. If I got it right, this is the address of Q35
> host bridge,
> we want other addresses here.

I will try to find another address in next version.

> > +
> > +/* Skip config write here as the qemu-level objects are already setup, 
> > we
> > + * read mcfg_base and mcfg_size from it just now. Instead, we directly 
> > add
> > + * this item to e820 */
> > +e820_add(mcfg_base.val, mcfg_size, E820_RESERVED);
>
> So did QEMU configure the address or only the size?

QEMU configure both the address and the size. Since the base address
is right behind
the ram_over_4g and the size depends on the number of buses we want to use, they
are not fixed anymore. So I just let qemu configures them both and
seabios only reads
them out. Maybe after we resolve the design issue, we can 'truly' let
seabios to fully
decide the base address and size.

> > +}
> > +
> >   static const struct pci_device_id pci_platform_tbl[] = {
> >   PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82441,
> >  i440fx_mem_addr_setup),
> >   PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_Q35_MCH,
> >  mch_mem_addr_setup),
> > +PCI_DEVICE(PCI_VENDOR_ID_REDHAT, PCI_DEVICE_ID_REDHAT_PXB_HOST,
> > +   ),
>
> Will this recognize only the pxb-pcie bridge, or also the legacy pxb one?
> Because we plan to support only the pxb-pcie version.

The value is 0x000b, which is pxb-pcie in qemu. The corresponding macro is
PCI_DEVICE_ID_REDHAT_PXB_PCIE. The value for PXB is 0x0009, and is
defined with another macro PCI_DEVICE_ID_REDHAT_PXB.

> Thanks,
> Marcel
>
> >   PCI_DEVICE_END
> >   };
> >
> > diff --git a/src/hw/pci_ids.h b/src/hw/pci_ids.h
> > index 38fa2ca..35096ea 100644
> > --- a/src/hw/pci_ids.h
> > +++ b/src/hw/pci_ids.h
> > @@ -2265,6 +2265,7 @@
> >
> >   #define PCI_VENDOR_ID_REDHAT0x1b36
> >   #define PCI_DEVICE_ID_REDHAT_ROOT_PORT  0x000C
> > +#define PCI_DEVICE_ID_REDHAT_PXB_HOST0x000B
> >
> >   #define PCI_VENDOR_ID_TEKRAM0x1de1
> >   #define PCI_DEVICE_ID_TEKRAM_DC290  0xdc29
>

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

Re: [SeaBIOS] [RFC v2 2/3] pci_device: Add pci domain support

[Zihan Yang]

Marcel Apfelbaum  于2018年8月25日周六 下午7:53写道：
>
>
>
> On 08/09/2018 08:43 AM, Zihan Yang wrote:
> > Most part of seabios assume only PCI domain 0. This patch adds support
> > for multiple domain in pci devices, which involves some API changes.
> >
> > For compatibility, interfaces such as pci_config_read[b|w|l] still exist
> > so that existing domain 0 devices needs no modification, but whenever a
> > device wants to reside in different domain, it should add *_dom suffix to
> > above functions, e.g, pci_config_readl_dom(..., domain_nr) to read from
> > specific host bridge other than q35 host bridge.
>
> It is not related only to q35. Is about PCI hosts bridges others
> that the main one.

I see, I will correct it.

> > Also, the user should
> > check the device domain when using foreachpci() macro to fileter undesired
> > devices that reside in a different domain.
> >
> > Signed-off-by: Zihan Yang 
> > ---
> >   src/fw/coreboot.c  |   2 +-
> >   src/fw/csm.c   |   2 +-
> >   src/fw/paravirt.c  |   2 +-
> >   src/fw/pciinit.c   | 261 
> > ++---
> >   src/hw/pci.c   |  69 +++---
> >   src/hw/pci.h   |  42 ++---
> >   src/hw/pci_ids.h   |   7 +-
> >   src/hw/pcidevice.c |   8 +-
> >   src/hw/pcidevice.h |   4 +-
> >   9 files changed, 227 insertions(+), 170 deletions(-)
> >
> > diff --git a/src/fw/coreboot.c b/src/fw/coreboot.c
> > index 7c0954b..c955dfd 100644
> > --- a/src/fw/coreboot.c
> > +++ b/src/fw/coreboot.c
> > @@ -254,7 +254,7 @@ coreboot_platform_setup(void)
> >   {
> >   if (!CONFIG_COREBOOT)
> >   return;
> > -pci_probe_devices();
> > +pci_probe_devices(0);
> >
> >   struct cb_memory *cbm = CBMemTable;
> >   if (!cbm)
> > diff --git a/src/fw/csm.c b/src/fw/csm.c
> > index 03b4bb8..e94f614 100644
> > --- a/src/fw/csm.c
> > +++ b/src/fw/csm.c
> > @@ -63,7 +63,7 @@ static void
> >   csm_maininit(struct bregs *regs)
> >   {
> >   interface_init();
> > -pci_probe_devices();
> > +pci_probe_devices(0);
> >
> >   csm_compat_table.PnPInstallationCheckSegment = SEG_BIOS;
> >   csm_compat_table.PnPInstallationCheckOffset = get_pnp_offset();
> > diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c
> > index 6b14542..ef4d487 100644
> > --- a/src/fw/paravirt.c
> > +++ b/src/fw/paravirt.c
> > @@ -155,7 +155,7 @@ qemu_platform_setup(void)
> >   return;
> >
> >   if (runningOnXen()) {
> > -pci_probe_devices();
> > +pci_probe_devices(0);
> >   xen_hypercall_setup();
> >   xen_biostable_setup();
> >   return;
> > diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
> > index 6e6a434..fcdcd38 100644
> > --- a/src/fw/pciinit.c
> > +++ b/src/fw/pciinit.c
> > @@ -51,6 +51,7 @@ u64 pcimem_end = BUILD_PCIMEM_END;
> >   u64 pcimem64_start = BUILD_PCIMEM64_START;
> >   u64 pcimem64_end   = BUILD_PCIMEM64_END;
> >   u64 pci_io_low_end = 0xa000;
> > +u64 pxb_mcfg_size  = 0;
> >
> >   struct pci_region_entry {
> >   struct pci_device *dev;
> > @@ -88,9 +89,9 @@ static void
> >   pci_set_io_region_addr(struct pci_device *pci, int bar, u64 addr, int 
> > is64)
> >   {
> >   u32 ofs = pci_bar(pci, bar);
> > -pci_config_writel(pci->bdf, ofs, addr);
> > +pci_config_writel_dom(pci->bdf, ofs, addr, pci->domain_nr);
> >   if (is64)
> > -pci_config_writel(pci->bdf, ofs + 4, addr >> 32);
> > +pci_config_writel_dom(pci->bdf, ofs + 4, addr >> 32, 
> > pci->domain_nr);
> >   }
> >
> >
> > @@ -405,25 +406,29 @@ static void pci_bios_init_device(struct pci_device 
> > *pci)
> >
> >   /* map the interrupt */
> >   u16 bdf = pci->bdf;
> > -int pin = pci_config_readb(bdf, PCI_INTERRUPT_PIN);
> > +int pin = pci_config_readb_dom(bdf, PCI_INTERRUPT_PIN, pci->domain_nr);
> >   if (pin != 0)
> > -pci_config_writeb(bdf, PCI_INTERRUPT_LINE, pci_slot_get_irq(pci, 
> > pin));
> > +pci_config_writeb_dom(bdf, PCI_INTERRUPT_LINE, 
> > pci_slot_get_irq(pci, pin),
> > +  pci->domain_nr);
> >
> >   pci_init_device(pci_device_tbl, pci, NULL);
> >
> >   /* enable memory mappings */
> > -pci_config_maskw(bdf, PCI_COMMAND, 0,
> > - PCI_COMMAND_IO 

Re: [SeaBIOS] [RFC v2 0/3] Support multiple pci domains in pci_device

[Zihan Yang]

Marcel Apfelbaum  于2018年8月25日周六 下午4:07写道：
>
> Hi,
>
> On 08/09/2018 08:43 AM, Zihan Yang wrote:
> > Currently seabios assumes there is only one pci domain(0), and almost
> > everything operates on pci domain 0 by default. This patch aims to add
> > multiple pci domain support for pci_device, while reserve the original
> > API for compatibility.
>
> This is a necessary addition to support your QEMU patches,
> Please send a link to the QEMU series on your next re-spin.

OK, I will attach the link in later QEMU patches.

> > The reason to get seabios involved is that the pxb-pcie host bus created
> > in QEMU is now in a different PCI domain, and its bus number would start
> > from 0 instead of bus_nr. Actually bus_nr should not be used when in
> > another non-zero domain.
>
> That is not necessarily true. As we discussed in QEMU devel
> mailing list, it is possible PCI buses of a different domain
> to start from a positive bus number.
> Both bus_nr and domain_nr support makes sense.

OK, I think I will still use bus_nr as the start bus when in separate domain.

> >   However, QEMU only binds port 0xcf8 and 0xcfc to
> > bus pcie.0. To avoid bus confliction, we should use other port pairs for
> > busses under new domains.
>
> I would skip support for IO based configuration and use only MMCONFIG
> for extra root buses.
>
> The question remains: how do we assign MMCONFIG space for
> each PCI domain.

Indeed, seabios does not have fixed MMCONFIG space(except for q35 host) yet.

> Thanks,
> Marcel
>
> > Current issues:
> > * when trying to read config space of pcie_pci_bridge, it actually reads
> >out the result of mch. I'm working on this weird behavior.
> >
> > Changelog:
> > v2 <- v1:
> > - Fix bugs in filtering domains when traversing pci devices
> > - Reformat some hardcoded codes, such as probing the pci device in pci_setup
> >
> > Zihan Yang (3):
> >fw/pciinit: Recognize pxb-pcie-dev device
> >pci_device: Add pci domain support
> >pci: filter undesired domain when traversing pci
> >
> >   src/fw/coreboot.c|   2 +-
> >   src/fw/csm.c |   2 +-
> >   src/fw/mptable.c |   1 +
> >   src/fw/paravirt.c|   3 +-
> >   src/fw/pciinit.c | 276 
> > ++-
> >   src/hw/ahci.c|   1 +
> >   src/hw/ata.c |   1 +
> >   src/hw/esp-scsi.c|   1 +
> >   src/hw/lsi-scsi.c|   1 +
> >   src/hw/megasas.c |   1 +
> >   src/hw/mpt-scsi.c|   1 +
> >   src/hw/nvme.c|   1 +
> >   src/hw/pci.c |  69 +++--
> >   src/hw/pci.h |  42 +---
> >   src/hw/pci_ids.h |   6 +-
> >   src/hw/pcidevice.c   |  11 +-
> >   src/hw/pcidevice.h   |   8 +-
> >   src/hw/pvscsi.c  |   1 +
> >   src/hw/sdcard.c  |   1 +
> >   src/hw/usb-ehci.c|   1 +
> >   src/hw/usb-ohci.c|   1 +
> >   src/hw/usb-uhci.c|   1 +
> >   src/hw/usb-xhci.c|   1 +
> >   src/hw/virtio-blk.c  |   1 +
> >   src/hw/virtio-scsi.c |   1 +
> >   src/optionroms.c |   3 +
> >   26 files changed, 268 insertions(+), 170 deletions(-)
> >
>

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

[SeaBIOS] Fwd: Fwd: [RFC 0/2] (Ongoing)Support multiple pci domains in pci_device

[Zihan Yang]

-- Forwarded message -
From: Zihan Yang 
Date: 2018年8月21日周二 上午10:34
Subject: Re: [SeaBIOS] Fwd: [RFC 0/2] (Ongoing)Support multiple pci
domains in pci_device
To: Kevin OConnor 


Kevin O'Connor  于2018年8月21日周二 上午4:24写道：
>
> On Thu, Aug 09, 2018 at 07:44:22AM +0800, Zihan Yang wrote:
> > Kevin O'Connor  于2018年8月8日周三 下午10:14写道：
> > > On Thu, Aug 02, 2018 at 10:39:13AM +0800, Zihan Yang wrote:
> > > > NOTE: This patch set is still ongoing and does not fully function
> > > > as its goal. But it involves some API changes, therefore I post them for
> > > > comments before moving on to make sure I'm on the right path.
> > > >
> > > > The corresponding qemu part can be found at
> > > > https://gitlab.com/WhoisZihan/qemu-pci-domain/tree/master/qemu
> > > > I will submit it to qemu list later.
> > > >
> > > > Currently seabios assumes there is only one pci domain(0), and almost
> > > > everything operates on pci domain 0 by default. This patch aims to add
> > > > multiple pci domain support for pci_device, while reserve the original
> > > > API for compatibility.
> > >
> > > Thanks.  I understand the desire to support multiple PCI domains in
> > > QEMU and the guest OS.  However, what is the high level reason for
> > > wanting the BIOS to be able to interact with the secondary PCI
> > > domains?
> >
> > The pxb-pcie host bus is put into a separated domain, so are the devices
> > under the pxb host bus. I think we should also initialize busses in other
> > domains and probe those devices during bios initialization. But currently
> > qemu only binds port 0xcf8 and 0xcfc to q35 host's conf_mem and data_mem,
> > if we want to read the config space of pxb host, we should use another port.
> > I use port range 0x1000 and 0x1004 for a temporary workaround because they
> > seem to be 'free' now.
>
> The patchset is quite large and touches a large amount of code in
> different parts of SeaBIOS.  I'd like to understand the high-level,
> user-visible, reason for making the change.  What important
> capabilities will a user be unable to accomplish if we don't make this
> change?

The restriction is that pcie topology limits one pcie device per bus,
and there are
at most 256 buses in a pci domain/segment. Currently the pxb host are
still inside
the same domain with q35, and the buses will run out if there are many
pcie devices.

This patch set aims to let users be able to put these 'extra' devices
into separate
pci domains to overcome the limitation of bus numbers in a single domain.

> As far as I know, there is no standard for accessing PCI besides the
> main one at cf8/cfc - so I'm not sure there is a good solution to this
> problem.  Perhaps it would be easier for users to always put their
> boot devices on the main PCI.

Yes, seabios reads pci config space only through 0xcf8/0xcfc, it seems
currently seabios
does not seperate pcie devices from pci devices.

This patch is just an temporary workaround, maybe we can replace it
with mmio later but
I think that would involve many changes to seabios too.

> Thanks,
> -Kevin

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCH v2 3/3] pci: recognize RH PCI legacy bridge resource reservation capability

[Zihan Yang]

Liu, Jing2  于2018年8月16日周四 上午10:39写道：
>
> Hi Zihan,
>
> I copy your comments of this patch several days ago here,
> and hope we could continue some discussion in this serial.

Hi Jing,

Sorry for the delay. I tested at the code just now and find that pcie
bridge does not
use a vendor specific capability. I met this warning in another
ongoing patch so I just
added pcie bridge to suppress the warning.

Now that it turns out pcie bridge does not use this vendor specific
capability, I think you
might want to stick with your original patch, and add it in the future
when redhat decides
to add specific capabilities in pcie bridge. I'm not quite an expert
in this field, so unfortunately
I don't have much insights to give, but I'm open for a discussion.

> On 8/16/2018 10:32 AM, Jing Liu wrote:
> [...]
> >
> >   static u8 pci_find_resource_reserve_capability(u16 bdf)
> >   {
> > -if (pci_config_readw(bdf, PCI_VENDOR_ID) == PCI_VENDOR_ID_REDHAT &&
> > -pci_config_readw(bdf, PCI_DEVICE_ID) ==
> > -PCI_DEVICE_ID_REDHAT_ROOT_PORT) {
> > -u8 cap = 0;
> > -do {
> > -cap = pci_find_capability(bdf, PCI_CAP_ID_VNDR, cap);
> > -} while (cap &&
> > - pci_config_readb(bdf, cap + PCI_CAP_REDHAT_TYPE_OFFSET) !=
> > -REDHAT_CAP_RESOURCE_RESERVE);
> > -if (cap) {
> > -u8 cap_len = pci_config_readb(bdf, cap + PCI_CAP_FLAGS);
> > -if (cap_len < RES_RESERVE_CAP_SIZE) {
> > -dprintf(1, "PCI: QEMU resource reserve cap length %d is 
> > invalid\n",
> > -cap_len);
> > -return 0;
> > -}
> > -} else {
> > -dprintf(1, "PCI: QEMU resource reserve cap not found\n");
> > +u16 device_id;
> > +
> > +if (pci_config_readw(bdf, PCI_VENDOR_ID) != PCI_VENDOR_ID_REDHAT) {
> > +dprintf(1, "PCI: QEMU resource reserve cap vendor ID doesn't 
> > match.\n");
> > +return 0;
> > +}
> > +
> > +device_id = pci_config_readw(bdf, PCI_DEVICE_ID);
> > +
> > +if (device_id != PCI_DEVICE_ID_REDHAT_ROOT_PORT &&
> > +device_id != PCI_DEVICE_ID_REDHAT_BRIDGE) {
>
> === comments by Zihan Yang =
> I think PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE shoud be added too, in case we put
> a pcie_pci_bridge at the host bus.
> 
> My reply:
> In theory all the pci bridge could add this capability but I'm not sure
> if we really need that? Would like to hear some more suggestion!
>
>
> Thanks,
> Jing
>
> [...]

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCH v2 3/3] pci: recognize RH PCI legacy bridge resource

[Zihan Yang]

> Enable the firmware recognizing RedHat legacy PCI bridge device ID,
> so QEMU can reserve additional PCI bridge resource capability.
> 
> Signed-off-by: Jing Liu 
> ---
>  src/fw/pciinit.c | 50 +-
>  src/hw/pci_ids.h |  1 +
>  2 files changed, 30 insertions(+), 21 deletions(-)
> 
> diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
> index 62a32f1..795d84a 100644
> --- a/src/fw/pciinit.c
> +++ b/src/fw/pciinit.c
> @@ -525,30 +525,38 @@ static void pci_bios_init_platform(void)
> 
>  static u8 pci_find_resource_reserve_capability(u16 bdf)
>  {
> -if (pci_config_readw(bdf, PCI_VENDOR_ID) == PCI_VENDOR_ID_REDHAT &&
> -pci_config_readw(bdf, PCI_DEVICE_ID) ==
> -PCI_DEVICE_ID_REDHAT_ROOT_PORT) {
> -u8 cap = 0;
> -do {
> -cap = pci_find_capability(bdf, PCI_CAP_ID_VNDR, cap);
> -} while (cap &&
> - pci_config_readb(bdf, cap + PCI_CAP_REDHAT_TYPE_OFFSET) !=
> -REDHAT_CAP_RESOURCE_RESERVE);
> -if (cap) {
> -u8 cap_len = pci_config_readb(bdf, cap + PCI_CAP_FLAGS);
> -if (cap_len < RES_RESERVE_CAP_SIZE) {
> -dprintf(1, "PCI: QEMU resource reserve cap length %d is 
> invalid\n",
> -cap_len);
> -return 0;
> -}
> -} else {
> -dprintf(1, "PCI: QEMU resource reserve cap not found\n");
> +u16 device_id;
> +
> +if (pci_config_readw(bdf, PCI_VENDOR_ID) != PCI_VENDOR_ID_REDHAT) {
> +dprintf(1, "PCI: QEMU resource reserve cap vendor ID doesn't 
> match.\n");
> +return 0;
> +}
> +
> +device_id = pci_config_readw(bdf, PCI_DEVICE_ID);
> +
> +if (device_id != PCI_DEVICE_ID_REDHAT_ROOT_PORT &&
> +device_id != PCI_DEVICE_ID_REDHAT_BRIDGE) {

I think PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE shoud be added too, in case we put
a pcie_pci_bridge at the host bus.

> +dprintf(1, "PCI: QEMU resource reserve cap device ID doesn't 
> match.\n");
> +return 0;
> +}
> +u8 cap = 0;
> +
> +do {
> +cap = pci_find_capability(bdf, PCI_CAP_ID_VNDR, cap);
> +} while (cap &&
> + pci_config_readb(bdf, cap + PCI_CAP_REDHAT_TYPE_OFFSET) !=
> +  REDHAT_CAP_RESOURCE_RESERVE);
> +if (cap) {
> +u8 cap_len = pci_config_readb(bdf, cap + PCI_CAP_FLAGS);
> +if (cap_len < RES_RESERVE_CAP_SIZE) {
> +dprintf(1, "PCI: QEMU resource reserve cap length %d is 
> invalid\n",
> +cap_len);
> +return 0;
>  }
> -return cap;
>  } else {
> -dprintf(1, "PCI: QEMU resource reserve cap VID or DID doesn't 
> match.\n");
> -return 0;
> +dprintf(1, "PCI: QEMU resource reserve cap not found\n");
>  }
> +return cap;
>  }
> 
>  /
> diff --git a/src/hw/pci_ids.h b/src/hw/pci_ids.h
> index 38fa2ca..1096461 100644
> --- a/src/hw/pci_ids.h
> +++ b/src/hw/pci_ids.h
> @@ -2265,6 +2265,7 @@
> 
>  #define PCI_VENDOR_ID_REDHAT   0x1b36
>  #define PCI_DEVICE_ID_REDHAT_ROOT_PORT 0x000C
> +#define PCI_DEVICE_ID_REDHAT_BRIDGE0x0001
> 
>  #define PCI_VENDOR_ID_TEKRAM   0x1de1
>  #define PCI_DEVICE_ID_TEKRAM_DC290 0xdc29
> -- 
> 1.8.3.1
> 

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

[SeaBIOS] [RFC v2 2/3] pci_device: Add pci domain support

[Zihan Yang]

Most part of seabios assume only PCI domain 0. This patch adds support
for multiple domain in pci devices, which involves some API changes.

For compatibility, interfaces such as pci_config_read[b|w|l] still exist
so that existing domain 0 devices needs no modification, but whenever a
device wants to reside in different domain, it should add *_dom suffix to
above functions, e.g, pci_config_readl_dom(..., domain_nr) to read from
specific host bridge other than q35 host bridge. Also, the user should
check the device domain when using foreachpci() macro to fileter undesired
devices that reside in a different domain.

Signed-off-by: Zihan Yang 
---
 src/fw/coreboot.c  |   2 +-
 src/fw/csm.c   |   2 +-
 src/fw/paravirt.c  |   2 +-
 src/fw/pciinit.c   | 261 ++---
 src/hw/pci.c   |  69 +++---
 src/hw/pci.h   |  42 ++---
 src/hw/pci_ids.h   |   7 +-
 src/hw/pcidevice.c |   8 +-
 src/hw/pcidevice.h |   4 +-
 9 files changed, 227 insertions(+), 170 deletions(-)

diff --git a/src/fw/coreboot.c b/src/fw/coreboot.c
index 7c0954b..c955dfd 100644
--- a/src/fw/coreboot.c
+++ b/src/fw/coreboot.c
@@ -254,7 +254,7 @@ coreboot_platform_setup(void)
 {
 if (!CONFIG_COREBOOT)
 return;
-pci_probe_devices();
+pci_probe_devices(0);
 
 struct cb_memory *cbm = CBMemTable;
 if (!cbm)
diff --git a/src/fw/csm.c b/src/fw/csm.c
index 03b4bb8..e94f614 100644
--- a/src/fw/csm.c
+++ b/src/fw/csm.c
@@ -63,7 +63,7 @@ static void
 csm_maininit(struct bregs *regs)
 {
 interface_init();
-pci_probe_devices();
+pci_probe_devices(0);
 
 csm_compat_table.PnPInstallationCheckSegment = SEG_BIOS;
 csm_compat_table.PnPInstallationCheckOffset = get_pnp_offset();
diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c
index 6b14542..ef4d487 100644
--- a/src/fw/paravirt.c
+++ b/src/fw/paravirt.c
@@ -155,7 +155,7 @@ qemu_platform_setup(void)
 return;
 
 if (runningOnXen()) {
-pci_probe_devices();
+pci_probe_devices(0);
 xen_hypercall_setup();
 xen_biostable_setup();
 return;
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
index 6e6a434..fcdcd38 100644
--- a/src/fw/pciinit.c
+++ b/src/fw/pciinit.c
@@ -51,6 +51,7 @@ u64 pcimem_end = BUILD_PCIMEM_END;
 u64 pcimem64_start = BUILD_PCIMEM64_START;
 u64 pcimem64_end   = BUILD_PCIMEM64_END;
 u64 pci_io_low_end = 0xa000;
+u64 pxb_mcfg_size  = 0;
 
 struct pci_region_entry {
 struct pci_device *dev;
@@ -88,9 +89,9 @@ static void
 pci_set_io_region_addr(struct pci_device *pci, int bar, u64 addr, int is64)
 {
 u32 ofs = pci_bar(pci, bar);
-pci_config_writel(pci->bdf, ofs, addr);
+pci_config_writel_dom(pci->bdf, ofs, addr, pci->domain_nr);
 if (is64)
-pci_config_writel(pci->bdf, ofs + 4, addr >> 32);
+pci_config_writel_dom(pci->bdf, ofs + 4, addr >> 32, pci->domain_nr);
 }
 
 
@@ -405,25 +406,29 @@ static void pci_bios_init_device(struct pci_device *pci)
 
 /* map the interrupt */
 u16 bdf = pci->bdf;
-int pin = pci_config_readb(bdf, PCI_INTERRUPT_PIN);
+int pin = pci_config_readb_dom(bdf, PCI_INTERRUPT_PIN, pci->domain_nr);
 if (pin != 0)
-pci_config_writeb(bdf, PCI_INTERRUPT_LINE, pci_slot_get_irq(pci, pin));
+pci_config_writeb_dom(bdf, PCI_INTERRUPT_LINE, pci_slot_get_irq(pci, 
pin),
+  pci->domain_nr);
 
 pci_init_device(pci_device_tbl, pci, NULL);
 
 /* enable memory mappings */
-pci_config_maskw(bdf, PCI_COMMAND, 0,
- PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_SERR);
+pci_config_maskw_dom(bdf, PCI_COMMAND, 0,
+ PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_SERR,
+ pci->domain_nr);
 /* enable SERR# for forwarding */
 if (pci->header_type & PCI_HEADER_TYPE_BRIDGE)
-pci_config_maskw(bdf, PCI_BRIDGE_CONTROL, 0,
- PCI_BRIDGE_CTL_SERR);
+pci_config_maskw_dom(bdf, PCI_BRIDGE_CONTROL, 0,
+ PCI_BRIDGE_CTL_SERR, pci->domain_nr);
 }
 
-static void pci_bios_init_devices(void)
+static void pci_bios_init_devices(int domain_nr)
 {
 struct pci_device *pci;
 foreachpci(pci) {
+if (pci->domain_nr != domain_nr)
+continue;
 pci_bios_init_device(pci);
 }
 }
@@ -520,6 +525,10 @@ static void pxb_mem_addr_setup(struct pci_device *dev, 
void *arg)
  * read mcfg_base and mcfg_size from it just now. Instead, we directly add
  * this item to e820 */
 e820_add(mcfg_base.val, mcfg_size, E820_RESERVED);
+
+/* Add PXBHosts so that we can can initialize them later */
+++PXBHosts;
+pxb_mcfg_size += mcfg_size;
 }
 
 static const struct pci_device_id pci_platform_tbl[] = {
@@ -532,27 +541,31 @@ static const struct pci_device_id pci_platform_tbl[] = {
 PCI_DEVICE_END
 };
 
-static void pci_bios_init

[SeaBIOS] [RFC v2 1/3] fw/pciinit: Recognize pxb-pcie-dev device

[Zihan Yang]

QEMU q35 uses pxb-pcie-dev to enable multiple host bridges, this patch
recognizes such devices in seabios and add corresponding e820 entry.

MCFG base and size are already setup in QEMU, we just need to read it

Signed-off-by: Zihan Yang 
---
 src/fw/paravirt.c |  1 -
 src/fw/pciinit.c  | 17 +
 src/hw/pci_ids.h  |  1 +
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c
index 0770c47..6b14542 100644
--- a/src/fw/paravirt.c
+++ b/src/fw/paravirt.c
@@ -197,7 +197,6 @@ qemu_platform_setup(void)
 if (!loader_err)
 warn_internalerror();
 }
-
 acpi_setup();
 }
 
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
index 3a2f747..6e6a434 100644
--- a/src/fw/pciinit.c
+++ b/src/fw/pciinit.c
@@ -507,11 +507,28 @@ static void mch_mem_addr_setup(struct pci_device *dev, 
void *arg)
 pci_io_low_end = acpi_pm_base;
 }
 
+static void pxb_mem_addr_setup(struct pci_device *dev, void *arg)
+{
+union u64_u32_u mcfg_base;
+mcfg_base.lo = pci_config_readl(dev->bdf, Q35_HOST_BRIDGE_PCIEXBAR);
+mcfg_base.hi = pci_config_readl(dev->bdf, Q35_HOST_BRIDGE_PCIEXBAR + 4);
+
+// Fix me! Use another meaningful macro
+u32 mcfg_size = pci_config_readl(dev->bdf, Q35_HOST_BRIDGE_PCIEXBAR + 8);
+
+/* Skip config write here as the qemu-level objects are already setup, we
+ * read mcfg_base and mcfg_size from it just now. Instead, we directly add
+ * this item to e820 */
+e820_add(mcfg_base.val, mcfg_size, E820_RESERVED);
+}
+
 static const struct pci_device_id pci_platform_tbl[] = {
 PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82441,
i440fx_mem_addr_setup),
 PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_Q35_MCH,
mch_mem_addr_setup),
+PCI_DEVICE(PCI_VENDOR_ID_REDHAT, PCI_DEVICE_ID_REDHAT_PXB_HOST,
+   pxb_mem_addr_setup),
 PCI_DEVICE_END
 };
 
diff --git a/src/hw/pci_ids.h b/src/hw/pci_ids.h
index 38fa2ca..35096ea 100644
--- a/src/hw/pci_ids.h
+++ b/src/hw/pci_ids.h
@@ -2265,6 +2265,7 @@
 
 #define PCI_VENDOR_ID_REDHAT   0x1b36
 #define PCI_DEVICE_ID_REDHAT_ROOT_PORT 0x000C
+#define PCI_DEVICE_ID_REDHAT_PXB_HOST  0x000B
 
 #define PCI_VENDOR_ID_TEKRAM   0x1de1
 #define PCI_DEVICE_ID_TEKRAM_DC290 0xdc29
-- 
2.7.4


___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

[SeaBIOS] [RFC v2 0/3] Support multiple pci domains in pci_device

[Zihan Yang]

Currently seabios assumes there is only one pci domain(0), and almost
everything operates on pci domain 0 by default. This patch aims to add
multiple pci domain support for pci_device, while reserve the original
API for compatibility.

The reason to get seabios involved is that the pxb-pcie host bus created
in QEMU is now in a different PCI domain, and its bus number would start
from 0 instead of bus_nr. Actually bus_nr should not be used when in
another non-zero domain. However, QEMU only binds port 0xcf8 and 0xcfc to
bus pcie.0. To avoid bus confliction, we should use other port pairs for
busses under new domains.

Current issues:
* when trying to read config space of pcie_pci_bridge, it actually reads
  out the result of mch. I'm working on this weird behavior.

Changelog:
v2 <- v1:
- Fix bugs in filtering domains when traversing pci devices
- Reformat some hardcoded codes, such as probing the pci device in pci_setup

Zihan Yang (3):
  fw/pciinit: Recognize pxb-pcie-dev device
  pci_device: Add pci domain support
  pci: filter undesired domain when traversing pci

 src/fw/coreboot.c|   2 +-
 src/fw/csm.c |   2 +-
 src/fw/mptable.c |   1 +
 src/fw/paravirt.c|   3 +-
 src/fw/pciinit.c | 276 ++-
 src/hw/ahci.c|   1 +
 src/hw/ata.c |   1 +
 src/hw/esp-scsi.c|   1 +
 src/hw/lsi-scsi.c|   1 +
 src/hw/megasas.c |   1 +
 src/hw/mpt-scsi.c|   1 +
 src/hw/nvme.c|   1 +
 src/hw/pci.c |  69 +++--
 src/hw/pci.h |  42 +---
 src/hw/pci_ids.h |   6 +-
 src/hw/pcidevice.c   |  11 +-
 src/hw/pcidevice.h   |   8 +-
 src/hw/pvscsi.c  |   1 +
 src/hw/sdcard.c  |   1 +
 src/hw/usb-ehci.c|   1 +
 src/hw/usb-ohci.c|   1 +
 src/hw/usb-uhci.c|   1 +
 src/hw/usb-xhci.c|   1 +
 src/hw/virtio-blk.c  |   1 +
 src/hw/virtio-scsi.c |   1 +
 src/optionroms.c |   3 +
 26 files changed, 268 insertions(+), 170 deletions(-)

-- 
2.7.4


___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

[SeaBIOS] [RFC v2 3/3] pci: filter undesired domain when traversing pci

[Zihan Yang]

Since pci devices could reside in different domains now, we should judge
the domain of pci devices when traversing them. Original devices still
use domain 0 for compatibility

Signed-off-by: Zihan Yang 
---
 src/fw/mptable.c |  1 +
 src/fw/pciinit.c | 10 --
 src/hw/ahci.c|  1 +
 src/hw/ata.c |  1 +
 src/hw/esp-scsi.c|  1 +
 src/hw/lsi-scsi.c|  1 +
 src/hw/megasas.c |  1 +
 src/hw/mpt-scsi.c|  1 +
 src/hw/nvme.c|  1 +
 src/hw/pcidevice.c   |  3 +++
 src/hw/pcidevice.h   |  4 
 src/hw/pvscsi.c  |  1 +
 src/hw/sdcard.c  |  1 +
 src/hw/usb-ehci.c|  1 +
 src/hw/usb-ohci.c|  1 +
 src/hw/usb-uhci.c|  1 +
 src/hw/usb-xhci.c|  1 +
 src/hw/virtio-blk.c  |  1 +
 src/hw/virtio-scsi.c |  1 +
 src/optionroms.c |  3 +++
 20 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/src/fw/mptable.c b/src/fw/mptable.c
index 47385cc..3989cb6 100644
--- a/src/fw/mptable.c
+++ b/src/fw/mptable.c
@@ -110,6 +110,7 @@ mptable_setup(void)
 
 struct pci_device *pci;
 foreachpci(pci) {
+filter_domain(pci, 0);
 u16 bdf = pci->bdf;
 if (pci_bdf_to_bus(bdf) != 0)
 break;
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
index fcdcd38..834540f 100644
--- a/src/fw/pciinit.c
+++ b/src/fw/pciinit.c
@@ -427,8 +427,7 @@ static void pci_bios_init_devices(int domain_nr)
 {
 struct pci_device *pci;
 foreachpci(pci) {
-if (pci->domain_nr != domain_nr)
-continue;
+filter_domain(pci, domain_nr);
 pci_bios_init_device(pci);
 }
 }
@@ -438,6 +437,7 @@ static void pci_enable_default_vga(void)
 struct pci_device *pci;
 
 foreachpci(pci) {
+filter_domain(pci, 0);
 if (is_pci_vga(pci)) {
 dprintf(1, "PCI: Using %pP for primary VGA\n", pci);
 return;
@@ -545,8 +545,7 @@ static void pci_bios_init_platform(int domain_nr)
 {
 struct pci_device *pci;
 foreachpci(pci) {
-if (pci->domain_nr != domain_nr)
-continue;
+filter_domain(pci, domain_nr);
 pci_init_device(pci_platform_tbl, pci, NULL);
 }
 }
@@ -884,8 +883,7 @@ static int pci_bios_check_devices(struct pci_bus *busses, 
int domain_nr)
 // Calculate resources needed for regular (non-bus) devices.
 struct pci_device *pci;
 foreachpci(pci) {
-if (pci->domain_nr != domain_nr)
-continue;
+filter_domain(pci, domain_nr);
 if (pci->class == PCI_CLASS_BRIDGE_PCI)
 busses[pci->secondary_bus].bus_dev = pci;
 
diff --git a/src/hw/ahci.c b/src/hw/ahci.c
index 1746e7a..f825992 100644
--- a/src/hw/ahci.c
+++ b/src/hw/ahci.c
@@ -677,6 +677,7 @@ ahci_scan(void)
 // Scan PCI bus for ATA adapters
 struct pci_device *pci;
 foreachpci(pci) {
+filter_domain(pci, 0);
 if (pci->class != PCI_CLASS_STORAGE_SATA)
 continue;
 if (pci->prog_if != 1 /* AHCI rev 1 */)
diff --git a/src/hw/ata.c b/src/hw/ata.c
index b6e073c..2273326 100644
--- a/src/hw/ata.c
+++ b/src/hw/ata.c
@@ -1024,6 +1024,7 @@ ata_scan(void)
 // Scan PCI bus for ATA adapters
 struct pci_device *pci;
 foreachpci(pci) {
+filter_domain(pci, 0);
 pci_init_device(pci_ata_tbl, pci, NULL);
 }
 }
diff --git a/src/hw/esp-scsi.c b/src/hw/esp-scsi.c
index ffd86d0..17436d5 100644
--- a/src/hw/esp-scsi.c
+++ b/src/hw/esp-scsi.c
@@ -233,6 +233,7 @@ esp_scsi_setup(void)
 
 struct pci_device *pci;
 foreachpci(pci) {
+filter_domain(pci, 0);
 if (pci->vendor != PCI_VENDOR_ID_AMD
 || pci->device != PCI_DEVICE_ID_AMD_SCSI)
 continue;
diff --git a/src/hw/lsi-scsi.c b/src/hw/lsi-scsi.c
index d5fc3e4..5748d1f 100644
--- a/src/hw/lsi-scsi.c
+++ b/src/hw/lsi-scsi.c
@@ -213,6 +213,7 @@ lsi_scsi_setup(void)
 
 struct pci_device *pci;
 foreachpci(pci) {
+filter_domain(pci, 0);
 if (pci->vendor != PCI_VENDOR_ID_LSI_LOGIC
 || pci->device != PCI_DEVICE_ID_LSI_53C895A)
 continue;
diff --git a/src/hw/megasas.c b/src/hw/megasas.c
index d267580..1d84771 100644
--- a/src/hw/megasas.c
+++ b/src/hw/megasas.c
@@ -386,6 +386,7 @@ megasas_setup(void)
 
 struct pci_device *pci;
 foreachpci(pci) {
+filter_domain(pci, 0);
 if (pci->vendor != PCI_VENDOR_ID_LSI_LOGIC &&
 pci->vendor != PCI_VENDOR_ID_DELL)
 continue;
diff --git a/src/hw/mpt-scsi.c b/src/hw/mpt-scsi.c
index 1faede6..e89316b 100644
--- a/src/hw/mpt-scsi.c
+++ b/src/hw/mpt-scsi.c
@@ -310,6 +310,7 @@ mpt_scsi_setup(void)
 
 struct pci_device *pci;
 foreachpci(pci) {
+filter_domain(pci, 0);
 if (pci->vendor == PCI_VENDOR_ID_LSI_LOGIC
 && (pci->device == PCI_DEVICE_ID_LSI_53C1030
 || pci->device == PCI_DEVICE_ID_LSI_SAS1068
diff --git a/src/hw/nvme.c b/src/hw/nvme.c
in

[SeaBIOS] Fwd: [RFC 0/2] (Ongoing)Support multiple pci domains in pci_device

[Zihan Yang]

[forgot to cc to the mail list]

Kevin O'Connor  于2018年8月8日周三 下午10:14写道：
>
> On Thu, Aug 02, 2018 at 10:39:13AM +0800, Zihan Yang wrote:
> > NOTE: This patch set is still ongoing and does not fully function
> > as its goal. But it involves some API changes, therefore I post them for
> > comments before moving on to make sure I'm on the right path.
> >
> > The corresponding qemu part can be found at
> > https://gitlab.com/WhoisZihan/qemu-pci-domain/tree/master/qemu
> > I will submit it to qemu list later.
> >
> > Currently seabios assumes there is only one pci domain(0), and almost
> > everything operates on pci domain 0 by default. This patch aims to add
> > multiple pci domain support for pci_device, while reserve the original
> > API for compatibility.
>
> Thanks.  I understand the desire to support multiple PCI domains in
> QEMU and the guest OS.  However, what is the high level reason for
> wanting the BIOS to be able to interact with the secondary PCI
> domains?

The pxb-pcie host bus is put into a separated domain, so are the devices
under the pxb host bus. I think we should also initialize busses in other
domains and probe those devices during bios initialization. But currently
qemu only binds port 0xcf8 and 0xcfc to q35 host's conf_mem and data_mem,
if we want to read the config space of pxb host, we should use another port.
I use port range 0x1000 and 0x1004 for a temporary workaround because they
seem to be 'free' now.

Please correct me if I misunderstand it.

P.S. Maybe you would want to ignore this patch set as there are a few bugs
that I fix later, and I will soon send a v2 patch (v2 is not working
either, but I
think I find where the current problem is), soon after I fix my
network proxy issue...

Thanks
Zihan

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

[SeaBIOS] [RFC 2/2] pci_device: Add pci domain support

[Zihan Yang]

Most part of seabios assume only PCI domain 0. This patch adds support
for multiple domain in pci devices

Signed-off-by: Zihan Yang 
---
 src/fw/coreboot.c  |   2 +-
 src/fw/csm.c   |   2 +-
 src/fw/paravirt.c  |   2 +-
 src/fw/pciinit.c   | 191 +
 src/hw/pci.c   |  69 ++-
 src/hw/pci.h   |  42 
 src/hw/pci_ids.h   |   7 +-
 src/hw/pcidevice.c |   8 ++-
 src/hw/pcidevice.h |  10 ++-
 9 files changed, 206 insertions(+), 127 deletions(-)

diff --git a/src/fw/coreboot.c b/src/fw/coreboot.c
index 7c0954b..c955dfd 100644
--- a/src/fw/coreboot.c
+++ b/src/fw/coreboot.c
@@ -254,7 +254,7 @@ coreboot_platform_setup(void)
 {
 if (!CONFIG_COREBOOT)
 return;
-pci_probe_devices();
+pci_probe_devices(0);
 
 struct cb_memory *cbm = CBMemTable;
 if (!cbm)
diff --git a/src/fw/csm.c b/src/fw/csm.c
index 03b4bb8..e94f614 100644
--- a/src/fw/csm.c
+++ b/src/fw/csm.c
@@ -63,7 +63,7 @@ static void
 csm_maininit(struct bregs *regs)
 {
 interface_init();
-pci_probe_devices();
+pci_probe_devices(0);
 
 csm_compat_table.PnPInstallationCheckSegment = SEG_BIOS;
 csm_compat_table.PnPInstallationCheckOffset = get_pnp_offset();
diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c
index 6b14542..ef4d487 100644
--- a/src/fw/paravirt.c
+++ b/src/fw/paravirt.c
@@ -155,7 +155,7 @@ qemu_platform_setup(void)
 return;
 
 if (runningOnXen()) {
-pci_probe_devices();
+pci_probe_devices(0);
 xen_hypercall_setup();
 xen_biostable_setup();
 return;
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
index 6e6a434..71508d5 100644
--- a/src/fw/pciinit.c
+++ b/src/fw/pciinit.c
@@ -51,6 +51,7 @@ u64 pcimem_end = BUILD_PCIMEM_END;
 u64 pcimem64_start = BUILD_PCIMEM64_START;
 u64 pcimem64_end   = BUILD_PCIMEM64_END;
 u64 pci_io_low_end = 0xa000;
+u64 pxb_mcfg_size  = 0;
 
 struct pci_region_entry {
 struct pci_device *dev;
@@ -405,19 +406,21 @@ static void pci_bios_init_device(struct pci_device *pci)
 
 /* map the interrupt */
 u16 bdf = pci->bdf;
-int pin = pci_config_readb(bdf, PCI_INTERRUPT_PIN);
+int pin = pci_config_readb_dom(bdf, PCI_INTERRUPT_PIN, pci->domain_nr);
 if (pin != 0)
-pci_config_writeb(bdf, PCI_INTERRUPT_LINE, pci_slot_get_irq(pci, pin));
+pci_config_writeb_dom(bdf, PCI_INTERRUPT_LINE, pci_slot_get_irq(pci, 
pin),
+  pci->domain_nr);
 
 pci_init_device(pci_device_tbl, pci, NULL);
 
 /* enable memory mappings */
-pci_config_maskw(bdf, PCI_COMMAND, 0,
- PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_SERR);
+pci_config_maskw_dom(bdf, PCI_COMMAND, 0,
+ PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_SERR,
+ pci->domain_nr);
 /* enable SERR# for forwarding */
 if (pci->header_type & PCI_HEADER_TYPE_BRIDGE)
-pci_config_maskw(bdf, PCI_BRIDGE_CONTROL, 0,
- PCI_BRIDGE_CTL_SERR);
+pci_config_maskw_dom(bdf, PCI_BRIDGE_CONTROL, 0,
+ PCI_BRIDGE_CTL_SERR, pci->domain_nr);
 }
 
 static void pci_bios_init_devices(void)
@@ -520,6 +523,10 @@ static void pxb_mem_addr_setup(struct pci_device *dev, 
void *arg)
  * read mcfg_base and mcfg_size from it just now. Instead, we directly add
  * this item to e820 */
 e820_add(mcfg_base.val, mcfg_size, E820_RESERVED);
+
+/* Add PXBHosts so that we can can initialize them later */
+++PXBHosts;
+pxb_mcfg_size += mcfg_size;
 }
 
 static const struct pci_device_id pci_platform_tbl[] = {
@@ -540,19 +547,21 @@ static void pci_bios_init_platform(void)
 }
 }
 
-static u8 pci_find_resource_reserve_capability(u16 bdf)
+static u8 pci_find_resource_reserve_capability(u16 bdf, int domain_nr)
 {
-if (pci_config_readw(bdf, PCI_VENDOR_ID) == PCI_VENDOR_ID_REDHAT &&
-pci_config_readw(bdf, PCI_DEVICE_ID) ==
-PCI_DEVICE_ID_REDHAT_ROOT_PORT) {
+if (pci_config_readw_dom(bdf, PCI_VENDOR_ID, domain_nr) == 
PCI_VENDOR_ID_REDHAT &&
+(pci_config_readw_dom(bdf, PCI_DEVICE_ID, domain_nr) ==
+PCI_DEVICE_ID_REDHAT_ROOT_PORT ||
+ pci_config_readw_dom(bdf, PCI_DEVICE_ID, domain_nr) ==
+PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE)) {
 u8 cap = 0;
 do {
-cap = pci_find_capability(bdf, PCI_CAP_ID_VNDR, cap);
+cap = pci_find_capability_dom(bdf, PCI_CAP_ID_VNDR, cap, 
domain_nr);
 } while (cap &&
- pci_config_readb(bdf, cap + PCI_CAP_REDHAT_TYPE_OFFSET) !=
+ pci_config_readb_dom(bdf, cap + PCI_CAP_REDHAT_TYPE_OFFSET, 
domain_nr) !=
 REDHAT_CAP_RESOURCE_RESERVE);
 if (cap) {
-u8 cap_len = pci_config_readb(bdf, cap + PCI_CAP_FLAGS);
+u8 cap_len = pci_config_

[SeaBIOS] [RFC 0/2] (Ongoing)Support multiple pci domains in pci_device

[Zihan Yang]

NOTE: This patch set is still ongoing and does not fully function
as its goal. But it involves some API changes, therefore I post them for
comments before moving on to make sure I'm on the right path.

The corresponding qemu part can be found at
https://gitlab.com/WhoisZihan/qemu-pci-domain/tree/master/qemu
I will submit it to qemu list later.

Currently seabios assumes there is only one pci domain(0), and almost
everything operates on pci domain 0 by default. This patch aims to add
multiple pci domain support for pci_device, while reserve the original
API for compatibility.

Some part of it is dirty and hardcoded, as I plan to make it support 2 pci
domains first as a working POC. Many works remain to do when BIOS checks
and initializes PCI devices, because almost everywhere assumes 1 pci domain
by default.

It compiles and runs, but the guest will issue a "Bus 0001:00 not in PCI
Namespace" warning, and it does not correctly recognize the bus under
host bridges other than q35. If you have any clue about this error, please
point me out, I will appreciate it.

Zihan Yang (2):
  fw/pciinit: Recognize pxb-pcie-dev device
  pci_device: Add pci domain support

 src/fw/coreboot.c  |   2 +-
 src/fw/csm.c   |   2 +-
 src/fw/paravirt.c  |   3 +-
 src/fw/pciinit.c   | 208 ++---
 src/hw/pci.c   |  69 +-
 src/hw/pci.h   |  42 +++
 src/hw/pci_ids.h   |   6 +-
 src/hw/pcidevice.c |   8 ++-
 src/hw/pcidevice.h |  10 ++-
 9 files changed, 223 insertions(+), 127 deletions(-)

-- 
2.7.4


___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

[SeaBIOS] [RFC 1/2] fw/pciinit: Recognize pxb-pcie-dev device

[Zihan Yang]

QEMU q35 uses pxb-pcie-dev to enable multiple host bridges, this patch
recognizes such devices in seabios and add corresponding e820 entry.

MCFG base and size are already setup in QEMU, we just need to read it

Signed-off-by: Zihan Yang 
---
 src/fw/paravirt.c |  1 -
 src/fw/pciinit.c  | 17 +
 src/hw/pci_ids.h  |  1 +
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c
index 0770c47..6b14542 100644
--- a/src/fw/paravirt.c
+++ b/src/fw/paravirt.c
@@ -197,7 +197,6 @@ qemu_platform_setup(void)
 if (!loader_err)
 warn_internalerror();
 }
-
 acpi_setup();
 }
 
diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
index 3a2f747..6e6a434 100644
--- a/src/fw/pciinit.c
+++ b/src/fw/pciinit.c
@@ -507,11 +507,28 @@ static void mch_mem_addr_setup(struct pci_device *dev, 
void *arg)
 pci_io_low_end = acpi_pm_base;
 }
 
+static void pxb_mem_addr_setup(struct pci_device *dev, void *arg)
+{
+union u64_u32_u mcfg_base;
+mcfg_base.lo = pci_config_readl(dev->bdf, Q35_HOST_BRIDGE_PCIEXBAR);
+mcfg_base.hi = pci_config_readl(dev->bdf, Q35_HOST_BRIDGE_PCIEXBAR + 4);
+
+// Fix me! Use another meaningful macro
+u32 mcfg_size = pci_config_readl(dev->bdf, Q35_HOST_BRIDGE_PCIEXBAR + 8);
+
+/* Skip config write here as the qemu-level objects are already setup, we
+ * read mcfg_base and mcfg_size from it just now. Instead, we directly add
+ * this item to e820 */
+e820_add(mcfg_base.val, mcfg_size, E820_RESERVED);
+}
+
 static const struct pci_device_id pci_platform_tbl[] = {
 PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82441,
i440fx_mem_addr_setup),
 PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_Q35_MCH,
mch_mem_addr_setup),
+PCI_DEVICE(PCI_VENDOR_ID_REDHAT, PCI_DEVICE_ID_REDHAT_PXB_HOST,
+   pxb_mem_addr_setup),
 PCI_DEVICE_END
 };
 
diff --git a/src/hw/pci_ids.h b/src/hw/pci_ids.h
index 38fa2ca..35096ea 100644
--- a/src/hw/pci_ids.h
+++ b/src/hw/pci_ids.h
@@ -2265,6 +2265,7 @@
 
 #define PCI_VENDOR_ID_REDHAT   0x1b36
 #define PCI_DEVICE_ID_REDHAT_ROOT_PORT 0x000C
+#define PCI_DEVICE_ID_REDHAT_PXB_HOST  0x000B
 
 #define PCI_VENDOR_ID_TEKRAM   0x1de1
 #define PCI_DEVICE_ID_TEKRAM_DC290 0xdc29
-- 
2.7.4


___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios