[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 8/9] gnttab: bail from GFN-storing loops early in case of error


  • To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • Date: Fri, 7 Oct 2022 19:36:16 +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=Tlb6xUuiyv3ehdq3dqr6CRWp/ClGMHT9k0urW2cDPLc=; b=I3oNz7Hz2ImA4OYDy3F2POu6UcUebBB9uZmJuBgyIQrxrVpnQR6V8rG7WaZe3GZveo7xppR9qC+I8k3z8OHP54LvdaIg19t10FVXgXfgsAPuoi1qUIhNb4vV0O18CfFEEWKbkaYDtPKU9QiAes0AF4H07l7lj1BSNzrK+6vgw0THYRbz6TCUqBLc8XL3bTd0iJ9AYGF29ZwMiQ0g3g11V9lHPQg1YAZOGFpoJNPQe7YVXi6qIUcWg9VbHHg1+OX83+RaU8D0cvoms4DKNBxmYBODMA6iDGhNGWCvyrevVRyuWlDyjl6e6zWQ0mdLKWiCZAW3R15bUa3Wdatf01R6JA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CjjJI0RNrDlMOH9KJq+Whf3mcgs+bAdJfygyK/739DUQy0/tT541E+bGw6tr75bu0gvfw6WeJbeufPchFO8mJii0rXTV8mIJjmX00IxHo6WAhHnxoCgoaFbnODoL/gUKWk4q7AbvoNzNS1mbf8aisZuBoPVQuTQT6gDL2kcyoIqNY2+rNllzcb7HEmFvOXaOjehVSVPJRGk//NZmYGfjcfLkSMuMUnZ8NZuOSS88YaqzLb7oXTbho6qmkCrYIX6Lg+jKkC2ARYmo2FbMKipSYT7BWfbUy5Z5GPuW7/7v3ASDYFXeDVaoAvZtLdroEzEg8wxImUFDIkZ8Qfo0TIiQ5A==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: George Dunlap <George.Dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Juergen Gross <jgross@xxxxxxxx>
  • Delivery-date: Fri, 07 Oct 2022 19:36:30 +0000
  • Ironport-data: A9a23:aopFOats0aSXX86J1CZ73bAOMefnOphVZv1QmMifNp3fv4Xw3xbKv3m3sRAOTtXT8in+f9KLFo7KrYYkrBB+5gp36znrwqbCJqyHHCV0Ikbv1gcjCz602xf45ielFaY0gBXBVjZFvyABWPxFTSkyH5tVnR22+F9zZS9nVaGRVYje02ZQKKt7F5a7EMhJDAuWrAiq6VmnuUBvHZ7WG2S1uU5g15e/J8PhnYJNOnllo/IV78tqHeJz27alrEA5+zszpwFfNTOtAs+y2LDbYbR0fbMlQqIaM+SfRS3ZEVSc3ejLSWmMhIn6NJkfQLgtz7WgDiHfX0GeR3Zn6WO/p+6cyMQ2YtOeyJxxxrB2Ez6z0itkyoWFAY6PGFLyXnWBDfwgDXlwGGgFdIL9oJaxv0Ee8KszNkOn/nwgCcTFKGv4HMYsFaj2Uy5yt3jhFaYqkms1fXJ9/s4jUoiSEVAwqaqqJc9sk/mM5AE7TJCs72gcG3Unp3xcaCgzqYnze58yJblKFocoxv1U2R2dgeZjhMWAAHWo+NHxWm2389opQP79n/LpmapqQcsLmL0HN30he1/DMI4HgP58ndsyfo2GNxtrQCEaTiURU3hAI9sZF0oECCwIwvD2vKA6fw+dcvQ6aZR5p70W+RrYYbx0cVeZOEYamK2p8+JxDeuG+GORwIuz5aRgGCvT1Cy8DxoccX+6SdxjGJpkPPLaMlIHNyub2LFp7Cnbzk9Wm7EgXWgUaZHKTcpxqxyuaYpf20+y5ngROJMCTvp26dG6Ifxm/83qkNRl3eIbMRaT1AKIkPhMm8o0ISXaKfhow/CaMtx+toJw6mZTu7x4mPAFLEBVaieA/KaLSwm0z3cKG370ZS8RiIcAUpHL4RWxEjlC9tqr4b1vOsICk5o7K90MHcUMXHovnBs8tbTavdNg6C6MgXwkaG/pVDeWB12hUDNvPOzZZawi7MfsnEV1WbYk8Gt2EBKMy+P4vzuzbxZJKy5hFbPr7dKh/7GQ2jWx5PwPJ8scEDOYZugFUIEPyyNsLjjD1vbK+CH1lTwq7hL8DiZHazoSVRa5q5+oUHju3A6LPRsOzFsGcHcHX57aFdQo7DP270kYfgVa7MwTh7U23/cWQaI+cFeRttJ4JTy009X8yIaADFwcmLFj75D+QlDeUaYvswKd8zBNLlD23WQtL9VgsOT3uLudBjMK0WNkv1XuryNYKFyY869QS0TK/k4TEkBbtgokFtBejP16Vc08PbJG08kvRISoVfK+nf+jIIdlsH8vaM/r60mOhfqQtzl3z0Nz/Lt3G1FUd0x3JAeOhAxA1Z9l1R+sKpj41aniPKL4ggVG+FGEjjHpt6NlF+NzrhP9+fYyC1BlK4RZaoNhuiIXRVrWwYklUgTIHnzABMrIgD6MV9LrRsqNKArCtviQbNvuqBwrBpav2rhHnoulZKzWit97Kgi2M9IdcvoImG5wzLCEbf2Bg6/5lI8ATIrXC7kzd63VEQQr4GPZTQKHf7IXDmcrA0bKNjZbeTbNbYpmXMaOBOPnnqXlNsc03QX+06Ig76H/GqWix8DrnV6TAZuGN9DBAnoQlq+3UYqLobiDxxcd5uvwu0JMY1jvvQT3Upx/xtkVPzz7w4C3zXRWDEFrgjZVuoiPnxXxs/BrH5x8kLNlqu4Rz/ZP1qEZgJTBuhd1/skLCJexuZ6l4/HbM5MzfA6CE4gqhff21SjkWV/PnzvRfUqVcU3xyZJGrNTWdIWFYz9taMwgw+3QyDJFAfL0S95qbuEZVd91Z9DaAbjcFmLhUiEt5lkdWZcsT16B3kS7d+jaWinCbQwkjt/sDDOEED5EySWnUTym/LqT/oNXlD0uFEkSh1ma3Uz0Vzqqad2jsSLO/VJXAJN/0H/7ylzPzLrWYJX+6rnHm758tqrJEFS/6c5c+2lycMSe4gOys/uEgYpoP7HEccAhni2YvWqceU6W9hcLRXR1t3huRLiMrIxbpSjnbWkP1foM0q7iRV/oMmFCyLtjVDLnFzQrrvicB0aLt+MLhoMn2ZEVCc09IqX/YLVU768mcIEtczwPXGWmsMxp5jKripZXPzBmfe/aNpQvuPB8JgnHyvi9lckA82xN45jUB8yjPURyrhiZwu0KGygw+RFO3g+e7C0Q56zQwWtICsXCv2WbX0uETfIzxCA7b/ZrJmOsmfwRuX+ewzeW9lhi7kZSwRKwST7NJHsmdXgiTl0RsPvL5otxqI1oPQMqV38JH3P/HxV/N7aGMMitX8J2jCEMlHvwz5bRGhvly1b+9X9VsGM7+BomraSpoA/DJT9q6I38gXd4zcBohI55PMcloRiO+G+0w30wnRvRRq3aDGCruECl2UVaIl9+ghzp9w1SgZz+I1cwoxCOs7Eto2pJApkIjwZmKPxtrGJvFL3N71jeLmG5OiqDYDHrj9c+7ppYWAZTtsnvj3EI1fTDR+Xv/mchnoRIvfPV/3Ngu9uKMdm1NDYqoHoO4fJdCZv5F0CTJiVdYgXd6ms4z1dChyU1P3Cu2FnjGwgTJweX4fF+/+uvx55nwTpASmPxs3sxcB05uKhvFZp784pa/h0UqGu7IQgs
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHXmmM/VphgVTklNkOGta5ws5Mbeq4F01sA
  • Thread-topic: [PATCH 8/9] gnttab: bail from GFN-storing loops early in case of error

