Re: [Xen-devel] PCI Pass-through in Xen ARM - Draft 2.

[Manish Jaggi <mjaggi@xxxxxxxxxxxxxxxxxx>]

On Monday 29 June 2015 04:01 PM, Julien Grall wrote:
> Hi Manish,
>
> On 28/06/15 19:38, Manish Jaggi wrote:
> > 4.1 Holes in guest memory space
> > ----------------------------
> > Holes are added in the guest memory space for mapping pci device's BAR
> > regions.
> > These are defined in arch-arm.h
> >
> > /* For 32bit */
> > GUEST_MMIO_HOLE0_BASE, GUEST_MMIO_HOLE0_SIZE
> >   
> > /* For 64bit */
> > GUEST_MMIO_HOLE1_BASE , GUEST_MMIO_HOLE1_SIZE
> The memory layout for 32bit and 64bit are exactly the same. Why do you
> need to differ here?
I think Ian has already replied. I will change the name of macro
> > 4.2 New entries in xenstore for device BARs
> > --------------------------------------------
> > toolkit also updates the xenstore information for the device
> > (virtualbar:physical bar).
> > This information is read by xenpciback and returned to the pcifront
> > driver configuration
> > space accesses.
> Can you details what do you plan to put in xenstore and how?
It is implementation . But I plan to put under domU / device / heirarchy
> What about the expansion ROM?
Do you want to put some restriction on not using expansion ROM as a 
passthrough device.
> > 4.3 Hypercall for bdf mapping notification to xen
> > -----------------------------------------------
> > #define PHYSDEVOP_map_sbdf              43
> > typedef struct {
> >      u32 s;
> >      u8 b;
> >      u8 df;
> >      u16 res;
> > } sbdf_t;
> > struct physdev_map_sbdf {
> >      int domain_id;
> >      sbdf_t    sbdf;
> >      sbdf_t    gsbdf;
> > };
> >
> > Each domain has a pdev list, which contains the list of all pci devices.
> > The
> > pdev structure already has a sbdf information. The arch_pci_dev is
> > updated to
> > contain the gsbdf information. (gs- guest segment id)
> >
> > Whenever there is trap from guest or an interrupt has to be injected,
> > the pdev
> > list is iterated to find the gsbdf.
> Can you give more background for this section? i.e:
>         - Why do you need this?
>         - How xen will translate the gbdf to a vDeviceID?
In the context of the hypercall processing.
>         - Who will call this hypercall?
>         - Why not setting the gsbdf when the device is assigned?
Can the maintainer of the pciback suggest an alternate.
The answer to your question is that I have only found a place to issue 
the hypercall where
all the information can be located is the function
__xen_pcibk_add_pci_dev


drivers/xen/xen-pciback/vpci.c
----
unlock:
...
                kfree(dev_entry);

+       /*Issue Hypercall here */
+#ifdef CONFIG_ARM64
+       map_sbdf.domain_id = pdev->xdev->otherend_id;
+       map_sbdf.sbdf_s = dev->bus->domain_nr;
+       map_sbdf.sbdf_b = dev->bus->number;
+       map_sbdf.sbdf_d = dev->devfn>>3;
+       map_sbdf.sbdf_f = dev->devfn & 0x7;
+       map_sbdf.gsbdf_s = 0;
+       map_sbdf.gsbdf_b = 0;
+       map_sbdf.gsbdf_d = slot;
+       map_sbdf.gsbdf_f = dev->devfn & 0x7;
+       pr_info("## sbdf = %d:%d:%d.%d g_sbdf %d:%d:%d.%d \
+                       domain_id=%d ##\r\n",
+                       map_sbdf.sbdf_s,
+                       map_sbdf.sbdf_b,
+                       map_sbdf.sbdf_d,
+                       map_sbdf.sbdf_f,
+                       map_sbdf.gsbdf_s,
+                       map_sbdf.gsbdf_b,
+                       map_sbdf.gsbdf_d,
+                       map_sbdf.gsbdf_f,
+                       map_sbdf.domain_id);
+
+       err = HYPERVISOR_physdev_op(PHYSDEVOP_map_sbdf, &map_sbdf);
+       if (err)
+               printk(KERN_ERR " Xen Error PHYSDEVOP_map_sbdf");
+#endif
---

> Regards,

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