lkml.org 
[lkml]   [2022]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] KVM: allow compiling out SMM support
On 9/27/22 19:59, Sean Christopherson wrote:
>> The patch isn't pretty. I could skip all the changes to add WARNs
>> to called functions, but the point of adding the config symbol is
>> to make sure that those functions, and all the baggage they bring,
>> are dead.
>
> I would much rather we go even further and completely kill off those functions
> at compile time.

Ok, but then we should go all the way and move as much as possible to a
separate file. This also means moving the out-of-SMM flow away from the
emulator, which in turn enables using ctxt only for the GPRs and not for
ctxt->ops.

I have already done all that and it's quite a bit nicer; I'll send it
once I've tested it with more than just smm_test. I left a couple stubs
behind where the balance seemed to be better that way (mostly for use in
kvm_vcpu_ioctl_x86_set_vcpu_events), but most of the code is compiled out.

> There are side effects that should also be eliminated, e.g. x86 should not define
> __KVM_VCPU_MULTIPLE_ADDRESS_SPACE so that usersepace can't create memslots for
> SMM. Dropping the functions entirely wrapping those #defines in #ifdef as well,
> and so makes it all but impossible for KVM to do anything SMM related.
>
> Eliminating those at compile time requires a bit more #ifdeffery, but it's not
> awful, and IMO it's better than sprinkling WARNs in a bunch of paths. KVM_REQ_SMI
> in particular might be going too far, but even for that one I vote to kill it.

Sounds good, though of course some of the various cleanups are best done
in separate patches.

>> static int kvm_vcpu_ioctl_smi(struct kvm_vcpu *vcpu)
>> {
>> - kvm_make_request(KVM_REQ_SMI, vcpu);
>> -
>> + if (IS_ENABLED(CONFIG_KVM_SMM))
>> + kvm_make_request(KVM_REQ_SMI, vcpu);
>> return 0;
>
> This should return -EINVAL, not 0.

I'm a bit wary of changing this in case userspace is relying on it not
failing, because the paths that lead to the failing ioctl are most
likely controlled by the guest.

Paolo

\
 
 \ /
  Last update: 2022-09-28 13:42    [W:0.077 / U:1.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site