Avi Kivity a...@redhat.com writes:
On 01/07/2010 02:33 PM, Anthony Liguori wrote:
There's another option.
Make cpuid information part of live migration protocol, and then
support something like -cpu Xeon-3550. We would remember the exact
cpuid mask we present to the guest and then we
On 01/06/2010 05:16 PM, Anthony Liguori wrote:
On 01/06/2010 08:48 AM, Dor Laor wrote:
On 01/06/2010 04:32 PM, Avi Kivity wrote:
On 01/06/2010 04:22 PM, Michael S. Tsirkin wrote:
We can probably default -enable-kvm to -cpu host, as long as we
explain
very carefully that if users wish to
On 01/07/2010 10:03 AM, Dor Laor wrote:
We can debate about the exact name/model to represent the Nehalem
family, I don't have an issue with that and actually Intel and Amd
should define it.
AMD and Intel already defined their names (in cat /proc/cpuinfo). They
don't define families, the
On Thu, Jan 07, 2010 at 10:03:28AM +0200, Dor Laor wrote:
On 01/06/2010 05:16 PM, Anthony Liguori wrote:
On 01/06/2010 08:48 AM, Dor Laor wrote:
On 01/06/2010 04:32 PM, Avi Kivity wrote:
On 01/06/2010 04:22 PM, Michael S. Tsirkin wrote:
We can probably default -enable-kvm to -cpu host, as
On 01/07/2010 10:18 AM, Avi Kivity wrote:
On 01/07/2010 10:03 AM, Dor Laor wrote:
We can debate about the exact name/model to represent the Nehalem
family, I don't have an issue with that and actually Intel and Amd
should define it.
AMD and Intel already defined their names (in cat
On 01/07/2010 10:24 AM, Daniel P. Berrange wrote:
On Thu, Jan 07, 2010 at 10:03:28AM +0200, Dor Laor wrote:
On 01/06/2010 05:16 PM, Anthony Liguori wrote:
On 01/06/2010 08:48 AM, Dor Laor wrote:
On 01/06/2010 04:32 PM, Avi Kivity wrote:
On 01/06/2010 04:22 PM, Michael S. Tsirkin wrote:
We
On 01/07/2010 11:11 AM, Dor Laor wrote:
On 01/07/2010 10:18 AM, Avi Kivity wrote:
On 01/07/2010 10:03 AM, Dor Laor wrote:
We can debate about the exact name/model to represent the Nehalem
family, I don't have an issue with that and actually Intel and Amd
should define it.
AMD and Intel
On 01/07/2010 11:24 AM, Avi Kivity wrote:
On 01/07/2010 11:11 AM, Dor Laor wrote:
On 01/07/2010 10:18 AM, Avi Kivity wrote:
On 01/07/2010 10:03 AM, Dor Laor wrote:
We can debate about the exact name/model to represent the Nehalem
family, I don't have an issue with that and actually Intel and
On 01/07/2010 03:40 AM, Dor Laor wrote:
There's no simple solution except to restrict features to what was
available on the first processors.
What's not simple about the above 4 options?
What's a better alternative (that insures users understand it and use
it and guest msi and even skype
On 01/07/2010 01:39 PM, Anthony Liguori wrote:
On 01/07/2010 03:40 AM, Dor Laor wrote:
There's no simple solution except to restrict features to what was
available on the first processors.
What's not simple about the above 4 options?
What's a better alternative (that insures users understand
On 01/07/2010 11:40 AM, Dor Laor wrote:
There's no such thing as Nehalem.
Intel were ok with it. Again, you can name is corei7 or
xeon34234234234, I don't care, the principle remains the same.
There are several processors belonging to the Nehalem family and each
have different features.
On 01/07/2010 01:44 PM, Dor Laor wrote:
So if you had a 2.6.18 kernel and a 2.6.33 kernel, it may be necessary
to say:
(2.6.33) qemu -cpu Nehalem,-syscall
(2.6.18) qemu -cpu Nehalem
Or let qemu do it automatically for you.
qemu on 2.6.33 doesn't know that you're running qemu on 2.6.18 on
On 01/07/2010 01:59 PM, Avi Kivity wrote:
On 01/07/2010 11:40 AM, Dor Laor wrote:
There's no such thing as Nehalem.
Intel were ok with it. Again, you can name is corei7 or
xeon34234234234, I don't care, the principle remains the same.
There are several processors belonging to the Nehalem
On 01/07/2010 02:00 PM, Avi Kivity wrote:
On 01/07/2010 01:44 PM, Dor Laor wrote:
So if you had a 2.6.18 kernel and a 2.6.33 kernel, it may be necessary
to say:
(2.6.33) qemu -cpu Nehalem,-syscall
(2.6.18) qemu -cpu Nehalem
Or let qemu do it automatically for you.
qemu on 2.6.33 doesn't
On 01/07/2010 06:20 AM, Dor Laor wrote:
On 01/07/2010 02:00 PM, Avi Kivity wrote:
On 01/07/2010 01:44 PM, Dor Laor wrote:
So if you had a 2.6.18 kernel and a 2.6.33 kernel, it may be necessary
to say:
(2.6.33) qemu -cpu Nehalem,-syscall
(2.6.18) qemu -cpu Nehalem
Or let qemu do it
On 01/07/2010 02:33 PM, Anthony Liguori wrote:
There's another option.
Make cpuid information part of live migration protocol, and then
support something like -cpu Xeon-3550. We would remember the exact
cpuid mask we present to the guest and then we could validate that we
can obtain the
On Thu, Jan 07, 2010 at 02:40:34PM +0200, Avi Kivity wrote:
On 01/07/2010 02:33 PM, Anthony Liguori wrote:
There's another option.
Make cpuid information part of live migration protocol, and then
support something like -cpu Xeon-3550. We would remember the exact
cpuid mask we present
On 01/07/2010 02:47 PM, Daniel P. Berrange wrote:
With the introduction of the new -device spport, there's no need to
replay hotplug events in order any more. Instead just use static
PCI addresses when starting the guest, and the same addresses after
migration. You could argue that QEMU should
On 01/07/2010 06:40 AM, Avi Kivity wrote:
On 01/07/2010 02:33 PM, Anthony Liguori wrote:
There's another option.
Make cpuid information part of live migration protocol, and then
support something like -cpu Xeon-3550. We would remember the exact
cpuid mask we present to the guest and then
On 01/07/2010 03:14 PM, Anthony Liguori wrote:
On 01/07/2010 06:40 AM, Avi Kivity wrote:
On 01/07/2010 02:33 PM, Anthony Liguori wrote:
There's another option.
Make cpuid information part of live migration protocol, and then
support something like -cpu Xeon-3550. We would remember the exact
On Tue, Jan 05, 2010 at 06:10:10PM -0600, Anthony Liguori wrote:
For instance, Xeon-X5570 should be a least common denominator for
Nehalem processors. It's probably better for users too. It's easier
for them to answer do I have anything older than a Xeon-X5570 than
to ask do I have any
On 01/06/2010 11:44 AM, Daniel P. Berrange wrote:
This is all a very long way of saying that mgmt apps based on libvirt
won't care about model names exposed in /proc/cpuinfo so there's no
particular need to have a direct mapping from them to QEMU for libvirt's
needs.
There is still a need
On Wed, Jan 06, 2010 at 11:54:16AM +0200, Avi Kivity wrote:
On 01/06/2010 11:44 AM, Daniel P. Berrange wrote:
This is all a very long way of saying that mgmt apps based on libvirt
won't care about model names exposed in /proc/cpuinfo so there's no
particular need to have a direct mapping
On 01/06/2010 12:21 PM, Daniel P. Berrange wrote:
On Wed, Jan 06, 2010 at 11:54:16AM +0200, Avi Kivity wrote:
On 01/06/2010 11:44 AM, Daniel P. Berrange wrote:
This is all a very long way of saying that mgmt apps based on libvirt
won't care about model names exposed in /proc/cpuinfo
On 01/05/2010 09:25 PM, Avi Kivity wrote:
Typically, there is at least a little sanity naming for these cases.
For instance, any Xeon W35xx should have the same features. A Xeon
W55xx may be different.
It's not going to be easy to include every possible model. It's a
hard problem for
On Wed, Jan 06, 2010 at 07:25:10AM -0600, Anthony Liguori wrote:
On 01/05/2010 09:25 PM, Avi Kivity wrote:
Typically, there is at least a little sanity naming for these cases.
For instance, any Xeon W35xx should have the same features. A Xeon
W55xx may be different.
It's not going to be
On 01/06/2010 03:25 PM, Anthony Liguori wrote:
On 01/05/2010 09:25 PM, Avi Kivity wrote:
Typically, there is at least a little sanity naming for these
cases. For instance, any Xeon W35xx should have the same features.
A Xeon W55xx may be different.
It's not going to be easy to include
On 01/06/2010 07:47 AM, Avi Kivity wrote:
On 01/06/2010 03:25 PM, Anthony Liguori wrote:
On 01/05/2010 09:25 PM, Avi Kivity wrote:
Typically, there is at least a little sanity naming for these
cases. For instance, any Xeon W35xx should have the same
features. A Xeon W55xx may be different.
On 01/06/2010 03:49 PM, Anthony Liguori wrote:
I think that's workable but I think there may be some subtle issues
especially across qemu versions. Can you give an example of what
you would expect the output to be?
- { command: query-cpu-capabalities }
- { result: { features: [vm, fpu,
On 06.01.2010, at 14:54, Avi Kivity wrote:
On 01/06/2010 03:49 PM, Anthony Liguori wrote:
I think that's workable but I think there may be some subtle issues
especially across qemu versions. Can you give an example of what you
would expect the output to be?
- { command:
On 01/06/2010 03:55 PM, Alexander Graf wrote:
Well, we can freeze qemu64 if we wish. That's still not 100% accurate since
kvm can remove features from qemu64.
-cpu none,+flags,vendor=foo,cache=bar,ad=nauseum?
I'd rather add a kvm cpu and leave the qemu64 one to qemu tcg features.
On Wed, Jan 06, 2010 at 03:58:01PM +0200, Avi Kivity wrote:
On 01/06/2010 03:55 PM, Alexander Graf wrote:
Well, we can freeze qemu64 if we wish. That's still not 100% accurate
since kvm can remove features from qemu64.
-cpu none,+flags,vendor=foo,cache=bar,ad=nauseum?
I'd rather
On 01/06/2010 04:22 PM, Michael S. Tsirkin wrote:
We can probably default -enable-kvm to -cpu host, as long as we explain
very carefully that if users wish to preserve cpu features across
upgrades, they can't depend on the default.
Hardware upgrades or software upgrades?
Yes.
--
On 01/06/2010 04:32 PM, Avi Kivity wrote:
On 01/06/2010 04:22 PM, Michael S. Tsirkin wrote:
We can probably default -enable-kvm to -cpu host, as long as we explain
very carefully that if users wish to preserve cpu features across
upgrades, they can't depend on the default.
Hardware upgrades or
On Wed, Jan 06, 2010 at 04:32:07PM +0200, Avi Kivity wrote:
On 01/06/2010 04:22 PM, Michael S. Tsirkin wrote:
We can probably default -enable-kvm to -cpu host, as long as we explain
very carefully that if users wish to preserve cpu features across
upgrades, they can't depend on the default.
On 01/06/2010 07:54 AM, Avi Kivity wrote:
On 01/06/2010 03:49 PM, Anthony Liguori wrote:
I think that's workable but I think there may be some subtle issues
especially across qemu versions. Can you give an example of what
you would expect the output to be?
- { command:
On 01/06/2010 08:48 AM, Dor Laor wrote:
On 01/06/2010 04:32 PM, Avi Kivity wrote:
On 01/06/2010 04:22 PM, Michael S. Tsirkin wrote:
We can probably default -enable-kvm to -cpu host, as long as we
explain
very carefully that if users wish to preserve cpu features across
upgrades, they can't
On Tue, Jan 05, 2010 at 06:10:10PM -0600, Anthony Liguori wrote:
Typically, there is at least a little sanity naming for these cases.
For instance, any Xeon W35xx should have the same features. A Xeon
W55xx may be different.
It doesn't work that way for intel. For example:
Core 2 Duo
Anthony Liguori wrote:
On 12/21/2009 02:28 AM, Dor Laor wrote:
John's new cpu definitions are the exact solution for this issue - all
users, whether using mgmt app or direct qemu (this is no user, this is
a developer/hacker/other, let's do not optimize this case) should use
the various 'real'
On 12/23/2009 04:32 AM, Avi Kivity wrote:
On 12/22/2009 06:12 PM, Anthony Liguori wrote:
I think the only two Fully Correct approachs are to support a very
specific CPU (e.g. Xeon-X5270) or provide the ability to individually
tweak cpu flags.
Yes. By a curious coincidence these are what
On 01/06/2010 02:10 AM, Anthony Liguori wrote:
On 12/23/2009 04:32 AM, Avi Kivity wrote:
On 12/22/2009 06:12 PM, Anthony Liguori wrote:
I think the only two Fully Correct approachs are to support a very
specific CPU (e.g. Xeon-X5270) or provide the ability to
individually tweak cpu flags.
On 12/22/2009 06:12 PM, Anthony Liguori wrote:
I think the only two Fully Correct approachs are to support a very
specific CPU (e.g. Xeon-X5270) or provide the ability to individually
tweak cpu flags.
Yes. By a curious coincidence these are what the hardware vendors
define (unlike compat
On 12/22/2009 12:51 AM, john cooper wrote:
Dor Laor wrote:
Qemu will check the required cpuid of the cpu model on the host and
refuse to load otherwise. When moving to this model, migration can be
simplified too since there are fewer combination, and one can choose
performance over migration
Dor Laor wrote:
On 12/22/2009 12:51 AM, john cooper wrote:
Dor Laor wrote:
Qemu will check the required cpuid of the cpu model on the host and
refuse to load otherwise. When moving to this model, migration can be
simplified too since there are fewer combination, and one can choose
On 12/21/2009 02:28 AM, Dor Laor wrote:
John's new cpu definitions are the exact solution for this issue - all
users, whether using mgmt app or direct qemu (this is no user, this is
a developer/hacker/other, let's do not optimize this case) should use
the various 'real' cpu definitions like
Michael S. Tsirkin wrote:
Bootup on different machines has some of the same issues as migration.
Consider a 64 bit guest as an example, I think it can not boot on a 32
bit host OS with kvm. I think you can use tcg, but it will be slower.
Same thing applies to other CPU features.
Alas, perhaps
Anthony Liguori wrote:
It would be insane to emulate sse3 too.
It doesn't sound too ridiculous if TCG is involved, provided the
switching between TCG and KVM isn't too rapid. TCG is slower, but
it's not ridiculously slow.
Though, I don't expect anyone to volunteer to implement it :-)
how
On 12/21/2009 09:43 AM, Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 11:59:43AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
Windows is a mystery box, so we can speculate as much as we want about it.
If you don't like something just say it may break Windows :) Losing
activation does sound
On 12/20/2009 07:18 PM, Michael S. Tsirkin wrote:
Hmm, then, shouldn't either kvm or qemu mask features that we do not
emulate well enough to make windows not crash?
-cpu host does that already, no?
Alex
I expected so, but Avi here seems to say windows will crash if you
use a
On 12/20/2009 07:59 PM, Anthony Liguori wrote:
Gleb Natapov wrote:
Windows is a mystery box, so we can speculate as much as we want
about it.
If you don't like something just say it may break Windows :) Losing
activation does sound like an issue too.
Downgrading seems more likely to cause
On Mon, Dec 21, 2009 at 01:12:26PM +0200, Avi Kivity wrote:
On 12/20/2009 07:18 PM, Michael S. Tsirkin wrote:
Hmm, then, shouldn't either kvm or qemu mask features that we do not
emulate well enough to make windows not crash?
-cpu host does that already, no?
Alex
I expected
On 21.12.2009, at 12:18, Michael S. Tsirkin wrote:
On Mon, Dec 21, 2009 at 01:12:26PM +0200, Avi Kivity wrote:
On 12/20/2009 07:18 PM, Michael S. Tsirkin wrote:
Hmm, then, shouldn't either kvm or qemu mask features that we do not
emulate well enough to make windows not crash?
-cpu host
On 12/21/2009 1:12 PM, Avi Kivity wrote:
On 12/20/2009 07:18 PM, Michael S. Tsirkin wrote:
Hmm, then, shouldn't either kvm or qemu mask features that we do not
emulate well enough to make windows not crash?
-cpu host does that already, no?
Alex
I expected so, but Avi here seems to say
On 21.12.2009, at 12:38, Michael S. Tsirkin wrote:
On Mon, Dec 21, 2009 at 12:22:53PM +0100, Alexander Graf wrote:
On 21.12.2009, at 12:18, Michael S. Tsirkin wrote:
On Mon, Dec 21, 2009 at 01:12:26PM +0200, Avi Kivity wrote:
On 12/20/2009 07:18 PM, Michael S. Tsirkin wrote:
Hmm,
On 12/21/2009 01:18 PM, Michael S. Tsirkin wrote:
No, Windows tries to detect changes in your hardware and assumes that if
too many things change, you might be a pirate and requires you to phone
their offices to re-authenticate.
How often does a casual user upgrade his host CPU?
I
On Mon, Dec 21, 2009 at 12:45:26PM +0100, Alexander Graf wrote:
On 21.12.2009, at 12:38, Michael S. Tsirkin wrote:
On Mon, Dec 21, 2009 at 12:22:53PM +0100, Alexander Graf wrote:
On 21.12.2009, at 12:18, Michael S. Tsirkin wrote:
On Mon, Dec 21, 2009 at 01:12:26PM +0200, Avi
On 12/21/2009 01:45 PM, Alexander Graf wrote:
Well, we have two groups:
1) Casual user w/o management app
2) Enterprise user w/ management app
So I clearly belong to the first group.
3) Developer/power user who knows what he's about.
You could simply add -cpu qemu64 for those guests
On Mon, Dec 21, 2009 at 02:04:47PM +0200, Avi Kivity wrote:
On 12/21/2009 01:18 PM, Michael S. Tsirkin wrote:
No, Windows tries to detect changes in your hardware and assumes that if
too many things change, you might be a pirate and requires you to phone
their offices to re-authenticate.
On 12/21/2009 02:04 PM, Michael S. Tsirkin wrote:
I think so - if this does not happen a lot, it's not a problem to phone home,
right?
I'm sure it's very annoying when it happens.
--
error compiling committee.c: too many arguments to function
On Mon, Dec 21, 2009 at 02:09:31PM +0200, Avi Kivity wrote:
On 12/21/2009 02:04 PM, Michael S. Tsirkin wrote:
I think so - if this does not happen a lot, it's not a problem to phone home,
right?
I'm sure it's very annoying when it happens.
It could well be less annoying than having
Avi Kivity wrote:
On 12/20/2009 07:59 PM, Anthony Liguori wrote:
Gleb Natapov wrote:
Windows is a mystery box, so we can speculate as much as we want
about it.
If you don't like something just say it may break Windows :) Losing
activation does sound like an issue too.
Downgrading seems more
On 12/21/2009 05:05 AM, Avi Kivity wrote:
On 12/21/2009 01:45 PM, Alexander Graf wrote:
Well, we have two groups:
1) Casual user w/o management app
2) Enterprise user w/ management app
So I clearly belong to the first group.
3) Developer/power user who knows what he's about.
On Mon, Dec 21, 2009 at 06:45:22AM -0700, David S. Ahern wrote:
On 12/21/2009 05:05 AM, Avi Kivity wrote:
On 12/21/2009 01:45 PM, Alexander Graf wrote:
Well, we have two groups:
1) Casual user w/o management app
2) Enterprise user w/ management app
So I clearly belong to the
On 12/21/2009 06:51 AM, Michael S. Tsirkin wrote:
On Mon, Dec 21, 2009 at 06:45:22AM -0700, David S. Ahern wrote:
On 12/21/2009 05:05 AM, Avi Kivity wrote:
On 12/21/2009 01:45 PM, Alexander Graf wrote:
Well, we have two groups:
1) Casual user w/o management app
2) Enterprise user w/
On 12/21/2009 03:45 PM, David S. Ahern wrote:
On 12/21/2009 05:05 AM, Avi Kivity wrote:
On 12/21/2009 01:45 PM, Alexander Graf wrote:
Well, we have two groups:
1) Casual user w/o management app
2) Enterprise user w/ management app
So I clearly belong to the first group.
On 12/21/2009 02:59 PM, Andre Przywara wrote:
KVM's cpuid filter doesn't help here because it won't attempt to
mask things like sse3. It would be insane to emulate sse3 too.
It does expose sse3 support (called pni in Linux IIRC). Not sure if
qemu masks it, but the information is there.
Dor Laor wrote:
Qemu will check the required cpuid of the cpu model on the host and
refuse to load otherwise. When moving to this model, migration can be
simplified too since there are fewer combination, and one can choose
performance over migration flexibility and wise versa.
Due to the
On 12/15/2009 07:56 PM, Michael S. Tsirkin wrote:
I see.
But unfortunately this bit has multiple meanings
for 64/32 bit, kvm does not know whether you will
run a 32 bit or a 64 bit program.
This is a cpu architecture bug.
Correct. One bit is used for two separate features (syscall-32
On 12/14/2009 10:18 PM, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
This might help 32 bit guests, but not guests with 64 bit
kernel and 32 bit userspace (my case) because all 64 bit
CPUs advertise syscall bit in cpuid. Thus 64 bit guests
do not seem to even bother checking this bit:
AMD +
Avi Kivity wrote:
Maybe we should make -cpu host the default. That will give the best
performance for casual users, more testing for newer features, and
will force management apps to treat migration much more seriously.
The downside is that casual users upgrading their machines might
On 12/20/2009 04:48 PM, Anthony Liguori wrote:
Avi Kivity wrote:
Maybe we should make -cpu host the default. That will give the best
performance for casual users, more testing for newer features, and
will force management apps to treat migration much more seriously.
The downside is that
Avi Kivity wrote:
On 12/20/2009 04:48 PM, Anthony Liguori wrote:
Avi Kivity wrote:
Maybe we should make -cpu host the default. That will give the best
performance for casual users, more testing for newer features, and
will force management apps to treat migration much more seriously.
The
On 12/20/2009 05:33 PM, Anthony Liguori wrote:
- casual (non-management-app-using) users will start seeing problems
with Windows guests unless they change their command lines
Assuming their migrating across different CPU types.
I was thinking about upgrading their host cpu. I doubt you'd
On Sun, Dec 20, 2009 at 05:36:57PM +0200, Avi Kivity wrote:
On 12/20/2009 05:33 PM, Anthony Liguori wrote:
- casual (non-management-app-using) users will start seeing
problems with Windows guests unless they change their command
lines
Assuming their migrating across different CPU types.
On 12/20/2009 05:38 PM, Gleb Natapov wrote:
I was thinking about upgrading their host cpu. I doubt you'd live
migrate without a management app.
And what about VM on disk-on-key or VM image on NFS that can be started
from different locations?
That needs a config file anyway to
On Sun, Dec 20, 2009 at 05:40:53PM +0200, Avi Kivity wrote:
On 12/20/2009 05:38 PM, Gleb Natapov wrote:
I was thinking about upgrading their host cpu. I doubt you'd live
migrate without a management app.
And what about VM on disk-on-key or VM image on NFS that can be started
from
On 12/20/2009 05:49 PM, Michael S. Tsirkin wrote:
That needs a config file anyway to let the host qemu know which machine
level (e.g. -M pc-0.11) to use.
Hmm, yes, but will qemu ship config files which configure host cpu
as well?
If it doesn't, the management app will have to to
On Sun, Dec 20, 2009 at 11:49:40AM +0200, Avi Kivity wrote:
On 12/14/2009 10:18 PM, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
This might help 32 bit guests, but not guests with 64 bit
kernel and 32 bit userspace (my case) because all 64 bit
CPUs advertise syscall bit in cpuid. Thus 64
On 12/20/2009 05:51 PM, Michael S. Tsirkin wrote:
Maybe we should make -cpu host the default. That will give the best
performance for casual users, more testing for newer features, and will
force management apps to treat migration much more seriously. The
downside is that casual users
On Sun, Dec 20, 2009 at 05:59:33PM +0200, Avi Kivity wrote:
On 12/20/2009 05:51 PM, Michael S. Tsirkin wrote:
Maybe we should make -cpu host the default. That will give the best
performance for casual users, more testing for newer features, and will
force management apps to treat migration
On 20.12.2009, at 17:56, Michael S. Tsirkin wrote:
On Sun, Dec 20, 2009 at 05:59:33PM +0200, Avi Kivity wrote:
On 12/20/2009 05:51 PM, Michael S. Tsirkin wrote:
Maybe we should make -cpu host the default. That will give the best
performance for casual users, more testing for newer
On Sun, Dec 20, 2009 at 06:17:02PM +0100, Alexander Graf wrote:
On 20.12.2009, at 17:56, Michael S. Tsirkin wrote:
On Sun, Dec 20, 2009 at 05:59:33PM +0200, Avi Kivity wrote:
On 12/20/2009 05:51 PM, Michael S. Tsirkin wrote:
Maybe we should make -cpu host the default. That will give
On 20.12.2009, at 18:18, Michael S. Tsirkin wrote:
On Sun, Dec 20, 2009 at 06:17:02PM +0100, Alexander Graf wrote:
On 20.12.2009, at 17:56, Michael S. Tsirkin wrote:
On Sun, Dec 20, 2009 at 05:59:33PM +0200, Avi Kivity wrote:
On 12/20/2009 05:51 PM, Michael S. Tsirkin wrote:
Maybe we
On Sun, Dec 20, 2009 at 07:18:22PM +0200, Michael S. Tsirkin wrote:
On Sun, Dec 20, 2009 at 06:17:02PM +0100, Alexander Graf wrote:
On 20.12.2009, at 17:56, Michael S. Tsirkin wrote:
On Sun, Dec 20, 2009 at 05:59:33PM +0200, Avi Kivity wrote:
On 12/20/2009 05:51 PM, Michael S.
On 20.12.2009, at 18:23, Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 07:18:22PM +0200, Michael S. Tsirkin wrote:
On Sun, Dec 20, 2009 at 06:17:02PM +0100, Alexander Graf wrote:
On 20.12.2009, at 17:56, Michael S. Tsirkin wrote:
On Sun, Dec 20, 2009 at 05:59:33PM +0200, Avi Kivity wrote:
On Sun, Dec 20, 2009 at 06:29:11PM +0100, Alexander Graf wrote:
On 20.12.2009, at 18:23, Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 07:18:22PM +0200, Michael S. Tsirkin wrote:
On Sun, Dec 20, 2009 at 06:17:02PM +0100, Alexander Graf wrote:
On 20.12.2009, at 17:56, Michael S. Tsirkin
Gleb Natapov wrote:
Windows is a mystery box, so we can speculate as much as we want about it.
If you don't like something just say it may break Windows :) Losing
activation does sound like an issue too.
Downgrading seems more likely to cause problems. Considering running
mplayer in a
On 20.12.2009, at 18:59, Anthony Liguori wrote:
Gleb Natapov wrote:
Windows is a mystery box, so we can speculate as much as we want about it.
If you don't like something just say it may break Windows :) Losing
activation does sound like an issue too.
Downgrading seems more likely to
On Sun, Dec 20, 2009 at 11:59:43AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
Windows is a mystery box, so we can speculate as much as we want about it.
If you don't like something just say it may break Windows :) Losing
activation does sound like an issue too.
Downgrading seems
On Sun, Dec 20, 2009 at 11:59:43AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
Windows is a mystery box, so we can speculate as much as we want about it.
If you don't like something just say it may break Windows :) Losing
activation does sound like an issue too.
Downgrading seems more
On Sun, Dec 20, 2009 at 07:06:03PM +0100, Alexander Graf wrote:
On 20.12.2009, at 18:59, Anthony Liguori wrote:
Gleb Natapov wrote:
Windows is a mystery box, so we can speculate as much as we want about it.
If you don't like something just say it may break Windows :) Losing
activation
Anthony Liguori wrote:
Gleb Natapov wrote:
I thought KVM emulates the syscall instruction? I swear I've seen
patches for that.
It is. Starting from 2.6.32.
Okay, so this is a performance vs. migration compatibility issue then?
BTW, couldn't we just not advertise syscall in cpuid?
On Mon, Dec 14, 2009 at 03:49:39PM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 02:54:49PM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 02:18:33PM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
On Tue, Dec 15, 2009 at 11:37:34AM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
I don't think it does: cpuid is an unpriveledged operation,
is it not?
We (qemu) ask the kernel (kvm.ko) to filter out the features bits from
the cpuid we expose to the guest in order to remove
Michael S. Tsirkin wrote:
Hi!
I have a linux guest where init crashes during boot with invalid opcode error
with kernel 2.6.31, but works fine with kernel 2.6.32.
It also works fine even with 2.6.31 with qemu-kvm.
With Gleb's help, we figured out that the opcode in question is syscall, which
is
On Mon, Dec 14, 2009 at 01:44:22PM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
Hi!
I have a linux guest where init crashes during boot with invalid opcode error
with kernel 2.6.31, but works fine with kernel 2.6.32.
It also works fine even with 2.6.31 with qemu-kvm.
With Gleb's
Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 01:44:22PM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
Hi!
I have a linux guest where init crashes during boot with invalid opcode error
with kernel 2.6.31, but works fine with kernel 2.6.32.
It also works fine even with
On Mon, Dec 14, 2009 at 01:57:29PM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 01:44:22PM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
Hi!
I have a linux guest where init crashes during boot with invalid opcode
error
with kernel 2.6.31, but
Gleb Natapov wrote:
I thought KVM emulates the syscall instruction? I swear I've seen
patches for that.
It is. Starting from 2.6.32.
Okay, so this is a performance vs. migration compatibility issue then?
BTW, couldn't we just not advertise syscall in cpuid? That should fix
it too
On Mon, Dec 14, 2009 at 02:02:03PM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
I thought KVM emulates the syscall instruction? I swear I've seen
patches for that.
It is. Starting from 2.6.32.
Okay, so this is a performance vs. migration compatibility issue then?
BTW, couldn't we
1 - 100 of 106 matches
Mail list logo
