[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 |