** Description changed:
[Impact]
When a host that supports PKRU initiates a guest that lacks PKRU support, the
flag is enabled on the guest's fpstate.
This information is then passed to userspace through the vcpu ioctl
KVM_GET_XSAVE.
However, a problem arises when the user opts to migrate the mentioned guest
to another machine that does not support PKRU.
In this scenario, the new host attempts to restore the guest's fpu registers.
Nevertheless, due to the absence of PKRU support on the new host, a
general-protection exception takes place, leading to a guest crash.
[Fix]
The problem is resolved by the following upstream commit:
- ad856280ddea x86/kvm/fpu: Limit guest user_xfeatures to supported bits of XCR0
-
- Additionally, a subsequent fix tackles the migration problem stemming from
the earlier commit:
- a1020a25e697 KVM: x86: Always enable legacy FP/SSE in allowed user XFEATURES
+ 18164f66e6c5 x86/fpu: Allow caller to constrain xfeatures when copying to
uabi buffer
+ 8647c52e9504 KVM: x86: Constrain guest-supported xfeatures only at
KVM_GET_XSAVE{2}
[Test Plan]
- 1. Set up two machines: one with PKRU support and the other without.
- 2. Initiate a guest that lacks PKRU support on the machine with PKRU support.
- 3. Utilize libvirt to migrate the aforementioned guest to a different machine
that lacks PKRU support.
- 4. The error emerges on the destination machine:
- KVM: entry failed, hardware error 0x80000021
+ Several scenarios need to be conducted to confirm the migration outcome.
+ Patched kernel with PKRU -> kernel with PKRU
+ Patched kernel with PKRU -> kernel without PKRU
+ Patched kernel without PKRU -> kernel with PKRU
+ Patched kernel without PKRU -> kernel without PKRU
+ Kernel with PKRU -> patched kernel with PKRU
+ Kernel with PKRU -> patched kernel without PKRU
+ Kernel without PKRU -> patched kernel with PKRU
+ Kernel without PKRU -> patched kernel without PKRU
+ Patched kernel with PKRU -> patched kernel without PKRU
- If you're running a guest on an Intel machine without unrestricted mode
- support, the failure can be most likely due to the guest entering an invalid
- state for Intel VT. For example, the guest maybe running in big real mode
- which is not supported on less recent Intel processors.
-
- EAX=86cf7970 EBX=00000000 ECX=00000001 EDX=005b0036
- ESI=00000087 EDI=00000087 EBP=87c03e38 ESP=87c03e18
- EIP=86cf7d5e EFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
- ES =0000 00000000 0000ffff 00009300
- CS =f000 ffff0000 0000ffff 00009b00
- SS =0000 00000000 0000ffff 00009300
- DS =0000 00000000 0000ffff 00009300
- FS =0000 00000000 0000ffff 00009300
- GS =0000 00000000 0000ffff 00009300
- LDT=0000 00000000 0000ffff 00008200
- TR =0000 00000000 0000ffff 00008b00
- GDT= 00000000 0000ffff
- IDT= 00000000 0000ffff
- CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
- DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000
DR3=0000000000000000
- DR6=00000000ffff0ff0 DR7=0000000000000400
- EFER=0000000000000000
- Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- 2023-07-09T03:03:14.911750Z qemu-system-x86_64: terminating on signal 15 from
pid 4134 (/usr/sbin/libvirtd)
- 2023-07-09 03:03:15.312+0000: shutting down, reason=destroyed
+ Each scenarios shall succeed except "Kernel with PKRU -> patched kernel
without PKRU" one.
+ Addressing this case poses challenges because the most plausible solution is
to clamp the FPU features at the destination during migration.
+ However, upstream does not support this approach due to concerns about
silently dropping features requested by userspace.
+ This could potentially lead to other issues and violate KVM's ABI.
[Where problems could occur]
The introduced commits will impact the guest migration process,
potentially leading to failures and preventing the guest from operating
successfully on the migration destination.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2032164
Title:
A general-proteciton exception during guest migration to unsupported
PKRU machine
Status in linux package in Ubuntu:
Confirmed
Status in linux source package in Jammy:
Triaged
Bug description:
[Impact]
When a host that supports PKRU initiates a guest that lacks PKRU support, the
flag is enabled on the guest's fpstate.
This information is then passed to userspace through the vcpu ioctl
KVM_GET_XSAVE.
However, a problem arises when the user opts to migrate the mentioned guest
to another machine that does not support PKRU.
In this scenario, the new host attempts to restore the guest's fpu registers.
Nevertheless, due to the absence of PKRU support on the new host, a
general-protection exception takes place, leading to a guest crash.
[Fix]
The problem is resolved by the following upstream commit:
18164f66e6c5 x86/fpu: Allow caller to constrain xfeatures when copying to
uabi buffer
8647c52e9504 KVM: x86: Constrain guest-supported xfeatures only at
KVM_GET_XSAVE{2}
[Test Plan]
Several scenarios need to be conducted to confirm the migration outcome.
Patched kernel with PKRU -> kernel with PKRU
Patched kernel with PKRU -> kernel without PKRU
Patched kernel without PKRU -> kernel with PKRU
Patched kernel without PKRU -> kernel without PKRU
Kernel with PKRU -> patched kernel with PKRU
Kernel with PKRU -> patched kernel without PKRU
Kernel without PKRU -> patched kernel with PKRU
Kernel without PKRU -> patched kernel without PKRU
Patched kernel with PKRU -> patched kernel without PKRU
Each scenarios shall succeed except "Kernel with PKRU -> patched kernel
without PKRU" one.
Addressing this case poses challenges because the most plausible solution is
to clamp the FPU features at the destination during migration.
However, upstream does not support this approach due to concerns about
silently dropping features requested by userspace.
This could potentially lead to other issues and violate KVM's ABI.
[Where problems could occur]
The introduced commits will impact the guest migration process,
potentially leading to failures and preventing the guest from operating
successfully on the migration destination.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2032164/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
