Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

["Michael S. Tsirkin" <mst@redhat.com>]

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 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 windows will crash if you
> >>>>> use a new CPU with it ...
> >>>>> 
> >>>> 
> >>>> 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 tend to have my VM images on an NFS share and expect them to work properly on all PCs I work on.
> >> So I guess the answer is "often"?
> >> 
> >> Alex
> > 
> > Yes but you are not a casual user, are you?  
> 
> 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.

No, you are in
3) virtualization hacker without management app
:)

> > Consider a 64 bit guest to
> > see why moving a VM across machines needs some planning.
> 
> -ENOPARSE
> 
> We're still talking about bootup on different machines, not migration / loadvm.
> 
> Alex

Translation: your requirement "work on all PCs I work on" might only be satisfied
by specifying the set of PCs you work on.

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.

Many guests reconfigure themselves when you swap harware under them.
This makes it easier to move such guests between machines, or change
qemu configuration and still reuse guest image.  Others might record
hardware state on setup (64 bit above is one such example) making such
changes more painful.

I do think it would be good for us to supply management with utilities
that analyse system hardware features relevant to qemu in a portable
way. Could be some qemu monitor command, even.  Management would be able
to decide between using least common denominator and not supporting some
hosts.

-- 
MST