On 10/13/2009 11:40 AM, Daniel P. Berrange wrote:
On Tue, Oct 13, 2009 at 02:56:41AM -0400, john cooper wrote:
Dor Laor wrote:
What about another approach for the cpuid issue:
I think that dealing with specific flags is pretty error prone on all
levels - virt-mgr, libvirt, qemu, migration, and
Dor Laor wrote:
What about another approach for the cpuid issue:
I think that dealing with specific flags is pretty error prone on all
levels - virt-mgr, libvirt, qemu, migration, and even the guest.
..and performance verification, QA, and the average end user.
Unless we reduce all possible
On Tue, Oct 13, 2009 at 02:56:41AM -0400, john cooper wrote:
Dor Laor wrote:
What about another approach for the cpuid issue:
I think that dealing with specific flags is pretty error prone on all
levels - virt-mgr, libvirt, qemu, migration, and even the guest.
..and performance
On Sun, Oct 11, 2009 at 11:44:04AM +0200, Dor Laor wrote:
On 10/09/2009 12:58 PM, Mukesh G wrote:
Speaking from an x86 angle,providing an ability to enable or disable
high level constructs like SSE instead of low level constructs, will
make it easy to understand.
ain't SSE a low level
On 10/09/2009 12:58 PM, Mukesh G wrote:
Speaking from an x86 angle,providing an ability to enable or disable
high level constructs like SSE instead of low level constructs, will
make it easy to understand.
ain't SSE a low level construct too?
What about another approach for the cpuid issue:
I
Speaking from an x86 angle,providing an ability to enable or disable
high level constructs like SSE instead of low level constructs, will
make it easy to understand.
Thanks
Mukesh
On Thu, Sep 3, 2009 at 3:09 PM, Daniel P. Berrange berra...@redhat.com wrote:
On Thu, Sep 03, 2009 at 11:19:47AM
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.
On 09/02/2009 07:09 PM, Daniel P. Berrange wrote:
On Wed, Sep 02, 2009 at 11:59:39AM -0400, Jim Paris wrote:
Jiri Denemark wrote:
Hi,
We need to provide support for CPU ID masking. Xen and VMware ESX are examples
of current hypervisors which support such masking.
My proposal is to define new
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
We need to provide support for CPU ID masking. Xen and VMware ESX are
examples
of current hypervisors which support such masking.
My proposal is to define new 'cpuid' feature advertised in guest
capabilities:
...
domain type='xen' id='42'
...
features
pae/
On Thu, Sep 03, 2009 at 11:19:47AM +0300, Dor Laor wrote:
On 09/02/2009 07:09 PM, Daniel P. Berrange wrote:
On Wed, Sep 02, 2009 at 11:59:39AM -0400, Jim Paris wrote:
Jiri Denemark wrote:
Hi,
We need to provide support for CPU ID masking. Xen and VMware ESX are
examples
of current
Hi,
We need to provide support for CPU ID masking. Xen and VMware ESX are examples
of current hypervisors which support such masking.
My proposal is to define new 'cpuid' feature advertised in guest
capabilities:
guest
...
features
cpuid/
/feature
2009/9/2 Jiri Denemark jdene...@redhat.com:
Hi,
We need to provide support for CPU ID masking. Xen and VMware ESX are examples
of current hypervisors which support such masking.
[...]
domain type='xen' id='42'
...
features
pae/
acpi/
apic/
cpuid
Jiri Denemark wrote:
Hi,
We need to provide support for CPU ID masking. Xen and VMware ESX are examples
of current hypervisors which support such masking.
My proposal is to define new 'cpuid' feature advertised in guest
capabilities:
...
domain type='xen' id='42'
...
features
On Wed, Sep 02, 2009 at 11:59:39AM -0400, Jim Paris wrote:
Jiri Denemark wrote:
Hi,
We need to provide support for CPU ID masking. Xen and VMware ESX are
examples
of current hypervisors which support such masking.
My proposal is to define new 'cpuid' feature advertised in guest
24 matches
Mail list logo
