[Top][All Lists]

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

Re: [Qemu-trivial] [Qemu-devel] [PATCH 1/1] arm: virt: change GPIO trigg

From: Peter Maydell
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH 1/1] arm: virt: change GPIO trigger interrupt to pulse
Date: Fri, 26 Feb 2016 15:42:00 +0000

On 26 February 2016 at 15:28, Wei Huang <address@hidden> wrote:
> On 02/26/2016 09:06 AM, Peter Maydell wrote:
>> On 26 February 2016 at 14:54, Shannon Zhao <address@hidden> wrote:
>>> On 2016/2/26 20:53, Peter Maydell wrote:
>>>> I don't understand why a 500ms pulse is better than a short one.
>>> Oh, I just pick a value which seems like a real latency for pressing a
>>> button. What's your suggestion?
>> I would prefer to avoid the pain of having a timer whose state
>> needs to be migrated. It's unclear to me why a 500ms pulse
>> will solve anything that an instantaneous pulse does not,
>> so I'd like to better understand the problem first.
> The problem we found with pulse was: only the last state change in GPIO
> is received by guest VM. In other words, with 0(L)->1(H)->0(L) or
> 1(H)->0(L)->1(0), PL061 only sees the last state (0 and 1). I guess this
> is because QEMU is non-preemptive. The solution is to have the following
> steps:
>   * qemu_set_irq(gpio_in, 1)
>   * yeild to guest VM
>   * qemu_set_irq(gpio_in, 0)
> Is there any way to do so in QEMU without using timer?

You have no guarantee that the guest VM will necessarily
make any progress even with a 500ms pulse length, so I don't
think increasing the length of the pulse is going to solidly
fix this.

As usual with any kind of interrupt you either need to
trigger on an edge (and latch the trigger in the interrupt
controller until the guest picks it up), or trigger on a
level, and keep the level high until the guest acknowledges
by writing back to the original device to tell it to drop
the level.

-- PMM

reply via email to

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