On Thursday 22 May 2008 08:31:46 Jan Kiszka wrote:
> Avi Kivity wrote:
> > Jan Kiszka wrote:
> >> In order to allow the gdbstub of QEMU to push (soft) breakpoint handling
> >> completely into the gdb frontend, this patch enables guest exits also
> >> for #BP exceptions - in case guest debugging was turned on.
> >>
> >> Along this enhancement, this patch also fixes the flag manipulation for
> >> the singlestep mode.
> >>
> >
> > Suppose userspace determines the exception is due to a guest
> > breakpoint. How does it inject the debug exception?
>
> Good question. Is there no "inject exception #XX" mechanism in kvm yet?
>
> Will need this, as my current impression is that we better keep track of
> breakpoints at qemu level to tell guest soft-BPs apart from host
> injected ones. Would you suggest to add a separate IOCTL for exception
> injection then? Or should the new guest debug IOCTL contain a flag that
> signals "inject breakpoint trap" (both for guest soft-BP hits as well as
> guests already in single step mode)?
In addition to injecting debug interrupts, qemu should also be able to inject
machine checks, for the case of undecoded MMIO accesses.
As long as qemu can access the complete register state (e.g. including "reason
for machine check" registers), I don't think the injection interface *needs*
to be more complicated than "exception number".
OTOH, I can see the argument for atomic injection operations, so to support
that you'd end up with a sub-structure like kvm_exit, something like:
struct kvm_inject_arch {
u32 exception_type;
union {
struct machine_check {
u32 mcsr;
} mc;
struct debug {
} debug;
};
}
This stuff is completely arch-specific, so making a common "inject" ioctl
number that simply calls arch function (like GET_SREGS) would be appropriate.
--
Hollis Blanchard
IBM Linux Technology Center
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
