target/i386/cpu-qom.h | 4 ++- target/i386/cpu.c | 98 ++++++++++++++++++++++++++++++++------------------- 2 files changed, 64 insertions(+), 38 deletions(-)
Changes v1 -> v2: * Fix build without CONFIG_KVM at lmce_supported() * Rebased on top of my x86-next branch: https://github.com/ehabkost/qemu x86-next Git branch for testing: https://github.com/ehabkost/qemu-hacks work/x86-cpu-max-tcg libvirt code to use the new feature already exist, and were submitted to libvir-list, at: https://www.mail-archive.com/libvir-list@redhat.com/msg142168.html --- This is a replacement for the previous series that enabled the "host" CPU model on TCG. Now a new "max" CPU is being added, while keeping "host" KVM-specific. In addition to simply adding "max" as a copy of the existing "host" CPU model, additional patches change it to not use any host CPUID information when in TCG mode. --- Cc: "Richard W.M. Jones" <rjones@redhat.com> Cc: David Hildenbrand <david@redhat.com> Cc: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: "Daniel P. Berrange" <berrange@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiri Denemark <jdenemar@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: "Jason J. Herne" <jjherne@linux.vnet.ibm.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Eduardo Habkost (3): i386: Create "max" CPU model i386: Make "max" model not use any host CPUID info on TCG i386: Don't set CPUClass::cpu_def on "max" model target/i386/cpu-qom.h | 4 ++- target/i386/cpu.c | 98 ++++++++++++++++++++++++++++++++------------------- 2 files changed, 64 insertions(+), 38 deletions(-) -- 2.11.0.259.g40922b1
Ping? As v1 was sitting on the list since Jan 19, if there are no objections I will merge this and include in my next pull request before soft freeze. On Wed, Feb 22, 2017 at 03:39:16PM -0300, Eduardo Habkost wrote: > Changes v1 -> v2: > * Fix build without CONFIG_KVM at lmce_supported() > * Rebased on top of my x86-next branch: > https://github.com/ehabkost/qemu x86-next > > Git branch for testing: > https://github.com/ehabkost/qemu-hacks work/x86-cpu-max-tcg > > libvirt code to use the new feature already exist, and were > submitted to libvir-list, at: > https://www.mail-archive.com/libvir-list@redhat.com/msg142168.html > > --- > > This is a replacement for the previous series that enabled the > "host" CPU model on TCG. Now a new "max" CPU is being added, > while keeping "host" KVM-specific. > > In addition to simply adding "max" as a copy of the existing > "host" CPU model, additional patches change it to not use any > host CPUID information when in TCG mode. > > --- > Cc: "Richard W.M. Jones" <rjones@redhat.com> > Cc: David Hildenbrand <david@redhat.com> > Cc: Cornelia Huck <cornelia.huck@de.ibm.com> > Cc: "Daniel P. Berrange" <berrange@redhat.com> > Cc: Peter Maydell <peter.maydell@linaro.org> > Cc: Igor Mammedov <imammedo@redhat.com> > Cc: Jiri Denemark <jdenemar@redhat.com> > Cc: Richard Henderson <rth@twiddle.net> > Cc: Christian Borntraeger <borntraeger@de.ibm.com> > Cc: "Jason J. Herne" <jjherne@linux.vnet.ibm.com> > Cc: Paolo Bonzini <pbonzini@redhat.com> > > Eduardo Habkost (3): > i386: Create "max" CPU model > i386: Make "max" model not use any host CPUID info on TCG > i386: Don't set CPUClass::cpu_def on "max" model > > target/i386/cpu-qom.h | 4 ++- > target/i386/cpu.c | 98 ++++++++++++++++++++++++++++++++------------------- > 2 files changed, 64 insertions(+), 38 deletions(-) > > -- > 2.11.0.259.g40922b1 > -- Eduardo
On Thu, Feb 23, 2017 at 05:07:47PM -0300, Eduardo Habkost wrote: > Ping? > > As v1 was sitting on the list since Jan 19, if there are no > objections I will merge this and include in my next pull request > before soft freeze. Do you have a copy which applies on top of current HEAD? I get loads of conflicts. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org
On Thu, Feb 23, 2017 at 09:57:41PM +0000, Richard W.M. Jones wrote: > On Thu, Feb 23, 2017 at 05:07:47PM -0300, Eduardo Habkost wrote: > > Ping? > > > > As v1 was sitting on the list since Jan 19, if there are no > > objections I will merge this and include in my next pull request > > before soft freeze. > > Do you have a copy which applies on top of current HEAD? I get > loads of conflicts. It is based on my x86-next branch. See cover letter for git URLs: ] * Rebased on top of my x86-next branch: ] https://github.com/ehabkost/qemu x86-next ] ] Git branch for testing: ] https://github.com/ehabkost/qemu-hacks work/x86-cpu-max-tcg -- Eduardo
On Fri, Feb 24, 2017 at 09:26:30AM -0300, Eduardo Habkost wrote: > On Thu, Feb 23, 2017 at 09:57:41PM +0000, Richard W.M. Jones wrote: > > On Thu, Feb 23, 2017 at 05:07:47PM -0300, Eduardo Habkost wrote: > > > Ping? > > > > > > As v1 was sitting on the list since Jan 19, if there are no > > > objections I will merge this and include in my next pull request > > > before soft freeze. > > > > Do you have a copy which applies on top of current HEAD? I get > > loads of conflicts. > > It is based on my x86-next branch. See cover letter for git URLs: > > ] * Rebased on top of my x86-next branch: > ] https://github.com/ehabkost/qemu x86-next > ] > ] Git branch for testing: > ] https://github.com/ehabkost/qemu-hacks work/x86-cpu-max-tcg OK I've tried it now, and it works in both TCG and KVM cases. If you want you can add: Tested-by: Richard W.M. Jones <rjones@redhat.com> Thanks, Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/
On 22 February 2017 at 18:39, Eduardo Habkost <ehabkost@redhat.com> wrote: > Changes v1 -> v2: > * Fix build without CONFIG_KVM at lmce_supported() > * Rebased on top of my x86-next branch: > https://github.com/ehabkost/qemu x86-next > > Git branch for testing: > https://github.com/ehabkost/qemu-hacks work/x86-cpu-max-tcg > > libvirt code to use the new feature already exist, and were > submitted to libvir-list, at: > https://www.mail-archive.com/libvir-list@redhat.com/msg142168.html > > --- > > This is a replacement for the previous series that enabled the > "host" CPU model on TCG. Now a new "max" CPU is being added, > while keeping "host" KVM-specific. > > In addition to simply adding "max" as a copy of the existing > "host" CPU model, additional patches change it to not use any > host CPUID information when in TCG mode. I had a look at implementing this for ARM, and ran into problems because of how we've done '-cpu host'. For us the "host" CPU type is registered dynamically when kvm_init() is called, because (a) it only exists if -enable-kvm and (b) it probes the kernel to find out what's available. So I could easily add 'max' in the same place; but then where should I add the type definition of 'max' for the non-KVM case? Any suggestions? thanks -- PMM
Am 24.02.2017 um 14:48 schrieb Peter Maydell: > On 22 February 2017 at 18:39, Eduardo Habkost <ehabkost@redhat.com> wrote: >> Changes v1 -> v2: >> * Fix build without CONFIG_KVM at lmce_supported() >> * Rebased on top of my x86-next branch: >> https://github.com/ehabkost/qemu x86-next >> >> Git branch for testing: >> https://github.com/ehabkost/qemu-hacks work/x86-cpu-max-tcg >> >> libvirt code to use the new feature already exist, and were >> submitted to libvir-list, at: >> https://www.mail-archive.com/libvir-list@redhat.com/msg142168.html >> >> --- >> >> This is a replacement for the previous series that enabled the >> "host" CPU model on TCG. Now a new "max" CPU is being added, >> while keeping "host" KVM-specific. >> >> In addition to simply adding "max" as a copy of the existing >> "host" CPU model, additional patches change it to not use any >> host CPUID information when in TCG mode. > > > I had a look at implementing this for ARM, and ran into problems > because of how we've done '-cpu host'. For us the "host" CPU > type is registered dynamically when kvm_init() is called, > because (a) it only exists if -enable-kvm and (b) it probes > the kernel to find out what's available. So I could easily > add 'max' in the same place; but then where should I add the > type definition of 'max' for the non-KVM case? > > Any suggestions? Maybe switch to some late initialization? On s390x, we register the host model right away, but fill it with life in the initfn. If KVM is disabled, the host model will be available, but we will deny to use it (via kvm_required). For max, it would be the same thing. The initfn will simply inititalize the model differently, depending on the selected accelerator. When the models are inititalized, kvm is already up and running, so it the kernel can be properly probed. Not sure if that helps :) -- Thanks, David
On Fri, Feb 24, 2017 at 01:48:46PM +0000, Peter Maydell wrote: > On 22 February 2017 at 18:39, Eduardo Habkost <ehabkost@redhat.com> wrote: > > Changes v1 -> v2: > > * Fix build without CONFIG_KVM at lmce_supported() > > * Rebased on top of my x86-next branch: > > https://github.com/ehabkost/qemu x86-next > > > > Git branch for testing: > > https://github.com/ehabkost/qemu-hacks work/x86-cpu-max-tcg > > > > libvirt code to use the new feature already exist, and were > > submitted to libvir-list, at: > > https://www.mail-archive.com/libvir-list@redhat.com/msg142168.html > > > > --- > > > > This is a replacement for the previous series that enabled the > > "host" CPU model on TCG. Now a new "max" CPU is being added, > > while keeping "host" KVM-specific. > > > > In addition to simply adding "max" as a copy of the existing > > "host" CPU model, additional patches change it to not use any > > host CPUID information when in TCG mode. > > > I had a look at implementing this for ARM, and ran into problems > because of how we've done '-cpu host'. For us the "host" CPU > type is registered dynamically when kvm_init() is called, > because (a) it only exists if -enable-kvm and (b) it probes > the kernel to find out what's available. So I could easily > add 'max' in the same place; but then where should I add the > type definition of 'max' for the non-KVM case? I recommend registering the type unconditionally, moving KVM-specific initialization to ->instance_init() and/or ->realize() (being careful to make instance_init() not crash if KVM is disabled), and make ->realize() fail if KVM is disabled. IIRC, we did exactly that on x86 a while ago. -- Eduardo
On 24 February 2017 at 17:11, Eduardo Habkost <ehabkost@redhat.com> wrote: > On Fri, Feb 24, 2017 at 01:48:46PM +0000, Peter Maydell wrote: >> I had a look at implementing this for ARM, and ran into problems >> because of how we've done '-cpu host'. For us the "host" CPU >> type is registered dynamically when kvm_init() is called, >> because (a) it only exists if -enable-kvm and (b) it probes >> the kernel to find out what's available. So I could easily >> add 'max' in the same place; but then where should I add the >> type definition of 'max' for the non-KVM case? > > I recommend registering the type unconditionally, moving > KVM-specific initialization to ->instance_init() and/or > ->realize() (being careful to make instance_init() not crash if > KVM is disabled), and make ->realize() fail if KVM is disabled. > IIRC, we did exactly that on x86 a while ago. Thanks, sounds reasonable. Also sounds like more rework than I want to try to write, test and cram into QEMU before freeze deadline on Tuesday, so I guess we'll have to wait til after 2.9; a pity, but can't be helped. thanks -- PMM
On 24 February 2017 at 18:04, Peter Maydell <peter.maydell@linaro.org> wrote: > On 24 February 2017 at 17:11, Eduardo Habkost <ehabkost@redhat.com> wrote: >> On Fri, Feb 24, 2017 at 01:48:46PM +0000, Peter Maydell wrote: >>> I had a look at implementing this for ARM, and ran into problems >>> because of how we've done '-cpu host'. For us the "host" CPU >>> type is registered dynamically when kvm_init() is called, >>> because (a) it only exists if -enable-kvm and (b) it probes >>> the kernel to find out what's available. So I could easily >>> add 'max' in the same place; but then where should I add the >>> type definition of 'max' for the non-KVM case? >> >> I recommend registering the type unconditionally, moving >> KVM-specific initialization to ->instance_init() and/or >> ->realize() (being careful to make instance_init() not crash if >> KVM is disabled), and make ->realize() fail if KVM is disabled. >> IIRC, we did exactly that on x86 a while ago. > > Thanks, sounds reasonable. Also sounds like more rework than > I want to try to write, test and cram into QEMU before freeze > deadline on Tuesday, so I guess we'll have to wait til after > 2.9; a pity, but can't be helped. I remembered this week that I'd completely forgotten that we should have a go at "cpu max" for ARM in the 2.10 cycle. Maybe for 2.11 :-) thanks -- PMM
© 2016 - 2024 Red Hat, Inc.