xref: /netbsd-src/doc/TODO.nvmm (revision cccc70bfe026c362d68ce933d91713c1b8ffc0fb)
16c017c90SmaxvKnown issues in NVMM, low priority in most cases.
26c017c90Smaxv
36c017c90Smaxv====== KERNEL NVMM DRIVER ======
46c017c90Smaxv
59613cf27Smaxv * 32bit-PAE guests can misbehave on Intel, because we need to manually
69613cf27Smaxv   install the PDPTEs, and currently we don't do it. In practice they don't
79613cf27Smaxv   misbehave because the emulator never has to interfere with CR3.
86c017c90Smaxv
9db69dfa8Smaxv * AMD: we don't support VCPU_CONF_TPR, would be nice to.
106c017c90Smaxv
11*cccc70bfSmaxv * AMD: need to do comprehensive CPUID filtering, like we already do on
12*cccc70bfSmaxv   Intel.
136c017c90Smaxv
146c017c90Smaxv====== LIBNVMM ======
156c017c90Smaxv
166c017c90Smaxv * There are still a few twisted corner cases we don't handle in the instruction
176c017c90Smaxv   emulator. For example if the guest makes an MMIO access relative to RSP, we
186c017c90Smaxv   must base the GVA on %SS and not %DS. This is tiring, and in practice, no
196c017c90Smaxv   guest is dumb enough to perform such accesses.
206c017c90Smaxv
21db69dfa8Smaxv * Maybe the __areas should have a rwlock? I don't think Qemu unmaps memory
22db69dfa8Smaxv   while VCPUs are running, but still.
23