From: Liran Alon <liran.alon@oracle.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: ehabkost@redhat.com, qemu-devel@nongnu.org,
Nikita Leshenko <nikita.leshchenko@oracle.com>,
pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [PATCH 04/14] hw/i386/vmport: Introduce vmx-version property
Date: Tue, 10 Mar 2020 13:28:32 +0200 [thread overview]
Message-ID: <10ffd04f-30f9-6333-26ef-169cd1615341@oracle.com> (raw)
In-Reply-To: <20200310071453-mutt-send-email-mst@kernel.org>
On 10/03/2020 13:18, Michael S. Tsirkin wrote:
> On Tue, Mar 10, 2020 at 01:05:02PM +0200, Liran Alon wrote:
>> On 10/03/2020 11:32, Michael S. Tsirkin wrote:
>>> On Tue, Mar 10, 2020 at 01:54:01AM +0200, Liran Alon wrote:
>>>> Instead of hard-coding the VMX version, make it a VMPORT object property.
>>>> This would allow user to control it's value via "-global vmport.vmx-version=X".
>>>>
>>>> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
>>>> Signed-off-by: Liran Alon <liran.alon@oracle.com>
>>> More detail on why this is useful?
>> It's more useful than returning a hard-coded "6" as the vmx-version...
>
> Maybe default should be 6 (a bit of explanation why 6 could be nice).
The default is indeed defined as 6. As it was before this patch.
There is not much to explain besides the fact that recent VMware
products returns 6 here.
I don't recall any mapping between the returned version here and the
supported set of VMPort commands. There is a separate mechanism (which
we implement in another patch) to signal that a command is unsupported /
failed.
The term "vmx-version" refers to the version of the Userspace-VMM of
VMware which is called (confusingly) "vmx".
>> We have used it to preserve compatibility for some VMware guests that we run
>> as-is on top of QEMU/KVM which expects specific vmx-version or else they
>> fail to run properly.
>>
>> -Liran
> Any detail on which guest it is?
I will need to dig in production history to find it... They are usually
proprietary appliances specially made to run as VMware VMs.
> Pretending to be a very advanced version has its pitfalls if we
> then don't behave the way vmware does, right?
In all those cases, we have taken the version number backwards, not forward.
> Figuring out the version number is I suspect a bit much to ask of users.
Most users will indeed not need to touch this. This is for advanced
users, such as Ravello.
We usually figured this out by reverse-engineering the failed guest
and/or examining the original VMware environment it used to run on.
-Liran
next prev parent reply other threads:[~2020-03-10 11:29 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-09 23:53 [PATCH 00/14]: hw/i386/vmport: Bug fixes and improvements Liran Alon
2020-03-09 23:53 ` [PATCH 01/14] hw/i386/vmport: Propagate IOPort read to vCPU EAX register Liran Alon
2020-03-09 23:53 ` [PATCH 02/14] hw/i386/vmport: Set EAX to -1 on failed and unsupported commands Liran Alon
2020-03-09 23:54 ` [PATCH 03/14] hw/i386/vmport: Add device properties Liran Alon
2020-03-09 23:54 ` [PATCH 04/14] hw/i386/vmport: Introduce vmx-version property Liran Alon
2020-03-10 9:32 ` Michael S. Tsirkin
2020-03-10 11:05 ` Liran Alon
2020-03-10 11:18 ` Michael S. Tsirkin
2020-03-10 11:28 ` Liran Alon [this message]
2020-03-10 11:44 ` Michael S. Tsirkin
2020-03-10 11:53 ` Liran Alon
2020-03-09 23:54 ` [PATCH 05/14] hw/i386/vmport: Report VMX type in CMD_GETVERSION Liran Alon
2020-03-10 9:20 ` Michael S. Tsirkin
2020-03-10 11:18 ` Liran Alon
2020-03-10 11:23 ` Michael S. Tsirkin
2020-03-10 11:40 ` Liran Alon
2020-03-10 11:47 ` Michael S. Tsirkin
2020-03-10 12:14 ` Michael S. Tsirkin
2020-03-10 12:25 ` Liran Alon
2020-03-10 12:35 ` Michael S. Tsirkin
2020-03-10 12:43 ` Liran Alon
2020-03-10 12:53 ` Michael S. Tsirkin
2020-03-10 13:35 ` Liran Alon
2020-03-10 14:08 ` Michael S. Tsirkin
2020-03-10 14:46 ` Liran Alon
2020-03-10 15:10 ` Michael S. Tsirkin
2020-03-10 16:39 ` Liran Alon
2020-03-10 17:36 ` Michael S. Tsirkin
2020-03-10 17:58 ` Liran Alon
2020-03-10 21:16 ` Michael S. Tsirkin
2020-03-10 21:34 ` Liran Alon
2020-03-10 21:49 ` Michael S. Tsirkin
2020-03-10 21:59 ` Liran Alon
2020-03-10 22:04 ` Michael S. Tsirkin
2020-03-09 23:54 ` [PATCH 06/14] hw/i386/vmport: Define enum for all commands Liran Alon
2020-03-10 9:28 ` Michael S. Tsirkin
2020-03-10 11:16 ` Liran Alon
2020-03-10 11:23 ` Michael S. Tsirkin
2020-03-10 11:37 ` Liran Alon
2020-03-10 11:46 ` Michael S. Tsirkin
2020-03-10 11:54 ` Liran Alon
2020-03-09 23:54 ` [PATCH 07/14] hw/i386/vmport: Add support for CMD_GETBIOSUUID Liran Alon
2020-03-10 9:22 ` Michael S. Tsirkin
2020-03-10 11:44 ` Liran Alon
2020-03-10 12:01 ` Michael S. Tsirkin
2020-03-10 12:37 ` Liran Alon
2020-03-10 13:01 ` Michael S. Tsirkin
2020-03-10 9:34 ` Michael S. Tsirkin
2020-03-10 11:13 ` Liran Alon
2020-03-10 11:22 ` Michael S. Tsirkin
2020-03-10 11:35 ` Liran Alon
2020-03-10 14:24 ` Liran Alon
2020-03-10 14:39 ` Michael S. Tsirkin
2020-03-10 14:56 ` Liran Alon
2020-03-09 23:54 ` [PATCH 08/14] hw/i386/vmport: Add support for CMD_GETTIME Liran Alon
2020-03-09 23:54 ` [PATCH 09/14] hw/i386/vmport: Add support for CMD_GETTIMEFULL Liran Alon
2020-03-09 23:54 ` [PATCH 10/14] hw/i386/vmport: Add support for CMD_GET_VCPU_INFO Liran Alon
2020-03-09 23:54 ` [PATCH 11/14] hw/i386/vmport: Allow x2apic without IR Liran Alon
2020-03-09 23:54 ` [PATCH 12/14] i386/cpu: Store LAPIC bus frequency in CPU structure Liran Alon
2020-03-10 9:29 ` Michael S. Tsirkin
2020-03-10 10:53 ` Liran Alon
2020-03-10 12:27 ` Michael S. Tsirkin
2020-03-10 12:29 ` Liran Alon
2020-03-09 23:54 ` [PATCH 13/14] hw/i386/vmport: Add support for CMD_GETHZ Liran Alon
2020-03-09 23:54 ` [PATCH 14/14] hw/i386/vmport: Assert vmport initialized before registering commands Liran Alon
2020-03-10 9:30 ` Michael S. Tsirkin
2020-03-10 10:57 ` Liran Alon
2020-03-10 0:13 ` [PATCH 00/14]: hw/i386/vmport: Bug fixes and improvements no-reply
2020-03-10 0:16 ` Liran Alon
2020-03-10 0:53 ` no-reply
2020-03-10 0:54 ` no-reply
2020-03-10 0:57 ` Liran Alon
2020-03-10 1:10 ` no-reply
2020-03-10 1:49 ` no-reply
2020-03-10 1:50 ` no-reply
2020-03-10 2:04 ` no-reply
2020-03-10 2:22 ` no-reply
2020-03-10 2:56 ` no-reply
2020-03-10 2:56 ` no-reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=10ffd04f-30f9-6333-26ef-169cd1615341@oracle.com \
--to=liran.alon@oracle.com \
--cc=ehabkost@redhat.com \
--cc=mst@redhat.com \
--cc=nikita.leshchenko@oracle.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).