On 02.07.14 19:28, Bharat.Bhushan@xxxxxxxxxxxxx wrote:
-----Original Message-----
From: Bhushan Bharat-R65777
Sent: Wednesday, July 02, 2014 5:07 PM
To: Wood Scott-B07421; Alexander Graf
Cc: kvm-ppc@xxxxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx
Subject: RE: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
guest
-----Original Message-----
From: Wood Scott-B07421
Sent: Tuesday, July 01, 2014 10:11 PM
To: Alexander Graf
Cc: Bhushan Bharat-R65777; kvm-ppc@xxxxxxxxxxxxxxx;
kvm@xxxxxxxxxxxxxxx
Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt
injection to guest
On Tue, 2014-07-01 at 18:22 +0200, Alexander Graf wrote:
On 01.07.14 17:35, Scott Wood wrote:
On Tue, 2014-07-01 at 17:04 +0200, Alexander Graf wrote:
On 01.07.14 16:58, Scott Wood wrote:
On Tue, 2014-07-01 at 08:23 +0200, Alexander Graf wrote:
I don't think QEMU should be aware of these limitations.
OK, but we should at least have some idea of how the whole thing
is supposed to work, in order to determine if this is the
correct behavior for QEMU. I thought the model was that debug
resources are either owned by QEMU or by the guest, and in the
latter case, QEMU would never see the debug exception to begin with.
That's bad for a number of reasons. For starters it's different
from how
x86 handles debug registers - and I hate to be different just for
the sake of being different.
How does it work on x86?
It overwrites more-or-less random breakpoints with its own ones, but
leaves the others intact ;).
Are you talking about software breakpoints or management of hardware
debug registers?
So if we do want to declare that debug registers are owned by
either QEMU or the guest, we should change the semantics for all
architectures.
If we want to say that ownership of the registers is shared, we
need a plan for how that would actually work.
I think you're overengineering here :). When do people actually use
gdbstub? Usually when they want to debug a broken guest. We can
either
* overengineer heavily and reduce the number of registers
available to the guest to always have spares
* overengineer a bit and turn off guest debugging completely when
we use gdbstub
* just leave as much alive as we can, hoping that it helps with
the debugging
Option 3 is what x86 does - and I think it's a reasonable approach.
This is not an interface that needs to be 100% consistent and bullet
proof, it's a best effort to enable you to debug as much as possible.
I'm not insisting on 100% -- just hoping for some
explanation/discussion about how it's intended to work for the cases where it
can.
How will MSR[DE] and MSRP[DEP] be handled?
How would I go about telling QEMU/KVM that I don't want this shared
mode, because I don't want guest to interfere with the debugging I'm
trying to do from QEMU?
Will guest accesses to debug registers cause a userspace exit when
guest_debug is enabled?
I think we're in a path that is slow enough already to not worry
about performance.
It's not just about performance, but simplicity of use, and
consistency of API.
Oh, and it looks like there already exist one reg definitions and
implementations for most of the debug registers.
For BookE? Where?
arch/powerpc/kvm/booke.c: KVM_REG_PPC_IACn, KVM_REG_PPC_DACn
I tried to quickly prototype what I think we want to do (this is not tested)
Hi Scott,
There is one problem which is stopping us to share debug resource between qemu and guest, looking for suggestions:
- As qemu is also using debug resource, We have to set MSR_DE and set MSRP_DEP (guest will not be able to clear MSR_DE). So qemu set debug events will always cause the debug interrupts.
- Now guest is also using debug resources and for some reason if guest wants to clear MSR_DE (disable debug interrupt) But it will not be able to disable as MSRP_DEP is set and KVM will not come to know guest willingness to disable MSR_DE.
- If the debug interrupts occurs then we will exit to QEMU and this may not a QEMU set event so it will inject interrupt to guest (using one-reg or set-sregs)
- Now KVM, when handling one-reg/sregs request to inject debug interrupt, do not know whether guest can handle the debug interrupt or not (as guest might have tried to set/clear MSR_DE).
Yeah, and with this everything falls apart. I guess we can't share
hardware debug resources after all then. So yes, let's declare all
hardware debug facilities QEMU owned as soon as QEMU starts using gdbstub.
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
