| Message ID | 217accd40903272153m650b0f1ata7bc899eb4b92be0@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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++?
> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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?
> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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; }; };
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(-)