On 19/10/2022 8:40 am, Jan Beulich wrote: > In preparation of the introduction of new vCPU operations allowing to > register the respective areas (one of the two is x86-specific) by > guest-physical address, add the necessary domain cleanup hooks.
What are the two areas you're discussing here? I assume you mean VCPUOP_register_vcpu_time_memory_area to be the x86-specific op, but ARM permits both VCPUOP_register_vcpu_info and VCPUOP_register_runstate_memory_area. So isn't it more 2+1 rather than 1+1? > > Signed-off-by: Jan Beulich <[email protected]> > --- > RFC: Zapping the areas in pv_shim_shutdown() may not be strictly > necessary: Aiui unmap_vcpu_info() is called only because the vCPU > info area cannot be re-registered. Beyond that I guess the > assumption is that the areas would only be re-registered as they > were before. If that's not the case I wonder whether the guest > handles for both areas shouldn't also be zapped. At this point in pv_shim_shutdown(), have already come out of suspend (successfully) and are preparing to poke the PV guest out of suspend too. The PV guest needs to not have its subsequent VCPUOP_register_vcpu_info call fail, but beyond that I can entirely believe that it was coded to "Linux doesn't crash" rather than "what's everything we ought to reset here" - recall that we weren't exactly flush with time when trying to push Shim out of the door. Whatever does get reregstered will be reregistered at the same position. No guest at all is going to have details like that dynamic across migrate. As a tangential observation, i see the periodic timer gets rearmed. This is still one of the more insane default properties of a PV guest; Linux intentionally clobbers it on boot, but I can equivalent logic to re-clobber after resume. ~Andrew
