> Excellent. One of the things I'm trying hard to do is keep kvm from being a > 'qemu accelerator' and generally useful for other projects. That is, I'm > trying to keep the userspace interface neutral, and not to model exactly the > hardware qemu provides but allow for other configurations. > > One example where we failed to do this is in mapping interrupts, where PIC > IRQ line n was tied to IOAPIC INTI line n. This came back to bite us when > qemu changed its model. > > So if you notice such issues in kvm please bring them up so we can fix them. I certainly will, and I have noticed such things already. They're mostly problems for me in libkvm at this point. I haven't noticed any big problems with KVM itself yet. I'm going back and forth as to whether or not I want to use libkvm at all, though if you're receptive to changes to that interface, I'll definitely keep that in mind. On the other hand, since I'm using C++, I may just write a C++ libkvm and try to give it to you guys. I will try to work with the existing libkvm for now though. > If you're interested in determinism, can't you just warm up the system once > and then save the state? We often do stuff like that. We drop checkpoints and run from the checkpoints, but the problem with that is that we often change things in such a way that you need to boot fresh again. If we change a device model or the kernel there's no getting around it. There are more subtle things though. For example, if you warm up a simulation with a simulated Gigabit ethernet and then decide that you really wanted 10 Gig, you can't just change it when you resume the checkpoint because TCP takes a while to warm up. We could of course warm up further from the checkpoint, but if you were to go in the reverse direction 10G -> 1G, TCP starts dropping packets and it takes a long time in a simulator to deal with that. If I can impose a good enough notion of time, I can deal with those things. Determinism is another issue altogether. Our simulator is deterministic, and we'd love to keep that property, but that's even more difficult, unless we can figure out a way to tell KVM to do something like "execute up to 100 instructions right now". I'm pretty far from really worrying about these problems. I do have lots of ideas and I know that there are a bunch of papers out there that work on this sort of thing. Thanks again, Nate -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
