Re: [Xen-devel] [PATCH 2/3] xen/arm: vgic-v3: Correctly retrieve the vCPU associated to a re-distributor

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, Sep 28, 2015 at 09:31:35PM +0100, Julien Grall wrote:
> When the guest is accessing the re-distributor, Xen retrieves the base
> of the re-distributor using a mask based on the stride.
> 
> Although, when the stride contains multiple set, the corresponding mask
> will be computed incorrectly [1] and therefore giving invalid vCPU and
> offset:
> 
> (XEN) d0v0: vGICR: unknown gpa read address 000000008d130008
> (XEN) traps.c:2447:d0v1 HSR=0x93c08006 pc=0xffffffc00032362c
> gva=0xffffff80000b0008 gpa=0x0000008d130008
> 
> For instance if the region of re-distributor is starting at 0x8d100000
> and the stride is 0x30000, an access to the address 0x8d130008 should
> be valid and use the re-distributor of vCPU1 with an offset of 0x8.
> Although, Xen is returning the vCPU0 and an offset of 0x20008.
> 
> I didn't find a way to replace the current computation of the mask with
> a valid. The only solution I have found is to pass the region in private
> data of the handler. So we can directly get the offset from the
> beginning of the region and find the corresponding vCPU/offset in the
> re-distributor.
> 
> This is also make the code simpler and avoid fast/slow path.
> 
> [1] http://lists.xen.org/archives/html/xen-devel/2015-09/msg03372.html
> 
> Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
> 
> ---
> Cc: shameerali.kolothum.thodi@xxxxxxxxxx
> Cc: Wei Liu <wei.liu2@xxxxxxxxxx>
> 
>     This is technically a good candidate for Xen 4.6. Without it DOM0
>     may not be able to bring secondary CPU on platform using a stride
>     with multiple bit set [1]. Although, we don't support such platform
>     right now. So I would rather defer this change to Xen 4.6.1 and
>     avoid possible downside/bug in this patch.
> 

This sounds reasonable to me.

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