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
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
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
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
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
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
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
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
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
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
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.
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:
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
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,
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
ice, 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 change
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
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
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
he 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:
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
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)
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
d 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
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
d 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
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.
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?
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.
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?
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 t
able 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
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
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
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 0x
(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
> > sc
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
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
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 bise
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
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
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
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
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
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
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(+)
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)
> >>
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
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
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
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
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
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
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 pat
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
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
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
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 machin
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
omU.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 +
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 cha
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
omU.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 +++
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
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 initialize
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 g
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
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 c
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 c
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:
&
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
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.
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
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
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
-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";
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
-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->d
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/Make
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'
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
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
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
> >
> >
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
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 com
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
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
Descr
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
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
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
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
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
> &
uf 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
@
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
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
: 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
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?
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
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
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
1 - 100 of 199 matches
Mail list logo
