All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Juergen Gross <jgross@suse.com>, Jan Beulich <JBeulich@suse.com>
Cc: Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH 04/20] xen/domctl: Drop vcpu_alloc_lock
Date: Wed, 21 Mar 2018 17:57:00 +0000	[thread overview]
Message-ID: <64ea2315-d8df-af8f-2c4e-fe4fe39d2bd9@citrix.com> (raw)
In-Reply-To: <58b42b13-70c3-0b88-99a8-704745b78acd@suse.com>

On 21/03/18 05:46, Juergen Gross wrote:
> On 20/03/18 18:22, Andrew Cooper wrote:
>> On 20/03/18 16:58, Jan Beulich wrote:
>>>>>> On 19.03.18 at 20:13, <andrew.cooper3@citrix.com> wrote:
>>>> It is not entirely clear why this interlock was introduced in c/s 8cbb5278e
>>>> "x86/AMD: Add support for AMD's OSVW feature in guests".
>>>>
>>>> At the time, svm_handle_osvw() could have seen an unexpected change in OSVW
>>>> (not the case now, due to the new CPUID Policy infrastructure), but even then,
>>>> it would have caused spurious changes in behaviour when handling
>>>> OSVW_{ID_LENGTH,STATUS} read requests on behalf of an already-running guest.
>>>>
>>>> There are plenty of other aspects of domain creation which depend on hardware
>>>> details which may change across a microcode load, but where not protected by
>>>> this interlock.
>>> Are there? We don't re-read CPUID (yet), for example. But of
>>> course it is also not really specified which aspects may change
>>> across microcode updates.
>>>
>>>> A host administrator choosing to perform late microcode loading has plenty of
>>>> other problems to worry about, and is it not unreasonable to expect them to
>>>> temporarily cease domain construction activities while the microcode loading
>>>> is in progress.
>>> But it is also not unreasonable to expect the hypervisor to guard
>>> against inconsistencies here. On the whole I'm not really
>>> convinced; I think I'd like to hear others' opinions.
>> The underlying problem is that this lock cannot say when merging
>> max_cpus into createdomain, because we cannot continue the hypercall
>> midway through.
>>
>> As it doesn't currently protect createdomain, which amongst other things
>> contains init_domain_cpuid_policy() and init_domain_msr_policy() (the
>> most likely structures to be affected by microcode updates), I don't see
>> any purpose in keeping it for the minute area it does cover.
> What about failing domain creation e.g. via -EAGAIN in case a
> microcode update happened in between? This would be easy by adding a
> microcode generation count which would have to be the same for start
> and end of the create domain hypercall.

Failing the hypercall is very complicated once domain_create() has
completed successfully.  See patch 11

(Although in writing this reply, I see that patch 11 is buggy).

Amongst other things, failing that late burns a domid, because there is
a period during which the domain has to live in the domain list.

