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
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 v
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 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 leve
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 wrote:
> On Thu, Sep 03, 2009 at 11:19:47AM +0300, Dor Laor wrot
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
> > 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
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
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,
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
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
[ 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
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
>
>
> > 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:
> >
> > ...
> >
> >
> 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
fe
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
> >>>exampl
> > 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:
> ...
> >
> > ...
> >
> >
> >
> >
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 adverti
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:
...
>
> ...
>
>
>
>
2009/9/2 Jiri Denemark :
> Hi,
>
> We need to provide support for CPU ID masking. Xen and VMware ESX are examples
> of current hypervisors which support such masking.
[...]
>
> ...
>
>
>
>
>
>
> :::1010::::
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:
...
When a driver supports cpuid
24 matches
Mail list logo
