linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan <maddy@linux.vnet.ibm.com>,
	paulus@samba.org, kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH] powerpc/kvm: support to handle sw breakpoint
Date: Tue, 17 Jun 2014 11:43:20 +0200	[thread overview]
Message-ID: <53A00DB8.4030207@suse.de> (raw)
In-Reply-To: <1402997541.7661.128.camel@pasglop>


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 
amount of real time, no?


Alex

  reply	other threads:[~2014-06-17  9:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-14 21:08 [PATCH] powerpc/kvm: support to handle sw breakpoint Madhavan Srinivasan
2014-06-17  8:54 ` Alexander Graf
2014-06-17  9:22   ` Benjamin Herrenschmidt
2014-06-17  9:25     ` Alexander Graf
2014-06-17  9:32       ` Benjamin Herrenschmidt
2014-06-17  9:43         ` Alexander Graf [this message]
2014-06-17 11:20           ` Madhavan Srinivasan
2014-06-17 11:31             ` Alexander Graf
2014-06-17 10:51         ` Madhavan Srinivasan
2014-06-17 11:07   ` Madhavan Srinivasan
2014-06-17 11:08     ` Alexander Graf
2014-06-17 11:13       ` Madhavan Srinivasan
2014-06-17 14:42         ` Alexander Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53A00DB8.4030207@suse.de \
    --to=agraf@suse.de \
    --cc=benh@kernel.crashing.org \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.vnet.ibm.com \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).