Messages in this thread | | | From | Juan Quintela <> | Subject | Re: [patch 5/6] x86/fpu: Provide fpu_update_guest_xcr0/xfd() | Date | Tue, 14 Dec 2021 22:35:43 +0100 |
| |
Thomas Gleixner <tglx@linutronix.de> wrote:
Hi Thomas
> On Tue, Dec 14 2021 at 20:07, Juan Quintela wrote: >> Thomas Gleixner <tglx@linutronix.de> wrote: >>> On Tue, Dec 14 2021 at 16:11, Wei W. Wang wrote: >>>> 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) >>> >>> There haven't been ordering requirements so far, but with dynamic >>> feature enablement there are. >>> >>> I really want to avoid going to the point to deduce it from the >>> xstate:xfeatures bitmap, which is just backwards and Qemu has all the >>> required information already. >> >> First of all, I claim ZERO knowledge about low level x86_64. > > Lucky you.
Well, that is true until I have to debug some bug, at that time I miss the knowledge O:-)
>> Once told that, this don't matter for qemu migration, code is at > > Once, that was at the time where rubber boots were still made of wood, > right? :)
I forgot to add: "famous last words".
>> target/i386/kvm/kvm.c:kvm_arch_put_registers() >> >> >> ret = kvm_put_xsave(x86_cpu); >> if (ret < 0) { >> return ret; >> } >> ret = kvm_put_xcrs(x86_cpu); >> if (ret < 0) { >> return ret; >> } >> /* must be before kvm_put_msrs */ >> ret = kvm_inject_mce_oldstyle(x86_cpu); > > So this has already ordering requirements. > >> if (ret < 0) { >> return ret; >> } >> ret = kvm_put_msrs(x86_cpu, level); >> if (ret < 0) { >> return ret; >> } >> >> If it needs to be done in any other order, it is completely independent >> of whatever is inside the migration stream. > > From the migration data perspective that's correct, but I have the > nagging feeling that this in not that simple.
Oh, I was not meaning that it was simple at all.
We have backward compatibility baggage on x86_64 that is grotesque at this point. We don't send a single msr (by that name) on the main migration stream. And then we send them based on "conditions". So the trick as somithing like:
- qemu reads the msrs from kvm at some order - it stores them in a list of MSR's - On migration pre_save we "mangle" that msr's and other cpu state to on the main (decades old) state - then we send the main state - then we send conditionally the variable state
on reception side:
- we receive everything that the sending side have sent - we "demangle" it on pre_load - then we create the list of MSR's that need to be transferred - at that point we send them to kvm in another random order
So yes, I fully agree that it is not _that_ simple O:-)
>> I guess that Paolo will put some light here. > > I fear shining light on that will unearth quite a few skeletons :)
It is quite probable.
When a bugzilla start with: We found a bug while we were trying to migrate during (BIOS) boot, I just ran for the hills O:-)
Later, Juan.
| |