lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