From patchwork Thu Nov 2 13:31:15 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ladi Prosek X-Patchwork-Id: 10038753 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 12309602D8 for ; Thu, 2 Nov 2017 13:32:14 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 048BE28FAB for ; Thu, 2 Nov 2017 13:32:14 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id ED88428FBB; Thu, 2 Nov 2017 13:32:13 +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=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 819EB28FAB for ; Thu, 2 Nov 2017 13:32:12 +0000 (UTC) Received: from localhost ([::1]:60403 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAFbP-0004i8-Si for patchwork-qemu-devel@patchwork.kernel.org; Thu, 02 Nov 2017 09:32:11 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55149) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eAFai-0004hp-Cr for qemu-devel@nongnu.org; Thu, 02 Nov 2017 09:31:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eAFad-0006Nd-G5 for qemu-devel@nongnu.org; Thu, 02 Nov 2017 09:31:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53654) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eAFad-0006MT-Ai for qemu-devel@nongnu.org; Thu, 02 Nov 2017 09:31:23 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9E83465754 for ; Thu, 2 Nov 2017 13:31:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9E83465754 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lprosek@redhat.com Received: from dhcp-1-107.brq.redhat.com (unknown [10.43.2.153]) by smtp.corp.redhat.com (Postfix) with ESMTP id EEC385D96F; Thu, 2 Nov 2017 13:31:16 +0000 (UTC) From: Ladi Prosek To: qemu-devel@nongnu.org Date: Thu, 2 Nov 2017 14:31:15 +0100 Message-Id: <20171102133115.19195-1-lprosek@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 02 Nov 2017 13:31:21 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH] virtio-pci: Don't force Subsystem Vendor ID = Vendor ID X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: yvugenfi@redhat.com, vrozenfe@redhat.com, mst@redhat.com Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP The statement being removed doesn't change anything as virtio PCI devices already have Subsystem Vendor ID set to pci_default_sub_vendor_id (0x1af4), same as Vendor ID. And the Virtio spec does not require the two to be equal, either: "The PCI Subsystem Vendor ID and the PCI Subsystem Device ID MAY reflect the PCI Vendor and Device ID of the environment (for informational purposes by the driver)." Background: Following the recent virtio-win licensing change, several vendors are planning to ship their own certified version of Windows guest Virtio drivers, potentially taking advantage of Windows Update as a distribution channel. It is therefore critical that each vendor uses their own PCI Subsystem Vendor ID for Virtio devices to prevent drivers from other vendors binding to it. This would be trivially done by adding: k->subsystem_vendor_id = ... to virtio_pci_class_init(). Except for the problematic statement deleted by this patch, which reverts the Subsystem Vendor ID back to 0x1af4 for legacy devices for no good reason. Signed-off-by: Ladi Prosek --- hw/virtio/virtio-pci.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c index e92837c42b..cb74aa3d85 100644 --- a/hw/virtio/virtio-pci.c +++ b/hw/virtio/virtio-pci.c @@ -1589,8 +1589,6 @@ static void virtio_pci_device_plugged(DeviceState *d, Error **errp) return ; } /* legacy and transitional */ - pci_set_word(config + PCI_SUBSYSTEM_VENDOR_ID, - pci_get_word(config + PCI_VENDOR_ID)); pci_set_word(config + PCI_SUBSYSTEM_ID, virtio_bus_get_vdev_id(bus)); } else { /* pure virtio-1.0 */