Jan Kiszka wrote:
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?
This is from the first days of qemu-kvm, some of this is due to Intel
real mode issues (can't start at 0xffff ffff ffff fff0), and some I
never got around to. It's possible that it requires proper slot
destruction. Even if that's the case, we cam simply return here, as the
code shows.