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

[Vlad-Ioan TOPAN <itopan@xxxxxxxxxxxxxxx>]

> > 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?

Thank you,
--
Vlad-Ioan TOPAN
Linux Kernel Development Lead
Bitdefender

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