From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v3 7/9] xen/arm: vgic: Optimize the way to store the target vCPU in the rank Date: Wed, 7 Oct 2015 16:38:40 +0100 Message-ID: <1444232320.1410.82.camel@citrix.com> References: <1444228871-383-1-git-send-email-julien.grall@citrix.com> <1444228871-383-8-git-send-email-julien.grall@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 1Zjqnk-0002KX-T8 for xen-devel@lists.xenproject.org; Wed, 07 Oct 2015 15:38:44 +0000 In-Reply-To: <1444228871-383-8-git-send-email-julien.grall@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: Julien Grall , xen-devel@lists.xenproject.org Cc: stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On Wed, 2015-10-07 at 15:41 +0100, Julien Grall wrote: > Note that with these changes, any read to those registers will list only > the target vCPU used by Xen. We think this is likely to be OK because the > GIC spec doesn't require to return exactly the value written and it can > be seen as if we decide to implement the register read-only. This still isn't true. The GIC spec requires one of two modes: Either the register is read-only _or_ it is writable and one can expect to read back what was written (because the spec doesn't say otherwise and doing otherwise would definitely be exceptional behaviour). This comment needs to explain why believe we are able to get away with implementing a third option despite that, i.e. why we think it is ok to push the boundaries of the spec here. At no point should the behaviour implemented be compared to implementing the register as read-only, because that is a bogus comparison. A register cannot be "sort of read-only" and justifying the behaviour here on that basis is incorrect. > Changes in v3: > - Make clear in the commit message that we rely on a corner case > of the spec. No we don't. We do something out of spec which we think we can get away with implementing as we have done. Ian.