> Hi,
>
> On my acer swift 3 (SF314-51), I can't boot on my device since
> 4.19.198 (no issue with 4.19.197) without adding "acpi=off" in the
> parameters. Same thing happens on 5.12.19 (didn't happened in
> 5.12.16), 5.13.4 and .5 and 5.10.52.
>
> If acpi is not off issue is :
> -black screen after grub,
> -no errors, no activity (tested by leaving the pc 10 hours), no tty,
> no logs whatsoever in journalctl as if the kernel didn't start. Even
> adding 'debug' or 'initcall_debug' doesn't show anything.
>
> If I add acpi=off, the screen blinks one time and boots normally but
> after kernel 5.10 (5.12 and 5.13) I loose usage of keyboard and touchpad.
>
> Notes:
> - I'm using Manjaro KDE
> - I have tested with 4.19.198 Vanilla (config file attached) and same
> thing happened
> - setting nomodeset doesn't change anything
> - tried every acpi parameters, only =off worked
> - Bios was not updated, but the bug persisted after upgrading it
> - Acpi issue is recurrent with this pc it seems below 4.11
> (https://askubuntu.com/questions/929904/cant-pass-the-acpi-off-problem
> <https://askubuntu.com/questions/929904/cant-pass-the-acpi-off-problem>)
>
> Thank you for your help,
> Adrien
>
Hi again,
I've done a bisect on the 4.19.y branch and I've found that it is the
commit 2bf1f848ca0af4e3d49624df49cbbd5511ec49a3 [ACPICA: Fix memory leak
caused by _CID repair function] that introduced the bug. By doing a git
revert and building the kernel I can boot normally but as long as this
commit exist I just get a black screen as explained above.
BR,
Adrien
Once an exception has been injected, any side effects related to
the exception (such as setting CR2 or DR6) have been taked place.
Therefore, once KVM sets the VM-entry interruption information
field or the AMD EVENTINJ field, the next VM-entry must deliver that
exception.
Pending interrupts are processed after injected exceptions, so
in theory it would not be a problem to use KVM_INTERRUPT when
an injected exception is present. However, DOSEMU is using
run->ready_for_interrupt_injection to detect interrupt windows
and then using KVM_SET_SREGS/KVM_SET_REGS to inject the
interrupt manually. For this to work, the interrupt window
must be delayed after the completion of the previous event
injection.
Cc: stable(a)vger.kernel.org
Reported-by: Stas Sergeev <stsp2(a)yandex.ru>
Tested-by: Stas Sergeev <stsp2(a)yandex.ru>
Fixes: 71cc849b7093 ("KVM: x86: Fix split-irqchip vs interrupt injection window request")
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
---
arch/x86/kvm/x86.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 4116567f3d44..e5d5c5ed7dd4 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4358,8 +4358,17 @@ static int kvm_cpu_accept_dm_intr(struct kvm_vcpu *vcpu)
static int kvm_vcpu_ready_for_interrupt_injection(struct kvm_vcpu *vcpu)
{
- return kvm_arch_interrupt_allowed(vcpu) &&
- kvm_cpu_accept_dm_intr(vcpu);
+ /*
+ * Do not cause an interrupt window exit if an exception
+ * is pending or an event needs reinjection; userspace
+ * might want to inject the interrupt manually using KVM_SET_REGS
+ * or KVM_SET_SREGS. For that to work, we must be at an
+ * instruction boundary and with no events half-injected.
+ */
+ return (kvm_arch_interrupt_allowed(vcpu) &&
+ kvm_cpu_accept_dm_intr(vcpu) &&
+ !kvm_event_needs_reinjection(vcpu) &&
+ !vcpu->arch.exception.pending);
}
static int kvm_vcpu_ioctl_interrupt(struct kvm_vcpu *vcpu,
--
2.27.0