From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <seanjc@google.com>
Cc: Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: nVMX: WARN on any attempt to allocate shadow VMCS for vmcs02
Date: Wed, 26 Jan 2022 17:27:08 +0100 [thread overview]
Message-ID: <87k0emh38j.fsf@redhat.com> (raw)
In-Reply-To: <053bb241-ea71-abf8-262b-7b452dc49d37@redhat.com>
Paolo Bonzini <pbonzini@redhat.com> writes:
> On 1/26/22 16:56, Vitaly Kuznetsov wrote:
>>> - WARN_ON(loaded_vmcs == &vmx->vmcs01 && loaded_vmcs->shadow_vmcs);
>>> + if (WARN_ON(loaded_vmcs != &vmx->vmcs01 || loaded_vmcs->shadow_vmcs))
>>> + return loaded_vmcs->shadow_vmcs;
>> Stupid question: why do we want to care about 'loaded_vmcs' at all,
>> i.e. why can't we hardcode 'vmx->vmcs01' in alloc_shadow_vmcs()? The
>> only caller is enter_vmx_operation() and AFAIU 'loaded_vmcs' will always
>> be pointing to 'vmx->vmcs01' (as enter_vmx_operation() allocates
>> &vmx->nested.vmcs02 so 'loaded_vmcs' can't point there!).
>>
>
> Well, that's why the WARN never happens. The idea is that if shadow
> VMCS _virtualization_ (not emulation, i.e. running L2 VMREAD/VMWRITE
> without even a vmexit to L0) was supported, then you would need a
> non-NULL shadow_vmcs in vmx->vmcs02.
>
> Regarding the patch, the old WARN was messy but it was also trying to
> avoid a NULL pointer dereference in the caller.
>
> What about:
>
> if (WARN_ON(loaded_vmcs->shadow_vmcs))
> return loaded_vmcs->shadow_vmcs;
>
> /* Go ahead anyway. */
> WARN_ON(loaded_vmcs != &vmx->vmcs01);
>
> ?
>
FWIW, this looks better [to my personal taste].
--
Vitaly
prev parent reply other threads:[~2022-01-26 16:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-25 22:05 [PATCH] KVM: nVMX: WARN on any attempt to allocate shadow VMCS for vmcs02 Sean Christopherson
2022-01-26 15:56 ` Vitaly Kuznetsov
2022-01-26 16:05 ` Paolo Bonzini
2022-01-26 16:22 ` Sean Christopherson
2022-01-26 17:05 ` Paolo Bonzini
2022-01-26 16:27 ` Vitaly Kuznetsov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k0emh38j.fsf@redhat.com \
--to=vkuznets@redhat.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=wanpengli@tencent.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.