On 31/12/2021 08:31, Cédric Le Goater wrote:
For Radix translation, the EA range is 64-bits. when EA(2:11) are
nonzero, a segment interrupt should occur.
Signed-off-by: Cédric Le Goater
---
Looks ok to me.
Reviewed-by: Frederic Barrat
Fred
target/ppc/mmu-radix64.h | 1 +
target
that the PCI AER code assumes an
interrupt is defined (LSI or MSI or MSI-X), which is not the case with
the root bridge device on powernv. So the last patch adds a check to
make sure a LSI is defined before entering pci_set_irq() as it asserts
if it's called with no LSI defined.
Frederic Barrat (3
Skip triggering an LSI when the AER root error status is updated if no
LSI is defined for the device. We can have a root bridge with no LSI,
MSI and MSI-X defined, for example on POWER systems.
Signed-off-by: Frederic Barrat
---
hw/pci/pcie_aer.c | 4 +++-
1 file changed, 3 insertions(+), 1
, all PHBs allocate the same bogus hw interrupt. We end up with
inconsistent interrupt controller (xive) data. The problem goes away
if we don't allocate the LSI in the first place.
Signed-off-by: Frederic Barrat
---
hw/pci-host/pnv_phb4.c | 5 -
1 file changed, 4 insertions(+), 1 deletion
Move the pci_intx() definition to the PCI header file, so that it can
be called from other PCI files. It is used by the next patch.
Signed-off-by: Frederic Barrat
---
hw/pci/pci.c | 5 -
include/hw/pci/pci.h | 5 +
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git
On 26/11/2021 10:09, Cédric Le Goater wrote:
On 11/16/21 18:01, Frederic Barrat wrote:
The PHB v4 found on POWER9 doesn't request any LSI, so let's clear the
Interrupt Pin register in the config space so that the model matches
the hardware.
If we don't, then we inherit from the default pcie
-E extended
config space access.
Signed-off-by: Christophe Lombard
---
FWIW, looks good to me
Reviewed-by: Frederic Barrat
hw/pci-host/pnv_phb4.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c
index 5c375a9f28..40b793201a 100644
On 07/12/2021 11:45, Cédric Le Goater wrote:
On 12/7/21 11:00, Frederic Barrat wrote:
On 02/12/2021 15:42, Cédric Le Goater wrote:
POWER9 processor comes with 3 PHB4 PECs (PCI Express Controller) and
each PEC can have several PHBs :
* PEC0 provides 1 PHB (PHB0)
* PEC1 provides 2
On 02/12/2021 15:42, Cédric Le Goater wrote:
All POWER8 machines have a maximum of 3 PHB3 devices. Adapt the
PNV8_CHIP_PHB3_MAX definition for consistency.
Signed-off-by: Cédric Le Goater
---
The Naples chip (Garrison) can have 4 PHBs and it seems we have a
power8nvl machine type for
On 02/12/2021 15:42, Cédric Le Goater wrote:
It is never used.
Signed-off-by: Cédric Le Goater
---
Reviewed-by: Frederic Barrat
hw/ppc/pnv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index bd768dcc28ad..988b305398b2 100644
--- a/hw/ppc/pnv.c
On 02/12/2021 15:42, Cédric Le Goater wrote:
PHB3s ared SysBus devices and should be allowed to be dynamically
created.
Signed-off-by: Cédric Le Goater
---
This one is a bit of black magic for me. I don't see an equivalent for
P9 though. Not needed there? I'll have another comment about
On 02/12/2021 15:42, Cédric Le Goater wrote:
Next changes will make use of it.
Signed-off-by: Cédric Le Goater
---
Reviewed-by: Frederic Barrat
include/hw/pci-host/pnv_phb4.h | 2 ++
hw/pci-host/pnv_phb4_pec.c | 2 ++
hw/ppc/pnv.c | 2 ++
3 files changed, 6
On 02/12/2021 15:42, Cédric Le Goater wrote:
PHB3 devices and PCI devices can now be added to the powernv8 machine
using :
-device pnv-phb3,chip-id=0,index=1 \
-device nec-usb-xhci,bus=pci.1,addr=0x0
The 'index' property identifies the PHB3 in the chip. In case of user
created
Make sure a PHB3 device is parented to its chip by reparenting the
object if necessary.
Signed-off-by: Cédric Le Goater
---
It will also be used later for P9, which explains why it's done that
way, I think. Looks ok to me.
Reviewed-by: Frederic Barrat
include/hw/ppc/pnv.h | 1 +
h
On 02/12/2021 15:42, Cédric Le Goater wrote:
This requires a link to the chip to add the regions under the XSCOM
address space. This change will help us providing support for user
created PHB3 devices.
Signed-off-by: Cédric Le Goater
---
Reviewed-by: Frederic Barrat
include/hw/pci
On 02/12/2021 15:42, Cédric Le Goater wrote:
Signed-off-by: Cédric Le Goater
---
Empty log message ok in qemu?
But it looks ok to me.
Reviewed-by: Frederic Barrat
include/hw/pci-host/pnv_phb4.h | 2 ++
hw/pci-host/pnv_phb4_pec.c | 2 ++
hw/ppc/pnv.c | 4
On 02/12/2021 15:42, Cédric Le Goater wrote:
POWER9 processor comes with 3 PHB4 PECs (PCI Express Controller) and
each PEC can have several PHBs :
* PEC0 provides 1 PHB (PHB0)
* PEC1 provides 2 PHBs (PHB1 and PHB2)
* PEC2 provides 3 PHBs (PHB3, PHB4 and PHB5)
A num_pecs class
uot;num-stacks" property.
Signed-off-by: Cédric Le Goater
---
Reviewed-by: Frederic Barrat
include/hw/pci-host/pnv_phb4.h | 1 +
hw/pci-host/pnv_phb4_pec.c | 17 -
hw/ppc/pnv.c | 7 ---
3 files changed, 17 insertions(+), 8 deletions(-)
diff
On 02/12/2021 15:42, Cédric Le Goater wrote:
Use the num_stacks class attribute to compute the PHB index depending
on the PEC index :
* PEC0 provides 1 PHB (PHB0)
* PEC1 provides 2 PHBs (PHB1 and PHB2)
* PEC2 provides 3 PHBs (PHB3, PHB4 and PHB5)
Signed-off-by: Cédric Le Goater
On 02/12/2021 15:42, Cédric Le Goater wrote:
This is not useful and will be in the way for support of user created
PHB4 devices.
Signed-off-by: Cédric Le Goater
---
I doubt I see all the implications here, but it doesn't look wrong to
me, so:
Reviewed-by: Frederic Barrat
Fred
the owning chip.
To be noted, that the PEC PHB4 devices can add more than one PHB4
devices:
* PEC0 provides 1 PHB (PHB0)
* PEC1 provides 2 PHBs (PHB1 and PHB2)
* PEC2 provides 3 PHBs (PHB3, PHB4 and PHB5)
Signed-off-by: Cédric Le Goater
---
Reviewed-by: Frederic Barrat
hw/pci-host
On 02/12/2021 15:42, Cédric Le Goater wrote:
This change will help us providing support for user created PHB4
devices.
Signed-off-by: Cédric Le Goater
---
hw/pci-host/pnv_phb4_pec.c | 36
hw/ppc/pnv.c | 31 +--
On 02/12/2021 15:42, Cédric Le Goater wrote:
This is not useful and will be in the way for support of user created
PHB4 devices.
Signed-off-by: Cédric Le Goater
---
I forgot to mention the typo in the commit title: "he PHB4".
Fred
hw/pci-host/pnv_phb4_pec.c | 6 +-
hey are mostly FIR registers...
Looks good to me.
Reviewed-by: Frederic Barrat
hw/pci-host/pnv_phb4.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c
index be29174f13..a7b638831e 100644
--- a/hw/pci-host/p
On 14/03/2022 15:38, Cédric Le Goater wrote:
On 3/14/22 15:16, Frederic Barrat wrote:
On 14/03/2022 14:05, Cédric Le Goater wrote:
On a real system with POWER{8,9,10} processors, PHBs are sub-units of
the processor, they can be deactivated by firmware but not plugged in
or out like a PCI
uot;)
Signed-off-by: Cédric Le Goater
---
So with this patch, -nodefaults has basically no effect on the PHBs and
root ports creation. They are always there. It makes sense, since we are
removing the capability to add a subset of them.
Reviewed-by: Frederic Barrat
include/hw/ppc/pn
A short series to fix creating PHB devices and root ports on the newly
merged powernv10 machine.
Frederic Barrat (3):
ppc/pnv: Introduce a pnv-phb5 device to match root port
ppc/pnv: Fixes for user-created pnv-phb5 devices
ppc/pnv: Fix PEC lookup function for POWER10
hw/pci-host/pnv_phb4
pnv-phb5-root-port
Fixes: 623575e16cd5 ("ppc/pnv: Add model for POWER10 PHB5 PCIe Host bridge")
Signed-off-by: Frederic Barrat
---
hw/pci-host/pnv_phb4.c | 7 +++
hw/pci-host/pnv_phb4_pec.c | 9 +
include/hw/pci-host/pnv_phb4.h | 5 +
3 files changed, 17
dynamically allocated system bus
Fixes: 623575e16cd5 ("ppc/pnv: Add model for POWER10 PHB5 PCIe Host bridge")
Signed-off-by: Frederic Barrat
---
hw/ppc/pnv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 0ac86e104f..df58403a3a 10064
pointer based on the chip object and PEC index.
Fixes: 623575e16cd5 ("ppc/pnv: Add model for POWER10 PHB5 PCIe Host bridge")
Signed-off-by: Frederic Barrat
---
hw/pci-host/pnv_phb4.c | 5 ++---
hw/ppc/pnv.c | 14 ++
include/hw/ppc/pnv.h | 1 +
3 files changed, 17
. For example on the POWER8/POWER9/POWER10 systems, the
root bridge doesn't request any LSI.
Signed-off-by: Frederic Barrat
---
hw/pci/pcie.c | 8 ++--
hw/pci/pcie_aer.c | 4 +++-
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index 67a5d67372
generated was bogus, as
the root bridge LSI was not properly mapped. On some
implementation (powernv9), it was leading to inconsistent interrupt
controller (xive) data. With this patch, it is now clean.
Signed-off-by: Frederic Barrat
---
hw/pci-host/pnv_phb3.c | 1 +
hw/pci-host/pnv_phb4.c | 1 +
2
is configured before
trying to trigger it.
Frederic Barrat (2):
pcie: Don't try triggering a LSI when not defined
ppc/pnv: Remove LSI on the PCIE host bridge
hw/pci-host/pnv_phb3.c | 1 +
hw/pci-host/pnv_phb4.c | 1 +
hw/pci/pcie.c | 8 ++--
hw/pci/pcie_aer.c | 4 +++-
4 files
On 24/03/2022 14:07, Daniel Henrique Barboza wrote:
On 3/21/22 12:33, Frederic Barrat wrote:
This patch skips [de]asserting a LSI interrupt if the device doesn't
have any LSI defined. Doing so would trigger an assert in
pci_irq_handler().
The PCIE root port implementation in qemu requests
On 01/04/2022 03:59, Benjamin Herrenschmidt wrote:
This one:
#define PHB4_PEC_PCI_REGS_COUNT 0x2
Should be
#define PHB4_PEC_PCI_REGS_COUNT 0x3
There is no register at 0x1 though.
Patch on the way
Fred
c/pnv: Add models for POWER9 PHB4 PCIe Host bridge")
Suggested-by: Benjamin Herrenschmidt
Signed-off-by: Frederic Barrat
---
include/hw/pci-host/pnv_phb4.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/hw/pci-host/pnv_phb4.h b/include/hw/pci-host/pnv_ph
If an iommu page has wrong permissions, an error message is displayed,
but the access is allowed, which is odd. This patch fixes it.
Signed-off-by: Frederic Barrat
---
hw/pci-host/pnv_phb3.c | 11 ++-
hw/pci-host/pnv_phb4.c | 11 ++-
2 files changed, 12 insertions(+), 10
On 21/01/2022 18:35, Cédric Le Goater wrote:
On 1/21/22 16:23, Frederic Barrat wrote:
If an iommu page has wrong permissions, an error message is displayed,
but the access is allowed, which is odd. This patch fixes it.
Being curious. How do you generate such errors ? could we have
the P10 model was already
being worked on so they may have simply fallen through the cracks.
Signed-off-by: Frederic Barrat
---
target/ppc/cpu_init.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c
index 073fd10168..2e9a3ded54 100644
--- a/target
On 06/04/2022 09:52, Michael S. Tsirkin wrote:
On Mon, Mar 21, 2022 at 04:33:55PM +0100, Frederic Barrat wrote:
The powernv8/powernv9/powernv10 machines allocate a LSI for their root
port bridge, which is not the case on real hardware. The default root
port implementation in qemu requests
xive: Add support for the PC MMIOs")
Signed-off-by: Cédric Le Goater
---
Reviewed-by: Frederic Barrat
hw/intc/pnv_xive.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/intc/pnv_xive.c b/hw/intc/pnv_xive.c
index 9b10e905195a..a36b3bf08c92 100644
--- a/hw/i
for the NVT accesses which we
will address later.
Signed-off-by: Cédric Le Goater
---
Reviewed-by: Frederic Barrat
Fred
hw/intc/pnv_xive_regs.h | 1 +
hw/intc/pnv_xive.c | 69 +++--
2 files changed, 68 insertions(+), 2 deletions(-)
diff --git
really to catch any error and remove any potential ambiguity about the
address space?
In any case,
Reviewed-by: Frederic Barrat
Fred
+if (result != MEMTX_OK) {
+xive_error(xive, "VST: read failed at @0x%" HWADDR_PRIx
+ " for VST %s %x/%x
_W5_ESC_END_DATA, end.w5));
+xive_router_end_notify_handler(xrtr, (XiveEAS *) );
I didn't like the cast, but I can see why you're doing it this way. We
should be fine as long as the notify handler is not testing the validity
bit of the EAS structure.
Reviewed-by: Frederic Barrat
Fred
}
void xive_route
by pnv_xive_vst_write
or read to perform the operation in RAM.
Remove the last use of pnv_xive_get_remote().
Signed-off-by: Cédric Le Goater
-
Nice cleanup
Reviewed-by: Frederic Barrat
Fred
hw/intc/pnv_xive.c | 84 ++
1 file changed, 48 insertions
-by: Frederic Barrat
---
Cedric: I'm wondering the reason behind commit
8256870ada9379abfd1f5b2c209ad01092dd0904, which makes the PIPR field
of the OS context read-only. The comment says it is re-evaluated from
the IPB when pushing a context, but I don't think it's true on P9
if there's no escalation. It's
Hello Cédric!
Thanks for the detail review!
On 26/04/2022 14:35, Cédric Le Goater wrote:
Hello Frederic,
On 4/26/22 12:11, Frederic Barrat wrote:
When pulling an OS context from a vcpu, we should lower the External
interrupt if it is pending. Otherwise, it may be delivered
is configured before
trying to trigger it.
Changes from v1:
- addressed comments from Daniel
Frederic Barrat (2):
pcie: Don't try triggering a LSI when not defined
ppc/pnv: Remove LSI on the PCIE host bridge
hw/pci-host/pnv_phb3.c | 1 +
hw/pci-host/pnv_phb4.c | 1 +
hw/pci/pcie.c | 5
. For example on the POWER8/POWER9/POWER10 systems, the
root bridge doesn't request any LSI.
Signed-off-by: Frederic Barrat
---
hw/pci/pcie.c | 5 +++--
hw/pci/pcie_aer.c | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index 67a5d67372
generated was bogus, as
the root bridge LSI was not properly mapped. On some
implementation (powernv9), it was leading to inconsistent interrupt
controller (xive) data. With this patch, it is now clean.
Signed-off-by: Frederic Barrat
---
hw/pci-host/pnv_phb3.c | 1 +
hw/pci-host/pnv_phb4.c | 1 +
2
to enable physical threads and the PC registers
at the same offset are either not used by our model or the update was
harmless.
Found through code inspection.
Signed-off-by: Frederic Barrat
---
hw/intc/pnv_xive2.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/hw/intc/pnv_xive2.c b/hw/intc
On 31/05/2022 23:49, Daniel Henrique Barboza wrote:
Hi,
This v2 is considerable different from the first version due to the
review provided by Mark Cave-Ayland.
We're now preserving all PnvPHB3/4/5 implementations already in place.
The PnvPHB device now acts as a base/proxy of the existing
On 31/05/2022 23:49, Daniel Henrique Barboza wrote:
Change the parent type of the PnvPHB4 device to TYPE_PARENT since the
s/TYPE_PARENT/TYPE_DEVICE
Fred
PCI bus is going to be initialized by the PnvPHB parent. Functions that
needs to access the bus via a PnvPHB4 object can do so via
. Everything is almost in place to allow access for
other nodes though. So this patch reworks how the PIR value is
computed so that we can access all thread contexts through the IC BAR.
The PIR is already correct on P9, so no need to modify anything there.
Signed-off-by: Frederic Barrat
---
hw/intc
On 31/05/2022 23:49, Daniel Henrique Barboza wrote:
The PnvPHB device is going to be the base device for all other powernv
PHBs. It consists of a device that has the same user API as the other
PHB, namely being a PCIHostBridge and having chip-id and index
properties. It also has a 'backend'
On 31/05/2022 23:49, Daniel Henrique Barboza wrote:
To enable user creatable PnvPHB devices for powernv9 we'll revert the
powernv9 related changes made in 9c10d86fee "ppc/pnv: Remove
user-created PHB{3,4,5} devices".
This change alone isn't enough to enable user creatable devices for
On 02/06/2022 19:00, Cédric Le Goater wrote:
On 6/2/22 18:53, Frederic Barrat wrote:
When accessing a thread context through the IC BAR, the offset of the
page in the BAR identifies the CPU. From that offset, we can compute
the PIR (processor ID register) of the CPU to do the data structure
x' parameter. Let's also add a 'chip_id' parameter to this
function and assign chassis and slot right there. This will spare us
from the hassle of accessing the PHB object inside realize().
Signed-off-by: Daniel Henrique Barboza
---
Reviewed-by: Frederic Barrat
Fred
hw/pci-host/pnv
Hello,
I've been looking at why our qemu powernv model is so slow when booting
a compressed linux kernel, using multiple vcpus and multi-thread tcg.
With only one vcpu, the decompression time of the kernel is what it is,
but when using multiple vcpus, the decompression is actually slower. And
[ Resending as it was meant for the qemu-ppc list ]
Hello,
I've been looking at why our qemu powernv model is so slow when booting
a compressed linux kernel, using multiple vcpus and multi-thread tcg.
With only one vcpu, the decompression time of the kernel is what it is,
but when using
On 28/06/2022 17:12, Alex Bennée wrote:
Frederic Barrat writes:
On 28/06/2022 13:25, Matheus K. Ferst wrote:
On 27/06/2022 15:25, Frederic Barrat wrote:
[ Resending as it was meant for the qemu-ppc list ]
Hello,
I've been looking at why our qemu powernv model is so slow when booting
On 28/06/2022 13:25, Matheus K. Ferst wrote:
On 27/06/2022 15:25, Frederic Barrat wrote:
[ Resending as it was meant for the qemu-ppc list ]
Hello,
I've been looking at why our qemu powernv model is so slow when booting
a compressed linux kernel, using multiple vcpus and multi-thread tcg
On 29/06/2022 00:17, Alex Bennée wrote:
If you run the sync-profiler (via the HMP "sync-profile on") you can
then get a breakdown of which mutex's are being held and for how long
("info sync-profile").
Alex, a huge thank you!
For the record, the "info sync-profile" showed:
Type
On 03/06/2022 23:00, Daniel Henrique Barboza wrote:
static void pnv_phb4_realize(DeviceState *dev, Error **errp)
{
PnvPHB4 *phb = PNV_PHB4(dev);
+ PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
+ PnvChip *chip = pnv_get_chip(pnv, phb->chip_id);
XiveSource *xsrc
On 07/06/2022 08:42, Cédric Le Goater wrote:
On 6/2/22 18:16, Frederic Barrat wrote:
On 31/05/2022 23:49, Daniel Henrique Barboza wrote:
The PnvPHB device is going to be the base device for all other powernv
PHBs. It consists of a device that has the same user API as the other
PHB, namely
On 07/06/2022 08:35, Cédric Le Goater wrote:
Also, the comment seems wrong to me. The qom parenting doesn't matter
when building the device tree.
it does. See pnv_dt_xscom()
Yeah, what I meant is that on P9, there's no "dt_scom" method for the
PHB. The PHBs are added by the dt_scom()
in secondary_wait.
It results in a full system hang with no message on the console, as
the uart hasn't been init'ed yet. It's actually not obvious to realise
what's happening if not tracing reset (-d cpu_reset). The fix is
simply to clear the 'resume_as_sreset' attribute on reset.
Signed-off-by: Frederic
On 13/06/2022 17:44, Daniel Henrique Barboza wrote:
pnv_ics_resend() is scrolling through all the child objects of the chip
to search for the PHBs. It's faster and simpler to just use the phbs[]
array.
pnv_ics_resend_child() was folded into pnv_ics_resend() since it's too
simple to justify
On 13/06/2022 17:44, Daniel Henrique Barboza wrote:
It is not advisable to execute an object_dynamic_cast() to poke into
bus->qbus.parent and follow it up with a C cast into the PnvPHB type we
think we got.
A better way is to access the PnvPHB object via a QOM macro accessing
the existing
-by: Frederic Barrat
Fred
hw/pci-host/pnv_phb3.c | 2 +-
hw/pci-host/pnv_phb4.c | 2 +-
hw/ppc/pnv.c | 7 ++-
include/hw/ppc/pnv.h | 2 +-
4 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/hw/pci-host/pnv_phb3.c b/hw/pci-host/pnv_phb3.c
index 26ac9b7123..4ba660f8b9
On 13/06/2022 17:44, Daniel Henrique Barboza wrote:
We already have access to the 'dev' object.
Signed-off-by: Daniel Henrique Barboza
---
Reviewed-by: Frederic Barrat
Fred
hw/pci-host/pnv_phb3.c | 4 ++--
hw/pci-host/pnv_phb4.c | 5 ++---
2 files changed, 4 insertions(+), 5
On 13/06/2022 17:44, Daniel Henrique Barboza wrote:
Creating a root port is something related to the PHB, not the PEC. It
also makes the logic more in line with what pnv-phb3 does.
Signed-off-by: Daniel Henrique Barboza
---
LGTM,
Reviewed-by: Frederic Barrat
Fred
hw/pci-host
oza
---
Reviewed-by: Frederic Barrat
Fred
hw/ppc/pnv.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index d70deffa1d..5e3323e950 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -652,25 +652,19 @@ static ISABus *pnv_isa_cre
don't see anything wrong
with it. So:
Reviewed-by: Frederic Barrat
Fred
hw/ppc/pnv.c | 19 ++-
include/hw/ppc/pnv.h | 6 +-
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 5e3323e950..6ce9e94e05 100644
--- a/
On 13/06/2022 17:44, Daniel Henrique Barboza wrote:
The function is working today by getting all the child objects of the
chip, interacting with each of them to check whether the child is a PHB,
and then doing what needs to be done.
We have all the chip PHBs in the phbs[] array so
On 13/06/2022 17:44, Daniel Henrique Barboza wrote:
There's nothing special that is being done in
pnv_chip_power8_instance_init() that can't be done during
pnv_chip_power8_realize(). Move the PHB creating and phbs[] assignment
to power8_realize().
We also need to assign a proper phb->chip
On 14/06/2022 17:39, Daniel Henrique Barboza wrote:
I've been thinking about it and I guess I could do better with this
and the proxy pnv-phb series that is already in v2. What I'm thinking
is:
- crop patches 8-11 from this series. Patches 1-7 would be the prep cleanup
series;
- split the
it was not in a stop state and/or when the appropriate
exception handler isn't set up yet.
Signed-off-by: Frederic Barrat
---
I didn't find an appropriate commit to add a "Fixes:". It originates
when adding support for power management states but the code looked
quite different in 2016 and it's
On 15/06/2022 07:23, Cédric Le Goater wrote:
On 6/14/22 10:29, Frederic Barrat wrote:
The 'resume_as_sreset' attribute of a cpu can be set when a thread is
entering a stop state on ppc books. It causes the thread to be
re-routed to vector 0x100 when woken up by an exception. So it must
interacting with all
child objects is unneeded. Open code pnv_ics_get_phb_ics() into
pnv_ics_get() and remove both pnv_ics_get_phb_ics() and the
ForeachPhb3Args struct.
Signed-off-by: Daniel Henrique Barboza
---
Reviewed-by: Frederic Barrat
Fred
hw/ppc/pnv.c | 38
its own function.
Signed-off-by: Daniel Henrique Barboza
---
Reviewed-by: Frederic Barrat
Fred
hw/ppc/pnv.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index ff7f803662..08136def8e 100644
--- a/hw/ppc/pnv.c
On 18/06/2022 13:02, Daniel Henrique Barboza wrote:
It's unneeded. No other PCIE_BUS implements this interface.
Fixes: 9ae1329ee2fe ("ppc/pnv: Add models for POWER8 PHB3 PCIe Host bridge")
Signed-off-by: Daniel Henrique Barboza
---
It seems indeed not needed.
Reviewed-by: Frede
On 18/06/2022 13:02, Daniel Henrique Barboza wrote:
It's unneeded. No other PCIE_BUS implements this interface.
Fixes: 4f9924c4d4cf ("ppc/pnv: Add models for POWER9 PHB4 PCIe Host bridge")
Signed-off-by: Daniel Henrique Barboza
---
Reviewed-by: Frederic Barrat
Fred
h
On 24/06/2022 10:49, Daniel Henrique Barboza wrote:
Hi,
This is the version 3 of the pnv-phb proxy device which has the
following main differences from v2:
- it's rebased on top of "[PATCH v3 0/8] pnv-phb related cleanups"
- it doesn't have any patches related to user-created devices
There
device and put into a new parent PnvPHB device.
The new pnv_phb3_bus_init() helper will be used by the parent to init
the bus when using the PHB3 backend.
Signed-off-by: Daniel Henrique Barboza
---
Reviewed-by: Frederic Barrat
Fred
hw/pci-host/pnv_phb3.c | 39
-by: Frederic Barrat
Fred
hw/pci-host/pnv_phb.c | 2 ++
hw/pci-host/pnv_phb4.c | 39 --
include/hw/pci-host/pnv_phb4.h | 1 +
3 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/hw/pci-host/pnv_phb.c b/hw/pci-host/pnv_phb.c
ult settings. The real gain will come with user created PnvPHB
devices, coming up next.
Signed-off-by: Daniel Henrique Barboza
---
A very minor indentation issue below, but other than that:
Reviewed-by: Frederic Barrat
hw/pci-host/pnv_phb3.c | 27 +--
hw/ppc/pn
-by: Frederic Barrat
Fred
hw/pci-host/pnv_phb.c | 4 +-
hw/pci-host/pnv_phb4.c | 85 --
hw/pci-host/pnv_phb4_pec.c | 4 +-
hw/ppc/pnv.c | 2 +
include/hw/pci-host/pnv_phb4.h | 9
5 files changed, 6 insertions(+), 98
On 24/06/2022 10:49, Daniel Henrique Barboza wrote:
It's unused.
Signed-off-by: Daniel Henrique Barboza
---
Reviewed-by: Frederic Barrat
Fred
include/hw/pci-host/pnv_phb4.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/hw/pci-host/pnv_phb4.h b/include/hw/pci-host
On 24/06/2022 10:49, Daniel Henrique Barboza wrote:
The helper is only used in this file.
Signed-off-by: Daniel Henrique Barboza
---
Reviewed-by: Frederic Barrat
Fred
hw/pci-host/pnv_phb.c | 24
hw/ppc/pnv.c | 25
On 24/06/2022 10:49, Daniel Henrique Barboza wrote:
The attribute is unused.
Signed-off-by: Daniel Henrique Barboza
---
Reviewed-by: Frederic Barrat
Fred
hw/pci-host/pnv_phb4_pec.c | 2 --
include/hw/pci-host/pnv_phb4.h | 1 -
2 files changed, 3 deletions(-)
diff --git
oza
---
Reviewed-by: Frederic Barrat
Fred
hw/pci-host/meson.build | 3 +-
hw/pci-host/pnv_phb.c | 124
hw/pci-host/pnv_phb.h | 39 +
3 files changed, 165 insertions(+), 1 deletion(-)
create mode 100644 hw/pci-host/pnv_phb.c
cre
-by: Daniel Henrique Barboza
---
Reviewed-by: Frederic Barrat
Fred
hw/pci-host/pnv_phb.c | 115 +++---
hw/pci-host/pnv_phb.h | 16 ++
2 files changed, 123 insertions(+), 8 deletions(-)
diff --git a/hw/pci-host/pnv_phb.c b/hw/pci-host/pnv_phb.c
we could remove the second if statement
for readability. The reason I mention it is that we don't take that much
care in the pnv_chip_power8_pic_print_info() function just above, so it
looks a bit odd.
In any case:
Reviewed-by: Frederic Barrat
Fred
@@ -2122,8 +2129,14 @@ st
-by: Frederic Barrat
Fred
hw/pci-host/pnv_phb.c | 2 +-
hw/pci-host/pnv_phb3.c | 42 --
hw/ppc/pnv.c | 1 +
include/hw/pci-host/pnv_phb3.h | 6 -
4 files changed, 2 insertions(+), 49 deletions(-)
diff --git a/hw/pci
On 24/06/2022 10:49, Daniel Henrique Barboza wrote:
We support only a single root port, PNV_PHB_ROOT_PORT.
Signed-off-by: Daniel Henrique Barboza
---
Reviewed-by: Frederic Barrat
Fred
hw/pci-host/pnv_phb.c | 7 +--
hw/ppc/pnv.c | 9 +
include/hw/ppc/pnv.h
On 26/04/2022 17:24, Cédric Le Goater wrote:
I would be interested to know if you can start an emulated QEMU PowerNV
system (2cpus) with a KVM guest (1 vcpu) and sustain some network load
host<->guest with a ping -f for instance.
We're not there yet unfortunately. It runs for a while
the OS context. Fortunately, it's already the case, as we
now always call xive_tctx_ipb_update(), which will raise the signal if
needed.
Signed-off-by: Frederic Barrat
---
hw/intc/xive.c| 14 ++
hw/intc/xive2.c | 2 ++
include/hw/ppc/xive.h | 1 +
3 files changed, 17
This short series fixes a couple of issues about interrupt handling
found when running a KVM guest on the powernv9 and powernv10 models. I
split a patch I previously sent.
Frederic Barrat (2):
ppc/xive: Always recompute the PIPR when pushing an OS context
ppc/xive: Update the state
. This patch fixes it by always calling xive_tctx_ipb_update().
Note that on P10 (xive2.c) and because of the above, there's no longer
any need to check the CPPR value so it can go away.
Signed-off-by: Frederic Barrat
---
hw/intc/xive.c | 10 +++---
hw/intc/xive2.c | 15 ---
2 files
1 - 100 of 187 matches
Mail list logo
