[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 1/3] cpu: make CPU_INTERRUPT_RESET available
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH v2 1/3] cpu: make CPU_INTERRUPT_RESET available on all targets |
Date: |
Wed, 06 Mar 2013 09:49:27 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 |
Il 06/03/2013 00:23, Peter Maydell ha scritto:
> On 6 March 2013 03:00, Paolo Bonzini <address@hidden> wrote:
>> 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, and provide a function that
>> will raise the interrupt on all CPUs.
>
> Not sure this makes sense -- reset isn't an interrupt...
cpu_interrupt is not just for interrupts, CPU_INTERRUPT_TGT_INT_* is a
generic mechanism for adding events to the CPU that have to exit the
translation block (they do not even have to be input pins, though
CPU_INTERRUPT_RESET is). This patch just takes one particular
CPU_INTERRUPT_TGT_INT_* value and makes it available to all targets.
It is important for the reset to exit the translation block, or the CPU
goes into the weeds. The problem I was seeing is that the code looked like:
mov $0xfe, %al
out %al, $0x60
jmp foo // this is a relative jump
...
foo:
cli
hlt
Now, if the reset were synchronous (i.e. cpu_reset), it would modify the
stored PC to 0xfffffff0 without leaving the translation block.
Because the jump is relative, it would go to 0xfffffff0 + the offset
instead of jumping to foo.
This could also be implemented by something like this:
run_on_cpu(cpu, cpu_reset);
cpu_interrupt(cpu, CPU_INTERRUPT_EXITTB);
But I preferred to reuse the existing logic (there would be some
additional complication because the x86 INIT signal does _not_ reset a
couple of things that are reset at power up).
Paolo
[Qemu-devel] [PATCH v2 3/3] hw: correctly implement soft reset, Paolo Bonzini, 2013/03/05