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

[Paolo Bonzini <pbonzini@redhat.com>]

Il 12/05/2014 11:41, Peter Maydell ha scritto:
> On 12 May 2014 08:47, Andreas Färber <afaerber@suse.de> 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.

Paolo