[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2 of 5] rombios/ata: Do not wait for BSY to be set



On 27/11/12 17:08, Alan Cox wrote:
>> Does this actually do anything useful?  I'd guess that on qemu the extra
>> outb has no effect and on real hardware that needed a delay here, one
>> I/O cycle would not be enough.
> It ought to be plenty - the time before the response is valid from an ATA
> command is very short but in the real hardware world most definitely
> present and important.
>
> However you also need to think about the state of the device registers
> after the second outb. If you don't wait for BSY and for some reason it's
> delayed in the emulation or on a multiprocessor what occurs.
>
> Might be safer to do
>
>       outb(0x80,0x00)
>       await_ide(...)
>
> at which point the await_ide would run once in the usual case.
>
> Alan

No - this is what we are trying to avoid.

SEABios has explicitly removed the wait for the BSY bit to be set.  We
want to remove it because Qemu will not set the BSY bit, resulting in
42k needless polled IO traps while we wait for the timeout (which is, if
I remember correctly, based on a loop counter rather than any notion of
actual time)

We can certainly argue about the outb(0x80,0x00).  When I was comparing
ROMBios with SEABios, this outb was the closest I could easily get to a
udelay(5) without implement udelay() in ROMBios.  Xen will execute an
outb(0x80, 0x00) on the real hardware if a guest executes it; It will
never result in a trap to qemu.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.