Re: [Xen-devel] [BUGFIX][PATCH 4/4] XEN_DOMCTL_gdbsx_guestmemio: always do the copyback.

[Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>]

On Tue, 7 Jan 2014 10:00:24 +0000
Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:

> On Mon, 2014-01-06 at 17:53 -0800, Mukesh Rathor wrote:
> > On Sat,  4 Jan 2014 12:52:16 -0500
> > Don Slutz <dslutz@xxxxxxxxxxx> 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 <dslutz@xxxxxxxxxxx>
> > > ---
> > >  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;
> > >      }
> > >      break;
> > >  
> > 
> > Ooopsy... my thought was that an application should not even look at
> > remain if the hcall/syscall failed, but forgot when writing the
> > gdbsx itself :). Think of it this way, if the call didn't even make
> > it to xen, and some reason the ioctl returned non-zero rc, then
> > remain would still be zero. So I think we should fix gdbsx instead
> > of here:
> > 
> > xg_write_mem():
> >     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);
> 
> Isn't this still using iop->remain on failure which is what you say
> shouldn't be done?

Right, it was just a guidline code with bad cut and paste of XGERR()..
so picky :) :)... 

Mukesh

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