On 07/09/18 09:48, Jan Beulich wrote: >>>> On 05.09.18 at 21:15, <[email protected]> wrote: >> Since its introduction in c/s 8cbb5278e "x86/AMD: Add support for AMD's OSVW >> feature in guests", the OSVW data has been corrected to be per-domain rather >> than per-vcpu, and is initialised during XEN_DOMCTL_createdomain. >> >> Furthermore, because XENPF_microcode_update uses hypercall continuations to >> move between CPUs, it drops the vcpu_alloc_lock mid update, meaning that it >> didn't provided the interlock guarantee that the OSVW patch was looking for >> in >> the first place. >> >> This interlock serves no purpose, so take the opportunity to drop it and >> remove a global spinlock from the hypervisor.
> I see you've rushed the patch in (perhaps to avoid objections, given > that you've proposed this removal before, and I didn't really like it), > so I guess we need to take it from there now. There was nothing deliberate here. TBH, I thought the patch had been pending on the list for longer than it had. Either way, as we are starting the conversation again... > The interlock didn't work as intended, I agree, but "serves no purpose" > is wrong imo. At the moment, I stand my by statement, because as far as I can tell, the interlock literally does nothing. > Rather than blindly dropping the logic, I'd have expected > for it to be fixed: Despite the movement into XEN_DOMCTL_createdomain > there's still a race between ucode updates and domain creation. What race? What have I overlooked? ~Andrew _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
