From patchwork Fri Mar 24 13:40:25 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paul Durrant X-Patchwork-Id: 9642841 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 7F0D16020B for ; Fri, 24 Mar 2017 13:42:49 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6D12327E5A for ; Fri, 24 Mar 2017 13:42:49 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 618E227F17; Fri, 24 Mar 2017 13:42:49 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id EA6DE27E5A for ; Fri, 24 Mar 2017 13:42:47 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1crPSB-0003i3-1A; Fri, 24 Mar 2017 13:40:31 +0000 Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1crPSA-0003hx-2f for xen-devel@lists.xenproject.org; Fri, 24 Mar 2017 13:40:30 +0000 Received: from [193.109.254.147] by server-11.bemta-6.messagelabs.com id 85/46-04971-DC125D85; Fri, 24 Mar 2017 13:40:29 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRWlGSWpSXmKPExsXitHRDpO4Zxas RBsemW1l83zKZyYHR4/CHKywBjFGsmXlJ+RUJrBmXGl6zFRxQrjj38z9TA+M+6S5GTg4JAX+J pcdXsYDYbAI6ElOfXmIFsUUEbCX6v38Hsjk4mAXCJS5PsgIJCws4S/x4MIkJxGYRUJU4tHIZm M0r4C6x5flVdoiRchLnj/9kBrGFBFQk1k+dxQZRIyhxcuYTsFXMAhISB1+8YJ7AyD0LSWoWkt QCRqZVjBrFqUVlqUW6hsZ6SUWZ6RkluYmZObqGBmZ6uanFxYnpqTmJScV6yfm5mxiBocAABDs YvywLOMQoycGkJMrrtu1KhBBfUn5KZUZicUZ8UWlOavEhRhkODiUJ3q0KVyOEBItS01Mr0jJz gEEJk5bg4FES4X0MkuYtLkjMLc5Mh0idYtTlmDN79xsmIZa8/LxUKXHeGpAiAZCijNI8uBGwC LnEKCslzMsIdJQQT0FqUW5mCar8K0ZxDkYlYd63IFN4MvNK4Da9AjqCCeiI2RuugBxRkoiQkm pgVP6X7RnYrFxaV6fgd+pIVqTsvhnsjtOd1S02Hz36nWephcTHojvz0rX/hq2Y4sKmYX/r027 DD08WFRQ940p+smv9vK/F5eG75e+2//yn3WY22afO8MT50kspVXKr625K3dbXeBO15oOU4fSp H487xj74dFLqu8isLInQcLaO8q0f2ItyWHOuK7EUZyQaajEXFScCAFPqDJOLAgAA X-Env-Sender: prvs=249263d75=Paul.Durrant@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1490362827!81123997!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 9.2.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 54039 invoked from network); 24 Mar 2017 13:40:28 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 24 Mar 2017 13:40:28 -0000 X-IronPort-AV: E=Sophos;i="5.36,215,1486425600"; d="scan'208";a="415738598" From: Paul Durrant To: , Date: Fri, 24 Mar 2017 13:40:25 +0000 Message-ID: <1490362825-24854-1-git-send-email-paul.durrant@citrix.com> X-Mailer: git-send-email 2.1.4 MIME-Version: 1.0 Cc: Anthony Perard , Paul Durrant Subject: [Xen-devel] [PATCH v3] xen-platform: separate unplugging of NVMe disks X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP Commit 090fa1c8 "add support for unplugging NVMe disks..." extended the existing disk unplug flag to cover NVMe disks as well as IDE and SCSI. The recent thread on the xen-devel mailing list [1] has highlighted that this is not desirable behaviour: PV frontends should be able to distinguish NVMe disks from other types of disk and should have separate control over whether they are unplugged. This patch defines a new bit in the unplug mask for this purpose (see Xen commit [2]) and also tidies up the definitions of, and improves the comments regarding, the previously exiting bits in the protocol. [1] https://lists.xen.org/archives/html/xen-devel/2017-03/msg02924.html [2] http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=1096aa02 Signed-off-by: Paul Durrant Reviewed-by: Stefano Stabellini --- Cc: Anthony Perard v3: - Updated to reference Xen documentation patch v2: - Fix the commit comment --- hw/i386/xen/xen_platform.c | 47 ++++++++++++++++++++++++++++++++++------------ 1 file changed, 35 insertions(+), 12 deletions(-) diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c index 6010f35..983d532 100644 --- a/hw/i386/xen/xen_platform.c +++ b/hw/i386/xen/xen_platform.c @@ -87,10 +87,30 @@ static void log_writeb(PCIXenPlatformState *s, char val) } } -/* Xen Platform, Fixed IOPort */ -#define UNPLUG_ALL_DISKS 1 -#define UNPLUG_ALL_NICS 2 -#define UNPLUG_AUX_IDE_DISKS 4 +/* + * Unplug device flags. + * + * The logic got a little confused at some point in the past but this is + * what they do now. + * + * bit 0: Unplug all IDE and SCSI disks. + * bit 1: Unplug all NICs. + * bit 2: Unplug IDE disks except primary master. This is overridden if + * bit 0 is also present in the mask. + * bit 3: Unplug all NVMe disks. + * + */ +#define _UNPLUG_IDE_SCSI_DISKS 0 +#define UNPLUG_IDE_SCSI_DISKS (1u << _UNPLUG_IDE_SCSI_DISKS) + +#define _UNPLUG_ALL_NICS 1 +#define UNPLUG_ALL_NICS (1u << _UNPLUG_ALL_NICS) + +#define _UNPLUG_AUX_IDE_DISKS 2 +#define UNPLUG_AUX_IDE_DISKS (1u << _UNPLUG_AUX_IDE_DISKS) + +#define _UNPLUG_NVME_DISKS 3 +#define UNPLUG_NVME_DISKS (1u << _UNPLUG_NVME_DISKS) static void unplug_nic(PCIBus *b, PCIDevice *d, void *o) { @@ -111,7 +131,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d, void *opaque) { uint32_t flags = *(uint32_t *)opaque; bool aux = (flags & UNPLUG_AUX_IDE_DISKS) && - !(flags & UNPLUG_ALL_DISKS); + !(flags & UNPLUG_IDE_SCSI_DISKS); /* We have to ignore passthrough devices */ if (!strcmp(d->name, "xen-pci-passthrough")) { @@ -124,12 +144,16 @@ static void unplug_disks(PCIBus *b, PCIDevice *d, void *opaque) break; case PCI_CLASS_STORAGE_SCSI: - case PCI_CLASS_STORAGE_EXPRESS: if (!aux) { object_unparent(OBJECT(d)); } break; + case PCI_CLASS_STORAGE_EXPRESS: + if (flags & UNPLUG_NVME_DISKS) { + object_unparent(OBJECT(d)); + } + default: break; } @@ -147,10 +171,9 @@ static void platform_fixed_ioport_writew(void *opaque, uint32_t addr, uint32_t v switch (addr) { case 0: { PCIDevice *pci_dev = PCI_DEVICE(s); - /* Unplug devices. Value is a bitmask of which devices to - unplug, with bit 0 the disk devices, bit 1 the network - devices, and bit 2 the non-primary-master IDE devices. */ - if (val & (UNPLUG_ALL_DISKS | UNPLUG_AUX_IDE_DISKS)) { + /* Unplug devices. See comment above flag definitions */ + if (val & (UNPLUG_IDE_SCSI_DISKS | UNPLUG_AUX_IDE_DISKS | + UNPLUG_NVME_DISKS)) { DPRINTF("unplug disks\n"); pci_unplug_disks(pci_dev->bus, val); } @@ -338,14 +361,14 @@ static void xen_platform_ioport_writeb(void *opaque, hwaddr addr, * If VMDP was to control both disk and LAN it would use 4. * If it controlled just disk or just LAN, it would use 8 below. */ - pci_unplug_disks(pci_dev->bus, UNPLUG_ALL_DISKS); + pci_unplug_disks(pci_dev->bus, UNPLUG_IDE_SCSI_DISKS); pci_unplug_nics(pci_dev->bus); } break; case 8: switch (val) { case 1: - pci_unplug_disks(pci_dev->bus, UNPLUG_ALL_DISKS); + pci_unplug_disks(pci_dev->bus, UNPLUG_IDE_SCSI_DISKS); break; case 2: pci_unplug_nics(pci_dev->bus);