[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 10/25] spapr: add MMIO handlers for the XIVE int
From: |
David Gibson |
Subject: |
Re: [Qemu-devel] [PATCH 10/25] spapr: add MMIO handlers for the XIVE interrupt sources |
Date: |
Thu, 30 Nov 2017 15:28:57 +1100 |
User-agent: |
Mutt/1.9.1 (2017-09-22) |
On Wed, Nov 29, 2017 at 05:23:25PM +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 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?
> >>>
> >>> Yes. I should.
> >>>
> >>> I am also lacking a guest driver to exercise these LSIs so I didn't
> >>> pay a lot of attention to level interrupts. Any idea ?
> >>
> >> How about an old-school emulated PCI device? Maybe rtl8139?
> >
> > Perfect. The current model is working but I will see how I can
> > improve it to use the PQ bits instead.
>
> Using the PQ bits is simplifying the model but we still have to
> maintain an array to store the IRQ type.
>
> There are 3 unused bits in the IVE descriptor, bits[1-3]:
>
> #define IVE_VALID PPC_BIT(0)
> #define IVE_EQ_BLOCK PPC_BITMASK(4, 7) /* Destination EQ block# */
> #define IVE_EQ_INDEX PPC_BITMASK(8, 31) /* Destination EQ index */
> #define IVE_MASKED PPC_BIT(32) /* Masked */
> #define IVE_EQ_DATA PPC_BITMASK(33, 63) /* Data written to the EQ
> */
>
> We could hijack one of them to store the LSI type and get rid of
> the type array. Would you object to that ?
Hrm. These IVE bits are architected, aren't they? In which case I'd
be wary of stealing a reserved bit in case of future extensions.
I'm wondering if we want another word / structure for storing
non-architected, implementation specific flags or info.
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.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
- Re: [Qemu-devel] [Qemu-ppc] [PATCH 08/25] spapr: introduce a skeleton for the XIVE interrupt controller, (continued)
- [Qemu-devel] [PATCH 09/25] spapr: introduce handlers for XIVE interrupt sources, Cédric Le Goater, 2017/11/23
- [Qemu-devel] [PATCH 10/25] spapr: add MMIO handlers for the XIVE interrupt sources, Cédric Le Goater, 2017/11/23
- Re: [Qemu-devel] [PATCH 10/25] spapr: add MMIO handlers for the XIVE interrupt sources, David Gibson, 2017/11/28
- Re: [Qemu-devel] [PATCH 10/25] spapr: add MMIO handlers for the XIVE interrupt sources, Cédric Le Goater, 2017/11/28
- Re: [Qemu-devel] [PATCH 10/25] spapr: add MMIO handlers for the XIVE interrupt sources, David Gibson, 2017/11/29
- Re: [Qemu-devel] [PATCH 10/25] spapr: add MMIO handlers for the XIVE interrupt sources, Cédric Le Goater, 2017/11/29
- Re: [Qemu-devel] [PATCH 10/25] spapr: add MMIO handlers for the XIVE interrupt sources, Cédric Le Goater, 2017/11/29
- Re: [Qemu-devel] [PATCH 10/25] spapr: add MMIO handlers for the XIVE interrupt sources,
David Gibson <=
- Re: [Qemu-devel] [PATCH 10/25] spapr: add MMIO handlers for the XIVE interrupt sources, Cédric Le Goater, 2017/11/30
- Re: [Qemu-devel] [PATCH 10/25] spapr: add MMIO handlers for the XIVE interrupt sources, David Gibson, 2017/11/30
- Re: [Qemu-devel] [PATCH 10/25] spapr: add MMIO handlers for the XIVE interrupt sources, Cédric Le Goater, 2017/11/30
[Qemu-devel] [PATCH 11/25] spapr: describe the XIVE interrupt source flags, Cédric Le Goater, 2017/11/23
[Qemu-devel] [PATCH 12/25] spapr: introduce a XIVE interrupt presenter model, Cédric Le Goater, 2017/11/23