Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13)
On Mon, Nov 25, 2019 at 7:55 PM Marek Marczykowski-Górecki wrote: > > On Mon, Nov 25, 2019 at 07:44:03PM -0800, Roman Shaposhnik wrote: > > On Sun, Nov 24, 2019 at 4:48 PM Marek Marczykowski-Górecki > > wrote: > > > Do you have by > > > a chance messages of that crash (without efi=no-rs, but with > > > EFI_SET_VIRTUAL_ADDRESS_MAP enabled)? Or even a photo if no serial output > > > is > > > available? > > > > With my awesome soldering skills ;-) I managed to rig a serial console. > > > > Output is attached. Please let me know if you'd like me to run any > > other experiments. > > Looks helpful, lets try to do something: > > > Xen 4.13.0-rc > > (XEN) Xen version 4.13.0-rc (@) (gcc (Alpine 6.4.0) 6.4.0) debug=y Tue Nov > > 26 03:19:38 UTC 2019 > > (XEN) Latest ChangeSet: > > (XEN) build-id: 07aa9f711fe09a91be2588ee7df10d93ebe34c80 > > (XEN) Bootloader: GRUB 2.03 > > (XEN) Command line: com1=115200,8n1 console=com1 loglvl=all noreboot > > dom0_mem=640M,max:640M dom0_max_vcpus=1 dom0_vcpus_pin smt=false > (...) > > (XEN) EFI memory map: > (...) > > (XEN) 077587000-0775f4fff type=5 attr=800f > > This is code that crashes - runtime services code, so somewhere with > actual UEFI code. Yup -- that was my hunch with adding efi=no-rs option. > (...) > > (XEN) 0ff90-0 type=11 attr=8000 > > (XEN) Unknown cachability for MFNs 0xff900-0xf > > The faulting address is in this range. And because of unknown > cachability, it isn't mapped. Try adding 'efi=attr=uc' to the Xen > cmdline. Feels like we're getting exactly the same failure. Log attached. Thanks, Roman. Xen 4.13.0-rc (XEN) Xen version 4.13.0-rc (@) (gcc (Alpine 6.4.0) 6.4.0) debug=y Tue Nov 26 03:19:38 UTC 2019 (XEN) Latest ChangeSet: (XEN) build-id: 07aa9f711fe09a91be2588ee7df10d93ebe34c80 (XEN) Bootloader: GRUB 2.03 (XEN) Command line: com1=115200,8n1 console=com1 loglvl=all noreboot efi=attr=uc dom0_mem=640M,max:640M dom0_max_vcpus=1 dom0_vcpus_pin smt=false (XEN) Xen image load base address: 0x70e0 (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) Disc information: (XEN) Found 0 MBR signatures (XEN) Found 1 EDD information structures (XEN) EFI RAM map: (XEN) - 0003f000 (usable) (XEN) 0003f000 - 0004 (ACPI NVS) (XEN) 0004 - 000a (usable) (XEN) 0010 - 2000 (usable) (XEN) 2000 - 2010 (reserved) (XEN) 2010 - 76ccb000 (usable) (XEN) 76ccb000 - 76d43000 (reserved) (XEN) 76d43000 - 76d54000 (ACPI data) (XEN) 76d54000 - 772de000 (ACPI NVS) (XEN) 772de000 - 775f5000 (reserved) (XEN) 775f5000 - 775f6000 (usable) (XEN) 775f6000 - 77638000 (reserved) (XEN) 77638000 - 789e5000 (usable) (XEN) 789e5000 - 78ffa000 (reserved) (XEN) 78ffa000 - 7900 (usable) (XEN) e000 - f000 (reserved) (XEN) fec0 - fec01000 (reserved) (XEN) fed01000 - fed02000 (reserved) (XEN) fed03000 - fed04000 (reserved) (XEN) fed08000 - fed09000 (reserved) (XEN) fed0c000 - fed1 (reserved) (XEN) fed1c000 - fed1d000 (reserved) (XEN) fee0 - fee01000 (reserved) (XEN) fef0 - ff00 (reserved) (XEN) ff90 - 0001 (reserved) (XEN) System RAM: 1919MB (1965176kB) (XEN) ACPI: RSDP 76D46000, 0024 (r2 DELL) (XEN) ACPI: XSDT 76D46088, 0094 (r1 DELL AS09 1072009 AMI 10013) (XEN) ACPI: FACP 76D52560, 010C (r5 DELL AS09 1072009 AMI 10013) (XEN) ACPI: DSDT 76D461B0, C3AF (r2 DELL AS09 1072009 INTL 20120913) (XEN) ACPI: FACS 772DDE80, 0040 (XEN) ACPI: APIC 76D52670, 0068 (r3 DELL AS09 1072009 AMI 10013) (XEN) ACPI: FPDT 76D526D8, 0044 (r1 DELL AS09 1072009 AMI 10013) (XEN) ACPI: FIDT 76D52720, 009C (r1 DELL AS09 1072009 AMI 10013) (XEN) ACPI: MCFG 76D527C0, 003C (r1 DELL AS09 1072009 MSFT 97) (XEN) ACPI: LPIT 76D52800, 0104 (r1 DELL AS093 VLV2 10D) (XEN) ACPI: HPET 76D52908, 0038 (r1 DELL AS09 1072009 AMI.5) (XEN) ACPI: SSDT 76D52940, 0763 (r1 DELL AS09 3000 INTL 20061109) (XEN) ACPI: SSDT 76D530A8, 0290 (r1 DELL AS09 3000 INTL 20061109) (XEN) ACPI: SSDT 76D53338, 017A (r1 DELL AS09 3000 INTL 20061109) (XEN) ACPI: UEFI 76D534B8, 0042 (r1 DELL AS090 0) (XEN) ACPI: CSRT 76D53500, 014C (r0 DELL AS095 INTL 20120624) (XEN) ACPI: TPM2 76D53650, 0034 (r3Tpm2Tabl1 AMI 0) (XEN) ACPI: SSDT 76D53688, 00C9 (r1 MSFT RHPROXY1 INTL 20120913) (XEN) No NUMA configuration found (XEN) Faking a node at -7900 (XEN)
[Xen-devel] [qemu-mainline test] 144297: tolerable FAIL - PUSHED
flight 144297 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/144297/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 16 guest-localmigrate fail REGR. vs. 144250 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 144250 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 144250 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 144250 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 144250 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 144250 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass version targeted for testing: qemuu122e6d2a9c1bf8aa1d51409c15809a82621515b1 baseline version: qemuu2061735ff09f9d5e67c501a96227b470e7de69b1 Last test of basis 144250 2019-11-22 18:06:35 Z3 days Testing same since 144297 2019-11-25 15:06:18 Z0 days1 attempts People who touched revisions under test: Christian Schoenebeck Dan Schatzberg Greg Kurz Peter Maydell jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf
[Xen-devel] [ovmf test] 144298: all pass - PUSHED
flight 144298 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/144298/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf bd85bf54c268204c7a698a96f3ccd96cd77952cd baseline version: ovmf e0f8261ad02217fa8ed57c95c379c2fc8fd67210 Last test of basis 144292 2019-11-25 06:08:58 Z0 days Testing same since 144298 2019-11-25 15:09:05 Z0 days1 attempts People who touched revisions under test: Kubacki, Michael A Michael Kubacki Sami Mujawar 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 e0f8261ad0..bd85bf54c2 bd85bf54c268204c7a698a96f3ccd96cd77952cd -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13)
On Mon, Nov 25, 2019 at 07:44:03PM -0800, Roman Shaposhnik wrote:
> On Sun, Nov 24, 2019 at 4:48 PM Marek Marczykowski-Górecki
> wrote:
> > Do you have by
> > a chance messages of that crash (without efi=no-rs, but with
> > EFI_SET_VIRTUAL_ADDRESS_MAP enabled)? Or even a photo if no serial output is
> > available?
>
> With my awesome soldering skills ;-) I managed to rig a serial console.
>
> Output is attached. Please let me know if you'd like me to run any
> other experiments.
Looks helpful, lets try to do something:
> Xen 4.13.0-rc
> (XEN) Xen version 4.13.0-rc (@) (gcc (Alpine 6.4.0) 6.4.0) debug=y Tue Nov
> 26 03:19:38 UTC 2019
> (XEN) Latest ChangeSet:
> (XEN) build-id: 07aa9f711fe09a91be2588ee7df10d93ebe34c80
> (XEN) Bootloader: GRUB 2.03
> (XEN) Command line: com1=115200,8n1 console=com1 loglvl=all noreboot
> dom0_mem=640M,max:640M dom0_max_vcpus=1 dom0_vcpus_pin smt=false
(...)
> (XEN) EFI memory map:
(...)
> (XEN) 077587000-0775f4fff type=5 attr=800f
This is code that crashes - runtime services code, so somewhere with
actual UEFI code.
(...)
> (XEN) 0ff90-0 type=11 attr=8000
> (XEN) Unknown cachability for MFNs 0xff900-0xf
The faulting address is in this range. And because of unknown
cachability, it isn't mapped. Try adding 'efi=attr=uc' to the Xen
cmdline.
(...)
> (XEN) Xen call trace:
> (XEN)[<775e0d21>] R 775e0d21
> (XEN)[<775ddb8e>] S 775ddb8e
> (XEN)[<>] F
> (XEN)[<7fff>] F 7fff
> (XEN)
> (XEN) Pagetable walk from ff920020:
> (XEN) L4[0x000] = 787c0063
> (XEN) L3[0x003] = 71298063
> (XEN) L2[0x1fc] =
> (XEN)
> (XEN)
> (XEN) Panic on CPU 0:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=]
> (XEN) Faulting linear address: ff920020
> (XEN)
> (XEN)
> (XEN) Manual reset required ('noreboot' specified)
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13)
On Sun, Nov 24, 2019 at 4:48 PM Marek Marczykowski-Górecki wrote: > > On Fri, Nov 22, 2019 at 10:00:13PM -0800, Roman Shaposhnik wrote: > > 3. Bad news: Marek's suggestion didn't work on Dell product line (and yes > > I double checked that I built it correctly). > > > > So... when it comes to RC2 regression -- we're all good. > > > > But since we're here anyway -- I'm wondering if anyone would be > > interested in helping me figure out why Xen on those Dell boxes coredumps > > without efi=no-rs ? > > > > Marek, any chance I can interest you in helping me a bit here? ;-) > > Yes, I am interested in helping with UEFI state there. Thanks! That's very much appreciated! Btw, I'll keep CCing xen-devel in case anyone else is interested in this conversation. > Do you have by > a chance messages of that crash (without efi=no-rs, but with > EFI_SET_VIRTUAL_ADDRESS_MAP enabled)? Or even a photo if no serial output is > available? With my awesome soldering skills ;-) I managed to rig a serial console. Output is attached. Please let me know if you'd like me to run any other experiments. Thanks, Roman. Xen 4.13.0-rc (XEN) Xen version 4.13.0-rc (@) (gcc (Alpine 6.4.0) 6.4.0) debug=y Tue Nov 26 03:19:38 UTC 2019 (XEN) Latest ChangeSet: (XEN) build-id: 07aa9f711fe09a91be2588ee7df10d93ebe34c80 (XEN) Bootloader: GRUB 2.03 (XEN) Command line: com1=115200,8n1 console=com1 loglvl=all noreboot dom0_mem=640M,max:640M dom0_max_vcpus=1 dom0_vcpus_pin smt=false (XEN) Xen image load base address: 0x70e0 (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) Disc information: (XEN) Found 0 MBR signatures (XEN) Found 1 EDD information structures (XEN) EFI RAM map: (XEN) - 0003f000 (usable) (XEN) 0003f000 - 0004 (ACPI NVS) (XEN) 0004 - 000a (usable) (XEN) 0010 - 2000 (usable) (XEN) 2000 - 2010 (reserved) (XEN) 2010 - 76ccb000 (usable) (XEN) 76ccb000 - 76d43000 (reserved) (XEN) 76d43000 - 76d54000 (ACPI data) (XEN) 76d54000 - 772de000 (ACPI NVS) (XEN) 772de000 - 775f5000 (reserved) (XEN) 775f5000 - 775f6000 (usable) (XEN) 775f6000 - 77638000 (reserved) (XEN) 77638000 - 789e5000 (usable) (XEN) 789e5000 - 78ffa000 (reserved) (XEN) 78ffa000 - 7900 (usable) (XEN) e000 - f000 (reserved) (XEN) fec0 - fec01000 (reserved) (XEN) fed01000 - fed02000 (reserved) (XEN) fed03000 - fed04000 (reserved) (XEN) fed08000 - fed09000 (reserved) (XEN) fed0c000 - fed1 (reserved) (XEN) fed1c000 - fed1d000 (reserved) (XEN) fee0 - fee01000 (reserved) (XEN) fef0 - ff00 (reserved) (XEN) ff90 - 0001 (reserved) (XEN) System RAM: 1919MB (1965176kB) (XEN) ACPI: RSDP 76D46000, 0024 (r2 DELL) (XEN) ACPI: XSDT 76D46088, 0094 (r1 DELL AS09 1072009 AMI 10013) (XEN) ACPI: FACP 76D52560, 010C (r5 DELL AS09 1072009 AMI 10013) (XEN) ACPI: DSDT 76D461B0, C3AF (r2 DELL AS09 1072009 INTL 20120913) (XEN) ACPI: FACS 772DDE80, 0040 (XEN) ACPI: APIC 76D52670, 0068 (r3 DELL AS09 1072009 AMI 10013) (XEN) ACPI: FPDT 76D526D8, 0044 (r1 DELL AS09 1072009 AMI 10013) (XEN) ACPI: FIDT 76D52720, 009C (r1 DELL AS09 1072009 AMI 10013) (XEN) ACPI: MCFG 76D527C0, 003C (r1 DELL AS09 1072009 MSFT 97) (XEN) ACPI: LPIT 76D52800, 0104 (r1 DELL AS093 VLV2 10D) (XEN) ACPI: HPET 76D52908, 0038 (r1 DELL AS09 1072009 AMI.5) (XEN) ACPI: SSDT 76D52940, 0763 (r1 DELL AS09 3000 INTL 20061109) (XEN) ACPI: SSDT 76D530A8, 0290 (r1 DELL AS09 3000 INTL 20061109) (XEN) ACPI: SSDT 76D53338, 017A (r1 DELL AS09 3000 INTL 20061109) (XEN) ACPI: UEFI 76D534B8, 0042 (r1 DELL AS090 0) (XEN) ACPI: CSRT 76D53500, 014C (r0 DELL AS095 INTL 20120624) (XEN) ACPI: TPM2 76D53650, 0034 (r3Tpm2Tabl1 AMI 0) (XEN) ACPI: SSDT 76D53688, 00C9 (r1 MSFT RHPROXY1 INTL 20120913) (XEN) No NUMA configuration found (XEN) Faking a node at -7900 (XEN) Domain heap initialised (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 55 (0x37), Stepping 9 (raw 00030679) (XEN) SMBIOS 3.0 present. (XEN) DMI 3.0 present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x408 (32 bits) (XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0] (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0] (XEN) ACPI: 32/64X FACS address mismatch in FADT - 772dde80/, using 32 (XEN) ACPI: wakeup_vec[772dde8c], vec_size[20] (XEN) ACPI: Local APIC address
[Xen-devel] [xen-unstable test] 144295: regressions - FAIL
flight 144295 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/144295/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs. 144289 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 17 guest-start.2 fail blocked in 144289 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 144289 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 144289 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 144289 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 144289 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 144289 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 144289 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 144289 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 144289 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 144289 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 77beba7c921a286c31a2a76f26500047f353614a baseline version: xen 183f354e1430087879de071f0c7122e42703916e Last test of basis 144289 2019-11-25 01:50:58 Z1 days Testing same since 144295 2019-11-25 14:06:43 Z0 days1 attempts People who touched revisions under test: Anthony PERARD George Dunlap Ian Jackson
Re: [Xen-devel] [GIT PULL] xen: fixes for xen
The pull request you sent on Mon, 25 Nov 2019 06:34:54 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git > for-linus-5.5a-rc1-tag has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/3f3c8be973af10875cfa1e7b85a535b6ba76b44f Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH v3 07/11] xen: arm: vgic: allow delivery of PPIs to guests
On Mon, 25 Nov 2019, Julien Grall wrote: > (+ Andre) > > On 23/11/2019 20:35, Julien Grall wrote: > > Hi, > > > > On 15/11/2019 20:10, Stewart Hildebrand wrote: > > > Allow vgic_get_hw_irq_desc to be called with a vcpu argument. > > > > > > Use vcpu argument in vgic_connect_hw_irq. > > > > > > vgic_connect_hw_irq is called for PPIs and SPIs, not SGIs. Enforce with > > > ASSERTs. > > > > > > Signed-off-by: Stewart Hildebrand > > > > > > --- > > > v3: new patch > > > > > > --- > > > Note: I have only modified the old vgic to allow delivery of PPIs. > > > > The new vGIC should also be modified to support delivery of PPIs. > > > > > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c > > > index 82f524a35c..c3933c2687 100644 > > > --- a/xen/arch/arm/vgic.c > > > +++ b/xen/arch/arm/vgic.c > > > @@ -410,10 +410,10 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, > > > int n) > > > irq_set_affinity(p->desc, cpumask_of(v_target->processor)); > > > spin_lock_irqsave(>desc->lock, flags); > > > /* > > > - * The irq cannot be a PPI, we only support delivery of SPIs > > > - * to guests. > > > + * The irq cannot be a SGI, we only support delivery of SPIs > > > + * and PPIs to guests. > > > */ > > > - ASSERT(irq >= 32); > > > + ASSERT(irq >= NR_SGIS); > > > > We usually put ASSERT() in place we know that code wouldn't be able to work > > correctly if there ASSERT were hit. In this particular case: > > > > > if ( irq_type_set_by_domain(d) ) > > > gic_set_irq_type(p->desc, vgic_get_virq_type(v, n, i)); > > > > 1) We don't want to allow any domain (including Dom0) to modify the > > interrupt type (i.e. level/edge) for PPIs as this is shared. You will also > > most likely need to modify the counterpart in setup_guest_irq(). > > > > > p->desc->handler->enable(p->desc); > > > > 2) On GICv3, the re-distributor of vCPU A is accessible by vCPU B. So vCPU B > > could enable the SGI for vCPU A. But this would be called on the wrong pCPU > > leading to inconsistency between the hardware state of the internal vGIC > > state. Is it actually meant to work from a GIC specification perspective? It sounds "wrong" somehow to me, but I went through the spec and it doesn't say explicitly that cpuB couldn't enable a SGI/PPI of cpuA. I am still a bit shocked by this revelation. [I haven't had a chance to think carefully about what you wrote below yet. I'll follow-up.] > I thought a bit more of the issue over the week-end. The current vGIC is > fairly messy. I can see two solutions on how to solve this: > 1) Send an IPI to the pCPU where the vCPU A is running and disable/enable > the interrupt. The other side would need to the vCPU was actually running to > avoid disabling the PPI for the wrong pCPU > 2) Keep the HW interrupt always enabled > > We propagated the enable/disable because of some messy part in the vGIC: > - vgic_inject_irq() will not queue any pending interrupt if the vCPU is > offline. While interrupt cannot be delivered, we still need to keep them > pending as they will never occur again otherwise. This is because they are > active on the host side and the guest has no way to deactivate them. > - Our implementation of PSCI CPU will remove all pending interrupts (see > vgic_clear_pending_irqs()). I am not entirely sure the implication here > because of the previous. > > There are a probably more. Aside the issues with it, I don't really see good > advantage to propagate the interrupt state as the interrupts (PPIs, SPIs) have > active state. So they can only be received once until the guest actually > handles it. > > So my preference would still be 2) because this makes the code simpler, avoid > IPI and other potential locking trouble. > > On a side note, there are more issues with enable/disable on the current vGIC > as a pending interrupt already in the LR will not get dropped... > > All of this is quite nasty. The sooner the new vGIC is finished the sooner we > can kill the current one.___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xen/arm: initialize vpl011 flag register
Hi, On 25/11/2019 20:58, Jeff Kubascik wrote: The tx/rx fifo flags were not set when the vpl011 is initialized. This is a problem for certain guests that are operating in polled mode, as a guest will generally check the rx fifo empty flag to determine if there is data before doing a read. The result is a continuous spam of the message "vpl011: Unexpected IN ring buffer empty" before the first valid character is received. This initializes the flag status register to the default specified in the PL011 technical reference manual. Signed-off-by: Jeff Kubascik You could have retained my acked-by here :). Acked-by: Julien Grall We are in late stage for Xen 4.13 and from what you say this will only spam the console (though it is rate-limited). So I don't intend to request to be merged in Xen 4.13 (feel free to request it if you think it is worth it). Instead, I will queue it for the next release in my branch for-next/4.14. Changes in v2: - Moved uartfr initialization to later point in function after potential return/failure points We don't commit the changelog. To help making the committers life boring, I would recommend to add --- before it. git am will stripped anything after it. --- Similar to this one. xen/arch/arm/vpl011.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c index 7bc5eeb207..895f436cc4 100644 --- a/xen/arch/arm/vpl011.c +++ b/xen/arch/arm/vpl011.c @@ -668,6 +668,8 @@ int domain_vpl011_init(struct domain *d, struct vpl011_init_info *info) goto out2; } +vpl011->uartfr = TXFE | RXFE; + spin_lock_init(>lock); register_mmio_handler(d, _mmio_handler, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: remove physical timer offset
Hi,
On 25/11/2019 16:14, Jeff Kubascik wrote:
The physical timer traps apply an offset so that time starts at 0 for
the guest. However, this offset is not currently applied to the physical
counter. Per the ARMv8 Arch Reference Manual, the offset between the
Which bit of the Arm Arm do you refer to here? In general, I would
recommend to give the exact section and version of the manual you use to
avoid any misunderstanding.
physical timer and counter should be 0. This removes the offset to make
the timer and counter consistent.
Xen time is at offset boot_count from the physical counter, so we need
to take this into account when reading/writing to CNTP_CVAL.
Signed-off-by: Jeff Kubascik
---
xen/arch/arm/vtimer.c| 18 ++
xen/include/asm-arm/domain.h | 3 ---
2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index e6aebdac9e..4790b5ce58 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -62,7 +62,6 @@ static void virt_timer_expired(void *data)
int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config)
{
-d->arch.phys_timer_base.offset = NOW();
d->arch.virt_timer_base.offset = READ_SYSREG64(CNTPCT_EL0);
d->time_offset_seconds = ticks_to_ns(d->arch.virt_timer_base.offset -
boot_count);
do_div(d->time_offset_seconds, 10);
@@ -184,8 +183,7 @@ static bool vtimer_cntp_ctl(struct cpu_user_regs *regs,
uint32_t *r, bool read)
if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
{
-set_timer(>arch.phys_timer.timer,
- v->arch.phys_timer.cval +
v->domain->arch.phys_timer_base.offset);
+set_timer(>arch.phys_timer.timer, v->arch.phys_timer.cval);
}
else
stop_timer(>arch.phys_timer.timer);
@@ -202,7 +200,7 @@ static bool vtimer_cntp_tval(struct cpu_user_regs *regs,
uint32_t *r,
if ( !ACCESS_ALLOWED(regs, EL0PTEN) )
return false;
-now = NOW() - v->domain->arch.phys_timer_base.offset;
+now = NOW();
if ( read )
{
@@ -214,9 +212,7 @@ static bool vtimer_cntp_tval(struct cpu_user_regs *regs,
uint32_t *r,
if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
{
v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
-set_timer(>arch.phys_timer.timer,
- v->arch.phys_timer.cval +
- v->domain->arch.phys_timer_base.offset);
+set_timer(>arch.phys_timer.timer, v->arch.phys_timer.cval);
}
}
return true;
@@ -232,17 +228,15 @@ static bool vtimer_cntp_cval(struct cpu_user_regs *regs,
uint64_t *r,
if ( read )
{
-*r = ns_to_ticks(v->arch.phys_timer.cval);
+*r = ns_to_ticks(v->arch.phys_timer.cval) + boot_count;
}
else
{
-v->arch.phys_timer.cval = ticks_to_ns(*r);
+v->arch.phys_timer.cval = ticks_to_ns(*r - boot_count);
I know that this is already like that in the code. But it feels weird
(to not say wrong) that cval will have a different meaning between the
virtual timer and physical timer.
Indeed, in the former case it is an exact copy of the hardware value
whilst in the latter it is the hardware value - NOW().
While you are reworking a big chunk of the physical timer emulation,
could you looking at removing this discrepancy?
if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
{
v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
-set_timer(>arch.phys_timer.timer,
- v->arch.phys_timer.cval +
- v->domain->arch.phys_timer_base.offset);
+set_timer(>arch.phys_timer.timer, v->arch.phys_timer.cval);
}
}
return true;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 86ebdd2bcf..16a7150a95 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -65,9 +65,6 @@ struct arch_domain
RELMEM_done,
} relmem;
-struct {
-uint64_t offset;
-} phys_timer_base;
struct {
uint64_t offset;
} virt_timer_base;
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC XEN PATCH v3 10/11] xen: arm: context switch vtimer PPI state.
(+ Andre)
Hi,
On 15/11/2019 20:14, Stewart Hildebrand wrote:
From: Ian Campbell
... instead of artificially masking the timer interrupt in the timer
state and relying on the guest to unmask (which it isn't required to
do per the h/w spec, although Linux does).
By using the newly added hwppi save/restore functionality we make use
of the GICD I[SC]ACTIVER registers to save and restore the active
state of the interrupt, which prevents the nested invocations which
the current masking works around.
Signed-off-by: Ian Campbell
Signed-off-by: Stewart Hildebrand
---
v2: Rebased, in particular over Julien's passthrough stuff which
reworked a bunch of IRQ related stuff.
Also largely rewritten since precursor patches now lay very
different groundwork.
v3: Address feedback from v2 [1]:
* Remove virt_timer_irqs performance counter since it is now unused.
* Add caveat to comment about not using I*ACTIVER register.
* HACK: don't initialize pending_irq->irq in vtimer for new vGIC to
allows us to build with CONFIG_NEW_VGIC=y
[1] https://lists.xenproject.org/archives/html/xen-devel/2015-11/msg01065.html
---
Note: Regarding Stefano's comment in [2], I did test it with the call
to gic_hwppi_set_pending removed, and I was able to boot dom0.
When dealing with the vGIC, testing is not enough to justify the removal
of some code. We need a worded justification of why it is (or not)
necessary.
In this case the timer is level (despite some broken HW misconfiguring
it), so by removing set_pending() you don't affect anything as restoring
the timer registers will automatically mark the interrupt pending.
[2] https://lists.xenproject.org/archives/html/xen-devel/2015-12/msg02683.html
---
xen/arch/arm/time.c | 26 ++
xen/arch/arm/vtimer.c| 45 +---
xen/include/asm-arm/domain.h | 1 +
xen/include/asm-arm/perfc_defn.h | 1 -
4 files changed, 44 insertions(+), 29 deletions(-)
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 739bcf186c..e3a23b8e16 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -243,28 +243,6 @@ static void timer_interrupt(int irq, void *dev_id, struct
cpu_user_regs *regs)
}
}
-static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs *regs)
-{
-/*
- * Edge-triggered interrupts can be used for the virtual timer. Even
- * if the timer output signal is masked in the context switch, the
- * GIC will keep track that of any interrupts raised while IRQS are
- * disabled. As soon as IRQs are re-enabled, the virtual interrupt
- * will be injected to Xen.
- *
- * If an IDLE vCPU was scheduled next then we should ignore the
- * interrupt.
- */
-if ( unlikely(is_idle_vcpu(current)) )
-return;
-
-perfc_incr(virt_timer_irqs);
-
-current->arch.virt_timer.ctl = READ_SYSREG32(CNTV_CTL_EL0);
-WRITE_SYSREG32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL_EL0);
-vgic_inject_irq(current->domain, current, current->arch.virt_timer.irq,
true);
-}
-
/*
* Arch timer interrupt really ought to be level triggered, since the
* design of the timer/comparator mechanism is based around that
@@ -304,8 +282,8 @@ void init_timer_interrupt(void)
request_irq(timer_irq[TIMER_HYP_PPI], 0, timer_interrupt,
"hyptimer", NULL);
-request_irq(timer_irq[TIMER_VIRT_PPI], 0, vtimer_interrupt,
- "virtimer", NULL);
+route_hwppi_to_current_vcpu(timer_irq[TIMER_VIRT_PPI], "virtimer");
+
request_irq(timer_irq[TIMER_PHYS_NONSECURE_PPI], 0, timer_interrupt,
"phytimer", NULL);
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index e6aebdac9e..6e3498952d 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -55,9 +55,19 @@ static void phys_timer_expired(void *data)
static void virt_timer_expired(void *data)
{
struct vtimer *t = data;
-t->ctl |= CNTx_CTL_MASK;
-vgic_inject_irq(t->v->domain, t->v, t->irq, true);
-perfc_incr(vtimer_virt_inject);
+t->ctl |= CNTx_CTL_PENDING;
I don't think this is necessary. If the software timer fire, then the
virtual timer (in HW) would have fired too. So by restoring the timer,
then the HW should by itself set the pending bit and trigger the interrupt.
+if ( !(t->ctl & CNTx_CTL_MASK) )
The timer is only set if the virtual timer is enabled and not masked. So
I think this check is unnecessary as we could never reached this code
with the virtual timer masked.
+{
+/*
+ * An edge triggered interrupt should now be pending. Since
This does not make sense, the timer interrupt ought to be level. So why
are you even speaking about edge here?
+ * this timer can never expire while the domain is scheduled
+ * we know that the gic_restore_hwppi in virt_timer_restore
+ * will cause the real hwppi to
Re: [Xen-devel] [XEN PATCH v3 05/11] xen: arm: add interfaces to save/restore the state of a PPI.
Hi,
On 15/11/2019 20:10, Stewart Hildebrand wrote:
From: Ian Campbell
Make use of the GICD I[SC]ACTIVER registers to save and
restore the active state of the interrupt.
For edge triggered interrupts we also need to context switch the
pending bit via I[SC]PENDR. Note that for level triggered interrupts
SPENDR sets a latch which is only cleared by ICPENDR (and not by h/w
state changes), therefore we do not want to context switch the pending
state for level PPIs -- instead we rely on the context switch of the
peripheral to restore the correct level.
Unused as yet, will be used by the vtimer code shortly.
Signed-off-by: Ian Campbell
Signed-off-by: Stewart Hildebrand
---
v3: Address feedback from v2 [1]:
* Add a comment to explain that PPI are always below 31.
* Use uint32_t for pendingr, activer, enabler
* Fixup register names in gic-v3.c
* Add newlines for clarity
* Make gicv3_irq_enable/disable declarations static
* Use readl_relaxed (not readl_gicd) in gic-v3.c
* Add note to comment explaining devices using PPI being quiet during
save/restore. Suggested by Julien.
* Test on QEMU's model of GICv3
Note: I have not given any thought to the comments in [2] regarding
disabling IRQ or enable/disable state.
I will try to answer this below.
[1] https://lists.xenproject.org/archives/html/xen-devel/2015-11/msg01049.html
[2] https://lists.xenproject.org/archives/html/xen-devel/2015-11/msg01051.html
---
xen/arch/arm/gic-v2.c| 69
xen/arch/arm/gic-v3.c| 69
xen/arch/arm/gic.c | 54
xen/arch/arm/irq.c | 7
xen/include/asm-arm/domain.h | 11 ++
xen/include/asm-arm/gic.h| 22
xen/include/asm-arm/irq.h| 2 ++
7 files changed, 234 insertions(+)
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 256988c665..13f106cb61 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -123,6 +123,9 @@ static DEFINE_PER_CPU(u8, gic_cpu_id);
/* Maximum cpu interface per GIC */
#define NR_GIC_CPU_IF 8
+static void gicv2_irq_enable(struct irq_desc *desc);
+static void gicv2_irq_disable(struct irq_desc *desc);
+
static inline void writeb_gicd(uint8_t val, unsigned int offset)
{
writeb_relaxed(val, gicv2.map_dbase + offset);
@@ -191,6 +194,38 @@ static void gicv2_save_state(struct vcpu *v)
writel_gich(0, GICH_HCR);
}
+static void gicv2_save_and_mask_hwppi(struct irq_desc *desc,
+ struct hwppi_state *s)
I would prefer if the two functions are implemented one after each other
rather than having gic_restore_state() between them. But could we move
them in place where a forward declaration for gicv2_irq_{enable,
disable} is not necessary?
While I understand the goal of this function is to be as generic as
possible, GICv2 interface access is slow and therefore a cost will occur
for every access. There are also some unwritten rule that interrupt will
be masked/not active/not pending when the vCPU is created. This rely on
the vGIC state to be the same. If not, then we are going to be in a
broken state.
So I would rather prefer if we try to use the vGIC state as much as
possible and even avoid touching the hardware GIC.
+{
+const uint32_t mask = (1u << desc->irq); /* PPIs are IRQ# 16-31 */
Please use BIT(...).
+const uint32_t pendingr = readl_gicd(GICD_ISPENDR);
This is only necessary for edge interrupt.
+const uint32_t activer = readl_gicd(GICD_ISACTIVER);
+const uint32_t enabler = readl_gicd(GICD_ISENABLER);
If the device is quiescent as suggested below, then masking/unmasking
the interrupt should not be necessary. This would save a few extra cycle
here.
+const bool is_edge = !!(desc->arch.type & DT_IRQ_TYPE_EDGE_BOTH);
+
+s->active = !!(activer & mask);
+s->enabled = !!(enabler & mask);
+s->pending = !!(pendingr & mask);
+
+/* Write a 1 to IC...R to clear the corresponding bit of state */
+if ( s->active )
+writel_gicd(mask, GICD_ICACTIVER);
+
+/*
+ * For an edge interrupt clear the pending state, for a level interrupt
+ * this clears the latch there is no need since saving the peripheral state
+ * (and/or restoring the next VCPU) will cause the correct action.
+ */
+if ( is_edge && s->pending )
+writel_gicd(mask, GICD_ICPENDR);
+
+if ( s->enabled )
+gicv2_irq_disable(desc);
+
+ASSERT(!(readl_gicd(GICD_ISACTIVER) & mask));
+ASSERT(!(readl_gicd(GICD_ISENABLER) & mask));
+}
+
static void gicv2_restore_state(const struct vcpu *v)
{
int i;
@@ -203,6 +238,38 @@ static void gicv2_restore_state(const struct vcpu *v)
writel_gich(GICH_HCR_EN, GICH_HCR);
}
+static void gicv2_restore_hwppi(struct irq_desc *desc,
+const struct hwppi_state *s)
+{
+const
[Xen-devel] [PATCH for-4.13] AMD/IOMMU: honour IR setting while pre-filling DTEs
IV bit shouldn't be set in DTE if interrupt remapping is not
enabled. This was traced to be a root cause behind assertion in
interrupt handling code on Lisbon.
Signed-off-by: Igor Druzhinin
---
xen/drivers/passthrough/amd/iommu_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/drivers/passthrough/amd/iommu_init.c
b/xen/drivers/passthrough/amd/iommu_init.c
index 16e84d4..2b81e38 100644
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -1279,7 +1279,7 @@ static int __init amd_iommu_setup_device_table(
for ( bdf = 0, size /= sizeof(*dt); bdf < size; ++bdf )
dt[bdf] = (struct amd_iommu_dte){
.v = true,
- .iv = true,
+ .iv = iommu_intremap,
};
}
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] xen/arm: initialize vpl011 flag register
The tx/rx fifo flags were not set when the vpl011 is initialized. This is a problem for certain guests that are operating in polled mode, as a guest will generally check the rx fifo empty flag to determine if there is data before doing a read. The result is a continuous spam of the message "vpl011: Unexpected IN ring buffer empty" before the first valid character is received. This initializes the flag status register to the default specified in the PL011 technical reference manual. Signed-off-by: Jeff Kubascik Changes in v2: - Moved uartfr initialization to later point in function after potential return/failure points --- xen/arch/arm/vpl011.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c index 7bc5eeb207..895f436cc4 100644 --- a/xen/arch/arm/vpl011.c +++ b/xen/arch/arm/vpl011.c @@ -668,6 +668,8 @@ int domain_vpl011_init(struct domain *d, struct vpl011_init_info *info) goto out2; } +vpl011->uartfr = TXFE | RXFE; + spin_lock_init(>lock); register_mmio_handler(d, _mmio_handler, -- 2.17.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: initialize vpl011 flag register
Hello, On 11/25/2019 2:20 PM, Julien Grall wrote: > Hi, > > On 25/11/2019 18:35, Jeff Kubascik wrote: >> The tx/rx fifo flags were not set when the vpl011 is initialized. This >> is a problem for certain guests that are operating in polled mode, as a >> guest will generally check the rx fifo empty flag to determine if there >> is data before doing a read. The result is a continuous spam of the >> message "vpl011: Unexpected IN ring buffer empty" before the first valid >> character is received. This initializes the flag status register to the >> default specified in the PL011 technical reference manual. > > Note that the vpl011 is not meant to emulate a full PL011. Instead it > emulates the SBSA UART which is a subset of the PL011. They have some > differences and I would be cautious to try to drive it as a PL011. I was not aware of this, but it makes sense. I took a quick peek at the SBSA design doc and the fifo flags are defined. >> >> Signed-off-by: Jeff Kubascik >> --- >> xen/arch/arm/vpl011.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c >> index 7bc5eeb207..31b7d56d7d 100644 >> --- a/xen/arch/arm/vpl011.c >> +++ b/xen/arch/arm/vpl011.c >> @@ -626,6 +626,8 @@ int domain_vpl011_init(struct domain *d, struct >> vpl011_init_info *info) >> if ( vpl011->backend.dom.ring_buf ) >> return -EINVAL; >> >> +vpl011->uartfr = TXFE | RXFE; > > I know that it does not make much difference, but I would prefer if > uartfr is initialized once we know nothing else can fail. Easy enough change, I'll send out an updated patch. > With or without this suggestion: > > Acked-by: Julien Gral > > Cheers, > > -- > Julien Grall > Thanks! Jeff Kubascik ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.11-testing test] 144293: regressions - FAIL
flight 144293 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/144293/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 144025 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 74507046dbd2c5d2991eeabd1af39af0d6b29d70 baseline version: xen 006b2041242129896fbd30135b3dc6f575894a07 Last test of basis 144025 2019-11-11 17:36:00 Z 14 days Testing same since 144058 2019-11-12 18:05:56 Z 13 days 23 attempts
Re: [Xen-devel] [PATCH] xen/arm: initialize vpl011 flag register
Hi, On 25/11/2019 18:35, Jeff Kubascik wrote: The tx/rx fifo flags were not set when the vpl011 is initialized. This is a problem for certain guests that are operating in polled mode, as a guest will generally check the rx fifo empty flag to determine if there is data before doing a read. The result is a continuous spam of the message "vpl011: Unexpected IN ring buffer empty" before the first valid character is received. This initializes the flag status register to the default specified in the PL011 technical reference manual. Note that the vpl011 is not meant to emulate a full PL011. Instead it emulates the SBSA UART which is a subset of the PL011. They have some differences and I would be cautious to try to drive it as a PL011. Signed-off-by: Jeff Kubascik --- xen/arch/arm/vpl011.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c index 7bc5eeb207..31b7d56d7d 100644 --- a/xen/arch/arm/vpl011.c +++ b/xen/arch/arm/vpl011.c @@ -626,6 +626,8 @@ int domain_vpl011_init(struct domain *d, struct vpl011_init_info *info) if ( vpl011->backend.dom.ring_buf ) return -EINVAL; +vpl011->uartfr = TXFE | RXFE; I know that it does not make much difference, but I would prefer if uartfr is initialized once we know nothing else can fail. With or without this suggestion: Acked-by: Julien Gral Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13 v2 1/9] libxl: Offer API versions 0x040700 and 0x040800
On 10/10/19 9:11 AM, Ian Jackson wrote: > According to git log -G: > > 0x040700 was introduced in 304400459ef0 (aka 4.7.0-rc1~481) >"tools/libxl: rename remus device to checkpoint device" > > 0x040800 was introduced in 57f8b13c7240 (aka 4.8.0-rc1~437) >"libxl: memory size in kb requires 64 bit variable" > > It is surprising that no-one noticed this. I am now noticing it :-(. As Anthony noted in V1, libvirt uses LIBXL_API_VERSION and currently has it set to 0x040500. I'm attempting to bump libvirt's minimum supported Xen version to 4.9.0 and for that would use 0x040800, but it's not possible without this commit backported through 4.9 and picked up and released by all the downstreams. Any ideas on how to use the APIs changes through 0x040800, but avoid the ones introduced in 0x041300 would be much appreciated. Regards, Jim ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] xen/arm: initialize vpl011 flag register
The tx/rx fifo flags were not set when the vpl011 is initialized. This is a problem for certain guests that are operating in polled mode, as a guest will generally check the rx fifo empty flag to determine if there is data before doing a read. The result is a continuous spam of the message "vpl011: Unexpected IN ring buffer empty" before the first valid character is received. This initializes the flag status register to the default specified in the PL011 technical reference manual. Signed-off-by: Jeff Kubascik --- xen/arch/arm/vpl011.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c index 7bc5eeb207..31b7d56d7d 100644 --- a/xen/arch/arm/vpl011.c +++ b/xen/arch/arm/vpl011.c @@ -626,6 +626,8 @@ int domain_vpl011_init(struct domain *d, struct vpl011_init_info *info) if ( vpl011->backend.dom.ring_buf ) return -EINVAL; +vpl011->uartfr = TXFE | RXFE; + /* * info is NULL when the backend is in Xen. * info is != NULL when the backend is in a domain. -- 2.17.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Status of 4.13
On Mon, Nov 25, 2019 at 05:34:15PM +, Andrew Cooper wrote:
> On 25/11/2019 17:27, Roger Pau Monné wrote:
> > On Mon, Nov 25, 2019 at 05:07:04PM +, Wei Liu wrote:
> >> On Mon, Nov 25, 2019 at 04:59:31PM +0100, Roger Pau Monné wrote:
> >> [...]
> >>> Which I think it's expected, we already knew clang had a lot of
> >>> duplicate symbols. The only way I know to workaround this ATM is to
> >>> use `gmake xen clang=y CONFIG_ENFORCE_UNIQUE_SYMBOLS=n`. It's on my
> >>> pile of stuff to look into, but I'm not sure when I will get to it.
> >> In that case we should make Gitlab CI use the new configuration option.
> > IMO the build should work out of the box, so we should disable
> > CONFIG_ENFORCE_UNIQUE_SYMBOLS automatically if clang is detected.
>
> Kconfig in 4.13 isn't in a position to know this. (It will be in 4.14
> with Anthony's refresh committed).
We already have Kconfig options that depend on toolchain features,
livepatch itself will be enabled if build id is supported by the
linker, why not use something like:
diff --git a/Config.mk b/Config.mk
index d8f90d75b3..009abda225 100644
--- a/Config.mk
+++ b/Config.mk
@@ -157,6 +157,8 @@ ifndef XEN_HAS_CHECKPOLICY
export XEN_HAS_CHECKPOLICY
endif
+export XEN_BUILD_WITH_CLANG = $(clang)
+
# as-insn: Check whether assembler supports an instruction.
# Usage: cflags-y += $(call as-insn,CC FLAGS,"insn",option-yes,option-no)
as-insn = $(if $(shell echo 'void _(void) { asm volatile ( $(2) ); }' \
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index f754741972..097996fc6c 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -80,6 +80,10 @@ config HAS_CHECKPOLICY
string
option env="XEN_HAS_CHECKPOLICY"
+config BUILD_WITH_CLANG
+ string
+ option env="XEN_BUILD_WITH_CLANG"
+
menu "Speculative hardening"
config SPECULATIVE_HARDEN_ARRAY
@@ -350,7 +354,7 @@ config CRYPTO
config LIVEPATCH
bool "Live patching support"
default X86
- depends on HAS_BUILD_ID = "y"
+ depends on HAS_BUILD_ID = "y" && BUILD_WITH_CLANG != "y"
---help---
Allows a running Xen hypervisor to be dynamically patched using
binary patches without rebooting. This is primarily used to binarily
This WFM with FreeBSD and clang.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Status of 4.13
On Mon, Nov 25, 2019 at 05:34:15PM +, Andrew Cooper wrote: > On 25/11/2019 17:27, Roger Pau Monné wrote: > > On Mon, Nov 25, 2019 at 05:07:04PM +, Wei Liu wrote: > >> On Mon, Nov 25, 2019 at 04:59:31PM +0100, Roger Pau Monné wrote: > >> [...] > >>> Which I think it's expected, we already knew clang had a lot of > >>> duplicate symbols. The only way I know to workaround this ATM is to > >>> use `gmake xen clang=y CONFIG_ENFORCE_UNIQUE_SYMBOLS=n`. It's on my > >>> pile of stuff to look into, but I'm not sure when I will get to it. > >> In that case we should make Gitlab CI use the new configuration option. > > IMO the build should work out of the box, so we should disable > > CONFIG_ENFORCE_UNIQUE_SYMBOLS automatically if clang is detected. > > Kconfig in 4.13 isn't in a position to know this. (It will be in 4.14 > with Anthony's refresh committed). > > Furthermore, the causal chain of LIVEPATCH -> ENFORCE_UNIQUE_SYMBOLS > *is* correct, because livepatching really is bust if duplicate symbols > exist. > > The only option (which is kconfig-specific) is to disable LIVEPATCH by > default. Are you going to submit a patch for 4.13? Wei. > > ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13 v2] x86/domctl: have XEN_DOMCTL_getpageframeinfo3 preemptible
On Mon, Nov 25, 2019 at 05:22:19PM +0100, Jan Beulich wrote: > On 25.11.2019 15:59, Anthony PERARD wrote: > > This hypercall can take a long time to finish because it attempts to > > grab the `hostp2m' lock up to 1024 times. The accumulated wait for the > > lock can take several seconds. > > > > This can easily happen with a guest with 32 vcpus and plenty of RAM, > > during localhost migration. > > > > Signed-off-by: Anthony PERARD > > As indicated on v1 already, this being a workaround rather than a fix > should be stated clearly in the description. Especially if more such > operations turn up, it'll become increasingly obvious that the root > of the problem will need dealing with rather than papering over some > of the symptoms. With this taken care of I'd be (still hesitantly) > willing to give my ack for this as a short term "solution". Sorry to have lead you to believe that the patch was *the* solution to the problem described. I don't think the patch itself is a workaround or a fix, it is simply an improvement to the hypercall. That improvement could be used to remove the limit on `num' (something that I've read on xen-devel as a possible improvement). Would it be enough to add this following paragraph to the commit description? While the patch doesn't fix the problem with the lock contention and the fact that the `hostp2m' lock is currently global (and not on a single page), it is still an improvement to the hypercall. I don't like the terms "workaround" or "short term solution" as a description for this patch. Both implies that the patch could be reverted once the root issue is taking care of. I'll keep working to try to improve the use of the hostp2m lock, at least with that hypercall, but I don't have a solution yet and it would be nice to have this patch in the release. > > diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h > > index a03e80e5984a..1b69eb75cb20 100644 > > --- a/xen/include/public/domctl.h > > +++ b/xen/include/public/domctl.h > > @@ -163,6 +163,10 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getdomaininfo_t); > > #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28) > > > > /* XEN_DOMCTL_getpageframeinfo3 */ > > +/* > > + * Both value `num' and `array' are modified by the hypercall to allow > > + * preemption. > > s/are/may be/ ? I don't think the distinction is necessary. How would that be useful to know that both values may not be modified? I though the goal of the added description was to warn against reusing the values after calling the hypercall. Thanks, -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Status of 4.13
On 25/11/2019 17:27, Roger Pau Monné wrote: > On Mon, Nov 25, 2019 at 05:07:04PM +, Wei Liu wrote: >> On Mon, Nov 25, 2019 at 04:59:31PM +0100, Roger Pau Monné wrote: >> [...] >>> Which I think it's expected, we already knew clang had a lot of >>> duplicate symbols. The only way I know to workaround this ATM is to >>> use `gmake xen clang=y CONFIG_ENFORCE_UNIQUE_SYMBOLS=n`. It's on my >>> pile of stuff to look into, but I'm not sure when I will get to it. >> In that case we should make Gitlab CI use the new configuration option. > IMO the build should work out of the box, so we should disable > CONFIG_ENFORCE_UNIQUE_SYMBOLS automatically if clang is detected. Kconfig in 4.13 isn't in a position to know this. (It will be in 4.14 with Anthony's refresh committed). Furthermore, the causal chain of LIVEPATCH -> ENFORCE_UNIQUE_SYMBOLS *is* correct, because livepatching really is bust if duplicate symbols exist. The only option (which is kconfig-specific) is to disable LIVEPATCH by default. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Status of 4.13
On Mon, Nov 25, 2019 at 05:07:04PM +, Wei Liu wrote: > On Mon, Nov 25, 2019 at 04:59:31PM +0100, Roger Pau Monné wrote: > [...] > > > > Which I think it's expected, we already knew clang had a lot of > > duplicate symbols. The only way I know to workaround this ATM is to > > use `gmake xen clang=y CONFIG_ENFORCE_UNIQUE_SYMBOLS=n`. It's on my > > pile of stuff to look into, but I'm not sure when I will get to it. > > In that case we should make Gitlab CI use the new configuration option. IMO the build should work out of the box, so we should disable CONFIG_ENFORCE_UNIQUE_SYMBOLS automatically if clang is detected. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/2] x86/tlbflush: do not toggle the PGE CR4 bit unless necessary
When PCID is not available Xen does a full tlbflush by toggling the
PGE bit in CR4. This is not necessary if PGE is not enabled, since a
flush can be performed by writing to CR3 in that case.
Change the code in do_tlb_flush to only toggle the PGE bit in CR4 if
it's already enabled, otherwise do the tlb flush by writing to CR3.
This is relevant when running virtualized, since hypervisors don't
usually trap accesses to CR3 when using hardware assisted paging, but
do trap accesses to CR4 specially on AMD hardware, which makes such
accesses much more expensive.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/flushtlb.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c
index c1ae0d9467..540209c856 100644
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -84,6 +84,7 @@ static void post_flush(u32 t)
static void do_tlb_flush(void)
{
unsigned long flags;
+unsigned long cr4;
u32 t;
/* This non-reentrant function is sometimes called in interrupt context. */
@@ -93,13 +94,13 @@ static void do_tlb_flush(void)
if ( use_invpcid )
invpcid_flush_all();
-else
+else if ( (cr4 = read_cr4()) & X86_CR4_PGE )
{
-unsigned long cr4 = read_cr4();
-
-write_cr4(cr4 ^ X86_CR4_PGE);
+write_cr4(cr4 & ~X86_CR4_PGE);
write_cr4(cr4);
}
+else
+write_cr3(read_cr3());
post_flush(t);
--
2.24.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/2] x86/pvshim: improve tlb flush performance
Hello, Enabling PGE in CR4 causes a huge performance penalty when running the shim on AMD hardware, this patch series avoids enabling PGE when in shim mode, and makes a small adjustment in do_tlb_flush to perform a flush by writing to CR3 if PGE is not enabled. Roger Pau Monne (2): x86/tlbflush: do not toggle the PGE CR4 bit unless necessary x86/pvshim: do not enable global pages in shim mode xen/arch/x86/flushtlb.c | 9 + xen/arch/x86/pv/domain.c | 3 ++- 2 files changed, 7 insertions(+), 5 deletions(-) -- 2.24.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/2] x86/pvshim: do not enable global pages in shim mode
When using global pages a full tlb flush can only be performed by
toggling the PGE bit in CR4, which is usually quite expensive in terms
of performance when running virtualized. This is specially relevant on
AMD hardware, which doesn't have the ability to do selective CR4
trapping, but can also be relevant on Intel if the underlying
hypervisor also traps on accesses to the PGE CR4 bit.
In order to avoid this performance penalty, do not use global pages
when running in shim mode. Note this is done when running on both
Intel or AMD hardware, since older versions of Xen capable of running
the shim don't make use of Intel selective CR4 trapping feature and
will vmexit on every access to CR4.
The above figures are from a PV shim running on AMD hardware with
32 vCPUs:
PGE enabled, x2APIC mode:
(XEN) Global lock flush_lock: addr=82d0804b01c0, lockval=1adb1adb, not
locked
(XEN) lock:1841883(1375128998543), block:1658716(10193054890781)
Average lock time: 746588ns
Average block time: 6145147ns
PGE disabled, x2APIC mode:
(XEN) Global lock flush_lock: addr=82d0804af1c0, lockval=a8bfa8bf, not
locked
(XEN) lock:2730175(657505389886), block:2039716(2963768247738)
Average lock time: 240829ns
Average block time: 1453029ns
As seen from the above figures the block time of the flush lock is
reduced to approximately 1/3 of the original value.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/pv/domain.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 4b6f48dea2..36f3903dcb 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
static __read_mostly enum {
@@ -130,7 +131,7 @@ unsigned long pv_make_cr4(const struct vcpu *v)
*/
if ( d->arch.pv.pcid )
cr4 |= X86_CR4_PCIDE;
-else if ( !d->arch.pv.xpti )
+else if ( !d->arch.pv.xpti && !pv_shim )
cr4 |= X86_CR4_PGE;
/*
--
2.24.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] create-diff-object: more precisely identify .rodata sections
On 11/5/19 3:37 PM, Pawel Wieczorkiewicz wrote: > This is needed for more precise patchability verification. > Only non-special .rodata sections should be subject > for such a non-referenced check in kpatch_verify_patchability(). > Current check (non-standard, non-rela, non-debug) is too weak and > allows also non-rodata sections without referenced symbols to slip > through. > > Detect .rodata section by checking section's type (SHT_PROGBITS), > flags (no exec, no write) and finally name prefix. > > Signed-off-by: Pawel Wieczorkiewicz > Reviewed-by: Andra-Irina Paraschiv > Reviewed-by: Bjoern Doebel > Reviewed-by: Norbert Manthey > --- Reviewed-by: Ross Lagerwall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Status of 4.13
On Mon, Nov 25, 2019 at 04:59:31PM +0100, Roger Pau Monné wrote: [...] > > Which I think it's expected, we already knew clang had a lot of > duplicate symbols. The only way I know to workaround this ATM is to > use `gmake xen clang=y CONFIG_ENFORCE_UNIQUE_SYMBOLS=n`. It's on my > pile of stuff to look into, but I'm not sure when I will get to it. In that case we should make Gitlab CI use the new configuration option. Wei. > > Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] create-diff-object: do not strip STN_UNDEF symbols from *.fixup
On 11/5/19 3:37 PM, Pawel Wieczorkiewicz wrote: > The rela groups in the *.fixup sections vary in size. That makes it > more complex to handle in the livepatch_strip_undefined_elements(). > It is also unnecessary as the .fixup sections are unlikely to have > any STN_UNDEF symbols anyway. > > Signed-off-by: Pawel Wieczorkiewicz > --- Reviewed-by: Ross Lagerwall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 7/7] livepatch-build: Strip all metadata symbols from hotpatch modules
On 9/16/19 12:30 PM, Pawel Wieczorkiewicz wrote: > Strip all unneeded metadata symbols from generated hotpatch modules. > The metadata symbols are the symbols from metadata-like sections (e.g. > '.livepatch.funcs') or livepatch hooks symbols (defined by a set of > prefixes. E.g. 'livepatch_load_data_'). > > By default the create-diff-object does not create symbols in metadata > sections. However, such symbols may be implicitly added by speciying > extra entries in the sections manually (in a given patch). > The symbols are not needed for the hotpatch modules and should be > stripped to avoid symbol names collisions and to save hotpatch files > space. > > Signed-off-by: Pawel Wieczorkiewicz Reviewed-by: Ross Lagerwall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.12-testing test] 144291: regressions - FAIL
flight 144291 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/144291/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 144035 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 144007 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 0138da196c8c334589a25144d4d69bf6553e2658 baseline version: xen 278e46ae8f99485915ae662e7905c8333a55048a Last test of basis 144035 2019-11-12 00:36:50 Z 13 days Testing same since 144059 2019-11-12 19:10:11 Z 12 days 22 attempts People who touched revisions under test: Andrew Cooper George Dunlap jobs:
Re: [Xen-devel] [XEN PATCH for-4.13 v2] x86/domctl: have XEN_DOMCTL_getpageframeinfo3 preemptible
On 25.11.2019 15:59, Anthony PERARD wrote:
> This hypercall can take a long time to finish because it attempts to
> grab the `hostp2m' lock up to 1024 times. The accumulated wait for the
> lock can take several seconds.
>
> This can easily happen with a guest with 32 vcpus and plenty of RAM,
> during localhost migration.
>
> Signed-off-by: Anthony PERARD
As indicated on v1 already, this being a workaround rather than a fix
should be stated clearly in the description. Especially if more such
operations turn up, it'll become increasingly obvious that the root
of the problem will need dealing with rather than papering over some
of the symptoms. With this taken care of I'd be (still hesitantly)
willing to give my ack for this as a short term "solution".
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -425,6 +425,26 @@ long arch_do_domctl(
> ret = -EFAULT;
> break;
> }
> +
> +/*
> + * Avoid checking for preemption when the `hostp2m' lock isn't
> + * involve, i.e. non-translated guest, and avoid preemption on
> + * the last iteration.
> + */
> +if ( paging_mode_translate(d) &&
> + likely((i + 1) < num) && hypercall_preempt_check() )
> +{
> +domctl->u.getpageframeinfo3.num = num - i - 1;
> +domctl->u.getpageframeinfo3.array.p =
> +guest_handle + ((i + 1) * width);
> +if ( __copy_to_guest(u_domctl, domctl, 1) )
> +{
> +ret = -EFAULT;
> +break;
> +}
> +return hypercall_create_continuation(__HYPERVISOR_domctl,
> + "h", u_domctl);
> +}
> }
>
> break;
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index a03e80e5984a..1b69eb75cb20 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -163,6 +163,10 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getdomaininfo_t);
> #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>
> /* XEN_DOMCTL_getpageframeinfo3 */
> +/*
> + * Both value `num' and `array' are modified by the hypercall to allow
> + * preemption.
s/are/may be/ ?
If Juergen wants to still allow this in, I'd be fine taking care of both
remarks while committing.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] xen/arm: remove physical timer offset
The physical timer traps apply an offset so that time starts at 0 for
the guest. However, this offset is not currently applied to the physical
counter. Per the ARMv8 Arch Reference Manual, the offset between the
physical timer and counter should be 0. This removes the offset to make
the timer and counter consistent.
Xen time is at offset boot_count from the physical counter, so we need
to take this into account when reading/writing to CNTP_CVAL.
Signed-off-by: Jeff Kubascik
---
xen/arch/arm/vtimer.c| 18 ++
xen/include/asm-arm/domain.h | 3 ---
2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index e6aebdac9e..4790b5ce58 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -62,7 +62,6 @@ static void virt_timer_expired(void *data)
int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config)
{
-d->arch.phys_timer_base.offset = NOW();
d->arch.virt_timer_base.offset = READ_SYSREG64(CNTPCT_EL0);
d->time_offset_seconds = ticks_to_ns(d->arch.virt_timer_base.offset -
boot_count);
do_div(d->time_offset_seconds, 10);
@@ -184,8 +183,7 @@ static bool vtimer_cntp_ctl(struct cpu_user_regs *regs,
uint32_t *r, bool read)
if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
{
-set_timer(>arch.phys_timer.timer,
- v->arch.phys_timer.cval +
v->domain->arch.phys_timer_base.offset);
+set_timer(>arch.phys_timer.timer, v->arch.phys_timer.cval);
}
else
stop_timer(>arch.phys_timer.timer);
@@ -202,7 +200,7 @@ static bool vtimer_cntp_tval(struct cpu_user_regs *regs,
uint32_t *r,
if ( !ACCESS_ALLOWED(regs, EL0PTEN) )
return false;
-now = NOW() - v->domain->arch.phys_timer_base.offset;
+now = NOW();
if ( read )
{
@@ -214,9 +212,7 @@ static bool vtimer_cntp_tval(struct cpu_user_regs *regs,
uint32_t *r,
if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
{
v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
-set_timer(>arch.phys_timer.timer,
- v->arch.phys_timer.cval +
- v->domain->arch.phys_timer_base.offset);
+set_timer(>arch.phys_timer.timer, v->arch.phys_timer.cval);
}
}
return true;
@@ -232,17 +228,15 @@ static bool vtimer_cntp_cval(struct cpu_user_regs *regs,
uint64_t *r,
if ( read )
{
-*r = ns_to_ticks(v->arch.phys_timer.cval);
+*r = ns_to_ticks(v->arch.phys_timer.cval) + boot_count;
}
else
{
-v->arch.phys_timer.cval = ticks_to_ns(*r);
+v->arch.phys_timer.cval = ticks_to_ns(*r - boot_count);
if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
{
v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
-set_timer(>arch.phys_timer.timer,
- v->arch.phys_timer.cval +
- v->domain->arch.phys_timer_base.offset);
+set_timer(>arch.phys_timer.timer, v->arch.phys_timer.cval);
}
}
return true;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 86ebdd2bcf..16a7150a95 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -65,9 +65,6 @@ struct arch_domain
RELMEM_done,
} relmem;
-struct {
-uint64_t offset;
-} phys_timer_base;
struct {
uint64_t offset;
} virt_timer_base;
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Status of 4.13
On Mon, Nov 25, 2019 at 02:06:06PM +, Wei Liu wrote: > Cc Roger -- you're our resident Clang expert. :-) > > On Mon, Nov 25, 2019 at 08:02:17AM -0600, Doug Goldstein wrote: > > On 11/21/19 12:05 AM, Jürgen Groß wrote: > > > > > Where do we stand with Xen 4.13 regarding blockers and related patches? > > > > > 1. Currently the default "make install" fails with errors in > > tools/tests/x86_emulator if you don't have a new enough GCC. Causing > > failures on distros that are considered still supported based on README. > > > > 2. The hypervisor currently fails to build with clang using versions that > > READM says are supported no matter the configuration. > > > > Do you have a link to the log? I guess the answer is to go to gitlab? This is what I get: [...] clang -D__ASSEMBLY__ -m64 -DBUILD_ID -fno-strict-aliasing -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-local-typedefs -O1 -fno-omit-frame-pointer -nostdinc -fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith -Wvla -pipe -D__XEN__ -include /root/src/xen/xen/include/xen/config.h '-D__OBJECT_FILE__="/root/src/xen/xen/.xen-syms.0.o"' -g -MMD -MF /root/src/xen/xen/..xen-syms.0.o.d -DXEN_BUILD_EFI -I/root/src/xen/xen/include -I/root/src/xen/xen/include/asm-x86/mach-generic -I/root/src/xen/xen/include/asm-x86/mach-default -DXEN_IMG_OFFSET=0x20 '-D__OBJECT_LABEL__=arch$x86$$root$src$xen$xen$.xen_syms.0.o' -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs -DHAVE_AS_VMX -DHAVE_AS_SSE4_2 -DHAVE_AS_EPT -DHAVE_AS_RDRAND -DHAVE_AS_FSGSBASE -DHAVE_AS_XSAVEOPT -DHAVE_AS_RDSEED -DHAVE_AS_CLWB -U__OBJECT_LABEL__ -DHAVE_AS_QUOTED_SYM '-D__OBJECT_LABEL__=arch/x86//root/src/xen/xen/.xen-syms.0.o' -DHAVE_AS_INVPCID -DHAVE_AS_NEGATIVE_TRUE -mno-red-zone -fpic -fno-asynchronous-unwind-tables -mno-sse -DGCC_HAS_VISIBILITY_ATTRIBUTE -Wa,-I/root/src/xen/xen/include -DBUILD_ID_EFI -c /root/src/xen/xen/.xen-syms.0.S -o /root/src/xen/xen/.xen-syms.0.o gmake[4]: Leaving directory '/root/src/xen/xen/arch/x86' ld-melf_x86_64_fbsd -T xen.lds -N prelink.o --build-id=sha1 \ /root/src/xen/xen/.xen-syms.0.o -o /root/src/xen/xen/.xen-syms.1 nm -pa --format=sysv /root/src/xen/xen/.xen-syms.1 \ | /root/src/xen/xen/tools/symbols --all-symbols --sort-by-name --sysv --sort --error-dup \ >/root/src/xen/xen/.xen-syms.1.S Duplicate symbol 'asid.c#get_cpu_info' (82d0803032c0 != 82d0802e0f50) Duplicate symbol 'asid.c#get_cpu_info_from_stack' (82d0802e1080 != 82d0803032f0) Duplicate symbol 'ats.c#__list_add' (82d080260a00 != 82d080267c70) Duplicate symbol 'boot.c#constant_test_bit' (82d08040ea60 != 82d0804372f0) Duplicate symbol 'common.c#clear_bit' (82d080332440 != 82d0802d33b0) Duplicate symbol 'common.c#constant_test_bit' (82d080332340 != 82d0802d2220) Duplicate symbol 'common.c#cpumask_check' (82d0802d3370 != 82d080337b60) Duplicate symbol 'common.c#get_cpu_info' (82d0802d22b0 != 82d080331590) Duplicate symbol 'common.c#get_cpu_info_from_stack' (82d0802d31c0 != 82d0803374b0) Duplicate symbol 'common.c#pfn_to_pdx' (82d0802d3270 != 82d080331e00) Duplicate symbol 'common.c#test_and_set_bit' (82d0802d3360 != 82d080332250) Duplicate symbol 'common.c#variable_clear_bit' (82d0802d2270 != 82d080337b50) Duplicate symbol 'compat.c#get_cpu_info' (82d08026eab0 != 82d080200460) Duplicate symbol 'compat.c#get_cpu_info_from_stack' (82d08026ebd0 != 82d080200f70) Duplicate symbol 'cpu_idle.c#get_cpu_info' (82d0802ccb00 != 82d08035fcc0) Duplicate symbol 'cpu_idle.c#get_cpu_info_from_stack' (82d08035ff60 != 82d0802ce9f0) Duplicate symbol 'cpufreq.c#_xmalloc_array' (82d08024f9e0 != 82d0802d0210) Duplicate symbol 'cpufreq.c#bitmap_empty' (82d0802d0650 != 82d08024fb70) Duplicate symbol 'cpufreq.c#bitmap_weight' (82d0802d06a0 != 82d08024fb50) Duplicate symbol 'cpufreq.c#cpumask_check' (82d0802d0190 != 82d08024fb20) Duplicate symbol 'cpufreq.c#cpumask_empty' (82d0802d05b0 != 82d08024f520) Duplicate symbol 'cpufreq.c#cpumask_first' (82d0802d05c0 != 82d08024f480) Duplicate symbol 'cpufreq.c#cpumask_test_cpu' (82d0802cfba0 != 82d08024f070) Duplicate symbol 'cpufreq.c#cpumask_weight' (82d0802d0660 != 82d08024f4d0) Duplicate symbol 'cpufreq.c#get_cpu_info' (82d0803600e0 != 82d0802cfbd0) Duplicate symbol 'cpufreq.c#get_cpu_info' (82d08024fa10 != 82d0803600e0) Duplicate symbol 'cpufreq.c#get_cpu_info_from_stack' (82d0802d01b0 != 82d08024fb90) Duplicate symbol 'cpufreq.c#get_cpu_info_from_stack' (82d0803600f0 != 82d0802d01b0) Duplicate symbol 'cpufreq.c#variable_test_bit' (82d0802d0180 != 82d08024fb10) Duplicate symbol 'cpuid.c#array_index_mask_nospec' (82d08026e990 != 82d08026bef0) Duplicate symbol 'cpuid.c#constant_test_bit' (82d08026b710 !=
Re: [Xen-devel] [PATCH] AMD/IOMMU: restore DTE fields in amd_iommu_setup_domain_device()
On 14/11/2019 12:28, Igor Druzhinin wrote:
> On 13/11/2019 13:50, Jan Beulich wrote:
>> Commit 1b00c16bdf ("AMD/IOMMU: pre-fill all DTEs right after table
>> allocation") moved ourselves into a more secure default state, but
>> didn't take sufficient care to also undo the effects when handing a
>> previously disabled device back to a(nother) domain. Put the fields
>> that may have been changed elsewhere back to their intended values
>> (some fields amd_iommu_disable_domain_device() touches don't
>> currently get written anywhere else, and hence don't need modifying
>> here).
>>
>> Reported-by: Sander Eikelenboom
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> @@ -114,11 +114,21 @@ static void amd_iommu_setup_domain_devic
>>
>> if ( !dte->v || !dte->tv )
>> {
>> +const struct ivrs_mappings *ivrs_dev;
>> +
>> /* bind DTE to domain page-tables */
>> amd_iommu_set_root_page_table(
>> dte, page_to_maddr(hd->arch.root_table), domain->domain_id,
>> hd->arch.paging_mode, valid);
>>
>> +/* Undo what amd_iommu_disable_domain_device() may have done. */
>> +ivrs_dev = _ivrs_mappings(iommu->seg)[req_id];
>> +if ( dte->it_root )
>> +dte->int_ctl = IOMMU_DEV_TABLE_INT_CONTROL_TRANSLATED;
>> +dte->iv = iommu_intremap;
>> +dte->ex = ivrs_dev->dte_allow_exclusion;
>> +dte->sys_mgt = MASK_EXTR(ivrs_dev->device_flags,
>> ACPI_IVHD_SYSTEM_MGMT);
>> +
>> if ( pci_ats_device(iommu->seg, bus, pdev->devfn) &&
>> iommu_has_cap(iommu, PCI_CAP_IOTLB_SHIFT) )
>> dte->i = ats_enabled;
>>
Jan,
Unfortunately, we're still seeing issues with the original 1b00c16bdf on
AMD Opteron 4162 Lisbon core. It manifests in IOMMU faults during boot:
(XEN) [ 13.072921] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0xa1, fault
address = 0xbf695000, flags = 0x10
(XEN) [ 13.072978] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0xa1, fault
address = 0xbf695040, flags = 0x10
... sometimes followed by assertion in debug builds:
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074311] Assertion '(sp == 0) ||
(peoi[sp-1].vector < vector)' failed at irq.c:1275
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074317] [ Xen-4.13.0-8.0.17-d
x86_64 debug=y Not tainted ]
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074321] CPU:0
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074325] RIP:
e008:[] do_IRQ+0x3fe/0x687
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074332] RFLAGS: 00010046
CONTEXT: hypervisor
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074338] rax: 0001 rbx:
82d0805c74c0 rcx: 00a0
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074342] rdx: 0001 rsi:
0006 rdi: 82d0805c7300
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074347] rbp: 8300bf2bfdd8 rsp:
8300bf2bfd58 r8:
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074386] r9: 83043ffe85d8 r10:
r11: 00030bd0be8f
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074390] r12: 8304340e5100 r13:
00a0 r14:
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074395] r15: 0010 cr0:
8005003b cr4: 06e0
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074399] cr3: 00043a008000 cr2:
7f5947408250
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074402] fsb: gsb:
8880a360 gss:
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074407] ds: es: fs:
gs: ss: e010 cs: e008
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074412] Xen code around
(do_IRQ+0x3fe/0x687):
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074415] 4c 8b ff 41 39 cd 77 02 <0f> 0b
3d be 00 00 00 7e 02 0f 0b 0f b6 c2 48 8d
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074430] Xen stack trace from
rsp=8300bf2bfd58:
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074432]82d080389851
82d080389845 82d080389851 82d080389845
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074440]82d0
83043fe01024 001080389851
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074447]82d080389851
82d080389845 82d080389851
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074453]
8300bf2b
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074459]7cff40d401f7
82d0803898ba 82d0805c7270
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074465]
82d0805cda80 8300bf2bfea0 8300bf2b
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074472]00035e998c9a
0023e3551479 82d080610700
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074478]
0048 8300bf2bfef8
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074484]
Re: [Xen-devel] [PATCH] AMD/IOMMU: restore DTE fields in amd_iommu_setup_domain_device()
On 14/11/2019 12:28, Igor Druzhinin wrote:
> On 13/11/2019 13:50, Jan Beulich wrote:
>> Commit 1b00c16bdf ("AMD/IOMMU: pre-fill all DTEs right after table
>> allocation") moved ourselves into a more secure default state, but
>> didn't take sufficient care to also undo the effects when handing a
>> previously disabled device back to a(nother) domain. Put the fields
>> that may have been changed elsewhere back to their intended values
>> (some fields amd_iommu_disable_domain_device() touches don't
>> currently get written anywhere else, and hence don't need modifying
>> here).
>>
>> Reported-by: Sander Eikelenboom
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> @@ -114,11 +114,21 @@ static void amd_iommu_setup_domain_devic
>>
>> if ( !dte->v || !dte->tv )
>> {
>> +const struct ivrs_mappings *ivrs_dev;
>> +
>> /* bind DTE to domain page-tables */
>> amd_iommu_set_root_page_table(
>> dte, page_to_maddr(hd->arch.root_table), domain->domain_id,
>> hd->arch.paging_mode, valid);
>>
>> +/* Undo what amd_iommu_disable_domain_device() may have done. */
>> +ivrs_dev = _ivrs_mappings(iommu->seg)[req_id];
>> +if ( dte->it_root )
>> +dte->int_ctl = IOMMU_DEV_TABLE_INT_CONTROL_TRANSLATED;
>> +dte->iv = iommu_intremap;
>> +dte->ex = ivrs_dev->dte_allow_exclusion;
>> +dte->sys_mgt = MASK_EXTR(ivrs_dev->device_flags,
>> ACPI_IVHD_SYSTEM_MGMT);
>> +
>> if ( pci_ats_device(iommu->seg, bus, pdev->devfn) &&
>> iommu_has_cap(iommu, PCI_CAP_IOTLB_SHIFT) )
>> dte->i = ats_enabled;
>>
Jan,
Unfortunately, with 1b00c16bdf and this fix on top we're still getting
issues on some old AMD hardware: Lisbon core Opteron 4162.
(XEN) [ 13.072921] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0xa1, fault
address = 0xbf695000, flags = 0x10
(XEN) [ 13.072978] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0xa1, fault
address = 0xbf695040, flags = 0x10
Sometimes accompanied by assertion later:
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074311] Assertion '(sp == 0) ||
(peoi[sp-1].vector < vector)' failed at irq.c:1275
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074317] [ Xen-4.13.0-8.0.17-d
x86_64 debug=y Not tainted ]
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074321] CPU:0
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074325] RIP:
e008:[] do_IRQ+0x3fe/0x687
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074332] RFLAGS: 00010046
CONTEXT: hypervisor
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074338] rax: 0001 rbx:
82d0805c74c0 rcx: 00a0
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074342] rdx: 0001 rsi:
0006 rdi: 82d0805c7300
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074347] rbp: 8300bf2bfdd8 rsp:
8300bf2bfd58 r8:
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074386] r9: 83043ffe85d8 r10:
r11: 00030bd0be8f
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074390] r12: 8304340e5100 r13:
00a0 r14:
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074395] r15: 0010 cr0:
8005003b cr4: 06e0
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074399] cr3: 00043a008000 cr2:
7f5947408250
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074402] fsb: gsb:
8880a360 gss:
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074407] ds: es: fs:
gs: ss: e010 cs: e008
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074412] Xen code around
(do_IRQ+0x3fe/0x687):
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074415] 4c 8b ff 41 39 cd 77 02 <0f> 0b
3d be 00 00 00 7e 02 0f 0b 0f b6 c2 48 8d
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074430] Xen stack trace from
rsp=8300bf2bfd58:
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074432]82d080389851
82d080389845 82d080389851 82d080389845
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074440]82d0
83043fe01024 001080389851
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074447]82d080389851
82d080389845 82d080389851
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074453]
8300bf2b
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074459]7cff40d401f7
82d0803898ba 82d0805c7270
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074465]
82d0805cda80 8300bf2bfea0 8300bf2b
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074472]00035e998c9a
0023e3551479 82d080610700
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074478]
0048 8300bf2bfef8
[2019-11-22 01:54:57 UTC] (XEN) [ 13.074484]
00a0
Re: [Xen-devel] Xen hiding thermal capabilities from Dom0
On 25.11.2019 16:43, Rishi wrote: > Next is the MSR read for actual temperature values. Currently > rdmsr_safe_on_cpu is being used, does it already get converted to a > Hypercall to be able to detect values? > While tracing the function calls from code, rdmsr_safe_on_cpu() -> > rdmsr_safe() -> native_read_msr_safe() -> asm volatile() comes up. > I can see xen_read_msr_safe() but not sure if this or its any other > variant can be called. None of these are suitable, as mentioned before, as they're all acting in terms of vCPU-s, while you want to act on pCPU-s. You're unlikely to be able to make this work without first making Xen allow Dom0 access to these MSRs via the indicated platform-op (or yet something more intrusive). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen hiding thermal capabilities from Dom0
On Mon, Nov 25, 2019 at 1:55 PM Jürgen Groß wrote: > > On 23.11.19 05:29, Elliott Mitchell wrote: > > On Thu, Nov 21, 2019 at 04:46:21PM +0100, J??rgen Gro?? wrote: > >> On 21.11.19 16:36, Jan Beulich wrote: > >>> On 21.11.2019 15:24, J??rgen Gro?? wrote: > So: no, just giving dom0 access to the management hardware isn't going > to fly. You need to have a proper virtualization layer for that purpose. > >>> > >>> Or, like I had done in our XenoLinux forward port, you need to > >>> go through hoops to make the coretemp driver actually understand > >>> the environment it's running in. > >> > >> This will still not guarantee you'll be able to reach all physical > >> cpus. IIRC you pinned the vcpu to the respective physical cpu for > >> performing its duty, but with cpupools this might not be possible for > >> all physical cpus in the system. > > > > Similar to the issue of MCE support, might it instead be better to have > > *less* virtualization here instead of more? The original idea behind Xen > > was to leave the hard to virtualize bits visible and work with Domain 0. > > > > Might it be better to expose this functionality to Domain 0, then > > intercept the kernel calls? Just needs 1 vcpu which can be scheduled on > > any processor and that can be moved around to retrieve the data. This > > way Xen wouldn't need a proper driver for the management hardware. > > In case dom0 is to handle this then it would be much easier to have a > way for dom0 to specify which physical cpu the data should be retrieved > from. Forcing a dom0 vcpu to run on a specific physical cpu would need > a major rework of the Xen scheduling (especially regarding cpupools, let > alone core scheduling). > > > Juergen While modifying coretemp driver, following CPU flags came across X86_FEATURE_DTHERM X86_FEATURE_PTS Need to replace/get these via Xen hypercall. This only detects if DTHERM and PTS support is present. Currently bypassing them in code and will wait for a proper EAX exposure. Next is the MSR read for actual temperature values. Currently rdmsr_safe_on_cpu is being used, does it already get converted to a Hypercall to be able to detect values? While tracing the function calls from code, rdmsr_safe_on_cpu() -> rdmsr_safe() -> native_read_msr_safe() -> asm volatile() comes up. I can see xen_read_msr_safe() but not sure if this or its any other variant can be called. I haven't gone into depth of this and would appreciate pointers to understand more. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] getting 4.12.2 ready
All, the 4.12.2 stable release is due in about 2 weeks time. Please point out backporting candidates that you find missing from the respective stable trees. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 144292: all pass - PUSHED
flight 144292 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/144292/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf e0f8261ad02217fa8ed57c95c379c2fc8fd67210 baseline version: ovmf 54a07f8fe088d1fe3b7a6fec76d64ab25cdba656 Last test of basis 144231 2019-11-20 23:39:24 Z4 days Testing same since 144292 2019-11-25 06:08:58 Z0 days1 attempts People who touched revisions under test: Fan, ZhijuX Zhiju.Fan 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 54a07f8fe0..e0f8261ad0 e0f8261ad02217fa8ed57c95c379c2fc8fd67210 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen-unstable + linux 5.4.0-rc8: RIP: 0010:xennet_poll+0x35f/0xae0
On 25/11/2019 15:42, Jan Beulich wrote: > On 25.11.2019 15:21, Sander Eikelenboom wrote: >> L.S., >> >> At present one of my PVH VM's kernel crashed with the splat below >> (haven't seen it before, so could be something that happens sporadically). >> >> Any ideas ? >> >> -- >> Sander >> >> >> >> database databaselogin: login: [184503.428811] general protection fault: >> [#1] SMP NOPTI >> [184503.428887] CPU: 0 PID: 0 Comm: swapper/0 Not tainted >> 5.4.0-rc8-20191123-doflr-mac80211debug+ #1 >> [184503.428932] RIP: 0010:xennet_poll+0x35f/0xae0 >> [184503.428955] Code: ba 00 01 00 00 48 8b 8d c0 00 00 00 0f b7 b4 24 92 00 >> 00 00 48 8b 5c 24 78 3d 00 01 00 00 0f 4e d0 89 55 28 8b 95 bc 00 00 00 <89> >> 74 11 3c 48 8b 8d c0 00 00 00 8b 95 bc 00 00 00 89 44 11 38 89 > > The insn here being "mov %esi,(%rcx,%rdx,0x3c)" ... > >> [184503.429027] RSP: 0018:c9003e10 EFLAGS: 00010287 >> [184503.429049] RAX: 0042 RBX: c9003e88 RCX: >> fffe88800b865a80 > > ... I notice corruption to bit 48 of RCX here. This can be a result of > memory corruption, but prior instances of such that I had to look into > were bit flips in the CPU instead. Is this a server or desktop class > CPU? > > Jan > Desktop (AMD phenom II X6) I have had some other kernel splats in kernel networking code the last months that didn't make sense to maintainers and that were written off to "some kind of corruption". So I will see to schedule a run of memtest86 just to try to rule out memory going bad. -- Sander ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH v3 07/11] xen: arm: vgic: allow delivery of PPIs to guests
(+ Andre) On 23/11/2019 20:35, Julien Grall wrote: Hi, On 15/11/2019 20:10, Stewart Hildebrand wrote: Allow vgic_get_hw_irq_desc to be called with a vcpu argument. Use vcpu argument in vgic_connect_hw_irq. vgic_connect_hw_irq is called for PPIs and SPIs, not SGIs. Enforce with ASSERTs. Signed-off-by: Stewart Hildebrand --- v3: new patch --- Note: I have only modified the old vgic to allow delivery of PPIs. The new vGIC should also be modified to support delivery of PPIs. diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c index 82f524a35c..c3933c2687 100644 --- a/xen/arch/arm/vgic.c +++ b/xen/arch/arm/vgic.c @@ -410,10 +410,10 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n) irq_set_affinity(p->desc, cpumask_of(v_target->processor)); spin_lock_irqsave(>desc->lock, flags); /* - * The irq cannot be a PPI, we only support delivery of SPIs - * to guests. + * The irq cannot be a SGI, we only support delivery of SPIs + * and PPIs to guests. */ - ASSERT(irq >= 32); + ASSERT(irq >= NR_SGIS); We usually put ASSERT() in place we know that code wouldn't be able to work correctly if there ASSERT were hit. In this particular case: if ( irq_type_set_by_domain(d) ) gic_set_irq_type(p->desc, vgic_get_virq_type(v, n, i)); 1) We don't want to allow any domain (including Dom0) to modify the interrupt type (i.e. level/edge) for PPIs as this is shared. You will also most likely need to modify the counterpart in setup_guest_irq(). p->desc->handler->enable(p->desc); 2) On GICv3, the re-distributor of vCPU A is accessible by vCPU B. So vCPU B could enable the SGI for vCPU A. But this would be called on the wrong pCPU leading to inconsistency between the hardware state of the internal vGIC state. I thought a bit more of the issue over the week-end. The current vGIC is fairly messy. I can see two solutions on how to solve this: 1) Send an IPI to the pCPU where the vCPU A is running and disable/enable the interrupt. The other side would need to the vCPU was actually running to avoid disabling the PPI for the wrong pCPU 2) Keep the HW interrupt always enabled We propagated the enable/disable because of some messy part in the vGIC: - vgic_inject_irq() will not queue any pending interrupt if the vCPU is offline. While interrupt cannot be delivered, we still need to keep them pending as they will never occur again otherwise. This is because they are active on the host side and the guest has no way to deactivate them. - Our implementation of PSCI CPU will remove all pending interrupts (see vgic_clear_pending_irqs()). I am not entirely sure the implication here because of the previous. There are a probably more. Aside the issues with it, I don't really see good advantage to propagate the interrupt state as the interrupts (PPIs, SPIs) have active state. So they can only be received once until the guest actually handles it. So my preference would still be 2) because this makes the code simpler, avoid IPI and other potential locking trouble. On a side note, there are more issues with enable/disable on the current vGIC as a pending interrupt already in the LR will not get dropped... All of this is quite nasty. The sooner the new vGIC is finished the sooner we can kill the current one. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [XEN PATCH for-4.13 v2] x86/domctl: have XEN_DOMCTL_getpageframeinfo3 preemptible
This hypercall can take a long time to finish because it attempts to
grab the `hostp2m' lock up to 1024 times. The accumulated wait for the
lock can take several seconds.
This can easily happen with a guest with 32 vcpus and plenty of RAM,
during localhost migration.
Signed-off-by: Anthony PERARD
---
Notes:
Changes in v2:
- fix coding style.
- check for translated guests.
- avoid preemption on the last iteration.
- add a comment in the public header.
Further possible improvement to the hypercall:
- process several GFNs after grabbing the hostp2m lock
- Remove the limit
xen/arch/x86/domctl.c | 20
xen/include/public/domctl.h | 4
2 files changed, 24 insertions(+)
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 43e368d63bb9..b461aadbd640 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -425,6 +425,26 @@ long arch_do_domctl(
ret = -EFAULT;
break;
}
+
+/*
+ * Avoid checking for preemption when the `hostp2m' lock isn't
+ * involve, i.e. non-translated guest, and avoid preemption on
+ * the last iteration.
+ */
+if ( paging_mode_translate(d) &&
+ likely((i + 1) < num) && hypercall_preempt_check() )
+{
+domctl->u.getpageframeinfo3.num = num - i - 1;
+domctl->u.getpageframeinfo3.array.p =
+guest_handle + ((i + 1) * width);
+if ( __copy_to_guest(u_domctl, domctl, 1) )
+{
+ret = -EFAULT;
+break;
+}
+return hypercall_create_continuation(__HYPERVISOR_domctl,
+ "h", u_domctl);
+}
}
break;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index a03e80e5984a..1b69eb75cb20 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -163,6 +163,10 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getdomaininfo_t);
#define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
/* XEN_DOMCTL_getpageframeinfo3 */
+/*
+ * Both value `num' and `array' are modified by the hypercall to allow
+ * preemption.
+ */
struct xen_domctl_getpageframeinfo3 {
/* IN variables. */
uint64_aligned_t num;
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-unstable test] 144289: tolerable FAIL
Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 144289: tolerable
FAIL"):
> On 25.11.2019 14:58, osstest service owner wrote:
...
> > test-amd64-amd64-libvirt-xsm 7 xen-boot fail pass in
> > 144283
>
> Other than the shell prompt not appearing, I can't see any
> indication of what may have gone wrong here for which reason.
The last message printed was
random: crng init done
This seemed familiar. Searching my email found
osstest service owner writes ("[osstest test] 143493: regressions - FAIL"):
> flight 143493 osstest real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/143493/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs.
143392
I don't know what this is. Linux fails to boot under Xen. The last
message is
random: crng init done
But it doesn't seem at all probable that this is anything to do
with osstest.
That was with debina1.
So either both these hosts have a similar hardware fault, or there is
something else wrong.
I looked at the next test that ran on debina0 after the failure above,
ie
http://logs.test-lab.xenproject.org/osstest/logs/144289/test-amd64-amd64-i386-pvgrub/info.html
It prints this:
Nov 25 08:51:11.808086 [ 10.030089] random: crng init done
Nov 25 08:51:11.820081 [ 10.030090] random: 7 urandom warning(s) missed due
to ratelimiting
Nov 25 08:51:11.820091 [ 10.040007] RAPL PMU: API unit is 2^-32 Joules, 4
fixed counters, 655360 ms ovfl timer
Nov 25 08:51:11.832079 [ 10.047923] RAPL PMU: hw unit of domain pp0-core
2^-14 Joules
Nov 25 08:51:11.832089 [ 10.053663] RAPL PMU: hw unit of domain package
2^-14 Joules
Nov 25 08:51:11.844084 [ 10.059321] RAPL PMU: hw unit of domain dram 2^-14
Joules
Nov 25 08:51:11.844094 [ 10.064712] RAPL PMU: hw unit of domain pp1-gpu
2^-14 Joules
Nov 25 08:51:11.856045 [ 10.128846] ioatdma: Intel(R) QuickData
Technology Driver 4.00
I think I have seen that message about "warning(s) missed" before.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 00/13] Speed up and restore host history
Jürgen Groß writes ("Re: [Xen-devel] [OSSTEST PATCH 00/13] Speed up and restore
host history"):
> On 20.11.19 18:54, Ian Jackson wrote:
> > Hi, I promised you to do a risk/benefit analysis on this series and
> > here is my report. With your permission I plan to push it on Sunday
> > night or Monday morning, if you think that is a convenient time.
>
> TYVM.
>
> I'm fine with your plan.
Thanks. I have pushed this to osstest pretest. Coincidentally, we
have what looks like it might be a low-probability hardware problem
with debina0. Or maybe some other kind of problem. Hopefully the
longer logs will help diagnose this.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen-unstable + linux 5.4.0-rc8: RIP: 0010:xennet_poll+0x35f/0xae0
On 25.11.2019 15:21, Sander Eikelenboom wrote: > L.S., > > At present one of my PVH VM's kernel crashed with the splat below > (haven't seen it before, so could be something that happens sporadically). > > Any ideas ? > > -- > Sander > > > > database databaselogin: login: [184503.428811] general protection fault: > [#1] SMP NOPTI > [184503.428887] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > 5.4.0-rc8-20191123-doflr-mac80211debug+ #1 > [184503.428932] RIP: 0010:xennet_poll+0x35f/0xae0 > [184503.428955] Code: ba 00 01 00 00 48 8b 8d c0 00 00 00 0f b7 b4 24 92 00 > 00 00 48 8b 5c 24 78 3d 00 01 00 00 0f 4e d0 89 55 28 8b 95 bc 00 00 00 <89> > 74 11 3c 48 8b 8d c0 00 00 00 8b 95 bc 00 00 00 89 44 11 38 89 The insn here being "mov %esi,(%rcx,%rdx,0x3c)" ... > [184503.429027] RSP: 0018:c9003e10 EFLAGS: 00010287 > [184503.429049] RAX: 0042 RBX: c9003e88 RCX: > fffe88800b865a80 ... I notice corruption to bit 48 of RCX here. This can be a result of memory corruption, but prior instances of such that I had to look into were bit flips in the CPU instead. Is this a server or desktop class CPU? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/p2m-pt: fix (latent) page table mapping leak on do_recalc() error paths
On 11/25/19 1:49 PM, Jan Beulich wrote:
> There are two mappings active in the middle of do_recalc(), and hence
> commit 0d0f4d78e5d1 ("p2m: change write_p2m_entry to return an error
> code") should have added (or otherwise invoked) unmapping code just
> like it did in p2m_next_level(), despite us not expecting any errors
> here. Arrange for the existing unmap invocation to take effect in all
> cases.
>
> Signed-off-by: Jan Beulich
Reviewed-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 6/7] livepatch-build: Strip transient or unneeded symbols
On 9/16/19 12:30 PM, Pawel Wieczorkiewicz wrote:
> In the process of creating a final hotpatch module file make sure to
> strip all transient symbols that have not been caught and removed by
> create-diff-object processing. For now these are only the hooks
> kpatch load/unload symbols.
>
> For all new object files that are carried along for the final linking
> the transient hooks symbols are not stripped and neither are any
> unneeded symbols. Strip them explicitly from resulting object file.
>
> Signed-off-by: Pawel Wieczorkiewicz
> ---
> livepatch-build | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/livepatch-build b/livepatch-build
> index b8a1728..816064c 100755
> --- a/livepatch-build
> +++ b/livepatch-build
> @@ -111,6 +111,28 @@ function build_special()
> unset LIVEPATCH_CAPTURE_DIR
> }
>
> +strip_extra_symbols ()
> +{
> +local -r FILE="$1"
> +local -a STRIP_CMD_OPTS=()
> +local -a SYM_PREFIX=("livepatch_load_data_"
> + "livepatch_unload_data_"
> + "livepatch_preapply_data_"
> + "livepatch_apply_data_"
> + "livepatch_postapply_data_"
> + "livepatch_prerevert_data_"
> + "livepatch_revert_data_"
> + "livepatch_postrevert_data_")
> +
> +STRIP_CMD_OPTS+=("-w")
> +for sym in "${SYM_PREFIX[@]}"; do
> +STRIP_CMD_OPTS+=("-N")
> +STRIP_CMD_OPTS+=("\"${sym}*\"")
> +done
> +
> +strip "${STRIP_CMD_OPTS[@]}" "$FILE"
> +}
> +
> function create_patch()
> {
> echo "Extracting new and modified ELF sections..."
> @@ -150,6 +172,7 @@ function create_patch()
> NEW_FILES=$(comm -23 <(cd patched/xen && find . -type f -name '*.o' |
> sort) <(cd original/xen && find . -type f -name '*.o' | sort))
> for i in $NEW_FILES; do
> cp "patched/$i" "output/$i"
> +strip --strip-unneeded "output/$i"
This strips debug symbols too which is not necessarily desirable and I think
for most software is normally left a high level process (e.g. rpmbuild). Can
you make this optional please?
Thanks,
--
Ross Lagerwall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] current staging x86 hypervisor build fails with clang
On 25.11.2019 15:06, Doug Goldstein wrote: > Hello, > > The following build failure happens when using clang to build the hypervisor. > This is a default config. > > make -f /builds/xen-project/xen/xen/Rules.mk > /builds/xen-project/xen/xen/.xen.efi.0r.o > /builds/xen-project/xen/xen/.xen.efi.0s.o > grep -v 'DEFINE_XEN_GUEST_HANDLE(long)' public/nmi.h | \ > python > /builds/xen-project/xen/tools/firmware/xen-dir/xen-root/xen/tools/compat-build-source.py > >compat/nmi.c.new > make[4]: Entering directory '/builds/xen-project/xen/xen/arch/x86' > Duplicate symbol 'asid.c#get_cpu_info' (82d08030c1b0 != 82d0802e8eb0) > Duplicate symbol 'asid.c#get_cpu_info_from_stack' (82d08030c1e0 != > 82d0802e8fe0) > Duplicate symbol 'ats.c#__list_add' (82d080268cd0 != 82d080261770) > Duplicate symbol 'boot.c#constant_test_bit' (82d080432330 != > 82d080408bf0) > Duplicate symbol 'common.c#clear_bit' (82d08033d030 != 82d0802db210) > Duplicate symbol 'common.c#constant_test_bit' (82d08033cf10 != > 82d0802da260) > Duplicate symbol 'common.c#cpumask_check' (82d0803427d0 != > 82d0802db220) > Duplicate symbol 'common.c#get_cpu_info' (82d08033c150 != > 82d0802da280) > Duplicate symbol 'common.c#get_cpu_info_from_stack' (82d080342c20 != > 82d0802db310) > Duplicate symbol 'common.c#test_and_set_bit' (82d08033ce30 != > 82d0802db250) > Duplicate symbol 'common.c#variable_clear_bit' (82d0803427e0 != > 82d0802da240) > Duplicate symbol 'compat.c#get_cpu_info' (82d08026fad0 != > 82d0802004b0) > Duplicate symbol 'compat.c#get_cpu_info_from_stack' (82d08026fc00 != > 82d0802010e0) > Duplicate symbol 'cpu_idle.c#get_cpu_info' (82d08036b690 != > 82d0802d48a0) > Duplicate symbol 'cpu_idle.c#get_cpu_info_from_stack' (82d08036b970 != > 82d0802d71b0) > Duplicate symbol 'cpufreq.c#_xmalloc_array' (82d0802d8740 != > 82d080250520) > Duplicate symbol 'cpufreq.c#bitmap_empty' (82d0802d85b0 != > 82d080250680) > Duplicate symbol 'cpufreq.c#bitmap_weight' (82d0802d85a0 != > 82d0802506b0) > Duplicate symbol 'cpufreq.c#cpumask_check' (82d0802d83a0 != > 82d0802506a0) > Duplicate symbol 'cpufreq.c#cpumask_empty' (82d0802d84e0 != > 82d080250030) > Duplicate symbol 'cpufreq.c#cpumask_first' (82d0802d8330 != > 82d08024ff90) > Duplicate symbol 'cpufreq.c#cpumask_test_cpu' (82d0802d7c50 != > 82d08024fb40) > Duplicate symbol 'cpufreq.c#cpumask_weight' (82d0802d8560 != > 82d08024ffe0) > Duplicate symbol 'cpufreq.c#get_cpu_info' (82d0802d7c80 != > 82d080250540) > Duplicate symbol 'cpufreq.c#get_cpu_info' (82d08036bb10 != > 82d0802d7c80) > Duplicate symbol 'cpufreq.c#get_cpu_info_from_stack' (82d0802d88f0 != > 82d080250660) > Duplicate symbol 'cpufreq.c#get_cpu_info_from_stack' (82d08036bb20 != > 82d0802d88f0) > Duplicate symbol 'cpufreq.c#variable_test_bit' (82d0802d8900 != > 82d0802506d0) > Duplicate symbol 'cpuid.c#array_index_mask_nospec' (82d08026f9b0 != > 82d08026cfb0) > Duplicate symbol 'cpuid.c#get_cpu_info' (82d08026f9d0 != 82d08026cfa0) > Duplicate symbol 'cpuid.c#get_cpu_info_from_stack' (82d08026fa30 != > 82d08026cfd0) > Duplicate symbol 'cpuid.c#zero_leaves' (82d08026f0d0 != 82d08026c6d0) > Duplicate symbol 'dom0_build.c#__maddr_to_virt' (82d08043a460 != > 82d080437c40) > Duplicate symbol 'dom0_build.c#_mfn' (82d080438a30 != 82d080437bf0) > Duplicate symbol 'dom0_build.c#clear_bit' (82d08043b010 != > 82d080437c20) > Duplicate symbol 'dom0_build.c#constant_test_bit' (82d08043a3a0 != > 82d080437f20) > Duplicate symbol 'dom0_build.c#elf_set_vcpu' (82d08043a8a0 != > 82d080437c30) > Duplicate symbol 'dom0_build.c#get_order_from_pages' (82d08043a410 != > 82d080438130) > Duplicate symbol 'dom0_build.c#mfn_x' (82d080438a20 != 82d080437f10) > Duplicate symbol 'dom0_build.c#pdx_to_pfn' (82d08043a3f0 != > 82d080438160) > Duplicate symbol 'dom0_build.c#pfn_to_pdx' (82d080438a00 != > 82d080437ca0) > Duplicate symbol 'dom0_build.c#set_bit' (82d08043dff0 != 82d08043a3c0) > Duplicate symbol 'domain.c#__rdgsbase' (82d080362ea0 != 82d0802789f0) > Duplicate symbol 'domain.c#__virt_to_maddr' (82d080362ff0 != > 82d080273e10) > Duplicate symbol 'domain.c#_gfn' (82d080274a20 != 82d0802099b0) > Duplicate symbol 'domain.c#_gfn' (82d0802eab70 != 82d080274a20) > Duplicate symbol 'domain.c#_mfn' (82d080273aa0 != 82d080208d10) > Duplicate symbol 'domain.c#_mfn' (82d0802eab00 != 82d080273aa0) > Duplicate symbol 'domain.c#_mfn' (82d0803630e0 != 82d0802eab00) > Duplicate symbol 'domain.c#_xzalloc_array' (82d080362b50 != > 82d080207690) > Duplicate symbol 'domain.c#atomic_read' (82d080275f10 != 82d080209960) > Duplicate symbol
Re: [Xen-devel] [PATCH v2 5/7] create-diff-object: Add support for expectations
On 9/16/19 12:30 PM, Pawel Wieczorkiewicz wrote: > Extend livepatch_patch_func to support a new field: expect. This new > field describes the expected data, its length and whether expectation > is enabled. The expectation's data is of opaque padding size. > > By default the expectation field is zero-out and the expectation is > disabled unless explicitly specified in the patch. > > Signed-off-by: Pawel Wieczorkiewicz Reviewed-by: Ross Lagerwall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen-unstable + linux 5.4.0-rc8: RIP: 0010:xennet_poll+0x35f/0xae0
L.S., At present one of my PVH VM's kernel crashed with the splat below (haven't seen it before, so could be something that happens sporadically). Any ideas ? -- Sander database databaselogin: login: [184503.428811] general protection fault: [#1] SMP NOPTI [184503.428887] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.0-rc8-20191123-doflr-mac80211debug+ #1 [184503.428932] RIP: 0010:xennet_poll+0x35f/0xae0 [184503.428955] Code: ba 00 01 00 00 48 8b 8d c0 00 00 00 0f b7 b4 24 92 00 00 00 48 8b 5c 24 78 3d 00 01 00 00 0f 4e d0 89 55 28 8b 95 bc 00 00 00 <89> 74 11 3c 48 8b 8d c0 00 00 00 8b 95 bc 00 00 00 89 44 11 38 89 [184503.429027] RSP: 0018:c9003e10 EFLAGS: 00010287 [184503.429049] RAX: 0042 RBX: c9003e88 RCX: fffe88800b865a80 [184503.429077] RDX: 0140 RSI: RDI: 888005504150 [184503.429107] RBP: 8880f0dfb800 R08: 888103417f00 R09: 888103010848 [184503.429137] R10: R11: 82c6e2e8 R12: 8880f0dfb800 [184503.429167] R13: 0001 R14: c9003ea0 R15: 8880055022e8 [184503.429202] FS: () GS:888103c0() knlGS: [184503.429231] CS: 0010 DS: ES: CR0: 80050033 [184503.429255] CR2: 7faab4774000 CR3: 000101652000 CR4: 06f0 [184503.429283] Call Trace: [184503.429296] [184503.429311] net_rx_action+0x136/0x380 [184503.429331] __do_softirq+0xda/0x2e0 [184503.429349] irq_exit+0x9e/0xa0 [184503.429368] xen_evtchn_do_upcall+0x27/0x40 [184503.429391] xen_hvm_callback_vector+0xf/0x20 [184503.429413] [184503.429425] RIP: 0010:native_safe_halt+0xe/0x10 [184503.429445] Code: 48 8b 04 25 c0 6b 01 00 f0 80 48 02 20 48 8b 00 a8 08 75 c4 eb 80 90 90 90 90 90 90 e9 07 00 00 00 0f 00 2d 64 78 60 00 fb f4 90 e9 07 00 00 00 0f 00 2d 54 78 60 00 f4 c3 90 90 41 55 41 54 [184503.429514] RSP: 0018:82c03e90 EFLAGS: 0246 ORIG_RAX: ff0c [184503.429544] RAX: 0001a548 RBX: RCX: 0001 [184503.429573] RDX: 067e991e RSI: RDI: 0086 [184503.429601] RBP: R08: 314d4ab0 R09: a7ced08b81fb [184503.429629] R10: 4400 R11: R12: [184503.429658] R13: R14: 888103ff0480 R15: [184503.429690] default_idle+0x17/0x140 [184503.429843] do_idle+0x1f9/0x220 [184503.429864] cpu_startup_entry+0x14/0x20 [184503.429884] start_kernel+0x4b6/0x4d8 [184503.429904] secondary_startup_64+0xa4/0xb0 [184503.429934] Modules linked in: [184503.430007] ---[ end trace 536ad19f63e35723 ]--- [184503.430032] RIP: 0010:xennet_poll+0x35f/0xae0 [184503.430055] Code: ba 00 01 00 00 48 8b 8d c0 00 00 00 0f b7 b4 24 92 00 00 00 48 8b 5c 24 78 3d 00 01 00 00 0f 4e d0 89 55 28 8b 95 bc 00 00 00 <89> 74 11 3c 48 8b 8d c0 00 00 00 8b 95 bc 00 00 00 89 44 11 38 89 [184503.430138] RSP: 0018:c9003e10 EFLAGS: 00010287 [184503.430159] RAX: 0042 RBX: c9003e88 RCX: fffe88800b865a80 [184503.430190] RDX: 0140 RSI: RDI: 888005504150 [184503.430236] RBP: 8880f0dfb800 R08: 888103417f00 R09: 888103010848 [184503.430266] R10: R11: 82c6e2e8 R12: 8880f0dfb800 [184503.430296] R13: 0001 R14: c9003ea0 R15: 8880055022e8 [184503.430331] FS: () GS:888103c0() knlGS: [184503.430361] CS: 0010 DS: ES: CR0: 80050033 [184503.430384] CR2: 7faab4774000 CR3: 000101652000 CR4: 06f0 [184503.430422] Kernel panic - not syncing: Fatal exception in interrupt [184503.430928] Kernel Offset: disabled ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 4/7] create-diff-object: Add support for applied/reverted marker
On 9/16/19 12:30 PM, Pawel Wieczorkiewicz wrote: > With version 2 of a payload structure additional field is supported > to track whether given function has been applied or reverted. > There also comes additional 8-byte alignment padding to reserve > place for future flags and options. > > The new fields are zero-out upon .livepatch.funcs section creation. > > Signed-off-by: Pawel Wieczorkiewicz Reviewed-by: Ross Lagerwall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] tools/tests/x86_emulator causes build failures with older but supported compilers
On 25.11.2019 14:52, Doug Goldstein wrote:
> On 11/25/19 4:44 AM, Jan Beulich wrote:
>
>> On 23.11.2019 19:00, Doug Goldstein wrote:
>>> Per README, GCC 4.1.2 should lead to a successful default "make install"
>>> per INSTALL. Currently this is failing due to tools/tests/x86_emulator
>>> being in the default path and requiring a compiler with AVX. GCC 4.4.7
>>> on CentOS 6 does not have this leading to a failure to build.
>>>
>>> 1265 make[5]: Entering directory `/builds/xen-project/xen/tools/tests'
>>> 1266 make -C x86_emulator install
>>> 1267 cc1: error: unrecognized command line option "-mavx2"
>>> 1268 cc1: error: unrecognized command line option "-mavx512f"
>>> 1269 cc1: error: unrecognized command line option "-mavx512bw"
>>> 1270 cc1: error: unrecognized command line option "-mavx512dq"
>>> 1271 cc1: error: unrecognized command line option "-mavx512er"
>>> 1272 cc1: error: unrecognized command line option "-mavx512vbmi"
>>> 1273 /tmp/ccMkLpTV.s: Assembler messages:
>>> 1274 /tmp/ccMkLpTV.s:3: Error: junk at end of line, first unrecognized
>>> character is `{'
>> These are errors, yes, but ...
>>
>>> 1275 make[6]: Entering directory
>>> `/builds/xen-project/xen/tools/tests/x86_emulator'
>>> 1276 Makefile:116: Test harness not built, use newer compiler than "gcc"
>>> (version 4.4.7) and an "{evex}" capable assembler
>>> 1277 make[6]: Nothing to be done for `install'.
>> ... there's no build failure here afaics, and this is the intended
>> way of how things are to work.
>
> The tree is intended to build with a default "make install" with a
> supported set of tools from README. This is part of the conversations
> we've had in the past about what should be treated as proper and it was
> universally agreed.
You still didn't clarify where the build failure is in here. Osstest
for example hits the above errors all the time, without the build
failing. Same for apparently everyone else.
And no, I don't think it was agreed that the _tests_ need to be
buildable with random old tool chains.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/7] create-diff-object: Handle optional apply|revert hooks
On 9/16/19 12:30 PM, Pawel Wieczorkiewicz wrote: > Include new sections containing optional apply and revert action > hooks. > > The following new section names are supported: > - .livepatch.hooks.apply > - .livepatch.hooks.revert > > Signed-off-by: Pawel Wieczorkiewicz Reviewed-by: Ross Lagerwall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Status of 4.13
On 25.11.2019 15:02, Doug Goldstein wrote: > 2. The hypervisor currently fails to build with clang using versions > that READM says are supported no matter the configuration. Did you post any details of this anywhere? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] current staging x86 hypervisor build fails with clang
Hello, The following build failure happens when using clang to build the hypervisor. This is a default config. make -f /builds/xen-project/xen/xen/Rules.mk /builds/xen-project/xen/xen/.xen.efi.0r.o /builds/xen-project/xen/xen/.xen.efi.0s.o grep -v 'DEFINE_XEN_GUEST_HANDLE(long)' public/nmi.h | \ python /builds/xen-project/xen/tools/firmware/xen-dir/xen-root/xen/tools/compat-build-source.py >compat/nmi.c.new make[4]: Entering directory '/builds/xen-project/xen/xen/arch/x86' Duplicate symbol 'asid.c#get_cpu_info' (82d08030c1b0 != 82d0802e8eb0) Duplicate symbol 'asid.c#get_cpu_info_from_stack' (82d08030c1e0 != 82d0802e8fe0) Duplicate symbol 'ats.c#__list_add' (82d080268cd0 != 82d080261770) Duplicate symbol 'boot.c#constant_test_bit' (82d080432330 != 82d080408bf0) Duplicate symbol 'common.c#clear_bit' (82d08033d030 != 82d0802db210) Duplicate symbol 'common.c#constant_test_bit' (82d08033cf10 != 82d0802da260) Duplicate symbol 'common.c#cpumask_check' (82d0803427d0 != 82d0802db220) Duplicate symbol 'common.c#get_cpu_info' (82d08033c150 != 82d0802da280) Duplicate symbol 'common.c#get_cpu_info_from_stack' (82d080342c20 != 82d0802db310) Duplicate symbol 'common.c#test_and_set_bit' (82d08033ce30 != 82d0802db250) Duplicate symbol 'common.c#variable_clear_bit' (82d0803427e0 != 82d0802da240) Duplicate symbol 'compat.c#get_cpu_info' (82d08026fad0 != 82d0802004b0) Duplicate symbol 'compat.c#get_cpu_info_from_stack' (82d08026fc00 != 82d0802010e0) Duplicate symbol 'cpu_idle.c#get_cpu_info' (82d08036b690 != 82d0802d48a0) Duplicate symbol 'cpu_idle.c#get_cpu_info_from_stack' (82d08036b970 != 82d0802d71b0) Duplicate symbol 'cpufreq.c#_xmalloc_array' (82d0802d8740 != 82d080250520) Duplicate symbol 'cpufreq.c#bitmap_empty' (82d0802d85b0 != 82d080250680) Duplicate symbol 'cpufreq.c#bitmap_weight' (82d0802d85a0 != 82d0802506b0) Duplicate symbol 'cpufreq.c#cpumask_check' (82d0802d83a0 != 82d0802506a0) Duplicate symbol 'cpufreq.c#cpumask_empty' (82d0802d84e0 != 82d080250030) Duplicate symbol 'cpufreq.c#cpumask_first' (82d0802d8330 != 82d08024ff90) Duplicate symbol 'cpufreq.c#cpumask_test_cpu' (82d0802d7c50 != 82d08024fb40) Duplicate symbol 'cpufreq.c#cpumask_weight' (82d0802d8560 != 82d08024ffe0) Duplicate symbol 'cpufreq.c#get_cpu_info' (82d0802d7c80 != 82d080250540) Duplicate symbol 'cpufreq.c#get_cpu_info' (82d08036bb10 != 82d0802d7c80) Duplicate symbol 'cpufreq.c#get_cpu_info_from_stack' (82d0802d88f0 != 82d080250660) Duplicate symbol 'cpufreq.c#get_cpu_info_from_stack' (82d08036bb20 != 82d0802d88f0) Duplicate symbol 'cpufreq.c#variable_test_bit' (82d0802d8900 != 82d0802506d0) Duplicate symbol 'cpuid.c#array_index_mask_nospec' (82d08026f9b0 != 82d08026cfb0) Duplicate symbol 'cpuid.c#get_cpu_info' (82d08026f9d0 != 82d08026cfa0) Duplicate symbol 'cpuid.c#get_cpu_info_from_stack' (82d08026fa30 != 82d08026cfd0) Duplicate symbol 'cpuid.c#zero_leaves' (82d08026f0d0 != 82d08026c6d0) Duplicate symbol 'dom0_build.c#__maddr_to_virt' (82d08043a460 != 82d080437c40) Duplicate symbol 'dom0_build.c#_mfn' (82d080438a30 != 82d080437bf0) Duplicate symbol 'dom0_build.c#clear_bit' (82d08043b010 != 82d080437c20) Duplicate symbol 'dom0_build.c#constant_test_bit' (82d08043a3a0 != 82d080437f20) Duplicate symbol 'dom0_build.c#elf_set_vcpu' (82d08043a8a0 != 82d080437c30) Duplicate symbol 'dom0_build.c#get_order_from_pages' (82d08043a410 != 82d080438130) Duplicate symbol 'dom0_build.c#mfn_x' (82d080438a20 != 82d080437f10) Duplicate symbol 'dom0_build.c#pdx_to_pfn' (82d08043a3f0 != 82d080438160) Duplicate symbol 'dom0_build.c#pfn_to_pdx' (82d080438a00 != 82d080437ca0) Duplicate symbol 'dom0_build.c#set_bit' (82d08043dff0 != 82d08043a3c0) Duplicate symbol 'domain.c#__rdgsbase' (82d080362ea0 != 82d0802789f0) Duplicate symbol 'domain.c#__virt_to_maddr' (82d080362ff0 != 82d080273e10) Duplicate symbol 'domain.c#_gfn' (82d080274a20 != 82d0802099b0) Duplicate symbol 'domain.c#_gfn' (82d0802eab70 != 82d080274a20) Duplicate symbol 'domain.c#_mfn' (82d080273aa0 != 82d080208d10) Duplicate symbol 'domain.c#_mfn' (82d0802eab00 != 82d080273aa0) Duplicate symbol 'domain.c#_mfn' (82d0803630e0 != 82d0802eab00) Duplicate symbol 'domain.c#_xzalloc_array' (82d080362b50 != 82d080207690) Duplicate symbol 'domain.c#atomic_read' (82d080275f10 != 82d080209960) Duplicate symbol 'domain.c#bitmap_empty' (82d080278660 != 82d080209a10) Duplicate symbol 'domain.c#clear_bit' (82d080276070 != 82d080208ae0) Duplicate symbol 'domain.c#constant_test_bit' (82d080274600 != 82d080209600) Duplicate symbol 'domain.c#constant_test_bit'
Re: [Xen-devel] Status of 4.13
Cc Roger -- you're our resident Clang expert. :-) On Mon, Nov 25, 2019 at 08:02:17AM -0600, Doug Goldstein wrote: > On 11/21/19 12:05 AM, Jürgen Groß wrote: > > > Where do we stand with Xen 4.13 regarding blockers and related patches? > > > 1. Currently the default "make install" fails with errors in > tools/tests/x86_emulator if you don't have a new enough GCC. Causing > failures on distros that are considered still supported based on README. > > 2. The hypervisor currently fails to build with clang using versions that > READM says are supported no matter the configuration. > Do you have a link to the log? I guess the answer is to go to gitlab? Wei. > -- > > Doug > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-unstable test] 144289: tolerable FAIL
On 25.11.2019 14:58, osstest service owner wrote: > flight 144289 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/144289/ > > Failures :-/ but no regressions. > > Tests which are failing intermittently (not blocking): > test-amd64-amd64-xl-rtds 17 guest-saverestore.2 fail in 144283 pass in > 144289 > test-amd64-amd64-libvirt-xsm 7 xen-boot fail pass in > 144283 Other than the shell prompt not appearing, I can't see any indication of what may have gone wrong here for which reason. However, I find Nov 25 08:26:50.472057 [4.568554] BERT: Error records from previous boot: Nov 25 08:26:50.472066 [4.573438] [Hardware Error]: event severity: fatal Nov 25 08:26:50.484062 [4.578314] [Hardware Error]: Error 0, type: fatal Nov 25 08:26:50.484072 [4.583192] [Hardware Error]: section_type: PCIe error Nov 25 08:26:50.496056 [4.588507] [Hardware Error]: port_type: 4, root port Nov 25 08:26:50.496066 [4.593730] [Hardware Error]: version: 1.16 Nov 25 08:26:50.496072 [4.598089] [Hardware Error]: command: 0x0010, status: 0x Nov 25 08:26:50.508062 [4.604012] [Hardware Error]: device_id: :00:02.2 Nov 25 08:26:50.508072 [4.609236] [Hardware Error]: slot: 0 Nov 25 08:26:50.520059 [4.613071] [Hardware Error]: secondary_bus: 0x00 Nov 25 08:26:50.520068 [4.617945] [Hardware Error]: vendor_id: 0x8086, device_id: 0x6f06 Nov 25 08:26:50.532058 [4.624295] [Hardware Error]: class_code: 040600 Nov 25 08:26:50.532067 [4.629090] [Hardware Error]: bridge: secondary_status: 0x, control: 0x (close to the top of the recorded serial log) concerning. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/7] livepatch-build: Embed hypervisor build id into every hotpatch
On 9/16/19 12:30 PM, Pawel Wieczorkiewicz wrote: > This change is part of a independant stacked hotpatch modules > feature. This feature allows to bypass dependencies between modules > upon loading, but still verifies Xen build ID matching. > > With stacked hotpatch modules it is essential that each and every > hotpatch is verified against the hypervisor build id upon upload. > It must not be possible to successfully upload hotpatches built for > incorrect version of the hypervisor. > > To achieve that always embed an additional ELF section: > '.livpatch.xen_depends' containing the hypervisor build id. > > The hypervisor build id must be always provided as a command line > parameter: --xen-depends. > > Signed-off-by: Pawel Wieczorkiewicz > Reviewed-by: Andra-Irina Paraschiv > Reviewed-by: Bjoern Doebel > Reviewed-by: Norbert Manthey Reviewed-by: Ross Lagerwall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Status of 4.13
On 11/21/19 12:05 AM, Jürgen Groß wrote: Where do we stand with Xen 4.13 regarding blockers and related patches? 1. Currently the default "make install" fails with errors in tools/tests/x86_emulator if you don't have a new enough GCC. Causing failures on distros that are considered still supported based on README. 2. The hypervisor currently fails to build with clang using versions that READM says are supported no matter the configuration. -- Doug ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 144289: tolerable FAIL
flight 144289 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/144289/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-rtds 17 guest-saverestore.2 fail in 144283 pass in 144289 test-amd64-amd64-libvirt-xsm 7 xen-boot fail pass in 144283 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail in 144283 never pass test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 144276 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 144283 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 144283 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 144283 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 144283 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 144283 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 144283 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 144283 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 144283 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 144283 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 144283 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 183f354e1430087879de071f0c7122e42703916e baseline version: xen 183f354e1430087879de071f0c7122e42703916e Last test of basis 144289 2019-11-25 01:50:58 Z0 days Testing same since (not found) 0 attempts jobs:
Re: [Xen-devel] tools/tests/x86_emulator causes build failures with older but supported compilers
On 11/25/19 4:44 AM, Jan Beulich wrote:
On 23.11.2019 19:00, Doug Goldstein wrote:
Per README, GCC 4.1.2 should lead to a successful default "make install"
per INSTALL. Currently this is failing due to tools/tests/x86_emulator
being in the default path and requiring a compiler with AVX. GCC 4.4.7
on CentOS 6 does not have this leading to a failure to build.
1265 make[5]: Entering directory `/builds/xen-project/xen/tools/tests'
1266 make -C x86_emulator install
1267 cc1: error: unrecognized command line option "-mavx2"
1268 cc1: error: unrecognized command line option "-mavx512f"
1269 cc1: error: unrecognized command line option "-mavx512bw"
1270 cc1: error: unrecognized command line option "-mavx512dq"
1271 cc1: error: unrecognized command line option "-mavx512er"
1272 cc1: error: unrecognized command line option "-mavx512vbmi"
1273 /tmp/ccMkLpTV.s: Assembler messages:
1274 /tmp/ccMkLpTV.s:3: Error: junk at end of line, first unrecognized
character is `{'
These are errors, yes, but ...
1275 make[6]: Entering directory
`/builds/xen-project/xen/tools/tests/x86_emulator'
1276 Makefile:116: Test harness not built, use newer compiler than "gcc"
(version 4.4.7) and an "{evex}" capable assembler
1277 make[6]: Nothing to be done for `install'.
... there's no build failure here afaics, and this is the intended
way of how things are to work.
The tree is intended to build with a default "make install" with a
supported set of tools from README. This is part of the conversations
we've had in the past about what should be treated as proper and it was
universally agreed.
2. Fix the default build to work with older GCC versions.
Not a reasonable option either, as it would be cluttering the harness
with all sorts of #ifdef-s or abstracting wrappers, making it even
more difficult to make changes to it.
What was considered in the past was to skip building of tests/ as a
whole in non-debug builds; don't know what has come of this. It is
probably telling enough that the bottom of ./Config.mk reads like this:
# Short answer -- do not enable this unless you know what you are
# doing and are prepared for some pain.
CONFIG_TESTS ?= y
Then this is what the default of the tree should be.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86/p2m-pt: fix (latent) page table mapping leak on do_recalc() error paths
There are two mappings active in the middle of do_recalc(), and hence
commit 0d0f4d78e5d1 ("p2m: change write_p2m_entry to return an error
code") should have added (or otherwise invoked) unmapping code just
like it did in p2m_next_level(), despite us not expecting any errors
here. Arrange for the existing unmap invocation to take effect in all
cases.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -391,21 +391,22 @@ static int do_recalc(struct p2m_domain *
if ( err )
{
ASSERT_UNREACHABLE();
-goto out;
+break;
}
}
remainder -= 1UL << ((level - 1) * PAGETABLE_ORDER);
}
smp_wmb();
-clear_recalc(l1, e);
-err = p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1);
-if ( err )
+if ( !err )
{
-ASSERT_UNREACHABLE();
-goto out;
+clear_recalc(l1, e);
+err = p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1);
+ASSERT(!err);
}
}
unmap_domain_page((void *)((unsigned long)pent & PAGE_MASK));
+if ( unlikely(err) )
+goto out;
}
pent = p2m_find_entry(table, _remainder, gfn,
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] vsnd issue
On 11/25/19 3:31 PM, Oleksandr Grytsov wrote: On Mon, Nov 25, 2019 at 2:25 PM Peng Fan wrote: Cc: sstabell...@kernel.org; jul...@xen.org; xen-de...@lists.xen.org Subject: Re: [Xen-devel] vsnd issue On 11/25/19 12:40 PM, Artem Mygaiev wrote: Hello Peng Fan Please contact Oleksandr Andrushchenko (added to this thread) on this issue. -- Artem On Mon, 2019-11-25 at 10:24 +, Julien Grall wrote: On 25/11/2019 10:19, Peng Fan wrote: Hi All, Hi, I am trying vsnd from xen-troops with xen 4.13 and Linux 5.4, but domu reports: xen-troops is not part of Xen Project. Please contact the owner of the repo for any help here. I have CCed Artem who should be able to point to the author of vsnd. Best regards, aplay compl.mp3 Hm, could you please try the same with wav and not mp3 and get back with the logs? Same issue. aplay hu01_48k.wav ALSA lib ../../../alsa-lib-1.1.9/src/pcm/pcm_direct.c:1156:(snd1_pcm_direct_initialize_slave) slave plugin does not support mmap interleaved or mmap noninterleaved access ALSA lib ../../../alsa-lib-1.1.9/src/pcm/pcm_dmix.c:1120:(snd_pcm_dmix_open) unable to initialize slave aplay: main:828: audio open error: Invalid argument Is there any limitation with current vsnd? Is there any plan to upstream libxenbe and snd_be to xen? Thanks, Peng. ALSA lib ../../../alsa-lib- 1.1.9/src/pcm/pcm_direct.c:1156:(snd1_pcm_direct_initialize_slave) slave plugin does not support mmap interleaved or mmap noninterleaved access ALSA frontend does not support mmap because of [1], so this is expected ALSA lib ../../../alsa-lib- 1.1.9/src/pcm/pcm_dmix.c:1120:(snd_pcm_dmix_open) unable to initialize slave aplay: main:828: audio open error: Invalid argument When executing aplay in domu, dom0 side log: root@imx8qmmek:~# 13.11.19 08:24:57.484 | XenEvtchn | DBG - Event received, port: 10 13.11.19 08:24:57.491 | StreamRing | DBG - Request received, id: alsa, cmd:9 13.11.19 08:24:57.500 | CommandHandler | DBG - Handle command [QUERY_HW_PARAM] 13.11.19 08:24:57.508 | AlsaPcm | DBG - Query pcm device hw:2,0 for HW parameters 13.11.19 08:24:57.516 | CommandHandler | DBG - Return status: [0] 13.11.19 08:24:57.523 | XenEvtchn | DBG - Notify event channel, port: 10 13.11.19 08:24:57.531 | XenEvtchn | DBG - Event received, port: 10 13.11.19 08:24:57.538 | StreamRing | DBG - Request received, id: alsa, cmd:9 13.11.19 08:24:57.546 | CommandHandler | DBG - Handle command [QUERY_HW_PARAM] 13.11.19 08:24:57.554 | AlsaPcm | DBG - Query pcm device hw:2,0 for HW parameters 13.11.19 08:24:57.563 | CommandHandler | DBG - Return status: [0] 13.11.19 08:24:57.570 | XenEvtchn | DBG - Notify event channel, port: 10 13.11.19 08:24:57.577 | XenEvtchn | DBG - Event received, port: 10 13.11.19 08:24:57.584 | StreamRing | DBG - Request received, id: alsa, cmd:9 13.11.19 08:24:57.593 | CommandHandler | DBG - Handle command [QUERY_HW_PARAM] 13.11.19 08:24:57.601 | AlsaPcm | DBG - Query pcm device hw:2,0 for HW parameters 13.11.19 08:24:57.610 | CommandHandler | DBG - Return status: [0] 13.11.19 08:24:57.616 | XenEvtchn | DBG - Notify event channel, port: 10 13.11.19 08:24:57.624 | XenEvtchn | DBG - Event received, port: 10 13.11.19 08:24:57.631 | StreamRing | DBG - Request received, id: alsa, cmd:9 13.11.19 08:24:57.640 | CommandHandler | DBG - Handle command [QUERY_HW_PARAM] 13.11.19 08:24:57.647 | AlsaPcm | DBG - Query pcm device hw:2,0 for HW parameters 13.11.19 08:24:57.656 | CommandHandler | DBG - Return status: [0] 13.11.19 08:24:57.663 | XenEvtchn | DBG - Notify event channel, port: 10 13.11.19 08:24:57.671 | XenEvtchn | DBG - Event received, port: 10 13.11.19 08:24:57.678 | StreamRing | DBG - Request received, id: alsa, cmd:9 13.11.19 08:24:57.686 | CommandHandler | DBG - Handle command [QUERY_HW_PARAM] 13.11.19 08:24:57.694 | AlsaPcm | DBG - Query pcm device hw:2,0 for HW parameters 13.11.19 08:24:57.703 | CommandHandler | DBG - Return status: [0] 13.11.19 08:24:57.709 | XenEvtchn | DBG - Notify event channel, port: 10 My xl.cfg: vsnd = [ ['CARD, short-name=Main, sample-formats=s16_le;s8;u32_be', 'PCM, name=Main', 'STREAM, unique-id=alsa, type=p', 'STREAM, unique-id=alsa, type=c, channels- max=2' ], ] Config seems to be ok The audio device on my board: aplay -l List of PLAYBACK Hardware Devices card 0: imxaudmix [imx-audmix], device 0: HiFi-AUDMIX-FE (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: imxaudmix [imx-audmix], device 1: HiFi-AUDMIX-FE (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: cs42888audio [cs42888-audio], device 0: HiFi cs42888-0 [HiFi cs42888-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: cs42888audio [cs42888-audio], device 1: HiFi-ASRC-FE (*) [] Subdevices: 1/1 Subdevice #0:
Re: [Xen-devel] vsnd issue
On Mon, Nov 25, 2019 at 2:25 PM Peng Fan wrote: > > > Cc: sstabell...@kernel.org; jul...@xen.org; xen-de...@lists.xen.org > > Subject: Re: [Xen-devel] vsnd issue > > > > On 11/25/19 12:40 PM, Artem Mygaiev wrote: > > > Hello Peng Fan > > > > > > Please contact Oleksandr Andrushchenko (added to this thread) on this > > > issue. > > > > > > -- Artem > > > > > > On Mon, 2019-11-25 at 10:24 +, Julien Grall wrote: > > >> On 25/11/2019 10:19, Peng Fan wrote: > > >>> Hi All, > > >> Hi, > > >> > > >>> I am trying vsnd from xen-troops with xen 4.13 and Linux 5.4, but > > >>> domu reports: > > >> xen-troops is not part of Xen Project. Please contact the owner of > > >> the repo for any help here. > > >> > > >> I have CCed Artem who should be able to point to the author of vsnd. > > >> > > >> Best regards, > > >> > > >>> aplay compl.mp3 > > Hm, could you please try the same with wav and not mp3 and get back with > > the logs? > > Same issue. > aplay hu01_48k.wav > ALSA lib > ../../../alsa-lib-1.1.9/src/pcm/pcm_direct.c:1156:(snd1_pcm_direct_initialize_slave) > slave plugin does not support mmap interleaved or mmap noninterleaved access > ALSA lib ../../../alsa-lib-1.1.9/src/pcm/pcm_dmix.c:1120:(snd_pcm_dmix_open) > unable to initialize slave > aplay: main:828: audio open error: Invalid argument > > Is there any limitation with current vsnd? Is there any plan to upstream > libxenbe and snd_be > to xen? > > Thanks, > Peng. > > > >>> ALSA lib ../../../alsa-lib- > > >>> 1.1.9/src/pcm/pcm_direct.c:1156:(snd1_pcm_direct_initialize_slave) > > >>> slave plugin does not support mmap interleaved or mmap > > >>> noninterleaved access > > ALSA frontend does not support mmap because of [1], so this is expected > > >>> ALSA lib ../../../alsa-lib- > > >>> 1.1.9/src/pcm/pcm_dmix.c:1120:(snd_pcm_dmix_open) unable to > > >>> initialize slave > > >>> aplay: main:828: audio open error: Invalid argument > > >>> > > >>> When executing aplay in domu, dom0 side log: > > >>> root@imx8qmmek:~# 13.11.19 08:24:57.484 | XenEvtchn | DBG > > - > > >>> Event received, port: 10 > > >>> 13.11.19 08:24:57.491 | StreamRing | DBG - Request received, > > >>> id: alsa, cmd:9 > > >>> 13.11.19 08:24:57.500 | CommandHandler | DBG - Handle command > > >>> [QUERY_HW_PARAM] > > >>> 13.11.19 08:24:57.508 | AlsaPcm | DBG - Query pcm device > > >>> hw:2,0 for HW parameters > > >>> 13.11.19 08:24:57.516 | CommandHandler | DBG - Return status: [0] > > >>> 13.11.19 08:24:57.523 | XenEvtchn | DBG - Notify event > > >>> channel, port: 10 > > >>> 13.11.19 08:24:57.531 | XenEvtchn | DBG - Event received, > > >>> port: 10 > > >>> 13.11.19 08:24:57.538 | StreamRing | DBG - Request received, > > >>> id: alsa, cmd:9 > > >>> 13.11.19 08:24:57.546 | CommandHandler | DBG - Handle command > > >>> [QUERY_HW_PARAM] > > >>> 13.11.19 08:24:57.554 | AlsaPcm | DBG - Query pcm device > > >>> hw:2,0 for HW parameters > > >>> 13.11.19 08:24:57.563 | CommandHandler | DBG - Return status: [0] > > >>> 13.11.19 08:24:57.570 | XenEvtchn | DBG - Notify event > > >>> channel, port: 10 > > >>> 13.11.19 08:24:57.577 | XenEvtchn | DBG - Event received, > > >>> port: 10 > > >>> 13.11.19 08:24:57.584 | StreamRing | DBG - Request received, > > >>> id: alsa, cmd:9 > > >>> 13.11.19 08:24:57.593 | CommandHandler | DBG - Handle command > > >>> [QUERY_HW_PARAM] > > >>> 13.11.19 08:24:57.601 | AlsaPcm | DBG - Query pcm device > > >>> hw:2,0 for HW parameters > > >>> 13.11.19 08:24:57.610 | CommandHandler | DBG - Return status: [0] > > >>> 13.11.19 08:24:57.616 | XenEvtchn | DBG - Notify event > > >>> channel, port: 10 > > >>> 13.11.19 08:24:57.624 | XenEvtchn | DBG - Event received, > > >>> port: 10 > > >>> 13.11.19 08:24:57.631 | StreamRing | DBG - Request received, > > >>> id: alsa, cmd:9 > > >>> 13.11.19 08:24:57.640 | CommandHandler | DBG - Handle command > > >>> [QUERY_HW_PARAM] > > >>> 13.11.19 08:24:57.647 | AlsaPcm | DBG - Query pcm device > > >>> hw:2,0 for HW parameters > > >>> 13.11.19 08:24:57.656 | CommandHandler | DBG - Return status: [0] > > >>> 13.11.19 08:24:57.663 | XenEvtchn | DBG - Notify event > > >>> channel, port: 10 > > >>> 13.11.19 08:24:57.671 | XenEvtchn | DBG - Event received, > > >>> port: 10 > > >>> 13.11.19 08:24:57.678 | StreamRing | DBG - Request received, > > >>> id: alsa, cmd:9 > > >>> 13.11.19 08:24:57.686 | CommandHandler | DBG - Handle command > > >>> [QUERY_HW_PARAM] > > >>> 13.11.19 08:24:57.694 | AlsaPcm | DBG - Query pcm device > > >>> hw:2,0 for HW parameters > > >>> 13.11.19 08:24:57.703 | CommandHandler | DBG - Return status: [0] > > >>> 13.11.19 08:24:57.709 | XenEvtchn | DBG - Notify event > > >>> channel, port: 10 > > >>> > > >>> > > >>> My xl.cfg: > > >>> vsnd = [ > > >>> ['CARD, short-name=Main, > > sample-formats=s16_le;s8;u32_be', > > >>> 'PCM, name=Main', > > >>>
Re: [Xen-devel] [PATCH v2 for 4.13] x86/microcode: refuse to load the same revision ucode
On 25.11.2019 03:22, Chao Gao wrote:
> On Fri, Nov 22, 2019 at 04:47:23PM +, Sergey Dyasli wrote:
>> Currently if a user tries to live-load the same or older ucode revision
>> than CPU already has, he will get a single message in Xen log like:
>>
>>(XEN) 128 cores are to update their microcode
>>
>> No actual ucode loading will happen and this situation can be quite
>> confusing. Fix this by starting ucode update only when the provided
>> ucode revision is higher than the currently cached one (if any).
>> This is based on the property that if microcode_cache exists, all CPUs
>> in the system should have at least that ucode revision.
>>
>> Additionally, print a user friendly message if no newer ucode can be
>> found in the provided blob. This also requires ignoring -ENODATA in
>> AMD-side code, otherwise the message given to the user is:
>>
>>(XEN) Parsing microcode blob error -61
>>
>> Which actually means that a ucode blob was parsed fine, but no matching
>> ucode was found.
>>
>> Signed-off-by: Sergey Dyasli
>
> Reviewed-by: Chao Gao
>
> I wonder whether it is better to put the comparison ...
>
>> @@ -641,6 +647,8 @@ int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void)
>> buf, unsigned long len)
>> if ( !patch )
>> {
>> ret = -ENOENT;
>> +printk(XENLOG_WARNING "microcode: couldn't find any newer revision
>> in "
>> + "the provided blob!\n");
>> goto put;
>> }
>
> ... after this if(). Then you needn't modify any vendor-specific code.
Yeah, this would seem to allow reducing code churn by quite a bit.
Also I think the AMD side -ENODATA ignoring would better go into
this
if ( error )
{
xfree(mc_amd->equiv_cpu_table);
xfree(mc_amd);
goto out;
}
block in cpu_request_microcode(), thus allowing potential future
unrelated -EONDATA to not also get ignored.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 144294: tolerable all pass - PUSHED
flight 144294 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/144294/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 77beba7c921a286c31a2a76f26500047f353614a baseline version: xen 183f354e1430087879de071f0c7122e42703916e Last test of basis 144268 2019-11-23 15:01:05 Z1 days Testing same since 144294 2019-11-25 11:00:30 Z0 days1 attempts People who touched revisions under test: Anthony PERARD George Dunlap Ian Jackson Oleksandr Grytsov Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt 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/xen.git 183f354e14..77beba7c92 77beba7c921a286c31a2a76f26500047f353614a -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC] x86: Don't increase ApicIdCoreSize past 7
On Mon, Nov 25, 2019 at 12:39:23PM +, George Dunlap wrote:
> Changeset ca2eee92df44 ("x86, hvm: Expose host core/HT topology to HVM
> guests") attempted to "fake up" a topology which would induce guest
> operating systems to not treat vcpus as sibling hyperthreads. This
> involved actually reporting hyperthreading as available, but giving
> vcpus every other ApicId; which in turn led to doubling the ApicIds
> per core by bumping the ApicIdCoreSize by one. In particular, Ryzen
> 3xxx series processors, and reportedly EPYC "Rome" cpus -- have an
> ApicIdCoreSize of 7; the "fake" topology increases this to 8.
>
> Unfortunately, Windows running on modern AMD hardware -- including
> Ryzen 3xxx series processors, and reportedly EPYC "Rome" cpus --
> doesn't seem to cope with this value being higher than 7. (Linux
> guests have so far continued to cope.)
>
> A "proper" fix is complicated and it's too late to fix it either for
> 4.13, or to backport to supported branches. As a short-term fix,
> limit this value to 7.
>
> This does mean that a Linux guest, booted on such a system without
> this change, and then migrating to a system with this change, with
> more than 64 vcpus, would see an apparent topology change. This is a
> low enough risk in practice that enabling this limit unilaterally, to
> allow other guests to boot without manual intervention, is worth it.
>
> Reported-by: Steven Haigh
> Reported-by: Andreas Kinzler
> Signed-off-by: George Dunlap
> ---
> CC: Ian Jackson
> CC: Wei Liu
> CC: Andrew Cooper
> CC: Jan Beulich
> CC: Juergen Gross
> ---
> tools/libxc/xc_cpuid_x86.c | 7 ++-
I will defer this to x86 maintainers.
Seeing that you already have an Ack from Jan, feel free to add mine if
necessary.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC] x86: Don't increase ApicIdCoreSize past 7
On 25.11.2019 13:39, George Dunlap wrote:
> Changeset ca2eee92df44 ("x86, hvm: Expose host core/HT topology to HVM
> guests") attempted to "fake up" a topology which would induce guest
> operating systems to not treat vcpus as sibling hyperthreads. This
> involved actually reporting hyperthreading as available, but giving
> vcpus every other ApicId; which in turn led to doubling the ApicIds
> per core by bumping the ApicIdCoreSize by one. In particular, Ryzen
> 3xxx series processors, and reportedly EPYC "Rome" cpus -- have an
> ApicIdCoreSize of 7; the "fake" topology increases this to 8.
>
> Unfortunately, Windows running on modern AMD hardware -- including
> Ryzen 3xxx series processors, and reportedly EPYC "Rome" cpus --
> doesn't seem to cope with this value being higher than 7. (Linux
> guests have so far continued to cope.)
>
> A "proper" fix is complicated and it's too late to fix it either for
> 4.13, or to backport to supported branches. As a short-term fix,
> limit this value to 7.
>
> This does mean that a Linux guest, booted on such a system without
> this change, and then migrating to a system with this change, with
> more than 64 vcpus, would see an apparent topology change. This is a
> low enough risk in practice that enabling this limit unilaterally, to
> allow other guests to boot without manual intervention, is worth it.
>
> Reported-by: Steven Haigh
> Reported-by: Andreas Kinzler
> Signed-off-by: George Dunlap
Acked-by: Jan Beulich
with ...
> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
> @@ -616,10 +616,15 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t
> domid,
> * - going out of sync with leaf 1 EBX[23:16],
> * - incrementing ApicIdCoreSize when it's zero (which changes
> the
> * meaning of bits 7:0).
> + *
> + * UPDATE: I addition to avoiding overflow, some
... this becoming "UPDATE: In ...".
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86: avoid HPET use on certain Intel platforms
On 25.11.2019 11:15, Jan Beulich wrote: On 23.11.2019 00:10, Andreas Kinzler wrote: BTW: Xeon E-2136 @ C242 has 8086:3eca as ID. One needs to check with Intel which combinations are really affected. Are you saying you observed the same issue on such a (server processor) system as well? Neither its datasheet nor its specification update The whole thread starting with https://lists.xenproject.org/archives/html/xen-devel/2019-10/msg00966.html was about Xeon E-2136. Setting a limit to PC7 greatly reduced the drift (https://lists.xenproject.org/archives/html/xen-devel/2019-11/msg01044.html) (which I specifically downloaded and looked through just because of your remark) have any mention of a similar issue. I also take it that the code comment inherited from Linux says "SoCs" for a reason. Even the kernel mailing list postings lack official confirmation from Intel. That is why I said: someone (with internal Intel knowledge) needs to confirm which combinations are affected. Regards Andreas ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC] x86: Don't increase ApicIdCoreSize past 7
On 25.11.19 13:39, George Dunlap wrote:
Changeset ca2eee92df44 ("x86, hvm: Expose host core/HT topology to HVM
guests") attempted to "fake up" a topology which would induce guest
operating systems to not treat vcpus as sibling hyperthreads. This
involved actually reporting hyperthreading as available, but giving
vcpus every other ApicId; which in turn led to doubling the ApicIds
per core by bumping the ApicIdCoreSize by one. In particular, Ryzen
3xxx series processors, and reportedly EPYC "Rome" cpus -- have an
ApicIdCoreSize of 7; the "fake" topology increases this to 8.
Unfortunately, Windows running on modern AMD hardware -- including
Ryzen 3xxx series processors, and reportedly EPYC "Rome" cpus --
doesn't seem to cope with this value being higher than 7. (Linux
guests have so far continued to cope.)
A "proper" fix is complicated and it's too late to fix it either for
4.13, or to backport to supported branches. As a short-term fix,
limit this value to 7.
This does mean that a Linux guest, booted on such a system without
this change, and then migrating to a system with this change, with
more than 64 vcpus, would see an apparent topology change. This is a
low enough risk in practice that enabling this limit unilaterally, to
allow other guests to boot without manual intervention, is worth it.
Reported-by: Steven Haigh
Reported-by: Andreas Kinzler
Signed-off-by: George Dunlap
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH RFC] x86: Don't increase ApicIdCoreSize past 7
Changeset ca2eee92df44 ("x86, hvm: Expose host core/HT topology to HVM
guests") attempted to "fake up" a topology which would induce guest
operating systems to not treat vcpus as sibling hyperthreads. This
involved actually reporting hyperthreading as available, but giving
vcpus every other ApicId; which in turn led to doubling the ApicIds
per core by bumping the ApicIdCoreSize by one. In particular, Ryzen
3xxx series processors, and reportedly EPYC "Rome" cpus -- have an
ApicIdCoreSize of 7; the "fake" topology increases this to 8.
Unfortunately, Windows running on modern AMD hardware -- including
Ryzen 3xxx series processors, and reportedly EPYC "Rome" cpus --
doesn't seem to cope with this value being higher than 7. (Linux
guests have so far continued to cope.)
A "proper" fix is complicated and it's too late to fix it either for
4.13, or to backport to supported branches. As a short-term fix,
limit this value to 7.
This does mean that a Linux guest, booted on such a system without
this change, and then migrating to a system with this change, with
more than 64 vcpus, would see an apparent topology change. This is a
low enough risk in practice that enabling this limit unilaterally, to
allow other guests to boot without manual intervention, is worth it.
Reported-by: Steven Haigh
Reported-by: Andreas Kinzler
Signed-off-by: George Dunlap
---
CC: Ian Jackson
CC: Wei Liu
CC: Andrew Cooper
CC: Jan Beulich
CC: Juergen Gross
---
tools/libxc/xc_cpuid_x86.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 312c481f1e..519d6d8bd0 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -616,10 +616,15 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t
domid,
* - going out of sync with leaf 1 EBX[23:16],
* - incrementing ApicIdCoreSize when it's zero (which changes the
* meaning of bits 7:0).
+ *
+ * UPDATE: I addition to avoiding overflow, some
+ * proprietary operating systems have trouble with
+ * apic_id_size values greater than 7. Limit the value to
+ * 7 for now.
*/
if ( p->extd.nc < 0x7f )
{
-if ( p->extd.apic_id_size != 0 && p->extd.apic_id_size != 0xf )
+if ( p->extd.apic_id_size != 0 && p->extd.apic_id_size < 0x7 )
p->extd.apic_id_size++;
p->extd.nc = (p->extd.nc << 1) | 1;
--
2.24.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen 4.13 RC3
Hi all, Xen 4.13 rc3 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.13.0-rc3 For your convenience there is also a tarball at: https://downloads.xenproject.org/release/xen/4.13.0-rc3/xen-4.13.0-rc3.tar.gz And the signature is at: https://downloads.xenproject.org/release/xen/4.13.0-rc3/xen-4.13.0-rc3.tar.gz.sig Please send bug reports and test reports to xen-devel@lists.xenproject.org. When sending bug reports, please CC relevant maintainers and me (jgr...@suse.com). There will be a Xen Test Day on Nov 28th. See instructions on: https://wiki.xenproject.org/wiki/Xen_4.13_RC_test_instructions https://wiki.xenproject.org/wiki/Xen_Project_Test_Days Juergen PS: resend due to wrong subject ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen 4.13 RC2
Hi all, Xen 4.13 rc3 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.13.0-rc3 For your convenience there is also a tarball at: https://downloads.xenproject.org/release/xen/4.13.0-rc3/xen-4.13.0-rc3.tar.gz And the signature is at: https://downloads.xenproject.org/release/xen/4.13.0-rc3/xen-4.13.0-rc3.tar.gz.sig Please send bug reports and test reports to xen-devel@lists.xenproject.org. When sending bug reports, please CC relevant maintainers and me (jgr...@suse.com). There will be a Xen Test Day on Nov 28th. See instructions on: https://wiki.xenproject.org/wiki/Xen_4.13_RC_test_instructions https://wiki.xenproject.org/wiki/Xen_Project_Test_Days Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] vsnd issue
> Cc: sstabell...@kernel.org; jul...@xen.org; xen-de...@lists.xen.org > Subject: Re: [Xen-devel] vsnd issue > > On 11/25/19 12:40 PM, Artem Mygaiev wrote: > > Hello Peng Fan > > > > Please contact Oleksandr Andrushchenko (added to this thread) on this > > issue. > > > > -- Artem > > > > On Mon, 2019-11-25 at 10:24 +, Julien Grall wrote: > >> On 25/11/2019 10:19, Peng Fan wrote: > >>> Hi All, > >> Hi, > >> > >>> I am trying vsnd from xen-troops with xen 4.13 and Linux 5.4, but > >>> domu reports: > >> xen-troops is not part of Xen Project. Please contact the owner of > >> the repo for any help here. > >> > >> I have CCed Artem who should be able to point to the author of vsnd. > >> > >> Best regards, > >> > >>> aplay compl.mp3 > Hm, could you please try the same with wav and not mp3 and get back with > the logs? Same issue. aplay hu01_48k.wav ALSA lib ../../../alsa-lib-1.1.9/src/pcm/pcm_direct.c:1156:(snd1_pcm_direct_initialize_slave) slave plugin does not support mmap interleaved or mmap noninterleaved access ALSA lib ../../../alsa-lib-1.1.9/src/pcm/pcm_dmix.c:1120:(snd_pcm_dmix_open) unable to initialize slave aplay: main:828: audio open error: Invalid argument Is there any limitation with current vsnd? Is there any plan to upstream libxenbe and snd_be to xen? Thanks, Peng. > >>> ALSA lib ../../../alsa-lib- > >>> 1.1.9/src/pcm/pcm_direct.c:1156:(snd1_pcm_direct_initialize_slave) > >>> slave plugin does not support mmap interleaved or mmap > >>> noninterleaved access > ALSA frontend does not support mmap because of [1], so this is expected > >>> ALSA lib ../../../alsa-lib- > >>> 1.1.9/src/pcm/pcm_dmix.c:1120:(snd_pcm_dmix_open) unable to > >>> initialize slave > >>> aplay: main:828: audio open error: Invalid argument > >>> > >>> When executing aplay in domu, dom0 side log: > >>> root@imx8qmmek:~# 13.11.19 08:24:57.484 | XenEvtchn | DBG > - > >>> Event received, port: 10 > >>> 13.11.19 08:24:57.491 | StreamRing | DBG - Request received, > >>> id: alsa, cmd:9 > >>> 13.11.19 08:24:57.500 | CommandHandler | DBG - Handle command > >>> [QUERY_HW_PARAM] > >>> 13.11.19 08:24:57.508 | AlsaPcm | DBG - Query pcm device > >>> hw:2,0 for HW parameters > >>> 13.11.19 08:24:57.516 | CommandHandler | DBG - Return status: [0] > >>> 13.11.19 08:24:57.523 | XenEvtchn | DBG - Notify event > >>> channel, port: 10 > >>> 13.11.19 08:24:57.531 | XenEvtchn | DBG - Event received, > >>> port: 10 > >>> 13.11.19 08:24:57.538 | StreamRing | DBG - Request received, > >>> id: alsa, cmd:9 > >>> 13.11.19 08:24:57.546 | CommandHandler | DBG - Handle command > >>> [QUERY_HW_PARAM] > >>> 13.11.19 08:24:57.554 | AlsaPcm | DBG - Query pcm device > >>> hw:2,0 for HW parameters > >>> 13.11.19 08:24:57.563 | CommandHandler | DBG - Return status: [0] > >>> 13.11.19 08:24:57.570 | XenEvtchn | DBG - Notify event > >>> channel, port: 10 > >>> 13.11.19 08:24:57.577 | XenEvtchn | DBG - Event received, > >>> port: 10 > >>> 13.11.19 08:24:57.584 | StreamRing | DBG - Request received, > >>> id: alsa, cmd:9 > >>> 13.11.19 08:24:57.593 | CommandHandler | DBG - Handle command > >>> [QUERY_HW_PARAM] > >>> 13.11.19 08:24:57.601 | AlsaPcm | DBG - Query pcm device > >>> hw:2,0 for HW parameters > >>> 13.11.19 08:24:57.610 | CommandHandler | DBG - Return status: [0] > >>> 13.11.19 08:24:57.616 | XenEvtchn | DBG - Notify event > >>> channel, port: 10 > >>> 13.11.19 08:24:57.624 | XenEvtchn | DBG - Event received, > >>> port: 10 > >>> 13.11.19 08:24:57.631 | StreamRing | DBG - Request received, > >>> id: alsa, cmd:9 > >>> 13.11.19 08:24:57.640 | CommandHandler | DBG - Handle command > >>> [QUERY_HW_PARAM] > >>> 13.11.19 08:24:57.647 | AlsaPcm | DBG - Query pcm device > >>> hw:2,0 for HW parameters > >>> 13.11.19 08:24:57.656 | CommandHandler | DBG - Return status: [0] > >>> 13.11.19 08:24:57.663 | XenEvtchn | DBG - Notify event > >>> channel, port: 10 > >>> 13.11.19 08:24:57.671 | XenEvtchn | DBG - Event received, > >>> port: 10 > >>> 13.11.19 08:24:57.678 | StreamRing | DBG - Request received, > >>> id: alsa, cmd:9 > >>> 13.11.19 08:24:57.686 | CommandHandler | DBG - Handle command > >>> [QUERY_HW_PARAM] > >>> 13.11.19 08:24:57.694 | AlsaPcm | DBG - Query pcm device > >>> hw:2,0 for HW parameters > >>> 13.11.19 08:24:57.703 | CommandHandler | DBG - Return status: [0] > >>> 13.11.19 08:24:57.709 | XenEvtchn | DBG - Notify event > >>> channel, port: 10 > >>> > >>> > >>> My xl.cfg: > >>> vsnd = [ > >>> ['CARD, short-name=Main, > sample-formats=s16_le;s8;u32_be', > >>> 'PCM, name=Main', > >>> 'STREAM, unique-id=alsa, type=p', > >>> 'STREAM, unique-id=alsa, type=c, > channels- > >>> max=2' > >>> ], > >>> ] > Config seems to be ok > >>> The audio device on my board: > >>> aplay -l > >>> List of PLAYBACK Hardware Devices card 0:
[Xen-devel] [libvirt test] 144290: regressions - FAIL
flight 144290 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/144290/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs. 144233 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 144233 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 144233 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass version targeted for testing: libvirt bc7e72914a07db9050eab2df8341262c46035717 baseline version: libvirt 5e939cea896fb3373a6f68f86e325c657429ed3d Last test of basis 144233 2019-11-21 04:18:53 Z4 days Failing since144244 2019-11-22 04:18:48 Z3 days4 attempts Testing same since 144260 2019-11-23 04:18:43 Z2 days3 attempts People who touched revisions under test: Christian Ehrhardt Daniel P. Berrangé Erik Skultety Jamie Strandboge Ján Tomko Michal Privoznik Peter Krempa Pino Toscano 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 fail test-armhf-armhf-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 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 Not
[Xen-devel] [PATCH v2 00/14] Convert cpu_up/down to device_online/offline
Changes in v2:
* Add 2 new patches that create smp_shutdown_nonboot_cpus() to be used
in machine_shutdown() in ia64, arm and arm64
* Use proper kernel-doc for the newly introduced functions
* Renamed a function
* Removed a stale comment in a function
* Rebased on top of 5.4-rc8
git clone git://linux-arm.org/linux-qy.git -b cpu-hp-cleanup-v2
Using cpu_up/down directly to bring cpus online/offline loses synchronization
with sysfs and could suffer from a race similar to what is described in
commit a6717c01ddc2 ("powerpc/rtas: use device model APIs and serialization
during LPM").
cpu_up/down seem to be more of a internal implementation detail for the cpu
subsystem to use to boot up cpus, perform suspend/resume and low level hotplug
operations. Users outside of the cpu subsystem would be better using the device
core API to bring a cpu online/offline which is the interface used to hotplug
memory and other system devices.
Several users have already migrated to use the device core API, this series
converts the remaining users and hides cpu_up/down from internal users at the
end.
I noticed this problem while working on a hack to disable offlining
a particular CPU but noticed that setting the offline_disabled attribute in the
device struct isn't enough because users can easily bypass the device core.
While my hack isn't a valid use case but it did highlight the inconsistency in
the way cpus are being onlined/offlined and this attempt hopefully improves on
this.
The first 8 patches fix arch users.
The remaining 6 patches fix generic code users. Particularly creating a new
special exported API for the device core to use instead of cpu_up/down.
The last patch removes cpu_up/down from cpu.h and unexport the functions.
In some cases where the use of cpu_up/down seemed legitimate, I encapsulated
the logic in a higher level - special purposed function; and converted the code
to use that instead.
I did re-run the rcu torture, lock torture and psci checker tests and no
problem was noticed. I did perform build tests on all arch affected except for
parisc.
Hopefully I got the CC list right for all the patches. Apologies in advance if
some people were omitted from some patches but they should have been CCed.
CC: Armijn Hemel
CC: Benjamin Herrenschmidt
CC: Bjorn Helgaas
CC: Borislav Petkov
CC: Boris Ostrovsky
CC: Catalin Marinas
CC: Christophe Leroy
CC: Daniel Lezcano
CC: Davidlohr Bueso
CC: "David S. Miller"
CC: Eiichi Tsukata
CC: Enrico Weigelt
CC: Fenghua Yu
CC: Greg Kroah-Hartman
CC: Helge Deller
CC: "H. Peter Anvin"
CC: Ingo Molnar
CC: "James E.J. Bottomley"
CC: James Morse
CC: Jiri Kosina
CC: Josh Poimboeuf
CC: Josh Triplett
CC: Juergen Gross
CC: Lorenzo Pieralisi
CC: Mark Rutland
CC: Michael Ellerman
CC: Nadav Amit
CC: Nicholas Piggin
CC: "Paul E. McKenney"
CC: Paul Mackerras
CC: Pavankumar Kondeti
CC: "Peter Zijlstra (Intel)"
CC: "Rafael J. Wysocki"
CC: Ram Pai
CC: Richard Fontana
CC: Russell King
CC: Sakari Ailus
CC: Stefano Stabellini
CC: Steve Capper
CC: Thiago Jung Bauermann
CC: Thomas Gleixner
CC: Tony Luck
CC: Will Deacon
CC: Zhenzhong Duan
CC: linux-arm-ker...@lists.infradead.org
CC: linux-i...@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: linux-par...@vger.kernel.org
CC: linuxppc-...@lists.ozlabs.org
CC: sparcli...@vger.kernel.org
CC: x...@kernel.org
CC: xen-devel@lists.xenproject.org
Qais Yousef (14):
smp: create a new function to shutdown nonboot cpus
ia64: Replace cpu_down with smp_shutdown_nonboot_cpus()
arm: arm64: Don't use disable_nonboot_cpus()
arm64: hibernate.c: create a new function to handle cpu_up(sleep_cpu)
x86: Replace cpu_up/down with devcie_online/offline
powerpc: Replace cpu_up/down with device_online/offline
sparc: Replace cpu_up/down with device_online/offline
parisc: Replace cpu_up/down with device_online/offline
driver: base: cpu: export device_online/offline
driver: xen: Replace cpu_up/down with device_online/offline
firmware: psci: Replace cpu_up/down with device_online/offline
torture: Replace cpu_up/down with device_online/offline
smp: Create a new function to bringup nonboot cpus online
cpu: Hide cpu_up/down
arch/arm/kernel/reboot.c | 4 +-
arch/arm64/kernel/hibernate.c | 13 ++--
arch/arm64/kernel/process.c| 4 +-
arch/ia64/kernel/process.c | 8 +--
arch/parisc/kernel/processor.c | 4 +-
arch/powerpc/kernel/machine_kexec_64.c | 4 +-
arch/sparc/kernel/ds.c | 8 ++-
arch/x86/kernel/topology.c | 4 +-
arch/x86/mm/mmio-mod.c | 8 ++-
arch/x86/xen/smp.c | 4 +-
drivers/base/core.c| 4 ++
drivers/base/cpu.c | 4 +-
drivers/firmware/psci/psci_checker.c | 6 +-
drivers/xen/cpu_hotplug.c | 2 +-
include/linux/cpu.h| 8 ++-
kernel/cpu.c
[Xen-devel] [PATCH v2 10/14] driver: xen: Replace cpu_up/down with device_online/offline
The core device API performs extra housekeeping bits that are missing
from directly calling cpu_up/down.
See commit a6717c01ddc2 ("powerpc/rtas: use device model APIs and
serialization during LPM") for an example description of what might go
wrong.
This also prepares to make cpu_up/down a private interface for anything
but the cpu subsystem.
Signed-off-by: Qais Yousef
CC: Boris Ostrovsky
CC: Juergen Gross
CC: Stefano Stabellini
CC: xen-devel@lists.xenproject.org
CC: linux-ker...@vger.kernel.org
---
drivers/xen/cpu_hotplug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index f192b6f42da9..ec975decb5de 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -94,7 +94,7 @@ static int setup_cpu_watcher(struct notifier_block *notifier,
for_each_possible_cpu(cpu) {
if (vcpu_online(cpu) == 0) {
- (void)cpu_down(cpu);
+ device_offline(get_cpu_device(cpu));
set_cpu_present(cpu, false);
}
}
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/3] libxl: introduce new backend type VINPUT
On Fri, Nov 22, 2019 at 06:08:13PM +, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] [PATCH v2 1/3] libxl: introduce new backend
> type VINPUT"):
> > On Fri, Nov 22, 2019 at 04:43:03PM +0100, Jürgen Groß wrote:
> > > Release-acked-by: Juergen Gross
> >
> > I take it this applies to both patch 1 and 3?
>
> In the absence of a reply to the contrary by 21:00 UTC today, I will
> assume this to be the case and push this to staging. I hope that
> meets with everyone's approval.
Got confirmation from Juergen on IRC, so I have just pushed patch 1 and
3.
Wei.
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] vsnd issue
On 11/25/19 12:40 PM, Artem Mygaiev wrote: Hello Peng Fan Please contact Oleksandr Andrushchenko (added to this thread) on this issue. -- Artem On Mon, 2019-11-25 at 10:24 +, Julien Grall wrote: On 25/11/2019 10:19, Peng Fan wrote: Hi All, Hi, I am trying vsnd from xen-troops with xen 4.13 and Linux 5.4, but domu reports: xen-troops is not part of Xen Project. Please contact the owner of the repo for any help here. I have CCed Artem who should be able to point to the author of vsnd. Best regards, aplay compl.mp3 Hm, could you please try the same with wav and not mp3 and get back with the logs? ALSA lib ../../../alsa-lib- 1.1.9/src/pcm/pcm_direct.c:1156:(snd1_pcm_direct_initialize_slave) slave plugin does not support mmap interleaved or mmap noninterleaved access ALSA frontend does not support mmap because of [1], so this is expected ALSA lib ../../../alsa-lib- 1.1.9/src/pcm/pcm_dmix.c:1120:(snd_pcm_dmix_open) unable to initialize slave aplay: main:828: audio open error: Invalid argument When executing aplay in domu, dom0 side log: root@imx8qmmek:~# 13.11.19 08:24:57.484 | XenEvtchn | DBG - Event received, port: 10 13.11.19 08:24:57.491 | StreamRing | DBG - Request received, id: alsa, cmd:9 13.11.19 08:24:57.500 | CommandHandler | DBG - Handle command [QUERY_HW_PARAM] 13.11.19 08:24:57.508 | AlsaPcm | DBG - Query pcm device hw:2,0 for HW parameters 13.11.19 08:24:57.516 | CommandHandler | DBG - Return status: [0] 13.11.19 08:24:57.523 | XenEvtchn | DBG - Notify event channel, port: 10 13.11.19 08:24:57.531 | XenEvtchn | DBG - Event received, port: 10 13.11.19 08:24:57.538 | StreamRing | DBG - Request received, id: alsa, cmd:9 13.11.19 08:24:57.546 | CommandHandler | DBG - Handle command [QUERY_HW_PARAM] 13.11.19 08:24:57.554 | AlsaPcm | DBG - Query pcm device hw:2,0 for HW parameters 13.11.19 08:24:57.563 | CommandHandler | DBG - Return status: [0] 13.11.19 08:24:57.570 | XenEvtchn | DBG - Notify event channel, port: 10 13.11.19 08:24:57.577 | XenEvtchn | DBG - Event received, port: 10 13.11.19 08:24:57.584 | StreamRing | DBG - Request received, id: alsa, cmd:9 13.11.19 08:24:57.593 | CommandHandler | DBG - Handle command [QUERY_HW_PARAM] 13.11.19 08:24:57.601 | AlsaPcm | DBG - Query pcm device hw:2,0 for HW parameters 13.11.19 08:24:57.610 | CommandHandler | DBG - Return status: [0] 13.11.19 08:24:57.616 | XenEvtchn | DBG - Notify event channel, port: 10 13.11.19 08:24:57.624 | XenEvtchn | DBG - Event received, port: 10 13.11.19 08:24:57.631 | StreamRing | DBG - Request received, id: alsa, cmd:9 13.11.19 08:24:57.640 | CommandHandler | DBG - Handle command [QUERY_HW_PARAM] 13.11.19 08:24:57.647 | AlsaPcm | DBG - Query pcm device hw:2,0 for HW parameters 13.11.19 08:24:57.656 | CommandHandler | DBG - Return status: [0] 13.11.19 08:24:57.663 | XenEvtchn | DBG - Notify event channel, port: 10 13.11.19 08:24:57.671 | XenEvtchn | DBG - Event received, port: 10 13.11.19 08:24:57.678 | StreamRing | DBG - Request received, id: alsa, cmd:9 13.11.19 08:24:57.686 | CommandHandler | DBG - Handle command [QUERY_HW_PARAM] 13.11.19 08:24:57.694 | AlsaPcm | DBG - Query pcm device hw:2,0 for HW parameters 13.11.19 08:24:57.703 | CommandHandler | DBG - Return status: [0] 13.11.19 08:24:57.709 | XenEvtchn | DBG - Notify event channel, port: 10 My xl.cfg: vsnd = [ ['CARD, short-name=Main, sample-formats=s16_le;s8;u32_be', 'PCM, name=Main', 'STREAM, unique-id=alsa, type=p', 'STREAM, unique-id=alsa, type=c, channels- max=2' ], ] Config seems to be ok The audio device on my board: aplay -l List of PLAYBACK Hardware Devices card 0: imxaudmix [imx-audmix], device 0: HiFi-AUDMIX-FE (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: imxaudmix [imx-audmix], device 1: HiFi-AUDMIX-FE (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: cs42888audio [cs42888-audio], device 0: HiFi cs42888-0 [HiFi cs42888-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: cs42888audio [cs42888-audio], device 1: HiFi-ASRC-FE (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: wm8960audio [wm8960-audio], device 0: HiFi wm8960-hifi-0 [] Subdevices: 0/1 Subdevice #0: subdevice #0 Is there something wrong in my configuration? Thanks, Peng. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://urldefense.com/v3/__https://lists.xenproject.org/mailman/listinfo/xen-devel__;!K6dmGCEab4ueJg!iTeJON61Y2nUcGMQr_y7-27bR_QlOG8gXqvRMaU8yy8nJuDhzWizylvl_6stD-ILOQ$ ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel [1]
Re: [Xen-devel] [PATCH v3 1/3] introduce GFN notification for translated domains
> -Original Message- > From: Jan Beulich > Sent: 25 November 2019 10:51 > To: Durrant, Paul > Cc: xen-devel@lists.xenproject.org; Andrew Cooper > ; Ian Jackson ; Roger > Pau Monné ; Sander Eikelenboom > ; George Dunlap ; > Stefano Stabellini ; Konrad Wilk > ; Juergen Gross ; Julien Grall > ; Wei Liu > Subject: Re: [Xen-devel] [PATCH v3 1/3] introduce GFN notification for > translated domains > > On 25.11.2019 11:37, Durrant, Paul wrote: > >> -Original Message- > >> From: Xen-devel On Behalf Of > Jan > >> Beulich > >> Sent: 25 November 2019 09:58 > >> > >> --- a/xen/arch/x86/hvm/hvm.c > >> +++ b/xen/arch/x86/hvm/hvm.c > >> @@ -4304,9 +4304,17 @@ static int hvmop_set_param( > >> if ( a.value > SHUTDOWN_MAX ) > >> rc = -EINVAL; > >> break; > >> + > >> case HVM_PARAM_IOREQ_SERVER_PFN: > >> -d->arch.hvm.ioreq_gfn.base = a.value; > >> +if ( d->arch.hvm.params[HVM_PARAM_NR_IOREQ_SERVER_PAGES] ) > >> +rc = notify_gfn( > >> + d, > >> + _gfn(a.value + d->arch.hvm.params > >> +[HVM_PARAM_NR_IOREQ_SERVER_PAGES] > - > >> 1)); > > > > IIRC the PFN is typically set by the toolstack before the number of > > pages, so the notify will be for a.value - 1, i.e. the previous gfn. > > Is that a problem? > > There's an if() around the invocation to avoid this situation, so I'm > afraid I don't understand the question. D'oh... Missed it. Sorry for the noise. Paul > > Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 1/3] introduce GFN notification for translated domains
On 25.11.2019 11:37, Durrant, Paul wrote: >> -Original Message- >> From: Xen-devel On Behalf Of Jan >> Beulich >> Sent: 25 November 2019 09:58 >> >> --- a/xen/arch/x86/hvm/hvm.c >> +++ b/xen/arch/x86/hvm/hvm.c >> @@ -4304,9 +4304,17 @@ static int hvmop_set_param( >> if ( a.value > SHUTDOWN_MAX ) >> rc = -EINVAL; >> break; >> + >> case HVM_PARAM_IOREQ_SERVER_PFN: >> -d->arch.hvm.ioreq_gfn.base = a.value; >> +if ( d->arch.hvm.params[HVM_PARAM_NR_IOREQ_SERVER_PAGES] ) >> +rc = notify_gfn( >> + d, >> + _gfn(a.value + d->arch.hvm.params >> +[HVM_PARAM_NR_IOREQ_SERVER_PAGES] - >> 1)); > > IIRC the PFN is typically set by the toolstack before the number of > pages, so the notify will be for a.value - 1, i.e. the previous gfn. > Is that a problem? There's an if() around the invocation to avoid this situation, so I'm afraid I don't understand the question. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] tools/tests/x86_emulator causes build failures with older but supported compilers
On 23.11.2019 19:00, Doug Goldstein wrote:
> Per README, GCC 4.1.2 should lead to a successful default "make install"
> per INSTALL. Currently this is failing due to tools/tests/x86_emulator
> being in the default path and requiring a compiler with AVX. GCC 4.4.7
> on CentOS 6 does not have this leading to a failure to build.
>
> 1265 make[5]: Entering directory `/builds/xen-project/xen/tools/tests'
> 1266 make -C x86_emulator install
> 1267 cc1: error: unrecognized command line option "-mavx2"
> 1268 cc1: error: unrecognized command line option "-mavx512f"
> 1269 cc1: error: unrecognized command line option "-mavx512bw"
> 1270 cc1: error: unrecognized command line option "-mavx512dq"
> 1271 cc1: error: unrecognized command line option "-mavx512er"
> 1272 cc1: error: unrecognized command line option "-mavx512vbmi"
> 1273 /tmp/ccMkLpTV.s: Assembler messages:
> 1274 /tmp/ccMkLpTV.s:3: Error: junk at end of line, first unrecognized
> character is `{'
These are errors, yes, but ...
> 1275 make[6]: Entering directory
> `/builds/xen-project/xen/tools/tests/x86_emulator'
> 1276 Makefile:116: Test harness not built, use newer compiler than "gcc"
> (version 4.4.7) and an "{evex}" capable assembler
> 1277 make[6]: Nothing to be done for `install'.
... there's no build failure here afaics, and this is the intended
way of how things are to work.
> Full log here: https://gitlab.com/xen-project/xen/-/jobs/358852978#L1266
>
> We have 2 options for the next release:
>
> 1. Bump the minimum GCC requirement for the tree and drop any support
> for any distro not matching that requirement.
Not an option - the harness can only be built with gcc 8 or newer right
now, yet we can't raise the requirements (for all of Xen) this much imo.
> 2. Fix the default build to work with older GCC versions.
Not a reasonable option either, as it would be cluttering the harness
with all sorts of #ifdef-s or abstracting wrappers, making it even
more difficult to make changes to it.
What was considered in the past was to skip building of tests/ as a
whole in non-debug builds; don't know what has come of this. It is
probably telling enough that the bottom of ./Config.mk reads like this:
# Short answer -- do not enable this unless you know what you are
# doing and are prepared for some pain.
CONFIG_TESTS ?= y
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] vsnd issue
Hello Peng Fan Please contact Oleksandr Andrushchenko (added to this thread) on this issue. -- Artem On Mon, 2019-11-25 at 10:24 +, Julien Grall wrote: > > On 25/11/2019 10:19, Peng Fan wrote: > > Hi All, > > Hi, > > > I am trying vsnd from xen-troops with xen 4.13 and Linux 5.4, but > > domu reports: > > xen-troops is not part of Xen Project. Please contact the owner of > the > repo for any help here. > > I have CCed Artem who should be able to point to the author of vsnd. > > Best regards, > > > aplay compl.mp3 > > ALSA lib ../../../alsa-lib- > > 1.1.9/src/pcm/pcm_direct.c:1156:(snd1_pcm_direct_initialize_slave) > > slave plugin does not support mmap interleaved or mmap > > noninterleaved access > > ALSA lib ../../../alsa-lib- > > 1.1.9/src/pcm/pcm_dmix.c:1120:(snd_pcm_dmix_open) unable to > > initialize slave > > aplay: main:828: audio open error: Invalid argument > > > > When executing aplay in domu, dom0 side log: > > root@imx8qmmek:~# 13.11.19 08:24:57.484 | XenEvtchn | DBG - > > Event received, port: 10 > > 13.11.19 08:24:57.491 | StreamRing | DBG - Request received, > > id: alsa, cmd:9 > > 13.11.19 08:24:57.500 | CommandHandler | DBG - Handle command > > [QUERY_HW_PARAM] > > 13.11.19 08:24:57.508 | AlsaPcm | DBG - Query pcm device > > hw:2,0 for HW parameters > > 13.11.19 08:24:57.516 | CommandHandler | DBG - Return status: [0] > > 13.11.19 08:24:57.523 | XenEvtchn | DBG - Notify event > > channel, port: 10 > > 13.11.19 08:24:57.531 | XenEvtchn | DBG - Event received, > > port: 10 > > 13.11.19 08:24:57.538 | StreamRing | DBG - Request received, > > id: alsa, cmd:9 > > 13.11.19 08:24:57.546 | CommandHandler | DBG - Handle command > > [QUERY_HW_PARAM] > > 13.11.19 08:24:57.554 | AlsaPcm | DBG - Query pcm device > > hw:2,0 for HW parameters > > 13.11.19 08:24:57.563 | CommandHandler | DBG - Return status: [0] > > 13.11.19 08:24:57.570 | XenEvtchn | DBG - Notify event > > channel, port: 10 > > 13.11.19 08:24:57.577 | XenEvtchn | DBG - Event received, > > port: 10 > > 13.11.19 08:24:57.584 | StreamRing | DBG - Request received, > > id: alsa, cmd:9 > > 13.11.19 08:24:57.593 | CommandHandler | DBG - Handle command > > [QUERY_HW_PARAM] > > 13.11.19 08:24:57.601 | AlsaPcm | DBG - Query pcm device > > hw:2,0 for HW parameters > > 13.11.19 08:24:57.610 | CommandHandler | DBG - Return status: [0] > > 13.11.19 08:24:57.616 | XenEvtchn | DBG - Notify event > > channel, port: 10 > > 13.11.19 08:24:57.624 | XenEvtchn | DBG - Event received, > > port: 10 > > 13.11.19 08:24:57.631 | StreamRing | DBG - Request received, > > id: alsa, cmd:9 > > 13.11.19 08:24:57.640 | CommandHandler | DBG - Handle command > > [QUERY_HW_PARAM] > > 13.11.19 08:24:57.647 | AlsaPcm | DBG - Query pcm device > > hw:2,0 for HW parameters > > 13.11.19 08:24:57.656 | CommandHandler | DBG - Return status: [0] > > 13.11.19 08:24:57.663 | XenEvtchn | DBG - Notify event > > channel, port: 10 > > 13.11.19 08:24:57.671 | XenEvtchn | DBG - Event received, > > port: 10 > > 13.11.19 08:24:57.678 | StreamRing | DBG - Request received, > > id: alsa, cmd:9 > > 13.11.19 08:24:57.686 | CommandHandler | DBG - Handle command > > [QUERY_HW_PARAM] > > 13.11.19 08:24:57.694 | AlsaPcm | DBG - Query pcm device > > hw:2,0 for HW parameters > > 13.11.19 08:24:57.703 | CommandHandler | DBG - Return status: [0] > > 13.11.19 08:24:57.709 | XenEvtchn | DBG - Notify event > > channel, port: 10 > > > > > > My xl.cfg: > > vsnd = [ > > ['CARD, short-name=Main, sample-formats=s16_le;s8;u32_be', > > 'PCM, name=Main', > > 'STREAM, unique-id=alsa, type=p', > > 'STREAM, unique-id=alsa, type=c, channels- > > max=2' > > ], > > ] > > > > The audio device on my board: > > aplay -l > > List of PLAYBACK Hardware Devices > > card 0: imxaudmix [imx-audmix], device 0: HiFi-AUDMIX-FE (*) [] > >Subdevices: 1/1 > >Subdevice #0: subdevice #0 > > card 0: imxaudmix [imx-audmix], device 1: HiFi-AUDMIX-FE (*) [] > >Subdevices: 1/1 > >Subdevice #0: subdevice #0 > > card 1: cs42888audio [cs42888-audio], device 0: HiFi cs42888-0 > > [HiFi cs42888-0] > >Subdevices: 1/1 > >Subdevice #0: subdevice #0 > > card 1: cs42888audio [cs42888-audio], device 1: HiFi-ASRC-FE (*) [] > >Subdevices: 1/1 > >Subdevice #0: subdevice #0 > > card 2: wm8960audio [wm8960-audio], device 0: HiFi wm8960-hifi-0 [] > >Subdevices: 0/1 > >Subdevice #0: subdevice #0 > > > > Is there something wrong in my configuration? > > > > Thanks, > > Peng. > > > > ___ > > Xen-devel mailing list > > Xen-devel@lists.xenproject.org > > > > https://urldefense.com/v3/__https://lists.xenproject.org/mailman/listinfo/xen-devel__;!K6dmGCEab4ueJg!iTeJON61Y2nUcGMQr_y7-27bR_QlOG8gXqvRMaU8yy8nJuDhzWizylvl_6stD-ILOQ$ > > > > > >
Re: [Xen-devel] [PATCH v3 1/3] introduce GFN notification for translated domains
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 25 November 2019 09:58
> To: xen-devel@lists.xenproject.org
> Cc: Juergen Gross ; Stefano Stabellini
> ; Julien Grall ; Wei Liu
> ; Konrad Wilk ; George Dunlap
> ; Andrew Cooper ;
> Sander Eikelenboom ; Ian Jackson
> ; Roger Pau Monné
> Subject: [Xen-devel] [PATCH v3 1/3] introduce GFN notification for
> translated domains
>
> In order for individual IOMMU drivers (and from an abstract pov also
> architectures) to be able to adjust, ahead of actual mapping requests,
> their data structures when they might cover only a sub-range of all
> possible GFNs, introduce a notification call used by various code paths
> potentially installing a fresh mapping of a never used GFN (for a
> particular domain).
>
> Note that before this patch, in gnttab_transfer(), once past
> assign_pages(), further errors modifying the physmap are ignored
> (presumably because it would be too complicated to try to roll back at
> that point). This patch follows suit by ignoring failed notify_gfn()s or
> races due to the need to intermediately drop locks, simply printing out
> a warning that the gfn may not be accessible due to the failure.
>
> Signed-off-by: Jan Beulich
> ---
> v3: Conditionalize upon CONFIG_IOMMU_FORCE_PT_SHARE, also covering the
> share_p2m_table() functionality as appropriate. Un-comment the
> GNTMAP_host_map check.
> v2: Introduce arch_notify_gfn(), to invoke gfn_valid() on x86 (this
> unfortunately means it and notify_gfn() now need to be macros, or
> else include file dependencies get in the way, as gfn_valid() lives
> in paging.h, which we shouldn't include from xen/sched.h). Improve
> description.
>
> TBD: Does Arm actually have anything to check against in its
> arch_notify_gfn()?
>
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -173,7 +173,8 @@ static int __init pvh_populate_memory_ra
> continue;
> }
>
> -rc = guest_physmap_add_page(d, _gfn(start), page_to_mfn(page),
> +rc = notify_gfn(d, _gfn(start + (1UL << order) - 1)) ?:
> + guest_physmap_add_page(d, _gfn(start), page_to_mfn(page),
> order);
> if ( rc != 0 )
> {
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4304,9 +4304,17 @@ static int hvmop_set_param(
> if ( a.value > SHUTDOWN_MAX )
> rc = -EINVAL;
> break;
> +
> case HVM_PARAM_IOREQ_SERVER_PFN:
> -d->arch.hvm.ioreq_gfn.base = a.value;
> +if ( d->arch.hvm.params[HVM_PARAM_NR_IOREQ_SERVER_PAGES] )
> +rc = notify_gfn(
> + d,
> + _gfn(a.value + d->arch.hvm.params
> +[HVM_PARAM_NR_IOREQ_SERVER_PAGES] -
> 1));
IIRC the PFN is typically set by the toolstack before the number of pages, so
the notify will be for a.value - 1, i.e. the previous gfn. Is that a problem?
Paul
> +if ( !rc )
> + d->arch.hvm.ioreq_gfn.base = a.value;
> break;
> +
> case HVM_PARAM_NR_IOREQ_SERVER_PAGES:
> {
> unsigned int i;
> @@ -4317,6 +4325,9 @@ static int hvmop_set_param(
> rc = -EINVAL;
> break;
> }
> +rc = notify_gfn(d, _gfn(d->arch.hvm.ioreq_gfn.base + a.value -
> 1));
> +if ( rc )
> +break;
> for ( i = 0; i < a.value; i++ )
> set_bit(i, >arch.hvm.ioreq_gfn.mask);
>
> @@ -4330,7 +4341,11 @@ static int hvmop_set_param(
> BUILD_BUG_ON(HVM_PARAM_BUFIOREQ_PFN >
> sizeof(d->arch.hvm.ioreq_gfn.legacy_mask) * 8);
> if ( a.value )
> -set_bit(a.index, >arch.hvm.ioreq_gfn.legacy_mask);
> +{
> +rc = notify_gfn(d, _gfn(a.value));
> +if ( !rc )
> +set_bit(a.index, >arch.hvm.ioreq_gfn.legacy_mask);
> +}
> break;
>
> case HVM_PARAM_X87_FIP_WIDTH:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -946,6 +946,16 @@ map_grant_ref(
> return;
> }
>
> +if ( paging_mode_translate(ld) && (op->flags & GNTMAP_host_map) &&
> + (rc = notify_gfn(ld, gaddr_to_gfn(op->host_addr))) )
> +{
> +gdprintk(XENLOG_INFO, "notify(%"PRI_gfn") -> %d\n",
> + gfn_x(gaddr_to_gfn(op->host_addr)), rc);
> +op->status = GNTST_general_error;
> +return;
> +BUILD_BUG_ON(GNTST_okay);
> +}
> +
> if ( unlikely((rd = rcu_lock_domain_by_id(op->dom)) == NULL) )
> {
> gdprintk(XENLOG_INFO, "Could not find domain %d\n", op->dom);
> @@ -2123,6 +2133,7 @@ gnttab_transfer(
> {
> bool_t okay;
> int rc;
> +gfn_t gfn;
>
> if ( i && hypercall_preempt_check() )
> return i;
> @@ -2300,21 +2311,52 @@ gnttab_transfer(
> act =
Re: [Xen-devel] vsnd issue
On 25/11/2019 10:19, Peng Fan wrote: Hi All, Hi, I am trying vsnd from xen-troops with xen 4.13 and Linux 5.4, but domu reports: xen-troops is not part of Xen Project. Please contact the owner of the repo for any help here. I have CCed Artem who should be able to point to the author of vsnd. Best regards, aplay compl.mp3 ALSA lib ../../../alsa-lib-1.1.9/src/pcm/pcm_direct.c:1156:(snd1_pcm_direct_initialize_slave) slave plugin does not support mmap interleaved or mmap noninterleaved access ALSA lib ../../../alsa-lib-1.1.9/src/pcm/pcm_dmix.c:1120:(snd_pcm_dmix_open) unable to initialize slave aplay: main:828: audio open error: Invalid argument When executing aplay in domu, dom0 side log: root@imx8qmmek:~# 13.11.19 08:24:57.484 | XenEvtchn | DBG - Event received, port: 10 13.11.19 08:24:57.491 | StreamRing | DBG - Request received, id: alsa, cmd:9 13.11.19 08:24:57.500 | CommandHandler | DBG - Handle command [QUERY_HW_PARAM] 13.11.19 08:24:57.508 | AlsaPcm | DBG - Query pcm device hw:2,0 for HW parameters 13.11.19 08:24:57.516 | CommandHandler | DBG - Return status: [0] 13.11.19 08:24:57.523 | XenEvtchn | DBG - Notify event channel, port: 10 13.11.19 08:24:57.531 | XenEvtchn | DBG - Event received, port: 10 13.11.19 08:24:57.538 | StreamRing | DBG - Request received, id: alsa, cmd:9 13.11.19 08:24:57.546 | CommandHandler | DBG - Handle command [QUERY_HW_PARAM] 13.11.19 08:24:57.554 | AlsaPcm | DBG - Query pcm device hw:2,0 for HW parameters 13.11.19 08:24:57.563 | CommandHandler | DBG - Return status: [0] 13.11.19 08:24:57.570 | XenEvtchn | DBG - Notify event channel, port: 10 13.11.19 08:24:57.577 | XenEvtchn | DBG - Event received, port: 10 13.11.19 08:24:57.584 | StreamRing | DBG - Request received, id: alsa, cmd:9 13.11.19 08:24:57.593 | CommandHandler | DBG - Handle command [QUERY_HW_PARAM] 13.11.19 08:24:57.601 | AlsaPcm | DBG - Query pcm device hw:2,0 for HW parameters 13.11.19 08:24:57.610 | CommandHandler | DBG - Return status: [0] 13.11.19 08:24:57.616 | XenEvtchn | DBG - Notify event channel, port: 10 13.11.19 08:24:57.624 | XenEvtchn | DBG - Event received, port: 10 13.11.19 08:24:57.631 | StreamRing | DBG - Request received, id: alsa, cmd:9 13.11.19 08:24:57.640 | CommandHandler | DBG - Handle command [QUERY_HW_PARAM] 13.11.19 08:24:57.647 | AlsaPcm | DBG - Query pcm device hw:2,0 for HW parameters 13.11.19 08:24:57.656 | CommandHandler | DBG - Return status: [0] 13.11.19 08:24:57.663 | XenEvtchn | DBG - Notify event channel, port: 10 13.11.19 08:24:57.671 | XenEvtchn | DBG - Event received, port: 10 13.11.19 08:24:57.678 | StreamRing | DBG - Request received, id: alsa, cmd:9 13.11.19 08:24:57.686 | CommandHandler | DBG - Handle command [QUERY_HW_PARAM] 13.11.19 08:24:57.694 | AlsaPcm | DBG - Query pcm device hw:2,0 for HW parameters 13.11.19 08:24:57.703 | CommandHandler | DBG - Return status: [0] 13.11.19 08:24:57.709 | XenEvtchn | DBG - Notify event channel, port: 10 My xl.cfg: vsnd = [ ['CARD, short-name=Main, sample-formats=s16_le;s8;u32_be', 'PCM, name=Main', 'STREAM, unique-id=alsa, type=p', 'STREAM, unique-id=alsa, type=c, channels-max=2' ], ] The audio device on my board: aplay -l List of PLAYBACK Hardware Devices card 0: imxaudmix [imx-audmix], device 0: HiFi-AUDMIX-FE (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: imxaudmix [imx-audmix], device 1: HiFi-AUDMIX-FE (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: cs42888audio [cs42888-audio], device 0: HiFi cs42888-0 [HiFi cs42888-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: cs42888audio [cs42888-audio], device 1: HiFi-ASRC-FE (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: wm8960audio [wm8960-audio], device 0: HiFi wm8960-hifi-0 [] Subdevices: 0/1 Subdevice #0: subdevice #0 Is there something wrong in my configuration? Thanks, Peng. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] vsnd issue
Hi All, I am trying vsnd from xen-troops with xen 4.13 and Linux 5.4, but domu reports: aplay compl.mp3 ALSA lib ../../../alsa-lib-1.1.9/src/pcm/pcm_direct.c:1156:(snd1_pcm_direct_initialize_slave) slave plugin does not support mmap interleaved or mmap noninterleaved access ALSA lib ../../../alsa-lib-1.1.9/src/pcm/pcm_dmix.c:1120:(snd_pcm_dmix_open) unable to initialize slave aplay: main:828: audio open error: Invalid argument When executing aplay in domu, dom0 side log: root@imx8qmmek:~# 13.11.19 08:24:57.484 | XenEvtchn | DBG - Event received, port: 10 13.11.19 08:24:57.491 | StreamRing | DBG - Request received, id: alsa, cmd:9 13.11.19 08:24:57.500 | CommandHandler | DBG - Handle command [QUERY_HW_PARAM] 13.11.19 08:24:57.508 | AlsaPcm | DBG - Query pcm device hw:2,0 for HW parameters 13.11.19 08:24:57.516 | CommandHandler | DBG - Return status: [0] 13.11.19 08:24:57.523 | XenEvtchn | DBG - Notify event channel, port: 10 13.11.19 08:24:57.531 | XenEvtchn | DBG - Event received, port: 10 13.11.19 08:24:57.538 | StreamRing | DBG - Request received, id: alsa, cmd:9 13.11.19 08:24:57.546 | CommandHandler | DBG - Handle command [QUERY_HW_PARAM] 13.11.19 08:24:57.554 | AlsaPcm | DBG - Query pcm device hw:2,0 for HW parameters 13.11.19 08:24:57.563 | CommandHandler | DBG - Return status: [0] 13.11.19 08:24:57.570 | XenEvtchn | DBG - Notify event channel, port: 10 13.11.19 08:24:57.577 | XenEvtchn | DBG - Event received, port: 10 13.11.19 08:24:57.584 | StreamRing | DBG - Request received, id: alsa, cmd:9 13.11.19 08:24:57.593 | CommandHandler | DBG - Handle command [QUERY_HW_PARAM] 13.11.19 08:24:57.601 | AlsaPcm | DBG - Query pcm device hw:2,0 for HW parameters 13.11.19 08:24:57.610 | CommandHandler | DBG - Return status: [0] 13.11.19 08:24:57.616 | XenEvtchn | DBG - Notify event channel, port: 10 13.11.19 08:24:57.624 | XenEvtchn | DBG - Event received, port: 10 13.11.19 08:24:57.631 | StreamRing | DBG - Request received, id: alsa, cmd:9 13.11.19 08:24:57.640 | CommandHandler | DBG - Handle command [QUERY_HW_PARAM] 13.11.19 08:24:57.647 | AlsaPcm | DBG - Query pcm device hw:2,0 for HW parameters 13.11.19 08:24:57.656 | CommandHandler | DBG - Return status: [0] 13.11.19 08:24:57.663 | XenEvtchn | DBG - Notify event channel, port: 10 13.11.19 08:24:57.671 | XenEvtchn | DBG - Event received, port: 10 13.11.19 08:24:57.678 | StreamRing | DBG - Request received, id: alsa, cmd:9 13.11.19 08:24:57.686 | CommandHandler | DBG - Handle command [QUERY_HW_PARAM] 13.11.19 08:24:57.694 | AlsaPcm | DBG - Query pcm device hw:2,0 for HW parameters 13.11.19 08:24:57.703 | CommandHandler | DBG - Return status: [0] 13.11.19 08:24:57.709 | XenEvtchn | DBG - Notify event channel, port: 10 My xl.cfg: vsnd = [ ['CARD, short-name=Main, sample-formats=s16_le;s8;u32_be', 'PCM, name=Main', 'STREAM, unique-id=alsa, type=p', 'STREAM, unique-id=alsa, type=c, channels-max=2' ], ] The audio device on my board: aplay -l List of PLAYBACK Hardware Devices card 0: imxaudmix [imx-audmix], device 0: HiFi-AUDMIX-FE (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: imxaudmix [imx-audmix], device 1: HiFi-AUDMIX-FE (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: cs42888audio [cs42888-audio], device 0: HiFi cs42888-0 [HiFi cs42888-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: cs42888audio [cs42888-audio], device 1: HiFi-ASRC-FE (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: wm8960audio [wm8960-audio], device 0: HiFi wm8960-hifi-0 [] Subdevices: 0/1 Subdevice #0: subdevice #0 Is there something wrong in my configuration? Thanks, Peng. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.11-testing test] 144288: regressions - FAIL
flight 144288 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/144288/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 144025 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 74507046dbd2c5d2991eeabd1af39af0d6b29d70 baseline version: xen 006b2041242129896fbd30135b3dc6f575894a07 Last test of basis 144025 2019-11-11 17:36:00 Z 13 days Testing same since 144058 2019-11-12 18:05:56 Z 12 days 22 attempts
Re: [Xen-devel] [PATCH] x86: avoid HPET use on certain Intel platforms
On 23.11.2019 00:10, Andreas Kinzler wrote: > BTW: Xeon E-2136 @ C242 has 8086:3eca as ID. One needs to check with > Intel which combinations are really affected. Are you saying you observed the same issue on such a (server processor) system as well? Neither its datasheet nor its specification update (which I specifically downloaded and looked through just because of your remark) have any mention of a similar issue. I also take it that the code comment inherited from Linux says "SoCs" for a reason. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 3/3] gnttab: don't expose host physical address without need
Translated domains shouldn't see host physical addresses. While the
address is also not supposed to be handed back even to non-translated
domains when GNTMAP_device_map is not set (as explicitly stated by a
comment in the public header), PV kernels (Linux at least) assume the
field to get populated nevertheless. (Similarly mapkind() should check
only GNTMAP_device_map.)
Along these lines split the paging mode related check near the top of
map_grant_ref() to handle the "external" and "translated" cases
separately (GNTMAP_device_map use getting tied to being non-translated
rather than non-external), and make the assignment of ->dev_bus_addr
conditional upon the guest being a non-translated one.
Still along these lines in the unmapping case there's no point checking
->dev_bus_addr when GNTMAP_device_map isn't set (and hence the field
isn't going to be consumed).
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -938,21 +938,29 @@ map_grant_ref(
}
if ( unlikely(paging_mode_external(ld) &&
- (op->flags & (GNTMAP_device_map|GNTMAP_application_map|
-GNTMAP_contains_pte))) )
+ (op->flags & (GNTMAP_application_map|GNTMAP_contains_pte))) )
{
-gdprintk(XENLOG_INFO, "No device mapping in HVM domain\n");
+gdprintk(XENLOG_INFO, "No application mapping in HVM domain\n");
op->status = GNTST_general_error;
return;
}
-if ( paging_mode_translate(ld) && (op->flags & GNTMAP_host_map) &&
- (rc = notify_gfn(ld, gaddr_to_gfn(op->host_addr))) )
+if ( paging_mode_translate(ld) )
{
-gdprintk(XENLOG_INFO, "notify(%"PRI_gfn") -> %d\n",
- gfn_x(gaddr_to_gfn(op->host_addr)), rc);
-op->status = GNTST_general_error;
-return;
+if ( unlikely((op->flags & GNTMAP_device_map)) )
+{
+gdprintk(XENLOG_INFO, "No device mapping in translated domain\n");
+op->status = GNTST_general_error;
+return;
+}
+
+if ( unlikely(rc = notify_gfn(ld, gaddr_to_gfn(op->host_addr))) )
+{
+gdprintk(XENLOG_INFO, "notify(%"PRI_gfn") -> %d\n",
+ gfn_x(gaddr_to_gfn(op->host_addr)), rc);
+op->status = GNTST_general_error;
+return;
+}
BUILD_BUG_ON(GNTST_okay);
}
@@ -1201,7 +1209,8 @@ map_grant_ref(
if ( need_iommu )
double_gt_unlock(lgt, rgt);
-op->dev_bus_addr = mfn_to_maddr(mfn);
+op->dev_bus_addr = paging_mode_translate(ld) ? op->host_addr
+ : mfn_to_maddr(mfn);
op->handle = handle;
op->status = GNTST_okay;
@@ -1382,7 +1391,7 @@ unmap_common(
op->mfn = act->mfn;
-if ( op->dev_bus_addr &&
+if ( op->dev_bus_addr && (flags & GNTMAP_device_map) &&
unlikely(op->dev_bus_addr != mfn_to_maddr(act->mfn)) )
PIN_FAIL(act_release_out, GNTST_general_error,
"Bus address doesn't match gntref (%"PRIx64" !=
%"PRIpaddr")\n",
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 2/3] AMD/IOMMU: use notify_dfn() hook to update paging mode
update_paging_mode() expects to be invoked with the PCI devices lock
held. The check occurring only when the mode actually needs updating,
the violation of this rule by the majority of callers did go unnoticed
until per-domain IOMMU setup was changed to do away with on-demand
creation of IOMMU page tables.
Acquiring the necessary lock in amd_iommu_map_page() or intermediate
layers in generic IOMMU code is not possible - we'd risk all sorts of
lock order violations. Hence the call to update_paging_mode() gets
pulled out of the function, to be invoked instead from the new
notify_dfn() hook, where no potentially conflicting locks are being
held by the callers.
Similarly the call to amd_iommu_alloc_root() gets pulled out - now
that we receive notification of all DFN range increases, there's no
need anymore to do this check when actually mapping a page.
Note that this ought to result in a small performance improvement as
well: The hook often gets invoked just once for larger blocks of pages,
so rather than going through amd_iommu_alloc_root() and
update_paging_mode() once per page, we may now invoke it just once per
batch.
Reported-by: Sander Eikelenboom
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -383,35 +383,16 @@ int amd_iommu_map_page(struct domain *d,
unsigned int flags, unsigned int *flush_flags)
{
struct domain_iommu *hd = dom_iommu(d);
-int rc;
unsigned long pt_mfn[7];
memset(pt_mfn, 0, sizeof(pt_mfn));
spin_lock(>arch.mapping_lock);
-rc = amd_iommu_alloc_root(hd);
-if ( rc )
+if ( !hd->arch.root_table )
{
spin_unlock(>arch.mapping_lock);
-AMD_IOMMU_DEBUG("Root table alloc failed, dfn = %"PRI_dfn"\n",
-dfn_x(dfn));
-domain_crash(d);
-return rc;
-}
-
-/* Since HVM domain is initialized with 2 level IO page table,
- * we might need a deeper page table for wider dfn now */
-if ( is_hvm_domain(d) )
-{
-if ( update_paging_mode(d, dfn_x(dfn)) )
-{
-spin_unlock(>arch.mapping_lock);
-AMD_IOMMU_DEBUG("Update page mode failed dfn = %"PRI_dfn"\n",
-dfn_x(dfn));
-domain_crash(d);
-return -EFAULT;
-}
+return -ENODATA;
}
if ( iommu_pde_from_dfn(d, dfn_x(dfn), pt_mfn, true) || (pt_mfn[1] == 0) )
@@ -468,6 +449,48 @@ int amd_iommu_unmap_page(struct domain *
return 0;
}
+
+int amd_iommu_notify_dfn(struct domain *d, dfn_t dfn)
+{
+struct domain_iommu *hd = dom_iommu(d);
+int rc;
+
+ASSERT(is_hvm_domain(d));
+
+/*
+ * Since HVM domain is initialized with 2 level IO page table,
+ * we might need a deeper page table for wider dfn now.
+ */
+pcidevs_lock();
+spin_lock(>arch.mapping_lock);
+
+rc = amd_iommu_alloc_root(hd);
+if ( rc )
+{
+spin_unlock(>arch.mapping_lock);
+pcidevs_unlock();
+AMD_IOMMU_DEBUG("Root table alloc failed, dfn = %"PRI_dfn" (rc %d)\n",
+dfn_x(dfn), rc);
+domain_crash(d);
+return rc;
+}
+
+rc = update_paging_mode(d, dfn_x(dfn));
+if ( rc )
+{
+spin_unlock(>arch.mapping_lock);
+pcidevs_unlock();
+AMD_IOMMU_DEBUG("Update paging mode failed dfn %"PRI_dfn" (rc %d)\n",
+dfn_x(dfn), rc);
+domain_crash(d);
+return rc;
+}
+
+spin_unlock(>arch.mapping_lock);
+pcidevs_unlock();
+
+return 0;
+}
static unsigned long flush_count(unsigned long dfn, unsigned int page_count,
unsigned int order)
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -638,6 +638,7 @@ static const struct iommu_ops __initcons
.teardown = amd_iommu_domain_destroy,
.map_page = amd_iommu_map_page,
.unmap_page = amd_iommu_unmap_page,
+.notify_dfn = amd_iommu_notify_dfn,
.iotlb_flush = amd_iommu_flush_iotlb_pages,
.iotlb_flush_all = amd_iommu_flush_iotlb_all,
.free_page_table = deallocate_page_table,
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
@@ -61,6 +61,7 @@ int __must_check amd_iommu_map_page(stru
int __must_check amd_iommu_unmap_page(struct domain *d, dfn_t dfn,
unsigned int *flush_flags);
int __must_check amd_iommu_alloc_root(struct domain_iommu *hd);
+int __must_check amd_iommu_notify_dfn(struct domain *d, dfn_t dfn);
int amd_iommu_reserve_domain_unity_map(struct domain *domain,
paddr_t phys_addr, unsigned long size,
int iw, int ir);
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
[Xen-devel] [PATCH v3 1/3] introduce GFN notification for translated domains
In order for individual IOMMU drivers (and from an abstract pov also
architectures) to be able to adjust, ahead of actual mapping requests,
their data structures when they might cover only a sub-range of all
possible GFNs, introduce a notification call used by various code paths
potentially installing a fresh mapping of a never used GFN (for a
particular domain).
Note that before this patch, in gnttab_transfer(), once past
assign_pages(), further errors modifying the physmap are ignored
(presumably because it would be too complicated to try to roll back at
that point). This patch follows suit by ignoring failed notify_gfn()s or
races due to the need to intermediately drop locks, simply printing out
a warning that the gfn may not be accessible due to the failure.
Signed-off-by: Jan Beulich
---
v3: Conditionalize upon CONFIG_IOMMU_FORCE_PT_SHARE, also covering the
share_p2m_table() functionality as appropriate. Un-comment the
GNTMAP_host_map check.
v2: Introduce arch_notify_gfn(), to invoke gfn_valid() on x86 (this
unfortunately means it and notify_gfn() now need to be macros, or
else include file dependencies get in the way, as gfn_valid() lives
in paging.h, which we shouldn't include from xen/sched.h). Improve
description.
TBD: Does Arm actually have anything to check against in its
arch_notify_gfn()?
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -173,7 +173,8 @@ static int __init pvh_populate_memory_ra
continue;
}
-rc = guest_physmap_add_page(d, _gfn(start), page_to_mfn(page),
+rc = notify_gfn(d, _gfn(start + (1UL << order) - 1)) ?:
+ guest_physmap_add_page(d, _gfn(start), page_to_mfn(page),
order);
if ( rc != 0 )
{
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4304,9 +4304,17 @@ static int hvmop_set_param(
if ( a.value > SHUTDOWN_MAX )
rc = -EINVAL;
break;
+
case HVM_PARAM_IOREQ_SERVER_PFN:
-d->arch.hvm.ioreq_gfn.base = a.value;
+if ( d->arch.hvm.params[HVM_PARAM_NR_IOREQ_SERVER_PAGES] )
+rc = notify_gfn(
+ d,
+ _gfn(a.value + d->arch.hvm.params
+[HVM_PARAM_NR_IOREQ_SERVER_PAGES] - 1));
+if ( !rc )
+ d->arch.hvm.ioreq_gfn.base = a.value;
break;
+
case HVM_PARAM_NR_IOREQ_SERVER_PAGES:
{
unsigned int i;
@@ -4317,6 +4325,9 @@ static int hvmop_set_param(
rc = -EINVAL;
break;
}
+rc = notify_gfn(d, _gfn(d->arch.hvm.ioreq_gfn.base + a.value - 1));
+if ( rc )
+break;
for ( i = 0; i < a.value; i++ )
set_bit(i, >arch.hvm.ioreq_gfn.mask);
@@ -4330,7 +4341,11 @@ static int hvmop_set_param(
BUILD_BUG_ON(HVM_PARAM_BUFIOREQ_PFN >
sizeof(d->arch.hvm.ioreq_gfn.legacy_mask) * 8);
if ( a.value )
-set_bit(a.index, >arch.hvm.ioreq_gfn.legacy_mask);
+{
+rc = notify_gfn(d, _gfn(a.value));
+if ( !rc )
+set_bit(a.index, >arch.hvm.ioreq_gfn.legacy_mask);
+}
break;
case HVM_PARAM_X87_FIP_WIDTH:
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -946,6 +946,16 @@ map_grant_ref(
return;
}
+if ( paging_mode_translate(ld) && (op->flags & GNTMAP_host_map) &&
+ (rc = notify_gfn(ld, gaddr_to_gfn(op->host_addr))) )
+{
+gdprintk(XENLOG_INFO, "notify(%"PRI_gfn") -> %d\n",
+ gfn_x(gaddr_to_gfn(op->host_addr)), rc);
+op->status = GNTST_general_error;
+return;
+BUILD_BUG_ON(GNTST_okay);
+}
+
if ( unlikely((rd = rcu_lock_domain_by_id(op->dom)) == NULL) )
{
gdprintk(XENLOG_INFO, "Could not find domain %d\n", op->dom);
@@ -2123,6 +2133,7 @@ gnttab_transfer(
{
bool_t okay;
int rc;
+gfn_t gfn;
if ( i && hypercall_preempt_check() )
return i;
@@ -2300,21 +2311,52 @@ gnttab_transfer(
act = active_entry_acquire(e->grant_table, gop.ref);
if ( evaluate_nospec(e->grant_table->gt_version == 1) )
+gfn = _gfn(shared_entry_v1(e->grant_table, gop.ref).frame);
+else
+gfn = _gfn(shared_entry_v2(e->grant_table,
gop.ref).full_page.frame);
+
+if ( paging_mode_translate(e) )
{
-grant_entry_v1_t *sha = _entry_v1(e->grant_table, gop.ref);
+gfn_t gfn2;
+
+active_entry_release(act);
+grant_read_unlock(e->grant_table);
+
+rc = notify_gfn(e, gfn);
+if ( rc )
+printk(XENLOG_G_WARNING
+ "%pd: gref %u: xfer GFN %"PRI_gfn" may be inaccessible
(%d)\n",
+ e, gop.ref, gfn_x(gfn), rc);
+
+grant_read_lock(e->grant_table);
+
[Xen-devel] [PATCH v3 0/3] AMD/IOMMU: re-work mode updating
update_paging_mode() in the AMD IOMMU code expects to be invoked with the PCI devices lock held. The check occurring only when the mode actually needs updating, the violation of this rule by the majority of callers did go unnoticed until per-domain IOMMU setup was changed to do away with on-demand creation of IOMMU page tables. Unfortunately the only half way reasonable fix to this that I could come up with requires more re-work than would seem desirable at this time of the release process, but addressing the issue seems unavoidable to me as its manifestation is a regression from the IOMMU page table setup re-work. The change also isn't without risk of further regressions - if in patch 2 I've missed a code path that would also need to invoke the new hook, then this might mean non- working guests (with passed-through devices on AMD hardware). 1: introduce GFN notification for translated domains 2: AMD/IOMMU: use notify_dfn() hook to update paging mode 3: gnttab: don't expose host physical address without need Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen hiding thermal capabilities from Dom0
On 23.11.19 05:29, Elliott Mitchell wrote: On Thu, Nov 21, 2019 at 04:46:21PM +0100, J??rgen Gro?? wrote: On 21.11.19 16:36, Jan Beulich wrote: On 21.11.2019 15:24, J??rgen Gro?? wrote: So: no, just giving dom0 access to the management hardware isn't going to fly. You need to have a proper virtualization layer for that purpose. Or, like I had done in our XenoLinux forward port, you need to go through hoops to make the coretemp driver actually understand the environment it's running in. This will still not guarantee you'll be able to reach all physical cpus. IIRC you pinned the vcpu to the respective physical cpu for performing its duty, but with cpupools this might not be possible for all physical cpus in the system. Similar to the issue of MCE support, might it instead be better to have *less* virtualization here instead of more? The original idea behind Xen was to leave the hard to virtualize bits visible and work with Domain 0. Might it be better to expose this functionality to Domain 0, then intercept the kernel calls? Just needs 1 vcpu which can be scheduled on any processor and that can be moved around to retrieve the data. This way Xen wouldn't need a proper driver for the management hardware. In case dom0 is to handle this then it would be much easier to have a way for dom0 to specify which physical cpu the data should be retrieved from. Forcing a dom0 vcpu to run on a specific physical cpu would need a major rework of the Xen scheduling (especially regarding cpupools, let alone core scheduling). Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/vtx: Fix fault semantics for early task switch failures
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Friday, November 22, 2019 6:16 AM > > The VT-x task switch handler adds inst_len to rip before calling > hvm_task_switch(). This causes early faults to be delivered to the guest > with > trap semantics, and break restartibility. > > Instead, pass the instruction length into hvm_task_switch() and write it into > the outgoing tss only, leaving rip in its original location. > > For now, pass 0 on the SVM side. This highlights a separate preexisting bug > which will be addressed in the following patch. > > While adjusting call sites, drop the unnecessary uint16_t cast. > > Signed-off-by: Andrew Cooper Reviewed-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86 / iommu: set up a scratch page in the quarantine domain
> From: Paul Durrant [mailto:pdurr...@amazon.com]
> Sent: Wednesday, November 20, 2019 8:09 PM
>
> This patch introduces a new iommu_op to facilitate a per-implementation
> quarantine set up, and then further code for x86 implementations
> (amd and vtd) to set up a read/wrote scratch page to serve as the source/
> target for all DMA whilst a device is assigned to dom_io.
>
> The reason for doing this is that some hardware may continue to re-try
> DMA, despite FLR, in the event of an error. Having a scratch page mapped
> will allow pending DMA to drain and thus quiesce such buggy hardware.
then there is no diagnostics at all since all faults are quiescent now...
why do we want to support such buggy hardware? Is it better to make
it an default-off option since buggy is supposed to niche case?
>
> Signed-off-by: Paul Durrant
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Kevin Tian
> Cc: Wei Liu
> Cc: "Roger Pau Monné"
> ---
> xen/drivers/passthrough/amd/iommu_map.c | 57 +++
> xen/drivers/passthrough/amd/pci_amd_iommu.c | 9 +--
> xen/drivers/passthrough/iommu.c | 25 ++-
> xen/drivers/passthrough/vtd/iommu.c | 71 +++
> xen/include/asm-x86/hvm/svm/amd-iommu-proto.h | 2 +
> xen/include/xen/iommu.h | 1 +
> 6 files changed, 143 insertions(+), 22 deletions(-)
>
> diff --git a/xen/drivers/passthrough/amd/iommu_map.c
> b/xen/drivers/passthrough/amd/iommu_map.c
> index cd5c7de7c5..8440ccf1c1 100644
> --- a/xen/drivers/passthrough/amd/iommu_map.c
> +++ b/xen/drivers/passthrough/amd/iommu_map.c
> @@ -560,6 +560,63 @@ int
> amd_iommu_reserve_domain_unity_map(struct domain *domain,
> return rt;
> }
>
> +int amd_iommu_quarantine_init(struct domain *d)
> +{
> +struct domain_iommu *hd = dom_iommu(d);
> +unsigned int level;
> +struct amd_iommu_pte *table;
> +
> +if ( hd->arch.root_table )
> +{
> +ASSERT_UNREACHABLE();
> +return 0;
> +}
> +
> +spin_lock(>arch.mapping_lock);
> +
> +level = hd->arch.paging_mode;
> +
> +hd->arch.root_table = alloc_amd_iommu_pgtable();
> +if ( !hd->arch.root_table )
> +goto out;
> +
> +table = __map_domain_page(hd->arch.root_table);
> +while ( level )
> +{
> +struct page_info *pg;
> +unsigned int i;
> +
> +/*
> + * The pgtable allocator is fine for the leaf page, as well as
> + * page table pages.
> + */
> +pg = alloc_amd_iommu_pgtable();
> +if ( !pg )
> +break;
> +
> +for ( i = 0; i < PTE_PER_TABLE_SIZE; i++ )
> +{
> +struct amd_iommu_pte *pde = [i];
> +
> +set_iommu_pde_present(pde, mfn_x(page_to_mfn(pg)), level - 1,
> + true, true);
> +}
> +
> +unmap_domain_page(table);
> +table = __map_domain_page(pg);
> +level--;
> +}
> +unmap_domain_page(table);
> +
> + out:
> +spin_unlock(>arch.mapping_lock);
> +
> +amd_iommu_flush_all_pages(d);
> +
> +/* Pages leaked in failure case */
> +return level ? -ENOMEM : 0;
> +}
> +
> /*
> * Local variables:
> * mode: C
> diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> index 75a0f1b4ab..c7858b4e8f 100644
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> @@ -95,10 +95,6 @@ static void amd_iommu_setup_domain_device(
> u8 bus = pdev->bus;
> const struct domain_iommu *hd = dom_iommu(domain);
>
> -/* dom_io is used as a sentinel for quarantined devices */
> -if ( domain == dom_io )
> -return;
> -
> BUG_ON( !hd->arch.root_table || !hd->arch.paging_mode ||
> !iommu->dev_table.buffer );
>
> @@ -290,10 +286,6 @@ static void
> amd_iommu_disable_domain_device(const struct domain *domain,
> int req_id;
> u8 bus = pdev->bus;
>
> -/* dom_io is used as a sentinel for quarantined devices */
> -if ( domain == dom_io )
> -return;
> -
> BUG_ON ( iommu->dev_table.buffer == NULL );
> req_id = get_dma_requestor_id(iommu->seg, PCI_BDF2(bus, devfn));
> table = iommu->dev_table.buffer;
> @@ -632,6 +624,7 @@ static void amd_dump_p2m_table(struct domain
> *d)
> static const struct iommu_ops __initconstrel _iommu_ops = {
> .init = amd_iommu_domain_init,
> .hwdom_init = amd_iommu_hwdom_init,
> +.quarantine_init = amd_iommu_quarantine_init,
> .add_device = amd_iommu_add_device,
> .remove_device = amd_iommu_remove_device,
> .assign_device = amd_iommu_assign_device,
> diff --git a/xen/drivers/passthrough/iommu.c
> b/xen/drivers/passthrough/iommu.c
> index 8cbe908fff..25283263d7 100644
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -440,6 +440,28 @@ int iommu_iotlb_flush_all(struct domain *d,
> unsigned int flush_flags)
>
