Re: [Xen-devel] [PATCH v3 11/13] x86/altp2m: define and implement alternate p2m HVMOP types.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.07.15 at 18:49, <edmund.h.white@xxxxxxxxx> 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.white@xxxxxxxxx>
>> 
>> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel