virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
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
>   

       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).