qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 11/22] i8259: Update IRQ state after reset
Date: Tue, 04 Oct 2011 14:12:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2

On 10/02/2011 10:36 PM, Blue Swirl wrote:
On Sun, Oct 2, 2011 at 8:31 PM, Avi Kivity<address@hidden>  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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]