diff options
author | Stefan Hajnoczi <stefanha@redhat.com> | 2025-06-10 13:36:40 +0100 |
---|---|---|
committer | Stefan Hajnoczi <stefanha@redhat.com> | 2025-06-12 13:39:07 -0400 |
commit | ba2868ce091cd4abe4be6de4b7e44b3be303b352 (patch) | |
tree | cba804071fe2f794c83ebc7b050f62c92b656850 /hw/avr/arduino.c | |
parent | c653b67d1863b7ebfa67f7c9f4aec209d7b5ced5 (diff) | |
download | qemu-ba2868ce091cd4abe4be6de4b7e44b3be303b352.zip qemu-ba2868ce091cd4abe4be6de4b7e44b3be303b352.tar.gz qemu-ba2868ce091cd4abe4be6de4b7e44b3be303b352.tar.bz2 |
hw/virtio/virtio: avoid cost of -ftrivial-auto-var-init in hot path
Since commit 7ff9ff039380 ("meson: mitigate against use of uninitialize
stack for exploits") the -ftrivial-auto-var-init=zero compiler option is
used to zero local variables. While this reduces security risks
associated with uninitialized stack data, it introduced a measurable
bottleneck in the virtqueue_split_pop() and virtqueue_packed_pop()
functions.
These virtqueue functions are in the hot path. They are called for each
element (request) that is popped from a VIRTIO device's virtqueue. Using
__attribute__((uninitialized)) on large stack variables in these
functions improves fio randread bs=4k iodepth=64 performance from 304k
to 332k IOPS (+9%).
This issue was found using perf-top(1). virtqueue_split_pop() was one of
the top CPU consumers and the "annotate" feature showed that the memory
zeroing instructions at the beginning of the functions were hot.
Fixes: 7ff9ff039380 ("meson: mitigate against use of uninitialize stack for exploits")
Cc: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20250610123709.835102-3-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Diffstat (limited to 'hw/avr/arduino.c')
0 files changed, 0 insertions, 0 deletions