[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |