Re: linux-next: tree build failure
Rusty's version of BUILD_BUG_ON() does indeed fix the build break, and
also exposes the bug in kvmppc_account_exit_stat(). So to recap:
original: built but didn't work
Jan's: doesn't build
Rusty's: builds and works
Where do you want to go from here?
--
Hollis Blanchard
IBM Linux Technology Center
On Mon, 2009-10-05 at 07:58 +0100, Jan Beulich wrote:
Hollis Blanchard holl...@us.ibm.com 02.10.09 17:48
On Wed, 2009-09-30 at 07:35 +0100, Jan Beulich wrote:
The one Rusty suggested the other day may help here. I don't like it
as a drop-in replacement for BUILD_BUG_ON() though (due to it
deferring the error generated to the linking stage), I'd rather view
this as an improvement to MAYBE_BUILD_BUG_ON() (which should
then be used here).
Can you be more specific?
I have no idea what Rusty suggested where. I can't even guess what
I'm attaching Rusty's response I was referring to.
MAYBE_BUILD_BUG_ON() is supposed to do (sounds like a terrible name).
Agreed - but presumably better than just deleting the bogus instances
altogether...
Jan
email message attachment
Forwarded Message
From: Rusty Russell ru...@rustcorp.com.au
To: Jan Beulich jbeul...@novell.com
Cc: linux-ker...@vger.kernel.org
Subject: Re: [PATCH] fix BUILD_BUG_ON() and a couple of bogus uses
of it
Date: Wed, 23 Sep 2009 10:27:00 +0930
On Wed, 19 Aug 2009 01:29:25 am Jan Beulich wrote:
gcc permitting variable length arrays makes the current construct
used for BUILD_BUG_ON() useless, as that doesn't produce any diagnostic
if the controlling expression isn't really constant. Instead, this
patch makes it so that a bit field gets used here. Consequently, those
uses where the condition isn't really constant now also need fixing.
Note that in the gfp.h, kmemcheck.h, and virtio_config.h cases
MAYBE_BUILD_BUG_ON() really just serves documentation purposes - even
if the expression is compile time constant (__builtin_constant_p()
yields true), the array is still deemed of variable length by gcc, and
hence the whole expression doesn't have the intended effect.
Signed-off-by: Jan Beulich jbeul...@novell.com
We used to use an undefined symbol here; diagnostics are worse but it
catches
more stuff.
Perhaps a hybrid is the way to go?
#ifndef __OPTIMIZE__
#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
#else
/* If it's a constant, catch it at compile time, otherwise at link time. */
extern int __build_bug_on_failed;
#define BUILD_BUG_ON(condition) \
do {\
((void)sizeof(char[1 - 2*!!(condition)])); \
if (condition) __build_bug_on_failed = 1; \
} while(0)
#endif
Thanks,
Rusty.
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/27] Add mfdec emulation
On Tue, 2009-09-29 at 10:18 +0200, Alexander Graf wrote:
We support setting the DEC to a certain value right now. Doing that basically
triggers the CPU local timer.
But there's also an mfdec command that enabled the OS to read the decrementor.
This is required at least by all desktop and server PowerPC Linux kernels. It
can't really hurt to allow embedded ones to do it as well though.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/kvm/emulate.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
index 7737146..50d411d 100644
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -66,12 +66,14 @@
void kvmppc_emulate_dec(struct kvm_vcpu *vcpu)
{
+ unsigned long nr_jiffies;
+
if (vcpu-arch.tcr TCR_DIE) {
/* The decrementer ticks at the same rate as the timebase, so
* that's how we convert the guest DEC value to the number of
* host ticks. */
- unsigned long nr_jiffies;
+ vcpu-arch.dec_jiffies = mftb();
nr_jiffies = vcpu-arch.dec / tb_ticks_per_jiffy;
mod_timer(vcpu-arch.dec_timer,
get_jiffies_64() + nr_jiffies);
@@ -211,6 +213,15 @@ int kvmppc_emulate_instruction(struct kvm_run *run,
struct kvm_vcpu *vcpu)
/* Note: SPRG4-7 are user-readable, so we don't get
* a trap. */
+ case SPRN_DEC:
+ {
+ u64 jd = mftb() - vcpu-arch.dec_jiffies;
+ vcpu-arch.gpr[rt] = vcpu-arch.dec - jd;
+#ifdef DEBUG_EMUL
+ printk(KERN_INFO mfDEC: %x - %llx = %lx\n,
vcpu-arch.dec, jd, vcpu-arch.gpr[rt]);
+#endif
+ break;
+ }
default:
emulated = kvmppc_core_emulate_mfspr(vcpu,
sprn, rt);
if (emulated == EMULATE_FAIL) {
mftb() doesn't exist for ppc32, so we'll need to use the get_tb()
wrapper instead.
--
Hollis Blanchard
IBM Linux Technology Center
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/27] Pass PVR in sregs
On Tue, 2009-09-29 at 10:17 +0200, Alexander Graf wrote:
Right now sregs is unused on PPC, so we can use it for initialization
of the CPU.
KVM on BookE always virtualizes the host CPU. On Book3s we go a step further
and take the PVR from userspace that tells us what kind of CPU we are supposed
to virtualize, because we support Book3s_32 and Book3s_64 guests.
In order to get that information, we use the sregs ioctl, because we don't
want to reset the guest CPU on every normal register set.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/powerpc/include/asm/kvm.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index bb2de6a..b82bd68 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -46,6 +46,8 @@ struct kvm_regs {
};
struct kvm_sregs {
+ __u64 pvr;
+ char pad[1016];
};
struct kvm_fpu {
Architecturally, PVR is 32 bits, even for PPC64. Is there a reason you
want it to be 64 bits here? (I can understand just picking 64 for
registers that could be either size, but that's not this case.)
--
Hollis Blanchard
IBM Linux Technology Center
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 25/27] Fix trace.h
On Tue, 2009-09-29 at 10:18 +0200, Alexander Graf wrote: It looks like the variable pc is defined. At least the current code always failed on me stating that pc is already defined somewhere else. Let's use _pc instead, because that doesn't collide. Is this the right approach? Does it break on 440 too? If not, why not? Signed-off-by: Alexander Graf ag...@suse.de --- arch/powerpc/kvm/trace.h |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/kvm/trace.h b/arch/powerpc/kvm/trace.h index 67f219d..a8e8400 100644 --- a/arch/powerpc/kvm/trace.h +++ b/arch/powerpc/kvm/trace.h @@ -12,8 +12,8 @@ * Tracepoint for guest mode entry. */ TRACE_EVENT(kvm_ppc_instr, - TP_PROTO(unsigned int inst, unsigned long pc, unsigned int emulate), - TP_ARGS(inst, pc, emulate), + TP_PROTO(unsigned int inst, unsigned long _pc, unsigned int emulate), + TP_ARGS(inst, _pc, emulate), TP_STRUCT__entry( __field(unsigned int, inst) @@ -23,7 +23,7 @@ TRACE_EVENT(kvm_ppc_instr, TP_fast_assign( __entry-inst = inst; - __entry-pc = pc; + __entry-pc = _pc; __entry-emulate= emulate; ), After much digging, I managed to actually enable CONFIG_TRACEPOINTS. However, I still don't get any build errors from this code. Maybe you could paste the full gcc output? -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
