From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a12138e089-fe3d4fc0-b585-4376-ad30-7be3b15e555f-000000@eu-central-1.amazonses.com> Received: from MRWPR03CU001.outbound.protection.outlook.com (mail-francesouthazon11021111.outbound.protection.outlook.com [40.107.130.111]) by lore.virtuozzo.com (Postfix) with ESMTPS id 432B2808A3 for ; Fri, 9 Oct 2026 15:12:25 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=b2H6fG9iQbntfcBPj0X4gli+DRsyroNhELpLjoUp86w0B0f32n3yzeKTm2t7INo54jyVnsh5sJnwidwHEM8asWWe4wFBYXlsbaMmhJ+ylEYYhuZNBZpYRrK4yLLP5civP2Ej+0Sro8GjiUYiI+4bxMKSbHNxs9HmX1M763QGtdPL4n6HJAMo8GdpE0Vt+n6yOCFwrSFmCohNrqRJaJ5zZEjVUhWUABee83Y0zXYO6rKTW9lgibre1FmoHn9CrPMfGH9SeZNTMk9ZGIz0PsVMD0c3qQ85yU9shwli+FmX9C68EKOSs4wsyajgRHvqGKHQHKd/DtVk0kylIj2s1XI29g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gTzjcIPfGQ4Yzn9twOgcn4ZM4PKSiKRcJyyg25ErsqQ=; b=XzxsMYpvmW/k7MmcqK48yoSoJhUyG5L3yuucuI6SC6L9p/A5cYofdocTP08vYZxe3anskOAOlmraQy8UEMzZoV1xcHHyhtx1gAbgoBHFEiPP7j8uGPtf69zaFscWExEp2UfnAMPy7u3wUEqVRSAJS4htlz0KGZAeXDkhUyqd+k0h6sLcke/wqZIPf92W92XNNSzkMfZQW4JOl3gpFNsHYuzuCRFUbXl3NM5MO8LCGvr1itDMl8ZNJKyDvYT3LUQ3/NjdVbtLHMRg7j2VU2UY6J8C/u1V1YhnGUii5p9pz/gEfNrtdJQuDXrSv02N5dBkufytcy90jdyL8B5zmHztBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 69.169.224.5) smtp.rcpttodomain=virtuozzo.com smtp.mailfrom=eu-central-1.amazonses.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=sashiko.virtuozzo.com; dkim=pass (signature was verified) header.d=sashiko.virtuozzo.com; dkim=pass (signature was verified) header.d=amazonses.com; arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuozzo.onmicrosoft.com; s=selector2-virtuozzo-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gTzjcIPfGQ4Yzn9twOgcn4ZM4PKSiKRcJyyg25ErsqQ=; b=fEktzATquaKI1b0htx+YY124If8Sx6ggtGY2c5PdlGUxH66XEw3lK5ionM7NJNRrGtRegJUP1IHavKcVVKccx3t9W1dNgxTQFLbXS+b7yhHAOyNZcyykwd2Ef+NRy55I5KEhsKbq12vT5dDTWYdJqsGIdfPcLgLvvdUotEiq2nU= Received: from DU7P189CA0030.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:552::34) by AS8PR08MB9195.eurprd08.prod.outlook.com (2603:10a6:20b:57f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.14; Fri, 9 Oct 2026 15:12:20 +0000 Received: from DU6PEPF0000A7E2.eurprd02.prod.outlook.com (2603:10a6:10:552:cafe::7c) by DU7P189CA0030.outlook.office365.com (2603:10a6:10:552::34) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.21 via Frontend Transport; Fri, 9 Oct 2026 15:12:19 +0000 Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 69.169.224.5) smtp.mailfrom=eu-central-1.amazonses.com; dkim=pass (signature was verified) header.d=sashiko.virtuozzo.com;dkim=pass (signature was verified) header.d=amazonses.com;dmarc=pass action=none header.from=sashiko.virtuozzo.com; Received-SPF: Pass (protection.outlook.com: domain of eu-central-1.amazonses.com designates 69.169.224.5 as permitted sender) receiver=protection.outlook.com; client-ip=69.169.224.5; helo=b224-5.smtp-out.eu-central-1.amazonses.com; pr=C Received: from b224-5.smtp-out.eu-central-1.amazonses.com (69.169.224.5) by DU6PEPF0000A7E2.mail.protection.outlook.com (10.167.8.42) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.6 via Frontend Transport; Fri, 9 Oct 2026 15:12:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1791558738; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=FawRinvs3o3XeKkjje6OnLZFpwRzNOjxnkiArw6uYLI=; b=tJ37DUrjRFOajrH5Wh9c8baJntjxFdnai6GQ4uyg0wSdQaYf1XETK83UjVqWeKTb EzcsdnMGk9KF/CvKx36LL6XIOCRmGFP7awQpwpEooPfN+r5utTxlGcCbYQuLwZUOL80 MEaIn6yklPLP9gBZKU94D1N24CghELIl177dTvBL2DbHYquG6lirmdovfvbjeI9NOck FTFNYJ4GuBxFokf9yyCuNEscuRA4IrPlpfsgDDCv9OlcL3IzocO0M6pJ5cNi1PMlczl Ts44eQv3edwlywFZaowJJ6f8bw6QUquzc5xphg/dpxmpIwyBxWpBwbwFWhfnPpsqCz3 kCXPmFSo7w== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1791558738; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=FawRinvs3o3XeKkjje6OnLZFpwRzNOjxnkiArw6uYLI=; b=PMJ+hFvIDWUdvYfwR4iM8PE5GG/IFwXwX6Mr3cFUhO9KkJF+KtimrhwW8iM2XN+s XG7/1G2v4jL4TawGPDmPFgDnnaDovDpcjQg7bO22xYPK6jaY3yjtyKHXBgoHOIabKBR kiHbV/mZ+vVXiTLV8EMmKJf5lQzZBOkQYgS0Le0c= Message-ID: <010701a12138e089-fe3d4fc0-b585-4376-ad30-7be3b15e555f-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.1 07/21] q35: Fix migration of SMRAM state To: svt-core@virtuozzo.com, Andrey Drobyshev In-Reply-To: <20261009-vfio_v1-v1-7-2ae91d5b8048@virtuozzo.com> References: <20261009-vfio_v1-v1-0-2ae91d5b8048@virtuozzo.com> <20261009-vfio_v1-v1-7-2ae91d5b8048@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Oct 2026 15:12:18 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.09-69.169.224.5 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU6PEPF0000A7E2:EE_|AS8PR08MB9195:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: b38505c1-b643-41f8-0b5f-08df2617b5ef X-LD-Processed: 0bc7f26d-0264-416e-a6fc-8352af79c58f,ExtAddr X-MS-Exchange-AtpMessageProperties: SA List-Id: svt-core@virtuozzo.com X-MS-Exchange-Transport-Rules-Loop: 1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|704162111799003|704161411799003|9140799003|61400799027|376014|48200799018|32142699015|5113699003|5063699009|4113699003|4143699003|56012099006|10067099003|18002099003|22082099003|13003099007|55112099003|16102099003; X-Microsoft-Antispam-Message-Info: KwUx3CxS52HHSXIT0aoghTxZlIijVfigsvcOFrHHqYeNQZKcpPW+/IXj7VOt3oTHpaWIwSHmgZyfW1j/9sOJbN4ArshXGPeyfPIQrelNHvX3jQQPEES8QHL2vzm/fBmAIDxN8wKzedrx0y4z1CE9yq6VoIXN/ljXGBla7Eb+tXRgl4Ii7lE0x6pYj6awd3wDOx79psQFIBeVAjLMDp1ISuIVW4KMboOC6DYzpbLScf3RVyHT/u0GrzUx6+IRAgtMqOq9lHhGhdUhBQNzGyD9WYj3Y+5caWhxd5WoB/nmNaJgmTybB42YAu76o34j0EW6HLmIMsSn2HD/PaoRlZg+kudhiF7G/POGjB4v8mPSZ8t19lR1o5H9ZJJ7oRhXkmbahg79OlwKZ5/IvASagiWg3xJuxkOu3d4CxLzwYvhMi5ewRjCYiRgd+adV+BGh6QT+9q5w2UkvsExSPvdiTBGMHwYTObs3YgnUY3iGL8tixbnaS3X/xZI6j16ffj3tpFWTqWaRIB9cCOTK1qh4kh8jTFicryx3CBtCksBPy7Ewm0/t6Ttlj8nsgTGAYH0XPWAA0kGuK6xv3duN26BjiK/mELQTh8xkJF14wNFuTj5zNqoRNWVGQ+RAwMIrFQvPKJhSDLJz0ElgNs9WpTOrdJ8R8/rYcB271ilJhO2moUmszQG+1//h6wGYsicTQCXALavAGW/SPJmca2bSuYWpNjTRehTi9Tc6v8+N4jIydXBpHBNUdFFRiE5k54aEpB4XoRcBk5Suwf1A6k4G2OUwOEfBppTLSwjBeSLbxJavdHJik9iAejuWaZ5JoFae50MZ0hzmayRiMZ3s3zT6Jvk1JoeEM/+MjBMttrSjr8V/JrVZOF24GS4s2juYCx2r3aMZeJc4gDHUHE6Bxm8ztlzXLwEU4JO6UUNycmUPYh79PU8vLkVygwxGxgzzNgfTgycxK3Gc X-Forefront-Antispam-Report: CIP:69.169.224.5;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:b224-5.smtp-out.eu-central-1.amazonses.com;PTR:b224-5.smtp-out.eu-central-1.amazonses.com;CAT:NONE;SFS:(13230040)(704162111799003)(704161411799003)(9140799003)(61400799027)(376014)(48200799018)(32142699015)(5113699003)(5063699009)(4113699003)(4143699003)(56012099006)(10067099003)(18002099003)(22082099003)(13003099007)(55112099003)(16102099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: WEEQGR3aIwpiW0fp7oTfoMAv1wxDp3056g0/0zyPxJOBw/HkNgxLAl9iQLWbfsP1af5VJfzB3ts4yEvkp1NqgwZw+tsdZUzvFszPWMOpd+mQIhjGLRP/vegE1sS1rJdu/XKP7jGYX5vklpY5TV5cRkjCau6XRUsrJmCUNPhLQ8dZ7TUHyHL9vwuB7wb+4Sfdp0ACjIdJqkMKDTdQJQJQnJvVHsxuFqB/LYloTnEOmzFznLiUcay4trKKaBILJsmQZ0hUlqi46W5xC+FKBtzZHoHWJHqnWw70pK9HF+LVRoj3pejWYau9+/U/odEG2gSI6MhCkgmpbip4Q0TB7SbkuA2wEjQ6YJVdgdhQIxInQSJsWYYNjR2dcjGv02jAyKula1bTZupJv2tXYSkJIIbq34j7fYCqGppVWBGd8HzHHC7ns4Q51bY9WVJ5DCh37xmP X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Oct 2026 15:12:18.5313 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b38505c1-b643-41f8-0b5f-08df2617b5ef X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: DU6PEPF0000A7E2.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB9195 Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: - [Low] q35: mch_update_smbase_smram() locks SMBASE on a pre-handshake writ= e with bit 1 set -- commit ba3fa220214fc6ee0a78056885c0b2f72b87e024 Author: Igor Mammedov q35: Fix migration of SMRAM state This patch stops mch_update_smbase_smram() from clearing the migrated MCH_HOST_BRIDGE_F_SMBASE value. It re-derives wmask from the register value instead, so a locked SMRAM state survives migration. It also removes the qtest check that junk written before the handshake reads back as 0. Link: https://patchew.org/QEMU/20251203180851.6390-1-arbn@yandex-team.com/ > diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c > --- a/hw/pci-host/q35.c > +++ b/hw/pci-host/q35.c [ ... ] > /* > - * default/reset state, discard written value > - * which will disable SMRAM balackhole at SMBASE > + * reg value can come from register write/reset/migration source, > + * update wmask to be in sync with it regardless of source > */ > - if (pd->wmask[MCH_HOST_BRIDGE_F_SMBASE] =3D=3D 0xff) { > - *reg =3D 0x00; > + if (*reg =3D=3D MCH_HOST_BRIDGE_F_SMBASE_IN_RAM) { > + pd->wmask[MCH_HOST_BRIDGE_F_SMBASE] =3D MCH_HOST_BRIDGE_F_SMBASE= _LCK; > + return; > } > - > - memory_region_transaction_begin(); > if (*reg & MCH_HOST_BRIDGE_F_SMBASE_LCK) { > - /* disable all writes */ > - pd->wmask[MCH_HOST_BRIDGE_F_SMBASE] &=3D > - ~MCH_HOST_BRIDGE_F_SMBASE_LCK; > + /* lock register at 0x2 and disable all writes */ > + pd->wmask[MCH_HOST_BRIDGE_F_SMBASE] =3D 0; > *reg =3D MCH_HOST_BRIDGE_F_SMBASE_LCK; > - lck =3D true; > - } else { > - lck =3D false; > } > + > + lck =3D *reg & MCH_HOST_BRIDGE_F_SMBASE_LCK; > + memory_region_transaction_begin(); > memory_region_set_enabled(&mch->smbase_blackhole, lck); > memory_region_set_enabled(&mch->smbase_window, lck); > memory_region_transaction_commit(); [Severity: Low] Can a guest now lock SMBASE without doing the 0xff handshake? After mch_reset(), config[0x9c] is 0 and wmask[0x9c] is 0xff. A guest config write of 0x02, 0x03 or 0xfe is stored by pci_default_write_config(), because wmask is 0xff. mch_write_config() then calls mch_update_smbase_smram(). The value is neither 0xff nor 0x01, so it reaches this branch: if (*reg & MCH_HOST_BRIDGE_F_SMBASE_LCK) { pd->wmask[MCH_HOST_BRIDGE_F_SMBASE] =3D 0; *reg =3D MCH_HOST_BRIDGE_F_SMBASE_LCK; } wmask becomes 0 and *reg becomes 0x02. smbase_blackhole and smbase_window are then enabled, so the 128K SMRAM window at SMBASE is black-holed until machine reset. The old wmask =3D=3D 0xff check discarded such a write and set *reg to 0. Other junk values are now stored as written, with no effect. Only the writing guest is affected, and a reset clears it. Firmware such as SeaBIOS and OVMF uses the 0xff query handshake first, so it is unaffected. The commit message describes this trade-off, and the change matches upstream QEMU 66cf169e29b0. Is this guest-visible change intended? The migration fix itself looks correct. mch_post_load() calls mch_update(), which calls mch_update_smbase_smram() and re-derives wmask from the migrated register value. A value of 0x01 gives wmask 0x02 with no black hole. A value of 0x02 gives wmask 0 with the black hole enabled. A value of 0 keeps the reset wmask of 0xff. > diff --git a/tests/qtest/q35-test.c b/tests/qtest/q35-test.c > --- a/tests/qtest/q35-test.c > +++ b/tests/qtest/q35-test.c > @@ -206,12 +206,6 @@ static void test_smram_smbase_lock(void) > qtest_writeb(qts, SMBASE, SMRAM_TEST_PATTERN); > g_assert_cmpint(qtest_readb(qts, SMBASE), =3D=3D, SMRAM_TEST_PATTERN= ); > =20 > - /* check that writing junk to 0x9c before before negotiating is igno= red */ > - for (i =3D 0; i < 0xff; i++) { > - qpci_config_writeb(pcidev, MCH_HOST_BRIDGE_F_SMBASE, i); > - g_assert(qpci_config_readb(pcidev, MCH_HOST_BRIDGE_F_SMBASE) =3D= =3D 0); > - } > - [Severity: Low] This isn't a bug, but the removed check is not replaced by anything. test_smram_smbase_lock() no longer covers a junk write before the handshake, or the new lock-on-junk behaviour where a value with bit 1 set locks the register. No test covers migration of the SMRAM state either. Could a test be added for these cases? --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261009-vfio= _v1-v1-0-2ae91d5b8048@virtuozzo.com?part=3D7