From: Jan Kiszka <jan.kiszka@siemens.com>
To: Abel Gordon <ABELG@il.ibm.com>
Cc: Nadav Har'El <NYH@il.ibm.com>, GaoYi <gaoyi709@gmail.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Michael D Day <mdday@us.ibm.com>, Avi Kivity <avi@redhat.com>,
Muli Ben-Yehuda <muli@cs.technion.ac.il>,
Nadav Amit <nadav.amit@gmail.com>
Subject: Re: [Qemu-devel] Will the ELI incorporated in theKVM?
Date: Thu, 20 Sep 2012 09:14:31 +0200 [thread overview]
Message-ID: <505AC257.3080000@siemens.com> (raw)
In-Reply-To: <OFB446208E.3A636A57-ONC2257A7F.0024D1F8-C2257A7F.00264E8C@il.ibm.com>
On 2012-09-20 08:58, Abel Gordon wrote:
>
>
> GaoYi <gaoyi709@gmail.com> wrote on 20/09/2012 08:42:51 AM:
>
>> The CPU isolation in Hitachi patches is just to improve the real
>> time performance of GUEST. The core of it, direct IRQ delivery, is
>> very similar to that of ELI.
>> For the ELI patches,
>> (1) Since EOI part of ELI is already supported by the Intel
>> Sandy Bridge CPUs and requires modifications on GUEST code, it
>> should not be included in the KVM. Only the ELI delivery part, which
>> plays a vital role in performance improvement, should be considered.
>
> Giving to the guest direct access to the EOI MSR (if x2APIC is available)
> is what we call "ELI completion". Note this mechanism is not so simple,
> there are some cases (which are not part of the critical path) where ELI
> must trap
> EOIs. For the APLOS paper evaluation we didn't have CPUs with x2APIC so we
> simulated the behavior changing the guest code.
> In any case, as you can see in the paper, the big part of the improvement
> comes from "ELI delivery". "ELI completion" improvement will be
> even smaller with the latest KVM EOI optimizations for the memory based
> LAPIC.
>
>> (2) It should be provided in the kvm-kmod or qemu-kvm ( not just
>> for some linux kernel as Hitachi patches do), to make this part
>> independent of linux kernel version.
>
> Exactly, ELI only modifies the kvm kernel module and qemu-kvm but we should
> also modify VFIO for newer kvm versions.
Again: If you think the feature is non-invasive, send patches against
the kernel and QEMU.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2012-09-20 7:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-18 12:50 [Qemu-devel] Will the ELI incorporated in theKVM? GaoYi
2012-09-18 13:08 ` Jan Kiszka
2012-09-19 13:37 ` Muli Ben-Yehuda
2012-09-19 14:10 ` Jan Kiszka
2012-09-19 14:20 ` Avi Kivity
2012-09-19 14:43 ` Abel Gordon
2012-09-19 14:46 ` Jan Kiszka
2012-09-20 5:42 ` GaoYi
2012-09-20 6:58 ` Abel Gordon
2012-09-20 7:14 ` Jan Kiszka [this message]
2012-09-20 7:19 ` Gleb Natapov
2012-09-20 9:18 ` Avi Kivity
2012-09-20 9:22 ` Gleb Natapov
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=505AC257.3080000@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=ABELG@il.ibm.com \
--cc=NYH@il.ibm.com \
--cc=avi@redhat.com \
--cc=gaoyi709@gmail.com \
--cc=mdday@us.ibm.com \
--cc=muli@cs.technion.ac.il \
--cc=nadav.amit@gmail.com \
--cc=qemu-devel@nongnu.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;
as well as URLs for NNTP newsgroup(s).