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

Re: [PATCH v3 6/8] domain: introduce GADDR based runstate area registration alternative


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Wed, 27 Sep 2023 17:24:39 +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=8QH8bWQOQixbauh0wVdBOpR/O1L3xaTNjpr8J5tngBU=; b=TF+e6rEJISkqf4m/Q1cbQd0pSntYH5qXUxr0inDXIpJV3RYj61mNHTsT9b32o57+yuoo1sbXx0RKNytOeRrRdC9j37OrbOZbgg+ZAIuBEjt9Q/jyNrRt/PlN9xDY2e1iC1nYQlp7gKjm2HhZsMXHn04VKc+0dqamtirxktEdUxgKm5lv8iDSBDN/Wx6NULcTuv1BbVeaO9ZtGHHg7ySFULsPS1j6u+ILefEjidUooyvOQxBZEd9wmnts1gYe8Wup7dyjxyCk6ymSVeNos3//XIfEgT/ZisLWpQ34F1Z/E0e7a6FNaEm31T81SwSPQaLedkZV341j5AvPn/WTL26Lsw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LQsrlgQuJL2J2VmaUw8le02j4dHSG9FE8mcZl3BqtTeBjlTlzzjivcYc3Esp9s5njiqy1h4Tx2CTFR9hDE5ELvMaLRWd+oOSV66d1IlDanUTGB4zoaJRHXz0bP/73EMIb9BDuaH682xXCqKtb77MSGkSrP6Sikp3P7LKD8EQIrEFLEGIyRrR0Yj8KSAQ94rRSNqJi742Ec9lSKat3B6wMPn75V8kNhawSyIZfKUrIXumtjIQM3jfdjvn7IZmi49DOdeZyS8nihn/RnYDmjVFe9UadmzMuMqn023DA+eIm3nSp9sm85l05RdyZr32Vv9F/DcW72E3IcASyiflmjdJIQ==
  • 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 15:25:11 +0000
  • Ironport-data: A9a23:0xS3y6/t2gojM2JGeSzPDrUDTn+TJUtcMsCJ2f8bNWPcYEJGY0x3x 2oXC2HUP67fNzenLookOYq0/U4DuJ7Xm9NlGwM6pSo8E34SpcT7XtnIdU2Y0wF+jCHgZBk+s 5hBMImowOQcFCK0SsKFa+C5xZVE/fjVAOK6UKidYnwZqTZMEE8JkQhkl/MynrlmiN24BxLlk d7pqojUNUTNNwRcawr40Ird7ks01BjOkGlA5AdmNKoU5AW2e0Q9V/rzG4ngdxMUfaEMdgKKb 76r5K20+Grf4yAsBruN+losWhRXKlJ6FVHmZkt+A8BOsDAbzsAB+v9T2M4nQVVWk120c+VZk 72hg3ASpTABZcUgkMxFO/VR/roX0aduoNcrKlDn2SCfItGvn9IBDJyCAWlvVbD09NqbDkkQ/ PsECgkKNyqBoLOX5Yi0auJvjfgaeZyD0IM34hmMzBn/JNN/GdXpZfqP4tVVmjAtmspJAPDSI dIDbiZiZwjBZBsJPUoLDJU5n6GjgXyXnz9w8QrJ4/ZopTeLilUpjdABM/KMEjCObd9SkUuC4 HrP4kzyAw0ANczZwj2Amp6prraVx32jAttJStVU8NZHmnGP/WIpLic/REK4iqmf1mz5fftAf hl8Fi0G6PJaGFaQZtv3UgC8oXWElgUBQNcWGOo/gCmdx6yR7wuHC2wsSj9adMdgpMIwXSYt1 FKCg5XuHzMHmL+ITXOQ8J+EoDX0PjIaRUcZfjMNRwYB59jloakwgwjJQ9IlF7S65vXqHRngz jbMqzIx74j/luYO3qS/uFrB3DSlo8GRShZvv12KGGW48gl+eYipIZSy7kTW5upBK4DfSUSdu H8DmI6V6+Vm4YyxqRFhid4lRNmBj8tp+hWF6bKzN/HNLwiQxkM=
  • Ironport-hdrordr: A9a23:PqqlTK21EZ8cbMbUeI7N/QqjBEgkLtp133Aq2lEZdPU0SKGlfg 6V/MjztCWE7Ar5PUtLpTnuAsa9qB/nm6KdgrNhWItKPjOW21dARbsKheffKlXbcBEWndQtt5 uIHZIeNDXxZ2IK8PoT4mODYqodKA/sytHWuQ/cpU0dMz2Dc8tbnmBE4p7wKDwMeOFBb6BJcq a01458iBeLX28YVci/DmltZZm4mzWa/KiWGCLvHnQcmXGzsQ8=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Wed, May 03, 2023 at 05:57:40PM +0200, Jan Beulich wrote:
> The registration by virtual/linear address has downsides: At least on
> x86 the access is expensive for HVM/PVH domains. Furthermore for 64-bit
> PV domains the area is inaccessible (and hence cannot be updated by Xen)
> when in guest-user mode.
> 
> Introduce a new vCPU operation allowing to register the runstate area by
> guest-physical address.
> 
> An at least theoretical downside to using physically registered areas is
> that PV then won't see dirty (and perhaps also accessed) bits set in its
> respective page table entries.
> 
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

One comment below.

> --- a/xen/include/public/vcpu.h
> +++ b/xen/include/public/vcpu.h
> @@ -221,6 +221,19 @@ struct vcpu_register_time_memory_area {
>  typedef struct vcpu_register_time_memory_area 
> vcpu_register_time_memory_area_t;
>  DEFINE_XEN_GUEST_HANDLE(vcpu_register_time_memory_area_t);
>  
> +/*
> + * Like the respective VCPUOP_register_*_memory_area, just using the "addr.p"
> + * field of the supplied struct as a guest physical address (i.e. in GFN 
> space).
> + * The respective area may not cross a page boundary.  Pass ~0 to unregister 
> an
> + * area.  Note that as long as an area is registered by physical address, the
> + * linear address based area will not be serviced (updated) by the 
> hypervisor.
> + *
> + * Note that the area registered via VCPUOP_register_runstate_memory_area 
> will
> + * be updated in the same manner as the one registered via virtual address 
> PLUS
> + * VMASST_TYPE_runstate_update_flag engaged by the domain.
> + */
> +#define VCPUOP_register_runstate_phys_area      14

Just to make it more obvious, it might be nice to add a note in the
comment on VCPUOP_register_runstate_memory_area that `p` can also be
used with the `VCPUOP_register_runstate_phys_area` hypercall.

Thanks, Roger.



 


Rackspace

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