Re: [Xen-devel] [PATCH 09/28] ARM: GICv3 ITS: map device and LPIs to the ITS on physdev_op hypercall

[Julien Grall <julien.grall@xxxxxxx>]

On 24/02/2017 19:57, Shanker Donthineni wrote:
> Hi Julien,
Hi Shanker,

> On 01/31/2017 10:18 AM, Julien Grall wrote:
> > On 31/01/17 16:02, Jaggi, Manish wrote:
> > > On 1/31/2017 8:47 PM, Julien Grall wrote:
> > > > On 31/01/17 14:08, Jaggi, Manish wrote:
> > > > > Hi Julien,
> > > > >
> > > > > On 1/31/2017 7:16 PM, Julien Grall wrote:
> > > > > > On 31/01/17 13:19, Jaggi, Manish wrote:
> > > > > > > On 1/31/2017 6:13 PM, Julien Grall wrote:
> > > > > > > > On 31/01/17 10:29, Jaggi, Manish wrote:
> > > > > If you please go back to your comment where you wrote "we need to
> > > > > find another way to get the DeviceID", I was referring that we
> > > > > should add that another way in this series so that correct DeviceID
> > > > > is programmed in ITS.
> > > > This is not the first time I am saying this, just saying "we should
> > > > add that another way..." is not helpful. You should also provide
> > > > some details on what you would do.
> > > Julien, As you suggested we need to find another way, I assumed you
> > > had something in mind.
> > I gave suggestions on my e-mail but you may have missed it...
> >
> > > Since we both agree that sbdf!=deviceID, the current series of ITS
> > > patches will program the incorrect deviceID so there is a need to
> > > have a way to map sbdf with deviceID in xen.
> > >
> > > One option could be to add a new hypercall to supply sbdf and
> > > deviceID to xen.
> > ... as well as the part where I am saying that I am not in favor to
> > implement an hypercall temporarily, and against adding a new hypercall
> > for only a couple of weeks. As you may know PHYSDEV hypercall are part
> > of the stable ABI and once they are added they cannot be removed.
> >
> > So we need to be sure the hypercall is necessary. In this case, the
> > hypercall is not necessary as all the information can be found in the
> > firmware tables. However this is not implemented yet and part of the
> > discussion on PCI Passthrough (see [1]).
> >
> > We need a temporary solution that does not involve any commitment on the
> > ABI until Xen is able to discover PCI.
> Why can't  we handle ITS device creation whenever a virtual ITS driver
> receives the MAPD command from dom0/domU. In case of dom0, it's straight
> forward dom0 always passes the real ITS device through MAPD command.
I guess this can work. Note that, on a separate thread (see [1]), I 
suggested to decouple the virtual DeviceID to the physical one for DOM0 
to simply the generation of the IORT.
So we would have to be a bit more clever here. But that's probably a 
separate subject and can go in Xen in separate series.
> This way we can support PCIe devices without hard-coded MSI(x) limit 32,
> and platform devices transparently. I used the below code to platform
> and PCIe device MSI(x) functionality on QDF2400 server platform.
>
> @@ -383,10 +384,17 @@ static int its_handle_mapd(struct virt_its *its,
> uint64_t *cmdptr)
>      int size = its_cmd_get_size(cmdptr);
>      bool valid = its_cmd_get_validbit(cmdptr);
>      paddr_t itt_addr = its_cmd_mask_field(cmdptr, 2, 0, 52) &
> GENMASK(51, 8);
> +    int ret;
>
>      if ( !its->dev_table )
>          return -1;
>
> +    size = size < 4 ? 4 : size;
> +    ret = gicv3_its_map_guest_device(hardware_domain, devid, devid,
> size + 1,
> +                                     valid);
> +    if (ret < 0)
> +        return ret;
> +
Cheers,

[1] https://lists.xen.org/archives/html/xen-devel/2017-02/msg02782.html

--
Julien Grall

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