From: "Yang, Sheng" <sheng.yang@intel.com>
To: Avi Kivity <avi@qumranet.com>
Cc: dor.laor@qumranet.com, kvm@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/4] KVM: Report hardware virtualization features
Date: Mon, 23 Jun 2008 17:47:07 +0800 [thread overview]
Message-ID: <200806231747.07773.sheng.yang@intel.com> (raw)
In-Reply-To: <200806231101.13399.sheng.yang@intel.com>
On Monday 23 June 2008 11:01:13 Yang, Sheng wrote:
> On Monday 23 June 2008 10:40:33 Avi Kivity wrote:
> > Yang, Sheng wrote:
> > > On Sunday 22 June 2008 20:21:37 Avi Kivity wrote:
> > >> Dor Laor wrote:
> > >>>> Yes, this is definitely helpful. However, I think that users will
> > >>>> expect cpu flags under /proc/cpuinfo.
> > >>>>
> > >>>> Perhaps we should add a new line 'virt flags' to /proc/cpuinfo? I
> > >>>> think all the features are reported using msrs, so it can be done
> > >>>> from arch/x86/kernel/cpu/proc.c without involving kvm at all.
> > >>>
> > >>> while I agree with Avi, it would be nice thought to see them on older
> > >>> kernels. At least sprinkle a printk message.
> > >>
> > >> Oh we'll certainly hack something for the external modules.
> > >
> > > Yeah, add a virt flags is more directly, and I think it's not hard to
> > > be accepted. I will do that.
> >
> > Perhaps just adding to the standard flags line is best, since tools
> > already read it.
>
> I was thinking of it before, but later I think it's not very proper.
> 1. The standard flag covered upper level of cpu capability.
> 2. If we add virtual feature to standard flag, I am afraid it would grow
> too fast.
>
> So I prefer to add a new "virt flag".
>
> > > And as Dor said, I think we also need a relative elegant method for the
> > > modules. So maybe we can keep these patches? Without that bash script.
> > > :)
> >
> > I'll just copy the code that finally makes it and put it in
> > kernel/external-module-compat.c. Patches would stop applying soon.
>
> You means the current patchset or patch for /proc/cpuinfo? :)
>
One of my colleague said that if we modify /proc/cpuinfo, it may cause some
trouble for some not well designed userspace parser... So he thought we
should be careful about modify this interface.
Add flag to standard flags can avoid this, but I still think it make some
different things mixture...
Maybe we should contact some guy on X86 side?
--
Thanks
Yang, Sheng
prev parent reply other threads:[~2008-06-23 9:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-19 10:42 [PATCH 1/4] KVM: Report hardware virtualization features Yang, Sheng
2008-06-22 6:49 ` Avi Kivity
2008-06-22 12:18 ` Dor Laor
2008-06-22 12:21 ` Avi Kivity
2008-06-23 1:46 ` Yang, Sheng
2008-06-23 2:40 ` Avi Kivity
2008-06-23 3:01 ` Yang, Sheng
2008-06-23 9:47 ` Yang, Sheng [this message]
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=200806231747.07773.sheng.yang@intel.com \
--to=sheng.yang@intel.com \
--cc=avi@qumranet.com \
--cc=dor.laor@qumranet.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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