This enables report of a signature in CPUID for the TCG interpretor. Changed in v4: - Report 0x40000001 in EAX for 0x40000000 index (Eduardo) - Report all zeros for 0x40000001 index (Eduardo) - Make code style consistent when checking limits (Eduardo) Changed in v3: - Simplify CPU limit code still further (Eduardo) Changed in v2: - Rewrite the way we bounds check / cap the CPUID index to use a flat switch, instead of nested ifs (Eduardo) - Add a 'tcg-cpuid' property to allow it to be hidden (Eduardo) - Hide the TCG signature for old machine types - Force code to a no-op if tcg_enabled() is false (Eduardo) NB, I did not introduce a general 'hypervisor-cpuid' property to obsolete the existing 'kvm=off|on' -cpu property, since it appears impossible to get the back compat semantics right, as described in a previous reply. Daniel P. Berrange (2): i386: rewrite way CPUID index is validated i386: expose "TCGTCGTCGTCG" in the 0x40000000 CPUID leaf include/hw/i386/pc.h | 5 ++++ target/i386/cpu.c | 65 +++++++++++++++++++++++++++++++++++----------------- target/i386/cpu.h | 1 + 3 files changed, 50 insertions(+), 21 deletions(-) -- 2.9.3
On 05/09/2017 06:27 AM, Daniel P. Berrange wrote: > This enables report of a signature in CPUID for the TCG > interpretor. > > Changed in v4: > > - Report 0x40000001 in EAX for 0x40000000 index (Eduardo) > - Report all zeros for 0x40000001 index (Eduardo) > - Make code style consistent when checking limits (Eduardo) > > Changed in v3: > > - Simplify CPU limit code still further (Eduardo) > > Changed in v2: > > - Rewrite the way we bounds check / cap the CPUID index > to use a flat switch, instead of nested ifs (Eduardo) > - Add a 'tcg-cpuid' property to allow it to be hidden > (Eduardo) > - Hide the TCG signature for old machine types > - Force code to a no-op if tcg_enabled() is false (Eduardo) > > > NB, I did not introduce a general 'hypervisor-cpuid' property > to obsolete the existing 'kvm=off|on' -cpu property, since it > appears impossible to get the back compat semantics right, > as described in a previous reply. > > Daniel P. Berrange (2): > i386: rewrite way CPUID index is validated > i386: expose "TCGTCGTCGTCG" in the 0x40000000 CPUID leaf I probably should have commented earlier but... what's the point? If you want the guest os to actually do anything with this, what do you gain for advertising TCG over KVM? r~
On Tue, May 09, 2017 at 07:05:51AM -0700, Richard Henderson wrote: > On 05/09/2017 06:27 AM, Daniel P. Berrange wrote: > > This enables report of a signature in CPUID for the TCG > > interpretor. > > > > Changed in v4: > > > > - Report 0x40000001 in EAX for 0x40000000 index (Eduardo) > > - Report all zeros for 0x40000001 index (Eduardo) > > - Make code style consistent when checking limits (Eduardo) > > > > Changed in v3: > > > > - Simplify CPU limit code still further (Eduardo) > > > > Changed in v2: > > > > - Rewrite the way we bounds check / cap the CPUID index > > to use a flat switch, instead of nested ifs (Eduardo) > > - Add a 'tcg-cpuid' property to allow it to be hidden > > (Eduardo) > > - Hide the TCG signature for old machine types > > - Force code to a no-op if tcg_enabled() is false (Eduardo) > > > > > > NB, I did not introduce a general 'hypervisor-cpuid' property > > to obsolete the existing 'kvm=off|on' -cpu property, since it > > appears impossible to get the back compat semantics right, > > as described in a previous reply. > > > > Daniel P. Berrange (2): > > i386: rewrite way CPUID index is validated > > i386: expose "TCGTCGTCGTCG" in the 0x40000000 CPUID leaf > > I probably should have commented earlier but... what's the point? > > If you want the guest os to actually do anything with this, what do > you gain for advertising TCG over KVM? TCG doesn't expose any of the paravirt features that KVM does, so from that POV reporting "KVMKVMKVM" when running TCG would be wrong. As mentioned in the 2nd patch too, every hypervisor out there reports a distinct CPUID string, so again I think TCG should have its own identity, as it is different CPU emulation other users of QEMU (Xen, KVM, $whatever Windows and OS-X CPU accelerators are). Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, May 09, 2017 at 07:05:51AM -0700, Richard Henderson wrote: > On 05/09/2017 06:27 AM, Daniel P. Berrange wrote: > >This enables report of a signature in CPUID for the TCG > >interpretor. > > > >Changed in v4: > > > > - Report 0x40000001 in EAX for 0x40000000 index (Eduardo) > > - Report all zeros for 0x40000001 index (Eduardo) > > - Make code style consistent when checking limits (Eduardo) > > > >Changed in v3: > > > > - Simplify CPU limit code still further (Eduardo) > > > >Changed in v2: > > > > - Rewrite the way we bounds check / cap the CPUID index > > to use a flat switch, instead of nested ifs (Eduardo) > > - Add a 'tcg-cpuid' property to allow it to be hidden > > (Eduardo) > > - Hide the TCG signature for old machine types > > - Force code to a no-op if tcg_enabled() is false (Eduardo) > > > > > >NB, I did not introduce a general 'hypervisor-cpuid' property > >to obsolete the existing 'kvm=off|on' -cpu property, since it > >appears impossible to get the back compat semantics right, > >as described in a previous reply. > > > >Daniel P. Berrange (2): > > i386: rewrite way CPUID index is validated > > i386: expose "TCGTCGTCGTCG" in the 0x40000000 CPUID leaf > > I probably should have commented earlier but... what's the point? > > If you want the guest os to actually do anything with this, what do > you gain for advertising TCG over KVM? I can see this being useful from virt-what, since it would allow vendors to diagnose problems being caused by TCG (since as Dan mentions in the other reply and as you are already well acquainted with, TCG and KVM don't present or emulate quite the same thing). That said, I don't think it's anything more than a nice to have. 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 05/09/2017 07:13 AM, Richard W.M. Jones wrote: > On Tue, May 09, 2017 at 07:05:51AM -0700, Richard Henderson wrote: >>> Daniel P. Berrange (2): >>> i386: rewrite way CPUID index is validated >>> i386: expose "TCGTCGTCGTCG" in the 0x40000000 CPUID leaf >> >> I probably should have commented earlier but... what's the point? >> >> If you want the guest os to actually do anything with this, what do >> you gain for advertising TCG over KVM? > > I can see this being useful from virt-what, since it would allow > vendors to diagnose problems being caused by TCG ... Thanks, that's an excellent point. r~
On Tue, May 09, 2017 at 07:18:07AM -0700, Richard Henderson wrote: > On 05/09/2017 07:13 AM, Richard W.M. Jones wrote: > > On Tue, May 09, 2017 at 07:05:51AM -0700, Richard Henderson wrote: > > > > Daniel P. Berrange (2): > > > > i386: rewrite way CPUID index is validated > > > > i386: expose "TCGTCGTCGTCG" in the 0x40000000 CPUID leaf > > > > > > I probably should have commented earlier but... what's the point? > > > > > > If you want the guest os to actually do anything with this, what do > > > you gain for advertising TCG over KVM? > > > > I can see this being useful from virt-what, since it would allow > > vendors to diagnose problems being caused by TCG ... > > Thanks, that's an excellent point. Richard, Paolo: I would like to merge this. Do you agree? -- Eduardo
On Fri, May 19, 2017 at 04:41:46PM -0300, Eduardo Habkost wrote: > On Tue, May 09, 2017 at 07:18:07AM -0700, Richard Henderson wrote: > > On 05/09/2017 07:13 AM, Richard W.M. Jones wrote: > > > On Tue, May 09, 2017 at 07:05:51AM -0700, Richard Henderson wrote: > > > > > Daniel P. Berrange (2): > > > > > i386: rewrite way CPUID index is validated > > > > > i386: expose "TCGTCGTCGTCG" in the 0x40000000 CPUID leaf > > > > > > > > I probably should have commented earlier but... what's the point? > > > > > > > > If you want the guest os to actually do anything with this, what do > > > > you gain for advertising TCG over KVM? > > > > > > I can see this being useful from virt-what, since it would allow > > > vendors to diagnose problems being caused by TCG ... > > > > Thanks, that's an excellent point. > > Richard, Paolo: I would like to merge this. Do you agree? It's fine by me but note that I didn't review the patch. 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 Fri, May 19, 2017 at 04:41:46PM -0300, Eduardo Habkost wrote: > On Tue, May 09, 2017 at 07:18:07AM -0700, Richard Henderson wrote: > > On 05/09/2017 07:13 AM, Richard W.M. Jones wrote: > > > On Tue, May 09, 2017 at 07:05:51AM -0700, Richard Henderson wrote: > > > > > Daniel P. Berrange (2): > > > > > i386: rewrite way CPUID index is validated > > > > > i386: expose "TCGTCGTCGTCG" in the 0x40000000 CPUID leaf > > > > > > > > I probably should have commented earlier but... what's the point? > > > > > > > > If you want the guest os to actually do anything with this, what do > > > > you gain for advertising TCG over KVM? > > > > > > I can see this being useful from virt-what, since it would allow > > > vendors to diagnose problems being caused by TCG ... > > > > Thanks, that's an excellent point. > > Richard, Paolo: I would like to merge this. Do you agree? Ah, other Richard, OK! Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
On Fri, May 19, 2017 at 04:41:46PM -0300, Eduardo Habkost wrote: > On Tue, May 09, 2017 at 07:18:07AM -0700, Richard Henderson wrote: > > On 05/09/2017 07:13 AM, Richard W.M. Jones wrote: > > > On Tue, May 09, 2017 at 07:05:51AM -0700, Richard Henderson wrote: > > > > > Daniel P. Berrange (2): > > > > > i386: rewrite way CPUID index is validated > > > > > i386: expose "TCGTCGTCGTCG" in the 0x40000000 CPUID leaf > > > > > > > > I probably should have commented earlier but... what's the point? > > > > > > > > If you want the guest os to actually do anything with this, what do > > > > you gain for advertising TCG over KVM? > > > > > > I can see this being useful from virt-what, since it would allow > > > vendors to diagnose problems being caused by TCG ... > > > > Thanks, that's an excellent point. > > Richard, Paolo: I would like to merge this. Do you agree? ping, since there's no objections can we merge this now ? Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Wed, Jun 14, 2017 at 11:18:46AM +0100, Daniel P. Berrange wrote: > On Fri, May 19, 2017 at 04:41:46PM -0300, Eduardo Habkost wrote: > > On Tue, May 09, 2017 at 07:18:07AM -0700, Richard Henderson wrote: > > > On 05/09/2017 07:13 AM, Richard W.M. Jones wrote: > > > > On Tue, May 09, 2017 at 07:05:51AM -0700, Richard Henderson wrote: > > > > > > Daniel P. Berrange (2): > > > > > > i386: rewrite way CPUID index is validated > > > > > > i386: expose "TCGTCGTCGTCG" in the 0x40000000 CPUID leaf > > > > > > > > > > I probably should have commented earlier but... what's the point? > > > > > > > > > > If you want the guest os to actually do anything with this, what do > > > > > you gain for advertising TCG over KVM? > > > > > > > > I can see this being useful from virt-what, since it would allow > > > > vendors to diagnose problems being caused by TCG ... > > > > > > Thanks, that's an excellent point. > > > > Richard, Paolo: I would like to merge this. Do you agree? > > ping, since there's no objections can we merge this now ? Queued on x86-next. Thanks! -- Eduardo
On Tue, May 09, 2017 at 03:13:37PM +0100, Richard W.M. Jones wrote: > On Tue, May 09, 2017 at 07:05:51AM -0700, Richard Henderson wrote: > > On 05/09/2017 06:27 AM, Daniel P. Berrange wrote: > > >This enables report of a signature in CPUID for the TCG > > >interpretor. > > > > > >Changed in v4: > > > > > > - Report 0x40000001 in EAX for 0x40000000 index (Eduardo) > > > - Report all zeros for 0x40000001 index (Eduardo) > > > - Make code style consistent when checking limits (Eduardo) > > > > > >Changed in v3: > > > > > > - Simplify CPU limit code still further (Eduardo) > > > > > >Changed in v2: > > > > > > - Rewrite the way we bounds check / cap the CPUID index > > > to use a flat switch, instead of nested ifs (Eduardo) > > > - Add a 'tcg-cpuid' property to allow it to be hidden > > > (Eduardo) > > > - Hide the TCG signature for old machine types > > > - Force code to a no-op if tcg_enabled() is false (Eduardo) > > > > > > > > >NB, I did not introduce a general 'hypervisor-cpuid' property > > >to obsolete the existing 'kvm=off|on' -cpu property, since it > > >appears impossible to get the back compat semantics right, > > >as described in a previous reply. > > > > > >Daniel P. Berrange (2): > > > i386: rewrite way CPUID index is validated > > > i386: expose "TCGTCGTCGTCG" in the 0x40000000 CPUID leaf > > > > I probably should have commented earlier but... what's the point? > > > > If you want the guest os to actually do anything with this, what do > > you gain for advertising TCG over KVM? > > I can see this being useful from virt-what, since it would allow > vendors to diagnose problems being caused by TCG (since as Dan > mentions in the other reply and as you are already well acquainted > with, TCG and KVM don't present or emulate quite the same thing). > > That said, I don't think it's anything more than a nice to have. We also have systemd-detect-virt, and the ConditionVirtualization option in systemd. -- Eduardo
© 2016 - 2024 Red Hat, Inc.