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
