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

Re: [RFC PATCH v1 2/4] xen/arm: Discovering PCI devices and add the PCI devices in XEN.



Hi,

On 24/07/2020 08:14, Oleksandr Andrushchenko wrote:

On 7/23/20 11:44 PM, Stefano Stabellini wrote:
On Thu, 23 Jul 2020, Rahul Singh wrote:
Hardware domain is in charge of doing the PCI enumeration and will
discover the PCI devices and then will communicate to XEN via hyper
call PHYSDEVOP_pci_device_add to add the PCI devices in XEN.

Change-Id: Ie87e19741689503b4b62da911c8dc2ee318584ac
Same question about Change-Id


Signed-off-by: Rahul Singh <rahul.singh@xxxxxxx>
---
   xen/arch/arm/physdev.c | 42 +++++++++++++++++++++++++++++++++++++++---
   1 file changed, 39 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/physdev.c b/xen/arch/arm/physdev.c
index e91355fe22..274720f98a 100644
--- a/xen/arch/arm/physdev.c
+++ b/xen/arch/arm/physdev.c
@@ -9,12 +9,48 @@
   #include <xen/errno.h>
   #include <xen/sched.h>
   #include <asm/hypercall.h>
-
+#include <xen/guest_access.h>
+#include <xsm/xsm.h>
int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
   {
-    gdprintk(XENLOG_DEBUG, "PHYSDEVOP cmd=%d: not implemented\n", cmd);
-    return -ENOSYS;
+    int ret = 0;
+
+    switch ( cmd )
+    {
+#ifdef CONFIG_HAS_PCI

In the cover letter you were saying "we are not enabling the HAS_PCI and HAS_VPCI 
flags for ARM".

Is this still valid?

+        case PHYSDEVOP_pci_device_add:
+            {
+                struct physdev_pci_device_add add;
+                struct pci_dev_info pdev_info;
+                nodeid_t node = NUMA_NO_NODE;
+
+                ret = -EFAULT;
+                if ( copy_from_guest(&add, arg, 1) != 0 )
+                    break;
+
+                pdev_info.is_extfn = !!(add.flags & XEN_PCI_DEV_EXTFN);
+                if ( add.flags & XEN_PCI_DEV_VIRTFN )
+                {
+                    pdev_info.is_virtfn = 1;
+                    pdev_info.physfn.bus = add.physfn.bus;
+                    pdev_info.physfn.devfn = add.physfn.devfn;
+                }
+                else
+                    pdev_info.is_virtfn = 0;
+
+                ret = pci_add_device(add.seg, add.bus, add.devfn,
+                                &pdev_info, node);
+
+                break;
+            }
+#endif
+        default:
+            gdprintk(XENLOG_DEBUG, "PHYSDEVOP cmd=%d: not implemented\n", cmd);
+            ret = -ENOSYS;
+    }
I think we should make the implementation common between arm and x86 by
creating xen/common/physdev.c:do_physdev_op as a shared entry point for
PHYSDEVOP hypercalls implementations. See for instance:

xen/common/sysctl.c:do_sysctl

and

xen/arch/arm/sysctl.c:arch_do_sysctl
xen/arch/x86/sysctl.c:arch_do_sysctl


Jan, Andrew, Roger, any opinions?


I think we can also have a look at [1] by Julien. That implementation,

IMO, had some thoughts on making Arm/x86 code common where possible

There are some ideas on how I would like to see the split, although they need some cleanup. :)

In particular, I was expecting some preparatory work to get the existing PCI code non-x86 specific.

Regarding the hypercall Stefano mentionned, I think it should be possible to make it common if we abstract the NUMA node lookup part.

Cheers,



[1] 
https://xenbits.xen.org/gitweb/?p=people/julieng/xen-unstable.git;a=shortlog;h=refs/heads/dev-pci


--
Julien Grall



 


Rackspace

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