On Fri, Feb 12, 2021, Dave Hansen wrote: > On 2/12/21 12:06 PM, Sean Christopherson wrote: > >> What happens if the guest attempts to access a secure GPA that is not > >> ACCEPTed? For example, suppose the VMM does THH.MEM.PAGE.REMOVE on a > >> secure > >> address and the guest accesses it, via instruction fetch or data access. > >> What happens? > > Well, as currently written in the spec, it will generate an EPT violation > > and > > the host will have no choice but to kill the guest. > > That's actually perfect behavior from my perspective. Host does > something stupid. Host gets left holding the pieces. No enabling to do > in the guest. > > This doesn't *preclude* the possibility that the VMM and guest could > establish a protocol to remove guest pages. It just means that the host > can't go it alone and that if they guest and host get out of sync, the > guest dies. > > In other words, I think I'm rooting for the docs, as written. :)
I tentatively agree that the host should not be able to remove pages without guest approval, but that's not the only use case for #VE on EPT violations. It's not even really an intended use case. There needs to be a mechanism for lazy/deferred/on-demand acceptance of pages. E.g. pre-accepting every page in a VM with hundreds of GB of memory will be ridiculously slow. #VE is the best option to do that: - Relatively sane re-entrancy semantics. - Hardware accelerated. - Doesn't require stealing an IRQ from the guest.
