[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a59b2a76-dada-866d-ff2b-2d730b70d070@redhat.com>
Date: Tue, 6 Apr 2021 15:47:59 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Ashish Kalra <ashish.kalra@....com>,
Steve Rutherford <srutherford@...gle.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, Joerg Roedel <joro@...tes.org>,
Borislav Petkov <bp@...e.de>,
Tom Lendacky <thomas.lendacky@....com>,
X86 ML <x86@...nel.org>, KVM list <kvm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Sean Christopherson <seanjc@...gle.com>,
Venu Busireddy <venu.busireddy@...cle.com>,
Brijesh Singh <brijesh.singh@....com>
Subject: Re: [PATCH v11 10/13] KVM: x86: Introduce new
KVM_FEATURE_SEV_LIVE_MIGRATION feature & Custom MSR.
On 06/04/21 15:26, Ashish Kalra wrote:
>> It's a little unintuitive to see KVM_MSR_RET_FILTERED here, since
>> userspace can make this happen on its own without having an entry in
>> this switch statement (by setting it in the msr filter bitmaps). When
>> using MSR filters, I would only expect to get MSR filter exits for
>> MSRs I specifically asked for.
>>
>> Not a huge deal, just a little unintuitive. I'm not sure other options
>> are much better (you could put KVM_MSR_RET_INVALID, or you could just
>> not have these entries in svm_{get,set}_msr).
>>
> Actually KVM_MSR_RET_FILTERED seems more logical to use, especially in
> comparison with KVM_MSR_RET_INVALID.
>
> Also, hooking this msr in svm_{get,set}_msr allows some in-kernel error
> pre-processsing before doing the pass-through to userspace.
I agree that it should be up to userspace to set up the filter since we
now have that functionality.
Let me read the whole threads for the past versions to see what the
objections were...
Paolo
Powered by blists - more mailing lists