Re: [libvirt PATCH] conf: ensure only one vgpu has ramfb enabled
On Fri, Apr 29, 2022 at 04:04:21PM -0500, Jonathon Jongsma wrote: Validate the domain configuration to ensure that if there are more than one vgpu assigned to a domain, only one of them has 'ramfb' enabled. This was never a supported configuration. QEMU failed confusingly when attempting to start a domain with this configuration. This change attempts to provide better information about the error. https://bugzilla.redhat.com/show_bug.cgi?id=2079760 Signed-off-by: Jonathon Jongsma Reviewed-by: Martin Kletzander signature.asc Description: PGP signature
Re: [libvirt PATCH 2/2] tests: don't set G_DEBUG=fatal-warnings on macOS
On Fri, Apr 29, 2022 at 01:05:42AM -0700, Andrea Bolognani wrote: On Thu, Apr 28, 2022 at 05:55:41PM +0100, Daniel P. Berrangé wrote: On Thu, Apr 28, 2022 at 08:33:46AM -0700, Andrea Bolognani wrote: > In other words, the current implementation of g_poll() on macOS > doesn't follow the contract defined by GLib itself. It seems to me > that this is a (fairly serious) bug in the library, no? It is significant, but long standing. GLib actually had this behaviour forever on macOS, but it regressed when Meson was introduced, until the recent fix. The question is whether efficiency trumps API semantics. Normally I'm heavily biased towards API semantics, but poll is a performance critical API, so it isn't so easy to declare we must workaround all the quirks. I filed a bug to raise the subject for discussion though https://gitlab.gnome.org/GNOME/glib/-/issues/2644 That's an excellent bug report! Thanks for spending time on it, and let's see where the upstream discussion leads :) Just so I don't sway the potential discussion in the issue to the wrong way, I'll ask here. Since BROKEN_POLL is used due to poll() on OS/X not behaving correctly with fds=NULL, nfds=0 [0], wouldn't it be possible to "fix" at least the internal calls to g_poll() which are done when running the main loop since they always have at least one FD (the eventfd used to signal the main loop [1])? I know it would not fix the problem, but it would at least workaround the part that is used the most, I presume. Martin [0] https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/gpoll.c#L59 [1] this is a presumption I did not find in the code, but I've seen in gdb and strace signature.asc Description: PGP signature
Release of libvirt-8.3.0
The 8.3.0 release of both libvirt and libvirt-python is tagged and signed tarballs and source RPMs are available at https://libvirt.org/sources/ https://libvirt.org/sources/python/ Thanks everybody who helped with this release by sending patches, reviewing, testing, or providing feedback. Your work is greatly appreciated. * Removed features * qemu: Remove support for QEMU < 3.1 In accordance with our platform support policy, the oldest supported QEMU version is now bumped from 2.11 to 3.1. * New features * qemu: Introduce support for virtio-iommu This IOMMU device can be used with both Q35 and ARM virt guests. Enjoy. Jirka
[PATCH] hw/nvme: deprecate the use-intel-id compatibility parameter
From: Klaus Jensen
Since version 5.2 commit 6eb7a071292a ("hw/block/nvme: change controller
pci id"), the emulated NVMe controller has defaulted to a non-Intel PCI
identifier.
Deprecate the compatibility parameter so we can get rid of it once and
for all.
Signed-off-by: Klaus Jensen
---
docs/about/deprecated.rst | 8
1 file changed, 8 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 896e5a97abbd..450f945ac25f 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -356,6 +356,14 @@ contains native support for this feature and thus use of
the option
ROM approach is obsolete. The native SeaBIOS support can be activated
by using ``-machine graphics=off``.
+``-device nvme,use-intel-id=on|off`` (since 7.1)
+
+
+The ``nvme`` device originally used a PCI Vendor/Device Identifier combination
+from Intel that was not properly allocated. Since version 5.2, the controller
+has used a properly allocated identifier. Deprecate the ``use-intel-id``
+machine compatibility parameter.
+
Block device options
--
2.35.1
[PATCH v2 2/5] hw/nvme: do not auto-generate eui64
From: Klaus Jensen
We cannot provide auto-generated unique or persistent namespace
identifiers (EUI64, NGUID, UUID) easily. Since 6.1, namespaces have been
assigned a generated EUI64 of the form "52:54:00:".
This is will be unique within a QEMU instance, but not globally.
Revert that this is assigned automatically and immediately deprecate the
compatibility parameter. Users can opt-in to this with the
`eui64-default=on` device parameter or set it explicitly with
`eui64=UINT64`.
Cc: libvir-list@redhat.com
Signed-off-by: Klaus Jensen
---
docs/about/deprecated.rst | 7 +++
hw/core/machine.c | 4 +++-
hw/nvme/ns.c | 2 +-
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 896e5a97abbd..c65faa5ab4ad 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -356,6 +356,13 @@ contains native support for this feature and thus use of
the option
ROM approach is obsolete. The native SeaBIOS support can be activated
by using ``-machine graphics=off``.
+``-device nvme-ns,eui64-default=on|off`` (since 7.1)
+
+
+In QEMU versions 6.1, 6.2 and 7.0, the ``nvme-ns`` generates an EUI-64
+identifer that is not globally unique. If an EUI-64 identifer is required, the
+user must set it explicitly using the ``nvme-ns`` device parameter ``eui64``.
+
Block device options
diff --git a/hw/core/machine.c b/hw/core/machine.c
index cb9bbc844d24..1e2108d95f11 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -37,7 +37,9 @@
#include "hw/virtio/virtio.h"
#include "hw/virtio/virtio-pci.h"
-GlobalProperty hw_compat_7_0[] = {};
+GlobalProperty hw_compat_7_0[] = {
+{ "nvme-ns", "eui64-default", "on"},
+};
const size_t hw_compat_7_0_len = G_N_ELEMENTS(hw_compat_7_0);
GlobalProperty hw_compat_6_2[] = {
diff --git a/hw/nvme/ns.c b/hw/nvme/ns.c
index af6504fad2d8..06a04131f192 100644
--- a/hw/nvme/ns.c
+++ b/hw/nvme/ns.c
@@ -641,7 +641,7 @@ static Property nvme_ns_props[] = {
DEFINE_PROP_SIZE("zoned.zrwas", NvmeNamespace, params.zrwas, 0),
DEFINE_PROP_SIZE("zoned.zrwafg", NvmeNamespace, params.zrwafg, -1),
DEFINE_PROP_BOOL("eui64-default", NvmeNamespace, params.eui64_default,
- true),
+ false),
DEFINE_PROP_END_OF_LIST(),
};
--
2.35.1
Re: [libvirt PATCH v3 00/16] Add QEMU "-display dbus" support
Hi On Wed, Dec 22, 2021 at 11:45 PM wrote: > From: Marc-André Lureau > > Hi, > > This series implements supports for the uQEMU "-display dbus" support, that > landed earlier this week for 7.0. > > By default, libvirt will start a private VM bus (sharing and reusing the > existing "vmstate" VM bus & code). > > The feature set should cover the needs to replace Spice as local client of > choice, > including 3daccel/dmabuf, audio, clipboard sharing, usb redirection, and > arbitrary > chardev/channels (for serial etc). > > The test Gtk4 client is also in progress, currently in development at > https://gitlab.com/marcandre.lureau/qemu-display/. A few dependencies, > such as > zbus, require an upcoming release. virt-viewer & boxes will need a port to > Gtk4 > to make use of the shared widget. > > Comments welcome, as we can still adjust the QEMU side etc. > 4 months later, the QEMU bits are now in the last release. This series has certainly bit rot. Could someone give it a review before I attempt rebasing? thanks > > thanks > > v3: after QEMU 7.0 dev cycle opening and merge > - rebased > - add 7.0 x86-64 capabilities (instead of tweaking 6.2) > - fix version annotations > > Marc-André Lureau (16): > qemu: add chardev-vdagent capability check > qemu: add -display dbus capability check > qemucapabilitiestest: Add x64 test data for the qemu-7.0 development > cycle > conf: add > qemu: start the D-Bus daemon for the display > qemu: add -display dbus support > virsh: refactor/split cmdDomDisplay() > virsh: report the D-Bus bus URI for domdisplay > conf: add support > qemu: add audio type 'dbus' > conf: add dbus > qemu: add dbus clipboard sharing > conf: add > qemu: add -chardev dbus support > qemu: add usbredir type 'dbus' > docs: document type dbus > > NEWS.rst | 7 +- > docs/formatdomain.rst |43 +- > docs/schemas/basictypes.rng | 7 + > docs/schemas/domaincommon.rng |71 + > src/bhyve/bhyve_command.c | 1 + > src/conf/domain_conf.c| 141 +- > src/conf/domain_conf.h|15 + > src/conf/domain_validate.c|41 +- > src/libxl/libxl_conf.c| 1 + > src/qemu/qemu_capabilities.c | 8 + > src/qemu/qemu_capabilities.h | 4 + > src/qemu/qemu_command.c |77 +- > src/qemu/qemu_domain.c| 1 + > src/qemu/qemu_driver.c|10 +- > src/qemu/qemu_extdevice.c |13 + > src/qemu/qemu_hotplug.c | 1 + > src/qemu/qemu_monitor_json.c |10 + > src/qemu/qemu_process.c |41 +- > src/qemu/qemu_validate.c |33 + > src/security/security_dac.c | 2 + > src/vmx/vmx.c | 1 + > .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 231 + > .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 237 + > tests/domaincapsdata/qemu_7.0.0.x86_64.xml| 231 + > .../caps_6.1.0.x86_64.xml | 1 + > .../caps_6.2.0.aarch64.xml| 1 + > .../caps_6.2.0.x86_64.xml | 1 + > .../caps_7.0.0.x86_64.replies | 37335 > .../caps_7.0.0.x86_64.xml | 3720 ++ > .../graphics-dbus-address.args|30 + > .../graphics-dbus-address.xml |35 + > .../qemuxml2argvdata/graphics-dbus-audio.args |33 + > .../qemuxml2argvdata/graphics-dbus-audio.xml |45 + > .../graphics-dbus-chardev.args|32 + > .../graphics-dbus-chardev.xml |43 + > .../graphics-dbus-clipboard.args |31 + > .../graphics-dbus-clipboard.xml |35 + > tests/qemuxml2argvdata/graphics-dbus-p2p.args |30 + > tests/qemuxml2argvdata/graphics-dbus-p2p.xml |33 + > .../graphics-dbus-usbredir.args |34 + > .../graphics-dbus-usbredir.xml|30 + > tests/qemuxml2argvdata/graphics-dbus.args |30 + > tests/qemuxml2argvdata/graphics-dbus.xml |33 + > tests/qemuxml2argvtest.c |22 + > .../graphics-dbus-address.xml | 1 + > .../graphics-dbus-audio.xml | 1 + > .../graphics-dbus-chardev.xml | 1 + > .../graphics-dbus-clipboard.xml | 1 + > .../qemuxml2xmloutdata/graphics-dbus-p2p.xml | 1 + > tests/qemuxml2xmloutdata/graphics-dbus.xml| 1 + > tests/qemuxml2xmltest.c |20 + > tools/virsh-domain.c | 366 +- > 52 files changed, 42981 insertions(+), 192 deletions(-) > create mode 100644
