Re: [PATCH v6 2/3] KVM: selftests: Add a test to get/set triple fault event

From: Chenyi Qiang <chenyi.qiang@intel.com>
To: Sean Christopherson <seanjc@google.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: Tue, 24 May 2022 21:27:29 +0800	[thread overview]
Message-ID: <26464954-f9d5-31e6-ba34-7b1f606328cc@intel.com> (raw)
In-Reply-To: <You1Eq6fp8F3YF5Z@google.com>

On 5/24/2022 12:23 AM, Sean Christopherson wrote:
> On Mon, May 23, 2022, Chenyi Qiang wrote:
>>
>>
>> On 5/19/2022 3:20 AM, Sean Christopherson wrote:
>>> 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;
>>>
>>
>> Maybe, A GUEST_SYNC to main() to change the request_interrupt_window also
>> works.
> 
> Hmm, yes, that should work too.  Feel free to punt on writing this sub-test.  As
> mentioned below, KVM should treat a pending triple fault as a pending "exception",
> i.e. userspace shouldn't see KVM_EXIT_IRQ_WINDOW_OPEN with a pending triple fault,
> and so the test should actually assert that the triple fault occurs in L2.  But I
> can roll that test into the KVM fix if you'd like.

If the KVM_EXIT_IRQ_WINDOW_OPEN can't see the pending triple fault, only 
asserting the triple fault may not have meaning in this selftest. 
Anyway, feel free to add the pending triple fault test in your KVM fix 
patches.

> 
>>> 	asm volatile("sti; ud2");
>>>
>>
>> How does the "real" triple fault occur here? Through UD2?
> 
> Yeah.  IIRC, by default L2 doesn't have a valid IDT, so any fault will escalate to
> a triple fault.
> 
>>> 	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.