All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
	mst@redhat.com, Nadav Amit <namit@cs.technion.ac.il>,
	qemu-devel@nongnu.org, 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 15:40:05 +0200	[thread overview]
Message-ID: <5523DE35.5050103@suse.de> (raw)
In-Reply-To: <5523DBC6.5000102@redhat.com>

Am 07.04.2015 um 15:29 schrieb Paolo Bonzini:
> On 07/04/2015 15:24, Andreas Färber wrote:
>>>>     /* We hard-wire the BSP to the first CPU. */
>>>>     if (s->cpu_index == 0) {
>>>>         apic_designate_bsp(cpu->apic_state);
>>>>     }
>> I know, that's what this patch is changing, and I am saying that by the
>> same logic the CPU has no business fiddling with the APIC's apicbase
>> field when the APIC's reset is touching that very same field.
> 
> That's exactly what a real CPU does on power up or #RESET, though.

Does the APIC retain its BSP bit value on #RESET though? I doubt it.
It feels we're awkwardly working around qdev reset semantics here...

If you say the CPU must be in charge, then we should assure that the
APIC is reset before the CPU designates it and not have the APIC reset
callback retain such bits.

Admittedly, if this were for-2.3 (as which it is not marked) then this
patch may be the least intrusive. But it isn't and I've been preparing
to refactor the CPU-APIC relationship, so I really want to get it right
long-term.

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 13:40 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
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 [this message]
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=5523DE35.5050103@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.