Avi Kivity 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 could v
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
c
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 we
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 p
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
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 sam
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 automatic
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 kn
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 f
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
a
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: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 i
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 appli
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 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 alrea
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 ca
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 /proc/cpui
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 -c
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 w
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 preser
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
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 dep
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: query-cpu-capabal
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 de
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 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.
--
err
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?
>>>
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 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?
>>>
>>>
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 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: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 every
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
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 manag
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 s
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 map
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 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
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/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 th
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 variou
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 c
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 li
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, perh
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 -cp
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 choo
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 fl
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 above
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.
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.
3)
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
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 c
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
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 mor
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
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: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-authent
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 tha
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
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 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:
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, then, shouldn't either kvm or qemu ma
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 windo
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
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?
>>>
>>>
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 p
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 n
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 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
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
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.
>>
>
> Downgra
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
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 gu
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, Mic
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
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, Mic
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:
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.
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
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
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 upgradi
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 cpui
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 th
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
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 let
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 differe
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 l
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 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 ca
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
exper
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 +
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 and
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 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
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 feature bits it
(kvm.ko) does not support.
Regards,
Anthony Liguori
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:
> Mic
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:
This might help 32 bit guests, but not guests with 64
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:
>>>
This might help 32 bit guests, but not guests with 64 bit
kernel and 32 bit userspa
Michael S. Tsirkin wrote:
On Mon, Dec 14, 2009 at 02:18:33PM -0600, 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
On Mon, Dec 14, 2009 at 02:18:33PM -0600, 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 bot
1 - 100 of 110 matches
Mail list logo
