On Thu, Feb 3, 2011 at 5:43 PM, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote: > On 2011-02-03 18:36, Blue Swirl wrote: >> On Thu, Feb 3, 2011 at 5:18 PM, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote: >>> On 2011-02-03 18:03, Blue Swirl wrote: >>>> On Thu, Feb 3, 2011 at 2:55 PM, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> 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? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
