On Thu, May 27, 2010 at 11:02:35AM -1000, Zachary Amsden wrote:
On 05/27/2010 10:36 AM, Glauber Costa wrote:We already specify that users can only trust the value of the wallclock
On Thu, May 27, 2010 at 10:13:12AM -1000, Zachary Amsden wrote:Little-endian non-atomic page crossing writes will write the small
On 05/27/2010 06:02 AM, Glauber Costa wrote:Which atomic write? This is the wallclock, we do no atomic writes for
On Thu, May 27, 2010 at 11:15:43AM +0300, Avi Kivity wrote:It's so the atomic write actually is atomic.
On 05/26/2010 09:04 PM, Glauber Costa wrote:I don't see the reason for it.
This patch adds a file that documents the usage of KVM-specificLooks good. A few comments:
MSRs.
+Which must be in guest RAM (i.e., don't point it somewhere random
+Custom MSR list
+--------
+
+The current supported Custom MSR list is:
+
+MSR_KVM_WALL_CLOCK: 0x11
+
+ data: physical address of a memory area.
and expect the hypervisor to allocate it for you).
Must be aligned to 4 bytes (we don't enforce it though).
If this is a requirement, our own implementation
is failing to meet it.
querying it. Not to confuse with system time (the other msr).
Stating a 4 -byteYes, but why require it?
alignment requirement prevents the wall clock from crossing a page
boundary.
reading the wallclock is not a hot path for anybody, is usually done
just once, and crossing a page boundary here does not pose any correctness
issue.
part of the wallclock first, so another CPU may observe the
following wallclock sequence:
0x01ff .. 0x0100 .. 0x0200
Big-endian writes also have similar failure:
0x01ff .. 0x02ff .. 0x0200
This won't happen if there is a single instruction write of the wall
clock word.
after we have an even version field.
When we start the update, and during the time of all writes to it,
it is odd, and thus, invalid.
The ABI guarantees to the guest that we'll only bump version
after we're done updating.