lkml.org 
[lkml]   [2022]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v6 2/3] KVM: selftests: Add a test to get/set triple fault event
From


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.

\
 
 \ /
  Last update: 2022-05-24 15:28    [W:0.057 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site