Laszlo Ersek
2023-Feb-09 14:34 UTC
[Libguestfs] [PATCH] lib: Choose q35 machine type for x86-64
On 2/9/23 14:54, Daniel P. Berrang? wrote:> On Thu, Feb 09, 2023 at 01:45:33PM +0000, Richard W.M. Jones wrote: >> This machine type is more modern than the older 'pc' type and as most >> qemu development is now focused there we expect it will perform and >> behave better. In almost all respects this change should make no >> difference. > > The key differences with q35 that have caused problems for > apps in the past > > - CDROMs must use 'sata' bus not 'ide' > - PCI topology is completely different, so if you're > trying to associate between the host side view of > the config and the guest side view, your logic may > need adapting > - Hotplug of devices is limited to 1 device unless you > pre-create a bunch of pcie-root-port devices > > If you're already using 'virt' machine for aarch64 successfully > though, you should have already known about the last 2 points, > if they did indeed affect libguestfs. > > The first point could conceivably affect the way to detect > devices, depending on what approach is used, but could equally > be a non issue. > > I presume the libguestfs test suite would have complained if > there was any genuine problem with the change, since it is > pretty comphrensive.We still have a direct PCI address reference, after commit range 4af6d68e2d8b..5858c2cf6c24 (RH bug 2034160). It's only supposed to be used on a fallback (very old libvirt) path. I've not found anything similar in the direct backend. I think one thing we could do is compare appliance QEMU cmdlines before/after, and libvirt domain XMLs before/after. We might not catch the corner cases like that, but eventually we'll have to make the switch anyway, and I expect the corner cases will not be hard to fix once they pop up. Acked-by: Laszlo Ersek <lersek at redhat.com> Laszlo> >> >> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2168578 >> --- >> lib/guestfs-internal.h | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/lib/guestfs-internal.h b/lib/guestfs-internal.h >> index 07a2b9f617..4e9a103d78 100644 >> --- a/lib/guestfs-internal.h >> +++ b/lib/guestfs-internal.h >> @@ -128,6 +128,9 @@ cleanup_mutex_unlock (pthread_mutex_t **ptr) >> #define MAX_WINDOWS_EXPLORER_SIZE (4 * 1000 * 1000) >> >> /* Machine types. */ >> +#if defined(__x86_64__) >> +#define MACHINE_TYPE "q35" >> +#endif >> #ifdef __arm__ >> #define MACHINE_TYPE "virt" >> #endif >> -- >> 2.39.0 >> >> _______________________________________________ >> Libguestfs mailing list >> Libguestfs at redhat.com >> https://listman.redhat.com/mailman/listinfo/libguestfs >> > > With regards, > Daniel
Richard W.M. Jones
2023-Feb-09 14:41 UTC
[Libguestfs] [PATCH] lib: Choose q35 machine type for x86-64
On Thu, Feb 09, 2023 at 03:34:26PM +0100, Laszlo Ersek wrote:> On 2/9/23 14:54, Daniel P. Berrang? wrote: > > On Thu, Feb 09, 2023 at 01:45:33PM +0000, Richard W.M. Jones wrote: > >> This machine type is more modern than the older 'pc' type and as most > >> qemu development is now focused there we expect it will perform and > >> behave better. In almost all respects this change should make no > >> difference. > > > > The key differences with q35 that have caused problems for > > apps in the past > > > > - CDROMs must use 'sata' bus not 'ide' > > - PCI topology is completely different, so if you're > > trying to associate between the host side view of > > the config and the guest side view, your logic may > > need adapting > > - Hotplug of devices is limited to 1 device unless you > > pre-create a bunch of pcie-root-port devices > > > > If you're already using 'virt' machine for aarch64 successfully > > though, you should have already known about the last 2 points, > > if they did indeed affect libguestfs. > > > > The first point could conceivably affect the way to detect > > devices, depending on what approach is used, but could equally > > be a non issue. > > > > I presume the libguestfs test suite would have complained if > > there was any genuine problem with the change, since it is > > pretty comphrensive. > > We still have a direct PCI address reference, after commit range > 4af6d68e2d8b..5858c2cf6c24 (RH bug 2034160). It's only supposed to be > used on a fallback (very old libvirt) path. I've not found anything > similar in the direct backend. > > I think one thing we could do is compare appliance QEMU cmdlines > before/after, and libvirt domain XMLs before/after. We might not catch > the corner cases like that, but eventually we'll have to make the switch > anyway, and I expect the corner cases will not be hard to fix once they > pop up. > > Acked-by: Laszlo Ersek <lersek at redhat.com>I will add a link to this thread to the commit so we can reference it in case of any future problems. Rich.> Laszlo > > > > > >> > >> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2168578 > >> --- > >> lib/guestfs-internal.h | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/lib/guestfs-internal.h b/lib/guestfs-internal.h > >> index 07a2b9f617..4e9a103d78 100644 > >> --- a/lib/guestfs-internal.h > >> +++ b/lib/guestfs-internal.h > >> @@ -128,6 +128,9 @@ cleanup_mutex_unlock (pthread_mutex_t **ptr) > >> #define MAX_WINDOWS_EXPLORER_SIZE (4 * 1000 * 1000) > >> > >> /* Machine types. */ > >> +#if defined(__x86_64__) > >> +#define MACHINE_TYPE "q35" > >> +#endif > >> #ifdef __arm__ > >> #define MACHINE_TYPE "virt" > >> #endif > >> -- > >> 2.39.0 > >> > >> _______________________________________________ > >> Libguestfs mailing list > >> Libguestfs at redhat.com > >> https://listman.redhat.com/mailman/listinfo/libguestfs > >> > > > > With regards, > > Daniel-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html