On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-19 at 21:21 -0600, Alex Williamson wrote:
Working on big endian being an accident may be a matter of perspective
:-)
The comment remains that this patch doesn't actually fix anything except
the overhead on big endian
On 24.06.14 12:11, Alexey Kardashevskiy wrote:
On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-19 at 21:21 -0600, Alex Williamson wrote:
Working on big endian being an accident may be a matter of perspective
:-)
The comment remains that this patch doesn't actually
On 06/24/2014 08:41 PM, Alexander Graf wrote:
On 24.06.14 12:11, Alexey Kardashevskiy wrote:
On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-19 at 21:21 -0600, Alex Williamson wrote:
Working on big endian being an accident may be a matter of perspective
:-)
The
On 24.06.14 14:50, Alexey Kardashevskiy wrote:
On 06/24/2014 08:41 PM, Alexander Graf wrote:
On 24.06.14 12:11, Alexey Kardashevskiy wrote:
On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-19 at 21:21 -0600, Alex Williamson wrote:
Working on big endian being an
On 06/24/2014 10:52 PM, Alexander Graf wrote:
On 24.06.14 14:50, Alexey Kardashevskiy wrote:
On 06/24/2014 08:41 PM, Alexander Graf wrote:
On 24.06.14 12:11, Alexey Kardashevskiy wrote:
On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-19 at 21:21 -0600, Alex Williamson
On 24.06.14 15:01, Alexey Kardashevskiy wrote:
On 06/24/2014 10:52 PM, Alexander Graf wrote:
On 24.06.14 14:50, Alexey Kardashevskiy wrote:
On 06/24/2014 08:41 PM, Alexander Graf wrote:
On 24.06.14 12:11, Alexey Kardashevskiy wrote:
On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
On
On Tue, 2014-06-24 at 15:22 +0200, Alexander Graf wrote:
On 24.06.14 15:01, Alexey Kardashevskiy wrote:
On 06/24/2014 10:52 PM, Alexander Graf wrote:
On 24.06.14 14:50, Alexey Kardashevskiy wrote:
On 06/24/2014 08:41 PM, Alexander Graf wrote:
On 24.06.14 12:11, Alexey Kardashevskiy wrote:
On 06/25/2014 12:21 AM, Alex Williamson wrote:
On Tue, 2014-06-24 at 15:22 +0200, Alexander Graf wrote:
On 24.06.14 15:01, Alexey Kardashevskiy wrote:
On 06/24/2014 10:52 PM, Alexander Graf wrote:
On 24.06.14 14:50, Alexey Kardashevskiy wrote:
On 06/24/2014 08:41 PM, Alexander Graf wrote:
On
From: Alexey Kardashevskiy
...
So IMHO we should either create new, generic iowrite helpers that don't
do any endian swapping at all or do iowrite32(cpu_to_le32(val)) calls.
I'm one of those people for whom iowrite32(le32_to_cpu(val)) makes sense
I do not understand why @val is
On Wed, 2014-06-25 at 00:33 +1000, Alexey Kardashevskiy wrote:
On 06/25/2014 12:21 AM, Alex Williamson wrote:
On Tue, 2014-06-24 at 15:22 +0200, Alexander Graf wrote:
On 24.06.14 15:01, Alexey Kardashevskiy wrote:
On 06/24/2014 10:52 PM, Alexander Graf wrote:
On 24.06.14 14:50, Alexey
On 06/25/2014 12:43 AM, Alex Williamson wrote:
On Wed, 2014-06-25 at 00:33 +1000, Alexey Kardashevskiy wrote:
On 06/25/2014 12:21 AM, Alex Williamson wrote:
On Tue, 2014-06-24 at 15:22 +0200, Alexander Graf wrote:
On 24.06.14 15:01, Alexey Kardashevskiy wrote:
On 06/24/2014 10:52 PM,
On Tue, 2014-06-24 at 12:41 +0200, Alexander Graf wrote:
Is there actually any difference in generated code with this patch
applied and without? I would hope that iowrite..() is inlined and
cancels out the cpu_to_le..() calls that are also inlined?
No, the former uses byteswapping asm, the
On Wed, 2014-06-25 at 00:33 +1000, Alexey Kardashevskiy wrote:
I do not understand why @val is considered LE here and need to be
converted
to CPU. Really. I truly believe it should be cpu_to_le32().
No. Both are slightly wrong semantically but le32_to_cpu() is less
wrong :-)
iowrite32
On 06/25/2014 07:54 AM, Benjamin Herrenschmidt wrote:
On Wed, 2014-06-25 at 00:33 +1000, Alexey Kardashevskiy wrote:
I do not understand why @val is considered LE here and need to be
converted
to CPU. Really. I truly believe it should be cpu_to_le32().
No. Both are slightly wrong
On 06/20/2014 01:21 PM, Alex Williamson wrote:
On Thu, 2014-06-19 at 13:48 +1000, Alexey Kardashevskiy wrote:
On 06/19/2014 11:50 AM, Alexey Kardashevskiy wrote:
On 06/19/2014 10:50 AM, Alexey Kardashevskiy wrote:
On 06/19/2014 04:35 AM, Alex Williamson wrote:
On Wed, 2014-06-18 at 21:36
On Thu, 2014-06-19 at 21:21 -0600, Alex Williamson wrote:
Working on big endian being an accident may be a matter of perspective
:-)
The comment remains that this patch doesn't actually fix anything except
the overhead on big endian systems doing redundant byte swapping and
maybe the
On Sat, 2014-06-21 at 00:14 +1000, Alexey Kardashevskiy wrote:
We can still use __raw_writelco, would that be ok?
No unless you understand precisely what kind of memory barriers each
platform require for these.
Cheers,
Ben.
--
To unsubscribe from this list: send the line unsubscribe kvm in
@vger.kernel.org; Nikunj A Dadhania; linux-ker...@vger.kernel.org;
Alexander Graf; linuxppc-...@lists.ozlabs.org
Subject: Re: [PATCH] vfio: Fix endianness handling for emulated BARs
On 06/19/2014 11:50 AM, Alexey Kardashevskiy wrote:
On 06/19/2014 10:50 AM, Alexey Kardashevskiy wrote:
On 06/19/2014
On Thu, 2014-06-19 at 13:48 +1000, Alexey Kardashevskiy wrote:
On 06/19/2014 11:50 AM, Alexey Kardashevskiy wrote:
On 06/19/2014 10:50 AM, Alexey Kardashevskiy wrote:
On 06/19/2014 04:35 AM, Alex Williamson wrote:
On Wed, 2014-06-18 at 21:36 +1000, Alexey Kardashevskiy wrote:
VFIO exposes
VFIO exposes BARs to user space as a byte stream so userspace can
read it using pread()/pwrite(). Since this is a byte stream, VFIO should
not do byte swapping and simply return values as it gets them from
PCI device.
Instead, the existing code assumes that byte stream in read/write is
On Wed, 2014-06-18 at 21:36 +1000, Alexey Kardashevskiy wrote:
VFIO exposes BARs to user space as a byte stream so userspace can
read it using pread()/pwrite(). Since this is a byte stream, VFIO should
not do byte swapping and simply return values as it gets them from
PCI device.
Instead,
On 06/19/2014 04:35 AM, Alex Williamson wrote:
On Wed, 2014-06-18 at 21:36 +1000, Alexey Kardashevskiy wrote:
VFIO exposes BARs to user space as a byte stream so userspace can
read it using pread()/pwrite(). Since this is a byte stream, VFIO should
not do byte swapping and simply return values
On 06/19/2014 10:50 AM, Alexey Kardashevskiy wrote:
On 06/19/2014 04:35 AM, Alex Williamson wrote:
On Wed, 2014-06-18 at 21:36 +1000, Alexey Kardashevskiy wrote:
VFIO exposes BARs to user space as a byte stream so userspace can
read it using pread()/pwrite(). Since this is a byte stream, VFIO
On 06/19/2014 10:50 AM, Alexey Kardashevskiy wrote:
On 06/19/2014 04:35 AM, Alex Williamson wrote:
On Wed, 2014-06-18 at 21:36 +1000, Alexey Kardashevskiy wrote:
VFIO exposes BARs to user space as a byte stream so userspace can
read it using pread()/pwrite(). Since this is a byte stream, VFIO
On 06/19/2014 11:50 AM, Alexey Kardashevskiy wrote:
On 06/19/2014 10:50 AM, Alexey Kardashevskiy wrote:
On 06/19/2014 04:35 AM, Alex Williamson wrote:
On Wed, 2014-06-18 at 21:36 +1000, Alexey Kardashevskiy wrote:
VFIO exposes BARs to user space as a byte stream so userspace can
read it using
;
Alexander Graf; linuxppc-...@lists.ozlabs.org
Subject: Re: [PATCH] vfio: Fix endianness handling for emulated BARs
On 06/19/2014 11:50 AM, Alexey Kardashevskiy wrote:
On 06/19/2014 10:50 AM, Alexey Kardashevskiy wrote:
On 06/19/2014 04:35 AM, Alex Williamson wrote:
On Wed, 2014-06-18
26 matches
Mail list logo
