|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH v2 13/22] xen/arm: its: Add virtual ITS command support
Hi, On 28/04/15 10:56, Stefano Stabellini wrote: > On Tue, 28 Apr 2015, Vijay Kilari wrote: >> Approach 1: (Using completion interrupt) >> ---------------- >> 1) Create dummy device for each virtual ITS when virtual its is >> created for a domain >> OR Allocate one interrupt number for each virtual ITS from the one >> single dummy device >> >> 2) Trap on CWRITER >> 3) Take vits lock >> 4) Read a Virtual Command from Virtual Command Queue >> 5) Translate Virtual command to Physical command >> 5) Release vits lock >> 6) Take physical ITS lock >> 7) Post physical commands + Append INT command >> 8) Release physical ITS lock >> 9) Return from CWRITER trap and let VCPU poll in EL1 (kernel) for CREADER >> update >> which indicates completion of command. >> 10) On receiving interrupt, Update CREADER of this virtual ITS >> >> Pros: >> - VCPU polls in EL1. >> >> Cons: >> - Complexity in creating & managing dummy device. If you properly manage the device with struct pci_dev or struct device (which is, as talked earlier, obviously required for security) you should avoid your so-called "dummy device". BTW, what do you mean by "dummy device"? >> Approach 2: >> ---------------- >> I thought of below approach where in we reduce locking time and no need >> of Interrupt. >> >> 1) Trap on CWRITER >> 2) Take vits lock >> 3) Read _all_ or 2 Virtual Commands from Virtual Command Queue >> 4) Translate _all_ or 2 Virtual commands to Physical commands >> 5) Release vits lock >> 6) Take physical ITS lock >> 7) Post physical commands >> 8) Release physical ITS lock >> 9) Poll for completion of command and return from CWRITER trap. >> >> Pros: >> - Simple approach >> Cons: >> - VCPU polls in EL2 > > I think we'll have to go with Approach 1. > > The problem with Approach 2 is that we would need to watch out for > sequences of guest ITS commands that could cause Xen to poll for too > long and lock up. +1, the approach 1 is the best. Regards, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |