Re: [Xen-devel] [PATCH V2 1/2] x86/altp2m: Add hypercall to set a range of sve bits

[Jan Beulich <jbeulich@suse.com>]

On 12.11.2019 15:05, Tamas K Lengyel wrote:
> On Tue, Nov 12, 2019 at 4:54 AM Jan Beulich <jbeulich@suse.com> wrote:
>> On 06.11.2019 16:35, Alexandru Stefan ISAILA wrote:
>>> +        else
>>> +        {
>>> +            rc = p2m_set_suppress_ve_multi(d, &a.u.suppress_ve);
>>> +
>>> +            if ( rc == -ERESTART )
>>> +                if ( __copy_field_to_guest(guest_handle_cast(arg,
>>> +                                           xen_hvm_altp2m_op_t),
>>> +                                           &a, u.suppress_ve.opaque) )
>>> +                    rc = -EFAULT;
>>
>> If the operation is best effort, _some_ indication of failure should
>> still be handed back to the caller. Whether that's through the opaque
>> field or by some other means is secondary. If not via that field
>> (which would make the outer of the two if()-s disappear), please fold
>> the if()-s.
> 
> At least for mem_sharing_range_op we also do a best-effort and don't
> return an error for pages where it wasn't possible to share. So I
> don't think it's absolutely necessary to do that, especially if the
> caller can't do anything about those errors anyway.

mem-sharing is a little different in nature, isn't it? If you
can't share a page, both involved guests will continue to run
with their own instances. If you want to suppress #VE delivery
and it fails, behavior won't be transparently correct, as
there'll potentially be #VE when there should be none. Whether
that's benign to the guest very much depends on its handler.

Jan

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