On 03/20/2017 04:20 PM, Andrew Cooper wrote: > On 20/03/17 09:50, Razvan Cojocaru wrote: >> xc_altp2m_set_mem_access() and xc_set_mem_access() end up doing the same >> thing >> in the hypervisor, but the former is a HVMOP and the latter a DOMCTL. Since >> nobody is currently using, or has stated intent to use, this functionality >> specifically as an HVMOP, this patch removes the HVMOP while adding an extra >> parameter to the more flexible DOMCTL variant, in which the altp2m view can >> be >> transmitted (0 for the default view, or when altp2m is disabled). >> The xen-access test has been updated in the process. >> >> Signed-off-by: Razvan Cojocaru <rcojoc...@bitdefender.com> > > I am sorry to be awkward here, but as this patch stands, it definitely > breaks the original usecase altp2m was introduced for. Therefore, I > don't it is appropriate to take in this form. > > The problem is that the current permissions are too coarse-grained. > > Intel's use case needs all hypercalls usable by the guest, as the agent > is entirely in-guest. (It also occurs to me that scenario might be > useful to develop within.) > > Bitdefenders use case needs vmfunc usable by the guest, but all > alteration of view permissions must be restricted to a more privileged > entity. > > Tamas' usecase is (IIRC) entirely behind the back of the guest. > > > As a result, the two choices needed are "can a guest configure/use > vmfunc", and "can a guest alter its own view permissions". > > These should cater to all usecases, as far as I understand.
Alright, but in that case I'm not sure how to proceed with this. Would returning to the previous form of the patch (adding another HVMOP + solving the compat issues) work? Or are you proposing an altogether different mechanism, alongside which this merge would work? As for Intel's use case, we've unfortunately had no reply from Ravi Sahita (CCd on the discussion even before V1 was sent). If somebody knows other email addresses we should use, please CC them. Thanks, Razvan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel