[PATCH 0/5] x86/pv: #DB vs %dr6 fixes, part 2

Andrew Cooper posted 5 patches 8 months, 2 weeks ago
Patches applied successfully (tree, apply log)
git fetch https://gitlab.com/xen-project/patchew/xen tags/patchew/20230912232113.402347-1-andrew.cooper3@citrix.com
There is a newer version of this series
xen/arch/x86/debug.c                   | 20 +++++++++++++++++
xen/arch/x86/include/asm/debugreg.h    |  7 ++++++
xen/arch/x86/include/asm/domain.h      | 12 ++++++++++
xen/arch/x86/include/asm/x86-defns.h   |  7 ++++++
xen/arch/x86/pv/emul-priv-op.c         | 31 +++++++++++++-------------
xen/arch/x86/pv/emulate.c              |  6 ++---
xen/arch/x86/pv/ro-page-fault.c        |  4 ++--
xen/arch/x86/pv/traps.c                | 17 ++++++++++----
xen/arch/x86/traps.c                   | 12 +++++-----
xen/arch/x86/x86_emulate/x86_emulate.c |  6 ++++-
xen/arch/x86/x86_emulate/x86_emulate.h | 22 ++++++++++++++----
11 files changed, 109 insertions(+), 35 deletions(-)
[PATCH 0/5] x86/pv: #DB vs %dr6 fixes, part 2
Posted by Andrew Cooper 8 months, 2 weeks ago
Slightly RFC.  This is the next chunk of debug fixes from the bug that Jinoh
reported.

I've decided to tackle PV guests alone to simplify the problem (No
introspection, get some of the core changes in place).

Patch 5 is still a bit chunky to follow, but I can't see any way to simplify
it without transiently breaking something.

Patchs 1 and 3 are entirely new, relative to previous postings of this work.
Others are rebased/shuffled.

There are still bugs/misfeatures:

 1) Data breakpoints during emulation (copy to/from guest) are accounted
    against Xen and not given back to the guest.
 2) Instruction breakpoints aren't calculated for FEP; CPUID.  This may not
    matter, but like everything in PV, it's undocumented and unclear if it's
    intended behaviour or not.

that can be left to some other future to fix.

Andrew Cooper (5):
  x86/pv: Fix the determiniation of whether to inject #DB
  x86: Introduce x86_merge_dr6()
  x86/emul: Add a pending_dbg field to x86_emulate_ctxt.retire
  x86/pv: Drop priv_op_ctxt.bpmatch and use pending_dbg instead
  x86/pv: Rewrite %dr6 handling

 xen/arch/x86/debug.c                   | 20 +++++++++++++++++
 xen/arch/x86/include/asm/debugreg.h    |  7 ++++++
 xen/arch/x86/include/asm/domain.h      | 12 ++++++++++
 xen/arch/x86/include/asm/x86-defns.h   |  7 ++++++
 xen/arch/x86/pv/emul-priv-op.c         | 31 +++++++++++++-------------
 xen/arch/x86/pv/emulate.c              |  6 ++---
 xen/arch/x86/pv/ro-page-fault.c        |  4 ++--
 xen/arch/x86/pv/traps.c                | 17 ++++++++++----
 xen/arch/x86/traps.c                   | 12 +++++-----
 xen/arch/x86/x86_emulate/x86_emulate.c |  6 ++++-
 xen/arch/x86/x86_emulate/x86_emulate.h | 22 ++++++++++++++----
 11 files changed, 109 insertions(+), 35 deletions(-)

-- 
2.30.2
Re: [PATCH 0/5] x86/pv: #DB vs %dr6 fixes, part 2
Posted by Andrew Cooper 8 months, 1 week ago
On 13/09/2023 12:21 am, Andrew Cooper wrote:
> Slightly RFC.  This is the next chunk of debug fixes from the bug that Jinoh
> reported.

I was trying to do a bit of due diligence before posting v2, and have
made some discoveries.

pv/emul-priv-op SingleStep vs Branch Step
  https://gitlab.com/xen-project/xen/-/work_items/170

HVM IO Breakpoints:
  https://gitlab.com/xen-project/xen/-/work_items/171


A third which I'm on the fence about is about PV guests and General
Detect.  We firmly prohibit PV guests from setting DR7.GD, but we them
play with the DR6.GD bit as if it had been asserted.

It would be easy to put GD back into the set of reserved bits for DR6,
but it also wouldn't be hard to handle GD via dr7_emul and let the PV
guest have a more-normal looking set of debug functionality.

Thoughts?

~Andrew

Re: [PATCH 0/5] x86/pv: #DB vs %dr6 fixes, part 2
Posted by Jan Beulich 8 months, 1 week ago
On 15.09.2023 21:56, Andrew Cooper wrote:
> A third which I'm on the fence about is about PV guests and General
> Detect.  We firmly prohibit PV guests from setting DR7.GD, but we them
> play with the DR6.GD bit as if it had been asserted.
> 
> It would be easy to put GD back into the set of reserved bits for DR6,
> but it also wouldn't be hard to handle GD via dr7_emul and let the PV
> guest have a more-normal looking set of debug functionality.

Anything "more-normal looking" is to be preferred, I would say. As long
as, like you say here, it isn't overly hard.

Jan