Re: [PATCH] xen/domctl: Drop vcpu_alloc_lock

From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Xen-devel <xen-devel@lists.xen.org>,
	Julien Grall <julien.grall@arm.com>
Subject: Re: [PATCH] xen/domctl: Drop vcpu_alloc_lock
Date: Fri, 7 Sep 2018 11:59:41 +0100	[thread overview]
Message-ID: <45b7ca77-989f-2fa5-261c-6bbe19deb8ae@citrix.com> (raw)
In-Reply-To: <5B92514002000078001E64C7@prv1-mh.provo.novell.com>

On 07/09/18 11:21, Jan Beulich wrote:
>>>> On 07.09.18 at 11:57, <andrew.cooper3@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