I don't see the point of trying to retain a broken mechanism, especially
at the expense of error path complexity.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2018-03-21 17:57 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-19 19:13 [PATCH For-4.11 00/20] Improvements to domain creation Andrew Cooper
2018-03-19 19:13 ` [PATCH 01/20] tools/libxl: Drop xc_domain_configuration_t from libxl__domain_build_state Andrew Cooper
2018-03-21 16:09   ` Roger Pau Monné
2018-03-21 17:17   ` Wei Liu
2018-03-19 19:13 ` [PATCH 02/20] tools/libxl: Don't prepare or save xc_config when soft resetting a domain Andrew Cooper
2018-03-21 16:18   ` Roger Pau Monné
2018-03-21 17:35     ` Andrew Cooper
2018-03-21 17:27   ` Wei Liu
2018-03-19 19:13 ` [PATCH 03/20] xen/public: Rename xen_domctl_createdomain.config to arch Andrew Cooper
2018-03-20 16:53   ` Jan Beulich
2018-03-21  5:03   ` Julien Grall
2018-03-21 17:27   ` Wei Liu
2018-03-19 19:13 ` [PATCH 04/20] xen/domctl: Drop vcpu_alloc_lock Andrew Cooper
2018-03-20 16:58   ` Jan Beulich
2018-03-20 17:22     ` Andrew Cooper
2018-03-21  5:46       ` Juergen Gross
2018-03-21 17:57         ` Andrew Cooper [this message]
2018-03-22  7:24           ` Jan Beulich
2018-03-19 19:13 ` [PATCH 05/20] arm/boot: Mark construct_dom0() as __init Andrew Cooper
2018-03-20  3:40   ` Julien Grall
2018-03-20  8:31     ` Julien Grall
2018-03-19 19:13 ` [PATCH 06/20] tools/ocaml: Drop domain_create_flag_table[] Andrew Cooper
2018-03-20 19:42   ` Christian Lindig
2018-03-19 19:13 ` [PATCH 07/20] tools/ocaml: Drop int_array_of_uuid_string() Andrew Cooper
2018-03-19 19:13 ` [PATCH 08/20] tools/ocaml: Pass a full domctl_create_config into stub_xc_domain_create() Andrew Cooper
2018-03-20 19:43   ` Christian Lindig
2018-03-19 19:13 ` [PATCH 09/20] tools: Rework xc_domain_create() to take a full xen_domctl_createdomain Andrew Cooper
2018-03-20 19:42   ` Christian Lindig
2018-03-21 16:44   ` Roger Pau Monné
2018-03-21 17:39   ` Wei Liu
2018-03-19 19:13 ` [PATCH 10/20] xen/domctl: Merge set_max_evtchn into createdomain Andrew Cooper
2018-03-20 19:27   ` Daniel De Graaf
2018-03-20 19:42   ` Christian Lindig
2018-03-21 17:40   ` Wei Liu
2018-03-19 19:13 ` [PATCH 11/20] xen/domctl: Merge set_gnttab_limits " Andrew Cooper
2018-03-19 21:43   ` Christian Lindig
2018-03-20 10:11     ` Andrew Cooper
2018-03-20 19:42       ` Christian Lindig
2018-03-20 19:27   ` Daniel De Graaf
2018-03-21 17:45   ` Wei Liu
2018-03-23 16:08   ` Jan Beulich
2018-03-19 19:13 ` [PATCH 12/20] xen/domctl: Merge max_vcpus " Andrew Cooper
2018-03-20 19:27   ` Daniel De Graaf
2018-03-20 19:42   ` Christian Lindig
2018-03-21 17:46   ` Wei Liu
2018-03-23 16:14   ` Jan Beulich
2018-03-19 19:13 ` [PATCH 13/20] xen/evtchn: Pass max_evtchn_port into evtchn_init() Andrew Cooper
2018-03-26 14:01   ` Jan Beulich
2018-03-19 19:13 ` [PATCH 14/20] xen/gnttab: Remove replace_grant_supported() Andrew Cooper
2018-03-20  3:44   ` Julien Grall
2018-03-26 14:03   ` Jan Beulich
2018-03-19 19:13 ` [PATCH 15/20] xen/gnttab: Export opt_max_{grant, maptrack}_frames Andrew Cooper
2018-03-26 14:17   ` Jan Beulich
2018-03-19 19:13 ` [PATCH 16/20] xen/gnttab: Pass max_{grant, maptrack}_frames into grant_table_create() Andrew Cooper
2018-03-26 14:18   ` Jan Beulich
2018-03-19 19:13 ` [PATCH 17/20] xen/gnttab: Fold grant_table_{create, set_limits}() into grant_table_init() Andrew Cooper
2018-03-26 14:29   ` Jan Beulich
2018-03-19 19:13 ` [PATCH 18/20] xen/dom0: Arrange for dom0_cfg to contain the real max_vcpus value Andrew Cooper
2018-03-20  3:54   ` Julien Grall
2018-03-26 15:19   ` Jan Beulich
2018-03-19 19:13 ` [PATCH 19/20] xen/domain: Call arch_domain_create() as early as possible in domain_create() Andrew Cooper
2018-03-26 15:58   ` Jan Beulich
2018-03-19 19:13 ` [PATCH 20/20] xen/domain: Allocate d->vcpu[] in arch_domain_create() Andrew Cooper
2018-03-20  4:17   ` Julien Grall
2018-03-20 15:28   ` [PATCH v1.5 " Andrew Cooper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=64ea2315-d8df-af8f-2c4e-fe4fe39d2bd9@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.