From: Jan Kiszka <jan.kiszka@siemens.com>
To: Muli Ben-Yehuda <muli@cs.technion.ac.il>
Cc: Nadav Har'el <nyh@il.ibm.com>, GaoYi <gaoyi709@gmail.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Avi Kivity <avi@redhat.com>, Nadav Amit <nadav.amit@gmail.com>,
Abel Gordon <abelg@il.ibm.com>
Subject: Re: [Qemu-devel] Will the ELI incorporated in theKVM?
Date: Wed, 19 Sep 2012 16:10:54 +0200 [thread overview]
Message-ID: <5059D26E.2050808@siemens.com> (raw)
In-Reply-To: <20120919133720.GB22659@snow>
[putting Avi on CC as the final decision maker]
On 2012-09-19 15:37, Muli Ben-Yehuda wrote:
> On Tue, Sep 18, 2012 at 03:08:40PM +0200, Jan Kiszka wrote:
>> On 2012-09-18 14:50, GaoYi wrote:
>>> Hi Jan,
>>>
>>> I have followed a previous thread about ELI proposed by Abel Gordon, http://www.spinics.net/lists/kvm/msg73907.html.
>>> I wonder whether this mechanism will be incorporated in KVM someday.
>>
>> Likely not. Both Intel and AMD will soon ship hardware that
>> obsoletes this invasive and imperfect software solution, see also
>> [1].
>
> Hi Jan,
>
> I think this decision may be short-sighted. First, it remains to be
> seen how good the upcoming hardware support for interrupt
> virtualization will be once it ships. Second, history has been pretty
> consistent in that it takes several years for hardware to catch up to
> software, and even when it does, software sometimes still wins. (There
> are workloads where shadow page tables still outperform EPT/NPT, to
> give a concrete example). Although ELI works today, I'd be happy to
> hear what parts of it you find "invasive" and "imperfect" (what
> software ever is perfect?)
It's imperfect as you need to dedicate a core to pure guest-mode load
and cannot run userspace on that core (cannot walk through
userspace-based device models e.g.). And it requires that magic bar to
map the shadow IDT into the guest (hmm, I think Hitachi avoided this).
It's invasive as it has to change Linux to maintain those isolated slave
CPUs. That is, of course, based on code that was published by Hitachi.
Yours may differ but will still have to solve the same problems.
Back then in our discussion, it was unclear if and when real hardware
will actually show up. Now the spec is already there, hardware should
follow within months (typically). I'm not aware of limitations regarding
zero-exit virtualization so far. But please share any insights you
collected from studying the specs or recent patches!
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2012-09-19 14:11 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 [this message]
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
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=5059D26E.2050808@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=abelg@il.ibm.com \
--cc=avi@redhat.com \
--cc=gaoyi709@gmail.com \
--cc=muli@cs.technion.ac.il \
--cc=nadav.amit@gmail.com \
--cc=nyh@il.ibm.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 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.