On 12/02/2025 01.41, Thomas Huth wrote:
On 11/02/2025 20.03, Philippe Mathieu-Daudé wrote:
On 11/2/25 19:53, Philippe Mathieu-Daudé wrote:
On 11/2/25 19:48, Philippe Mathieu-Daudé wrote:
On 11/2/25 19:26, Stefan Hajnoczi wrote:
On Mon, Feb 10, 2025 at 3:43 PM Philippe Mathieu-Daudé
<phi...@linaro.org> wrote:
The following changes since commit
54e91d1523b412b4cff7cb36c898fa9dc133e886:
Merge tag 'pull-qapi-2025-02-10-v2' of https://repo.or.cz/qemu/
armbru into staging (2025-02-10 10:47:31 -0500)
are available in the Git repository at:
https://github.com/philmd/qemu.git tags/hw-misc-20250210
for you to fetch changes up to 1078a376932cc1d1c501ee3643fef329da6a189a:
hw/net/smc91c111: Ignore attempt to pop from empty RX fifo
(2025-02-10 21:30:44 +0100)
----------------------------------------------------------------
Misc HW patches
- Use qemu_hexdump_line() in TPM backend (Philippe)
- Make various Xilinx devices endianness configurable (Philippe)
- Remove magic number in APIC (Phil)
- Disable thread-level cache topology (Zhao)
- Xen QOM style cleanups (Bernhard)
- Introduce TYPE_DYNAMIC_SYS_BUS_DEVICE (Philippe)
- Invert logic of machine no_sdcard flag (Philippe)
- Housekeeping in MicroBlaze functional tests (Philippe)
Please take a look at this CI failure:
https://gitlab.com/qemu-project/qemu/-/jobs/9106591368
Hmm I can not reproduce locally this error:
Exception: Asset cache is invalid and downloads disabled
OK, I could reproduce by blowing my cache away.
The problem seems in the "tests/functional: Have microblaze tests
inherit common parent class" patch, which does:
-class MicroblazeelMachine(QemuSystemTest):
+class MicroblazeLittleEndianMachine(MicroblazeMachine):
I presume, since MicroblazeLittleEndianMachine is no more a direct
child of QemuSystemTest, then the ASSET_IMAGE_* aren't automatically
downloaded.
Well, apparently related to network failure:
INFO:qemu-test:Downloading http://www.qemu-advent-calendar.org/2023/
download/day13.tar.gz to /Users/philmd/.cache/qemu/download/
b9b3d43c5dd79db88ada495cc6e0d1f591153fe41355e925d791fbf44de50c22...
ERROR:qemu-test:Unable to download http://www.qemu-advent-
calendar.org/2023/ download/day13.tar.gz: HTTP Error 403: Forbidden
$ curl -v http://www.qemu-advent-calendar.org/2023/download/day13.tar.gz
> GET /2023/download/day13.tar.gz HTTP/1.1
< HTTP/1.1 301 Moved Permanently
< Location: https://www.qemu-advent-calendar.org/2023/download/day13.tar.gz
Using:
-- >8 --
diff --git a/tests/functional/test_microblaze_s3adsp1800.py b/tests/
functional/test_microblaze_s3adsp1800.py
index 177c8a685bc..949e627c84a 100755
--- a/tests/functional/test_microblaze_s3adsp1800.py
+++ b/tests/functional/test_microblaze_s3adsp1800.py
@@ -24,3 +24,3 @@ class MicroblazeMachine(QemuSystemTest):
ASSET_IMAGE_LE = Asset(
- ('http://www.qemu-advent-calendar.org/2023/download/day13.tar.gz'),
+ ('https://www.qemu-advent-calendar.org/2023/download/day13.tar.gz'),
'b9b3d43c5dd79db88ada495cc6e0d1f591153fe41355e925d791fbf44de50c22')
---
I still get:
INFO:qemu-test:Downloading https://www.qemu-advent-calendar.org/2023/
download/day13.tar.gz to /Users/philmd/.cache/qemu/download/
b9b3d43c5dd79db88ada495cc6e0d1f591153fe41355e925d791fbf44de50c22...
However:
$ curl --http1.0 -v https://www.qemu-advent-calendar.org/2023/download/
day13.tar.gz
> GET /2023/download/day13.tar.gz HTTP/1.0
< HTTP/1.0 200 OK
< Content-Length: 4752277
< Content-Type: application/gzip
So I'm confused...
Looks like this also happens in test runs without your patches:
https://gitlab.com/qemu-project/qemu/-/jobs/9108828196#L844
The test then silently gets skipped there (since we only fail hard for a 404
error now).
Maybe Eldon could comment why the downloads are blocked for python scripts
but not for curl downloads?
I the worst case, we have to mirror the asset to another place, I guess...
Ok, I've now also put the image here:
https://qemu-advcal.gitlab.io/qac-best-of-multiarch/download/day05.tar.xz
(just had to use a different day number there since 13 was an image that I
did not want to sacrifice in the best-of roaster).
So if the qemu-advent-calendar.org server keeps refusing the downloads, you
should be able to use the mirrored tarball instead.
HTH,
Thomas
