All of lore.kernel.org
 help / color / mirror / Atom feed
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/3] virtio-mmio: handle BE guests on LE hosts
Date: Mon, 14 Oct 2013 16:36:57 +0100	[thread overview]
Message-ID: <525C0F99.8030909@arm.com> (raw)
In-Reply-To: <525C0C21.2070001@redhat.com>

On 14/10/13 16:22, Paolo Bonzini wrote:
> Il 14/10/2013 17:12, Marc Zyngier ha scritto:
>> On 14/10/13 15:56, Paolo Bonzini wrote:
>>> Il 14/10/2013 16:52, Marc Zyngier ha scritto:
>>>>>> Sure. And I imagine this traps back into the kernel to read some
>>>>>> register and find out what the endianness of the accessing CPU is?
>>>>>
>>>>> Not yet. To be exact, it does the below today. But all virtio device
>>>>> emulation is 100% guest endianness unaware. This helper is the only
>>>>> piece of code where it gets any idea what endianness the guest has. So
>>>>> by checking for references to it in the code you know where endianness
>>>>> is an issue. And that's only in the config space.
>>>>
>>>> Only config space? How do you deal with virtio ring descriptors, for
>>>> example?
>>>
>>> They also use guest endianness, but do not use virtio_is_big_endian()
>>> (yet?) so Alex missed them.
>>
>> Yeah, I thought as much. There is a whole bunch of things that need byte
>> swapping, both at the virtio level itself, and at the device level as well.
>>
>> Grep-ing for __u{16,32,64} through include/uapi/linux/virtio* shows the
>> extent of the disaster.
> 
> Devices are fine in QEMU, it's only the "generic" parts (rings) that are
> missing AFAICT.

So if I understand correctly how it works, target endianness is set at
compile time, and you have a BE specific QEMU?

	M.
-- 
Jazz is not dead. It just smells funny...

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <marc.zyngier@arm.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Alexander Graf <agraf@suse.de>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"kvm@vger.kernel.org mailing list" <kvm@vger.kernel.org>,
	Pawel Moll <Pawel.Moll@arm.com>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 0/3] virtio-mmio: handle BE guests on LE hosts
Date: Mon, 14 Oct 2013 16:36:57 +0100	[thread overview]
Message-ID: <525C0F99.8030909@arm.com> (raw)
In-Reply-To: <525C0C21.2070001@redhat.com>

On 14/10/13 16:22, Paolo Bonzini wrote:
> Il 14/10/2013 17:12, Marc Zyngier ha scritto:
>> On 14/10/13 15:56, Paolo Bonzini wrote:
>>> Il 14/10/2013 16:52, Marc Zyngier ha scritto:
>>>>>> Sure. And I imagine this traps back into the kernel to read some
>>>>>> register and find out what the endianness of the accessing CPU is?
>>>>>
>>>>> Not yet. To be exact, it does the below today. But all virtio device
>>>>> emulation is 100% guest endianness unaware. This helper is the only
>>>>> piece of code where it gets any idea what endianness the guest has. So
>>>>> by checking for references to it in the code you know where endianness
>>>>> is an issue. And that's only in the config space.
>>>>
>>>> Only config space? How do you deal with virtio ring descriptors, for
>>>> example?
>>>
>>> They also use guest endianness, but do not use virtio_is_big_endian()
>>> (yet?) so Alex missed them.
>>
>> Yeah, I thought as much. There is a whole bunch of things that need byte
>> swapping, both at the virtio level itself, and at the device level as well.
>>
>> Grep-ing for __u{16,32,64} through include/uapi/linux/virtio* shows the
>> extent of the disaster.
> 
> Devices are fine in QEMU, it's only the "generic" parts (rings) that are
> missing AFAICT.

So if I understand correctly how it works, target endianness is set at
compile time, and you have a BE specific QEMU?

	M.
-- 
Jazz is not dead. It just smells funny...


  reply	other threads:[~2013-10-14 15:36 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-11 14:36 [PATCH 0/3] virtio-mmio: handle BE guests on LE hosts Marc Zyngier
2013-10-11 14:36 ` Marc Zyngier
2013-10-11 14:36 ` [PATCH 1/3] virtio: let the guest report its endianess if advertized by the host Marc Zyngier
2013-10-11 14:36   ` Marc Zyngier
2013-10-11 14:36 ` [PATCH 2/3] virtio: mmio: fix signature checking for BE guests Marc Zyngier
2013-10-11 14:36   ` Marc Zyngier
2013-10-14  8:46   ` Pawel Moll
2013-10-14  8:46     ` Pawel Moll
2013-10-14  9:11     ` Rusty Russell
2013-10-14  9:11       ` Rusty Russell
2013-11-05  3:36       ` Rusty Russell
2013-11-05  3:36         ` Rusty Russell
2013-11-05 10:45         ` Pawel Moll
2013-11-05 10:45           ` Pawel Moll
2013-11-07  0:36           ` Rusty Russell
2013-11-07  0:36             ` Rusty Russell
2013-10-11 14:36 ` [PATCH 3/3] virtio: mmio: access configuration space as little-endian Marc Zyngier
2013-10-11 14:36   ` Marc Zyngier
2013-10-14  8:44   ` Pawel Moll
2013-10-14  8:44     ` Pawel Moll
2013-10-12 18:28 ` [PATCH 0/3] virtio-mmio: handle BE guests on LE hosts Michael S. Tsirkin
2013-10-12 18:28   ` Michael S. Tsirkin
2013-10-14  8:24   ` Marc Zyngier
2013-10-14  8:24     ` Marc Zyngier
2013-10-14  8:59     ` Michael S. Tsirkin
2013-10-14  8:59       ` Michael S. Tsirkin
2013-10-14  9:04       ` Pawel Moll
2013-10-14  9:04         ` Pawel Moll
2013-10-14 10:46         ` Michael S. Tsirkin
2013-10-14 10:46           ` Michael S. Tsirkin
2013-10-14 10:50           ` Pawel Moll
2013-10-14 10:50             ` Pawel Moll
2013-10-14 23:02             ` Rusty Russell
2013-10-14 23:02               ` Rusty Russell
2013-10-14  9:13     ` Rusty Russell
2013-10-14  9:13       ` Rusty Russell
2013-10-14  8:21 ` Rusty Russell
2013-10-14  8:21   ` Rusty Russell
2013-10-14 12:36   ` Marc Zyngier
2013-10-14 12:36     ` Marc Zyngier
2013-10-14 12:51     ` Michael S. Tsirkin
2013-10-14 12:51       ` Michael S. Tsirkin
2013-10-17  0:27     ` Rusty Russell
2013-10-17  0:27       ` Rusty Russell
2013-10-14 13:03 ` Paolo Bonzini
2013-10-14 13:03   ` Paolo Bonzini
2013-10-14 13:10   ` Alexander Graf
2013-10-14 13:10     ` Alexander Graf
2013-10-14 13:13     ` Paolo Bonzini
2013-10-14 13:13       ` Paolo Bonzini
2013-10-14 13:24     ` Marc Zyngier
2013-10-14 13:24       ` Marc Zyngier
2013-10-14 13:29       ` Paolo Bonzini
2013-10-14 13:29         ` Paolo Bonzini
2013-10-14 13:39       ` Alexander Graf
2013-10-14 13:39         ` Alexander Graf
2013-10-14 13:49         ` Marc Zyngier
2013-10-14 13:49           ` Marc Zyngier
2013-10-14 14:05           ` Michael S. Tsirkin
2013-10-14 14:05             ` Michael S. Tsirkin
2013-10-14 14:13             ` Marc Zyngier
2013-10-14 14:13               ` Marc Zyngier
2013-10-14 14:16               ` Alexander Graf
2013-10-14 14:16                 ` Alexander Graf
2013-10-14 14:52                 ` Marc Zyngier
2013-10-14 14:52                   ` Marc Zyngier
2013-10-14 14:56                   ` Paolo Bonzini
2013-10-14 14:56                     ` Paolo Bonzini
2013-10-14 15:12                     ` Marc Zyngier
2013-10-14 15:12                       ` Marc Zyngier
2013-10-14 15:22                       ` Paolo Bonzini
2013-10-14 15:22                         ` Paolo Bonzini
2013-10-14 15:36                         ` Marc Zyngier [this message]
2013-10-14 15:36                           ` Marc Zyngier
2013-10-14 16:50                           ` Paolo Bonzini
2013-10-14 16:50                             ` Paolo Bonzini
2013-10-14 17:10                             ` Michael S. Tsirkin
2013-10-14 17:10                               ` Michael S. Tsirkin
2013-10-14 23:23                               ` Rusty Russell
2013-10-14 23:23                                 ` Rusty Russell
2013-10-15  6:38                                 ` Michael S. Tsirkin
2013-10-15  6:38                                   ` Michael S. Tsirkin
2013-10-15  9:19                                   ` Marc Zyngier
2013-10-15  9:19                                     ` Marc Zyngier
2013-10-14 15:45                         ` Anup Patel
2013-10-14 15:45                           ` Anup Patel

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=525C0F99.8030909@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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 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.