This will allow us to trace 16B-long memory accesses.

While at it, add some defines for the mem_info bits and simplify
trace_mem_get_info by making it a wrapper around trace_mem_build_info.

Signed-off-by: Emilio G. Cota <cota@braap.org>
---
 trace-events | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/trace-events b/trace-events
index 4fd2cb4b97..9d65d472d2 100644
--- a/trace-events
+++ b/trace-events
@@ -151,7 +151,7 @@ vcpu guest_cpu_reset(void)
 # Access information can be parsed as:
 #
 # struct mem_info {
-#     uint8_t size_shift : 2; /* interpreted as "1 << size_shift" bytes */
+#     uint8_t size_shift : 3; /* interpreted as "1 << size_shift" bytes */
 #     bool    sign_extend: 1; /* sign-extended */
 #     uint8_t endianness : 1; /* 0: little, 1: big */
 #     bool    store      : 1; /* wheter it's a store operation */
-- 
2.17.1

Emilio G. Cota <cota@braap.org> writes:

> This will allow us to trace 16B-long memory accesses.
>
> While at it, add some defines for the mem_info bits and simplify
> trace_mem_get_info by making it a wrapper around trace_mem_build_info.
>
> Signed-off-by: Emilio G. Cota <cota@braap.org>

Currently we ignore atomic operation but I assume we'll want to
represent them at some point here. I don't know if memory barrier
behaviour would also be worth exporting?

> ---
>  trace-events | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/trace-events b/trace-events
> index 4fd2cb4b97..9d65d472d2 100644
> --- a/trace-events
> +++ b/trace-events
> @@ -151,7 +151,7 @@ vcpu guest_cpu_reset(void)
>  # Access information can be parsed as:
>  #
>  # struct mem_info {
> -#     uint8_t size_shift : 2; /* interpreted as "1 << size_shift" bytes */
> +#     uint8_t size_shift : 3; /* interpreted as "1 << size_shift" bytes */
>  #     bool    sign_extend: 1; /* sign-extended */
>  #     uint8_t endianness : 1; /* 0: little, 1: big */
>  #     bool    store      : 1; /* wheter it's a store operation */


--
Alex Bennée

On Wed, Nov 14, 2018 at 13:03:19 +0000, Alex Bennée wrote:
> 
> Emilio G. Cota <cota@braap.org> writes:
> 
> > This will allow us to trace 16B-long memory accesses.
> >
> > While at it, add some defines for the mem_info bits and simplify
> > trace_mem_get_info by making it a wrapper around trace_mem_build_info.
> >
> > Signed-off-by: Emilio G. Cota <cota@braap.org>
> 
> Currently we ignore atomic operation but I assume we'll want to
> represent them at some point here.

We "ignore" them in that we just trace them without marking them
as atomic. We do trace them since d071f4cd55 ("trace: enable tracing
of TCG atomics", 2018-06-27), which BTW is a spin-off of early
iterations of this series.

> I don't know if memory barrier behaviour would also be worth exporting?

I don't see much value in that from a tracing viewpoint; if
users need such instruction-specific details they can just
use a plugin, where they can disassemble TB's.

Thanks,

		E.