[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v7 21/28] xen/arm: ITS: Add GICR register emulation
On 28/09/15 11:37, Vijay Kilari wrote: > On Mon, Sep 28, 2015 at 3:23 PM, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote: >> On Sat, 2015-09-26 at 21:38 +0530, Vijay Kilari wrote: >> >>> LPI property table is accessed in interrupt context. So interrupts >>> are disabled. >> >> Interrupts a reenabled while handling an interrupt, so a higher priority >> interrupt can still interrupt things. >> >> See the use of local_irq_enable in gic_interrupt. > > true, for this reason, I have taken spin lock with disabled > interrrupts when reading guest LPI table. > > Question is to avoid disabling interrupts for a long time for about 8K/16K > lpis > state update. Why only 8K/16K LPIs? From the ITS spec, the number of LPIs is encoded on 32bit so it would be possible to have 500K LPIs... > The LPI state update from guest LPI property table is done when guest > updates GICR_CTLR.EnableLPIs to 1. > (I am doing this in next revision). > > So we can make a check for guest's GICR_CTLR.EnableLPIs field before > injecting LPIs to the domain. As per design > GICR_CTLR.EnableLPIs should be 0 when updating guest property table. > i.e updating GICR_PROPBASER. GICR_CTLR is per vCPU and the property table is per domain. How would you know when to parse the property table? > So that we don't need to disable interrupts(LPIs are already disabled) > while reading guest LPI table. That won't help. As already said on a previous mail, it was for command emulation, the vCPU will monopolize the physical CPU for a very long time. That means that no other vCPU can run this physical CPU. I think the best solution would be tasklet which will divide the parsing in small chunk. This would avoid to get Xen stuck on the physical CPU for a long time. A tasklet would be created when GICR_PROPBASER is written. Any vCPU sending an INV command would get block until the tasklet is finished. Regards, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |