From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42968) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RB3rM-0001D8-7M for qemu-devel@nongnu.org; Tue, 04 Oct 2011 08:12:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RB3rK-0001O4-Ak for qemu-devel@nongnu.org; Tue, 04 Oct 2011 08:12:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59271) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RB3rK-0001Nv-1E for qemu-devel@nongnu.org; Tue, 04 Oct 2011 08:12:30 -0400 Message-ID: <4E8AF829.10005@redhat.com> Date: Tue, 04 Oct 2011 14:12:25 +0200 From: Avi Kivity MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 11/22] i8259: Update IRQ state after reset List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Anthony Liguori , Jan Kiszka , qemu-devel On 10/02/2011 10:36 PM, Blue Swirl wrote: > On Sun, Oct 2, 2011 at 8:31 PM, Avi Kivity 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