public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Yang, Sheng" <sheng.yang@intel.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: kvm-devel@lists.sourceforge.net, Avi Kivity <avi@qumranet.com>
Subject: Re: [PATCH][QEMU] Use a separate device for in-kernel PIT
Date: Thu, 13 Mar 2008 10:20:17 +0800	[thread overview]
Message-ID: <200803131020.18323.sheng.yang@intel.com> (raw)
In-Reply-To: <47D8559C.6060203@us.ibm.com>

On Thursday 13 March 2008 06:13:48 Anthony Liguori wrote:
> Dor Laor wrote:
> > On Wed, 2008-03-12 at 12:38 -0500, Anthony Liguori wrote:
> >> Part of the feedback we received from Fabrice about the KVM patches
> >> for QEMU
> >> is that we should create a separate device for the in-kernel APIC to
> >> avoid
> >> having lots of if (kvm_enabled()) within the APIC code that were
> >> difficult to
> >> understand why there were needed.
> >>
> >> This patch separates the in-kernel PIT into a separate device.  It
> >> also
> >> introduces some configure logic to only compile in support for the
> >> in-kernel
> >> PIT if it's available.
> >>
> >> The result of this is that we now only need a single if
> >> (kvm_enabled()) to
> >> determine which device to use.  Besides making it more upstream
> >> friendly, I
> >> think this makes the code much easier to understand.
> >
> > Seems like a good idea.
> >
> > [snip]
> > ..
> >
> >> +static void pit_reset(void *opaque)
> >> +{
> >> +    PITState *pit = opaque;
> >> +    PITChannelState *s;
> >> +    int i;
> >> +
> >> +    for(i = 0;i < 3; i++) {
> >> +        s = &pit->channels[i];
> >> +        s->mode = 3;
> >> +        s->gate = (i != 2);
> >> +        pit_load_count(s, 0);
> >> +    }
> >> +}
> >> +
> >
> > Seems like pit_reset won't change the in-kernel pit state.
>
> Yeah, that seemed suspicious to me too.  I didn't want to change the
> existing behavior though for fear of introducing regressions.  Perhaps
> Sheng can comment on whether it's necessary to even have a reset handler
> in userspace?

IMO the reset support is needed even it would introduce regression (e would 
finally solve the regression if exists, won't we? :) ).

And we got two choices in userspace: one ioctl to reset all kvm devices, or 
one ioctl for each device. For we are separating in kernel device into 
separate devices, seems the later is more proper. But would it bring other 
troubles like inconsistent state for smp? 

Thanks
Yang, Sheng

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

  reply	other threads:[~2008-03-13  2:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-12 17:38 [PATCH][QEMU] Use a separate device for in-kernel PIT Anthony Liguori
2008-03-12 22:04 ` Dor Laor
2008-03-12 22:13   ` Anthony Liguori
2008-03-13  2:20     ` Yang, Sheng [this message]
2008-03-16 11:24       ` Avi Kivity
2008-03-16 11:22 ` Avi Kivity
2008-03-21 20:20 ` Hollis Blanchard
2008-03-21 20:24   ` Anthony Liguori
2008-03-23  8:45     ` Avi Kivity
2008-03-23 14:06       ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200803131020.18323.sheng.yang@intel.com \
    --to=sheng.yang@intel.com \
    --cc=aliguori@us.ibm.com \
    --cc=avi@qumranet.com \
    --cc=kvm-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox