[src/trunk]: src/doc Add a TODO list for NVMM, just to list some known issues.

[maxv <maxv%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/03262c1dc362
branches:  trunk
changeset: 997092:03262c1dc362
user:      maxv <maxv%NetBSD.org@localhost>
date:      Thu Feb 21 14:56:23 2019 +0000

description:
Add a TODO list for NVMM, just to list some known issues.

diffstat:

 doc/TODO.nvmm |  27 +++++++++++++++++++++++++++
 1 files changed, 27 insertions(+), 0 deletions(-)

diffs (31 lines):

diff -r 7d6e64a7d31b -r 03262c1dc362 doc/TODO.nvmm
--- /dev/null   Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/TODO.nvmm     Thu Feb 21 14:56:23 2019 +0000
@@ -0,0 +1,27 @@
+Known issues in NVMM, low priority in most cases.
+
+====== KERNEL NVMM DRIVER ======
+
+ * Currently you can't modunload NVMM while a VM is running, otherwise you hit
+   a panic. See TODO in nvmm_fini().
+
+ * Maybe we will want a way to return to userland when the guest TPR changes.
+   On Intel that's not complicated, but on old AMD CPUs, we need to disassemble
+   the instruction, and I don't like that.
+
+ * Maybe we shouldn't modify the INT/NMI windows during event injection. The
+   virtualizer is supposed to inject the event only when these windows allow
+   it. (Eg Qemu does.)
+
+ * We need a cleaner way to handle CPUID exits. It is not complicated to solve,
+   but I'm still not sure which design is the cleanest.
+
+ * Same for the MSRs.
+
+====== LIBNVMM ======
+
+ * There are still a few twisted corner cases we don't handle in the instruction
+   emulator. For example if the guest makes an MMIO access relative to RSP, we
+   must base the GVA on %SS and not %DS. This is tiring, and in practice, no
+   guest is dumb enough to perform such accesses.
+