qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [0.14?][PATCH 3/4] ioapic: Prepare for base address rel


From: Jan Kiszka
Subject: Re: [Qemu-devel] [0.14?][PATCH 3/4] ioapic: Prepare for base address relocation
Date: Thu, 03 Feb 2011 20:06:08 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2011-02-03 20:01, Blue Swirl wrote:
> On Thu, Feb 3, 2011 at 6:01 PM, Jan Kiszka <address@hidden> wrote:
>> On 2011-02-03 18:54, Blue Swirl wrote:
>>> On Thu, Feb 3, 2011 at 5:43 PM, Jan Kiszka <address@hidden> wrote:
>>>> On 2011-02-03 18:36, Blue Swirl wrote:
>>>>> On Thu, Feb 3, 2011 at 5:18 PM, Jan Kiszka <address@hidden> wrote:
>>>>>> On 2011-02-03 18:03, Blue Swirl wrote:
>>>>>>> On Thu, Feb 3, 2011 at 2:55 PM, Jan Kiszka <address@hidden> wrote:
>>>>>>>> The registers of real IOAPICs can be relocated during runtime (via
>>>>>>>> chipset registers). We don't support this yet, but qemu-kvm carries the
>>>>>>>> current base address in its version 2 vmstate.
>>>>>>>>
>>>>>>>> To align both implementations for migratability, add the proper
>>>>>>>> infrastructure to accept initial as well as updated base addresses and
>>>>>>>> include the current address in the vmstate. This is done in a way that
>>>>>>>> will also allow multiple IOAPICs in the future.
>>>>>>>
>>>>>>> Nack, the addresses should be device properties.
>>>>>>
>>>>>> Hmm.... we could make default_base_address a property. Will change that.
>>>>>> But current_base_address is just the same as apicbase and can't be a
>>>>>> property.
>>>>>
>>>>> Oh, right. What will current_base_address used for? Why can't board
>>>>> just unmap IOAPIC from current address and remap it at the new
>>>>> address? Then the device would not need to know its base address.
>>>>
>>>> The board could do this. The question is where we put this service, in
>>>> the context if the IOAPIC as ioapic_set_base_address (compare to
>>>> cpu_set_apic_base - which is buggy as it lacks sysbus_mmio_map) or into
>>>> each and every board code. In the latter case, the boards would also be
>>>> responsible for saving/restoring the address.
>>>
>>> How is the device relocated? Where are the chipset registers you mention?
>>
>> Intel's PIIX chipsets contain a register called APICBASE (but it means
>> the IOAPIC), and that defines the location. The analogy in the APIC
>> world is the MSR_IA32_APICBASE which we maintain via the APIC state.
> 
> In ICH10 the register is called OIC—Other Interrupt Control Register
> and the interesting bits APIC Range Select (ASEL).
> 
> So actually PIIX should manage IOAPIC mapping, not board level.

The point is we need ioapic_set_base_address logic in multiple places
(once chipsets start to implement it). Better push it to a central place
from the beginning. Also the bit keeping. There is no difference to
apicbase.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



reply via email to

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