[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a1ab92dd-6e76-fb30-d570-582cd3ebecd3@redhat.com>
Date: Tue, 14 Sep 2021 12:52:54 +0200
From: Emanuele Giuseppe Esposito <eesposit@...hat.com>
To: Maxim Levitsky <mlevitsk@...hat.com>, kvm@...r.kernel.org
Cc: Paolo Bonzini <pbonzini@...hat.com>,
Sean Christopherson <seanjc@...gle.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 3/3] nSVM: use svm->nested.save to load vmcb12
registers and avoid TOC/TOU races
>
> I would do it this way:
>
> struct svm_nested_state {
> ...
> /* cached fields from the vmcb12 */
> struct vmcb_control_area_cached ctl;
> struct vmcb_save_area_cached save;
> ...
> };
>
>
The only thing that requires a little bit of additional work when
applying this is svm_get_nested_state() (and theoretically
svm_set_nested_state(), in option 2). In this function, nested.ctl is
copied in user_vmcb->control. But now nested.ctl is not anymore a
vmcb_control_area, so the sizes differ.
There are 2 options here:
1) copy nested.ctl into a full vmcb_control_area, and copy it to user
space without modifying the API. The advantage is that the API is left
intact, but an additional copy is required.
2) modify KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE to handle
vmcb_control_area_cached. Advantage is that there is a lightweight copy
+ the benefits explained by you in the previous email (no unset field).
I am not sure which one is the preferred way here.
Thank you,
Emanuele
Powered by blists - more mailing lists