[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v3 2/8] domain: update GADDR based runstate guest area
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |