Re: [PATCH 9/11] Panic delay fix

From: Zachary Amsden <zach@vmware.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Pavel Machek <pavel@ucw.cz>, Andi Kleen <ak@muc.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Chris Wright <chrisw@sous-sol.org>
Subject: Re: [PATCH 9/11] Panic delay fix
Date: Wed, 07 Feb 2007 14:23:50 -0800	[thread overview]
Message-ID: <45CA5176.4000306@vmware.com> (raw)
In-Reply-To: <1170880572.11736.4.camel@localhost.localdomain>

Rusty Russell wrote:
> On Wed, 2007-02-07 at 12:35 +0000, Pavel Machek wrote:
>   
>> Ugh, it sounds like paravirt is more b0rken then I thought. It should
>> always to the proper delay, then replace those udelays that are not
>> needed on virtualized hardware with something else.
>>
>> Just magically defining udelay into nop is broken.
>>     
>
> We'd have to audit and figure out what udelays are for hardware and
> which are not, but the evidence is that the vast majority of them are
> for hardware and not needed for virtualization.
>
> Changing udelay to "hardware_udelay" or something all over the kernel
> would have delayed the paravirt_ops merge by an infinite amount 8)
>   

Yes, so I chose the same approach used for b0rken hardware - #define 
REALLY_SLOW_IO before including headers.  It's ugly, but it works 
without rewriting the entire source base.

Zach