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.1...@kaball.uk.xensource.com>). > > 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@lists.xen.org http://lists.xen.org/xen-devel