Re: kvmclock - the host part.

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Avi Kivity <avi@...>
Cc: <linux-kernel@...>, <jeremy@...>, <aliguori@...>, <kvm-devel@...>, <hollisb@...>
Date: Wednesday, November 7, 2007 - 9:08 am

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Avi Kivity escreveu:
Because my plan was exactly, updating it at each timer interrupt.
There's a trade off between
updating every run (hopefully more precision, but more overhead), versus
updating at timer irqs, or other events.

What would you prefer?

Right.

That's true, I'm just copying it at the end, the whole thing. thanks.

Too slow. Updating guest time, even only in timer interrupts, was a too
frequent operation, and the kmap / kunmap (atomic) at every iteration
deemed the whole thing
unusable.

Earlier version had a check for !dst_vcpu, you are absolutely right.

Locking was not a problem in practice, because these operations are done
 serialized, by the same cpu.

This hypercall is called by cpu_up, which, at least in the beginning,
it's called by cpu0. And that's why each vcpu cannot register its own.
(And why we don't need locking).

Well, theorectically each vcpu do can register its own clocksource, it
will just be a little bit more complicated, we have to fire out an IPI,
and have the other cpu to catch it, and call the hypercall.

But I honestly don't like it.
Usually, the cpu leaves start_secondary with a clock already registered,
so the kernel relies on it.

a0 is not a gfn, but a physical address.

You are right. I developed part of it in an older version of kvm, where
reality was:

struct page *gfn_to_page(struct kvm *kvm, gfn_t gfn)
{
        struct kvm_memory_slot *slot;

        gfn = unalias_gfn(kvm, gfn);
        slot = __gfn_to_memslot(kvm, gfn);
        if (!slot)
                return NULL;
        return slot->phys_mem[gfn - slot->base_gfn];
}

Will update.

Yeah , right, but again: It will be slow to the point of making the
whole thing not worthy. So what alternatives do we get?


Okay, will do.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Remi - http://enigmail.mozdev.org

iD8DBQFHMbjDjYI8LaFUWXMRAvcnAKCZOtPqHAxvcUkAfSaOezPWq1ib2wCg1TNz
fT1rt86/j25K/6lmFsRmbI0=
=nSkW
-----END PGP SIGNATURE-----
-
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
KVM paravirt clocksource - Take 3 out of &lt;put your number..., Glauber de Oliveira Costa..., (Tue Nov 6, 6:18 pm)
include files for kvmclock, Glauber de Oliveira Costa..., (Tue Nov 6, 6:18 pm)
Re: [kvm-devel] include files for kvmclock, Akio Takebe, (Wed Nov 7, 4:16 am)
Re: [kvm-devel] include files for kvmclock, Glauber de Oliveira Costa..., (Wed Nov 7, 9:16 am)
Re: [kvm-devel] include files for kvmclock, Akio Takebe, (Wed Nov 7, 9:27 am)
Re: include files for kvmclock, Jeremy Fitzhardinge, (Tue Nov 6, 6:50 pm)
Re: include files for kvmclock, Glauber de Oliveira Costa..., (Tue Nov 6, 6:58 pm)
Re: [kvm-devel] include files for kvmclock, Glauber de Oliveira Costa..., (Tue Nov 6, 5:35 pm)
Re: [kvm-devel] include files for kvmclock, Avi Kivity, (Wed Nov 7, 1:55 am)
Re: [kvm-devel] include files for kvmclock, Jeremy Fitzhardinge, (Wed Nov 7, 1:58 am)
Re: [kvm-devel] include files for kvmclock, Glauber de Oliveira Costa..., (Wed Nov 7, 8:49 am)
kvmclock - the host part., Glauber de Oliveira Costa..., (Tue Nov 6, 6:18 pm)
Re: kvmclock - the host part., Avi Kivity, (Wed Nov 7, 1:50 am)
Re: kvmclock - the host part., Glauber de Oliveira Costa..., (Wed Nov 7, 9:08 am)
Re: kvmclock - the host part., Avi Kivity, (Wed Nov 7, 9:59 am)
kvmclock implementation, the guest part., Glauber de Oliveira Costa..., (Tue Nov 6, 6:18 pm)