Possible busy-loop on process_tx errors

[nirs]

This logic can lead to a busy-loop if process_tx() returns a persistent error other than NothingWritten. In such cases, tx_has_deferred_frame will be false, and if the guest continues to supply TX buffers (has_new_entries is true), this loop will repeatedly call process_tx() and fail. The loop should be broken on any error from process_tx() to avoid this.

            let result = self.process_tx();
            self.tx_has_deferred_frame =
                matches!(result, Err(TxError::Backend(WriteError::NothingWritten)));

            if let Err(e) = result {
                if !self.tx_has_deferred_frame {
                    log::error!("Failed to process tx: {e:?}");
                }
                break;
            }

            if !self.tx_q.queue.enable_notification(&self.mem).unwrap() {
                break;
            }

Originally posted by @gemini-code-assist[bot] in #556 (comment)

[nirs]

I think the behavior should be to drop frames that we cannot write and log the error. This seems to be the behavior in the current code.

If we break from the loop we may not woke up since we use edge triggered events. If the socket is writable and we cannot write we may never wake up which is not helpful.