Glauber de Oliveira Costa wrote:
Here you're passing a virtual address across the guest/host interface,
which is something we've previously agreed is bad.
And that's the reason for the nothing. It was just the easier way,
and I'm not aware of any discussion in which it was agreed
Glauber de Oliveira Costa wrote:
Obviously people have figured out how to do dynticks on real x86
hardware, so I don't accept this reason. :)
Using more advanced timers like the HPET.
I'd think there is no reason for virtual timer to be PIT like, which
is mostly due to
Glauber de Oliveira Costa wrote:
On 10/15/07, Gerd Hoffmann [EMAIL PROTECTED] wrote:
Host should know. Well, I hope. Dunno whenever one really can be sure
in all cases given all the different CPUs and tsc implementations.
In the same way we can be sure about hardware for
Glauber de Oliveira Costa wrote:
On 10/15/07, Avi Kivity [EMAIL PROTECTED] wrote:
If we want to make the clocksource useful for Windows we need to go
through the apic as that will allow the TPR to mask the interrupt when
Windows isn't ready to receive it. However I don't know whether it
+ case KVM_HCALL_SET_ALARM: {
+ ktime_t kt;
+ kt = ktime_add_ns(ktime_get_real(), a0);
This one will cause accumulated time shift. a0 is the delta time
when the guest calculate.
+ hrtimer_start(vcpu-oneshooter, kt, HRTIMER_MODE_ABS);
+
Hollis Blanchard wrote:
That's a good point, but does PIT/HPET emulation show up as a hot spot
in any profiles? I think keeping the hypercall API as small as feasible
is a desirable design goal.
At the moment I think not. Even a dyntick kernel would only require a
few thousands exits per
Glauber de Oliveira Costa wrote:
I think I'll stick to two fields then, with u64 for seconds and nanoseconds.
Or would it just be better to use a u64 nanoseconds field?
A _lot_ of time should have passed before such counter overflows. So
having two is possibly overkill
u64 nanoseconds looks
[EMAIL PROTECTED] wrote:
Hollis Blanchard wrote:
That's a good point, but does PIT/HPET emulation show up as a hot
spot in any profiles? I think keeping the hypercall API as small as
feasible is a desirable design goal.
At the moment I think not. Even a dyntick kernel would only require
Gerd Hoffmann wrote:
Hollis Blanchard wrote:
That's a good point, but does PIT/HPET emulation show up as a hot spot
in any profiles? I think keeping the hypercall API as small as feasible
is a desirable design goal.
pit probably doesn't due to being rarely updated. For hpet I'd
Gerd Hoffmann wrote:
With VT you can attempt to make that invisible to the guest using the
tsc offset field. Probably svm can do that too (didn't check docs
though). kvm-lite can't (what is the status btw?). Xen solves that
by not doing power management *evil grin*.
On s390, we've had an
On Mon, 2007-10-15 at 12:04 +0800, Dong, Eddie wrote:
1) the PIT is periodic. a PV timer can offer a one shot
timer which
enables dynticks.
Obviously people have figured out how to do dynticks on real x86
hardware, so I don't accept this reason. :)
Using more advanced
Carsten Otte wrote:
On s390, we've had an instruction...
Yes, quite ;)
J
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and
Hollis Blanchard wrote:
I'd think there is no reason for virtual timer to be PIT like, which
is mostly due to historic reason.
If we need to make it close to native timer device, HPET is much
better than PIT for virtual time to look like.
Fine, so why do we need PV time when we can
+
+void __init kvmclock_init(void)
+{
+
+ unsigned long shared_page = (unsigned long)hv_clock;
+ /*
+ * If we can't use the paravirt clock, just go with
+ * the usual timekeeping
+ */
+ if (!kvm_para_available() || no_kvmclock)
+ return;
On 10/12/07, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
* Measure the time it takes for a hypercall, and subtract this time
for calculating the expiry time for the timer event.
I don't think there's much point in trying to do stuff like this. The
guest can be preempted at any time, so
On 10/12/07, Hollis Blanchard [EMAIL PROTECTED] wrote:
2) the TSC would have to be used as a clocksource. You don't know the
frequency which is the first problem with using the TSC but some systems
have a TSC that changes frequencies. A PV time source gives you more
stable clocksource
On 10/12/07, Hollis Blanchard [EMAIL PROTECTED] wrote:
What makes you think this is page-aligned?
Nothing.
+ if (kvm_hypercall1(KVM_HCALL_SET_SHARED_PAGE, shared_page))
+ return;
Here you're passing a virtual address across the guest/host interface,
which is
On 10/15/07, Avi Kivity [EMAIL PROTECTED] wrote:
Gerd Hoffmann wrote:
2) the TSC would have to be used as a clocksource. You don't know the
frequency which is the first problem with using the TSC but some systems
have a TSC that changes frequencies.
Also note the tsc may stop
On Mon, 2007-10-15 at 18:47 +0200, Avi Kivity wrote:
Hollis Blanchard wrote:
I'd think there is no reason for virtual timer to be PIT like, which
is mostly due to historic reason.
If we need to make it close to native timer device, HPET is much
better than PIT for virtual time to look
The basic issue is that on many architectures, the hardware MMU does
*not* hold all mappings, and even if it does, performing MMU translation
in software can be prohibitively complicated and slow. As a worst-case
scenario, consider a software-controlled TLB which can hold a small
finite
On 10/15/07, Hollis Blanchard [EMAIL PROTECTED] wrote:
(This mail was sent off-list, so I'll do the same.)
Oh, I'm sorry Hollis, after so many mails, I've hit the reply key
instead of the reply to all one ;-)
I'm moving it to the list again, where it belongs.
On Mon, 2007-10-15 at 14:29
1) the PIT is periodic. a PV timer can offer a one shot
timer which
enables dynticks.
Obviously people have figured out how to do dynticks on real x86
hardware, so I don't accept this reason. :)
Using more advanced timers like the HPET.
I'd think there is no reason for
On Fri, 2007-10-12 at 13:08 -0300, Glauber de Oliveira Costa wrote:
+config KVM_CLOCK
+ bool KVM paravirtualized clock
+ depends on PARAVIRT GENERIC_CLOCKEVENTS
+ help
+ Turning on this option will allow you to run a paravirtualized clock
+ when running
Hi,
Attached is a first draft to a paravirt implementation for a timer to
KVM. It is inspired in anthony's last patch about it, but not that
much based on it.
I'm not using hypercalls to get the current time, but rather,
registering an address that will get timer updates once in a while.
Also,
Glauber de Oliveira Costa wrote:
My next TODOs with it are:
* Get SMP working
* Try something for stolen time, as jeremy's last suggestion for anthony's
patch
* Measure the time it takes for a hypercall, and subtract this time
for calculating the expiry time for the timer event.
I
Glauber de Oliveira Costa wrote:
Hi,
Attached is a first draft to a paravirt implementation for a timer to
KVM. It is inspired in anthony's last patch about it, but not that
much based on it.
I'm not using hypercalls to get the current time, but rather,
registering an address that will get
Hollis Blanchard wrote:
On Fri, 2007-10-12 at 13:08 -0300, Glauber de Oliveira Costa wrote:
+config KVM_CLOCK
+ bool KVM paravirtualized clock
+ depends on PARAVIRT GENERIC_CLOCKEVENTS
+ help
+ Turning on this option will allow you to run a paravirtualized
Hollis Blanchard wrote:
On Fri, 2007-10-12 at 15:02 -0500, Anthony Liguori wrote:
Hollis Blanchard wrote:
On Fri, 2007-10-12 at 13:08 -0300, Glauber de Oliveira Costa wrote:
+config KVM_CLOCK
+ bool KVM paravirtualized clock
+ depends on PARAVIRT
On Fri, 2007-10-12 at 15:02 -0500, Anthony Liguori wrote:
Hollis Blanchard wrote:
On Fri, 2007-10-12 at 13:08 -0300, Glauber de Oliveira Costa wrote:
+config KVM_CLOCK
+ bool KVM paravirtualized clock
+ depends on PARAVIRT GENERIC_CLOCKEVENTS
+ help
+
29 matches
Mail list logo
