> env = cpu_single_env;
> if (!env)
> @@ -727,7 +762,6 @@ static void apic_mem_writel(void *opaque, target_phys_addr_t addr, uint32_t val)
> printf("APIC write: %08x = %08x\n", (uint32_t)addr, val);
> #endif
>
> - index = (addr >> 4) & 0xff;
> switch(index) {
> case 0x02:
> s->id = (val >> 24);
> @@ -911,6 +945,7 @@ int apic_init(CPUState *env)
> s->cpu_env = env;
>
> apic_reset(s);
> + msix_supported = 1;
>
> /* XXX: mapping more APICs at the same memory location */
> if (apic_io_memory == 0) {
> @@ -918,7 +953,8 @@ int apic_init(CPUState *env)
> on the global memory bus. */
> apic_io_memory = cpu_register_io_memory(0, apic_mem_read,
> apic_mem_write, NULL);
> - cpu_register_physical_memory(s->apicbase & ~0xfff, 0x1000,
> + /* XXX: what if the base changes? */
> + cpu_register_physical_memory(MSI_ADDR_BASE, MSI_ADDR_SIZE,
> apic_io_memory);
+1
I think you have a point here. Your patch is in no way worse than what we had,
but we're currently not handling correctly the case of base address changing.
Guess it is not common in normal apic usage for OSes...
--
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
