qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH v2 0/7] APIC/IOAPIC cleanup
Date: Mon, 23 Aug 2010 08:49:37 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100806 Fedora/3.1.2-1.fc13 Thunderbird/3.1.2

 On 08/23/2010 12:06 AM, Anthony Liguori wrote:
On 08/22/2010 03:33 PM, Avi Kivity wrote:
 On 08/22/2010 11:03 PM, Anthony Liguori wrote:
On 08/22/2010 02:44 PM, Avi Kivity wrote:
No more MI diamond and all devices have DeviceStates. Coincidentally, it matches more closely how hardware works..



Well, I agree, but I honestly lost the context. How does this relate to the APIC and cpu hotplug?

My original assertion was that the local APIC is not a DeviceState, but rather it's a CPU feature.

If you look at some of the magic that apic.c has to do in the IO callbacks, it should be clear that it's special.

It's special in that it is connected to a cpu core. So's the RTL8139 device, on one hand connected to a PCI bus, on the other hand connected to a PHY (netdev in qemu).

In the not too distant future, I'd like to move apic.c to target-i386. There should be no need to explicitly instantiate it when you instantiate a CPU.

But then there's a need explicitly not to instantiate it when using -isapc.

No.  isapc has nothing to do with whether a CPU has a local APIC.

You don't instantiate the local APIC if you create a 486 CPU. If you create an isapc with a pentium processor, it's going to have a local APIC although it's irrelevant as it's fully compatible with the 486.


Okay, okay. "But then there's a need explicitly not to instantiate it when modelling a 486 or lower".


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]