Le 08/01/2020 à 22:50, Andrew Doran a écrit :
On Tue, Jan 07, 2020 at 09:39:22AM +0100, Maxime Villard wrote:
Module Name: src
Committed By: ad
Date: Sat Jan 4 22:49:20 UTC 2020
Modified Files:
src/sys/arch/x86/include: pmap.h pmap_pv.h
src/sys/arch/x86/x86: pmap.c
src/sys/arch/xen/x86: xen_pmap.c
Log Message:
x86 pmap improvements, reducing system time during a build by about 15% on
my test machine:
This breaks nvmm-intel. I have only given a quick glance, but this change
already is wrong:
- old_pp->pp_attrs |= pmap_ept_to_pp_attrs(opte);
+ old_pp->pp_attrs |= pmap_pte_to_pp_attrs(opte);
This is an EPT function handling EPT PTEs, so "ept" was correct. Fixing
this bug is not sufficient, so it seems that there are more bugs.
Reverting the whole change puts nvmm-intel back in a functional state.
You can test with this on an Intel CPU:
# modload nvmm
# /usr/tests/lib/libnvmm/./h_mem_assist
This currently gives random crashes.
With a couple of typos fixed (PTE -> EPT, now checked in) I see the same FPU
DNA exception that Chavdar reports on current-users (in his case with a
kernel which doesn't have these pmap changes). It's coming from:
vmx_vcpu_guest_fpu_leave() -> fpu_area_save() -> fxsave()
What I can tell you is that the fxsave area is definitely writable and
correctly aligned but beyond that I have no idea what's causing it. Any
suggestions?
Cheers,
Andrew
This FPU issue should be fixed in the latest nvmm_x86_vmx.c, we still have
STTS/CLTS (not needed but for debugging) as part of context switches, and
when overhauling the FPU code I overlooked that VMX needs special CR0_TS
care that SVM doesn't need.
Note that dropping STTS/CLTS would probably increase cswitch performance,
because updating cr0 is costly.
Having said that, I am still hitting a KASSERT related to pmap:
kernel diagnostic assertion "ptp->wire_count == 1" failed file
".../x86/x86/pmap.c", line 1969
pmap_freepages
pmap_ept_free_ptp
pmap_ept_remove
pmap_remove
uvm_unmap_remove
uvmspace_free
nvmm_ioctl
sys_ioctl
Maxime
