From: Alex Bennée <hidden> Date: 2015-05-15 14:27:41
Currently x86, powerpc and soon arm64 use the same two architecture
specific bits for guest debug support for software and hardware
breakpoints. This makes the shared values explicit.
Signed-off-by: Alex Bennée <redacted>
Reviewed-by: Andrew Jones <redacted>
-
v4
- claim more bits for the common functionality
v5
- don't use __ mechanism to move values common
=20
This is an ABI break for s390, no?
=20
David, do you remember why we do not use KVM_GUESTDBG_USE_SW_BP?
=20
We never had to tell the kernel about software breakpoints as this is all
handled via 4 byte DIAG instructions until now. We don't have to turn this
mechanism on. QEMU can directly insert the desired DIAG instructions and ge=
ts
notified when they are about to get executed.
(But we still have 2 byte breakpoint support todo - still tbd how exactly t=
his
will be realized - could be turned on via such a mechanism)
The problem is, that these bits are arch specific, now Alex wants to unify
them for all archs.
So yes, this is an ABI break for us and breaks hardware breakpoints.(I think
the first version of this patch didn't contain this ABI break when I had a =
look)
I wonder if it wouldn't make more sense to
- introduce new bits in the arch-unspecific section
- rework the existing implementers to accept both bits
Or to simply leave stuff as it is and handle it via arch specific bits.
David
This is an ABI break for s390, no?
David, do you remember why we do not use KVM_GUESTDBG_USE_SW_BP?
We never had to tell the kernel about software breakpoints as this is all
handled via 4 byte DIAG instructions until now. We don't have to turn this
mechanism on. QEMU can directly insert the desired DIAG instructions and gets
notified when they are about to get executed.
(But we still have 2 byte breakpoint support todo - still tbd how exactly this
will be realized - could be turned on via such a mechanism)
The problem is, that these bits are arch specific, now Alex wants to unify
them for all archs.
So yes, this is an ABI break for us and breaks hardware breakpoints.(I think
the first version of this patch didn't contain this ABI break when I had a look)
I wonder if it wouldn't make more sense to
- introduce new bits in the arch-unspecific section
- rework the existing implementers to accept both bits
Or to simply leave stuff as it is and handle it via arch specific bits.
With one arch proving the "all need this" theory wrong, just drop this
patch. Even quicker when it breaks an ABI.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux