From: Marc Zyngier <marc.zyngier@arm.com>
To: Christoffer Dall <christoffer.dall@linaro.org>
Cc: "kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH] arm/arm64: KVM: Complete WFI/WFE instructions
Date: Tue, 26 Aug 2014 14:24:45 +0100 [thread overview]
Message-ID: <53FC8A9D.70300@arm.com> (raw)
In-Reply-To: <1409057387-27458-1-git-send-email-christoffer.dall@linaro.org>
Hi Christoffer,
On 26/08/14 13:49, Christoffer Dall wrote:
> The architecture specifies that when the processor wakes up from a WFE
> or WFI instruction, the instruction is considered complete, however we
> currrently return to EL1 (or EL0) at the WFI/WFE instruction itself.
>
> While most guests may not be affected by this because their local
> exception handler performs an exception returning setting the event bit
> or with an interrupt pending, some guests like UEFI will get wedged due
> this little mishap.
>
> Simply skip the instruction when we have completed the emulation.
>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> Note that I haven't confirmed exactly how Linux guests survives WFI
> without this fix. My working hypothesis is that the Linux ISR doesn't
> complete the interrupt, leaving an active interrupt on the LR, which may
> cause the PE to consider it a wake-up event for the WFI despite the EL1
> handler returning to the WFI instruction itself. Tianocore on the other
> hand may complete the interrupt entirely before returning to the WFI
> instruction.
>
> Input on this is most welcome and likely to improve the quality of my
> sleep.
Very good catch.
The main reason is that Linux uses WFI in the idle loop, so it doesn't
matter if we come back to WFI or the following instruction (it is likely
to be a branch to WFI...).
Guests that have useful code *after* WFI will be terminally broken.
Anyway, time to run some tests and consider merging this as a fix (with
the equivalent arm64 patch), and possibly Cc stable.
Thanks,
M.
>
> arch/arm/kvm/handle_exit.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/kvm/handle_exit.c b/arch/arm/kvm/handle_exit.c
> index 4c979d4..a96a804 100644
> --- a/arch/arm/kvm/handle_exit.c
> +++ b/arch/arm/kvm/handle_exit.c
> @@ -93,6 +93,8 @@ static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
> else
> kvm_vcpu_block(vcpu);
>
> + kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
> +
> return 1;
> }
>
>
--
Jazz is not dead. It just smells funny...
prev parent reply other threads:[~2014-08-26 13:24 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-26 12:49 [PATCH] arm/arm64: KVM: Complete WFI/WFE instructions Christoffer Dall
2014-08-26 13:24 ` Marc Zyngier [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53FC8A9D.70300@arm.com \
--to=marc.zyngier@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=christoffer.dall@linaro.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox