(context put back:)
But does that mean that a guest should never be allowed to modify a
virtualized
timebase register, even if the hypervisor can support it?
The book3e mtspr writeup doesn't appear to specify the behavior when
writing to a read-only SPR, so perhaps you could argue that something
other
than a no-op is implementation-specific behavior.
v2.06 III-E 9.2.1:
"Writing the Time Base is hypervisor privileged."
v2.06 III-E 2.1:
"If a hypervisor-privileged register is accessed in the guest
supervisor
state (MSR[GS PR] = 0b10), an Embedded Hypervisor Privilege exception
occurs."
(v2.06 III-E 5.4.1, the big SPR table, also shows the TB regs (for
writing,
i.e. 284 and 285) to be hypervisor privileged. Consistency, hurray
:-) )
To me, all this means that a guest cannot write to the actual timebase
register.
It also means that the hypervisor gets a trap when a guest tries to do
this.
I'm not interpreting this to mean that a hypervisor can't
virtualize the timebase and allow a guest to read/write a virtual
timebase
register, so that it thinks it's writing to the real hardware timebase
register.
Yes, a hypervisor can do this. The behaviour of the hardware is not
implementation-specific (modulo bugs ;-) ); when a guest tries to write
to the timebase, the hypervisor gets a trap. The hypervisor can then
do whatever it wants with it.
Segher
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
