head	1.5;
access;
symbols
	netbsd-11-0-RC4:1.5
	netbsd-11-0-RC3:1.5
	netbsd-11-0-RC2:1.5
	netbsd-11-0-RC1:1.5
	perseant-exfatfs-base-20250801:1.5
	netbsd-11:1.5.0.28
	netbsd-11-base:1.5
	netbsd-10-1-RELEASE:1.5
	perseant-exfatfs-base-20240630:1.5
	perseant-exfatfs:1.5.0.26
	perseant-exfatfs-base:1.5
	netbsd-9-4-RELEASE:1.4
	netbsd-10-0-RELEASE:1.5
	netbsd-10-0-RC6:1.5
	netbsd-10-0-RC5:1.5
	netbsd-10-0-RC4:1.5
	netbsd-10-0-RC3:1.5
	netbsd-10-0-RC2:1.5
	thorpej-ifq:1.5.0.24
	thorpej-ifq-base:1.5
	thorpej-altq-separation:1.5.0.22
	thorpej-altq-separation-base:1.5
	netbsd-10-0-RC1:1.5
	netbsd-10:1.5.0.20
	netbsd-10-base:1.5
	bouyer-sunxi-drm:1.5.0.18
	bouyer-sunxi-drm-base:1.5
	netbsd-9-3-RELEASE:1.4
	thorpej-i2c-spi-conf2:1.5.0.16
	thorpej-i2c-spi-conf2-base:1.5
	thorpej-futex2:1.5.0.14
	thorpej-futex2-base:1.5
	thorpej-cfargs2:1.5.0.12
	thorpej-cfargs2-base:1.5
	cjep_sun2x-base1:1.5
	cjep_sun2x:1.5.0.10
	cjep_sun2x-base:1.5
	cjep_staticlib_x-base1:1.5
	netbsd-9-2-RELEASE:1.4
	cjep_staticlib_x:1.5.0.8
	cjep_staticlib_x-base:1.5
	thorpej-i2c-spi-conf:1.5.0.6
	thorpej-i2c-spi-conf-base:1.5
	thorpej-cfargs:1.5.0.4
	thorpej-cfargs-base:1.5
	thorpej-futex:1.5.0.2
	thorpej-futex-base:1.5
	netbsd-9-1-RELEASE:1.4
	bouyer-xenpvh-base2:1.4
	phil-wifi-20200421:1.4
	bouyer-xenpvh-base1:1.4
	phil-wifi-20200411:1.4
	bouyer-xenpvh:1.4.0.12
	bouyer-xenpvh-base:1.4
	is-mlppp:1.4.0.10
	is-mlppp-base:1.4
	phil-wifi-20200406:1.4
	ad-namecache-base3:1.4
	netbsd-9-0-RELEASE:1.4
	netbsd-9-0-RC2:1.4
	ad-namecache-base2:1.4
	ad-namecache-base1:1.4
	ad-namecache:1.4.0.8
	ad-namecache-base:1.4
	netbsd-9-0-RC1:1.4
	phil-wifi-20191119:1.4
	netbsd-9:1.4.0.6
	netbsd-9-base:1.4
	phil-wifi:1.4.0.4
	phil-wifi-20190609:1.4
	isaki-audio2:1.4.0.2
	isaki-audio2-base:1.4
	pgoyette-compat-merge-20190127:1.1.2.2
	pgoyette-compat-20190127:1.1
	pgoyette-compat-20190118:1.1
	pgoyette-compat-1226:1.1
	pgoyette-compat:1.1.0.2
	pgoyette-compat-1126:1.1;
locks; strict;
comment	@# @;


1.5
date	2020.08.05.10.33.01;	author maxv;	state Exp;
branches;
next	1.4;
commitid	l2xLVpokiR7mwRiC;

1.4
date	2019.02.23.12.27.00;	author maxv;	state Exp;
branches
	1.4.4.1;
next	1.3;
commitid	HAD3iRZq9dTC9TcB;

1.3
date	2019.02.17.04.05.55;	author rin;	state Exp;
branches;
next	1.2;
commitid	viEUadQYccaOx4cB;

1.2
date	2019.02.13.16.03.16;	author maxv;	state Exp;
branches;
next	1.1;
commitid	foc2r4ELMQ9xFCbB;

1.1
date	2018.11.07.07.43.08;	author maxv;	state Exp;
branches
	1.1.2.1;
next	;
commitid	wcR77DxkGB823ZYA;

1.4.4.1
date	2019.02.23.12.27.00;	author christos;	state dead;
branches;
next	1.4.4.2;
commitid	jtc8rnCzWiEEHGqB;

1.4.4.2
date	2019.06.10.22.09.35;	author christos;	state Exp;
branches;
next	;
commitid	jtc8rnCzWiEEHGqB;

1.1.2.1
date	2018.11.07.07.43.08;	author pgoyette;	state dead;
branches;
next	1.1.2.2;
commitid	Zj4q5SspGdKXto1B;

1.1.2.2
date	2018.11.26.01.52.50;	author pgoyette;	state Exp;
branches;
next	;
commitid	Zj4q5SspGdKXto1B;


desc
@@


1.5
log
@Upgrade NVMM to WARNS=5.
@
text
@#	$NetBSD: Makefile,v 1.4 2019/02/23 12:27:00 maxv Exp $

.include "../Makefile.inc"
.include "../Makefile.assym"

CPPFLAGS+=

.PATH:	${S}/dev/nvmm
.PATH:	${S}/dev/nvmm/x86

KMOD=	nvmm
IOCONF=	nvmm.ioconf
SRCS=	nvmm.c

