From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id B16961A000D for ; Sat, 21 Jun 2014 09:12:54 +1000 (EST) Message-ID: <1403305961.4587.66.camel@pasglop> Subject: Re: [PATCH] vfio: Fix endianness handling for emulated BARs From: Benjamin Herrenschmidt To: Alex Williamson Date: Sat, 21 Jun 2014 09:12:41 +1000 In-Reply-To: <1403234514.3707.278.camel@ul30vt.home> References: <1403091391-31780-1-git-send-email-aik@ozlabs.ru> <1403116512.3707.175.camel@ul30vt.home> <53A233E9.6030006@ozlabs.ru> <53A241F6.9010307@ozlabs.ru> <53A25D74.5000804@ozlabs.ru> <1403234514.3707.278.camel@ul30vt.home> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Cc: kvm@vger.kernel.org, Nikunj A Dadhania , Alexey Kardashevskiy , linux-kernel@vger.kernel.org, Alexander Graf , linuxppc-dev@lists.ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 philosophy that vfio regions are little endian. Yes, that works by accident because technically VFIO is a transport and thus shouldn't perform any endian swapping of any sort, which remains the responsibility of the end driver which is the only one to know whether a given BAR location is a a register or some streaming data and in the former case whether it's LE or BE (some PCI devices are BE even ! :-) But yes, in the end, it works with the dual "cancelling" swaps and the overhead of those swaps is probably drowned in the noise of the syscall overhead. > I'm still not a fan of iowrite vs iowritebe, there must be something we > can use that doesn't have an implicit swap. Sadly there isn't ... In the old day we didn't even have the "be" variant and readl/writel style accessors still don't have them either for all archs. There is __raw_readl/writel but here the semantics are much more than just "don't swap", they also don't have memory barriers (which means they are essentially useless to most drivers unless those are platform specific drivers which know exactly what they are doing, or in the rare cases such as accessing a framebuffer which we know never have side effects). > Calling it iowrite*_native is also an abuse of the namespace. > Next thing we know some common code > will legitimately use that name. I might make sense to those definitions into a common header. There have been a handful of cases in the past that wanted that sort of "native byte order" MMIOs iirc (though don't ask me for examples, I can't really remember). > If we do need to define an alias > (which I'd like to avoid) it should be something like vfio_iowrite32. > Thanks, Cheers, Ben. > Alex > > > > === > > > > > > any better? > > > > > > > > > > > > > > >>>> Suggested-by: Benjamin Herrenschmidt > > >>>> Signed-off-by: Alexey Kardashevskiy > > >>>> --- > > >>>> drivers/vfio/pci/vfio_pci_rdwr.c | 20 ++++++++++++++++---- > > >>>> 1 file changed, 16 insertions(+), 4 deletions(-) > > >>>> > > >>>> diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c > > >>>> index 210db24..f363b5a 100644 > > >>>> --- a/drivers/vfio/pci/vfio_pci_rdwr.c > > >>>> +++ b/drivers/vfio/pci/vfio_pci_rdwr.c > > >>>> @@ -21,6 +21,18 @@ > > >>>> > > >>>> #include "vfio_pci_private.h" > > >>>> > > >>>> +#ifdef __BIG_ENDIAN__ > > >>>> +#define ioread16_native ioread16be > > >>>> +#define ioread32_native ioread32be > > >>>> +#define iowrite16_native iowrite16be > > >>>> +#define iowrite32_native iowrite32be > > >>>> +#else > > >>>> +#define ioread16_native ioread16 > > >>>> +#define ioread32_native ioread32 > > >>>> +#define iowrite16_native iowrite16 > > >>>> +#define iowrite32_native iowrite32 > > >>>> +#endif > > >>>> + > > >>>> /* > > >>>> * Read or write from an __iomem region (MMIO or I/O port) with an excluded > > >>>> * range which is inaccessible. The excluded range drops writes and fills > > >>>> @@ -50,9 +62,9 @@ static ssize_t do_io_rw(void __iomem *io, char __user *buf, > > >>>> if (copy_from_user(&val, buf, 4)) > > >>>> return -EFAULT; > > >>>> > > >>>> - iowrite32(le32_to_cpu(val), io + off); > > >>>> + iowrite32_native(val, io + off); > > >>>> } else { > > >>>> - val = cpu_to_le32(ioread32(io + off)); > > >>>> + val = ioread32_native(io + off); > > >>>> > > >>>> if (copy_to_user(buf, &val, 4)) > > >>>> return -EFAULT; > > >>>> @@ -66,9 +78,9 @@ static ssize_t do_io_rw(void __iomem *io, char __user *buf, > > >>>> if (copy_from_user(&val, buf, 2)) > > >>>> return -EFAULT; > > >>>> > > >>>> - iowrite16(le16_to_cpu(val), io + off); > > >>>> + iowrite16_native(val, io + off); > > >>>> } else { > > >>>> - val = cpu_to_le16(ioread16(io + off)); > > >>>> + val = ioread16_native(io + off); > > >>>> > > >>>> if (copy_to_user(buf, &val, 2)) > > >>>> return -EFAULT; > > >>> > > >>> > > >>> > > >> > > >> > > > > > > > > > > > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [PATCH] vfio: Fix endianness handling for emulated BARs Date: Sat, 21 Jun 2014 09:12:41 +1000 Message-ID: <1403305961.4587.66.camel@pasglop> References: <1403091391-31780-1-git-send-email-aik@ozlabs.ru> <1403116512.3707.175.camel@ul30vt.home> <53A233E9.6030006@ozlabs.ru> <53A241F6.9010307@ozlabs.ru> <53A25D74.5000804@ozlabs.ru> <1403234514.3707.278.camel@ul30vt.home> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: kvm@vger.kernel.org, Nikunj A Dadhania , Alexey Kardashevskiy , linux-kernel@vger.kernel.org, Alexander Graf , linuxppc-dev@lists.ozlabs.org To: Alex Williamson Return-path: In-Reply-To: <1403234514.3707.278.camel@ul30vt.home> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" List-Id: kvm.vger.kernel.org T24gVGh1LCAyMDE0LTA2LTE5IGF0IDIxOjIxIC0wNjAwLCBBbGV4IFdpbGxpYW1zb24gd3JvdGU6 Cgo+IFdvcmtpbmcgb24gYmlnIGVuZGlhbiBiZWluZyBhbiBhY2NpZGVudCBtYXkgYmUgYSBtYXR0 ZXIgb2YgcGVyc3BlY3RpdmUKCiA6LSkKCj4gVGhlIGNvbW1lbnQgcmVtYWlucyB0aGF0IHRoaXMg cGF0Y2ggZG9lc24ndCBhY3R1YWxseSBmaXggYW55dGhpbmcgZXhjZXB0Cj4gdGhlIG92ZXJoZWFk IG9uIGJpZyBlbmRpYW4gc3lzdGVtcyBkb2luZyByZWR1bmRhbnQgYnl0ZSBzd2FwcGluZyBhbmQK PiBtYXliZSB0aGUgcGhpbG9zb3BoeSB0aGF0IHZmaW8gcmVnaW9ucyBhcmUgbGl0dGxlIGVuZGlh bi4KClllcywgdGhhdCB3b3JrcyBieSBhY2NpZGVudCBiZWNhdXNlIHRlY2huaWNhbGx5IFZGSU8g aXMgYSB0cmFuc3BvcnQgYW5kCnRodXMgc2hvdWxkbid0IHBlcmZvcm0gYW55IGVuZGlhbiBzd2Fw cGluZyBvZiBhbnkgc29ydCwgd2hpY2ggcmVtYWlucwp0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhl IGVuZCBkcml2ZXIgd2hpY2ggaXMgdGhlIG9ubHkgb25lIHRvIGtub3cKd2hldGhlciBhIGdpdmVu IEJBUiBsb2NhdGlvbiBpcyBhIGEgcmVnaXN0ZXIgb3Igc29tZSBzdHJlYW1pbmcgZGF0YQphbmQg aW4gdGhlIGZvcm1lciBjYXNlIHdoZXRoZXIgaXQncyBMRSBvciBCRSAoc29tZSBQQ0kgZGV2aWNl cyBhcmUgQkUKZXZlbiAhIDotKQoKQnV0IHllcywgaW4gdGhlIGVuZCwgaXQgd29ya3Mgd2l0aCB0 aGUgZHVhbCAiY2FuY2VsbGluZyIgc3dhcHMgYW5kIHRoZQpvdmVyaGVhZCBvZiB0aG9zZSBzd2Fw cyBpcyBwcm9iYWJseSBkcm93bmVkIGluIHRoZSBub2lzZSBvZiB0aGUgc3lzY2FsbApvdmVyaGVh ZC4KCj4gSSdtIHN0aWxsIG5vdCBhIGZhbiBvZiBpb3dyaXRlIHZzIGlvd3JpdGViZSwgdGhlcmUg bXVzdCBiZSBzb21ldGhpbmcgd2UKPiBjYW4gdXNlIHRoYXQgZG9lc24ndCBoYXZlIGFuIGltcGxp Y2l0IHN3YXAuCgpTYWRseSB0aGVyZSBpc24ndCAuLi4gSW4gdGhlIG9sZCBkYXkgd2UgZGlkbid0 IGV2ZW4gaGF2ZSB0aGUgImJlIgp2YXJpYW50IGFuZCByZWFkbC93cml0ZWwgc3R5bGUgYWNjZXNz b3JzIHN0aWxsIGRvbid0IGhhdmUgdGhlbSBlaXRoZXIKZm9yIGFsbCBhcmNocy4KClRoZXJlIGlz IF9fcmF3X3JlYWRsL3dyaXRlbCBidXQgaGVyZSB0aGUgc2VtYW50aWNzIGFyZSBtdWNoIG1vcmUg dGhhbgpqdXN0ICJkb24ndCBzd2FwIiwgdGhleSBhbHNvIGRvbid0IGhhdmUgbWVtb3J5IGJhcnJp ZXJzICh3aGljaCBtZWFucwp0aGV5IGFyZSBlc3NlbnRpYWxseSB1c2VsZXNzIHRvIG1vc3QgZHJp dmVycyB1bmxlc3MgdGhvc2UgYXJlIHBsYXRmb3JtCnNwZWNpZmljIGRyaXZlcnMgd2hpY2gga25v dyBleGFjdGx5IHdoYXQgdGhleSBhcmUgZG9pbmcsIG9yIGluIHRoZSByYXJlCmNhc2VzIHN1Y2gg YXMgYWNjZXNzaW5nIGEgZnJhbWVidWZmZXIgd2hpY2ggd2Uga25vdyBuZXZlciBoYXZlIHNpZGUK ZWZmZWN0cykuIAoKPiAgQ2FsbGluZyBpdCBpb3dyaXRlKl9uYXRpdmUgaXMgYWxzbyBhbiBhYnVz ZSBvZiB0aGUgbmFtZXNwYWNlLgoKCj4gIE5leHQgdGhpbmcgd2Uga25vdyBzb21lIGNvbW1vbiBj b2RlCj4gd2lsbCBsZWdpdGltYXRlbHkgdXNlIHRoYXQgbmFtZS4gCgpJIG1pZ2h0IG1ha2Ugc2Vu c2UgdG8gdGhvc2UgZGVmaW5pdGlvbnMgaW50byBhIGNvbW1vbiBoZWFkZXIuIFRoZXJlIGhhdmUK YmVlbiBhIGhhbmRmdWwgb2YgY2FzZXMgaW4gdGhlIHBhc3QgdGhhdCB3YW50ZWQgdGhhdCBzb3J0 IG9mICJuYXRpdmUKYnl0ZSBvcmRlciIgTU1JT3MgaWlyYyAodGhvdWdoIGRvbid0IGFzayBtZSBm b3IgZXhhbXBsZXMsIEkgY2FuJ3QgcmVhbGx5CnJlbWVtYmVyKS4KCj4gIElmIHdlIGRvIG5lZWQg dG8gZGVmaW5lIGFuIGFsaWFzCj4gKHdoaWNoIEknZCBsaWtlIHRvIGF2b2lkKSBpdCBzaG91bGQg YmUgc29tZXRoaW5nIGxpa2UgdmZpb19pb3dyaXRlMzIuCj4gVGhhbmtzLAoKQ2hlZXJzLApCZW4u Cgo+IEFsZXgKPiAKPiA+ID4gPT09Cj4gPiA+IAo+ID4gPiBhbnkgYmV0dGVyPwo+ID4gPiAKPiA+ ID4gCj4gPiA+IAo+ID4gPiAKPiA+ID4+Pj4gU3VnZ2VzdGVkLWJ5OiBCZW5qYW1pbiBIZXJyZW5z Y2htaWR0IDxiZW5oQGtlcm5lbC5jcmFzaGluZy5vcmc+Cj4gPiA+Pj4+IFNpZ25lZC1vZmYtYnk6 IEFsZXhleSBLYXJkYXNoZXZza2l5IDxhaWtAb3psYWJzLnJ1Pgo+ID4gPj4+PiAtLS0KPiA+ID4+ Pj4gIGRyaXZlcnMvdmZpby9wY2kvdmZpb19wY2lfcmR3ci5jIHwgMjAgKysrKysrKysrKysrKysr Ky0tLS0KPiA+ID4+Pj4gIDEgZmlsZSBjaGFuZ2VkLCAxNiBpbnNlcnRpb25zKCspLCA0IGRlbGV0 aW9ucygtKQo+ID4gPj4+Pgo+ID4gPj4+PiBkaWZmIC0tZ2l0IGEvZHJpdmVycy92ZmlvL3BjaS92 ZmlvX3BjaV9yZHdyLmMgYi9kcml2ZXJzL3ZmaW8vcGNpL3ZmaW9fcGNpX3Jkd3IuYwo+ID4gPj4+ PiBpbmRleCAyMTBkYjI0Li5mMzYzYjVhIDEwMDY0NAo+ID4gPj4+PiAtLS0gYS9kcml2ZXJzL3Zm aW8vcGNpL3ZmaW9fcGNpX3Jkd3IuYwo+ID4gPj4+PiArKysgYi9kcml2ZXJzL3ZmaW8vcGNpL3Zm aW9fcGNpX3Jkd3IuYwo+ID4gPj4+PiBAQCAtMjEsNiArMjEsMTggQEAKPiA+ID4+Pj4gIAo+ID4g Pj4+PiAgI2luY2x1ZGUgInZmaW9fcGNpX3ByaXZhdGUuaCIKPiA+ID4+Pj4gIAo+ID4gPj4+PiAr I2lmZGVmIF9fQklHX0VORElBTl9fCj4gPiA+Pj4+ICsjZGVmaW5lIGlvcmVhZDE2X25hdGl2ZQkJ aW9yZWFkMTZiZQo+ID4gPj4+PiArI2RlZmluZSBpb3JlYWQzMl9uYXRpdmUJCWlvcmVhZDMyYmUK PiA+ID4+Pj4gKyNkZWZpbmUgaW93cml0ZTE2X25hdGl2ZQlpb3dyaXRlMTZiZQo+ID4gPj4+PiAr I2RlZmluZSBpb3dyaXRlMzJfbmF0aXZlCWlvd3JpdGUzMmJlCj4gPiA+Pj4+ICsjZWxzZQo+ID4g Pj4+PiArI2RlZmluZSBpb3JlYWQxNl9uYXRpdmUJCWlvcmVhZDE2Cj4gPiA+Pj4+ICsjZGVmaW5l IGlvcmVhZDMyX25hdGl2ZQkJaW9yZWFkMzIKPiA+ID4+Pj4gKyNkZWZpbmUgaW93cml0ZTE2X25h dGl2ZQlpb3dyaXRlMTYKPiA+ID4+Pj4gKyNkZWZpbmUgaW93cml0ZTMyX25hdGl2ZQlpb3dyaXRl MzIKPiA+ID4+Pj4gKyNlbmRpZgo+ID4gPj4+PiArCj4gPiA+Pj4+ICAvKgo+ID4gPj4+PiAgICog UmVhZCBvciB3cml0ZSBmcm9tIGFuIF9faW9tZW0gcmVnaW9uIChNTUlPIG9yIEkvTyBwb3J0KSB3 aXRoIGFuIGV4Y2x1ZGVkCj4gPiA+Pj4+ICAgKiByYW5nZSB3aGljaCBpcyBpbmFjY2Vzc2libGUu ICBUaGUgZXhjbHVkZWQgcmFuZ2UgZHJvcHMgd3JpdGVzIGFuZCBmaWxscwo+ID4gPj4+PiBAQCAt NTAsOSArNjIsOSBAQCBzdGF0aWMgc3NpemVfdCBkb19pb19ydyh2b2lkIF9faW9tZW0gKmlvLCBj aGFyIF9fdXNlciAqYnVmLAo+ID4gPj4+PiAgCQkJCWlmIChjb3B5X2Zyb21fdXNlcigmdmFsLCBi dWYsIDQpKQo+ID4gPj4+PiAgCQkJCQlyZXR1cm4gLUVGQVVMVDsKPiA+ID4+Pj4gIAo+ID4gPj4+ PiAtCQkJCWlvd3JpdGUzMihsZTMyX3RvX2NwdSh2YWwpLCBpbyArIG9mZik7Cj4gPiA+Pj4+ICsJ CQkJaW93cml0ZTMyX25hdGl2ZSh2YWwsIGlvICsgb2ZmKTsKPiA+ID4+Pj4gIAkJCX0gZWxzZSB7 Cj4gPiA+Pj4+IC0JCQkJdmFsID0gY3B1X3RvX2xlMzIoaW9yZWFkMzIoaW8gKyBvZmYpKTsKPiA+ ID4+Pj4gKwkJCQl2YWwgPSBpb3JlYWQzMl9uYXRpdmUoaW8gKyBvZmYpOwo+ID4gPj4+PiAgCj4g PiA+Pj4+ICAJCQkJaWYgKGNvcHlfdG9fdXNlcihidWYsICZ2YWwsIDQpKQo+ID4gPj4+PiAgCQkJ CQlyZXR1cm4gLUVGQVVMVDsKPiA+ID4+Pj4gQEAgLTY2LDkgKzc4LDkgQEAgc3RhdGljIHNzaXpl X3QgZG9faW9fcncodm9pZCBfX2lvbWVtICppbywgY2hhciBfX3VzZXIgKmJ1ZiwKPiA+ID4+Pj4g IAkJCQlpZiAoY29weV9mcm9tX3VzZXIoJnZhbCwgYnVmLCAyKSkKPiA+ID4+Pj4gIAkJCQkJcmV0 dXJuIC1FRkFVTFQ7Cj4gPiA+Pj4+ICAKPiA+ID4+Pj4gLQkJCQlpb3dyaXRlMTYobGUxNl90b19j cHUodmFsKSwgaW8gKyBvZmYpOwo+ID4gPj4+PiArCQkJCWlvd3JpdGUxNl9uYXRpdmUodmFsLCBp byArIG9mZik7Cj4gPiA+Pj4+ICAJCQl9IGVsc2Ugewo+ID4gPj4+PiAtCQkJCXZhbCA9IGNwdV90 b19sZTE2KGlvcmVhZDE2KGlvICsgb2ZmKSk7Cj4gPiA+Pj4+ICsJCQkJdmFsID0gaW9yZWFkMTZf bmF0aXZlKGlvICsgb2ZmKTsKPiA+ID4+Pj4gIAo+ID4gPj4+PiAgCQkJCWlmIChjb3B5X3RvX3Vz ZXIoYnVmLCAmdmFsLCAyKSkKPiA+ID4+Pj4gIAkJCQkJcmV0dXJuIC1FRkFVTFQ7Cj4gPiA+Pj4K PiA+ID4+Pgo+ID4gPj4+Cj4gPiA+Pgo+ID4gPj4KPiA+ID4gCj4gPiA+IAo+ID4gCj4gPiAKPiAK PiAKPiAKPiAtLQo+IFRvIHVuc3Vic2NyaWJlIGZyb20gdGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5l ICJ1bnN1YnNjcmliZSBsaW51eC1rZXJuZWwiIGluCj4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRv IG1ham9yZG9tb0B2Z2VyLmtlcm5lbC5vcmcKPiBNb3JlIG1ham9yZG9tbyBpbmZvIGF0ICBodHRw Oi8vdmdlci5rZXJuZWwub3JnL21ham9yZG9tby1pbmZvLmh0bWwKPiBQbGVhc2UgcmVhZCB0aGUg RkFRIGF0ICBodHRwOi8vd3d3LnR1eC5vcmcvbGttbC8KCgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpMaW51eHBwYy1kZXYgbWFpbGluZyBsaXN0CkxpbnV4 cHBjLWRldkBsaXN0cy5vemxhYnMub3JnCmh0dHBzOi8vbGlzdHMub3psYWJzLm9yZy9saXN0aW5m by9saW51eHBwYy1kZXY= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964946AbaFTXNR (ORCPT ); Fri, 20 Jun 2014 19:13:17 -0400 Received: from gate.crashing.org ([63.228.1.57]:59762 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752850AbaFTXNQ (ORCPT ); Fri, 20 Jun 2014 19:13:16 -0400 Message-ID: <1403305961.4587.66.camel@pasglop> Subject: Re: [PATCH] vfio: Fix endianness handling for emulated BARs From: Benjamin Herrenschmidt To: Alex Williamson Cc: Alexey Kardashevskiy , linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Alexander Graf , Nikunj A Dadhania Date: Sat, 21 Jun 2014 09:12:41 +1000 In-Reply-To: <1403234514.3707.278.camel@ul30vt.home> References: <1403091391-31780-1-git-send-email-aik@ozlabs.ru> <1403116512.3707.175.camel@ul30vt.home> <53A233E9.6030006@ozlabs.ru> <53A241F6.9010307@ozlabs.ru> <53A25D74.5000804@ozlabs.ru> <1403234514.3707.278.camel@ul30vt.home> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 philosophy that vfio regions are little endian. Yes, that works by accident because technically VFIO is a transport and thus shouldn't perform any endian swapping of any sort, which remains the responsibility of the end driver which is the only one to know whether a given BAR location is a a register or some streaming data and in the former case whether it's LE or BE (some PCI devices are BE even ! :-) But yes, in the end, it works with the dual "cancelling" swaps and the overhead of those swaps is probably drowned in the noise of the syscall overhead. > I'm still not a fan of iowrite vs iowritebe, there must be something we > can use that doesn't have an implicit swap. Sadly there isn't ... In the old day we didn't even have the "be" variant and readl/writel style accessors still don't have them either for all archs. There is __raw_readl/writel but here the semantics are much more than just "don't swap", they also don't have memory barriers (which means they are essentially useless to most drivers unless those are platform specific drivers which know exactly what they are doing, or in the rare cases such as accessing a framebuffer which we know never have side effects). > Calling it iowrite*_native is also an abuse of the namespace. > Next thing we know some common code > will legitimately use that name. I might make sense to those definitions into a common header. There have been a handful of cases in the past that wanted that sort of "native byte order" MMIOs iirc (though don't ask me for examples, I can't really remember). > If we do need to define an alias > (which I'd like to avoid) it should be something like vfio_iowrite32. > Thanks, Cheers, Ben. > Alex > > > > === > > > > > > any better? > > > > > > > > > > > > > > >>>> Suggested-by: Benjamin Herrenschmidt > > >>>> Signed-off-by: Alexey Kardashevskiy > > >>>> --- > > >>>> drivers/vfio/pci/vfio_pci_rdwr.c | 20 ++++++++++++++++---- > > >>>> 1 file changed, 16 insertions(+), 4 deletions(-) > > >>>> > > >>>> diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c > > >>>> index 210db24..f363b5a 100644 > > >>>> --- a/drivers/vfio/pci/vfio_pci_rdwr.c > > >>>> +++ b/drivers/vfio/pci/vfio_pci_rdwr.c > > >>>> @@ -21,6 +21,18 @@ > > >>>> > > >>>> #include "vfio_pci_private.h" > > >>>> > > >>>> +#ifdef __BIG_ENDIAN__ > > >>>> +#define ioread16_native ioread16be > > >>>> +#define ioread32_native ioread32be > > >>>> +#define iowrite16_native iowrite16be > > >>>> +#define iowrite32_native iowrite32be > > >>>> +#else > > >>>> +#define ioread16_native ioread16 > > >>>> +#define ioread32_native ioread32 > > >>>> +#define iowrite16_native iowrite16 > > >>>> +#define iowrite32_native iowrite32 > > >>>> +#endif > > >>>> + > > >>>> /* > > >>>> * Read or write from an __iomem region (MMIO or I/O port) with an excluded > > >>>> * range which is inaccessible. The excluded range drops writes and fills > > >>>> @@ -50,9 +62,9 @@ static ssize_t do_io_rw(void __iomem *io, char __user *buf, > > >>>> if (copy_from_user(&val, buf, 4)) > > >>>> return -EFAULT; > > >>>> > > >>>> - iowrite32(le32_to_cpu(val), io + off); > > >>>> + iowrite32_native(val, io + off); > > >>>> } else { > > >>>> - val = cpu_to_le32(ioread32(io + off)); > > >>>> + val = ioread32_native(io + off); > > >>>> > > >>>> if (copy_to_user(buf, &val, 4)) > > >>>> return -EFAULT; > > >>>> @@ -66,9 +78,9 @@ static ssize_t do_io_rw(void __iomem *io, char __user *buf, > > >>>> if (copy_from_user(&val, buf, 2)) > > >>>> return -EFAULT; > > >>>> > > >>>> - iowrite16(le16_to_cpu(val), io + off); > > >>>> + iowrite16_native(val, io + off); > > >>>> } else { > > >>>> - val = cpu_to_le16(ioread16(io + off)); > > >>>> + val = ioread16_native(io + off); > > >>>> > > >>>> if (copy_to_user(buf, &val, 2)) > > >>>> return -EFAULT; > > >>> > > >>> > > >>> > > >> > > >> > > > > > > > > > > > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/