- 04 2月, 2011 1 次提交
-
-
由 Amit Shah 提交于
Commit 728674a7 moved virtio_console.c to drivers/tty/hvc/ under the perception of this being an hvc driver. It was such once, but these days it has generic communication capabilities as well, so move it to drivers/char/. In the future, the hvc part from this file can be split off and moved under drivers/tty/hvc/. Signed-off-by: NAmit Shah <amit.shah@redhat.com> CC: Rusty Russell <rusty@rustcorp.com.au> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 14 1月, 2011 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
As requested by Arnd Bergmann, the hvc drivers are now moved to the drivers/tty/hvc/ directory. The virtio_console.c driver was also moved, as it required the hvc_console.h file to be able to be built, and it really is a hvc driver. Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 24 11月, 2010 1 次提交
-
-
由 Jiri Slaby 提交于
Stanse found that in init_vqs, memory is leaked under certain circumstanses (the fail path order is incorrect). Fix that by checking allocations in one turn and free all of them at once if some fails (some may be NULL, but this is OK). Signed-off-by: NJiri Slaby <jslaby@suse.cz> Cc: Amit Shah <amit.shah@redhat.com> Cc: virtualization@lists.linux-foundation.org Cc: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
- 21 10月, 2010 19 次提交
-
-
由 Amit Shah 提交于
The ports are char devices; do not have seeking capabilities. Calling nonseekable_open() from the fops_open() call and setting the llseek fops pointer to no_llseek ensures an lseek() call from userspace returns -ESPIPE. Signed-off-by: NAmit Shah <amit.shah@redhat.com> CC: Arnd Bergmann <arnd@arndb.de> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
If a port has registered for SIGIO signals, let the application know that the port is getting unplugged. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
Send a SIGIO signal when new data arrives on a port. This is sent only when the process has requested for the signal to be sent using fcntl(). Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
A process can request for SIGIO on host connect / disconnect events using the O_ASYNC file flag using fcntl(). If that's requested, and if the guest-side connection for the port is open, any host-side open/close events for that port will raise a SIGIO. The process can then use poll() within the signal handler to find out which port triggered the signal. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
Explain in a comment why there's no need to reference-count the portdev struct: when a device is yanked out, we can't do anything more with it anyway so just give up doing anything more with the data or the vqs and exit cleanly. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
When a port got hot-unplugged, when a port was open, any file operation after the unplugging resulted in a crash. This is fixed by ref-counting the port structure, and releasing it only when the file is closed. This splits the unplug operation in two parts: first marks the port as unavailable, removes all the buffers in the vqs and removes the port from the per-device list of ports. The second stage, invoked when all references drop to zero, releases the chardev and frees all other memory. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
This moves to using cdev on the heap instead of it being embedded in the ports struct. This helps individual refcounting and will allow us to properly remove cdev structs after hot-unplugs and close operations. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
To convert to using cdev as a pointer to avoid kref troubles, we have to use a different method to get to a port from an inode than the current container_of method. Add find_port_by_devt() that looks up all portdevs and ports with those portdevs to find the right port. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
The virtio_console.c driver is capable of handling multiple devices at a time. Maintain a list of devices for future traversal. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
Just re-arrange code for future patches. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
When a port is removed, we have to assume the port is gone. So a success/failure return value doesn't make sense. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
When a port is hot-unplugged while an app was blocked on a write() call, the call was unblocked but would not get an error returned. Return -ENODEV to ensure the app knows the port has gone away. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
When a port is hot-unplugged while an app was blocked on a read() call, the call was unblocked but would not get an error returned. Return -ENODEV to ensure the app knows the port has gone away. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
When a port is hot-unplugged while an app is blocked on poll(), unblock the poll() and return. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
If a chardev is closed, any blocked read / poll calls should just return and not attempt to use other state. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
A portdev may have been hot-unplugged while a port was open()ed. Skip sending control messages when the portdev isn't valid. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
If a portdev isn't using multiport support, it won't have any control vq data to remove. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
The virtqueues should be disabled before attempting to remove the device. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
If the host is slow in reading data or doesn't read data at all, blocking write calls not only blocked the program that called write() but the entire guest itself. To overcome this, let's not block till the host signals it has given back the virtio ring element we passed it. Instead, send the buffer to the host and return to userspace. This operation then becomes similar to how non-blocking writes work, so let's use the existing code for this path as well. This code change also ensures blocking write calls do get blocked if there's not enough room in the virtio ring as well as they don't return -EAGAIN to userspace. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Acked-by: NHans de Goede <hdegoede@redhat.com> CC: stable@kernel.org Signed-off-by: NRusty Russell <rusty@rustcorp.com.au> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 21 9月, 2010 2 次提交
-
-
由 Amit Shah 提交于
A userspace could submit a buffer with 0 length to be written to the host. Prevent such a situation. This was not needed previously, but recent changes in the way write() works exposed this condition to trigger a virtqueue event to the host, causing a NULL buffer to be sent across. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au> CC: stable@kernel.org
-
由 Hans de Goede 提交于
I found this while working on a Linux agent for spice, the symptom I was seeing was select blocking on the spice vdagent virtio serial port even though there were messages queued up there. virtio_console's port_fops_poll checks port->inbuf != NULL to determine if read won't block. However if an application reads enough bytes from inbuf through port_fops_read, to empty the current port->inbuf, port->inbuf will be NULL even though there may be buffers left in the virtqueue. This causes poll() to block even though there is data to be read, this patch fixes this by using will_read_block(port) instead of the port->inbuf != NULL check. Signed-off-By: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au> Cc: stable@kernel.org
-
- 03 6月, 2010 2 次提交
-
-
由 Amit Shah 提交于
When a program that has a virtio port opened and blocked for a write operation, a port hot-unplug event will later led to a crash when SIGTERM was sent to the program. Fix that. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
When removing a port we don't check if a program was blocked for read. This leads to a crash when SIGTERM is sent to the program after hot-unplugging the port. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
- 19 5月, 2010 14 次提交
-
-
由 Julia Lawall 提交于
In each case, the first argument to send_control_msg or __send_control_msg, respectively, has either not been successfully allocated or has been freed at the point of the call. In the first case, the first argument, port, is only used to access the portdev and id fields, in order to call __send_control_msg. Thus it seems possible instead to call __send_control_msg directly. In the second case, the call to __send_control_msg is moved up to a place where it seems like the first argument, portdev, has been initialized sufficiently to make the call to __send_control_msg meaningful. This has only been compile tested. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @free@ expression E; position p; @@ kfree@p(E) @@ expression free.E, subE<=free.E, E1; position free.p; @@ kfree@p(E) ... ( subE = E1 | * E ) // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Acked-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
The VIRTIO_CONSOLE_RESIZE control message sent to us by the host now contains the new {rows, cols} values for the console. This ensures each console port gets its own size, and we don't depend on the config-space rows and cols values at all now. Signed-off-by: NAmit Shah <amit.shah@redhat.com> CC: Christian Borntraeger <borntraeger@de.ibm.com> CC: linuxppc-dev@ozlabs.org CC: Kusanagi Kouichi <slash@ac.auone-net.jp> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
With support for multiple consoles, just using one {rows,cols} pair in the config space is not going to suffice. Store each console's size as part of the console struct. This changes the behaviour for one case when multiport is not enabled: when notifier_add_vio() is called, the console size is taken from that of the last config-space update instead of fetching it afresh from the config space. Also add a helper to update the size in the console struct as we'll need to use the same code to update the size via control messages when multiport support is enabled. Signed-off-by: NAmit Shah <amit.shah@redhat.com> CC: Christian Borntraeger <borntraeger@de.ibm.com> CC: linuxppc-dev@ozlabs.org CC: Kusanagi Kouichi <slash@ac.auone-net.jp> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
When using multiport, we'll use control messages. Ensure we don't accidentally update port 0 size on config interrupts. Signed-off-by: NAmit Shah <amit.shah@redhat.com> CC: Christian Borntraeger <borntraeger@de.ibm.com> CC: linuxppc-dev@ozlabs.org CC: Kusanagi Kouichi <slash@ac.auone-net.jp> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
If the host port is not open, a write() should either just return if the file is opened in non-blocking mode, or block till the host port is opened. Also, don't spin till host consumes data for nonblocking ports. For non-blocking ports, we can do away with the spinning and reclaim the buffers consumed by the host on the next write call or on the condition that'll make poll return. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
We'll introduce a function that checks if write will block. Have function names that are similar for the two cases. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
If we're using multiport, there's no point in always creating a console port. Create the console port only if the host doesn't support multiport. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
Instead of the host and guest independently enumerating ports, switch to a control message to add ports where the host supplies the port number so there's no ambiguity or a possibility of a race between the host and the guest port numbers. We now no longer need the 'nr_ports' config value. Since no kernel has been released with the MULTIPORT changes yet, we have a chance to fiddle with the config space without adding compatibility features. This is beneficial for management software, which would now be able to instantiate ports at known locations and avoid problems that arise with implicit numbering in the host and the guest. This removes the 'guessing game' part of it, and management software can now actually indicate which id to spawn a particular port on. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
We're going to use add_port() from handle_control_message() in the next patch. Move the add_port() and fill_queue(), which depends on it, above handle_control_message() to avoid forward declarations. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
We're going to switch to using control messages for port hot-plug and initial port discovery. Remove the config work handler which handled port hot-plug so far. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
hvc_remove() has some bug which freezes other active hvc ports when one port is removed. So disable calling of hvc_remove() which deregisters a port with the hvc_console. If the hvc_console code calls into our get_chars() routine as a result of a poll operation, we will return -EPIPE and the hvc_console code will then do the necessary cleanup. This call will be restored when the bug in hvc_remove() is found and fixed. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
hvc_console handles -EPIPE properly when the connection to the host is lost. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
The host may want to know and let management apps notify of port or device add failures. Send a control message saying the device or port is not ready in this case. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Amit Shah 提交于
We will introduce control messages that operate on the device as a whole rather than just ports. Make send_control_msg() a wrapper around __send_control_msg() which does not need a valid port. Signed-off-by: NAmit Shah <amit.shah@redhat.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-