Re: [Xen-devel] Enabling #VE for a domain from dom0

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 10/03/17 11:57, Vlad-Ioan TOPAN wrote:
>>> Is there any reason for the other check I've mentioned, performed when
>>> setting the "suppres #VE" bit in PTEs? Unsuppressing #VEs for a page
>>> will only do anything if the guest has already enabled #VE, so the
>>> previous issue doesn't apply in this case.
>> suppress #VE has a negative meaning.  Once #VE is enabled, all frames
>> need SVE for Xen to continue getting EPT_VIOLATION vmexits per usual. 
>> It is only whitelisted frames which should have SVE cleared on them.
>>
>> Having said that, by the time you have cooperation between several
>> domains, I don't see a reason for excluding a remote domain updating SVE.
> Sorry for following up so late on this; what would be an acceptable
> approach to allow a remote domain to update the "Suppress VE" bit for a
> given domain?
>
> The current page permission code flow via do_altp2m_op() / 
> HVMOP_altp2m_set_mem_access only allows setting actual page permissions,
> and all the other APIs it calls along the way (p2m_set_mem_access(),
> set_mem_access() and p2m_set_altp2m_mem_access() in mem_access.c) don't
> have a "suppress VE" parameter (up until the ept_set_entry() call,
> which gets sve as "current->domain != d" from
> p2m_set_altp2m_mem_access()). At that level a separate parameter for
> sVE does not make sense, since the code is shared with the ARM arch.
>
> Would it be acceptable to add an HVMOP_altp2m_set_suppres_ve op?

Given the reasoning in
https://lists.xenproject.org/archives/html/xen-devel/2017-03/msg01309.html
I think it is reasonable, after the domain has initialised altp2m
support, to allow a remote domain to alter all aspects of altp2m
permissions.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel