[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e8fe4664-d948-f239-4ec9-82d9010b7d26@web.de>
Date: Sat, 29 Feb 2020 20:21:49 +0100
From: Jan Kiszka <jan.kiszka@....de>
To: Jim Mattson <jmattson@...gle.com>, Oliver Upton <oupton@...gle.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
kvm list <kvm@...r.kernel.org>, stable@...r.kernel.org
Subject: Re: [FYI PATCH 1/3] KVM: nVMX: Don't emulate instructions in guest
mode
On 29.02.20 20:00, Jim Mattson wrote:
> On Sat, Feb 29, 2020 at 10:33 AM Oliver Upton <oupton@...gle.com> wrote:
>>
>> Hi Jan,
>>
>> On Sat, Feb 29, 2020 at 10:00 AM Jan Kiszka <jan.kiszka@....de> wrote:
>>> Is this expected to cause regressions on less common workloads?
>>> Jailhouse as L1 now fails when Linux as L2 tries to boot a CPU: L2-Linux
>>> gets a triple fault on load_current_idt() in start_secondary(). Only
>>> bisected so far, didn't debug further.
>>
>> I'm guessing that Jailhouse doesn't use 'descriptor table exiting', so
>> when KVM gets the corresponding exit from L2 the emulation burden is
>> on L0. We now refuse the emulation, which kicks a #UD back to L2. I
>> can get a patch out quickly to address this case (like the PIO exiting
>> one that came in this series) but the eventual solution is to map
>> emulator intercept checks into VM-exits + call into the
>> nested_vmx_exit_reflected() plumbing.
>
> If Jailhouse doesn't use descriptor table exiting, why is L0
> intercepting descriptor table instructions? Is this just so that L0
> can partially emulate UMIP on hardware that doesn't support it?
>
That seems to be the case: My host lacks umip, L1 has it. So, KVM is
intercepting descriptor table load instructions to emulate umip.
Jailhouse never activates that interception.
Jan
Powered by blists - more mailing lists