Re: [PATCH] Intel x86-64 support merge

Re: [PATCH] Intel x86-64 support merge

[Bill Davidsen]

David Mosberger-Tang wrote:
>>>>>>On Thu, 19 Feb 2004 00:40:24 +0100, Arjan van de Ven <arjan@fenrus.demon.nl> said:
> 
> 
>   Arjan> On Wed, 2004-02-18 at 23:57, H. Peter Anvin wrote:
>   >>  Because they were caught by surprise and just hacked the chips
>   >> they had in the pipeline, presumably.
> 
>   Arjan> fair enough; I hope this means the next generation has this
>   Arjan> wart fixed...
> 
> I wouldn't hold my breath.  My impression was that the Intel chipset
> folks don't want I/O MMU because (a) Windows doesn't need it and (b)
> real machines use (close-to-)64-bit-capable hardware.

Doesn't need it? Does that mean the Win64 uses bounce buffers for 
everything? Or am I totally misreading this?

Re: [PATCH] Intel x86-64 support merge

[David Mosberger-Tang]

>>>>> On Thu, 19 Feb 2004 17:06:58 -0500, Bill Davidsen <davidsen@tmr.com> said:

  Bill> David Mosberger-Tang wrote:
  >>>>>>> On Thu, 19 Feb 2004 00:40:24 +0100, Arjan van de Ven
  >>>>>>> <arjan@fenrus.demon.nl> said:
  >>
  Arjan> On Wed, 2004-02-18 at 23:57, H. Peter Anvin wrote:
  >> >> Because they were caught by surprise and just hacked the chips
  >> >> they had in the pipeline, presumably.

  Arjan> fair enough; I hope this means the next generation has this
  Arjan> wart fixed...
  >>  I wouldn't hold my breath.  My impression was that the Intel
  >> chipset folks don't want I/O MMU because (a) Windows doesn't need
  >> it and (b) real machines use (close-to-)64-bit-capable hardware.

  Bill> Doesn't need it? Does that mean the Win64 uses bounce buffers
  Bill> for everything? Or am I totally misreading this?

Remember: I'm just the messenger here...

