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

[manish jaggi <manishjaggi.oss@xxxxxxxxx>]

On 2 October 2014 22:29, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxxxxx> wrote:
> 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?
>
Guest Passes passthrough devices stream id - which is generated by BDF
so a device with BDF (real ID) say 1:0:5.0 may at BDF 0:0:0.0 in
guest.
Xen ITS Emulation Code would need the information mapping between
guestBDF actual BDF of a passthrough device.

Guest ITS never sees real ID.

>
>> > >> >> 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