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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list