From nobody Tue Feb 10 04:15:49 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 216.205.24.124 as permitted sender) client-ip=216.205.24.124; envelope-from=philmd@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 216.205.24.124 as permitted sender) smtp.mailfrom=philmd@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1621363092; cv=none; d=zohomail.com; s=zohoarc; b=fzTjsEEwKOVBi3fVemeKWVxODD7GRvd9T+Bt4zhSESdPOhCrqYFUQD93XFCjUDr0PSgWR8RfCMPtXwQG95eFsrslCJLqCYDCu4q+9UMU7Fr6DoB6Imo3gVVd90hpNFBvDh1CGAG5W6N3ZTdFEPCh8B8t8mOjpAFhgS6Q2mLmY4w= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1621363092; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=mh+awpUaZ2yWuu439ZFMUaH3zSpAqoD7H3lWBxX++40=; b=XXlV3z2a1Ju0MoPfvNW9RGGmnyeJEeJdVgMjDj/qLXZwUcCxdFgHLAE+0wqS1m65rJywldJX6vhWcM4WGSsxtofyX/PEudJLzLd8q1fXpniCMUPezWSjhRzcMyoRH9Dpis6XcuNQWSiLDB5j31KC/agkjZr/fgJ6Kt3pNm+h358= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 216.205.24.124 as permitted sender) smtp.mailfrom=philmd@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.zohomail.com with SMTPS id 1621363092270932.0503322997939; Tue, 18 May 2021 11:38:12 -0700 (PDT) Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-541-l1qDSwNeOGWoGbbY33HMiA-1; Tue, 18 May 2021 14:38:09 -0400 Received: by mail-ed1-f71.google.com with SMTP id h16-20020a0564020950b029038cbdae8cbaso6237140edz.6 for ; Tue, 18 May 2021 11:38:09 -0700 (PDT) Return-Path: Return-Path: Received: from x1w.redhat.com (31.red-83-51-215.dynamicip.rima-tde.net. [83.51.215.31]) by smtp.gmail.com with ESMTPSA id b25sm13715551edv.9.2021.05.18.11.38.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 May 2021 11:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621363091; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mh+awpUaZ2yWuu439ZFMUaH3zSpAqoD7H3lWBxX++40=; b=MUwnUmzd08Hdw3c8mjtifwCWuH7l+c5BEHpKrUHXUH1V1gvmTUKcG4+BtO3P4UpW0g7IRq 0JPgDZv7FbyYmlJCXmu+shMFI63bdrHEWG2mgNmiqHLCF2BoNwvF4X3JHwcIVOEpzrS8qy 3af5EJLbN2QKb6jgyJUApWHKW0CI0+0= X-MC-Unique: l1qDSwNeOGWoGbbY33HMiA-1 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=mh+awpUaZ2yWuu439ZFMUaH3zSpAqoD7H3lWBxX++40=; b=Fu+RhcZk06kpz2s2Kb0DRaoFvpykI7FtNxXGn1tJcKg/AaxE/l0jCttnqACKOLAI7R /lwg52BIcUGgu88nz8hM4akRA87AaZYdz8o+/Qulg8SvSjNRWysdmGWHzSFXxEZExLnA B5bNp3CmxyIIehF4AWJjVMwoYqPYApfsn4YfnUac7tQu4zKeqFqp5i028KvHQZgKeE95 bjRr6LEUznTZHjW0Shxe1Js9KXB76rFq9DyYYuAmEUpll/ACFh8WpxmtTXiPm4Ni+ne9 OTDyylkv5fO5zaNrL+4u+MavLR79ZwUyqvzJgy1zeXuMT/UytnX3W1LFuEI3FvsuCjz3 MneA== X-Gm-Message-State: AOAM5312A1Us1CWRsxh/nzsAS/9o26VokF0gIlL3jGeendIYjUaC1MFb iWD45F9EnK+rVYL80F++ryNUZuhztNiGPChbT31SvUPobdo7NkxQ3YnC/yx10uyVQ9z1i9AvIoK PvamNXpL7wob/Jg== X-Received: by 2002:a17:906:fa83:: with SMTP id lt3mr7308762ejb.261.1621363088400; Tue, 18 May 2021 11:38:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw1oWMszBWk7GQeRY5gkpfYvVRDrwExWaLKmjYbxQFKdsK8Fq2bTy5KlkIUeUKN/gBvPKxqTw== X-Received: by 2002:a17:906:fa83:: with SMTP id lt3mr7308737ejb.261.1621363088172; Tue, 18 May 2021 11:38:08 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: Bibo Mao , "Michael S. Tsirkin" , Richard Henderson , Paolo Bonzini , Jiaxun Yang , Peter Xu , Huacai Chen , Peter Maydell , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Stefan Hajnoczi Subject: [RFC PATCH 14/25] qemu/bswap: Introduce load/store for aligned pointer Date: Tue, 18 May 2021 20:36:44 +0200 Message-Id: <20210518183655.1711377-15-philmd@redhat.com> X-Mailer: git-send-email 2.26.3 In-Reply-To: <20210518183655.1711377-1-philmd@redhat.com> References: <20210518183655.1711377-1-philmd@redhat.com> MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=philmd@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) When the pointer alignment is known to be safe, we can directly swap the data in place, without having to rely on the compiler builtin code. Load/store methods expecting aligned pointer use the 'a' infix. For example to read a 16-bit unsigned value stored in little endianess at an unaligned pointer: val =3D lduw_le_p(&unaligned_ptr); then to store it in big endianess at an aligned pointer: stw_be_ap(&aligned_ptr, val); Suggested-by: Stefan Hajnoczi Signed-off-by: Philippe Mathieu-Daud=C3=A9 --- docs/devel/loads-stores.rst | 27 ++++++++++++++++----------- include/qemu/bswap.h | 22 ++++++++++++++++++++++ 2 files changed, 38 insertions(+), 11 deletions(-) diff --git a/docs/devel/loads-stores.rst b/docs/devel/loads-stores.rst index 568274baec0..88493ba1293 100644 --- a/docs/devel/loads-stores.rst +++ b/docs/devel/loads-stores.rst @@ -13,20 +13,21 @@ documentation of each API -- for that you should look a= t the documentation comments in the relevant header files. =20 =20 -``ld*_p and st*_p`` -~~~~~~~~~~~~~~~~~~~ +``ld*_[a]p and st*_[a]p`` +~~~~~~~~~~~~~~~~~~~~~~~~~ =20 These functions operate on a host pointer, and should be used when you already have a pointer into host memory (corresponding to guest ram or a local buffer). They deal with doing accesses with the desired endianness and with correctly handling -potentially unaligned pointer values. +potentially unaligned pointer values. If the pointer alignment +is known to be safe, then the aligned functions can be used. =20 Function names follow the pattern: =20 -load: ``ld{sign}{size}_{endian}_p(ptr)`` +load: ``ld{sign}{size}_{endian}_{aligned}p(ptr)`` =20 -store: ``st{size}_{endian}_p(ptr, val)`` +store: ``st{size}_{endian}_{aligned}p(ptr, val)`` =20 ``sign`` - (empty) : for 32 or 64 bit sizes @@ -49,24 +50,28 @@ The ``_{endian}`` infix is omitted for target-endian ac= cesses. The target endian accessors are only available to source files which are built per-target. =20 +By using the ``_{aligned}`` infix, unsafe optimizations might be used, +however unaligned pointer might trigger an exception and abort the +process. + There are also functions which take the size as an argument: =20 -load: ``ldn{endian}_p(ptr, sz)`` +load: ``ldn{endian}_{aligned}p(ptr, sz)`` =20 which performs an unsigned load of ``sz`` bytes from ``ptr`` as an ``{endian}`` order value and returns it in a uint64_t. =20 -store: ``stn{endian}_p(ptr, sz, val)`` +store: ``stn{endian}_{aligned}p(ptr, sz, val)`` =20 which stores ``val`` to ``ptr`` as an ``{endian}`` order value of size ``sz`` bytes. =20 =20 Regexes for git grep - - ``\`` - - ``\`` - - ``\`` - - ``\`` + - ``\`` + - ``\`` + - ``\`` + - ``\`` =20 ``cpu_{ld,st}*_mmuidx_ra`` ~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/include/qemu/bswap.h b/include/qemu/bswap.h index 4cd120ca014..3f272c3cb46 100644 --- a/include/qemu/bswap.h +++ b/include/qemu/bswap.h @@ -350,25 +350,47 @@ static inline void st ## size ## _he_p(void *ptr, vty= pe v)\ __builtin_memcpy(ptr, &v, sizeof(v));\ } =20 +#define LD_CONVERT_ALIGNED(bits, rtype, vtype, size)\ +static inline rtype ld ## size ## _he_ap(const void *ptr)\ +{\ + return *(vtype *)ptr;\ +} + +#define ST_CONVERT_ALIGNED(bits, vtype, size)\ +static inline void st ## size ## _he_ap(void *ptr, vtype v)\ +{\ + *(vtype *)ptr =3D v;\ +} + #define LD_CONVERT_END(endian, bits, rtype, vtype, size)\ static inline rtype ld ## size ## _ ## endian ## _p(const void *ptr)\ {\ return (vtype)glue(endian, _bswap)(ld ## size ## _he_p(ptr), bits);\ +}\ +static inline rtype ld ## size ## _ ## endian ## _ap(const void *ptr)\ +{\ + return (vtype)glue(endian, _bswap)(ld ## size ## _he_ap(ptr), bits);\ } =20 #define ST_CONVERT_END(endian, bits, vtype, size)\ static inline void st ## size ## _ ## endian ## _p(void *ptr, vtype v)\ {\ st ## size ## _he_p(ptr, glue(endian, _bswap)(v, bits));\ +}\ +static inline void st ## size ## _ ## endian ## _ap(void *ptr, vtype v)\ +{\ + st ## size ## _he_ap(ptr, glue(endian, _bswap)(v, bits));\ } =20 #define LD_CONVERT(bits, rtype, vtype, size)\ LD_CONVERT_UNALIGNED(bits, rtype, vtype, size)\ + LD_CONVERT_ALIGNED(bits, rtype, vtype, size)\ LD_CONVERT_END(le, bits, rtype, vtype, size)\ LD_CONVERT_END(be, bits, rtype, vtype, size) =20 #define ST_CONVERT(bits, vtype, size)\ ST_CONVERT_UNALIGNED(bits, vtype, size)\ + ST_CONVERT_ALIGNED(bits, vtype, size)\ ST_CONVERT_END(le, bits, vtype, size)\ ST_CONVERT_END(be, bits, vtype, size) =20 --=20 2.26.3