From: Don Slutz <dslutz@verizon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Don Slutz <dslutz@verizon.com>
Cc: Keir Fraser <keir@xen.org>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
George Dunlap <george.dunlap@eu.citrix.com>,
Ian Jackson <ian.jackson@eu.citrix.com>,
xen-devel@lists.xen.org, Jan Beulich <jbeulich@suse.com>
Subject: Re: [BUGFIX][PATCH v2 5/5] xg_main: If XEN_DOMCTL_gdbsx_guestmemio fails then force error.
Date: Wed, 08 Jan 2014 09:39:32 -0500 [thread overview]
Message-ID: <52CD6324.9020908@terremark.com> (raw)
In-Reply-To: <1389177355.4883.8.camel@kazak.uk.xensource.com>
On 01/08/14 05:35, Ian Campbell wrote:
> On Tue, 2014-01-07 at 19:25 -0500, Don Slutz wrote:
>> Without this gdb does not report an error.
>>
>> With this patch and using a 1G hvm domU:
>>
>> (gdb) x/1xh 0x6ae9168b
>> 0x6ae9168b: Cannot access memory at address 0x6ae9168b
>>
>> Drop output of iop->remain because it most likely will be zero.
>> This leads to a strange message:
>>
>> ERROR: failed to read 0 bytes. errno:14 rc:-1
>>
>> Add address to write error because it may be the only message
>> displayed.
>>
>> Note: currently XEN_DOMCTL_gdbsx_guestmemio does not change 'iop' on
>> error and so iop->remain will be zero.
>>
>> Signed-off-by: Don Slutz <dslutz@verizon.com>
>> ---
>> tools/debugger/gdbsx/xg/xg_main.c | 13 +++++++++----
>> 1 file changed, 9 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/debugger/gdbsx/xg/xg_main.c b/tools/debugger/gdbsx/xg/xg_main.c
>> index 3b2a285..0fc3f82 100644
>> --- a/tools/debugger/gdbsx/xg/xg_main.c
>> +++ b/tools/debugger/gdbsx/xg/xg_main.c
>> @@ -787,8 +787,10 @@ xg_read_mem(uint64_t guestva, char *tobuf, int tobuf_len, uint64_t pgd3val)
>> iop->gwr = 0; /* not writing to guest */
>>
>> if ( (rc = _domctl_hcall(XEN_DOMCTL_gdbsx_guestmemio, tobuf, tobuf_len)) )
>> - XGTRC("ERROR: failed to read %d bytes. errno:%d rc:%d\n",
>> - iop->remain, errno, rc);
>> + {
>> + XGTRC("ERROR: failed to read bytes. errno:%d rc:%d\n", errno, rc);
> Is it worth printing the expect number (i.e. the input) of bytes? Is
> that buflen here?
Not in my testing. If I turn on debug output (-d), I get:
...
process_remote_request:E:m8957006a,1 curvcpu:0
xg_read_mem:E:gva:8957006a tobuf:1c81020 len:1
ERROR:xg_read_mem:ERROR: failed to read bytes. errno:14 rc:-1
xg_read_mem:X:remain:0 buf8:0x24
process_m_request:Failed read mem. addr:0x8957006a len:1 remn:1 errno:14
process_remote_request:X:E01 curvcpu:0
...
Which outputs the length (1) a few times already. The expected number here is tobuf_len.
>> + return tobuf_len;
>> + }
>>
>> for(i=0; i < XGMIN(8, tobuf_len); u.buf8[i]=tobuf[i], i++);
>> XGTRC("X:remain:%d buf8:0x%llx\n", iop->remain, u.llbuf8);
>> @@ -818,8 +820,11 @@ xg_write_mem(uint64_t guestva, char *frombuf, int buflen, uint64_t pgd3val)
>> iop->gwr = 1; /* writing to guest */
>>
>> if ((rc=_domctl_hcall(XEN_DOMCTL_gdbsx_guestmemio, frombuf, buflen)))
>> - XGERR("ERROR: failed to write %d bytes. errno:%d rc:%d\n",
>> - iop->remain, errno, rc);
>> + {
>> + XGERR("ERROR: failed to write bytes to %llx. errno:%d rc:%d\n",
>> + guestva, errno, rc);
> Same here.
Since this error message is output without other context, it might help. Most of the time, the user knows the write size requested. Since this code has an ACK from Mukesh, I lean to not making a change, but if you want it, I will.
-Don Slutz
>> + return buflen;
>> + }
>> return iop->remain;
>> }
>>
>
next prev parent reply other threads:[~2014-01-08 14:39 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-08 0:25 [BUGFIX][PATCH v2 0/5] gdbsx: fix 3 bugs Don Slutz
2014-01-08 0:25 ` [PATCH v2 1/5] Add Emacs local variables to source files Don Slutz
2014-01-08 1:16 ` Mukesh Rathor
2014-01-08 1:27 ` Andrew Cooper
2014-01-08 9:51 ` Ian Campbell
2014-01-08 15:58 ` Ian Campbell
2014-01-08 0:25 ` [BUGFIX][PATCH v2 2/5] dbg_rw_guest_mem: need to call put_gfn in error path Don Slutz
2014-01-08 0:55 ` Andrew Cooper
2014-01-08 1:06 ` Don Slutz
2014-01-08 1:15 ` Andrew Cooper
2014-01-08 1:14 ` Mukesh Rathor
2014-01-08 1:44 ` Mukesh Rathor
2014-01-08 2:30 ` Andrew Cooper
2014-01-08 2:44 ` Mukesh Rathor
2014-01-08 10:40 ` Ian Campbell
2014-01-08 14:01 ` Don Slutz
2014-01-08 8:36 ` Jan Beulich
2014-01-08 13:48 ` Don Slutz
2014-01-08 0:25 ` [PATCH v2 3/5] dbg_rw_guest_mem: Conditionally enable debug log output Don Slutz
2014-01-08 1:38 ` Mukesh Rathor
2014-01-08 10:38 ` Ian Campbell
2014-01-08 14:28 ` Don Slutz
2014-01-08 16:47 ` Ian Campbell
2014-01-08 17:04 ` Tim Deegan
2014-01-08 17:44 ` Ian Campbell
2014-01-08 18:10 ` Tim Deegan
2014-01-09 8:41 ` Ian Campbell
2014-01-09 10:32 ` Tim Deegan
2014-01-09 0:38 ` Mukesh Rathor
2014-01-09 9:59 ` Ian Campbell
2014-01-09 16:08 ` Don Slutz
2014-01-09 16:30 ` Jan Beulich
2014-01-09 17:56 ` Don Slutz
2014-01-10 17:13 ` Ian Campbell
2014-01-10 21:15 ` Don Slutz
2014-01-10 22:08 ` [PATCH v3 " Don Slutz
2014-01-10 1:54 ` [PATCH v2 " Mukesh Rathor
2014-01-08 0:25 ` [BUGFIX][PATCH v2 4/5] xg_read_mem: Report on error Don Slutz
2014-01-08 1:16 ` Mukesh Rathor
2014-01-08 0:25 ` [BUGFIX][PATCH v2 5/5] xg_main: If XEN_DOMCTL_gdbsx_guestmemio fails then force error Don Slutz
2014-01-08 1:11 ` Mukesh Rathor
2014-01-08 10:35 ` Ian Campbell
2014-01-08 14:39 ` Don Slutz [this message]
2014-01-08 8:28 ` [BUGFIX][PATCH v2 0/5] gdbsx: fix 3 bugs Jan Beulich
2014-01-08 14:43 ` Don Slutz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52CD6324.9020908@terremark.com \
--to=dslutz@verizon.com \
--cc=Ian.Campbell@citrix.com \
--cc=george.dunlap@eu.citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.