Re: [PULL 19/35] ppc/pnv: Add models for POWER9 PHB4 PCIe Host bridge

On Thu, 2022-03-31 at 18:51 +0100, Peter Maydell wrote: > > Hi; Coverity has just spotted an error in this old change > (CID 1487176): Oh my this is old ... I don't work for IBM anymore but I found the relevant doc here:

Re: [PATCH 1/2] hw/misc/bcm2835_property: Fix framebuffer with recent RPi kernels

On Mon, 2021-10-18 at 11:47 +0200, Philippe Mathieu-Daudé wrote: > > > I've just checked the rpi-5.15.y branch and it's the same. > > Indeed. I stopped testing recent kernels because they use too many > features QEMU don't implement. > > Our model should generate the DTB blob of devices

Re: [PATCH 1/2] hw/misc/bcm2835_property: Fix framebuffer with recent RPi kernels

On Sun, 2021-10-17 at 17:08 +0200, Philippe Mathieu-Daudé wrote: > Hi Benjamin, > > On 10/17/21 09:48, Benjamin Herrenschmidt wrote: > > The framebuffer driver fails to initialize with recent Raspberry Pi > > kernels, such as the ones shipped in the current RaspiOS ima

[PATCH 2/2] hw/misc/bcm2835_property: Add dummy Get/Set GPIO virt buf messages

Without these the RaspiOS kernel tries to ioremap some bogus address and dumps a backtrace in the console at boot. These work around it. The virt-gpio driver still fails to initialize but much more cleanly Signed-off-by: Benjamin Herrenschmidt --- hw/misc/bcm2835_property.c | 7 +++ 1 file

[PATCH 1/2] hw/misc/bcm2835_property: Fix framebuffer with recent RPi kernels

fails is broken. So implement the call and claim we have exactly one display Signed-off-by: Benjamin Herrenschmidt --- hw/misc/bcm2835_property.c | 4 1 file changed, 4 insertions(+) diff --git a/hw/misc/bcm2835_property.c b/hw/misc/bcm2835_property.c index 73941bdae9..b958fa6a5c 100644

Re: [PATCH for-6.1? v2 7/9] hw/pci-hist/pnv_phb4: Fix typo in pnv_phb4_ioda_write

et-variable] > > > > It's pretty clear that we meant to write back 'v' after > > all that computation and not 'val'. > > > > Fixes: 4f9924c4d4c ("ppc/pnv: Add models for POWER9 PHB4 PCIe Host > bridge") Acked-by: Benjamin Herrenschmidt > > > A

Re: [EXTERNAL] [PATCH 2/2] target/ppc: Fix ISA v3.0 (POWER9) slbia implementation

On Wed, 2020-03-18 at 18:08 +0100, Cédric Le Goater wrote: > On 3/18/20 5:41 AM, Nicholas Piggin wrote: > > Linux using the hash MMU ("disable_radix" command line) on a POWER9 > > machine quickly hits translation bugs due to using v3.0 slbia > > features that are not implemented in TCG. Add them.

Re: Semihosting, arm, riscv, ppc and common code

On Wed, 2020-01-15 at 12:01 +, Alex Bennée wrote: > > > There seem to be some linux-user stuff in there, I'm mostly considering > > whatever ARM does today but we can certainly extend later. > > Depends on if it is to be used. AFAIK the main users of arm linux user > are compiler test cases

Re: Semihosting, arm, riscv, ppc and common code

On Thu, 2020-01-16 at 00:02 +0200, Liviu Ionescu wrote: > > ... they did have the opportunity to do better, and did not. > > I don't know why you present Arm semihosting as a disaster. It is not > perfect, but it is functional, and common unit tests use only a small > subset of the calls. > >

Re: Semihosting, arm, riscv, ppc and common code

On Wed, 2020-01-15 at 13:32 +, Peter Maydell wrote: > On Wed, 15 Jan 2020 at 01:17, Benjamin Herrenschmidt > wrote: > > On Tue, 2020-01-14 at 09:59 +, Peter Maydell wrote: > > > Note that semihosting is not a "here's a handy QEMU feature" > > >

Re: Semihosting, arm, riscv, ppc and common code

On Tue, 2020-01-14 at 09:59 +, Peter Maydell wrote: > Note that semihosting is not a "here's a handy QEMU feature" > thing. It's an architecture-specific API and ABI, which should > be defined somewhere in a standard external to QEMU. There is no such standard for powerpc today that I know

Re: Semihosting, arm, riscv, ppc and common code

On Tue, 2020-01-14 at 09:51 +, Alex Bennée wrote: > > Well, one of the LCA talks wasn't that interesting so I started > > doing > > it and am almost done :-) > > > > I'll look at doing something for arm, riscv and ppc and send > > patches > > once I get it working. > > Cool. Are you

Re: Semihosting, arm, riscv, ppc and common code

On Tue, 2020-01-14 at 09:32 +0200, Liviu Ionescu wrote: > > On 14 Jan 2020, at 08:25, Benjamin Herrenschmidt < > > b...@kernel.crashing.org> wrote: > > > > I noticed that the bulk of arm-semi.c (or riscv-semi.c) is > > trivially > > made completely gener

Semihosting, arm, riscv, ppc and common code

