From: Alexander Graf <agraf@suse.de>
To: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org, 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 13:31:22 +0200 [thread overview]
Message-ID: <53A0270A.1070401@suse.de> (raw)
In-Reply-To: <53A0248D.7070909@linux.vnet.ibm.com>
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
next prev parent reply other threads:[~2014-06-17 11:31 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
2014-06-17 11:20 ` Madhavan Srinivasan
2014-06-17 11:31 ` Alexander Graf [this message]
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=53A0270A.1070401@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).