Hi Jan, > -----Original Message----- > From: Jan Beulich <[email protected]> > Subject: [PATCH 2/2][4.17?] x86: wire up > VCPUOP_register_vcpu_time_memory_area for 32-bit guests > > Forever sinced its introduction VCPUOP_register_vcpu_time_memory_area > was available only to native domains. Linux, for example, would attempt > to use it irrespective of guest bitness (including in its so called > PVHVM mode) as long as it finds XEN_PVCLOCK_TSC_STABLE_BIT set (which > we > set only for clocksource=tsc, which in turn needs engaging via command > line option). > > Fixes: a5d39947cb89 ("Allow guests to register secondary vcpu_time_info") > Signed-off-by: Jan Beulich <[email protected]> > --- > Is it actually correct for us to do cross-vCPU updates of the area here > (and also in the native counterpart as well as for runstate area > updates)? The virtual address may be valid for the given vCPU only, but > may be mapped to something else on the current vCPU (yet we only deal > with it not being mapped at all). Note how HVM code already calls > update_vcpu_system_time() only when v == current. > > I'm surprised by Linux not using the secondary area in a broader > fashion. But I'm also surprised that they would only ever register an > area for vCPU 0.
I re-read the guide for release manager, and it tells me that "in feature freeze and early stage of code freeze, bug fixes are encouraged to be merged, while in the late stage of code freeze, complex bug fixes might be rejected if the risk of accepting is higher than the risk of rejecting it". Hence I guess in current stage, I would not block this patch for release. If this patch is acked/reviewed by other x86 maintainers, feel free to add: Release-acked-by: Henry Wang <[email protected]> Kind regards, Henry
