All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jason Andryuk <jandryuk@gmail.com>
Cc: sstabellini@kernel.org, Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org, julien.grall@arm.com,
	Jan Beulich <JBeulich@suse.com>,
	roger.pau@citrix.com
Subject: Re: [PATCH 3/3] xen/vcpu: Rework sanity checks in vcpu_create()
Date: Fri, 7 Sep 2018 00:01:32 +0100	[thread overview]
Message-ID: <6e5f11bb-bd6d-5d76-24f4-62f71224f60c@citrix.com> (raw)
In-Reply-To: <CAKf6xpvAYJryWPCjtNPhNbU9v3p1+ihMH=FqoPzb1Nc65KHSCQ@mail.gmail.com>

On 06/09/18 21:07, Jason Andryuk wrote:
> On Thu, Sep 6, 2018 at 3:28 PM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> Poisoning idle_vcpu[0] with the sanity debug value isn't actually a clever
>> idea, because it passes a NULL pointer check but isn't a usable vcpu.  It is
>> also the reason for the (!is_idle_domain(d) || vcpu_id) part of the existing
>> sanity BUG_ON().
>>
>> Now that d->max_vcpus is appropriately set up before vcpu_create() is called,
>> we can properly range check the requested vcpu_id.  Drop the BUG_ON() and
>> replace it with code which is runtime safe but non-fatal.
>>
>> While v0 must be the first allocated vcpu for for_each_vcpu() to work, it
>> isn't a requirement for the threading the vcpu into the linked list, so update
>> the threading code to be more generic, and add a comment explaining why we
>> need to search for prev_id.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>> CC: Jan Beulich <JBeulich@suse.com>
>> CC: Wei Liu <wei.liu2@citrix.com>
>> CC: Roger Pau Monné <roger.pau@citrix.com>
>> CC: Stefano Stabellini <sstabellini@kernel.org>
>> CC: Julien Grall <julien.grall@arm.com>
>> ---
>>  xen/arch/arm/setup.c |  1 -
>>  xen/arch/x86/setup.c |  1 -
>>  xen/common/domain.c  | 32 ++++++++++++++++++++++++++++----
>>  3 files changed, 28 insertions(+), 6 deletions(-)
>>
>> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
>> index 01aaaab..d06ac40 100644
>> --- a/xen/arch/arm/setup.c
>> +++ b/xen/arch/arm/setup.c
>> @@ -704,7 +704,6 @@ void __init start_xen(unsigned long boot_phys_offset,
>>      set_processor_id(0); /* needed early, for smp_processor_id() */
>>
>>      set_current((struct vcpu *)0xfffff000); /* debug sanity */
>> -    idle_vcpu[0] = current;
>>
>>      setup_virtual_regions(NULL, NULL);
>>      /* Initialize traps early allow us to get backtrace when an error occurred */
>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>> index a2f22a1..5e1e8ae 100644
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -691,7 +691,6 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>
>>      set_processor_id(0);
>>      set_current(INVALID_VCPU); /* debug sanity. */
>> -    idle_vcpu[0] = current;
> xen/arch/x86/tboot.c:tboot_shutdown() has:
>     if ( idle_vcpu[0] != INVALID_VCPU )
>         write_ptbase(idle_vcpu[0]);
>
> With your change, this should be update to check for non-NULL.

Oh - very good catch.  Thanks.

Looking at the code, ideally it would change to
write_cr3(idle_pg_table), but that isn't going to include the additional
CR4 changes.  Leaving this in this form (with a NULL) check is probably
best.

~Andrew

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

  reply	other threads:[~2018-09-06 23:01 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-06 19:25 [PATCH 0/3] xen: Improvements to the vcpu create/destroy paths Andrew Cooper
2018-09-06 19:25 ` [PATCH 1/3] xen/vcpu: Rename the common interfaces for consistency Andrew Cooper
2018-09-07  9:52   ` Jan Beulich
2018-09-13 10:29   ` Roger Pau Monné
2018-09-17  1:08   ` Julien Grall
2018-09-06 19:25 ` [PATCH 2/3] xen/vcpu: Introduce vcpu_destroy() Andrew Cooper
2018-09-07  9:53   ` Jan Beulich
2018-09-13 10:32   ` Roger Pau Monné
2018-09-06 19:25 ` [PATCH 3/3] xen/vcpu: Rework sanity checks in vcpu_create() Andrew Cooper
2018-09-06 20:07   ` Jason Andryuk
2018-09-06 23:01     ` Andrew Cooper [this message]
2018-09-07 10:15   ` Jan Beulich
2018-09-07 19:17     ` Andrew Cooper
2018-09-11 16:46   ` [PATCH v2] " Andrew Cooper
2018-09-12 11:38     ` Jason Andryuk
2018-09-12 15:00     ` Jan Beulich

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=6e5f11bb-bd6d-5d76-24f4-62f71224f60c@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=jandryuk@gmail.com \
    --cc=julien.grall@arm.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=wei.liu2@citrix.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.