Hi Folks ! So I started "porting" over (read: copying) the arm semihosting code to ppc to mimmic what Keith did for risv (mostly for picolibc support). I noticed that the bulk of arm-semi.c (or riscv-semi.c) is trivially made completely generic by doing a couple of changes: - Make most

Re: [Qemu-devel] [PATCH 5/6] memory_ldst: Add atomic ops for PTE updates

On Mon, 2019-04-15 at 13:38 +1000, David Gibson wrote: > On Thu, Apr 11, 2019 at 10:00:03AM +0200, Cédric Le Goater wrote: > > From: Benjamin Herrenschmidt > > > > On some architectures, PTE updates for dirty and changed bits need > > to be performed ato

Re: [Qemu-devel] [PATCH 07/19] target/ppc: Make special ORs match x86 pause and don't generate on mttcg

On Tue, 2019-02-12 at 16:59 +1100, David Gibson wrote: > On Mon, Jan 28, 2019 at 10:46:13AM +0100, Cédric Le Goater wrote: > > From: Benjamin Herrenschmidt > > > > There's no point in going out of translation on an SMT OR with > > mttcg since the backend won't do anyt

Re: [Qemu-devel] [PATCH 08/19] target/ppc: Fix nip on power management instructions

On Tue, 2019-02-12 at 17:02 +1100, David Gibson wrote: > On Mon, Jan 28, 2019 at 10:46:14AM +0100, Cédric Le Goater wrote: > > From: Benjamin Herrenschmidt > > > > Those instructions currently raise an exception from within > > the helper. This tends to result in a bog

Re: [Qemu-devel] [PATCH 1/3] memory_ldst: Add atomic ops for PTE updates

On Thu, 2018-12-13 at 21:01 -0600, Richard Henderson wrote: > On 12/13/18 5:58 PM, Benjamin Herrenschmidt wrote: > > +#ifdef CONFIG_ATOMIC64 > > +/* This is meant to be used for atomic PTE updates under MT-TCG */ > > +uint32_t glue(address_space_cmpxchgq_notdir

Re: [Qemu-devel] [PATCH 2/3] i386: Atomically update PTEs with mttcg

Note to RiscV folks: You may want to adapt your code to do the same as this, esp. afaik, what you do today is endian-broken if host and guest endian are different. Cheers, Ben. On Fri, 2018-12-14 at 10:58 +1100, Benjamin Herrenschmidt wrote: > Afaik, this isn't well documented (at le

Re: [Qemu-devel] [PATCH 3/3] ppc: Fix radix RC updates

On Fri, 2018-12-14 at 10:58 +1100, Benjamin Herrenschmidt wrote: > They should be atomic for MTTCG. Note: a real POWER9 core doesn't actually > implement atomic PTE updates, it always fault for SW to handle it. Only > the nest MMU (used by some accelerator devices and GPUs) implements &

[Qemu-devel] [PATCH 3/3] ppc: Fix radix RC updates

it, and doing so in TCG is faster than letting the guest do it. Signed-off-by: Benjamin Herrenschmidt --- target/ppc/cpu.h | 1 + target/ppc/mmu-radix64.c | 70 +--- 2 files changed, 59 insertions(+), 12 deletions(-) diff --git a/target/ppc/cpu.h b/target/ppc

[Qemu-devel] [PATCH 1/3] memory_ldst: Add atomic ops for PTE updates

On some architectures, PTE updates for dirty and changed bits need to be performed atomically. This adds a couple of address_space_cmpxchg* helpers for that purpose. Signed-off-by: Benjamin Herrenschmidt --- include/exec/memory_ldst.inc.h | 6 +++ memory_ldst.inc.c | 78

[Qemu-devel] [PATCH 2/3] i386: Atomically update PTEs with mttcg

with 0 and assume the value read has "final" stable dirty and accessed bits (the TLB invalidation is deferred). Signed-off-by: Benjamin Herrenschmidt --- target/i386/excp_helper.c | 104 +- 1 file changed, 80 insertions(+), 24 deletions(-) diff --gi

