Plugins Not Reporting AArch64 SVE Memory Operations

Plugins Not Reporting AArch64 SVE Memory Operations

[Aaron Lindsay]

Hi folks,

I see there has been some previous discussion [1] about 1.5 years ago
around the fact that AArch64 SVE instructions do not emit any memory
operations via the plugin interface, as one might expect them to.

I am interested in being able to more accurately trace the memory
operations of SVE instructions using the plugin interface - has there
been any further discussion or work on this topic off-list (or that
escaped my searching)?

In the previous discussion [1], Richard raised some interesting
questions:

> The plugin interface needs extension for this.  How should I signal that 256
> consecutive byte loads have occurred?  How should I signal that the controlling
> predicate was not all true, so only 250 of those 256 were actually active?  How
> should I signal 59 non-consecutive (gather) loads have occurred?
> 
> If the answer is simply that you want 256 or 250 or 59 plugin callbacks
> respectively, then we might be able to force the memory operations into the
> slow path, and hook the operation there.  As if it were an i/o operation.

My initial reaction is that simply sending individual callbacks for each
access (only the ones which were active, in the case of predication)
seems to fit reasonably well with the existing plugin interface. For
instance, I think we already receive two callbacks for each AArch64
`LDP` instruction, right?

If this is an agreeable solution that wouldn't take too much effort to
implement (and no one else is doing it), would someone mind pointing me
in the right direction to get started?

Thanks!

-Aaron

[1] https://lists.nongnu.org/archive/html/qemu-discuss/2020-12/msg00015.html

Re: [EXTERNAL] Plugins Not Reporting AArch64 SVE Memory Operations

[Robert Henry]

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

I have not done anything on this front, alas.
________________________________
From: Aaron Lindsay <aaron@os.amperecomputing.com>
Sent: Thursday, March 24, 2022 1:17 PM
To: qemu-devel@nongnu.org <qemu-devel@nongnu.org>; qemu-arm@nongnu.org <qemu-arm@nongnu.org>
Cc: Alex Bennée <alex.bennee@linaro.org>; richard.henderson@linaro.org <richard.henderson@linaro.org>; Robert Henry <robhenry@microsoft.com>
Subject: [EXTERNAL] Plugins Not Reporting AArch64 SVE Memory Operations

Hi folks,

I see there has been some previous discussion [1] about 1.5 years ago
around the fact that AArch64 SVE instructions do not emit any memory
operations via the plugin interface, as one might expect them to.

I am interested in being able to more accurately trace the memory
operations of SVE instructions using the plugin interface - has there
been any further discussion or work on this topic off-list (or that
escaped my searching)?

In the previous discussion [1], Richard raised some interesting
questions:

> The plugin interface needs extension for this.  How should I signal that 256
> consecutive byte loads have occurred?  How should I signal that the controlling
> predicate was not all true, so only 250 of those 256 were actually active?  How
> should I signal 59 non-consecutive (gather) loads have occurred?
>
> If the answer is simply that you want 256 or 250 or 59 plugin callbacks
> respectively, then we might be able to force the memory operations into the
> slow path, and hook the operation there.  As if it were an i/o operation.

My initial reaction is that simply sending individual callbacks for each
access (only the ones which were active, in the case of predication)
seems to fit reasonably well with the existing plugin interface. For
instance, I think we already receive two callbacks for each AArch64
`LDP` instruction, right?

If this is an agreeable solution that wouldn't take too much effort to
implement (and no one else is doing it), would someone mind pointing me
in the right direction to get started?

Thanks!

-Aaron

[1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nongnu.org%2Farchive%2Fhtml%2Fqemu-discuss%2F2020-12%2Fmsg00015.html&amp;data=04%7C01%7Crobhenry%40microsoft.com%7C4fbf9f5adeca457a475e08da0dd35dc4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637837498833440416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=bTHMSkvOvvX7o7seFIbf7gDk5V%2BMBhC6YytOorHbNts%3D&amp;reserved=0

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

Re: Plugins Not Reporting AArch64 SVE Memory Operations

[Alex Bennée]

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

> Hi folks,
>
> I see there has been some previous discussion [1] about 1.5 years ago
> around the fact that AArch64 SVE instructions do not emit any memory
> operations via the plugin interface, as one might expect them to.
>
> I am interested in being able to more accurately trace the memory
> operations of SVE instructions using the plugin interface - has there
> been any further discussion or work on this topic off-list (or that
> escaped my searching)?
>
> In the previous discussion [1], Richard raised some interesting
> questions:
>
>> The plugin interface needs extension for this.  How should I signal that 256
>> consecutive byte loads have occurred?  How should I signal that the controlling
>> predicate was not all true, so only 250 of those 256 were actually active?  How
>> should I signal 59 non-consecutive (gather) loads have occurred?
>> 
>> If the answer is simply that you want 256 or 250 or 59 plugin callbacks
>> respectively, then we might be able to force the memory operations into the
>> slow path, and hook the operation there.  As if it were an i/o operation.
>
> My initial reaction is that simply sending individual callbacks for each
> access (only the ones which were active, in the case of predication)
> seems to fit reasonably well with the existing plugin interface. For
> instance, I think we already receive two callbacks for each AArch64
> `LDP` instruction, right?

This seems the simplest solution. I think what you need to look at is
how the sve_ldst1_host_fn and sve_ldst1_tlb_fn functions eventually
emerge out of the macro expansion (having a -E copy of the compiled
source might be helpful here).

That said I'm confused that softmmu isn't already hooked into by virtue
of using the softmmu slowpath (cpu_[ld|st]_*). However user space
emulation which typically directly accesses a final host address will
need to be fixed.

> If this is an agreeable solution that wouldn't take too much effort to
> implement (and no one else is doing it), would someone mind pointing me
> in the right direction to get started?

Richard, anything to add?

>
> Thanks!
>
> -Aaron
>
> [1] https://lists.nongnu.org/archive/html/qemu-discuss/2020-12/msg00015.html


-- 
Alex Bennée

Re: Plugins Not Reporting AArch64 SVE Memory Operations

[Alex Bennée]

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

> Hi folks,
>
> I see there has been some previous discussion [1] about 1.5 years ago
> around the fact that AArch64 SVE instructions do not emit any memory
> operations via the plugin interface, as one might expect them to.

To help I updated one of the tests and extended the exec plugin. See:

  Subject: [PATCH  v1 0/2] some tests and plugin tweaks for SVE
  Date: Mon, 28 Mar 2022 16:26:12 +0100
  Message-Id: <20220328152614.2452259-1-alex.bennee@linaro.org>

-- 
Alex Bennée

Re: Plugins Not Reporting AArch64 SVE Memory Operations

[Aaron Lindsay via]

On Mar 28 16:30, Alex Bennée wrote:
> 
> Aaron Lindsay <aaron@os.amperecomputing.com> writes:
> 
> > Hi folks,
> >
> > I see there has been some previous discussion [1] about 1.5 years ago
> > around the fact that AArch64 SVE instructions do not emit any memory
> > operations via the plugin interface, as one might expect them to.
> 
> To help I updated one of the tests and extended the exec plugin. See:
> 
>   Subject: [PATCH  v1 0/2] some tests and plugin tweaks for SVE
>   Date: Mon, 28 Mar 2022 16:26:12 +0100
>   Message-Id: <20220328152614.2452259-1-alex.bennee@linaro.org>

This looks helpful, thanks!

-Aaron