From: Arjan van de Ven <arjan@linux.intel.com>
To: Andy Lutomirski <luto@amacapital.net>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: KVM list <kvm@vger.kernel.org>
Subject: Re: Should KVM_GUEST stop depending on PARAVIRT?
Date: Mon, 27 Jul 2015 12:04:55 -0700 [thread overview]
Message-ID: <55B680D7.1000206@linux.intel.com> (raw)
In-Reply-To: <CALCETrUcdY0_Uz9ScE=_86jcV-8NeYS51CyePnwNekZttNNwqw@mail.gmail.com>
On 7/27/2015 11:45 AM, Andy Lutomirski wrote:
>> With PARAVIRT=y it never #GPs:
>>
>> .read_msr = native_read_msr_safe,
>> .write_msr = native_write_msr_safe,
>>
>> I don't remember if it's this way on bare-metal too.
>
> Oh, whoops, I missed the "_safe". IMO that's just a bug, and I guess
> KVM relies on it?
btw it's a common misperception that _safe is actually safe;-)
they're still highly dangerous, just they won't fault on the linux side
>
> ISTM the host should be fixed so that a non-PARAVIRT guest won't crash
> when using perf (if it indeed currently crashes) and/or the perf code
> should be fixed to work without this bug^Wfeature.
>
> Then KVM_GUEST kernels could be de-bloated by dropping PARAVIRT.
>
> Hi Arjan- A quick and dirty measurement suggests that this would save
> 2-3 ms when booting a KVM_GUEST=y kernel under KVM by turning
> apply_paravirt into a noop.
nice
next prev parent reply other threads:[~2015-07-27 19:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-24 17:33 Should KVM_GUEST stop depending on PARAVIRT? Andy Lutomirski
2015-07-27 13:59 ` Paolo Bonzini
2015-07-27 15:56 ` Andy Lutomirski
2015-07-27 17:49 ` Paolo Bonzini
2015-07-27 17:51 ` Andy Lutomirski
2015-07-27 18:30 ` Paolo Bonzini
2015-07-27 18:45 ` Andy Lutomirski
2015-07-27 19:04 ` Arjan van de Ven [this message]
2015-07-28 9:57 ` Paolo Bonzini
2015-07-29 0:23 ` Andy Lutomirski
2015-07-29 4:49 ` Venkatesh Srinivas
2015-07-29 8:27 ` Paolo Bonzini
2015-07-29 9:19 ` Peter Zijlstra
2015-07-29 9:24 ` Paolo Bonzini
2015-07-29 9:40 ` Peter Zijlstra
2015-07-29 9:41 ` Paolo Bonzini
2015-07-30 0:14 ` Andy Lutomirski
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=55B680D7.1000206@linux.intel.com \
--to=arjan@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=pbonzini@redhat.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.