[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: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 27 Sep 2023 12:19:59 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=AGexAdk9bM7ssoOXTrZr+4jSeP4JbipQGyZ1N1Cikv4=; b=iSw9yh9doYgbARp7MLFGby7QzA1+h+eDqfTyUQj1+4+IQ+CI5MdiOk8Ig54giazZ9AkEr1PJa7EYbyqcIqr6qL8PpftOvU9bzqTdAXlyG9NVZoTj1mzKawljpeHLI2nwb0Uv0WX3ZBUtlQA/aSqV3sWStj56ZWWjlJqsKeYE7y44Drzb4VDg/vYgJjNOL5fqb24G1iJKgnt3x4EooU/fHHdJGCCae29u10NDIpP0qFDsSmuS4EwZR6i3Oiw2Ulzz7ZJdCyMFzWm2eu5B+zYLXze2SjUFPdMebqh/Sb79TvvkdS8i+NW2hktDEe1FeDUr21AUcuhrQcV7Ljz//MCfsQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mPloEKHuBDpDyejoLIXQic39XJGqZ1jm3DQbocSmuXAGXTB4SjUltdyq9vTXjgnt7UBU6XWojt0ym8FIYi27kPlDCpkARN8nREWcAaUmUg1hBCX1E243acW+2kpncAol7Ovml+d9rh0I7kuOynjxTuLAQeZYvMR5hi4V2wEr4tjqJWbqdPQd6Uq+ATB9GrxDJ6Q/UADq3zZ/P5vedYOFqLRJC/AulT/1jyQvqNWMN69gWqWKrY0R/szSpJI1gpGoF3chSXf5Zr9ItnsZyqwftN5WACWaubfHTdEKm1nhcT0V9cISqjg0H5c0mO7sNfkuGReslh4X0uUeJIApZ09ChQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.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 10:20:12 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 27.09.2023 11:44, Roger Pau Monné wrote:
> 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>

Thanks.

>> ---
>> 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.

Well, the OVMF example falls in a different class: Before transferring
ownership of the system, it wants to unmap regardless of whether bitness
is going to change, or else memory corruption can occur to the following
entity.

Jan



 


Rackspace

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