From: Avi Kivity <avi@redhat.com>
To: nathan binkert <nate@binkert.org>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: Make kvm header compile under g++.
Date: Tue, 07 Apr 2009 20:11:44 +0300 [thread overview]
Message-ID: <49DB8950.7090605@redhat.com> (raw)
In-Reply-To: <217accd40904070944p258080a2i8897212b471dd96b@mail.gmail.com>
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.
next prev parent reply other threads:[~2009-04-07 17:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-28 4:53 [PATCH] KVM: Make kvm header compile under g++ nathan binkert
2009-04-06 18:57 ` nathan binkert
2009-04-07 10:16 ` Avi Kivity
2009-04-07 16:44 ` nathan binkert
2009-04-07 17:11 ` Avi Kivity [this message]
2009-04-07 17:25 ` nathan binkert
2009-04-09 16:10 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49DB8950.7090605@redhat.com \
--to=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=nate@binkert.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox