Remove libkrun patches, buffer tarball writes for next unstable - #923

… packets

The unix-vsock proxy issues one recv() per RX descriptor and emits whatever
that single read found buffered. Against a bulk sender that hands the stream
over in small chunks, the muxer drains the socket faster than the writer
fills it, so descriptors carry a fraction of their capacity and the stream
fragments into sub-KiB packets while the peer's window is wide open.

Linux charges every queued packet SKB_TRUESIZE(0) against buf_alloc
regardless of payload -- 576 bytes on arm64 -- so a stream whose mean packet
falls below that exhausts the receiver's queue budget long before its byte
budget. At a 256 KiB window the queue caps at 455 packets, and since 6.12.92
the receiver resets the connection (ENOBUFS) on the 456th rather than
dropping it. That is the failure behind bulk host->guest uploads.

Fill the descriptor rather than emit one recv()'s worth, and -- because
draining alone does not help when the writer is slower than we are across
wakeups -- wait briefly on EAGAIN while still below a packet worth carrying.
poll() returns as soon as more data lands, so a fast writer pays nothing, a
slow one costs at most 4 ms, and data is always delivered rather than held.

Instrumented on both the guest rejection path and libkrun's emit path: 86%
of sub-576-byte packets came from the fill loop exiting on EAGAIN with
descriptor space and credit both free, not from the credit clamp (14%, tail
only) and never from the descriptor size (constant 3732 B). A/B with libkrun
the only variable: 0 of 10 uploads completed without this, 16 of 16 with it,
and the instrumented kernel logged no rejections.

This is a single self-contained patch against the pinned libkrun commit,
numbered 0001 because #923 removed the earlier fill-loop patches from the
tree. It subsumes their fill-loop mechanics; it does not re-carry the
separate signal-used-queue credit-request fix, which is worth its own PR.

Refs: #869

… packets (#921)

The unix-vsock proxy issues one recv() per RX descriptor and emits whatever
that single read found buffered. Against a bulk sender that hands the stream
over in small chunks, the muxer drains the socket faster than the writer
fills it, so descriptors carry a fraction of their capacity and the stream
fragments into sub-KiB packets while the peer's window is wide open.

Linux charges every queued packet SKB_TRUESIZE(0) against buf_alloc
regardless of payload -- 576 bytes on arm64 -- so a stream whose mean packet
falls below that exhausts the receiver's queue budget long before its byte
budget. At a 256 KiB window the queue caps at 455 packets, and since 6.12.92
the receiver resets the connection (ENOBUFS) on the 456th rather than
dropping it. That is the failure behind bulk host->guest uploads.

Fill the descriptor rather than emit one recv()'s worth, and -- because
draining alone does not help when the writer is slower than we are across
wakeups -- wait briefly on EAGAIN while still below a packet worth carrying.
poll() returns as soon as more data lands, so a fast writer pays nothing, a
slow one costs at most 4 ms, and data is always delivered rather than held.

Instrumented on both the guest rejection path and libkrun's emit path: 86%
of sub-576-byte packets came from the fill loop exiting on EAGAIN with
descriptor space and credit both free, not from the credit clamp (14%, tail
only) and never from the descriptor size (constant 3732 B). A/B with libkrun
the only variable: 0 of 10 uploads completed without this, 16 of 16 with it,
and the instrumented kernel logged no rejections.

This is a single self-contained patch against the pinned libkrun commit,
numbered 0001 because #923 removed the earlier fill-loop patches from the
tree. It subsumes their fill-loop mechanics; it does not re-carry the
separate signal-used-queue credit-request fix, which is worth its own PR.

Refs: #869