[ovmf test] 184408: all pass - PUSHED
flight 184408 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/184408/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 5d016fe0a061647ed29562c9f161e454b0f7f9dd baseline version: ovmf 0223bdd4e40975c427616761fb13c9454461b64d Last test of basis 184403 2024-01-19 07:11:05 Z0 days Testing same since 184408 2024-01-20 03:43:02 Z0 days1 attempts People who touched revisions under test: Pierre Gondois jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 0223bdd4e4..5d016fe0a0 5d016fe0a061647ed29562c9f161e454b0f7f9dd -> xen-tested-master
[linux-linus test] 184405: tolerable FAIL - PUSHED
flight 184405 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/184405/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184402 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 184402 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 184402 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 184402 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 184402 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 184402 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184402 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184402 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass version targeted for testing: linux556e2d17cae620d549c5474b1ece053430cd50bc baseline version: linux9d1694dc91ce7b80bc96d6d8eaf1a1eca668d847 Last test of basis 184402 2024-01-19 05:57:15 Z0 days Testing same since 184405 2024-01-19 18:44:05 Z0 days1 attempts People who touched revisions under test: "Darrick J. Wong" Al Viro Chandan Babu R Christian Brauner Darrick J. Wong David Howells Dominique Martinet Eric Biggers Ilya Dryomov Jia Zhu Linus Torvalds Marc Dionne Namjae Jeon Steve French Venky Shankar Wenchao Hao Xiubo Li Yiqun Leng jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf
[xen-unstable test] 184404: tolerable FAIL - PUSHED
flight 184404 xen-unstable real [real] flight 184406 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184404/ http://logs.test-lab.xenproject.org/osstest/logs/184406/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-vhd6 host-ping-check-native fail pass in 184406-retest test-armhf-armhf-libvirt-qcow2 17 guest-start/debian.repeat fail pass in 184406-retest Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-vhd 14 migrate-support-check fail in 184406 never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail in 184406 never pass test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184398 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 184398 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184398 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 184398 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184398 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 184398 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184398 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 184398 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184398 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184398 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184398 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 184398 test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass version targeted for testing: xen b25607e528f6ce7851e907ed59ad5ff583aa1840 baseline version: xen
Re: Xen 4.18rc/ARM64 on Raspberry Pi 4B: Traffic in DomU crashing Dom0 when using VLANs
On Sun, Jan 14, 2024 at 10:54:24PM +0100, Paul Leiber wrote: > > Am 22.10.2023 um 07:42 schrieb Paul Leiber: > > Am 13.10.2023 um 20:56 schrieb Paul Leiber: > >> Hi Xen developers list, > >> > >> TL;DR: > >> -- > >> > >> Causing certain web server traffic on a secondary VLAN on Raspberry Pi > >> under vanilla Debian/UEFI in combination with Xen leads to complete > >> system reboot (watchdog triggering for Dom0). Other strange things are > >> happening. > >> > >> Description: > >> -- > >> > >> I recently set up Xen (self compiled, Version 4.18-rc) on a Raspberry > >> Pi 4B (on vanilla Debian Bookworm, UEFI boot mode). Until some time > >> ago, everything worked well with Dom0, one DomU and one bridge. > >> > >> Then I wanted to actually make use of the virtualization and started > >> to set up a second Debian Bookworm DomU (using xen-create-image) for > >> monitoring my systems with zabbix (a webserver based system monitoring > >> solution). The bridge used for this setup was the device bridging the > >> hardware NIC. I installed zabbix, set it up, and everything went well, > >> I could access the web interface without any problem. > >> > >> Then I set up VLANs (initally using VLAN numbers 1 and 2) to separate > >> network traffic between the DomUs. I made the existing device bridge > >> VLAN 1 (bridge 1) and created a secondary device for bridging VLAN 2 > >> (bridge 2). Using only bridge 1 / VLAN 1 everything works well, I can > >> access the zabbix web interface without any noticeable issue. After > >> switching the zabbix DomU to VLAN 2 / bridge 2, everything seemingly > >> keeps on working well, I can ping different devices in my network from > >> the zabbix DomU and vice versa, I can ssh into the machine. > >> > >> However, as soon as I remotely access the zabbix web interface, the > >> complete system (DomUs and Dom0) becomes unresponsive and reboots > >> after some time (usually seconds, sometimes 1-2 minutes). The reboot > >> is reliably reproducable. > >> > >> I didn't see any error message in any log (zabbix, DomU syslog, Dom0 > >> syslog) except for the following lines immediately before the system > >> reboots on the Xen serial console: > >> > >> (XEN) Watchdog timer fired for domain 0 > >> (XEN) Hardware Dom0 shutdown: watchdog rebooting machine > >> > >> As soon as I change the bridge to bridge 1 (with or without VLAN > >> setup), the web interface is accessible again after booting the zabbix > >> DomU, no reboots. > >> > >> So I assume that causing specific traffic on the virtual NIC when > >> using a VLAN setup with more than one VLAN under Xen makes the Dom0 > >> system hard crash. Of course, there might be other causes that I'm not > >> aware of, but to me, this seems to be the most likely explanation > >> right now. > >> > >> What I tried: > >> - > >> > >> 1. I changed the VLAN numbers. First to 101, 102, 103 etc. This was > >> when I noticed another strange thing: VLANs with numbers >99 simply > >> don't work on my Raspberry Pi under Debian, with or without Xen. VLAN > >> 99 works, VLAN 100 (or everything else >99 that I tried) doesn't work. > >> If I choose a number >99, the VLAN is not configured, "ip a" doesn't > >> list it. Other Debian systems on x64 architecture don't show this > >> behavior, there, it was no problem to set up VLANs > 99. Therefore, > >> I've changed the VLANs to 10, 20, 30 etc., which worked. But it didn't > >> solve the initial problem of the crashing Dom0 and DomUs. > >> > >> 2. Different bridge options, without noticable effect: > >> bridge_stp off # dont use STP (spanning tree proto) > >> bridge_waitport 0 # dont wait for port to be available > >> bridge_fd 0 # no forward delay > >> > >> 3. Removing IPv6: No noticable effect. > >> > >> 4. Network traffic analysis: Now, here it becomes _really_ strange. I > >> started tcpdumps on Dom0, and depending on on which interface/bridge > >> traffic was logged, the problem went away, meaning, the DomU was > >> running smoothly for hours, even when accessing the zabbix web > >> interface. Stopping the log makes the system crash (as above, after > >> seconds up to 1-2 minutes) reproducably if I access the zabbix web > >> interface. > >> > >> Logging enabcm6e4ei0 (NIC): no crashes > >> Logging enabcm6e4ei0.10 (VLAN 10): instant crash > >> Logging enabcm6e4ei0.20 (VLAN 20): no crashes > >> Logging xenbr0 (on VLAN 10): instant crash > >> Logging xenbr1 (on VLAN 20): no crashes > >> > >> I am clinging to the thought that there must be a rational explanation > >> for why logging the traffic on certain interfaces/bridges should avoid > >> the crash of the complete system, while logging other > >> interfaces/bridges doesn't. I myself can't think of one. > >> > >> I checked the dumps of enabcm6e4ei0.10 and xenbr0 (where the system > >> crashes) with wireshark, nothing sticks out to me (but I am really no > >> expert in analyzing network
[linux-linus test] 184402: tolerable FAIL - PUSHED
flight 184402 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/184402/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184396 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 184396 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 184396 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 184396 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 184396 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 184396 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184396 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184396 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass version targeted for testing: linux9d1694dc91ce7b80bc96d6d8eaf1a1eca668d847 baseline version: linuxb0d326da462e20285236e11e4cbc32085de9f363 Last test of basis 184396 2024-01-18 20:42:11 Z0 days Testing same since 184402 2024-01-19 05:57:15 Z0 days1 attempts People who touched revisions under test: Abel Vesa Akinobu Mita Alain Volmat Alejandro Jimenez Alex Bee Alex Deucher Alex Williamson Alexander Gordeev Alexander Stein Alexandra Winter Alexandre Belloni Alexandre Ghiti Alexei Starovoitov Alison Schofield Amit Cohen Andi Shyti Andreas Kemnade Andrew Halaney # sa8775p-ride Andrii Nakryiko Andy Shevchenko Andy Yan Anshul Dalal Antoniu Miclaus Ard Biesheuvel Arnd Bergmann Arpana Arland (A Contingent worker at Intel) Arınç ÜNAL Ashish Mhetre Bard Liao Bart Van Assche Bartosz Golaszewski Benjamin Poirier Benjamin Poirier Biju Das Bjorn Helgaas Boris Brezillon Breno Leitao Brett Creeley
Re: Xen 4.19 release management plan
On Tue, 2024-01-16 at 17:48 +0100, Jan Beulich wrote: > (reducing Cc list) > > On 16.01.2024 17:32, Oleksii wrote: > > Please reply with items you would like to see in 4.19 so that > > people > > know what is happening and prioritize accordingly. > > You're welcome to provide a description and use cases of the > > feature > > you're working on. > > The "annotate entry points with type and size" series including as > many > as possible follow-ups on the x86 and Arm side, ideally bringing both > architectures fully in shape for the new model. > > On x86, > - among smaller scope ISA extension work we probably want to make > sure AVX10.1 is going to be usable by guests (patches already > posted), > - "x86: memcpy() / memset() (non-)ERMS flavors plus fallout" > > There's likely more, but let's go with this for now. Thanks for sharing your items. I would suggest that we also pay attention to the following: * NUMA: no need for asm/numa.h when !NUMA * move __read_mostly to xen/cache.h At least, I am really interested in them as they are dependencies for RISC-V patches. Best regards, Oleksii
Re: [PATCH v2 5/5] hw/xen: convert stderr prints to error/warn reports
On 19/1/24 14:24, Manos Pitsidianakis wrote: According to the QEMU Coding Style document: Do not use printf(), fprintf() or monitor_printf(). Instead, use error_report() or error_vreport() from error-report.h. This ensures the error is reported in the right place (current monitor or stderr), and in a uniform format. Use error_printf() & friends to print additional information. This commit changes fprintfs that report warnings and errors to the appropriate report functions. Signed-off-by: Manos Pitsidianakis --- hw/xen/xen-hvm-common.c | 12 ++-- hw/xen/xen-mapcache.c | 5 ++--- 2 files changed, 8 insertions(+), 9 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: Community Process Group - Proposal
Hi Yann, See my reply below On Thu, Jan 18, 2024 at 10:09 AM Yann Dirson wrote: > Hi all, > > On 1/17/24 18:10, Kelly Choi wrote: > > Hi everyone, > > > > I've spent a bit of time talking to various individuals and the advisory > > board about setting up a new Community Process Group. > > > > A survey was recently conducted to identify how the community as a whole > > feels about a certain situation. It was not intended to ban specific > > wording or create a policy to do so, but more to give context that the > > community has a wide range of ideas, and individuals may agree and > > disagree a lot more frequently than we as individuals might think. It > > helps us understand that as a community there are many situations where > > it is not clear. As such, the results indicated a very even split among > > the community, which indicates a larger problem as we may not always > > come to agreement. > > > > There is obvious frustration with how certain matters are handled, as > > some members may want the project to move faster, whereas others like to > > take a cautious approach. Given we are an open source project, > > differences in opinion are likely to happen and what we don’t want to do > > is cause further frustration. > > > > *This is where I would like to propose the idea of a ‘Community Process > > Group’.* > > That made me look for a list of official roles in the project, which I > found at [0]. How up-to-date is this list? The Release Manager role is > mentioned there but not described, the Community Manager role is not > mentioned at all, and the only link to get project leadership info [1] > redirects to unrelated information. > > [0] https://xenproject.org/developers/governance/#roles-local > [1] https://xenproject.org/developers/teams/hypervisor > > I feel it would be necessary to have a clear view on the current > situation, before adding more structures. > Aspects of the information on the website are outdated and do require reviewing as part of a wider governance update. However, the majority of the information such as the roles of committers is still accurate. In this specific instance, the CPG would act fairly similar to a project lead in terms of progressing the project forward. Rather than it being one person, it will be a collective group of elected members. From my understanding, we haven't had a project lead for a very long time within the project and this was before the governance was formalized. If the community is happy, we can replace the project lead role with the CPG. For clarification, this is the current governance policy in relation to the project lead/leadership team: *"Sub-projects and teams hosted on Xenproject.org are not democracies but meritocracies. In situations where there is disagreement on issues related to the day-to-day running of the project, the project leadership team is expected to act as referee and make a decision on behalf of the community. Projects leadership teams can choose to delegate entire classes of conflict resolution issues to community members and/or the project lead (e.g. the project can choose to delegate refereeing on committer disagreements to the project lead; or it could choose a specific committer to always act as referee amongst a group of committers). Any such delegation needs to be approved as normal and has to be documented.* *Should a project leadership team become dysfunctional or paralysed, the project leadership team or project lead should work with the community manager or advisory board to find a way forward.In situations where the entire Xen Project community becomes paralysed the impacted project leadership teams or project leads should work with the community manager or advisory board to find a way forward.* I will take your feedback on board to add descriptions to the release manager role and propose this to the mailing list. You will find the description of the community manager role on the page under 'Xen Project wide roles'. > > > > > A CPG can help as they will be able to advise members on similar issues > > regarding community processes or appeals and decide on the best way > > forward. To help with this process, I have consulted with various > > individuals including some committers and conduct team members. > > * > > What is a CPG’s purpose?* > > In the first instance, we would expect an informal vote resolves most > > disagreements. However, there will be certain circumstances where the > > outcome is not always agreed on. > > > > A CPG will be your second point of call, where you can escalate matters > > quickly for a democratic solution. > > > > Their purpose is to resolve process issues and informal vote appeals to > > avoid matters going to a formal vote, but also act as a representative > > on behalf of others in the community on future matters. > > > > For example: > > > > * Naming conventions > > * Whether feedback requesting changes on a patch series is acceptable > > * How to move forward
Re: Possible bug? DOM-U network stopped working after fatal error reported in DOM0
On Tue, Jan 9, 2024 at 11:28 PM Roger Pau Monné wrote: > > On Tue, Jan 09, 2024 at 12:13:04PM +0100, Niklas Hallqvist wrote: > > > On 14 Dec 2022, at 07:16, G.R. wrote: ... > > > Hi Roger, > > > Just another query of the latest status. It'll be great if you can > > > share a link to the upstream commit. > > > I'm thinking of asking for a back-port of your fix to the FreeNAS > > > community, assuming it will take a long time to roll out otherwise. > > > > > > Thanks, > > > G.R. > > > > > >> > > >> Thanks, Roger. > > > > > > > > > > Hi everyone! > > > > So did anything ever happen on this? I find myself in the same situation > > with TrueNAS core 13, and can’t see any signs of changes in the FreeBSD 13 > > branches. > > Hello, > > I don't think the change is suitable to backport, it's IMO too > intrusive and risky. It was committed late 2022, and it's in 14.0: > ... > TrueNAS/OOPNsense might consider picking it up themselves. > > Thanks, Roger. Just FYI: I was able to locate that commit in 14.0 tree and cherry-picked it into TrueNas 13. I did it last November and the build has been running stably without issue since. The fix was fairly standalone and didn't cause any trouble during the cherry-picking so it could be reasonable to raise a request in the TrueNAS forum. Thanks, G.R.
RE: ACPI VFCT table too short on PVH dom0 (was: Re: E820 memory allocation issue on Threadripper platforms)
[Public] > -Original Message- > From: Huang, Ray > Sent: Friday, January 19, 2024 4:55 AM > To: Patrick Plenefisch > Cc: Roger Pau Monné ; Jan Beulich > ; xen-devel@lists.xenproject.org; Juergen Gross > ; Chen, Jiqian ; Deucher, > Alexander > Subject: Re: ACPI VFCT table too short on PVH dom0 (was: Re: E820 memory > allocation issue on Threadripper platforms) > > On Fri, Jan 19, 2024 at 03:44:35PM +0800, Patrick Plenefisch wrote: > >On Thu, Jan 18, 2024 at 7:41 AM Roger Pau Monné > ><[1]roger@citrix.com> wrote: > > > > From that environment (PVH dom0) can you see if you can dump the > > contents of the VFCT table? I don't have a system with that table, > > so > > not sure if this will work (because iasl is unlikely to know how to > > decode it): > > # acpidump -n VFCT -o table.dump > > # acpixtract -a table.dump > > # iasl -d vfct.dat > > # cat vfct.dsl > > Would be good if you can compare the output from what you get on a > > PV > > dom0 or when running native Linux. > > I'm also adding some AMD folks, as IIRC they did some fixes to Linux > > in order to get some AMD graphics cards running on a PVH dom0, maybe > > they can provide some additional input. > > > >Well, this is pretty weird. I'll go into more details because it may be > >relevant. I had been working with ASRock support ever since I got my > >brand new motherboard because I couldn't see the BIOS/UEFI screens. I > >could boot up, and once native linux took control amdgpu got the > >screens/gpu working fine. I finally managed to be able to see the > >UEFI/BIOS setup screens by patching my VBIOS: I extracted the VBIOS > >image of a cheap R5 430 OEM, ran GOPupd to update the VBIOS UEFI > >component (GOP) from version 1.60 to 1.67. That allowed the UEFI to > >actually initialize and use a screen. However, I later realized that > >only 1 monitor was lighting up in the bios: my monitor plugged into the > >Radeon RX 480 that was still on VBIOS GOP 1.60. It appears the GOP was > >initializing the RX 480 too, despite not being flashed with the latest > >itself. I am working on an email to asrock support about that. Once I > >get into linux (native or PV), both monitors light up as expected. > >Also, If I boot linux PVH from grub, they also work. Those usage > >scenarios have acpidump output as identical. Booting linux PVH directly > >from UEFI (no grub), the monitors go to sleep on the RX 480, and amdgpu > >errors out about VFCT, but the R5 430 OEM does still have output. > >Interestingly, there is a different screen mode booting UEFI+PVH, the > >characters are basically squares, with more vertical lines than > >"default", maybe close to native screen resolution, but horizontally > >it's still "default". Booting from grub gives everything in the > >"default" resolution. > >So what is in the VFCT Table? VFCT contains the non-GOP VIOS image > > of > > Thanks Roger to involve us. The VFCT table is to expose video BIOS image by > AMD GPUs. You can see details here: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers > /gpu/drm/amd/include/atombios.h > > Did you apply this patch? > > https://lore.kernel.org/xen-devel/20230312075455.450187-2- > ray.hu...@amd.com/ > VFCT is generated on the fly by the system bios at boot. The system bios fetches the PCI rom image from the AMD display devices and uses them to populate the VFCT table. Alex > Thanks, > Ray > > >my Radeon RX 480 GPU. You can compare it to the VBIOS hosted at > >[2]https://www.techpowerup.com/vgabios/185789/msi-rx480-4096- > 160720 > >(Compare the end at E667 in the VFCT table to E5ff in that vbios link). > >I find this extra suspicious due to the above. > >Now for the extra horrible things: > >UEFI-booted PVH Linux doesn't support keyboard getty input, and at > >least some of the USB devices are not in lsusb. It also decided to > >vanish one of my HDD's. The `reboot` command hangs. The Power button > >doesn't do anything. There are several stack traces in dmesg. But > >Alt-SysRq-B does reboot! Luckily I could ssh in and capture the ACPI > >tables. They are much smaller, and VFCT is empty. Booting back to one > >of the working scenarios (direct linux, Grub PV, Grub PVH, UEFI PV), > >all of this is normal. > >I've attached: > >xenboot.log which is the serial log of xen+linux booting in UEFI PVH > >(kernel is debian's config, but patched to start at 2MiB) > >dmesg.txt which is the linux dmesg that contains some nice stack traces > >(kernel is debian's config, but patched to start at 2MiB) > >efipvh-tables.dump is ALL acpi tables from UEFI+PVH mode (acpidump -o > >efipvh-tables.dump) > >working-tables.dump is ALL acpi tables from the other modes (acpidump > >-o working-tables.dump)
Re: [PATCH] coverage: filter out lib{fdt,elf}-temp.o
On Fri, Jan 19, 2024 at 09:43:30AM +0100, Michal Orzel wrote: > Is my understanding correct that by switching from extra-y to targets we are > preventing these objects to > appear in non-init-objects (and thus having COV_FLAGS appended) while > retaining the proper if_changed behavior? > > According to docs/misc/xen-makefiles/makefiles.rst: > Any target that utilises if_changed must be listed in $(targets), > otherwise the command line check will fail, and the target will > always be built. Indeed, and $(extra-y) is added to $(targets) via $(targets-for-builtin). While switching from $(extra-y) to $(targets) prevents the objects from been added to $(non-init-objets), it doesn't matter because "libelf.o" is in that variable, so $(COV_FLAGS) is added to $(_c_flags) and its value is used in all the prerequisites of "libelf.o" which includes "libelf-temp.o" and for example "libelf-dominfo.o". So the only thing preventing $(COV_FLAGS) from been added when building "libelf-tools.o" for example is that we set `COV_FLAGS:=` for "libelf.o". Cheers, -- Anthony PERARD
Re: E820 memory allocation issue on Threadripper platforms
On Fri, Jan 19, 2024 at 02:50:38PM +0100, Jan Beulich wrote: > On 19.01.2024 14:40, Marek Marczykowski-Górecki wrote: > > On Thu, Jan 18, 2024 at 01:23:56AM -0500, Patrick Plenefisch wrote: > >> On Wed, Jan 17, 2024 at 3:46 AM Jan Beulich wrote: > >>> On 17.01.2024 07:12, Patrick Plenefisch wrote: > As someone who hasn't built a kernel in over a decade, should I figure > >>> out > how to do a kernel build with CONFIG_PHYSICAL_START=0x200 and report > back? > >>> > >>> That was largely a suggestion to perhaps allow you to gain some > >>> workable setup. It would be of interest to us largely for completeness. > >>> > >> > >> Typo aside, setting the boot to 2MiB works! It works better for PV > > > > Are there any downsides of running kernel with > > CONFIG_PHYSICAL_START=0x20? I can confirm it fixes the issue on > > another affected system, and if there aren't any practical downsides, > > I'm tempted to change it the default kernel in Qubes OS. > > There must have been a reason to make the default 16Mb. You may want > to fish out the commit doing so ... https://git.kernel.org/torvalds/c/ceefccc93932b920 Default CONFIG_PHYSICAL_START and CONFIG_PHYSICAL_ALIGN each to 16 MB, so that both non-relocatable and relocatable kernels are loaded at 16 MB by a non-relocating bootloader. This is somewhat hacky, but it appears to be the only way to do this that does not break some some set of existing bootloaders. We want to avoid the bottom 16 MB because of large page breakup, memory holes, and ZONE_DMA. Embedded systems may need to reduce this, or update their bootloaders to be aware of the new min_alignment field. Large pages (in practice) do not apply to PV dom0, but other points could in theory. That said, I checked few other systems and I don't see any reserved regions there (there is large usable region at 0x10, other reserved regions are near the 4GB boundary). This isn't very representative sample, though... > In Qubes, though, I understand > you're always running with Xen underneath, so unless this same kernel > is also needed to run in HVM guests, some of whatever the reasons may > have been may go away. The same kernel is used for PVH/HVM guests too. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab signature.asc Description: PGP signature
[PATCH v12.3 09/15] vpci/header: program p2m with guest BAR view
From: Oleksandr Andrushchenko
Take into account guest's BAR view and program its p2m accordingly:
gfn is guest's view of the BAR and mfn is the physical BAR value.
This way hardware domain sees physical BAR values and guest sees
emulated ones.
Hardware domain continues getting the BARs identity mapped, while for
domUs the BARs are mapped at the requested guest address without
modifying the BAR address in the device PCI config space.
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Volodymyr Babchuk
Signed-off-by: Stewart Hildebrand
Reviewed-by: Roger Pau Monné
---
In v12.3:
- Update arguments passed to permission error prints in map_range()
In v12.2:
- Slightly tweak print format in modify_bars()
In v12.1:
- ASSERT(rangeset_is_empty()) in modify_bars()
- Fixup print format in modify_bars()
- Make comment single line in bar_write()
- Add Roger's R-b
In v12:
- Update guest_addr in rom_write()
- Use unsigned long for start_mfn and map_mfn to reduce mfn_x() calls
- Use existing vmsix_table_*() functions
- Change vmsix_table_base() to use .guest_addr
In v11:
- Add vmsix_guest_table_addr() and vmsix_guest_table_base() functions
to access guest's view of the VMSIx tables.
- Use MFN (not GFN) to check access permissions
- Move page offset check to this patch
- Call rangeset_remove_range() with correct parameters
In v10:
- Moved GFN variable definition outside the loop in map_range()
- Updated printk error message in map_range()
- Now BAR address is always stored in bar->guest_addr, even for
HW dom, this removes bunch of ugly is_hwdom() checks in modify_bars()
- vmsix_table_base() now uses .guest_addr instead of .addr
In v9:
- Extended the commit message
- Use bar->guest_addr in modify_bars
- Extended printk error message in map_range
- Moved map_data initialization so .bar can be initialized during declaration
Since v5:
- remove debug print in map_range callback
- remove "identity" from the debug print
Since v4:
- moved start_{gfn|mfn} calculation into map_range
- pass vpci_bar in the map_data instead of start_{gfn|mfn}
- s/guest_addr/guest_reg
Since v3:
- updated comment (Roger)
- removed gfn_add(map->start_gfn, rc); which is wrong
- use v->domain instead of v->vpci.pdev->domain
- removed odd e.g. in comment
- s/d%d/%pd in altered code
- use gdprintk for map/unmap logs
Since v2:
- improve readability for data.start_gfn and restructure ?: construct
Since v1:
- s/MSI/MSI-X in comments
---
xen/drivers/vpci/header.c | 84 ++-
xen/include/xen/vpci.h| 3 +-
2 files changed, 67 insertions(+), 20 deletions(-)
diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index feccd070ddd0..61f0660a9b0a 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -34,6 +34,7 @@
struct map_data {
struct domain *d;
+const struct vpci_bar *bar;
bool map;
};
@@ -41,26 +42,38 @@ static int cf_check map_range(
unsigned long s, unsigned long e, void *data, unsigned long *c)
{
const struct map_data *map = data;
+/* Start address of the BAR as seen by the guest. */
+unsigned long start_gfn = PFN_DOWN(map->bar->guest_addr);
+/* Physical start address of the BAR. */
+unsigned long start_mfn = PFN_DOWN(map->bar->addr);
int rc;
for ( ; ; )
{
unsigned long size = e - s + 1;
+/*
+ * Ranges to be mapped don't always start at the BAR start address, as
+ * there can be holes or partially consumed ranges. Account for the
+ * offset of the current address from the BAR start.
+ */
+unsigned long map_mfn = start_mfn + s - start_gfn;
+unsigned long m_end = map_mfn + size - 1;
-if ( !iomem_access_permitted(map->d, s, e) )
+if ( !iomem_access_permitted(map->d, map_mfn, m_end) )
{
printk(XENLOG_G_WARNING
"%pd denied access to MMIO range [%#lx, %#lx]\n",
- map->d, s, e);
+ map->d, map_mfn, m_end);
return -EPERM;
}
-rc = xsm_iomem_mapping(XSM_HOOK, map->d, s, e, map->map);
+rc = xsm_iomem_mapping(XSM_HOOK, map->d, map_mfn, m_end,
+ map->map);
if ( rc )
{
printk(XENLOG_G_WARNING
"%pd XSM denied access to MMIO range [%#lx, %#lx]: %d\n",
- map->d, s, e, rc);
+ map->d, map_mfn, m_end, rc);
return rc;
}
@@ -73,8 +86,8 @@ static int cf_check map_range(
* - {un}map_mmio_regions doesn't support preemption.
*/
-rc = map->map ? map_mmio_regions(map->d, _gfn(s), size, _mfn(s))
- : unmap_mmio_regions(map->d, _gfn(s), size, _mfn(s));
+rc = map->map ? map_mmio_regions(map->d, _gfn(s), size, _mfn(map_mfn))
+ : unmap_mmio_regions(map->d, _gfn(s), size,
_mfn(map_mfn));
if ( rc == 0 )
{
[libvirt test] 184401: tolerable all pass - PUSHED
flight 184401 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/184401/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184389 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184389 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 184389 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 15 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass version targeted for testing: libvirt 8581ec7e68d5d656d7121cf77206b47dc6b261c4 baseline version: libvirt 5df470f47d02e39a5c6a80e78f54d8ddf98d80af Last test of basis 184389 2024-01-18 04:20:45 Z1 days Testing same since 184401 2024-01-19 04:18:53 Z0 days1 attempts People who touched revisions under test: Ján Tomko jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at
Re: E820 memory allocation issue on Threadripper platforms
On 19.01.2024 14:40, Marek Marczykowski-Górecki wrote: > On Thu, Jan 18, 2024 at 01:23:56AM -0500, Patrick Plenefisch wrote: >> On Wed, Jan 17, 2024 at 3:46 AM Jan Beulich wrote: >>> On 17.01.2024 07:12, Patrick Plenefisch wrote: As someone who hasn't built a kernel in over a decade, should I figure >>> out how to do a kernel build with CONFIG_PHYSICAL_START=0x200 and report back? >>> >>> That was largely a suggestion to perhaps allow you to gain some >>> workable setup. It would be of interest to us largely for completeness. >>> >> >> Typo aside, setting the boot to 2MiB works! It works better for PV > > Are there any downsides of running kernel with > CONFIG_PHYSICAL_START=0x20? I can confirm it fixes the issue on > another affected system, and if there aren't any practical downsides, > I'm tempted to change it the default kernel in Qubes OS. There must have been a reason to make the default 16Mb. You may want to fish out the commit doing so ... In Qubes, though, I understand you're always running with Xen underneath, so unless this same kernel is also needed to run in HVM guests, some of whatever the reasons may have been may go away. Jan
Re: [PATCH v12.2 09/15] vpci/header: program p2m with guest BAR view
On Tue, Jan 16, 2024 at 10:01:24PM -0500, Stewart Hildebrand wrote:
> On 1/15/24 14:44, Stewart Hildebrand wrote:
> > diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
> > index feccd070ddd0..8483404c5e91 100644
> > --- a/xen/drivers/vpci/header.c
> > +++ b/xen/drivers/vpci/header.c
> > @@ -41,13 +42,24 @@ static int cf_check map_range(
> > unsigned long s, unsigned long e, void *data, unsigned long *c)
> > {
> > const struct map_data *map = data;
> > +/* Start address of the BAR as seen by the guest. */
> > +unsigned long start_gfn = PFN_DOWN(map->bar->guest_addr);
> > +/* Physical start address of the BAR. */
> > +unsigned long start_mfn = PFN_DOWN(map->bar->addr);
> > int rc;
> >
> > for ( ; ; )
> > {
> > unsigned long size = e - s + 1;
> > +/*
> > + * Ranges to be mapped don't always start at the BAR start
> > address, as
> > + * there can be holes or partially consumed ranges. Account for the
> > + * offset of the current address from the BAR start.
> > + */
> > +unsigned long map_mfn = start_mfn + s - start_gfn;
> > +unsigned long m_end = map_mfn + size - 1;
> >
> > -if ( !iomem_access_permitted(map->d, s, e) )
> > +if ( !iomem_access_permitted(map->d, map_mfn, m_end) )
>
> Nit: since this check will now use map_mfn and m_end...
>
> > {
> > printk(XENLOG_G_WARNING
> > "%pd denied access to MMIO range [%#lx, %#lx]\n",
> > map->d, s, e);
>
> ... I'd like to also update the arguments passed to this print statement.
Indeed. You will need a new version.
Thanks, Roger.
Re: [PATCH v12.2 01/15] vpci: use per-domain PCI lock to protect vpci structure
On Mon, Jan 15, 2024 at 02:43:08PM -0500, Stewart Hildebrand wrote: > From: Oleksandr Andrushchenko > > Use the per-domain PCI read/write lock to protect the presence of the > pci device vpci field. This lock can be used (and in a few cases is used > right away) so that vpci removal can be performed while holding the lock > in write mode. Previously such removal could race with vpci_read for > example. > > When taking both d->pci_lock and pdev->vpci->lock, they should be > taken in this exact order: d->pci_lock then pdev->vpci->lock to avoid > possible deadlock situations. > > 1. Per-domain's pci_lock is used to protect pdev->vpci structure > from being removed. > > 2. Writing the command register and ROM BAR register may trigger > modify_bars to run, which in turn may access multiple pdevs while > checking for the existing BAR's overlap. The overlapping check, if > done under the read lock, requires vpci->lock to be acquired on both > devices being compared, which may produce a deadlock. It is not > possible to upgrade read lock to write lock in such a case. So, in > order to prevent the deadlock, use d->pci_lock in write mode instead. > > All other code, which doesn't lead to pdev->vpci destruction and does > not access multiple pdevs at the same time, can still use a > combination of the read lock and pdev->vpci->lock. > > 3. Drop const qualifier where the new rwlock is used and this is > appropriate. > > 4. Do not call process_pending_softirqs with any locks held. For that > unlock prior the call and re-acquire the locks after. After > re-acquiring the lock there is no need to check if pdev->vpci exists: > - in apply_map because of the context it is called (no race condition >possible) > - for MSI/MSI-X debug code because it is called at the end of >pdev->vpci access and no further access to pdev->vpci is made > > 5. Use d->pci_lock around for_each_pdev and pci_get_pdev_by_domain > while accessing pdevs in vpci code. > > Suggested-by: Roger Pau Monné > Suggested-by: Jan Beulich > Signed-off-by: Oleksandr Andrushchenko > Signed-off-by: Volodymyr Babchuk > Signed-off-by: Stewart Hildebrand Reviewed-by: Roger Pau Monné Thanks, Roger.
Re: E820 memory allocation issue on Threadripper platforms
On Thu, Jan 18, 2024 at 01:23:56AM -0500, Patrick Plenefisch wrote: > On Wed, Jan 17, 2024 at 3:46 AM Jan Beulich wrote: > > On 17.01.2024 07:12, Patrick Plenefisch wrote: > > > As someone who hasn't built a kernel in over a decade, should I figure > > out > > > how to do a kernel build with CONFIG_PHYSICAL_START=0x200 and report > > > back? > > > > That was largely a suggestion to perhaps allow you to gain some > > workable setup. It would be of interest to us largely for completeness. > > > > Typo aside, setting the boot to 2MiB works! It works better for PV Are there any downsides of running kernel with CONFIG_PHYSICAL_START=0x20? I can confirm it fixes the issue on another affected system, and if there aren't any practical downsides, I'm tempted to change it the default kernel in Qubes OS. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab signature.asc Description: PGP signature
[PATCH v2 4/5] hw/xen/xen-hvm-common.c: convert DPRINTF to tracepoints
Tracing DPRINTFs to stderr might not be desired. A developer that relies
on tracepoints should be able to opt-in to each tracepoint and rely on
QEMU's log redirection, instead of stderr by default.
This commit converts DPRINTFs in this file that are used for tracing
into tracepoints.
Signed-off-by: Manos Pitsidianakis
---
hw/xen/trace-events | 10 +-
hw/xen/xen-hvm-common.c | 35 ++-
2 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/hw/xen/trace-events b/hw/xen/trace-events
index 1b748dba09..dd5b5a7f35 100644
--- a/hw/xen/trace-events
+++ b/hw/xen/trace-events
@@ -42,7 +42,7 @@ xs_node_vscanf(char *path, char *value) "%s %s"
xs_node_watch(char *path) "%s"
xs_node_unwatch(char *path) "%s"
-# xen-hvm.c
+# xen-hvm-common.c
xen_ram_alloc(unsigned long ram_addr, unsigned long size) "requested: 0x%lx,
size 0x%lx"
xen_client_set_memory(uint64_t start_addr, unsigned long size, bool log_dirty)
"0x%"PRIx64" size 0x%lx, log_dirty %i"
handle_ioreq(void *req, uint32_t type, uint32_t dir, uint32_t df, uint32_t
data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size)
"I/O=%p type=%d dir=%d df=%d ptr=%d port=0x%"PRIx64" data=0x%"PRIx64" count=%d
size=%d"
@@ -55,6 +55,14 @@ cpu_ioreq_move(void *req, uint32_t dir, uint32_t df,
uint32_t data_is_ptr, uint6
xen_map_resource_ioreq(uint32_t id, void *addr) "id: %u addr: %p"
cpu_ioreq_config_read(void *req, uint32_t sbdf, uint32_t reg, uint32_t size,
uint32_t data) "I/O=%p sbdf=0x%x reg=%u size=%u data=0x%x"
cpu_ioreq_config_write(void *req, uint32_t sbdf, uint32_t reg, uint32_t size,
uint32_t data) "I/O=%p sbdf=0x%x reg=%u size=%u data=0x%x"
+cpu_get_ioreq_from_shared_memory_req_not_ready(int state, int data_is_ptr,
uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O request not
ready: 0x%x, ptr: 0x%x, port: 0x%"PRIx64", data: 0x%"PRIx64", count: %u, size:
%u"
+xen_main_loop_prepare_init_cpu(int id, void *cpu) "cpu_by_vcpu_id[%d]=%p"
+xen_map_ioreq_server_shared_page(long unsigned int ioreq_pfn) "shared page at
pfn 0x%lx"
+xen_map_ioreq_server_buffered_io_page(long unsigned int ioreq_pfn) "buffered
io page at pfn 0x%lx"
+xen_map_ioreq_server_buffered_io_evtchn(int bufioreq_evtchn) "buffered io
evtchn is 0x%x"
+destroy_hvm_domain_cannot_acquire_handle(void) "Cannot acquire xenctrl handle"
+destroy_hvm_domain_failed_action(const char *action, int sts, char *errno_s)
"xc_domain_shutdown failed to issue %s, sts %d, %s"
+destroy_hvm_domain_action(int xen_domid, const char *action) "Issued domain %d
%s"
# xen-mapcache.c
xen_map_cache(uint64_t phys_addr) "want 0x%"PRIx64
diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-common.c
index 47e6cb1db3..05a29c6f11 100644
--- a/hw/xen/xen-hvm-common.c
+++ b/hw/xen/xen-hvm-common.c
@@ -169,11 +169,12 @@ static ioreq_t
*cpu_get_ioreq_from_shared_memory(XenIOState *state, int vcpu)
ioreq_t *req = xen_vcpu_ioreq(state->shared_page, vcpu);
if (req->state != STATE_IOREQ_READY) {
-DPRINTF("I/O request not ready: "
-"%x, ptr: %x, port: %"PRIx64", "
-"data: %"PRIx64", count: %u, size: %u\n",
-req->state, req->data_is_ptr, req->addr,
-req->data, req->count, req->size);
+trace_cpu_get_ioreq_from_shared_memory_req_not_ready(req->state,
+ req->data_is_ptr,
+ req->addr,
+ req->data,
+ req->count,
+ req->size);
return NULL;
}
@@ -601,10 +602,9 @@ static void xen_main_loop_prepare(XenIOState *state)
if (evtchn_fd != -1) {
CPUState *cpu_state;
-DPRINTF("%s: Init cpu_by_vcpu_id\n", __func__);
CPU_FOREACH(cpu_state) {
-DPRINTF("%s: cpu_by_vcpu_id[%d]=%p\n",
-__func__, cpu_state->cpu_index, cpu_state);
+trace_xen_main_loop_prepare_init_cpu(cpu_state->cpu_index,
+ cpu_state);
state->cpu_by_vcpu_id[cpu_state->cpu_index] = cpu_state;
}
qemu_set_fd_handler(evtchn_fd, cpu_handle_ioreq, NULL, state);
@@ -681,7 +681,7 @@ static int xen_map_ioreq_server(XenIOState *state)
}
if (state->shared_page == NULL) {
-DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
+trace_xen_map_ioreq_server_shared_page(ioreq_pfn);
state->shared_page = xenforeignmemory_map(xen_fmem, xen_domid,
PROT_READ | PROT_WRITE,
@@ -693,7 +693,7 @@ static int xen_map_ioreq_server(XenIOState *state)
}
if (state->buffered_io_page == NULL) {
-DPRINTF("buffered io page at pfn %lx\n", bufioreq_pfn);
+
[PATCH v2 5/5] hw/xen: convert stderr prints to error/warn reports
According to the QEMU Coding Style document:
> Do not use printf(), fprintf() or monitor_printf(). Instead, use
> error_report() or error_vreport() from error-report.h. This ensures the
> error is reported in the right place (current monitor or stderr), and in
> a uniform format.
> Use error_printf() & friends to print additional information.
This commit changes fprintfs that report warnings and errors to the
appropriate report functions.
Signed-off-by: Manos Pitsidianakis
---
hw/xen/xen-hvm-common.c | 12 ++--
hw/xen/xen-mapcache.c | 5 ++---
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-common.c
index 05a29c6f11..baa1adb9f2 100644
--- a/hw/xen/xen-hvm-common.c
+++ b/hw/xen/xen-hvm-common.c
@@ -20,8 +20,8 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
MemoryRegion *mr,
if (runstate_check(RUN_STATE_INMIGRATE)) {
/* RAM already populated in Xen */
-fprintf(stderr, "%s: do not alloc "RAM_ADDR_FMT
-" bytes of ram at "RAM_ADDR_FMT" when runstate is INMIGRATE\n",
+warn_report("%s: do not alloc "RAM_ADDR_FMT
+" bytes of ram at "RAM_ADDR_FMT" when runstate is INMIGRATE",
__func__, size, ram_addr);
return;
}
@@ -552,9 +552,9 @@ static void cpu_handle_ioreq(void *opaque)
req->data = copy.data;
if (req->state != STATE_IOREQ_INPROCESS) {
-fprintf(stderr, "Badness in I/O request ... not in service?!: "
+warn_report("Badness in I/O request ... not in service?!: "
"%x, ptr: %x, port: %"PRIx64", "
-"data: %"PRIx64", count: %u, size: %u, type: %u\n",
+"data: %"PRIx64", count: %u, size: %u, type: %u",
req->state, req->data_is_ptr, req->addr,
req->data, req->count, req->size, req->type);
destroy_hvm_domain(false);
@@ -758,9 +758,9 @@ void xen_shutdown_fatal_error(const char *fmt, ...)
va_list ap;
va_start(ap, fmt);
-vfprintf(stderr, fmt, ap);
+error_vreport(fmt, ap);
va_end(ap);
-fprintf(stderr, "Will destroy the domain.\n");
+error_report("Will destroy the domain.");
/* destroy the domain */
qemu_system_shutdown_request(SHUTDOWN_CAUSE_HOST_ERROR);
}
diff --git a/hw/xen/xen-mapcache.c b/hw/xen/xen-mapcache.c
index 336c212376..4f956d048e 100644
--- a/hw/xen/xen-mapcache.c
+++ b/hw/xen/xen-mapcache.c
@@ -347,9 +347,8 @@ tryagain:
MapCacheRev *reventry = g_new0(MapCacheRev, 1);
entry->lock++;
if (entry->lock == 0) {
-fprintf(stderr,
-"mapcache entry lock overflow: "HWADDR_FMT_plx" -> %p\n",
-entry->paddr_index, entry->vaddr_base);
+error_report("mapcache entry lock overflow: "HWADDR_FMT_plx" ->
%p",
+ entry->paddr_index, entry->vaddr_base);
abort();
}
reventry->dma = dma;
--
γαῖα πυρί μιχθήτω
[PATCH v2 3/5] hw/xen/xen-mapcache.c: convert DPRINTF to tracepoints
Tracing DPRINTFs to stderr might not be desired. A developer that relies
on tracepoints should be able to opt-in to each tracepoint and rely on
QEMU's log redirection, instead of stderr by default.
This commit converts DPRINTFs in this file that are used for tracing
into tracepoints.
Signed-off-by: Manos Pitsidianakis
---
hw/xen/trace-events | 11 +
hw/xen/xen-mapcache.c | 54 +++
2 files changed, 35 insertions(+), 30 deletions(-)
diff --git a/hw/xen/trace-events b/hw/xen/trace-events
index 67a6c41926..1b748dba09 100644
--- a/hw/xen/trace-events
+++ b/hw/xen/trace-events
@@ -60,3 +60,14 @@ cpu_ioreq_config_write(void *req, uint32_t sbdf, uint32_t
reg, uint32_t size, ui
xen_map_cache(uint64_t phys_addr) "want 0x%"PRIx64
xen_remap_bucket(uint64_t index) "index 0x%"PRIx64
xen_map_cache_return(void* ptr) "%p"
+xen_map_cache_init(uint64_t nr_buckets, uint64_t size) "nr_buckets = 0x%lx
size %lu"
+xen_replace_cache_entry_dummy(uint64_t old_phys_addr, uint64_t new_phys_addr)
"Replacing a dummy mapcache entry for 0x%"PRIx64" with 0x%"PRIx64
+xen_invalidate_map_cache_entry_unlocked_not_found(void *p) "could not find %p"
+xen_invalidate_map_cache_entry_unlocked_found(uint64_t addr, void *p) "
0x%"PRIx64" -> %p is present"
+xen_invalidate_map_cache_entry_unlocked_miss(void *buffer) "Trying to unmap
address %p that is not in the mapcache"
+xen_replace_cache_entry_unlocked_could_not_update_entry(uint64_t
old_phys_addr) "Unable to update a mapcache entry for 0x%"PRIx64
+xen_ram_addr_from_mapcache_not_found(void *p) "could not find %p"
+xen_ram_addr_from_mapcache_found(uint64_t addr, void *p) " 0x%"PRIx64" -> %p
is present"
+xen_ram_addr_from_mapcache_not_in_cache(void *p) "Trying to find address %p
that is not in the mapcache"
+xen_replace_cache_entry_unlocked(uint64_t old_phys_addr) "Trying to update an
entry for 0x%"PRIx64" that is not in the mapcache"
+xen_invalidate_map_cache(uint64_t paddr_index, void *vaddr_req) "Locked DMA
mapping while invalidating mapcache 0x%"PRIx64" -> %p is present"
diff --git a/hw/xen/xen-mapcache.c b/hw/xen/xen-mapcache.c
index f7d974677d..336c212376 100644
--- a/hw/xen/xen-mapcache.c
+++ b/hw/xen/xen-mapcache.c
@@ -22,16 +22,6 @@
#include "trace.h"
-//#define MAPCACHE_DEBUG
-
-#ifdef MAPCACHE_DEBUG
-# define DPRINTF(fmt, ...) do { \
-fprintf(stderr, "xen_mapcache: " fmt, ## __VA_ARGS__); \
-} while (0)
-#else
-# define DPRINTF(fmt, ...) do { } while (0)
-#endif
-
#if HOST_LONG_BITS == 32
# define MCACHE_BUCKET_SHIFT 16
# define MCACHE_MAX_SIZE (1UL<<31) /* 2GB Cap */
@@ -145,8 +135,7 @@ void xen_map_cache_init(phys_offset_to_gaddr_t f, void
*opaque)
size = mapcache->nr_buckets * sizeof (MapCacheEntry);
size = (size + XC_PAGE_SIZE - 1) & ~(XC_PAGE_SIZE - 1);
-DPRINTF("%s, nr_buckets = %lx size %lu\n", __func__,
-mapcache->nr_buckets, size);
+trace_xen_map_cache_init(mapcache->nr_buckets, size);
mapcache->entry = g_malloc0(size);
}
@@ -286,7 +275,9 @@ tryagain:
test_bits(address_offset >> XC_PAGE_SHIFT,
test_bit_size >> XC_PAGE_SHIFT,
mapcache->last_entry->valid_mapping)) {
-trace_xen_map_cache_return(mapcache->last_entry->vaddr_base +
address_offset);
+trace_xen_map_cache_return(
+mapcache->last_entry->vaddr_base + address_offset
+);
return mapcache->last_entry->vaddr_base + address_offset;
}
@@ -368,7 +359,9 @@ tryagain:
QTAILQ_INSERT_HEAD(>locked_entries, reventry, next);
}
-trace_xen_map_cache_return(mapcache->last_entry->vaddr_base +
address_offset);
+trace_xen_map_cache_return(
+mapcache->last_entry->vaddr_base + address_offset
+);
return mapcache->last_entry->vaddr_base + address_offset;
}
@@ -402,10 +395,10 @@ ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
}
}
if (!found) {
-fprintf(stderr, "%s, could not find %p\n", __func__, ptr);
+trace_xen_ram_addr_from_mapcache_not_found(ptr);
QTAILQ_FOREACH(reventry, >locked_entries, next) {
-DPRINTF(" "HWADDR_FMT_plx" -> %p is present\n",
reventry->paddr_index,
-reventry->vaddr_req);
+trace_xen_ram_addr_from_mapcache_found(reventry->paddr_index,
+ reventry->vaddr_req);
}
abort();
return 0;
@@ -416,7 +409,7 @@ ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
entry = entry->next;
}
if (!entry) {
-DPRINTF("Trying to find address %p that is not in the mapcache!\n",
ptr);
+trace_xen_ram_addr_from_mapcache_not_in_cache(ptr);
raddr = 0;
} else {
raddr = (reventry->paddr_index << MCACHE_BUCKET_SHIFT) +
@@ -443,9 +436,12 @@ static void
xen_invalidate_map_cache_entry_unlocked(uint8_t *buffer)
}
}
if (!found) {
-DPRINTF("%s,
Re: ACPI VFCT table too short on PVH dom0 (was: Re: E820 memory allocation issue on Threadripper platforms)
On Fri, Jan 19, 2024 at 02:44:35AM -0500, Patrick Plenefisch wrote: > On Thu, Jan 18, 2024 at 7:41 AM Roger Pau Monné > wrote: > > > > > From that environment (PVH dom0) can you see if you can dump the > > contents of the VFCT table? I don't have a system with that table, so > > not sure if this will work (because iasl is unlikely to know how to > > decode it): > > > > # acpidump -n VFCT -o table.dump > > # acpixtract -a table.dump > > # iasl -d vfct.dat > > # cat vfct.dsl > > > > Would be good if you can compare the output from what you get on a PV > > dom0 or when running native Linux. > > > > I'm also adding some AMD folks, as IIRC they did some fixes to Linux > > in order to get some AMD graphics cards running on a PVH dom0, maybe > > they can provide some additional input. > > > > > Well, this is pretty weird. I'll go into more details because it may be > relevant. Wow, you have certainly gone out of the beaten path here. > I had been working with ASRock support ever since I got my brand > new motherboard because I couldn't see the BIOS/UEFI screens. I could boot > up, and once native linux took control amdgpu got the screens/gpu working > fine. I finally managed to be able to see the UEFI/BIOS setup screens by > patching my VBIOS: I extracted the VBIOS image of a cheap R5 430 OEM, ran > GOPupd to update the VBIOS UEFI component (GOP) from version 1.60 to 1.67. > That allowed the UEFI to actually initialize and use a screen. However, I > later realized that only 1 monitor was lighting up in the bios: my monitor > plugged into the Radeon RX 480 that was still on VBIOS GOP 1.60. It appears > the GOP was initializing the RX 480 too, despite not being flashed with the > latest itself. I am working on an email to asrock support about that. Once > I get into linux (native or PV), both monitors light up as expected. Also, > If I boot linux PVH from grub, they also work. OK, that's good, so that would be UEFI -> grub -> Xen -> Linux PVH? > Those usage scenarios have > acpidump output as identical. Booting linux PVH directly from UEFI (no > grub), the monitors go to sleep on the RX 480, and amdgpu errors out about > VFCT, but the R5 430 OEM does still have output. Interestingly, there is a > different screen mode booting UEFI+PVH, the characters are basically > squares, with more vertical lines than "default", maybe close to native > screen resolution, but horizontally it's still "default". Booting from grub > gives everything in the "default" resolution. Hm, maybe we are not passing the correct video information to Linux dom0 when booted from UEFI. I'm afraid I don't have such setup myself, so it's going to be hard to test. To clarify, the output from Xen is fine, is the video output from Linux dom0 in PVH mode that's corrupt? > > So what is in the VFCT Table? VFCT contains the non-GOP VIOS image of my > Radeon RX 480 GPU. You can compare it to the VBIOS hosted at > https://www.techpowerup.com/vgabios/185789/msi-rx480-4096-160720 (Compare > the end at E667 in the VFCT table to E5ff in that vbios link). I find this > extra suspicious due to the above. > > Now for the extra horrible things: > > UEFI-booted PVH Linux doesn't support keyboard getty input, and at least > some of the USB devices are not in lsusb. It also decided to vanish one of > my HDD's. The `reboot` command hangs. The Power button doesn't do anything. Yes, it does seem Lunux has issues reserving some BARs: [6.520615] ahci :07:00.1: version 3.0 [6.520701] ahci :07:00.1: BAR 5: can't reserve [mem 0xf0e0-0xf0e007ff] ... [ 17.130099] ccp :06:00.5: enabling device ( -> 0002) [ 17.137025] ccp :06:00.5: BAR 2: can't reserve [mem 0xf0b0-0xf0bf] [ 17.145210] ccp :06:00.5: pcim_iomap_regions failed (-16) [ 17.151868] ccp :06:00.5: initialization failed [ 17.157615] ccp: probe of :06:00.5 failed with error -16 ... [ 17.993532] snd_hda_intel :01:00.1: enabling device ( -> 0002) [ 18.001207] snd_hda_intel :01:00.1: Force to non-snoop mode [ 18.007997] snd_hda_intel :01:00.1: BAR 0: can't reserve [mem 0xf0f6-0xf0f63fff 64bit] [ 18.018053] snd_hda_intel :06:00.7: enabling device ( -> 0002) [ 18.025723] snd_hda_intel :06:00.7: BAR 0: can't reserve [mem 0xf0d0-0xf0d07fff] [ 18.033679] snd_hda_intel :41:00.1: enabling device ( -> 0002) [ 18.043165] snd_hda_intel :41:00.1: Force to non-snoop mode I bet this because Xen balloon driver has started picking up those regions in order to map foreign pages. > There are several stack traces in dmesg. But Alt-SysRq-B does reboot! > Luckily I could ssh in and capture the ACPI tables. They are much smaller, > and VFCT is empty. Booting back to one of the working scenarios (direct > linux, Grub PV, Grub PVH, UEFI PV), all of this is normal. > > I've attached: > > xenboot.log which is the serial log of xen+linux booting in UEFI PVH > (kernel is debian's config, but patched to
Re: [PATCH v3] x86/xen: Add some null pointer checking to smp.c
> kasprintf() returns a pointer to dynamically allocated memory > which can be NULL upon failure. Ensure the allocation was successful > by checking the pointer validity. … > --- > Changes in v3: > - Remove rc initialization > - Simply error paths by adding a new label 'fail_mem' … I became curious if you would like to simplify further source code places. > +++ b/arch/x86/xen/smp.c > @@ -65,6 +65,8 @@ int xen_smp_intr_init(unsigned int cpu) > char *resched_name, *callfunc_name, *debug_name; > > resched_name = kasprintf(GFP_KERNEL, "resched%d", cpu); > + if (!resched_name) > + goto fail_mem; Would you like to add a blank line after such a statement? > per_cpu(xen_resched_irq, cpu).name = resched_name; … Please compare with your subsequent suggestion. … > @@ -101,6 +108,9 @@ int xen_smp_intr_init(unsigned int cpu) > } > > callfunc_name = kasprintf(GFP_KERNEL, "callfuncsingle%d", cpu); > + if (!callfunc_name) > + goto fail_mem; > + > per_cpu(xen_callfuncsingle_irq, cpu).name = callfunc_name; … Regards, Markus
Re: [PATCH v5 8/8] common: honor CONFIG_CC_SPLIT_SECTIONS also for assembly functions
On Mon, Jan 15, 2024 at 03:40:19PM +0100, Jan Beulich wrote: > Leverage the new infrastructure in xen/linkage.h to also switch to per- > function sections (when configured), deriving the specific name from the > "base" section in use at the time FUNC() is invoked. > > Signed-off-by: Jan Beulich > --- > TBD: Since we use .subsection in UNLIKELY_START(), a perhaps not really > wanted side effect of this change is that respective out-of-line > code now moves much closer to its original (invoking) code. Hm, I'm afraid I don't have much useful suggestions here. > TBD: Of course something with the same overall effect, but less > impactful might do in Config.mk. E.g. $(filter-out -D%,$(3)) > instead of $(firstword (3)). I don't have a strong opinion re those two options My preference however (see below for reasoning) would be to put this detection in Kconfig. > TBD: On top of Roger's respective patch (for livepatch), also respect > CONFIG_FUNCTION_ALIGNMENT. I think you can drop that, as the series is blocked. > Note that we'd need to split DATA() in order to separate r/w and r/o > contributions. Further splitting might be needed to also support more > advanced attributes (e.g. merge), hence why this isn't done right here. > Sadly while a new section's name can be derived from the presently in > use, its attributes cannot be. Perhaps the only thing we can do is give > DATA() a 2nd mandatory parameter. Then again I guess most data > definitions could be moved to C anyway. > --- > v5: Re-base over changes earlier in the series. > v4: Re-base. > v2: Make detection properly fail on old gas (by adjusting > cc-option-add-closure). > > --- a/Config.mk > +++ b/Config.mk > @@ -102,7 +102,7 @@ cc-option = $(shell if $(1) $(2:-Wno-%=- > # Usage: $(call cc-option-add CFLAGS,CC,-march=winchip-c6) > cc-option-add = $(eval $(call cc-option-add-closure,$(1),$(2),$(3))) > define cc-option-add-closure > -ifneq ($$(call cc-option,$$($(2)),$(3),n),n) > +ifneq ($$(call cc-option,$$($(2)),$(firstword $(3)),n),n) > $(1) += $(3) > endif > endef > --- a/xen/Makefile > +++ b/xen/Makefile > @@ -409,6 +409,9 @@ AFLAGS += -D__ASSEMBLY__ > > $(call cc-option-add,AFLAGS,CC,-Wa$$(comma)--noexecstack) > > +# Check to see whether the assmbler supports the --sectname-subst option. > +$(call cc-option-add,AFLAGS,CC,-Wa$$(comma)--sectname-subst > -DHAVE_AS_SECTNAME_SUBST) I guess you already know what I'm going to comment on. I think this would be clearer if it was a Kconfig option. For once because I think we should gate livapatch support on the option being available, and secondly it would avoid having to pass the extra -D around. I think it's relevant to have a consistent set of build tool options requirements for livepatch support, so that when enabled the support is consistent across builds. With this approach livepatch could be enabled in Kconfig, but depending on the tools support the resulting binary might or might not support live patching of assembly code. Such behavior is IMO unhelpful from a user PoV, and can lead to surprises down the road. Thanks, Roger.
Re: ACPI VFCT table too short on PVH dom0 (was: Re: E820 memory allocation issue on Threadripper platforms)
On Fri, Jan 19, 2024 at 03:44:35PM +0800, Patrick Plenefisch wrote: >On Thu, Jan 18, 2024 at 7:41 AM Roger Pau Monné ><[1]roger@citrix.com> wrote: > > From that environment (PVH dom0) can you see if you can dump the > contents of the VFCT table? I don't have a system with that table, > so > not sure if this will work (because iasl is unlikely to know how to > decode it): > # acpidump -n VFCT -o table.dump > # acpixtract -a table.dump > # iasl -d vfct.dat > # cat vfct.dsl > Would be good if you can compare the output from what you get on a > PV > dom0 or when running native Linux. > I'm also adding some AMD folks, as IIRC they did some fixes to Linux > in order to get some AMD graphics cards running on a PVH dom0, maybe > they can provide some additional input. > >Well, this is pretty weird. I'll go into more details because it may be >relevant. I had been working with ASRock support ever since I got my >brand new motherboard because I couldn't see the BIOS/UEFI screens. I >could boot up, and once native linux took control amdgpu got the >screens/gpu working fine. I finally managed to be able to see the >UEFI/BIOS setup screens by patching my VBIOS: I extracted the VBIOS >image of a cheap R5 430 OEM, ran GOPupd to update the VBIOS UEFI >component (GOP) from version 1.60 to 1.67. That allowed the UEFI to >actually initialize and use a screen. However, I later realized that >only 1 monitor was lighting up in the bios: my monitor plugged into the >Radeon RX 480 that was still on VBIOS GOP 1.60. It appears the GOP was >initializing the RX 480 too, despite not being flashed with the latest >itself. I am working on an email to asrock support about that. Once I >get into linux (native or PV), both monitors light up as expected. >Also, If I boot linux PVH from grub, they also work. Those usage >scenarios have acpidump output as identical. Booting linux PVH directly >from UEFI (no grub), the monitors go to sleep on the RX 480, and amdgpu >errors out about VFCT, but the R5 430 OEM does still have output. >Interestingly, there is a different screen mode booting UEFI+PVH, the >characters are basically squares, with more vertical lines than >"default", maybe close to native screen resolution, but horizontally >it's still "default". Booting from grub gives everything in the >"default" resolution. >So what is in the VFCT Table? VFCT contains the non-GOP VIOS image of Thanks Roger to involve us. The VFCT table is to expose video BIOS image by AMD GPUs. You can see details here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/include/atombios.h Did you apply this patch? https://lore.kernel.org/xen-devel/20230312075455.450187-2-ray.hu...@amd.com/ Thanks, Ray >my Radeon RX 480 GPU. You can compare it to the VBIOS hosted at >[2]https://www.techpowerup.com/vgabios/185789/msi-rx480-4096-160720 >(Compare the end at E667 in the VFCT table to E5ff in that vbios link). >I find this extra suspicious due to the above. >Now for the extra horrible things: >UEFI-booted PVH Linux doesn't support keyboard getty input, and at >least some of the USB devices are not in lsusb. It also decided to >vanish one of my HDD's. The `reboot` command hangs. The Power button >doesn't do anything. There are several stack traces in dmesg. But >Alt-SysRq-B does reboot! Luckily I could ssh in and capture the ACPI >tables. They are much smaller, and VFCT is empty. Booting back to one >of the working scenarios (direct linux, Grub PV, Grub PVH, UEFI PV), >all of this is normal. >I've attached: >xenboot.log which is the serial log of xen+linux booting in UEFI PVH >(kernel is debian's config, but patched to start at 2MiB) >dmesg.txt which is the linux dmesg that contains some nice stack traces >(kernel is debian's config, but patched to start at 2MiB) >efipvh-tables.dump is ALL acpi tables from UEFI+PVH mode (acpidump -o >efipvh-tables.dump) >working-tables.dump is ALL acpi tables from the other modes (acpidump >-o working-tables.dump) >efipvh-vfct.dump is attached in spirit, as it is 0 bytes long (acpidump >-n VFCT -o efipvh-vfct.dump) >I ran iasl, but it just said Unknown ACPI table signature [VFCT] >and spat out the raw data table, nothing interesting >Something I can try, but have been nervous to try due to GOPupd >warnings is to also flash the 1.67 GOP to the VBIOS on the RX 480. The >R5 430 OEM had no such warnings. >Patrick > > References > >1. mailto:roger@citrix.com >2. https://www.techpowerup.com/vgabios/185789/msi-rx480-4096-160720
[xen-unstable test] 184398: tolerable FAIL - PUSHED
flight 184398 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/184398/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail blocked in 184388 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail blocked in 184388 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184388 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 184388 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184388 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 184388 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184388 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184388 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 184388 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184388 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184388 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184388 test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass version targeted for testing: xen c30021be302aa2a644ef5544097fb8bb763ec140 baseline version: xen 730d2637a8e5b98dc8e4e366179b4cedc496b3ad Last test of basis 184388 2024-01-18 01:55:55 Z1 days Testing same since 184398 2024-01-19 01:37:36 Z0 days1 attempts People who touched revisions under test: Andrew Cooper jobs: build-amd64-xsm
Re: [PATCH v5 2/8] x86: annotate entry points with type and size
On Mon, Jan 15, 2024 at 03:34:56PM +0100, Jan Beulich wrote:
> Use the generic framework in xen/linkage.h.
>
> For switch_to_kernel() and restore_all_guest() so far implicit alignment
> (from being first in their respective sections) is being made explicit
> (as in: using FUNC() without 2nd argument). Whereas for
> {,compat}create_bounce_frame() and autogen_entrypoints[] alignment is
> newly arranged for.
>
> Except for the added/adjusted alignment padding (including their
> knock-on effects) no change in generated code/data. Note that the basis
> for support of weak definitions is added despite them not having any use
> right now.
>
> Note that ASM_INT() is switched to DATA(), not DATA_LOCAL(), as the only
> use site wants the symbol global anyway.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks, Roger.
[ovmf test] 184403: all pass - PUSHED
flight 184403 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/184403/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 0223bdd4e40975c427616761fb13c9454461b64d baseline version: ovmf 9d3fe85fcc8ff386ee0814a4dad03bbf7dc54594 Last test of basis 184400 2024-01-19 03:43:25 Z0 days Testing same since 184403 2024-01-19 07:11:05 Z0 days1 attempts People who touched revisions under test: Yi Li jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 9d3fe85fcc..0223bdd4e4 0223bdd4e40975c427616761fb13c9454461b64d -> xen-tested-master
Re: [PATCH v3 10/34] xen/riscv: introduce bitops.h
On Fri, 2024-01-19 at 10:14 +0100, Jan Beulich wrote: > On 19.01.2024 10:09, Oleksii wrote: > > On Thu, 2024-01-18 at 12:03 +0100, Jan Beulich wrote: > > > On 22.12.2023 16:12, Oleksii Kurochko wrote: > > > > --- /dev/null > > > > +++ b/xen/include/asm-generic/bitops/bitops-bits.h > > > > @@ -0,0 +1,10 @@ > > > > +/* SPDX-License-Identifier: GPL-2.0 */ > > > > +#ifndef _ASM_GENERIC_BITOPS_BITS_H_ > > > > +#define _ASM_GENERIC_BITOPS_BITS_H_ > > > > + > > > > +#define BITOP_BITS_PER_WORD 32 > > > > +#define BITOP_MASK(nr) (1UL << ((nr) % > > > > BITOP_BITS_PER_WORD)) > > > > +#define BITOP_WORD(nr) ((nr) / BITOP_BITS_PER_WORD) > > > > +#define BITS_PER_BYTE 8 > > > > > > Btw, I can't spot a use of BITS_PER_BYTE. Why do you add it? And > > > if > > > it really needed adding, it surely wouldn't belong here. > > It is used in common/bitmap.c and ns16550.c, and inside some arch > > code, > > but it is not used by RISC-V right now. > > > > Would it be better to define it in config.h? > > Yes, perhaps. Imo this shouldn't have a "generic" fallback; every > arch > should explicitly state this (along with e.g. BITS_PER_LONG). Got it. Thanks. ~ Oleksii
Re: [PATCH v3 10/34] xen/riscv: introduce bitops.h
On 19.01.2024 10:16, Oleksii wrote:
> On Thu, 2024-01-18 at 12:01 +0100, Jan Beulich wrote:
>> On 18.01.2024 10:43, Oleksii wrote:
>>> On Wed, 2024-01-17 at 14:42 +0100, Jan Beulich wrote:
On 17.01.2024 12:37, Oleksii wrote:
>> Also you want to make sure asm-generic/bitops/bitops-
>> bits.h
>> is
>> really in use here, or else an arch overriding / not
>> using
>> that
>> header may end up screwed.
> I am not really understand what do you mean. Could you
> please
> explain a
> little bit more.
Whichever type you use here, it needs to be in sync with
BITOP_BITS_PER_WORD. Hence you want to include the
_local_
bitops-
bits.h
here, such that in case of an inconsistent override by an
arch
the
compiler would complain about the two differring #define-
s.
(IOW
an
arch overriding BITOP_BITS_PER_WORD cannot re-use this
header
as-
is.)
The same may, btw, be true for others of the new headers
you
add
-
the
same #include would therefore be needed there as well.
>>> Now it clear to me.
>>>
>>>
>>> It seems like BITOP_BITS_PER_WORD, BITOP_MASK, BITOP_WORD,
>>> and
>>> BITS_PER_BYTE are defined in {arm, ppc,
>>> riscv}/include/asm/bitops.h.
>>> I expected that any architecture planning to use asm-
>>> generic/bitops/bitops-bits.h would include it at the
>>> beginning
>>> of
>>> /include/asm/bitops.h, similar to what is done for
>>> RISC-
>>> V:
>>> #ifndef _ASM_RISCV_BITOPS_H
>>> #define _ASM_RISCV_BITOPS_H
>>>
>>> #include
>>>
>>> #include
>>> ...
>>>
>>> But in this case, to allow architecture overrides macros,
>>> it is
>>> necessary to update asm-generic/bitops/bitops-bits.h:
>>> #ifndef BITOP_BITS_PER_WORD
>>> #define BITOP_BITS_PER_WORD 32
>>> #endif
>>> ...
>>> Therefore, if an architecture needs to override something,
>>> it
>>> will
>>> add
>>> #define ... before #include >> bits.h>.
>>>
>>> Does it make sense?
>>
>> Sure. But then the arch also needs to provide a corresponding
>> typedef
>> (and bitops-bits.h the fallback one), for use wherever you
>> use
>> any of
>> those #define-s.
> Which one typedef is needed to provide?
> contains only macros.
A new one, to replace where right now you use "unsigned int" and
I
initially said you need to use "uint32_t" instead. With what you
said
earlier, uint32_t won't work there (anymore).
>>> Wouldn't it be enough just to "#include " in headers
>>> where
>>> "uint32_t" is used?
>>
>> No, my point wasn't to make uint32_t available. We need a _separate_
>> typedef which matches the #define-s. Otherwise, if an arch defines
>> BITOP_BITS_PER_WORD to, say, 64, this generic code would do the wrong
>> thing.
> Oh, yeah this is true.
>
> We have to introduce in bitops-bits.h:
>typedef uint_32t bitops_type;
Perhaps e.g.
typedef uint32_t bitops_uint_t;
though.
Jan
> And then use it in function such as test_bit:
>static inline int test_bit(int nr, const volatile void *addr)
>{
>const volatile bitops_type *p = addr;
>return 1 & (p[BITOP_WORD(nr)] >> (nr & (BITOP_BITS_PER_WORD -
>1)));
>}
>
> Thanks for clarification.
>
> ~ Oleksii
Re: [PATCH v3 10/34] xen/riscv: introduce bitops.h
On Thu, 2024-01-18 at 12:01 +0100, Jan Beulich wrote:
> On 18.01.2024 10:43, Oleksii wrote:
> > On Wed, 2024-01-17 at 14:42 +0100, Jan Beulich wrote:
> > > On 17.01.2024 12:37, Oleksii wrote:
> > > > > > >
> > > > > > > > > Also you want to make sure asm-generic/bitops/bitops-
> > > > > > > > > bits.h
> > > > > > > > > is
> > > > > > > > > really in use here, or else an arch overriding / not
> > > > > > > > > using
> > > > > > > > > that
> > > > > > > > > header may end up screwed.
> > > > > > > > I am not really understand what do you mean. Could you
> > > > > > > > please
> > > > > > > > explain a
> > > > > > > > little bit more.
> > > > > > >
> > > > > > > Whichever type you use here, it needs to be in sync with
> > > > > > > BITOP_BITS_PER_WORD. Hence you want to include the
> > > > > > > _local_
> > > > > > > bitops-
> > > > > > > bits.h
> > > > > > > here, such that in case of an inconsistent override by an
> > > > > > > arch
> > > > > > > the
> > > > > > > compiler would complain about the two differring #define-
> > > > > > > s.
> > > > > > > (IOW
> > > > > > > an
> > > > > > > arch overriding BITOP_BITS_PER_WORD cannot re-use this
> > > > > > > header
> > > > > > > as-
> > > > > > > is.)
> > > > > > >
> > > > > > > The same may, btw, be true for others of the new headers
> > > > > > > you
> > > > > > > add
> > > > > > > -
> > > > > > > the
> > > > > > > same #include would therefore be needed there as well.
> > > > > > Now it clear to me.
> > > > > >
> > > > > >
> > > > > > It seems like BITOP_BITS_PER_WORD, BITOP_MASK, BITOP_WORD,
> > > > > > and
> > > > > > BITS_PER_BYTE are defined in {arm, ppc,
> > > > > > riscv}/include/asm/bitops.h.
> > > > > > I expected that any architecture planning to use asm-
> > > > > > generic/bitops/bitops-bits.h would include it at the
> > > > > > beginning
> > > > > > of
> > > > > > /include/asm/bitops.h, similar to what is done for
> > > > > > RISC-
> > > > > > V:
> > > > > > #ifndef _ASM_RISCV_BITOPS_H
> > > > > > #define _ASM_RISCV_BITOPS_H
> > > > > >
> > > > > > #include
> > > > > >
> > > > > > #include
> > > > > > ...
> > > > > >
> > > > > > But in this case, to allow architecture overrides macros,
> > > > > > it is
> > > > > > necessary to update asm-generic/bitops/bitops-bits.h:
> > > > > > #ifndef BITOP_BITS_PER_WORD
> > > > > > #define BITOP_BITS_PER_WORD 32
> > > > > > #endif
> > > > > > ...
> > > > > > Therefore, if an architecture needs to override something,
> > > > > > it
> > > > > > will
> > > > > > add
> > > > > > #define ... before #include > > > > > bits.h>.
> > > > > >
> > > > > > Does it make sense?
> > > > >
> > > > > Sure. But then the arch also needs to provide a corresponding
> > > > > typedef
> > > > > (and bitops-bits.h the fallback one), for use wherever you
> > > > > use
> > > > > any of
> > > > > those #define-s.
> > > > Which one typedef is needed to provide?
> > > > contains only macros.
> > >
> > > A new one, to replace where right now you use "unsigned int" and
> > > I
> > > initially said you need to use "uint32_t" instead. With what you
> > > said
> > > earlier, uint32_t won't work there (anymore).
> > Wouldn't it be enough just to "#include " in headers
> > where
> > "uint32_t" is used?
>
> No, my point wasn't to make uint32_t available. We need a _separate_
> typedef which matches the #define-s. Otherwise, if an arch defines
> BITOP_BITS_PER_WORD to, say, 64, this generic code would do the wrong
> thing.
Oh, yeah this is true.
We have to introduce in bitops-bits.h:
typedef uint_32t bitops_type;
And then use it in function such as test_bit:
static inline int test_bit(int nr, const volatile void *addr)
{
const volatile bitops_type *p = addr;
return 1 & (p[BITOP_WORD(nr)] >> (nr & (BITOP_BITS_PER_WORD -
1)));
}
Thanks for clarification.
~ Oleksii
Re: [PATCH v3 10/34] xen/riscv: introduce bitops.h
On 19.01.2024 10:09, Oleksii wrote: > On Thu, 2024-01-18 at 12:03 +0100, Jan Beulich wrote: >> On 22.12.2023 16:12, Oleksii Kurochko wrote: >>> --- /dev/null >>> +++ b/xen/include/asm-generic/bitops/bitops-bits.h >>> @@ -0,0 +1,10 @@ >>> +/* SPDX-License-Identifier: GPL-2.0 */ >>> +#ifndef _ASM_GENERIC_BITOPS_BITS_H_ >>> +#define _ASM_GENERIC_BITOPS_BITS_H_ >>> + >>> +#define BITOP_BITS_PER_WORD 32 >>> +#define BITOP_MASK(nr) (1UL << ((nr) % >>> BITOP_BITS_PER_WORD)) >>> +#define BITOP_WORD(nr) ((nr) / BITOP_BITS_PER_WORD) >>> +#define BITS_PER_BYTE 8 >> >> Btw, I can't spot a use of BITS_PER_BYTE. Why do you add it? And if >> it really needed adding, it surely wouldn't belong here. > It is used in common/bitmap.c and ns16550.c, and inside some arch code, > but it is not used by RISC-V right now. > > Would it be better to define it in config.h? Yes, perhaps. Imo this shouldn't have a "generic" fallback; every arch should explicitly state this (along with e.g. BITS_PER_LONG). Jan
Re: [PATCH v3 10/34] xen/riscv: introduce bitops.h
On Thu, 2024-01-18 at 12:03 +0100, Jan Beulich wrote: > On 22.12.2023 16:12, Oleksii Kurochko wrote: > > --- /dev/null > > +++ b/xen/include/asm-generic/bitops/bitops-bits.h > > @@ -0,0 +1,10 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +#ifndef _ASM_GENERIC_BITOPS_BITS_H_ > > +#define _ASM_GENERIC_BITOPS_BITS_H_ > > + > > +#define BITOP_BITS_PER_WORD 32 > > +#define BITOP_MASK(nr) (1UL << ((nr) % > > BITOP_BITS_PER_WORD)) > > +#define BITOP_WORD(nr) ((nr) / BITOP_BITS_PER_WORD) > > +#define BITS_PER_BYTE 8 > > Btw, I can't spot a use of BITS_PER_BYTE. Why do you add it? And if > it really needed adding, it surely wouldn't belong here. It is used in common/bitmap.c and ns16550.c, and inside some arch code, but it is not used by RISC-V right now. Would it be better to define it in config.h? ~ Oleksii
Re: [PATCH] coverage: filter out lib{fdt,elf}-temp.o
Hi Anthony,
On 18/01/2024 18:37, Anthony PERARD wrote:
>
>
> On Thu, Jan 18, 2024 at 02:12:21PM +0100, Jan Beulich wrote:
>> On 18.01.2024 13:06, Michal Orzel wrote:
>>> At the moment, trying to run xencov read/reset (calling SYSCTL_coverage_op
>>> under the hood) results in a crash. This is due to an attempt to
>>> access code in the .init.* sections (libfdt for Arm and libelf for x86)
>>> that are stripped after boot. Normally, the build system compiles any
>>> *.init.o file without COV_FLAGS. However, these two libraries are
>>> handled differently as sections will be renamed to init after linking.
>>>
>>> This worked until e321576f4047 ("xen/build: start using if_changed")
>>> that added lib{fdt,elf}-temp.o to extra-y. Any file listed there without
>>> *.init.o suffix will be part of non-init-objects for which COV_FLAGS
>>> will be appended.
>>
>> While this is true, aiui COV_FLAGS would be empty for anything listed
>> in nocov-y and all of the prerequisites of those objects (iirc target-
>> specific variable settings propagate to prerequisites). Therefore ...
>>
>>> In such case, the solution is to add a file to nocov-y.
>>
>> ... libelf.o / libfdt.o already being listed there ought to suffice.
>> Alternatively listing only libelf-temp.o / libfdt-temp.o ought to
>> suffice as well.
>>
>> Since you apparently observed things not working, I must be missing
>> something.
>
> Yes, $(extra-y) is like $(obj-y), but objects there will not be added
> "built_in.o". So, make is likely building "libelf-temp.o" and deps
> because it's in $(extra-y) rather than because it's a prerequisite of
> "libelf.o". We could ask make to process prerequisite in a reverse
> order, and suddenly, the command line to make all "libelf-*.o" is
> different: `make --shuffle=reverse V=2`.
That's helpful.
>
> So, adding extra object to $(nocov-y) is a workaround, but I think a
> better fix would be to add those objects to $(targets) instead of
> $(extra-y). I think I've made a mistake by using $(extra-y) instead of
> $(targets) in that original commit.
I can confirm that by moving lib{fdt,elf}-temp.o and deps to targets, the issue
is gone as well.
Is my understanding correct that by switching from extra-y to targets we are
preventing these objects to
appear in non-init-objects (and thus having COV_FLAGS appended) while retaining
the proper if_changed behavior?
According to docs/misc/xen-makefiles/makefiles.rst:
Any target that utilises if_changed must be listed in $(targets),
otherwise the command line check will fail, and the target will
always be built.
~Michal
Re: [PATCH v5 2/8] x86: annotate entry points with type and size
On 18.01.2024 18:45, Roger Pau Monné wrote: > On Mon, Jan 15, 2024 at 03:34:56PM +0100, Jan Beulich wrote: >> @@ -625,7 +627,7 @@ ENTRY(dom_crash_sync_extable) >> >> /* No special register assumptions. */ >> #ifdef CONFIG_PV >> -ENTRY(continue_pv_domain) >> +FUNC(continue_pv_domain) >> ENDBR64 >> call check_wakeup_from_wait >> ret_from_intr: >> @@ -640,26 +642,28 @@ ret_from_intr: >> #else >> jmp test_all_events >> #endif >> +END(continue_pv_domain) >> #else >> -ret_from_intr: >> +FUNC_LOCAL(ret_from_intr, 0) > > Why does this need to have an alignment of 0? There's no fallthrough > of previous code AFAICT. It doesn't have to, but see the description for where I thought it would make sense to newly introduce alignment; I simply didn't want to go too far with such changes leading to generated code being altered. This (and the other cases below) weren't in that group. Without ... >> ASSERT_CONTEXT_IS_XEN ... this I would be strongly inclined to switch ... >> jmp restore_all_xen ... to #define ret_from_intr restore_all_xen anyway. And perhaps we ought to change the "#else" above to "#elif !defined(NDEBUG)", at which point I'd say alignment isn't required here at all. >> @@ -713,12 +718,14 @@ ENTRY(common_interrupt) >> mov %r15, STACK_CPUINFO_FIELD(xen_cr3)(%r14) >> mov %bl, STACK_CPUINFO_FIELD(use_pv_cr3)(%r14) >> jmp ret_from_intr >> +END(common_interrupt) >> >> -ENTRY(entry_PF) >> +FUNC(entry_PF) >> ENDBR64 >> movl $X86_EXC_PF, 4(%rsp) >> +END(entry_PF) >> /* No special register assumptions. */ >> -GLOBAL(handle_exception) >> +FUNC(handle_exception, 0) > > Given patch 8/8 that enables support for placing FUNC() into separate > sections, the fallthrough arrangement here with entry_PF is no longer > guaranteed, as the linker could re-order the sections and thus > entry_PF could fallthrough into another text section? > > IOW: entry_PF needs a "jmp handle_exception", and then > handle_exception itself can be padded as required by the default > alignment? Oh, yes, very much so. Thanks for noticing. I'll do that in the later patch, though. >> @@ -1149,7 +1176,7 @@ GLOBAL(autogen_entrypoints) >> .endm >> >> .popsection >> -autogen_stubs: /* Automatically generated stubs. */ >> +FUNC_LOCAL(autogen_stubs, 0) /* Automatically generated stubs. */ > > Won't it be good to align the stubs? As that's possible to make them > faster? Well. If I used default alignment here, it would be the 1st stub only which gains alignment. I'd view that as simply inconsistent. You'll find there already is an ALIGN inside the .rept below. That covers only certain cases, but intentionally so, I believe: it's only entry points which shouldn't be reached anyway which get no alignment. So yes, in this case I clearly think there wants to explicitly be no alignment here. Jan
