On 19 February 2013 16:05, Jan Kiszka <jan.kis...@siemens.com> wrote: > On 2013-02-19 16:54, Peter Maydell wrote: >> On 19 February 2013 15:51, Jan Kiszka <jan.kis...@siemens.com> wrote: >>> On 2013-02-19 16:20, Michael S. Tsirkin wrote: >>>> qdev_init_nofail(dev); >>>> d = SYS_BUS_DEVICE(dev); >>>> - sysbus_mmio_map(d, 0, 0xfec00000); >>>> + /* APIC overlaps the PCI window. */ >>>> + sysbus_mmio_map_overlap(d, 0, 0xfec00000, 1000); >>> >>> That's the IOAPIC, not the APIC. If you mean the IOAPIC, APIC and HPET >>> would require higher prio, too. But I suppose this is really about the >>> APIC and its special priority due to CPU-local access dispatching, right? >> >> Is this a proposed minimally invasive patch for 1.4 with a >> different approach (possibly involving reworking things with >> a better managed set of container regions) for master, or >> is this the planned fix for master too? > > I'm not yet sure we need any overhaul at all. If hardware prioritizes > certain windows like APIC, IOAPIC, HPET over PCI device mappings, then > we can already express this today - we just need to do it.
Yes, indeed, but there are different ways to do it with the API we have at the moment (the patch above being one way). On reflection it's probably a reasonable approach since we can't currently set up CPUs to dispatch memory accesses to an arbitrary MemoryRegion.[*] [*] by which I mean that really the correct model for this would be something like: the CPU cores live inside a QOM container object which also has the CPU-local devices like the IOAPIC &c inside it. This container has a container memory region which is set up as "background region == the MR which the board model passes to us; overlaid at higher priority == CPU-local devices", and that container MR is then what you pass to the CPU cores as their view of the address space. I don't suppose we'll go down that path until we have a compelling reason to implement multiple bus masters with different views of the address space, though. -- PMM
