On Wed, Mar 22, 2017 at 2:06 AM, Jan Beulich <jbeul...@suse.com> wrote: >>>> 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). >
We can certainly add two levels of what can be denied. IMHO at the moment there isn't a usecase for that, so there isn't much point doing that. OTOH it shouldn't be much work to add it so fine I guess. Tamas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
