[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b3ac7ba45c984cf39783e33e0c25274d@intel.com>
Date: Tue, 14 Dec 2021 16:11:47 +0000
From: "Wang, Wei W" <wei.w.wang@...el.com>
To: Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
"Dr. David Alan Gilbert" <dgilbert@...hat.com>,
Juan Quintela <quintela@...hat.com>
CC: Jing Liu <jing2.liu@...ux.intel.com>,
"Zhong, Yang" <yang.zhong@...el.com>,
Paolo Bonzini <pbonzini@...hat.com>,
"x86@...nel.org" <x86@...nel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"Sean Christoperson" <seanjc@...gle.com>,
"Nakajima, Jun" <jun.nakajima@...el.com>,
"Tian, Kevin" <kevin.tian@...el.com>
Subject: RE: [patch 5/6] x86/fpu: Provide fpu_update_guest_xcr0/xfd()
On Tuesday, December 14, 2021 11:40 PM, Thomas Gleixner wrote:
> On Tue, Dec 14 2021 at 15:09, Wei W. Wang wrote:
> > On Tuesday, December 14, 2021 10:50 AM, Thomas Gleixner wrote:
> >> + * Return: 0 on success, error code otherwise */ int
> >> +__fpu_update_guest_features(struct fpu_guest *guest_fpu, u64 xcr0,
> >> +u64
> >> +xfd) {
> >
> > I think there would be one issue for the "host write on restore" case.
> > The current QEMU based host restore uses the following sequence:
> > 1) restore xsave
> > 2) restore xcr0
> > 3) restore XFD MSR
>
> This needs to be fixed. Ordering clearly needs to be:
>
> XFD, XCR0, XSTATE
Sorry, just to clarify that the ordering in QEMU isn't made by us for this specific XFD enabling.
It has been there for long time for the general restoring of all the XCRs and MSRs.
(if you are interested..FYI: https://github.com/qemu/qemu/blob/master/target/i386/kvm/kvm.c#L4168).
- kvm_put_xsave()
- kvm_put_xcrs()
- kvm_put_msrs()
We need to check with the QEMU migration maintainer (Dave and Juan CC-ed)
if changing that ordering would be OK.
(In general, I think there are no hard rules documented for this ordering)
Thanks,
Wei
Powered by blists - more mailing lists