Re: [Xen-devel] Xen/arm: Virtual ITS command queue handling

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Fri, 2015-05-15 at 14:24 +0100, Julien Grall wrote:
> Hi Ian,
> 
> On 15/05/15 13:58, Ian Campbell wrote:
> >>>>>>> Therefore it is proposed that the restriction that a single vITS maps
> >>>>>>> to one pITS be retained. If a guest requires access to devices
> >>>>>>> associated with multiple pITSs then multiple vITS should be
> >>>>>>> configured.
> >>>>>>
> >>>>>> Having multiple vITS per domain brings other issues:
> >>>>>>        - How do you know the number of ITS to describe in the device 
> >>>>>> tree at boot?
> >>>>>
> >>>>> I'm not sure. I don't think 1 vs N is very different from the question
> >>>>> of 0 vs 1 though, somehow the tools need to know about the pITS setup.
> >>>>
> >>>> I don't see why the tools would require to know the pITS setup.
> >>>
> >>> Even with only a single vits the tools need to know if the system has 0,
> >>> 1, or more pits, to know whether to vreate a vits at all or not.
> >>
> >> In the 1 vITS solution no, it's only necessary to add a new gic define
> >> for the gic_version field in xen_arch_domainconfig.
> > 
> > Would we expose a vITS to guests on a host which has no pITS at all?
> 
> No, Xen will check if we can support vITS. See an example with my "GICv2
> on GICv3" series. Obviously, we don't allow vGICv3 on GICv2.

Did you mean to refer to "arm: Allow the user to specify the GIC
version" or some other part of that series?

I suppose you are proposing a new flag vits=yes|no passed as part of the
domain config which Xen can then update to indicate yes or no? Or is
there more to it than that? Could Xen not equally well expose nr_vits
back to the tools?

Ian.


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