From: "Michael S. Tsirkin" <mst@redhat.com>
To: Liran Alon <liran.alon@oracle.com>
Cc: nikita.leshchenko@oracle.com, ehabkost@redhat.com,
qemu-devel@nongnu.org, rth@twiddle.net
Subject: Re: [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements
Date: Tue, 10 Mar 2020 16:56:06 -0400 [thread overview]
Message-ID: <20200310164239-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <bcf7f439-7954-a6dc-322e-f8cbddd51d24@oracle.com>
On Tue, Mar 10, 2020 at 08:09:09PM +0200, Liran Alon wrote:
>
> On 10/03/2020 19:44, Michael S. Tsirkin wrote:
> > On Tue, Mar 10, 2020 at 06:53:16PM +0200, Liran Alon wrote:
> > > Hi,
> > >
> > > This series aims to fix several bugs in VMPort and improve it by supporting
> > > more VMPort commands and make command results more configurable to
> > > user via QEMU command-line.
> > >
> > > This functionality was proven to be useful to run various VMware VMs
> > > when attempting to run them as-is on top of QEMU/KVM.
> > >
> > > For more details, see commit messages.
> > Well two versions in one day and some review comments weren't addressed.
> There is a single review comment that wasn't addressed which is replacing an
> enum with a comment. And I explicitly mentioned that it's because I want
> additional opinion on this.
> I don't see why such a small thing should block review for 15 patches...
> All the rest of the comments (Which were great) have been addressed. Unless
> I have mistakenly missed something, which please point it out if I did.
OK I just took a quick peek, two things quickly jumped out at me.
version property really should be a boolean and have some documentation
saying what functionality enables.
userspace properties should use the non-abbreviated
vm-executable since vmx is easy to confuse with vm extensions.
That's just a quick look.
> > Some people do this, try to wear the maintainers out by sheer volume.
> > It works sometimes but it's not a nice tactic. I personally think it's
> > worth taking the time to think harder about ways to address all
> > comments, not try to dismiss them.
> That's not what I tried to do. I carefully fixed all comments I saw in the
> review discussion and run tests.
> The only thing which wasn't addressed is removing an enum and replacing it
> with a comment.
> The hint that I try to manipulate maintainers is disrespectful. I assume
> that this isn't your intention, as we all just want to collaborate together
> here. No need to make this a personal discussion.
>
> If you think that replacing the enum with a comment is a blocker for v2
> patch-series, I will go ahead and submit v3 with that change.
Yes IMHO it needs to be fixed but please go over the comments and try to
address them all as best you can, instead of looking for an explanation
why the comments were irrelevant and can be dismissed. Sure someone
might propose you introduce a bug, and that can't just be addressed, but
that's not the case here. Also please do not send multiple revisions of
a large patchset in a day. People need time for review.
> Is there any other comment you made on v1 patch-series you think I missed?
>
> Thanks,
> -Liran
>
> >
> > Thanks!
> >
> > > Regards,
> > > -Liran
> > >
> > > v1->v2:
> > > * Fix coding convention [Patchew Bot & MST].
> > > * Create new header file for vmport.h [MST].
> > > * Move KVM_APIC_BUS_FREQUENCY from linux-headers/asm-x86/kvm.h
> > > auto-generated header [MST]
> > > * Elaborate more that vmx-version refers to the VMware userspace
> > > VMM in commit message. [MST]
> > > * Use le32_to_cpu() on BIOS_UUID vmport command. [MST]
> > > * Introduce VMPort compatability version property to maintain migration
> > > compatibility. [MST]
next prev parent reply other threads:[~2020-03-10 20:57 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-10 16:53 [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Liran Alon
2020-03-10 16:53 ` [PATCH v2 01/16] hw/i386/vmport: Add device properties Liran Alon
2020-03-10 16:53 ` [PATCH v2 02/16] hw/i386/vmport: Add compatability version field Liran Alon
2020-03-10 16:53 ` [PATCH v2 03/16] hw/i386/vmport: Propagate IOPort read to vCPU EAX register Liran Alon
2020-03-10 16:53 ` [PATCH v2 04/16] hw/i386/vmport: Set EAX to -1 on failed and unsupported commands Liran Alon
2020-03-10 16:53 ` [PATCH v2 05/16] hw/i386/vmport: Introduce vmx-version property Liran Alon
2020-03-10 16:53 ` [PATCH v2 06/16] hw/i386/vmport: Report VMX type in CMD_GETVERSION Liran Alon
2020-03-10 16:53 ` [PATCH v2 07/16] hw/i386/vmport: Introduce vmport.h Liran Alon
2020-03-10 16:53 ` [PATCH v2 08/16] hw/i386/vmport: Define enum for all commands Liran Alon
2020-03-10 16:53 ` [PATCH v2 09/16] hw/i386/vmport: Add support for CMD_GETBIOSUUID Liran Alon
2020-03-10 16:53 ` [PATCH v2 10/16] hw/i386/vmport: Add support for CMD_GETTIME Liran Alon
2020-03-10 16:53 ` [PATCH v2 11/16] hw/i386/vmport: Add support for CMD_GETTIMEFULL Liran Alon
2020-03-10 16:53 ` [PATCH v2 12/16] hw/i386/vmport: Add support for CMD_GET_VCPU_INFO Liran Alon
2020-03-10 16:53 ` [PATCH v2 13/16] hw/i386/vmport: Allow x2apic without IR Liran Alon
2020-03-10 16:53 ` [PATCH v2 14/16] i386/cpu: Store LAPIC bus frequency in CPU structure Liran Alon
2020-03-10 16:53 ` [PATCH v2 15/16] hw/i386/vmport: Add support for CMD_GETHZ Liran Alon
2020-03-10 16:53 ` [PATCH v2 16/16] hw/i386/vmport: Assert vmport initialized before registering commands Liran Alon
2020-03-10 17:44 ` [PATCH v2 00/16]: hw/i386/vmport: Bug fixes and improvements Michael S. Tsirkin
2020-03-10 18:09 ` Liran Alon
2020-03-10 20:56 ` Michael S. Tsirkin [this message]
2020-03-10 21:29 ` Liran Alon
2020-03-10 21:44 ` Michael S. Tsirkin
2020-03-10 21:57 ` Liran Alon
2020-03-10 22:00 ` Michael S. Tsirkin
2020-03-10 22:19 ` Liran Alon
2020-03-11 6:29 ` Michael S. Tsirkin
2020-03-10 19:12 ` 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=20200310164239-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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.