aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)AuthorFilesLines
2019-01-17tpm: allocate/map buffer for TPM Physical Presence interfaceStefan Berger5-0/+82
Implement a virtual memory device for the TPM Physical Presence interface. The memory is located at 0xFED45000 and used by ACPI to send messages to the firmware (BIOS) and by the firmware to provide parameters for each one of the supported codes. This interface should be used by all TPM devices on x86 and can be added by calling tpm_ppi_init_io(). Note: bios_linker cannot be used to allocate the PPI memory region, since the reserved memory should stay stable across reboots, and might be needed before the ACPI tables are installed. Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-17tpm: add a "ppi" boolean propertyMarc-André Lureau3-0/+8
The following patches implement the TPM Physical Presence Interface, make use of a new memory region and a fw_cfg entry. Enable PPI by default with >=4.0 machine type, to avoid migration issues. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-17hw/misc/edu: add msi_uninit() for pci_edu_uninit()Fei Li1-0/+1
Let's supplement the msi_uninit() when failing to realize the pci edu device. Reported-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Fei Li <shirley17fei@gmail.com> Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-17virtio: Make disable-legacy/disable-modern compat properties optionalEduardo Habkost1-2/+3
The disable-legacy and disable-modern properties apply only to some virtio-pci devices. Make those properties optional. This fixes the crash introduced by commit f6e501a28ef9 ("virtio: Provide version-specific variants of virtio PCI devices"): $ qemu-system-x86_64 -machine pc-i440fx-2.6 \ -device virtio-net-pci-non-transitional Unexpected error in object_property_find() at qom/object.c:1092: qemu-system-x86_64: -device virtio-net-pci-non-transitional: can't apply \ global virtio-pci.disable-modern=on: Property '.disable-modern' not found Aborted (core dumped) Reported-by: Thomas Huth <thuth@redhat.com> Fixes: f6e501a28ef9 ("virtio: Provide version-specific variants of virtio PCI devices") Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-17virtio: split virtio crypto bits from virtio-pci.hJuan Quintela2-14/+14
Reviewed-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-17virtio: split virtio gpu bits from virtio-pci.hJuan Quintela3-14/+15
Reviewed-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-17virtio: split virtio serial bits from virtio-pciJuan Quintela4-93/+116
Virtio console and qga tests also depend on CONFIG_VIRTIO_SERIAL. Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-17virtio: split virtio net bits from virtio-pciJuan Quintela4-73/+99
Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-17virtio: split virtio blk bits from virtio-pciJuan Quintela4-75/+101
Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-17virtio: split virtio scsi bits from virtio-pciJuan Quintela4-85/+108
Notice that we can't still run tests with it disabled. Both cdrom-test and drive_del-test use virtio-scsi without checking if it is enabled. Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-17virtio: split vhost scsi bits from virtio-pciJuan Quintela4-80/+98
Reviewed-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-17virtio: split vhost user scsi bits from virtio-pciJuan Quintela4-71/+104
Reviewed-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-17virtio: split vhost user blk bits from virtio-pciJuan Quintela4-80/+104
Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-17virtio: split virtio 9p bits from virtio-pciJuan Quintela4-74/+89
Reviewed-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Acked-by: Greg Kurz <groug@kaod.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-17virtio: split virtio balloon bits from virtio-pciJuan Quintela4-74/+97
Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-17virtio: split virtio rng bits from virtio-pciJuan Quintela4-68/+89
Reviewed-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-17virtio: split virtio input bits from virtio-pciJuan Quintela4-135/+158
Reviewed-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-17virtio: split virtio input host bits from virtio-pciJuan Quintela4-37/+49
For consistency with other devices, rename virtio_host_{initfn,pci_info} to virtio_input_host_{initfn,info}. Reviewed-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-17virtio: split vhost vsock bits from virtio-pciJuan Quintela4-71/+89
Reviewed-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-17virtio-net: changed VIRTIO_NET_F_RSC_EXT to be 61Yuri Benditovich1-1/+1
Allocated feature bit changed in spec draft per TC request. Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-17virtio-net: support RSC v4/v6 tcp traffic for Windows HCKYuri Benditovich1-1/+666
This commit adds implementation of RX packets coalescing, compatible with requirements of Windows Hardware compatibility kit. The device enables feature VIRTIO_NET_F_RSC_EXT in host features if it supports extended RSC functionality as defined in the specification. This feature requires at least one of VIRTIO_NET_F_GUEST_TSO4, VIRTIO_NET_F_GUEST_TSO6. Windows guest driver acks this feature only if VIRTIO_NET_F_CTRL_GUEST_OFFLOADS is also present. If the guest driver acks VIRTIO_NET_F_RSC_EXT feature, the device coalesces TCPv4 and TCPv6 packets (if respective VIRTIO_NET_F_GUEST_TSO feature is on, populates extended RSC information in virtio header and sets VIRTIO_NET_HDR_F_RSC_INFO bit in header flags. The device does not recalculate checksums in the coalesced packet, so they are not valid. In this case: All the data packets in a tcp connection are cached to a single buffer in every receive interval, and will be sent out via a timer, the 'virtio_net_rsc_timeout' controls the interval, this value may impact the performance and response time of tcp connection, 50000(50us) is an experience value to gain a performance improvement, since the whql test sends packets every 100us, so '300000(300us)' passes the test case, it is the default value as well, tune it via the command line parameter 'rsc_interval' within 'virtio-net-pci' device, for example, to launch a guest with interval set as '500000': 'virtio-net-pci,netdev=hostnet1,bus=pci.0,id=net1,mac=00, guest_rsc_ext=on,rsc_interval=500000' The timer will only be triggered if the packets pool is not empty, and it'll drain off all the cached packets. 'NetRscChain' is used to save the segments of IPv4/6 in a VirtIONet device. A new segment becomes a 'Candidate' as well as it passed sanity check, the main handler of TCP includes TCP window update, duplicated ACK check and the real data coalescing. An 'Candidate' segment means: 1. Segment is within current window and the sequence is the expected one. 2. 'ACK' of the segment is in the valid window. Sanity check includes: 1. Incorrect version in IP header 2. An IP options or IP fragment 3. Not a TCP packet 4. Sanity size check to prevent buffer overflow attack. 5. An ECN packet Even though, there might more cases should be considered such as ip identification other flags, while it breaks the test because windows set it to the same even it's not a fragment. Normally it includes 2 typical ways to handle a TCP control flag, 'bypass' and 'finalize', 'bypass' means should be sent out directly, while 'finalize' means the packets should also be bypassed, but this should be done after search for the same connection packets in the pool and drain all of them out, this is to avoid out of order fragment. All the 'SYN' packets will be bypassed since this always begin a new' connection, other flags such 'URG/FIN/RST/CWR/ECE' will trigger a finalization, because this normally happens upon a connection is going to be closed, an 'URG' packet also finalize current coalescing unit. Statistics can be used to monitor the basic coalescing status, the 'out of order' and 'out of window' means how many retransmitting packets, thus describe the performance intuitively. Difference between ip v4 and v6 processing: Fragment length in ipv4 header includes itself, while it's not included for ipv6, thus means ipv6 can carry a real 65535 payload. Note that main goal of implementing this feature in software is to create reference setup for certification tests. In such setups guest migration is not required, so the coalesced packets not yet delivered to the guest will be lost in case of migration. Signed-off-by: Wei Xu <wexu@redhat.com> Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-14vhost-user: fix ioeventfd_enabledLi Qiang1-1/+1
Currently, the vhost-user-test assumes the eventfd is available. However it's not true because the accel is qtest. So the 'vhost_set_vring_file' will not add fds to the msg and the server side of vhost-user-test will be broken. The bug is in 'ioeventfd_enabled'. We should make this function return true if not using kvm accel. Signed-off-by: Li Qiang <liq3ea@163.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-14qemu: avoid memory leak while remove diskJian Wang3-4/+9
Memset vhost_dev to zero in the vhost_dev_cleanup function. This causes dev.vqs to be NULL, so that vqs does not free up space when calling the g_free function. This will result in a memory leak. But you can't release vqs directly in the vhost_dev_cleanup function, because vhost_net will also call this function, and vhost_net's vqs is assigned by array. In order to solve this problem, we first save the pointer of vqs, and release the space of vqs after vhost_dev_cleanup is called. Signed-off-by: Jian Wang <wangjian161@huawei.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-14hw/misc/ivshmem: Remove deprecated "ivshmem" legacy deviceThomas Huth2-206/+5
It's been marked as deprecated in QEMU v2.6.0 already, so really nobody should use the legacy "ivshmem" device anymore (but use ivshmem-plain or ivshmem-doorbell instead). Time to remove the deprecated device now. Belatedly also update a mention of the deprecated "ivshmem" in the file docs/specs/ivshmem-spec.txt to "ivshmem-doorbell". Missed in commit 5400c02b90b ("ivshmem: Split ivshmem-plain, ivshmem-doorbell off ivshmem"). Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-14msix: make pba size math more uniformDongli Zhang1-1/+1
In msix_exclusive_bar the bar_pba_size is more than what the pba is expected to have, although this never affects the bar size. Specifically, the math in msix_init_exclusive_bar allocates too much memory in some cases. For example consider nentries = 8. msix_exclusive_bar will give us bar_pba_size = 16. So 16 bytes. However 8 bytes would be enough - this is all that the spec requires. So in practice bar_pba_size sometimes allocates an extra 8 bytes but never more. Since each MSIX entry size is 16 bytes, and since we make sure that table+pba is a power of two, this always leaves a multiple of 16 bytes for the PBA, so extra 8 bytes have no effect. However, its ugly to have pba size temporary variable have an incorrect value. For consistency switch to the formula used in msix_init. Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-14pci/pcie: stop plug/unplug if the slot is lockedDavid Hildenbrand2-8/+18
We better stop right away. For now, errors would be partially ignored (so the guest might get informed or the device might get unplugged), although actual plug/unplug will be reported as failed to the user. While at it, properly move the check to the pre_plug handler for the plug case, as we can test the slot state before the device will be realized. Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-14Merge remote-tracking branch 'remotes/ehabkost/tags/x86-next-pull-request' ↵Peter Maydell1-0/+10
into staging x86 queue, 2019-01-14 * Reenable RDTSCP support on Opteron_G[345] CPU models CPU models (Borislav Petkov) * host-phys-bits-limit option for better control of 5-level EPT (Eduardo Habkost) * Disable MPX support on named CPU models (Paolo Bonzini) * expose HV_CPUID_ENLIGHTMENT_INFO.EAX and HV_CPUID_NESTED_FEATURES.EAX as feature words (Vitaly Kuznetsov) # gpg: Signature made Mon 14 Jan 2019 14:33:55 GMT # gpg: using RSA key 2807936F984DC5A6 # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost/tags/x86-next-pull-request: i386/kvm: add a comment explaining why .feat_names are commented out for Hyper-V feature bits x86: host-phys-bits-limit option target/i386: Disable MPX support on named CPU models target-i386: Reenable RDTSCP support on Opteron_G[345] CPU models CPU models i386/kvm: expose HV_CPUID_ENLIGHTMENT_INFO.EAX and HV_CPUID_NESTED_FEATURES.EAX as feature words Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-01-14target/i386: Disable MPX support on named CPU modelsPaolo Bonzini1-0/+7
MPX support is being phased out by Intel; GCC has dropped it, Linux is also going to do that. Even though KVM will have special code to support MPX after the kernel proper stops enabling it in XCR0, we probably also want to deprecate that in a few years. As a start, do not enable it by default for any named CPU model starting with the 4.0 machine types; this include Skylake, Icelake and Cascadelake. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20181220121100.21554-1-pbonzini@redhat.com> Reviewed-by:   Wainer dos Santos Moschetta <wainersm@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-01-14target-i386: Reenable RDTSCP support on Opteron_G[345] CPU models CPU modelsBorislav Petkov1-0/+3
The missing functionality was added ~3 years ago with the Linux commit 46896c73c1a4 ("KVM: svm: add support for RDTSCP") so reenable RDTSCP support on those CPU models. Opteron_G2 - being family 15, model 6, doesn't have RDTSCP support (the real hardware doesn't have it. K8 got RDTSCP support with the NPT models, i.e., models >= 0x40). Document the host's minimum required kernel version, while at it. Signed-off-by: Borislav Petkov <bp@suse.de> Message-ID: <20181212200803.GG6653@zn.tnic> [ehabkost: moved compat properties code to pc.c] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-01-14xen-block: avoid repeated memory allocationTim Smith1-5/+9
The xen-block dataplane currently allocates memory to hold the data for each request as that request is used, and frees it afterwards. Because it requires page-aligned blocks, this interacts poorly with non-page- aligned allocations and balloons the heap. Instead, allocate the maximum possible buffer size required for the protocol, which is BLKIF_MAX_SEGMENTS_PER_REQUEST (currently 11) pages when the request structure is created, and keep that buffer until it is destroyed. Since the requests are re-used via a free list, this should actually improve memory usage. Signed-off-by: Tim Smith <tim.smith@citrix.com> Re-based and commit comment adjusted. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-01-14xen-block: improve response latencyTim Smith1-38/+18
If the I/O ring is full, the guest cannot send any more requests until some responses are sent. Only sending all available responses just before checking for new work does not leave much time for the guest to supply new work, so this will cause stalls if the ring gets full. Also, not completing reads as soon as possible adds latency to the guest. To alleviate that, complete IO requests as soon as they come back. xen_block_send_response() already returns a value indicating whether a notify should be sent, which is all the batching we need. Signed-off-by: Tim Smith <tim.smith@citrix.com> Re-based and commit comment adjusted. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-01-14xen-block: improve batching behaviourTim Smith1-0/+35
When I/O consists of many small requests, performance is improved by batching them together in a single io_submit() call. When there are relatively few requests, the extra overhead is not worth it. This introduces a check to start batching I/O requests via blk_io_plug()/ blk_io_unplug() in an amount proportional to the number which were already in flight at the time we started reading the ring. Signed-off-by: Tim Smith <tim.smith@citrix.com> Re-based and commit comment adjusted. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-01-14xen: Replace few mentions of xend by libxlAnthony PERARD1-1/+1
xend have been replaced by libxenlight (libxl) for many Xen releases now. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org>
2019-01-14Remove broken Xen PV domain builderAnthony PERARD4-328/+0
It is broken since Xen 4.9 [1] and it will not build in Xen 4.12. Also, it is not built by default since QEMU 2.6. [1] https://lists.xenproject.org/archives/html/xen-devel/2018-09/msg00313.html Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org>
2019-01-14xen: remove the legacy 'xen_disk' backendPaul Durrant2-1012/+0
This backend has now been replaced by the 'xen-qdisk' XenDevice. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Anthony Perard <anthony.perard@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-01-14xen: automatically create XenBlockDevice-sPaul Durrant3-1/+379
This patch adds create and destroy function for XenBlockDevice-s so that they can be created automatically when the Xen toolstack instantiates a new PV backend via xenstore. When the XenBlockDevice is created this way it is also necessary to create a 'drive' which matches the configuration that the Xen toolstack has written into xenstore. This is done by formulating the parameters necessary for each 'blockdev' layer of the drive and then using qmp_blockdev_add() to create the layers. Also, for compatibility with the legacy 'xen_disk' implementation, an iothread is automatically created for the new XenBlockDevice. This, like the driver layers, will be destroyed after the XenBlockDevice is unrealized. The legacy backend scan for 'qdisk' is removed by this patch, which makes the 'xen_disk' code is redundant. The code will be removed by a subsequent patch. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-01-14xen: add a mechanism to automatically create XenDevice-s...Paul Durrant4-2/+332
...that maintains compatibility with existing Xen toolstacks. Xen toolstacks instantiate PV backends by simply writing information into xenstore and expecting a backend implementation to be watching for this. This patch adds a new 'xen-backend' module to allow individual XenDevice implementations to register create and destroy functions. The creator will be called when a tool-stack instantiates a new backend in this way, and the destructor will then be called after the resulting XenDevice object is unrealized. To support this it is also necessary to add new watchers into the XenBus implementation to handle enumeration of new backends and also destruction of XenDevice-s when the toolstack sets the backend 'online' key to 0. NOTE: This patch only adds the framework. A subsequent patch will add a creator function for xen-block devices. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Anthony Perard <anthony.perard@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-01-14xen: add implementations of xen-block connect and disconnect functions...Paul Durrant3-25/+331
...and wire in the dataplane. This patch adds the remaining code to make the xen-block XenDevice functional. The parameters that a block frontend expects to find are populated in the backend xenstore area, and the 'ring-ref' and 'event-channel' values specified in the frontend xenstore area are mapped/bound and used to set up the dataplane. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Anthony Perard <anthony.perard@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-01-14xen: purge 'blk' and 'ioreq' from function names in dataplane/xen-block.cPaul Durrant1-44/+46
This is a purely cosmetic patch that purges remaining use of 'blk' and 'ioreq' in local function names, and then makes sure all functions are prefixed with 'xen_block_'. No functional change. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Anthony Perard <anthony.perard@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-01-14xen: remove 'ioreq' struct/varable/field names from dataplane/xen-block.cPaul Durrant1-154/+156
This is a purely cosmetic patch that purges the name 'ioreq' from struct, variable and field names. (This name has been problematic for a long time as 'ioreq' is the name used for generic I/O requests coming from Xen). The patch replaces 'struct ioreq' with a new 'XenBlockRequest' type and 'ioreq' field/variable names with 'request', and then does necessary fix-up to adhere to coding style. Function names are not modified by this patch. They will be dealt with in a subsequent patch. No functional change. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Anthony Perard <anthony.perard@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-01-14xen: remove 'XenBlkDev' and 'blkdev' names from dataplane/xen-blockPaul Durrant2-171/+183
This is a purely cosmetic patch that substitutes the old 'struct XenBlkDev' name with 'XenBlockDataPlane' and 'blkdev' field/variable names with 'dataplane', and then does necessary fix-up to adhere to coding style. No functional change. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Anthony Perard <anthony.perard@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-01-14xen: add header and build dataplane/xen-block.cPaul Durrant3-100/+286
This patch adds the transformations necessary to get dataplane/xen-block.c to build against the new XenBus/XenDevice framework. MAINTAINERS is also updated due to the introduction of dataplane/xen-block.h. NOTE: Existing data structure names are retained for the moment. These will be modified by subsequent patches. A typedef for XenBlockDataPlane has been added to the header (based on the old struct XenBlkDev name for the moment) so that the old names don't need to leak out of the dataplane code. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Anthony Perard <anthony.perard@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-01-14xen: remove unnecessary code from dataplane/xen-block.cPaul Durrant1-406/+23
Not all of the code duplicated from xen_disk.c is required as the basis for the new dataplane implementation so this patch removes extraneous code, along with the legacy #includes and calls to the legacy xen_pv_printf() function. Error messages are changed to be reported using error_report(). NOTE: The code is still not yet built. Further transformations will be required to make it correctly interface to the new XenBus/XenDevice framework. They will be delivered in a subsequent patch. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Anthony Perard <anthony.perard@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-01-14xen: duplicate xen_disk.c as basis of dataplane/xen-block.cPaul Durrant1-0/+1019
The new xen-block XenDevice implementation requires the same core dataplane as the legacy xen_disk implementation it will eventually replace. This patch therefore copies the legacy xen_disk.c source module into a new dataplane/xen-block.c source module as the basis for the new dataplane and adjusts the MAINTAINERS file accordingly. NOTE: The duplicated code is not yet built. It is simply put into place by this patch (just fixing style violations) such that the modifications that will need to be made to the code are not conflated with code movement, thus making review harder. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Anthony Perard <anthony.perard@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-01-14xen: add event channel interface for XenDevice-sPaul Durrant1-0/+103
The legacy PV backend infrastructure provides functions to bind, unbind and send notifications to event channnels. Similar functionality will be required by XenDevice implementations so this patch adds the necessary support. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Anthony Perard <anthony.perard@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Patch squashed with: Patch "xen: add event channel interface for XenDevice-s" makes use of the type xenevtchn_port_or_error_t, but this isn't avaiable before Xen 4.7. Also the function xen_device_bind_event_channel assign the return value of xenevtchn_bind_interdomain to channel->local_port but check the result for error with xendev->local_port. Fix by: - removing local_port from struct XenDevice as it isn't use anywere. - adding a compatibility typedef for xenevtchn_port_or_error_t for Xen 4.6 and earlier. As extra, replace the type of XenEventChannel->local_port by evtchn_port_t. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
2019-01-14xen: add grant table interface for XenDevice-sPaul Durrant1-0/+146
The legacy PV backend infrastructure provides functions to map, unmap and copy pages granted by frontends. Similar functionality will be required by XenDevice implementations so this patch adds the necessary support. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Anthony Perard <anthony.perard@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-01-14xen: add xenstore watcher infrastructurePaul Durrant5-2/+321
A Xen PV frontend communicates its state to the PV backend by writing to the 'state' key in the frontend area in xenstore. It is therefore necessary for a XenDevice implementation to be notified whenever the value of this key changes. This patch adds code to do this as follows: - an 'fd handler' is registered on the libxenstore handle which will be triggered whenever a 'watch' event occurs - primitives are added to xen-bus-helper to add or remove watch events - a list of Notifier objects is added to XenBus to provide a mechanism to call the appropriate 'watch handler' when its associated event occurs The xen-block implementation is extended with a 'frontend_changed' method, which calls as-yet stub 'connect' and 'disconnect' functions when the relevant frontend state transitions occur. A subsequent patch will supply a full implementation for these functions. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Anthony Perard <anthony.perard@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-01-14xen: create xenstore areas for XenDevice-sPaul Durrant5-5/+489
This patch adds a new source module, xen-bus-helper.c, which builds on basic libxenstore primitives to provide functions to create (setting permissions appropriately) and destroy xenstore areas, and functions to 'printf' and 'scanf' nodes therein. The main xen-bus code then uses these primitives [1] to initialize and destroy the frontend and backend areas for a XenDevice during realize and unrealize respectively. The 'xen-block' implementation is extended with a 'get_name' method that returns the VBD number. This number is required to 'name' the xenstore areas. NOTE: An exit handler is also added to make sure the xenstore areas are cleaned up if QEMU terminates without devices being unrealized. [1] The 'scanf' functions are actually not yet needed, but they will be needed by code delivered in subsequent patches. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Anthony Perard <anthony.perard@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-01-14xen: introduce 'xen-block', 'xen-disk' and 'xen-cdrom'Paul Durrant3-0/+352
This patch adds new XenDevice-s: 'xen-disk' and 'xen-cdrom', both derived from a common 'xen-block' parent type. These will eventually replace the 'xen_disk' (note the underscore rather than hyphen) legacy PV backend but it is illustrative to build up the implementation incrementally, along with the XenBus/XenDevice framework. Subsequent patches will therefore add to these devices' implementation as new features are added to the framework. After this patch has been applied it is possible to instantiate new 'xen-disk' or 'xen-cdrom' devices with a single 'vdev' parameter, which accepts values adhering to the Xen VBD naming scheme [1]. For example, a command-line instantiation of a xen-disk can be done with an argument similar to the following: -device xen-disk,vdev=hda The implementation of the vdev parameter formulates the appropriate VBD number for use in the PV protocol. [1] https://xenbits.xen.org/docs/unstable/man/xen-vbd-interface.7.html Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Anthony Perard <anthony.perard@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-01-14xen: introduce new 'XenBus' and 'XenDevice' object hierarchyPaul Durrant5-1/+140
This patch adds the basic boilerplate for a 'XenBus' object that will act as a parent to 'XenDevice' PV backends. A new 'XenBridge' object is also added to connect XenBus to the system bus. The XenBus object is instantiated by a new xen_bus_init() function called from the same sites as the legacy xen_be_init() function. Subsequent patches will flesh-out the functionality of these objects. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Anthony Perard <anthony.perard@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>