>From: Jan Beulich [mailto:[email protected]]
>Sent: Thursday, July 23, 2015 3:22 AM
>
>>>> On 23.07.15 at 01:01, <[email protected]> wrote:
>> Signed-off-by: Ed White <[email protected]>
>>
>> Acked-by: Jan Beulich <[email protected]>
>
>And I have to withdraw this ack pending clarification of (and perhaps
>adjustment to) the #VE info address interface.
>
Could we have the ack back :-) I clarified the #VE info address interface in
the other email - repeating here:
" If the "EPT-violation #VE" VM-execution control is 1, the
virtualization-exception information address must
satisfy the following checks:
- Bits 11:0 of the address must be 0.
- The address must not set any bits beyond the processor's physical-address
width."
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -6138,6 +6138,140 @@ static int hvmop_get_param(
>> return rc;
>> }
>>
>> +static int do_altp2m_op(
>> + XEN_GUEST_HANDLE_PARAM(void) arg) {
>> + struct xen_hvm_altp2m_op a;
>> + struct domain *d = NULL;
>> + int rc = 0;
>> +
>> + if ( !hvm_altp2m_supported() )
>> + return -EOPNOTSUPP;
>> +
>> + if ( copy_from_guest(&a, arg, 1) )
>> + return -EFAULT;
>> +
>> + if ( a.pad1 || a.pad2 ||
>> + (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) ||
>> + (a.cmd < HVMOP_altp2m_get_domain_state) ||
>> + (a.cmd > HVMOP_altp2m_change_gfn) )
>
>I'm afraid such a change invalidates any earlier ack, even if ti is correct.
>Instead
>of this, why don't you start numbering of the sub-ops at zero? Or if you really
>have a reason to start at 1, why not simply check a.cmd against zero (without
>using any particular sub-op value)? And then it escapes me why this can't be
>handled in a default case in the switch statement below anyway.
Hmm - is that a requirement per se? we are consistently checking per the sub-op
definition we have.
Would like this to be considered as is.
As I said in the cover letter we have constraints on how much more we can do
this week now -
so requesting the maintainers to accept v7 with the review comments you have on
those recorded as pending to be addressed by us.
Thanks much!
Ravi
>
>Jan
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel
