All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] plugins: Expose physical addresses instead of device offsets
@ 2021-03-08 20:14 Aaron Lindsay
  2021-03-08 20:22 ` Aaron Lindsay
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Aaron Lindsay @ 2021-03-08 20:14 UTC (permalink / raw)
  To: qemu-devel, Peter Maydell, Alex Bennée
  Cc: cota, richard.henderson, Aaron Lindsay

This allows plugins to query for full virtual-to-physical address
translation for a given `qemu_plugin_hwaddr` and stops exposing the
offset within the device itself. As this change breaks the API,
QEMU_PLUGIN_VERSION is incremented.

Signed-off-by: Aaron Lindsay <aaron@os.amperecomputing.com>
---
 contrib/plugins/hotpages.c  |  2 +-
 contrib/plugins/hwprofile.c |  2 +-
 include/qemu/qemu-plugin.h  |  4 ++--
 plugins/api.c               | 16 +++++++++++-----
 4 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/contrib/plugins/hotpages.c b/contrib/plugins/hotpages.c
index eacc678eac..bf53267532 100644
--- a/contrib/plugins/hotpages.c
+++ b/contrib/plugins/hotpages.c
@@ -122,7 +122,7 @@ static void vcpu_haddr(unsigned int cpu_index, qemu_plugin_meminfo_t meminfo,
         }
     } else {
         if (hwaddr && !qemu_plugin_hwaddr_is_io(hwaddr)) {
-            page = (uint64_t) qemu_plugin_hwaddr_device_offset(hwaddr);
+            page = (uint64_t) qemu_plugin_hwaddr_phys_addr(hwaddr);
         } else {
             page = vaddr;
         }
diff --git a/contrib/plugins/hwprofile.c b/contrib/plugins/hwprofile.c
index 6dac1d5f85..faf216ac00 100644
--- a/contrib/plugins/hwprofile.c
+++ b/contrib/plugins/hwprofile.c
@@ -201,7 +201,7 @@ static void vcpu_haddr(unsigned int cpu_index, qemu_plugin_meminfo_t meminfo,
         return;
     } else {
         const char *name = qemu_plugin_hwaddr_device_name(hwaddr);
-        uint64_t off = qemu_plugin_hwaddr_device_offset(hwaddr);
+        uint64_t off = qemu_plugin_hwaddr_phys_addr(hwaddr);
         bool is_write = qemu_plugin_mem_is_store(meminfo);
         DeviceCounts *counts;
 
diff --git a/include/qemu/qemu-plugin.h b/include/qemu/qemu-plugin.h
index c66507fe8f..2252ecf2f0 100644
--- a/include/qemu/qemu-plugin.h
+++ b/include/qemu/qemu-plugin.h
@@ -47,7 +47,7 @@ typedef uint64_t qemu_plugin_id_t;
 
 extern QEMU_PLUGIN_EXPORT int qemu_plugin_version;
 
-#define QEMU_PLUGIN_VERSION 0
+#define QEMU_PLUGIN_VERSION 1
 
 typedef struct {
     /* string describing architecture */
@@ -328,7 +328,7 @@ struct qemu_plugin_hwaddr *qemu_plugin_get_hwaddr(qemu_plugin_meminfo_t info,
  * offset will be into the appropriate block of RAM.
  */
 bool qemu_plugin_hwaddr_is_io(const struct qemu_plugin_hwaddr *haddr);
-uint64_t qemu_plugin_hwaddr_device_offset(const struct qemu_plugin_hwaddr *haddr);
+uint64_t qemu_plugin_hwaddr_phys_addr(const struct qemu_plugin_hwaddr *haddr);
 
 /*
  * Returns a string representing the device. The string is valid for
diff --git a/plugins/api.c b/plugins/api.c
index 0b04380d57..e7352df3e3 100644
--- a/plugins/api.c
+++ b/plugins/api.c
@@ -40,6 +40,7 @@
 #include "sysemu/sysemu.h"
 #include "tcg/tcg.h"
 #include "exec/exec-all.h"
+#include "exec/ram_addr.h"
 #include "disas/disas.h"
 #include "plugin.h"
 #ifndef CONFIG_USER_ONLY
@@ -298,19 +299,24 @@ bool qemu_plugin_hwaddr_is_io(const struct qemu_plugin_hwaddr *haddr)
 #endif
 }
 
-uint64_t qemu_plugin_hwaddr_device_offset(const struct qemu_plugin_hwaddr *haddr)
+uint64_t qemu_plugin_hwaddr_phys_addr(const struct qemu_plugin_hwaddr *haddr)
 {
 #ifdef CONFIG_SOFTMMU
     if (haddr) {
         if (!haddr->is_io) {
-            ram_addr_t ram_addr = qemu_ram_addr_from_host((void *) haddr->v.ram.hostaddr);
-            if (ram_addr == RAM_ADDR_INVALID) {
+            RAMBlock *block;
+            ram_addr_t offset;
+
+            block = qemu_ram_block_from_host((void *) haddr->v.ram.hostaddr, false, &offset);
+            if (!block) {
                 error_report("Bad ram pointer %"PRIx64"", haddr->v.ram.hostaddr);
                 abort();
             }
-            return ram_addr;
+
+            return block->offset + offset + block->mr->addr;
         } else {
-            return haddr->v.io.offset;
+            MemoryRegionSection *mrs = haddr->v.io.section;
+            return haddr->v.io.offset + mrs->mr->addr;
         }
     }
 #endif
-- 
2.17.1



^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] plugins: Expose physical addresses instead of device offsets
  2021-03-08 20:14 [PATCH] plugins: Expose physical addresses instead of device offsets Aaron Lindsay
@ 2021-03-08 20:22 ` Aaron Lindsay
  2021-03-09 10:28   ` Alex Bennée
  2021-03-08 20:33 ` no-reply
  2021-03-09 10:08 ` Peter Maydell
  2 siblings, 1 reply; 8+ messages in thread
From: Aaron Lindsay @ 2021-03-08 20:22 UTC (permalink / raw)
  To: qemu-devel, Peter Maydell, Alex Bennée; +Cc: cota, richard.henderson

Alex,

I've now tested this change, and it is giving what appear to be valid
and correct physical addresses for both RAM and IO accesses in all the
cases I've thrown at it. My main concern with this patch at this point
is that I am concerned I may be breaking your new plugin here:

> +++ b/contrib/plugins/hwprofile.c
> @@ -201,7 +201,7 @@ static void vcpu_haddr(unsigned int cpu_index, qemu_plugin_meminfo_t meminfo,
>          return;
>      } else {
>          const char *name = qemu_plugin_hwaddr_device_name(hwaddr);
> -        uint64_t off = qemu_plugin_hwaddr_device_offset(hwaddr);
> +        uint64_t off = qemu_plugin_hwaddr_phys_addr(hwaddr);

How angry is the plugin going to be that these are now physical
addresses instead of offsets?

-Aaron


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] plugins: Expose physical addresses instead of device offsets
  2021-03-08 20:14 [PATCH] plugins: Expose physical addresses instead of device offsets Aaron Lindsay
  2021-03-08 20:22 ` Aaron Lindsay
@ 2021-03-08 20:33 ` no-reply
  2021-03-09 10:08 ` Peter Maydell
  2 siblings, 0 replies; 8+ messages in thread
From: no-reply @ 2021-03-08 20:33 UTC (permalink / raw)
  To: aaron
  Cc: peter.maydell, richard.henderson, qemu-devel, aaron, cota, alex.bennee

Patchew URL: https://patchew.org/QEMU/20210308201406.1240023-1-aaron@os.amperecomputing.com/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 20210308201406.1240023-1-aaron@os.amperecomputing.com
Subject: [PATCH] plugins: Expose physical addresses instead of device offsets

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
   0436c55..229a834  master     -> master
 - [tag update]      patchew/20210308121155.2476-1-mark.cave-ayland@ilande.co.uk -> patchew/20210308121155.2476-1-mark.cave-ayland@ilande.co.uk
 - [tag update]      patchew/20210308173244.20710-1-peter.maydell@linaro.org -> patchew/20210308173244.20710-1-peter.maydell@linaro.org
 * [new tag]         patchew/20210308201406.1240023-1-aaron@os.amperecomputing.com -> patchew/20210308201406.1240023-1-aaron@os.amperecomputing.com
Switched to a new branch 'test'
fdddbf1 plugins: Expose physical addresses instead of device offsets

=== OUTPUT BEGIN ===
ERROR: line over 90 characters
#96: FILE: plugins/api.c:310:
+            block = qemu_ram_block_from_host((void *) haddr->v.ram.hostaddr, false, &offset);

total: 1 errors, 0 warnings, 68 lines checked

Commit fdddbf18a9ac (plugins: Expose physical addresses instead of device offsets) has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20210308201406.1240023-1-aaron@os.amperecomputing.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] plugins: Expose physical addresses instead of device offsets
  2021-03-08 20:14 [PATCH] plugins: Expose physical addresses instead of device offsets Aaron Lindsay
  2021-03-08 20:22 ` Aaron Lindsay
  2021-03-08 20:33 ` no-reply
@ 2021-03-09 10:08 ` Peter Maydell
  2021-03-09 14:40   ` Aaron Lindsay
  2 siblings, 1 reply; 8+ messages in thread
From: Peter Maydell @ 2021-03-09 10:08 UTC (permalink / raw)
  To: Aaron Lindsay
  Cc: Richard Henderson, Emilio G. Cota, Alex Bennée, QEMU Developers

On Mon, 8 Mar 2021 at 20:14, Aaron Lindsay <aaron@os.amperecomputing.com> wrote:
>
> This allows plugins to query for full virtual-to-physical address
> translation for a given `qemu_plugin_hwaddr` and stops exposing the
> offset within the device itself. As this change breaks the API,
> QEMU_PLUGIN_VERSION is incremented.
>
> Signed-off-by: Aaron Lindsay <aaron@os.amperecomputing.com>
> ---


> diff --git a/include/qemu/qemu-plugin.h b/include/qemu/qemu-plugin.h
> index c66507fe8f..2252ecf2f0 100644
> --- a/include/qemu/qemu-plugin.h
> +++ b/include/qemu/qemu-plugin.h
> @@ -47,7 +47,7 @@ typedef uint64_t qemu_plugin_id_t;
>
>  extern QEMU_PLUGIN_EXPORT int qemu_plugin_version;
>
> -#define QEMU_PLUGIN_VERSION 0
> +#define QEMU_PLUGIN_VERSION 1
>
>  typedef struct {
>      /* string describing architecture */
> @@ -328,7 +328,7 @@ struct qemu_plugin_hwaddr *qemu_plugin_get_hwaddr(qemu_plugin_meminfo_t info,
>   * offset will be into the appropriate block of RAM.
>   */
>  bool qemu_plugin_hwaddr_is_io(const struct qemu_plugin_hwaddr *haddr);
> -uint64_t qemu_plugin_hwaddr_device_offset(const struct qemu_plugin_hwaddr *haddr);
> +uint64_t qemu_plugin_hwaddr_phys_addr(const struct qemu_plugin_hwaddr *haddr);


This should have a documentation comment, since this is the public-facing API.

Also, physical addresses aren't uniquely identifying, they're only valid
in the context of a particular address space (think TrustZone, for instance),
so the plugin-facing API should probably have some concept of how it
distinguishes "this is an access for Secure 0x4000" from "this is an
access for Non-Secure 0x4000".

thanks
-- PMM


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] plugins: Expose physical addresses instead of device offsets
  2021-03-08 20:22 ` Aaron Lindsay
@ 2021-03-09 10:28   ` Alex Bennée
  0 siblings, 0 replies; 8+ messages in thread
From: Alex Bennée @ 2021-03-09 10:28 UTC (permalink / raw)
  To: Aaron Lindsay; +Cc: Peter Maydell, cota, richard.henderson, qemu-devel


Aaron Lindsay <aaron@os.amperecomputing.com> writes:

> Alex,
>
> I've now tested this change, and it is giving what appear to be valid
> and correct physical addresses for both RAM and IO accesses in all the
> cases I've thrown at it. My main concern with this patch at this point
> is that I am concerned I may be breaking your new plugin here:
>
>> +++ b/contrib/plugins/hwprofile.c
>> @@ -201,7 +201,7 @@ static void vcpu_haddr(unsigned int cpu_index, qemu_plugin_meminfo_t meminfo,
>>          return;
>>      } else {
>>          const char *name = qemu_plugin_hwaddr_device_name(hwaddr);
>> -        uint64_t off = qemu_plugin_hwaddr_device_offset(hwaddr);
>> +        uint64_t off = qemu_plugin_hwaddr_phys_addr(hwaddr);
>
> How angry is the plugin going to be that these are now physical
> addresses instead of offsets?

I think it will be fine. It's a new plugin this cycle and it only
changes the reporting.

-- 
Alex Bennée


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] plugins: Expose physical addresses instead of device offsets
  2021-03-09 10:08 ` Peter Maydell
@ 2021-03-09 14:40   ` Aaron Lindsay
  2021-03-09 17:45     ` Alex Bennée
  0 siblings, 1 reply; 8+ messages in thread
From: Aaron Lindsay @ 2021-03-09 14:40 UTC (permalink / raw)
  To: Peter Maydell
  Cc: QEMU Developers, Alex Bennée, Emilio G. Cota, Richard Henderson

On Mar 09 10:08, Peter Maydell wrote:
> On Mon, 8 Mar 2021 at 20:14, Aaron Lindsay <aaron@os.amperecomputing.com> wrote:
> >
> > This allows plugins to query for full virtual-to-physical address
> > translation for a given `qemu_plugin_hwaddr` and stops exposing the
> > offset within the device itself. As this change breaks the API,
> > QEMU_PLUGIN_VERSION is incremented.
> >
> > Signed-off-by: Aaron Lindsay <aaron@os.amperecomputing.com>
> > ---
> 
> 
> > diff --git a/include/qemu/qemu-plugin.h b/include/qemu/qemu-plugin.h
> > index c66507fe8f..2252ecf2f0 100644
> > --- a/include/qemu/qemu-plugin.h
> > +++ b/include/qemu/qemu-plugin.h
> > @@ -47,7 +47,7 @@ typedef uint64_t qemu_plugin_id_t;
> >
> >  extern QEMU_PLUGIN_EXPORT int qemu_plugin_version;
> >
> > -#define QEMU_PLUGIN_VERSION 0
> > +#define QEMU_PLUGIN_VERSION 1
> >
> >  typedef struct {
> >      /* string describing architecture */
> > @@ -328,7 +328,7 @@ struct qemu_plugin_hwaddr *qemu_plugin_get_hwaddr(qemu_plugin_meminfo_t info,
> >   * offset will be into the appropriate block of RAM.
> >   */
> >  bool qemu_plugin_hwaddr_is_io(const struct qemu_plugin_hwaddr *haddr);
> > -uint64_t qemu_plugin_hwaddr_device_offset(const struct qemu_plugin_hwaddr *haddr);
> > +uint64_t qemu_plugin_hwaddr_phys_addr(const struct qemu_plugin_hwaddr *haddr);
> 
> 
> This should have a documentation comment, since this is the public-facing API.

I now see I neglected to update the comment right here the function
declaration, and will do so for v2.

But are you asking for additional documentation beyond that change? If
so, where is the right place to add this? docs/devel/tcg-plugins.rst
doesn't seem to have much in the way of documentation for the actual
calls.

> Also, physical addresses aren't uniquely identifying, they're only valid
> in the context of a particular address space (think TrustZone, for instance),
> so the plugin-facing API should probably have some concept of how it
> distinguishes "this is an access for Secure 0x4000" from "this is an
> access for Non-Secure 0x4000".

I agree it could be handy to expose address spaces in addition to the
addresses themselves. Do you believe doing so would change the form of
the interface in this patch, or could that be a logically separate
addition?

I have a secondary concern that it might be hard to expose address
spaces in an architecture-agnostic yet still-helpful way, but haven't
thought through that enough for it to be a firm opinion.

-Aaron


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] plugins: Expose physical addresses instead of device offsets
  2021-03-09 14:40   ` Aaron Lindsay
@ 2021-03-09 17:45     ` Alex Bennée
  2021-03-09 20:30       ` Aaron Lindsay via
  0 siblings, 1 reply; 8+ messages in thread
From: Alex Bennée @ 2021-03-09 17:45 UTC (permalink / raw)
  To: Aaron Lindsay
  Cc: Peter Maydell, Emilio G. Cota, Richard Henderson, QEMU Developers


Aaron Lindsay <aaron@os.amperecomputing.com> writes:

> On Mar 09 10:08, Peter Maydell wrote:
>> On Mon, 8 Mar 2021 at 20:14, Aaron Lindsay <aaron@os.amperecomputing.com> wrote:
>> >
>> > This allows plugins to query for full virtual-to-physical address
>> > translation for a given `qemu_plugin_hwaddr` and stops exposing the
>> > offset within the device itself. As this change breaks the API,
>> > QEMU_PLUGIN_VERSION is incremented.
>> >
>> > Signed-off-by: Aaron Lindsay <aaron@os.amperecomputing.com>
>> > ---
>> 
>> 
>> > diff --git a/include/qemu/qemu-plugin.h b/include/qemu/qemu-plugin.h
>> > index c66507fe8f..2252ecf2f0 100644
>> > --- a/include/qemu/qemu-plugin.h
>> > +++ b/include/qemu/qemu-plugin.h
>> > @@ -47,7 +47,7 @@ typedef uint64_t qemu_plugin_id_t;
>> >
>> >  extern QEMU_PLUGIN_EXPORT int qemu_plugin_version;
>> >
>> > -#define QEMU_PLUGIN_VERSION 0
>> > +#define QEMU_PLUGIN_VERSION 1
>> >
>> >  typedef struct {
>> >      /* string describing architecture */
>> > @@ -328,7 +328,7 @@ struct qemu_plugin_hwaddr *qemu_plugin_get_hwaddr(qemu_plugin_meminfo_t info,
>> >   * offset will be into the appropriate block of RAM.
>> >   */
>> >  bool qemu_plugin_hwaddr_is_io(const struct qemu_plugin_hwaddr *haddr);
>> > -uint64_t qemu_plugin_hwaddr_device_offset(const struct qemu_plugin_hwaddr *haddr);
>> > +uint64_t qemu_plugin_hwaddr_phys_addr(const struct qemu_plugin_hwaddr *haddr);
>> 
>> 
>> This should have a documentation comment, since this is the public-facing API.
>
> I now see I neglected to update the comment right here the function
> declaration, and will do so for v2.
>
> But are you asking for additional documentation beyond that change? If
> so, where is the right place to add this? docs/devel/tcg-plugins.rst
> doesn't seem to have much in the way of documentation for the actual
> calls.

The calls should be documented in @kerneldoc style comments in the main
plugin header. Which reminds me I should be able to extract them into
the tcg-plugins.rst document via sphinx.

>
>> Also, physical addresses aren't uniquely identifying, they're only valid
>> in the context of a particular address space (think TrustZone, for instance),
>> so the plugin-facing API should probably have some concept of how it
>> distinguishes "this is an access for Secure 0x4000" from "this is an
>> access for Non-Secure 0x4000".
>
> I agree it could be handy to expose address spaces in addition to the
> addresses themselves. Do you believe doing so would change the form of
> the interface in this patch, or could that be a logically separate
> addition?

I think information about address spaces should extracted be a separate
query.

> I have a secondary concern that it might be hard to expose address
> spaces in an architecture-agnostic yet still-helpful way, but haven't
> thought through that enough for it to be a firm opinion.

Indeed - so I don't think we need to rush this without giving it some
thought. As soft-freeze is only a few days away I don't think we want to
rush an address space query API into 6.0. For most users I expect a
assuming physical address is unique will work for the most part. But
it's worth mentioning it might not be in the comment.

>
> -Aaron


-- 
Alex Bennée


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] plugins: Expose physical addresses instead of device offsets
  2021-03-09 17:45     ` Alex Bennée
@ 2021-03-09 20:30       ` Aaron Lindsay via
  0 siblings, 0 replies; 8+ messages in thread
From: Aaron Lindsay via @ 2021-03-09 20:30 UTC (permalink / raw)
  To: Alex Bennée
  Cc: Peter Maydell, QEMU Developers, Emilio G. Cota, Richard Henderson

On Mar 09 17:45, Alex Bennée wrote:
> Aaron Lindsay <aaron@os.amperecomputing.com> writes:
> > On Mar 09 10:08, Peter Maydell wrote:
> >> On Mon, 8 Mar 2021 at 20:14, Aaron Lindsay <aaron@os.amperecomputing.com> wrote:
> >> >
> >> > This allows plugins to query for full virtual-to-physical address
> >> > translation for a given `qemu_plugin_hwaddr` and stops exposing the
> >> > offset within the device itself. As this change breaks the API,
> >> > QEMU_PLUGIN_VERSION is incremented.
> >> >
> >> > Signed-off-by: Aaron Lindsay <aaron@os.amperecomputing.com>
> >> > ---
> >> 
> >> 
> >> > diff --git a/include/qemu/qemu-plugin.h b/include/qemu/qemu-plugin.h
> >> > index c66507fe8f..2252ecf2f0 100644
> >> > --- a/include/qemu/qemu-plugin.h
> >> > +++ b/include/qemu/qemu-plugin.h
> >> > @@ -47,7 +47,7 @@ typedef uint64_t qemu_plugin_id_t;
> >> >
> >> >  extern QEMU_PLUGIN_EXPORT int qemu_plugin_version;
> >> >
> >> > -#define QEMU_PLUGIN_VERSION 0
> >> > +#define QEMU_PLUGIN_VERSION 1
> >> >
> >> >  typedef struct {
> >> >      /* string describing architecture */
> >> > @@ -328,7 +328,7 @@ struct qemu_plugin_hwaddr *qemu_plugin_get_hwaddr(qemu_plugin_meminfo_t info,
> >> >   * offset will be into the appropriate block of RAM.
> >> >   */
> >> >  bool qemu_plugin_hwaddr_is_io(const struct qemu_plugin_hwaddr *haddr);
> >> > -uint64_t qemu_plugin_hwaddr_device_offset(const struct qemu_plugin_hwaddr *haddr);
> >> > +uint64_t qemu_plugin_hwaddr_phys_addr(const struct qemu_plugin_hwaddr *haddr);
> >> 
> >> 
> >> This should have a documentation comment, since this is the public-facing API.
> >
> > I now see I neglected to update the comment right here the function
> > declaration, and will do so for v2.
> >
> > But are you asking for additional documentation beyond that change? If
> > so, where is the right place to add this? docs/devel/tcg-plugins.rst
> > doesn't seem to have much in the way of documentation for the actual
> > calls.
> 
> The calls should be documented in @kerneldoc style comments in the main
> plugin header. Which reminds me I should be able to extract them into
> the tcg-plugins.rst document via sphinx.

I just sent out v2, in which I took a pass at updating this
documentation. Let me know what you think.

-Aaron


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2021-03-09 21:00 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-08 20:14 [PATCH] plugins: Expose physical addresses instead of device offsets Aaron Lindsay
2021-03-08 20:22 ` Aaron Lindsay
2021-03-09 10:28   ` Alex Bennée
2021-03-08 20:33 ` no-reply
2021-03-09 10:08 ` Peter Maydell
2021-03-09 14:40   ` Aaron Lindsay
2021-03-09 17:45     ` Alex Bennée
2021-03-09 20:30       ` Aaron Lindsay via

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.