On 17.06.14 13:20, Madhavan Srinivasan wrote:
On Tuesday 17 June 2014 03:13 PM, Alexander Graf wrote:
On 17.06.14 11:32, Benjamin Herrenschmidt wrote:
On Tue, 2014-06-17 at 11:25 +0200, Alexander Graf wrote:
On 17.06.14 11:22, Benjamin Herrenschmidt wrote:
On Tue, 2014-06-17 at 10:54 +0200, Alexander Graf wrote:
Also, why don't we use twi always or something else that actually is
defined as illegal instruction? I would like to see this shared with
book3s_32 PR.
twi will be directed to the guest on HV no ? We want a real illegal
because those go to the host (for potential emulation by the HV).
Ah, good point. I guess we need different one for PR and HV then to
ensure compatibility with older ISAs on PR.
Well, we also need to be careful with what happens if a PR guest puts
that instruction in, do that stop its HV guest/host ?
What if it's done in userspace ? Do that stop the kernel ? :-)
The way SW breakpointing is handled is that when we see one, it gets
deflected into user space. User space then has an array of breakpoints
it configured itself. If the breakpoint is part of that list, it
consumes it. If not, it injects a debug interrupt (program in this case)
into the guest.
That way we can overlay that one instruction with as many layers as we
like :). We only get a performance hit on execution of that instruction.
Maddy, I haven't checked, does your patch ensure that we only ever stop
if the instruction is at a recorded bkpt address ? It still means that a
userspace process can practically DOS its kernel by issuing a lot of
these causing a crapload of exits.
Only user space knows about its breakpoint addresses, so we have to
deflect. However since time still ticks on, we only increase jitter of
the guest. The process would still get scheduled away after the same
^^^ Where is this taken care. I am still trying to understand. Kindly
can you explain or point to the code. Will help.
We tell the guest via VPA about its steal time which includes QEMU time.
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