On 26/08/2021 11:14, Jan Beulich wrote:
> The contents of the output arrays are undefined in both cases anyway
> when the operation itself gets marked as failed. There's no value in
> trying to continue after a guest memory access failure.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

Not really Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

This is an example of a bad loop adjustment.  Taking just one example to
demonstrate with,

> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -3289,17 +3292,15 @@ gnttab_get_status_frames(XEN_GUEST_HANDL
>                   "status frames, but has only %u\n",
>                   d->domain_id, op.nr_frames, nr_status_frames(gt));
>          op.status = GNTST_general_error;
> -        goto unlock;
>      }
>  
> -    for ( i = 0; i < op.nr_frames; i++ )
> +    for ( i = 0; op.status == GNTST_okay && i < op.nr_frames; i++ )
>      {
>          gmfn = gfn_x(gnttab_status_gfn(d, gt, i));
>          if ( __copy_to_guest_offset(op.frame_list, i, &gmfn, 1) )
>              op.status = GNTST_bad_virt_addr;
>      }
>  
> - unlock:
>      grant_read_unlock(gt);
>   out2:
>      rcu_unlock_domain(d);
>


If instead, this were written

    for ( i = 0; i < op.nr_frames; i++ )
    {
        gmfn = gfn_x(gnttab_status_gfn(d, gt, i));
        if ( __copy_to_guest_offset(op.frame_list, i, &gmfn, 1) )
        {
            op.status = GNTST_bad_virt_addr;
            goto unlock;
        }
    }

then the delta vs your version is -36 bytes, and faster to run because
the loop doesn't need a memory read and compare on every iteration when
you can exit based purely on existing control flow.

Furthermore, the version with a goto is clearer to follow, because the
exit condition is much more obvious.  The compat change can do the same
with breaks rather than gotos, for a slightly more modest -11 saving.

A form with the op.status changes adjustments *not* added to the loop
condition, Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>


In reference to the hypercall ABI adjustments, it occurs to me that
loops like this (which we have loads of, even in hypercall hotpaths) are
horrifying for performance.  For HVM, we're redoing the nested pagewalk
for every uint64_t element of an array. 

A "copy array to guest" primitive would more efficient still than a
plain virt->phys translation, because we'd be able to drop the p2m walks
too.

Obviously, we don't want every instance like this to be doing its own
manual bounce buffering, so perhaps we should invest in some buffered
copy helpers as part of trying to improve hypercall performance.

~Andrew

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.