On 2011-02-03 18:36, Blue Swirl wrote: > On Thu, Feb 3, 2011 at 5:18 PM, Jan Kiszka <jan.kis...@siemens.com> wrote: >> On 2011-02-03 18:03, Blue Swirl wrote: >>> On Thu, Feb 3, 2011 at 2:55 PM, Jan Kiszka <jan.kis...@siemens.com> 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. Well, unless we have a good reason, I would prefer to keep the split as suggested, also to avoid that qemu-kvm needs to break its vmstate. Jan PS: Another bug in the APIC emulation: cpu_set_apic_base lacks a call to sysbus_mmio_map to update its mapping. -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
