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: Thu, 8 Oct 2015 19:36:49 +0100 Message-ID: <5616B7C1.8070503@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZkG5E-0002Ew-GQ for xen-devel@lists.xenproject.org; Thu, 08 Oct 2015 18:38:28 +0000 In-Reply-To: <1444314312.1410.206.camel@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 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. Regards, -- Julien Grall