public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Kyle McMartin <kyle@mcmartin.ca>,
	tglx@linutronix.de, mingo@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86: make clflush a required feature on x86_64
Date: Fri, 18 Jan 2008 08:56:43 -0500	[thread overview]
Message-ID: <4790B01B.8020406@zytor.com> (raw)
In-Reply-To: <20080118065428.GA12594@one.firstfloor.org>

Andi Kleen wrote:
>> Simulators can be fixed, 
> 
> They could, but why? I don't know of a good reason to require CLFLUSH.

Well, simulators are generally expected to follow the architecture, not 
vice versa.  I would tend to agree with the coupling that recent 
versions of Bochs appeared to have made here -- I think we're unlikely 
to see any processors with sse2 sans clflush, so keeping code branches 
in which will never be executed seems like a bad idea in the long term. 
  I'm much more worried about the possibility of embedded 64-bit CPUs 
who try to skimp on SSE2 than CLFLUSH.

Now, that being said, this being encapsulated in the required set (and 
unified, which means the branches will be executed on 32-bit hardware) 
it seems the impact of leaving them in is small for now.  We can 
re-evaluate that as appropriate.  Either way, we should *not* have 
#ifdef CONFIG_X86_64 around usage sites, circumventing the master 
switch.  It either goes in the required masks or it doesn't.

>> I just verified that Bochs 2.3.0 lacks this CPUID bit whereas the 
>> current version, 2.3.6, enables CLFLUSH iff SSE2 is enabled.  Qemu 0.9.0 
>> has CLFLUSH.  Andi, do you happen to know of any specific simulators 
>> which are problematic?  I would assume any recent version of SimNow is 
>> up to date.
> 
> I don't know of any specific ones that lack CLFLUSH, although Bochs
> definitely had similar problems in the past.

OK, so we're talking about outdated versions of Bochs, then?

	-hpa


  reply	other threads:[~2008-01-18 14:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-18  4:59 [PATCH] x86: make clflush a required feature on x86_64 Kyle McMartin
2008-01-18  5:04 ` H. Peter Anvin
2008-01-18  5:25   ` [PATCH] x86_64: remove redundant cpu_has_ definitions Kyle McMartin
2008-01-18  8:07     ` Ingo Molnar
2008-01-18  5:53 ` [PATCH] x86: make clflush a required feature on x86_64 Andi Kleen
2008-01-18  6:01   ` Kyle McMartin
2008-01-18  6:27     ` H. Peter Anvin
2008-01-11 18:16       ` Pavel Machek
2008-01-18  6:54       ` Andi Kleen
2008-01-18 13:56         ` H. Peter Anvin [this message]
2008-01-18 14:18           ` Andi Kleen

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=4790B01B.8020406@zytor.com \
    --to=hpa@zytor.com \
    --cc=andi@firstfloor.org \
    --cc=kyle@mcmartin.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    /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