From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37059) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6jWD-0003YJ-RW for qemu-devel@nongnu.org; Sun, 11 Mar 2012 10:13:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S6jWB-0005bz-Sj for qemu-devel@nongnu.org; Sun, 11 Mar 2012 10:13:05 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:59938) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S6jWB-0005bp-OB for qemu-devel@nongnu.org; Sun, 11 Mar 2012 10:13:03 -0400 Received: by yenr5 with SMTP id r5so2227619yen.4 for ; Sun, 11 Mar 2012 07:13:01 -0700 (PDT) Message-ID: <4F5CB2EA.10000@codemonkey.ws> Date: Sun, 11 Mar 2012 09:12:58 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> In-Reply-To: <20120311132755.GJ17882@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: libvir-list@redhat.com, qemu-devel@nongnu.org, Avi Kivity , Jiri Denemark , "arch@ovirt.org" On 03/11/2012 08:27 AM, Gleb Natapov wrote: > On Sat, Mar 10, 2012 at 12:24:47PM -0600, Anthony Liguori wrote: >> Let's step back here. >> >> Why are you writing these patches? It's probably not because you >> have a desire to say -cpu Westmere when you run QEMU on your laptop. >> I'd wager to say that no human has ever done that or that if they >> had, they did so by accident because they read documentation and >> thought they had to. >> > I'd be glad if QEMU will chose -cpu Westmere for me if it detects > Westmere host CPU as a default. This is -cpu best that Alex proposed FWIW. >> Humans probably do one of two things: 1) no cpu option or 2) -cpu host. >> > And both are not optimal. Actually both are bad. First one because > default cpu is very conservative and the second because there is no > guaranty that guest will continue to work after qemu or kernel upgrade. > > Let me elaborate about the later. Suppose host CPU has kill_guest > feature and at the time a guest was installed it was not implemented by > kvm. Since it was not implemented by kvm it was not present in vcpu > during installation and the guest didn't install "workaround kill_guest" > module. Now unsuspecting user upgrades the kernel and tries to restart > the guest and fails. He writes angry letter to qemu-devel and is asked to > reinstall his guest and move along. -cpu best wouldn't solve this. You need a read/write configuration file where QEMU probes the available CPU and records it to be used for the lifetime of the VM. >> So then why are you introducing -cpu Westmere? Because ovirt-engine >> has a concept of datacenters and the entire datacenter has to use a >> compatible CPU model to allow migration compatibility. Today, the >> interface that ovirt-engine exposes is based on CPU codenames. >> Presumably ovirt-engine wants to add a Westmere CPU group and as >> such have levied a requirement down the stack to QEMU. >> > First of all this is not about live migration only. Guest visible vcpu > should not change after guest reboot (or hibernate/resume) too. And > second this concept exists with only your laptop and single guest on it > too. There are three inputs into a "CPU model module": 1) host cpu, 2) > qemu capabilities, 3) kvm capabilities. With datacenters scenario all > three can change, with your laptop only last two can change (first one > can change too when you'll get new laptop) , but the net result is that > guest visible cpuid can change and it shouldn't. This is the goal of > introducing -cpu Westmere, to prevent it from happening. This discussion isn't about whether QEMU should have a Westmere processor definition. In fact, I think I already applied that patch. It's a discussion about how we handle this up and down the stack. The question is who should define and manage CPU compatibility. Right now QEMU does to a certain degree, libvirt discards this and does it's own thing, and VDSM/ovirt-engine assume that we're providing something and has built a UI around it. What I'm proposing we consider: have VDSM manage CPU definitions in order to provide a specific user experience in ovirt-engine. We would continue to have Westmere/etc in QEMU exposed as part of the user configuration. But I don't think it makes a lot of sense to have to modify QEMU any time a new CPU comes out. Regards, Anthony Liguori