From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [BUGFIX][PATCH 4/4] XEN_DOMCTL_gdbsx_guestmemio: always do the copyback. Date: Sun, 5 Jan 2014 23:35:24 +0000 Message-ID: <52C9EC3C.2060008@citrix.com> References: <1388857936-664-1-git-send-email-dslutz@verizon.com> <1388857936-664-5-git-send-email-dslutz@verizon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1388857936-664-5-git-send-email-dslutz@verizon.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Don Slutz , xen-devel@lists.xen.org Cc: Keir Fraser , Ian Campbell , Stefano Stabellini , George Dunlap , Ian Jackson , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 04/01/2014 17:52, Don Slutz wrote: > The gdbsx code expects that domctl->u.gdbsx_guest_memio.remain is > returned. > > 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 > > Signed-off-by: Don Slutz > --- > xen/arch/x86/domctl.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c > index ef6c140..4aa751f 100644 > --- a/xen/arch/x86/domctl.c > +++ b/xen/arch/x86/domctl.c > @@ -997,8 +997,7 @@ long arch_do_domctl( > domctl->u.gdbsx_guest_memio.len; > > ret = gdbsx_guest_mem_io(domctl->domain, &domctl->u.gdbsx_guest_memio); > - if ( !ret ) > - copyback = 1; > + copyback = 1; This whole hypercall implementation looks suspect. gdbsx_guest_mem_io() itself writes to the 'remain' field, making the statement crossing the top of this context redundant. Furthermore, ret is strictly 0 in the case that 'remain' is 0, or -EFAULT if 'remain' is non-0. While this does change the ABI of a hypercall, I think it is reasonable to do, as domctl.h does imply that 'remain' is an output parameter, without specifying anything about its behaviour in the case of an error. ~Andrew