Re: [PATCH 04/10] xen/arm: vgic-v3: Don't check the size when we ignore the write/read as zero

From: Ian Campbell <Ian.Campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: xen-devel@lists.xenproject.org, tim@xen.org,
	stefano.stabellini@citrix.com
Subject: Re: [PATCH 04/10] xen/arm: vgic-v3: Don't check the size when we ignore the write/read as zero
Date: Wed, 21 Jan 2015 12:11:35 +0000	[thread overview]
Message-ID: <1421842295.13271.16.camel@citrix.com> (raw)
In-Reply-To: <54BEA393.5060207@linaro.org>

On Tue, 2015-01-20 at 18:50 +0000, Julien Grall wrote:
[...]
> I agree for RAZ, but WI would mean something will goes wrong. For
> instance if the guest is trying to set a bit to 1, while the bit should
> be 0.

It depends on the reason for the WI. If the reason is that the spec says
the register is WI (in our supported HW configuration) then we should
silently implement that.

If it is WI because we don't implement some functionality which we
should, i.e. something should happen but we don't emulate that, then
debug-level logging might be appropriate (on a case by case basis).

Note that I'm treating things which are WI because we don't support
GICv2 compat and therefore ARE=1 and some register is then WI because of
that as the former case, not the latter. Because not implementing GICv2
compat is a valid h/w configuration.

> As the spec defines the access to be UNPREDICATABLE, I would rather
> prefer to not decode the size and directly read as zero/write ignore.

I thought about this overnight, and I would like to keep UNPREDICATABLE
as the current log + crash please. Apart from the fact that I don't want
guests to be able to rely on unpredictable accesses returning 0 it is
also more consistent with the ARM ARM which says "UNPREDICTABLE
behaviour must not be documented or promoted as having a defined
effect".

So, in summary:

1) Any access which is described as UNPREDICTABLE in GIC spec 5.1.3
should result in the current bad_width behaviour, that is: a log message
and a domain crash.

2) Accesses which are valid and which are correctly emulated according
to the features which our virtual GIC exposes to the guest should
succeed silently, regardless of whether that means WI, read a constant
or actually have some effect.

3) Accesses which are valid but which do not correctly emulate according
to the features of the virtual gic which we are exposing can log if we
think it is useful to do so.

Ian.