Re: [Xen-devel] [RFC + Queries] Flow of PCI passthrough in ARM

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 2 Oct 2014, Stefano Stabellini wrote:
> > >> >> using this the ITS emulation code in xen is able to trap ITS command
> > >> >> writes by driver.
> > >> >> But we are facing a problem now, where your help is needed

Actually  given that you are talking about the virtual ITS, why do you
need the real Device ID or Stream ID of the passthrough device in the
guest at all?  Shouldn't you just be generating a bunch of virtual IDs
instead?

Let's take a step back: why do you need *real* IDs to program a
*virtual* ITS?


> > >> >> The StreamID is generated by segment: bus : device: number which is
> > >> >> fed as DevID in ITS commands. In Dom0 the streamID is correctly
> > >> >> generated but in domU the Stream ID for a passthrough device is
> > >> >> 0:0:0:0 now when emulating this in Xen it is a problem as xen does not
> > >> >> know how to get the physical stream id.
> > >> >>
> > >> >> (Eg: xl pci-attach 1 0001:00:05.0
> > >> >> DomU has the device but in DomU the id is 0000:00:00.0.)
> > >> >>
> > >> >> Could you suggest how to go about this.
> > >> >
> > >> > I don't think that the ITS patches have been posted yet, so it is
> > >> > difficult for me to understand the problem and propose a solution.
> > >>
> > >> In a simpler way, It is more of what the StreamID a driver running in
> > >> domU sees. Which is programmed in the ITS commands.
> > >> And how to map the domU  streamID to actual streamID in Xen when the
> > >> ITS command write traps.
> > >
> > > Wouldn't it be possible to pass the correct StreamID to DomU via device
> > > tree? Does it really need to match the PCI BDF?
> > Device Tree provide static mapping, runtime attaching a device (using
> > xl tools) to a domU is what I am working on.
> 
> As I wrote before it is difficult to answer without the patches and/or a
> design document.
> 
> You should be able to specify StreamID ranges in Device Tree to cover a
> bus. So you should be able to say that the virtual PCI bus in the guest
> has StreamID [0-8] for slots [0-8]. Then in your example below you need
> to make sure to insert the passthrough device in virtual slot 1 instead
> of virtual slot 0.
> 
> I don't know if you were aware of this but you can already specify the
> virtual slot number to pci-attach, see xl pci-attach --help
> 
> Otherwise you could let the frontend know the StreamID via xenbus: the
> backend should know the correct StreamID for the device, it could just
> add it to xenstore as a new parameter for the frontend.
> 
> Either way you should be able to tell the frontend what is the right
> StreamID for the device.
> 
> 
> > > Otherwise if the command trap into Xen, couldn't Xen do the translation?
> > Xen does not know how to map the BDF in domU to actual streamID.
> > 
> > I had thought of adding a hypercall,  when xl pci-attach is called.
> > PHYSDEVOP_map_streamid {
> >     dom_id,
> >     phys_streamid, //bdf
> >     guest_streamid,
> > }
> > 
> >  But I am not able to get correct BDF of domU.
> 
> I don't think that an hypercall is a good way to solve this.
> 
> 
> > For instance the logs at 2 different place give diff BDFs
> > 
> > #xl pci-attach 1 '0002:01:00.1,permissive=1'
> > 
> > xen-pciback pci-1-0: xen_pcibk_export_device exporting dom 2 bus 1 slot 0 
> > func 1
> > xen_pciback: vpci: 0002:01:00.1: assign to virtual slot 1
> > xen_pcibk_publish_pci_dev 0000:00:01.00
> > 
> > Code that generated print:
> > static int xen_pcibk_publish_pci_dev(struct xen_pcibk_device *pdev,
> >                                    unsigned int domain, unsigned int bus,
> >                                    unsigned int devfn, unsigned int devid)
> > {
> >     ...
> >         printk(KERN_ERR"%s %04x:%02x:%02x.%02x",__func__, domain, bus,
> >                             PCI_SLOT(devfn), PCI_FUNC(devfn));
> > 
> > 
> > While in xen_pcibk_do_op Print is:
> > 
> > xen_pcibk_do_op Guest SBDF=0:0:1.1 (this is output of lspci in domU)
> > 
> > Code that generated print:
> > 
> > void xen_pcibk_do_op(struct work_struct *data)
> > {
> >      ...
> >         if (dev == NULL)
> >                 op->err = XEN_PCI_ERR_dev_not_found;
> >         else {
> >         printk(KERN_ERR"%s Guest SBDF=%d:%d:%d.%d \r\n",__func__,
> > op->domain, op->bus, op->devfn>>3, op->devfn&0x7);
> > 
> > 
> > Stefano, I need your help in this
> 

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