WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation
From: Avi Kivity <avi@xxxxxxxxxx>
Date: Wed, 07 Oct 2009 23:37:47 +0200
Cc: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, kurt.hackel@xxxxxxxxxx, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Glauber de Oliveira Costa <gcosta@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Zach Brown <zach.brown@xxxxxxxxxx>, Chris Mason <chris.mason@xxxxxxxxxx>
Delivery-date: Wed, 07 Oct 2009 14:39:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4ACD05D8.5090903@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1254790211-15416-1-git-send-email-jeremy.fitzhardinge@xxxxxxxxxx> <1254790211-15416-4-git-send-email-jeremy.fitzhardinge@xxxxxxxxxx> <4ACB0833.2050203@xxxxxxxxxx> <4ACB9074.1000804@xxxxxxxx> <4ACC6C9C.7080707@xxxxxxxxxx> <4ACCEC18.90401@xxxxxxxx> <4ACCF565.30804@xxxxxxxxxx> <4ACD05D8.5090903@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3
On 10/07/2009 11:19 PM, Jeremy Fitzhardinge wrote:

When do you copy?

I'd rather have a single copy for guest and host.
When Xen updates the parameters normally.  The interface never really
needed to share the memory between hypervisor and guest, and I think
avoiding it is a bit more robust.

But for KVM, you already use the MSR to place the pvclock_vcpu_time_info
structure, so you could just place it in the page and use the same
memory for kernel and usermode.

Yes.

If the hypervisor does a pvclock->version = somethingelse->version++
then the guest may get confused.  But I understand you have a
guest-private ->version?
The guest should never get confused by the version being changed by the
hypervisor.  It's already part of the ABI.  Or did you mean something else?

If the guest does a RMW on the version, but the host does not (copying it from somewhere else), then the guest RMW can be lost.

Looking at the code, that's what kvm does:

    vcpu->hv_clock.version += 2;

    shared_kaddr = kmap_atomic(vcpu->time_page, KM_USER0);

    memcpy(shared_kaddr + vcpu->time_offset, &vcpu->hv_clock,
           sizeof(vcpu->hv_clock));

so a guest-side ++version can be lost.

I'm not sure what you mean by "guest-private version"; the versions are
always guest-private:  te version is part of the pvclock structure,
which is per-vcpu, which is private to each guest.   The guest nevern
maintains a separate long-term copy of the structure, only a transient
snapshot while computing time from the tsc (that's the current pvclock.c
code).

Same for kvm. I'm not worried about cross-guest corruption, just the guest and host working together to confuse the guest.

No need to read them atomically.

cpu1 = vgetcpu()
hver1 = pvclock[cpu1].hver
kver1 = pvclock[cpu1].kver
tsc = rdtsc
/* multipication magic with pvclock[cpu1]*/
cpu2 = vgetcpu()
hver2 = pvclock[cpu2].hver
kver2 = pvclock[cpu2].kver
valid = cpu1 == cpu2&&  hver1 == hver2&&  kver1 == kver2
I don't think that's necessary, but I can certainly live with it if it
makes you happier.

I think the version issue requires it.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>