Subject: Re: testing bus barriers
To: None <tech-kern@NetBSD.org>
From: David Young <dyoung@pobox.com>
List: tech-kern
Date: 02/12/2004 18:25:00
On Thu, Feb 12, 2004 at 01:44:59PM -0500, Thor Lancelot Simon wrote:
> On Sun, Feb 08, 2004 at 08:09:43PM -0600, David Young wrote:
> >
> > A word about testing bus barriers: I keep coming back to this idea
> > of producing a "virtual bus" which either simulates a bus or else
> > filters/logs/re-orders I/O before passing it through to a physical bus.
> > An overlay bus that re-orders I/O under the constraints set by explicit
> > bus barriers would be useful for stressing a device driver to find bugs
> > in the placement of barriers. An overlay bus could reverse I/O, say,
> > or randomize it, whenever barriers did not forbid it.
>
> I can see how we could use bus_space or even, under limited conditions,
> bus_dma to do this. I am skeptical about the applicability to
> interrupt-driven and DMA device or driver operation, though. It seems
> like for device simulation, you'd end up with some hack to call the
> driver's interrupt routine after manipulating the I/O that ultimately
> lost the timing of the underlying events -- this would even be true
> with just a reordering bus, unless you carefully imposed a uniform delay
> on all operations. That seems likely to hide ugly corner cases in drivers,
> or distort performance analyses. In the DMA case, it'd be important to
> interpose a "DMA reorderer" that actually obeyed the same physical
> constraints as the device itself, with regard to alignment, etc. and
> possibly to know something about the actual bus hardware the device was
> physically attached through.
>
> I know these seem like nitpicking details, but I think there are a _lot_
> of such details to be considered before arriving at a general framework
> that could simulate devices or buses, or be interposed between real ones,
> with valid results. What's your take on this?
I think that for different values of "valid results," there are different
details that need to be considered.
I can make some vague examples. For one example, if I want to study the
effects of Alpha-like re-orderings on the reliability of Rx-interrupt
handling in atw(4), but all I have is an i386, then I will build a kernel:
fakebus* at pci? dev ? function ?
atw* at fakebus?
Configure Alpha-like re-orderings for register read/write:
# fakeconfig atw0 filter \
> bus_space_barrier,bus_space_write_4,bus_space_read_4=alpha_reorderings
I also want to log the reads/writes:
# fakeconfig atw0 log bus_space_write_4,bus_space_read_4
And put atw through its paces. I don't know precisely how this will all
fit into the autoconf framework, but I am assuming in this case that a
fakebus is a new bus type, and atw has a dev/fakebus/if_atw_fakebus.c
that knows how to attach it.
For another example, if I want to test PCI device attachment, then I
will configure the kernel with a fakebus that has PCI properties,
fakepci* at pci? dev ? function ?
atw* at fakepci?
Then I will install some filter for pci_intr_map that makes it return
an error,
# fakeconfig atw0 filter pci_intr_map=error
I guess that I have to postpone attachment. Maybe fakebuses should attach
their devices under control of fakeconfig....
Does this make sense so far?
Dave
--
David Young OJC Technologies
dyoung@ojctech.com Urbana, IL * (217) 278-3933