Yang, Sheng wrote:
> +
> +static int pit_get_out(struct kvm *kvm, int channel)
> +{
> + struct kvm_kpit_channel_state *c =
> + &kvm->arch.vpit->pit_state.channels[channel];
> + s64 d, t;
> + int out;
> +
> + ASSERT(mutex_is_locked(&kvm->arch.vpit->pit_state.lock));
> +
>
On Wednesday 05 March 2008 14:54:06 Avi Kivity wrote:
> Yang, Sheng wrote:
> > +
> > +static int pit_get_out(struct kvm *kvm, int channel)
> > +{
> > + struct kvm_kpit_channel_state *c =
> > + &kvm->arch.vpit->pit_state.channels[channel];
> > + s64 d, t;
> > + int out;
> > +
> > +
* Yang, Sheng <[EMAIL PROTECTED]> wrote:
> +#if 1
> +#define pit_debug(fmt, arg...) printk(KERN_WARNING fmt, ##arg)
> +#else
> +#define pit_debug(fmt, arg...)
> +#endif
this should use pr_debug() instead i guess.
> +#ifndef CONFIG_X86_64
> +#define mod_64(x, y) ((x) - (y) * div64_64(x, y))
> +#
Thanks for comments!
On Wednesday 05 March 2008 17:15:29 Ingo Molnar wrote:
> * Yang, Sheng <[EMAIL PROTECTED]> wrote:
> > +#if 1
> > +#define pit_debug(fmt, arg...) printk(KERN_WARNING fmt, ##arg)
> > +#else
> > +#define pit_debug(fmt, arg...)
> > +#endif
>
> this should use pr_debug() instead i
Yang, Sheng wrote:
> Thanks for comments!
>
> On Wednesday 05 March 2008 17:15:29 Ingo Molnar wrote:
>
>> * Yang, Sheng <[EMAIL PROTECTED]> wrote:
>>
>>> +#if 1
>>> +#define pit_debug(fmt, arg...) printk(KERN_WARNING fmt, ##arg)
>>> +#else
>>> +#define pit_debug(fmt, arg...)
>>> +#endif
>>>
* Yang, Sheng <[EMAIL PROTECTED]> wrote:
> > * Yang, Sheng <[EMAIL PROTECTED]> wrote:
> > > +#if 1
> > > +#define pit_debug(fmt, arg...) printk(KERN_WARNING fmt, ##arg)
> > > +#else
> > > +#define pit_debug(fmt, arg...)
> > > +#endif
> >
> > this should use pr_debug() instead i guess.
>
> Um...
On Wednesday 05 March 2008 19:35:40 Yang, Sheng wrote:
> On Wednesday 05 March 2008 17:15:29 Ingo Molnar wrote:
> > * Yang, Sheng <[EMAIL PROTECTED]> wrote:
> > > + val &= 0xff;
> > > + addr &= 3;
> >
> > magic constants.
>
> I will update these constants. :) In fact, I have thought of these befor
Yang, Sheng wrote:
> Here is the updated patch. I kept 0xff because I think it's OK for understand
> easily. :)
>
>
Any news on the regression with older Linux guests? That's the only
thing keeping my from applying the patchset.
--
Do not meddle in the internals of kernels, for they are s
On Thursday 06 March 2008 16:06:51 Avi Kivity wrote:
> Yang, Sheng wrote:
> > Here is the updated patch. I kept 0xff because I think it's OK for
> > understand easily. :)
>
> Any news on the regression with older Linux guests? That's the only
> thing keeping my from applying the patchset.
Not muc
* Yang, Sheng <[EMAIL PROTECTED]> wrote:
> + /* Though spec said the state of 8254 is undefined after power-up,
> + * seems some tricky OS like Windows XP depends on IRQ0 interrupt
> + * when booting up.
> + * So here setting initialize rate for it, and not a specific number */
On Thursday 06 March 2008 17:14:34 Ingo Molnar wrote:
> * Yang, Sheng <[EMAIL PROTECTED]> wrote:
> > + /* Though spec said the state of 8254 is undefined after power-up,
> > +* seems some tricky OS like Windows XP depends on IRQ0 interrupt
> > +* when booting up.
> > +* So here settin
* Yang, Sheng <[EMAIL PROTECTED]> wrote:
> > another silly style nit, the canonical comment style is:
> > > + /*
> > > + * Though spec said the state of 8254 is undefined after power-up,
> > > + * seems some tricky OS like Windows XP depends on IRQ0 interrupt
> > > + * when booting up.
> > > +
On Thursday 06 March 2008 16:43:18 Yang, Sheng wrote:
> On Thursday 06 March 2008 16:06:51 Avi Kivity wrote:
> > Yang, Sheng wrote:
> > > Here is the updated patch. I kept 0xff because I think it's OK for
> > > understand easily. :)
> >
> > Any news on the regression with older Linux guests? That'
On Thursday 06 March 2008 17:41:03 Yang, Sheng wrote:
> On Thursday 06 March 2008 16:43:18 Yang, Sheng wrote:
> > On Thursday 06 March 2008 16:06:51 Avi Kivity wrote:
> > > Yang, Sheng wrote:
> > > > Here is the updated patch. I kept 0xff because I think it's OK for
> > > > understand easily. :)
>
Yang, Sheng wrote:
> Found more complex for KVM. Xen pulled pm timer down to kernel part, and used
> the guest TSC as source. So only adjust TSC is OK for it. But we are still
> using pm timer in QEmu, which using host time as source. So even we pull back
> TSC, the problem still exists, for 2.6
On Friday 07 March 2008 16:53:40 Avi Kivity wrote:
> Yang, Sheng wrote:
> > Found more complex for KVM. Xen pulled pm timer down to kernel part, and
> > used the guest TSC as source. So only adjust TSC is OK for it. But we are
> > still using pm timer in QEmu, which using host time as source. So ev
Yang, Sheng wrote:
> On Friday 07 March 2008 16:53:40 Avi Kivity wrote:
>
>> Yang, Sheng wrote:
>>
>>> Found more complex for KVM. Xen pulled pm timer down to kernel part, and
>>> used the guest TSC as source. So only adjust TSC is OK for it. But we are
>>> still using pm timer in QEmu, whi
17 matches
Mail list logo
