On 08/04/2024 14:00, Ross Lagerwall wrote:
On Sat, Apr 6, 2024 at 11:58 AM Durrant, Paul <xadimg...@gmail.com> wrote:
On 04/04/2024 15:08, Ross Lagerwall wrote:
A malicious or buggy guest may generated buffered ioreqs faster than
QEMU can process them in handle_buffered_iopage(). The result is a
livelock - QEMU continuously processes ioreqs on the main thread without
iterating through the main loop which prevents handling other events,
processing timers, etc. Without QEMU handling other events, it often
results in the guest becoming unsable and makes it difficult to stop the
source of buffered ioreqs.
To avoid this, if we process a full page of buffered ioreqs, stop and
reschedule an immediate timer to continue processing them. This lets
QEMU go back to the main loop and catch up.
Do PV backends potentially cause the same scheduling issue (if not using
io threads)?
From what I can tell:
xen-block: It reads req_prod / req_cons once before entering the loop
so it should be fine, I think.
xen_console: Same as xen-block
xen_nic: It reads req_prod / req_cons once before entering the loop.
However, once the loop ends it checks for more requests and if there
are more requests it restarts from the beginning. It seems like this
could be susceptible to the same issue.
(These PV backends generally aren't used by XenServer's system QEMU
so I didn't spend too much time looking into it.)
Thanks,
Ok. Thanks for checking.
Paul
