[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v4] altp2m: Allow specifying external-only use-case



On Wed, Mar 22, 2017 at 2:06 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 21.03.17 at 18:25, <tamas.lengyel@xxxxxxxxxxxx> wrote:
>> On Tue, Mar 21, 2017 at 11:19 AM, Jan Beulich <JBeulich@xxxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.