Multiple issues with debug register access handling

[tandasat]

1. DR7.general_detect (GD) should be cleared

hvpp does not clear the DR7.GD bit in the VMCS up on #DB. This causes an unintended #DB when the processor attempt to access debug registers and likely to cause a bug check. As 17.2.4 Debug Control Register (DR7) states (The processor clears the GD flag upon entering to the debug exception handler (...)), the processor automatically the DR7.GD bit on #DB. Since hvpp does not emulate this behaviour and leaves that bit set in the VMCS, any DR access results in #DB, while it should have been allowed if GD is properly cleared. The proper fix will be to add such a #DB handler, though clearing it within handle_mov_dr when #DB is injected can be an lazy option too.

2. Access to DR4 and 5 should be treated in the same manner as DR6 and 7 access are

hvpp behaves differently when DR4,5 and DR6,7 are accessed, resulting in setting to or getting of incorrect values. For example, write to DR5 is emulated with just the mov instruction while it should be handled in the same manner as write to DR7, which needs writes to VMCS with the upper bits check. This issue only manifests when CR4.DE is cleared, which is not the default case on Windows as far as I can tell.

3. Always 1 and 0 bits in the DR6 and 7 should be emulated

The processor appears to ignore writes to the bits described as 0 or 1 in Figure 17-1. Debug Registers on the non-root mode. It is, however, the processor can indeed modify those bits on the root-mode, and so, the current hpvv's emulate that behaviour. I was unable to find a description about this behaviour in the Intel SDM, but VMware and KVM(Link) emulate this too.

If you would like to have three separated issues, let me know. I will do so.

[tandasat]

Those were found while I was fixing the other issue in HyperPlatform. Here is a fix I made for them.
tandasat/HyperPlatform#28 (comment)

[wbenny]

Thank you! Hopefully commit ca561fa fixes all listed issues. I've tested it with provided driver in Issue28.zip and everything should be working as expected. If you spot anything else related to this issue, feel free to reopen it.