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

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

[nathan binkert]

Two things needed fixing: 1) g++ does not allow a named structure type
within an anonymous union and 2) Avoid name clash between two padding
fields within the same struct by giving them different names as is
done elsewhere in the header.


Signed-off-by: Nathan Binkert <nate@binkert.org>
---
 include/linux/kvm.h |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index ee755e2..2e3a734 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -119,7 +119,7 @@ struct kvm_run {
 			__u32 error_code;
 		} ex;
 		/* KVM_EXIT_IO */
-		struct kvm_io {
+		struct {
 #define KVM_EXIT_IO_IN  0
 #define KVM_EXIT_IO_OUT 1
 			__u8 direction;
@@ -224,10 +224,10 @@ struct kvm_interrupt {
 /* for KVM_GET_DIRTY_LOG */
 struct kvm_dirty_log {
 	__u32 slot;
-	__u32 padding;
+	__u32 padding1;
 	union {
 		void __user *dirty_bitmap; /* one bit per page */
-		__u64 padding;
+		__u64 padding2;
 	};
 };

-- 
1.6.1.2

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

[nathan binkert]

Hi Avi,

You said that you'd be willing to include this.  I don't want to
pester or anything, but I would like it to not fall into the abyss.
Would you like me to file it as a bug and assign it to you?  Are there
any changes that you'd like?

The one change you mentioned was to pull struct kvm_io outside of
struct kvm_run.  I mentioned that a grep shows no usage of kvm_io
anywhere, so I didn't do that.

  Nate

On Fri, Mar 27, 2009 at 9:53 PM, nathan binkert <nate@binkert.org> wrote:
> Two things needed fixing: 1) g++ does not allow a named structure type
> within an anonymous union and 2) Avoid name clash between two padding
> fields within the same struct by giving them different names as is
> done elsewhere in the header.
>
>
> Signed-off-by: Nathan Binkert <nate@binkert.org>
> ---
>  include/linux/kvm.h |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/kvm.h b/include/linux/kvm.h
> index ee755e2..2e3a734 100644
> --- a/include/linux/kvm.h
> +++ b/include/linux/kvm.h
> @@ -119,7 +119,7 @@ struct kvm_run {
>                        __u32 error_code;
>                } ex;
>                /* KVM_EXIT_IO */
> -               struct kvm_io {
> +               struct {
>  #define KVM_EXIT_IO_IN  0
>  #define KVM_EXIT_IO_OUT 1
>                        __u8 direction;
> @@ -224,10 +224,10 @@ struct kvm_interrupt {
>  /* for KVM_GET_DIRTY_LOG */
>  struct kvm_dirty_log {
>        __u32 slot;
> -       __u32 padding;
> +       __u32 padding1;
>        union {
>                void __user *dirty_bitmap; /* one bit per page */
> -               __u64 padding;
> +               __u64 padding2;
>        };
>  };
>
> --
> 1.6.1.2
>

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

[Avi Kivity]

nathan binkert wrote:
> Hi Avi,
>
> You said that you'd be willing to include this.  I don't want to
> pester or anything, but I would like it to not fall into the abyss.
> Would you like me to file it as a bug and assign it to you?  Are there
> any changes that you'd like?
>   

No, I just missed your patch.  Applied now.  Thanks for pestering, it's 
the right thing when I miss something (copying me also helps).

btw, can you share what you're doing with kvm and g++?

-- 
error compiling committee.c: too many arguments to function

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

[nathan binkert]

> No, I just missed your patch.  Applied now.  Thanks for pestering, it's the
> right thing when I miss something (copying me also helps).
Thanks.

> btw, can you share what you're doing with kvm and g++?

I am a researcher at HP Labs studying system architecture.  For many
years, I have been involved in a simulator project called M5
(m5sim.org).  It shares a lot of things in common with qemu/kvm,
except instead of performance as our number one goal, measurement is
our number one goal.  We model many aspects of computer systems in
detail trying to understand how to build future systems.  We support a
number of architectures and are right now trying to finish x86
support.  We want M5 to be able to do everything x86 by itself, but I
was looking into the feasibility of using KVM as a fast "CPU" model to
help us get workloads running at an interesting point quickly at which
point we can switch over to a more detailed CPU model.  Since M5 does
all of the modeling of memory, devices, and interrupts itself, this
really would use just the KVM bits and not use QEMU.  We can also use
KVM in a single stepping mode to validate the correctness of the
simulator itself.

My initial playing around with the code looks pretty promising.  The
only big question mark I have is how to deal with time.  I really need
the simulator to control what the VCPU understands as the passage of
time (think about exactly when interrupts arrive, or exactly how VCPUs
advance with respect to each other when they're communicating through
shared memory).  This has to be done to properly warm up the system.
I'm not concerned about whether I can do it at all.  I just want to
make sure that I maintain the speed of KVM while I do it.

Anyway, thanks for your hard work!

  Nate

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

[Avi Kivity]

nathan binkert wrote:
>> btw, can you share what you're doing with kvm and g++?
>>     
>
> I am a researcher at HP Labs studying system architecture.  For many
> years, I have been involved in a simulator project called M5
> (m5sim.org).  It shares a lot of things in common with qemu/kvm,
> except instead of performance as our number one goal, measurement is
> our number one goal.  We model many aspects of computer systems in
> detail trying to understand how to build future systems.  We support a
> number of architectures and are right now trying to finish x86
> support.  We want M5 to be able to do everything x86 by itself, but I
> was looking into the feasibility of using KVM as a fast "CPU" model to
> help us get workloads running at an interesting point quickly at which
> point we can switch over to a more detailed CPU model.  Since M5 does
> all of the modeling of memory, devices, and interrupts itself, this
> really would use just the KVM bits and not use QEMU.  We can also use
> KVM in a single stepping mode to validate the correctness of the
> simulator itself.
>   

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.

> My initial playing around with the code looks pretty promising.  The
> only big question mark I have is how to deal with time.  I really need
> the simulator to control what the VCPU understands as the passage of
> time (think about exactly when interrupts arrive, or exactly how VCPUs
> advance with respect to each other when they're communicating through
> shared memory).  This has to be done to properly warm up the system.
> I'm not concerned about whether I can do it at all.  I just want to
> make sure that I maintain the speed of KVM while I do it.
>   

If you're interested in determinism, can't you just warm up the system 
once and then save the state?

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

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

[nathan binkert]

> 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

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

[Avi Kivity]

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.