From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [BUGFIX][PATCH 0/4] gdbsx: fix 3 bugs Date: Mon, 6 Jan 2014 15:45:48 +0000 Message-ID: <1389023148.31766.64.camel@kazak.uk.xensource.com> References: <1388857936-664-1-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-1-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 Cc: Keir Fraser , Stefano Stabellini , George Dunlap , Ian Jackson , xen-devel@lists.xen.org, Jan Beulich List-Id: xen-devel@lists.xenproject.org On Sat, 2014-01-04 at 12:52 -0500, Don Slutz wrote: > Release manager requests: > patch 1 should be in 4.4.0 > patch 3 and 4 would be good to be in 4.4.0 (as acting RM in George's absence): In all three cases what is missing is the "why" and the appropriate analysis from http://wiki.xen.org/wiki/Xen_Roadmap/4.4#Exception_guidelines_for_after_the_code_freeze i.e. what is the impact of the bug (i..e what are the advantages of the fix) and what are the risks of this changing causing further breakage? I'm not really in a position to evaluate the risk of a change in gdbsx, so someone needs to tell me. I think given that gdbsx is a somewhat "peripheral" bit of code and that it is targeted at developers (who might be better able to tolerate any resulting issues and more able to apply subsequent fixups than regular users) we can accept a larger risk than we would with a change to the hypervisor itself etc (that's assuming that all of these changes cannot potentially impact non-debugger usecases which I expect is the case from the function names but I would like to see confirmed). Apart from a release ack 4 of these would need an Ack from Mukesh IMHO. TBH if he is happy with them then I see no reason not to give a release ack as well. > patch 2 is optional. > > While tracking down a bug in seabios/grub I found the bug in patch > 1. > > There are 2 ways that gfn will not be INVALID_GFN and yet mfn will > be INVALID_MFN. > > 1) p2m_is_readonly(gfntype) and writing memory. > 2) the requested vaddr does not exist. > > This may only be an issue for a HVM guest that is in real mode > (I.E. no page tables). > > Patch 2 is debug logging that was used to find the 2nd way. > > Patch 3 and 4 are more of a cleanup bug fix. > > Don Slutz (4): > dbg_rw_guest_mem: need to call put_gfn in error path. > dbg_rw_guest_mem: Enable debug log output > xg_read_mem: Report on error. > XEN_DOMCTL_gdbsx_guestmemio: always do the copyback. > > tools/debugger/gdbsx/xg/xg_main.c | 6 ++++-- > xen/arch/x86/debug.c | 44 ++++++++++++++++++++++++++++++--------- > xen/arch/x86/domctl.c | 3 +-- > 3 files changed, 39 insertions(+), 14 deletions(-) >