- 21 11月, 2019 4 次提交
-
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 15 11月, 2019 1 次提交
-
-
由 Jonathon Jongsma 提交于
The 'ramfb' attribute provides a framebuffer to the guest that can be used as a boot display for the vgpu For example, the following configuration can be used to provide a vgpu with a boot display: <hostdev mode='subsystem' type='mdev' model='vfio-pci' display='on' ramfb='on'> <source> <address uuid='$UUID'/> </source> </hostdev> Reviewed-by: NCole Robinson <crobinso@redhat.com> Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
-
- 13 11月, 2019 2 次提交
-
-
由 Jiri Denemark 提交于
When a CPU definition wants to explicitly disable some features that are unknown to QEMU, we can safely drop them from the definition before starting QEMU. Naturally QEMU won't enable such features implicitly. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 07 11月, 2019 1 次提交
-
-
由 Andrea Bolognani 提交于
Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Tested-by: NAndrew Jones <drjones@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 21 10月, 2019 1 次提交
-
-
由 Peter Krempa 提交于
We don't allow such config in the schema but the code can handle that so add a test case supporting it. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 18 10月, 2019 2 次提交
-
-
由 Julio Faracco 提交于
This commit let QEMU command line define 'xres' and 'yres' properties if XML contains both properties from video model: based on resolution fields 'x' and 'y'. There is a conditional structure inside qemuDomainDeviceDefValidateVideo() that validates if video model supports this feature. This commit includes the necessary changes to cover resolution for 'video-qxl-resolution' test cases too. Reviewed-by: NCole Robinson <crobinso@redhat.com> Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
-
由 Julio Faracco 提交于
This commit adds resolution element with parameters 'x' and 'y' into video XML domain group definition. Both, properties were added into an element called 'resolution' and it was added inside 'model' element. They are set as optional. This element does not follow QEMU properties 'xres' and 'yres' format. Both HTML documentation and schema were changed too. This commit includes a simple test case to cover resolution for QEMU video models. The new XML format for resolution looks like: <model ...> <resolution x='800' y='600'/> </model> Reviewed-by: NCole Robinson <crobinso@redhat.com> Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
-
- 10 10月, 2019 2 次提交
-
-
由 Daniel Henrique Barboza 提交于
This patch adds the implementation of the ccf-assist pSeries feature, based on the QEMU_CAPS_MACHINE_PSERIES_CAP_CCF_ASSIST capability that was added in the previous patch. Reviewed-by: NCole Robinson <crobinso@redhat.com> Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Jonathon Jongsma 提交于
This device is a very simple framebuffer device supported by qemu that is mostly intended to use as a boot framebuffer in conjunction with a vgpu. However, there is also a standalone ramfb device that can be used as a primary display device and is useful for e.g. aarch64 guests where different memory mappings between the host and guest can prevent use of other devices with framebuffers such as virtio-vga. https://bugzilla.redhat.com/show_bug.cgi?id=1679680 describes the issues in more detail. Reviewed-by: NCole Robinson <crobinso@redhat.com> Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
-
- 07 10月, 2019 5 次提交
-
-
由 Peter Krempa 提交于
Commit fb973cfb added versioned test outputs for the above mentioned tests but didn't actually enable them. Fix that mistake and fix the output of the tsc-frequency test. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
The test data was modernized to use actual caps but commit 4dadcaa9 forgot to delete this test data. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
The last use was removed in 7b604379 when we deleted the old commandline parser. The argv generator tests are provided by: machine-aeskeywrap-on-caps machine-aeskeywrap-on-cap machine-aeskeywrap-off-caps machine-aeskeywrap-off-cap machine-deakeywrap-on-caps machine-deakeywrap-on-cap machine-deakeywrap-off-caps machine-deakeywrap-off-cap Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
The last use was removed in 7b604379 when we deleted the old commandline parser. The same functionality is tested by many tests for pseries guests. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
The last use was removed in 7b604379 when we deleted the old commandline parser. The same functionality is tested by 'serial-pty-chardev'. Signed-off-by: NPeter Krempa <pkrempa@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 02 10月, 2019 1 次提交
-
-
由 Pavel Mores 提交于
The way in which the qemu driver generates aliases for disks involves ignoring the partition number part of a target dev name. This means that all partitions of a block device and the device itself all end up with the same alias. If multiple such disks are specified in XML, the resulting name clash makes qemu invocation fail. Since attaching partitions to qemu VMs doesn't seem to make much sense anyway, disallow partitions in target specifications altogether. https://bugzilla.redhat.com/show_bug.cgi?id=1346265Signed-off-by: NPavel Mores <pmores@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 30 9月, 2019 1 次提交
-
-
由 Daniel P. Berrangé 提交于
The video private data was not initializing the vhostuser FD causing us to attempt to close FD 0 many times over. Fixes commit ca60ecfa Author: Marc-André Lureau <marcandre.lureau@redhat.com> Date: Mon Sep 23 14:44:36 2019 +0400 qemu: add qemuDomainVideoPrivate Since the test suite does not invoke qemuExtDevicesStart(), no vhost_user_fd will be present when generating test XML. To deal with this we can must a fake FD number. While the current XML is using FD == 0, we pick a very interesting number that's unlikely to be a real FD, so that we're more likely to see any mistakes closing the invalid FD. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 25 9月, 2019 5 次提交
-
-
由 Marc-André Lureau 提交于
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Marc-André Lureau 提交于
For each vhost-user GPUs, - build a socket chardev, and pass the vhost-user socket to it - build a vhost-user video device and associate it with the chardev Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Marc-André Lureau 提交于
vhost-user device doesn't have a virgl option, it is passed to the vhost-user-gpu helper process instead. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NCole Robinson <crobinso@redhat.com>
-
由 Marc-André Lureau 提交于
vhost-user-gpu helper takes --render-node option to specify on which GPU should the renderning be done. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Marc-André Lureau 提交于
Accept a new driver name attribute to specify usage of helper process, ex: <video> <driver name='vhostuser'/> <model type='virtio'/> </video> Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 19 9月, 2019 2 次提交
-
-
由 Michal Privoznik 提交于
The fact that qemu is capable -netdev socket is not enough to start a migratable domain. It also needs dbus-vmstate capability. Since there are already some qemu releases which have net-socket-dgram capability and don't have dbus-vmstate we need to check for dbus-vmstate. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
由 Michal Privoznik 提交于
This reverts commit 385543a5. I've mistakenly pushed wrong branch. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 18 9月, 2019 1 次提交
-
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 10 9月, 2019 2 次提交
-
-
由 Laine Stump 提交于
If managed='no', then the tap device must already exist, and setting of MAC address and online status (IFF_UP) is skipped. NB: we still set IFF_VNET_HDR and IFF_MULTI_QUEUE as appropriate, because those bits must be properly set in the TUNSETIFF we use to set the tap device name of the handle we've opened - if IFF_VNET_HDR has not been set and we set it the request will be honored even when running libvirtd unprivileged; if IFF_MULTI_QUEUE is requested to be different than how it was created, that will result in an error from the kernel. This means that you don't need to pay attention to IFF_VNET_HDR when creating the tap devices, but you *do* need to set IFF_MULTI_QUEUE if you're going to use multiple queues for your tap device. NB2: /dev/vhost-net normally has permissions 600, so it can't be opened by an unprivileged process. This would normally cause a warning message when using a virtio net device from an unprivileged libvirtd. I've found that setting the permissions for /dev/vhost-net permits unprivileged libvirtd to use vhost-net for virtio devices, but have no idea what sort of security implications that has. I haven't changed libvrit's code to avoid *attempting* to open /dev/vhost-net - if you are concerned about the security of opening up permissions of /dev/vhost-net (probably a good idea at least until we ask someone who knows about the code) then add <driver name='qemu'/> to the interface definition and you'll avoid the warning message. Note that virNetDevTapCreate() is the correct function to call in the case of an existing device, because the same ioctl() that creates a new tap device will also open an existing tap device. Resolves: https://bugzilla.redhat.com/1723367 (partially) Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Laine Stump 提交于
Although <interface type='ethernet'> has always been able to use an existing tap device, this is just a coincidence due to the fact that the same ioctl is used to create a new tap device or get a handle to an existing device. Even then, once we have the handle to the device, we still insist on doing extra setup to it (setting the MAC address and IFF_UP). That *might* be okay if libvirtd is running as a privileged process, but if libvirtd is running as an unprivileged user, those attempted modifications to the tap device will fail (yes, even if the tap is set to be owned by the user running libvirtd). We could avoid this if we knew that the device already existed, but as stated above, an existing device and new device are both accessed in the same manner, and anyway, we need to preserve existing behavior for those who are already using pre-existing devices with privileged libvirtd (and allowing/expecting libvirt to configure the pre-existing device). In order to cleanly support the idea of using a pre-existing and pre-configured tap device, this patch introduces a new optional attribute "managed" for the interface <target> element. This attribute is only valid for <interface type='ethernet'> (since all other interface types have mandatory config that doesn't apply in the case where we expect the tap device to be setup before we get it). The syntax would look something like this: <interface type='ethernet'> <target dev='mytap0' managed='no'/> ... </interface> This patch just adds managed to the grammar and parser for <target>, but has no functionality behind it. (NB: when managed='no' (the default when not specified is 'yes'), the target dev is always a name explicitly provided, so we don't auto-remove it from the config just because it starts with "vnet" (VIR_NET_GENERATED_TAP_PREFIX); this makes it possible to use the same pattern of names that libvirt itself uses when it automatically creates the tap devices.) Signed-off-by: NLaine Stump <laine@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 09 9月, 2019 2 次提交
-
-
由 Shivaprasad G Bhat 提交于
There are already good number of test cases with hostdevices, few have multifunction devices but none having more than one than one multifunction cards. This patch adds a case where there are two multifunction cards and two Virtual functions part of the same XML. 0001:01:00.X & 0005:09:00.X - are Multifunction PCI cards. 0000:06:12.[5|6] - are SRIOV Virtual functions Future commits will improve on automatically detecting the multifunction cards and auto-assinging the addresses appropriately. Reviewed-by: NMichal Privoznik <mprivozn@redhat.com> Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com> Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
-
由 Shivaprasad G Bhat 提交于
The softlink to physfn is the way to know if the device is VF or not. So, the patch softlinks 'physfn' to the parent function. The multifunction PCI devices dont have 'physfn' softlinks. The patch adds few Virtual functions to the mock environment and changes the existing VFIO test xmls using the VFs to use the newly added VFs for their use case. Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com> Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 06 9月, 2019 3 次提交
-
-
由 Marc-André Lureau 提交于
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Marc-André Lureau 提交于
It is failing, because it ends up being parsed with version='default' and expects '1.2' instead. Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jonathon Jongsma 提交于
After parsing a video device with a model type of VIR_DOMAIN_VIDEO_TYPE_NONE, all device info is cleared (see virDomainDefPostParseVideo()) in order to avoid formatting any auto-generated values for the XML. Subsequently, however, an alias is generated for the video device (e.g. 'video0'), which results in an alias property being formatted in the XML output anyway. This creates confusion if the user has explicitly provided an alias for the video device since the alias will change. To avoid this, don't clear the user-defined alias for video devices of type "none". https://bugzilla.redhat.com/show_bug.cgi?id=1720612Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com> Reviewed-by: NErik Skultety <eskultet@redhat.com>
-
- 28 8月, 2019 3 次提交
-
-
由 Boris Fiuczynski 提交于
Add support to specify a boot order on vfio-ccw passthrough devices. Reviewed-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by: NBjoern Walk <bwalk@linux.ibm.com> Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Boris Fiuczynski 提交于
Adding a failure test for booting from a vhost scsi hostdev device. Reviewed-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by: NBjoern Walk <bwalk@linux.ibm.com> Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Boris Fiuczynski 提交于
Reviewed-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by: NBjoern Walk <bwalk@linux.ibm.com> Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Signed-off-by: NJán Tomko <jtomko@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 19 8月, 2019 2 次提交
-
-
由 Vitaly Kuznetsov 提交于
QEMU-4.1 supports 'Direct Mode' for Hyper-V synthetic timers (hv-stimer-direct CPU flag): Windows guests can request that timer expiration notifications are delivered as normal interrupts (and not VMBus messages). This is used by Hyper-V on KVM. Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Vitaly Kuznetsov 提交于
In particular, use DO_TEST_CAPS_LATEST which tests the canonical 'hv-feature' syntax instead of 'hv_feature' aliases and DO_TEST_CAPS_VER with 4.0.0 to also test the old syntax. Suggested-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-