From: Anthony Liguori <aliguori@us.ibm.com>
To: "Nakajima, Jun" <jun.nakajima@intel.com>
Cc: kvm-devel <kvm-devel@lists.sourceforge.net>,
virtualization@lists.linux-foundation.org
Subject: Re: [kvm-devel] [PATCH 3/3] Eliminate read_cr3 on TLB flush
Date: Wed, 30 May 2007 14:22:00 -0500 [thread overview]
Message-ID: <465DCED8.4080506@us.ibm.com> (raw)
In-Reply-To: <97D612E30E1F88419025B06CB4CF1BE10259AD95@scsmsx412.amr.corp.intel.com>
Nakajima, Jun wrote:
> Zachary Amsden wrote:
>
>> Nakajima, Jun wrote:
>>
>>> And actually you don't need the write to CR3 to flush TLB because
>>>
> the
>
>>> one to CR4 does it. Or does kvm_flush_tlb_kernel assume that CR3 is
>>>
> updated
>
>>> at the same time?
>>>
>>> Jun
>>>
>> It should not be necessary, but I believe this was added as a
>>
> workaround
>
>> to a PII erratum. I can't find the erratum, however, and the history
>>
> of
>
>> using G bits in Linux is complicated (several bugs introduced and many
>> intermediate versions of this code). Since this is not performance
>> critical, I think it is probably best to leave the CR3 reload.
>>
>
> I don't recommend this for old processors.
>
>
>> However, being unnecessary on modern processors, I already submitted a
>> patch to eliminate it on 64-bit (or maybe just told Andi about it, I
>> can't recall).
>>
>> Zach
>>
>
> For KVM, it should be okay as well. But we can replace two CR4 accesses
> with just one hypercall.
>
I was thinking the same thing :-)
I was actually thinking about adding a hypercall to set/clear a bit in a
control register. The thought here is that it would be useful not just
for the global bit but also for CR0.TS although we would need another
paravirt_op hook for stts.
Regards,
Anthony Liguori
> Jun
> ---
> Intel Open Source Technology Center
>
next parent reply other threads:[~2007-05-30 19:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <97D612E30E1F88419025B06CB4CF1BE10259AD95@scsmsx412.amr.corp.intel.com>
2007-05-30 19:22 ` Anthony Liguori [this message]
2007-05-30 20:40 ` [kvm-devel] [PATCH 3/3] Eliminate read_cr3 on TLB flush Nakajima, Jun
2007-05-30 21:49 ` Zachary Amsden
2007-05-31 1:12 ` Rusty Russell
2007-05-31 7:50 ` Avi Kivity
[not found] ` <465E7E4F.8050208@qumranet.com>
2007-05-31 17:30 ` Anthony Liguori
[not found] <97D612E30E1F88419025B06CB4CF1BE10259AE6D@scsmsx412.amr.corp.intel.com>
2007-05-30 22:03 ` Anthony Liguori
[not found] <465DBB49.5030503@vmware.com>
2007-05-30 19:12 ` Nakajima, Jun
[not found] <97D612E30E1F88419025B06CB4CF1BE10259AB81@scsmsx412.amr.corp.intel.com>
2007-05-30 17:58 ` Zachary Amsden
2007-05-30 15:38 Jeremy Fitzhardinge
2007-05-30 17:11 ` [kvm-devel] " Nakajima, Jun
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=465DCED8.4080506@us.ibm.com \
--to=aliguori@us.ibm.com \
--cc=jun.nakajima@intel.com \
--cc=kvm-devel@lists.sourceforge.net \
--cc=virtualization@lists.linux-foundation.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).