From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [RFC PATCH v2 13/22] xen/arm: its: Add virtual ITS command support Date: Thu, 2 Apr 2015 12:18:59 +0100 Message-ID: <1427973539.4037.52.camel@citrix.com> References: <1426775889-29442-1-git-send-email-vijay.kilari@gmail.com> <1426775889-29442-14-git-send-email-vijay.kilari@gmail.com> <55114EFA.9050304@linaro.org> <55197005.7090408@linaro.org> <1427888815.2115.279.camel@citrix.com> <551BDE4C.9030109@citrix.com> <1427966007.4037.14.camel@citrix.com> <551D2298.2060302@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <551D2298.2060302@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Julien Grall Cc: Vijay Kilari , Stefano Stabellini , Prasun Kapoor , Vijaya Kumar K , Julien Grall , Tim Deegan , "xen-devel@lists.xen.org" , Stefano Stabellini , manish.jaggi@caviumnetworks.com List-Id: xen-devel@lists.xenproject.org On Thu, 2015-04-02 at 12:06 +0100, Julien Grall wrote: > > Can we just enqueue with the hardware and use the guest vcpu polling > > loop to trigger us to check for completion? > > Enqueue may be long. I was thinking about suggesting to use a tasklet > for processing ITS command. We don't need to enqueue everything the guest gives us at once, we could only do a subset and pickup the rest later as things complete at the physical ITS. > But I don't know how much we can do in Xen with them. > > > What would happen if a guest > > never polled, I suppose we would have to catch it some other way? > > The specification (see 4.9.9 PRD03-GENC-010745 24.0) defines 2 different > way to be notify for completion: > 1) Polling: Reading GITS_CREADR in a loop > 2) Receiving an interrupt (see 4.9.10) by using the command MAPI. I would expect Xen itself to use the second option at the host level, which would then drive the completion via the vGITS_CREADR or the guest's virtualised interrupt. That means the pCPU is free during the ITS processing, which is surely what we want. > A guest would be buggy if it doesn't implement one of this solution. And > therefore may not run on real h/w. I was more concerned about it wedging the hypervisor somehow with a large number of completed but not released operations. Ian.