Re: [Qemu-devel] target-i386: clear bsp bit when designating bsp

[Paolo Bonzini <pbonzini@redhat.com>]

On 07/04/2015 15:40, Andreas Färber wrote:
> 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.

You cannot tell, since the MP protocol reruns immediately after a full
reset.  I think we do this in apic_cpu_reset to avoid mess with the
initialization order of the APIC and CPU.

> 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.

Yes, I agree, but as you know very well the propagation of signals (be
it "reset" or "realize") is a mess.

Even if you make the APIC a QOM child of the CPU, this doesn't mean that
qdev reset (which is post-order) propagates to the APIC before
propagating to the CPU.

> 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.

Well, actually I did post it for inclusion in 2.3 since it affected only
KVM and it would be ugly to have 4.0 fail kvm-unit-tests with all
existing QEMU releases.

Paolo