From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [Draft F] Xen on ARM vITS Handling Date: Fri, 12 Jun 2015 13:55:48 +0100 Message-ID: <1434113748.30003.207.camel@citrix.com> References: <1434015607.30003.137.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1434015607.30003.137.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: xen-devel Cc: manish.jaggi@caviumnetworks.com, Julien Grall , Stefano Stabellini , Vijay Kilari List-Id: xen-devel@lists.xenproject.org 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. Ian.