Hi,
Intel manuals aren't very clear about the invept instruction. I have a guest running and it encounters a ept violation (the entry doesn't exist in ept tables). Then my hypervisor sets up a new EPT mapping, do I need to call invept on that gpa?
If I just setup a new mapping in my EPT table, and do a VMRESUME, bochs corrupts the hosts page tables and on a vmexit the host triple faults (instruction not found). My guest works perfectly if I do a static EPT mapping before I run the guest for the first time, VMRUN.
Thanks.
[EPT][BOCHS] Do I need to do an invept on VMEXIT?
Re: [EPT][BOCHS] Do I need to do an invept on VMEXIT?
Intel guarantees that it won't cache in the TLBs or intermediate translation caches any not present page entries or pages with reserved bits violations.
For EPT it means not present or misconfigured EPT entries. For all other cases the translation could be cached and TLB invalidation will be required.
For example:
If your walk encountered EPT violation because of not present EPT entry, it is guaranteed that no TLB cache could keep translation to this entry.
In this case, if you simply define EPT entry and make it present, no TLB invalidations are required. You could just restart the operation.
If your walk encountered EPT violation because of of permissions (for example not writeable page) the translation could be cached in the TLBs so it won't be enough to fix the permissions in EPT PTE and restart the operation. The restarted operation could hit in the TLB and still see non writeable page.
The special case are PDPTE entries for legacy PAE. I am not 100% sure that happens with them but you should keep in mind that they are actually CPU registers and not just ordinary intermediate level translations. This is why 4 PDPTE entries have separate VMCS fields and provided directly on VMENTRY by host instead of being page walked as usual.
BTW, it also could be the Bochs bug, could you explain the scenartio you see in more details ?
I could help both validating the expected architectural behavior and with checking if Bochs doing the stuff right.
Thanks
Stanislav
For EPT it means not present or misconfigured EPT entries. For all other cases the translation could be cached and TLB invalidation will be required.
For example:
If your walk encountered EPT violation because of not present EPT entry, it is guaranteed that no TLB cache could keep translation to this entry.
In this case, if you simply define EPT entry and make it present, no TLB invalidations are required. You could just restart the operation.
If your walk encountered EPT violation because of of permissions (for example not writeable page) the translation could be cached in the TLBs so it won't be enough to fix the permissions in EPT PTE and restart the operation. The restarted operation could hit in the TLB and still see non writeable page.
The special case are PDPTE entries for legacy PAE. I am not 100% sure that happens with them but you should keep in mind that they are actually CPU registers and not just ordinary intermediate level translations. This is why 4 PDPTE entries have separate VMCS fields and provided directly on VMENTRY by host instead of being page walked as usual.
BTW, it also could be the Bochs bug, could you explain the scenartio you see in more details ?
I could help both validating the expected architectural behavior and with checking if Bochs doing the stuff right.
Thanks
Stanislav
Re: [EPT][BOCHS] Do I need to do an invept on VMEXIT?
Thank you Stanislav for the reply. That cleared things up and I'm indeed doing the right thing when it comes to EPT violations for pages that aren't present.
My situation is this, my guest starts up in real mode and switched to long mode. Host is also running in long mode, obviously. Upon an EPT violation, I grab a free page from my host, map it in the EPT tables (with full permissions) and mark it as non free in the host.
Then I re-enter the guest, sometimes randomly, the host memory (specifically the page tables I think, because it can no longer find the instruction to execute after a VMEXIT) is corrupted when the guest does a memset(0) to a newly mapped page in EPT, leading to a host triple fault.
I'm trying to reproduce this bug, will post the bochs logs when I'm able to do so. I'm also trying to get my kernel up and running on real hardware so that the bug can be isolated to bochs.
My situation is this, my guest starts up in real mode and switched to long mode. Host is also running in long mode, obviously. Upon an EPT violation, I grab a free page from my host, map it in the EPT tables (with full permissions) and mark it as non free in the host.
Then I re-enter the guest, sometimes randomly, the host memory (specifically the page tables I think, because it can no longer find the instruction to execute after a VMEXIT) is corrupted when the guest does a memset(0) to a newly mapped page in EPT, leading to a host triple fault.
I'm trying to reproduce this bug, will post the bochs logs when I'm able to do so. I'm also trying to get my kernel up and running on real hardware so that the bug can be isolated to bochs.