From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SzsEM-0005T8-U0 for qemu-devel@nongnu.org; Fri, 10 Aug 2012 12:38:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SzsEK-0004Ve-8Z for qemu-devel@nongnu.org; Fri, 10 Aug 2012 12:38:34 -0400 Received: from e3.ny.us.ibm.com ([32.97.182.143]:55598) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SzsEK-0004VT-3u for qemu-devel@nongnu.org; Fri, 10 Aug 2012 12:38:32 -0400 Received: from /spool/local by e3.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 10 Aug 2012 12:38:31 -0400 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 8D03838C8041 for ; Fri, 10 Aug 2012 12:38:27 -0400 (EDT) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q7AGc57j20119560 for ; Fri, 10 Aug 2012 12:38:05 -0400 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q7AGbe4F022334 for ; Fri, 10 Aug 2012 10:37:41 -0600 From: Anthony Liguori In-Reply-To: <20120810155901.GI4425@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> Date: Fri, 10 Aug 2012 11:37:30 -0500 Message-ID: <87ehnevh2t.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 09:43:21AM -0500, Anthony Liguori wrote: >> Eduardo Habkost writes: >> >> > On Fri, Jul 27, 2012 at 08:37:18AM -0500, Anthony Liguori wrote: >> >> Signed-off-by: Anthony Liguori >> >> --- >> >> target-i386/cpu.c | 22 ++++++++++++++++++++++ >> >> 1 files changed, 22 insertions(+), 0 deletions(-) >> >> >> >> diff --git a/target-i386/cpu.c b/target-i386/cpu.c >> >> index 6b9659f..b398439 100644 >> >> --- a/target-i386/cpu.c >> >> +++ b/target-i386/cpu.c >> >> @@ -28,6 +28,7 @@ >> >> #include "qemu-config.h" >> >> >> >> #include "qapi/qapi-visit-core.h" >> >> +#include "qmp-commands.h" >> >> >> >> #include "hyperv.h" >> >> >> >> @@ -1123,6 +1124,27 @@ void x86_cpu_list(FILE *f, fprintf_function cpu_fprintf, const char *optarg) >> >> } >> >> } >> >> >> >> +CpuDefInfoList *qmp_query_cpudefs(Error **errp) >> >> +{ >> >> + CpuDefInfoList *cpu_list = NULL; >> >> + x86_def_t *def; >> >> + >> >> + for (def = x86_defs; def; def = def->next) { >> >> + CpuDefInfoList *entry; >> >> + CpuDefInfo *info; >> >> + >> >> + info = g_malloc0(sizeof(*info)); >> >> + info->name = g_strdup(def->name); >> >> + >> >> + entry = g_malloc0(sizeof(*entry)); >> >> + entry->value = info; >> >> + entry->next = cpu_list; >> >> + cpu_list = entry; >> >> + } >> >> + >> >> + return cpu_list; >> >> +} >> > >> > How would the interface look like once we: >> > - let libvirt know which features are available on each CPU model >> > (libvirt needs that information[1]); and >> >> I'm not sure I understand why libvirt needs this information. Can you elaborate? > > I see two reasons: > > - The libvirt API has functions to tell the user which features are > going to be enabled for each CPU model, so it needs to know which > features are enabled or not, for each machine-type + cpu-model > combination, so this information can be reported proeprly. Ok, step number one is that CPU 'features' need to be defined more formally. By formally, I mean via qapi-schema.json. Then we can extend this command to return the set of features supported by each CPU type. The first step will need to sort out how this maps across architectures. > - Also, if libvirt can enable/disable specific CPU features in the > command-line, it just makes sens to know which ones are already > enabled in each built-in CPU model. > > - Probing for migration: libvirt needs to know if a given CPU model on a > host can be migrated to another host. To know that, two pieces of > information are needed: > A) Which CPU features are visible to the guest for a specific > configuration; > B) Which of those features are really supported by the host > hardware+kernel+QEMU, on the destination host, so it can > know if migration is really possible. Note that what QEMU thinks it exposes is not necessarily what gets exposed. KVM may mask additional features. How is this handled today? >> > - 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 2) Features are expressed as properties 3) Same global mechanism used for everything else is used for CPUs 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