Re: [Xen-devel] [PATCH v3] x86/altp2m: Add a new hypercall to get the active altp2m index

[Jan Beulich <JBeulich@xxxxxxxx>]

On 22.07.2019 14:39, Alexandru Stefan ISAILA wrote:
> Ping,
> 
> Any reviews on this patch are appreciated.

FAOD I think I've provided all the feedback I have. The patch doesn't
seem to have a tool stack maintainer ack yet, and I think I had made
clear previously that I'm willing to look at changes to do_altp2m_op(),
but that I'm not willing to ack new additions to this interface as long
as it's (optionally or not) exposed to guests. It effectively being
part of altp2m, strictly speaking it shouldn't be a general x86
maintainer ack that's needed here anyway. As a hint - it certainly
would help if the function was moved suitably.

Jan

> On 07.06.2019 14:50, Jan Beulich wrote:
>>>>> On 07.06.19 at 12:55, <aisaila@xxxxxxxxxxxxxxx> wrote:
>>> @@ -4735,6 +4736,28 @@ static int do_altp2m_op(
>>>                        _gfn(a.u.change_gfn.old_gfn),
>>>                        _gfn(a.u.change_gfn.new_gfn));
>>>            break;
>>> +
>>> +    case HVMOP_altp2m_get_p2m_idx:
>>> +    {
>>> +        struct vcpu *v;
>>> +
>>> +        if ( !altp2m_active(d) )
>>> +        {
>>> +            rc = -EOPNOTSUPP;
>>> +            break;
>>> +        }
>>> +
>>> +        if ( (v = domain_vcpu(d, a.u.get_vcpu_p2m_idx.vcpu_id)) == NULL )
>>> +        {
>>> +            rc = -EINVAL;
>>> +            break;
>>> +        }
>>
>> The order of return values was the other way around before, but
>> I suppose this doesn't matter much?
>>
>>> +        a.u.get_vcpu_p2m_idx.altp2m_idx = altp2m_vcpu_idx(v);
>>> +        rc = __copy_to_guest(arg, &a, 1) ? -EFAULT : 0;
>>
>> Just as remark for the future (I didn't pay attention before,
>> and the difference isn't overly meaningful for operations that
>> don't occur frequently) - __copy_field_to_guest() would be
>> less overhead here. Oh, right - this is once again not possible
>> because of arg (still) being a handle of void.
>>
>> Jan
>>
>>
>>
>> ________________________
>> This email was scanned by Bitdefender
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel