On Tue, 2024-02-20 at 10:35 +1000, Nicholas Piggin wrote:
> On Fri Feb 16, 2024 at 3:50 AM AEST, Peter Maydell wrote:
> > On Thu, 15 Feb 2024 at 17:16, Nicholas Piggin
> > wrote:
> > > Calculate the BHRB base from arithmetic on the tcg_env target
> > > ptr.
> > >
> > > Signed-off-by: Nicholas Pig
On Tue, 2024-03-05 at 07:20 +0100, Cédric Le Goater wrote:
> On 3/4/24 23:32, Paolo Bonzini wrote:
> > On 1/25/24 23:48, Glenn Miles wrote:
> > > Specs are available here:
> > >
> > > https://www.nxp.com/docs/en/data-sheet/PCA9554_9554A.pdf
> > >
> > > This is a simple model supporting the b
On Thu, 2024-03-21 at 17:01 +0100, Cédric Le Goater wrote:
> Coverity detected an "Integer handling" issue with the pin value :
>
> In expression "state >> pin", right shifting "state" by more than 7
> bits always yields zero. The shift amount, "pin", is as much as 8.
>
> In practice, this s
Thanks for doing this, Cédric!
Reviewed-by: Glenn Miles
-Glenn
On Mon, 2024-03-25 at 14:48 +0100, Cédric Le Goater wrote:
> The PCA9552 and PCA9554 devices are both I2C GPIO controllers and the
> PCA9552 also can drive LEDs. Do all the necessary adjustments to move
> the models unde
On Mon, 2024-03-18 at 16:58 +0100, Cédric Le Goater wrote:
Thanks for fixing that!
-Glenn
Reviewed-by: Glenn Miles
> The I2C controller is a subunit of the processor. Make it so and
> avoid
> QEMU crashes.
>
> $ build/qemu-system-ppc64 -S -machine powernv9 -device pnv-i2c
> qemu-system-pp
Looks good. Thanks for taking care of that for us!
-Glenn
Reviewed-by: Glenn Miles
On Tue, 2024-04-16 at 20:47 +0200, Philippe Mathieu-Daudé wrote:
> One of the biggest change from I2C spec v6 -> v7 is:
>
> • Updated the terms "master/slave" to "controller/target"
>
> Since it follows the
Thanks!
Reviewed-by: Glenn Miles
Glenn
On Wed, 2024-06-26 at 04:05 -0500, Chalapathi V wrote:
> SPI controller device model supports a connection to a single SPI
> responder.
> This provide access to SPI seeproms, TPM, flash device and an ADC
> controller.
>
> All SPI f
Thanks!
Reviewed-by: Glenn Miles
Glenn
On Wed, 2024-06-26 at 04:05 -0500, Chalapathi V wrote:
> In this commit SPI shift engine and sequencer logic is implemented.
> Shift engine performs serialization and de-serialization according to
> the
> control by the sequencer and acco
Reviewed-by: Glenn Miles
Thanks,
Glenn
On Tue, 2024-05-28 at 16:20 +1000, Nicholas Piggin wrote:
> From: Glenn Miles
>
> The LPC HC irq status register bits are set when an LPC IRQSER input
> is
> asserted. These irq status bits drive the PSI irq to the CPU
> interrupt
> controller. The LPC H
Reviewed-by: Glenn Miles
Thanks,
Glenn
On Tue, 2024-05-28 at 16:20 +1000, Nicholas Piggin wrote:
> The POWER8 LPC ISA device irqs all get combined and reported to the
> line
> connected the PSI LPCHC irq. POWER9 changed this so only internal LPC
> host controller irqs use that line, and the dev
Hi Chalapathi,
Looks good. Just some suggestions on readability and some
simplifications (see below).
Thanks,
Glenn
On Thu, 2024-05-16 at 11:33 -0500, Chalapathi V wrote:
> SPI controller device model supports a connection to a single SPI
> responder.
> This provide access to SPI seeproms, TPM
Hi Chalapathi,
Looks good. I think I would just shorten the names of the xscom
read/write functions to make things more readable inside the
transaction function.
-Glenn
Reviewed-by: Glenn Miles
> +static uint64_t pnv_spi_seeprom_xscom_addr(uint32_t reg)
> +{
> +return pnv_xscom_addr(SPIC2
Reviewed-by: Glenn Miles
-Glenn
On Thu, 2024-05-16 at 11:33 -0500, Chalapathi V wrote:
> Add Microchip's 25CSM04 Serial EEPROM to m25p80. 25CSM04 provides 4
> Mbits
> of Serial EEPROM utilizing the Serial Peripheral Interface (SPI)
> compatible
> bus. The device is organ
Reviewed-by: Glenn Miles
-Glenn
On Thu, 2024-05-16 at 11:33 -0500, Chalapathi V wrote:
> In this commit, create SPI controller on p10 chip and connect cs irq.
>
> The QOM tree of spi controller and seeprom are.
> /machine (powernv10-machine)
> /chip[0] (power10_v2.0-pnv-chip)
Chalapathi,
I'm having trouble seeing the benefit of breaking this commit out from
patch 1/5. It seems like the two should be merged into a single commit
responsible for adding the PNV SPI Controller model.
-Glenn
On Thu, 2024-05-16 at 11:33 -0500, Chalapathi V wrote:
> In this commit SPI shif
On Tue, 2024-05-21 at 08:18 +0200, Cédric Le Goater wrote:
> On 5/21/24 08:11, Chalapathi V wrote:
> > On 18-05-2024 01:24, Miles Glenn wrote:
> > > Chalapathi,
> > >
> > > I'm having trouble seeing the benefit of breaking this commit out
> > > f
Reviewed-by: Glenn Miles
Thanks,
Glenn
On Tue, 2024-05-21 at 11:30 +1000, Nicholas Piggin wrote:
> checkstop state does not halt the system, interrupts continue to be
> serviced, and other CPUs run. Make it stop the machine with
> qemu_system_guest_panicked.
>
> Signed-off-by: Nicholas Piggin
Reviewed-by: Glenn Miles
Thanks,
Glenn
On Tue, 2024-05-21 at 11:30 +1000, Nicholas Piggin wrote:
> Change the logging not to print to stderr as well, because a
> checkstop is a guest error (or perhaps a simulated machine error)
> rather than a QEMU error, so send it to the log.
>
> Update the
Reviewed-by: Glenn Miles
Thanks,
Glenn
On Tue, 2024-05-21 at 11:30 +1000, Nicholas Piggin wrote:
> The DECAR SPR is 32-bits width.
>
> Signed-off-by: Nicholas Piggin
> ---
> target/ppc/cpu_init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/ppc/cpu_init.c
Looks like this patch is failing to apply to the current master head?
Thanks,
Glenn
On Tue, 2024-05-21 at 11:30 +1000, Nicholas Piggin wrote:
> attn is an implementation-specific instruction that on POWER (and G5/
> 970) can be enabled with a HID bit (disabled = illegal), and
> executing
> it ca
Reviewed-by: Glenn Miles
Thanks,
Glenn
On Tue, 2024-05-21 at 11:30 +1000, Nicholas Piggin wrote:
> PPR32 provides access to the upper half of PPR.
>
> Signed-off-by: Nicholas Piggin
> ---
> target/ppc/cpu.h| 1 +
> target/ppc/spr_common.h | 2 ++
> target/ppc/cpu_init.c | 12
Reviewed-by: Glenn Miles
Thanks,
Glenn
On Tue, 2024-05-21 at 11:30 +1000, Nicholas Piggin wrote:
> AMOR, MMCRC, HRMOR, TSCR, HMEER, RPR SPRs are per-core or per-LPAR
> registers with simple (generic) implementations.
>
> Signed-off-by: Nicholas Piggin
> ---
> target/ppc/cpu_init.c | 12 +
Reviewed-by: Glenn Miles
Thanks,
Glenn
On Tue, 2024-05-21 at 11:30 +1000, Nicholas Piggin wrote:
> PTCR is a per-core register.
>
> Signed-off-by: Nicholas Piggin
> ---
> target/ppc/misc_helper.c | 16 ++--
> target/ppc/translate.c | 4
> 2 files changed, 18 insertions(+)
Reviewed-by: Glenn Miles
Thanks,
Glenn
On Tue, 2024-05-21 at 11:30 +1000, Nicholas Piggin wrote:
> This implements the POWER SPRC/SPRD SPRs, and SCRATCH0-7 registers
> that
> can be accessed via these indirect SPRs.
>
> SCRATCH registers only provide storage, but they are used by firmware
> fo
Reviewed-by: Glenn Miles
Thanks,
Glenn
On Tue, 2024-05-21 at 11:30 +1000, Nicholas Piggin wrote:
> LDBAR, TTR are a Power-specific SPRs. These simple implementations
> are enough for IBM proprietary firmware for now.
>
> Signed-off-by: Nicholas Piggin
> ---
> target/ppc/cpu.h | 2 ++
>
Reviewed-by: Glenn Miles
Thanks,
Glenn
On Tue, 2024-05-21 at 11:30 +1000, Nicholas Piggin wrote:
> An SPR can be either per-thread, per-core, or per-LPAR. Per-LPAR
> means
> per-thread or per-core, depending on 1LPAR mode.
>
> Signed-off-by: Nicholas Piggin
> ---
> target/ppc/spr_common.h |
Reviewed-by: Glenn Miles
Thanks,
Glenn
On Tue, 2024-05-21 at 11:30 +1000, Nicholas Piggin wrote:
> msgsnd has a broadcast mode that sends hypervisor doorbells to all
> threads belonging to the same core as the target. A "subcore" mode
> sends to all or one thread depending on 1LPAR mode.
>
> S
Hi Chalapathi,
I can't say I have a great understanding of this IBM SPI controller,
but I did find some places for improvement, mostly dealing with the use
of "magic numbers" throughout the code. Please see comments below.
Thanks,
Glenn
On Mon, 2024-06-17 at 11:54 -0500, Chalapathi V wrote:
>
On Mon, 2023-10-09 at 23:06 +0200, Cédric Le Goater wrote:
> Hello Glenn,
>
> On 10/5/23 23:10, Glenn Miles wrote:
> > Testing of the pca9552 device on the powernv platform
> > showed that the reset method was not being called when
> > an instance of the device was realized. This was causing
> >
On Mon, 2023-10-09 at 22:42 +0200, Cédric Le Goater wrote:
> Hello Glenn,
>
> On 10/9/23 20:05, Glenn Miles wrote:
> > From: Cédric Le Goater
> >
> > Not supported :
> >
> > . 10 bit addresses
> > . multimaster
> > . slave
> >
> > Signed-off-by: Cédric Le Goater
> > Signed-off-by: Glenn
On Tue, 2023-10-10 at 21:58 +0200, Cédric Le Goater wrote:
> On 10/10/23 21:52, Glenn Miles wrote:
> > Testing of the pca9552 device on the powernv platform
> > showed that the reset method was not being called when
> > an instance of the device was realized. This was causing
> > the INPUT0/INPUT1
On Tue, 2023-10-10 at 21:31 +0100, Mark Cave-Ayland wrote:
> On 10/10/2023 20:52, Glenn Miles wrote:
>
> > Testing of the pca9552 device on the powernv platform
> > showed that the reset method was not being called when
> > an instance of the device was realized. This was causing
> > the INPUT0/I
On Wed, 2023-10-11 at 19:05 +0200, Cédric Le Goater wrote:
> On 10/5/23 22:41, Glenn Miles wrote:
> > Allow external devices to drive pca9552 input pins by adding
> > input GPIO's to the model. This allows a device to connect
> > its output GPIO's to the pca9552 input GPIO's.
> >
> > In order for
On Wed, 2023-10-11 at 16:27 +0200, Cédric Le Goater wrote:
> On 9/27/23 22:32, Glenn Miles wrote:
> > The pca9552 INPUT0 and INPUT1 registers are supposed to
> > hold the logical values of the LED pins. A logical 0
> > should be seen in the INPUT0/1 registers for a pin when
> > its corresponding L
On Tue, 2023-10-10 at 22:14 +0200, Cédric Le Goater wrote:
> On 10/10/23 19:19, Glenn Miles wrote:
> > From: Cédric Le Goater
> >
> > Wires up three I2C controller instances to the powernv9 chip
> > XSCOM address space.
> >
> > Each controller instance is wired up to a single I2C bus of
> > its
On Tue, 2023-10-10 at 22:10 +0200, Cédric Le Goater wrote:
> On 10/10/23 19:19, Glenn Miles wrote:
> > From: Cédric Le Goater
> >
> > The more recent IBM power processors have an embedded I2C
> > controller that is accessible by software via the XSCOM
> > address space.
> >
> > Each instance of
On Tue, 2023-10-10 at 23:02 +1030, Joel Stanley wrote:
> On Fri, 6 Oct 2023 at 07:23, Glenn Miles
> wrote:
> > Allow external devices to drive pca9552 input pins by adding
> > input GPIO's to the model. This allows a device to connect
> > its output GPIO's to the pca9552 input GPIO's.
> >
> > In
On Tue, 2023-10-10 at 22:41 +0200, Cédric Le Goater wrote:
> On 10/10/23 22:35, Miles Glenn wrote:
> > On Tue, 2023-10-10 at 21:31 +0100, Mark Cave-Ayland wrote:
> > > On 10/10/2023 20:52, Glenn Miles wrote:
> > >
> > > > Testing of the pca9552 device on t
On Fri, 2023-10-20 at 11:42 +0200, Philippe Mathieu-Daudé wrote:
> On 20/10/23 04:51, Andrew Jeffery wrote:
> > On Thu, 2023-10-19 at 15:40 -0500, Glenn Miles wrote:
> > > > The pca9552 INPUT0 and INPUT1 registers are supposed to
> > > > hold the logical values of the LED pins. A logical 0
> > > >
On Fri, 2023-10-20 at 15:18 +1030, Andrew Jeffery wrote:
> On Thu, 2023-10-19 at 15:40 -0500, Glenn Miles wrote:
> > Allow external devices to drive pca9552 input pins by adding
> > input GPIO's to the model. This allows a device to connect
> > its output GPIO's to the pca9552 input GPIO's.
> >
>
On Tue, 2023-10-24 at 10:04 +1030, Andrew Jeffery wrote:
> On Fri, 2023-10-20 at 11:32 -0500, Miles Glenn wrote:
> > On Fri, 2023-10-20 at 11:42 +0200, Philippe Mathieu-Daudé wrote:
> > > On 20/10/23 04:51, Andrew Jeffery wrote:
> > > > On Thu, 2023-10-19 at
On Tue, 2023-10-24 at 10:13 +1030, Andrew Jeffery wrote:
> On Fri, 2023-10-20 at 13:23 -0500, Glenn Miles wrote:
> > The pca9552 code was updating output GPIO states whenever
> > the pin state was updated even if the state did not change.
> > This commit adds a check so that we only update the GPIO
On Tue, 2023-10-24 at 10:15 +1030, Andrew Jeffery wrote:
> On Fri, 2023-10-20 at 13:23 -0500, Glenn Miles wrote:
> > The pca9552 INPUT0 and INPUT1 registers are supposed to
> > hold the logical values of the LED pins. A logical 0
> > should be seen in the INPUT0/1 registers for a pin when
> > its
On Tue, 2023-10-24 at 07:47 +0200, Cédric Le Goater wrote:
> Hello Glenn,
>
> On 10/23/23 18:52, Glenn Miles wrote:
> > Power9 is supposed to have 4 PIB-connected I2C engines with the
> > following number of ports on each engine:
> >
> > 0: 2
> > 1: 13
> > 2: 2
> > 3: 2
> >
>
On Tue, 2023-10-24 at 18:46 +0100, Peter Maydell wrote:
> On Tue, 24 Oct 2023 at 18:40, Glenn Miles
> wrote:
> > Testing of the LED state showed that when the LED polarity was
> > set to GPIO_POLARITY_ACTIVE_LOW and a low logic value was set on
> > the input GPIO of the LED, the LED was being turn
On Fri, 2023-11-17 at 17:04 +0100, Cédric Le Goater wrote:
> > Well, I was hoping to sweep the pca9554 model under the PowerNV
> > maintainership (like pca9552 is under the BMC aspeed
> > maintainership).
> > I did update the PowerNV list to include it, but perhaps that was
> > presumptuous of me.
On Tue, 2023-11-21 at 08:29 +0100, Cédric Le Goater wrote:
> On 11/21/23 02:33, Nicholas Piggin wrote:
> > On Tue Nov 21, 2023 at 9:51 AM AEST, Glenn Miles wrote:
> > > Create a new powernv machine type, powernv10-rainier, that
> > > will contain rainier-specific devices.
> >
> > Is the plan to ha
On Tue, 2023-11-21 at 07:46 +0100, Cédric Le Goater wrote:
> On 11/21/23 00:51, Glenn Miles wrote:
> > Create a new powernv machine type, powernv10-rainier, that
> > will contain rainier-specific devices.
> >
> > Signed-off-by: Glenn Miles
> > ---
> > hw/ppc/pnv.c | 29 +
On Tue, 2023-11-21 at 19:26 +0100, Cédric Le Goater wrote:
> On 11/21/23 17:36, Miles Glenn wrote:
> > On Tue, 2023-11-21 at 08:29 +0100, Cédric Le Goater wrote:
> > > On 11/21/23 02:33, Nicholas Piggin wrote:
> > > > On Tue Nov 21, 2023 at 9:51 AM AEST, Glenn Miles
On Tue, 2023-11-21 at 19:36 +0100, Cédric Le Goater wrote:
> On 11/21/23 00:51, Glenn Miles wrote:
> > For power10-rainier, a pca9552 device is used for PCIe slot hotplug
> > power control by the Power Hypervisor code. The code expects that
> > some time after it enables power to a PCIe slot by as
On Wed, 2023-11-22 at 09:55 +0100, Cédric Le Goater wrote:
> On 11/21/23 20:09, Glenn Miles wrote:
> > Specs are available here:
> >
> > https://www.nxp.com/docs/en/data-sheet/PCA9554_9554A.pdf
> >
> > This is a simple model supporting the basic registers for GPIO
> > mode. The device also
On Wed, 2023-10-18 at 10:59 -0500, Miles Glenn wrote:
> On Thu, 2023-10-19 at 01:06 +1000, Nicholas Piggin wrote:
> > On Tue Sep 26, 2023 at 3:43 AM AEST, Glenn Miles wrote:
> > > This is a series of patches for adding support for the Branch
> > > History
> >
On Fri, 2023-10-13 at 09:04 +0200, Cédric Le Goater wrote:
> On 10/12/23 22:08, Glenn Miles wrote:
> > From: Cédric Le Goater
> >
> > The more recent IBM power processors have an embedded I2C
> > controller that is accessible by software via the XSCOM
> > address space.
> >
> > Each instance of
On Fri, 2023-10-13 at 09:06 +0200, Cédric Le Goater wrote:
> On 10/12/23 22:08, Glenn Miles wrote:
> > From: Cédric Le Goater
> >
> > Wires up three I2C controller instances to the powernv9 chip
> > XSCOM address space.
> >
> > Each controller instance is wired up to a single I2C bus of
> > its
On Fri, 2023-10-13 at 10:58 +0200, Philippe Mathieu-Daudé wrote:
> Hi Glenn, Cédric,
>
> On 12/10/23 22:08, Glenn Miles wrote:
> > From: Cédric Le Goater
> >
> > The more recent IBM power processors have an embedded I2C
> > controller that is accessible by software via the XSCOM
> > address spac
On Tue, 2023-10-17 at 09:01 +0200, Cédric Le Goater wrote:
> On 10/17/23 00:20, Glenn Miles wrote:
> > Upstreams the PowerNV I2C controller model originally
> > authored by Cédric Le Goater with minor changes by
> > myself to split the actual addition of the model from
> > wiring it up to a power p
On Thu, 2023-10-19 at 01:06 +1000, Nicholas Piggin wrote:
> On Tue Sep 26, 2023 at 3:43 AM AEST, Glenn Miles wrote:
> > This is a series of patches for adding support for the Branch
> > History
> > Rolling Buffer (BHRB) facility. This was added to the Power ISA
> > starting with version 2.07. Cha
On Thu, 2023-11-09 at 18:15 +0100, Cédric Le Goater wrote:
> Coverity warns that "i2c_bus_busy(i2c->busses[i]) << i" might
> overflow
> because the expression is evaluated using 32-bit arithmetic and then
> used in a context expecting a uint64_t.
>
> While we are at it, introduce a PNV_I2C_MAX_BUS
On Fri, 2023-11-10 at 11:22 -0600, Glenn Miles wrote:
> This series of patches includes support, tests and fixes for
> adding PCA9552 and PCA9554 I2C devices to the powernv10 chip.
>
> The PCA9552 device is used for PCIe slot hotplug power control
> and monitoring, while the PCA9554 device is used
On Mon, 2023-11-13 at 10:05 +0100, Cédric Le Goater wrote:
> On 11/10/23 20:49, Glenn Miles wrote:
> > The Power Hypervisor code expects to see a pca9552 device connected
> > to the 3rd PNV I2C engine on port 1 at I2C address 0x63 (or left-
> > justified address of 0xC6). This is used by hyperviso
On Mon, 2023-11-13 at 10:10 +0100, Cédric Le Goater wrote:
> On 11/10/23 20:49, Glenn Miles wrote:
> > The PNV I2C Controller was clearing the status register
> > after a reset without repopulating the "upper threshold
> > for I2C ports", "Command Complete" and the SCL/SDA input
> > level fields.
>
On Mon, 2023-11-13 at 10:07 +0100, Cédric Le Goater wrote:
> On 11/10/23 20:49, Glenn Miles wrote:
> > The PNV I2C engines for power9 and power10 were being assigned a
> > base
> > XSCOM address that was off by one I2C engine's address range such
> > that engine 0 had engine 1's address and so on.
On Tue, 2023-11-14 at 18:55 +0100, Cédric Le Goater wrote:
> On 11/14/23 16:26, Miles Glenn wrote:
> > On Mon, 2023-11-13 at 10:10 +0100, Cédric Le Goater wrote:
> > > On 11/10/23 20:49, Glenn Miles wrote:
> > > > The PNV I2C Controller was clearing the status
On Wed, 2023-11-15 at 08:28 +0100, Cédric Le Goater wrote:
> On 11/14/23 20:56, Glenn Miles wrote:
> > The Power Hypervisor code expects to see a pca9552 device connected
> > to the 3rd PNV I2C engine on port 1 at I2C address 0x63 (or left-
> > justified address of 0xC6). This is used by hyperviso
On Wed, 2023-11-15 at 23:34 +0100, Cédric Le Goater wrote:
> On 11/15/23 17:37, Miles Glenn wrote:
> > On Wed, 2023-11-15 at 08:28 +0100, Cédric Le Goater wrote:
> > > On 11/14/23 20:56, Glenn Miles wrote:
> > > > The Power Hypervisor code expects to see a pc
On Fri, 2023-10-27 at 07:05 +0200, Philippe Mathieu-Daudé wrote:
> On 25/10/23 08:56, Cédric Le Goater wrote:
> > On 10/24/23 23:29, Glenn Miles wrote:
> > > Power9 is supposed to have 4 PIB-connected I2C engines with the
> > > following number of ports on each engine:
> > >
> > > 0: 2
> > >
Reviewed-by: Glenn Miles
On Thu, 2024-11-07 at 19:54 +, Titus Rwantare wrote:
> Makes it more explicit that 16 bit values are being used
>
> Signed-off-by: Titus Rwantare
> ---
> include/qemu/bitops.h | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/inc
Reviewed-by: Glenn Miles
On Mon, 2024-11-25 at 23:20 +1000, Nicholas Piggin wrote:
> From: Glenn Miles
>
> The THREAD_SIBLING_FOREACH macro wasn't excluding threads from
> other chips. Add chip_index field to the thread state and add
> a check for the new field in the macro.
>
> Fixes: b769d4c
Reviewed-by: Glenn Miles
On Mon, 2024-11-25 at 23:20 +1000, Nicholas Piggin wrote:
> The ppc (pnv and spapr) NMI injection code does not go through the
> asynchronous interrupt path and set a bit in env->pending_interrupts
> and raise an interrupt request that the cpu_exec() loop can see.
> Ins
Reviewed-by: Glenn Miles
On Mon, 2024-11-25 at 23:20 +1000, Nicholas Piggin wrote:
> By convention, xscom regions get a xscom- prefix.
>
> Fixes: 1adf24708bf7 ("hw/ppc: Add pnv nest pervasive common chiplet
> model")
> Signed-off-by: Nicholas Piggin
> ---
> hw/ppc/pnv_nest_pervasive.c | 2 +-
>
Reviewed-by: Glenn Miles
On Mon, 2024-11-25 at 23:20 +1000, Nicholas Piggin wrote:
> powernv CPUs have a set of control registers that can stop, start,
> and
> do other things to control a thread's execution.
>
> Using this interface to stop a thread puts it into a particular state
> that can be
Reviewed-by: Glenn Miles
On Fri, 2024-12-13 at 13:07 -0600, Richard Henderson wrote:
> Signed-off-by: Richard Henderson
> ---
> hw/gpio/imx_gpio.c | 2 +-
> hw/gpio/npcm7xx_gpio.c | 2 +-
> hw/gpio/omap_gpio.c | 2 +-
> hw/gpio/pca9552.c| 2 +-
> hw/gpio/pca9554.c|
On Thu, 2025-03-20 at 16:09 -0400, Stefan Hajnoczi wrote:
> On Thu, Mar 20, 2025 at 12:34 PM Miles Glenn wrote:
> > Hello,
> >
> > I am attempting to simulate a system with multiple CPU
> > architectures. To do this I am starting a unique QEMU process for each
&
Hello,
I am attempting to simulate a system with multiple CPU
architectures. To do this I am starting a unique QEMU process for each
CPU architecture that is needed. I'm also developing some QEMU code
that aids in transporting MMIO transactions across the process
boundaries using sockets.
The de
On Mon, 2025-03-24 at 14:35 -0400, Stefan Hajnoczi wrote:
> On Fri, Mar 21, 2025 at 11:17 AM Miles Glenn wrote:
> > On Thu, 2025-03-20 at 16:09 -0400, Stefan Hajnoczi wrote:
> > > On Thu, Mar 20, 2025 at 12:34 PM Miles Glenn wrote:
> > > > Hello,
> > > &
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> The relationship between an interrupt signaled in the TIMA and the QEMU
> irq line to the processor to be 1:1, so they should be raised and
> lowered together and "just in case" lowering should be avoided (it cou
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> When CPPR priority is decreased, pending interrupts do not need to be
> re-checked if one is already presented because by definition that will
> be the highest priority.
>
> This prevents a presented group inter
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> Implement the phys (aka hard) VP push. PowerVM uses this operation.
>
> Signed-off-by: Nicholas Piggin
> ---
> hw/intc/xive.c | 2 ++
> hw/intc/xive2.c| 11 +++
> include/hw/ppc/xive2.
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> Further split xive_tctx_pipr_update() by splitting out a new function
> that is used to re-compute the PIPR from IPB. This is generally only
> used with XIVE1, because group interrputs require more logic.
>
> Si
On Fri, 2025-05-16 at 10:05 +1000, Nicholas Piggin wrote:
> On Mon May 12, 2025 at 1:10 PM AEST, Nicholas Piggin wrote:
> > From: Glenn Miles
> >
> > Add support for XIVE ESB Interrupt Escalation.
> >
> > Suggested-by: Michael Kowal
> > [This change was taken from a patch provided by Michael Ko
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> Typo, IBP should be IPB.
>
> Signed-off-by: Nicholas Piggin
> ---
> hw/intc/trace-events | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/hw/intc/trace-events b/hw/intc/trace-eve
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> Report access size in XIVE TM operation error logs.
>
> Signed-off-by: Nicholas Piggin
> ---
> hw/intc/xive.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/hw/intc/xive.c b/
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> From: Michael Kowal
>
> In a multi chip environment there will be remote/forwarded VSDs. The check
> to find a matching INT controller (XIVE) of the remote block number was
> checking the INTs chip number. Bl
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> From: Michael Kowal
>
> When the END Event Queue wraps the END EQ Generation bit is flipped and the
> Generation Flipped bit is set to one. On a END cache Watch read operation,
> the Generation Flipped bit nee
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> Group interrupts should not be taken from the backlog and presented
> if they are precluded by CPPR.
>
> Fixes: 855434b3b8 ("ppc/xive2: Process group backlog when pushing an OS
> context")
> Signed-off-by: Nich
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> Test that the NSR exception bit field is equal to the pool ring value,
> rather than any common bits set, which is more correct (although there
> is no practical bug because the LSI NSR type is not implemented an
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> Pushing a context and loading IPB from NVP is defined to merge ('or')
> that IPB into the TIMA IPB register. PIPR should therefore be calculated
> based on the final IPB value, not just the NVP value.
>
> Fixes:
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> The group interrupt delivery flow selects the group backlog scan if
> LSMFB < IPB, but that scan may find an interrupt with a priority >=
> IPB. In that case, the VP-direct interrupt should be chosen. This
> extends to selecting the lowest
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> From: Glenn Miles
>
> The current xive algorithm for finding a matching group vCPU
> target always uses the first vCPU found. And, since it always
> starts the search with thread 0 of a core, thread 0 is almos
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> Have xive_tctx_accept clear NSR in one shot rather than masking out bits
> as they are tested, which makes it clear it's reset to 0, and does not
> have a partial NSR value in the register.
>
> Signed-off-by: Ni
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> This improves the implementation of pulling pool and phys contexts in
> XIVE1, by following closer the OS pulling code.
>
> In particular, the old ring data is returned rather than the modified,
> and irq signal
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> From: Michael Kowal
>
> Writes to the Flush Control registers were logged as invalid
> when they are allowed. Clearing the unsupported want_cache_disable
> feature is supported, so don't log an error in that ca
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> From: Michael Kowal
>
> This can make it easier to see what the target system is trying to
> do.
>
> [npiggin: split from larger patch]
> Signed-off-by: Michael Kowal
> ---
> hw/intc/pnv_xive2.c | 24 +++
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> Rather than functions to return masks to test NSR bits, have functions
> to test those bits directly. This should be no functional change, it
> just makes the code more readable.
>
> Signed-off-by: Nicholas Pigg
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> If CPPR is lowered to preclude the pending interrupt, NSR should be
> cleared and the qemu_irq should be lowered. This avoids some cases
> of supurious interrupts.
>
> Signed-off-by: Nicholas Piggin
> ---
> hw
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> Have the match_nvt method only perform a TCTX match but don't present
> the interrupt, the caller presents. This has no functional change, but
> allows for more complicated presentation logic after matching.
>
>
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> A group interrupt that gets preempted by a higher priority interrupt
> delivery must be redistributed otherwise it would get lost.
>
> Signed-off-by: Nicholas Piggin
> ---
> hw/intc/xive2.c | 14 --
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> xive_tctx_pipr_update() is used for multiple things. In an effort
> to make things simpler and less overloaded, split out the function
> that is used to present a new interrupt to the tctx.
>
> Signed-off-by: Ni
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> xive_tctx_pipr_present() as implemented with xive_tctx_pipr_update()
> causes VP-directed (group==0) interrupt to be presented in PIPR and NSR
> despite being a lower priority than the currently presented group
>
Reviewed-by: Glenn Miles
On Mon, 2025-05-12 at 13:10 +1000, Nicholas Piggin wrote:
> The tctx "signaling" registers (PIPR, CPPR, NSR) raise an interrupt on
> the target CPU thread. The POOL and PHYS rings both raise hypervisor
> interrupts, so they both share one set of signaling registers in the
1 - 100 of 118 matches
Mail list logo