News for hackers. Stuff that matters.
Re:Cannoli: The Fast QEMU Tracer by coffeeri on Friday May 27, 2022 @09:31AM (#31529416)
It's great to see new projects in this space! I wonder if you have compared Cannoli to panda [0]. If so, what was the outcome - especially regarding the performance?

[0] https://github.com/panda-re/panda

Re:Cannoli: The Fast QEMU Tracer by bonzini on Friday May 27, 2022 @02:37AM (#31526647)
Get this thing upstream!
Re:Cannoli: The Fast QEMU Tracer by gamozolabs on Friday May 27, 2022 @03:17AM (#31526876)
I put some thought into that, unfortunately I had some issues with writing these hooks in QEMU TCG itself. That's what I originally did, such that it was JIT-target agnostic, but unfortunately I couldn't get the register stuff to work correctly? Idk, probably an assumption of the QEMU TCG implementation I didn't allow.

I don't think they'd want it if it's specific to one target arch. Idk. In theory the hooks into QEMU are target agnostic, there's no assembly on the QEMU side, only in the Cannoli server side (shared library).

I had it working target agnostic if I did memory accesses from the JIT, but it "didn't work" when I tried to put my data in registers (eg. the only generic implementation I used caused 2 extra memory accesses per target instruction, which is brutal at these speeds)

Re:Cannoli: The Fast QEMU Tracer by solarengineer on Friday May 27, 2022 @10:27AM (#31530039)
Perhaps you want to check with the Qemu devs? They may have advice on what work would be needed regardless of whether they accept your contribution or not, and additionally what they'd want to see in order to accept your contribution.

In any case, thank you for such a nice creation!

Re:Cannoli: The Fast QEMU Tracer by zokier on Friday May 27, 2022 @11:43AM (#31530923)
Would be interesting to know what sort of uses this thing has, now it is kinda without context.. I guess it is similar to VM introspection, but with emulation instead of virtualization?
Re:Cannoli: The Fast QEMU Tracer by UncleOxidant on Friday May 27, 2022 @12:00PM (#31531152)
I've been struggling with a problem for a few days that I think this might be great for. I'm trying to figure out how many AVX multiply-accumulate ops (vfmadd231ps) are being executed for a particular workload so I can compare two different implementations (going a bit deeper: I'm trying to figure out why there are substantial performance differences between two programs. Is it because one of them is doing a lot more multiply-accumulates (expensive ops) or is is because one is just much more cache efficient). I've got assembler for both, but one of them is macro-assembler so it's tough to actually reason about how many of these ops are being run.