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 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 features, and
> >>>>>>> will
> >>>>>>> force management apps to treat migration much more seriously. The
> >>>>>>> downside is that casual users upgrading their machines might
> >>>>>>> experience
> >>>>>>> issues with Windows. Feature compatibility is not just about
> >>>>>>> migration.
> >>>>>>>
> >>>>>> This seems very aggressive. Can't we whitelist features that we know
> >>>>>> about? Further, doesn't KVM already do this?
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> It does, but without -cpuid host you're stuck with qemu64 (kvm.ko
> >>>>> doesn't add features userspace didn't request).
> >>>>
> >>>> 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 ...
> >>
> > Windows _may_ crash if you'll _upgrade_ your _host_ CPU.
>
> Uh. It may lose activation I guess. But apart from that I can't see how it'd
> break as long as you don't expect loadvm to work.
>
> Anybody mind to go into a bit more detail here? :-)
>
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.
--
Gleb.
