From: Ian Campbell <ian.campbell@citrix.com>
To: Julien Grall <julien.grall@citrix.com>, xen-devel@lists.xenproject.org
Cc: Zoltan Kiss <zoltan.kiss@huawei.com>, stefano.stabellini@eu.citrix.com
Subject: Re: [PATCH v3 1/3] xen/arm: gic: Check the size of the CPU and vCPU interface retrieved from DT
Date: Tue, 6 Oct 2015 15:55:15 +0100 [thread overview]
Message-ID: <1444143315.5302.208.camel@citrix.com> (raw)
In-Reply-To: <5613DD14.5080800@citrix.com>
On Tue, 2015-10-06 at 15:39 +0100, Julien Grall wrote:
> > > + csize = SZ_8K;
> > > + }
> > > +
> > > + /*
> > > + * Check if the CPU interface and virtual CPU interface have the
> > > + * same size.
> > > + */
> > > + if ( csize != vsize )
> > > + printk(XENLOG_WARNING "GICv2: WARNING: "
> > > + "Sizes of GICC (%#"PRIpaddr") and GICV (%#"PRIpaddr")
> > > don't match\n",
> > > + csize, vsize);
> >
> > Should we also force them to be equal? Either
> > csize = vsize = min(csize,vsize)
>
> If we restrict csize we will get to some other troubles later because
> vsize may be only 4KB.
Does Xen work with that? I suppose so.
> >
> > WRT to the XXX I think I'd be happier if this was < SZ_8K for each.
> > Otherwise some future GIC which is compatible but has extensions to the
> > register space would needlessly require changes here. But I can live
> > with
> > this.
>
> The GICv2 CPU interface is always at least 8KB. Having an higher value
> may mean that the GIC is aliased.
Or that this is a GICvN which has 8KB of GICv2 compatible registers and
then some extensions.
In either that situation or the aliasing one it would be safe to expose the
first 8KB as a gic-v2 to the guest.
> GICv2 on GICv3 is only used for guest. I prefer to restrict the usage to
> known and safe value until we have someone using different size.
>
> This will avoid to expose unwanted data/value to a guest.
Right, I'm not saying we should expose the whole region, just the known to
be gic-v2 compatible first 8KB.
NB I'm talking about domU here, things are more complicated with dom0 and
in that case you are right that it would be a bad idea.
Ian.
next prev parent reply other threads:[~2015-10-06 14:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-05 14:17 [PATCH v3 0/3] xen/arm: gic-v2: Detect automatically aliased GIC 400 Julien Grall
2015-10-05 14:17 ` [PATCH v3 1/3] xen/arm: gic: Check the size of the CPU and vCPU interface retrieved from DT Julien Grall
2015-10-06 14:11 ` Ian Campbell
2015-10-06 14:39 ` Julien Grall
2015-10-06 14:55 ` Ian Campbell [this message]
2015-10-07 15:07 ` Julien Grall
2015-10-08 13:01 ` Ian Campbell
2015-10-05 14:17 ` [PATCH v3 2/3] xen/arm: gic-v2: Automatically detect aliased GIC400 Julien Grall
2015-10-05 14:17 ` [PATCH v3 3/3] xen/arm: platform: Drop the quirks callback Julien Grall
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=1444143315.5302.208.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=julien.grall@citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xenproject.org \
--cc=zoltan.kiss@huawei.com \
/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.