From: Zachary Amsden <zamsden@redhat.com>
To: Glauber Costa <glommer@redhat.com>
Cc: Avi Kivity <avi@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Add Documentation/kvm/msr.txt
Date: Thu, 27 May 2010 11:02:35 -1000 [thread overview]
Message-ID: <4BFEDDEB.9020700@redhat.com> (raw)
In-Reply-To: <20100527203638.GH3445@mothafucka.localdomain>
On 05/27/2010 10:36 AM, Glauber Costa wrote:
> On Thu, May 27, 2010 at 10:13:12AM -1000, Zachary Amsden wrote:
>
>> On 05/27/2010 06:02 AM, Glauber Costa wrote:
>>
>>> On Thu, May 27, 2010 at 11:15:43AM +0300, Avi Kivity wrote:
>>>
>>>> On 05/26/2010 09:04 PM, Glauber Costa wrote:
>>>>
>>>>> This patch adds a file that documents the usage of KVM-specific
>>>>> MSRs.
>>>>>
>>>>>
>>>> Looks good. A few comments:
>>>>
>>>>
>>>>> +
>>>>> +Custom MSR list
>>>>> +--------
>>>>> +
>>>>> +The current supported Custom MSR list is:
>>>>> +
>>>>> +MSR_KVM_WALL_CLOCK: 0x11
>>>>> +
>>>>> + data: physical address of a memory area.
>>>>>
>>>> Which must be in guest RAM (i.e., don't point it somewhere random
>>>> and expect the hypervisor to allocate it for you).
>>>>
>>>> Must be aligned to 4 bytes (we don't enforce it though).
>>>>
>>> I don't see the reason for it.
>>>
>>> If this is a requirement, our own implementation
>>> is failing to meet it.
>>>
>> It's so the atomic write actually is atomic.
>>
> Which atomic write? This is the wallclock, we do no atomic writes for
> querying it. Not to confuse with system time (the other msr).
>
>
>> Stating a 4 -byte
>> alignment requirement prevents the wall clock from crossing a page
>> boundary.
>>
> Yes, but why require it?
>
> 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.
>
Little-endian non-atomic page crossing writes will write the small 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.
next prev parent reply other threads:[~2010-05-27 21:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-26 18:04 [PATCH] Add Documentation/kvm/msr.txt Glauber Costa
2010-05-26 18:35 ` Randy Dunlap
2010-05-26 18:59 ` Glauber Costa
2010-05-27 8:15 ` Avi Kivity
2010-05-27 16:02 ` Glauber Costa
2010-05-27 20:13 ` Zachary Amsden
2010-05-27 20:36 ` Glauber Costa
2010-05-27 21:02 ` Zachary Amsden [this message]
2010-05-28 0:10 ` Glauber Costa
2010-05-28 4:10 ` Zachary Amsden
2010-05-30 9:14 ` Avi Kivity
2010-05-31 13:49 ` Glauber Costa
2010-05-31 14:03 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BFEDDEB.9020700@redhat.com \
--to=zamsden@redhat.com \
--cc=avi@redhat.com \
--cc=glommer@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).