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:
host
cpu
...
features
featureNAME/feature
[ 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 need a
On Tue, Sep 22, 2009 at 02:41:08PM +0200, Daniel Veillard wrote:
I'm not 100% sure we should represent CPU features as
featureNAME/feature
especially because some features are currently advertised as NAME/.
However,
extending XML schema every time a new feature is introduced doesn't
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 output
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, in
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 and VMWare
I'm not 100% sure we should represent CPU features as
featureNAME/feature
especially because some features are currently advertised as NAME/.
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
On Tue, Sep 22, 2009 at 05:51:02PM +0200, Jiri Denemark wrote:
I'm not 100% sure we should represent CPU features as
featureNAME/feature
especially because some features are currently advertised as NAME/.
However,
extending XML schema every time a new feature is introduced doesn't
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:
guest
...
cpu model=NAME
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.
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.
Firstly, CPU topology and all (actually all that libvirt knows about) CPU
11 matches
Mail list logo
