From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Paul Mackerras <paulus@samba.org>
Cc: agraf@suse.de, benh@kernel.crashing.org,
linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org,
kvm@vger.kernel.org
Subject: Re: [RFC PATCH 02/10] KVM: PPC: BOOK3S: PR: Emulate virtual timebase register
Date: Fri, 31 Jan 2014 10:57:52 +0000 [thread overview]
Message-ID: <87vbx0ju5a.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140130054913.GA10611@iris.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> On Tue, Jan 28, 2014 at 10:14:07PM +0530, Aneesh Kumar K.V wrote:
>> virtual time base register is a per vm register and need to saved
>> and restored on vm exit and entry. Writing to VTB is not allowed
>> in the privileged mode.
> ...
>
>> +#ifdef CONFIG_PPC_BOOK3S_64
>> +#define mfvtb() ({unsigned long rval; \
>> + asm volatile("mfspr %0, %1" : \
>> + "=r" (rval) : "i" (SPRN_VTB)); rval;})
>
> The mfspr will be a no-op on anything before POWER8, meaning the
> result will be whatever value was in the destination GPR before the
> mfspr. I suppose that may not matter if the result is only ever used
> when we're running on a POWER8 host, but I would feel more comfortable
> if we had explicit feature tests to make sure of that, rather than
> possibly doing computations with unpredictable values.
>
> With your patch, a guest on a POWER7 or a PPC970 could do a read from
> VTB and get garbage -- first, there is nothing to stop userspace from
> requesting POWER8 emulation on an older machine, and secondly, even if
> the virtual machine is a PPC970 (say) you don't implement
> unimplemented SPR semantics for VTB (no-op if PR=0, illegal
> instruction interrupt if PR=1).
Ok that means we need to do something like ?
struct cpu_spec *s = find_cpuspec(vcpu->arch.pvr);
if (s->cpu_features & CPU_FTR_ARCH_207S) {
}
>
> On the whole I think it is reasonable to reject an attempt to set the
> virtual PVR to a POWER8 PVR value if we are not running on a POWER8
> host, because emulating all the new POWER8 features in software
> (particularly transactional memory) would not be feasible. Alex may
> disagree. :)
That would make it much simpler.
-aneesh
WARNING: multiple messages have this Message-ID (diff)
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org, agraf@suse.de,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [RFC PATCH 02/10] KVM: PPC: BOOK3S: PR: Emulate virtual timebase register
Date: Fri, 31 Jan 2014 16:27:37 +0530 [thread overview]
Message-ID: <87vbx0ju5a.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140130054913.GA10611@iris.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> On Tue, Jan 28, 2014 at 10:14:07PM +0530, Aneesh Kumar K.V wrote:
>> virtual time base register is a per vm register and need to saved
>> and restored on vm exit and entry. Writing to VTB is not allowed
>> in the privileged mode.
> ...
>
>> +#ifdef CONFIG_PPC_BOOK3S_64
>> +#define mfvtb() ({unsigned long rval; \
>> + asm volatile("mfspr %0, %1" : \
>> + "=r" (rval) : "i" (SPRN_VTB)); rval;})
>
> The mfspr will be a no-op on anything before POWER8, meaning the
> result will be whatever value was in the destination GPR before the
> mfspr. I suppose that may not matter if the result is only ever used
> when we're running on a POWER8 host, but I would feel more comfortable
> if we had explicit feature tests to make sure of that, rather than
> possibly doing computations with unpredictable values.
>
> With your patch, a guest on a POWER7 or a PPC970 could do a read from
> VTB and get garbage -- first, there is nothing to stop userspace from
> requesting POWER8 emulation on an older machine, and secondly, even if
> the virtual machine is a PPC970 (say) you don't implement
> unimplemented SPR semantics for VTB (no-op if PR=0, illegal
> instruction interrupt if PR=1).
Ok that means we need to do something like ?
struct cpu_spec *s = find_cpuspec(vcpu->arch.pvr);
if (s->cpu_features & CPU_FTR_ARCH_207S) {
}
>
> On the whole I think it is reasonable to reject an attempt to set the
> virtual PVR to a POWER8 PVR value if we are not running on a POWER8
> host, because emulating all the new POWER8 features in software
> (particularly transactional memory) would not be feasible. Alex may
> disagree. :)
That would make it much simpler.
-aneesh
WARNING: multiple messages have this Message-ID (diff)
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Paul Mackerras <paulus@samba.org>
Cc: agraf@suse.de, benh@kernel.crashing.org,
linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org,
kvm@vger.kernel.org
Subject: Re: [RFC PATCH 02/10] KVM: PPC: BOOK3S: PR: Emulate virtual timebase register
Date: Fri, 31 Jan 2014 16:27:37 +0530 [thread overview]
Message-ID: <87vbx0ju5a.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140130054913.GA10611@iris.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> On Tue, Jan 28, 2014 at 10:14:07PM +0530, Aneesh Kumar K.V wrote:
>> virtual time base register is a per vm register and need to saved
>> and restored on vm exit and entry. Writing to VTB is not allowed
>> in the privileged mode.
> ...
>
>> +#ifdef CONFIG_PPC_BOOK3S_64
>> +#define mfvtb() ({unsigned long rval; \
>> + asm volatile("mfspr %0, %1" : \
>> + "=r" (rval) : "i" (SPRN_VTB)); rval;})
>
> The mfspr will be a no-op on anything before POWER8, meaning the
> result will be whatever value was in the destination GPR before the
> mfspr. I suppose that may not matter if the result is only ever used
> when we're running on a POWER8 host, but I would feel more comfortable
> if we had explicit feature tests to make sure of that, rather than
> possibly doing computations with unpredictable values.
>
> With your patch, a guest on a POWER7 or a PPC970 could do a read from
> VTB and get garbage -- first, there is nothing to stop userspace from
> requesting POWER8 emulation on an older machine, and secondly, even if
> the virtual machine is a PPC970 (say) you don't implement
> unimplemented SPR semantics for VTB (no-op if PR=0, illegal
> instruction interrupt if PR=1).
Ok that means we need to do something like ?
struct cpu_spec *s = find_cpuspec(vcpu->arch.pvr);
if (s->cpu_features & CPU_FTR_ARCH_207S) {
}
>
> On the whole I think it is reasonable to reject an attempt to set the
> virtual PVR to a POWER8 PVR value if we are not running on a POWER8
> host, because emulating all the new POWER8 features in software
> (particularly transactional memory) would not be feasible. Alex may
> disagree. :)
That would make it much simpler.
-aneesh
next prev parent reply other threads:[~2014-01-31 10:57 UTC|newest]
Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-28 16:44 [RFC PATCH 01/10] KVM: PPC: BOOK3S: PR: Add POWER8 support Aneesh Kumar K.V
2014-01-28 16:56 ` Aneesh Kumar K.V
2014-01-28 16:44 ` Aneesh Kumar K.V
2014-01-28 16:44 ` [RFC PATCH 01/10] KVM: PPC: BOOK3S: PR: Fix PURR and SPURR emulation Aneesh Kumar K.V
2014-01-28 16:56 ` Aneesh Kumar K.V
2014-01-28 16:44 ` Aneesh Kumar K.V
2014-01-29 16:32 ` Alexander Graf
2014-01-29 16:32 ` Alexander Graf
2014-01-29 16:32 ` Alexander Graf
2014-01-31 10:38 ` Aneesh Kumar K.V
2014-01-31 10:50 ` Aneesh Kumar K.V
2014-01-31 10:38 ` Aneesh Kumar K.V
2014-01-31 10:47 ` Alexander Graf
2014-01-31 10:47 ` Alexander Graf
2014-01-31 10:47 ` Alexander Graf
2014-01-31 22:17 ` Paul Mackerras
2014-01-31 22:17 ` Paul Mackerras
2014-01-31 22:17 ` Paul Mackerras
2014-02-05 9:15 ` Alexander Graf
2014-02-05 9:15 ` Alexander Graf
2014-02-05 9:15 ` Alexander Graf
2014-01-28 16:44 ` [RFC PATCH 02/10] KVM: PPC: BOOK3S: PR: Emulate virtual timebase register Aneesh Kumar K.V
2014-01-28 16:56 ` Aneesh Kumar K.V
2014-01-28 16:44 ` Aneesh Kumar K.V
2014-01-29 16:39 ` Alexander Graf
2014-01-29 16:39 ` Alexander Graf
2014-01-29 16:39 ` Alexander Graf
2014-01-29 22:54 ` Benjamin Herrenschmidt
2014-01-29 22:54 ` Benjamin Herrenschmidt
2014-01-29 22:54 ` Benjamin Herrenschmidt
2014-01-30 0:35 ` Benjamin Herrenschmidt
2014-01-30 0:35 ` Benjamin Herrenschmidt
2014-01-30 0:35 ` Benjamin Herrenschmidt
2014-01-30 5:49 ` Paul Mackerras
2014-01-30 5:49 ` Paul Mackerras
2014-01-30 5:49 ` Paul Mackerras
2014-01-30 10:04 ` Alexander Graf
2014-01-30 10:04 ` Alexander Graf
2014-01-30 10:04 ` Alexander Graf
2014-01-31 10:57 ` Aneesh Kumar K.V [this message]
2014-01-31 10:57 ` Aneesh Kumar K.V
2014-01-31 10:57 ` Aneesh Kumar K.V
2014-01-28 16:44 ` [RFC PATCH 03/10] KVM: PPC: BOOK3S: PR: Emulate instruction counter Aneesh Kumar K.V
2014-01-28 16:56 ` Aneesh Kumar K.V
2014-01-28 16:44 ` Aneesh Kumar K.V
2014-01-29 16:40 ` Alexander Graf
2014-01-29 16:40 ` Alexander Graf
2014-01-29 16:40 ` Alexander Graf
2014-01-31 11:25 ` Aneesh Kumar K.V
2014-01-31 11:37 ` Aneesh Kumar K.V
2014-01-31 11:25 ` Aneesh Kumar K.V
2014-01-31 11:28 ` Alexander Graf
2014-01-31 11:28 ` Alexander Graf
2014-01-31 11:28 ` Alexander Graf
2014-01-28 16:44 ` [RFC PATCH 04/10] KVM: PPC: BOOK3S: PR: Emulate Thread identification register Aneesh Kumar K.V
2014-01-28 16:56 ` Aneesh Kumar K.V
2014-01-28 16:44 ` Aneesh Kumar K.V
2014-01-28 16:44 ` [RFC PATCH 05/10] KVM: PPC: BOOK3S: PR: Doorbell support Aneesh Kumar K.V
2014-01-28 16:56 ` Aneesh Kumar K.V
2014-01-28 16:44 ` Aneesh Kumar K.V
2014-01-28 16:44 ` [RFC PATCH 06/10] KVM: PPC: BOOK3S: PR: Emulate DPDES register Aneesh Kumar K.V
2014-01-28 16:56 ` Aneesh Kumar K.V
2014-01-28 16:44 ` Aneesh Kumar K.V
2014-01-28 16:44 ` [RFC PATCH 07/10] KVM: PPC: BOOK3S: PR: Emulate facility status and control register Aneesh Kumar K.V
2014-01-28 16:56 ` Aneesh Kumar K.V
2014-01-28 16:44 ` Aneesh Kumar K.V
2014-01-29 17:11 ` Alexander Graf
2014-01-29 17:11 ` Alexander Graf
2014-01-29 17:11 ` Alexander Graf
2014-01-30 6:00 ` Paul Mackerras
2014-01-30 6:00 ` Paul Mackerras
2014-01-30 6:00 ` Paul Mackerras
2014-01-30 10:02 ` Alexander Graf
2014-01-30 10:02 ` Alexander Graf
2014-01-30 10:02 ` Alexander Graf
2014-01-31 11:28 ` Aneesh Kumar K.V
2014-01-31 11:40 ` Aneesh Kumar K.V
2014-01-31 11:28 ` Aneesh Kumar K.V
2014-01-28 16:44 ` [RFC PATCH 08/10] KVM: PPC: BOOK3S: PR: Add support for facility unavailable interrupt Aneesh Kumar K.V
2014-01-28 16:56 ` Aneesh Kumar K.V
2014-01-28 16:44 ` Aneesh Kumar K.V
2014-01-29 17:35 ` Alexander Graf
2014-01-29 17:35 ` Alexander Graf
2014-01-29 17:35 ` Alexander Graf
2014-01-31 11:40 ` Aneesh Kumar K.V
2014-01-31 11:52 ` Aneesh Kumar K.V
2014-01-31 11:40 ` Aneesh Kumar K.V
2014-01-31 12:02 ` Alexander Graf
2014-01-31 12:02 ` Alexander Graf
2014-01-31 12:02 ` Alexander Graf
2014-01-28 16:44 ` [RFC PATCH 09/10] KVM: PPC: BOOK3S: PR: Ignore write to monitor mode control register Aneesh Kumar K.V
2014-01-28 16:56 ` Aneesh Kumar K.V
2014-01-28 16:44 ` Aneesh Kumar K.V
2014-01-28 16:44 ` [RFC PATCH 10/10] PPC: BOOK3S: Disable/Enable TM looking at the ibm, pa-features device tree entry Aneesh Kumar K.V
2014-01-28 16:56 ` [RFC PATCH 10/10] PPC: BOOK3S: Disable/Enable TM looking at the ibm,pa-features " Aneesh Kumar K.V
2014-01-28 16:44 ` Aneesh Kumar K.V
2014-01-29 17:37 ` [RFC PATCH 10/10] PPC: BOOK3S: Disable/Enable TM looking at the ibm,pa-features device tree entr Alexander Graf
2014-01-29 17:37 ` [RFC PATCH 10/10] PPC: BOOK3S: Disable/Enable TM looking at the ibm,pa-features device tree entry Alexander Graf
2014-01-29 17:37 ` 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=87vbx0ju5a.fsf@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=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=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 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.