[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <90cb8be18da40c62f6acbf2bee19ec046e122e49.camel@redhat.com>
Date: Thu, 30 Nov 2023 19:29:13 +0200
From: Maxim Levitsky <mlevitsk@...hat.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"Yang, Weijiang" <weijiang.yang@...el.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"seanjc@...gle.com" <seanjc@...gle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Hansen, Dave" <dave.hansen@...el.com>
Cc: "john.allen@....com" <john.allen@....com>,
"peterz@...radead.org" <peterz@...radead.org>,
"Gao, Chao" <chao.gao@...el.com>
Subject: Re: [PATCH v7 05/26] x86/fpu/xstate: Introduce fpu_guest_cfg for
guest FPU configuration
On Tue, 2023-11-28 at 14:58 +0000, Edgecombe, Rick P wrote:
> On Fri, 2023-11-24 at 00:53 -0500, Yang Weijiang wrote:
> > + /*
> > + * Set guest's __user_state_size to fpu_user_cfg.default_size
> > so that
> > + * existing uAPIs can still work.
> > + */
> > + fpu->guest_perm.__user_state_size =
> > fpu_user_cfg.default_size;
>
> It seems like an appropriate value, but where does this come into play
> exactly for guest FPUs?
It is used because permission API is used for guest fpu state as well (for user features),
and it affects two things:
1. If permission is not asked, then KVM will fail to resize the FPU state to match guest CPUID.
2. It will affect output size of the KVM_GET_XSAVE2 ioctl, which outputs buffer similar to
other FPU state buffers exposed to userspace (like one saved on signal stack, or one obtained via ptrace).
Best regards,
Maxim Levitsky
Powered by blists - more mailing lists