[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 2/7] xen/x86: merge 2 hvm_event_... functions into 1





On Wed, Feb 10, 2016 at 10:28 AM, Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> wrote:
On 02/10/2016 07:04 PM, Corneliu ZUZU wrote:
>>> @@ -27,9 +33,8 @@ bool_t hvm_event_cr(unsigned int index, unsigned
>>> long value,
>>>Â Â#define hvm_event_crX(what, new, old) \
>>>Â Â Â Âhvm_event_cr(VM_EVENT_X86_##what, new, old)
>>>Â Âvoid hvm_event_msr(unsigned int msr, uint64_t value);
>>> -/* Called for current VCPU: returns -1 if no listener */
>>> -int hvm_event_int3(unsigned long rip);
>>> -int hvm_event_single_step(unsigned long rip);
>>> +int hvm_event_breakpoint(unsigned long rip,
>>> +Â Â Â Â Â Â Â Â Â Â Â Â Âenum hvm_event_breakpoint_type type);
>> I guess the comment was here for a reason, and this reason doesn't
>> go away with this code folding. But I'll leave it to the VM event code
>> maintainers to judge.
>>
>> Jan
>
> That comment seemed & still seems wrong to me, I don't see any code
> paths out of which that function would return -1.

That seems to be true. Those functions return whatever hvm_event_traps()
returns, which is 0 on success, 1 (maybe the minus is a typo?) if
there's no ring, or whatever value vm_event_claim_slot() returns.
Vm_event_claim_slot()'s documentation says that it can only return 0 (on
success), -ENOSYS or -EBUSY, none of which translate to -1 (and the code
seems to agree with that claim).

Maybe I'm missing some macro wizardry here, but I don't think so - it
looks like the comment is stale. Tamas, maybe you remember more, should
those functions return -1 if no listener is present?

It could very well be that it's just a comment that was forgotten and is out-of-date. I don't see any issue removing it if it's actually misleading (as it seems to be).

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.