[<prev] [next>] [day] [month] [year] [list]
Message-Id: <200806231747.07773.sheng.yang@intel.com>
Date: Mon, 23 Jun 2008 17:47:07 +0800
From: "Yang, Sheng" <sheng.yang@...el.com>
To: Avi Kivity <avi@...ranet.com>
Cc: dor.laor@...ranet.com, kvm@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] KVM: Report hardware virtualization features
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists