I do the check there because I was having problems where, if the HDEC
goes negative before we do the partition switch, we would
occasionally
not get the HDEC interrupt at all until the next time HDEC went
negative, ~ 8.4 seconds later.
Yikes - so HDEC is edge and doesn't even keep the interrup
If HDEC expires when interrupts are off, the HDEC interrupt stays
pending until interrupts get re-enabled. I'm not sure exactly what
the conditions are that cause an HDEC interrupt to get lost, but they
seem to involve at least a partition switch.
On some CPUs, if the top bit of the decrementer
Sure, but that shouldn't happen with HDEC during the odd 50
instructions that it takes to enter the guest :)
It's more like 500 insns, including some ptesync, so lots of cycles
too.
I don't think its actually that bad.
There's a loop of 128 iterations of 3 insns.
I'm not saying it is actua
> +/*
> + * KVMPPC_INST_BOOK3S_DEBUG is debug Instruction for supporting Software
> Breakpoint.
> + * Based on PowerISA v2.07, Instruction with opcode 0s will be treated as
> illegal
> + * instruction.
> + */
"primary opcode 0" instead?
> +#define OP_ZERO 0x0
Using 0x0 where yo
Nice patchset. Some comments on the emulation part:
+#define OP_31_XOP_EIOIO854
You mean EIEIO.
+ case 19:
+ switch (get_xop(inst)) {
+ case OP_19_XOP_RFID:
+ case OP_19_XOP_RFI:
+ vcpu->arch.pc = vcpu->ar
+ case OP_31_XOP_EIOIO:
+ break;
Have you always executed an eieio or sync when you get here, or
do you just not allow direct access to I/O devices? Other context
synchronising insns are not enough, they do not broadcast on the
bus.
There is no device passt
On PowerPC it's very normal to not support all of the physical RAM
in real mode.
Oh? Are you referring to "real mode limit", or 32-bit
implementations with
more than 32 address lines, or something else?
Either way, RMO is a really bad name for this, since that name is
already
used for a
There is also a form of mtmsr where all bits need to be addressed.
While the
PPC64 Linux kernel behaves resonably well here, the PPC32 one never
uses the
L=1 form but does mtmsr even for simple things like only changing EE.
You make it sound like the 32-bit kernel does something stupid, whil
On PowerPC it's very normal to not support all of the physical
RAM in real mode.
Oh? Are you referring to "real mode limit", or 32-bit
implementations with
more than 32 address lines, or something else?
The former.
Okay. In that case, the hypervisor can usually access all of physical
r
There is also a form of mtmsr where all bits need to be
addressed. While the
PPC64 Linux kernel behaves resonably well here, the PPC32 one
never uses the
L=1 form but does mtmsr even for simple things like only changing
EE.
You make it sound like the 32-bit kernel does something stupid, whi
Also, it seems you construct the physical address by masking out
bits from
the effective address. Most implementations will trap or
machine check if
you address outside of physical address space, instead.
Well the only case where I remember to have hit a real RMO case
is on the PS3 - that
[without]
debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello > /
dev/null; done
real0m14.659s
user0m8.967s
sys 0m5.688s
[with]
debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello > /
dev/null; done
real0m7.557s
user0m4.121s
sys 0m3.426s
So th
v1 -> v2:
- RMO -> PAM
Except you forgot the subject line.
Segher
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
+To find out if we're running on KVM or not, we overlay the PVR
register. Usually
+the PVR register contains an id that identifies your CPU type. If,
however, you
+pass KVM_PVR_PARA in the register that you want the PVR result in,
the register
+still contains KVM_PVR_PARA after the mfpvr cal
14 matches
Mail list logo
