[PATCH] x86: svm: Fix broken FS base on deactivation

[Jan Kiszka]

After f93e23934b, we no longer call vmsave, thus will also not find the
right FS base there. This caused sporadic crashes of "jailhouse disable"
on return to userspace.

Fix it by loading the value from the corresponding MSR.

Signed-off-by: Jan Kiszka <jan.k...@siemens.com>
---
hypervisor/arch/x86/svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hypervisor/arch/x86/svm.c b/hypervisor/arch/x86/svm.c
index 18fb688..e911e30 100644
--- a/hypervisor/arch/x86/svm.c
+++ b/hypervisor/arch/x86/svm.c
@@ -468,7 +468,7 @@ void __attribute__((noreturn)) vcpu_deactivate_vmm(void)
asm volatile("str %0" : "=m" (cpu_data->linux_tss.selector));

cpu_data->linux_efer = vmcb->efer & (~EFER_SVME);
- cpu_data->linux_fs.base = vmcb->fs.base;
+ cpu_data->linux_fs.base = read_msr(MSR_FS_BASE);
cpu_data->linux_gs.base = vmcb->gs.base;

cpu_data->linux_ds.selector = vmcb->ds.selector;
--
2.1.4

[Valentine Sinitsyn]

Should we do the same for GS, for consistency reasons? vmcb->gs.base is
equals to MSR_GS_BASE, as VMM deactivation follows VM exit now, but
that's an implicit dependency.

> cpu_data->linux_ds.selector = vmcb->ds.selector;

Valentine

[Jan Kiszka]

At this point, MSR_GS_BASE is still set to the hypervisor value (or we
couldn't use this_cpu_data() in this function). It will only be loaded
with the Linux value in arch_cpu_restore.

Jan

--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux