Re: [Xen-devel] Xen on ARM vITS Handling Draft B (Was Re: Xen/arm: Virtual ITS command queue handling)

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi,

On 25/05/2015 15:38, Vijay Kilari wrote:
> On Mon, May 25, 2015 at 6:14 PM, Julien Grall <julien.grall@xxxxxxxxxx> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel