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. > Yet further we could put ourselves on the position that ucode > updates with _any_ guests running are a bad idea. Boot time microcode loading is by far the best option going (and with live migration, there is little excuse to avoid using this method). Runtime microcode loading has a few real bugs which need addressing, but fundamentally, the list of things an admin needs to consider is massive. To start with, is this piece of ucode even safe to runtime patch? (There is at least one piece of ucode from each vendor where the answer to this is a definite no.) ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
