aboutsummaryrefslogtreecommitdiffstats
path: root/hw/virtio-console.c
AgeCommit message (Collapse)AuthorFilesLines
2012-02-15qom: Unify type registrationAndreas Färber1-8/+4
Replace device_init() with generalized type_init(). While at it, unify naming convention: type_init([$prefix_]register_types) Also, type_init() is a function, so add preceding blank line where necessary and don't put a semicolon after the closing brace. Signed-off-by: Andreas Färber <afaerber@suse.de> Cc: Anthony Liguori <anthony@codemonkey.ws> Cc: malc <av1474@comtv.ru> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-02-03qdev: register all types natively through QEMU Object ModelAnthony Liguori1-12/+16
This was done in a mostly automated fashion. I did it in three steps and then rebased it into a single step which avoids repeatedly touching every file in the tree. The first step was a sed-based addition of the parent type to the subclass registration functions. The second step was another sed-based removal of subclass registration functions while also adding virtual functions from the base class into a class_init function as appropriate. Finally, a python script was used to convert the DeviceInfo structures and qdev_register_subclass functions to TypeInfo structures, class_init functions, and type_register_static calls. We are almost fully converted to QOM after this commit. Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-01-27virtio-serial: convert to QEMU Object ModelAnthony Liguori1-26/+43
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-01-27qdev: move qdev->info to classAnthony Liguori1-1/+1
Right now, DeviceInfo acts as the class for qdev. In order to switch to a proper ObjectClass derivative, we need to ween all of the callers off of interacting directly with the info pointer. Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-01-13virtio-console: no need to remove char handlers explicitlyAmit Shah1-17/+0
qdev is now equipped (thanks to the last commit) to disassociate chardevs from the qdev devices on the devices going away. So doing it in the virtio-console driver is not necessary. Since that was the only thing being done in the qdev exit method, drop it entirely. Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-12-21virtio-console: Properly initialise class methodsAmit Shah1-3/+6
The earlier code really was a hack: initialising class methods in an object init function as noted by Anthony. The motivation for that was to not have the virtio-serial-bus call into the callback functions if there was no chardev backend registered. However, that really wasn't a worthwhile optimisation, and definitely not one that was well-implemented. Get rid of it. Reported-by: Anthony Liguori <aliguori@us.ibm.com> Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-12-21virtio-console: Check if chardev backends available before calling into themAmit Shah1-0/+11
For the callback functions invoked by the virtio-serial-bus code, check if we have chardev backends registered before we call into the chardev functions. Signed-off-by: Amit Shah <amit.shah@redhat.com> Reported-by: Anthony Liguori <aliguori@us.ibm.com> Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-08-22char: rename qemu_chr_guest_close() -> qemu_chr_fe_close()Anthony Liguori1-1/+1
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-08-22char: rename qemu_chr_guest_open() -> qemu_chr_fe_open()Anthony Liguori1-1/+1
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-08-22char: rename qemu_chr_write() -> qemu_chr_fe_write()Anthony Liguori1-1/+1
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-07-23virtio-serial: Turn props any virtio-serial-bus device must have into bus propsMarkus Armbruster1-4/+0
Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-07-18virtio-console: Prevent abort()s in case of host chardev closeAmit Shah1-1/+15
A host chardev could close just before the guest sends some data to be written. This will cause an -EPIPE error. This shouldn't be propagated to virtio-serial-bus. Ideally we should close the port once -EPIPE is received, but since the chardev interface doesn't return such meaningful values to its users, all we get is -1 for any kind of error. Just return 0 for now and wait for chardevs to return better error messages to act better on the return messages. Signed-off-by: Amit Shah <amit.shah@redhat.com>
2011-07-18virtio-console: Add some trace eventsAmit Shah1-1/+8
Add some trace events for messages passed between the char layer and the virtio-serial bus. Signed-off-by: Amit Shah <amit.shah@redhat.com>
2011-05-27virtio-console: Simplify init callbacksMarkus Armbruster1-26/+9
Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2011-05-27virtio-serial: Drop redundant VirtIOSerialPort member infoMarkus Armbruster1-3/+6
Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2011-05-27virtio-serial: Drop useless property is_consoleMarkus Armbruster1-2/+0
All you could ever achieve with it is break stuff, so removing it should be safe. Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2011-05-27virtio-serial: Clean up virtconsole detectionMarkus Armbruster1-2/+3
virtio-serial-bus needs to treat "virtconsole" devices specially. It uses VirtIOSerialPort member is_console to recognize them. It gets its value via property initialization. Cute hack, except it lets users mess with it: "-device virtconsole,is_console=0" isn't plugged into port 0 as it should. Move the flag to VirtIOSerialPortInfo. Keep the property for backward compatibility; its value has no effect. Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2011-04-28virtio-console: notify backend of guest open / closeHans de Goede1-0/+18
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Alon Levy <alevy@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2011-03-21virtio-console: Keep chardev open for other users after hot-unplugAmit Shah1-1/+5
After a hot-unplug operation, the previous behaviour was to close the chardev. That meant the chardev couldn't be re-used. Also, since chardev hot-plug isn't possible so far, this means virtio-console hot-plug isn't feasible as well. With this change, the chardev is kept around. A new virtio-console channel can then be hot-plugged with the same chardev and things will continue to work. Signed-off-by: Amit Shah <amit.shah@redhat.com>
2011-03-21virtio-serial: Don't clear ->have_data() pointer after unplugAmit Shah1-1/+0
After a port unplug operation, the port->info->have_data() pointer was set to NULL. The problem is, the ->info struct is shared by all ports, effectively disabling writes to other ports. Reported-by: juzhang <juzhang@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2011-03-21virtio-serial: Disallow generic ports at id 0Amit Shah1-0/+9
Port 0 is reserved for virtconsole devices for backward compatibility with the old -virtioconsole (from qemu 0.12) device type. libvirt prior to commit 8e28c5d40200b4c5d483bd585d237b9d870372e5 used port 0 for generic ports. libvirt will no longer do that, but disallow instantiating generic ports at id 0 from qemu as well. Signed-off-by: Amit Shah <amit.shah@redhat.com>
2011-02-24virtio-serial: kill VirtIOSerialDeviceGerd Hoffmann1-11/+6
VirtIOSerialDevice is like VirtIOSerialPort with just the first two fields, which makes it pretty pointless. Using VirtIOSerialPort directly works equally well and is less confusing. [Amit: - rebase - rename 'dev' to 'port' in function params in virtio-serial.h ] Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-01-20virtio-serial: Let virtio-serial-bus know if all data was consumedAmit Shah1-2/+2
The have_data() API to hand off guest data to apps using virtio-serial so far assumed all the data was consumed. Relax this assumption. Future commits will allow for incomplete writes. Signed-off-by: Amit Shah <amit.shah@redhat.com>
2011-01-19virtio-console: Remove unnecessary bracesAmit Shah1-2/+1
Remove unnecessary braces around a case statement. Signed-off-by: Amit Shah <amit.shah@redhat.com>
2011-01-19virtio-console: Factor out common init between console and generic portsAmit Shah1-17/+14
The initialisation for generic ports and console ports is similar. Factor out the parts that are the same in a different function that can be called from each of the initfns. Signed-off-by: Amit Shah <amit.shah@redhat.com>
2010-04-28virtio-serial: Apps should consume all data that guest sends out / Fix ↵Amit Shah1-5/+2
virtio api abuse We cannot indicate to the guest how much data was consumed by an app for out_bufs. So we just have to assume the apps will consume all the data that are handed over to them. Fix the virtio api abuse in control_out() and handle_output(). Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-04-28virtio-serial: Update copyright year to 2010Amit Shah1-1/+1
Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-04-28virtio-serial: Use control messages to notify guest of new portsAmit Shah1-0/+2
Allow the port 'id's to be set by a user on the command line. This is needed by management apps that will want a stable port numbering scheme for hot-plug/unplug and migration. Since the port numbers are shared with the guest (to identify ports in control messages), we just send a control message to the guest indicating addition of new ports (hot-plug) or notifying the guest of the available ports when the guest sends us a DEVICE_READY control message. Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-01-26virtio-console: Rename virtio-serial.c back to virtio-console.cAmit Shah1-0/+146
This file was renamed to ease the reviews of the recent changes that went in. Now that the changes are done, rename the file back to its original name. Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-01-20virtio-console: qdev conversion, new virtio-serial-busAmit Shah1-143/+0
This commit converts the virtio-console device to create a new virtio-serial bus that can host console and generic serial ports. The file hosting this code is now called virtio-serial-bus.c. The virtio console is now a very simple qdev device that sits on the virtio-serial-bus and communicates between the bus and qemu's chardevs. This commit also includes a few changes to the virtio backing code for pci and s390 to spawn the virtio-serial bus. As a result of the qdev conversion, we get rid of a lot of legacy code. The old-style way of instantiating a virtio console using -virtioconsole ... is maintained, but the new, preferred way is to use -device virtio-serial -device virtconsole,chardev=... With this commit, multiple devices as well as multiple ports with a single device can be supported. For multiple ports support, each port gets an IO vq pair. Since the guest needs to know in advance how many vqs a particular device will need, we have to set this number as a property of the virtio-serial device and also as a config option. In addition, we also spawn a pair of control IO vqs. This is an internal channel meant for guest-host communication for things like port open/close, sending port properties over to the guest, etc. This commit is a part of a series of other commits to get the full implementation of multiport support. Future commits will add other support as well as ride on the savevm version that we bump up here. Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-01-11virtio: add features as qdev propertiesMichael S. Tsirkin1-2/+2
Add feature bits as properties to virtio. This makes it possible to e.g. define machine without indirect buffer support, which is required for 0.10 compatibility, or without hardware checksum support, which is required for 0.11 compatibility. Since default values for optional features are now set by qdev, get_features callback has been modified: it sets non-optional bits, and clears bits not supported by host. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2009-08-27virtio-console: rename dvq to ovqAmit Shah1-2/+2
It isn't obvious what 'dvq' stands for. Since it's the output queue and the corresponding input queue is called 'ivq', call this 'ovq' Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2009-05-18Separate virtio PCI codePaul Brook1-16/+6
Split the PCI host bindings from the VRing transport implementation. Signed-off-by: Paul Brook <paul@codesourcery.com>
2009-05-14Virtio-console conversionPaul Brook1-15/+11
Signed-off-by: Paul Brook <paul@codesourcery.com>
2009-05-14Virtio-net qdev conversionPaul Brook1-2/+8
Signed-off-by: Paul Brook <paul@codesourcery.com>
2009-04-13Fix OpenSolaris gcc4 warnings: iovec type mismatches, missing 'static'blueswir11-2/+4
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7103 c046a42c-6fe2-441c-8c8c-71466251a162
2009-02-01Add and use #defines for PCI device classesblueswir11-1/+1
This patch adds and uses #defines for PCI device classes and subclases, using a new pci_config_set_class() function, similar to the recently added pci_config_set_vendor_id() and pci_config_set_device_id(). Change since v1: fixed compilation of hw/sun4u.c Signed-off-by: Stuart Brady <stuart.brady@gmail.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6491 c046a42c-6fe2-441c-8c8c-71466251a162
2009-01-26Use the default subsystem vendor ID for virtio devices (Mark McLoughlin)aliguori1-1/+2
A subsystem vendor ID of zero isn't allowed, so we use our default ID. Gerd points out that although the PCI subsystem vendor ID is treated by the guest as the virtio vendor ID: /* we use the subsystem vendor/device id as the virtio vendor/device * id. this allows us to use the same PCI vendor/device id for all * virtio devices and to identify the particular virtio driver by * the subsytem ids */ vp_dev->vdev.id.vendor = pci_dev->subsystem_vendor; vp_dev->vdev.id.device = pci_dev->subsystem_device; it looks like only the device ID is used right now: # grep virtio modules.alias alias virtio:d00000001v* virtio_net alias virtio:d00000002v* virtio_blk alias virtio:d00000003v* virtio_console alias virtio:d00000004v* virtio-rng alias virtio:d00000005v* virtio_balloon alias pci:v00001AF4d*sv*sd*bc*sc*i* virtio_pci alias virtio:d00000009v* 9pnet_virtio so setting the subsystem vendor id to something != zero shouldn't cause trouble. Signed-off-by: Mark McLoughlin <markmc@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6440 c046a42c-6fe2-441c-8c8c-71466251a162
2009-01-26Add macro for virtio-console PCI device ID (Mark McLoughlin)aliguori1-1/+2
Also use the existing macro for the PCI vendor ID Signed-off-by: Mark McLoughlin <markmc@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6439 c046a42c-6fe2-441c-8c8c-71466251a162
2009-01-15Add missing files from last commit.aliguori1-0/+147
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6316 c046a42c-6fe2-441c-8c8c-71466251a162
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-27 03:02:14 +0000