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

[Avi Kivity <avi@redhat.com>]

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.