On 09/07/2018 11:59 AM, Andrew Cooper wrote: > On 07/09/18 11:21, Jan Beulich wrote: >>>>> On 07.09.18 at 11:57, <andrew.coop...@citrix.com> wrote: >>> On 07/09/18 09:48, Jan Beulich wrote: >>>> 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? >> One CPU doing a microcode update while the other creates a >> domain. I haven't looked in detail, but I think all domain creation >> should be deferred until completion of the microcode update, so >> that domains get a consistent/predictable OSVW state set up. > > The path in domain create will see a consistent OSVW, which will be > either the pre or post microcode value. The other aspect (which again > can't be covered with an interlock like this) is that nothing goes and > adjusts the already-created domains to update their OSVW values. > >> Of course we can put ourselves on the position that it is an >> admin mistake to invoke a microcode update without suspending >> domain creations temporarily, but since domain creation includes >> domain reboots, I don't think this is something an admin can >> fully control. > > Domain reboots (including soft reset) are an entirely > toolstack-controlled actions. Xen raises VIRQ_DOM_EXC and does nothing > more with the domain. The toolstack subsequently issues a new > DOMCTL_createdomain. > > libxl's architecture may make it hard to defer rebooting for a short > period, but such a design doesn't impact other toolstacks.
But if we do need some sort of interlock, Xen is the one that "knows" about the rule, so Xen should be the one to enforce it. Expecting the toolstack to "remember" not to do any domain operations while doing ucode update is going to be fragile. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
