[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f3611af9-dce2-b07f-e5c4-5a47c7e519a6@redhat.com>
Date: Tue, 26 Jan 2021 12:39:16 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Wei Huang <wei.huang2@....com>, kvm@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, vkuznets@...hat.com,
mlevitsk@...hat.com, seanjc@...gle.com, joro@...tes.org,
bp@...en8.de, tglx@...utronix.de, mingo@...hat.com, x86@...nel.org,
jmattson@...gle.com, wanpengli@...cent.com, bsd@...hat.com,
dgilbert@...hat.com, luto@...capital.net
Subject: Re: [PATCH v3 4/4] KVM: SVM: Support #GP handling for the case of
nested on nested
On 26/01/21 09:18, Wei Huang wrote:
> Under the case of nested on nested (L0->L1->L2->L3), #GP triggered by
> SVM instructions can be hided from L1. Instead the hypervisor can inject
> the proper #VMEXIT to inform L1 of what is happening. Thus L1 can avoid
> invoking the #GP workaround. For this reason we turns on guest VM's
> X86_FEATURE_SVME_ADDR_CHK bit for KVM running inside VM to receive the
> notification and change behavior.
Slightly reworked commit message:
KVM: SVM: Fix #GP handling for doubly-nested virtualization
Under the case of nested on nested (L0, L1, L2 are all hypervisors),
#GP triggered by SVM instructions can be hidden from L1. Because
we do not support emulation of the vVMLOAD/VMSAVE feature, the
L0 hypervisor can inject the proper #VMEXIT to inform L1 of what is
happening and L1 can avoid invoking the #GP workaround.
Thanks,
Paolo
Powered by blists - more mailing lists