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
