On (Tue) Oct 19 2010 [09:23:00], Hans de Goede wrote:
> >>3) This patch will cause processes filling the virtqueue fast enough to
> >>block
> >> to never wake up again, due to a missing waitqueue wakeup, see:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=643750
> >
> >Doesn't happen in my testcase, but this patch shouldn't cause that
> >problem if it exists -- it's a problem that exists even now for
> >nonblocking ports. So if such a bug exists, it needs to be fixed
> >independently.
>
> First of all lets agree that this is a real problem,
Sure, got a testcase for the test-virtserial or kvm-autotest projects?
;-)
I did try it and POLLOUT gets set for me immediately when I read one
buffer from the host.
> there is simply nothing
> waking the waitqueue were fops_write (or poll) block on when buffers become
> available in out_vq, it may be hard to come up with a test case which fills
> the queue fast enough to hit this scenario, but it is very real.
Not at all.
Connect guest
Connect host
On guest, check for POLLOUT. As long as it's set, write buffers.
When POLLOUT goes off, read one buffer from host. See if POLLOUT is set
again.
Also, as I mentioned in a private chat, the fix for that problem is easy
enough.
> I agree it is an independent problem, and should be fixed in a separate
> patch, but that patch should be part of the same set and become *before*
> this one, as this patch now extends the problem to ports opened in blocking
> mode too.
Strongly disagree. This patch fixes a problem wherein blocking-mode
writes to a port freeze the entire guest. That's a much uglier problem
to have than poll not indicating a port is writable again.
> BTW, many thanks for working on this, it is appreciated :)
Sure, thanks :-)
Amit
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/virtualization
