From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v7 21/28] xen/arm: ITS: Add GICR register emulation Date: Mon, 28 Sep 2015 12:03:03 +0100 Message-ID: <56091E67.5020308@citrix.com> References: <1442581755-2668-1-git-send-email-vijay.kilari@gmail.com> <1442581755-2668-22-git-send-email-vijay.kilari@gmail.com> <56027D80.2030005@citrix.com> <1443434034.25250.235.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Vijay Kilari , Ian Campbell Cc: Stefano Stabellini , Prasun Kapoor , Vijaya Kumar K , Tim Deegan , "xen-devel@lists.xen.org" , Stefano Stabellini , manish.jaggi@caviumnetworks.com List-Id: xen-devel@lists.xenproject.org On 28/09/15 11:37, Vijay Kilari wrote: > On Mon, Sep 28, 2015 at 3:23 PM, Ian Campbell 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