All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: Mihai Caraman <mihai.caraman@freescale.com>,
	kvm-ppc@vger.kernel.org, kvm@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 2/2] KVM: PPC: Book3E: Emulate MCSRR0/1 SPR and rfmci instruction
Date: Tue, 09 Jul 2013 18:29:22 +0000	[thread overview]
Message-ID: <1373394562.8183.197@snotra> (raw)
In-Reply-To: <51DC4C78.5080808@suse.de> (from agraf@suse.de on Tue Jul  9 12:46:32 2013)

On 07/09/2013 12:46:32 PM, Alexander Graf wrote:
> On 07/09/2013 07:16 PM, Scott Wood wrote:
>> On 07/08/2013 01:45:58 PM, Alexander Graf wrote:
>>> 
>>> On 03.07.2013, at 15:30, Mihai Caraman wrote:
>>> 
>>> > Some guests are making use of return from machine check  
>>> instruction
>>> > to do crazy things even though the 64-bit kernel doesn't handle  
>>> yet
>>> > this interrupt. Emulate MCSRR0/1 SPR and rfmci instruction  
>>> accordingly.
>>> >
>>> > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
>>> > ---
>>> > arch/powerpc/include/asm/kvm_host.h |    1 +
>>> > arch/powerpc/kvm/booke_emulate.c    |   25  
>>> +++++++++++++++++++++++++
>>> > arch/powerpc/kvm/timing.c           |    1 +
>>> > 3 files changed, 27 insertions(+), 0 deletions(-)
>>> >
>>> > diff --git a/arch/powerpc/include/asm/kvm_host.h  
>>> b/arch/powerpc/include/asm/kvm_host.h
>>> > index af326cd..0466789 100644
>>> > --- a/arch/powerpc/include/asm/kvm_host.h
>>> > +++ b/arch/powerpc/include/asm/kvm_host.h
>>> > @@ -148,6 +148,7 @@ enum kvm_exit_types {
>>> >     EMULATED_TLBWE_EXITS,
>>> >     EMULATED_RFI_EXITS,
>>> >     EMULATED_RFCI_EXITS,
>>> > +    EMULATED_RFMCI_EXITS,
>>> 
>>> I would quite frankly prefer to see us abandon the whole exit  
>>> timing framework in the kernel and instead use trace points. Then  
>>> we don't have to maintain all of this randomly exercised code.
>> 
>> Would this map well to tracepoints?  We're not trying to track  
>> discrete events, so much as accumulated time spent in different  
>> areas.
> 
> I think so. We'd just have to emit tracepoints as soon as we enter  
> handle_exit and in prepare_to_enter. Then a user space program should  
> have everything it needs to create statistics out of that. It would  
> certainly simplify the entry/exit path.

I was hoping that wasn't going to be your answer. :-)

Such a change would introduce a new dependency, more complexity, and  
the possibility for bad totals to result from a ring buffer filling  
faster than userspace can drain it.

I also don't see how it would simplify entry/exit, since we'd still  
need to take timestamps in the same places, in order to record a final  
event that says how long a particular event took.

-Scott

WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: Mihai Caraman <mihai.caraman@freescale.com>,
	linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
	kvm-ppc@vger.kernel.org
Subject: Re: [PATCH 2/2] KVM: PPC: Book3E: Emulate MCSRR0/1 SPR and rfmci instruction
Date: Tue, 9 Jul 2013 13:29:22 -0500	[thread overview]
Message-ID: <1373394562.8183.197@snotra> (raw)
In-Reply-To: <51DC4C78.5080808@suse.de> (from agraf@suse.de on Tue Jul  9 12:46:32 2013)

On 07/09/2013 12:46:32 PM, Alexander Graf wrote:
> On 07/09/2013 07:16 PM, Scott Wood wrote:
>> On 07/08/2013 01:45:58 PM, Alexander Graf wrote:
>>>=20
>>> On 03.07.2013, at 15:30, Mihai Caraman wrote:
>>>=20
>>> > Some guests are making use of return from machine check =20
>>> instruction
>>> > to do crazy things even though the 64-bit kernel doesn't handle =20
>>> yet
>>> > this interrupt. Emulate MCSRR0/1 SPR and rfmci instruction =20
>>> accordingly.
>>> >
>>> > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
>>> > ---
>>> > arch/powerpc/include/asm/kvm_host.h |    1 +
>>> > arch/powerpc/kvm/booke_emulate.c    |   25 =20
>>> +++++++++++++++++++++++++
>>> > arch/powerpc/kvm/timing.c           |    1 +
>>> > 3 files changed, 27 insertions(+), 0 deletions(-)
>>> >
>>> > diff --git a/arch/powerpc/include/asm/kvm_host.h =20
>>> b/arch/powerpc/include/asm/kvm_host.h
>>> > index af326cd..0466789 100644
>>> > --- a/arch/powerpc/include/asm/kvm_host.h
>>> > +++ b/arch/powerpc/include/asm/kvm_host.h
>>> > @@ -148,6 +148,7 @@ enum kvm_exit_types {
>>> >     EMULATED_TLBWE_EXITS,
>>> >     EMULATED_RFI_EXITS,
>>> >     EMULATED_RFCI_EXITS,
>>> > +    EMULATED_RFMCI_EXITS,
>>>=20
>>> I would quite frankly prefer to see us abandon the whole exit =20
>>> timing framework in the kernel and instead use trace points. Then =20
>>> we don't have to maintain all of this randomly exercised code.
>>=20
>> Would this map well to tracepoints?  We're not trying to track =20
>> discrete events, so much as accumulated time spent in different =20
>> areas.
>=20
> I think so. We'd just have to emit tracepoints as soon as we enter =20
> handle_exit and in prepare_to_enter. Then a user space program should =20
> have everything it needs to create statistics out of that. It would =20
> certainly simplify the entry/exit path.

I was hoping that wasn't going to be your answer. :-)

Such a change would introduce a new dependency, more complexity, and =20
the possibility for bad totals to result from a ring buffer filling =20
faster than userspace can drain it.

I also don't see how it would simplify entry/exit, since we'd still =20
need to take timestamps in the same places, in order to record a final =20
event that says how long a particular event took.

-Scott=

WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: Mihai Caraman <mihai.caraman@freescale.com>,
	<kvm-ppc@vger.kernel.org>, <kvm@vger.kernel.org>,
	<linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 2/2] KVM: PPC: Book3E: Emulate MCSRR0/1 SPR and rfmci instruction
Date: Tue, 9 Jul 2013 13:29:22 -0500	[thread overview]
Message-ID: <1373394562.8183.197@snotra> (raw)
In-Reply-To: <51DC4C78.5080808@suse.de> (from agraf@suse.de on Tue Jul  9 12:46:32 2013)

On 07/09/2013 12:46:32 PM, Alexander Graf wrote:
> On 07/09/2013 07:16 PM, Scott Wood wrote:
>> On 07/08/2013 01:45:58 PM, Alexander Graf wrote:
>>> 
>>> On 03.07.2013, at 15:30, Mihai Caraman wrote:
>>> 
>>> > Some guests are making use of return from machine check  
>>> instruction
>>> > to do crazy things even though the 64-bit kernel doesn't handle  
>>> yet
>>> > this interrupt. Emulate MCSRR0/1 SPR and rfmci instruction  
>>> accordingly.
>>> >
>>> > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
>>> > ---
>>> > arch/powerpc/include/asm/kvm_host.h |    1 +
>>> > arch/powerpc/kvm/booke_emulate.c    |   25  
>>> +++++++++++++++++++++++++
>>> > arch/powerpc/kvm/timing.c           |    1 +
>>> > 3 files changed, 27 insertions(+), 0 deletions(-)
>>> >
>>> > diff --git a/arch/powerpc/include/asm/kvm_host.h  
>>> b/arch/powerpc/include/asm/kvm_host.h
>>> > index af326cd..0466789 100644
>>> > --- a/arch/powerpc/include/asm/kvm_host.h
>>> > +++ b/arch/powerpc/include/asm/kvm_host.h
>>> > @@ -148,6 +148,7 @@ enum kvm_exit_types {
>>> >     EMULATED_TLBWE_EXITS,
>>> >     EMULATED_RFI_EXITS,
>>> >     EMULATED_RFCI_EXITS,
>>> > +    EMULATED_RFMCI_EXITS,
>>> 
>>> I would quite frankly prefer to see us abandon the whole exit  
>>> timing framework in the kernel and instead use trace points. Then  
>>> we don't have to maintain all of this randomly exercised code.
>> 
>> Would this map well to tracepoints?  We're not trying to track  
>> discrete events, so much as accumulated time spent in different  
>> areas.
> 
> I think so. We'd just have to emit tracepoints as soon as we enter  
> handle_exit and in prepare_to_enter. Then a user space program should  
> have everything it needs to create statistics out of that. It would  
> certainly simplify the entry/exit path.

I was hoping that wasn't going to be your answer. :-)

Such a change would introduce a new dependency, more complexity, and  
the possibility for bad totals to result from a ring buffer filling  
faster than userspace can drain it.

I also don't see how it would simplify entry/exit, since we'd still  
need to take timestamps in the same places, in order to record a final  
event that says how long a particular event took.

-Scott

  reply	other threads:[~2013-07-09 18:29 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-03 13:30 [PATCH 1/2] KVM: PPC: Fix kvm_exit_names array Mihai Caraman
2013-07-03 13:30 ` Mihai Caraman
2013-07-03 13:30 ` Mihai Caraman
2013-07-03 13:30 ` [PATCH 2/2] KVM: PPC: Book3E: Emulate MCSRR0/1 SPR and rfmci instruction Mihai Caraman
2013-07-03 13:30   ` Mihai Caraman
2013-07-03 13:30   ` Mihai Caraman
2013-07-08 18:45   ` Alexander Graf
2013-07-08 18:45     ` Alexander Graf
2013-07-08 18:45     ` Alexander Graf
2013-07-09 17:16     ` Scott Wood
2013-07-09 17:16       ` Scott Wood
2013-07-09 17:16       ` Scott Wood
2013-07-09 17:46       ` Alexander Graf
2013-07-09 17:46         ` Alexander Graf
2013-07-09 17:46         ` Alexander Graf
2013-07-09 18:29         ` Scott Wood [this message]
2013-07-09 18:29           ` Scott Wood
2013-07-09 18:29           ` Scott Wood
2013-07-09 21:49           ` Alexander Graf
2013-07-09 21:49             ` Alexander Graf
2013-07-09 21:49             ` Alexander Graf
2013-07-09 21:54             ` Scott Wood
2013-07-09 21:54               ` Scott Wood
2013-07-09 21:54               ` Scott Wood
2013-07-09 22:00               ` Alexander Graf
2013-07-09 22:00                 ` Alexander Graf
2013-07-09 22:00                 ` Alexander Graf
2013-07-09 22:26                 ` Scott Wood
2013-07-09 22:26                   ` Scott Wood
2013-07-09 22:26                   ` Scott Wood
2013-07-10  0:00                   ` Steven Rostedt
2013-07-10  0:00                     ` Steven Rostedt
2013-07-10  0:00                     ` Steven Rostedt
2013-07-10 10:23                   ` Alexander Graf
2013-07-10 10:23                     ` Alexander Graf
2013-07-10 10:23                     ` Alexander Graf
2013-07-10 18:24                     ` Scott Wood
2013-07-10 18:24                       ` Scott Wood
2013-07-10 18:24                       ` Scott Wood
2013-07-10 22:47                       ` Alexander Graf
2013-07-10 22:47                         ` Alexander Graf
2013-07-10 22:47                         ` Alexander Graf
2013-07-09 23:50                 ` Steven Rostedt
2013-07-09 23:50                   ` Steven Rostedt
2013-07-09 23:50                   ` Steven Rostedt
2013-07-08 18:39 ` [PATCH 1/2] KVM: PPC: Fix kvm_exit_names array Alexander Graf
2013-07-08 18:39   ` Alexander Graf
2013-07-08 18:39   ` 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=1373394562.8183.197@snotra \
    --to=scottwood@freescale.com \
    --cc=agraf@suse.de \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mihai.caraman@freescale.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.