From: "Michael S. Tsirkin" <mst@redhat.com>
To: Liran Alon <liran.alon@oracle.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 07:18:17 -0400 [thread overview]
Message-ID: <20200310071453-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <0dd22d9c-e1d2-db1e-372e-5009be705dab@oracle.com>
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).
> 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?
Pretending to be a very advanced version has its pitfalls if we
then don't behave the way vmware does, right?
Figuring out the version number is I suspect a bit much to ask of users.
> >
> > > ---
> > > hw/i386/vmport.c | 6 +++++-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/hw/i386/vmport.c b/hw/i386/vmport.c
> > > index 7c21e56081b0..a2c8ff4b59cf 100644
> > > --- a/hw/i386/vmport.c
> > > +++ b/hw/i386/vmport.c
> > > @@ -44,6 +44,8 @@ typedef struct VMPortState {
> > > MemoryRegion io;
> > > VMPortReadFunc *func[VMPORT_ENTRIES];
> > > void *opaque[VMPORT_ENTRIES];
> > > +
> > > + uint32_t vmx_version;
> > > } VMPortState;
> > > static VMPortState *port_state;
> > > @@ -112,7 +114,7 @@ static uint32_t vmport_cmd_get_version(void *opaque, uint32_t addr)
> > > X86CPU *cpu = X86_CPU(current_cpu);
> > > cpu->env.regs[R_EBX] = VMPORT_MAGIC;
> > > - return 6;
> > > + return port_state->vmx_version;
> > > }
> > > static uint32_t vmport_cmd_ram_size(void *opaque, uint32_t addr)
> > > @@ -169,6 +171,8 @@ static void vmport_realizefn(DeviceState *dev, Error **errp)
> > > }
> > > static Property vmport_properties[] = {
> > > + /* Default value taken from open-vm-tools code VERSION_MAGIC definition */
> > > + DEFINE_PROP_UINT32("vmx-version", VMPortState, vmx_version, 6),
> > > DEFINE_PROP_END_OF_LIST(),
> > > };
> > > --
> > > 2.20.1
next prev parent reply other threads:[~2020-03-10 11:19 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 [this message]
2020-03-10 11:28 ` Liran Alon
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=20200310071453-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=ehabkost@redhat.com \
--cc=liran.alon@oracle.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).