Re: [Qemu-devel] [PATCH 11/22] i8259: Update IRQ state after reset

[Avi Kivity <avi@redhat.com>]

On 10/02/2011 10:36 PM, Blue Swirl wrote:
> On Sun, Oct 2, 2011 at 8:31 PM, Avi Kivity<avi@redhat.com>  wrote:
> >
> >>  >
> >>  >  In fact these aren't problems.  The packet may be sent or data
> >>  >  written, as long as they aren't corrupted.  A device is allowed to
> >>  >  "delay" a reset (but not indefinitely).
> >>
> >>  Oh, but corruption could easily happen. Consider for example a disk
> >>  controller waiting for DMA ready signal a device separate from the
> >>  DMA
> >>  controller. Due to reset glitches in the device or signal chain, the
> >>  DMA ready signal arrives but the DMA controller still contains old
> >>  information, writing the data to disk from wrong memory location.
> >
> >
> >  Would not this corruption also happen on real hardware?  If reset to the disk controller is delayed by a slow gate or extra capacitance on a line?
>
> Maybe, but the delays are probably too short on real HW before any
> packets are sent or disk gets written. On QEMU, I/O can be
> instantaneous.

As an anecdote, while reading a chip errata I came upon this:



15. CPU May Record Signal Glitches When MCH is Being Reset

Problem: When the MCH is reset via RSTIN# the CPU may record any one or 
more of the
following errors: address strobe glitch (MSR IA32_MCi_STATUS bit 23), 
data strobe
glitch (MSR IA32_MCi_STATUS bit 22), P/N data strobes out of sync (MSR
IA32_MCi_STATUS bit 21), PIC & FSB data parity (MSR IA32_MCi_STATUS bit 
19), RSP
parity (MSR IA32_MCi_STATUS bit 18), or FSB address parity (MSR 
IA32_MCi_STATUS
bit 16).  This can happen when the MCH asserts CPURST# just after the 
MCH drives an
FSB transaction.  This may happen because RSTIN# and CPURST# maintain an
asynchronous relationship with each other.

Workaround: None.

Status: No Fix

(of course the situation there is different, there is no global reset 
signal)

-- 
error compiling committee.c: too many arguments to function