Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [patch 13/31] x86/fpu: Move KVMs FPU swapping to FPU core | Date | Thu, 14 Oct 2021 14:23:21 +0200 |
| |
Paolo,
On Thu, Oct 14 2021 at 08:50, Paolo Bonzini wrote: > On 13/10/21 16:06, Thomas Gleixner wrote: >>> - the guest value stored in vcpu->arch. >>> >>> - the "QEMU" value attached to host_fpu. This one only becomes zero if >>> QEMU requires AMX (which shouldn't happen). >> >> I don't think that makes sense. >> >> First of all, if QEMU wants to expose AMX to guests, then it has to ask >> for permission to do so as any other user space process. We're not going >> to make that special just because. > > Hmm, I would have preferred if there was no need to enable AMX for the > QEMU FPU. But you're saying that guest_fpu needs to swap out to > current->thread.fpu if the guest is preempted, which would require > XFD=0; and affect QEMU operation as well.
Exactly. If we don't enable it for QEMY itself, then this is creating just a horrible inconsistency which requires nasty hacks. I'm not at all interested in those as I just got rid of quite some and made the code consistent.
> In principle I don't like it very much; it would be nicer to say "you > enable it for QEMU itself via arch_prctl(ARCH_SET_STATE_ENABLE), and for > the guests via ioctl(KVM_SET_CPUID2)". But I can see why you want to > keep things simple, so it's not a strong objection at all.
Errm.
qemu() read_config() if (dynamic_features_passthrough()) request_permission(feature) <- prctl(ARCH_SET_STATE_ENABLE)
create_vcpu_threads() ....
vcpu_thread() kvm_ioctl(ENABLE_DYN_FEATURE, feature) <- KVM ioctl
That's what I lined out, right?
>> Anything else will just create more problems than it solves. Especially >> #NM handling (think nested guest) and the XFD_ERR additive behaviour >> will be a nasty playground and easy to get wrong. >> >> Not having that at all makes life way simpler, right? > > It is simpler indeed, and it makes sense to start simple. I am not sure > if it will hold, but I agree it's better for the first implementation.
KISS is a very reasonable engineering principle :)
If there is a real world use case and a proper technical justification for doing the dynamic buffer allocation then I'm happy to discuss that.
Thanks,
tglx
| |