Re: [libvirt] [RFC] Support for CPUID masking v2

2009-09-22 Thread Daniel P. Berrange
On Tue, Sep 22, 2009 at 05:51:02PM +0200, Jiri Denemark wrote: > > > I'm not 100% sure we should represent CPU features as > > > NAME > > > especially because some features are currently advertised as . > > > However, > > > extending XML schema every time a new feature is introduced doesn't look

Re: [libvirt] [RFC] Support for CPUID masking v2

2009-09-22 Thread Jiri Denemark
> > I'm not 100% sure we should represent CPU features as > > NAME > > especially because some features are currently advertised as . > > However, > > extending XML schema every time a new feature is introduced doesn't look > > like > > a good idea at all. The problem is we can't get rid of -sty

Re: [libvirt] [RFC] Support for CPUID masking v2

2009-09-22 Thread Daniel Veillard
On Tue, Sep 22, 2009 at 03:01:18PM +0100, Daniel P. Berrange wrote: > On Tue, Sep 22, 2009 at 03:52:08PM +0200, Daniel Veillard wrote: > > On Tue, Sep 22, 2009 at 02:25:54PM +0100, Daniel P. Berrange wrote: > > > No, we should't rely on /proc/cpuinfo because that is Linux specific. > > > For Xen an

Re: [libvirt] [RFC] Support for CPUID masking v2

2009-09-22 Thread Daniel P. Berrange
On Tue, Sep 22, 2009 at 03:52:08PM +0200, Daniel Veillard wrote: > On Tue, Sep 22, 2009 at 02:25:54PM +0100, Daniel P. Berrange wrote: > > No, we should't rely on /proc/cpuinfo because that is Linux specific. > > For Xen and VMWare drivers we want a naming scheme for flags that is > > OS agnostic,

Re: [libvirt] [RFC] Support for CPUID masking v2

2009-09-22 Thread Daniel Veillard
On Tue, Sep 22, 2009 at 02:25:54PM +0100, Daniel P. Berrange wrote: > On Tue, Sep 22, 2009 at 02:41:08PM +0200, Daniel Veillard wrote: > > IMHO the worst is that the definition of the names. > > First there is gonna be a bunch of them and second their name if you > > rely just on the procinfo out

Re: [libvirt] [RFC] Support for CPUID masking v2

2009-09-22 Thread Daniel P. Berrange
On Tue, Sep 22, 2009 at 02:41:08PM +0200, Daniel Veillard wrote: > > I'm not 100% sure we should represent CPU features as > > NAME > > especially because some features are currently advertised as . > > However, > > extending XML schema every time a new feature is introduced doesn't look > > lik

Re: [libvirt] [RFC] Support for CPUID masking v2

2009-09-22 Thread Daniel Veillard
[ Sending again as my mail from yesterday seems to not have gone out :-( ] On Fri, Sep 04, 2009 at 04:58:25PM +0200, Jiri Denemark wrote: > Hi, > > This is an attempt to provide similar flexibility to CPU ID masking without > being x86-specific and unfriendly to users. As suggested by Dan, we nee

Re: [libvirt] [RFC] Support for CPUID masking v2

2009-09-22 Thread Daniel P. Berrange
On Fri, Sep 04, 2009 at 04:58:25PM +0200, Jiri Denemark wrote: > Firstly, CPU topology and all (actually all that libvirt knows about) CPU > features have to be advertised in host capabilities: > > > > ... > > NAME > >

Re: [libvirt] [RFC] Support for CPUID masking v2

2009-09-13 Thread 'Jiri Denemark'
> > I'm not sure how to deal with named CPUs suggested by Dan. Either we need > > to come up with global set of named CPUs and document what they mean or > > let drivers specify their own named CPUs and advertise them through guest > > capabilities: > > > > ... > > > >

RE: [libvirt] [RFC] Support for CPUID masking v2

2009-09-13 Thread Itamar Heim
> From: libvir-list-boun...@redhat.com [mailto:libvir-list- > Hi, > > This is an attempt to provide similar flexibility to CPU ID masking > without > being x86-specific and unfriendly to users. As suggested by Dan, we need a > way > to specify both CPU flags and topology to achieve this goal. > >