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

[PATCH v4 3/6] x86/PVH: permit more physdevop-s to be used by Dom0


  • To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 29 Sep 2021 15:14:13 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Le5BJdNW9ne/Xmuzk0IFXev47snchE6r7a8FNfwFXaI=; b=gQpLzv+oOu6U5g7uL1B8nU321iyQ6d7bKLQKBSnBGFRe69dOiMPKKKwi4FqGrNmM3vcACEo7M7u/64e4VzeTmebefSdw+bcUHPsopXr7z1XKXqF50RAF95DuKmCfGTPkc+UXtbvaNnnVUi+0ujaxQJlz1A7ge2dGkZXulVVutTon9YwfGIg9Nu5Z9PWx3eVoUspTzPPfHakX3zweGDg7fJasoouZP5KQpeE/LOYK5TLt4l5v8B1dXusbWSZZ2H0CXk9LhrfEcQ4sFOVEghgK8XwPNc1R3bGxjnDLetAJIG0vklz53oVGZirFHZbDbGdzT2X4M+ZtPGAu2q5MXZ9xAg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Pa70P8gc42nrhMzTduy6SDxlH5qd3UO/ngbw/+cAe3IVXwkSZ2qKjkip8D+/unc72MTUZfnmodjNlqdszToP9P4NN0d4DuF6r1mciUUBpO62X25urL4zcSLYpen2xxvu2SoFWAt/HZaikGyMldbuBDDVzEASmH6DHuZCR8lcfqN6Qr9nPJLgT+mDTsOqjeK6+gUhAcXNkanVUwwjVXbqHGtcePYgoBdrATgqkTmJVN2BkIuDS4EFYkVRo8D8I4caRxy/C4ytq/3Gxe+soqv+VqnnhD0jpQB0GYP/e+6ibDKgLNmpDu71b9ZXRkFRAigCJbMc4IPuaA0LjghRVomeyg==
  • Authentication-results: citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Wed, 29 Sep 2021 13:14:20 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Certain notifications of Dom0 to Xen are independent of the mode Dom0 is
running in. Permit further PCI related ones (only their modern forms).
Also include the USB2 debug port operation at this occasion.

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
---
I'm uncertain about the has_vpci() part of the check: I would think
is_hardware_domain() is both sufficient and concise. Without vPCI a PVH
Dom0 won't see any PCI devices in the first place (and hence would
effectively be non-functioning). Dropping this would in particular make
PHYSDEVOP_dbgp_op better fit in the mix.
---
v3: New.

--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -94,6 +94,12 @@ static long hvm_physdev_op(int cmd, XEN_
         break;
 
     case PHYSDEVOP_pci_mmcfg_reserved:
+    case PHYSDEVOP_pci_device_add:
+    case PHYSDEVOP_pci_device_remove:
+    case PHYSDEVOP_restore_msi_ext:
+    case PHYSDEVOP_dbgp_op:
+    case PHYSDEVOP_prepare_msix:
+    case PHYSDEVOP_release_msix:
         if ( !has_vpci(currd) || !is_hardware_domain(currd) )
             return -ENOSYS;
         break;




 


Rackspace

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