From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 2 of 5] rombios/ata: Do not wait for BSY to be set Date: Tue, 27 Nov 2012 18:24:55 +0000 Message-ID: <50B50577.8040704@citrix.com> References: <20121127164637.GG51942@ocelot.phlegethon.org> <20121127170844.536be218@pyramind.ukuu.org.uk> <50B4F6EC.3050300@citrix.com> <20121127174900.68a51564@pyramind.ukuu.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20121127174900.68a51564@pyramind.ukuu.org.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Alan Cox Cc: "Keir (Xen.org)" , "Tim (Xen.org)" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 27/11/12 17:49, Alan Cox wrote: > O> 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 > So why not fix the qemu emulation bug ? I do not have a copy of the ATA specification, and http://code.coreboot.org/p/seabios/source/commit/580e33293244fee4556e56ecc67b8bd877f3c496/ certainly implies that waiting for BSY is not required > >> 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) > Not good, although half caused by the fact that years on qemu still > hasn't implemented predictors to avoid trapping further than the kernel > layer 8) > >> 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; > Don't do that then. 0x80 is not safe on a modern PC system (you'll note > the Linux kernel changed behaviour here). It may be a debug port but we've > seen some hardware do worse things if you touch it. It's also completely > out on a limb with EFI based systems which don't necessarily have the > legacy stuff present. > > Alan If port 0x80 is problematic, then this is a Xen problem, but a legacy guest should have no adverse effects. Perhaps we should "emulate" port 0x80 by deliberately re-scheduling another VCPU ? -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com