Paul Mackerras <paulus@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html