From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a15a309946-2c1c1fe8-f160-4679-81f6-3c565860102e-000000@eu-central-1.amazonses.com> Received: from MRWPR03CU001.outbound.protection.outlook.com (mail-francesouthazon11021143.outbound.protection.outlook.com [40.107.130.143]) by lore.virtuozzo.com (Postfix) with ESMTPS id E3CFB8017D for ; Tue, 20 Oct 2026 16:41:41 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=AZOGwF6mV65xyuMBFoBQSisxdG5PkuaORRQi3B37BCwLI8rwXLSV5az7bTechWTH9FRF11RvOb3Y18d76jcvnu4/xVRSS6/PWKkDsECHG1noT8Y+XHvHXE23Ogw6seCDVFWux7T+U61QtOznn2il3dzgMGSRkMSOWvsYd9ajdUMkFVUtsF9MSF5g4xgFmwz0E31mCFrdHXdhQ/HCrBl8btqRPUGYdEwM4GfvJalnMRvWwAyQya1ISNOZS3Hvtb9ZltKYqTMWAg6uzsvIT/iw9I7Kk9+mmk5mrqpjqp7xkd8ZBHE06S3JLxSKtGH5t9U4prv9A9AWZ6F73r171vej2g== 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=M5tbcgUNyl3lQ4rLmHksbT6GJB/Sox+ex1aVeqrWWdc=; b=xch+0OtJwX3GdMCIaP5S6u9vDwuJyD93Kdqn8nH8UBujaJNs94HXbsSC6JV7/Bk79O3BIhghCbdooJcnIiKYoE121F7MbjmUxn6BVCAJmBe9gge3XmSRRZmLcVI7/G3qMXO8wst1euS7t27qvAGO0Fp1ErMz6sa3yxWSxIZz3zjiylJ6j42yYSudVKMdbBh9Rkp0xSu4k0r1MSeqj1KDsBKVDW1V/fU7FaR9V2uGMb2F5noN+990Hlpnw4pHr+ETyViS9OGAeL2AaE+LqddZX2cpBBKfM0/LWJBAEap6EjBorW3/epD3nZ2ufqxxasuy7q81TO+kKFR95SvwV8eMJw== 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=M5tbcgUNyl3lQ4rLmHksbT6GJB/Sox+ex1aVeqrWWdc=; b=ojTUUTGcrYx+8XK8v4lGw0TIyXc3b1NpD7QxBUCSX+zW/20XZs3LgjFHkTE+8x0uCKAB/ld0ZqYhc68eA/5cW+QUwqA002yOYM2TnjUwWP4WHx/UAK5ysU7x+VyYHcdYFkRkEtW0RRsdwSiLSYm9CUbIn1Pnky/mTARxusxLdnE= Received: from PR3PR09CA0001.eurprd09.prod.outlook.com (2603:10a6:102:b7::6) by PAVPR08MB9038.eurprd08.prod.outlook.com (2603:10a6:102:32d::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.14; Tue, 20 Oct 2026 16:41:37 +0000 Received: from MI3PEPF00008497.eurprd03.prod.outlook.com (2603:10a6:102:b7:cafe::6d) by PR3PR09CA0001.outlook.office365.com (2603:10a6:102:b7::6) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.19 via Frontend Transport; Tue, 20 Oct 2026 16:41:37 +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 MI3PEPF00008497.mail.protection.outlook.com (10.167.240.182) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.15 via Frontend Transport; Tue, 20 Oct 2026 16:41:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1792514496; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=DyVJXFHqvh1Pn99uEWalRCmABA2zYn2oNhrFTjrQ67Q=; b=lLA9YnqGM1xM2qIjLffdQ9ufomQELp+VSQLj2rj6QkXT5SQAYY6RsuC2Wd3XT/i/ zZiMWvmMiLeaJK9zcDPquE4yiaUGNYsgh/b8eQ4f6E0BEib/zwdjeRzySKd/DNTwue8 0FIP2x1yMJHR+9f4AP2HWe0aLs7/1r2gaRhFaALt3rs7mSH+apw26yH2xHkaAOmIOqD 0ddJrtkAzrgOtjbGDfQvOh4WbyiGK7OmtyhTgq+OSlv2Q3H0UwiERWk1DRuiqArXPd6 94qGWnaI+QbV0M5q4l994duaTEOwIFwNSfWEZN+zzyqPAa2+KxPnYWT2Vt5Ye9q4Gbb PV59nf9h1g== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1792514496; h=Message-ID:From:Subject:To:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=DyVJXFHqvh1Pn99uEWalRCmABA2zYn2oNhrFTjrQ67Q=; b=e6JXtnXLLzsOel84bocMtNf7n2fObarEr2Q3fV/WZuWj9wglE0otmIl7XiW0FV5u EEWFTuXy88kT0qI9sgHCGPLVHCtcUkGIyMFH/yGf246ACLYAiH2zRy2RGetcIaX8mgy 9GSQtSnKuv46Mqi6DzWODUkXSflnBGYvZB320u9c= Message-ID: <010701a15a309946-2c1c1fe8-f160-4679-81f6-3c565860102e-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.1 v4 12/31] q35: Fix migration of SMRAM state To: Andrey Drobyshev , svt-core@virtuozzo.com In-Reply-To: <20261020-vfio_v1-v4-12-83a5668230e5@virtuozzo.com> References: <20261020-vfio_v1-v4-0-83a5668230e5@virtuozzo.com> <20261020-vfio_v1-v4-12-83a5668230e5@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Oct 2026 16:41:36 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.20-69.169.224.1 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MI3PEPF00008497:EE_|PAVPR08MB9038:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 8fc890e6-a617-4d0c-62b1-08df2ec90269 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|704161411799003|376014|48200799018|9140799003|32142699015|61400799027|5113699003|4113699003|55112099003|16102099003|22082099003|18002099003|10067099003|13003099007|4143699003|261009223027099003|5023799004|56012099006|5063699009; X-Microsoft-Antispam-Message-Info: ruDctYu6gXGOlcCVJ9aQ3louJDJlujJfFGHxWjZj0YNdcVszz/3kv28uyVqp1eA4OmYqqagVviTuSjFF8dZFHOu5XopXp/RlmqBEW1dTecfGgKlk1laDSxhGg8m3nAzBqrAUFqibztMH1wUu/yZdBJb5g+qkr3Hezqz8HEqXlb7al28BeYAqeMOISWMRJzZ8OdtQ+Pe/kZRDFqGepHzIj1qtC4zw10J3zhuAJlR9iZnDknt1+BxhGfQ8RGpM31DhGTZmQ/zc3ZLHYYX1m8NrJroBEXHvWvwtC+tDdmddN/yGWIoj+3qy+EjdVtc2uJtQ5bkO0FDizg23DTa3KSusUFH9ULlp34a0DcnbaR9htjWgBVUNxjhEr7vjjo/YmBbp6Z+r54Q6Hxp5H+Tscsufd++pwYBkV2mydWDB2ITm/PXmn+4+cIflnKUTLN0AdIWhs3KILfrtkQaJoQgERj7IAu2NUOp3dD2cH3+zVsytd1kqu2I1BoZJbkgv9vlngyQsWTvQ12wkTl4geJoJC+5ra1iTvoBYZ8+VKQ2DSl1MmXX4zy01hAN5NJoGiele/xWRwrxXA1GFuDzYSSw3MrPH4L+UxUB1+4ETwOV8CY7hilLU6BD3RQI6lgir2ZYnjkZUc5hEld93ib0y7dcY9Hvri/r83PjrKVe6IsD0ro6YaSJbFIj6QCLdbzqcQjkfm7mAyzzr3EypJ6rMMVpzvoSGgX53QEtisT+nLnFQAqDWzzOHGKm4r3l1c/YRwrc0sHIKwzIFVUaWIwdckMypsKweq5Wb2DoRjOuhQeGq2RPO0KeYP2ZXr35S0eNyJeKba5QFwxuL1CVFCpFx+eMD/h/PerqVIg4kylNde8hB5rrGIeYqLPgF/a76XN22D2PCsHSc 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)(376014)(48200799018)(9140799003)(32142699015)(61400799027)(5113699003)(4113699003)(55112099003)(16102099003)(22082099003)(18002099003)(10067099003)(13003099007)(4143699003)(261009223027099003)(5023799004)(56012099006)(5063699009);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: guAF1wBxFLR4swqDkHD8J0cB8ERp2J83jjLCOxV6zqE+FA52hFxfL8tYEzVhqBu0zvb75QcKVdvUkcWa7Bl4KY2oMvlOkv60ebQnLRVcG7BSuD9Hum/Zi5Qt8xo8BQyXr/w2BavkfO4/uaWxLkJ9PtY7Y+yMIr+7mJOhl2luiBeG3t/cQzmU5l7XrWR+e+s3gBieNwqQeDuOJarSnfjqVvVwIvp9Ar9DA2TMgdsYxQkYYV7+Ng0Dgh1P+FZyLeoA7Prwo2sTccgaFLtfZn5JsyBGYZxJDrRAJCK5EsJoQE2fcmq3yfMVOL6SynFQzt2qEAYYy7Ege24QQpt2b8XUh8bKSqYPPR5z7oqMRKF/mR+tknwHN9+t1oMURjZallYYCaX1yRB95Ck4Voj+1qMZs2XRHfQQgPST1EDFr9Z9mYcxe/Gs43RtTwrh3mdfp+Cb X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2026 16:41:37.2966 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8fc890e6-a617-4d0c-62b1-08df2ec90269 X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: MI3PEPF00008497.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR08MB9038 Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: - [Low] q35: SMBASE lock reachable from reset state without 0xff/0x01 negot= iation -- commit 910f528c422bd7c6087d0502ae62fa2f2c8cd852 Author: Igor Mammedov q35: Fix migration of SMRAM state This commit stops mch_update_smbase_smram() from clearing the SMBASE register when wmask is still at its reset value. wmask is now derived from the register value instead, so a locked state survives migration. The junk-write check in test_smram_smbase_lock() is removed to match. 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] After mch_reset(), config[MCH_HOST_BRIDGE_F_SMBASE] is 0 and wmask is 0xff, with no 0xff/0x01 negotiation having taken place. Can a guest now lock the register directly from this state? For example, a guest config write of 0x02, 0x06 or 0xfe is stored by pci_default_write_config() because wmask is 0xff: mch_write_config() mch_update_smbase_smram() /* value is neither QUERY (0xff) nor IN_RAM (0x01) */ 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; } lck =3D *reg & MCH_HOST_BRIDGE_F_SMBASE_LCK; memory_region_set_enabled(&mch->smbase_blackhole, lck); memory_region_set_enabled(&mch->smbase_window, lck); The removed check used to zero such writes while wmask was 0xff, so this path was not reachable before negotiation. Now smbase_blackhole and smbase_window can be enabled without it, and non-lock junk values are stored as written. The commit message acknowledges that junk values are now accepted, but it says the register can only be locked after reaching the reserved 0x1 or 0x2 values. Should it also say that a plain write of 0x02 locks the register directly from the reset state? [ ... ] > 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 test that checked the old "junk is ignored before negotiation" behaviour is removed, and nothing replaces it. Could test_smram_smbase_lock() get coverage for the new pre-negotiation behaviour? The same applies to the wmask resync that the patch adds for migrated register values. Is there a test that covers the case where the register is 0x02 or 0x01 after post_load? --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261020-vfio= _v1-v4-0-83a5668230e5@virtuozzo.com?part=3D12