Re: [Xen-devel] [PATCH v8 0/7] xen/arm: Add GICv3 support

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

(reinstating the cc)

On Mon, 2014-08-04 at 20:19 +0530, Vijay Kilari wrote:
> On Mon, Aug 4, 2014 at 4:12 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:

> Yes, Already I have booted domU with GICv3 patches with changes to
> xl tool.

Excellent!

>  Need some time to make it generic and send patches.

Perhaps you could send out whatever dirty version you have now for
people who want to try GICv3 to play with?

>  BTW, I have following questions
> 
> 1) The device tree is generated by xl tool for domU is hardcoding
> GICv2 node. How to generate device tree for GICv2 & GICv3 based on DomU?
> Should we always generate GIC node based on HW support  (by query hw
> support via domctl) ?

Something like that, yes.

There's a few different aspects which need to be taken care of, first of
all what the hardware+Xen actual support (v2 only, v3 only, v3 w/ v2
compat, vN+1 etc) and what the guest cfg actually asks for, what to do
if the guest cfg asks for something which Xen can't manage (e.g. v2 on a
v3 only system etc).

I think Julien is adding a domctl to control the number of SPIs in his
passthrough series. It probably makes sense to extend that into a more
generic "gic cfg" domctl with a field for requesting the version of gic
to support for this guest, with an explicit "default" setting for
letting Xen choose. I think it would be preferable to do all the gic
setup in one domctl, rather than proliferate loads of them.

By default I suppose Xen should be able to pick the latest GIC, unless
the guest cfg file says otherwise.

Which means we need some mechanism to find out the actual version which
Xen picked, so that the toolstack can generate the appropriate DTB node.
Perhaps that is as simple as having the domctl field be IN/OUT i.e.
updated with the actual selection.

I think we can get away with not exposing what Xen supports by simply
failing domctl requests for things which can't be done. If we really do
need this then we can perhaps use XENVER_capabilities or something new
which exposes which versions of h/w we support. I suppose we'll need
something like that sooner or later.

> 2) The GIC regs are hardcoded to physical base address for DOMU in
> xen/include/public/arch-arm.h
> 
> /* Physical Address Space */
> #define GUEST_GICD_BASE   0x03001000ULL
> #define GUEST_GICD_SIZE   0x00001000ULL
> #define GUEST_GICC_BASE   0x03002000ULL
> #define GUEST_GICC_SIZE   0x00000100ULL
> 
> any idea why it is kept same as physical address?

Same as what physical address?

The guest physical address space is static (and unrelated to any
particular hardware). So far we haven't had a need to make it dynamic.

Note that these are shared only between the Xen hypervisor (which
implements the "hardware") and Xen toolstack (which generates the DTB
describing the "hardware"). These defines are surrounded by ifdefs so
that e.g. guest kernels do not see them.

> How about for GICv3?. can we encode physical base address for domU's?

Yes. Just need to reserve some space, it can reuse the existing spaces
or extend it as needed. I think there is plenty of room in the vicinity
of 0x03xxxxxx.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel