[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 07/11] x86/shadow: L2H shadow type is PV32-only
- To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- Date: Fri, 6 Jan 2023 01:31:44 +0000
- Accept-language: en-GB, en-US
- 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=oh7cyCArkL503G2e+TUqgklZst87qK1v5xznyrpur2s=; b=gEKVuBrohVqmcbbARxKYbTQ1342wV/LX2GtC6XwNlw4OitPFc9nQUyWQb+SHRmxprVg/L17PJzic/uBKsU0YLuvhqdR6D7p3cJ+amVGs6RupfQJzIah5l05yDB1JI1fwWjn96sw4iHQA0LWJku5iajRwffOOIuj97Yfj1EgG5qXdsG1lam1enWgvuEnglzu8No9kIPnhvseSY9DDjs3kmFAJptICkBULQLB8DfGT45r7PU0EwCEyH9fsrBPJYqBEWawqZi5pnvLFacOXMSQjgRJh0XsUl/QpUnt1vHx4XLcuuAEGj8jCO/SlgDN8AFX/6H1cYHs7qv6+0dHmzGmrRg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kRj2BAisd7GPfX3Nws1+dtWFtkLJFDkvpUXCBubddKlJdTAv8Z56z9VHEG9ym54fFMNk/FPpXe0Zr2Ps5aNgz84K5inC02LqICYMDvpl9pqfxQT00LhX7rTXk6ZSovMUKonpwvlcKkldDIxT1dydhaaWEc1DyHx5sRS6/j9KA89klMULbpApmMLNFSvVLB02KNafnq899eXQ8lW1wAUO6kdmdXW9ZnBvS/GVUEn/ayxfB5zTLRxHDWF6ssW10JBYgVH2d6KpkqEyx7JqYgBW10ufc+kouWClpOq2x0rwQ86N8BcdPAUPnifPdNWD++YN0DXMVZI3Amj046W7JWFtig==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, "Tim (Xen.org)" <tim@xxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>
- Delivery-date: Fri, 06 Jan 2023 01:32:02 +0000
- Ironport-data: A9a23:jbWz1qpII069CFmoh6826T8AuR5eBmIpZBIvgKrLsJaIsI4StFCzt garIBmHPquMNmegftp/PYSyoUxTucTTnYRnGlQ+qn0zEn4b8puZCYyVIHmrMnLJJKUvbq7FA +Y2MYCccZ9uHhcwgj/3b9ANeFEljfngqoLUUbKCYWYpAFc+E0/NsDo788YhmIlknNOlNA2Ev NL2sqX3NUSsnjV5KQr40YrawP9UlKm06W1wUmAWP6gR5weHzyRNV/rzGInqR5fGatgMdgKFb 76rIIGRpgvx4xorA9W5pbf3GmVirmn6ZFXmZtJ+AsBOszAazsAA+v9T2Mk0MC+7vw6hjdFpo OihgLTrIesf0g8gr8xGO/VQO3kW0aSrY9YrK1Dn2SCY5xWun3cBX5yCpaz5VGEV0r8fPI1Ay RAXADAPLSDTuOeH+4yEG8l9pNR9A/uwf5xK7xmMzRmBZRonabbqZvyQoPV+jHI3jM0IGuvCb c0EbzYpdA7HfxBEJlYQDtQ5gfusgX78NTZfrTp5p4JuuzSVkFM3jeWraYWMEjCJbZw9ckKwj 2TK5WnmRDodM8SS02Gt+XOwnO7f2yj8Xer+EZXpr6Iy3ATNlwT/DjUnCBjnsainm3TnVtZiK xEx9nEJ97MLoRnDot7VGkfQTGS/lhwWVsdUEuY6wBqQ0aeS6AGcbkAUQzgEZNE4ucseQT0xy kTPj97vHSZosrCeVTSa7Lj8hSy2ETgYKykFfyBsZRcE5vHzrYd1iQjAJuuPC4awh9zxXDv2k zaDqXFkg61J1JFSkaKm4VrAnjSg4IDTSRI47RnWWWTj6R5lYImiZMqj7l2zAet8Ebt1h2Kp5 BAs8/VyJshUZX1RvERhmNkwIYw=
- Ironport-hdrordr: A9a23:AsAjkK6cP2IM/bTnMgPXwMbXdLJyesId70hD6qkRc3Bom6mj/P xG88516faZslgssRMb+exoSZPgfZq0z/cci+Qs1NyZLWrbUQWTXeRfxLqn7zr8GzDvss5xvJ 0QF5SW0eeAb2RHsQ==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHZIR97UU3x5E5JME2c1R2RCJMcMa6QmwUA
- Thread-topic: [PATCH 07/11] x86/shadow: L2H shadow type is PV32-only
On 05/01/2023 4:05 pm, Jan Beulich wrote:
> Like for the various HVM-only types, save a little bit of code by suitably
> "masking" this type out when !PV32.
add/remove: 0/1 grow/shrink: 2/4 up/down: 544/-922 (-378)
Function old new delta
sh_map_and_validate_gl2e__guest_4 136 666 +530
sh_destroy_shadow 289 303 +14
sh_clear_shadow_entry__guest_4 178 176 -2
sh_validate_guest_entry 521 472 -49
sh_map_and_validate_gl2he__guest_4 136 2 -134
sh_remove_shadows 4757 4545 -212
validate_gl2e 525 - -525
Total: Before=3914702, After=3914324, chg -0.01%
Marginal...
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> I wasn't really sure whether it would be worthwhile to also update the
> "#else" part of shadow_size(). Doing so would be a little tricky, as the
> type to return 0 for has no name right now; I'd need to move down the
> #undef to allow for that. Thoughts?
This refers to the straight deletion from sh_type_to_size[] ?
I was confused by that at first. The shadow does have a size of 1. Might
/* [SH_type_l2h_64_shadow] = 1, PV32 only */
work better? That leaves it clearly in there as a 1, but not needing
any further ifdefary.
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -859,13 +866,12 @@ do {
> int _i; \
> int _xen = !shadow_mode_external(_dom); \
> shadow_l2e_t *_sp = map_domain_page((_sl2mfn)); \
> - ASSERT(mfn_to_page(_sl2mfn)->u.sh.type == SH_type_l2_64_shadow ||\
> - mfn_to_page(_sl2mfn)->u.sh.type == SH_type_l2h_64_shadow);\
> + ASSERT_VALID_L2(mfn_to_page(_sl2mfn)->u.sh.type); \
> for ( _i = 0; _i < SHADOW_L2_PAGETABLE_ENTRIES; _i++ ) \
> { \
> if ( (!(_xen)) \
> || !is_pv_32bit_domain(_dom) \
> - || mfn_to_page(_sl2mfn)->u.sh.type != SH_type_l2h_64_shadow \
> + || mfn_to_page(_sl2mfn)->u.sh.type == SH_type_l2_64_shadow \
Isn't this redundant with the ASSERT_VALID_L2() now?
Per your other question, yes this desperately wants rearranging, but I
would agree with it being another patch.
I did previously play at trying to simplify the PV pagetable loops in a
similar way. Code-gen wise, I think the L2 loops what to calculate an
upper bound which is either 512, or compat_first_slot, while the L4
loops what an "if(i == 256) i += 7; continue;" rather than having
LFENCE-ing predicates on each iteration.
~Andrew
|