qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Gibson
Subject: Re: [Qemu-devel] [RFC PATCH v2 11/21] ppc/xive: push the EQ data in OS event queue
Date: Wed, 20 Sep 2017 16:34:16 +1000
User-agent: Mutt/1.8.3 (2017-05-23)

On Tue, Sep 19, 2017 at 09:36:08PM +0200, Cédric Le Goater wrote:
> On 09/19/2017 09:45 AM, David Gibson wrote:
> > On Mon, Sep 11, 2017 at 07:12:25PM +0200, Cédric Le Goater wrote:
> >> If a triggered event is let through, the Event Queue data defined in
> >> the associated IVE is pushed in the in-memory event queue. The latter
> >> is a circular buffer provided by the OS using the H_INT_SET_QUEUE_CONFIG
> >> hcall, one per target and priority couple. It is composed of Event
> >> Queue entries which are 4 bytes long, the first bit being a
> >> 'generation' bit and the 31 following bits the EQ Data field.
> >>
> >> The EQ Data field provides a way to set an invariant logical event
> >> source number for an IRQ. It is set with the H_INT_SET_SOURCE_CONFIG
> >> hcall.
> >>
> >> Notification of the CPU will be done in the following patch.
> >>
> >> Signed-off-by: Cédric Le Goater <address@hidden>
> >> ---
> >>  hw/intc/spapr_xive.c | 67 
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>  1 file changed, 67 insertions(+)
> >>
> >> diff --git a/hw/intc/spapr_xive.c b/hw/intc/spapr_xive.c
> >> index 557a7e2535b5..4bc61cfda67a 100644
> >> --- a/hw/intc/spapr_xive.c
> >> +++ b/hw/intc/spapr_xive.c
> >> @@ -175,9 +175,76 @@ static const MemoryRegionOps spapr_xive_tm_ops = {
> >>      },
> >>  };
> >>  
> >> +static void spapr_xive_eq_push(XiveEQ *eq, uint32_t data)
> >> +{
> >> +    uint64_t qaddr_base = (((uint64_t)(eq->w2 & 0x0fffffff)) << 32) | 
> >> eq->w3;
> >> +    uint32_t qsize = GETFIELD(EQ_W0_QSIZE, eq->w0);
> >> +    uint32_t qindex = GETFIELD(EQ_W1_PAGE_OFF, eq->w1);
> >> +    uint32_t qgen = GETFIELD(EQ_W1_GENERATION, eq->w1);
> >> +
> >> +    uint64_t qaddr = qaddr_base + (qindex << 2);
> >> +    uint32_t qdata = cpu_to_be32((qgen << 31) | (data & 0x7fffffff));
> >> +    uint32_t qentries = 1 << (qsize + 10);
> >> +
> >> +    if (dma_memory_write(&address_space_memory, qaddr, &qdata, 
> >> sizeof(qdata))) {
> >> +        qemu_log_mask(LOG_GUEST_ERROR, "%s: failed to write EQ data @0x%"
> >> +                      HWADDR_PRIx "\n", __func__, qaddr);
> >> +        return;
> >> +    }
> >> +
> >> +    qindex = (qindex + 1) % qentries;
> >> +    if (qindex == 0) {
> >> +        qgen ^= 1;
> >> +        eq->w1 = SETFIELD(EQ_W1_GENERATION, eq->w1, qgen);
> >> +    }
> >> +    eq->w1 = SETFIELD(EQ_W1_PAGE_OFF, eq->w1, qindex);
> >> +}
> >> +
> >>  static void spapr_xive_irq(sPAPRXive *xive, int srcno)
> >>  {
> >> +    XiveIVE *ive;
> >> +    XiveEQ *eq;
> >> +    uint32_t eq_idx;
> >> +    uint32_t priority;
> >> +
> >> +    ive = spapr_xive_get_ive(xive, srcno);
> >> +    if (!ive || !(ive->w & IVE_VALID)) {
> >> +        qemu_log_mask(LOG_GUEST_ERROR, "XIVE: invalid LISN %d\n", srcno);
> >> +        return;
> >> +    }
> >> +
> >> +    if (ive->w & IVE_MASKED) {
> >> +        return;
> >> +    }
> >> +
> >> +    /* Find our XiveEQ */
> >> +    eq_idx = GETFIELD(IVE_EQ_INDEX, ive->w);
> >> +    eq = spapr_xive_get_eq(xive, eq_idx);
> >> +    if (!eq) {
> >> +        qemu_log_mask(LOG_GUEST_ERROR, "XIVE: No EQ for LISN %d\n", 
> >> srcno);
> >> +        return;
> >> +    }
> >> +
> >> +    if (eq->w0 & EQ_W0_ENQUEUE) {
> >> +        spapr_xive_eq_push(eq, GETFIELD(IVE_EQ_DATA, ive->w));
> >> +    } else {
> >> +        qemu_log_mask(LOG_UNIMP, "XIVE: !ENQUEUE not implemented\n");
> >> +    }
> >> +
> >> +    if (!(eq->w0 & EQ_W0_UCOND_NOTIFY)) {
> >> +        qemu_log_mask(LOG_UNIMP, "XIVE: !UCOND_NOTIFY not implemented\n");
> >> +    }
> >> +
> >> +    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) {
> >> +            return;
> > 
> > How does the 8-bit priority field here interact with the 3-bit
> > priority which selects which EQ to use?
> 
> priority OxFF is a special case kept for masking, see the hcall 
> h_int_set_source_config. It should never reach the EQ lookup 
> routines. So may be an assert would be better here.

Ok, if this situation can't be guest triggered, only by a bug in the
rest of the XIVE code, then an assert() is better.

> 
> C. 
> 
> > 
> >> +        }
> >> +    } else {
> >> +        qemu_log_mask(LOG_UNIMP, "XIVE: w7 format1 not implemented\n");
> >> +    }
> >>  }
> >>  
> >>  /*
> > 
> 

-- 
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

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]