Re: [Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

On Thu, 2018-11-29 at 11:04 -0800, Richard Henderson wrote: > > While I know the existing code just updates the low 32-bits, I'd rather update > the whole entry, and make use of the old value returned from the cmpxchg. So I had to put this on the back burner for a bit, but I'm back to it now.

Re: [Qemu-devel] [PATCH v7 17/19] spapr: Add a pseries-4.0 machine type

On Sun, 2018-12-09 at 20:46 +0100, Cédric Le Goater wrote: > Signed-off-by: Cédric Le Goater > --- If you're going to do that, can we include large decrementer in there too ? (patches from Suraj in my tree but they night need a bit of massaging). > include/hw/compat.h | 3 +++ >

Re: [Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

On Thu, 2018-11-29 at 16:12 -0800, Richard Henderson wrote: > > You mean translating once for the load and for the udpate ? Do you > > expect that translation to have such a significant cost considering > > that all it needs should be in L1 at that point ? > > I guess if the update is rare-ish,

Re: [Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

On Thu, 2018-11-29 at 16:12 -0800, Richard Henderson wrote: > On 11/29/18 2:54 PM, Benjamin Herrenschmidt wrote: > > > pdpe_addr = (pml4e & PG_ADDRESS_MASK) + > > > (((gphys >> 30) & 0x1ff) << 3); > > >

Re: [Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

On Thu, 2018-11-29 at 11:04 -0800, Richard Henderson wrote: > On 11/28/18 3:15 PM, Benjamin Herrenschmidt wrote: > > +static inline uint64_t update_entry(CPUState *cs, target_ulong addr, > > +uint64_t orig_entry, uint32_t bits) > > +{ > &

Re: [Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

On Thu, 2018-11-29 at 10:26 +0100, Paolo Bonzini wrote: > On 29/11/18 00:15, Benjamin Herrenschmidt wrote: > > Afaik, this isn't well documented (at least it wasn't when I last looked) > > but OSes such as Linux rely on this behaviour: > > > > The HW updates to the

Re: [Qemu-devel] [PATCH v5 08/36] ppc/xive: introduce a simplified XIVE presenter

On Thu, 2018-11-29 at 11:47 +1100, David Gibson wrote: > > 1) read/write accessors which take a word number > > 2) A "get" accessor which copies the whole structure, but "write" > accessor which takes a word number. The asymmetry is a bit ugly, but > it's the non-atomic writeback of the whole

[Qemu-devel] [RFC/PATCH] i386: Atomically update PTEs with mttcg

with 0 and assume the value read has "final" stable dirty and accessed bits (the TLB invalidation is deferred). Signed-off-by: Benjamin Herrenschmidt --- This is lightly tested at this point, mostly to gather comments on the approach. I noticed that RiscV is attempting to do somethi

Re: [Qemu-devel] [PATCH v5 08/36] ppc/xive: introduce a simplified XIVE presenter

On Wed, 2018-11-28 at 10:49 +1100, David Gibson wrote: > On Fri, Nov 16, 2018 at 11:57:01AM +0100, Cédric Le Goater wrote: > > The last sub-engine of the XIVE architecture is the Interrupt > > Virtualization Presentation Engine (IVPE). On HW, they share elements, > > the Power Bus interface (CQ),

Re: [Qemu-devel] [PATCH v5 09/36] ppc/xive: notify the CPU when the interrupt priority is more privileged

On Wed, 2018-11-28 at 11:13 +1100, David Gibson wrote: > Don't you need a cast to avoid (nsr << 8) being a shift-wider-than-size? Shouldn't be a problem as long as it fits in an int, no ? Cheers, Ben.

Re: [Qemu-devel] [PATCH v5 04/36] ppc/xive: introduce the XiveRouter model

On Thu, 2018-11-22 at 15:44 +1100, David Gibson wrote: > > Sorry, didn't think of this in my first reply. > > 1) Does the hardware ever actually write back to the EAS? I know it > does for the END, but it's not clear why it would need to for the > EAS. If not, we don't need the setter. Nope,

Re: [Qemu-devel] [PATCH v5 05/36] ppc/xive: introduce the XIVE Event Notification Descriptors

On Thu, 2018-11-22 at 15:41 +1100, David Gibson wrote: > > > +void xive_end_reset(XiveEND *end) > > +{ > > +memset(end, 0, sizeof(*end)); > > + > > +/* switch off the escalation and notification ESBs */ > > +end->w1 = END_W1_ESe_Q | END_W1_ESn_Q; > > It's not obvious to me what

Re: [Qemu-devel] [PATCH v2 1/2] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Fri, 2018-07-27 at 15:32 +1000, David Gibson wrote: > > > > What is this pci bridge representing? I know PCI-e PHBs typically > > > have a pseudo P2P bridge right under them, but isn't that represnted > > > by the root complex above? > > > > This is the legacy pci bridge under the pcie bus.

Re: [Qemu-devel] [PATCH v2 1/2] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Fri, 2018-07-27 at 10:25 +0200, Cédric Le Goater wrote: > Each PHB creates a pci-bridge device and the PCI bus that comes with it. > It makes things easier to define PCI devices. > > It is still quite complex ... Here is a sample : > > qemu-system-ppc64 -m 2G -machine powernv \ > -cpu

Re: [Qemu-devel] [PATCH v2 1/2] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Fri, 2018-07-27 at 09:16 +0200, Cédric Le Goater wrote: > > I'd have to remember how PQ works on P8 ... my gut feeling is that we > > should resend if P=1 but I'm no 100% certain. > > This is not exactly what the code does. To force a resend, it ignores > P but if Q=1, it bails out without

Re: [Qemu-devel] [PATCH v2 1/2] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Thu, 2018-07-26 at 11:03 +0200, Cédric Le Goater wrote: > Ben, > > I have found out recently that the QEMU PowerNV could hang while accessing > the disk. > > The issue seems to be the phb3_msi_try_send() routine when called from > the resend() handler. The 'P' is ignored in that case but

Re: [Qemu-devel] [PATCH v2 1/2] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Tue, 2018-07-24 at 12:14 +1000, David Gibson wrote: > > I don't know, is there much shared logic ? And the shared bits are the > > subclassing, that's handled that way... > > > > This is really a different piece of HW, a separate ICS implementation, > > that has its own quirks, is configured

Re: [Qemu-devel] [PATCH v2 1/2] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Mon, 2018-07-23 at 14:16 +1000, David Gibson wrote: > > > > Now, this is an ICS subclass, so why shouldn't it directly poke at the > > target ICP ? > > That's ok in theory, but causing it to expose the icp interface to a > new module isn't great. > > > It's an alternate to the normal ICS

Re: [Qemu-devel] [PATCH v2 1/2] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Wed, 2018-07-18 at 16:12 +1000, David Gibson wrote: > On Thu, Jun 28, 2018 at 10:36:32AM +0200, Cédric Le Goater wrote: > > From: Benjamin Herrenschmidt Can you trim your replies ? It's really hard to find your comments in such a long patch... > > diff --git a/include/hw/ppc/x

Re: [Qemu-devel] [PATCH] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Thu, 2018-06-28 at 10:00 +0200, Andrea Bolognani wrote: > On Thu, 2018-06-28 at 13:59 +1000, David Gibson wrote: > > On Wed, Jun 27, 2018 at 12:22:31PM +0200, Andrea Bolognani wrote: > > > On Tue, 2018-06-26 at 19:02 +0200, Cédric Le Goater wrote: > > > > I didn't follow that discussion but

Re: [Qemu-devel] [PATCH] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Wed, 2018-06-27 at 09:46 +0200, Cédric Le Goater wrote: > So the "IBM PHB3 PCIE Root Port" is already user createable. > > I can take a look at user createable PHB3s. I think this is OK from a model > perspective. The object is rather standalone, it needs the machine for > the XICS fabric and

Re: [Qemu-devel] [PATCH] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Wed, 2018-06-27 at 03:35 +0300, Michael S. Tsirkin wrote: > > > + > > +/* Extract field fname from val */ > > +#define GETFIELD(fname, val)\ > > +(((val) & fname##_MASK) >> fname##_LSH) > > + > > +/* Set field fname of oval to fval > > + * NOTE: oval isn't modified,

Re: [Qemu-devel] [PATCH] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge

On Tue, 2018-06-26 at 17:57 +0200, Andrea Bolognani wrote: > On Tue, 2018-06-26 at 15:59 +0200, Cédric Le Goater wrote: > > This is a model of the PCIe host bridge found on Power8 chips, > > including PowerBus logic interface, IOMMU support, PCIe root complex, > > XICS MSI and LSI interrupt

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 02/19] spapr: introduce a skeleton for the XIVE interrupt controller

On Mon, 2018-02-12 at 13:20 +0100, Andrea Bolognani wrote: > On Mon, 2018-02-12 at 13:02 +1100, Alexey Kardashevskiy wrote: > > On 12/02/18 09:55, Benjamin Herrenschmidt wrote: > > > Well, we have a problem then. It looks like Qemu broken migration is > > > fundament

Re: [Qemu-devel] [PATCH v2 02/19] spapr: introduce a skeleton for the XIVE interrupt controller

On Sun, 2018-02-11 at 19:08 +1100, David Gibson wrote: > On Thu, Jan 18, 2018 at 08:27:52AM +1100, Benjamin Herrenschmidt wrote: > > On Wed, 2018-01-17 at 15:39 +0100, Cédric Le Goater wrote: > > > Migration is a problem. We will need both backend QEMU objects to be > >

Re: [Qemu-devel] [PATCH v2 02/19] spapr: introduce a skeleton for the XIVE interrupt controller

On Thu, 2018-01-18 at 14:27 +0100, Cédric Le Goater wrote: > The source and the target machines should have the same realized > objects. I think this is the simplest solution to keep the migration > framework maintainable. Yeah well, it all boils down to qemu migration being completely brain

Re: [Qemu-devel] [PATCH v2 02/19] spapr: introduce a skeleton for the XIVE interrupt controller

On Wed, 2018-01-17 at 15:39 +0100, Cédric Le Goater wrote: > Migration is a problem. We will need both backend QEMU objects to be > available anyhow if we want to migrate. So we are back to the current > solution creating both QEMU objects but we can try to defer some of the > KVM inits and

Re: [Qemu-devel] [PATCH v2 02/19] spapr: introduce a skeleton for the XIVE interrupt controller

On Wed, 2018-01-17 at 10:18 +0100, Cédric Le Goater wrote: > > > > Also, have we decided how the process of switching between XICS and > > > > XIVE will work vs. CAS ? > > > > > > That's how it is described in the architecture. The current choice is > > > to create both XICS and XIVE objects and

Re: [Qemu-devel] [PATCH v2 02/19] spapr: introduce a skeleton for the XIVE interrupt controller

On Thu, 2017-12-21 at 10:16 +0100, Cédric Le Goater wrote: > On 12/21/2017 01:12 AM, Benjamin Herrenschmidt wrote: > > On Wed, 2017-12-20 at 16:09 +1100, David Gibson wrote: > > > > > > As you've suggested in yourself, I think we might need to more > > > expli

Re: [Qemu-devel] [PATCH v2 02/19] spapr: introduce a skeleton for the XIVE interrupt controller

On Wed, 2017-12-20 at 16:09 +1100, David Gibson wrote: > > As you've suggested in yourself, I think we might need to more > explicitly model the different components of the XIVE system. As part > of that, I think you need to be clearer in this base skeleton about > exactly what component your

Re: [Qemu-devel] [PATCH 0/6] spapr: Add optional capabilities

On Mon, 2017-12-18 at 20:20 +1100, David Gibson wrote: > This series is a first draft to add the notion of optional > capabilities to the "pseries" machine type. A default set of > capabilities is selected based on the machine type version and > selected cpu model, but this can be overridden with

Re: [Qemu-devel] [PATCH v2 03/19] spapr: introduce the XIVE interrupt sources

On Thu, 2017-12-14 at 16:24 +0100, Cédric Le Goater wrote: > The API between the source and the IVRE is extremely simple : > > static void spapr_xive_irq(sPAPRXive *xive, int lisn) > > The IVRE then scans its IVT, finds the EQ, and moves on to the > presenter. In HW it's an MMIO store

Re: [Qemu-devel] [PATCH 19/25] spapr: add hcalls support for the XIVE interrupt mode

On Wed, 2017-12-06 at 20:20 +1100, David Gibson wrote: > On Tue, Dec 05, 2017 at 08:50:26AM -0600, Benjamin Herrenschmidt wrote: > > On Tue, 2017-12-05 at 18:00 +1100, David Gibson wrote: > > > > The CPU revision. But we won't introduce XIVE exploitation mode on > > &

Re: [Qemu-devel] [PATCH 19/25] spapr: add hcalls support for the XIVE interrupt mode

On Tue, 2017-12-05 at 18:00 +1100, David Gibson wrote: > > The CPU revision. But we won't introduce XIVE exploitation mode on > > anything else than DD2.0 which has full XIVE support. Even STORE_EOI > > that we should be adding. > > Hrm. Host CPU? That's a problem - if guest visible

Re: [Qemu-devel] [PATCH 15/25] spapr: notify the CPU when the XIVE interrupt priority is more privileged

On Mon, 2017-12-04 at 12:17 +1100, David Gibson wrote: > On Sat, Dec 02, 2017 at 08:40:58AM -0600, Benjamin Herrenschmidt wrote: > > On Thu, 2017-11-30 at 16:00 +1100, David Gibson wrote: > > > > > > > static uint64_t spapr_xive_icp_accept(sPAPRXiveICP *icp) &g

Re: [Qemu-devel] [PATCH 11/25] spapr: describe the XIVE interrupt source flags

On Sat, 2017-12-02 at 15:38 +0100, Cédric Le Goater wrote: > Hmm, yes. So, the current design for sPAPR handles all sources > under the same XIVE object with a global memory region for all > the ESBs. > > The first RFC had a mechanism to register source objects into > the XIVE main one,

Re: [Qemu-devel] [PATCH 14/25] spapr: push the XIVE EQ data in OS event queue

On Sat, 2017-12-02 at 08:45 -0600, Benjamin Herrenschmidt wrote: > On Fri, 2017-12-01 at 15:10 +1100, David Gibson wrote: > > > > Hm, ok. Guest endian (or at least, not definitively host-endian) data > > in a plain uint32_t makes me uncomfortable. Could we use char data[4]

Re: [Qemu-devel] [PATCH 14/25] spapr: push the XIVE EQ data in OS event queue

On Fri, 2017-12-01 at 15:10 +1100, David Gibson wrote: > > Hm, ok. Guest endian (or at least, not definitively host-endian) data > in a plain uint32_t makes me uncomfortable. Could we use char data[4] > instead, to make it clear it's a byte-ordered buffer, rather than a > number as far as the

Re: [Qemu-devel] [PATCH 13/25] spapr: introduce the XIVE Event Queues

On Sat, 2017-12-02 at 08:39 -0600, Benjamin Herrenschmidt wrote: > The IVEs and EQs are managed by the virtualization controller. The VPs > (aka ENDs) typo. aka NVTs > are managed by the presentation controller. There's a VP per > real and virtual CPU.

Re: [Qemu-devel] [PATCH 15/25] spapr: notify the CPU when the XIVE interrupt priority is more privileged

On Thu, 2017-11-30 at 16:00 +1100, David Gibson wrote: > > > static uint64_t spapr_xive_icp_accept(sPAPRXiveICP *icp) > > { > > -return 0; > > +uint8_t nsr = icp->tima_os[TM_NSR]; > > + > > +qemu_irq_lower(icp->output); > > + > > +if (icp->tima_os[TM_NSR] & TM_QW1_NSR_EO) { > >

Re: [Qemu-devel] [PATCH 13/25] spapr: introduce the XIVE Event Queues

On Thu, 2017-11-30 at 15:38 +1100, David Gibson wrote: > On Thu, Nov 23, 2017 at 02:29:43PM +0100, Cédric Le Goater wrote: > > The Event Queue Descriptor (EQD) table, also known as Event Notification > > Descriptor (END), is one of the internal tables the XIVE interrupt > > controller uses to

Re: [Qemu-devel] [PATCH 10/25] spapr: add MMIO handlers for the XIVE interrupt sources

On Thu, 2017-11-30 at 15:28 +1100, David Gibson wrote: > > How does this work at the hardware level? Presumbly the actual > hardware components don't communicate with the XIVE to request edge or > level. So how does it know? Specific ranges for LSIs? If that we > should probably do the same.

Re: [Qemu-devel] [PATCH 10/25] spapr: add MMIO handlers for the XIVE interrupt sources

On Wed, 2017-11-29 at 17:23 +0100, Cédric Le Goater wrote: > On 11/29/2017 02:56 PM, Cédric Le Goater wrote: > > > > > > +switch (offset) { > > > > > > +case 0: > > > > > > +spapr_xive_source_eoi(xive, lisn); > > > > > > > > > > Hrm. I don't love that you're dealing with clearing

Re: [Qemu-devel] [PATCH 09/25] spapr: introduce handlers for XIVE interrupt sources

On Tue, 2017-11-28 at 18:18 +, Cédric Le Goater wrote: > AFAICT, it doesn't. LSI events are configured as the other XIVE interrupts. > The level is converted in the P bit and the Q bit should always be zero. > So I should be able to simplify the proposed model which still is mimicking > XICS

Re: [Qemu-devel] [PATCH 11/25] spapr: describe the XIVE interrupt source flags

On Tue, 2017-11-28 at 17:40 +1100, David Gibson wrote: > > @@ -368,6 +368,10 @@ static void spapr_xive_realize(DeviceState *dev, Error > > **errp) > > /* Allocate the IVT (Interrupt Virtualization Table) */ > > xive->ivt = g_malloc0(xive->nr_irqs * sizeof(XiveIVE)); > > > > +/*

Re: [Qemu-devel] [PATCH 10/25] spapr: add MMIO handlers for the XIVE interrupt sources

On Tue, 2017-11-28 at 17:38 +1100, David Gibson wrote: > Hrm. I don't love that you're dealing with clearing that LSI bit > here, but setting it at a different level. > > The state machines are doing my head in a bit, is there any way > you could derive the STATUS_SENT bit from the PQ bits?

Re: [Qemu-devel] [PATCH 13/25] spapr: introduce the XIVE Event Queues

On Fri, 2017-11-24 at 09:15 +0100, Cédric Le Goater wrote: > So The Linux driver is expected to choose priority 6. The priority > validity is then checked in each hcall returning H_P4/H_P3 in case of > failure. > > But it is true that we scale the arrays with : > > #define

Re: [Qemu-devel] [PATCH 13/25] spapr: introduce the XIVE Event Queues

On Thu, 2017-11-23 at 14:29 +0100, Cédric Le Goater wrote: > The Event Queue Descriptor (EQD) table, also known as Event Notification > Descriptor (END), is one of the internal tables the XIVE interrupt > controller uses to redirect exception from event sources to CPU > threads. Keep in mind tha

Re: [Qemu-devel] [PATCH v2 2/4] spapr/rtas: disable the decrementer interrupt when a CPU is unplugged

On Mon, 2017-10-09 at 17:49 +0200, Cédric Le Goater wrote: > When a CPU is stopped with the 'stop-self' RTAS call, its state > 'halted' is switched to 1 and, in this case, the MSR is not taken into > account anymore in the cpu_has_work() routine. Only the pending > hardware interrupts are checked

Re: [Qemu-devel] [PATCH 1/2] spapr/rtas: disable the decrementer interrupt when a CPU is unplugged

On Fri, 2017-10-06 at 20:07 +1100, David Gibson wrote: > Hm. Checking mmu_model doesn't seem right to me. I mean, it'll get > the right answer in practice, but the LPCR programming has nothing > whatsoever to do with the MMU. > > I think explicitly checking if cpu_ is a POWER9 instance with >

Re: [Qemu-devel] [PATCH 0/2] disable the decrementer interrupt when a CPU is unplugged

On Fri, 2017-10-06 at 11:40 +0530, Nikunj A Dadhania wrote: > Cédric Le Goater writes: > > > Hello, > > > > When a CPU is stopped with the 'stop-self' RTAS call, its state > > 'halted' is switched to 1 and, in this case, the MSR is not taken into > > account anymore in the

Re: [Qemu-devel] [RFC PATCH v2 18/21] ppc/xive: add device tree support

On Thu, 2017-09-28 at 10:51 +0200, Cédric Le Goater wrote: > probably, I just removed the properties under QEMU and could > boot the guest, with disks and network. As long as you don't use LSIs... > > > Do you have a DT snapshot from pHyp for me to look at ? > > > # lsprop

Re: [Qemu-devel] [RFC PATCH v2 18/21] ppc/xive: add device tree support

On Thu, 2017-09-21 at 11:35 +1000, David Gibson wrote: > > >> +_FDT(fdt_setprop_string(fdt, node, "device_type", "power-ivpe")); > > >> +_FDT(fdt_setprop(fdt, node, "reg", timas, sizeof(timas))); > > >> + > > >> +_FDT(fdt_setprop_string(fdt, node, "compatible", "ibm,power-ivpe")); > >

Re: [Qemu-devel] [RFC PATCH v2 18/21] ppc/xive: add device tree support

On Thu, 2017-09-21 at 13:21 +0200, Cédric Le Goater wrote: > Let me be more precise. I am saying that the interrupt-controller > and #interrupt-cells properties are not needed under the main interrupt > controller node. They can be removed from the tree and the Linux guest > kernel will boot

Re: [Qemu-devel] [RFC PATCH v2 07/21] ppc/xive: add MMIO handlers for the XIVE interrupt sources

On Wed, 2017-09-20 at 15:05 +0200, Cédric Le Goater wrote: > > > +/* > > > + * XIVE Interrupt Source MMIOs > > > + */ > > > +static uint64_t spapr_xive_esb_read(void *opaque, hwaddr addr, unsigned > > > size) > > > +{ > > > +sPAPRXive *xive = SPAPR_XIVE(opaque); > > > +uint32_t offset =

Re: [Qemu-devel] [RFC PATCH v2 07/21] ppc/xive: add MMIO handlers for the XIVE interrupt sources

On Wed, 2017-09-20 at 14:54 +0200, Cédric Le Goater wrote: > On 09/19/2017 04:57 AM, David Gibson wrote: > > On Mon, Sep 11, 2017 at 07:12:21PM +0200, Cédric Le Goater wrote: > > > Each interrupt source is associated with a two bit state machine > > > called an Event State Buffer (ESB) which is

Re: [Qemu-devel] [RFC PATCH v2 00/21] Guest exploitation of the XIVE interrupt controller (POWER9)

On Wed, 2017-09-20 at 14:33 +0200, Cédric Le Goater wrote: > > > I'm thinking maybe trying to support the CAS negotiation of interrupt > > > controller from day 1 is warping the design. A better approach might > > > be first to implement XIVE only when given a specific machine option - > > >

Re: [Qemu-devel] [RFC PATCH v2 14/21] ppc/xive: add support for the SET_OS_PENDING command

On Wed, 2017-09-20 at 11:47 +0200, Cédric Le Goater wrote: > > > @@ -162,7 +162,14 @@ static bool spapr_xive_tm_is_readonly(uint8_t index) > > > static void spapr_xive_tm_write_special(ICPState *icp, hwaddr offset, > > > uint64_t value, unsigned size) > > >

Re: [Qemu-devel] [RFC PATCH v2 13/21] ppc/xive: handle interrupt acknowledgment by the O/S

On Wed, 2017-09-20 at 11:40 +0200, Cédric Le Goater wrote: > > Plus, this doesn't seem right. Shouldn't this > > recheck the CPPR against the PIPR, in case a higher priority irq has > > been delivered since the one the cpu is acking. > > If a higher priority is delivered, it means that the CPPR

Re: [Qemu-devel] [RFC PATCH v2 11/21] ppc/xive: push the EQ data in OS event queue

On Wed, 2017-09-20 at 16:34 +1000, David Gibson wrote: > > >> +if (GETFIELD(EQ_W6_FORMAT_BIT, eq->w6) == 0) { > > >> +priority = GETFIELD(EQ_W7_F0_PRIORITY, eq->w7); > > >> > > >> +/* The EQ is masked. Can this happen ? */ > > >> +if (priority == 0xff) { > > >> +

Re: [Qemu-devel] [RFC PATCH v2 01/21] ppc/xive: introduce a skeleton for the sPAPR XIVE interrupt controller

On Tue, 2017-09-26 at 13:54 +1000, David Gibson wrote: > > > > > > Which ones? My impression was that there needed to be at least #cpus > > > * #priority-levels EQs, but there could be more than that, > > > > euh no, not in spapr mode at least. There are 8 queues per cpu. > > Ok. There's a

Re: [Qemu-devel] [RFC PATCH 16/26] ppc/xive: notify CPU when interrupt priority is more privileged

On Sat, 2017-09-09 at 10:08 +0200, Cédric Le Goater wrote: > On 09/09/2017 09:39 AM, Benjamin Herrenschmidt wrote: > > On Wed, 2017-07-05 at 19:13 +0200, Cédric Le Goater wrote: > > > Signed-off-by: Cédric Le Goater <c...@kaod.org> > > &g

Re: [Qemu-devel] [RFC PATCH 16/26] ppc/xive: notify CPU when interrupt priority is more privileged

On Wed, 2017-07-05 at 19:13 +0200, Cédric Le Goater wrote: > Signed-off-by: Cédric Le Goater > --- > hw/intc/xive.c | 21 + > 1 file changed, 21 insertions(+) > > diff --git a/hw/intc/xive.c b/hw/intc/xive.c > index c3c1e9c9db2d..cda1fa18e44d 100644 > ---

Re: [Qemu-devel] [RFC PATCH 08/26] ppc/xive: add flags to the XIVE interrupt source

On Tue, 2017-07-25 at 14:18 +1000, David Gibson wrote: > > Well, at this point I think nothing will set that flag It's there > > for workaround around HW bugs on some chips. At least in full emu it > > shouldn't happen unless we try to emulate those bugs. Hopefully direct > > MMIO will just

Re: [Qemu-devel] [RFC PATCH 08/26] ppc/xive: add flags to the XIVE interrupt source

On Tue, 2017-07-25 at 14:19 +1000, David Gibson wrote: > > Nevertheless I have added support for the hcall in Linux and QEMU. > > To use, I think we could create a specific source. > > So, IIUC, it's host constraints that would make this one way or the > other. So what happens when a guest

Re: [Qemu-devel] [RFC PATCH 08/26] ppc/xive: add flags to the XIVE interrupt source

On Mon, 2017-07-24 at 19:50 +1000, David Gibson wrote: > On Mon, Jul 24, 2017 at 05:00:57PM +1000, Benjamin Herrenschmidt wrote: > > On Mon, 2017-07-24 at 14:36 +1000, David Gibson wrote: > > > On Wed, Jul 05, 2017 at 07:13:21PM +0200, Cédric Le Goater wrote: > > >

Re: [Qemu-devel] [RFC PATCH 07/26] ppc/xive: add MMIO handlers to the XIVE interrupt source

On Mon, 2017-07-24 at 14:29 +1000, David Gibson wrote: > > +case XIVE_ESB_SET_PQ_00: > > +case XIVE_ESB_SET_PQ_01: > > +case XIVE_ESB_SET_PQ_10: > > +case XIVE_ESB_SET_PQ_11: > > +ret = xive_pq_get(x, lisn); > > +xive_pq_set(x, lisn, (offset >> 8) & 0x3); > > Again

Re: [Qemu-devel] [RFC PATCH 04/26] ppc/xive: introduce a skeleton for the XIVE interrupt controller model

On Mon, 2017-07-24 at 15:38 +1000, David Gibson wrote: > > Can we assign our logical numbers sparsely, or will that cause other > problems? The main issue is that they probably needs to be the same between XICS and XIVE because by the time we get the CAS call to chose between XICS and XIVE, we

Re: [Qemu-devel] [RFC PATCH 08/26] ppc/xive: add flags to the XIVE interrupt source

On Mon, 2017-07-24 at 14:36 +1000, David Gibson wrote: > On Wed, Jul 05, 2017 at 07:13:21PM +0200, Cédric Le Goater wrote: > > These flags define some characteristics of the source : > > > > - XIVE_SRC_H_INT_ESB the Event State Buffer are controlled with a > >specific

Re: [Qemu-devel] [RFC PATCH 09/26] ppc/xive: add an overall memory region for the ESBs

On Mon, 2017-07-24 at 14:49 +1000, David Gibson wrote: > On Wed, Jul 05, 2017 at 07:13:22PM +0200, Cédric Le Goater wrote: > > Each source adds its own ESB mempry region to the overall ESB memory > > region of the controller. It will be mapped in the CPU address space > > when XIVE is activated. >

Re: [Qemu-devel] [RFC PATCH 04/26] ppc/xive: introduce a skeleton for the XIVE interrupt controller model

On Mon, 2017-07-24 at 13:28 +1000, David Gibson wrote: > > So yes, in PAPR there's an "allocator" because the hypervisor will > > create a guest "virtual" (or logical to use PAPR terminology) interrupt > > number space, in order to represents the various interrupts into the > > guest. > > Ok, but

Re: [Qemu-devel] [RFC PATCH 04/26] ppc/xive: introduce a skeleton for the XIVE interrupt controller model

On Fri, 2017-07-21 at 17:50 +1000, David Gibson wrote: > On Wed, Jul 19, 2017 at 02:02:18PM +1000, Benjamin Herrenschmidt wrote: > > On Wed, 2017-07-19 at 13:08 +1000, David Gibson wrote: > > > > > > I'm somewhat uncomfortable with an irq allocater here in the intc

Re: [Qemu-devel] [RFC PATCH 04/26] ppc/xive: introduce a skeleton for the XIVE interrupt controller model

On Wed, 2017-07-19 at 14:01 +1000, David Gibson wrote: > On Wed, Jul 19, 2017 at 01:56:57PM +1000, Benjamin Herrenschmidt wrote: > > On Wed, 2017-07-19 at 13:08 +1000, David Gibson wrote: > > > On Wed, Jul 05, 2017 at 07:13:17PM +0200, Cédric Le Goater wrote: > > > >

Re: [Qemu-devel] [RFC PATCH 04/26] ppc/xive: introduce a skeleton for the XIVE interrupt controller model

On Wed, 2017-07-19 at 13:08 +1000, David Gibson wrote: > > I'm somewhat uncomfortable with an irq allocater here in the intc > code. As a rule, irq allocation is the responsibility of the machine, > not any sub-component. Furthermore, it should allocate in a way which > is repeatable, since

Re: [Qemu-devel] [RFC PATCH 04/26] ppc/xive: introduce a skeleton for the XIVE interrupt controller model

On Wed, 2017-07-19 at 13:08 +1000, David Gibson wrote: > On Wed, Jul 05, 2017 at 07:13:17PM +0200, Cédric Le Goater wrote: > > Let's provide an empty shell for the XIVE controller model with a > > couple of attributes for the IRQ number allocator. The latter is > > largely inspired by OPAL which

Re: [Qemu-devel] [RFC PATCH 00/26] guest exploitation of the XIVE interrupt controller (POWER9)

On Wed, 2017-07-19 at 13:00 +1000, David Gibson wrote: > So, this is probably obvious, but I'm not considering this a candidate > for qemu 2.10 (seeing as the soft freeze was yesterday). I'll still > try to review and, once ready, queue for 2.11. Right. I need to review still and we need to make

Re: [Qemu-devel] [PATCH v3] spapr: disable decrementer during reset

On Tue, 2017-07-18 at 10:56 +0530, Nikunj A Dadhania wrote: > In case of reboot, all CPUs are resumed after reboot. So we check the > next condition cpu_has_work() in cpu_thread_is_idle(), where we see a > DECR interrupt and remove the CPU from halted state as the CPU has work. Shouldn't we put

  1   2   3   4   5   6   7   8   9   10   >