Re: [PATCH] KVM: Make kvm header compile under g++.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux