All of lore.kernel.org
 help / color / mirror / Atom feed
From: <tony.nguyen@bt.com>
To: <qemu-devel@nongnu.org>
Cc: peter.maydell@linaro.org, walling@linux.ibm.com, mst@redhat.com,
	palmer@sifive.com, mark.cave-ayland@ilande.co.uk,
	Alistair.Francis@wdc.com, arikalo@wavecomp.com, david@redhat.com,
	pasic@linux.ibm.com, borntraeger@de.ibm.com, rth@twiddle.net,
	atar4qemu@gmail.com, ehabkost@redhat.com, sw@weilnetz.de,
	qemu-s390x@nongnu.org, qemu-arm@nongnu.org,
	david@gibson.dropbear.id.au, qemu-riscv@nongnu.org,
	cohuck@redhat.com, claudio.fontana@huawei.com,
	alex.williamson@redhat.com, qemu-ppc@nongnu.org,
	amarkovic@wavecomp.com, pbonzini@redhat.com,
	aurelien@aurel32.net
Subject: [Qemu-devel] [PATCH v2 11/20] hw/virtio: Access MemoryRegion with MemOp
Date: Mon, 22 Jul 2019 15:48:00 +0000	[thread overview]
Message-ID: <1563810480347.95681@bt.com> (raw)
In-Reply-To: <e9c6e5310b1a4863be45d45bf087fc3d@tpw09926dag18e.domain1.systemhost.net>

On 17/07/19 08:06, Paolo Bonzini wrote:

> My main concern is that MO_BE/MO_LE/MO_TE do not really apply to the
> memory.c paths.  MO_BSWAP is never passed into the MemOp, even if target
> endianness != host endianness.
>
> Therefore, you could return MO_TE | MO_{8,16,32,64} from this function,
> and change memory_region_endianness_inverted to test
> HOST_WORDS_BIGENDIAN instead of TARGET_WORDS_BIGENDIAN.  Then the two
> MO_BSWAPs (one from MO_TE, one from adjust_endianness because
> memory_region_endianness_inverted returns true) cancel out if the
> memory region's endianness is the same as the host's but different
> from the target's.
>
> Some care is needed in virtio_address_space_write and zpci_write_bar.  I
> think the latter is okay, while the former could do something like this:
>
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index ce928f2429..61885f020c 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -541,16 +541,16 @@ void virtio_address_space_write(VirtIOPCIProxy *proxy,
> hwaddr addr,
>          val = pci_get_byte(buf);
>          break;
>      case 2:
> -        val = cpu_to_le16(pci_get_word(buf));
> +        val = pci_get_word(buf);
>          break;
>      case 4:
> -        val = cpu_to_le32(pci_get_long(buf));
> +        val = pci_get_long(buf);
>          break;
>      default:
>          /* As length is under guest control, handle illegal values. */
>          return;
>      }
> -    memory_region_dispatch_write(mr, addr, val, len, MEMTXATTRS_UNSPECIFIED);
> +    memory_region_dispatch_write(mr, addr, val, size_memop(len) & ~MO_BSWAP,
> MEMTXATTRS_UNSPECIFIED);
>  }
>
>  static void

Sorry Paolo, I noted the need to take care in virtio_address_space_write and
zpci_write_bar but did not understand.

> Some care is needed in virtio_address_space_write and zpci_write_bar.
Is this advice for my v1 implementation, or in the case of the
MO_TE | MO_{8,16,32,64} idead suggested in the paragraph before?

Signed-off-by: Tony Nguyen <tony.nguyen@bt.com>
---
 hw/virtio/virtio-pci.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index ce928f2..265f066 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -17,6 +17,7 @@

 #include "qemu/osdep.h"

+#include "exec/memop.h"
 #include "standard-headers/linux/virtio_pci.h"
 #include "hw/virtio/virtio.h"
 #include "hw/pci/pci.h"
@@ -550,7 +551,8 @@ void virtio_address_space_write(VirtIOPCIProxy *proxy, hwaddr addr,
         /* As length is under guest control, handle illegal values. */
         return;
     }
-    memory_region_dispatch_write(mr, addr, val, len, MEMTXATTRS_UNSPECIFIED);
+    memory_region_dispatch_write(mr, addr, val, SIZE_MEMOP(len),
+                                 MEMTXATTRS_UNSPECIFIED);
 }

 static void
@@ -573,7 +575,8 @@ virtio_address_space_read(VirtIOPCIProxy *proxy, hwaddr addr,
     /* Make sure caller aligned buf properly */
     assert(!(((uintptr_t)buf) & (len - 1)));

-    memory_region_dispatch_read(mr, addr, &val, len, MEMTXATTRS_UNSPECIFIED);
+    memory_region_dispatch_read(mr, addr, &val, SIZE_MEMOP(len),
+                                MEMTXATTRS_UNSPECIFIED);
     switch (len) {
     case 1:
         pci_set_byte(buf, val);
--
1.8.3.1




WARNING: multiple messages have this Message-ID (diff)
From: <tony.nguyen@bt.com>
To: <qemu-devel@nongnu.org>
Cc: <peter.maydell@linaro.org>, <walling@linux.ibm.com>,
	<david@redhat.com>, <palmer@sifive.com>,
	<mark.cave-ayland@ilande.co.uk>, <Alistair.Francis@wdc.com>,
	<arikalo@wavecomp.com>, <mst@redhat.com>, <pasic@linux.ibm.com>,
	<borntraeger@de.ibm.com>, <rth@twiddle.net>,
	<atar4qemu@gmail.com>, <ehabkost@redhat.com>, <sw@weilnetz.de>,
	<alex.williamson@redhat.com>, <qemu-arm@nongnu.org>,
	<david@gibson.dropbear.id.au>, <qemu-riscv@nongnu.org>,
	<cohuck@redhat.com>, <claudio.fontana@huawei.com>,
	<qemu-s390x@nongnu.org>, <qemu-ppc@nongnu.org>,
	 <amarkovic@wavecomp.com>, <pbonzini@redhat.com>,
	<aurelien@aurel32.net>
Subject: [Qemu-riscv] [Qemu-devel] [PATCH v2 11/20] hw/virtio: Access MemoryRegion with MemOp
Date: Mon, 22 Jul 2019 15:48:00 +0000	[thread overview]
Message-ID: <1563810480347.95681@bt.com> (raw)
In-Reply-To: <e9c6e5310b1a4863be45d45bf087fc3d@tpw09926dag18e.domain1.systemhost.net>

[-- Attachment #1: Type: text/plain, Size: 3413 bytes --]

On 17/07/19 08:06, Paolo Bonzini wrote:

> My main concern is that MO_BE/MO_LE/MO_TE do not really apply to the
> memory.c paths.  MO_BSWAP is never passed into the MemOp, even if target
> endianness != host endianness.
>
> Therefore, you could return MO_TE | MO_{8,16,32,64} from this function,
> and change memory_region_endianness_inverted to test
> HOST_WORDS_BIGENDIAN instead of TARGET_WORDS_BIGENDIAN.  Then the two
> MO_BSWAPs (one from MO_TE, one from adjust_endianness because
> memory_region_endianness_inverted returns true) cancel out if the
> memory region's endianness is the same as the host's but different
> from the target's.
>
> Some care is needed in virtio_address_space_write and zpci_write_bar.  I
> think the latter is okay, while the former could do something like this:
>
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index ce928f2429..61885f020c 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -541,16 +541,16 @@ void virtio_address_space_write(VirtIOPCIProxy *proxy,
> hwaddr addr,
>          val = pci_get_byte(buf);
>          break;
>      case 2:
> -        val = cpu_to_le16(pci_get_word(buf));
> +        val = pci_get_word(buf);
>          break;
>      case 4:
> -        val = cpu_to_le32(pci_get_long(buf));
> +        val = pci_get_long(buf);
>          break;
>      default:
>          /* As length is under guest control, handle illegal values. */
>          return;
>      }
> -    memory_region_dispatch_write(mr, addr, val, len, MEMTXATTRS_UNSPECIFIED);
> +    memory_region_dispatch_write(mr, addr, val, size_memop(len) & ~MO_BSWAP,
> MEMTXATTRS_UNSPECIFIED);
>  }
>
>  static void

Sorry Paolo, I noted the need to take care in virtio_address_space_write and
zpci_write_bar but did not understand.

> Some care is needed in virtio_address_space_write and zpci_write_bar.
Is this advice for my v1 implementation, or in the case of the
MO_TE | MO_{8,16,32,64} idead suggested in the paragraph before?

Signed-off-by: Tony Nguyen <tony.nguyen@bt.com>
---
 hw/virtio/virtio-pci.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index ce928f2..265f066 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -17,6 +17,7 @@

 #include "qemu/osdep.h"

+#include "exec/memop.h"
 #include "standard-headers/linux/virtio_pci.h"
 #include "hw/virtio/virtio.h"
 #include "hw/pci/pci.h"
@@ -550,7 +551,8 @@ void virtio_address_space_write(VirtIOPCIProxy *proxy, hwaddr addr,
         /* As length is under guest control, handle illegal values. */
         return;
     }
-    memory_region_dispatch_write(mr, addr, val, len, MEMTXATTRS_UNSPECIFIED);
+    memory_region_dispatch_write(mr, addr, val, SIZE_MEMOP(len),
+                                 MEMTXATTRS_UNSPECIFIED);
 }

 static void
@@ -573,7 +575,8 @@ virtio_address_space_read(VirtIOPCIProxy *proxy, hwaddr addr,
     /* Make sure caller aligned buf properly */
     assert(!(((uintptr_t)buf) & (len - 1)));

-    memory_region_dispatch_read(mr, addr, &val, len, MEMTXATTRS_UNSPECIFIED);
+    memory_region_dispatch_read(mr, addr, &val, SIZE_MEMOP(len),
+                                MEMTXATTRS_UNSPECIFIED);
     switch (len) {
     case 1:
         pci_set_byte(buf, val);
--
1.8.3.1




[-- Attachment #2: Type: text/html, Size: 6123 bytes --]

  parent reply	other threads:[~2019-07-22 15:48 UTC|newest]

Thread overview: 120+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-22 15:34 [Qemu-devel] [PATCH v2 00/20] Invert Endian bit in SPARCv9 MMU TTE tony.nguyen
2019-07-22 15:34 ` [Qemu-riscv] " tony.nguyen
2019-07-22 15:38 ` [Qemu-devel] [PATCH v2 01/20] tcg: Replace MO_8 with MO_UB alias tony.nguyen
2019-07-22 15:38   ` [Qemu-riscv] " tony.nguyen
2019-07-23  8:04   ` [Qemu-devel] [qemu-s390x] " David Hildenbrand
2019-07-23  8:04     ` [Qemu-riscv] [qemu-s390x] [Qemu-devel] " David Hildenbrand
2019-07-22 15:39 ` [Qemu-devel] [PATCH v2 02/20] tcg: Replace MO_16 with MO_UW alias tony.nguyen
2019-07-22 15:39   ` [Qemu-riscv] " tony.nguyen
2019-07-22 15:40 ` tony.nguyen
2019-07-22 15:40   ` [Qemu-riscv] " tony.nguyen
2019-07-22 15:41 ` [Qemu-devel] [PATCH v2 03/20] tcg: Replace MO_32 with MO_UL alias tony.nguyen
2019-07-22 15:41   ` [Qemu-riscv] " tony.nguyen
2019-07-22 15:42 ` [Qemu-devel] [PATCH v2 04/20] tcg: Replace MO_64 with MO_UQ alias tony.nguyen
2019-07-22 15:42   ` [Qemu-riscv] " tony.nguyen
2019-07-22 15:43 ` [Qemu-devel] [PATCH v2 05/20] tcg: Move size+sign+endian from TCGMemOp to MemOp tony.nguyen
2019-07-22 15:43   ` [Qemu-riscv] " tony.nguyen
2019-07-22 15:44 ` [Qemu-devel] [PATCH v2 06/20] tcg: Rename get_memop to get_tcgmemop tony.nguyen
2019-07-22 15:44   ` [Qemu-riscv] " tony.nguyen
2019-07-22 15:45 ` [Qemu-devel] [PATCH v2 07/20] memory: Access MemoryRegion with MemOp tony.nguyen
2019-07-22 15:45   ` [Qemu-riscv] " tony.nguyen
2019-07-22 15:45 ` [Qemu-devel] [PATCH v2 08/20] target/mips: " tony.nguyen
2019-07-22 15:45   ` [Qemu-riscv] " tony.nguyen
2019-07-22 15:46 ` [Qemu-devel] [PATCH v2 09/20] hw/s390x: " tony.nguyen
2019-07-22 15:46   ` [Qemu-riscv] " tony.nguyen
2019-07-22 15:47 ` [Qemu-devel] [PATCH v2 10/20] hw/intc/armv7m_nic: " tony.nguyen
2019-07-22 15:47   ` [Qemu-riscv] " tony.nguyen
2019-07-22 15:48 ` tony.nguyen [this message]
2019-07-22 15:48   ` [Qemu-riscv] [Qemu-devel] [PATCH v2 11/20] hw/virtio: " tony.nguyen
2019-07-22 15:48 ` [Qemu-devel] [PATCH v2 12/20] hw/vfio: " tony.nguyen
2019-07-22 15:48   ` [Qemu-riscv] " tony.nguyen
2019-07-22 15:49 ` [Qemu-devel] [PATCH v2 13/20] exec: " tony.nguyen
2019-07-22 15:49   ` [Qemu-riscv] " tony.nguyen
2019-07-22 15:50 ` [Qemu-devel] [PATCH v2 14/20] cputlb: " tony.nguyen
2019-07-22 15:50   ` [Qemu-riscv] " tony.nguyen
2019-07-22 15:50 ` [Qemu-devel] [PATCH v2 15/20] memory: Access MemoryRegion with MemOp semantics tony.nguyen
2019-07-22 15:50   ` [Qemu-riscv] " tony.nguyen
2019-07-22 15:51 ` [Qemu-devel] [PATCH v2 16/20] memory: Single byte swap along the I/O path tony.nguyen
2019-07-22 15:51   ` [Qemu-riscv] " tony.nguyen
2019-07-22 15:51 ` [Qemu-devel] [PATCH v2 17/20] cpu: TLB_FLAGS_MASK bit to force memory slow path tony.nguyen
2019-07-22 15:51   ` [Qemu-riscv] " tony.nguyen
2019-07-25  7:01   ` [Qemu-devel] [PATCH v3 00/15] Invert Endian bit in SPARCv9 MMU TTE tony.nguyen
2019-07-25  7:01     ` [Qemu-riscv] " tony.nguyen
2019-07-25  7:03     ` [Qemu-devel] [PATCH v3 01/15] tcg: TCGMemOp is now accelerator independent MemOp tony.nguyen
2019-07-25  7:03       ` [Qemu-riscv] " tony.nguyen
2019-07-25  7:03     ` [Qemu-devel] [PATCH v3 02/15] memory: Access MemoryRegion with MemOp tony.nguyen
2019-07-25  7:03       ` [Qemu-riscv] " tony.nguyen
2019-07-25  7:05     ` [Qemu-devel] [PATCH v3 03/15] target/mips: " tony.nguyen
2019-07-25  7:05       ` [Qemu-riscv] " tony.nguyen
2019-07-25  7:06     ` [Qemu-devel] [PATCH v3 04/15] hw/s390x: " tony.nguyen
2019-07-25  7:06       ` [Qemu-riscv] " tony.nguyen
2019-07-25  7:06     ` [Qemu-devel] [PATCH v3 05/15] hw/intc/armv7m_nic: " tony.nguyen
2019-07-25  7:06       ` [Qemu-riscv] " tony.nguyen
2019-07-25  7:07     ` [Qemu-devel] [PATCH v3 06/15] hw/virtio: " tony.nguyen
2019-07-25  7:07       ` [Qemu-riscv] " tony.nguyen
2019-07-25  7:08     ` [Qemu-devel] [PATCH v3 07/15] hw/vfio: " tony.nguyen
2019-07-25  7:08       ` [Qemu-riscv] " tony.nguyen
2019-07-25  7:08     ` [Qemu-devel] [PATCH v3 08/15] exec: " tony.nguyen
2019-07-25  7:08       ` [Qemu-riscv] " tony.nguyen
2019-07-25  7:08     ` [Qemu-devel] [PATCH v3 09/15] cputlb: " tony.nguyen
2019-07-25  7:08       ` [Qemu-riscv] " tony.nguyen
2019-07-25  7:09     ` [Qemu-devel] [PATCH v3 10/15] memory: Access MemoryRegion with MemOp semantics tony.nguyen
2019-07-25  7:09       ` [Qemu-riscv] " tony.nguyen
2019-07-25  7:10     ` [Qemu-devel] [PATCH v3 11/15] memory: Single byte swap along the I/O path tony.nguyen
2019-07-25  7:10       ` [Qemu-riscv] " tony.nguyen
2019-07-25  7:10     ` [Qemu-devel] [PATCH v3 12/15] cpu: TLB_FLAGS_MASK bit to force memory slow path tony.nguyen
2019-07-25  7:10       ` [Qemu-riscv] " tony.nguyen
2019-07-25  7:11     ` [Qemu-devel] [PATCH v3 13/15] cputlb: Byte swap memory transaction attribute tony.nguyen
2019-07-25  7:11       ` [Qemu-riscv] " tony.nguyen
2019-07-25  7:11     ` [Qemu-devel] [PATCH v3 14/15] target/sparc: Add TLB entry with attributes tony.nguyen
2019-07-25  7:11       ` [Qemu-riscv] " tony.nguyen
2019-07-25  7:12     ` [Qemu-devel] [PATCH v3 15/15] target/sparc: sun4u Invert Endian TTE bit tony.nguyen
2019-07-25  7:12       ` [Qemu-riscv] " tony.nguyen
2019-07-25  7:25     ` [Qemu-devel] [PATCH v3 00/15] Invert Endian bit in SPARCv9 MMU TTE no-reply
2019-07-25  7:25       ` [Qemu-riscv] " no-reply
2019-07-25  7:58     ` [Qemu-devel] [PATCH v4 " tony.nguyen
2019-07-25  7:58       ` [Qemu-riscv] " tony.nguyen
2019-07-25  8:00       ` [Qemu-devel] [PATCH v4 01/15] tcg: TCGMemOp is now accelerator independent MemOp tony.nguyen
2019-07-25  8:00         ` [Qemu-riscv] " tony.nguyen
2019-07-25  8:00       ` [Qemu-devel] [PATCH v4 02/15] memory: Access MemoryRegion with MemOp tony.nguyen
2019-07-25  8:00         ` [Qemu-riscv] " tony.nguyen
2019-07-25  8:01       ` [Qemu-devel] [PATCH v4 03/15] target/mips: " tony.nguyen
2019-07-25  8:01         ` [Qemu-riscv] " tony.nguyen
2019-07-25  8:01       ` [Qemu-devel] [PATCH v4 04/15] hw/s390x: " tony.nguyen
2019-07-25  8:01         ` [Qemu-riscv] " tony.nguyen
2019-07-25  8:02       ` [Qemu-devel] [PATCH v4 05/15] hw/intc/armv7m_nic: " tony.nguyen
2019-07-25  8:02         ` [Qemu-riscv] " tony.nguyen
2019-07-25  8:02       ` [Qemu-devel] [PATCH v4 06/15] hw/virtio: " tony.nguyen
2019-07-25  8:02         ` [Qemu-riscv] " tony.nguyen
2019-07-25  8:03       ` [Qemu-devel] [PATCH v4 07/15] hw/vfio: " tony.nguyen
2019-07-25  8:03         ` [Qemu-riscv] " tony.nguyen
2019-07-25  8:03       ` [Qemu-devel] [PATCH v4 08/15] exec: " tony.nguyen
2019-07-25  8:03         ` [Qemu-riscv] " tony.nguyen
2019-07-25  8:04       ` [Qemu-devel] [PATCH v4 09/15] cputlb: " tony.nguyen
2019-07-25  8:04         ` [Qemu-riscv] " tony.nguyen
2019-07-25  8:04       ` [Qemu-devel] [PATCH v4 10/15] memory: Access MemoryRegion with MemOp semantics tony.nguyen
2019-07-25  8:04         ` [Qemu-riscv] " tony.nguyen
2019-07-25  8:04       ` [Qemu-devel] [PATCH v4 11/15] memory: Single byte swap along the I/O path tony.nguyen
2019-07-25  8:04         ` [Qemu-riscv] " tony.nguyen
2019-07-25  8:05       ` [Qemu-devel] [PATCH v4 12/15] cpu: TLB_FLAGS_MASK bit to force memory slow path tony.nguyen
2019-07-25  8:05         ` [Qemu-riscv] " tony.nguyen
2019-07-25  8:05       ` [Qemu-devel] [PATCH v4 13/15] cputlb: Byte swap memory transaction attribute tony.nguyen
2019-07-25  8:05         ` [Qemu-riscv] " tony.nguyen
2019-07-25  8:06       ` [Qemu-devel] [PATCH v4 14/15] target/sparc: Add TLB entry with attributes tony.nguyen
2019-07-25  8:06         ` [Qemu-riscv] " tony.nguyen
2019-07-25  8:06       ` [Qemu-devel] [PATCH v4 15/15] target/sparc: sun4u Invert Endian TTE bit tony.nguyen
2019-07-25  8:06         ` [Qemu-riscv] " tony.nguyen
2019-07-22 15:52 ` [Qemu-devel] [PATCH v2 18/20] cputlb: Byte swap memory transaction attribute tony.nguyen
2019-07-22 15:52   ` [Qemu-riscv] " tony.nguyen
2019-07-22 15:53 ` [Qemu-devel] [PATCH v2 19/20] target/sparc: Add TLB entry with attributes tony.nguyen
2019-07-22 15:53   ` [Qemu-riscv] " tony.nguyen
2019-07-22 15:54 ` [Qemu-devel] [PATCH v2 20/20] target/sparc: sun4u Invert Endian TTE bit tony.nguyen
2019-07-22 15:54   ` [Qemu-riscv] " tony.nguyen
2019-07-22 15:59 ` [Qemu-devel] [PATCH v2 00/20] Invert Endian bit in SPARCv9 MMU TTE Richard Henderson
2019-07-22 15:59   ` [Qemu-riscv] " Richard Henderson
2019-07-22 16:22   ` Paolo Bonzini
2019-07-22 16:22     ` [Qemu-riscv] " Paolo Bonzini
2019-07-22 16:28   ` tony.nguyen
2019-07-22 16:28     ` [Qemu-riscv] " tony.nguyen
2019-07-22 18:58     ` Richard Henderson
2019-07-22 18:58       ` [Qemu-riscv] " Richard Henderson

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=1563810480347.95681@bt.com \
    --to=tony.nguyen@bt.com \
    --cc=Alistair.Francis@wdc.com \
    --cc=alex.williamson@redhat.com \
    --cc=amarkovic@wavecomp.com \
    --cc=arikalo@wavecomp.com \
    --cc=atar4qemu@gmail.com \
    --cc=aurelien@aurel32.net \
    --cc=borntraeger@de.ibm.com \
    --cc=claudio.fontana@huawei.com \
    --cc=cohuck@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=david@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=mst@redhat.com \
    --cc=palmer@sifive.com \
    --cc=pasic@linux.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=sw@weilnetz.de \
    --cc=walling@linux.ibm.com \
    /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.