From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH 3 of 5] rombios/ata: Reading this status register has no relevant side effects Date: Tue, 31 Jul 2012 11:08:09 +0100 Message-ID: <5017AE89.4010707@cantab.net> References: <5e8fbfea222946369f08.1343677642@andrewcoop.uk.xensource.com> <20120730225731.70f6842a@ultron> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120730225731.70f6842a@ultron> 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: Andrew Cooper , Keir Fraser , Jan Beulich , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 30/07/12 22:57, Alan Cox wrote: > On Mon, 30 Jul 2012 20:47:22 +0100 > Andrew Cooper wrote: > >> So taking two traps when one will do is pointless. This codepath is on the int >> 0x13 hot path, and removing it has about a 30% reduction in the number of traps >> to Qemu during Win7 boot. > > You can't read the status for 400nS after a command issue, so throwing > one away is a typical way to handle that. This is only relevant when talking to real hardware, the qemu model has no such requirement. Also, I think you mean 400 ns not 400 nanosiemens. > All of this is optimising the wrong thing. > > The problem is that neither kvm not xen have the most basic prediction > handlers in the kernel side exception code so keep hitting qemu. I'd be interested in seeing how you think this will work without knowledge of the emulated device in the hypervisor. How does the predictor know whether accesses have side effects? A better solution would be to avoid most I/O accesses by the BIOS by using PV drivers instead. David