All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Cc: Eduardo Habkost <ehabkost@redhat.com>,
	Nadav Amit <namit@cs.technion.ac.il>,
	mst@redhat.com, Igor Mammedov <imammedo@redhat.com>,
	nadav.amit@gmail.com, rth@twiddle.net
Subject: Re: [Qemu-devel] target-i386: clear bsp bit when designating bsp
Date: Tue, 07 Apr 2015 13:57:34 +0200	[thread overview]
Message-ID: <5523C62E.6010507@suse.de> (raw)
In-Reply-To: <5523BB00.3040404@suse.de>

Am 07.04.2015 um 13:09 schrieb Andreas Färber:
> Am 07.04.2015 um 12:54 schrieb Paolo Bonzini:
>> On 07/04/2015 12:44, Andreas Färber wrote:
>>>>> It can change at runtime, though, if you're using the KVM in-kernel LAPIC.
>>> Got a pointer? A quick git-grep doesn't show anything in hw/ or
>>> kvm-all.c or target-i386/ assigning cpu_index, so it'll always have the
>>> initial value.
>>
>> Not cpu_index, s->apicbase's MSR_IA32_APICBASE_BSP bit can change with
>> KVM in-kernel LAPIC.  It cannot change with QEMU's userspace LAPIC.
>>
>> Because it can change, you have to call apic_designate_bsp for all CPUs
>> and not only on CPU 0.
> 
> Now I'm even more confused. Surely CPUState is initially
> zero-initialized. Then we designate one as BSP on reset. That should be
> the same result as designating all non-BSP CPUs, no? The only way that
> would change is then cpu_index == 0 goes away (hot-unplug, not
> implemented yet), and in that case it would be about designating a
> different CPU, not about un-designating one.
> 
> If this is some issue with sync'ing state back and forth before QEMU and
> KVM then the real issue has not been explained.

Hm, hw/intc/apic_common.c:apic_reset_common() has:

    bsp = cpu_is_bsp(s->cpu);
    s->apicbase = APIC_DEFAULT_ADDRESS |
        (bsp ? MSR_IA32_APICBASE_BSP : 0) | MSR_IA32_APICBASE_ENABLE;

What this is doing is really:

    bsp = cpu_get_apic_base(s->cpu->apic_state) & MSR_IA32_APICBASE_BSP;
    s->apicbase = APIC_DEFAULT_ADDRESS |
        (bsp ? MSR_IA32_APICBASE_BSP : 0) | MSR_IA32_APICBASE_ENABLE;

Unless I'm missing something, since we are in the APIC device's reset
function, this is effectively a twisted way of writing:

    bsp = s->apicbase & MSR_IA32_APICBASE_BSP;
    s->apicbase = APIC_DEFAULT_ADDRESS |
        (bsp ? MSR_IA32_APICBASE_BSP : 0) | MSR_IA32_APICBASE_ENABLE;

In which case we already relied on s->cpu and could thus simply change
this to something like:

    bsp = CPU(s->cpu)->cpu_index == 0;
    s->apicbase = APIC_DEFAULT_ADDRESS |
        (bsp ? MSR_IA32_APICBASE_BSP : 0) | MSR_IA32_APICBASE_ENABLE;

Then the apicbase manipulation would be nicely encapsulated in the APIC
rather than the APIC reset retaining it and the CPU reset meddling with
its state.

Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)

  reply	other threads:[~2015-04-07 11:57 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-01 23:58 [Qemu-devel] target-i386: clear bsp bit when designating bsp Nadav Amit
2015-04-02 12:34 ` Paolo Bonzini
2015-04-07 10:15   ` Andreas Färber
2015-04-07 10:34     ` Paolo Bonzini
2015-04-07 10:44       ` Andreas Färber
2015-04-07 10:54         ` Paolo Bonzini
2015-04-07 11:09           ` Andreas Färber
2015-04-07 11:57             ` Andreas Färber [this message]
2015-04-07 13:14               ` Igor Mammedov
2015-04-07 13:24                 ` Andreas Färber
2015-04-07 13:29                   ` Paolo Bonzini
2015-04-07 13:40                     ` Andreas Färber
2015-04-07 13:54                       ` Paolo Bonzini
2015-04-07 13:18               ` Paolo Bonzini
2015-04-07 13:26                 ` Denis V. Lunev
2015-04-07 13:29                   ` Paolo Bonzini
2015-04-07 13:44                     ` Denis V. Lunev
2015-04-07 13:47                       ` Andreas Färber

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=5523C62E.6010507@suse.de \
    --to=afaerber@suse.de \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=mst@redhat.com \
    --cc=nadav.amit@gmail.com \
    --cc=namit@cs.technion.ac.il \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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.