Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Vitaly Kuznetsov <vkuznets@redhat.com>
To:     Paolo Bonzini <pbonzini@redhat.com>,
        Sean Christopherson <seanjc@google.com>,
        Maxim Levitsky <mlevitsk@redhat.com>
Cc:     Wanpeng Li <wanpengli@tencent.com>,
        Jim Mattson <jmattson@google.com>,
        Cathy Avery <cavery@redhat.com>,
        Emanuele Giuseppe Esposito <eesposit@redhat.com>,
        linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH RFC] KVM: nSVM: Fix L1 state corruption upon return from
 SMM
In-Reply-To: <82327cd1-92ca-9f6b-3af0-8215e9d21eae@redhat.com>
References: <20210623074427.152266-1-vkuznets@redhat.com>
 <a3918bfa-7b4f-c31a-448a-aa22a44d4dfd@redhat.com>
 <53a9f893cb895f4b52e16c374cbe988607925cdf.camel@redhat.com>
 <ac98150acd77f4c09167bc1bb1c552db68925cf2.camel@redhat.com>
 <87pmwc4sh4.fsf@vitty.brq.redhat.com>
 <5fc502b70a89e18034716166abc65caec192c19b.camel@redhat.com>
 <YNNc9lKIzM6wlDNf@google.com> <YNNfnLsc+3qMsdlN@google.com>
 <82327cd1-92ca-9f6b-3af0-8215e9d21eae@redhat.com>
Date:   Thu, 24 Jun 2021 09:41:57 +0200
Message-ID: <87lf6z4sl6.fsf@vitty.brq.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 23/06/21 18:21, Sean Christopherson wrote:
>> On Wed, Jun 23, 2021, Sean Christopherson wrote:
>>> And I believe this hackery is necessary only because nested_svm_vmexit(=
) isn't
>>> following the architcture in the first place.  I.e. using vmcb01 to res=
tore
>>> host state is flat out wrong.
>>=20
>> Ah, that's not true, using vmcb01 is allowed by "may store some or all h=
ost state
>> in hidden on-chip memory".
>
> And also, "Different implementations may choose to save the hidden parts=
=20
> of the host=E2=80=99s segment registers as well as the selectors".
>
>>  From a performance perspective, I do like the SMI/RSM shenanigans.  I'm=
 not
>> totally opposed to the trickery since I think it will break a guest if a=
nd only
>> if the L1 guest is also violating the APM.  And we're not fudging the sp=
ec thaat
>> much :-)
>
> Yeah, that was my reasoning as well.  Any reference to "hidden on-chip=20
> memory", plus the forbidding modifications of the host save area, sort=20
> of implies that the processor can actually flush that hidden on-chip=20
> memory for whatever reason (such as on some sleep states?!?).

Ok, so it seems nobody feel strongly against the idea I've implemented
in the RFC. We could've avoided saving L1 host state upon L2 enter in
vmcb01 altogether, true, but we would still need some sort of a cache
emulating "hidden on-chip memory" for performance reasons. Resurrecting
'hsave'/ allocating 'special' vmcb01_smm/... and modifying nested state
seems to be unneeded, the L2->SMM case should be rare indeed.

I'll add a testcase to smm selftest and submit v1 then, thanks!

--=20
Vitaly