Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

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

 




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 ;).


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.


The second problem I see is that we're disabling use cases for the sake
of correctness. When I use gdbstub, I usually don't want anything in the
way of debugging something - like if I want to debug the guest debugging
itself for example.
I don't have a problem with making it possible for userspace to forcibly
claim ownership of the debug registers -- but I don't want to advertise
that won't mess up the guest debugging that you're trying to debug,
without some reason to believe that.

It will mes up guest debugging, but only up to the extent that's necessary. We can even try to find unused breakpoint registers before we start killing guest ones.


So overall, I think the x86 approach is a nice middle ground between
usability, performance and functionality.
You mean don't document anything other than the mechanism to get/set the
registers and hope everything works out? :-)

There's certainly some lack of documentation here ;). Otherwise we probably wouldn't have this conversation :).


one reg?
We are using SREGS but if required we can use one_reg.
I thought we were preferring one reg over sregs for new functionality.
I'm personally torn on this one. The problem here is that the sregs
fields and values are already reserved. For anything we don't have an
API for yet, yes, one_reg only. IIUC we have the API here, but were
lacking the implementation.
  From a QEMU perspective, are we going to want to update this at the same
time as everything else, or would jumping through sregs hoops be a
nuisance?  Is the long term goal to have one reg support for everything?
Because we need to maintain backwards compatibility, I don't think we'll
actually have any benefit from one reg support for everything.
We don't need to maintain backwards compatibility with interfaces that
were never implemented, and even where we do need to maintain
compatibility, that doesn't mean the caller needs to use the old,
cumbersome interface (don't assume the caller is QEMU, or that all new
features of QEMU need to support old kernels).

Yes, that's why I'm torn for this particular case. I thought you were asking about the general line of thinking. In this concrete case I think the only thing we get from using SREGS over ONE_REG is that we don't have to wait for the patches to trickle into kvm-next to be able to apply the QEMU patches ;).

From an esthetic point of view, I would prefer ONE_REG too.


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?


Alex

--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [KVM Development]     [KVM ARM]     [KVM ia64]     [Linux Virtualization]     [Linux USB Devel]     [Linux Video]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux