From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [RFC PATCH v2 13/22] xen/arm: its: Add virtual ITS command support Date: Thu, 02 Apr 2015 14:47:52 +0100 Message-ID: <551D4888.1020309@gmail.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> <1427973539.4037.52.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1427973539.4037.52.camel@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: Ian Campbell , 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 Hi Ian, On 02/04/2015 12:18, Ian Campbell wrote: > 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. That would require more tracking. Anyway, I think that would work. > 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. Right, that would be the best solution for Xen. Although, the would mean diverging from Linux driver (see discussion on patch #6). But I think it's inevitable we can't have the same driver close to Linux. >> 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. We don't have to worry about released operations. Once it acknowledge (via the above completion notification) the command can be discard in the ITS driver. Regards, -- Julien Grall