|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v8 0/7] xen/arm: Add GICv3 support
Hello Vijay, On 08/06/2014 03:52 PM, Vijay Kilari wrote: > Hi Ian, > > On Mon, Aug 4, 2014 at 9:18 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: >> (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? > > If there are no further comments on GICv3 patches, > I can fix pending NITs and send new version, which you can merge. > This helps to test DomUs and your 48 bit support RFC patches. I think Ian was asking to have a dirty version of your patch to support GICv3 on guest. It would be nice if you can send it. So people can give a try of the support on the ARM64 model. >> >>> 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. The plan was to allow the hypercall to be extended. I'm sure we would need to configure other things in the future. >> > > Any reference to Julien's patches for the same? https://patches.linaro.org/34664/ Regards, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |