From: Paolo Bonzini <pbonzini@redhat.com>
To: Greg Kurz <gkurz@linux.vnet.ibm.com>
Cc: Michael Roth <mdroth@linux.vnet.ibm.com>,
Cedric Le Goater <clg@fr.ibm.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
qemu-devel@nongnu.org, qemu-stable@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 2/2] memory: fix the eventfd data endianness according to the host
Date: Fri, 13 Mar 2015 15:52:50 +0100 [thread overview]
Message-ID: <5502F9C2.7040800@redhat.com> (raw)
In-Reply-To: <20150313123212.481ce3f6@bahia.local>
On 13/03/2015 12:32, Greg Kurz wrote:
> On Fri, 13 Mar 2015 12:06:06 +0100
> Paolo Bonzini <pbonzini@redhat.com> wrote:
>>
>>
>> On 13/03/2015 09:11, Greg Kurz wrote:
>>> The data argument is a host entity. It is not related to the target
>>> endianness. Let's introduce a HOST_WORDS_BIGENDIAN based helper for
>>> that.
>>>
>>> This patch fixes ioeventfd and vhost for a ppc64le host running a ppc64le
>>> guest (only virtqueue 0 was handled, all others being byteswapped because
>>> of TARGET_WORDS_BIGENDIAN). It doesn't change functionnality for fixed
>>> endian architectures (i.e. doesn't break x86).
>>>
>>> Reported-by: Cédric Le Goater <clg@fr.ibm.com>
>>> Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
>>> ---
>>> memory.c | 13 +++++++++++--
>>> 1 file changed, 11 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/memory.c b/memory.c
>>> index 6291cc0..1e29d40 100644
>>> --- a/memory.c
>>> +++ b/memory.c
>>> @@ -1549,6 +1549,15 @@ void memory_region_clear_flush_coalesced(MemoryRegion *mr)
>>> }
>>> }
>>>
>>> +static bool eventfd_wrong_endianness(MemoryRegion *mr)
>>> +{
>>> +#ifdef HOST_WORDS_BIGENDIAN
>>> + return mr->ops->endianness == DEVICE_LITTLE_ENDIAN;
>>> +#else
>>> + return mr->ops->endianness == DEVICE_BIG_ENDIAN;
>>> +#endif
>>> +}
>>> +
>>> void memory_region_add_eventfd(MemoryRegion *mr,
>>> hwaddr addr,
>>> unsigned size,
>>> @@ -1565,7 +1574,7 @@ void memory_region_add_eventfd(MemoryRegion *mr,
>>> };
>>> unsigned i;
>>>
>>> - adjust_endianness(&mrfd.data, size, memory_region_wrong_endianness(mr));
>>> + adjust_endianness(&mrfd.data, size, eventfd_wrong_endianness(mr));
>>
>> Strictly speaking, the place to do this would be kvm_set_ioeventfd_mmio.
>
> FWIW the swap is being done in memory.c since commit:
>
> commit 28f362be6e7f45ea9b7a57a08555c4c784f36198
> Author: Alexander Graf <agraf@suse.de>
> Date: Mon Oct 15 20:30:28 2012 +0200
>
> memory: Make eventfd adhere to device endianness
>
> Are you asking to revert this commit and to pass the device endianness to
> kvm_set_ioeventfd_mmio() so it can fix the ordering ?
Yes.
>> A hypothetical userspace ioeventfd emulation would not need the swap.
>
> I don't understand why "would not need the swap"...
Because the userspace ioeventfd emulation would look at the value as it
comes from the target CPU, in target CPU endianness. So it would have a
swap done at ioeventfd time, and a swap done at access time. Host
endianness doesn't matter.
Here, QEMU believes that the target's natural endianness is big-endian,
but the kernel believes that the target's natural endianness is
little-endian (based on MSR_KERNEL). So there is a different number of
swaps in memory_region_add_eventfd and in the kernel's kvmppc_handle_store.
Does something like this work?
#if defined(HOST_WORDS_BIGENDIAN) != defined(TARGET_WORDS_BIGENDIAN)
/* The kernel expects ioeventfd values in HOST_WORDS_BIGENDIAN
* endianness, but the memory core hands them in target endianness.
* For example, PPC is always treated as big-endian even if running
* on KVM and on PPC64LE. Correct here.
*/
switch(size) {
case 2:
val = bswap16(val);
break;
case 4:
val = bswap32(val);
break;
}
#endif
in kvm_set_ioeventfd_mmio and kvm_set_ioeventfd_pio?
Paolo
>
>> I can accept the patch, but it's better to add a comment.
>>
>
> ... and so I don't know what to write. :)
>
> Please enlight !
>
> --
> Greg
>
>> Paolo
>>
>>> memory_region_transaction_begin();
>>> for (i = 0; i < mr->ioeventfd_nb; ++i) {
>>> if (memory_region_ioeventfd_before(mrfd, mr->ioeventfds[i])) {
>>> @@ -1598,7 +1607,7 @@ void memory_region_del_eventfd(MemoryRegion *mr,
>>> };
>>> unsigned i;
>>>
>>> - adjust_endianness(&mrfd.data, size, memory_region_wrong_endianness(mr));
>>> + adjust_endianness(&mrfd.data, size, eventfd_wrong_endianness(mr));
>>> memory_region_transaction_begin();
>>> for (i = 0; i < mr->ioeventfd_nb; ++i) {
>>> if (memory_region_ioeventfd_equal(mrfd, mr->ioeventfds[i])) {
>>>
>>
>
next prev parent reply other threads:[~2015-03-13 14:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-11 18:04 [Qemu-devel] [PATCH] virtio-pci: fix host notifiers on bi-endian architectures Greg Kurz
2015-03-11 20:06 ` Michael S. Tsirkin
2015-03-11 22:03 ` Greg Kurz
2015-03-11 22:18 ` [Qemu-devel] [Qemu-ppc] " Benjamin Herrenschmidt
2015-03-11 22:52 ` Greg Kurz
2015-03-12 7:10 ` Michael S. Tsirkin
2015-03-12 7:08 ` [Qemu-devel] " Michael S. Tsirkin
2015-03-12 16:25 ` Paolo Bonzini
2015-03-13 8:03 ` Greg Kurz
2015-03-13 8:11 ` [Qemu-devel] [PATCH 1/2] memory: make adjust_endianness() generic Greg Kurz
2015-03-13 8:11 ` [Qemu-devel] [PATCH 2/2] memory: fix the eventfd data endianness according to the host Greg Kurz
2015-03-13 11:06 ` Paolo Bonzini
2015-03-13 11:32 ` Greg Kurz
2015-03-13 14:52 ` Paolo Bonzini [this message]
2015-03-13 15:24 ` Michael S. Tsirkin
2015-03-13 14:23 ` Michael S. Tsirkin
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=5502F9C2.7040800@redhat.com \
--to=pbonzini@redhat.com \
--cc=clg@fr.ibm.com \
--cc=gkurz@linux.vnet.ibm.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
/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).