[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 2/6] x86/debugger: separate Xen and guest debugging debugger_trap_* functions


  • To: Jan Beulich <jbeulich@xxxxxxxx>, Bobby Eshleman <bobby.eshleman@xxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Tue, 24 Aug 2021 13:41:52 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tE78tg92dfnp6QQGPRGJ8r8VD9pevASCWFLZPe1xwq0=; b=hAVnaa6eqqaePaFvA72DJxB+nj31ubbmNKKicEv88kuZVCZzNidoxqwfF1ro6GIVWcJ2CqZFmx8q+/yV6yYeJJfaxd9ioAnFntJ8odH6/Sy3Fn7pY0wMUnTadXZY8qhTBYJVXs6EtoOt6asfLvSCoUMJ+PdYDETGsv4qTAIyWMh2+rChQtSK+ZDdLnmk7bPP5K5COW1Pl8y/hZ1PUVOMix+wkS9BqkbUsbEoSQtrL8yWoQdHGKAe7dpxvQ9CFYA00p1UgSVkITBmGo0Gd0VJBJkhFQtH1L84nbZdUn3ZV2/3ROej68vjMPR3DZRBRZ+FZwdjGkfrib+BTfws24HxUg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SOLYGdSs1OLLHEVDXjhlEd3U+SiBy3i9NMB136aW52kw0orKKuSdX8NVX4UlDRDLQiSUEIKxTyiFPOUacT/RRU1VnAGYmXju8dQNgAdj6IBsXcmQLf6me7j6LNSCHzNQGQOB4uEhl2XxRI4I7+YUQYNlN6wftnL5qR5VO+8l9OIKwjZdDrcoUhfdO1sk2RbvrLs32NJtWgTRFohiBH7nsfJbBmlo3+nRh4GvC83MDa89M0mpHaMcj36TkmOL9CM1W8ljkuGOrcSWLJUCbxllAaUbGabJ9EcdqJtvd60ZjUCmk0i7xJ9CmYjw5bAUIV+EBuxYrloi8dPj18n10NNYtg==
  • Authentication-results: esa4.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Elena Ufimtseva <elena.ufimtseva@xxxxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 24 Aug 2021 12:42:21 +0000
  • Ironport-hdrordr: A9a23:2o77X6zPCyNQuUX0J6r7KrPxq+skLtp133Aq2lEZdPULSKKlfp GV88jziyWZtN9wYhEdcdDpAtjlfZquz+8K3WB3B8bcYOCGghrVEGgG1+rfKlLbalbDH4JmpM Fdmu1FeaDN5DtB/LXHCWuDYq4dKbC8mcjC74qurAYOPHRXguNbnmBE426gYz1LrWJ9dOME/f Snl696TnabCA4qhpPRPAh1YwGPnayLqHqgCiR2TiIP2U2rt3eF+bT6Gx+X0lM3VC5O+64r9S zgnxbi7quunvmnwluEvlWjrKh+qZ/E8J9uFcaMgs8aJnHFjRupXp1oX/mnsCouqO+ixV42mJ 3nogsmPe5093TNF1vF4SfF6k3F6nID+nXiwViXjT/KptH4fiszD457iYdQYnLimgYdleA59J gO83OStpJRAx+Ftj/6/cL0WxZjkVfxiWY+kMYI5kYvFbc2Wft0l8gy7UlVGJAPEGbR84Y8Ct RjC8na+bJ/bU6aVXbEpWNiqebcG0jbJi32BHTqh/bligS/xBtCvhMlLY0k7zU9HasGOt55D7 +uCNUyqFkmJfVmH56UB486MIaK4yL2MEjx2M/7GyWuKEg9AQO7l3fA2sR+2AibQu198HIMou W2bLp5jx98R6u8M7zB4HV0miq9C1lVGw6dl/1j2w==
  • Ironport-sdr: kP8G5EXDlkW903ZAzoT9UtcAXQqAaq+fYyQDpXNaaCNxVGrUbqey5EROi53r01P+iZ6PClXhQ8 nBBStGXaNUvD5sU+E+okt6OG1i9Wb6f/eQ3qo/fxlkekLRrkQ0xn3m0e07U0iqI66Cs5dBKRrW 6q1thU87TRF6YyZWvWGZdi0+WF5WlaQwc/geFNfpW8b5IiJv+t2dmtQGuDL3Hp59WI9GqY4Rvn FKXLUMSaYDwXyU+5zTITmpKDDXSgcYDpWXXtM1py/FR2xrUU+zXRYcD+3fD2m6eYbZQSzJU6cm 6B4J8OwJFjsHqkww+Tyr3H61
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 24/08/2021 13:16, Jan Beulich wrote:
> On 18.08.2021 22:29, Bobby Eshleman wrote:
>> Unlike debugger_trap_fatal() and debugger_trap_immediate(),
>> debugger_trap_entry() is specific to guest debugging and *NOT* the
>> debugging of Xen itself. That is, it is part of gdbsx functionality and
>> not the Xen gdstub. This is evidenced by debugger_trap_fatal()'s usage
>> of domain_pause_for_debugger(). Because of this, debugger_trap_entry()
>> does not belong alongside the generic Xen debugger functionality.
> I'm not convinced this is what the original intentions were. Instead I
> think this was meant to be a generic hook function which initially
> only cared to deal with the gdbsx needs.

It doesn't exactly matter what the original intentions where - what we
currently have is unused and and a clear source of confusion between two
unrelated subsystems.

It is unclear that the gdbstub is even usable, given at least a decade
of bitrot.

Keeping an empty static inline in the enabled case is nonsense, because
at the point you need to edit Xen to insert some real debugging, there
are better ways to do it in something which isn't even a catch-all
despite appearing to be one.

~Andrew




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.