All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: Caraman Mihai Claudiu-B02008 <B02008@freescale.com>,
	"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support
Date: Wed, 03 Jul 2013 18:36:15 +0000	[thread overview]
Message-ID: <1372876575.8183.137@snotra> (raw)
In-Reply-To: <098F899F-54BF-4172-958B-C52C015F5142@suse.de> (from agraf@suse.de on Wed Jul  3 12:07:30 2013)

On 07/03/2013 12:07:30 PM, Alexander Graf wrote:
> 
> On 03.07.2013, at 18:49, Caraman Mihai Claudiu-B02008 wrote:
> 
> >>>> Do we need to do this even when the guest doesn't use Altivec?  
> Can't
> >> we
> >>>> just load it on demand then once we fault? This code path really
> >> should
> >>>> only be a prefetch enable when MSR_VEC is already set in guest
> >> context.
> >>>
> >>> No we can't, read 6/6.
> >>
> >> So we have to make sure we're completely unlazy when it comes to a  
> KVM
> >> guest. Are we?
> >
> > Yes, because MSR[SPV] is under its control.
> 
> Oh, sure, KVM wants it unlazy. That part is obvious. But does the  
> kernel always give us unlazyness? The way I read the code, process.c  
> goes lazy when !CONFIG_SMP.
> 
> So the big question is why we're manually enforcing FPU giveup, but  
> not Altivec giveup? One of the 2 probably is wrong :).

Why do you think we're not enforcing it for Altivec?  Is there some  
specific piece of code you're referring to that is different in this  
regard?

-Scott

WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: Caraman Mihai Claudiu-B02008 <B02008@freescale.com>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>
Subject: Re: [PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support
Date: Wed, 3 Jul 2013 13:36:15 -0500	[thread overview]
Message-ID: <1372876575.8183.137@snotra> (raw)
In-Reply-To: <098F899F-54BF-4172-958B-C52C015F5142@suse.de> (from agraf@suse.de on Wed Jul  3 12:07:30 2013)

On 07/03/2013 12:07:30 PM, Alexander Graf wrote:
>=20
> On 03.07.2013, at 18:49, Caraman Mihai Claudiu-B02008 wrote:
>=20
> >>>> Do we need to do this even when the guest doesn't use Altivec? =20
> Can't
> >> we
> >>>> just load it on demand then once we fault? This code path really
> >> should
> >>>> only be a prefetch enable when MSR_VEC is already set in guest
> >> context.
> >>>
> >>> No we can't, read 6/6.
> >>
> >> So we have to make sure we're completely unlazy when it comes to a =20
> KVM
> >> guest. Are we?
> >
> > Yes, because MSR[SPV] is under its control.
>=20
> Oh, sure, KVM wants it unlazy. That part is obvious. But does the =20
> kernel always give us unlazyness? The way I read the code, process.c =20
> goes lazy when !CONFIG_SMP.
>=20
> So the big question is why we're manually enforcing FPU giveup, but =20
> not Altivec giveup? One of the 2 probably is wrong :).

Why do you think we're not enforcing it for Altivec?  Is there some =20
specific piece of code you're referring to that is different in this =20
regard?

-Scott=

WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: Caraman Mihai Claudiu-B02008 <B02008@freescale.com>,
	"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support
Date: Wed, 3 Jul 2013 13:36:15 -0500	[thread overview]
Message-ID: <1372876575.8183.137@snotra> (raw)
In-Reply-To: <098F899F-54BF-4172-958B-C52C015F5142@suse.de> (from agraf@suse.de on Wed Jul  3 12:07:30 2013)

