From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from DU2PR03CU002.outbound.protection.outlook.com (mail-northeuropeazon11021087.outbound.protection.outlook.com [52.101.65.87]) by lore.virtuozzo.com (Postfix) with ESMTPS id 3A3D280726 for ; Tue, 13 Oct 2026 15:35:19 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=AX16KIEkp0iIDRGUDJZD434mVDvq6hlW82L/TcmV3j/A1pbVKaczW3FHMi2K96N9zNoO2sUWCHUyC3+yqKcGxkJOC7T5Uvs6/awTXPzQ/eb+AQoNWPaNTqcO5E2ZhJPQx95JLEI1emMFOTkCuQxbiYb87mfhZsi5zOxZJNACMtERA0OvfipxasipxUC4X/VaW4f6B4zQUUf2m3+Y9Qw6DMviC8JbzMkwM9xVlxKr6Ykmgi8xp/b6m9Izj9s0wfSgJqrN7Pvw6oNga24b7CpR6clY/61D6bAoI/SBvGKJ/IpEEB7t8f8HOooryvuteeV/MOBqDDjbDIRGMcc/ADOxqg== 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=IpdN0YhX9Xa9H+cONYp9P/PQ+7Dujd29C7Ix52N7Xmg=; b=iGqlFJZRYpfDDCoal6f/PmJInr8hbHu09ReK1rBy7KPx9MBoxSqrp4ht1Pfq6BM9G9iE8o/AQQlz4Hiyu9Jek0nwaQrcOGmbCVMw/jPqBFsVfuBcqOztOWSF8K4/rfEQKEGBmCZ9Gs6Z3eL4/o794PQxZeqW0BDD8fMFlwGpqP8hlAnVq5ID96Qvag4vYt8XpBEiuMq8CI9N5UYn1cwaCrLWcRFmXoqzrcrXETYkWZUP0kLtGxA3tgvfQoD1xwP9iMxYhREQ12WVisQPSURImlaKU/0PpHOK2aQidOwPjGFl3xehJjnPrILTbzztr9DX7oHyfQ2meRnLlXIoIQl65g== 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=IpdN0YhX9Xa9H+cONYp9P/PQ+7Dujd29C7Ix52N7Xmg=; b=B6jB9cqcyCTwzLUmF8JOuOMxc5sjGtY2jlH61D8omGxwvmGq3r6IBYdl9ufn4bNJRujUKQIJk0GSKgAPLSL9w2vW2hL88kys3o+ZpcU2sapn9gBiclV958oGLPWDyLb8ZHqGP+ySjeKp+3Zfjr86KWjGBNa6b7zsE526eD9Io20= Received: from PAZP264CA0131.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:1f8::17) by GVXPR08MB11352.eurprd08.prod.outlook.com (2603:10a6:150:2c4::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.12; Tue, 13 Oct 2026 15:35:13 +0000 Received: from AM7PEPF00000052.EURPRD83.prod.outlook.com (2603:10a6:102:1f8:cafe::69) by PAZP264CA0131.outlook.office365.com (2603:10a6:102:1f8::17) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.522.4 via Frontend Transport; Tue, 13 Oct 2026 15:35:12 +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 AM7PEPF00000052.mail.protection.outlook.com (10.167.242.38) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.546.0 via Frontend Transport; Tue, 13 Oct 2026 15:35:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1791905712; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=nAyfOESi4dcXa8B4ENcKX+bh8hZd3m7vyoJ8i9UmhHg=; b=PkAwzhlKic3V1Boblu+TTAaK9sAk9GbFku3YvYNmEQ+SsXrq2bscuPuVLhIlimBs oyh2nzOmNk0OueV5+ikfHEf42akTlfuddNBF9ROhSoXKUsxQsIWd+gMeqt+A9haheIF Jj92UIIoJca2yIoHaf1ugWl4lNnfNxc+YTn+4wzFuFT9A8fxiXIwd8cT43kIphAVprt YdjMTiquJ23qM87cNW6+4QCY3vtXaUWhf6V7Ml4HwaajPu0qZcbjKgGfFGYVTKNiGWu LpVCZN196B89OP9fj2dXBu0mFeCtTgzEd+PDvT0yXRxmZ1dACd1T/VsyD73cUP3C8VL Qmety8uTqw== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=qftdzk2dqsatjnlrq4r5brjbihpfcrsh; d=amazonses.com; t=1791905712; h=Message-ID:From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Feedback-ID; bh=nAyfOESi4dcXa8B4ENcKX+bh8hZd3m7vyoJ8i9UmhHg=; b=jBITY7oAZETFWBxk4jw56WViHsKGb3GdHl/zyKsuY6jgHkOUnQWhQ7z1rSkp0Qua il6r7xMh1+bA/ez5jIR/NxeidDywPK4M+dPCNuf6IHQpjWEbI6fjQ+IdqIYSkmXRwJk IHJ9gUenlr1kHbPfoae6Zki6BAZwysm0pQhTodPY= Message-ID: <010701a135e7496d-8ae3d0f5-4d6c-4242-9acb-b5db0aa881c3-000000@eu-central-1.amazonses.com> From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH QEMU HCI-8.1 v2 07/24] q35: Fix migration of SMRAM state To: svt-core@virtuozzo.com, Andrey Drobyshev Cc: andrey.drobyshev@virtuozzo.com In-Reply-To: <20261013-vfio_v1-v2-7-433455c0a294@virtuozzo.com> References: <20261013-vfio_v1-v2-0-433455c0a294@virtuozzo.com> <20261013-vfio_v1-v2-7-433455c0a294@virtuozzo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Oct 2026 15:35:12 +0000 Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.13-69.169.224.5 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM7PEPF00000052:EE_|GVXPR08MB11352:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: a78d8a32-34f8-4c18-0e58-08df293f9298 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|61400799027|32142699015|376014|9140799003|48200799018|5063699009|56012099006|4143699003|261009223027099003|18002099003|10067099003|16102099003|22082099003|55112099003|5113699003|4113699003; X-Microsoft-Antispam-Message-Info: xz+BxAK7krCVn3bkqmE24fx6qckH0We1OZrnUj9zc2W0nIUwBc0IfMLaKwOTyEb7XOAV/pRCLmtjINy5iLhR1YBkNqAJ1CK9D7tTshPrhc6xwKaJvy4qE+geLxHHepZ4psXbJtTWc9ry+bfKf1+Sc4AaS231/mmuvZuk70eQ8ca2koeV8xjevNPvCVElMBm1esnxoA+IxGSqLymgDznmJ+0dI6udLgHwdUvGQCqAT0dBnQxAx13ahupsWr+dodaI+tckfPbNwc9Oc2AgLuyX9MiZr+YRSCOQFWTQjXZP+vyEtXD0v/V1NESEmzwdJ5HzrjlI+ecGBjo8Sc32jz+niBTArDCbYLt5Syt1iNUPQmi2YiD3Rqx4o+PHR0lSimrbIPmU+vV07/1YfjghpMPNZRJz9JmFmYm09odp26syW4HezZu5w0PagsvAm9UgyT5Ri29Mj+n6Zyu+1O4cOkwwLcLsoqCHnhB8pAGu7BWvepwUugVBHmkDqCAGjsjSkosyoeUT6kQcblDy+kNj6d5F0KZjB53Ee+UgX2OJ8XoQXKzSndVyC2vBmBOUNr7pwhuir6+9PeALLO04hD8vylIEpzID5z8c2cYb+T8H9R9rA3APx9SIanZdUbjhNgyEGXO02rckiJJjLWIVbH9ECBtVyGHYA9JvamwNFT9JkhvIL5G7qphTawAZJFo5xcee1L4QUrmox64B9j9uvv2B/ViSoEg9lU51ZuXdHB1EwNFrL70UOx7AOAUZW8XlwKU69F5jG2NMO88EGJPVYGqSGIfLIZpfZktFj8uCvgLaEqCPfEU= 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)(704161411799003)(61400799027)(32142699015)(376014)(9140799003)(48200799018)(5063699009)(56012099006)(4143699003)(261009223027099003)(18002099003)(10067099003)(16102099003)(22082099003)(55112099003)(5113699003)(4113699003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: VqfEus8nHk5lm5Y0Q2Kahnf98w360I4sQ53DIBbfwCPABNDlMj/FrNHHU6d6YFTZNcIXDwUuHv27Hbs5yBXD7gmGO3JzNY7aiaU7V13IJ6FVl/CLPIzRH6AGc1n9HfavVvaZaMY67X5cLCdc3uztFoZkDIdJDrw2BKHUYvzOWxjwOyfY4kAL1mJyntkJOECIEvjY+lUo4xd3z8cqqVy8IvNUSIX074Ek5p8wz42gSbhH2XnKYth684+MmY/hKLSBL0iZdV0nBw+RIaOe0lg0ABCYH6D22jnsD/kFfKdMKdrss1bjiX5Y/rYt59DufUQ43DhVTRKyHkxcffZ2zJakaE6nDm/VHfupKZxsLgQEzwY/E6KcrIrMKy8BHFAGi3lRJlnLXzdRaY2PgyK3x4ma/+IifbS6DNu09z/KzDuRQu3uBMqi2z8yqckC0ZxKTzCe X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-Auto-Response-Suppress: DR, OOF, AutoReply X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Oct 2026 15:35:12.8384 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a78d8a32-34f8-4c18-0e58-08df293f9298 X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: AM7PEPF00000052.EURPRD83.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR08MB11352 Thank you for your contribution! Sashiko AI review found 2 potential issue(= s) to consider: - [Medium] q35: mch_update_smbase_smram() skips region disable on IN_RAM po= st_load - [Low] q35: mch_update_smbase_smram() does not restore wmask for loaded 0x= 00 SMBASE -- commit fa09770dda8724554b3e3a42f4619ca6364af58c Author: Igor Mammedov q35: Fix migration of SMRAM state This change drops the check in mch_update_smbase_smram() that cleared the SMBASE register while wmask was 0xff. It resyncs wmask from the register value instead, so a locked SMRAM state is preserved across migration. It also removes the test hunk that wrote junk to the register before negotiation. 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; > } [Severity: Medium] Can this early return leave the SMBASE regions enabled? Before this patch, a register value of 0x01 fell through to lck =3D false, which disabled both smbase_blackhole and smbase_window. Now only wmask is updated, and memory_region_set_enabled(false) is never called for 0x01. Consider mch_post_load() -> mch_update() -> mch_update_smbase_smram() on a live MCHPCIState that is currently locked (regions enabled) and has not been through mch_reset(). If the incoming SMBASE value is 0x01, the regions stay enabled while config[SMBASE] reads 0x01 (unlocked). The guest then sees a black-holed SMBASE although the register says the range is unlocked. This contradicts the comment "update wmask to be in sync with it regardless of source". The snapshot-load path calls qemu_system_reset() and a fresh migration destination has the regions disabled, so neither is affected. The path that looks reachable is COLO, where colo_process_incoming_thread() calls qemu_loadvm_state_main() repeatedly on a running secondary VM without qemu_system_reset(). If the primary locks SMRAM, reboots, and negotiates 0x01 within one checkpoint interval, the secondary loads 0x01 while its regions are still enabled from the earlier lock. This needs COLO and a machine with has_smram_at_smbase. The final series state does not change hw/pci-host/q35.c, so this is not addressed later in the series. Should the IN_RAM branch also disable smbase_blackhole and smbase_window before returning? > 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] Does this code restore wmask when a loaded SMBASE value is 0x00 or a junk value without bit 1 set? wmask is resynced only for QUERY, IN_RAM and values with the LCK bit. For other values wmask is left unchanged. mch_reset() is the only place that sets wmask back to 0xff: d->config[MCH_HOST_BRIDGE_F_SMBASE] =3D 0; d->wmask[MCH_HOST_BRIDGE_F_SMBASE] =3D 0xff; On the COLO secondary, colo_incoming_process_checkpoint() calls qemu_load_device_state() -> qemu_loadvm_state_main() -> mch_post_load() -> mch_update() -> mch_update_smbase_smram() without a device reset. If the secondary's MCH is locked (wmask 0) and a later checkpoint carries SMBASE=3D0x00, wmask stays 0. The register is then read-only and the guest= can no longer negotiate or lock SMRAM at SMBASE. The primary could carry 0x00 after a guest reset, before firmware negotiation. This only shows up if the secondary takes over after such a checkpoint without a guest reset, and the final series state does not change this file. Is the comment "update wmask to be in sync with it regardless of source" fully accurate here, and should wmask be set to 0xff for values that do not match the QUERY, IN_RAM or LCK cases? --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/20261013-vfio= _v1-v2-0-433455c0a294@virtuozzo.com?part=3D7