#
1.6 |
|
05-Sep-2020 |
maxv |
nvmm: update copyright headers
|
#
1.5 |
|
11-Aug-2020 |
maxv |
Micro-optimize: use pushq instead of pushw. To avoid LCP stalls and unaligned stack accesses.
|
#
1.4 |
|
19-Jul-2020 |
maxv |
The TLB flush IPIs do not respect the IPL, so enforcing IPL_HIGH has no effect. Disable interrupts earlier instead. This prevents a possible race against such IPIs.
|
Revision tags: bouyer-xenpvh-base2 phil-wifi-20200421 bouyer-xenpvh-base1 phil-wifi-20200411 bouyer-xenpvh-base is-mlppp-base phil-wifi-20200406 ad-namecache-base3 netbsd-9-0-RELEASE netbsd-9-0-RC2 ad-namecache-base2 ad-namecache-base1 ad-namecache-base netbsd-9-0-RC1 phil-wifi-20191119 netbsd-9-base phil-wifi-20190609
|
#
1.3 |
|
27-Apr-2019 |
maxv |
branches: 1.3.2; 1.3.4; Optimize nvmm-intel, use inlined GCC assembly rather than function calls.
|
#
1.2 |
|
24-Apr-2019 |
maxv |
Match the structure order, for better cache utilization.
|
Revision tags: isaki-audio2-base
|
#
1.1 |
|
13-Feb-2019 |
maxv |
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.
|
#
1.5 |
|
11-Aug-2020 |
maxv |
Micro-optimize: use pushq instead of pushw. To avoid LCP stalls and unaligned stack accesses.
|
#
1.4 |
|
19-Jul-2020 |
maxv |
The TLB flush IPIs do not respect the IPL, so enforcing IPL_HIGH has no effect. Disable interrupts earlier instead. This prevents a possible race against such IPIs.
|
Revision tags: bouyer-xenpvh-base2 phil-wifi-20200421 bouyer-xenpvh-base1 phil-wifi-20200411 bouyer-xenpvh-base is-mlppp-base phil-wifi-20200406 ad-namecache-base3 netbsd-9-0-RELEASE netbsd-9-0-RC2 ad-namecache-base2 ad-namecache-base1 ad-namecache-base netbsd-9-0-RC1 phil-wifi-20191119 netbsd-9-base phil-wifi-20190609
|
#
1.3 |
|
27-Apr-2019 |
maxv |
branches: 1.3.2; Optimize nvmm-intel, use inlined GCC assembly rather than function calls.
|
#
1.2 |
|
24-Apr-2019 |
maxv |
Match the structure order, for better cache utilization.
|
Revision tags: isaki-audio2-base
|
#
1.1 |
|
13-Feb-2019 |
maxv |
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.
|
#
1.4 |
|
19-Jul-2020 |
maxv |
The TLB flush IPIs do not respect the IPL, so enforcing IPL_HIGH has no effect. Disable interrupts earlier instead. This prevents a possible race against such IPIs.
|
Revision tags: bouyer-xenpvh-base2 phil-wifi-20200421 bouyer-xenpvh-base1 phil-wifi-20200411 bouyer-xenpvh-base is-mlppp-base phil-wifi-20200406 ad-namecache-base3 netbsd-9-0-RELEASE netbsd-9-0-RC2 ad-namecache-base2 ad-namecache-base1 ad-namecache-base netbsd-9-0-RC1 phil-wifi-20191119 netbsd-9-base phil-wifi-20190609
|
#
1.3 |
|
27-Apr-2019 |
maxv |
branches: 1.3.2; Optimize nvmm-intel, use inlined GCC assembly rather than function calls.
|
#
1.2 |
|
24-Apr-2019 |
maxv |
Match the structure order, for better cache utilization.
|
Revision tags: isaki-audio2-base
|
#
1.1 |
|
13-Feb-2019 |
maxv |
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.
|
#
1.3 |
|
27-Apr-2019 |
maxv |
Optimize nvmm-intel, use inlined GCC assembly rather than function calls.
|
#
1.2 |
|
24-Apr-2019 |
maxv |
Match the structure order, for better cache utilization.
|
Revision tags: isaki-audio2-base
|
#
1.1 |
|
13-Feb-2019 |
maxv |
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.
|