On 07/03/2013 12:07:30 PM, Alexander Graf wrote:
> 
> On 03.07.2013, at 18:49, Caraman Mihai Claudiu-B02008 wrote:
> 
> >>>> Do we need to do this even when the guest doesn't use Altivec?  
> Can't
> >> we
> >>>> just load it on demand then once we fault? This code path really
> >> should
> >>>> only be a prefetch enable when MSR_VEC is already set in guest
> >> context.
> >>>
> >>> No we can't, read 6/6.
> >>
> >> So we have to make sure we're completely unlazy when it comes to a  
> KVM
> >> guest. Are we?
> >
> > Yes, because MSR[SPV] is under its control.
> 
> Oh, sure, KVM wants it unlazy. That part is obvious. But does the  
> kernel always give us unlazyness? The way I read the code, process.c  
> goes lazy when !CONFIG_SMP.
> 
> So the big question is why we're manually enforcing FPU giveup, but  
> not Altivec giveup? One of the 2 probably is wrong :).

Why do you think we're not enforcing it for Altivec?  Is there some  
specific piece of code you're referring to that is different in this  
regard?

-Scott

  reply	other threads:[~2013-07-03 18:36 UTC|newest]

Thread overview: 111+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-03 12:42 [PATCH 0/6] KVM: PPC: Book3E: AltiVec support Mihai Caraman
2013-07-03 12:42 ` Mihai Caraman
2013-07-03 12:42 ` Mihai Caraman
2013-07-03 12:42 ` [PATCH 1/6] KVM: PPC: Book3E: Use common defines for SPE/FP/AltiVec int numbers Mihai Caraman
2013-07-03 12:42   ` Mihai Caraman
2013-07-03 12:42   ` Mihai Caraman
2013-07-03 12:42 ` [PATCH 2/6] KVM: PPC: Book3E: Refactor SPE/FP exit handling Mihai Caraman
2013-07-03 12:42   ` Mihai Caraman
2013-07-03 12:42   ` Mihai Caraman
2013-07-03 13:30   ` Alexander Graf
2013-07-03 13:30     ` Alexander Graf
2013-07-03 13:30     ` Alexander Graf
2013-07-03 13:53     ` Caraman Mihai Claudiu-B02008
2013-07-03 13:53       ` Caraman Mihai Claudiu-B02008
2013-07-03 13:53       ` Caraman Mihai Claudiu-B02008
2013-07-03 15:13       ` Alexander Graf
2013-07-03 15:13         ` Alexander Graf
2013-07-03 15:13         ` Alexander Graf
2013-07-03 18:28         ` Scott Wood
2013-07-03 18:28           ` Scott Wood
2013-07-03 18:28           ` Scott Wood
2013-07-03 18:42           ` Alexander Graf
2013-07-03 18:42             ` Alexander Graf
2013-07-03 18:42             ` Alexander Graf
2013-07-03 18:44             ` Scott Wood
2013-07-03 18:44               ` Scott Wood
2013-07-03 18:44               ` Scott Wood
2013-07-03 12:42 ` [PATCH 3/6] KVM: PPC: Book3E: Increase FPU laziness Mihai Caraman
2013-07-03 12:42   ` Mihai Caraman
2013-07-03 12:42   ` Mihai Caraman
2013-07-03 13:45   ` Alexander Graf
2013-07-03 13:45     ` Alexander Graf
2013-07-03 13:45     ` Alexander Graf
2013-07-03 13:55     ` Caraman Mihai Claudiu-B02008
2013-07-03 13:55       ` Caraman Mihai Claudiu-B02008
2013-07-03 13:55       ` Caraman Mihai Claudiu-B02008
2013-07-03 15:11       ` Alexander Graf
2013-07-03 15:11         ` Alexander Graf
2013-07-03 15:11         ` Alexander Graf
2013-07-03 15:41         ` Caraman Mihai Claudiu-B02008
2013-07-03 15:41           ` Caraman Mihai Claudiu-B02008
2013-07-03 15:41           ` Caraman Mihai Claudiu-B02008
2013-07-03 16:59           ` Alexander Graf
2013-07-03 16:59             ` Alexander Graf
2013-07-03 16:59             ` Alexander Graf
2013-07-03 17:17             ` Scott Wood
2013-07-03 17:17               ` Scott Wood
2013-07-03 17:17               ` Scott Wood
2013-07-03 17:22               ` Alexander Graf
2013-07-03 17:22                 ` Alexander Graf
2013-07-03 17:22                 ` Alexander Graf
2013-07-03 17:07         ` Scott Wood
2013-07-03 17:07           ` Scott Wood
2013-07-03 17:07           ` Scott Wood
2013-07-03 17:08           ` Alexander Graf
2013-07-03 17:08             ` Alexander Graf
2013-07-03 17:08             ` Alexander Graf
2013-07-03 17:18   ` Scott Wood
2013-07-03 17:18     ` Scott Wood
2013-07-03 17:18     ` Scott Wood
2013-07-03 17:23     ` Alexander Graf
2013-07-03 17:23       ` Alexander Graf
2013-07-03 17:23       ` Alexander Graf
2013-07-03 17:44       ` Scott Wood
2013-07-03 17:44         ` Scott Wood
2013-07-03 17:44         ` Scott Wood
2013-07-03 18:39         ` Alexander Graf
2013-07-03 18:39           ` Alexander Graf
2013-07-03 18:39           ` Alexander Graf
2013-07-03 18:37   ` Scott Wood
2013-07-03 18:37     ` Scott Wood
2013-07-03 18:37     ` Scott Wood
2013-07-03 18:40     ` Alexander Graf
2013-07-03 18:40       ` Alexander Graf
2013-07-03 18:40       ` Alexander Graf
2013-07-04  6:50       ` Caraman Mihai Claudiu-B02008
2013-07-04  6:50         ` Caraman Mihai Claudiu-B02008
2013-07-04  6:50         ` Caraman Mihai Claudiu-B02008
2013-07-03 12:42 ` [PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support Mihai Caraman
2013-07-03 12:42   ` Mihai Caraman
2013-07-03 12:42   ` Mihai Caraman
2013-07-03 15:17   ` Alexander Graf
2013-07-03 15:17     ` Alexander Graf
2013-07-03 15:17     ` Alexander Graf
2013-07-03 16:09     ` Caraman Mihai Claudiu-B02008
2013-07-03 16:09       ` Caraman Mihai Claudiu-B02008
2013-07-03 16:09       ` Caraman Mihai Claudiu-B02008
2013-07-03 16:43       ` Alexander Graf
2013-07-03 16:43         ` Alexander Graf
2013-07-03 16:43         ` Alexander Graf
2013-07-03 16:49         ` Caraman Mihai Claudiu-B02008
2013-07-03 16:49           ` Caraman Mihai Claudiu-B02008
2013-07-03 16:49           ` Caraman Mihai Claudiu-B02008
2013-07-03 17:07           ` Alexander Graf
2013-07-03 17:07             ` Alexander Graf
2013-07-03 17:07             ` Alexander Graf
2013-07-03 18:36             ` Scott Wood [this message]
2013-07-03 18:36               ` Scott Wood
2013-07-03 18:36               ` Scott Wood
2013-07-03 18:45               ` Alexander Graf
2013-07-03 18:45                 ` Alexander Graf
2013-07-03 18:45                 ` Alexander Graf
2013-07-03 18:38   ` Scott Wood
2013-07-03 18:38     ` Scott Wood
2013-07-03 18:38     ` Scott Wood
2013-07-03 12:42 ` [PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG " Mihai Caraman
2013-07-03 12:42   ` Mihai Caraman
2013-07-03 12:42   ` Mihai Caraman
2013-07-03 12:42 ` [PATCH 6/6] KVM: PPC: Book3E: Enable e6500 core Mihai Caraman
2013-07-03 12:42   ` Mihai Caraman
2013-07-03 12:42   ` Mihai Caraman

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=1372876575.8183.137@snotra \
    --to=scottwood@freescale.com \
    --cc=B02008@freescale.com \
    --cc=agraf@suse.de \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.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 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.