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?
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.
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.
[0] https://github.com/panda-re/panda
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)
In any case, thank you for such a nice creation!