Anthony Liguori wrote: >>> >>> If we do this, then we can probably just handle the TPR as a special >>> case anyway and not bother returning to userspace when the TPR is >>> updated through MMIO. That saves the round trip without adding >>> emulation complexity. >> >> That means the emulation is split among user space and kernel. Not >> nice. One of the advantages of moving the entire thing is that it is >> at least clearly defined. > > It still exists in userspace. Having the code duplication (especially > when it's not the same code base) is unfortunate.
This remains true. > Plus, it complicates save/restore/migration since now some device > state is in the kernel. It further complicates things if you want to > make sure that KVM saved images are loadable in QEMU (you have to make > sure that the device state is identical for the kernel and userspace). You'd just load the kernel state into qemu state, like we do with the registers, and use the regular qemu save. You could turn kernel apic emulation on and off during runtime :) > Special casing the TPR emulation seems like the lesser of two evils to > me. It's not just the tpr. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
