|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/5] x86/hvm: Rework HVM_HCALL_invalidate handling
>>> On 13.02.17 at 18:01, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 13/02/17 16:49, Jan Beulich wrote:
>>>>> On 13.02.17 at 14:03, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> Sending an invalidation to the device model is an internal detail of
>>> completing the hypercall; callers should not need to be responsible for it.
>>> Drop HVM_HCALL_invalidate entirely and call send_invalidate_req() when
>>> appropriate.
>>>
>>> This makes the function boolean in nature, although the existing
>>> HVM_HCALL_{completed,preempted} to aid code clarity.
>> "are being retained" missing somewhere here?
>
> Yes. I already noticed and fixed that up. It now reads
>
> "This makes the function boolean in nature, although the existing
> HVM_HCALL_{completed,preempted} constants are kept to aid code clarity."
>
>>
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -3874,7 +3874,7 @@ static const hypercall_table_t hvm_hypercall_table[]
>>> =
>>> {
>>> #undef HYPERCALL
>>> #undef COMPAT_CALL
>>>
>>> -int hvm_do_hypercall(struct cpu_user_regs *regs)
>>> +bool hvm_hypercall(struct cpu_user_regs *regs)
>> I don't think bool is a particularly good choice when the callers can't
>> sensibly use the result without comparing with HVM_HCALL_*
>
> Ok. I will keep it as int.
With that
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |