Yang, Sheng wrote:
> I updated patch using ktime_get() (Is it too heavy?).
>
>
Shouldn't be. At least on modern hosts.
> And currently all the muldiv64() is used to divide 1e9, which can be
> insteaded
> by ">> 30" approximately. What's your opinion?
>
Accuracy is more important. And m
On Wednesday 23 January 2008 17:46:22 Avi Kivity wrote:
> Yang, Sheng wrote:
> > On Tuesday 22 January 2008 21:54:10 Avi Kivity wrote:
> >> Yang, Sheng wrote:
> >>> +
> >>> +static int pit_get_out(struct kvm *kvm, int channel)
> >>> +{
> >>> + struct PITChannelState *c =
> >>> + &kvm->arch.
Yang, Sheng wrote:
> On Tuesday 22 January 2008 21:54:10 Avi Kivity wrote:
>
>> Yang, Sheng wrote:
>>
>>> +
>>> +/* Compute with 96 bit intermediate result: (a*b)/c */
>>> +static u64 muldiv64(u64 a, u32 b, u32 c)
>>>
>> Why do we need such high accuracy for the pit?
>>
>
> The
On Tuesday 22 January 2008 21:54:10 Avi Kivity wrote:
> Yang, Sheng wrote:
> > +
> > +/* Compute with 96 bit intermediate result: (a*b)/c */
> > +static u64 muldiv64(u64 a, u32 b, u32 c)
>
> Why do we need such high accuracy for the pit?
The direct reason is we using TSC as the reference of pit co
Yang, Sheng wrote:
> +
> +/* Compute with 96 bit intermediate result: (a*b)/c */
> +static u64 muldiv64(u64 a, u32 b, u32 c)
>
Why do we need such high accuracy for the pit?
> +
> +static int pit_get_out(struct kvm *kvm, int channel)
> +{
> + struct PITChannelState *c =
> + &kv
On Monday 21 January 2008 18:28:32 Carsten Otte wrote:
> Jan Kiszka wrote:
> > The PIT may not be limited to x86 platforms. So I would propose to make
> > the setup more generic and flexible. And I would move the code out of
> > arch/x86, just the speaker support should remain there.
>
> It should
Jan Kiszka wrote:
> I would rather stuff these parameters into KVM_CREATE_PIT right from the
> beginning than later breaking the kernel/user ABI or adding a clumsy
> KVM_CREATE_PIT_SPECIAL_EXTENDED_VERSION. :->
>
Binary compatibility is only guaranteed between released kernel
versions; develop
Jan Kiszka wrote:
> The PIT may not be limited to x86 platforms. So I would propose to make
> the setup more generic and flexible. And I would move the code out of
> arch/x86, just the speaker support should remain there.
It should also not be common among all archs. On s390 we have CPU
timer, whi
Avi Kivity wrote:
> Jan Kiszka wrote:
>> The PIT may not be limited to x86 platforms. So I would propose to make
>> the setup more generic and flexible. And I would move the code out of
>> arch/x86, just the speaker support should remain there.
>>
>> I'm currently struggling with emulating a propri
Jan Kiszka wrote:
> The PIT may not be limited to x86 platforms. So I would propose to make
> the setup more generic and flexible. And I would move the code out of
> arch/x86, just the speaker support should remain there.
>
> I'm currently struggling with emulating a proprietary platform that has
>
Yang, Sheng wrote:
> --- /dev/null
> +++ b/arch/x86/kvm/i8254.h
...
> +#define PIT_BASE_ADDRESS 0x40
> +#define SPEAKER_BASE_ADDRESS 0x61
> +#define PIT_MEM_LENGTH 4
> +#define PIT_FREQ 1193181
The PIT may not be limited to x86 platforms. So I would propose to make
th
From 56a50952929f9a7e78fc3ec812dd4550c623b956 Mon Sep 17 00:00:00 2001
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Mon, 21 Jan 2008 16:42:37 +0800
Subject: [PATCH] KVM: In-kernel PIT model
Signed-off-by: Sheng Yang <[EMAIL PROTECTED]>
---
arch/x86/kvm/Makefile |3 +-
arch/x86/kvm/i8254.c
12 matches
Mail list logo
