All of lore.kernel.org
 help / color / mirror / Atom feed
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: Tue, 20 Jan 2015 15:57:35 +0000	[thread overview]
Message-ID: <1421769455.10440.306.camel@citrix.com> (raw)
In-Reply-To: <1421684957-29884-5-git-send-email-julien.grall@linaro.org>

On Mon, 2015-01-19 at 16:29 +0000, Julien Grall wrote:
> In general, it's not necessary/important to check the size.

Only if the docs say this register can be accessed by a partial
read/write, or if it is implementation defined what the result would be
(and RAZ/WI is within the set of allowable actions).

Do you have a reference for the behaviour of GICR accesses which aren't
of the register's natural size?

>  It's better
> to log it to let know the guest that its access will have no effect.
> 
> Note: On debug build it may happen to see some of these messages during
> domain boot.

We should only print if the guest has done something wrong, and reading
a RAZ register (or one which we have implemented that way) is not
inherently wrong.

IOW read_as_zero* should be silent, and a different code path used for
"guest did something wrong".

IOW I think the current distinction between bad_width and read_as_zero*
is correct currently, although perhaps the goto's which target them need
adjusting in some cases.

Perhaps you want to add a read_as_zero_32 which has the check, making
read_as_zero accept either 32- or 64-bit accesses, and goto the correct
label for each register?

Ian.

  reply	other threads:[~2015-01-20 16:17 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-19 16:29 [PATCH 00/10] xen/arm: Bug fixes for the vGIC Julien Grall
2015-01-19 16:29 ` [PATCH 01/10] xen/arm: vgic-v3: Correctly set GICD_TYPER.IDbits Julien Grall
2015-01-20 15:34   ` Ian Campbell
2015-01-20 17:16     ` Julien Grall
2015-01-20 15:43   ` Ian Campbell
2015-01-19 16:29 ` [PATCH 02/10] xen/arm: vgic-v3: Correctly set GICD_TYPER.CPUNumber Julien Grall
2015-01-20 15:43   ` Ian Campbell
2015-01-19 16:29 ` [PATCH 03/10] xen/arm: vgic-v3: Correctly handle GICD_CTLR Julien Grall
2015-01-20 15:51   ` Ian Campbell
2015-01-20 17:17     ` Julien Grall
2015-01-19 16:29 ` [PATCH 04/10] xen/arm: vgic-v3: Don't check the size when we ignore the write/read as zero Julien Grall
2015-01-20 15:57   ` Ian Campbell [this message]
2015-01-20 17:41     ` Julien Grall
2015-01-20 17:57       ` Ian Campbell
2015-01-20 18:50         ` Julien Grall
2015-01-21 12:11           ` Ian Campbell
2015-01-21 12:28             ` Julien Grall
2015-01-21 12:36               ` Ian Campbell
2015-01-21 12:45                 ` Julien Grall
2015-01-21 12:50                   ` Ian Campbell
2015-01-20 18:04       ` Julien Grall
2015-01-19 16:29 ` [PATCH 05/10] xen/arm: vgic-v3: Document the current restrictions Julien Grall
2015-01-20 16:00   ` Ian Campbell
2015-01-20 17:49     ` Julien Grall
2015-01-21 12:16       ` Ian Campbell
2015-01-21 12:33         ` Julien Grall
2015-01-21 12:48           ` Ian Campbell
2015-01-21 13:19             ` Julien Grall
2015-01-22 15:19               ` Julien Grall
2015-01-19 16:29 ` [PATCH 06/10] xen/arm: vgic-v3: Print the domain/vcpu in each message Julien Grall
2015-01-20 16:05   ` Ian Campbell
2015-01-20 17:50     ` Julien Grall
2015-01-19 16:29 ` [PATCH 07/10] xen/arm: vgic-v2: Correctly set GICD_TYPER.CPUNumber Julien Grall
2015-01-20 16:06   ` Ian Campbell
2015-01-19 16:29 ` [PATCH 08/10] xen/arm: vgic-v2: Don't check the size when we ignore the write/read a zero Julien Grall
2015-01-20 16:08   ` Ian Campbell
2015-01-19 16:29 ` [PATCH 09/10] xen/arm: vgic-v2: Take the lock when writing into GICD_CTLR Julien Grall
2015-01-20 16:09   ` Ian Campbell
2015-01-19 16:29 ` [PATCH 10/10] xen/arm: vgic-v2: Print the domain/vcpu in each message Julien Grall
2015-01-20 16:09   ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1421769455.10440.306.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=julien.grall@linaro.org \
    --cc=stefano.stabellini@citrix.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.