Re: [x86 pmap changes] CVS commit: src/sys/arch

[Maxime Villard <max%m00nbsd.net@localhost>]

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