From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54022) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Szsij-00053y-D8 for qemu-devel@nongnu.org; Fri, 10 Aug 2012 13:09:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Szsig-0005xy-NX for qemu-devel@nongnu.org; Fri, 10 Aug 2012 13:09:57 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]:43206) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Szsig-0005xu-JU for qemu-devel@nongnu.org; Fri, 10 Aug 2012 13:09:54 -0400 Received: from /spool/local by e6.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 10 Aug 2012 13:09:54 -0400 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id CFF4638C8065 for ; Fri, 10 Aug 2012 13:09:51 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q7AH9p4a150488 for ; Fri, 10 Aug 2012 13:09:51 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q7AH9oZT022050 for ; Fri, 10 Aug 2012 14:09:50 -0300 From: Anthony Liguori In-Reply-To: <20120810165100.GJ4425@otherpad.lan.raisama.net> References: <1343396239-19272-1-git-send-email-aliguori@us.ibm.com> <1343396239-19272-7-git-send-email-aliguori@us.ibm.com> <20120731155743.GG18479@otherpad.lan.raisama.net> <87fw7u6c52.fsf@codemonkey.ws> <20120810155901.GI4425@otherpad.lan.raisama.net> <87ehnevh2t.fsf@codemonkey.ws> <20120810165100.GJ4425@otherpad.lan.raisama.net> Date: Fri, 10 Aug 2012 12:09:44 -0500 Message-ID: <87zk627jxj.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH 6/7] target-i386: add implementation of query-cpudefs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: Peter Maydell , libvir-list@redhat.com, qemu-devel@nongnu.org, Markus Armbruster , Alexander Graf , Jiri Denemark , Eric Blake Eduardo Habkost writes: > On Fri, Aug 10, 2012 at 11:37:30AM -0500, Anthony Liguori wrote: >> Eduardo Habkost writes: >> >> > - add machine-type-specific cpudef compatibility changes? >> >> >> >> I think we've discussed this in IRC. I don't think we need to worry >> >> about this. >> > >> > I remember discussing a lot about the mechanism we will use to add the >> > compatibility changes, but I don t know how the query API will look >> > like, after we implement this mechanism. >> >> 0) User-defined CPU definitions go away >> - We already made a big step in this direction >> >> 1) CPU becomes a DeviceState > > 1.1) CPU models become classes > >> >> 2) Features are expressed as properties >> >> 3) Same global mechanism used for everything else is used for CPUs > > This is basically the compatibility mechanism we agreed upon, yes, but > what about the probing mechanism to allow libvirt to know what will be > the result of "-machine M -cpu C"[1] before actually starting a VM? I think that the requirement of "before actually starting a VM" is unreasonable. Presumably migration compatibility checking would happen after launching a guest so libvirt could surely delay querying the CPUID info until after the guest has started. There's a lot of logic involved in deciding what gets exposed to the guest. We don't really fully know until we've created the VCPU. It's a whole lot easier and saner to just create the VCPU. Regards, Anthony Liguori > > [1] By "result" I mean: > - Whether that combination can be run properly on that host; > - Which CPU features will be visible to the guest in case it runs. > Both items depend on CPU model _and_ machine-type, that's why we need > some probing mechanism that depends on the machine-type or use the > machine-type as input. > > >> >> Regards, >> >> Anthony Liguori >> >> >> > Would the command report different results depending on -machine? >> >> >> >> No. >> > >> > The problem is: >> > >> > 1) We need to introduce fixes on a CPU model that changes the set of >> > guest-visible features (add or remove a feature)[1]; >> > 2) The fix has to keep compatibility, so older machine-types will >> > keep exposing the old set of gues-visible features; >> > - That means different machine-types will have different CPU >> > features being exposed. >> > 3) libvirt needs to control/know which guest-visible CPU features are >> > available to the guest (see above); >> > 4) Because of (2), the querying system used by libvirt need to depend on >> > the CPU model and machine-type. >> > >> > >> > [1] Example: >> > The SandyBridge model today has the "tsc-deadline" bit set, but >> > QEMU-1.1 did not expose the tsc-deadline feature properly because of >> > incorrect expectations about the GET_SUPPORTED_CPUID ioctl. This was >> > fixed on qemu-1.2. >> > >> > That means "qemu-1.1 -machine pc-1.1 -cpu SandyBridge" does _not_ >> > expose tsc-deadline to the guest, and we need to make "qemu-1.2 >> > -machine pc-1.1 -cpu SandyBridge" _not_ expose it, too (otherwise >> > migration from qemu-1.1 to qemu-1.2 will be broken). >> > >> >> >> >> > >> >> > Would the command return the latest cpudef without any machine-type >> >> > hacks, and libvirt would have to query for the cpudef compatibility data >> >> > for each machine-type and combine both pieces of information itself? >> >> >> >> I'm not sure what you mean by compatibility data. >> > >> > I mean any guest-visible compatibility bit that we will need to >> > introduce on older machine-types, when making changes on CPU models (see >> > the SandyBridge + tsc-deadline example above). >> > >> > I see two options: >> > - Libvirt queries for a [f(machine_type, cpu_model) -> cpu_features] >> > function, that will take into account the machine-type-specific >> > compatibility bits. >> > - Libvirt queries for a [f(cpu_model) -> cpu_features] function and a >> > [f(machine_type) -> compatibility_changes] function, and combine both. >> > - I don't like this approach, I am just including it as a possible >> > alternative. >> > >> >> >> >> Regards, >> >> >> >> Anthony Liguori >> >> >> >> > >> >> > [1] Note that it doesn't have to be low-level leaf-by-leaf >> >> > register-by-register CPUID bits (I prefer a more high-level >> >> > interface, myself), but it has to at least say "feature FOO is >> >> > enabled/disabled" for a set of features libvirt cares about. >> >> > >> >> > -- >> >> > Eduardo >> >> >> > >> > -- >> > Eduardo >> > > -- > Eduardo