From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [Draft F] Xen on ARM vITS Handling Date: Fri, 12 Jun 2015 09:14:38 -0400 Message-ID: <557ADB3E.1050103@citrix.com> References: <1434015607.30003.137.camel@citrix.com> <1434113748.30003.207.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: <1434113748.30003.207.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 , xen-devel Cc: manish.jaggi@caviumnetworks.com, Julien Grall , Stefano Stabellini , Vijay Kilari List-Id: xen-devel@lists.xenproject.org On 12/06/2015 08:55, Ian Campbell wrote: > On Thu, 2015-06-11 at 10:40 +0100, Ian Campbell wrote: >> ## Command Queue Virtualisation >> >> The command translation/emulation in this design has been arranged to >> be as cheap as possible (e.g. in many cases the actions are NOPs), >> avoiding previous concerns about the length of time which an emulated >> write to a `CWRITER` register may block the vcpu. >> >> The vits will simply track its reader and writer pointers. On write >> to `CWRITER` it will immediately and synchronously process all >> commands in the queue and update its state accordingly. >> >> It might be possible to implement a rudimentary form of preemption by >> periodically (as determined by `hypercall_preempt_check()`) returning >> to the guest without incrementing PC but with updated internal >> `CREADR` state, meaning it will reexecute the write to `CWRITER` and >> we can pickup where we left off for another iteration. This at least >> lets us schedule other vcpus etc and prevents a monopoly. > > In the presence of multiple VCPUs writing to GITS_CWRITER preemption > actually gets pretty subtle. I suggest leaving it out for now. Would it be possible to do it with re-doing the write to the GITS_CWRITER? Regards, -- Julien Grall