Re: Regression in v7.2.10 - ui-dbus.so requires -fPIC
Mon, 18 Mar 2024 11:35:54 +0400 Marc-André Lureau : > Alternatively, we could always build with pic: true (or pic: > enable_modules), but that's not ideal either. I'm sure that unconditionally building with -fPIC has no downsides in this context. Olaf pgpGUQPNKGONs.pgp Description: Digitale Signatur von OpenPGP
Re: Regression in v7.2.10 - ui-dbus.so requires -fPIC
Sat, 16 Mar 2024 22:40:14 +0300 Michael Tokarev : > meson: ensure dbus-display generated code is built before other units > (cherry picked from commit 1222070e772833c6875e0ca63565db12c22df39e) "static_library" is used often. Some use the 'pic' option, which fixes the issue. I think every usage that ends up in a shared library requires 'pic:true'. Olaf pgpFRuboYgLKH.pgp Description: Digitale Signatur von OpenPGP
Regression in v7.2.10 - ui-dbus.so requires -fPIC
ui-dbus.so is a shared library. But it is apparently handled differently than all the other shared libraries: it is not compiled with -fPIC. As a result it fails to link. Not sure why this happens only here. Everything up to v7.2.9 was fine. Looking at some random other library like libui-spice-core.a, every object is compiled with -fPIC. But ui/dbus-display1.c is compiled with -fPIE instead. Is this intentional? Olaf ld: ui/libdbus-display1.a.p/meson-generated_.._dbus-display1.c.o: warning: relocation against `qemu_dbus_display1_audio_get_type' in read-only section `.text' pgpwtSSADV5iy.pgp Description: Digitale Signatur von OpenPGP
Re: [Stable-8.1.2 00/45] Patch Round-up for stable 8.1.2, freeze on 2023-10-14
Wed, 4 Oct 2023 11:44:53 +0300 Michael Tokarev : > Second, this is not even the production code, it is testing code. I need to double check if there is indeed a way to omit this code. A quick search indicates that disabling TCG may be required. > And the most important, third: even with the warning being emitted, 8.1 is > still > usable on openSUSE Tumbleweed: all qemu released tarballs are built WITHOUT > -Werror option, so when building a release there, these warnings wont fail the > build. Currently, this is controlled by presence of .git in the top-level > source dir, -Werror is only enabled if .git is present. The failure comes from outside, Werror=return-type in CFLAGS, not from QEMU's built-in Werror. Olaf pgpeFAwYOEkBO.pgp Description: Digitale Signatur von OpenPGP
Re: [Stable-8.1.2 00/45] Patch Round-up for stable 8.1.2, freeze on 2023-10-14
Wed, 4 Oct 2023 11:01:21 +0300 Michael Tokarev : > Please respond here or CC qemu-sta...@nongnu.org on any additional patches > you think should (or shouldn't) be included in the release. How about this change for 8.1.x? This will allow usage in openSUSE Tumbleweed. c01196bddd subprojects/berkeley-testfloat-3: Update to fix a problem with compiler warnings Olaf pgpgLkLRCIHDC.pgp Description: Digitale Signatur von OpenPGP
[PATCH v1] roms: use PYTHON to invoke python
python3 may not be the expected python version.
Use PYTHON to invoke python.
Fixes: 22e11539e1 ("edk2: replace build scripts")
Signed-off-by: Olaf Hering
---
roms/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/roms/Makefile b/roms/Makefile
index 6859685290..67f709ba2d 100644
--- a/roms/Makefile
+++ b/roms/Makefile
@@ -147,7 +147,7 @@ skiboot:
cp skiboot/skiboot.lid ../pc-bios/skiboot.lid
efi:
- python3 edk2-build.py --config edk2-build.config \
+ $(PYTHON) edk2-build.py --config edk2-build.config \
--version-override "edk2-stable202302-for-qemu" \
--release-date "03/01/2023"
rm -f ../pc-bios/edk2-*.fd.bz2
base-commit: 36e9aab3c569d4c9ad780473596e18479838d1aa
Re: [PATCH] subprojects/berkeley-testfloat-3: Update to fix a problem with compiler warnings
Wed, 16 Aug 2023 14:49:07 +0200 Philippe Mathieu-Daudé : > Why the default is with 7 and not 3 or 5? > Shouldn't we abort() or mark with __builtin_unreachable()? In the referenced bug it was suggested to add a trailing "unreachable". But suggestion arrived after my MR, and I'm also not sure if there is a way to implement it for all supported compilers. Olaf pgp6k9ECi3rG9.pgp Description: Digitale Signatur von OpenPGP
Re: [PULL 0/5] Misc fixes, for thread-pool, xen, and xen-emulate
Wed, 2 Aug 2023 18:18:01 +0300 Michael Tokarev : > Or if whole thing makes no sense to backport to stable, please > let me know as well. The xen-platform change does not need to be backported IMHO. Olaf pgpcgqotx9y5h.pgp Description: Digitale Signatur von OpenPGP
Re: [Stable-8.0.4 00/31] Patch Round-up for stable 8.0.4, freeze on 2023-08-05
Wed, 26 Jul 2023 13:12:43 +0300 Michael Tokarev : > This one is included in 8.0.3 and 7.2.4 already, picked up for the previous > stable series/releases. Indeed. I just noticed I still had 8.0.2 exported, sorry for the noise. Olaf pgpk0hLzJTvpI.pgp Description: Digitale Signatur von OpenPGP
Re: [Stable-8.0.4 00/31] Patch Round-up for stable 8.0.4, freeze on 2023-08-05
Tue, 25 Jul 2023 16:45:17 +0300 Michael Tokarev :
> Please respond here or CC qemu-sta...@nongnu.org on any additional patches
> you think should (or shouldn't) be included in the release.
Consider 497fad38979c16b6412388927401e577eba43d26 ("pc-bios/keymaps: Use the
official xkb name for Arabic layout, not the legacy synonym").
Otherwise it will start to FTBFS in Tumbleweed from now on.
Olaf
pgpzyW9ApUjPS.pgp
Description: Digitale Signatur von OpenPGP
Re: 8.1-rc0 testfloat fails to compile
Sat, 22 Jul 2023 13:49:40 +0100 Richard Henderson : > If this is with optimization enabled, the bug should be reported to gcc > bugzilla. > The compiler should easily prove the default case is unreachable. This happens also with -O0 or without any -On, or without -Wall. https://bugzilla.suse.com/show_bug.cgi?id=1213600 https://gitlab.com/qemu-project/berkeley-testfloat-3/-/merge_requests/2 Olaf pgpetlyLwb7EN.pgp Description: Digitale Signatur von OpenPGP
Re: 8.1-rc0 testfloat fails to compile
Fri, 21 Jul 2023 09:53:51 +0200 Thomas Huth : > I thought that -Wreturn-type would be part of > -Wall, but apparently it is only enabled by default for C++ in my version of > GCC :-( Hopefully gcc14 will fix that, and others. Only two decades late ... Olaf pgpx3QdBimJAf.pgp Description: Digitale Signatur von OpenPGP
Re: 8.1-rc0 testfloat fails to compile
Fri, 21 Jul 2023 09:18:08 +0200 Thomas Huth : > Or are you compiling with -O0 or something similar? Does the master branch compile for you with 'export CFLAGS="-O2 -Wall -Werror=return-type"'? I prepared a patch to deal with it, and indeed it looks like the compiler might be able to spot the fact that only values between 0 and 7 can ever appear there. Apparently it fails to recognize that. Olaf pgpf8MtewCTaw.pgp Description: Digitale Signatur von OpenPGP
Re: 8.1-rc0 testfloat fails to compile
Fri, 21 Jul 2023 08:54:21 +0200 Thomas Huth : > Which compiler version is causing trouble for you? Right now it is gcc 13, hopefully every compiler will error out with -Werror=return-type. I think it makes sense to replace Leap with Tumbleweed. We already know it compiles fine with Leap, because the submission compiled fine on the submitters laptop. Where is the repository that needs to be adjusted to make this replacement? Olaf pgpSHAJeqbTxh.pgp Description: Digitale Signatur von OpenPGP
8.1-rc0 testfloat fails to compile
This is going on since a few weeks. I guess there is no check in CI to see if qemu.git#master compiles in Tumbleweed. Since the switch to meson submodules, berkeley-testfloat-3 became mandatory. I think in the past I was able to ignore this submodule and not export it, so the following error did not show up: [ 141s] ../subprojects/berkeley-testfloat-3/source/genCases_f64.c: In function 'f64Random': [ 141s] ../subprojects/berkeley-testfloat-3/source/genCases_f64.c:559:1: error: control reaches end of non-void function [-Werror=return-type] [ 141s] 559 | } [ 141s] | ^ [ 141s] cc1: some warnings being treated as errors Apparently this is a known issue, 3ac1f81329f attempted to ignore such errors. Do I need to tweak the global, system-provided CFLAGS myself, or can the source be fixed to address this? Disabling this error globally will hide errors elsewhere. Maybe there is a way to append something to tests/fp/meson.build:libtestfloat.c_args? Right now it is apparently set to tfcflags+fpcflags+CFLAGS. Olaf pgpWS1pTvCXHa.pgp Description: Digitale Signatur von OpenPGP
[PATCH v1] xen-platform: do full PCI reset during unplug of IDE devices
The IDE unplug function needs to reset the entire PCI device, to make
sure all state is initialized to defaults. This is done by calling
pci_device_reset, which resets not only the chip specific registers, but
also all PCI state. This fixes "unplug" in a Xen HVM domU with the
modular legacy xenlinux PV drivers.
Commit ee358e919e38 ("hw/ide/piix: Convert reset handler to
DeviceReset") changed the way how the the disks are unplugged. Prior
this commit the PCI device remained unchanged. After this change,
piix_ide_reset is exercised after the "unplug" command, which was not
the case prior that commit. This function resets the command register.
As a result the ata_piix driver inside the domU will see a disabled PCI
device. The generic PCI code will reenable the PCI device. On the qemu
side, this runs pci_default_write_config/pci_update_mappings. Here a
changed address is returned by pci_bar_address, this is the address
which was truncated in piix_ide_reset. In case of a Xen HVM domU, the
address changes from 0xc120 to 0xc100. This truncation was a bug in
piix_ide_reset, which was fixed in commit 230dfd9257 ("hw/ide/piix:
properly initialize the BMIBA register"). If pci_xen_ide_unplug had used
pci_device_reset, the PCI registers would have been properly reset, and
commit ee358e919e38 would have not introduced a regression for this
specific domU environment.
While the unplug is supposed to hide the IDE disks, the changed BMIBA
address broke the UHCI device. In case the domU has an USB tablet
configured, to recive absolute pointer coordinates for the GUI, it will
cause a hang during device discovery of the partly discovered USB hid
device. Reading the USBSTS word size register will fail. The access ends
up in the QEMU piix-bmdma device, instead of the expected uhci device.
Here a byte size request is expected, and a value of ~0 is returned. As
a result the UCHI driver sees an error state in the register, and turns
off the UHCI controller.
Signed-off-by: Olaf Hering
---
hw/i386/xen/xen_platform.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c
index 57f1d742c1..17457ff3de 100644
--- a/hw/i386/xen/xen_platform.c
+++ b/hw/i386/xen/xen_platform.c
@@ -164,8 +164,9 @@ static void pci_unplug_nics(PCIBus *bus)
*
* [1]
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/hvm-emulated-unplug.pandoc
*/
-static void pci_xen_ide_unplug(DeviceState *dev, bool aux)
+static void pci_xen_ide_unplug(PCIDevice *d, bool aux)
{
+DeviceState *dev = DEVICE(d);
PCIIDEState *pci_ide;
int i;
IDEDevice *idedev;
@@ -195,7 +196,7 @@ static void pci_xen_ide_unplug(DeviceState *dev, bool aux)
blk_unref(blk);
}
}
-device_cold_reset(dev);
+pci_device_reset(d);
}
static void unplug_disks(PCIBus *b, PCIDevice *d, void *opaque)
@@ -210,7 +211,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d, void
*opaque)
switch (pci_get_word(d->config + PCI_CLASS_DEVICE)) {
case PCI_CLASS_STORAGE_IDE:
-pci_xen_ide_unplug(DEVICE(d), aux);
+pci_xen_ide_unplug(d, aux);
break;
case PCI_CLASS_STORAGE_SCSI:
Re: [PATCH v2] hw/ide/piix: properly initialize the BMIBA register
Mon, 17 Jul 2023 08:46:16 + Bernhard Beschow : > The PIIX fix alone just fixes the syptom, not the underlying problem. The > underlying problem is that the BAR isn't deactivated, and with the PIIX patch > it will stay at address zero rather than in the USB function address range. Did you mean to say USB will not work now? It actually does with just 230dfd9257 backported to v4.2+. Either way, I will test and send the additional change for pci_xen_ide_unplug in the next days. Olaf pgpnkmmqXFwfp.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH v2] hw/ide/piix: properly initialize the BMIBA register
Mon, 17 Jul 2023 08:46:16 + Bernhard Beschow : > Would you mind sending this patch as well? Sure, I was waiting for the other change to appear in the master branch, so I can reference it in the new commit message. Olaf pgpICjazXPmwt.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH] roms: add back edk2-basetools target
Tue, 11 Apr 2023 12:17:09 +0200 Gerd Hoffmann : > +++ b/roms/Makefile > +edk2-basetools: > + python3 edk2-build.py --config edk2-build.config -m none I think that needs to be $(PYTHON), because plain 'python3' may not be the required python version. In addition, a global EDK2_OPTIONS may allow to pass arbitrary options to their build wrapper, like -j1. Olaf pgpbNNpw_rOSl.pgp Description: Digitale Signatur von OpenPGP
[PATCH v3] hw/ide/piix: properly initialize the BMIBA register
According to the 82371FB documentation (82371FB.pdf, 2.3.9. BMIBA-BUS
MASTER INTERFACE BASE ADDRESS REGISTER, April 1997), the register is
32bit wide. To properly reset it to default values, all 32bit need to be
cleared. Bit #0 "Resource Type Indicator (RTE)" needs to be enabled.
The initial change wrote just the lower 8 bit, leaving parts of the "Bus
Master Interface Base Address" address at bit 15:4 unchanged.
Fixes: e6a71ae327 ("Add support for 82371FB (Step A1) and Improved support for
82371SB (Function 1)")
Signed-off-by: Olaf Hering
Reviewed-by: Bernhard Beschow
---
hw/ide/piix.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index 151f206046..4e5e12935f 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -117,7 +117,7 @@ static void piix_ide_reset(DeviceState *dev)
pci_set_word(pci_conf + PCI_COMMAND, 0x);
pci_set_word(pci_conf + PCI_STATUS,
PCI_STATUS_DEVSEL_MEDIUM | PCI_STATUS_FAST_BACK);
-pci_set_byte(pci_conf + 0x20, 0x01); /* BMIBA: 20-23h */
+pci_set_long(pci_conf + 0x20, 0x1); /* BMIBA: 20-23h */
}
static bool pci_piix_init_bus(PCIIDEState *d, unsigned i, Error **errp)
base-commit: 887cba855bb6ff4775256f7968409281350b568c
prerequisite-patch-id: daed167f888bd89b010a2e890e3edd97872cfc05
prerequisite-patch-id: 532640812ba7cd0303414c77450923f6abcb5119
prerequisite-patch-id: abf2f4ed52b072599c49d993de902e6dd7f2b560
Re: [PATCH v2] hw/ide/piix: properly initialize the BMIBA register
Wed, 05 Jul 2023 21:52:05 + Bernhard Beschow : > I wonder if we should fix this line rather than dropping it. I think this needs to be fixed, just to fix the initial commit which added this bug. This will allow backporting this oneliner. Further changes to pci_xen_ide_unplug will be done in a separate patch. Olaf pgp0IOAhN2vOv.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH v2] hw/ide/piix: properly initialize the BMIBA register
Tue, 4 Jul 2023 08:38:33 +0200 Paolo Bonzini :
> I agree that calling pci_device_reset() would be a better match for
> pci_xen_ide_unplug().
This change works as well:
--- a/hw/i386/xen/xen_platform.c
+++ b/hw/i386/xen/xen_platform.c
@@ -164,8 +164,9 @@ static void pci_unplug_nics(PCIBus *bus)
*
* [1]
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/hvm-emulated-unplug.pandoc
*/
-static void pci_xen_ide_unplug(DeviceState *dev, bool aux)
+static void pci_xen_ide_unplug(PCIDevice *d, bool aux)
{
+DeviceState *dev = DEVICE(d);
PCIIDEState *pci_ide;
int i;
IDEDevice *idedev;
@@ -195,7 +196,7 @@ static void pci_xen_ide_unplug(DeviceState *dev, bool aux)
blk_unref(blk);
}
}
-device_cold_reset(dev);
+pci_device_reset(d);
}
static void unplug_disks(PCIBus *b, PCIDevice *d, void *opaque)
@@ -210,7 +211,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d, void
*opaque)
switch (pci_get_word(d->config + PCI_CLASS_DEVICE)) {
case PCI_CLASS_STORAGE_IDE:
-pci_xen_ide_unplug(DEVICE(d), aux);
+pci_xen_ide_unplug(d, aux);
break;
case PCI_CLASS_STORAGE_SCSI:
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -118,7 +118,6 @@ static void piix_ide_reset(DeviceState *dev)
pci_set_word(pci_conf + PCI_COMMAND, 0x);
pci_set_word(pci_conf + PCI_STATUS,
PCI_STATUS_DEVSEL_MEDIUM | PCI_STATUS_FAST_BACK);
-pci_set_byte(pci_conf + 0x20, 0x01); /* BMIBA: 20-23h */
}
static bool pci_piix_init_bus(PCIIDEState *d, unsigned i, Error **errp)
Olaf
pgpkjwqzOkjC0.pgp
Description: Digitale Signatur von OpenPGP
Re: [PATCH v2] hw/ide/piix: properly initialize the BMIBA register
Sun, 02 Jul 2023 22:18:50 + Bernhard Beschow : > Do you know if that command calls pci_device_reset() (which would eventually > call piix_ide_reset())? The function is pci_xen_ide_unplug, which calls device_cold_reset. Olaf pgpcLzDeO7ZPB.pgp Description: Digitale Signatur von OpenPGP
[PATCH v2] hw/ide/piix: properly initialize the BMIBA register
According to the 82371FB documentation (82371FB.pdf, 2.3.9. BMIBA—BUS
MASTER INTERFACE BASE ADDRESS REGISTER, April 1997), the register is
32bit wide. To properly reset it to default values, all 32bit need to be
cleared. Bit #0 "Resource Type Indicator (RTE)" needs to be enabled.
The initial change wrote just the lower 8 bit, leaving parts of the "Bus
Master Interface Base Address" address at bit 15:4 unchanged.
This bug went unnoticed until commit ee358e919e38 ("hw/ide/piix: Convert
reset handler to DeviceReset"). After this change, piix_ide_reset is
exercised after the "unplug" command from a Xen HVM domU, which was not
the case prior that commit. This function resets the command register.
As a result the ata_piix driver inside the domU will see a disabled PCI
device. The generic PCI code will reenable the PCI device. On the qemu
side, this runs pci_default_write_config/pci_update_mappings. Here a
changed address is returned by pci_bar_address, this is the address
which was truncated in piix_ide_reset. In case of a Xen HVM domU, the
address changes from 0xc120 to 0xc100.
While the unplug is supposed to hide the IDE disks, the changed BMIBA
address breaks the UHCI device. In case the domU has an USB tablet
configured, to recive absolute pointer coordinates for the GUI, it will
cause a hang during device discovery of the partly discovered USB hid
device. Reading the USBSTS word size register will fail. The access ends
up in the QEMU piix-bmdma device, instead of the expected uhci device.
Here a byte size request is expected, and a value of ~0 is returned. As
a result the UCHI driver sees an error state in the register, and turns
off the UHCI controller.
Fixes: e6a71ae327 ("Add support for 82371FB (Step A1) and Improved support for
82371SB (Function 1)")
Signed-off-by: Olaf Hering
---
hw/ide/piix.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index 41d60921e3..1e346b1b1d 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -118,7 +118,7 @@ static void piix_ide_reset(DeviceState *dev)
pci_set_word(pci_conf + PCI_COMMAND, 0x);
pci_set_word(pci_conf + PCI_STATUS,
PCI_STATUS_DEVSEL_MEDIUM | PCI_STATUS_FAST_BACK);
-pci_set_byte(pci_conf + 0x20, 0x01); /* BMIBA: 20-23h */
+pci_set_long(pci_conf + 0x20, 0x01); /* BMIBA: 20-23h */
}
static bool pci_piix_init_bus(PCIIDEState *d, unsigned i, Error **errp)
base-commit: d145c0da22cde391d8c6672d33146ce306e8bf75
Re: [PATCH v1] hw/ide/piix: properly initialize the BMIBA register
Sat, 1 Jul 2023 15:34:40 +0200 (CEST) BALATON Zoltan : > If all 32 bits should be writtern does this need pci_set_long instead of > pci_set_word? Thanks for spotting. After a number of experiments I used the wrong variant. Olaf pgpCw5bEslAgv.pgp Description: Digitale Signatur von OpenPGP
[PATCH v1] hw/ide/piix: properly initialize the BMIBA register
According to the 82371FB documentation (82371FB.pdf, 2.3.9. BMIBA—BUS
MASTER INTERFACE BASE ADDRESS REGISTER, April 1997), the register is
32bit wide. To properly reset it to default values, all 32bit need to be
cleared. Bit #1 "Resource Type Indicator (RTE)" needs to be enabled.
The initial change wrote just the lower 8 bit, leaving parts of the "Bus
Master Interface Base Address" address at bit 15:4 unchanged.
This bug went unnoticed until commit ee358e919e38 ("hw/ide/piix: Convert
reset handler to DeviceReset"). After this change, piix_ide_reset is
exercised after the "unplug" command from a Xen HVM domU, which was not
the case prior that commit. This function resets the command register.
As a result the ata_piix driver inside the domU will see a disabled PCI
device. The generic PCI code will reenable the PCI device. On the qemu
side, this runs pci_default_write_config/pci_update_mappings. Here a
changed address is returned by pci_bar_address, this is the address
which was truncated in piix_ide_reset. In case of a Xen HVM domU, the
address changes from 0xc120 to 0xc100.
While the unplug is supposed to hide the IDE disks, the changed BMIBA
address breaks the UHCI device. In case the domU has an USB tablet
configured, to recive absolute pointer coordinates for the GUI, it will
cause a hang during device discovery of the partly discovered USB hid
device. Reading the USBSTS word size register will fail. The access ends
up in the QEMU piix-bmdma device, instead of the expected uhci device.
Here a byte size request is expected, and a value of ~0 is returned. As
a result the UCHI driver sees an error state in the register, and turns
off the UHCI controller.
Fixes: e6a71ae327 ("Add support for 82371FB (Step A1) and Improved support for
82371SB (Function 1)")
Signed-off-by: Olaf Hering
---
hw/ide/piix.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index 41d60921e3..6449ba8b6b 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -118,7 +118,7 @@ static void piix_ide_reset(DeviceState *dev)
pci_set_word(pci_conf + PCI_COMMAND, 0x);
pci_set_word(pci_conf + PCI_STATUS,
PCI_STATUS_DEVSEL_MEDIUM | PCI_STATUS_FAST_BACK);
-pci_set_byte(pci_conf + 0x20, 0x01); /* BMIBA: 20-23h */
+pci_set_word(pci_conf + 0x20, 0x01); /* BMIBA: 20-23h */
}
static bool pci_piix_init_bus(PCIIDEState *d, unsigned i, Error **errp)
base-commit: d145c0da22cde391d8c6672d33146ce306e8bf75
Re: [PATCH v2] piix: fix regression during unplug in Xen HVM domUs
Fri, 30 Jun 2023 08:05:29 + Bernhard Beschow : > Yes. Have a look for piix3/piix4 here: > https://www.intel.com/design/archives/chipsets/440/index.htm This is hidden behind a login or whatever. I should be able to come up with a commit message without hardware specs being available. Olaf pgpGmflp4XEAR.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH v2] piix: fix regression during unplug in Xen HVM domUs
Wed, 28 Jun 2023 09:27:16 + Bernhard Beschow : > Would you mind sending a patch fixing the BMIBA register to be reset as 32 > bit? Will do so next week. Are the specs for this chipset available, does this address really need to be accessed in quantities of u32, or is perhaps u16 required? I guess for this specific bug pci_set_word may work as well. Either way, commit e6a71ae327a388723182a504bb253777ec36869b was wrong. Does the comment added in this commit mean, the quantity is really u32? Olaf pgpLqeVXMHpFG.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH v2] piix: fix regression during unplug in Xen HVM domUs
Tue, 27 Jun 2023 10:12:50 + Bernhard Beschow : > The BAR is a 32 bit register whose default value is 0x0001. I think > what's supposed to happen here is a pci_set_long() rather than a > pci_set_byte(). Indeed, the u32 at that address changes from c121 to c101 with the current code. Olaf pgpLHpN5pHN4u.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH v2] piix: fix regression during unplug in Xen HVM domUs
Tue, 27 Jun 2023 10:12:50 + Bernhard Beschow : > Bits 4..15 represent the BAR address, and pci_set_byte() only clears bits > 4..7, leaving bits 8..15 unchanged. Perhaps this causes the BAR to be moved > into the UHCI region? Does changing the call to pci_set_long() fix the > problem? Thanks, it seems this fixes the issue. Let me verify this with a clean build. Olaf pgpWRfMj07Puc.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH v2] piix: fix regression during unplug in Xen HVM domUs
Mon, 26 Jun 2023 23:19:01 +0200 Olaf Hering : > So far I was unable to decipher how the pci_set_word calls can > possibly affect the outcome and the owner of memory_region_ops_read. It is enough to return from piix_ide_reset right after pci_set_word(pci_conf + PCI_COMMAND, 0) to trigger the issue. One thing which was not mentioned yet: the order in which kernel drivers are loaded matters. Usually it is xen-platform-pci/uhci-hcd/ata_piix. When uhci loads, it scans the USB bus, finds the tablet, loads usbhid. While this happens, ata_piix loads. It finds the PCI device in state disabled. The PCI code enables the device. On the qemu side this ends up in pci_default_write_config for PCI device "piix3-ide" with addr=4, val=1, len=2. This calls pci_update_mappings, which for region #4 changes the addr from 0xc120 to 0xc100. This causes the issue. Now usbhid tries to use the USB bus, but uhci_irq fails. If ata_piix is not loaded, uhci works. If ata_piix is loaded before uhci-hcd, the USB bus can not be scanned, udev is killed after a timeout and boot proceeds. If usbhid is loaded before ata_piix, USB bus discovery usually finishes before ata_piix enables its PCI device, boot proceeds. Olaf pgpAUwVLa6uWc.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH v2] piix: fix regression during unplug in Xen HVM domUs
I need advice on how to debug this. One thing that stands out is uhci_irq(). It reads a u16 from the USBSTS register. On the qemu side, this read is served from bmdma_read. Since the read size is 2, the result is ~0, and uhci_irq() turns the controller off. In other words, memory_region_ops_read from addr=0xc102 is served from "piix-bmdma" If the pci_set_word calls in piix_ide_reset are skipped, the read is served from uhci_port_write. This is the expected behavior. In other words, memory_region_ops_read from addr=0xc102 is served from "uhci". So far I was unable to decipher how the pci_set_word calls can possibly affect the outcome and the owner of memory_region_ops_read. Thanks, Olaf Wed, 10 May 2023 00:58:27 +0200 Olaf Hering : > Resuming this old thread about an unfixed bug, which was introduced in > qemu-4.2: > > qemu ends up in piix_ide_reset from pci_unplug_disks. > This was not the case prior 4.2, the removed call to > qemu_register_reset(piix3_reset, d) in > ee358e919e385fdc79d59d0d47b4a81e349cd5c9 did apparently nothing. > > In my debugging (with v8.0.0) it turned out the three pci_set_word > causes the domU to hang. In fact, it is just the last one: > >pci_set_byte(pci_conf + 0x20, 0x01); /* BMIBA: 20-23h */ > > It changes the value from 0xc121 to 0x1. > > The question is: what does this do in practice? > > Starting with recent qemu (like 7.2), the domU sometimes proceeds with > these messages: > > [1.631161] uhci_hcd :00:01.2: host system error, PCI problems? > [1.634965] uhci_hcd :00:01.2: host controller process error, > something bad happened! > [1.634965] uhci_hcd :00:01.2: host controller halted, very bad! > [1.634965] uhci_hcd :00:01.2: HC died; cleaning up > Loading basic drivers...[2.398048] Disabling IRQ #23 pgpi55T1mZisj.pgp Description: Digitale Signatur von OpenPGP
Re: stable-8.0.1 re-tagging?
Tue, 30 May 2023 11:15:31 +0300 Michael Tokarev : > I'm for creating new v8.0.1 tag for the new commit. But I'd like to > hear opinions of others on this matter, since this is an important > process which definitely should be public. The man page of git-tag is very clear on this topic IMO. Go for v8.0.2. Olaf pgpMraWVViPBA.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH v2] piix: fix regression during unplug in Xen HVM domUs
Am Tue, 16 May 2023 13:38:42 -0400 schrieb John Snow : > I haven't touched IDE or block code in quite a long while now -- I > don't think I can help land this fix, but I won't get in anyone's way, > either. Maybe just re-submit the patches with an improved commit > message / cover letter that helps collect the info from the previous > thread, the core issue, etc. I poked at it some more in the past days. Paolo was right in 2019, this issue needs to be debugged more to really understand why fiddling with one PCI devices breaks another, apparently unrelated PCI device. Once I know more, I will suggest a new change. The old one is stale, and needs to be rebased anyway. Olaf pgpM_EdBiS24y.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH v2] piix: fix regression during unplug in Xen HVM domUs
Wed, 10 May 2023 00:58:27 +0200 Olaf Hering : > In my debugging (with v8.0.0) it turned out the three pci_set_word > causes the domU to hang. In fact, it is just the last one: > >pci_set_byte(pci_conf + 0x20, 0x01); /* BMIBA: 20-23h */ > > It changes the value from 0xc121 to 0x1. If I disable just "pci_set_word(pci_conf + PCI_COMMAND, 0x);" it works as well. It changes the value from 0x5 to 0. In general I feel it is wrong to fiddle with PCI from the host side. This is most likely not the intention of the Xen unplug protocol. I'm sure the guest does not expect such changes under the hood. It happens to work by luck with pvops kernels because their PCI discovery is done after the unplug. So, what do we do here to get this off the table? Olaf pgp5Q4M6gldFe.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH v2] piix: fix regression during unplug in Xen HVM domUs
Resuming this old thread about an unfixed bug, which was introduced in qemu-4.2: qemu ends up in piix_ide_reset from pci_unplug_disks. This was not the case prior 4.2, the removed call to qemu_register_reset(piix3_reset, d) in ee358e919e385fdc79d59d0d47b4a81e349cd5c9 did apparently nothing. In my debugging (with v8.0.0) it turned out the three pci_set_word causes the domU to hang. In fact, it is just the last one: pci_set_byte(pci_conf + 0x20, 0x01); /* BMIBA: 20-23h */ It changes the value from 0xc121 to 0x1. The question is: what does this do in practice? Starting with recent qemu (like 7.2), the domU sometimes proceeds with these messages: [1.631161] uhci_hcd :00:01.2: host system error, PCI problems? [1.634965] uhci_hcd :00:01.2: host controller process error, something bad happened! [1.634965] uhci_hcd :00:01.2: host controller halted, very bad! [1.634965] uhci_hcd :00:01.2: HC died; cleaning up Loading basic drivers...[2.398048] Disabling IRQ #23 Is anyone familiar enough with PIIX3 and knows how these devices are interacting? 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01) 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01) 00:03.0 VGA compatible controller: Cirrus Logic GD 5446 Thanks, Olaf On Thu, Mar 25, Paolo Bonzini wrote: > On 25/03/21 12:12, Olaf Hering wrote: > > Am Mon, 22 Mar 2021 18:09:17 -0400 > > schrieb John Snow : > > > > > My understanding is that XEN has some extra disks that it unplugs when > > > it later figures out it doesn't need them. How exactly this works is > > > something I've not looked into too closely. > > > > It has no extra disks, why would it? > > > > I assume each virtualization variant has some sort of unplug if it has to > > support guests that lack PV/virtio/enlightened/whatever drivers. > > No, it's Xen only and really should be legacy. Ideally one would just have > devices supported at all levels from firmware to kernel. > > > > So if these IDE devices have been "unplugged" already, we avoid > > > resetting them here. What about this reset causes the bug you describe > > > in the commit message? > > > > > > Does this reset now happen earlier/later as compared to what it did > > > prior to ee358e91 ? > > > > Prior this commit, piix_ide_reset was only called when the entire > > emulated machine was reset. Like: never. With this commit, > > piix_ide_reset will be called from pci_piix3_xen_ide_unplug. For some > > reason it confuses the emulated USB hardware. Why it does confused > > it, no idea. > > > I wonder what the purpose of the qdev_reset_all() call really is. It > > is 10 years old. It might be stale. > > piix_ide_reset is only calling ide_bus_reset, and from there ide_reset and > bmdma_reset. All of these functions do just two things: reset internal > registers and ensure pending I/O is completed or canceled. The latter is > indeed unnecessary; drain/flush/detach is already done before the call to > qdev_reset_all. > > But the fact that it breaks USB is weird. That's the part that needs to be > debugged, because changing IDE to unbreak USB needs an explanation even if > it's the right thing to do. > > If you don't want to debug it, removing the qdev_reset_all call might do the > job; you'll have to see what the Xen maintainers think of it. But if you > don't debug the USB issue now, it will come back later almost surely. > > Paolo signature.asc Description: Digital signature
Re: [PATCH v2 2/2] tests: lcitool: Switch to OpenSUSE Leap 15.4
Mon, 17 Apr 2023 14:46:54 +0200 Peter Krempa : > Switch the dockerfile to 15.4. Given that Leap 15.5 is essentially done, please skip this meanwhile stale version of Leap. Thanks, Olaf pgp08kRqcL5xn.pgp Description: Digitale Signatur von OpenPGP
Re: qemu v8.0-rc3 fails to compile with Xen
Wed, 12 Apr 2023 15:05:06 +0100 David Woodhouse : > On Wed, 2023-04-12 at 14:20 +0200, Olaf Hering wrote: > > Wed, 12 Apr 2023 12:46:23 +0100 Alex Bennée : > > > > > Olaf Hering writes: > > > > Qemu v7.2.1 can be compiled with Xen 4.6, but v8.0.0-rc3 needs now at > > > > least Xen 4.7. > > > Was this caused by the addition of the KVM Xen target support or some > > > other churn since? > > > > I did not bisect this failure, just checking if bisect is worth the effort. > > It'll be something like this. I haven't tested this yet because I can't > even get Xen that old to build locally. The error with this patch applied looks like this: FAILED: libcommon.fa.p/hw_xen_xen-operations.c.o /usr/bin/gcc-7 -m64 -mcx16 -Ilibcommon.fa.p -I/usr/include/pixman-1 -I/usr/include/libpng16 -I/usr/include/spice-server -I/usr/include/cacard -I/usr/include/nss3 -I/usr/include/nspr4 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/spice-1 -I/usr/include/p11-kit-1 -I/usr/include/libusb-1.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 -I/usr/include/ncursesw -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -isystem /Qc6f3cbca32/linux-headers -isystem linux-headers -iquote . -iquote /Qc6f3cbca32 -iquote /Qc6f3cbca32/include -iquote /Qc6f3cbca32/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -Wundef -Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wmissing-format-attribute -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -fPIE -DOPENSSL_LOAD_CONF -MD -MQ libcommon.fa.p/hw_xen_xen-operations.c.o -MF libcommon.fa.p/hw_xen_xen-operations.c.o.d -o libcommon.fa.p/hw_xen_xen-operations.c.o -c ../hw/xen/xen-operations.c ../hw/xen/xen-operations.c:37:19: error: conflicting types for 'xenevtchn_handle' typedef xc_evtchn xenevtchn_handle; ^~~~ In file included from ../hw/xen/xen-operations.c:17:0: /Qc6f3cbca32/include/hw/xen/xen_backend_ops.h:33:33: note: previous declaration of 'xenevtchn_handle' was here typedef struct xenevtchn_handle xenevtchn_handle; ^~~~ ../hw/xen/xen-operations.c:49:19: error: conflicting types for 'xengnttab_handle' typedef xc_gnttab xengnttab_handle; ^~~~ In file included from ../hw/xen/xen-operations.c:17:0: /Qc6f3cbca32/include/hw/xen/xen_backend_ops.h:136:33: note: previous declaration of 'xengnttab_handle' was here typedef struct xengntdev_handle xengnttab_handle; ^~~~ ../hw/xen/xen-operations.c:193:13: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types] .open = libxenevtchn_backend_open, ^ ../hw/xen/xen-operations.c:193:13: note: (near initialization for 'libxenevtchn_backend_ops.open') ../hw/xen/xen-operations.c:194:14: error: 'xenevtchn_close' undeclared here (not in a function); did you mean 'xc_evtchn_close'? .close = xenevtchn_close, ^~~ xc_evtchn_close ../hw/xen/xen-operations.c:195:25: error: 'xenevtchn_bind_interdomain' undeclared here (not in a function); did you mean 'xc_evtchn_bind_interdomain'? .bind_interdomain = xenevtchn_bind_interdomain, ^~ xc_evtchn_bind_interdomain ../hw/xen/xen-operations.c:196:15: error: 'xenevtchn_unbind' undeclared here (not in a function); did you mean 'xc_evtchn_unbind'? .unbind = xenevtchn_unbind, ^~~~ xc_evtchn_unbind ../hw/xen/xen-operations.c:197:15: error: 'xenevtchn_fd' undeclared here (not in a function); did you mean 'xc_evtchn_fd'? .get_fd = xenevtchn_fd, ^~~~ xc_evtchn_fd ../hw/xen/xen-operations.c:198:15: error: 'xenevtchn_notify' undeclared here (not in a function); did you mean 'xc_evtchn_notify'? .notify = xenevtchn_notify, ^~~~ xc_evtchn_notify ../hw/xen/xen-operations.c:199:15: error: 'xenevtchn_unmask' undeclared here (not in a function); did you mean 'xc_evtchn_unmask'? .unmask = xenevtchn_unmask, ^~~~ xc_evtchn_unmask ../hw/xen/xen-operations.c:200:16: error: 'xenevtchn_pending' undeclared here (
Re: qemu v8.0-rc3 fails to compile with Xen
Wed, 12 Apr 2023 12:46:23 +0100 Alex Bennée : > Olaf Hering writes: > > Qemu v7.2.1 can be compiled with Xen 4.6, but v8.0.0-rc3 needs now at least > > Xen 4.7. > Was this caused by the addition of the KVM Xen target support or some other > churn since? I did not bisect this failure, just checking if bisect is worth the effort. Olaf pgpg6w3yQYqRD.pgp Description: Digitale Signatur von OpenPGP
qemu v8.0-rc3 fails to compile with Xen
Qemu v7.2.1 can be compiled with Xen 4.6, but v8.0.0-rc3 needs now at least Xen 4.7. Is Xen older than 4.7 still a supported target? There is a lot compat code, and the meson checks go back to 4.2. Olaf FAILED: libcommon.fa.p/hw_xen_xen-operations.c.o /usr/bin/gcc-7 -m64 -mcx16 -Ilibcommon.fa.p -I/usr/include/pixman-1 -I/usr/include/libpng16 -I/usr/include/spice-server -I/usr/include/cacard -I/usr/include/nss3 -I/usr/include/nspr4 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/spice-1 -I/usr/include/p11-kit-1 -I/usr/include/libusb-1.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 -I/usr/include/ncursesw -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -isystem /Qc6f3cbca32/linux-headers -isystem linux-headers -iquote . -iquote /Qc6f3cbca32 -iquote /Qc6f3cbca32/include -iquote /Qc6f3cbca32/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -Wundef -Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wmissing-format-attribute -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -fPIE -DOPENSSL_LOAD_CONF -MD -MQ libcommon.fa.p/hw_xen_xen-operations.c.o -MF libcommon.fa.p/hw_xen_xen-operations.c.o.d -o libcommon.fa.p/hw_xen_xen-operations.c.o -c ../hw/xen/xen-operations.c In file included from ../hw/xen/xen-operations.c:16:0: /Qc6f3cbca32/include/hw/xen/xen_native.h: In function 'xenforeignmemory_map2': /Qc6f3cbca32/include/hw/xen/xen_native.h:121:12: warning: implicit declaration of function 'xenforeignmemory_map'; did you mean 'xenforeignmemory_map2'? [-Wimplicit-function-declaration] return xenforeignmemory_map(h, dom, prot, pages, arr, err); ^~~~ xenforeignmemory_map2 /Qc6f3cbca32/include/hw/xen/xen_native.h:121:12: warning: nested extern declaration of 'xenforeignmemory_map' [-Wnested-externs] /Qc6f3cbca32/include/hw/xen/xen_native.h:121:12: warning: return makes pointer from integer without a cast [-Wint-conversion] return xenforeignmemory_map(h, dom, prot, pages, arr, err); ^~~ ../hw/xen/xen-operations.c: At top level: ../hw/xen/xen-operations.c:37:19: error: conflicting types for 'xenevtchn_handle' typedef xc_evtchn xenevtchn_handle; ^~~~ In file included from ../hw/xen/xen-operations.c:17:0: /Qc6f3cbca32/include/hw/xen/xen_backend_ops.h:33:33: note: previous declaration of 'xenevtchn_handle' was here typedef struct xenevtchn_handle xenevtchn_handle; ^~~~ ../hw/xen/xen-operations.c:49:19: error: conflicting types for 'xengnttab_handle' typedef xc_gnttab xengnttab_handle; ^~~~ In file included from ../hw/xen/xen-operations.c:17:0: /Qc6f3cbca32/include/hw/xen/xen_backend_ops.h:136:33: note: previous declaration of 'xengnttab_handle' was here typedef struct xengntdev_handle xengnttab_handle; ^~~~ ../hw/xen/xen-operations.c:193:13: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types] .open = libxenevtchn_backend_open, ^ ../hw/xen/xen-operations.c:193:13: note: (near initialization for 'libxenevtchn_backend_ops.open') ../hw/xen/xen-operations.c:194:14: error: 'xenevtchn_close' undeclared here (not in a function); did you mean 'xc_evtchn_close'? .close = xenevtchn_close, ^~~ xc_evtchn_close ../hw/xen/xen-operations.c:195:25: error: 'xenevtchn_bind_interdomain' undeclared here (not in a function); did you mean 'xc_evtchn_bind_interdomain'? .bind_interdomain = xenevtchn_bind_interdomain, ^~ xc_evtchn_bind_interdomain ../hw/xen/xen-operations.c:196:15: error: 'xenevtchn_unbind' undeclared here (not in a function); did you mean 'xc_evtchn_unbind'? .unbind = xenevtchn_unbind, ^~~~ xc_evtchn_unbind ../hw/xen/xen-operations.c:197:15: error: 'xenevtchn_fd' undeclared here (not in a function); did you mean 'xc_evtchn_fd'? .get_fd = xenevtchn_fd, ^~~~ xc_evtchn_fd ../hw/xen/xen-operations.c:198:15: error: 'xenevtchn_notify' undeclared here (not in a function); did you mean 'xc_evtchn_notify'? .notify = xenevtchn_notify, ^~~~
Re: [PATCH] roms: add back edk2-basetools target
Tue, 11 Apr 2023 12:17:09 +0200 Gerd Hoffmann : > + python3 edk2-build.py --config edk2-build.config -m none Is '-m none' correct? I think previously the result was just a native build. Now that introduced .config attempts cross builds. Maybe that detail must be mentioned in the release notes, and the build requirements. Olaf pgpUOxK5PW_wu.pgp Description: Digitale Signatur von OpenPGP
Re: [PULL 5/6] edk2: replace build scripts
Mon, 20 Mar 2023 10:38:46 +0100 Gerd Hoffmann : > Remove Makefile.edk2 and the edk2*.sh scripts and replace them > with a python script (which already handles fedora rpm builds) > and a config file for it. This breaks 'make roms efirom' (in case this happens to be a valid make target). Olaf pgpEk5fc3zOXQ.pgp Description: Digitale Signatur von OpenPGP
[PATCH v1] migration: fix typo in mig_throttle_guest_down comment
Fixes commit 3d0684b2ad82a5dde68e3f08b0d7786dccaf619c ("ram: Update
all functions comments")
Signed-off-by: Olaf Hering
---
migration/ram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/migration/ram.c b/migration/ram.c
index 723af67c2e..88ff34f574 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -600,7 +600,7 @@ static size_t save_page_header(RAMState *rs, QEMUFile *f,
RAMBlock *block,
}
/**
- * mig_throttle_guest_down: throotle down the guest
+ * mig_throttle_guest_down: throttle down the guest
*
* Reduce amount of guest cpu execution to hopefully slow down memory
* writes. If guest dirty memory rate is reduced below the rate at
Re: [PATCH v2] piix: fix regression during unplug in Xen HVM domUs
Am Mon, 22 Mar 2021 18:09:17 -0400 schrieb John Snow : > My understanding is that XEN has some extra disks that it unplugs when > it later figures out it doesn't need them. How exactly this works is > something I've not looked into too closely. It has no extra disks, why would it? I assume each virtualization variant has some sort of unplug if it has to support guests that lack PV/virtio/enlightened/whatever drivers. In case of HVM, the configured block or network devices can be either accessed via emulated PCI or via the PV drivers. Since the BIOS, the bootloader and potentially the operating system kernel typically lack PV drivers, they will find the devices only via the PCI bus. In case they happen to have PV drivers in addition to PCI drivers, both drivers will find and offer the same resource via different paths. In case of a block device, ata_piix.ko will show it via "/dev/sda" and xen-blkfront.ko will show it via "/dev/xvda". This is obviously bad, at least in the read-write case. The pvops kernel triggers the unplug of the emulated PCI hardware early, prior any other PCI initialization. As a result the PCI drivers will not find their hardware anymore. In case of ata_piix, only the non-CDROM storage will be removed in qmeu, because there is no PV-CDROM driver. The PV support in old xenlinux based kernels is only available as modules. As a result the unplug will happen after PCI was initialized, but it must happen before any PCI device drivers are loaded. > So if these IDE devices have been "unplugged" already, we avoid > resetting them here. What about this reset causes the bug you describe > in the commit message? > > Does this reset now happen earlier/later as compared to what it did > prior to ee358e91 ? Prior this commit, piix_ide_reset was only called when the entire emulated machine was reset. Like: never. With this commit, piix_ide_reset will be called from pci_piix3_xen_ide_unplug. For some reason it confuses the emulated USB hardware. Why it does confused it, no idea. I wonder what the purpose of the qdev_reset_all() call really is. It is 10 years old. It might be stale. Olaf pgpAJb2zZreCU.pgp Description: Digitale Signatur von OpenPGP
[PATCH v2] piix: fix regression during unplug in Xen HVM domUs
Commit ee358e919e385fdc79d59d0d47b4a81e349cd5c9 causes a regression in
Xen HVM domUs which run xenlinux based kernels.
If the domU has an USB device assigned, for example with
"usbdevice=['tablet']" in domU.cfg, the late unplug of devices will
kill the emulated USB host. As a result the khubd thread hangs, and as
a result the entire boot process.
For some reason this does not affect pvops based kernels. This is
most likely caused by the fact that unplugging happens very early
during boot.
Signed-off-by: Olaf Hering
---
hw/ide/piix.c| 5 +
include/hw/ide/pci.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index b9860e35a5..7f1998bf04 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -109,6 +109,9 @@ static void piix_ide_reset(DeviceState *dev)
uint8_t *pci_conf = pd->config;
int i;
+if (d->xen_unplug_done == true) {
+return;
+}
for (i = 0; i < 2; i++) {
ide_bus_reset(>bus[i]);
}
@@ -151,6 +154,7 @@ static void pci_piix_ide_realize(PCIDevice *dev, Error
**errp)
PCIIDEState *d = PCI_IDE(dev);
uint8_t *pci_conf = dev->config;
+d->xen_unplug_done = false;
pci_conf[PCI_CLASS_PROG] = 0x80; // legacy ATA mode
bmdma_setup_bar(d);
@@ -170,6 +174,7 @@ int pci_piix3_xen_ide_unplug(DeviceState *dev, bool aux)
BlockBackend *blk;
pci_ide = PCI_IDE(dev);
+pci_ide->xen_unplug_done = true;
for (i = aux ? 1 : 0; i < 4; i++) {
idebus = _ide->bus[i / 2];
diff --git a/include/hw/ide/pci.h b/include/hw/ide/pci.h
index d8384e1c42..9e71cfec3b 100644
--- a/include/hw/ide/pci.h
+++ b/include/hw/ide/pci.h
@@ -50,6 +50,7 @@ struct PCIIDEState {
IDEBus bus[2];
BMDMAState bmdma[2];
uint32_t secondary; /* used only for cmd646 */
+bool xen_unplug_done;
MemoryRegion bmdma_bar;
MemoryRegion cmd_bar[2];
MemoryRegion data_bar[2];
[PATCH v1] piix: fix regression during unplug in Xen HVM domUs
Commit ee358e919e385fdc79d59d0d47b4a81e349cd5c9 causes a regression in
Xen HVM domUs which run xenlinux based kernels.
If the domU has an USB device assigned, for example with
"usbdevice=['tablet']" in domU.cfg, the late unplug of devices will
kill the emulated USB host. As a result the khubd thread hangs, and as
a result the entire boot process.
For some reason this does not affect pvops based kernels. This is
most likely caused by the fact that unplugging happens very early
during boot.
Signed-off-by: Olaf Hering
---
hw/ide/piix.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index b9860e35a5..2a380a90e9 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -34,6 +34,7 @@
#include "hw/ide/pci.h"
#include "trace.h"
+static bool pci_piix3_xen_ide_unplug_done;
static uint64_t bmdma_read(void *opaque, hwaddr addr, unsigned size)
{
BMDMAState *bm = opaque;
@@ -109,6 +110,8 @@ static void piix_ide_reset(DeviceState *dev)
uint8_t *pci_conf = pd->config;
int i;
+if (pci_piix3_xen_ide_unplug_done == true)
+return;
for (i = 0; i < 2; i++) {
ide_bus_reset(>bus[i]);
}
@@ -169,6 +172,7 @@ int pci_piix3_xen_ide_unplug(DeviceState *dev, bool aux)
IDEBus *idebus;
BlockBackend *blk;
+pci_piix3_xen_ide_unplug_done = true;
pci_ide = PCI_IDE(dev);
for (i = aux ? 1 : 0; i < 4; i++) {
@@ -259,6 +263,7 @@ static const TypeInfo piix4_ide_info = {
static void piix_ide_register_types(void)
{
+pci_piix3_xen_ide_unplug_done = false;
type_register_static(_ide_info);
type_register_static(_ide_xen_info);
type_register_static(_ide_info);
Re: [RFC v1 34/38] target/arm: cpu: only initialize TCG gt timers under CONFIG_TCG
Am Sun, 21 Feb 2021 14:59:38 +0100 schrieb Claudio Fontana : > On 2/21/21 10:55 AM, Philippe Mathieu-Daudé wrote: > > On 2/21/21 10:24 AM, Claudio Fontana wrote: > >> @@ -1347,7 +1348,8 @@ static void arm_cpu_realizefn(DeviceState *dev, > >> Error **errp) > >> cpu->gt_timer[GTIMER_HYPVIRT] = timer_new(QEMU_CLOCK_VIRTUAL, > >> scale, > >>arm_gt_hvtimer_cb, > >> cpu); > > What about Xen? > Good question, what about it.. > Ccing also Olaf. Yes, what about Xen? Does Xen on ARM use these code paths? I do not have the answer for this question. Olaf pgp5hlWOtClUv.pgp Description: Digitale Signatur von OpenPGP
Re: virtfs-proxy-helper fails due to bogus libattr test
Am Tue, 12 Jan 2021 14:08:31 +0100 schrieb Paolo Bonzini : > Olaf, can you expand on that? The full log is here: https://build.opensuse.org/public/build/home:olh:xen-unstable/openSUSE_15.1/x86_64/qemu/_log I browsed configure and meson.build to make a guess which variable is false, so virtfs-proxy-helper is not built anymore. Olaf pgpZgnQFIUe4d.pgp Description: Digitale Signatur von OpenPGP
Re: virtfs-proxy-helper fails due to bogus libattr test
Am Tue, 12 Jan 2021 13:26:00 +0100 schrieb Christian Schoenebeck : > Olaf, could you run a 'git bisect' to identify the relevant commit causing > this? attr was recently moved from configure to meson. After further inspection it turned out that messages on stderr may have no meaning for meson. Elsewhere in the log I see: libcap-ng support: YES ATTR/XATTR support: YES VirtFS support: YES There is also --enable-tools, so CONFIG_TOOLS should be true. have_virtfs_proxy_helper might be false, at least there is no indication that a build of /usr/lib/virtfs-proxy-helper was attempted. However, where is CONFIG_VIRTFS supposed to come from? It seems have_system influences "have_virtfs". There is apparently no easy way to see if 'have_system' became true. Olaf pgpYL9mkJjEgH.pgp Description: Digitale Signatur von OpenPGP
virtfs-proxy-helper fails due to bogus libattr test
Depending on the build environment, the meson test to find a suitable libattr
fails. Something appends -O0 to CFLAGS.
I see no "-O0" in qemu.git. This is a regression, it worked in
553032db17440f8de011390e5a1cfddd13751b0b.
Does anyone happen to know what is causing this?
Olaf
./configure --host=x86_64-suse-linux-gnu --build=x86_64-suse-linux-gnu
--program-prefix= --disable-dependency-tracking --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
--libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib
--mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking
--cc=/usr/bin/gcc-10 --host-cc=/usr/bin/gcc-10 --cxx=/usr/bin/g++-10
--docdir=/usr/share/doc/packages --firmwarepath=/usr/share/qemu/firmware
'--target-list=i386-softmmu x86_64-softmmu' '--audio-drv-list=alsa pa'
--iasl=/usr/bin/iasl --install=/usr/bin/install --objcc=/usr/bin/false
--python=/usr/bin/python3 --ninja=/usr/bin/ninja --tls-priority=NORMAL
--with-git=/usr/bin/false --with-suffix=qemu --disable-docs --disable-gtk
--disable-libnfs --disable-opengl --disable-rbd --disable-spice
--disable-virglrenderer --disable-vte --enable-attr --disable-brlapi
--disable-bsd-user --enable-bzip2 --enable-cap-ng --disable-capstone
--disable-cocoa --enable-coroutine-pool --disable-crypto-afalg --enable-curl
--enable-curses --disable-debug-info --disable-debug-mutex --disable-debug-tcg
--with-default-devices --enable-docs --disable-fdt --enable-gcrypt
--enable-gettext --disable-git-update --disable-glusterfs --enable-gnutls
--enable-gtk --enable-guest-agent --disable-guest-agent-msi --disable-hax
--disable-hvf --enable-iconv --disable-jemalloc --disable-keyring --enable-kvm
--disable-libdaxctl --disable-libiscsi --enable-libnfs --enable-libssh
--enable-libusb --enable-libxml2 --enable-linux-aio --disable-linux-user
--enable-live-block-migration --disable-lzo --disable-lzfse
--disable-malloc-trim --disable-membarrier --enable-modules --disable-mpath
--disable-netmap --disable-nettle --enable-numa --enable-opengl --enable-pie
--enable-plugins --disable-qom-cast-debug --enable-rbd --disable-rdma
--enable-replication --enable-rng-none --disable-safe-stack
--disable-sanitizers --disable-sdl --disable-sdl-image --disable-seccomp
--disable-slirp --disable-smartcard --disable-snappy --disable-sparse
--enable-spice --enable-stack-protector --disable-strip --enable-system
--enable-tcg --disable-tcg-interpreter --disable-tcmalloc --enable-tools
--disable-tpm --disable-tsan --disable-u2f --enable-usb-redir --disable-user
--enable-vde --enable-vhost-crypto --enable-vhost-net --enable-vhost-scsi
--enable-vhost-user --enable-vhost-user-fs --enable-vhost-vsock
--enable-virglrenderer --enable-virtfs --disable-virtiofsd --enable-vnc
--disable-vnc-jpeg --enable-vnc-png --disable-vnc-sasl --enable-vte
--disable-werror --disable-whpx --enable-xen --enable-xen-pci-passthrough
--enable-xfsctl
[ 223s] Run-time dependency libnfs found: YES 4.0.0
[ 223s] None of 'CC_LD' are defined in the environment, not changing global
flags.
[ 223s] Running compile:
[ 223s] Working directory:
/home/abuild/rpmbuild/BUILD/qemu-20210111T151535.b3f846c59d/build/meson-private/tmpg908fqs3
[ 223s] Command line: /usr/bin/gcc-10 -I/usr/include/ncursesw
/home/abuild/rpmbuild/BUILD/qemu-20210111T151535.b3f846c59d/build/meson-private/tmpg908fqs3/testfile.c
-o
/home/abuild/rpmbuild/BUILD/qemu-20210111T151535.b3f846c59d/build/meson-private/tmpg908fqs3/output.exe
-pipe -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g
-D_FILE_OFFSET_BITS=64 -O0 -std=gnu99
[ 223s]
[ 223s] Code:
[ 223s]
[ 223s] #include
[ 223s] #include
[ 223s] #ifdef CONFIG_LIBATTR
[ 223s] #include
[ 223s] #else
[ 223s] #include
[ 223s] #endif
[ 223s] int main(void) { getxattr(NULL, NULL, NULL, 0); setxattr(NULL, NULL,
NULL, 0, 0); return 0; }
[ 223s] Compiler stdout:
[ 223s]
[ 223s] Compiler stderr:
[ 223s] In file included from /usr/include/sys/types.h:25,
[ 223s] from
/home/abuild/rpmbuild/BUILD/qemu-20210111T151535.b3f846c59d/build/meson-private/tmpg908fqs3/testfile.c:3:
[ 223s] /usr/include/features.h:397:4: warning: #warning _FORTIFY_SOURCE
requires compiling with optimization (-O) [-Wcpp]
[ 223s] 397 | # warning _FORTIFY_SOURCE requires compiling with
optimization (-O)
[ 223s] |^~~
[ 223s]
[ 223s] Dependency libseccomp skipped: feature seccomp disabled
pgp1jzTb2YMIo.pgp
Description: Digitale Signatur von OpenPGP
[PATCH v1] configure: remove python pkg_resources check
Since meson.git#0240d760c7699a059cc89e584363c6431cdd2b61 setuptools is not
required anymore.
Signed-off-by: Olaf Hering
---
configure | 3 ---
1 file changed, 3 deletions(-)
diff --git a/configure b/configure
index 8c5d2f9a69..ce9b3c0a33 100755
--- a/configure
+++ b/configure
@@ -1913,9 +1913,6 @@ fi
case "$meson" in
git | internal)
-if ! $python -c 'import pkg_resources' > /dev/null 2>&1; then
-error_exit "Python setuptools not found"
-fi
meson="$python ${source_path}/meson/meson.py"
;;
*) meson=$(command -v "$meson") ;;
regression in meson build, binaries lost reproducibility
Up to qemu.git#v5.0.0 the produced binaries are all reproducible, when built from the same source with same configuration at different times on different hosts and filesystems. See https://reproducible-builds.org/ for hints why this might be a good idea. Now with qemu.git#master this feature was lost. I briefly looked through the meson.build files for potential sources of error, like using wildcards for filelists. But it seems all to-be-compiled files are explicitly listed. Is anyone familiar with the build process and has an idea why this feature was lost? Olaf pgpIaDXEikXEb.pgp Description: Digitale Signatur von OpenPGP
Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules first
Am Wed, 21 Oct 2020 14:05:18 +0200 schrieb Laszlo Ersek : > Olaf: if you build QEMU from source, why don't you build SeaBIOS, iPXE, > edk2 etc *also* from their corresponding pristine upstream clones / > checkouts, using your own dedicated build scripts / packagings? From my perspective it is like that: I export xen/qemu/libivrt into an offline environment for building. The "git clone/git export" is done without submodules, but each required submodule is of course cloned/exported as well into the target directory. In the end it is me who decides what is required or not, which means only a subset of all submodules need to be provided. The build process sees the complete source, and as a result nothing needs to be downloaded. With current master there are these two offending git commands. In my environment they can not do anything but fail. I guess once the next qemu-X.Y release becomes available as the usual "qemu-X.Y.tar.xz" release these git commands will fail as well with 'make -C roms efirom'. As said elsewhere, the correct approach might be to check what is missing and download only these submodules. This should take the existing configure knobs into account. Olaf pgpW6sPdzN6YJ.pgp Description: Digitale Signatur von OpenPGP
Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules first
Am Tue, 20 Oct 2020 11:16:18 +0200 schrieb Olaf Hering : > > + cd edk2/BaseTools && git submodule update --init --force After looking further, there are more bugs: configure has a --with-git knob, which this patch ignores. configure has a --enable-git-update knob, which this patch should most likely use. Olaf pgpGIHgWQr_jn.pgp Description: Digitale Signatur von OpenPGP
Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules first
Am Tue, 20 Oct 2020 11:29:01 +0200 schrieb Philippe Mathieu-Daudé : > The EDK2 roms are only used for testing, we certainly don't want them > to be used by distributions. You mean 'make -C rom efirom' is something that must not be done? Olaf pgpHpgtTLDewr.pgp Description: Digitale Signatur von OpenPGP
Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules first
This is about qemu.git#ec87b5daca761039bbcf781eedbe4987f790836f
On Mon, Sep 07, Laszlo Ersek wrote:
> In edk2 commit 06033f5abad3 ("BaseTools: Make brotli a submodule",
> 2020-04-16), part of edk2-stable202005, the Brotli compressor /
> decompressor source code that edk2 had flattened into BaseTools was
> replaced with a git submodule.
>
> This means we have to initialize edk2's own submodules before building
> BaseTools not just in "roms/Makefile.edk2", but in "roms/Makefile" (for
> the sake of the "efirom" target) and "tests/uefi-test-tools/Makefile" as
> well.
> +++ b/roms/Makefile
> edk2-basetools:
> + cd edk2/BaseTools && git submodule update --init --force
> build-edk2-tools:
> + cd $(edk2_dir)/BaseTools && git submodule update --init --force
This change can not possibly be correct.
With current qemu.git#master one is forced to have network access to
build the roms. This fails with exported (and complete) sources in an
offline environment.
Please revert this patch.
Olaf
signature.asc
Description: PGP signature
[PATCH v1] configure: fix malloc check
Avoid random return value.
Fixes commit f2dfe54c74f768a5bf78c9e5918918727f9d9459
Signed-off-by: Olaf Hering
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index 5d6f5a7f57..85f3662b8e 100755
--- a/configure
+++ b/configure
@@ -6305,6 +6305,7 @@ int main(void) {
if (tmp != NULL) {
return *(int *)(tmp + 2);
}
+return 1;
}
EOF
if compile_prog "$CPU_CFLAGS -Werror -fsanitize=undefined" ""; then
Re: [PATCH v4] piix: fix xenfv regression, add compat machine xenfv-qemu4
Am Mon, 6 Apr 2020 18:00:45 +0200 schrieb Paolo Bonzini : > On 28/03/20 08:09, Olaf Hering wrote: > > On Fri, Mar 27, Paolo Bonzini wrote: > > > >> Looks good, I would just do the following adjustments to have more > >> consistency between pc and xenfv machine types > > > > Do you want me to resend with this change? > > Had you tested this patch? It fails qom-test, test-qmp and test-hmp > because xenfv-qemu4 is not blacklisted. Anyway I fixed it up and will > include it in my next pull request. I did not specifically test your follow-up change, it just renamed variables. I also got failures from automated testing. To me they looked like unrelated general errors in the testing framework. Sorry if I overlooked the essential piece of info that said it was a regression caused by the tested changes. Olaf pgp9dxuZPOQOq.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH v4] piix: fix xenfv regression, add compat machine xenfv-qemu4
On Fri, Mar 27, Paolo Bonzini wrote: > Looks good, I would just do the following adjustments to have more > consistency between pc and xenfv machine types Do you want me to resend with this change? Olaf
[PATCH v4] piix: fix xenfv regression, add compat machine xenfv-qemu4
With qemu4 an incompatible change was added to pc_piix, which makes it
practical impossible to migrate domUs started with qemu2 or qemu3 to
newer qemu versions. Commit 7fccf2a06890e3bc3b30e29827ad3fb93fe88fea
added and enabled a new member "smbus_no_migration_support". In commit
4ab2f2a8aabfea95cc53c64e13b3f67960b27fdf the vmstate_acpi got new
elements, which are conditionally filled. As a result, an incoming
migration expected smbus related data unless smbus migration was
disabled for a given MachineClass. Since first commit forgot to handle
'xenfv', domUs started with qemu4 are incompatible with their qemu3
siblings.
Using other existing machine types, such as 'pc-i440fx-3.1', is not
possible because 'xenfv' creates the 'xen-platform' PCI device at
00:02.0, while all other variants to run a domU would create it at
00:04.0.
To cover both the existing and the broken case of 'xenfv' in a single
qemu binary, a new compatibility variant of 'xenfv-qemu4' must be added
which targets domUs started with qemu-4.0, qemu-4.1 and qemu-4.2. The
existing 'xenfv' restores compatibility of qemu5+ with qemu2/3.
Host admins who started domUs with qemu-4.x have to use a wrapper script
which appends '-machine xenfv-qemu4' to the device-model command line.
This is only required if there is no maintenance window which allows to
temporary shutdown the domU and restart it with a fixed device-model.
The wrapper script is as simple as this:
#!/bin/sh
exec /usr/bin/qemu-system-i386 "$@" -machine xenfv-qemu4
With xl this script will be enabled with device_model_override=, see
xl.cfg(5). To live migrate a domU, adjust the existing domU.cfg and pass
it to xl migrate or xl save/restore:
xl migrate -C new-domU.cfg domU remote-host
xl save domU CheckpointFile new-domU.cfg
xl restore new-domU.cfg CheckpointFile
With libvirt this script will be enabled with the element in
domU.xml. Use 'virsh edit' prior 'virsh migrate' to replace the existing
element to point it to the wrapper script.
Signed-off-by: Olaf Hering
---
hw/i386/pc_piix.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index e6756216f9..c565f41791 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -948,8 +948,21 @@ DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,
#ifdef CONFIG_XEN
+static void xenfv_qemu_4_x_machine_options(MachineClass *m)
+{
+pc_i440fx_4_2_machine_options(m);
+m->desc = "Xen Fully-virtualized PC (qemu 4.x compat)";
+m->max_cpus = HVM_MAX_VCPUS;
+m->default_machine_opts = "accel=xen";
+m->smbus_no_migration_support = false;
+}
+
+DEFINE_PC_MACHINE(xenfv_qemu4, "xenfv-qemu4", pc_xen_hvm_init,
+ xenfv_qemu_4_x_machine_options);
+
static void xenfv_machine_options(MachineClass *m)
{
+pc_i440fx_3_1_machine_options(m);
m->desc = "Xen Fully-virtualized PC";
m->max_cpus = HVM_MAX_VCPUS;
m->default_machine_opts = "accel=xen";
Re: [PATCH v3] piix: fix xenfv regression, add compat machine xenfv-qemu4
On Wed, Mar 25, Paolo Bonzini wrote: > On 25/03/20 16:45, Olaf Hering wrote: > >> hw_compat_3_1 and pc_compat_3_1 > > I have asked about this earlier, so again: > > What do all these arrays do in the context of 'xenfv' to the emulated > > system? > They change the hardware and CPU features that is presented to the VMs, > if the respective devices are included in the virtual machine. For > example USB devices will have a different serial number on 3.1 and 5.0, > and VGA devices present EDID information on 4.1+. I will adjust the change to use either pc_i440fx_3_1_machine_options or pc_i440fx_4_2_machine_options. Olaf signature.asc Description: PGP signature
Re: [PATCH v3] piix: fix xenfv regression, add compat machine xenfv-qemu4
Am Wed, 25 Mar 2020 16:39:54 +0100 schrieb Paolo Bonzini : > hw_compat_3_1 and pc_compat_3_1 I have asked about this earlier, so again: What do all these arrays do in the context of 'xenfv' to the emulated system? Olaf pgpu29Y5u2NnF.pgp Description: Digitale Signatur von OpenPGP
[PATCH v3] piix: fix xenfv regression, add compat machine xenfv-qemu4
With qemu4 an incompatible change was added to pc_piix, which makes it
practical impossible to migrate domUs started with qemu2 or qemu3 to
newer qemu versions. Commit 7fccf2a06890e3bc3b30e29827ad3fb93fe88fea
added and enabled a new member "smbus_no_migration_support". In commit
4ab2f2a8aabfea95cc53c64e13b3f67960b27fdf the vmstate_acpi got new
elements, which are conditionally filled. As a result, an incoming
migration expected smbus related data unless smbus migration was
disabled for a given MachineClass. Since first commit forgot to handle
'xenfv', domUs started with qemu4 are incompatible with their qemu3
siblings.
Using other existing machine types, such as 'pc-i440fx-3.1', is not
possible because 'xenfv' creates the 'xen-platform' PCI device at
00:02.0, while all other variants to run a domU would create it at
00:04.0.
To cover both the existing and the broken case of 'xenfv' in a single
qemu binary, a new compatibility variant of 'xenfv-qemu4' must be added
which targets domUs started with qemu-4.0, qemu-4.1 and qemu-4.2. The
existing 'xenfv' restores compatibility of qemu5+ with qemu2/3.
Host admins who started domUs with qemu-4.x have to use a wrapper script
which appends '-machine xenfv-qemu4' to the device-model command line.
This is only required if there is no maintenance window which allows to
temporary shutdown the domU and restart it with a fixed device-model.
The wrapper script is as simple as this:
#!/bin/sh
exec /usr/bin/qemu-system-i386 "$@" -machine xenfv-qemu4
With xl this script will be enabled with device_model_override=, see
xl.cfg(5). To live migrate a domU, adjust the existing domU.cfg and pass
it to xl migrate or xl save/restore:
xl migrate -C new-domU.cfg domU remote-host
xl save domU CheckpointFile new-domU.cfg
xl restore new-domU.cfg CheckpointFile
With libvirt this script will be enabled with the element in
domU.xml. Use 'virsh edit' prior 'virsh migrate' to replace the existing
element to point it to the wrapper script.
Signed-off-by: Olaf Hering
---
hw/i386/pc_piix.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index e6756216f9..ef23da88d9 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -948,11 +948,26 @@ DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,
#ifdef CONFIG_XEN
+static void xenfv_qemu_4_x_machine_options(MachineClass *m)
+{
+m->desc = "Xen Fully-virtualized PC (qemu 4.x compat)";
+m->max_cpus = HVM_MAX_VCPUS;
+m->default_machine_opts = "accel=xen";
+m->smbus_no_migration_support = false;
+}
+
+DEFINE_PC_MACHINE(xenfv_qemu4, "xenfv-qemu4", pc_xen_hvm_init,
+ xenfv_qemu_4_x_machine_options);
+
static void xenfv_machine_options(MachineClass *m)
{
+PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
+
m->desc = "Xen Fully-virtualized PC";
m->max_cpus = HVM_MAX_VCPUS;
m->default_machine_opts = "accel=xen";
+m->smbus_no_migration_support = true;
+pcmc->pvh_enabled = false;
}
DEFINE_PC_MACHINE(xenfv, "xenfv", pc_xen_hvm_init,
[PATCH v1] configure: record sphinx output
If configure fails to run due to errors in the expected sphinx
environment no helpful message is recorded. Write all of the output to
config.log to assist with debugging.
Signed-off-by: Olaf Hering
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 12dbb0c76b..55086b0280 100755
--- a/configure
+++ b/configure
@@ -4908,7 +4908,7 @@ has_sphinx_build() {
# sphinx-build doesn't exist at all or if it is too old.
mkdir -p "$TMPDIR1/sphinx"
touch "$TMPDIR1/sphinx/index.rst"
-"$sphinx_build" -c "$source_path/docs" -b html "$TMPDIR1/sphinx"
"$TMPDIR1/sphinx/out" >/dev/null 2>&1
+"$sphinx_build" -c "$source_path/docs" -b html "$TMPDIR1/sphinx"
"$TMPDIR1/sphinx/out" >> config.log 2>&1
}
# Check if tools are available to build documentation.
Re: [PATCH v2] hw/i386: disable smbus migration for xenfv
Am Wed, 19 Feb 2020 12:35:30 +0100 schrieb Olaf Hering : > Is any of the things done by pc_i440fx_5_0_machine_options and > pc_i440fx_machine_options a desired, or even breaking, change for the > current result of pc_xen_hvm_init? I tried to follow a few of the initialized members: default_nic_model, perhaps the involved code paths are not called, so the NULL pointer does not matter. pvh_enabled, does this mean the PVH domU type? If yes, this would be lost when xenfv is locked at v3.1. Olaf pgpFyuzy9M65y.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH v2] hw/i386: disable smbus migration for xenfv
Am Thu, 16 Jan 2020 19:26:39 +0100 schrieb Paolo Bonzini : > On 16/01/20 19:03, Olaf Hering wrote: > [...] > > This patch is wrong; xenfv does not support cross-version migration > compatibility. Even if the migration stream does not change, the > hardware exposed to the guest will. > > My understanding is that Xen is able to use "-M > pc-i440fx-VERSION,accel=xen". The presence of the version in the > machine type guarantees that the migration stream is compatible and that > the hardware exposed to the guest is the same on the source and destination. The current idea is to make 'xenfv' a copy of 'pc-i440fx-3.1'. But is this actually the desired behavior? Lets assume xenfv_machine_options calls pc_i440fx_5_0_machine_options. What impact that that have on the result of pc_init1()? Is any of the things done by pc_i440fx_5_0_machine_options and pc_i440fx_machine_options a desired, or even breaking, change for the current result of pc_xen_hvm_init? Also, do the calls to compat_props_add have negative impact on compatibility for running domUs? Olaf pgp9q3w2gqRaR.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH v2] hw/i386: disable smbus migration for xenfv
Am Wed, 19 Feb 2020 09:05:49 +0100 schrieb Paolo Bonzini : > Has any version of Xen been released with a QEMU version above 3.1? Xen 4.13 has a copy of qemu4. But, Xen can use an external qemu. It is unknown how many supposed-to-be-migrated domUs with qemu4+ are out there. But there is a six digit number of running domUs with qemu3 out there. Olaf pgpZcol0bYXqj.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH v2] hw/i386: disable smbus migration for xenfv
Am Tue, 18 Feb 2020 18:37:09 +0100
schrieb Paolo Bonzini :
> On 18/02/20 18:27, Olaf Hering wrote:
> > The approach below (making 'xenfv' an alias of 'pc') does not work:
> > xen_enabled() is false when pc_i440fx_3_1_machine_options runs.
> Don't use an alias, copy the 3.1 code into the xenfv machine type and/or
> call the 3.1 functions from the xenfv machine type.
In the end it may look like this.
Let me know about any preferences regarding the naming of configure options and
variables.
Olaf
diff --git a/configure b/configure
index 6f5d850949..65ca345fd6 100755
--- a/configure
+++ b/configure
@@ -368,6 +368,7 @@ vnc_jpeg=""
vnc_png=""
xkbcommon=""
xen=""
+xen_hvm_pc_i440fx_version_3_1=""
xen_ctrl_version=""
xen_pci_passthrough=""
linux_aio=""
@@ -1162,6 +1163,10 @@ for opt do
;;
--enable-xen-pci-passthrough) xen_pci_passthrough="yes"
;;
+ --disable-xenfv-i440fx-version-3_1) xen_hvm_pc_i440fx_version_3_1="no"
+ ;;
+ --enable-xenfv-i440fx-version-3_1) xen_hvm_pc_i440fx_version_3_1="yes"
+ ;;
--disable-brlapi) brlapi="no"
;;
--enable-brlapi) brlapi="yes"
@@ -7836,6 +7841,9 @@ if supported_xen_target $target; then
if test "$xen_pci_passthrough" = yes; then
echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak"
fi
+if test "$xen_hvm_pc_i440fx_version_3_1" = yes; then
+echo "CONFIG_XEN_HVM_PC_I440FX_VERSION_3_1=y" >> "$config_target_mak"
+fi
else
echo "$target/config-devices.mak: CONFIG_XEN=n" >> $config_host_mak
fi
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index fa12203079..83d1fcc0ba 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -949,6 +949,11 @@ DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,
#ifdef CONFIG_XEN
static void xenfv_machine_options(MachineClass *m)
{
+#ifdef CONFIG_XEN_HVM_PC_I440FX_VERSION_3_1
+pc_i440fx_3_1_machine_options(m);
+#else
+pc_i440fx_4_2_machine_options(m);
+#endif
m->desc = "Xen Fully-virtualized PC";
m->max_cpus = HVM_MAX_VCPUS;
m->default_machine_opts = "accel=xen";
pgpwjhF4nUqph.pgp
Description: Digitale Signatur von OpenPGP
Re: [PATCH v2] hw/i386: disable smbus migration for xenfv
Am Tue, 18 Feb 2020 18:37:09 +0100
schrieb Paolo Bonzini :
> On 18/02/20 18:27, Olaf Hering wrote:
> > The approach below (making 'xenfv' an alias of 'pc') does not work:
> > xen_enabled() is false when pc_i440fx_3_1_machine_options runs.
> Don't use an alias, copy the 3.1 code into the xenfv machine type and/or
> call the 3.1 functions from the xenfv machine type.
Since pci_create_simple must be called after pc_init1, the change appears to be
as simple as this:
@@ -949,6 +953,7 @@ DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,
#ifdef CONFIG_XEN
static void xenfv_machine_options(MachineClass *m)
{
+pc_i440fx_3_1_machine_options(m);
m->desc = "Xen Fully-virtualized PC";
m->max_cpus = HVM_MAX_VCPUS;
m->default_machine_opts = "accel=xen";
There will likely be an argument about making xenfv compatible with 3.1 or 4.2.
I guess the only consensus will be configure option.
Olaf
pgpycSikkwFYZ.pgp
Description: Digitale Signatur von OpenPGP
Re: [PATCH v2] hw/i386: disable smbus migration for xenfv
The approach below (making 'xenfv' an alias of 'pc') does not work:
xen_enabled() is false when pc_i440fx_3_1_machine_options runs.
So, how is this incompatibility between qemu2/3 and qemu4+ supposed to be fixed?
Using '-machine pc,accel=xen -device xen-platform' is incompatible with
'-machine xenpv' because the platform device has a different PCI address. As
such it is not migrateable.
Olaf
Am Mon, 27 Jan 2020 10:09:51 +0100
schrieb Olaf Hering :
> Am Mon, 20 Jan 2020 11:18:41 +
> schrieb Paul Durrant :
>
> > On Fri, 17 Jan 2020 at 13:06, Olaf Hering wrote:
> > > What would future domUs lose if 'xenfv' would be locked to
> > > 'pc-i440fx-3.0'?
>
> > I guess eventually that pc type would be removed and then we'd have a
> > compat issue. Ideally I think libxl should simply not use xenfv and
> > then it can be deprecated and removed, and then such issues can be
> > dealt with directly in xl/libxl.
>
> I think this does not answer the question at all.
> What future versions of libxl do is one thing.
> What existing versions of libxl do with future versions of qemu is another.
>
>
> IMO it was wrong to map "xenfv" to "pc", simply because it entirely
> ignores live migration. We were just lucky until qemu-3.1. Maybe the
> creators of 'xenfv' just meant it to be "do everything to make it
> compatible with HVM".
>
> What about a variant of this change, to lock 'xenfv' to 'qemu-3.0'?
>
>
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -490,6 +490,13 @@ static void pc_i440fx_3_0_machine_options(MachineClass
> *m)
> pc_i440fx_3_1_machine_options(m);
> compat_props_add(m->compat_props, hw_compat_3_0, hw_compat_3_0_len);
> compat_props_add(m->compat_props, pc_compat_3_0, pc_compat_3_0_len);
> +
> +m->alias = "xenfv";
> +if (xen_enabled()) {
> +m->desc = "Xen Fully-virtualized PC";
> +m->max_cpus = HVM_MAX_VCPUS;
> +m->default_machine_opts = "accel=xen";
> +}
> }
>
> DEFINE_I440FX_MACHINE(v3_0, "pc-i440fx-3.0", NULL,
> @@ -500,6 +507,7 @@ static void pc_i440fx_2_12_machine_options(MachineClass
> *m)
> pc_i440fx_3_0_machine_options(m);
> compat_props_add(m->compat_props, hw_compat_2_12, hw_compat_2_12_len);
> compat_props_add(m->compat_props, pc_compat_2_12, pc_compat_2_12_len);
> +m->alias = NULL;
> }
>
> DEFINE_I440FX_MACHINE(v2_12, "pc-i440fx-2.12", NULL,
> @@ -946,14 +954,3 @@ DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,
>isapc_machine_options);
>
>
> -#ifdef CONFIG_XEN
> -static void xenfv_machine_options(MachineClass *m)
> -{
> -m->desc = "Xen Fully-virtualized PC";
> -m->max_cpus = HVM_MAX_VCPUS;
> -m->default_machine_opts = "accel=xen";
> -}
> -
> -DEFINE_PC_MACHINE(xenfv, "xenfv", pc_xen_hvm_init,
> - xenfv_machine_options);
> -#endif
>
>
> Olaf
pgp6RUV3zfRif.pgp
Description: Digitale Signatur von OpenPGP
Re: [PATCH v2] hw/i386: disable smbus migration for xenfv
Am Mon, 27 Jan 2020 10:35:59 +0100 schrieb Paolo Bonzini : > That's years away, so ideally libxl would have migrated away from xenfv > before that. For now, sticking to a fixed version as in Olaf's patch is > a good stopgap measure. Is there a way to inspect a running qemu process to see what version it is? I assume one thing is to poke at /proc/$PID/cmdline and make some guesses. Would a running qemu report what pc-i440fx it supports? With such info an enlightened libxl might be able construct a compatible commandline for the receiving host. Olaf pgpkzkEWZrrxw.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH v2] hw/i386: disable smbus migration for xenfv
Am Mon, 20 Jan 2020 11:18:41 +
schrieb Paul Durrant :
> On Fri, 17 Jan 2020 at 13:06, Olaf Hering wrote:
> > What would future domUs lose if 'xenfv' would be locked to 'pc-i440fx-3.0'?
> I guess eventually that pc type would be removed and then we'd have a
> compat issue. Ideally I think libxl should simply not use xenfv and
> then it can be deprecated and removed, and then such issues can be
> dealt with directly in xl/libxl.
I think this does not answer the question at all.
What future versions of libxl do is one thing.
What existing versions of libxl do with future versions of qemu is another.
IMO it was wrong to map "xenfv" to "pc", simply because it entirely
ignores live migration. We were just lucky until qemu-3.1. Maybe the
creators of 'xenfv' just meant it to be "do everything to make it
compatible with HVM".
What about a variant of this change, to lock 'xenfv' to 'qemu-3.0'?
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -490,6 +490,13 @@ static void pc_i440fx_3_0_machine_options(MachineClass *m)
pc_i440fx_3_1_machine_options(m);
compat_props_add(m->compat_props, hw_compat_3_0, hw_compat_3_0_len);
compat_props_add(m->compat_props, pc_compat_3_0, pc_compat_3_0_len);
+
+m->alias = "xenfv";
+if (xen_enabled()) {
+m->desc = "Xen Fully-virtualized PC";
+m->max_cpus = HVM_MAX_VCPUS;
+m->default_machine_opts = "accel=xen";
+}
}
DEFINE_I440FX_MACHINE(v3_0, "pc-i440fx-3.0", NULL,
@@ -500,6 +507,7 @@ static void pc_i440fx_2_12_machine_options(MachineClass *m)
pc_i440fx_3_0_machine_options(m);
compat_props_add(m->compat_props, hw_compat_2_12, hw_compat_2_12_len);
compat_props_add(m->compat_props, pc_compat_2_12, pc_compat_2_12_len);
+m->alias = NULL;
}
DEFINE_I440FX_MACHINE(v2_12, "pc-i440fx-2.12", NULL,
@@ -946,14 +954,3 @@ DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,
isapc_machine_options);
-#ifdef CONFIG_XEN
-static void xenfv_machine_options(MachineClass *m)
-{
-m->desc = "Xen Fully-virtualized PC";
-m->max_cpus = HVM_MAX_VCPUS;
-m->default_machine_opts = "accel=xen";
-}
-
-DEFINE_PC_MACHINE(xenfv, "xenfv", pc_xen_hvm_init,
- xenfv_machine_options);
-#endif
Olaf
pgp4CKT5ZrT6w.pgp
Description: Digitale Signatur von OpenPGP
Re: [PATCH v2] hw/i386: disable smbus migration for xenfv
Am Fri, 17 Jan 2020 11:27:59 +0100 schrieb Paolo Bonzini : > It doesn't even try to be compatible for all existing and future guests. This looks like the underlying bug. What would future domUs lose if 'xenfv' would be locked to 'pc-i440fx-3.0'? Olaf pgpcvh3cEqCHz.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH v2] hw/i386: disable smbus migration for xenfv
Am Thu, 16 Jan 2020 19:26:39 +0100 schrieb Paolo Bonzini : > My understanding is that Xen is able to use "-M > pc-i440fx-VERSION,accel=xen". The presence of the version in the > machine type guarantees that the migration stream is compatible and that > the hardware exposed to the guest is the same on the source and destination. It seems 'xenfv' is not a 'pc-i440fx-X.X', even with accel=xen. The "xen-platform" will not be created and as a result no PV driver can be used. I do not know what a 'xenfv' is supposed to be, and how it is supposed to behave compatible for all existing and future guests. Olaf pgp4N2iG0pw0Z.pgp Description: Digitale Signatur von OpenPGP
Re: [PATCH v2] hw/i386: disable smbus migration for xenfv
Am Thu, 16 Jan 2020 19:26:39 +0100 schrieb Paolo Bonzini : > xenfv does not support cross-version migration compatibility. Wait, what does that mean? So far live migration of a running domU must be possible from Xen N to Xen N+1. It would be more than unexpected if the target host running "Xen N+1" must have the very same qemu version as "Xen N". Olaf pgpYl_ff4rXPj.pgp Description: Digitale Signatur von OpenPGP
[PATCH v2] hw/i386: disable smbus migration for xenfv
With commit 7fccf2a06890e3bc3b30e29827ad3fb93fe88fea a new member smbus_no_migration_support was added, and enabled in two places. With commit 4ab2f2a8aabfea95cc53c64e13b3f67960b27fdf the vmstate_acpi got new elements, which are conditionally filled. As a result, an incoming migration expected smbus related data unless smbus migration was disabled for a given MachineClass. Since commit 7fccf2a06890e3bc3b30e29827ad3fb93fe88fea forgot to handle xenfv, live migration to receiving hosts using qemu-4.0 and later is broken. Therefore this patch must be applied to stable-4.x as well. Signed-off-by: Olaf Hering --- diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index fa12203079..e19716d0d3 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -952,6 +952,7 @@ static void xenfv_machine_options(MachineClass *m) m->desc = "Xen Fully-virtualized PC"; m->max_cpus = HVM_MAX_VCPUS; m->default_machine_opts = "accel=xen"; +m->smbus_no_migration_support = true; } DEFINE_PC_MACHINE(xenfv, "xenfv", pc_xen_hvm_init,
Re: [PATCH v1] hw/i386: disable smbus migration for xenfv
Am Mon, 13 Jan 2020 18:45:21 +0100 schrieb Olaf Hering : > commit 7fccf2a06890e3bc3b30e29827ad3fb93fe88fea forgot to handle xenpv Actually it is xenFv, but you get the idea. Olaf pgpNSBWyN27Pu.pgp Description: Digitale Signatur von OpenPGP
[PATCH v1] hw/i386: disable smbus migration for xenpv
With commit 7fccf2a06890e3bc3b30e29827ad3fb93fe88fea a new member smbus_no_migration_support was added, and enabled in two places. With commit 4ab2f2a8aabfea95cc53c64e13b3f67960b27fdf the vmstate_acpi got new elements, which are conditionally filled. As a result, an incoming migration expected smbus related data unless smbus migration was disabled for a given MachineClass. Since commit 7fccf2a06890e3bc3b30e29827ad3fb93fe88fea forgot to handle xenpv, live migration to receiving hosts using qemu-4.0 and later is broken. Therefore this patch must be applied to stable-4.x as well. Signed-off-by: Olaf Hering --- hw/i386/pc_piix.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index fa12203079..e19716d0d3 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -952,6 +952,7 @@ static void xenfv_machine_options(MachineClass *m) m->desc = "Xen Fully-virtualized PC"; m->max_cpus = HVM_MAX_VCPUS; m->default_machine_opts = "accel=xen"; +m->smbus_no_migration_support = true; } DEFINE_PC_MACHINE(xenfv, "xenfv", pc_xen_hvm_init,
[Qemu-devel] [PATCH v1] Makefile: remove DESTDIR from firmware file content
The resulting firmware files should only contain the runtime path.
Fixes commit 26ce90fde5c ("Makefile: install the edk2 firmware images
and their descriptors")
Signed-off-by: Olaf Hering
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index f0be624f47..61267bf1a4 100644
--- a/Makefile
+++ b/Makefile
@@ -844,7 +844,7 @@ ifneq ($(DESCS),)
$(INSTALL_DIR) "$(DESTDIR)$(qemu_datadir)/firmware"
set -e; tmpf=$$(mktemp); trap 'rm -f -- "$$tmpf"' EXIT; \
for x in $(DESCS); do \
- sed -e 's,@DATADIR@,$(DESTDIR)$(qemu_datadir),' \
+ sed -e 's,@DATADIR@,$(qemu_datadir),' \
"$(SRC_PATH)/pc-bios/descriptors/$$x" > "$$tmpf"; \
$(INSTALL_DATA) "$$tmpf" \
"$(DESTDIR)$(qemu_datadir)/firmware/$$x"; \
Re: [Qemu-devel] [PATCH for-4.0 v2 2/2] roms: Allow the EDK2_EFIROM variable to be overridden
Am Mon, 8 Apr 2019 13:05:07 +0200 schrieb Laszlo Ersek : > Then build scripts could be updated to invoke: > > make -C roms \ > EDK2_BASETOOLS_OPTFLAGS='...' \ > EDK2_BASETOOLS_LDFLAGS='...' \ > efirom The question remains: 'But why?'. Why can edk2 not be built with '-fno-pie' right away? Did noone approach the edk2 developers yet that their buildsystem is broken in that regard? Olaf pgpJ9MiDSHWZw.pgp Description: Digitale Signatur von OpenPGP
Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2
Am Mon, 8 Apr 2019 11:04:09 +0200 schrieb Laszlo Ersek : > This is not a QEMU build failure, but an issue in the downstream > packaging that not only tries to build QEMU, but performs a maintainer > build on binary artifacts. I'm sure everyone will rebuild the things from source that can be rebuilt. Who would ship random binary blobs from unknown origin? Olaf pgp3dPZPPhGmm.pgp Description: Digitale Signatur von OpenPGP
Re: [Qemu-devel] [PATCH for-4.0] roms: Allow the EFIROM variable to be overridden
Am Fri, 5 Apr 2019 19:17:35 -0400 schrieb "Michael S. Tsirkin" : > Let's keep it simple: set a config variable, then check it here. Better revert f590a812c21074e82228de3e1dfb57b75fc02b62 and 23858f4092fc9ebf9e7a5e5110e44abef6fc6643 for the time being. It looks like a no-op right now. How did people get away without the system-wide EfiRom until now? It is certainly only a very small inconvenience to build a private EfiRom for those who can not possibly receive it from the vendor. Also roms/ seems to be unable to receive configure options. Olaf pgppni9ubBkZ6.pgp Description: Digitale Signatur von OpenPGP
Re: [Qemu-devel] [PATCH for-4.0] roms: Allow the EFIROM variable to be overridden
Am Fri, 5 Apr 2019 14:59:16 +0200 schrieb Philippe Mathieu-Daudé : > On 4/5/19 2:09 PM, Olaf Hering wrote: > > Am Fri, 5 Apr 2019 13:55:29 +0200 > > schrieb Philippe Mathieu-Daudé : > > > >> +EFIROM ?= edk2/BaseTools/Source/C/bin/EfiRom > > > > This name is too generic and will conflict with ipxe.git if any of "bios > > seavgabios pxerom" is used for 'make -C roms'. > > This is similar to commit c9d18c1c150c84e where you said "it used to > work", what is the difference? Before there was no need to pass EFIROM= to make, so ipxe.git was happy. Now it is required, and ipxe.git gets an unexpected value. > IPXE override the EFIROM variable, so there is no change there. For me ipxe tries to rm $(type -P EfiRom). Let me double check. > How can I trigger a SUSE package build with this patch? Not so easy without a VM. Olaf pgpkLyUiPIZQH.pgp Description: Digitale Signatur von OpenPGP
Re: [Qemu-devel] [PATCH for-4.0] roms: Allow the EFIROM variable to be overridden
Am Fri, 5 Apr 2019 13:55:29 +0200 schrieb Philippe Mathieu-Daudé : > +EFIROM ?= edk2/BaseTools/Source/C/bin/EfiRom This name is too generic and will conflict with ipxe.git if any of "bios seavgabios pxerom" is used for 'make -C roms'. Olaf pgpFSdFcL3tvf.pgp Description: Digitale Signatur von OpenPGP
Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2
Am Fri, 5 Apr 2019 13:14:35 +0200
schrieb Philippe Mathieu-Daudé :
> On 4/5/19 12:59 PM, Olaf Hering wrote:
> > Am Fri, 5 Apr 2019 12:49:15 +0200
> > schrieb Philippe Mathieu-Daudé :
> >
> >> The EDK2 submodule was added for UEFI testing, you don't need to compile
> >> it to build/use QEMU.
> >>
> >> How did you end up compiling it?
> >
> > The qemu.spec file has this since a very long time:
> > make -C roms efirom ${unrelated_settings}
> I don't have any qemu.spec, is it a SUSE file?
Yes, it is part of the qemu package.
https://build.opensuse.org/package/show/Virtualization/qemu
> > This used to work still in January with
> > c9d18c1c150c84e7a976df989ad04ddf01083f46.
> Before f590a812c210 the EfiRom tool was not available, now we compile it
> inconditionally.
I wonder why it must be compiled unconditionally.
This is my workaround:
sed -i 's@EFIROM@KAPUTT@g' roms/Makefile
efirom=
test -x "$(type -P EfiRom)" && KAPUTT="$_" efirom=efirom
make -C roms ${efirom} KAPUTT=${KAPUTT}
> So I assume your distribution already provides the EfiRom tool. Can you
> point me at the package which provides it? I wonder if your distribution
> use a non-upstreamed patch that change the EDK2 BaseTools PIE/PIC flags.
It is in ovmf-tools.rpm, which comes from ovmf. And looking at this package,
they also had to workaround the fact that edk2 does not cope with PIE.
https://build.opensuse.org/package/show/Virtualization/ovmf
Olaf
pgprz2wLLT6h5.pgp
Description: Digitale Signatur von OpenPGP
Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2
Am Fri, 5 Apr 2019 13:29:44 +0200 schrieb Philippe Mathieu-Daudé : > I'll submit that patch. Can this actually work? It does not remove the naming conflict. Olaf pgpL9MyUiEtmy.pgp Description: Digitale Signatur von OpenPGP
Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2
Am Fri, 5 Apr 2019 12:59:18 +0200 schrieb Olaf Hering : > This used to work still in January with > c9d18c1c150c84e7a976df989ad04ddf01083f46. It is not possible to just override EFIROM=$(type -P EfiRom) because this variable is also used by ipxe.git. Olaf pgp6kq871XR2n.pgp Description: Digitale Signatur von OpenPGP
Re: [Qemu-devel] edk2 fails to compile in v4.0.0-rc2
Am Fri, 5 Apr 2019 12:49:15 +0200
schrieb Philippe Mathieu-Daudé :
> The EDK2 submodule was added for UEFI testing, you don't need to compile
> it to build/use QEMU.
>
> How did you end up compiling it?
The qemu.spec file has this since a very long time:
make -C roms efirom ${unrelated_settings}
This used to work still in January with
c9d18c1c150c84e7a976df989ad04ddf01083f46.
Olaf
pgpO7EmIaP4Ag.pgp
Description: Digitale Signatur von OpenPGP
[Qemu-devel] edk2 fails to compile in v4.0.0-rc2
It seems in qemu.git#master the edk2.git submodule is now mandatory. For me it fails to compile. This is not a new error. It needs to be compiled with -fPIC since essentially forever. But I wonder, why does it fail to compile only for me?! Example of failure: $ grep -h CommonLib.o /dev/shm/*/.build.log [ 85s] gcc -c -I .. -I ../Include/Common -I ../Include/ -I ../Include/IndustryStandard -I ../Common/ -I .. -I . -I ../Include/X64/ -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -Wno-stringop-truncation -Wno-restrict -Wno-unused-result -nostdlib -g -O2 CommonLib.c -o CommonLib.o [ 89s] ar crs ../libs/libCommon.a BasePeCoff.o BinderFuncs.o CommonLib.o Crc32.o Decompress.o EfiCompress.o EfiUtilityMsgs.o FirmwareVolumeBuffer.o FvLib.o MemoryFile.o MyAlloc.o OsPath.o ParseGuidedSectionTools.o ParseInf.o PeCoffLoaderEx.o SimpleFileParsing.o StringFuncs.o TianoCompress.o PcdValueCommon.o [ 106s] /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: ../libs/libCommon.a(CommonLib.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC [ 106s] /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: ../libs/libCommon.a(CommonLib.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC [ 120s] /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: ../libs/libCommon.a(CommonLib.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC What do I need to change in my setup so that -fPIC is not required? Olaf pgpCUSpA5ozKp.pgp Description: Digitale Signatur von OpenPGP
Re: [Qemu-devel] [PATCH v1] xen: preserve COMPAT in CFLAGS
Am Thu, 13 Dec 2018 11:05:25 + schrieb Anthony PERARD : > Hi, > > Ian, we have those XC_WANT_COMPAT_* #defines to allow consumers of Xen > libs be able to use old interfaces. Do you think it's a good idea to > have this consumers (QEMU here) #undef the flag when it has implemented > the newer interface? I think the wording is wrong. The defines exist to expose existing APIs to software that was not updated to use the "latest" API. To me it looks like the undef's are wrong. Even the usage in configure looks bogus, but that is another unrelated thing. Olaf pgpKGRkQWgOgT.pgp Description: Digitale Signatur von OpenPGP
Re: [Qemu-devel] [Xen-devel] xen_disk qdevification (was: [PATCH 0/3] Performance improvements for xen_disk v2)
On Fri, Nov 02, Kevin Wolf wrote: > A while ago, a downstream patch review found out that there are some QMP > commands that would immediately crash if a xen_disk device were present > because of the lacking qdevification. This is not the code quality > standard I envision for QEMU. It's time for non-qdev devices to go. Do you have that backwards by any chance? IMO the presence of assert() contributes to bad code quality, not the drivers that trigger those asserts. It is bad enough that two QEMU releases went out while being in bad shape. Anyway, hopefully Paul or whoever will find the time and energy to convert the code at some point. Olaf signature.asc Description: PGP signature
Re: [Qemu-devel] [Xen-devel] memory leak in block/xen_disk in qemu-3.x
On Tue, Dec 11, Paul Durrant wrote: > > -Original Message- > > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > > Of Olaf Hering > > Sent: 11 December 2018 15:31 > > To: xen-de...@lists.xenproject.org; qemu-devel@nongnu.org > > Subject: [Xen-devel] memory leak in block/xen_disk in qemu-3.x > > > > What are the live time rules of ioreq->buf? > > In my testing the memory usage of qemu is constantly growing from about > > 250MB to several GB after a few days. > Are you perhaps running into the problem addressed by this patch? > https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg00244.html This looks like a fix, rather than an improvement. More than a month passed already, why is it not yet in qemu.git#master? Olaf signature.asc Description: PGP signature
[Qemu-devel] [PATCH v1] xen_disk: fix memory leak
There are some code paths that clobber ioreq->buf, which leads to a huge
memory leak after a few hours of runtime. One code path is
qemu_aio_complete, which might be called recursive. Another one is
ioreq_reset, which might clobber ioreq->buf as well.
Add wrappers to free ioreq->buf before reassignment.
Signed-off-by: Olaf Hering
---
hw/block/xen_disk.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 36eff94f84..e15eefe625 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -103,12 +103,24 @@ struct XenBlkDev {
/* - */
+static void ioreq_buf_alloc(struct ioreq *ioreq, size_t alignment)
+{
+if (ioreq->buf)
+qemu_vfree(ioreq->buf);
+ioreq->buf = qemu_memalign(XC_PAGE_SIZE, ioreq->size);
+}
+static void ioreq_buf_free(struct ioreq *ioreq)
+{
+if (ioreq->buf)
+qemu_vfree(ioreq->buf);
+ioreq->buf = NULL;
+}
static void ioreq_reset(struct ioreq *ioreq)
{
+ioreq_buf_free(ioreq);
memset(>req, 0, sizeof(ioreq->req));
ioreq->status = 0;
ioreq->start = 0;
-ioreq->buf = NULL;
ioreq->size = 0;
ioreq->presync = 0;
@@ -315,14 +327,14 @@ static void qemu_aio_complete(void *opaque, int ret)
if (ret == 0) {
ioreq_grant_copy(ioreq);
}
-qemu_vfree(ioreq->buf);
+ioreq_buf_free(ioreq);
break;
case BLKIF_OP_WRITE:
case BLKIF_OP_FLUSH_DISKCACHE:
if (!ioreq->req.nr_segments) {
break;
}
-qemu_vfree(ioreq->buf);
+ioreq_buf_free(ioreq);
break;
default:
break;
@@ -390,12 +402,12 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
{
struct XenBlkDev *blkdev = ioreq->blkdev;
-ioreq->buf = qemu_memalign(XC_PAGE_SIZE, ioreq->size);
+ioreq_buf_alloc(ioreq, XC_PAGE_SIZE);
if (ioreq->req.nr_segments &&
(ioreq->req.operation == BLKIF_OP_WRITE ||
ioreq->req.operation == BLKIF_OP_FLUSH_DISKCACHE) &&
ioreq_grant_copy(ioreq)) {
-qemu_vfree(ioreq->buf);
+ioreq_buf_free(ioreq);
goto err;
}
[Qemu-devel] memory leak in block/xen_disk in qemu-3.x
What are the live time rules of ioreq->buf? In my testing the memory usage of qemu is constantly growing from about 250MB to several GB after a few days. Some debugging shows that ioreq_runio_qemu_aio() overwrites ioreq->buf, which contributes to the leak. In addition, ioreq_reset() also just globbers iorew->buf. While this was observed with a backport of xen_disk changes to qemu-2.9, the code in xen_disk.c did not change in this regard. I changed the code to call qemu_vfree(ioreq->buf) in the few places that globber the pointer, that fixes the leak for me. Right now neither qemu-3.0 nor 3.1 for me, so I can not test qemu.git#master if it eventually behaves different than qemu.git#stable-2.9+backport. Olaf signature.asc Description: PGP signature
Re: [Qemu-devel] [Xen-devel] [PATCH v1] xen: preserve COMPAT in CFLAGS
Ping? On Fri, Oct 26, Olaf Hering wrote: > A given Qemu version can not predict what version of Xen it will run on. > There are some checks in configure to decide what Xen libraries and > functions are available. How exactly these functions must be accessed > has to be decided by configure and the user who is compiling Qemu. > In no way some random header file must override this decision. > > Remove the breakage introduced by commit 5eeb39c24b, which would always > hide the libxc interfaces the given version of Qemu knows about. > > The current symptom of such breakage is a build failure with qemu-2.9 > and older, in combination with Xen 4.12. > > Fixes: 5eeb39c24b7d4da5d129bfdd9c4fd21cfb3d28d6 > Signed-off-by: Olaf Hering > --- > include/hw/xen/xen_common.h | 9 - > 1 file changed, 9 deletions(-) > > diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h > index 5f1402b494..33fa2d3497 100644 > --- a/include/hw/xen/xen_common.h > +++ b/include/hw/xen/xen_common.h > @@ -1,15 +1,6 @@ > #ifndef QEMU_HW_XEN_COMMON_H > #define QEMU_HW_XEN_COMMON_H > > -/* > - * If we have new enough libxenctrl then we do not want/need these compat > - * interfaces, despite what the user supplied cflags might say. They > - * must be undefined before including xenctrl.h > - */ > -#undef XC_WANT_COMPAT_EVTCHN_API > -#undef XC_WANT_COMPAT_GNTTAB_API > -#undef XC_WANT_COMPAT_MAP_FOREIGN_API > - > #include > #include > #include > > ___ > Xen-devel mailing list > xen-de...@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel signature.asc Description: PGP signature
[Qemu-devel] [PATCH v1] xen: preserve COMPAT in CFLAGS
A given Qemu version can not predict what version of Xen it will run on. There are some checks in configure to decide what Xen libraries and functions are available. How exactly these functions must be accessed has to be decided by configure and the user who is compiling Qemu. In no way some random header file must override this decision. Remove the breakage introduced by commit 5eeb39c24b, which would always hide the libxc interfaces the given version of Qemu knows about. The current symptom of such breakage is a build failure with qemu-2.9 and older, in combination with Xen 4.12. Fixes: 5eeb39c24b7d4da5d129bfdd9c4fd21cfb3d28d6 Signed-off-by: Olaf Hering --- include/hw/xen/xen_common.h | 9 - 1 file changed, 9 deletions(-) diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h index 5f1402b494..33fa2d3497 100644 --- a/include/hw/xen/xen_common.h +++ b/include/hw/xen/xen_common.h @@ -1,15 +1,6 @@ #ifndef QEMU_HW_XEN_COMMON_H #define QEMU_HW_XEN_COMMON_H -/* - * If we have new enough libxenctrl then we do not want/need these compat - * interfaces, despite what the user supplied cflags might say. They - * must be undefined before including xenctrl.h - */ -#undef XC_WANT_COMPAT_EVTCHN_API -#undef XC_WANT_COMPAT_GNTTAB_API -#undef XC_WANT_COMPAT_MAP_FOREIGN_API - #include #include #include
Re: [Qemu-devel] [PATCH v1] exec: handle NULL pointer in flatview_read_continue
Am Fri, 10 Aug 2018 14:29:28 +0200 schrieb Paolo Bonzini : > On 10/08/2018 12:32, Olaf Hering wrote: > > Am Fri, 10 Aug 2018 12:25:09 +0200 > > schrieb Paolo Bonzini : > > So you mean that function must not return NULL? > > Or should the caller check for the result? > Either, but the former would of course be much simpler if possible. Since other callers already deal with NULL, that one has to cope as well. And since unavailable memory can not be zero, the memset 0xff is most likely correct as well. So, for me the patch is good as it is. The write part will get a separate change in a few days. Olaf pgpkxWwOj1cPY.pgp Description: Digitale Signatur von OpenPGP
Re: [Qemu-devel] [PATCH v1] exec: handle NULL pointer in flatview_read_continue
Am Fri, 10 Aug 2018 12:25:09 +0200 schrieb Paolo Bonzini : > There are many more callers of qemu_ram_ptr_length, and none of them check > the result. So you mean that function must not return NULL? Or should the caller check for the result? Olaf pgp6zq9J9aL36.pgp Description: Digitale Signatur von OpenPGP
Re: [Qemu-devel] [PATCH v1] exec: handle NULL pointer in flatview_read_continue
Am Thu, 9 Aug 2018 16:52:22 +0200 schrieb Paolo Bonzini : > I think the simplest fix is for the map > cache to set aside a zero page and return it whenever it is asked for a > ballooned page. Can qemu actually know if it ran into a ballooned page? I think no. Olaf pgpmdqCLn4Xnn.pgp Description: Digitale Signatur von OpenPGP
Re: [Qemu-devel] [PATCH v1] exec: handle NULL pointer in flatview_read_continue
Am Thu, 9 Aug 2018 16:38:16 +0200 schrieb Olaf Hering : > Someone familiar with that code has to figure that out. A ballooned page will > trigger that bug. Indeed, xen-4.4 + qemu-3.0 crashes with ballooned pages. That can easily happen if the domU does readdir via NFS. Olaf Thread 1 "qemu-system-i38" received signal SIGSEGV, Segmentation fault. 0x7f439593f2ee in __memcpy_sse2_unaligned () from /lib64/libc.so.6 #0 0x7f439593f2ee in __memcpy_sse2_unaligned () at /lib64/libc.so.6 #1 0x55c7f7c8ee14 in memcpy (__len=1, __src=, __dest=0x7fff6819bc68) at /usr/include/bits/string3.h:53 #2 0x55c7f7c8ee14 in flatview_read_continue (fv=0x55c7f99350f0, addr=3833593856, attrs=..., buf=0x7fff6819bc68 "", len=1, addr1=3833593856, l=1, mr=0x55c7f88309a0 ) at /usr/src/debug/qemu-3.0-20180807T172617.6ad9080538/exec.c:3321 #3 0x55c7f7c8efef in flatview_read (fv=0x55c7f99350f0, addr=3833593856, attrs=..., buf=0x7fff6819bc68 "", len=1) at /usr/src/debug/qemu-3.0-20180807T172617.6ad9080538/exec.c:3354 #4 0x55c7f7c8f11f in address_space_read_full (as=, addr=, attrs=..., buf=, len=) at /usr/src/debug/qemu-3.0-20180807T172617.6ad9080538/exec.c:3367 #5 0x55c7f7c8f337 in cpu_physical_memory_rw (addr=, buf=, len=, is_write=) at /usr/src/debug/qemu-3.0-20180807T172617.6ad9080538/exec.c:3404 #6 0x55c7f7d980a6 in read_phys_req_item (val=0x7fff6819bc68, i=0, req=0x7fff6819bc60, addr=) at /usr/src/debug/qemu-3.0-20180807T172617.6ad9080538/hw/i386/xen/xen-hvm.c:841 #7 0x55c7f7d980a6 in cpu_ioreq_move (req=0x7fff6819bc60) at /usr/src/debug/qemu-3.0-20180807T172617.6ad9080538/hw/i386/xen/xen-hvm.c:904 #8 0x55c7f7d980a6 in handle_ioreq (state=, req=0x7fff6819bc60) at /usr/src/debug/qemu-3.0-20180807T172617.6ad9080538/hw/i386/xen/xen-hvm.c:1046 #9 0x55c7f7d99b85 in cpu_handle_ioreq (opaque=0x55c7f90fe360) at /usr/src/debug/qemu-3.0-20180807T172617.6ad9080538/hw/i386/xen/xen-hvm.c:1153 #10 0x55c7f811e288 in aio_dispatch_handlers (ctx=0x55c7f9052130) at util/aio-posix.c:406 #11 0x55c7f811ec48 in aio_dispatch (ctx=0x55c7f9052130) at util/aio-posix.c:437 #12 0x55c7f811a75e in aio_ctx_dispatch (source=, callback=, user_data=) at util/async.c:261 #13 0x7f43965d6134 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0 #14 0x55c7f811dca7 in glib_pollfds_poll () at util/main-loop.c:215 #15 0x55c7f811dca7 in os_host_main_loop_wait (timeout=) at util/main-loop.c:238 #16 0x55c7f811dca7 in main_loop_wait (nonblocking=) at util/main-loop.c:497 #17 0x55c7f7e129c2 in main_loop () at vl.c:1866 #18 0x55c7f7c7efdc in main () pgpg8DRYs_2yO.pgp Description: Digitale Signatur von OpenPGP
