Avi Kivity wrote:
Jan Kiszka wrote:
Check e.g the diff of hw/vga.c against upstream: All the magic dances
there are required as qemu-kvm tracking
cpu_register_physical_memory and
kvm_log_start cannot cope with all the patterns normal qemu code comes
up with. Upstream slot management now provides the same features
(including migration) like qemu-kvm, it just does not deal with
legacy,
thus it does not have to patch qemu code (rather, we were able to
remove
some already merged hooks - vga_dirty_log_stop).
Still not very restrictive, all this could be encapsulated with for
example macro COMPAT_NO_DMRW which could be removed when we don't care
anymore. Next?
Really, it's not worth the maintenance pain: Every new device emulation
code that wants to be KVM-legacy-compatible would need to be written
like that. And unless you are familiar with the slot management
internals, the "correct" pattern will not be obvious.
Only devices which direct map memory. Currently VGA and cirrus.
--- /data/qemu/hw/piix_pci.c 2009-06-07 09:42:27.000000000 +0200
+++ hw/piix_pci.c 2009-06-02 13:00:09.000000000 +0200
...
@@ -91,6 +93,10 @@ static void i440fx_update_memory_mapping
int i, r;
uint32_t smram, addr;
+ if (kvm_enabled()) {
+ /* FIXME: Support remappings and protection changes. */
+ return;
+ }
update_pam(d, 0xf0000, 0x100000, (d->config[0x59] >> 4) & 3);
for(i = 0; i < 12; i++) {
r = (d->config[(i >> 1) + 0x5a] >> ((i & 1) * 4)) & 3;
IIRC, this is at least partially due to the restricted slot management
in qemu-kvm - or is this obsolete now?