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
[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 on
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 lo
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
+ 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.
pit probably doesn't due to being rarely updated. For hpet I'd expect
it showing up much more.
Glauber de Oliveira Costa wrote:
> Well, my previous understanding was that if the CPU marks the tsc as
> stable, it _won't_ stop even in C3, and it was done this way exactly
> to make sure there are a stable source for timing.
Other way around: Kernel can mark the TSC unstable if it figures it
d
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 whe
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 fo
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 li
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 i
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 -
> 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 n
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 vi
On Mon, 2007-10-15 at 14:48 -0300, Glauber de Oliveira Costa wrote:
> On 10/12/07, Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> > > + if (kvm_hypercall1(KVM_HCALL_SET_SHARED_PAGE, shared_page))
> > > + return;
> >
> > Here you're passing a virtual address across the guest/host
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 is
> possible to integrate a paravi
On 10/15/07, Carsten Otte <[EMAIL PROTECTED]> wrote:
> 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
> >
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 everything else:
Well... not being _quite_ sure ;
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 th
On 10/15/07, Dong, Eddie <[EMAIL PROTECTED]> 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. :)
> >>
> >
> >U
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 i
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 clock
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
Glauber de Oliveira Costa wrote:
>>
>> It might be better to just rely on the in-kernel APIC to inject an
>> interrupt for the clock (via kvm_pic_set_irq()).
>>
>>
>
>
> After trying this option a little bit, it does not seemed worthwhile
> to me. But it might well have been due to some misund
> > +
> > +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)
> >
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 tim
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 configuratio
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. :)
> >>
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
2007/10/15, Gerd Hoffmann <[EMAIL PROTECTED]>:
> Avi Kivity 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.
> >
Avi Kivity 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 ticking if the CPU
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 ticking if the CPU goes sleep in C3, which
Hi,
> 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 ticking if the CPU goes sleep in C3, which
IMHO makes the tsc almost useles
>>> 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
On Fri, 2007-10-12 at 13:08 -0300, Glauber de Oliveira Costa wrote:
> +
> +/* The hypervisor will put information about time periodically here */
> +struct kvm_hv_clock hv_clock;
...
> +void __init kvmclock_init(void)
> +{
> +
> + unsigned long shared_page = (unsigned long)&hv_clock;
What
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"
+ dep
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
> >> +
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 parav
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 ru
Jeremy Fitzhardinge wrote:
> 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
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.
>
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 w
42 matches
Mail list logo
