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).
>>
>>
On 10/02/2011 10:55 PM, Blue Swirl wrote:
It's already in, see -win2k-hack and floppy DMA hack.
Is the floppy DMA hack just a consequence of the weird idle BHs, or is
it to actually please a real BIOS?
Paolo
On Sun, Oct 2, 2011 at 8:41 PM, Avi Kivity wrote:
>> >
>> >
>> > 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
>>
On Sun, Oct 2, 2011 at 8:39 PM, Avi Kivity wrote:
>
>
> - Original Message -
>> On Sun, Oct 2, 2011 at 8:21 PM, Avi Kivity wrote:
>> >> >
>> >> > What I'm saying is that RESET order isn't defined on real
>> >> > hardware
>> >> > either, due to signal propagation effects.
>> >>
>> >> Yes,
> >
> >
> > 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
- Original Message -
> On Sun, Oct 2, 2011 at 8:21 PM, Avi Kivity wrote:
> >> >
> >> > What I'm saying is that RESET order isn't defined on real
> >> > hardware
> >> > either, due to signal propagation effects.
> >>
> >> Yes, but there the millions of reset cycles help immensely to
> >>
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 f
> >
> > 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 signa
On Sun, Oct 2, 2011 at 8:21 PM, Avi Kivity wrote:
>> >
>> > What I'm saying is that RESET order isn't defined on real hardware
>> > either, due to signal propagation effects.
>>
>> Yes, but there the millions of reset cycles help immensely to
>> suppress
>> the effects.
>>
>
> That's modeled corre
On Sun, Oct 2, 2011 at 8:17 PM, Avi Kivity wrote:
>> >
>> > It doesn't help. There is propagation delay there as well. If the
>> > input wins the race against reset, the launch sequence is started.
>>
>> To bring the example back to QEMU, a disk write could be issued or
>> network packet could b
> >
> > What I'm saying is that RESET order isn't defined on real hardware
> > either, due to signal propagation effects.
>
> Yes, but there the millions of reset cycles help immensely to
> suppress
> the effects.
>
That's modeled correctly. After the end of phase 1, everything is settled.
Du
On Sun, Oct 2, 2011 at 8:14 PM, Avi Kivity wrote:
>> >
>> > Say the target device's output has an AND connecting #RESET and an
>> > input, to the output. When #RESET is asserted, the input is
>> > driven low. The output is connected to a counter.
>> >
>> > When #RESET is asserted, the source dev
> >
> > It doesn't help. There is propagation delay there as well. If the
> > input wins the race against reset, the launch sequence is started.
>
> To bring the example back to QEMU, a disk write could be issued or
> network packet could be sent. But still, this only confirms that
> during the i
> >
> > Say the target device's output has an AND connecting #RESET and an
> > input, to the output. When #RESET is asserted, the input is
> > driven low. The output is connected to a counter.
> >
> > When #RESET is asserted, the source device's A and B are raised
> > high, with delay Da and Db.
On Sun, Oct 2, 2011 at 8:03 PM, Avi Kivity wrote:
>> >
>> > It still has propagation delay. If your XNOR gate connects to the
>> > NORAD master launch controller, your design may have side effects.
>>
>> Hopefully the reset signal would control also the edge triggered
>> launch controller.
>
> It
On Sun, Oct 2, 2011 at 7:58 PM, Avi Kivity wrote:
>> >
>> > There is no way to guarantee this. If A is driven high before the
>> > target device detects RESET, it will see the edge.
>>
>> That case is not what we have here, it would be equivalent of pulsing
>> qemu_irq reset lines for each device
> >
> > It still has propagation delay. If your XNOR gate connects to the
> > NORAD master launch controller, your design may have side effects.
>
> Hopefully the reset signal would control also the edge triggered
> launch controller.
It doesn't help. There is propagation delay there as well. I
On Sun, Oct 2, 2011 at 7:52 PM, Avi Kivity wrote:
>
>
> - Original Message -
>> On Sun, Oct 2, 2011 at 7:44 PM, Avi Kivity wrote:
>> >> >
>> >> > A real device also ignores inputs during reset (or if it
>> >> > doesn't,
>> >> > we can just emulate that).
>> >>
>> >> Maybe this could work:
> >
> > There is no way to guarantee this. If A is driven high before the
> > target device detects RESET, it will see the edge.
>
> That case is not what we have here, it would be equivalent of pulsing
> qemu_irq reset lines for each device in order. This would be even
> worse than what we have n
- Original Message -
> On Sun, Oct 2, 2011 at 7:44 PM, Avi Kivity wrote:
> >> >
> >> > A real device also ignores inputs during reset (or if it
> >> > doesn't,
> >> > we can just emulate that).
> >>
> >> Maybe this could work:
> >> 1 - issue start of reset cycle (raise qemu_irq, unrealiz
On Sun, Oct 2, 2011 at 7:47 PM, Avi Kivity wrote:
>> >> For example, outputs A and B should both be driven high by reset.
>> >> They
>> >> are connected to a XNOR gate, whose output is fed to edge
>> >> triggered
>> >> device. The device should not see any edges outside of the reset
>> >> cycle, d
> >
> > Why not use an ordinary qemu_irq? It reresents a pin; 0->1 edge
> > (assert) enters phase 1, 1->0 edge (deassert) enters phase 2.
> > Exactly like real hardware.
>
> QEMU makes no difference between power-on reset and system reset
> right
> now. At least I am not aware of any device mod
On Sun, Oct 2, 2011 at 7:44 PM, Avi Kivity wrote:
>> >
>> > A real device also ignores inputs during reset (or if it doesn't,
>> > we can just emulate that).
>>
>> Maybe this could work:
>> 1 - issue start of reset cycle (raise qemu_irq, unrealize): internal
>> states reset, no I/O.
>> 2 - issue s
On 2011-10-02 21:07, Avi Kivity wrote:
>>>
>>> The way to fix it is two-phase reset:
>>>
>>> phase 1: reset internal state (-> move all outputs to reset
>>> values),
>>> don't sample inputs yet
>>> phase 2: allow sampling inputs
>>
>> As far as I understood Anthony's QOM plans, phase 1 will corresp
> >> For example, outputs A and B should both be driven high by reset.
> >> They
> >> are connected to a XNOR gate, whose output is fed to edge
> >> triggered
> >> device. The device should not see any edges outside of the reset
> >> cycle, during reset cycle they are ignored.
> >>
> >
> > I don't
> >
> > A real device also ignores inputs during reset (or if it doesn't,
> > we can just emulate that).
>
> Maybe this could work:
> 1 - issue start of reset cycle (raise qemu_irq, unrealize): internal
> states reset, no I/O.
> 2 - issue start of I/O, reset held (new phase): evaluate inputs and
>
On Sun, Oct 2, 2011 at 7:35 PM, Avi Kivity wrote:
>> >
>> > Can you give an example? Can be theoretical, doesn't have to refer
>> > to real hardware.
>>
>> For example, outputs A and B should both be driven high by reset.
>> They
>> are connected to a XNOR gate, whose output is fed to edge trigge
On Sun, Oct 2, 2011 at 7:20 PM, Avi Kivity wrote:
>
>
> - Original Message -
>> On Sun, Oct 2, 2011 at 4:56 PM, Avi Kivity wrote:
>> > On 10/01/2011 10:31 AM, Blue Swirl wrote:
>> >>
>> >> Therefore it is incorrect to perform any qemu_irq activities
>> >> during
>> >> reset (also VM resto
> >
> > Can you give an example? Can be theoretical, doesn't have to refer
> > to real hardware.
>
> For example, outputs A and B should both be driven high by reset.
> They
> are connected to a XNOR gate, whose output is fed to edge triggered
> device. The device should not see any edges outside
On Sun, Oct 2, 2011 at 7:08 PM, Avi Kivity wrote:
>> > phase 1: reset internal state (-> move all outputs to reset
>> > values), don't
>> > sample inputs yet
>>
>> This solves the problem of old state accidentally interfering with
>> reset state.
>>
>> > phase 2: allow sampling inputs
>>
>> This c
- Original Message -
> On Sun, Oct 2, 2011 at 4:56 PM, Avi Kivity wrote:
> > On 10/01/2011 10:31 AM, Blue Swirl wrote:
> >>
> >> Therefore it is incorrect to perform any qemu_irq activities
> >> during
> >> reset (also VM restore like the original example), don't you
> >> agree?
> >
> >
On Sun, Oct 2, 2011 at 7:07 PM, Avi Kivity wrote:
>> >
>> > The way to fix it is two-phase reset:
>> >
>> > phase 1: reset internal state (-> move all outputs to reset
>> > values),
>> > don't sample inputs yet
>> > phase 2: allow sampling inputs
>>
>> As far as I understood Anthony's QOM plans, p
On Sun, Oct 2, 2011 at 4:56 PM, Avi Kivity wrote:
> On 10/01/2011 10:31 AM, Blue Swirl wrote:
>>
>> Therefore it is incorrect to perform any qemu_irq activities during
>> reset (also VM restore like the original example), don't you agree?
>
> It is not incorrect. Real hardware updates outputs on
> > phase 1: reset internal state (-> move all outputs to reset
> > values), don't
> > sample inputs yet
>
> This solves the problem of old state accidentally interfering with
> reset state.
>
> > phase 2: allow sampling inputs
>
> This could lead to incorrect state for complex networks. It woul
> >
> > The way to fix it is two-phase reset:
> >
> > phase 1: reset internal state (-> move all outputs to reset
> > values),
> > don't sample inputs yet
> > phase 2: allow sampling inputs
>
> As far as I understood Anthony's QOM plans, phase 1 will correspond
> to
> "unrealize", phase 2 to "re
On Sun, Oct 2, 2011 at 4:39 PM, Avi Kivity wrote:
> On 09/28/2011 09:01 PM, Blue Swirl wrote:
>>
>> On Wed, Sep 28, 2011 at 11:00 AM, Jan Kiszka
>> wrote:
>> > As we clearly modify the PIC state on pic_reset, we also have to update
>> > the IRQ output. This only happened on init so far. Apply t
On Sun, Oct 2, 2011 at 4:27 PM, Jan Kiszka wrote:
> On 2011-10-01 09:31, Blue Swirl wrote:
>> On Sat, Oct 1, 2011 at 6:47 AM, Jan Kiszka wrote:
>>> On 2011-09-30 22:47, Blue Swirl wrote:
That part of the discussion is obsolete (or at least uninteresting
here). For example this message h
On 2011-10-02 18:39, Avi Kivity wrote:
> On 09/28/2011 09:01 PM, Blue Swirl wrote:
>> On Wed, Sep 28, 2011 at 11:00 AM, Jan Kiszka
>> wrote:
>> > As we clearly modify the PIC state on pic_reset, we also have to
>> update
>> > the IRQ output. This only happened on init so far. Apply this
>> > co
On 10/01/2011 10:31 AM, Blue Swirl wrote:
Therefore it is incorrect to perform any qemu_irq activities during
reset (also VM restore like the original example), don't you agree?
It is not incorrect. Real hardware updates outputs on RESET assertion,
and real hardware deals with devices enterin
On 09/28/2011 09:01 PM, Blue Swirl wrote:
On Wed, Sep 28, 2011 at 11:00 AM, Jan Kiszka wrote:
> As we clearly modify the PIC state on pic_reset, we also have to update
> the IRQ output. This only happened on init so far. Apply this
> consistently.
Nack, IRQ lines shouldn't be touched on rese
On 2011-10-01 09:31, Blue Swirl wrote:
> On Sat, Oct 1, 2011 at 6:47 AM, Jan Kiszka wrote:
>> On 2011-09-30 22:47, Blue Swirl wrote:
>>> That part of the discussion is obsolete (or at least uninteresting
>>> here). For example this message has a relevant example:
>>> http://lists.nongnu.org/archiv
On 30 September 2011 21:47, Blue Swirl wrote:
> If reliable post reset effects are needed, reset should be divided
> into two separate phases. So far no interesting cases have been
> demonstrated.
I've already cited one in this thread [realview mmc card present]
and that's just the one I happen t
On Sat, Oct 1, 2011 at 6:47 AM, Jan Kiszka wrote:
> On 2011-09-30 22:47, Blue Swirl wrote:
>> That part of the discussion is obsolete (or at least uninteresting
>> here). For example this message has a relevant example:
>> http://lists.nongnu.org/archive/html/qemu-devel/2009-06/msg01081.html
>>
>>
On 2011-09-30 22:47, Blue Swirl wrote:
> That part of the discussion is obsolete (or at least uninteresting
> here). For example this message has a relevant example:
> http://lists.nongnu.org/archive/html/qemu-devel/2009-06/msg01081.html
>
> It's about VM restore, but the situation is similar duri
On Fri, Sep 30, 2011 at 9:14 AM, Peter Maydell wrote:
> On 30 September 2011 07:47, Jan Kiszka wrote:
>> There is no difference between system reset after power-up or later on.
>> And there should be no difference between per device, per group of
>> devices or system-wide reset. A device model ca
On Fri, Sep 30, 2011 at 6:47 AM, Jan Kiszka wrote:
> On 2011-09-29 21:45, Blue Swirl wrote:
>> On Wed, Sep 28, 2011 at 9:18 PM, Jan Kiszka wrote:
>>> On 2011-09-28 20:01, Blue Swirl wrote:
On Wed, Sep 28, 2011 at 11:00 AM, Jan Kiszka
wrote:
>
> As we clearly modify the PIC
On 30 September 2011 07:47, Jan Kiszka wrote:
> There is no difference between system reset after power-up or later on.
> And there should be no difference between per device, per group of
> devices or system-wide reset. A device model cannot tell these apart.
I think it's also useful to distingu
On 2011-09-29 21:45, Blue Swirl wrote:
> On Wed, Sep 28, 2011 at 9:18 PM, Jan Kiszka wrote:
>> On 2011-09-28 20:01, Blue Swirl wrote:
>>>
>>> On Wed, Sep 28, 2011 at 11:00 AM, Jan Kiszka
>>> wrote:
As we clearly modify the PIC state on pic_reset, we also have to update
the IRQ outp
On Wed, Sep 28, 2011 at 9:18 PM, Jan Kiszka wrote:
> On 2011-09-28 20:01, Blue Swirl wrote:
>>
>> On Wed, Sep 28, 2011 at 11:00 AM, Jan Kiszka
>> wrote:
>>>
>>> As we clearly modify the PIC state on pic_reset, we also have to update
>>> the IRQ output. This only happened on init so far. Apply thi
On Wed, Sep 28, 2011 at 9:38 PM, Peter Maydell wrote:
> On 28 September 2011 19:42, Blue Swirl wrote:
>> We also assume that the reset states of devices and their outputs are
>> coherent i.e. the output of one device during reset would not change
>> the state of another device from its reset stat
On 28 September 2011 19:42, Blue Swirl wrote:
> We also assume that the reset states of devices and their outputs are
> coherent i.e. the output of one device during reset would not change
> the state of another device from its reset state.
This seems a very dubious assumption to make. Consider t
On 2011-09-28 20:01, Blue Swirl wrote:
On Wed, Sep 28, 2011 at 11:00 AM, Jan Kiszka wrote:
As we clearly modify the PIC state on pic_reset, we also have to update
the IRQ output. This only happened on init so far. Apply this
consistently.
Nack, IRQ lines shouldn't be touched on reset. The oth
On Wed, Sep 28, 2011 at 6:09 PM, Peter Maydell wrote:
> On 28 September 2011 19:01, Blue Swirl wrote:
>> On Wed, Sep 28, 2011 at 11:00 AM, Jan Kiszka wrote:
>>> As we clearly modify the PIC state on pic_reset, we also have to update
>>> the IRQ output. This only happened on init so far. Apply th
On 28 September 2011 19:01, Blue Swirl wrote:
> On Wed, Sep 28, 2011 at 11:00 AM, Jan Kiszka wrote:
>> As we clearly modify the PIC state on pic_reset, we also have to update
>> the IRQ output. This only happened on init so far. Apply this
>> consistently.
>
> Nack, IRQ lines shouldn't be touched
On Wed, Sep 28, 2011 at 11:00 AM, Jan Kiszka wrote:
> As we clearly modify the PIC state on pic_reset, we also have to update
> the IRQ output. This only happened on init so far. Apply this
> consistently.
Nack, IRQ lines shouldn't be touched on reset. The other side may not
be ready for receivin
As we clearly modify the PIC state on pic_reset, we also have to update
the IRQ output. This only happened on init so far. Apply this
consistently.
Signed-off-by: Jan Kiszka
---
hw/i8259.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/hw/i8259.c b/hw/i8259.c
index b7
56 matches
Mail list logo
