From nobody Sun Nov 24 16:54:25 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1722429292; cv=none; d=zohomail.com; s=zohoarc; b=XZZ1HSy1ISuAdnTWEDRz0lT/pf3H/xOyS9C6MXeGcVYgXYKk3EFf8MAkS+7qtA4b0Dc8dqIg7wIQDMLh1uIZSpCbt1tHD6+U/bHgWVVFWUD8gOf/hI1zQyg8pQ5pN+cjkDxuhMht6Nx27yRr6XD/kQsknSgM5F47lDf0xt/H0fQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1722429292; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=FOIXpdiXP48X03eoys7HTXHfkbmBuHCmyJnnxafRgkA=; b=bJnQsWZotMhgifem1Syx8Cd1opG3rWXtvvjgNnn8oP3XqO1o6lQp2DilyAeUm0IFVBNgbTOdjclSKRsbi7ER+fHV2osCGuPs+eAUUs3qZOVutNzvh55hduUM83AqmoQPEPIKSv0+G0neG7E5JT3JIHnGrdGqQBWoe6C5ok4dafA= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1722429292549954.6018008544702; Wed, 31 Jul 2024 05:34:52 -0700 (PDT) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sZ8VV-0002Yd-Hz; Wed, 31 Jul 2024 08:32:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sZ8VS-0002MG-0t for qemu-devel@nongnu.org; Wed, 31 Jul 2024 08:32:38 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sZ8VQ-00047U-5h for qemu-devel@nongnu.org; Wed, 31 Jul 2024 08:32:37 -0400 Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-518-Gk62xqpRNUynKS1g6Or1lw-1; Wed, 31 Jul 2024 08:32:32 -0400 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 7426C189A364; Wed, 31 Jul 2024 12:32:31 +0000 (UTC) Received: from merkur.redhat.com (unknown [10.39.194.1]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 08DA61955E92; Wed, 31 Jul 2024 12:32:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1722429155; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FOIXpdiXP48X03eoys7HTXHfkbmBuHCmyJnnxafRgkA=; b=AUNRzEkOdg6Xd1XnZbtqybWMD84Q6aVwjbVloAVHxNyCoBpWuG4ug1UjuvxY4yUFpMUuKv i3OdA+w+akXsUOif2tEuB3fvrFeh465Kz1XxqhUaGB/4pu5IEZynoOnpvLQugsPi9RXn6H s8sgM7tuMFlH2z8eHvE6GTJ1xAhLIyw= X-MC-Unique: Gk62xqpRNUynKS1g6Or1lw-1 From: Kevin Wolf To: qemu-block@nongnu.org Cc: kwolf@redhat.com, pbonzini@redhat.com, fam@euphon.net, stefanha@redhat.com, qemu-devel@nongnu.org Subject: [PATCH v2 4/4] scsi-disk: Always report RESERVATION_CONFLICT to guest Date: Wed, 31 Jul 2024 14:32:07 +0200 Message-ID: <20240731123207.27636-5-kwolf@redhat.com> In-Reply-To: <20240731123207.27636-1-kwolf@redhat.com> References: <20240731123207.27636-1-kwolf@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=170.10.133.124; envelope-from=kwolf@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -21 X-Spam_score: -2.2 X-Spam_bar: -- X-Spam_report: (-2.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.126, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1722429294520116600 Content-Type: text/plain; charset="utf-8" In the case of scsi-block, RESERVATION_CONFLICT is not a backend error, but indicates that the guest tried to make a request that it isn't allowed to execute. Pass the error to the guest so that it can decide what to do with it. Without this, if we stop the VM in response to a RESERVATION_CONFLICT (as is the default policy in management software such as oVirt or KubeVirt), it can happen that the VM cannot be resumed any more because every attempt to resume it immediately runs into the same error and stops the VM again. One case that expects RESERVATION_CONFLICT errors to be visible in the guest is running the validation tests in Windows 2019's Failover Cluster Manager, which intentionally tries to execute invalid requests to see if they are properly rejected. Buglink: https://issues.redhat.com/browse/RHEL-50000 Signed-off-by: Kevin Wolf --- hw/scsi/scsi-disk.c | 35 ++++++++++++++++++++++++++++++----- 1 file changed, 30 insertions(+), 5 deletions(-) diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c index 69a195177e..4d94b2b816 100644 --- a/hw/scsi/scsi-disk.c +++ b/hw/scsi/scsi-disk.c @@ -224,7 +224,7 @@ static bool scsi_handle_rw_error(SCSIDiskReq *r, int re= t, bool acct_failed) SCSIDiskState *s =3D DO_UPCAST(SCSIDiskState, qdev, r->req.dev); SCSIDiskClass *sdc =3D (SCSIDiskClass *) object_get_class(OBJECT(s)); SCSISense sense =3D SENSE_CODE(NO_SENSE); - int error =3D 0; + int error; bool req_has_sense =3D false; BlockErrorAction action; int status; @@ -235,11 +235,35 @@ static bool scsi_handle_rw_error(SCSIDiskReq *r, int = ret, bool acct_failed) } else { /* A passthrough command has completed with nonzero status. */ status =3D ret; - if (status =3D=3D CHECK_CONDITION) { + switch (status) { + case CHECK_CONDITION: req_has_sense =3D true; error =3D scsi_sense_buf_to_errno(r->req.sense, sizeof(r->req.= sense)); - } else { + break; + case RESERVATION_CONFLICT: + /* + * Don't apply the error policy, always report to the guest. + * + * This is a passthrough code path, so it's not a backend erro= r, but + * a response to an invalid guest request. + * + * Windows Failover Cluster validation intentionally sends inv= alid + * requests to verify that reservations work as intended. It is + * crucial that it sees the resulting errors. + * + * Treating a reservation conflict as a guest-side error is ob= vious + * when a pr-manager is in use. Without one, the situation is = less + * clear, but there might be nothing that can be fixed on the = host + * (like in the above example), and we don't want to be stuck = in a + * loop where resuming the VM and retrying the request immedia= tely + * stops it again. So always reporting is still the safer opti= on in + * this case, too. + */ + error =3D 0; + break; + default: error =3D EINVAL; + break; } } =20 @@ -249,8 +273,9 @@ static bool scsi_handle_rw_error(SCSIDiskReq *r, int re= t, bool acct_failed) * are usually retried immediately, so do not post them to QMP and * do not account them as failed I/O. */ - if (req_has_sense && - scsi_sense_buf_is_guest_recoverable(r->req.sense, sizeof(r->req.se= nse))) { + if (!error || (req_has_sense && + scsi_sense_buf_is_guest_recoverable(r->req.sense, + sizeof(r->req.sense= )))) { action =3D BLOCK_ERROR_ACTION_REPORT; acct_failed =3D false; } else { --=20 2.45.2