>>> On 21.03.17 at 18:25, <tamas.leng...@zentific.com> wrote: > On Tue, Mar 21, 2017 at 11:19 AM, Jan Beulich <jbeul...@suse.com> wrote: >> Hmm, the original (abstract) VMFUNC use case, as I have >> understood it, allows a guest to actively select between EPT >> variants without having (direct) control over their contents. > > Correct. But even when altp2m is enabled on the domain VMFUNC and #VE > is not available to the guest unless vmx_vcpu_update_vmfunc_ve is > called via HVMOP_altp2m_vcpu_enable_notify. That HVMOP is created such > that it can be called from the guest, which I need to be able to deny.
All understood, but with you agreeing with my statement above, I think you also agree that there need to be two levels of what can be denied: altp2m ops in general vs altp2m ops except HVMOP_altp2m_vcpu_enable_notify (then implying the guest being allowed to use VMFUNC and receive #VE). Which, as suggested earlier, results in a total of 3 modes (besides fully disabled altp2m). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