I have no idea what Win64 does, but obviously bounce buffering is only
an issue for devices that can't address all physical memory.  These
days, even relatively low-end machines have devices that can address
"more than enough" physical memory (I'm not sure exactly what the DMA
limit of, say, a Kenai32 e1000 card is, but it's a lot more than 4GB).

	--david

Re: [PATCH] Intel x86-64 support merge

[Jeff Garzik]

Bill Davidsen wrote:
> David Mosberger-Tang wrote:
> 
>>>>>>> On Thu, 19 Feb 2004 00:40:24 +0100, Arjan van de Ven 
>>>>>>> <arjan@fenrus.demon.nl> said:
>>
>>
>>
>>   Arjan> On Wed, 2004-02-18 at 23:57, H. Peter Anvin wrote:
>>   >>  Because they were caught by surprise and just hacked the chips
>>   >> they had in the pipeline, presumably.
>>
>>   Arjan> fair enough; I hope this means the next generation has this
>>   Arjan> wart fixed...
>>
>> I wouldn't hold my breath.  My impression was that the Intel chipset
>> folks don't want I/O MMU because (a) Windows doesn't need it and (b)
>> real machines use (close-to-)64-bit-capable hardware.
> 
> 
> Doesn't need it? Does that mean the Win64 uses bounce buffers for 
> everything? Or am I totally misreading this?


Well, for 32-bit PCI hardware on a 64-bit OS, you pretty much have to 
bounce, without an IOMMU.

I doubt Win64 bounces for 64-bit PCI hardware, but who knows...

	Jeff

Re: [PATCH] Intel x86-64 support merge

[Jes Sorensen]

>>>>> "Jeff" == Jeff Garzik <jgarzik@pobox.com> writes:

Jeff> Bill Davidsen wrote:
>> Doesn't need it? Does that mean the Win64 uses bounce buffers for
>> everything? Or am I totally misreading this?

Jeff> Well, for 32-bit PCI hardware on a 64-bit OS, you pretty much
Jeff> have to bounce, without an IOMMU.

Jeff> I doubt Win64 bounces for 64-bit PCI hardware, but who knows...

Just a shame they don't seem to care about performance and allowing
one to issue SAC cycles when possible. Oh well, guess one just has to
buy a real computer.

Cheers,
Jes

Re: [PATCH] Intel x86-64 support merge

[David Mosberger]

>>>>> On 20 Feb 2004 02:48:06 -0500, Jes Sorensen <jes@wildopensource.com> said:

  Jeff> I doubt Win64 bounces for 64-bit PCI hardware, but who knows...

  Jes> Just a shame they don't seem to care about performance and allowing
  Jes> one to issue SAC cycles when possible.

Careful.  You're assuming that the I/O MMU translation is free.
Depending on many details, that may or may not be the case.

The timing couldn't have been better:

 http://marc.theaimsgroup.com/?l=linux-ia64&m=107732581008944

  Jes> Oh well, guess one just has to buy a real computer.

That's always a good idea.

	--david

Re: [PATCH] Intel x86-64 support merge

[David Mosberger-Tang]

>>>>> On Thu, 19 Feb 2004 00:40:24 +0100, Arjan van de Ven <arjan@fenrus.demon.nl> said:

  Arjan> On Wed, 2004-02-18 at 23:57, H. Peter Anvin wrote:
  >>  Because they were caught by surprise and just hacked the chips
  >> they had in the pipeline, presumably.

  Arjan> fair enough; I hope this means the next generation has this
  Arjan> wart fixed...

I wouldn't hold my breath.  My impression was that the Intel chipset
folks don't want I/O MMU because (a) Windows doesn't need it and (b)
real machines use (close-to-)64-bit-capable hardware.

	--david

Re: [PATCH] Intel x86-64 support merge

[David Weinehall]

On Wed, Feb 18, 2004 at 04:05:22PM -0800, David Mosberger-Tang wrote:
> >>>>> On Thu, 19 Feb 2004 00:40:24 +0100, Arjan van de Ven <arjan@fenrus.demon.nl> said:
> 
>   Arjan> On Wed, 2004-02-18 at 23:57, H. Peter Anvin wrote:
>   >>  Because they were caught by surprise and just hacked the chips
>   >> they had in the pipeline, presumably.
> 
>   Arjan> fair enough; I hope this means the next generation has this
>   Arjan> wart fixed...
> 
> I wouldn't hold my breath.  My impression was that the Intel chipset
> folks don't want I/O MMU because (a) Windows doesn't need it and (b)
> real machines use (close-to-)64-bit-capable hardware.

Does Windows(-users) really need anything more than ever-more advanced
graphics-adapters with ever-more buggy drivers and ever-faster CPU's,
both to support their ever-more advanced and mind numbing games.  Oh,
and ever-bigger hard disks to hold their ever-growing collections of
mp3's and movies that they probably don't even listen to/watch...

Yeeshh...

Some day maybe even manufactors of Intel hardware might start to create
intelligent, thought through hardware, but I seriously doubt it.


Regards: David Weinehall
-- 
 /) David Weinehall <tao@acc.umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/

Re: [PATCH] Intel x86-64 support merge

[Arjan van de Ven]

On Wed, 2004-02-18 at 20:44, Linux Kernel Mailing List wrote:

> 	The ugliest part is probably the swiotlb code.  In fact the code for
> 	that is not even included, but just reused from IA64.  swiotlb
> 	implements the PCI DMA API using bounce buffering.  I don't like this at
> 	all, but there was no other way to support non DAC capable hardware
> 	(like IDE or USB) on machines with >3GB.  Please redirect all flames for
> 	that to the Intel chipset designers.

ehm... so why on earth did Intel cripple this new platform?????

Re: [PATCH] Intel x86-64 support merge

[H. Peter Anvin]

Followup to:  <1077139308.4479.8.camel@laptop.fenrus.com>
By author:    Arjan van de Ven <arjan@fenrus.demon.nl>
In newsgroup: linux.dev.kernel
>
> On Wed, 2004-02-18 at 20:44, Linux Kernel Mailing List wrote:
> 
> > 	The ugliest part is probably the swiotlb code.  In fact the code for
> > 	that is not even included, but just reused from IA64.  swiotlb
> > 	implements the PCI DMA API using bounce buffering.  I don't like this at
> > 	all, but there was no other way to support non DAC capable hardware
> > 	(like IDE or USB) on machines with >3GB.  Please redirect all flames for
> > 	that to the Intel chipset designers.
> 
> ehm... so why on earth did Intel cripple this new platform?????
> 

Because they were caught by surprise and just hacked the chips they
had in the pipeline, presumably.

	-hpa

Re: [PATCH] Intel x86-64 support merge

[Arjan van de Ven]

On Wed, 2004-02-18 at 23:57, H. Peter Anvin wrote:

> 
> Because they were caught by surprise and just hacked the chips they
> had in the pipeline, presumably.

fair enough; I hope this means the next generation has this wart
fixed...