[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.