[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9adb43fb-182f-dffb-1fde-ae7e9610a344@redhat.com>
Date: Wed, 13 Oct 2021 17:12:21 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Sean Christopherson <seanjc@...gle.com>,
Borislav Petkov <bp@...en8.de>
Cc: Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
"Chang S. Bae" <chang.seok.bae@...el.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Arjan van de Ven <arjan@...ux.intel.com>,
kvm@...r.kernel.org
Subject: Re: [patch 14/31] x86/fpu: Replace KVMs homebrewn FPU copy from user
On 13/10/21 16:57, Sean Christopherson wrote:
>>> +int fpu_copy_kvm_uabi_to_vcpu(struct fpu *fpu, const void *buf, u64 xcr0,
>>> + u32 *vpkru)
>> Right, except that there's no @vcpu in the args of that function. I
>> guess you could call it
>>
>> fpu_copy_kvm_uabi_to_buf()
>>
>> and that @buf can be
>>
>> vcpu->arch.guest_fpu
> But the existing @buf is the userspace pointer, which semantically makes sense
> because the userspace pointer is the "buffer" and the destination @fpu (and @prku)
> is vCPU state, not a buffer.
>
> That said, I also struggled with the lack of @vcpu. What about prepending vcpu_
> to fpu and to pkru? E.g.
>
> int fpu_copy_kvm_uabi_to_vcpu(struct fpu *vcpu_fpu, const void *buf, u64 xcr0,
> u32 *vcpu_pkru)
>
It doesn't matter much that the source is somehow related to a vCPU, as
long as the FPU is concerned. If anything I would even drop the "v"
from vpkru, but that's really nitpicking.
Paolo
Powered by blists - more mailing lists