Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

[Avi Kivity]

David P. Reed wrote:
> Replace use of outb to "unused" diagnostic port 0x80 for time delay
> with udelay based time delay on x86_64 architecture machines.  Fix for
> bugs 9511 and 6307 in bugzilla, plus bugs reported in
> bugzilla.redhat.com.
>
> Derived from suggestion (that didn't compile) by Pavel Machek, and
> tested, also based on measurements of typical timings of out's
> collated by Rene Herman from many in the community.
>
> This patch fixes a number of bugs known to cause problems on HP
> Pavilion dv9000z and dv6000z laptops - in the form of solid freezes
> when hwclock is used to show or set the time.  Also, it potentially
> improves bus utilization on SMP machines, by using a waiting process
> that doesn't tie up the ISA/LPC bus for 1 or 2 microseconds.
>

kvm will forward a virtual machine's writes to port 0x80 to the real 
port.  The reason is that the write is much faster than exiting and 
emulating it; the difference is measurable when compiling kernels.

Now if the cause is simply writing to port 0x80, then we must stop doing 
that.  But if the reason is the back-to-back writes, when we can keep 
it, since the other writes will be trapped by kvm and emulated.  Do you 
which is the case?

-- 
Any sufficiently difficult bug is indistinguishable from a feature.

Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

[David P. Reed]

Avi Kivity wrote:
> kvm will forward a virtual machine's writes to port 0x80 to the real 
> port.  The reason is that the write is much faster than exiting and 
> emulating it; the difference is measurable when compiling kernels.
>
> Now if the cause is simply writing to port 0x80, then we must stop 
> doing that.  But if the reason is the back-to-back writes, when we can 
> keep it, since the other writes will be trapped by kvm and emulated.  
> Do you which is the case?
>
As for kvm, I don't have enough info to know anything about that.  Is 
there a test you'd like me to try?

I think you are also asking if the crash on these laptops is caused only 
by back-to-back writes.  Actually, it doesn't seem to matter if they are 
back to back.  I can cause the crash if the writes to 80 are very much 
spread out in time - it seems only to matter how many of them get 
executed - almost as if there is a buffer overflow.  (And of course if 
you do back to back writes to other ports that are apparently fully 
unused, such as 0xED on my machine, no crash occurs).

I believe (though no one seems to have confirming documentation from the 
chipset or motherboard vendor) that port 80 is actually functional for 
some unknown function on these machines.   (They do respond to "in" 
instructions faster than a bus cycle abort does - more evidence).

I searched the DSDT to see if there is any evidence of an ACPI use for 
this port, but found nothing.

Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

[linux-os (Dick Johnson)]

[-- Attachment #1: Type: text/plain, Size: 2814 bytes --]


On Fri, 14 Dec 2007, David P. Reed wrote:

> Avi Kivity wrote:
>> kvm will forward a virtual machine's writes to port 0x80 to the real
>> port.  The reason is that the write is much faster than exiting and
>> emulating it; the difference is measurable when compiling kernels.
>>
>> Now if the cause is simply writing to port 0x80, then we must stop
>> doing that.  But if the reason is the back-to-back writes, when we can
>> keep it, since the other writes will be trapped by kvm and emulated.
>> Do you which is the case?
>>
> As for kvm, I don't have enough info to know anything about that.  Is
> there a test you'd like me to try?
>
> I think you are also asking if the crash on these laptops is caused only
> by back-to-back writes.  Actually, it doesn't seem to matter if they are
> back to back.  I can cause the crash if the writes to 80 are very much
> spread out in time - it seems only to matter how many of them get
> executed - almost as if there is a buffer overflow.  (And of course if
> you do back to back writes to other ports that are apparently fully
> unused, such as 0xED on my machine, no crash occurs).
>
> I believe (though no one seems to have confirming documentation from the
> chipset or motherboard vendor) that port 80 is actually functional for
> some unknown function on these machines.   (They do respond to "in"
> instructions faster than a bus cycle abort does - more evidence).
>
> I searched the DSDT to see if there is any evidence of an ACPI use for
> this port, but found nothing.
>
>

Attached is a patch that changes the outs to ins on port 0x80.
I did NOT let gcc decide what to do about modified registers.
Instead, the code saves/restores EAX itself so that all of the
times (whatever they are) are the same.

The code works and is running here. I also patched a very early
version (2.4.26) running on  a 400 MHz i486 with an real ISA
bus (Adaptec AHA1453). It works too.

David, will you please try it on your machine. Maybe reading
from the port is less harmful than writing.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.27 BogoMips).
My book : http://www.AbominableFirebug.com/
_


****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

[-- Attachment #2: io.h.patch --]
[-- Type: TEXT/PLAIN, Size: 429 bytes --]

--- linux-2.6.22.1/include/asm-i386/io.h.orig	2007-07-10 14:56:30.000000000 -0400
+++ linux-2.6.22.1/include/asm-i386/io.h	2007-12-17 12:06:10.000000000 -0500
@@ -252,7 +252,10 @@
 
 static inline void native_io_delay(void)
 {
-	asm volatile("outb %%al,$0x80" : : : "memory");
+	asm volatile(	"pushl %%eax\n\t"
+			"inb $0x80, %%al\n\t"
+			"popl %%eax\n\t"
+			 : : : "memory");
 }
 
 #if defined(CONFIG_PARAVIRT)

Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

[Rene Herman]

On 17-12-07 19:14, linux-os (Dick Johnson) wrote:

> Attached is a patch that changes the outs to ins on port 0x80.

No, that isn't useful. Only a write is "guaranteed" to make ISA/LPC meaning 
the timing for a read varies wildly. See the in/out cycles results posted 
earlier. Was also reading the Intel PIIX(3) chiset datasheet today which 
specifically mentions that only writes flow through to ISA, reads do not.

Rene.

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

[H. Peter Anvin]

David P. Reed wrote:
> 
> I believe (though no one seems to have confirming documentation from the 
> chipset or motherboard vendor) that port 80 is actually functional for 
> some unknown function on these machines.   (They do respond to "in" 
> instructions faster than a bus cycle abort does - more evidence).
> 

This is normal.  IN from port 0x80 is used by the DMA address map chip.

As far as I understand, there are other laptops with the same chipset 
which don't have this problem, so it's likely either a motherboard or 
firmware issue.  My guess is that they probably let debugging code out 
in the field (trap port 0x80 in SMM, and then try to output it on some 
debugging bus.)

	-hpa

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

[Avi Kivity]

David P. Reed wrote:
> Avi Kivity wrote:
>> kvm will forward a virtual machine's writes to port 0x80 to the real 
>> port.  The reason is that the write is much faster than exiting and 
>> emulating it; the difference is measurable when compiling kernels.
>>
>> Now if the cause is simply writing to port 0x80, then we must stop 
>> doing that.  But if the reason is the back-to-back writes, when we 
>> can keep it, since the other writes will be trapped by kvm and 
>> emulated.  Do you which is the case?
>>
> As for kvm, I don't have enough info to know anything about that.  Is 
> there a test you'd like me to try?
>

I have a test, but I see that it is broken for mainline.  I'll update it 
eventually, but...

> I think you are also asking if the crash on these laptops is caused 
> only by back-to-back writes.  Actually, it doesn't seem to matter if 
> they are back to back.  I can cause the crash if the writes to 80 are 
> very much spread out in time - it seems only to matter how many of 
> them get executed - almost as if there is a buffer overflow.  (And of 
> course if you do back to back writes to other ports that are 
> apparently fully unused, such as 0xED on my machine, no crash occurs).
>
> I believe (though no one seems to have confirming documentation from 
> the chipset or motherboard vendor) that port 80 is actually functional 
> for some unknown function on these machines.   (They do respond to 
> "in" instructions faster than a bus cycle abort does - more evidence).

That seems to be sufficient evidence for me to remove port 0x80 
pass-through from kvm and emulate it instead.  Given that port 80 writes 
take 1 microsecond, and that an in-kernel exit handler takes a similar 
amount of time, there won't be any significant performance loss.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace