All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Chenyi Qiang <chenyi.qiang@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	Xiaoyao Li <xiaoyao.li@intel.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 2/3] KVM: selftests: Add a test to get/set triple fault event
Date: Wed, 18 May 2022 19:20:32 +0000	[thread overview]
Message-ID: <YoVHAIGcFgJit1qp@google.com> (raw)
In-Reply-To: <20220421072958.16375-3-chenyi.qiang@intel.com>

On Thu, Apr 21, 2022, Chenyi Qiang wrote:
> +#ifndef __x86_64__
> +# error This test is 64-bit only

No need, all of KVM selftests are 64-bit only.

> +#endif
> +
> +#define VCPU_ID			0
> +#define ARBITRARY_IO_PORT	0x2000
> +
> +/* The virtual machine object. */
> +static struct kvm_vm *vm;
> +
> +static void l2_guest_code(void)
> +{
> +	/*
> +	 * Generate an exit to L0 userspace, i.e. main(), via I/O to an
> +	 * arbitrary port.
> +	 */

I think we can test a "real" triple fault without too much effort by abusing
vcpu->run->request_interrupt_window.  E.g. map the run struct into L2, clear
PIN_BASED_EXT_INTR_MASK in vmcs12, and then in l2_guest_code() do:

	asm volatile("cli");

	run->request_interrupt_window = true;

	asm volatile("sti; ud2");

	asm volatile("inb %%dx, %%al"                                           
		     : : [port] "d" (ARBITRARY_IO_PORT) : "rax"); 	

The STI shadow will block the IRQ-window VM-Exit until after the ud2, i.e. until
after the triple fault is pending.

And then main() can

  1. verify it got KVM_EXIT_IRQ_WINDOW_OPEN with a pending triple fault
  2. clear the triple fault and re-enter L1+l2
  3. continue with the existing code, e.g. verify it got KVM_EXIT_IO, stuff a
     pending triple fault, etc...

That said, typing that out makes me think we should technically handle/prevent this
in KVM since triple fault / shutdown is kinda sorta just a special exception.

Heh, and a potentially bad/crazy idea would be to use a reserved/magic vector in
kvm_vcpu_events.exception to save/restore triple fault, e.g. we could steal
NMI_VECTOR.

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index f2d0ee9296b9..d58c0cfd3cd3 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4743,7 +4743,8 @@ static int kvm_vcpu_ready_for_interrupt_injection(struct kvm_vcpu *vcpu)
        return (kvm_arch_interrupt_allowed(vcpu) &&
                kvm_cpu_accept_dm_intr(vcpu) &&
                !kvm_event_needs_reinjection(vcpu) &&
-               !vcpu->arch.exception.pending);
+               !vcpu->arch.exception.pending &&
+               !kvm_test_request(KVM_REQ_TRIPLE_FAULT, vcpu));
 }

 static int kvm_vcpu_ioctl_interrupt(struct kvm_vcpu *vcpu,




  reply	other threads:[~2022-05-18 19:20 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-21  7:29 [PATCH v6 0/3] Introduce Notify VM exit Chenyi Qiang
2022-04-21  7:29 ` [PATCH v6 1/3] KVM: X86: Save&restore the triple fault request Chenyi Qiang
2022-05-18 18:42   ` Sean Christopherson
2022-05-19  6:25     ` Chenyi Qiang
2022-04-21  7:29 ` [PATCH v6 2/3] KVM: selftests: Add a test to get/set triple fault event Chenyi Qiang
2022-05-18 19:20   ` Sean Christopherson [this message]
2022-05-23  6:46     ` Chenyi Qiang
2022-05-23 16:23       ` Sean Christopherson
2022-05-24 13:27         ` Chenyi Qiang
2022-04-21  7:29 ` [PATCH v6 3/3] KVM: VMX: Enable Notify VM exit Chenyi Qiang
2022-04-21 13:53   ` kernel test robot
2022-04-22  6:44   ` kernel test robot
2022-05-17  0:59   ` Chenyi Qiang
2022-05-18 22:30   ` Sean Christopherson
2022-05-19 10:38     ` Chenyi Qiang
2022-05-19 15:22       ` Sean Christopherson
2022-05-06  2:43 ` [PATCH v6 0/3] Introduce " Chenyi Qiang
2022-05-23 19:30 ` Paolo Bonzini
2022-05-24 14:00   ` Chenyi Qiang

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=YoVHAIGcFgJit1qp@google.com \
    --to=seanjc@google.com \
    --cc=chenyi.qiang@intel.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=xiaoyao.li@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.