[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 2/8] domain: update GADDR based runstate guest area
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Wed, 27 Sep 2023 11:44:15 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=kRQOR4pn7vW1Uv3oIea21Tw40/Z1SPOjrWh+R4pYCH0=; b=DeB10ba290sLW2oCvptrtVW+s80YTgnR73fAgUo2Z9UXCvoGfb+sWYjFjQDf19aEeag89SmTTC8Alc3ocC4ja3R09iXO9L1dnZCbh8aCWdg8u1llPnsCFh2ZXxAmjeG8MCXCPloqgyiPJWqtZMuOFKQfKpsxyuifT7dxFtKI2FiPh5KcHA7zSjzIUi28KoFdEAootTp0yd+fgZ+1vsGPKh4XECaix0z6srQG94BWnArs5YW49VR8jOQOI3H46XmuWHup1sgPM3ed761NbfDmACxFOwv1K5GzUeT8Bz6/Nx2H2simHRuRAroGTHCflf5+wv5iGLOd9AqpGa6rhmLF0g==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KQPUNLQPG5guLBjrl3Um1y/jxt+g+Qtr6vjQMK0gmLVgUzakiy8n6ioHn14CcSSqCxpLkN9eJnKdmIObG4kk3sKmkBSbE4EtGDc+0yFP8pkmzQtcHmoLbDEh7f/MfM5TodEhLKEBhG0o+zBpCwKdvfB6gapa+2ac2NG48MWxOZxNwc9Sj2VmClLjliVcOh8xMaELp5emXKcxHmKySuVViOOLu/FfSti83ViD8qmc7iT0Hh89eFqy4ZGFsgoAUTgl4I6gvpSA/NA4DPxQBSoMIufgrDiV9BvFnWDtt5dN+qgJV0WJZhnii6HssD273wN7j9x+BoKXzs4ax8sGUm9tMg==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
- Delivery-date: Wed, 27 Sep 2023 09:44:30 +0000
- Ironport-data: A9a23:O+yes6qME8m8UZHS0bKXnnZ0VuFeBmLWZBIvgKrLsJaIsI4StFCzt garIBmPP66JY2ahct0jYY23pBxUu8PUmt5qSgBu/yAyQnwX8JuZCYyVIHmrMnLJJKUvbq7FA +Y2MYCccZ9uHhcwgj/3b9ANeFEljfngqoLUUbOCYmYpA1Y8FE/NsDo788YhmIlknNOlNA2Ev NL2sqX3NUSsnjV5KQr40YrawP9UlKq04GhwUmAWP6gR5wePzSZNVfrzGInqR5fGatgMdgKFb 76rIIGRpgvx4xorA9W5pbf3GmVirmn6ZFXmZtJ+AsBOszAazsAA+v9T2Mk0MC+7vw6hjdFpo OihgLTrIesf0g8gr8xGO/VQO3kW0aSrY9YrK1Dn2SCY5xWun3cBX5yCpaz5VGEV0r8fPI1Ay RAXABQ0aT/E2/K5/JeEY7Zv1uA4DdLVf7pK7xmMzRmBZRonabbqZvySoPpnhnI3jM0IGuvCb c0EbzYpdA7HfxBEJlYQDtQ5gfusgX78NTZfrTp5p4JuuzSVkFM3jeWraYKKEjCJbZw9ckKwv GXJ8n6/GhgHHNee1SCE4jSngeqncSbTAdhJReHhr64y6LGV7msoLRFOT3KBmPL6mly4f9lUA EEwxBN7+MDe82TuFLERRSaQonSJoxodUNp4CPAh5UeGza+8yxaUAC0IQyBMbPQitdQqXno62 1mRhdTrCDdz9rqPRhq19KqQrD60ETgYKykFfyBsZRAe/9DprYU3jxTOZtVuCqi4ipvyAz6Y6 y+OhDgzgfMUl8Fj6kmg1VXOgjbpo4eTSAcwv13TRjj8tlw/Y5O5bYu171Sd9exHMIuSUliGu j4DhtSa6+cNS5qKkURhXdkwIV1g3N7dWBW0vLKlN8BJG+iFk5J7Qb1t3Q==
- Ironport-hdrordr: A9a23:/CAd0K1a8319oMTrtp8A7wqjBHYkLtp133Aq2lEZdPU0SKGlfq GV7ZEmPHrP4gr5N0tOpTntAse9qBDnhPxICOsqXYtKNTOO0AeVxelZhrcKqAeQeBEWmNQ96U 9hGZIOcuEZDzJB/LvHCN/TKadd/DGFmprY+ts31x1WPGVXgzkL1XYANu6ceHcGIzVuNN4CO7 e3wNFInDakcWR/VLXBOpFUN9KzweEijfjdEGc7OyI=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Wed, May 03, 2023 at 05:55:11PM +0200, Jan Beulich wrote:
> Before adding a new vCPU operation to register the runstate area by
> guest-physical address, add code to actually keep such areas up-to-date.
>
> Note that updating of the area will be done exclusively following the
> model enabled by VMASST_TYPE_runstate_update_flag for virtual-address
> based registered areas.
>
> Note further that pages aren't marked dirty when written to (matching
> the handling of space mapped by map_vcpu_info()), on the basis that the
> registrations are lost anyway across migration (or would need re-
> populating at the target for transparent migration). Plus the contents
> of the areas in question have to be deemed volatile in the first place
> (so saving a "most recent" value is pretty meaningless even for e.g.
> snapshotting).
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> ---
> RFC: HVM guests (on x86) can change bitness and hence layout (and size!
> and alignment) of the runstate area. I don't think it is an option
> to require 32-bit code to pass a range such that even the 64-bit
> layout wouldn't cross a page boundary (and be suitably aligned). I
> also don't see any other good solution, so for now a crude approach
> with an extra boolean is used (using has_32bit_shinfo() isn't race
> free and could hence lead to overrunning the mapped space).
Shouldn't a well behaved guest attempt to unmap the runstate area
before changing bitness? I would expect this to happen for example
when OVMF relinquishes control to the OS.
Thanks, Roger.
|
