Il 22/08/2013 12:34, Laszlo Ersek ha scritto:
<academic>
Actually it's fine to clarify these things! Hence the longish digression below.
I think before priority comes into the picture, the access size would matter first, no?
(I think I'm recalling this from the 0xCF9 reset control register, which falls into the [0xCF8..0xCFA] range.)
The base address is what matters. A 2- or 4-byte access to x will always go to the region that includes address x, even if there are other regions between x and respectively x+1 or x+3. So an access to 0xCF8 will go to the PCI address register, while an access to 0xCF9 will always go to the reset control register. This happens in address_space_translate_internal: diff = int128_sub(section->mr->size, int128_make64(addr)); For a write to 0xCF8, addr would be 0 (it is relative to the base of the MemoryRegion). section->size would be 1 because the next section starts at 0xCF9. However, section->mr->size would be 4 as specified e.g. in i440fx_pcihost_initfn: memory_region_init_io(&s->conf_mem, obj, &pci_host_conf_le_ops, s, "pci-conf-idx", 4); Using section->size would be wrong---it would attempt a 1-byte write to 0xCF8, another 1-byte write to 0xCF9, and a 2-byte write to 0xCFA. section->mr->size instead does a single write to 0xCF8, the same as on real hardware. BTW, the behavior changed slightly in QEMU 1.6 for 8-byte accesses. All such accesses were split to two 4-byte accesses before; now the maximum size of a "direct" MMIO operation (the data bus size, effectively) is 64 bits, so a 64-bit write will always address a single MemoryRegion. For example, say you had the PCI address and data registers occupying two separate 4-byte MemoryRegions in 8 consecutive bytes of memory. In 1.5 you could write both of them with a single 64-bit write. In 1.6, this would only write four bytes to the first MemoryRegion. This matches hardware more closely, and is really unlikely to be a problem: a target with 32-bit data bus probably would not have 64-bit CPU registers to begin with. If it did, it would resemble the architecture of the 80386SX or 8088 processors.
Unless ioport 0 is accessed with width 1 for dma-chan purposes, I think such an access would be unique to pvpanic, and always dispatched to pvpanic.
It is: static const MemoryRegionOps channel_io_ops = { .read = read_chan, .write = write_chan, .endianness = DEVICE_NATIVE_ENDIAN, .impl = { .min_access_size = 1, .max_access_size = 1, }, };
Channel 0 is (was) used for DRAM refresh, so it should not have any visible effect. However, it may not be entirely disabling pvpanic, just making it mostly invisible.
That's good enough for the guest to reach kexec :)
Yes, I cannot deny that. :) Paolo