| Message ID | 20181025172057.20414-3-cota@braap.org |
|---|---|
| State | New |
| Headers | show |
| Series | Plugin support | expand |
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.
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 */
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(-)