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/
next prev parent 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