From mboxrd@z Thu Jan  1 00:00:00 1970
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
Subject: Re: [PATCH v2 2/7] xen/x86: merge 2 hvm_event_...
 functions into 1
Date: Wed, 10 Feb 2016 19:28:37 +0200
Message-ID: <56BB7345.3030703@bitdefender.com>
References: <1455119259-2161-1-git-send-email-czuzu@bitdefender.com>
	<1455119433-2308-1-git-send-email-czuzu@bitdefender.com>
	<56BB710302000078000D0B05@prv-mh.provo.novell.com>
	<56BB6D92.3050300@bitdefender.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <56BB6D92.3050300@bitdefender.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Corneliu ZUZU <czuzu@bitdefender.com>, Jan Beulich <JBeulich@suse.com>
Cc: Kevin Tian <kevin.tian@intel.com>, Tamas K Lengyel <tamas@tklengyel.com>, Keir Fraser <keir@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org, Jun Nakajima <jun.nakajima@intel.com>
List-Id: xen-devel@lists.xenproject.org

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?


Thanks,
Razvan