From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: Xen on ARM vITS Handling Draft B (Was Re: Xen/arm: Virtual ITS command queue handling) Date: Mon, 25 May 2015 19:11:08 +0200 Message-ID: <556357AC.7010501@citrix.com> References: <1431442942.8263.175.camel@citrix.com> <1431690336.8943.97.camel@citrix.com> <555608C6.7000609@citrix.com> <1432037407.12989.103.camel@citrix.com> <555B3C7E.2030608@citrix.com> <1432043511.12989.132.camel@citrix.com> <5561A95E.1070706@citrix.com> <5562EC2D.2030705@gmail.com> <55631917.80800@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Vijay Kilari , Julien Grall Cc: Ian Campbell , Stefano Stabellini , Prasun Kapoor , manish.jaggi@caviumnetworks.com, Julien Grall , "xen-devel@lists.xen.org" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org Hi, On 25/05/2015 15:38, Vijay Kilari wrote: > On Mon, May 25, 2015 at 6:14 PM, Julien Grall wrote: >> AFAIU your proposal, the function mapping(vCID) will always return the same >> pCID, right? > > Yes, vCID to pCID is mapped But how? Let say we have a function vCID_to_pCID which take a vCID in parameter and return the corresponding pCID. Is this function pure (i.e the function always evaluates the same result and don't depend on any hidden information)? Don't forget that any interrupt associated to a collection should be moved with the collection. So depending how you decide to map the vCID to the pCID you may also need to move all the interrupts one by one. MOVALL only move the pending interrupt from one vCPU to another vCPU (BTW this could be very expensive). [..] >> I can't see where the spec says that 2 MAPD (one with V=1 and the other with >> V=0) is required. The section 4.9.18 contains an 'or': >> >> "Issue a mapping command (MAPD; see section 5.13.11) or an un-mapping >> command" >> >> This is related to "Interrupts can be re-mapped or un-mapped". >> >> 4.9.18 and 5.13.11 (PRD03-GENC-010745 24.0) are only speaking about a single >> MAPD: >> >> "Note: software might issue a MAPD command to re-map an already mapped >> device and the ITS must invalidate all cached data for that device." >> > > OK. I have missed this 'or'. If so, MAPD always overwrites the old info You have to ensure that all interrupts related to this device have been disabled before using the new ITT. You can't trust that the guest did it correctly before re-issuing MAPD. -- Julien Grall