From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v3 7/9] xen/arm: vgic: Optimize the way to store the target vCPU in the rank Date: Fri, 9 Oct 2015 12:24:41 +0100 Message-ID: <5617A3F9.70906@citrix.com> References: <1444228871-383-1-git-send-email-julien.grall@citrix.com> <1444228871-383-8-git-send-email-julien.grall@citrix.com> <56156161.4090109@citrix.com> <1444301795.1410.148.camel@citrix.com> <1444307021.1410.170.camel@citrix.com> <561673A8.8050608@citrix.com> <1444314312.1410.206.camel@citrix.com> <5616B7C1.8070503@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZkVoO-00006e-5k for xen-devel@lists.xenproject.org; Fri, 09 Oct 2015 11:26:08 +0000 In-Reply-To: <5616B7C1.8070503@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Stefano Stabellini Cc: xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org 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 ). > > 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