From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from PA4PR04CU001.outbound.protection.outlook.com (mail-francecentralazon11023094.outbound.protection.outlook.com [40.107.162.94]) by lore.virtuozzo.com (Postfix) with ESMTPS id 656158017D for ; Mon, 2 Nov 2026 10:48:23 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=E9u8Cjcms5GqZ2DuFG30E6NVZdY3K2XBfNXghKacLaTtmDuxBeEpSxoattcths1gYsxr6qug8EyIuJkMJ9EZyPk2UEm2+lD6d8h6Wynjx8vmswf1pdx7YcbQvlB9mO4uKY/n7irxMhN8bO1fm2wlzoGgeDCV+iHwgP1ipmnxyVKpAQzJVWJbSqjBTfluKBedkiqFWziF84q52m5TJcrkoTs/aQf56DL3FIU2PERHYzlq23mCh2fzHHA8BwIQQ/9Dz4tCI97+pIZ+gSEMlJSTsx72a0frUdLK3PufTu24M6AjNa4uHuzDaOmd3X5b1AqlNCeymUQEv4HOKGoSDL/MOQ== 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=dRkCsQYnSRoFqcNEJM8dsa1pvia2sGIIdCar+VjiDCo=; b=MyhgyxBlPwX91ILUKYkK9ZOLNEoApmuWmI3uk8NxJQNlXw3sh1ypg4oe+0MenWYjsDEarPofwYncywSNrdRplWGtLVygTWd+2nCVNrsgCPLFPNGFMwYrzaloKd6hGBK7/7sMpffFO4u1HkPp+NdK5+cZ5YR2Nbxz3WVAk7rBP6yk/D9SwoGHTTqAfQMuHDnB3lab09y4QO5aProOuqEwUAz9znJoDbHBDhHrIrdC2vgBWwMDM56DH2p2VFuXsNhzc8k+q+kSQuT2GjPtou/EqsVoJxxtMOHWZdZiRJRqHAjoAowzgQQ1PAN5oOU52FCU1puFkTtlnc/glydDsksZlA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 69.169.224.1) 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=dRkCsQYnSRoFqcNEJM8dsa1pvia2sGIIdCar+VjiDCo=; b=NPiab4ZhUmi6m3q+qWlc4vjsukVAky7FnAfmQAqNOx2WlkBSlqiDdy2m0fgHzMzXuX0Ns/ZzrVWoaYBLsR/D/RUhYk9RiXtk9f3Y4/NttIwFOFA4QgQFR+YnIs/SKyry6N2ObYIzaFLSudlEtYFJDNF2wrMjbPdkaH+HvU8TUKk= Received: from DUZP191CA0043.EURP191.PROD.OUTLOOK.COM (2603:10a6:10:4f8::26) by AM0PR08MB5298.eurprd08.prod.outlook.com (2603:10a6:208:188::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.569.12; Mon, 2 Nov 2026 10:48:21 +0000 Received: from DB1PEPF000509EA.eurprd03.prod.outlook.com (2603:10a6:10:4f8:cafe::63) by DUZP191CA0043.outlook.office365.com (2603:10a6:10:4f8::26) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.22 via Frontend Transport; Mon, 2 Nov 2026 10:48:21 +0000 Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 69.169.224.1) 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.1 as permitted sender) receiver=protection.outlook.com; client-ip=69.169.224.1; helo=b224-1.smtp-out.eu-central-1.amazonses.com; pr=C Received: from b224-1.smtp-out.eu-central-1.amazonses.com (69.169.224.1) by DB1PEPF000509EA.mail.protection.outlook.com (10.167.242.68) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.592.5 via Frontend Transport; Mon, 2 Nov 2026 10:48:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1793616500; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=YEG2Xxi0rilqUmt8FEgX/3mwy6VvIHv0ckhn5FY1+ZQ=; b=txSfthX6Dvz/uO0F6gQEHL3wmoS0Mt3Lz9jbIfibX7Sk0AjgZe6VVYvZIT7SlweN /AkgEUtJ6X39GY6Ucnz1C+ht5eBsCc2nc/ZxxsSubnedLjHGJnCAMxFbfoiE16V+qe7 nzjFP3ecrW5Ijc4huUmAoIvU/cvGE/YgvfKdHiaPwvFnrBHA2J/0w6qDICta+DHg0Fn 1M4ns3DJUl54QeQVBkM0sCvYMH+iDv8weYtAgyQeVZQ6Fz6fEKNezlyajmDyLfZzivV JsYS6qtGVGuuyGTUeeYVRO3NUlzBih2jw4+Q6RX096LdCJg05yo3SjGotq4py/dzqw/ mahXQ+944Q== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1793616500; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=YEG2Xxi0rilqUmt8FEgX/3mwy6VvIHv0ckhn5FY1+ZQ=; b=GnfQP2LgQQw+cRrtWDc4uq2fQRAV4rBIsejWk4pDsonQsqczd1OU67zQ3yuXbu1u hP4+eSjTbkHm3hXI2rrdYrq0MG3Z1Z1uSysAMATooj1TMNTAeVSGaa+G4cvhQp8wN/x q8uFo14qSJKLSghfSqD9OKLRVoYGEf7lvv5UlJBg= Message-ID: <010701a19bdfd6f2-46916c3b-0348-4f35-a1eb-fa21df1e480d-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.1 v6 14/34] q35: Fix migration of SMRAM state To: Andrey Drobyshev , svt-core@virtuozzo.com In-Reply-To: <20261102-vfio_v1-v6-14-9bc7cabc850d@virtuozzo.com> References: <20261102-vfio_v1-v6-0-9bc7cabc850d@virtuozzo.com> <20261102-vfio_v1-v6-14-9bc7cabc850d@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Nov 2026 10:48:20 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.11.02-69.169.224.1 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB1PEPF000509EA:EE_|AM0PR08MB5298:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: c8912756-8591-49c8-f52f-08df38cecfee X-LD-Processed: 0bc7f26d-0264-416e-a6fc-8352af79c58f,ExtAddr X-MS-Exchange-AtpMessageProperties: SA List-Id: svt-core@virtuozzo.com X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|704161411799003|48200799018|376014|61400799027|9140799003|32142699015|4143699003|5063699009|56012099006|261009223027099003|261028144727099003|261021121427099003|261026121527099003|261022105027099003|261026140227099003|10067099003|18002099003|55112099003|22082099003|16102099003|5113699003|4113699003|6133799003|3023799007; X-Microsoft-Antispam-Message-Info: Holp9+o7xSN9/YLEm/tx6aM3ylBI8b9RUBpAx7rdegnc6dUbt+XjjOAH+AsE91zBqpyNjrDNkHH1f6UI0KZ2yiDgT3KF/nEmQ58kGcoa0jARBCL3Aho6JREMcAUfxQLHaJsLn9VZcxnFbSypdlw7qFO0oU5ZjHBGhKQQi6yQUedshFFGBUVyynQap+Fvl8xmhxVt04+Sw9hjJYLmWhBaShVs0RJQrxDWYSATRTaepYazqJF5tmlk9vw436PZ6NxpdfFRhNRbUdkIf5mJaHfs4SNojhsn+GmmC7R8KhbDji/tulTPEDGamIj0KVJQipzLoW86CFoI9ijo36+YambbKeOpcWe6uhUyvGm1qSt4m9l1vYYSiWaMr6/XekDDjmw/SxucK38CnZMmyw5A6Lrcb+rcfj688oTiv4PAg1pMPnZXZM/TKXcpKJcyEMaN7lWV5uoKJ8Gn9P81Db8r1MDhGcsZ56EY7NmKiqvtwyiFG7BmuI7uu09JfHMNtP8EqPYyQww6f96qEbFDrwPyKwLYp4oKHbL5eNr6mvxxhpATTDMjrIvzzOBxCbPwXFeQ9d6pzVQsemDt8F0N7Oxgt2fsIrygrv2LxuOdgfivqoLdSrZDYRVda9GXC93FVQDxeYsJ0pz2qPyrqd0tR5YhWYFcSHOsMcNLdIWzT+xDNnqUaT+ZM8nTktkoEPcRj1JtIVWqIHtYVA7JnITFKWSVvvi6CdbA0Va3S4fzIvfS/Dqez55uKECiTWSAl6bkCLlwyckSgyz04IZpPCVrUZG33qYagQ36hAMw3xcZOYSUtNaAdOfSxF697RC3WcPBuA0sG9GQCdKUu3Yeu7Mff1AJVywwj/aQRkOWlgkSsbRll1n9fX/Zr3H5058aFvPmatVb1N8E X-Forefront-Antispam-Report: CIP:69.169.224.1;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:b224-1.smtp-out.eu-central-1.amazonses.com;PTR:b224-1.smtp-out.eu-central-1.amazonses.com;CAT:NONE;SFS:(13230040)(704161411799003)(48200799018)(376014)(61400799027)(9140799003)(32142699015)(4143699003)(5063699009)(56012099006)(261009223027099003)(261028144727099003)(261021121427099003)(261026121527099003)(261022105027099003)(261026140227099003)(10067099003)(18002099003)(55112099003)(22082099003)(16102099003)(5113699003)(4113699003)(6133799003)(3023799007);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: cOob2B+L+rhuN5QjwO5V2NjAHCcyyTTWdo5yCnuV6fHmC29DnN6cx/h72lK1PE3P/+uSHijTfZAywaBqsyxitGXaCiam86Obp9LaM0oLXR+PYsLP3dcbKZ87i/7Xwlv37vqZS/k77wiCn33OHSBZWJLqa03oynOxStQnIpygdhDCYzkW5Cg5xj5AIOrEOrajVydQhFqrtOE+Uj5ByyBDdk0rFYjYGty8tw+cTRPmL5sxGklGVHwJGmXhRD1vYYEsM4z9n8+jbuAfYPo/4nB+KamQQfIvVXzEUKhJGDLu8JDPzrSu/7a29q7MCX7Gf7z8NLJ+S6zTvdHhfFszW2d2u36IVmJqbc6HAfdveflVyLt/kK2iA67gcJVSn7YwP9ZD0UcAau/56f39wXh7iypvXKkKGY4UCr1Kv8ww8fQsWVZfAM0pYSQOx1o54AhW9kJj X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-Auto-Response-Suppress: DR, OOF, AutoReply X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Nov 2026 10:48:20.9890 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c8912756-8591-49c8-f52f-08df38cecfee X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: DB1PEPF000509EA.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5298 Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: - [Low] q35: pre-negotiation writes to SMBASE reg can lock it and enable SM= RAM blackhole -- commit e599128e44cfa63b5f0a0828dcf6845ef880af50 Author: Igor Mammedov q35: Fix migration of SMRAM state This change drops the wmask =3D=3D 0xff discard in mch_update_smbase_smram(= ) and resyncs wmask from the SMBASE config register value, so a locked SMRAM state survives migration. It also removes the pre-negotiation junk-write check from test_smram_smbase_lock(). 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 [ ... ] > @@ -432,30 +432,27 @@ static void mch_update_smbase_smram(MCHPCIState *mc= h) > } > =20 > if (*reg =3D=3D MCH_HOST_BRIDGE_F_SMBASE_QUERY) { > - pd->wmask[MCH_HOST_BRIDGE_F_SMBASE] =3D > - MCH_HOST_BRIDGE_F_SMBASE_LCK; > + pd->wmask[MCH_HOST_BRIDGE_F_SMBASE] =3D MCH_HOST_BRIDGE_F_SMBASE= _LCK; > *reg =3D MCH_HOST_BRIDGE_F_SMBASE_IN_RAM; > return; > } > =20 > /* > - * 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 lock the SMBASE register without negotiating first? mch_reset() sets config[MCH_HOST_BRIDGE_F_SMBASE] to 0 and wmask[MCH_HOST_BRIDGE_F_SMBASE] to 0xff, so after reset every bit of the register is writable. A guest config write to offset 0x9c then goes through this path: pci_default_write_config() mch_write_config() mch_update_smbase_smram() The old "wmask =3D=3D 0xff" check used to set *reg =3D 0x00 here. With that check removed, a written value with bit 0x2 set reaches the MCH_HOST_BRIDGE_F_SMBASE_LCK branch with no 0xff query step first. That branch sets wmask to 0 and *reg to 0x02, and then enables smbase_blackhole and smbase_window. A write of exactly 0x01 reaches the MCH_HOST_BRIDGE_F_SMBASE_IN_RAM branch and sets wmask to MCH_HOST_BRIDGE_F_SMBASE_LCK, also without negotiation. Can this make the 128K of RAM at the default SMBASE become inaccessible to the guest CPU address space until the next reset, for a guest that never negotiated the protocol? For example, a stray dword config write covering 0x9c could trigger it. The commit message acknowledges junk writes are accepted ("it would let guest write junk values in register ... until it's stumbles upon reserved 0x1 [|] 0x2 values"). Is this behavior change intended, given that the migration fix needs wmask to be derived from the register value? No later patch in the series changes mch_update_smbase_smram() or the SMBASE wmask handling. > 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); > - } > - Since this junk-write check was removed from test_smram_smbase_lock(), is there any test that covers the junk-then-lock path, where a pre-negotiation write with bit 0x2 set enables the SMRAM blackhole? > /* enable SMRAM at SMBASE */ > qpci_config_writeb(pcidev, MCH_HOST_BRIDGE_F_SMBASE, 0xff); > g_assert(qpci_config_readb(pcidev, MCH_HOST_BRIDGE_F_SMBASE) =3D=3D = 0x01); --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261102-vfio= _v1-v6-0-9bc7cabc850d@virtuozzo.com?part=3D14