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