[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v2 6/8] cpu: make CPU_INTERRUPT_RESET available

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v2 6/8] cpu: make CPU_INTERRUPT_RESET available on all targets
Date: Mon, 12 May 2014 12:31:07 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

Il 12/05/2014 11:41, Peter Maydell ha scritto:
On 12 May 2014 08:47, Andreas Färber <address@hidden> wrote:
Am 02.05.2014 16:33, schrieb Paolo Bonzini:
On the x86, some devices need access to the CPU reset pin (INIT#).
Provide a generic service to do this, using one of the internal
cpu_interrupt targets.  Generalize the PPC-specific code for
CPU_INTERRUPT_RESET to other targets.

Since PPC does not support migration across QEMU versions (its
machine types are not versioned yet), I picked the value that
is used on x86, CPU_INTERRUPT_TGT_INT_1.  Consequently, TGT_INT_2
and TGT_INT_3 are shifted down by one while keeping their value.

No objection from my side, but I thought there had been agreement among
Anthony, Peter and others that soft-reset is nothing generic that can be
implemented as API?

s390x has multiple ways to do resets, same for ppc, and I thought the
suggested way to implement them was a qemu_irq in the particular piece
of hardware together with custom reset functions as done for s390x?

I think the right way to expose reset to the outside world is via
a qemu_irq line, yes, but possibly the implementation inside the
CPU object might use a CPU_INTERRUPT_* bit (compare the way
that ARM IRQ and FIQ are qemu_irq lines to the outside world
but operate by just setting bits for the mainloop to check).

Ok, I'll queue patches 1-7 and rewrite patch 8 to use a qemu_irq.

This patch also seems to be eliding the difference between
"reset signal asserted, stop doing stuff" and "reset signal
deasserted, start executing code again".

In the x86 architecture it is actually not defined whether the reset is edge-triggered or level-triggered, so that's okay I think.


reply via email to

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