Re: [libvirt] Modern CPU models cannot be used with libvirt
I added a summary of the changes I am planning, at: http://wiki.qemu.org/Features/CPUModels#Current_Issues_and_proposed_changes I'm sure I forgot lots of details, so feel free to send me questions and suggestions, or even edit the wiki page directly. On Fri, Mar 09, 2012 at 05:56:52PM -0300, Eduardo Habkost wrote: Resurrecting an old thread: [...] -- Eduardo -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Modern CPU models cannot be used with libvirt
On Fri, Mar 09, 2012 at 03:15:26PM -0600, Anthony Liguori wrote: On 03/09/2012 03:04 PM, Daniel P. Berrange wrote: On Fri, Mar 09, 2012 at 05:56:52PM -0300, Eduardo Habkost wrote: Resurrecting an old thread: I didn't see any clear conclusion in this thread (this is why I am resurrecting it), except that many were arguing that libvirt should simply copy and/or generate the CPU model definitions from Qemu. I really don't think it's reasonable to expect that. On Thu, Dec 15, 2011 at 03:54:15PM +0100, Jiri Denemark wrote: Hi, Recently I realized that all modern CPU models defined in /etc/qemu/target-x86_64.conf are useless when qemu is used through libvirt. That's because we start qemu with -nodefconfig which results in qemu ignoring that file with CPU model definitions. We have a very good reason for using -nodefconfig because we need to control the ABI presented to a guest OS and we don't want any configuration file that can contain lots of things including device definitions to be read by qemu. However, we would really like the new CPU models to be understood by qemu even if used through libvirt. What would be the best way to solve this? I suspect this could have been already discussed in the past but obviously a workable solution was either not found or just not implemented. So, our problem today is basically: A) libvirt uses -nodefconfig; B) -nodefconfig makes Qemu not load the config file containing the CPU model definitions; and C) libvirt expects the full CPU model list from Qemu to be available. I could have sworn we had this discussion a year ago or so, and had decided that the default CPU models would be in something like /usr/share/qemu/cpu-x86_64.conf and loaded regardless of the -nodefconfig setting. /etc/qemu/target-x86_64.conf would be solely for end user configuration changes, not for QEMU builtin defaults. But looking at the code in QEMU, it doesn't seem we ever implemented this ? I don't remember that discussion and really don't think I agree with the conclusion. If libvirt wants to define CPU models on their own, they can. If It can't without knowing qemu/host cpu/host kernel capabilities and knowing the logic that qemu uses to combine them. libvirt wants to use the user's definitions, don't use -nodefconfig. CPU models aren't a QEMU concept. The reason it's in the I do not know what do you mean by that, but CPU capabilities (and CPU model is only a name for a group of them) are KVM/TCG concept and, by inclusion, are QEMU concept. If QEMU will not have built in support for CPU models (as a name for a group of CPU capabilities) then how do you start a guest without specifying full set of CPU capabilities on a command line? configuration file is to allow a user to add their own as they see fit. There is no right model names. It's strictly a policy. So you think it should be user's responsibility to check what his qemu/host cpu/host kernel combo can support? -- Gleb. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Modern CPU models cannot be used with libvirt
On Fri, Mar 09, 2012 at 09:04:03PM +, Daniel P. Berrange wrote: On Fri, Mar 09, 2012 at 05:56:52PM -0300, Eduardo Habkost wrote: Resurrecting an old thread: I didn't see any clear conclusion in this thread (this is why I am resurrecting it), except that many were arguing that libvirt should simply copy and/or generate the CPU model definitions from Qemu. I really don't think it's reasonable to expect that. On Thu, Dec 15, 2011 at 03:54:15PM +0100, Jiri Denemark wrote: Hi, Recently I realized that all modern CPU models defined in /etc/qemu/target-x86_64.conf are useless when qemu is used through libvirt. That's because we start qemu with -nodefconfig which results in qemu ignoring that file with CPU model definitions. We have a very good reason for using -nodefconfig because we need to control the ABI presented to a guest OS and we don't want any configuration file that can contain lots of things including device definitions to be read by qemu. However, we would really like the new CPU models to be understood by qemu even if used through libvirt. What would be the best way to solve this? I suspect this could have been already discussed in the past but obviously a workable solution was either not found or just not implemented. So, our problem today is basically: A) libvirt uses -nodefconfig; B) -nodefconfig makes Qemu not load the config file containing the CPU model definitions; and C) libvirt expects the full CPU model list from Qemu to be available. I could have sworn we had this discussion a year ago or so, and had decided that the default CPU models would be in something like /usr/share/qemu/cpu-x86_64.conf and loaded regardless of the -nodefconfig setting. /etc/qemu/target-x86_64.conf would be solely for end user configuration changes, not for QEMU builtin defaults. But looking at the code in QEMU, it doesn't seem we ever implemented this ? Arrrgggh. It seems this was implemented as a patch in RHEL-6 qemu RPMs but, contrary to our normal RHEL development practice, it was not based on a cherry-pick of an upstream patch :-( For sake of reference, I'm attaching the two patches from the RHEL6 source RPM that do what I'm describing NB, I'm not neccessarily advocating these patches for upstream. I still maintain that libvirt should write out a config file containing the exact CPU model description it desires and specify that with -readconfig. The end result would be identical from QEMU's POV and it would avoid playing games with QEMU's config loading code. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| From ab8e4c035638685f1e579ce472dd8b4c957f8097 Mon Sep 17 00:00:00 2001 From: john cooper john.coo...@redhat.com Date: Thu, 8 Jul 2010 04:17:13 -0300 Subject: [PATCH 1/3] Move CPU definitions to /usr/share/... BZ #610805 RH-Author: john cooper john.coo...@redhat.com Message-id: 4c355149.2050...@redhat.com Patchwork-id: 10557 O-Subject: [RHEL6 PATCH] Move CPU definitions to /usr/share/... BZ #610805 Bugzilla: 610805 RH-Acked-by: Markus Armbruster arm...@redhat.com RH-Acked-by: Jes Sorensen jes.soren...@redhat.com RH-Acked-by: Juan Quintela quint...@redhat.com Description: libvirt requested the cpu model configuration file be relocated to /usr/share to more clearly signify it was not to be modified by users. In addition the model file is now loaded even in the presence of the -nodefconfig command line flag. Note this is intended as an interim work-around for rhel6.0. While the new location of the config file should remain the same, the mechanism to direct qemu to it will likely differ going forward. Minor Caveat: Although the model definitions have moved from /etc/qemu/target-x86_64.conf to /usr/share/qemu-kvm/cpu-model/cpu-x86_64.conf an open of the former default config file is still attempted by qemu. In a new installation of the rpm this is a non-issue as well as when -nodefconfig is specified. However if the former config file exists, and is allowed to be read, and and contains model definitions conflicting with those in cpu-x86_64.conf, they will override those from the new config file. This realistically is only an issue for development testing and may be detected by -readconfig ? which will indicate when the old file had been found or -cpu ? which will display replicated model definitions. Verification: # /usr/libexec/qemu-kvm -nodefconfig -readconfig ? -cpu ? parsed config file /usr/share/qemu-kvm/cpu-model/cpu-x86_64.conf x86 Opteron_G3 x86 Opteron_G2 x86 Opteron_G1 x86 Nehalem x86 Penryn x86 Conroe x86 [n270] x86
Re: [libvirt] Modern CPU models cannot be used with libvirt
Resurrecting an old thread: I didn't see any clear conclusion in this thread (this is why I am resurrecting it), except that many were arguing that libvirt should simply copy and/or generate the CPU model definitions from Qemu. I really don't think it's reasonable to expect that. On Thu, Dec 15, 2011 at 03:54:15PM +0100, Jiri Denemark wrote: Hi, Recently I realized that all modern CPU models defined in /etc/qemu/target-x86_64.conf are useless when qemu is used through libvirt. That's because we start qemu with -nodefconfig which results in qemu ignoring that file with CPU model definitions. We have a very good reason for using -nodefconfig because we need to control the ABI presented to a guest OS and we don't want any configuration file that can contain lots of things including device definitions to be read by qemu. However, we would really like the new CPU models to be understood by qemu even if used through libvirt. What would be the best way to solve this? I suspect this could have been already discussed in the past but obviously a workable solution was either not found or just not implemented. So, our problem today is basically: A) libvirt uses -nodefconfig; B) -nodefconfig makes Qemu not load the config file containing the CPU model definitions; and C) libvirt expects the full CPU model list from Qemu to be available. Those three expectations can't be fulfilled at the same time. So, we have to break one of the expectations above. That means: - Breaking (A), that would mean libvirt wouldn't use -nodefconfig. I think -nodefconfig _has_ a point, even if it doesn't do much today, so I think we can drop this possibility. - Breaking (B), that means loading the CPU model definitions anyway when using -nodefconfig. I am inclined for this option: the list of CPU model defs are a list of CPU templates, not actual virtual machine configuration. The fact that the CPU templates are stored in an external file instead of hardcoded inside the Qemu source code is just an implementation detail. A more detailed explanation is below. - Breaking (C), that means libvirt would simply not have the existing CPU model definitions available for its use. This is what happens today. The problem with this solution is: if we are spending lots of efforts defining properly all those CPU definition templates, we should allow the upper layers to reuse them, instead of forcing them to duplicate work and maintain their own copies and deal with exactly the same problems we had to deal inside Qemu. This is related to the argument that CPU definitions are part of machine-types. Machine-types are a mechanism to allow new guest-visible features to be added to a virtual machine without waiting until libvirt can handle the details of that feature. You just choose a newer machine-type, and the new features are going to be enabled, even if libvirt doesn't know anything about it. When libvirt starts to model some details of some feature, we can let it probe for them, so it knows what's exactly being exposed to a guest. But while these details are not modelled by libvirt, the only way we can let the user enjoy new features as they are available is using machine-types. And to make this work, machine-types details can't be disabled using -nodefconfig. Complementing what Gleb said at that time: On Sun, Dec 18, 2011 at 11:58:16AM +0200, Gleb Natapov wrote: Ideally libvirt would just write out a config file with the CPU that was configured in libvirt and pass -readconfig /var/lib/libvirt/qemu/guestcpu.conf That way libvirt can configure CPU models without regard for what the particular QEMU version might have in its config. And how libvirt would know that particular QEMU/kvm version can create this CPU. Managing cpuid shouldn't be libvirt busyness. Even if managing CPUID bits is libvirt business on some specific cases, this is not true for _all_ CPU details. I don't think that the libvirt internal model of CPU features will be ever complete (and maybe it even shouldn't be). There will be always some feature that libvirt don't know anything about, and _that_ is what we have to model inside the Qemu CPU definitions and/or inside machine-type definitions--I don't think we even have a choice. We can make it easier to change and probe for the existing CPU definitions and features, in case libvirt wants to deal with some details, but we can't expect libvirt to be able to configure every single detail about the CPU. -- Eduardo -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Modern CPU models cannot be used with libvirt
On Fri, Mar 09, 2012 at 05:56:52PM -0300, Eduardo Habkost wrote: Resurrecting an old thread: I didn't see any clear conclusion in this thread (this is why I am resurrecting it), except that many were arguing that libvirt should simply copy and/or generate the CPU model definitions from Qemu. I really don't think it's reasonable to expect that. On Thu, Dec 15, 2011 at 03:54:15PM +0100, Jiri Denemark wrote: Hi, Recently I realized that all modern CPU models defined in /etc/qemu/target-x86_64.conf are useless when qemu is used through libvirt. That's because we start qemu with -nodefconfig which results in qemu ignoring that file with CPU model definitions. We have a very good reason for using -nodefconfig because we need to control the ABI presented to a guest OS and we don't want any configuration file that can contain lots of things including device definitions to be read by qemu. However, we would really like the new CPU models to be understood by qemu even if used through libvirt. What would be the best way to solve this? I suspect this could have been already discussed in the past but obviously a workable solution was either not found or just not implemented. So, our problem today is basically: A) libvirt uses -nodefconfig; B) -nodefconfig makes Qemu not load the config file containing the CPU model definitions; and C) libvirt expects the full CPU model list from Qemu to be available. I could have sworn we had this discussion a year ago or so, and had decided that the default CPU models would be in something like /usr/share/qemu/cpu-x86_64.conf and loaded regardless of the -nodefconfig setting. /etc/qemu/target-x86_64.conf would be solely for end user configuration changes, not for QEMU builtin defaults. But looking at the code in QEMU, it doesn't seem we ever implemented this ? Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Modern CPU models cannot be used with libvirt
On 03/09/2012 03:04 PM, Daniel P. Berrange wrote: On Fri, Mar 09, 2012 at 05:56:52PM -0300, Eduardo Habkost wrote: Resurrecting an old thread: I didn't see any clear conclusion in this thread (this is why I am resurrecting it), except that many were arguing that libvirt should simply copy and/or generate the CPU model definitions from Qemu. I really don't think it's reasonable to expect that. On Thu, Dec 15, 2011 at 03:54:15PM +0100, Jiri Denemark wrote: Hi, Recently I realized that all modern CPU models defined in /etc/qemu/target-x86_64.conf are useless when qemu is used through libvirt. That's because we start qemu with -nodefconfig which results in qemu ignoring that file with CPU model definitions. We have a very good reason for using -nodefconfig because we need to control the ABI presented to a guest OS and we don't want any configuration file that can contain lots of things including device definitions to be read by qemu. However, we would really like the new CPU models to be understood by qemu even if used through libvirt. What would be the best way to solve this? I suspect this could have been already discussed in the past but obviously a workable solution was either not found or just not implemented. So, our problem today is basically: A) libvirt uses -nodefconfig; B) -nodefconfig makes Qemu not load the config file containing the CPU model definitions; and C) libvirt expects the full CPU model list from Qemu to be available. I could have sworn we had this discussion a year ago or so, and had decided that the default CPU models would be in something like /usr/share/qemu/cpu-x86_64.conf and loaded regardless of the -nodefconfig setting. /etc/qemu/target-x86_64.conf would be solely for end user configuration changes, not for QEMU builtin defaults. But looking at the code in QEMU, it doesn't seem we ever implemented this ? I don't remember that discussion and really don't think I agree with the conclusion. If libvirt wants to define CPU models on their own, they can. If libvirt wants to use the user's definitions, don't use -nodefconfig. CPU models aren't a QEMU concept. The reason it's in the configuration file is to allow a user to add their own as they see fit. There is no right model names. It's strictly a policy. Regards, Anthony Liguori Daniel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Modern CPU models cannot be used with libvirt
Hi, Recently I realized that all modern CPU models defined in /etc/qemu/target-x86_64.conf are useless when qemu is used through libvirt. That's because we start qemu with -nodefconfig which results in qemu ignoring that file with CPU model definitions. We have a very good reason for using -nodefconfig because we need to control the ABI presented to a guest OS and we don't want any configuration file that can contain lots of things including device definitions to be read by qemu. However, we would really like the new CPU models to be understood by qemu even if used through libvirt. What would be the best way to solve this? I suspect this could have been already discussed in the past but obviously a workable solution was either not found or just not implemented. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Modern CPU models cannot be used with libvirt
On Thu, Dec 15, 2011 at 03:54:15PM +0100, Jiri Denemark wrote: Hi, Recently I realized that all modern CPU models defined in /etc/qemu/target-x86_64.conf are useless when qemu is used through libvirt. That's because we start qemu with -nodefconfig which results in qemu ignoring that file with CPU model definitions. We have a very good reason for using -nodefconfig because we need to control the ABI presented to a guest OS and we don't want any configuration file that can contain lots of things including device definitions to be read by qemu. However, we would really like the new CPU models to be understood by qemu even if used through libvirt. What would be the best way to solve this? Ideally libvirt would just write out a config file with the CPU that was configured in libvirt and pass -readconfig /var/lib/libvirt/qemu/guestcpu.conf That way libvirt can configure CPU models without regard for what the particular QEMU version might have in its config. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