.if ${MACHINE_ARCH} == "x86_64"
SRCS+=	nvmm_x86.c
SRCS+=	nvmm_x86_svm.c nvmm_x86_svmfunc.S
SRCS+=	nvmm_x86_vmx.c nvmm_x86_vmxfunc.S
.endif

WARNS=	5

.include <bsd.kmodule.mk>
@


1.4
log
@Install the x86 RESET state at VCPU creation time, for convenience, so
that the libnvmm users can expect a functional VCPU right away.
@
text
@d1 1
a1 1
#	$NetBSD: Makefile,v 1.3 2019/02/17 04:05:55 rin Exp $
d21 1
a21 1
WARNS=	3
@


1.4.4.1
log
@file Makefile was added on branch phil-wifi on 2019-06-10 22:09:35 +0000
@
text
@d1 23
@


1.4.4.2
log
@Sync with HEAD
@
text
@a0 23
#	$NetBSD: Makefile,v 1.4 2019/02/23 12:27:00 maxv Exp $

.include "../Makefile.inc"
.include "../Makefile.assym"

CPPFLAGS+=

.PATH:	${S}/dev/nvmm
.PATH:	${S}/dev/nvmm/x86

KMOD=	nvmm
IOCONF=	nvmm.ioconf
SRCS=	nvmm.c

.if ${MACHINE_ARCH} == "x86_64"
SRCS+=	nvmm_x86.c
SRCS+=	nvmm_x86_svm.c nvmm_x86_svmfunc.S
SRCS+=	nvmm_x86_vmx.c nvmm_x86_vmxfunc.S
.endif

WARNS=	3

.include <bsd.kmodule.mk>
@


1.3
log
@Bump default value of WARNS for modules from 3 to 5, and
explicitly set WARNS for modules that fail with WARNS=5.

Also, turn on -Wno-missing-noreturn for clang for some files.

At the moment, among ~ 360 modules,
- 2 (lua and zfs) need WARNS=0
- 1 (solaris) needs WARNS=1
- 136 need WARNS=3 (mostly due to sign-compare)
- 4 need WARNS=4
- others can be compiled with WARNS=5

Discussed on tech-kern.
@
text
@d1 1
a1 1
#	$NetBSD: Makefile,v 1.2 2019/02/13 16:03:16 maxv Exp $
d16 1
@


1.2
log
@Add Intel-VMX support in NVMM. This allows us to run hardware-accelerated
VMs on Intel CPUs. Overall this implementation is fast and reliable, I am
able to run NetBSD VMs with many VCPUs on a quad-core Intel i5.

NVMM-Intel applies several optimizations already present in NVMM-AMD, and
has a code structure similar to it. No change was needed in the NVMM MI
frontend, or in libnvmm.

Some differences exist against AMD:

 - On Intel the ASID space is big, so we don't fall back to a shared ASID
   when there are more VCPUs executing than available ASIDs in the host,
   contrary to AMD. There are enough ASIDs for the maximum number of VCPUs
   supported by NVMM.

 - On Intel there are two TLBs we need to take care of, one for the host
   (EPT) and one for the guest (VPID). Changes in EPT paging flush the
   host TLB, changes to the guest mode flush the guest TLB.

 - On Intel there is no easy way to set/fetch the VTPR, so we intercept
   reads/writes to CR8 and maintain a software TPR, that we give to the
   virtualizer as if it was the effective TPR in the guest.

 - On Intel, because of SVS, the host CR4 and LSTAR are not static, so
   we're forced to save them on each VMENTRY.

 - There is extra Intel weirdness we need to take care of, for example the
   reserved bits in CR0 and CR4 when accesses trap.

While this implementation is functional and can already run many OSes, we
likely have a problem on 32bit-PAE guests, because they require special
care on Intel CPUs, and currently we don't handle that correctly; such
guests may misbehave for now (without altering the host stability). I
expect to fix that soon.
@
text
@d1 1
a1 1
#	$NetBSD: Makefile,v 1.1 2018/11/07 07:43:08 maxv Exp $
d20 2
@


1.1
log
@Add NVMM - for NetBSD Virtual Machine Monitor -, a kernel driver that
provides support for hardware-accelerated virtualization on NetBSD.

It is made of an MI frontend, to which MD backends can be plugged. One
MD backend is implemented, x86-SVM, for x86 AMD CPUs.

We install

	/usr/include/dev/nvmm/nvmm.h
	/usr/include/dev/nvmm/nvmm_ioctl.h
	/usr/include/dev/nvmm/{arch}/nvmm_{arch}.h

And the kernel module. For now, the only architecture where we do that
is amd64 (arch=x86).

NVMM is not enabled by default in amd64-GENERIC, but is instead easily
modloadable.

Sent to tech-kern@@ a month ago. Validated with kASan, and optimized
with tprof.
@
text
@d1 1
a1 1
#	$NetBSD: Makefile,v 1.1 2018/11/05 00:00:00 maxv Exp $
d17 1
@


1.1.2.1
log
@file Makefile was added on branch pgoyette-compat on 2018-11-26 01:52:50 +0000
@
text
@d1 19
@


1.1.2.2
log
@Sync with HEAD, resolve a couple of conflicts
@
text
@a0 19
#	$NetBSD: Makefile,v 1.1 2018/11/07 07:43:08 maxv Exp $

.include "../Makefile.inc"
.include "../Makefile.assym"

CPPFLAGS+=

.PATH:	${S}/dev/nvmm
.PATH:	${S}/dev/nvmm/x86

KMOD=	nvmm
IOCONF=	nvmm.ioconf
SRCS=	nvmm.c

.if ${MACHINE_ARCH} == "x86_64"
SRCS+=	nvmm_x86_svm.c nvmm_x86_svmfunc.S
.endif

.include <bsd.kmodule.mk>
@


