Re: [Qemu-devel] [PATCH] Keep pty slave file descriptor open until the master is closed

[Marc-André Lureau]

Hi

On Fri, Feb 12, 2016 at 3:29 AM, Marc-André Lureau
<address@hidden> wrote:
> Hi
>
> On Mon, Jan 11, 2016 at 10:13 AM, Paolo Bonzini <address@hidden> wrote:
>>
>>
>> On 11/01/2016 09:33, Michael Tokarev wrote:
>>> 11.12.2015 14:29, Ashley Jonathan wrote:
>>>> I have experienced a minor difficulty using QEMU with the "-serial pty" 
>>>> option:
>>>>
>>>> If a process opens the slave pts device, writes data to it, then 
>>>> immediately closes it, the data doesn't reliably get delivered to the 
>>>> emulated serial port. This seems to be because a read of the master pty 
>>>> device returns EIO on Linux if no process has the pts device open, even 
>>>> when data is waiting "in the pipe".
>>>>
>>>> A fix seems to be for QEMU to keep the pts file descriptor open until the 
>>>> pty is closed, as per the below patch.
>>>
>>> The patch looks fine, so
>>>
>>> Reviewed-by: Michael Tokarev <address@hidden>
>>>
>>> but I'd love to have an ACK from the maintainer about this one,
>>> or for it to pick it up.
>>
>> Ok, I'll pick it up after I've read up a bit more on PTYs.
>
> That patch slows down qemu a lot when using -chardev
> pty,id=charserial0 -device isa-serial,chardev=charserial0. I forgot a
> lot about how pty/pts work, and reading some man pages didn't help me
> much to understand the issue, I would suggest to revert it until a
> better solution is found.

It looks like if a the slave is opened, then Linux will buffer the
master writes, up to a few kb and then throttle, so it's not entirely
blocked but eventually the guest VM dies. However, not having any
slave open it will simply let the write go and discard the data. At
least, virt-install configures a pty for the serial but viewers like
virt-manager do not necessarily open it. And, if there are no viewers,
it will just hang. If qemu starts reading all the data from the slave,
I don't think interactions with other slaves will work. I don't see
much options but to close the slave, thus reverting this patch.

Regarding the original bug, I wonder if the slave writing process
couldn't simply fsync/fdatasync (I guess you tried that already)
Probably better to interact with the guest with something else than a
terminal though..


-- 
Marc-André Lureau