nathan binkert wrote:
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.
libkvm suffers from not abstracting things enough. Since it was
rejected from upstream qemu, it is unlikely to survive for much longer
(though I think it has merit, it shouldn't be the case that everyone has
to keep reimplementing this stuff).
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.
You could do that with performance counters, although it would require
kernel changes.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
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
