From: Avi Kivity <avi@redhat.com>
To: "Kohl, Bernhard (NSN - DE/Munich)" <bernhard.kohl@nsn.com>
Cc: kvm@vger.kernel.org, jan.kiszka@siemens.com, "Ostler,
Thomas (NSN - DE/Munich)" <thomas.ostler@nsn.com>
Subject: Re: [PATCH] Account for Fedora kernels with backported vzalloc
Date: Wed, 18 May 2011 12:20:43 +0300 [thread overview]
Message-ID: <4DD38F6B.9040804@redhat.com> (raw)
In-Reply-To: <81D3255A15981A4B912531E3648B1E16049AD446@DEMUEXC005.nsn-intra.net>
On 05/18/2011 12:11 PM, Kohl, Bernhard (NSN - DE/Munich) wrote:
> >
> > Curious, why are you targetting Fedora kernels at all? They have a
> > really short shelf life. I though kvm-kmod was for people using
> longer
> > term kernels like enterprise distros or long lived embedded projects.
>
> Here at NSN a couple of developers and testers are using Fedora +
> kvm-kmod
> to run some of our systems (with in-house developed OS) on KVM. This
> works
> also without kvm-kmod since kernel 2.6.35 (Fedora 14). The number of
> users
> (which are not Linux experts at all) is growing since over a year.
> Usually
> I prepare and test new versions of kvm-kmod and then it's easy for these
> guys to install it on their machines. So I always keep track to be
> up-to-date with the upstream kvm-kmod.
>
> The next candidate for kvm-kmod usage here might be your patch set
> "KVM in-guest performance monitoring", but I think we need a complete
> kernel for this as major parts of these patches are outside KVM. Some
> people here are eager for this new feature. Accidentally my colleague
> Thomas started investigating the performance counter topic 2 weeks ago.
>
> Nevertheless I hope that kvm-kmod will live for a while. It is quite
> useful for our work.
Yes, I can see how it helps your workflow. I guess the only viable
alternative would be to prepare a full kernel rpm, but that is a lot
more work.
Regarding the PMU, the patchset modifies the core perf_event code and
exports some symbols. We might be able to work around these issues but
this isn't certain.
--
error compiling committee.c: too many arguments to function
prev parent reply other threads:[~2011-05-18 9:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-17 14:55 [PATCH] Account for Fedora kernels with backported vzalloc Bernhard Kohl
2011-05-17 15:27 ` Jan Kiszka
2011-05-17 15:44 ` Kohl, Bernhard (NSN - DE/Munich)
2011-05-17 17:01 ` Jan Kiszka
2011-05-17 17:30 ` Avi Kivity
2011-05-18 9:11 ` Kohl, Bernhard (NSN - DE/Munich)
2011-05-18 9:20 ` Avi Kivity [this message]
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=4DD38F6B.9040804@redhat.com \
--to=avi@redhat.com \
--cc=bernhard.kohl@nsn.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=thomas.ostler@nsn.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.