From patchwork Wed Apr 6 12:40:23 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Laszlo Ersek X-Patchwork-Id: 65178 Delivered-To: patch@linaro.org Received: by 10.112.199.169 with SMTP id jl9csp1027765lbc; Wed, 6 Apr 2016 05:41:23 -0700 (PDT) X-Received: by 10.66.237.33 with SMTP id uz1mr38724321pac.5.1459946467995; Wed, 06 Apr 2016 05:41:07 -0700 (PDT) Return-Path: Received: from ml01.01.org (ml01.01.org. [2001:19d0:306:5::1]) by mx.google.com with ESMTPS id c89si4445701pfj.79.2016.04.06.05.41.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Apr 2016 05:41:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of edk2-devel-bounces@lists.01.org designates 2001:19d0:306:5::1 as permitted sender) client-ip=2001:19d0:306:5::1; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of edk2-devel-bounces@lists.01.org designates 2001:19d0:306:5::1 as permitted sender) smtp.mailfrom=edk2-devel-bounces@lists.01.org Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 312881A1FCF; Wed, 6 Apr 2016 05:40:59 -0700 (PDT) X-Original-To: edk2-devel@ml01.01.org Delivered-To: edk2-devel@ml01.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id E5E9A1A1FD0 for ; Wed, 6 Apr 2016 05:40:56 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7F73364D0B; Wed, 6 Apr 2016 12:40:56 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com ([10.3.113.15]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u36CeV8Y027635; Wed, 6 Apr 2016 08:40:55 -0400 From: Laszlo Ersek To: edk2-devel-01 Date: Wed, 6 Apr 2016 14:40:23 +0200 Message-Id: <1459946427-15771-14-git-send-email-lersek@redhat.com> In-Reply-To: <1459946427-15771-1-git-send-email-lersek@redhat.com> References: <1459946427-15771-1-git-send-email-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 06 Apr 2016 12:40:56 +0000 (UTC) Subject: [edk2] [wave 3 PATCH v2 13/17] OvmfPkg: VirtioScsiDxe: adapt feature negotiation to virtio-1.0 X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Jordan Justen , Ard Biesheuvel MIME-Version: 1.0 Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" Relative to virtio-0.9.5, virtio-1.0 reverses the order of queue discovery and feature negotiation. In virtio-1.0, feature negotiation has to complete first, and the device can also reject a self-inconsistent feature request through the new VSTAT_FEATURES_OK status bit. (For example if the driver requests a higher level feature but clears a prerequisite feature.) Furthermore, we retain the VIRTIO_F_VERSION_1 feature bit if the VIRTIO_DEVICE_PROTOCOL provider has high enough revision. Cc: Ard Biesheuvel Cc: Jordan Justen Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Tested-by: Ard Biesheuvel Reviewed-by: Jordan Justen --- OvmfPkg/VirtioScsiDxe/VirtioScsi.c | 27 +++++++++++++++----- 1 file changed, 20 insertions(+), 7 deletions(-) -- 1.8.3.1 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel diff --git a/OvmfPkg/VirtioScsiDxe/VirtioScsi.c b/OvmfPkg/VirtioScsiDxe/VirtioScsi.c index 162577bcb961..c080404330e5 100644 --- a/OvmfPkg/VirtioScsiDxe/VirtioScsi.c +++ b/OvmfPkg/VirtioScsiDxe/VirtioScsi.c @@ -796,14 +796,27 @@ VirtioScsiInit ( // We must be able to halve it for bidirectional transfers // (see EFI_BAD_BUFFER_SIZE in PopulateRequest()). // Status = EFI_UNSUPPORTED; goto Failed; } + Features &= VIRTIO_SCSI_F_INOUT | VIRTIO_F_VERSION_1; + + // + // In virtio-1.0, feature negotiation is expected to complete before queue + // discovery, and the device can also reject the selected set of features. + // + if (Dev->VirtIo->Revision >= VIRTIO_SPEC_REVISION (1, 0, 0)) { + Status = Virtio10WriteFeatures (Dev->VirtIo, Features, &NextDevStat); + if (EFI_ERROR (Status)) { + goto Failed; + } + } + // // step 4b -- allocate request virtqueue // Status = Dev->VirtIo->SetQueueSel (Dev->VirtIo, VIRTIO_SCSI_REQUEST_QUEUE); if (EFI_ERROR (Status)) { goto Failed; } @@ -843,22 +856,22 @@ VirtioScsiInit ( // Status = Dev->VirtIo->SetQueueAddress (Dev->VirtIo, &Dev->Ring); if (EFI_ERROR (Status)) { goto ReleaseQueue; } // - // step 5 -- Report understood features and guest-tuneables. We want none of - // the known (or unknown) VIRTIO_SCSI_F_* or VIRTIO_F_* capabilities (see - // virtio-0.9.5, Appendices B and I), except bidirectional transfers. + // step 5 -- Report understood features and guest-tuneables. // - Status = Dev->VirtIo->SetGuestFeatures (Dev->VirtIo, - Features & VIRTIO_SCSI_F_INOUT); - if (EFI_ERROR (Status)) { - goto ReleaseQueue; + if (Dev->VirtIo->Revision < VIRTIO_SPEC_REVISION (1, 0, 0)) { + Features &= ~(UINT64)VIRTIO_F_VERSION_1; + Status = Dev->VirtIo->SetGuestFeatures (Dev->VirtIo, Features); + if (EFI_ERROR (Status)) { + goto ReleaseQueue; + } } // // We expect these maximum sizes from the host. Since they are // guest-negotiable, ask for them rather than just checking them. // Status = VIRTIO_CFG_WRITE (Dev, CdbSize, VIRTIO_SCSI_CDB_SIZE);