From: David Daney <david.s.daney@gmail.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Sanjay Lal <sanjayl@kymasys.com>,
linux-mips@linux-mips.org, kvm@vger.kernel.org,
ralf@linux-mips.org, mtosatti@redhat.com,
David Daney <david.daney@cavium.com>
Subject: Re: [PATCH 4/4] KVM/MIPS32: Bring in patch from David Daney with new 64 bit compatible ABI.
Date: Sun, 19 May 2013 14:17:33 -0700 [thread overview]
Message-ID: <5199416D.1010200@gmail.com> (raw)
In-Reply-To: <20130519141712.GL4725@redhat.com>
On 05/19/2013 07:17 AM, Gleb Natapov wrote:
> On Sat, May 18, 2013 at 06:54:26AM -0700, Sanjay Lal wrote:
>> From: David Daney <david.daney@cavium.com>
>>
>> There are several parts to this:
>>
>> o All registers are 64-bits wide, 32-bit guests use the least
>> significant portion of the register storage fields.
>>
>> o FPU register formats are defined.
>>
>> o CP0 Registers are manipulated via the KVM_GET_MSRS/KVM_SET_MSRS
>> mechanism.
>>
>> The vcpu_ioctl_get_regs and vcpu_ioctl_set_regs function pointers
>> become unused so they were removed.
>>
>> Some IOCTL functions were moved to kvm_trap_emul because the
>> implementations are only for that flavor of KVM host. In the future, if
>> hardware based virtualization is added, they can be hidden behind
>> function pointers as appropriate.
>>
> David, can you please divide this one big patch to smaller patches
> with each one having only one of the changes listed above?
Expanding the registers to 64 bits changes only four lines. Defining the
FPU registers is an additional seven lines. The rest really has to be
an atomic change.
The point here is that we change the ABI. Any userspace tools have to
change too. So is it better to have a multi-part patch set where the
interface is unusable in the intermediate patches? Or is it preferable
to do an 'atomic' switch?
It wasn't out of laziness that I chose to do it this way, it was because
I thought it was cleaner.
So to directly answer your question: I prefer not to split this up, and
would want to have a better reason than an orthodox interpretation of
SubmittingPatches sec. 3.
David Daney
next prev parent reply other threads:[~2013-05-19 21:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-18 13:54 [PATCH v3 0/4] KVM/MIPS32: Fixes for Linux 3.10 Sanjay Lal
2013-05-18 13:54 ` [PATCH 1/4] KVM/MIPS32: Move include/asm/kvm.h => include/uapi/asm/kvm.h since it is a user visible API Sanjay Lal
2013-05-18 13:54 ` [PATCH 2/4] KVM/MIPS32: Wrap calls to gfn_to_pfn() with srcu_read_lock/unlock() Sanjay Lal
2013-05-19 12:52 ` Gleb Natapov
2013-05-19 14:36 ` Sanjay Lal
2013-05-21 8:00 ` Gleb Natapov
2013-05-21 14:22 ` Sanjay Lal
2013-05-18 13:54 ` [PATCH 3/4] KVM/MIPS32: Export min_low_pfn Sanjay Lal
2013-05-18 13:54 ` [PATCH 4/4] KVM/MIPS32: Bring in patch from David Daney with new 64 bit compatible ABI Sanjay Lal
2013-05-19 14:17 ` Gleb Natapov
2013-05-19 21:17 ` David Daney [this message]
2013-05-20 6:02 ` Gleb Natapov
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=5199416D.1010200@gmail.com \
--to=david.s.daney@gmail.com \
--cc=david.daney@cavium.com \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=mtosatti@redhat.com \
--cc=ralf@linux-mips.org \
--cc=sanjayl@kymasys.com \
/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.