>>> On 06.07.15 at 18:49, <edmund.h.wh...@intel.com> wrote: > On 07/06/2015 03:09 AM, Andrew Cooper wrote: >> On 01/07/15 19:09, Ed White wrote: >>> Signed-off-by: Ed White <edmund.h.wh...@intel.com> >> >> I am still very much unconvinced by the argument against having a single >> HVMOP_altp2m and a set of subops. do_domctl() and do_sysctl() are >> examples of a subop style hypercall with different XSM settings for >> different subops. >> >> Furthermore, factoring out a do_altp2m_op() handler would allow things >> like the hvm_altp2m_supported() check to be made common. Factoring >> further to having a named common header of a subop and a domid at the >> head of every subop structure would allow all the domain rcu locking to >> become common outside of the subop switch. >> > > How do we get to a binding decision on whether making this change is > a prerequisite for acceptance or not? Changing the HVMOP encoding > means fairly extensive changes to the code in hvm.c, and the XSM > patch, and the code Tamas has written. It also necessitates significant > changes to all the code we use to test the intra-domain protection > model.
I don't follow this argumentation about XSM at all: Various HVMOPs have different XSM handling anway (i.e. by far not all of them go through e.g. xsm_hvm_control()), and hence I don't even see the problem of passing the sub-op to a (new) XSM handler. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
