[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v8 0/7] xen/arm: Add GICv3 support
(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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |