From nobody Wed Nov 27 06:48:19 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=1700567677; cv=none; d=zohomail.com; s=zohoarc; b=BZD8H16NTmkLDE9UF6VlM4rP+BRVrOy07cUx+AnApXBHaqi9wXFzX+8MhdkAqz8ISyWi0f12LEDbGq0qrsJlU+p2goyWffvlocJ/ObbmTmSi9GKYheoFw/qNpo1BAJfpux9i02z4dgCaLUFiQb92eJGNF1SaiqhkdUq6nmV/e1U= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1700567677; 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=0Ku6C++zJqvi5s7JjQEttBg89WdSDuViyFjlGk+UHms=; b=XBXgyufIP8djMjIIhvmyfyGZgFgHpYul7tZ5+hef1jQIDfNrgH3VswD5ihNDk98qlq65IRdsQ18TvSqxr2Hh9LBRqvSMW/NwIc7TlAl1WvM+IdvbYCGtVD8FV2Atc+eEOq9HK8lhIC41gzmqD04m+aOhEO5NJ8a+l2l79HJS98U= 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 1700567677357811.0164736516413; Tue, 21 Nov 2023 03:54:37 -0800 (PST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r5PJc-0003OE-1L; Tue, 21 Nov 2023 06:53:16 -0500 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 1r5PJa-0003NL-4C for qemu-devel@nongnu.org; Tue, 21 Nov 2023 06:53:14 -0500 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 1r5PJX-0004GG-9w for qemu-devel@nongnu.org; Tue, 21 Nov 2023 06:53:13 -0500 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-512-AR0zMI3xMauSFLQ_955ILw-1; Tue, 21 Nov 2023 06:53:08 -0500 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (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 mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3E70D80513E; Tue, 21 Nov 2023 11:53:08 +0000 (UTC) Received: from merkur.fritz.box (unknown [10.39.194.112]) by smtp.corp.redhat.com (Postfix) with ESMTP id 47B2C492BFC; Tue, 21 Nov 2023 11:53:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1700567590; 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=0Ku6C++zJqvi5s7JjQEttBg89WdSDuViyFjlGk+UHms=; b=PgR9c03QRCqaCLiQEi5p01+VSKEIc8iQMvYBqFrszI8HQ0WniYGC638HjM35ifEyEJScVz vFaBuH7UFC/lwgRXcMZ5dl5rdghWqynaTY9Khk3HYKCf31eh0+O01B1MRk4CDSHNQM/2hU PRYzX06/SjsJZ0iylGmreg+NYcui6xg= X-MC-Unique: AR0zMI3xMauSFLQ_955ILw-1 From: Kevin Wolf To: qemu-block@nongnu.org Cc: kwolf@redhat.com, qemu-devel@nongnu.org Subject: [PULL 1/9] hw/ide/ahci: fix legacy software reset Date: Tue, 21 Nov 2023 12:52:54 +0100 Message-ID: <20231121115302.52214-2-kwolf@redhat.com> In-Reply-To: <20231121115302.52214-1-kwolf@redhat.com> References: <20231121115302.52214-1-kwolf@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.10 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: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.035, 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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: 1700567679121100003 Content-Type: text/plain; charset="utf-8" From: Niklas Cassel Legacy software contains a standard mechanism for generating a reset to a Serial ATA device - setting the SRST (software reset) bit in the Device Control register. Serial ATA has a more robust mechanism called COMRESET, also referred to as port reset. A port reset is the preferred mechanism for error recovery and should be used in place of software reset. Commit e2a5d9b3d9c3 ("hw/ide/ahci: simplify and document PxCI handling") improved the handling of PxCI, such that PxCI gets cleared after handling a non-NCQ, or NCQ command (instead of incorrectly clearing PxCI after receiving anything - even a FIS that failed to parse, which should NOT clear PxCI, so that you can see which command slot that caused an error). However, simply clearing PxCI after a non-NCQ, or NCQ command, is not enough, we also need to clear PxCI when receiving a SRST in the Device Control register. A legacy software reset is performed by the host sending two H2D FISes, the first H2D FIS asserts SRST, and the second H2D FIS deasserts SRST. The first H2D FIS will not get a D2H reply, and requires the FIS to have the C bit set to one, such that the HBA itself will clear the bit in PxCI. The second H2D FIS will get a D2H reply once the diagnostic is completed. The clearing of the bit in PxCI for this command should ideally be done in ahci_init_d2h() (if it was a legacy software reset that caused the reset (a COMRESET does not use a command slot)). However, since the reset value for PxCI is 0, modify ahci_reset_port() to actually clear PxCI to 0, that way we can avoid complex logic in ahci_init_d2h(). This fixes an issue for FreeBSD where the device would fail to reset. The problem was not noticed in Linux, because Linux uses a COMRESET instead of a legacy software reset by default. Fixes: e2a5d9b3d9c3 ("hw/ide/ahci: simplify and document PxCI handling") Reported-by: Marcin Juszkiewicz Signed-off-by: Niklas Cassel Message-ID: <20231108222657.117984-1-nks@flawful.org> Reviewed-by: Kevin Wolf Tested-by: Marcin Juszkiewicz Signed-off-by: Kevin Wolf --- hw/ide/ahci.c | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c index 7676e2d871..afdc44b8e0 100644 --- a/hw/ide/ahci.c +++ b/hw/ide/ahci.c @@ -623,9 +623,13 @@ static void ahci_init_d2h(AHCIDevice *ad) return; } =20 + /* + * For simplicity, do not call ahci_clear_cmd_issue() for this + * ahci_write_fis_d2h(). (The reset value for PxCI is 0.) + */ if (ahci_write_fis_d2h(ad, true)) { ad->init_d2h_sent =3D true; - /* We're emulating receiving the first Reg H2D Fis from the device; + /* We're emulating receiving the first Reg D2H FIS from the device; * Update the SIG register, but otherwise proceed as normal. */ pr->sig =3D ((uint32_t)ide_state->hcyl << 24) | (ide_state->lcyl << 16) | @@ -663,6 +667,7 @@ static void ahci_reset_port(AHCIState *s, int port) pr->scr_act =3D 0; pr->tfdata =3D 0x7F; pr->sig =3D 0xFFFFFFFF; + pr->cmd_issue =3D 0; d->busy_slot =3D -1; d->init_d2h_sent =3D false; =20 @@ -1242,10 +1247,30 @@ static void handle_reg_h2d_fis(AHCIState *s, int po= rt, case STATE_RUN: if (cmd_fis[15] & ATA_SRST) { s->dev[port].port_state =3D STATE_RESET; + /* + * When setting SRST in the first H2D FIS in the reset seq= uence, + * the device does not send a D2H FIS. Host software thus = has to + * set the "Clear Busy upon R_OK" bit such that PxCI (and = BUSY) + * gets cleared. See AHCI 1.3.1, section 10.4.1 Software R= eset. + */ + if (opts & AHCI_CMD_CLR_BUSY) { + ahci_clear_cmd_issue(ad, slot); + } } break; case STATE_RESET: if (!(cmd_fis[15] & ATA_SRST)) { + /* + * When clearing SRST in the second H2D FIS in the reset + * sequence, the device will execute diagnostics. When thi= s is + * done, the device will send a D2H FIS with the good stat= us. + * See SATA 3.5a Gold, section 11.4 Software reset protoco= l. + * + * This D2H FIS is the first D2H FIS received from the dev= ice, + * and is received regardless if the reset was performed b= y a + * COMRESET or by setting and clearing the SRST bit. There= fore, + * the logic for this is found in ahci_init_d2h() and not = here. + */ ahci_reset_port(s, port); } break; --=20 2.42.0