Re: [Xen-devel] [PATCH v3 7/9] xen/arm: vgic: Optimize the way to store the target vCPU in the rank

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 08/10/15 19:36, Julien Grall wrote:
> On 08/10/15 15:25, Ian Campbell wrote:
>>> If the concern is the behavior is changed, I'm happy to rework this code
>>> to keep exactly the same behavior. I.e any 32-bit write containing
>>> a 0 byte will be ignored. This is not optimal but at least I'm not
>>> opening the pandora box of fixing every single error in the code touch
>>> by this series.
>>
>> I'm okay with the new behaviour, I think Stefano was willing to tolerate it
>> (based on <alpine.DEB.2.02.1510081220190.1179@xxxxxxxxxxxxxxxxxxxxxxx>).
> 
> It's what I understand too. I will a resend a new version tomorrow.
> 
>> So if we aren't going to fix it to DTRT WRT writing zero to a target then I
>> think we can go with the current variant and not change to ignoring any
>> word with a zero byte in it.
> 
> I'm thinking to split this patch in two:
>       - One which will turn the current ITARGETSR emulation in a function
> with the change of behavior when writing zero to a target.
>         - The other to optimize the way we store the target.
> 
> This will keep the second patch nearly mechanical and avoid to change
> multiple behavior within the same patch.

While looking to split the patch in two part I've noticed another error
in the current emulation of ITARGETSR.

For a byte access, the byte will always be in r[0:7] of the register.
Although we are assuming that if the guest is writing to byte N (0 <= N
< 3), the byte will be in r[N * 8: ((N + 1)* 8) - 1]. Therefore any
guest using byte access won't be able to change the target:

target = (target << (8 * (gicd_reg & 0x3)));
target &= r;

I plan to fix it in patch #1 and request a backport for Xen 4.6 and Xen
4.5. I can do a separate patch if we don't want the cleanup. Note that
the second patch will be a requirement to fix 32-bit access to 64-bit
register.

Regards,

-- 
Julien Grall

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