Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <26464954-f9d5-31e6-ba34-7b1f606328cc@intel.com>
Date:   Tue, 24 May 2022 21:27:29 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 Thunderbird/91.9.0
Subject: Re: [PATCH v6 2/3] KVM: selftests: Add a test to get/set triple fault
 event
Content-Language: en-US
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
References: <20220421072958.16375-1-chenyi.qiang@intel.com>
 <20220421072958.16375-3-chenyi.qiang@intel.com> <YoVHAIGcFgJit1qp@google.com>
 <5c5a7597-d6e3-7a05-ead8-659c45aea222@intel.com>
 <You1Eq6fp8F3YF5Z@google.com>
From:   Chenyi Qiang <chenyi.qiang@intel.com>
In-Reply-To: <You1Eq6fp8F3YF5Z@google.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


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.