All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.