[Xen-devel] [xen-unstable test] 141083: regressions - FAIL
flight 141083 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/141083/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail REGR. vs. 139876 test-amd64-amd64-xl-qemuu-debianhvm-amd64 21 leak-check/check fail REGR. vs. 139876 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 139876 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 139876 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 139876 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 139876 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 139876 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 139876 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 139876 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 139876 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 139876 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 139876 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-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-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 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-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 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail 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-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-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail 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 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version
[Xen-devel] [linux-4.19 test] 141079: regressions - FAIL
flight 141079 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/141079/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 129313 build-armhf-pvops 6 kernel-build fail REGR. vs. 129313 test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail in 141040 REGR. vs. 129313 Tests which are failing intermittently (not blocking): test-arm64-arm64-examine 11 examine-serial/bootloader fail in 141040 pass in 141079 test-amd64-amd64-xl-pvshim 15 guest-saverestore fail pass in 141040 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-armhf-armhf-examine 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 13 migrate-support-check fail in 141040 never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail in 141040 never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail in 141040 never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail in 141040 never pass test-amd64-amd64-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-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-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-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-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-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-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-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-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop
Re: [Xen-devel] [PATCH v2 00/12] livepatch: new features and fixes
Hi Konrad, On 9/5/19 8:13 PM, Konrad Rzeszutek Wilk wrote: On Tue, Aug 27, 2019 at 08:46:12AM +, Pawel Wieczorkiewicz wrote: This series introduces new features to the livepatch functionality as briefly discussed during Xen Developer Summit 2019: [a] and [b]. It also provides a few fixes and some small improvements. Main changes in v2: - added new features to livepatch documentation - added livepatch tests - enabled Arm support for [5] - make .modinfo optional for [11] - fixed typos I took your patches, redid them per what I had responded on these patches (and squashed your fix for xen_expectations) and stuck them in my branch: http://xenbits.xen.org/gitweb/?p=people/konradwilk/xen.git;a=shortlog;h=refs/heads/livepatch.aws.v3 There are three extra patches that were needed for me to test on ARM32 - those are known issues and they don't block your patches. I will post them independent of your patches. From my perspective, your patches are good to go. But I believe I need: - the tools folks Ack on the libxc code changes, - and also an Ack from the REST on sysctl.h, - and Julian OK on the ARM32/ARM64 code changes which are tiny, but nonethless are his. I believe all the modifications are under in livepatch.c files. So your Ack should be sufficient here :). Anyway, feel free to add mine on Arm specific modifications. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 00/12] livepatch: new features and fixes
Hi, Thank you for the new version. However, I nearly missed the v2 as this is a sub-thread of v1. May I ask you to send a new version as a new thread instead? Cheers, On 8/27/19 9:46 AM, Pawel Wieczorkiewicz wrote: This series introduces new features to the livepatch functionality as briefly discussed during Xen Developer Summit 2019: [a] and [b]. It also provides a few fixes and some small improvements. Main changes in v2: - added new features to livepatch documentation - added livepatch tests - enabled Arm support for [5] - make .modinfo optional for [11] - fixed typos FEATURES: 1. independent modules (patches: [1], [2]) * livepatch-build-tools repo dependency [A] Livepatch enforces the following buildid-based dependency chain between hotpatch modules: 1) first module depends on given hypervisor buildid 2) every consecutive module depends on previous module's buildid This way proper hotpatch stack order is maintained and enforced. While it is important for production hotpatches it limits agility and blocks usage of testing or debug hotpatches. These kinds of hotpatch modules are typically expected to be loaded at any time irrespective of current state of the modules stack. [A] livepatch-build: Embed hypervisor build id into every hotpatch 2. pre- and post- apply|revert actions hooks (patches: [3], [4]) * livepatch-build-tools repo dependency [B] This is an implementation of 4 new livepatch module vetoing hooks, that can be optionally supplied along with modules. Hooks that currently exists in the livepatch mechanism aren't agile enough and have various limitations: * run only from within a quiescing zone * cannot conditionally prevent applying or reverting * do not have access to the module context To address these limitations the following has been implemented: 1) pre-apply hook 2) post-apply hook 3) pre-revert hook 4) post-revert hook [B] create-diff-object: Handle extra pre-|post- hooks 3. apply|revert actions replacement hooks (patches: [5], [6], [7]) * livepatch-build-tools repo dependency: [C], [D], [E] To increase hotpatching system's agility and provide more flexiable long-term hotpatch solution, allow to overwrite the default apply and revert action functions with hook-like supplied alternatives. The alternative functions are optional and the default functions are used by default. [C] create-diff-object: Do not create empty .livepatch.funcs section [D] create-diff-object: Handle optional apply|revert hooks [E] create-diff-object: Add support for applied/reverted marker 4. inline asm hotpatching expectations (patches: [8]) * livepatch-build-tools repo dependency: [F] Expectations are designed as optional feature, since the main use of them is planned for inline asm hotpatching. The payload structure is modified as each expectation structure is part of the livepatch_func structure and hence extends the payload. The payload version is bumped to 3 with this change to highlight the ABI modification and enforce proper support. The expectation is manually enabled during inline asm module construction. If enabled, expectation ensures that the expected content of memory is to be found at a given patching (old_addr) location. [F] create-diff-object: Add support for expectations 5. runtime hotpatch metadata support (patches: [9], [10], [11]) Having detailed hotpatch metadata helps to properly identify module's origin and version. It also allows to keep track of the history of hotpatch loads in the system (at least within dmesg buffer size limits). Extend the livepatch list operation to fetch also payloads' metadata. This is achieved by extending the sysctl list interface with 2 extra guest handles: * metadata - an array of arbitrary size strings * metadata_len - an array of metadata strings' lengths (uin32_t each) To unify and simplify the interface, handle the modules' name strings of arbitrary size by copying them in adhering chunks to the userland. 6. python bindings for livepatch operations (patches: [12]) Extend the XC python bindings library to support all common livepatch operations and actions: - status (pyxc_livepatch_status): - action (pyxc_livepatch_action): - upload (pyxc_livepatch_upload): - list (pyxc_livepatch_list): [a] https://wiki.xenproject.org/wiki/Design_Sessions_2019#LivePatch_improvements_and_features [b] https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg00846.html Merged in v1: python: Add XC binding for Xen build ID livepatch: always print XENLOG_ERR information Pawel Wieczorkiewicz (12): [1] livepatch: Always check hypervisor build ID upon hotpatch upload [2] livepatch: Allow to override inter-modules buildid dependency [3] livepatch: Export payload structure via livepatch_payload.h [4] livepatch: Implement pre-|post-
Re: [Xen-devel] [PATCH] xen/pci: try to reserve MCFG areas earlier
On 9/3/19 8:20 PM, Igor Druzhinin wrote: > If MCFG area is not reserved in E820, Xen by default will defer its usage > until Dom0 registers it explicitly after ACPI parser recognizes it as > a reserved resource in DSDT. Having it reserved in E820 is not > mandatory according to "PCI Firmware Specification, rev 3.2" (par. 4.1.2) > and firmware is free to keep a hole E820 in that place. Xen doesn't know > what exactly is inside this hole since it lacks full ACPI view of the > platform therefore it's potentially harmful to access MCFG region > without additional checks as some machines are known to provide > inconsistent information on the size of the region. > > Now xen_mcfg_late() runs after acpi_init() which is too late as some basic > PCI enumeration starts exactly there. Trying to register a device prior > to MCFG reservation causes multiple problems with PCIe extended > capability initializations in Xen (e.g. SR-IOV VF BAR sizing). There are > no convenient hooks for us to subscribe to so try to register MCFG > areas earlier upon the first invocation of xen_add_device(). Where is MCFG parsed? pci_arch_init()? -boris > Keep the > existing initcall in case information of MCFG areas is updated later > in acpi_init(). > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 141076: regressions - trouble: blocked/broken/fail/pass
flight 141076 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/141076/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win10-i386 broken test-amd64-i386-xl-qemuu-win10-i386 4 host-install(4) broken REGR. vs. 133580 test-amd64-i386-examine 8 reboot fail REGR. vs. 133580 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 133580 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 133580 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-xl-pvshim 15 guest-saverestorefail REGR. vs. 133580 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 133580 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 133580 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 133580 test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 133580 build-armhf-pvops 6 kernel-build fail REGR. vs. 133580 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-examine 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-boot fail baseline untested test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-boot fail baseline untested test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133580 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133580 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 133580 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133580 test-amd64-amd64-libvirt-xsm 13 migrate-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-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 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-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14
[Xen-devel] [freebsd-master test] 141086: regressions - trouble: blocked/fail
flight 141086 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/141086/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 141004 Tests which did not succeed, but are not blocking: build-amd64-xen-freebsd 1 build-check(1) blocked n/a build-amd64-freebsd-again 1 build-check(1) blocked n/a version targeted for testing: freebsd 3a2c285092d73635e4e1c74448bb900c984fa487 baseline version: freebsd a3dbacfc31a3c2ef7d9d4d12d4e5108f044c0701 Last test of basis 141004 2019-09-04 09:20:13 Z2 days Testing same since 141086 2019-09-06 09:21:33 Z0 days1 attempts People who touched revisions under test: 0mp <0...@freebsd.org> adrian avg bcran bdrewery br cem cy emaste hselasky ian imp jgh jhibbits jilles kevans kib kp manu mjg philip rmacklem scottph sevan stevek trasz tsoome jobs: build-amd64-freebsd-againblocked build-amd64-freebsd fail build-amd64-xen-freebsd blocked 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 pushing. (No revision log; it would be 884 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 141097: tolerable all pass - PUSHED
flight 141097 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/141097/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 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-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass version targeted for testing: xen 74791511067aaff67efbd2555a5f635246264453 baseline version: xen aae639bc538778f4bf44f3f50d03e376f82108bb Last test of basis 141092 2019-09-06 14:00:50 Z0 days Testing same since 141097 2019-09-06 17:00:57 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Bandan Das Jan Beulich Roger Pau Monné Zhang Rui 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 aae639bc53..7479151106 74791511067aaff67efbd2555a5f635246264453 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 141081: regressions - FAIL
flight 141081 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/141081/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 141033 test-armhf-armhf-libvirt16 guest-start/debian.repeat fail REGR. vs. 141033 test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs. 141033 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 141033 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 141033 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-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 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 14 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-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass version targeted for testing: libvirt f709377301b919a9fcbfc366e33057f7848bee28 baseline version: libvirt 267699a03cc38810dcd40f4ddbf864bd0dc29d4e Last test of basis 141033 2019-09-05 04:22:27 Z1 days Testing same since 141081 2019-09-06 04:19:01 Z0 days1 attempts People who touched revisions under test: Jiri Denemark jobs: build-amd64-xsm fail 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 blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt fail 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 pushing. commit
Re: [Xen-devel] Running xenstored in Linux stubdom
On Wed, Sep 4, 2019 at 1:26 PM Daniel Smith wrote:
>
> On Wed, Sep 4, 2019 at 12:12 PM Juergen Gross wrote:
> >
> > The stubdom gets an event channel to use for dom0 xenbstore connection
> > via commandline parameter ("--event "). This needs to be used
> > in the stubdom for setting up the communication path.
> >
> >
> > Juergen
>
> Hi Juergen,
>
> Thanks for the quick response! tracing through xenstored, looks like
> that flag sets the variable dom0_event which is only used in the
> xenstored_minios.c as the return value to the xenbus_evtchn() call. I
> could naively short circuit xenbus_evtchn() under xenstored_posix.c to
> return immediately if dom0_event has been set. If that works, I would
> be glad to submit it back upstream if there is interest in
> incorporating it.
Hi again,
I made the change to short circuit the xenbus_evtchn and did testing
as a guest domain approach to confirm that i was parsing the
parameters correctly in initramfs script that init-xenstore-helper
passed. I am still it hanging after the attempt to write
/tool/xenstored/domid. At this point I was wondering if there might be
a way to get console output from the domain to try and troubleshoot if
xenstored is getting started when actually running as the actual
stubdom instead of as a guest?
Thanks in Advance!
Daniel P. Smith
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] ARM: xen: unexport HYPERVISOR_platform_op function
On 06/09/2019 17:00, Arnd Bergmann wrote:
> On Fri, Sep 6, 2019 at 5:55 PM Andrew Cooper
> wrote:
>> On 06/09/2019 16:39, Arnd Bergmann wrote:
>>> HYPERVISOR_platform_op() is an inline function and should not
>>> be exported. Since commit 15bfc2348d54 ("modpost: check for
>>> static EXPORT_SYMBOL* functions"), this causes a warning:
>>>
>>> WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
>>>
>>> Remove the extraneous export.
>>>
>>> Fixes: 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions")
>>> Signed-off-by: Arnd Bergmann
>> Something is wonky. That symbol is (/ really ought to be) in the
>> hypercall page and most definitely not inline.
>>
>> Which tree is that changeset from? I can't find the SHA.
> This is from linux-next, I think from the kbuild tree.
Thanks.
Julien/Stefano: Why are any of these hypercalls out-of-line? ARM
doesn't use the hypercall page, and there is no argument translation
(not even in arm32 as there are no 5-argument hypercalls declared).
They'd surely be easier to implement with a few static inlines and some
common code, than to try and replicate the x86 side hypercall_page
interface ?
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [ANNOUNCE] Xen 4.13 Development Update
> == Hypervisor == > > * Per-cpu tasklet > - XEN-28 > - Konrad Rzeszutek Wilk I haven't gotten to them since the posting three years ago? I don't think I will get to them anytime soom too :-( Would love if someone took them over.. P.S: http://xenbits.xen.org/gitweb/?p=people/konradwilk/xen.git;a=shortlog;h=refs/heads/percpu_tasklet.v4.8.v2 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 141092: tolerable all pass - PUSHED
flight 141092 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/141092/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 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-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass version targeted for testing: xen aae639bc538778f4bf44f3f50d03e376f82108bb baseline version: xen d2a95f1c3ef96f47840ab172278293e55c4fc430 Last test of basis 141068 2019-09-05 23:01:32 Z0 days Testing same since 141092 2019-09-06 14:00:50 Z0 days1 attempts People who touched revisions under test: Andrew Cooper 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 d2a95f1c3e..aae639bc53 aae639bc538778f4bf44f3f50d03e376f82108bb -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [ANNOUNCE] Xen 4.13 Development Update
On 06/09/2019 08:40, Juergen Gross wrote: > This email only tracks big items for xen.git tree. Please reply for items you > would like to see in 4.13 so that people have an idea what is going on and > prioritise accordingly. > > You're welcome to provide description and use cases of the feature you're > working on. > > = Timeline = > > We now adopt a fixed cut-off date scheme. We will release about every 8 > months. > The upcoming 4.13 timeline are as followed: > > * Last posting date: September 13th, 2019 > * Hard code freeze: September 27th, 2019 > * RC1: TBD > * Release: November 7th, 2019 Wow this has crept up suddenly... I'm going to braindump my "needs to be done for 4.13" list. Before code freeze: 1) Refresh and repost MSR_VIRT_SPEC_CTRL. Still very important for perf on AMD Fam17h hardware. 2) Put together the "skeleton set_cpu_policy" plan. This will help to unblock some of the CPUID/MSR work, and will allow us to take (/backport) MSR_ARCH_CAPS support, which is very critical for perf on Intel Cascade Lake hardware. 2a) Stretch goal. See about getting MSR_ARCH_CAPS working. More likely to be early in the 4.14 dev cycle and backport for 4.13.1 3) Stretch goal. Dust off the domain_crash() changes which have been pending for a couple of releases now. Blockers: 1) L1TF_BARRIER mode. What we have currently in tree takes a perf hit while providing 0 security and breaking the ability to build livepatches against 4.13. My plan here is to put it behind an off-by-default Kconfig option. 2) Get the Sphinx docs licensed as CC-BY, seeing as this is the first release with them in. Misc ought-to-haves: 1) Refresh and repost the "Introduction" and "wishlist" docs. 2) Post the conversion of xen-command-line.pandoc to sphinx which I've been carrying locally rather too long now. This should get the sphinx docs into a state of having several useful bits in, even though we haven't moved over wholesale yet. I've probably missed some things, but this should do for now. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] ARM: xen: unexport HYPERVISOR_platform_op function
On Fri, Sep 6, 2019 at 5:55 PM Andrew Cooper wrote:
>
> On 06/09/2019 16:39, Arnd Bergmann wrote:
> > HYPERVISOR_platform_op() is an inline function and should not
> > be exported. Since commit 15bfc2348d54 ("modpost: check for
> > static EXPORT_SYMBOL* functions"), this causes a warning:
> >
> > WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
> >
> > Remove the extraneous export.
> >
> > Fixes: 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions")
> > Signed-off-by: Arnd Bergmann
>
> Something is wonky. That symbol is (/ really ought to be) in the
> hypercall page and most definitely not inline.
>
> Which tree is that changeset from? I can't find the SHA.
This is from linux-next, I think from the kbuild tree.
Arnd
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] ARM: xen: unexport HYPERVISOR_platform_op function
On 06.09.2019 17:55, Andrew Cooper wrote:
> On 06/09/2019 16:39, Arnd Bergmann wrote:
>> HYPERVISOR_platform_op() is an inline function and should not
>> be exported. Since commit 15bfc2348d54 ("modpost: check for
>> static EXPORT_SYMBOL* functions"), this causes a warning:
>>
>> WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
>>
>> Remove the extraneous export.
>>
>> Fixes: 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions")
>> Signed-off-by: Arnd Bergmann
>
> Something is wonky. That symbol is (/ really ought to be) in the
> hypercall page and most definitely not inline.
It's HYPERVISOR_platform_op_raw that's in the hypercall page afaics.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] ARM: xen: unexport HYPERVISOR_platform_op function
On 06/09/2019 16:39, Arnd Bergmann wrote:
> HYPERVISOR_platform_op() is an inline function and should not
> be exported. Since commit 15bfc2348d54 ("modpost: check for
> static EXPORT_SYMBOL* functions"), this causes a warning:
>
> WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
>
> Remove the extraneous export.
>
> Fixes: 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions")
> Signed-off-by: Arnd Bergmann
Something is wonky. That symbol is (/ really ought to be) in the
hypercall page and most definitely not inline.
Which tree is that changeset from? I can't find the SHA.
I hate to open a separate can of worms, but why are they tagged GPL?
The Xen hypercall ABI, like the Linux syscall ABI, are specifically not
GPL. Xen has as something very similar to (and probably derived from)
the Linux-syscall-note exception.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.14 test] 141071: regressions - FAIL
flight 141071 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/141071/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 140979 REGR. vs. 139910 build-amd64-xsm 6 xen-build fail in 141045 REGR. vs. 139910 build-amd64 6 xen-build fail in 141045 REGR. vs. 139910 Tests which are failing intermittently (not blocking): test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail in 140979 pass in 141071 test-amd64-amd64-xl-pvshim 17 guest-saverestore.2 fail in 141009 pass in 140979 test-amd64-amd64-xl-pvhv2-amd 7 xen-boot fail pass in 141009 test-amd64-amd64-xl-pvshim 12 guest-startfail pass in 141009 test-armhf-armhf-libvirt 19 leak-check/check fail pass in 141045 Tests which did not succeed, but are not blocking: test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked in 141045 n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked in 141045 n/a test-amd64-amd64-xl-qemut-win10-i386 1 build-check(1) blocked in 141045 n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked in 141045 n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked in 141045 n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked in 141045 n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked in 141045 n/a test-amd64-i386-xl-xsm1 build-check(1) blocked in 141045 n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked in 141045 n/a test-amd64-i386-xl-qemut-win10-i386 1 build-check(1)blocked in 141045 n/a build-amd64-libvirt 1 build-check(1) blocked in 141045 n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1)blocked in 141045 n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1)blocked in 141045 n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked in 141045 n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked in 141045 n/a test-amd64-amd64-libvirt 1 build-check(1) blocked in 141045 n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked in 141045 n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked in 141045 n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked in 141045 n/a test-amd64-amd64-pygrub 1 build-check(1) blocked in 141045 n/a test-amd64-i386-freebsd10-amd64 1 build-check(1)blocked in 141045 n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1)blocked in 141045 n/a test-amd64-i386-xl1 build-check(1) blocked in 141045 n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked in 141045 n/a test-amd64-i386-pair 1 build-check(1) blocked in 141045 n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked in 141045 n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked in 141045 n/a test-amd64-amd64-xl 1 build-check(1) blocked in 141045 n/a test-amd64-amd64-xl-qemuu-win10-i386 1 build-check(1) blocked in 141045 n/a test-amd64-amd64-examine 1 build-check(1) blocked in 141045 n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 141045 n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1)blocked in 141045 n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked in 141045 n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1)blocked in 141045 n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1)blocked in 141045 n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked in 141045 n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked in 141045 n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 141045 n/a test-amd64-i386-examine 1 build-check(1) blocked in 141045 n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked in 141045 n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked in 141045 n/a test-amd64-amd64-pair 1 build-check(1) blocked in 141045 n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked in 141045 n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked in 141045 n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked in 141045 n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked in 141045 n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 141045 n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1)blocked in 141045 n/a test-amd64-i386-libvirt 1 build-check(1) blocked in 141045 n/a
Re: [Xen-devel] [PATCH v2] x86/cpuid: Extend the cpuid= option to support all named features
On 06.09.2019 17:27, Andrew Cooper wrote:
> On 06/09/2019 16:18, Jan Beulich wrote:
>> On 05.09.2019 21:49, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpuid.c
>>> +++ b/xen/arch/x86/cpuid.c
>>> @@ -21,45 +21,62 @@ static const uint32_t deep_features[] =
>>> INIT_DEEP_FEATURES;
>>>
>>> static int __init parse_xen_cpuid(const char *s)
>>> {
>>> +static const struct feature {
>>> +const char *name;
>>> +unsigned int bit;
>>> +} features[] __initconst = INIT_FEATURE_NAMES, *lhs, *mid, *rhs;
>> The pointer field want this to use __initconstrel.
>
> Ok.
>
>> And I don't think you mean lhs, mid, and rhs to also be static?
>
> No - not intentional.
>
>> Albeit ...
>>
>>> const char *ss;
>>> int val, rc = 0;
>>>
>>> do {
>>> +const char *feat;
>>> +
>>> ss = strchr(s, ',');
>>> if ( !ss )
>>> ss = strchr(s, '\0');
>>>
>>> -if ( (val = parse_boolean("md-clear", s, ss)) >= 0 )
>>> -{
>>> -if ( !val )
>>> -setup_clear_cpu_cap(X86_FEATURE_MD_CLEAR);
>>> -}
>>> -else if ( (val = parse_boolean("ibpb", s, ss)) >= 0 )
>>> -{
>>> -if ( !val )
>>> -setup_clear_cpu_cap(X86_FEATURE_IBPB);
>>> -}
>>> -else if ( (val = parse_boolean("ibrsb", s, ss)) >= 0 )
>>> -{
>>> -if ( !val )
>>> -setup_clear_cpu_cap(X86_FEATURE_IBRSB);
>>> -}
>>> -else if ( (val = parse_boolean("stibp", s, ss)) >= 0 )
>>> -{
>>> -if ( !val )
>>> -setup_clear_cpu_cap(X86_FEATURE_STIBP);
>>> -}
>>> -else if ( (val = parse_boolean("l1d-flush", s, ss)) >= 0 )
>>> -{
>>> -if ( !val )
>>> -setup_clear_cpu_cap(X86_FEATURE_L1D_FLUSH);
>>> -}
>>> -else if ( (val = parse_boolean("ssbd", s, ss)) >= 0 )
>>> +/* Skip the 'no-' prefix for name comparisons. */
>>> +feat = s;
>>> +if ( strncmp(s, "no-", 3) == 0 )
>>> +feat += 3;
>>> +
>>> +/* (Re)initalise lhs and rhs for binary search. */
>>> +lhs = features;
>>> +rhs = features + ARRAY_SIZE(features);
>> ... the comment here suggests you do, but I don't currently see why.
>
> We are inside a do { } () while loop, parsing something such as
> cpuid=avx512,ss,smx
>
> The binary search over the feature names needs to start again from
> scratch for each new cpuid= list item.
>
> Otherwise, the while ( lhs < rhs ) binary search will never be entered
> for the second cpuid= item.
In which case, why don't you move the three variables into the do/while
scope? Anyway, with the annotation correction and the variables non-
static (in whichever scope)
Reviewed-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8] x86/emulate: Send vm_event from emulate
On 03.09.2019 16:01, Alexandru Stefan ISAILA wrote:
> A/D bit writes (on page walks) can be considered benign by an introspection
> agent, so receiving vm_events for them is a pessimization. We try here to
> optimize by filtering these events out.
> Currently, we are fully emulating the instruction at RIP when the hardware
> sees
> an EPT fault with npfec.kind != npfec_kind_with_gla. This is, however,
> incorrect, because the instruction at RIP might legitimately cause an
> EPT fault of its own while accessing a _different_ page from the original one,
> where A/D were set.
> The solution is to perform the whole emulation, while ignoring EPT
> restrictions
> for the walk part, and taking them into account for the "actual" emulating of
> the instruction at RIP. When we send out a vm_event, we don't want the
> emulation
> to complete, since in that case we won't be able to veto whatever it is doing.
> That would mean that we can't actually prevent any malicious activity, instead
> we'd only be able to report on it.
> When we see a "send-vm_event" case while emulating, we need to first send the
> event out and then suspend the emulation (return X86EMUL_RETRY).
> After the emulation stops we'll call hvm_vm_event_do_resume() again after the
> introspection agent treats the event and resumes the guest. There, the
> instruction at RIP will be fully emulated (with the EPT ignored) if the
> introspection application allows it, and the guest will continue to run past
> the instruction.
>
> A common example is if the hardware exits because of an EPT fault caused by a
> page walk, p2m_mem_access_check() decides if it is going to send a vm_event.
> If the vm_event was sent and it would be treated so it runs the instruction
> at RIP, that instruction might also hit a protected page and provoke a
> vm_event.
>
> Now if npfec.kind != npfec_kind_with_gla and
> d->arch.monitor.inguest_pagefault_disabled
> is true then we are in the page walk case and we can do this emulation
> optimization
> and emulate the page walk while ignoring the EPT, but don't ignore the EPT
> for the
> emulation of the actual instruction.
Instead of comparing against npfec_kind_with_gla, wouldn't you
better compare against npfec_kind_in_gpt to positively identify
page table accesses by the guest? Both VMX and SVM may leave the
field at npfec_kind_unknown after all.
> In the first case we would have 2 EPT events, in the second case we would have
> 1 EPT event if the instruction at the RIP triggers an EPT event.
>
> We use hvmemul_map_linear_addr() to intercept r/w access and
> __hvm_copy() to intercept exec access.
>
> hvm_emulate_send_vm_event() can return false if there was no violation,
> if there was an error from monitor_traps() or p2m_get_mem_access().
> Returning false if p2m_get_mem_access() fails if the entry was not found
> in the EPT in which case it is unrestricted.
I'm afraid I can't interpret what the second sentence is supposed to
clarify.
> @@ -531,6 +533,72 @@ static int hvmemul_do_mmio_addr(paddr_t mmio_gpa,
> return hvmemul_do_io_addr(1, mmio_gpa, reps, size, dir, df, ram_gpa);
> }
>
> +/*
> + * Send memory access vm_events based on pfec. Returns true if the event was
> + * sent and false for p2m_get_mem_access() error, no violation and event send
> + * error. Assumes the caller will check arch.vm_event->send_event.
> + *
> + * NOTE: p2m_get_mem_access() can fail if the entry was not found in the EPT
> + * (in which case access to it is unrestricted, so no violations can occur).
> + * In this cases it is fine to continue the emulation.
> + */
> +bool hvm_emulate_send_vm_event(unsigned long gla, gfn_t gfn,
> + uint32_t pfec)
> +{
> +xenmem_access_t access;
> +vm_event_request_t req = {};
> +paddr_t gpa = (gfn_to_gaddr(gfn) | (gla & ~PAGE_MASK));
> +
> +ASSERT(current->arch.vm_event->send_event);
> +
> +current->arch.vm_event->send_event = false;
> +
> +if ( p2m_get_mem_access(current->domain, gfn, ,
> +altp2m_vcpu_idx(current)) != 0 )
> +return false;
> +
> +switch ( access )
> +{
> +case XENMEM_access_x:
> +case XENMEM_access_rx:
> +if ( pfec & PFEC_write_access )
> +req.u.mem_access.flags = MEM_ACCESS_R | MEM_ACCESS_W;
> +break;
> +
> +case XENMEM_access_w:
> +case XENMEM_access_rw:
> +if ( pfec & PFEC_insn_fetch )
> +req.u.mem_access.flags = MEM_ACCESS_X;
> +break;
> +
> +case XENMEM_access_r:
> +case XENMEM_access_n:
> +if ( pfec & PFEC_write_access )
> +req.u.mem_access.flags |= MEM_ACCESS_R | MEM_ACCESS_W;
> +if ( pfec & PFEC_insn_fetch )
> +req.u.mem_access.flags |= MEM_ACCESS_X;
> +break;
> +
> +case XENMEM_access_wx:
> +case XENMEM_access_rwx:
> +case XENMEM_access_rx2rw:
> +case XENMEM_access_n2rwx:
> +case XENMEM_access_default:
> +break;
> +}
>
[Xen-devel] [PATCH] ARM: xen: unexport HYPERVISOR_platform_op function
HYPERVISOR_platform_op() is an inline function and should not
be exported. Since commit 15bfc2348d54 ("modpost: check for
static EXPORT_SYMBOL* functions"), this causes a warning:
WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
Remove the extraneous export.
Fixes: 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions")
Signed-off-by: Arnd Bergmann
---
arch/arm/xen/enlighten.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 1e57692552d9..845c528acf24 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -437,7 +437,6 @@ EXPORT_SYMBOL_GPL(HYPERVISOR_memory_op);
EXPORT_SYMBOL_GPL(HYPERVISOR_physdev_op);
EXPORT_SYMBOL_GPL(HYPERVISOR_vcpu_op);
EXPORT_SYMBOL_GPL(HYPERVISOR_tmem_op);
-EXPORT_SYMBOL_GPL(HYPERVISOR_platform_op);
EXPORT_SYMBOL_GPL(HYPERVISOR_multicall);
EXPORT_SYMBOL_GPL(HYPERVISOR_vm_assist);
EXPORT_SYMBOL_GPL(HYPERVISOR_dm_op);
--
2.20.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] Xen Project Code of Conduct
On 06/09/2019, 16:10, "Roger Pau Monne" wrote: On Wed, Sep 04, 2019 at 07:12:18PM +0100, Lars Kurth wrote: [...] > +## Conduct Team members > +Conduct Team members are project leadership team members from any > +sub-project. The current list of Conduct Team members is: > +* Lars Kurth > +* George Dunlap > +* Ian Jackson > + > +Conduct Team members are changed by proposing a change to this document, > +posted on all sub-project lists, followed by a formal global vote as outlined [here]: https://xenproject.org/developers/governance/#project-decisions Could you break the above line to match the existing line length of the document? Sure, I can do this in the next revision I intentionally didn't do line breaks on most changes to make sure that the differences can be seen Also, we will probably never publish this content anywhere but on the main website (as html generated from the MD) Lars ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/cpuid: Extend the cpuid= option to support all named features
On 06/09/2019 16:18, Jan Beulich wrote:
> On 05.09.2019 21:49, Andrew Cooper wrote:
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen/arch/x86/cpuid.c
>> @@ -21,45 +21,62 @@ static const uint32_t deep_features[] =
>> INIT_DEEP_FEATURES;
>>
>> static int __init parse_xen_cpuid(const char *s)
>> {
>> +static const struct feature {
>> +const char *name;
>> +unsigned int bit;
>> +} features[] __initconst = INIT_FEATURE_NAMES, *lhs, *mid, *rhs;
> The pointer field want this to use __initconstrel.
Ok.
> And I don't think you mean lhs, mid, and rhs to also be static?
No - not intentional.
> Albeit ...
>
>> const char *ss;
>> int val, rc = 0;
>>
>> do {
>> +const char *feat;
>> +
>> ss = strchr(s, ',');
>> if ( !ss )
>> ss = strchr(s, '\0');
>>
>> -if ( (val = parse_boolean("md-clear", s, ss)) >= 0 )
>> -{
>> -if ( !val )
>> -setup_clear_cpu_cap(X86_FEATURE_MD_CLEAR);
>> -}
>> -else if ( (val = parse_boolean("ibpb", s, ss)) >= 0 )
>> -{
>> -if ( !val )
>> -setup_clear_cpu_cap(X86_FEATURE_IBPB);
>> -}
>> -else if ( (val = parse_boolean("ibrsb", s, ss)) >= 0 )
>> -{
>> -if ( !val )
>> -setup_clear_cpu_cap(X86_FEATURE_IBRSB);
>> -}
>> -else if ( (val = parse_boolean("stibp", s, ss)) >= 0 )
>> -{
>> -if ( !val )
>> -setup_clear_cpu_cap(X86_FEATURE_STIBP);
>> -}
>> -else if ( (val = parse_boolean("l1d-flush", s, ss)) >= 0 )
>> -{
>> -if ( !val )
>> -setup_clear_cpu_cap(X86_FEATURE_L1D_FLUSH);
>> -}
>> -else if ( (val = parse_boolean("ssbd", s, ss)) >= 0 )
>> +/* Skip the 'no-' prefix for name comparisons. */
>> +feat = s;
>> +if ( strncmp(s, "no-", 3) == 0 )
>> +feat += 3;
>> +
>> +/* (Re)initalise lhs and rhs for binary search. */
>> +lhs = features;
>> +rhs = features + ARRAY_SIZE(features);
> ... the comment here suggests you do, but I don't currently see why.
We are inside a do { } () while loop, parsing something such as
cpuid=avx512,ss,smx
The binary search over the feature names needs to start again from
scratch for each new cpuid= list item.
Otherwise, the while ( lhs < rhs ) binary search will never be entered
for the second cpuid= item.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/cpuid: Extend the cpuid= option to support all named features
On 05.09.2019 21:49, Andrew Cooper wrote:
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -21,45 +21,62 @@ static const uint32_t deep_features[] =
> INIT_DEEP_FEATURES;
>
> static int __init parse_xen_cpuid(const char *s)
> {
> +static const struct feature {
> +const char *name;
> +unsigned int bit;
> +} features[] __initconst = INIT_FEATURE_NAMES, *lhs, *mid, *rhs;
The pointer field want this to use __initconstrel. And I don't think
you mean lhs, mid, and rhs to also be static? Albeit ...
> const char *ss;
> int val, rc = 0;
>
> do {
> +const char *feat;
> +
> ss = strchr(s, ',');
> if ( !ss )
> ss = strchr(s, '\0');
>
> -if ( (val = parse_boolean("md-clear", s, ss)) >= 0 )
> -{
> -if ( !val )
> -setup_clear_cpu_cap(X86_FEATURE_MD_CLEAR);
> -}
> -else if ( (val = parse_boolean("ibpb", s, ss)) >= 0 )
> -{
> -if ( !val )
> -setup_clear_cpu_cap(X86_FEATURE_IBPB);
> -}
> -else if ( (val = parse_boolean("ibrsb", s, ss)) >= 0 )
> -{
> -if ( !val )
> -setup_clear_cpu_cap(X86_FEATURE_IBRSB);
> -}
> -else if ( (val = parse_boolean("stibp", s, ss)) >= 0 )
> -{
> -if ( !val )
> -setup_clear_cpu_cap(X86_FEATURE_STIBP);
> -}
> -else if ( (val = parse_boolean("l1d-flush", s, ss)) >= 0 )
> -{
> -if ( !val )
> -setup_clear_cpu_cap(X86_FEATURE_L1D_FLUSH);
> -}
> -else if ( (val = parse_boolean("ssbd", s, ss)) >= 0 )
> +/* Skip the 'no-' prefix for name comparisons. */
> +feat = s;
> +if ( strncmp(s, "no-", 3) == 0 )
> +feat += 3;
> +
> +/* (Re)initalise lhs and rhs for binary search. */
> +lhs = features;
> +rhs = features + ARRAY_SIZE(features);
... the comment here suggests you do, but I don't currently see why.
I'd like to understand this though before giving an ack.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Criteria for checking in core scheduling series
On Fri, Sep 06, 2019 at 12:46:03PM +, Lars Kurth wrote: > > > On 06/09/2019, 12:09, "George Dunlap" wrote: > > There was a discussion on the community call about the core scheduling > series being developed by Juergen Gross [1]. The conclusion can be > summarized as follows: > > * We normally wait to check in series until they are quite good -- all > the i's dotted and all the t's crossed > > * This is for several reasons; primarily because once code gets checked > in, it rarely gets looked at again. In particular, there's nothing > stopping the submitter from neglecting to do important clean-ups, in > spite of their best intentions; leaving the maintainer or the rest of > the community to do it. > > * However, for particularly long, complicated series like the core > scheduling series, this can have significant downsides. Rebasing a > 60-patch branch regularly is a lot of churn for little value; and core > parts of the series which are mostly complete are currently only getting > sporadic dev testing rather than the wide range of testing they would > get from being in staging. > > * XenServer and SuSE are both long-term community members with a strong > incentive to maintain and improve the feature; so the risk of the > feature being left for the community to maintian is relatively now. > > With all those things in mind, the conclusion was to lower the > "check-in" threshold from what it normally is, in order to allow the > series to be checked in in the near future, in enough time at least for > the "default off" to be well-tested by the 4.13 release. > > The criteria we sketched out were: > > * All the patches still need appropriate Ack / R-b's > > * There should be reason to believe that the series will have little to > no impact on "thread mode" (threads being the unit of scheduling; i.e., > the status quo) > > WRT the second point, apparently XenServer have been testing the series > regularly for some time, and are satisfied from a testing perspective > that there is no significant degradation for the series when in "thread > mode". > > So this would really be a recommendation / license to the various > maintainers involved; primarily Dario, I think (since I probably won't > have time to review the series). > > No decisions are official until discussed on xen-devel; so the decision > will not be considered official until a few days have passed without > objection. And of course, if anyone at the meeting had a different > understanding of what was said, or has something to add, please do so. > > I believe the following people were on the community call and did NOT have > objections when asked > Sergey, Jan, Juergen, Andrew, George, Roger, Christopher Clark, Daniel P > Smith, Rich (list may be incomplete) I have no objection with this going in on the above terms. Thanks for writing this down. Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] Xen Project Code of Conduct
On Wed, Sep 04, 2019 at 07:12:18PM +0100, Lars Kurth wrote: [...] > +## Conduct Team members > +Conduct Team members are project leadership team members from any > +sub-project. The current list of Conduct Team members is: > +* Lars Kurth > +* George Dunlap > +* Ian Jackson > + > +Conduct Team members are changed by proposing a change to this document, > +posted on all sub-project lists, followed by a formal global vote as > outlined [here]: > https://xenproject.org/developers/governance/#project-decisions Could you break the above line to match the existing line length of the document? Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/2] Code of Conduct (based on Contributor Covenant v1.4)
On Wed, Sep 04, 2019 at 07:12:16PM +0100, Lars Kurth wrote: > This series proposes a concrete version of the Xen Project > CoC based on v1.4 of the Contributor Covenant. See [1] > > It also reflects the discussion in [2] and some private > discussions on IRC to identify initial members of the Xen > Project’s CoC team. > > For convenence of review and in line with other policy documents > I created a git repository at [3]. This series can be found at [5]. > > The series is incomplete in that it does not yet contain the document > on positive behavior: this will be based on [4]. My intention is to > use a lightwight process based on > * Documentation to set expectations, share tips and best practices - with the > hope that people in the community reflect occasionally on how they are doing > against these (or are maybe prompted by peers to do so) > * A safe back-channel to ask for advice when a conversation becomes > inefficient, > unactionable, is unfriendly, ... with a view to recover it > * Arbitration in cases where there is some friction amongst participants in a > discussion, which was not resolvable by any of the before. After all, when > this > happens there is a risk that a working relationship gets negatively impacted. > It > is actually in the interest of each participant to improve to avoid friction, > stress, etc. > > I hope that we can approve the series without the first part, but I do not > mind > if people feel this needs to be done in one go. The current document LGTM, I just have one style nit. Thanks for doing this! ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 09/11] swiotlb-xen: simplify cache maintainance
On 9/6/19 10:43 AM, Konrad Rzeszutek Wilk wrote: > On Fri, Sep 06, 2019 at 10:19:01AM -0400, Boris Ostrovsky wrote: >> On 9/6/19 10:01 AM, Christoph Hellwig wrote: >>> On Fri, Sep 06, 2019 at 09:52:12AM -0400, Boris Ostrovsky wrote: We need nop definitions of these two for x86. Everything builds now but that's probably because the calls are under 'if (!dev_is_dma_coherent(dev))' which is always false so compiler optimized is out. I don't think we should rely on that. >>> That is how a lot of the kernel works. Provide protypes only for code >>> that is semantically compiled, but can't ever be called due to >>> IS_ENABLED() checks. It took me a while to get used to it, but it >>> actually is pretty nice as the linker does the work for you to check >>> that it really is never called. Much better than say a BUILD_BUG_ON(). >> >> (with corrected Juergen's email) >> >> I know about IS_ENABLED() but I didn't realize that this is allowed for >> compile-time inlines and such as well. >> >> Anyway, for non-ARM bits >> >> Reviewed-by: Boris Ostrovsky > Acked-by: Konrad Rzeszutek Wilk > > as well. > > Albeit folks have tested this under x86 Xen with 'swiotlb=force' right? Yes, I did. -boris > > I can test it myself but it will take a couple of days. >> If this goes via Xen tree then the first couple of patches need an ack >> from ARM maintainers. >> >> -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 09/11] swiotlb-xen: simplify cache maintainance
On Fri, Sep 06, 2019 at 10:19:01AM -0400, Boris Ostrovsky wrote: > On 9/6/19 10:01 AM, Christoph Hellwig wrote: > > On Fri, Sep 06, 2019 at 09:52:12AM -0400, Boris Ostrovsky wrote: > >> We need nop definitions of these two for x86. > >> > >> Everything builds now but that's probably because the calls are under > >> 'if (!dev_is_dma_coherent(dev))' which is always false so compiler > >> optimized is out. I don't think we should rely on that. > > That is how a lot of the kernel works. Provide protypes only for code > > that is semantically compiled, but can't ever be called due to > > IS_ENABLED() checks. It took me a while to get used to it, but it > > actually is pretty nice as the linker does the work for you to check > > that it really is never called. Much better than say a BUILD_BUG_ON(). > > > (with corrected Juergen's email) > > I know about IS_ENABLED() but I didn't realize that this is allowed for > compile-time inlines and such as well. > > Anyway, for non-ARM bits > > Reviewed-by: Boris Ostrovsky Acked-by: Konrad Rzeszutek Wilk as well. Albeit folks have tested this under x86 Xen with 'swiotlb=force' right? I can test it myself but it will take a couple of days. > > If this goes via Xen tree then the first couple of patches need an ack > from ARM maintainers. > > -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/2] sysctl/libxl: choose a sane default for HAP
On 06/09/2019 15:30, Roger Pau Monne wrote: > Current libxl code will always enable Hardware Assisted Paging (HAP), > expecting that the hypervisor will fallback to shadow if HAP is not > available. With the changes to the domain builder that's not the case "domain builder" is usually libxenguest. I'd suggest using DOMCTL_createdomain specifically to make it obvious that it was a hypervisor side change. otherwise, everything LGTM. This should probably be adjusted on commit. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] IOMMU/x86: make page type checks consistent when mapping pages
On Fri, Sep 06, 2019 at 04:19:50PM +0200, Jan Beulich wrote:
> On 06.09.2019 16:08, Roger Pau Monné wrote:
> > On Fri, Sep 06, 2019 at 02:08:09PM +0200, Jan Beulich wrote:
> >> On 06.09.2019 13:45, Roger Pau Monné wrote:
> >>> On Fri, Sep 06, 2019 at 12:52:11PM +0200, Jan Beulich wrote:
> On 06.09.2019 11:37, Roger Pau Monné wrote:
> > On Wed, Jul 03, 2019 at 12:18:45PM +, Jan Beulich wrote:
> >> --- a/xen/arch/x86/mm/p2m.c
> >> +++ b/xen/arch/x86/mm/p2m.c
> >> @@ -829,13 +829,13 @@ guest_physmap_add_page(struct domain *d,
> >>*
> >>* Retain this property by grabbing a writable type ref and
> >> then
> >>* dropping it immediately. The result will be pages that
> >> have a
> >> - * writable type (and an IOMMU entry), but a count of 0 (such
> >> that
> >> - * any guest-requested type changes succeed and remove the
> >> IOMMU
> >> - * entry).
> >> + * writable type (and an IOMMU entry if necessary), but a
> >> count of 0
> >> + * (such that any guest-requested type changes succeed and
> >> remove the
> >> + * IOMMU entry).
> >>*/
> >> for ( i = 0; i < (1UL << page_order); ++i, ++page )
> >> {
> >> -if ( !need_iommu_pt_sync(d) )
> >> +if ( !iommu_enabled )
> >
> > That's kind of a strong check for a domain that might never use the
> > iommu at all. Isn't it fine to just rely on
> > arch_iommu_populate_page_table finding non-writable pages and thus not
> > adding them to the iommu page-tables?
>
> No - the code change here is to take care of page additions to
> the domain after it has booted.
> >>>
> >>> Please bear with me, but AFAICT arch_iommu_populate_page_table could
> >>> be used after the domain has booted if a pci device is hot plugged.
> >>>
> >>> If this is to deal with additions to domains having an iommu already
> >>> enabled, isn't it enough to use need_iommu_pt_sync?
> >>>
> >>> That's going to return true for all PV domains, except for dom0 not
> >>> running in strict mode, which is expected because in that case dom0
> >>> already has the whole RAM mapped into the iommu page-tables?
> >>
> >> Well, my previous reply wasn't precise enough, I guess. The change
> >> really is about both cases: If the domain is already using an IOMMU,
> >> need_iommu_pt_sync() would be enough indeed. If IOMMU use _may_ be
> >> enabled later on, we need to transition pages out of their initial
> >> PGT_none state right away. If we deferred this until the point
> >> where the IOMMU gets enabled for the domain, we'd have to watch out
> >> for PGT_none pages there, which would be extra hassle.
> >
> > I still think a relaxed PV dom0 should avoid the overhead of
> > get_page_and_type, and the iommu flush done afterwards, as it already
> > has all host RAM into it's iommu page-tables.
> >
> > Ie: I think the check should be something like:
> >
> > if ( !iommu_enabled ||
> > (is_hardware_domain(d) && !need_iommu_pt_sync(d) )
>
> Ah, yes, I can certainly do this (if the patch doesn't become
> unnecessary anyway).
With that please add my Reviewed-by: Roger Pau Monné
, albeit as you say I'm not sure whether this is
really needed in light of the upcoming iommu changes.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 2/2] sysctl/libxl: choose a sane default for HAP
Current libxl code will always enable Hardware Assisted Paging (HAP),
expecting that the hypervisor will fallback to shadow if HAP is not
available. With the changes to the domain builder that's not the case
any longer, and the hypervisor will raise an error if HAP is not
available instead of silently falling back to shadow.
In order to keep the previous functionality report whether HAP is
available or not in XEN_SYSCTL_physinfo, so that the toolstack can
select a sane default if there's no explicit user selection of whether
HAP should be used.
Note that on ARM hardware HAP capability is always reported since it's
a required feature in order to run Xen.
Fixes: d0c0ba7d3de ('x86/hvm/domain: remove the 'hap_enabled' flag')
Signed-off-by: Roger Pau Monné
Reviewed-by: Paul Durrant
Acked-by: Jan Beulich
---
Cc: Paul Durrant
---
Changes since v2:
- Add a LIBXL_HAVE_PHYSINFO_CAP_HAP for compatibility.
Changes since v1:
- Also report HAP capability for ARM.
- Print hap capability in xl info.
---
tools/libxl/libxl.c | 1 +
tools/libxl/libxl.h | 7 +++
tools/libxl/libxl_create.c | 8 +++-
tools/libxl/libxl_types.idl | 1 +
tools/xl/xl_info.c | 5 +++--
xen/arch/arm/sysctl.c | 2 +-
xen/arch/x86/sysctl.c | 2 ++
xen/include/public/sysctl.h | 4
8 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index ec71574e99..5c0fcf320e 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -399,6 +399,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo
*physinfo)
physinfo->cap_pv = !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_pv);
physinfo->cap_hvm_directio =
!!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_directio);
+physinfo->cap_hap = !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_hap);
GC_FREE;
return 0;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 9bacfb97f0..3ff67792a7 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -394,6 +394,13 @@
*/
#define LIBXL_HAVE_EXTENDED_VKB 1
+/*
+ * LIBXL_HAVE_PHYSINFO_CAP_HAP indicates that libxl_physinfo has a cap_hap
+ * field that indicates whether the hardware supports Hardware Assisted
+ * Paging.
+ */
+#define LIBXL_HAVE_PHYSINFO_CAP_HAP 1
+
/*
* libxl ABI compatibility
*
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 03ce166f4f..6a556dea8f 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -38,7 +38,13 @@ int libxl__domain_create_info_setdefault(libxl__gc *gc,
libxl__arch_domain_create_info_setdefault(gc, c_info);
if (c_info->type != LIBXL_DOMAIN_TYPE_PV) {
-libxl_defbool_setdefault(_info->hap, true);
+libxl_physinfo info;
+int rc = libxl_get_physinfo(CTX, );
+
+if (rc)
+return rc;
+
+libxl_defbool_setdefault(_info->hap, info.cap_hap);
libxl_defbool_setdefault(_info->oos, true);
}
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index b61399ce36..9e1f8515d3 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -1025,6 +1025,7 @@ libxl_physinfo = Struct("physinfo", [
("cap_hvm", bool),
("cap_pv", bool),
("cap_hvm_directio", bool), # No longer HVM specific
+("cap_hap", bool),
], dir=DIR_OUT)
libxl_connectorinfo = Struct("connectorinfo", [
diff --git a/tools/xl/xl_info.c b/tools/xl/xl_info.c
index 46d9c9f712..aa6724bc7f 100644
--- a/tools/xl/xl_info.c
+++ b/tools/xl/xl_info.c
@@ -210,11 +210,12 @@ static void output_physinfo(void)
info.hw_cap[4], info.hw_cap[5], info.hw_cap[6], info.hw_cap[7]
);
-maybe_printf("virt_caps :%s%s%s%s\n",
+maybe_printf("virt_caps :%s%s%s%s%s\n",
info.cap_pv ? " pv" : "",
info.cap_hvm ? " hvm" : "",
info.cap_hvm && info.cap_hvm_directio ? " hvm_directio" : "",
- info.cap_pv && info.cap_hvm_directio ? " pv_directio" : ""
+ info.cap_pv && info.cap_hvm_directio ? " pv_directio" : "",
+ info.cap_hap ? " hap" : ""
);
vinfo = libxl_get_version_info(ctx);
diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
index 92ac99c928..f87944e847 100644
--- a/xen/arch/arm/sysctl.c
+++ b/xen/arch/arm/sysctl.c
@@ -14,7 +14,7 @@
void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
{
-pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
+pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm | XEN_SYSCTL_PHYSCAP_hap;
}
long arch_do_sysctl(struct xen_sysctl *sysctl,
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index 7ec6174e6b..5777a05ffc 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -163,6 +163,8 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
if ( IS_ENABLED(CONFIG_PV) )
pi->capabilities |= XEN_SYSCTL_PHYSCAP_pv;
+if (
[Xen-devel] [PATCH v3 0/2] libxl: choose a sane default for HAP
Hello, First patch is a preparatory change to also make use of the physcaps on ARM, second patch introduces a new physcap (HAP) in order for the toolstack to decide whether to use HAP if the user hasn't made a selection. Thanks, Roger. Roger Pau Monne (2): sysctl: report existing physcaps on ARM sysctl/libxl: choose a sane default for HAP tools/libxl/libxl.c | 1 + tools/libxl/libxl.h | 7 +++ tools/libxl/libxl_create.c | 8 +++- tools/libxl/libxl_types.idl | 1 + tools/xl/xl_info.c | 5 +++-- xen/arch/arm/sysctl.c | 5 - xen/arch/x86/sysctl.c | 4 ++-- xen/common/sysctl.c | 2 ++ xen/include/public/sysctl.h | 10 +++--- 9 files changed, 34 insertions(+), 9 deletions(-) -- 2.22.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 1/2] sysctl: report existing physcaps on ARM
Current physcaps in XEN_SYSCTL_physinfo are only used by x86, albeit
the capabilities themselves are not x86 specific.
This patch adds support for also reporting the current capabilities on
ARM hardware. Note that on ARM PHYSCAP_hvm is always reported, and
setting PHYSCAP_directio has been moved to common code since the same
logic to set it is used by x86 and ARM.
Signed-off-by: Roger Pau Monné
Reviewed-by: Paul Durrant
Acked-by: Jan Beulich
---
Changes since v1:
- New in this version.
---
xen/arch/arm/sysctl.c | 5 -
xen/arch/x86/sysctl.c | 2 --
xen/common/sysctl.c | 2 ++
xen/include/public/sysctl.h | 6 +++---
4 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
index fbfdb44eff..92ac99c928 100644
--- a/xen/arch/arm/sysctl.c
+++ b/xen/arch/arm/sysctl.c
@@ -12,7 +12,10 @@
#include
#include
-void arch_do_physinfo(struct xen_sysctl_physinfo *pi) { }
+void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
+{
+pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
+}
long arch_do_sysctl(struct xen_sysctl *sysctl,
XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index c50d910a1c..7ec6174e6b 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -163,8 +163,6 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
if ( IS_ENABLED(CONFIG_PV) )
pi->capabilities |= XEN_SYSCTL_PHYSCAP_pv;
-if ( iommu_enabled )
-pi->capabilities |= XEN_SYSCTL_PHYSCAP_directio;
}
long arch_do_sysctl(
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index fcf2d2fd7c..92b4ea0d21 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -267,6 +267,8 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t)
u_sysctl)
pi->cpu_khz = cpu_khz;
pi->max_mfn = get_upper_mfn_bound();
arch_do_physinfo(pi);
+if ( iommu_enabled )
+pi->capabilities |= XEN_SYSCTL_PHYSCAP_directio;
if ( copy_to_guest(u_sysctl, op, 1) )
ret = -EFAULT;
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 91c48dcae0..36b3f8c429 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -81,13 +81,13 @@ struct xen_sysctl_tbuf_op {
* Get physical information about the host machine
*/
/* XEN_SYSCTL_physinfo */
- /* (x86) The platform supports HVM guests. */
+ /* The platform supports HVM guests. */
#define _XEN_SYSCTL_PHYSCAP_hvm 0
#define XEN_SYSCTL_PHYSCAP_hvm (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
- /* (x86) The platform supports PV guests. */
+ /* The platform supports PV guests. */
#define _XEN_SYSCTL_PHYSCAP_pv 1
#define XEN_SYSCTL_PHYSCAP_pv(1u<<_XEN_SYSCTL_PHYSCAP_pv)
- /* (x86) The platform supports direct access to I/O devices with IOMMU. */
+ /* The platform supports direct access to I/O devices with IOMMU. */
#define _XEN_SYSCTL_PHYSCAP_directio 2
#define XEN_SYSCTL_PHYSCAP_directio (1u<<_XEN_SYSCTL_PHYSCAP_directio)
struct xen_sysctl_physinfo {
--
2.22.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] IOMMU/x86: make page type checks consistent when mapping pages
On 06.09.2019 16:08, Roger Pau Monné wrote:
> On Fri, Sep 06, 2019 at 02:08:09PM +0200, Jan Beulich wrote:
>> On 06.09.2019 13:45, Roger Pau Monné wrote:
>>> On Fri, Sep 06, 2019 at 12:52:11PM +0200, Jan Beulich wrote:
On 06.09.2019 11:37, Roger Pau Monné wrote:
> On Wed, Jul 03, 2019 at 12:18:45PM +, Jan Beulich wrote:
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -829,13 +829,13 @@ guest_physmap_add_page(struct domain *d,
>>*
>>* Retain this property by grabbing a writable type ref and
>> then
>>* dropping it immediately. The result will be pages that
>> have a
>> - * writable type (and an IOMMU entry), but a count of 0 (such
>> that
>> - * any guest-requested type changes succeed and remove the IOMMU
>> - * entry).
>> + * writable type (and an IOMMU entry if necessary), but a count
>> of 0
>> + * (such that any guest-requested type changes succeed and
>> remove the
>> + * IOMMU entry).
>>*/
>> for ( i = 0; i < (1UL << page_order); ++i, ++page )
>> {
>> -if ( !need_iommu_pt_sync(d) )
>> +if ( !iommu_enabled )
>
> That's kind of a strong check for a domain that might never use the
> iommu at all. Isn't it fine to just rely on
> arch_iommu_populate_page_table finding non-writable pages and thus not
> adding them to the iommu page-tables?
No - the code change here is to take care of page additions to
the domain after it has booted.
>>>
>>> Please bear with me, but AFAICT arch_iommu_populate_page_table could
>>> be used after the domain has booted if a pci device is hot plugged.
>>>
>>> If this is to deal with additions to domains having an iommu already
>>> enabled, isn't it enough to use need_iommu_pt_sync?
>>>
>>> That's going to return true for all PV domains, except for dom0 not
>>> running in strict mode, which is expected because in that case dom0
>>> already has the whole RAM mapped into the iommu page-tables?
>>
>> Well, my previous reply wasn't precise enough, I guess. The change
>> really is about both cases: If the domain is already using an IOMMU,
>> need_iommu_pt_sync() would be enough indeed. If IOMMU use _may_ be
>> enabled later on, we need to transition pages out of their initial
>> PGT_none state right away. If we deferred this until the point
>> where the IOMMU gets enabled for the domain, we'd have to watch out
>> for PGT_none pages there, which would be extra hassle.
>
> I still think a relaxed PV dom0 should avoid the overhead of
> get_page_and_type, and the iommu flush done afterwards, as it already
> has all host RAM into it's iommu page-tables.
>
> Ie: I think the check should be something like:
>
> if ( !iommu_enabled ||
> (is_hardware_domain(d) && !need_iommu_pt_sync(d) )
Ah, yes, I can certainly do this (if the patch doesn't become
unnecessary anyway).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 09/11] swiotlb-xen: simplify cache maintainance
On 9/6/19 10:01 AM, Christoph Hellwig wrote: > On Fri, Sep 06, 2019 at 09:52:12AM -0400, Boris Ostrovsky wrote: >> We need nop definitions of these two for x86. >> >> Everything builds now but that's probably because the calls are under >> 'if (!dev_is_dma_coherent(dev))' which is always false so compiler >> optimized is out. I don't think we should rely on that. > That is how a lot of the kernel works. Provide protypes only for code > that is semantically compiled, but can't ever be called due to > IS_ENABLED() checks. It took me a while to get used to it, but it > actually is pretty nice as the linker does the work for you to check > that it really is never called. Much better than say a BUILD_BUG_ON(). (with corrected Juergen's email) I know about IS_ENABLED() but I didn't realize that this is allowed for compile-time inlines and such as well. Anyway, for non-ARM bits Reviewed-by: Boris Ostrovsky If this goes via Xen tree then the first couple of patches need an ack from ARM maintainers. -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] sysctl/libxl: choose a sane default for HAP
On Fri, Sep 06, 2019 at 03:54:10PM +0200, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel On Behalf Of Paul
> > Durrant
> > Sent: 05 September 2019 14:52
> > To: Roger Pau Monne ; xen-devel@lists.xenproject.org
> > Cc: Stefano Stabellini ; Wei Liu ;
> > Konrad Rzeszutek Wilk
> > ; Andrew Cooper ; Tim
> > (Xen.org) ;
> > George Dunlap ; Julien Grall
> > ; Jan Beulich
> > ; Anthony Perard ; Ian
> > Jackson ;
> > Volodymyr Babchuk ; Roger Pau Monne
> >
> > Subject: Re: [Xen-devel] [PATCH v2 2/2] sysctl/libxl: choose a sane default
> > for HAP
> >
> > > -Original Message-
> > > From: Roger Pau Monne
> > > Sent: 05 September 2019 14:27
> > > To: xen-devel@lists.xenproject.org
> > > Cc: Roger Pau Monne ; Ian Jackson
> > > ; Wei Liu
> > > ; Anthony Perard ; Andrew Cooper
> > > ;
> > > George Dunlap ; Jan Beulich
> > > ; Julien Grall
> > > ; Konrad Rzeszutek Wilk ;
> > > Stefano Stabellini
> > > ; Tim (Xen.org) ; Volodymyr Babchuk
> > ;
> > > Paul Durrant
> > > Subject: [PATCH v2 2/2] sysctl/libxl: choose a sane default for HAP
> > >
> > > Current libxl code will always enable Hardware Assisted Paging (HAP),
> > > expecting that the hypervisor will fallback to shadow if HAP is not
> > > available. With the changes to the domain builder that's not the case
> > > any longer, and the hypervisor will raise an error if HAP is not
> > > available instead of silently falling back to shadow.
> > >
> > > In order to keep the previous functionality report whether HAP is
> > > available or not in XEN_SYSCTL_physinfo, so that the toolstack can
> > > select a sane default if there's no explicit user selection of whether
> > > HAP should be used.
> > >
> > > Note that on ARM hardware HAP capability is always reported since it's
> > > a required feature in order to run Xen.
> > >
> > > Fixes: d0c0ba7d3de ('x86/hvm/domain: remove the 'hap_enabled' flag')
> > > Signed-off-by: Roger Pau Monné
> >
> > LGTM
> >
> > Reviewed-by: Paul Durrant
> >
> > > ---
> > > Cc: Paul Durrant
> > > ---
> > > Changes since v1:
> > > - Also report HAP capability for ARM.
> > > - Print hap capability in xl info.
> > > ---
> > > tools/libxl/libxl.c | 1 +
> > > tools/libxl/libxl_create.c | 8 +++-
> > > tools/libxl/libxl_types.idl | 1 +
> > > tools/xl/xl_info.c | 5 +++--
> > > xen/arch/arm/sysctl.c | 2 +-
> > > xen/arch/x86/sysctl.c | 2 ++
> > > xen/include/public/sysctl.h | 4
> > > 7 files changed, 19 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > > index ec71574e99..5c0fcf320e 100644
> > > --- a/tools/libxl/libxl.c
> > > +++ b/tools/libxl/libxl.c
> > > @@ -399,6 +399,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo
> > > *physinfo)
> > > physinfo->cap_pv = !!(xcphysinfo.capabilities &
> > > XEN_SYSCTL_PHYSCAP_pv);
> > > physinfo->cap_hvm_directio =
> > > !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_directio);
> > > +physinfo->cap_hap = !!(xcphysinfo.capabilities &
> > > XEN_SYSCTL_PHYSCAP_hap);
> > >
> > > GC_FREE;
> > > return 0;
> > > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > > index 03ce166f4f..6a556dea8f 100644
> > > --- a/tools/libxl/libxl_create.c
> > > +++ b/tools/libxl/libxl_create.c
> > > @@ -38,7 +38,13 @@ int libxl__domain_create_info_setdefault(libxl__gc *gc,
> > > libxl__arch_domain_create_info_setdefault(gc, c_info);
> > >
> > > if (c_info->type != LIBXL_DOMAIN_TYPE_PV) {
> > > -libxl_defbool_setdefault(_info->hap, true);
> > > +libxl_physinfo info;
> > > +int rc = libxl_get_physinfo(CTX, );
> > > +
> > > +if (rc)
> > > +return rc;
> > > +
> > > +libxl_defbool_setdefault(_info->hap, info.cap_hap);
> > > libxl_defbool_setdefault(_info->oos, true);
> > > }
> > >
> > > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > > index b61399ce36..9e1f8515d3 100644
> > > --- a/tools/libxl/libxl_types.idl
> > > +++ b/tools/libxl/libxl_types.idl
> > > @@ -1025,6 +1025,7 @@ libxl_physinfo = Struct("physinfo", [
> > > ("cap_hvm", bool),
> > > ("cap_pv", bool),
> > > ("cap_hvm_directio", bool), # No longer HVM specific
> > > +("cap_hap", bool),
>
> Actually Julien's review of one of my patches points out that this idl change
> should be accompanied by an associated LIBXL_HAVE_CAP_HAP definition.
Ouch, yes, I always forget those. I will add now, and keep your RB and
Jan's Ack unless any of you tell me otherwise.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] IOMMU/x86: make page type checks consistent when mapping pages
On Fri, Sep 06, 2019 at 02:08:09PM +0200, Jan Beulich wrote:
> On 06.09.2019 13:45, Roger Pau Monné wrote:
> > On Fri, Sep 06, 2019 at 12:52:11PM +0200, Jan Beulich wrote:
> >> On 06.09.2019 11:37, Roger Pau Monné wrote:
> >>> On Wed, Jul 03, 2019 at 12:18:45PM +, Jan Beulich wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -829,13 +829,13 @@ guest_physmap_add_page(struct domain *d,
> *
> * Retain this property by grabbing a writable type ref and
> then
> * dropping it immediately. The result will be pages that
> have a
> - * writable type (and an IOMMU entry), but a count of 0 (such
> that
> - * any guest-requested type changes succeed and remove the IOMMU
> - * entry).
> + * writable type (and an IOMMU entry if necessary), but a count
> of 0
> + * (such that any guest-requested type changes succeed and
> remove the
> + * IOMMU entry).
> */
> for ( i = 0; i < (1UL << page_order); ++i, ++page )
> {
> -if ( !need_iommu_pt_sync(d) )
> +if ( !iommu_enabled )
> >>>
> >>> That's kind of a strong check for a domain that might never use the
> >>> iommu at all. Isn't it fine to just rely on
> >>> arch_iommu_populate_page_table finding non-writable pages and thus not
> >>> adding them to the iommu page-tables?
> >>
> >> No - the code change here is to take care of page additions to
> >> the domain after it has booted.
> >
> > Please bear with me, but AFAICT arch_iommu_populate_page_table could
> > be used after the domain has booted if a pci device is hot plugged.
> >
> > If this is to deal with additions to domains having an iommu already
> > enabled, isn't it enough to use need_iommu_pt_sync?
> >
> > That's going to return true for all PV domains, except for dom0 not
> > running in strict mode, which is expected because in that case dom0
> > already has the whole RAM mapped into the iommu page-tables?
>
> Well, my previous reply wasn't precise enough, I guess. The change
> really is about both cases: If the domain is already using an IOMMU,
> need_iommu_pt_sync() would be enough indeed. If IOMMU use _may_ be
> enabled later on, we need to transition pages out of their initial
> PGT_none state right away. If we deferred this until the point
> where the IOMMU gets enabled for the domain, we'd have to watch out
> for PGT_none pages there, which would be extra hassle.
I still think a relaxed PV dom0 should avoid the overhead of
get_page_and_type, and the iommu flush done afterwards, as it already
has all host RAM into it's iommu page-tables.
Ie: I think the check should be something like:
if ( !iommu_enabled ||
(is_hardware_domain(d) && !need_iommu_pt_sync(d) )
> +{
> +put_page_and_type(page);
> +flush_flags |= IOMMUF_readable |
> IOMMUF_writable;
> +}
> +else if ( !rc )
> +rc = -EBUSY;
> >>>
> >>> Is it fine to return an error here? AFAICT you could have a RO page
> >>> shared with Xen with PGT_none, and not having an iommu mapping for it
> >>> would be expected, hence returning an error seems wrong?
> >>
> >> No, pages shared with Xen don't live on d->page_list (which is what the
> >> loop iterates over).
> >
> > So then there should be no PGT_none pages in d->page_list?
> >
> > The only user I can find of PGT_none is share_xen_page_with_guest.
>
> Plus the implicit use when a page gets first added to a domain (by
> setting ->u.inuse.type_info to zero).
Ack, thanks for the clarification.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 09/11] swiotlb-xen: simplify cache maintainance
On 06/09/2019 15:01, Christoph Hellwig wrote: > On Fri, Sep 06, 2019 at 09:52:12AM -0400, Boris Ostrovsky wrote: >> We need nop definitions of these two for x86. >> >> Everything builds now but that's probably because the calls are under >> 'if (!dev_is_dma_coherent(dev))' which is always false so compiler >> optimized is out. I don't think we should rely on that. > That is how a lot of the kernel works. Provide protypes only for code > that is semantically compiled, but can't ever be called due to > IS_ENABLED() checks. It took me a while to get used to it, but it > actually is pretty nice as the linker does the work for you to check > that it really is never called. Much better than say a BUILD_BUG_ON(). Yeah - its a weird concept to get used to, but it results in much clearer code. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 3/3] x86/apic: do not initialize LDR and DFR for bigsmp
On 06/09/2019 15:01, Jan Beulich wrote: > Legacy apic init uses bigsmp for smp systems with 8 and more CPUs. The > bigsmp APIC implementation uses physical destination mode, but it > nevertheless initializes LDR and DFR. The LDR even ends up incorrectly with > multiple bit being set. > > This does not cause a functional problem because LDR and DFR are ignored > when physical destination mode is active, but it triggered a problem on a > 32-bit KVM guest which jumps into a kdump kernel. > > The multiple bits set unearthed a bug in the KVM APIC implementation. The > code which creates the logical destination map for VCPUs ignores the > disabled state of the APIC and ends up overwriting an existing valid entry > and as a result, APIC calibration hangs in the guest during kdump > initialization. > > Remove the bogus LDR/DFR initialization. > > This is not intended to work around the KVM APIC bug. The LDR/DFR > ininitalization is wrong on its own. > > Suggested-by: Thomas Gleixner > Signed-off-by: Bandan Das > [Linux commit bae3a8d3308ee69a7dbdf145911b18dfda8ade0d] > > Drop init_apic_ldr_x2apic_phys() at the same time. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/3] x86/apic: include the LDR when clearing out APIC registers
On 06/09/2019 15:01, Jan Beulich wrote: > Although APIC initialization will typically clear out the LDR before > setting it, the APIC cleanup code should reset the LDR. > > This was discovered with a 32-bit KVM guest jumping into a kdump > kernel. The stale bits in the LDR triggered a bug in the KVM APIC > implementation which caused the destination mapping for VCPUs to be > corrupted. > > Note that this isn't intended to paper over the KVM APIC bug. The kernel > has to clear the LDR when resetting the APIC registers except when X2APIC > is enabled. > > Signed-off-by: Bandan Das > [Linux commit 558682b5291937a70748d36fd9ba757fb25b99ae] > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3/3] x86/apic: do not initialize LDR and DFR for bigsmp
Legacy apic init uses bigsmp for smp systems with 8 and more CPUs. The
bigsmp APIC implementation uses physical destination mode, but it
nevertheless initializes LDR and DFR. The LDR even ends up incorrectly with
multiple bit being set.
This does not cause a functional problem because LDR and DFR are ignored
when physical destination mode is active, but it triggered a problem on a
32-bit KVM guest which jumps into a kdump kernel.
The multiple bits set unearthed a bug in the KVM APIC implementation. The
code which creates the logical destination map for VCPUs ignores the
disabled state of the APIC and ends up overwriting an existing valid entry
and as a result, APIC calibration hangs in the guest during kdump
initialization.
Remove the bogus LDR/DFR initialization.
This is not intended to work around the KVM APIC bug. The LDR/DFR
ininitalization is wrong on its own.
Suggested-by: Thomas Gleixner
Signed-off-by: Bandan Das
[Linux commit bae3a8d3308ee69a7dbdf145911b18dfda8ade0d]
Drop init_apic_ldr_x2apic_phys() at the same time.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/genapic/delivery.c
+++ b/xen/arch/x86/genapic/delivery.c
@@ -40,11 +40,7 @@ unsigned int cpu_mask_to_apicid_flat(con
void init_apic_ldr_phys(void)
{
- unsigned long val;
- apic_write(APIC_DFR, APIC_DFR_FLAT);
- /* A dummy logical ID should be fine. We only deliver in phys mode. */
- val = apic_read(APIC_LDR) & ~APIC_LDR_MASK;
- apic_write(APIC_LDR, val);
+ /* We only deliver in phys mode - no setup needed. */
}
void __init clustered_apic_check_phys(void)
--- a/xen/arch/x86/genapic/x2apic.c
+++ b/xen/arch/x86/genapic/x2apic.c
@@ -38,10 +38,6 @@ static inline u32 x2apic_cluster(unsigne
return per_cpu(cpu_2_logical_apicid, cpu) >> 16;
}
-static void init_apic_ldr_x2apic_phys(void)
-{
-}
-
static void init_apic_ldr_x2apic_cluster(void)
{
unsigned int cpu, this_cpu = smp_processor_id();
@@ -167,7 +163,7 @@ static const struct genapic __initconstr
APIC_INIT("x2apic_phys", NULL),
.int_delivery_mode = dest_Fixed,
.int_dest_mode = 0 /* physical delivery */,
-.init_apic_ldr = init_apic_ldr_x2apic_phys,
+.init_apic_ldr = init_apic_ldr_phys,
.clustered_apic_check = clustered_apic_check_x2apic,
.vector_allocation_cpumask = vector_allocation_cpumask_phys,
.cpu_mask_to_apicid = cpu_mask_to_apicid_phys,
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 09/11] swiotlb-xen: simplify cache maintainance
On Fri, Sep 06, 2019 at 09:52:12AM -0400, Boris Ostrovsky wrote: > We need nop definitions of these two for x86. > > Everything builds now but that's probably because the calls are under > 'if (!dev_is_dma_coherent(dev))' which is always false so compiler > optimized is out. I don't think we should rely on that. That is how a lot of the kernel works. Provide protypes only for code that is semantically compiled, but can't ever be called due to IS_ENABLED() checks. It took me a while to get used to it, but it actually is pretty nice as the linker does the work for you to check that it really is never called. Much better than say a BUILD_BUG_ON(). ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/3] x86: drop CONFIG_X86_MCE_THERMAL
On 06/09/2019 15:00, Jan Beulich wrote: > There's no point having this if it's not exposed through Kconfig. > > Take the liberty and also drop an unnecessary "return" in context. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/3] x86/apic: include the LDR when clearing out APIC registers
Although APIC initialization will typically clear out the LDR before
setting it, the APIC cleanup code should reset the LDR.
This was discovered with a 32-bit KVM guest jumping into a kdump
kernel. The stale bits in the LDR triggered a bug in the KVM APIC
implementation which caused the destination mapping for VCPUs to be
corrupted.
Note that this isn't intended to paper over the KVM APIC bug. The kernel
has to clear the LDR when resetting the APIC registers except when X2APIC
is enabled.
Signed-off-by: Bandan Das
[Linux commit 558682b5291937a70748d36fd9ba757fb25b99ae]
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -212,6 +212,10 @@ void clear_local_APIC(void)
apic_write(APIC_LVTTHMR, APIC_LVT_MASKED);
if (maxlvt >= 6)
apic_write(APIC_CMCI, APIC_LVT_MASKED);
+if (!x2apic_enabled) {
+v = apic_read(APIC_LDR) & ~APIC_LDR_MASK;
+apic_write(APIC_LDR, v);
+}
if (maxlvt > 3)/* Due to Pentium errata 3AP and 11AP. */
apic_write(APIC_ESR, 0);
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/3] x86: drop CONFIG_X86_MCE_THERMAL
There's no point having this if it's not exposed through Kconfig.
Take the liberty and also drop an unnecessary "return" in context.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -189,19 +189,15 @@ void clear_local_APIC(void)
v = apic_read(APIC_LVTPC);
apic_write(APIC_LVTPC, v | APIC_LVT_MASKED);
}
-
-/* lets not touch this if we didn't frob it */
-#ifdef CONFIG_X86_MCE_THERMAL
if (maxlvt >= 5) {
v = apic_read(APIC_LVTTHMR);
apic_write(APIC_LVTTHMR, v | APIC_LVT_MASKED);
}
-#endif
-
if (maxlvt >= 6) {
v = apic_read(APIC_CMCI);
apic_write(APIC_CMCI, v | APIC_LVT_MASKED);
}
+
/*
* Clean APIC state for other OSs:
*/
@@ -212,11 +208,8 @@ void clear_local_APIC(void)
apic_write(APIC_LVTERR, APIC_LVT_MASKED);
if (maxlvt >= 4)
apic_write(APIC_LVTPC, APIC_LVT_MASKED);
-
-#ifdef CONFIG_X86_MCE_THERMAL
if (maxlvt >= 5)
apic_write(APIC_LVTTHMR, APIC_LVT_MASKED);
-#endif
if (maxlvt >= 6)
apic_write(APIC_CMCI, APIC_LVT_MASKED);
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -51,7 +51,6 @@ bool __read_mostly lmce_support;
#define INTEL_SRAR_DATA_LOAD 0x134
#define INTEL_SRAR_INSTR_FETCH 0x150
-#ifdef CONFIG_X86_MCE_THERMAL
#define MCE_RING0x1
static DEFINE_PER_CPU(int, last_state);
@@ -174,9 +173,7 @@ static void intel_init_thermal(struct cp
if ( opt_cpu_info )
printk(KERN_INFO "CPU%u: Thermal monitoring enabled (%s)\n",
cpu, tm2 ? "TM2" : "TM1");
-return;
}
-#endif /* CONFIG_X86_MCE_THERMAL */
/* Intel MCE handler */
static inline void intel_get_extended_msr(struct mcinfo_extended *ext, u32 msr)
@@ -941,9 +938,8 @@ enum mcheck_type intel_mcheck_init(struc
intel_init_mce();
intel_init_cmci(c);
-#ifdef CONFIG_X86_MCE_THERMAL
+
intel_init_thermal(c);
-#endif
return mcheck_intel;
}
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -21,7 +21,6 @@
#define CONFIG_X86_PM_TIMER 1
#define CONFIG_HPET_TIMER 1
-#define CONFIG_X86_MCE_THERMAL 1
#define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS 1
#define CONFIG_DISCONTIGMEM 1
#define CONFIG_NUMA_EMU 1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/3] x86: (largely) LAPIC related cleanup
The latter two patches are derived from Linux ones, which caught my attention. The first one is simply some extra code reduction potential I noticed while evaluating whether those Linux changes are applicable to our tree. 1: x86: drop CONFIG_X86_MCE_THERMAL 2: x86/apic: include the LDR when clearing out APIC registers 3: x86/apic: do not initialize LDR and DFR for bigsmp Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/mwait-idle: add support for Jacobsville
On 06/09/2019 14:54, Jan Beulich wrote: > From: Zhang Rui > > Jacobsville uses the same C-states as Denverton. > > Signed-off-by: Zhang Rui > [Linux commit 04b1d5d098491244f506c4265cc95b87210eef2f] > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] sysctl/libxl: choose a sane default for HAP
> -Original Message-
> From: Xen-devel On Behalf Of Paul
> Durrant
> Sent: 05 September 2019 14:52
> To: Roger Pau Monne ; xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Wei Liu ;
> Konrad Rzeszutek Wilk
> ; Andrew Cooper ; Tim
> (Xen.org) ;
> George Dunlap ; Julien Grall
> ; Jan Beulich
> ; Anthony Perard ; Ian Jackson
> ;
> Volodymyr Babchuk ; Roger Pau Monne
>
> Subject: Re: [Xen-devel] [PATCH v2 2/2] sysctl/libxl: choose a sane default
> for HAP
>
> > -Original Message-
> > From: Roger Pau Monne
> > Sent: 05 September 2019 14:27
> > To: xen-devel@lists.xenproject.org
> > Cc: Roger Pau Monne ; Ian Jackson
> > ; Wei Liu
> > ; Anthony Perard ; Andrew Cooper
> > ;
> > George Dunlap ; Jan Beulich ;
> > Julien Grall
> > ; Konrad Rzeszutek Wilk ;
> > Stefano Stabellini
> > ; Tim (Xen.org) ; Volodymyr Babchuk
> ;
> > Paul Durrant
> > Subject: [PATCH v2 2/2] sysctl/libxl: choose a sane default for HAP
> >
> > Current libxl code will always enable Hardware Assisted Paging (HAP),
> > expecting that the hypervisor will fallback to shadow if HAP is not
> > available. With the changes to the domain builder that's not the case
> > any longer, and the hypervisor will raise an error if HAP is not
> > available instead of silently falling back to shadow.
> >
> > In order to keep the previous functionality report whether HAP is
> > available or not in XEN_SYSCTL_physinfo, so that the toolstack can
> > select a sane default if there's no explicit user selection of whether
> > HAP should be used.
> >
> > Note that on ARM hardware HAP capability is always reported since it's
> > a required feature in order to run Xen.
> >
> > Fixes: d0c0ba7d3de ('x86/hvm/domain: remove the 'hap_enabled' flag')
> > Signed-off-by: Roger Pau Monné
>
> LGTM
>
> Reviewed-by: Paul Durrant
>
> > ---
> > Cc: Paul Durrant
> > ---
> > Changes since v1:
> > - Also report HAP capability for ARM.
> > - Print hap capability in xl info.
> > ---
> > tools/libxl/libxl.c | 1 +
> > tools/libxl/libxl_create.c | 8 +++-
> > tools/libxl/libxl_types.idl | 1 +
> > tools/xl/xl_info.c | 5 +++--
> > xen/arch/arm/sysctl.c | 2 +-
> > xen/arch/x86/sysctl.c | 2 ++
> > xen/include/public/sysctl.h | 4
> > 7 files changed, 19 insertions(+), 4 deletions(-)
> >
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index ec71574e99..5c0fcf320e 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -399,6 +399,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo
> > *physinfo)
> > physinfo->cap_pv = !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_pv);
> > physinfo->cap_hvm_directio =
> > !!(xcphysinfo.capabilities & XEN_SYSCTL_PHYSCAP_directio);
> > +physinfo->cap_hap = !!(xcphysinfo.capabilities &
> > XEN_SYSCTL_PHYSCAP_hap);
> >
> > GC_FREE;
> > return 0;
> > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > index 03ce166f4f..6a556dea8f 100644
> > --- a/tools/libxl/libxl_create.c
> > +++ b/tools/libxl/libxl_create.c
> > @@ -38,7 +38,13 @@ int libxl__domain_create_info_setdefault(libxl__gc *gc,
> > libxl__arch_domain_create_info_setdefault(gc, c_info);
> >
> > if (c_info->type != LIBXL_DOMAIN_TYPE_PV) {
> > -libxl_defbool_setdefault(_info->hap, true);
> > +libxl_physinfo info;
> > +int rc = libxl_get_physinfo(CTX, );
> > +
> > +if (rc)
> > +return rc;
> > +
> > +libxl_defbool_setdefault(_info->hap, info.cap_hap);
> > libxl_defbool_setdefault(_info->oos, true);
> > }
> >
> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > index b61399ce36..9e1f8515d3 100644
> > --- a/tools/libxl/libxl_types.idl
> > +++ b/tools/libxl/libxl_types.idl
> > @@ -1025,6 +1025,7 @@ libxl_physinfo = Struct("physinfo", [
> > ("cap_hvm", bool),
> > ("cap_pv", bool),
> > ("cap_hvm_directio", bool), # No longer HVM specific
> > +("cap_hap", bool),
Actually Julien's review of one of my patches points out that this idl change
should be accompanied by an associated LIBXL_HAVE_CAP_HAP definition.
Paul
> > ], dir=DIR_OUT)
> >
> > libxl_connectorinfo = Struct("connectorinfo", [
> > diff --git a/tools/xl/xl_info.c b/tools/xl/xl_info.c
> > index 46d9c9f712..aa6724bc7f 100644
> > --- a/tools/xl/xl_info.c
> > +++ b/tools/xl/xl_info.c
> > @@ -210,11 +210,12 @@ static void output_physinfo(void)
> > info.hw_cap[4], info.hw_cap[5], info.hw_cap[6], info.hw_cap[7]
> > );
> >
> > -maybe_printf("virt_caps :%s%s%s%s\n",
> > +maybe_printf("virt_caps :%s%s%s%s%s\n",
> > info.cap_pv ? " pv" : "",
> > info.cap_hvm ? " hvm" : "",
> > info.cap_hvm && info.cap_hvm_directio ? " hvm_directio" : "",
> > - info.cap_pv && info.cap_hvm_directio ? " pv_directio" : ""
> > + info.cap_pv && info.cap_hvm_directio ? "
[Xen-devel] [PATCH] x86/mwait-idle: add support for Jacobsville
From: Zhang Rui
Jacobsville uses the same C-states as Denverton.
Signed-off-by: Zhang Rui
[Linux commit 04b1d5d098491244f506c4265cc95b87210eef2f]
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -962,6 +962,7 @@ static const struct x86_cpu_id intel_idl
ICPU(0x5c, bxt),
ICPU(0x7a, bxt),
ICPU(0x5f, dnv),
+ ICPU(0x86, dnv),
{}
};
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 09/11] swiotlb-xen: simplify cache maintainance
On 9/5/19 7:34 AM, Christoph Hellwig wrote: > diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h > index 5e4b83f83dbc..d71380f6ed0b 100644 > --- a/include/xen/swiotlb-xen.h > +++ b/include/xen/swiotlb-xen.h > @@ -4,6 +4,11 @@ > > #include > > +void xen_dma_sync_for_cpu(struct device *dev, dma_addr_t handle, > + phys_addr_t paddr, size_t size, enum dma_data_direction dir); > +void xen_dma_sync_for_device(struct device *dev, dma_addr_t handle, > + phys_addr_t paddr, size_t size, enum dma_data_direction dir); > + > extern int xen_swiotlb_init(int verbose, bool early); > extern const struct dma_map_ops xen_swiotlb_dma_ops; We need nop definitions of these two for x86. Everything builds now but that's probably because the calls are under 'if (!dev_is_dma_coherent(dev))' which is always false so compiler optimized is out. I don't think we should rely on that. -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xstate: make use_xsave non-init
On Fri, Sep 06, 2019 at 03:33:50PM +0200, Jan Beulich wrote:
> On 05.09.2019 18:04, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/xstate.c
> > +++ b/xen/arch/x86/xstate.c
> > @@ -577,7 +577,11 @@ unsigned int xstate_ctxt_size(u64 xcr0)
> > /* Collect the information of processor's extended state */
> > void xstate_init(struct cpuinfo_x86 *c)
> > {
> > -static bool __initdata use_xsave = true;
> > +/*
> > + * NB: use_xsave cannot live in initdata because llvm might optimize
> > + * reading it, see: https://bugs.llvm.org/show_bug.cgi?id=39707
> > + */
> > +static bool use_xsave = true;
> > boolean_param("xsave", use_xsave);
> >
> > bool bsp = c == _cpu_data;
>
> I think we'd want to use __read_mostly then instead. Can be added
> while committing of course, if you agree. With the addition
> Acked-by: Jan Beulich
Yes, that seems OK to me. Feel free to expand the commit message to
mention the change to read_mostly if you want.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] swiotlb-xen: Convert to use macro
On Fri, Sep 6, 2019 at 7:02 PM Boris Ostrovsky wrote: > > On 9/6/19 8:27 AM, Souptick Joarder wrote: > > On Mon, Sep 2, 2019 at 2:04 PM Souptick Joarder > > wrote: > >> Rather than using static int max_dma_bits, this > >> can be coverted to use as macro. > >> > >> Signed-off-by: Souptick Joarder > >> Reviewed-by: Juergen Gross > > If it is still not late, can we get this patch in queue for 5.4 ? > > > Yes, I will queue it later today. Thanks Boris. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] xstate: make use_xsave non-init
On 05.09.2019 18:04, Roger Pau Monne wrote:
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -577,7 +577,11 @@ unsigned int xstate_ctxt_size(u64 xcr0)
> /* Collect the information of processor's extended state */
> void xstate_init(struct cpuinfo_x86 *c)
> {
> -static bool __initdata use_xsave = true;
> +/*
> + * NB: use_xsave cannot live in initdata because llvm might optimize
> + * reading it, see: https://bugs.llvm.org/show_bug.cgi?id=39707
> + */
> +static bool use_xsave = true;
> boolean_param("xsave", use_xsave);
>
> bool bsp = c == _cpu_data;
I think we'd want to use __read_mostly then instead. Can be added
while committing of course, if you agree. With the addition
Acked-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] swiotlb-xen: Convert to use macro
On 9/6/19 8:27 AM, Souptick Joarder wrote: > On Mon, Sep 2, 2019 at 2:04 PM Souptick Joarder wrote: >> Rather than using static int max_dma_bits, this >> can be coverted to use as macro. >> >> Signed-off-by: Souptick Joarder >> Reviewed-by: Juergen Gross > If it is still not late, can we get this patch in queue for 5.4 ? Yes, I will queue it later today. -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/boot: Don't explicitly map the VGA region as UC-
On 05.09.2019 21:04, Andrew Cooper wrote: > All 64-bit capable processors use PAT, and with PAT, it is explicitly > permitted to have mappings with a cacheability different to MTRRs. > > On a native system with a real legacy VGA region, MTRRs will cause the region > to be UC-. Minor correction: MTRRs can't be used to specify UC-. UC- is used in PAT to allow WC from MTRRs to be retained, rather than becoming UC. And hence sensible BIOSes would make this range WC in the MTRRs, not UC. The main question here is whether we can rely on firmware to actually set MTRRs correctly. > When booting virtualised, this range may be RAM and not a legacy > VGA region, at which point it wants to be WB. To limit the effect of improper MTRR settings, did you consider using WT instead? Furthermore, did you consider dynamically changing the involved PTEs depending on whether we run virtualized ourselves? > Use WB mapping in the pagetables, such that in systems without a legacy VGA > region, the RAM between 0xa and 0xc doesn't become unnecesserily UC-. May I suggest s/RAM/range/ ? There's no guarantee that when there's no VGA there, that it would be RAM instead. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 141080: regressions - FAIL
flight 141080 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141080/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 141054
Tests which did not succeed, but are not blocking:
build-amd64-libvirt 1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
version targeted for testing:
ovmf 59b754c9f697d9627b0d327d5132f0e1abb0
baseline version:
ovmf 8a1305a11f3bda2d6c1ab758e4aea79ee021dd1c
Last test of basis 141054 2019-09-05 13:58:24 Z0 days
Testing same since 141080 2019-09-06 03:49:55 Z0 days1 attempts
People who touched revisions under test:
Ard Biesheuvel
Laszlo Ersek
Leif Lindholm
Zhichao Gao
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 fail
build-i386 pass
build-amd64-libvirt blocked
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked
test-amd64-i386-xl-qemuu-ovmf-amd64 blocked
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 pushing.
commit 59b754c9f697d9627b0d327d5132f0e1abb0
Author: Laszlo Ersek
Date: Tue Jul 2 02:03:15 2019 +0200
OvmfPkg/EnrollDefaultKeys: clean up Base64Decode() retval handling
Since commit 35e242b698cd ("MdePkg/BaseLib: rewrite Base64Decode()",
2019-07-16), Base64Decode() guarantees that DestinationSize is larger on
output than it was on input if RETURN_BUFFER_TOO_SMALL is returned. Clean
up the retval handling for the first Base64Decode() call in
EnrollDefaultKeys, which used to work around the ambiguity in the previous
Base64Decode() interface contract.
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc: Philippe Mathieu-Daudé
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1981
Signed-off-by: Laszlo Ersek
Reviewed-by: Philippe Mathieu-Daude
Acked-by: Ard Biesheuvel
commit ae9f12058d71d9c5971c3cf36191cd813ecc9554
Author: Laszlo Ersek
Date: Tue Sep 3 17:08:45 2019 +0200
ArmVirtPkg/PlatformBootManagerLib: unload image on EFI_SECURITY_VIOLATION
The LoadImage() boot service is a bit unusual in that it allocates
resources in a particular failure case; namely, it produces a valid
"ImageHandle" when it returns EFI_SECURITY_VIOLATION. This is supposed to
happen e.g. when Secure Boot verification fails for the image, but the
platform policy for the particular image origin (such as "fixed media" or
"removable media") is DEFER_EXECUTE_ON_SECURITY_VIOLATION. The return code
allows platform logic to selectively override the verification failure,
and launch the image nonetheless.
ArmVirtPkg/PlatformBootManagerLib does not override EFI_SECURITY_VIOLATION
for the kernel image loaded from fw_cfg -- any LoadImage() error is
considered fatal. When we simply treat EFI_SECURITY_VIOLATION like any
other LoadImage() error, we leak the resources associated with
"KernelImageHandle". From a resource usage perspective,
EFI_SECURITY_VIOLATION must be considered "success", and rolled back.
Implement this rollback, without breaking the proper "nesting" of error
handling jumps and labels.
Cc: Ard Biesheuvel
Cc: Dandan Bi
Cc: Leif Lindholm
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Fixes: 23d04b58e27b382bbd3f9b16ba9adb1cb203dad5
Signed-off-by: Laszlo Ersek
Acked-by: Ard Biesheuvel
Reviewed-by: Dandan Bi
Reviewed-by: Philippe Mathieu-Daude
commit 23908d0f5cc6bc04a0d19f694cd8c2a392077da0
Author: Ard Biesheuvel
Date: Wed Sep 4 09:30:47 2019 -0700
Re: [Xen-devel] [xen-unstable-smoke test] 141063: regressions - FAIL
On 06/09/2019 14:12, Jan Beulich wrote: > On 06.09.2019 14:28, Andrew Cooper wrote: >> On 06/09/2019 08:29, Jan Beulich wrote: >>> On 06.09.2019 00:04, osstest service owner wrote: flight 141063 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/141063/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 141049 >>> Looks like this currently fails about every other time, and >>> >>> /home/osstest/build.141063.build-amd64/xen/tools/firmware/../../tools/cross-install >>> -m0644 -p xen-dir/xen-shim >>> /home/osstest/build.141063.build-amd64/xen/dist/install/usr/local/lib/xen/boot/xen-shim >>> install: cannot stat 'xen-dir/xen-shim': No such file or directory >>> Makefile:48: recipe for target 'install' failed >>> make[4]: Leaving directory >>> '/home/osstest/build.141063.build-amd64/xen/tools/firmware' >>> make[4]: *** [install] Error 1 >>> >>> suggests to me that the further amount of duct tape put in >>> place by a342900d48 still wasn't enough. >> Right. I don't have time to investigate further. I'll revert the >> original patches which caused this, as doing so will most likely resolve >> the intermittent pv-shim test issues. > Hmm, why did you also revert the follow-on Makefile adjustment? > That was right, wasn't it? c/s 32b1d62887 alone completely broke a parallel build, and was fixed by c/s 060f4eee0f To revert 32b1d62887, I needed to take both out. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH -tip v4 4/4] x86: kprobes: Prohibit probing on instruction which has emulate prefix
Prohibit probing on instruction which has XEN_EMULATE_PREFIX or KVM's emulate prefix. Since that prefix is a marker for Xen and KVM, if we modify the marker by kprobe's int3, that doesn't work as expected. Signed-off-by: Masami Hiramatsu --- arch/x86/kernel/kprobes/core.c |4 1 file changed, 4 insertions(+) diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c index 43fc13c831af..4f13af7cbcdb 100644 --- a/arch/x86/kernel/kprobes/core.c +++ b/arch/x86/kernel/kprobes/core.c @@ -351,6 +351,10 @@ int __copy_instruction(u8 *dest, u8 *src, u8 *real, struct insn *insn) kernel_insn_init(insn, dest, MAX_INSN_SIZE); insn_get_length(insn); + /* We can not probe force emulate prefixed instruction */ + if (insn_has_emulate_prefix(insn)) + return 0; + /* Another subsystem puts a breakpoint, failed to recover */ if (insn->opcode.bytes[0] == BREAKPOINT_INSTRUCTION) return 0; ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH -tip v4 3/4] x86: xen: insn: Decode Xen and KVM emulate-prefix signature
Decode Xen and KVM's emulate-prefix signature by x86 insn decoder.
It is called "prefix" but actually not x86 instruction prefix, so
this adds insn.emulate_prefix_size field instead of reusing
insn.prefixes.
If x86 decoder finds a special sequence of instructions of
XEN_EMULATE_PREFIX and 'ud2a; .ascii "kvm"', it just counts the
length, set insn.emulate_prefix_size and fold it with the next
instruction. In other words, the signature and the next instruction
is treated as a single instruction.
Reported-by: Josh Poimboeuf
Signed-off-by: Masami Hiramatsu
Acked-by: Josh Poimboeuf
---
Changes in v4:
- Use asm/emulate_prefix.h instead of xen/prefix.h
- Fix to add emulate_prefix.h to the checkist of perf.
---
arch/x86/include/asm/insn.h |6 +
arch/x86/lib/insn.c | 34 +++
tools/arch/x86/include/asm/emulate_prefix.h | 14 +++
tools/arch/x86/include/asm/insn.h |6 +
tools/arch/x86/lib/insn.c | 34 +++
tools/objtool/sync-check.sh |3 ++
tools/perf/check-headers.sh |3 ++
7 files changed, 98 insertions(+), 2 deletions(-)
create mode 100644 tools/arch/x86/include/asm/emulate_prefix.h
diff --git a/arch/x86/include/asm/insn.h b/arch/x86/include/asm/insn.h
index 154f27be8bfc..5c1ae3eff9d4 100644
--- a/arch/x86/include/asm/insn.h
+++ b/arch/x86/include/asm/insn.h
@@ -45,6 +45,7 @@ struct insn {
struct insn_field immediate2; /* for 64bit imm or seg16 */
};
+ int emulate_prefix_size;
insn_attr_t attr;
unsigned char opnd_bytes;
unsigned char addr_bytes;
@@ -128,6 +129,11 @@ static inline int insn_is_evex(struct insn *insn)
return (insn->vex_prefix.nbytes == 4);
}
+static inline int insn_has_emulate_prefix(struct insn *insn)
+{
+ return !!insn->emulate_prefix_size;
+}
+
/* Ensure this instruction is decoded completely */
static inline int insn_complete(struct insn *insn)
{
diff --git a/arch/x86/lib/insn.c b/arch/x86/lib/insn.c
index 0b5862ba6a75..404279563891 100644
--- a/arch/x86/lib/insn.c
+++ b/arch/x86/lib/insn.c
@@ -13,6 +13,8 @@
#include
#include
+#include
+
/* Verify next sizeof(t) bytes can be on the same instruction */
#define validate_next(t, insn, n) \
((insn)->next_byte + sizeof(t) + n <= (insn)->end_kaddr)
@@ -58,6 +60,36 @@ void insn_init(struct insn *insn, const void *kaddr, int
buf_len, int x86_64)
insn->addr_bytes = 4;
}
+static const insn_byte_t xen_prefix[] = { __XEN_EMULATE_PREFIX };
+static const insn_byte_t kvm_prefix[] = { __KVM_EMULATE_PREFIX };
+
+static int __insn_get_emulate_prefix(struct insn *insn,
+const insn_byte_t *prefix, size_t len)
+{
+ size_t i;
+
+ for (i = 0; i < len; i++) {
+ if (peek_nbyte_next(insn_byte_t, insn, i) != prefix[i])
+ goto err_out;
+ }
+
+ insn->emulate_prefix_size = len;
+ insn->next_byte += len;
+
+ return 1;
+
+err_out:
+ return 0;
+}
+
+static void insn_get_emulate_prefix(struct insn *insn)
+{
+ if (__insn_get_emulate_prefix(insn, xen_prefix, sizeof(xen_prefix)))
+ return;
+
+ __insn_get_emulate_prefix(insn, kvm_prefix, sizeof(kvm_prefix));
+}
+
/**
* insn_get_prefixes - scan x86 instruction prefix bytes
* @insn: insn containing instruction
@@ -76,6 +108,8 @@ void insn_get_prefixes(struct insn *insn)
if (prefixes->got)
return;
+ insn_get_emulate_prefix(insn);
+
nb = 0;
lb = 0;
b = peek_next(insn_byte_t, insn);
diff --git a/tools/arch/x86/include/asm/emulate_prefix.h
b/tools/arch/x86/include/asm/emulate_prefix.h
new file mode 100644
index ..70f5b98a5286
--- /dev/null
+++ b/tools/arch/x86/include/asm/emulate_prefix.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_EMULATE_PREFIX_H
+#define _ASM_X86_EMULATE_PREFIX_H
+
+/*
+ * Virt escape sequences to trigger instruction emulation;
+ * ideally these would decode to 'whole' instruction and not destroy
+ * the instruction stream; sadly this is not true for the 'kvm' one :/
+ */
+
+#define __XEN_EMULATE_PREFIX 0x0f,0x0b,0x78,0x65,0x6e /* ud2 ; .ascii "xen"
*/
+#define __KVM_EMULATE_PREFIX 0x0f,0x0b,0x6b,0x76,0x6d /* ud2 ; .ascii "kvm" */
+
+#endif
diff --git a/tools/arch/x86/include/asm/insn.h
b/tools/arch/x86/include/asm/insn.h
index 37a4c390750b..568854b14d0a 100644
--- a/tools/arch/x86/include/asm/insn.h
+++ b/tools/arch/x86/include/asm/insn.h
@@ -45,6 +45,7 @@ struct insn {
struct insn_field immediate2; /* for 64bit imm or seg16 */
};
+ int emulate_prefix_size;
insn_attr_t attr;
unsigned char opnd_bytes;
unsigned char addr_bytes;
@@ -128,6 +129,11 @@ static inline int insn_is_evex(struct insn
[Xen-devel] [PATCH -tip v4 2/4] x86: xen: kvm: Gather the definition of emulate prefixes
Gather the emulate prefixes, which forcibly make the following
instruction emulated on virtualization, in one place.
Suggested-by: Peter Zijlstra
Signed-off-by: Masami Hiramatsu
---
arch/x86/include/asm/emulate_prefix.h | 14 ++
arch/x86/include/asm/xen/interface.h | 11 ---
arch/x86/kvm/x86.c|4 +++-
3 files changed, 21 insertions(+), 8 deletions(-)
create mode 100644 arch/x86/include/asm/emulate_prefix.h
diff --git a/arch/x86/include/asm/emulate_prefix.h
b/arch/x86/include/asm/emulate_prefix.h
new file mode 100644
index ..70f5b98a5286
--- /dev/null
+++ b/arch/x86/include/asm/emulate_prefix.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_EMULATE_PREFIX_H
+#define _ASM_X86_EMULATE_PREFIX_H
+
+/*
+ * Virt escape sequences to trigger instruction emulation;
+ * ideally these would decode to 'whole' instruction and not destroy
+ * the instruction stream; sadly this is not true for the 'kvm' one :/
+ */
+
+#define __XEN_EMULATE_PREFIX 0x0f,0x0b,0x78,0x65,0x6e /* ud2 ; .ascii "xen"
*/
+#define __KVM_EMULATE_PREFIX 0x0f,0x0b,0x6b,0x76,0x6d /* ud2 ; .ascii "kvm" */
+
+#endif
diff --git a/arch/x86/include/asm/xen/interface.h
b/arch/x86/include/asm/xen/interface.h
index 62ca03ef5c65..9139b3e86316 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -379,12 +379,9 @@ struct xen_pmu_arch {
* Prefix forces emulation of some non-trapping instructions.
* Currently only CPUID.
*/
-#ifdef __ASSEMBLY__
-#define XEN_EMULATE_PREFIX .byte 0x0f,0x0b,0x78,0x65,0x6e ;
-#define XEN_CPUID XEN_EMULATE_PREFIX cpuid
-#else
-#define XEN_EMULATE_PREFIX ".byte 0x0f,0x0b,0x78,0x65,0x6e ; "
-#define XEN_CPUID XEN_EMULATE_PREFIX "cpuid"
-#endif
+#include
+
+#define XEN_EMULATE_PREFIX __ASM_FORM(.byte __XEN_EMULATE_PREFIX ;)
+#define XEN_CPUID XEN_EMULATE_PREFIX __ASM_FORM(cpuid)
#endif /* _ASM_X86_XEN_INTERFACE_H */
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 290c3c3efb87..5f8b0a60f48b 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -68,6 +68,7 @@
#include
#include
#include
+#include
#include
#define CREATE_TRACE_POINTS
@@ -5319,6 +5320,7 @@ EXPORT_SYMBOL_GPL(kvm_write_guest_virt_system);
int handle_ud(struct kvm_vcpu *vcpu)
{
+ static const char kvm_emulate_prefix[] = { __KVM_EMULATE_PREFIX };
int emul_type = EMULTYPE_TRAP_UD;
enum emulation_result er;
char sig[5]; /* ud2; .ascii "kvm" */
@@ -5327,7 +5329,7 @@ int handle_ud(struct kvm_vcpu *vcpu)
if (force_emulation_prefix &&
kvm_read_guest_virt(vcpu, kvm_get_linear_rip(vcpu),
sig, sizeof(sig), ) == 0 &&
- memcmp(sig, "\xf\xbkvm", sizeof(sig)) == 0) {
+ memcmp(sig, kvm_emulate_prefix, sizeof(sig)) == 0) {
kvm_rip_write(vcpu, kvm_rip_read(vcpu) + sizeof(sig));
emul_type = 0;
}
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH -tip v4 1/4] x86/asm: Allow to pass macros to __ASM_FORM()
Use __stringify() at __ASM_FORM() so that user can pass code including macros to __ASM_FORM(). Signed-off-by: Masami Hiramatsu --- arch/x86/include/asm/asm.h |8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/asm.h b/arch/x86/include/asm/asm.h index 3ff577c0b102..1b563f9167ea 100644 --- a/arch/x86/include/asm/asm.h +++ b/arch/x86/include/asm/asm.h @@ -7,9 +7,11 @@ # define __ASM_FORM_RAW(x) x # define __ASM_FORM_COMMA(x) x, #else -# define __ASM_FORM(x) " " #x " " -# define __ASM_FORM_RAW(x) #x -# define __ASM_FORM_COMMA(x) " " #x "," +#include + +# define __ASM_FORM(x) " " __stringify(x) " " +# define __ASM_FORM_RAW(x) __stringify(x) +# define __ASM_FORM_COMMA(x) " " __stringify(x) "," #endif #ifndef __x86_64__ ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH -tip v4 0/4] x86: kprobes: Prohibit kprobes on Xen/KVM emulate prefixes
Hi, Here is the 4th version of patches to handle Xen/KVM emulate prefix by x86 instruction decoder. These patches allow x86 instruction decoder to decode Xen and KVM emulate prefix correctly, and prohibit kprobes to probe on it. Previous version is here; https://lkml.kernel.org/r/156773433821.31441.2905951246664148487.stgit@devnote2 In this version, I added 2 patches, [1/4] fixes __ASM_FORM() to accept macros using __stringify(), [2/4] introduces new asm/emulate_prefix.h to initialize Xen and KVM emulate prefix at one place. [3/4] is updated to use new emulate_prefix.h and fix to add emulate_prefix.h to sync check list. This series can be applied on -tip master branch which has merged Josh's objtool/perf sharing common x86 insn decoder series. Thank you, --- Masami Hiramatsu (4): x86/asm: Allow to pass macros to __ASM_FORM() x86: xen: kvm: Gather the definition of emulate prefixes x86: xen: insn: Decode Xen and KVM emulate-prefix signature x86: kprobes: Prohibit probing on instruction which has emulate prefix arch/x86/include/asm/asm.h |8 -- arch/x86/include/asm/emulate_prefix.h | 14 +++ arch/x86/include/asm/insn.h |6 + arch/x86/include/asm/xen/interface.h| 11 +++-- arch/x86/kernel/kprobes/core.c |4 +++ arch/x86/kvm/x86.c |4 ++- arch/x86/lib/insn.c | 34 +++ tools/arch/x86/include/asm/emulate_prefix.h | 14 +++ tools/arch/x86/include/asm/insn.h |6 + tools/arch/x86/lib/insn.c | 34 +++ tools/objtool/sync-check.sh |3 ++ tools/perf/check-headers.sh |3 ++ 12 files changed, 128 insertions(+), 13 deletions(-) create mode 100644 arch/x86/include/asm/emulate_prefix.h create mode 100644 tools/arch/x86/include/asm/emulate_prefix.h -- Masami Hiramatsu (Linaro) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-unstable-smoke test] 141063: regressions - FAIL
On 06.09.2019 14:28, Andrew Cooper wrote: > On 06/09/2019 08:29, Jan Beulich wrote: >> On 06.09.2019 00:04, osstest service owner wrote: >>> flight 141063 xen-unstable-smoke real [real] >>> http://logs.test-lab.xenproject.org/osstest/logs/141063/ >>> >>> Regressions :-( >>> >>> Tests which did not succeed and are blocking, >>> including tests which could not be run: >>> build-amd64 6 xen-buildfail REGR. vs. >>> 141049 >> Looks like this currently fails about every other time, and >> >> /home/osstest/build.141063.build-amd64/xen/tools/firmware/../../tools/cross-install >> -m0644 -p xen-dir/xen-shim >> /home/osstest/build.141063.build-amd64/xen/dist/install/usr/local/lib/xen/boot/xen-shim >> install: cannot stat 'xen-dir/xen-shim': No such file or directory >> Makefile:48: recipe for target 'install' failed >> make[4]: Leaving directory >> '/home/osstest/build.141063.build-amd64/xen/tools/firmware' >> make[4]: *** [install] Error 1 >> >> suggests to me that the further amount of duct tape put in >> place by a342900d48 still wasn't enough. > > Right. I don't have time to investigate further. I'll revert the > original patches which caused this, as doing so will most likely resolve > the intermittent pv-shim test issues. Hmm, why did you also revert the follow-on Makefile adjustment? That was right, wasn't it? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Criteria for checking in core scheduling series
On 06/09/2019, 12:09, "George Dunlap" wrote: There was a discussion on the community call about the core scheduling series being developed by Juergen Gross [1]. The conclusion can be summarized as follows: * We normally wait to check in series until they are quite good -- all the i's dotted and all the t's crossed * This is for several reasons; primarily because once code gets checked in, it rarely gets looked at again. In particular, there's nothing stopping the submitter from neglecting to do important clean-ups, in spite of their best intentions; leaving the maintainer or the rest of the community to do it. * However, for particularly long, complicated series like the core scheduling series, this can have significant downsides. Rebasing a 60-patch branch regularly is a lot of churn for little value; and core parts of the series which are mostly complete are currently only getting sporadic dev testing rather than the wide range of testing they would get from being in staging. * XenServer and SuSE are both long-term community members with a strong incentive to maintain and improve the feature; so the risk of the feature being left for the community to maintian is relatively now. With all those things in mind, the conclusion was to lower the "check-in" threshold from what it normally is, in order to allow the series to be checked in in the near future, in enough time at least for the "default off" to be well-tested by the 4.13 release. The criteria we sketched out were: * All the patches still need appropriate Ack / R-b's * There should be reason to believe that the series will have little to no impact on "thread mode" (threads being the unit of scheduling; i.e., the status quo) WRT the second point, apparently XenServer have been testing the series regularly for some time, and are satisfied from a testing perspective that there is no significant degradation for the series when in "thread mode". So this would really be a recommendation / license to the various maintainers involved; primarily Dario, I think (since I probably won't have time to review the series). No decisions are official until discussed on xen-devel; so the decision will not be considered official until a few days have passed without objection. And of course, if anyone at the meeting had a different understanding of what was said, or has something to add, please do so. I believe the following people were on the community call and did NOT have objections when asked Sergey, Jan, Juergen, Andrew, George, Roger, Christopher Clark, Daniel P Smith, Rich (list may be incomplete) We are asking because key people have not been on the community call Regards Lars ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] tools/libs: put common Makefile parts into new libs.mk
The Makefile below tools/libs have a lot in common. Put those common parts into a new libs.mk and include that from the specific Makefiles. Signed-off-by: Juergen Gross --- V2: - include common Makefile via absolute path for not breaking stubdom --- tools/libs/call/Makefile | 86 ++- tools/libs/devicemodel/Makefile | 88 ++-- tools/libs/evtchn/Makefile| 86 ++- tools/libs/foreignmemory/Makefile | 86 ++- tools/libs/gnttab/Makefile| 86 ++- tools/libs/libs.mk| 95 +++ tools/libs/toolcore/Makefile | 85 +-- tools/libs/toollog/Makefile | 84 +- 8 files changed, 114 insertions(+), 582 deletions(-) create mode 100644 tools/libs/libs.mk diff --git a/tools/libs/call/Makefile b/tools/libs/call/Makefile index 6291e6dfe7..7f6dc3fcbd 100644 --- a/tools/libs/call/Makefile +++ b/tools/libs/call/Makefile @@ -3,11 +3,8 @@ include $(XEN_ROOT)/tools/Rules.mk MAJOR= 1 MINOR= 2 -SHLIB_LDFLAGS += -Wl,--version-script=libxencall.map - -CFLAGS += -Werror -Wmissing-prototypes -CFLAGS += -I./include $(CFLAGS_xeninclude) -CFLAGS += $(CFLAGS_libxentoollog) $(CFLAGS_libxentoolcore) +LIBNAME := call +USELIBS := toollog toolcore SRCS-y += core.c buffer.c SRCS-$(CONFIG_Linux) += linux.c @@ -16,84 +13,7 @@ SRCS-$(CONFIG_SunOS) += solaris.c SRCS-$(CONFIG_NetBSD) += netbsd.c SRCS-$(CONFIG_MiniOS) += minios.c -LIB_OBJS := $(patsubst %.c,%.o,$(SRCS-y)) -PIC_OBJS := $(patsubst %.c,%.opic,$(SRCS-y)) - -LIB := libxencall.a -ifneq ($(nosharedlibs),y) -LIB += libxencall.so -endif - -PKG_CONFIG := xencall.pc -PKG_CONFIG_VERSION := $(MAJOR).$(MINOR) - -ifneq ($(CONFIG_LIBXC_MINIOS),y) -PKG_CONFIG_INST := $(PKG_CONFIG) -$(PKG_CONFIG_INST): PKG_CONFIG_PREFIX = $(prefix) -$(PKG_CONFIG_INST): PKG_CONFIG_INCDIR = $(includedir) -$(PKG_CONFIG_INST): PKG_CONFIG_LIBDIR = $(libdir) -endif - -PKG_CONFIG_LOCAL := $(foreach pc,$(PKG_CONFIG),$(PKG_CONFIG_DIR)/$(pc)) +include $(XEN_ROOT)/tools/libs/libs.mk -$(PKG_CONFIG_LOCAL): PKG_CONFIG_PREFIX = $(XEN_ROOT) $(PKG_CONFIG_LOCAL): PKG_CONFIG_INCDIR = $(XEN_LIBXENCALL)/include -$(PKG_CONFIG_LOCAL): PKG_CONFIG_LIBDIR = $(CURDIR) $(PKG_CONFIG_LOCAL): PKG_CONFIG_CFLAGS_LOCAL = $(CFLAGS_xeninclude) - -.PHONY: all -all: build - -.PHONY: build -build: - $(MAKE) libs - -.PHONY: libs -libs: headers.chk $(LIB) $(PKG_CONFIG_INST) $(PKG_CONFIG_LOCAL) - -headers.chk: $(wildcard include/*.h) - -libxencall.a: $(LIB_OBJS) - $(AR) rc $@ $^ - -libxencall.so: libxencall.so.$(MAJOR) - $(SYMLINK_SHLIB) $< $@ -libxencall.so.$(MAJOR): libxencall.so.$(MAJOR).$(MINOR) - $(SYMLINK_SHLIB) $< $@ - -libxencall.so.$(MAJOR).$(MINOR): $(PIC_OBJS) libxencall.map - $(CC) $(LDFLAGS) $(PTHREAD_LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxencall.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $(PIC_OBJS) $(LDLIBS_libxentoollog) $(LDLIBS_libxentoolcore) $(APPEND_LDFLAGS) - -.PHONY: install -install: build - $(INSTALL_DIR) $(DESTDIR)$(libdir) - $(INSTALL_DIR) $(DESTDIR)$(includedir) - $(INSTALL_SHLIB) libxencall.so.$(MAJOR).$(MINOR) $(DESTDIR)$(libdir) - $(INSTALL_DATA) libxencall.a $(DESTDIR)$(libdir) - $(SYMLINK_SHLIB) libxencall.so.$(MAJOR).$(MINOR) $(DESTDIR)$(libdir)/libxencall.so.$(MAJOR) - $(SYMLINK_SHLIB) libxencall.so.$(MAJOR) $(DESTDIR)$(libdir)/libxencall.so - $(INSTALL_DATA) include/xencall.h $(DESTDIR)$(includedir) - $(INSTALL_DATA) xencall.pc $(DESTDIR)$(PKG_INSTALLDIR) - -.PHONY: uninstall -uninstall: - rm -f $(DESTDIR)$(PKG_INSTALLDIR)/xencall.pc - rm -f $(DESTDIR)$(includedir)/xencall.h - rm -f $(DESTDIR)$(libdir)/libxencall.so - rm -f $(DESTDIR)$(libdir)/libxencall.so.$(MAJOR) - rm -f $(DESTDIR)$(libdir)/libxencall.so.$(MAJOR).$(MINOR) - rm -f $(DESTDIR)$(libdir)/libxencall.a - -.PHONY: TAGS -TAGS: - etags -t *.c *.h - -.PHONY: clean -clean: - rm -rf *.rpm $(LIB) *~ $(DEPS_RM) $(LIB_OBJS) $(PIC_OBJS) - rm -f libxencall.so.$(MAJOR).$(MINOR) libxencall.so.$(MAJOR) - rm -f headers.chk - rm -f xencall.pc - -.PHONY: distclean -distclean: clean diff --git a/tools/libs/devicemodel/Makefile b/tools/libs/devicemodel/Makefile index 73cff6dbc4..61bfa35273 100644 --- a/tools/libs/devicemodel/Makefile +++ b/tools/libs/devicemodel/Makefile @@ -3,13 +3,8 @@ include $(XEN_ROOT)/tools/Rules.mk MAJOR= 1 MINOR= 3 -SHLIB_LDFLAGS += -Wl,--version-script=libxendevicemodel.map - -CFLAGS += -Werror -Wmissing-prototypes -CFLAGS += -I./include $(CFLAGS_xeninclude) -CFLAGS += $(CFLAGS_libxentoollog) -CFLAGS += $(CFLAGS_libxentoolcore) -CFLAGS += $(CFLAGS_libxencall) +LIBNAME := devicemodel +USELIBS := toollog toolcore call SRCS-y
[Xen-devel] [linux-4.4 test] 141062: regressions - FAIL
flight 141062 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/141062/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 140955 REGR. vs. 139698 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-multivcpu 8 host-ping-check-xen fail in 140955 pass in 141062 test-armhf-armhf-libvirt 19 leak-check/check fail in 140955 pass in 141062 test-armhf-armhf-libvirt-raw 10 debian-di-install fail in 140955 pass in 141062 test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail pass in 140955 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-xl-pvhv2-amd 12 guest-start fail never pass test-arm64-arm64-xl-credit1 7 xen-boot fail never pass test-arm64-arm64-xl 7 xen-boot fail never pass test-arm64-arm64-xl-seattle 7 xen-boot fail never pass test-arm64-arm64-xl-xsm 7 xen-boot fail never pass test-arm64-arm64-examine 8 reboot fail never pass test-amd64-amd64-xl-pvhv2-intel 12 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 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 7 xen-boot fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 7 xen-boot 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-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-qemut-win7-amd64 17 guest-stop fail 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-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-credit2 7 xen-boot fail never pass test-amd64-amd64-xl-qemut-ws16-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-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-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-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check
Re: [Xen-devel] [PATCH v2] swiotlb-xen: Convert to use macro
On Mon, Sep 2, 2019 at 2:04 PM Souptick Joarder wrote:
>
> Rather than using static int max_dma_bits, this
> can be coverted to use as macro.
>
> Signed-off-by: Souptick Joarder
> Reviewed-by: Juergen Gross
If it is still not late, can we get this patch in queue for 5.4 ?
> ---
> drivers/xen/swiotlb-xen.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index ae1df49..d1eced5 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -38,6 +38,7 @@
> #include
>
> #include
> +#define MAX_DMA_BITS 32
> /*
> * Used to do a quick range check in swiotlb_tbl_unmap_single and
> * swiotlb_tbl_sync_single_*, to see if the memory was in fact allocated by
> this
> @@ -114,8 +115,6 @@ static int is_xen_swiotlb_buffer(dma_addr_t dma_addr)
> return 0;
> }
>
> -static int max_dma_bits = 32;
> -
> static int
> xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs)
> {
> @@ -135,7 +134,7 @@ static int is_xen_swiotlb_buffer(dma_addr_t dma_addr)
> p + (i << IO_TLB_SHIFT),
> get_order(slabs << IO_TLB_SHIFT),
> dma_bits, _handle);
> - } while (rc && dma_bits++ < max_dma_bits);
> + } while (rc && dma_bits++ < MAX_DMA_BITS);
> if (rc)
> return rc;
>
> --
> 1.9.1
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-unstable-smoke test] 141063: regressions - FAIL
On 06/09/2019 08:29, Jan Beulich wrote: > On 06.09.2019 00:04, osstest service owner wrote: >> flight 141063 xen-unstable-smoke real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/141063/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including tests which could not be run: >> build-amd64 6 xen-buildfail REGR. vs. >> 141049 > Looks like this currently fails about every other time, and > > /home/osstest/build.141063.build-amd64/xen/tools/firmware/../../tools/cross-install > -m0644 -p xen-dir/xen-shim > /home/osstest/build.141063.build-amd64/xen/dist/install/usr/local/lib/xen/boot/xen-shim > install: cannot stat 'xen-dir/xen-shim': No such file or directory > Makefile:48: recipe for target 'install' failed > make[4]: Leaving directory > '/home/osstest/build.141063.build-amd64/xen/tools/firmware' > make[4]: *** [install] Error 1 > > suggests to me that the further amount of duct tape put in > place by a342900d48 still wasn't enough. Right. I don't have time to investigate further. I'll revert the original patches which caused this, as doing so will most likely resolve the intermittent pv-shim test issues. We can revisit this at some point in the future. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] RFC: Criteria for checking in core scheduling series
On 06/09/2019 12:09, George Dunlap wrote: > There was a discussion on the community call about the core scheduling > series being developed by Juergen Gross [1]. The conclusion can be > summarized as follows: > > * We normally wait to check in series until they are quite good -- all > the i's dotted and all the t's crossed > > * This is for several reasons; primarily because once code gets checked > in, it rarely gets looked at again. In particular, there's nothing > stopping the submitter from neglecting to do important clean-ups, in > spite of their best intentions; leaving the maintainer or the rest of > the community to do it. > > * However, for particularly long, complicated series like the core > scheduling series, this can have significant downsides. Rebasing a > 60-patch branch regularly is a lot of churn for little value; and core > parts of the series which are mostly complete are currently only getting > sporadic dev testing rather than the wide range of testing they would > get from being in staging. > > * XenServer and SuSE are both long-term community members with a strong > incentive to maintain and improve the feature; so the risk of the > feature being left for the community to maintian is relatively now. > > With all those things in mind, the conclusion was to lower the > "check-in" threshold from what it normally is, in order to allow the > series to be checked in in the near future, in enough time at least for > the "default off" to be well-tested by the 4.13 release. > > The criteria we sketched out were: > > * All the patches still need appropriate Ack / R-b's > > * There should be reason to believe that the series will have little to > no impact on "thread mode" (threads being the unit of scheduling; i.e., > the status quo) > > WRT the second point, apparently XenServer have been testing the series > regularly for some time, and are satisfied from a testing perspective > that there is no significant degradation for the series when in "thread > mode". To clarify, we've been testing core mode, and providing feedback on the xen-devel threads. We are currently organising an extended regression test to run in thread mode to increase the confidence of the previous bullet point. > So this would really be a recommendation / license to the various > maintainers involved; primarily Dario, I think (since I probably won't > have time to review the series). > > No decisions are official until discussed on xen-devel; so the decision > will not be considered official until a few days have passed without > objection. And of course, if anyone at the meeting had a different > understanding of what was said, or has something to add, please do so. No objection from me at all. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/shadow: fold p2m page accounting into sh_min_allocation()
On 05/09/2019 09:34, Jan Beulich wrote: > This is to make the function live up to the promise its name makes. And > it simplifies all callers. > > Suggested-by: Andrew Cooper > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper I haven't looked at the calculations in detail, but from an end code point of view, this is much better. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] IOMMU/x86: make page type checks consistent when mapping pages
On 06.09.2019 13:45, Roger Pau Monné wrote:
> On Fri, Sep 06, 2019 at 12:52:11PM +0200, Jan Beulich wrote:
>> On 06.09.2019 11:37, Roger Pau Monné wrote:
>>> On Wed, Jul 03, 2019 at 12:18:45PM +, Jan Beulich wrote:
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -829,13 +829,13 @@ guest_physmap_add_page(struct domain *d,
*
* Retain this property by grabbing a writable type ref and then
* dropping it immediately. The result will be pages that have a
- * writable type (and an IOMMU entry), but a count of 0 (such that
- * any guest-requested type changes succeed and remove the IOMMU
- * entry).
+ * writable type (and an IOMMU entry if necessary), but a count
of 0
+ * (such that any guest-requested type changes succeed and remove
the
+ * IOMMU entry).
*/
for ( i = 0; i < (1UL << page_order); ++i, ++page )
{
-if ( !need_iommu_pt_sync(d) )
+if ( !iommu_enabled )
>>>
>>> That's kind of a strong check for a domain that might never use the
>>> iommu at all. Isn't it fine to just rely on
>>> arch_iommu_populate_page_table finding non-writable pages and thus not
>>> adding them to the iommu page-tables?
>>
>> No - the code change here is to take care of page additions to
>> the domain after it has booted.
>
> Please bear with me, but AFAICT arch_iommu_populate_page_table could
> be used after the domain has booted if a pci device is hot plugged.
>
> If this is to deal with additions to domains having an iommu already
> enabled, isn't it enough to use need_iommu_pt_sync?
>
> That's going to return true for all PV domains, except for dom0 not
> running in strict mode, which is expected because in that case dom0
> already has the whole RAM mapped into the iommu page-tables?
Well, my previous reply wasn't precise enough, I guess. The change
really is about both cases: If the domain is already using an IOMMU,
need_iommu_pt_sync() would be enough indeed. If IOMMU use _may_ be
enabled later on, we need to transition pages out of their initial
PGT_none state right away. If we deferred this until the point
where the IOMMU gets enabled for the domain, we'd have to watch out
for PGT_none pages there, which would be extra hassle.
+{
+put_page_and_type(page);
+flush_flags |= IOMMUF_readable | IOMMUF_writable;
+}
+else if ( !rc )
+rc = -EBUSY;
>>>
>>> Is it fine to return an error here? AFAICT you could have a RO page
>>> shared with Xen with PGT_none, and not having an iommu mapping for it
>>> would be expected, hence returning an error seems wrong?
>>
>> No, pages shared with Xen don't live on d->page_list (which is what the
>> loop iterates over).
>
> So then there should be no PGT_none pages in d->page_list?
>
> The only user I can find of PGT_none is share_xen_page_with_guest.
Plus the implicit use when a page gets first added to a domain (by
setting ->u.inuse.type_info to zero).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] IOMMU/x86: make page type checks consistent when mapping pages
On Fri, Sep 06, 2019 at 12:52:11PM +0200, Jan Beulich wrote:
> On 06.09.2019 11:37, Roger Pau Monné wrote:
> > On Wed, Jul 03, 2019 at 12:18:45PM +, Jan Beulich wrote:
> >> --- a/xen/arch/x86/mm/p2m.c
> >> +++ b/xen/arch/x86/mm/p2m.c
> >> @@ -829,13 +829,13 @@ guest_physmap_add_page(struct domain *d,
> >>*
> >>* Retain this property by grabbing a writable type ref and then
> >>* dropping it immediately. The result will be pages that have a
> >> - * writable type (and an IOMMU entry), but a count of 0 (such that
> >> - * any guest-requested type changes succeed and remove the IOMMU
> >> - * entry).
> >> + * writable type (and an IOMMU entry if necessary), but a count
> >> of 0
> >> + * (such that any guest-requested type changes succeed and remove
> >> the
> >> + * IOMMU entry).
> >>*/
> >> for ( i = 0; i < (1UL << page_order); ++i, ++page )
> >> {
> >> -if ( !need_iommu_pt_sync(d) )
> >> +if ( !iommu_enabled )
> >
> > That's kind of a strong check for a domain that might never use the
> > iommu at all. Isn't it fine to just rely on
> > arch_iommu_populate_page_table finding non-writable pages and thus not
> > adding them to the iommu page-tables?
>
> No - the code change here is to take care of page additions to
> the domain after it has booted.
Please bear with me, but AFAICT arch_iommu_populate_page_table could
be used after the domain has booted if a pci device is hot plugged.
If this is to deal with additions to domains having an iommu already
enabled, isn't it enough to use need_iommu_pt_sync?
That's going to return true for all PV domains, except for dom0 not
running in strict mode, which is expected because in that case dom0
already has the whole RAM mapped into the iommu page-tables?
>
> >> --- a/xen/drivers/passthrough/iommu.c
> >> +++ b/xen/drivers/passthrough/iommu.c
> >> @@ -192,28 +192,46 @@ void __hwdom_init iommu_hwdom_init(struc
> >> unsigned int i = 0, flush_flags = 0;
> >> int rc = 0;
> >>
> >> +this_cpu(iommu_dont_flush_iotlb) = true;
> >> +
> >> page_list_for_each ( page, >page_list )
> >> {
> >> -unsigned long mfn = mfn_x(page_to_mfn(page));
> >> -unsigned long dfn = mfn_to_gmfn(d, mfn);
> >> -unsigned int mapping = IOMMUF_readable;
> >> -int ret;
> >> -
> >> -if ( ((page->u.inuse.type_info & PGT_count_mask) == 0) ||
> >> - ((page->u.inuse.type_info & PGT_type_mask)
> >> - == PGT_writable_page) )
> >> -mapping |= IOMMUF_writable;
> >> -
> >> -ret = iommu_map(d, _dfn(dfn), _mfn(mfn), 0, mapping,
> >> -_flags);
> >> -
> >> -if ( !rc )
> >> -rc = ret;
> >> +switch ( page->u.inuse.type_info & PGT_type_mask )
> >> +{
> >> +case PGT_none:
> >> +if ( is_pv_domain(d) )
> >> +{
> >> +ASSERT(!(page->u.inuse.type_info & PGT_count_mask));
> >> +if ( get_page_and_type(page, d, PGT_writable_page) )
> >
> > Could you add a comment that get_page_and_type will add an iommu
> > entry if succeeding?
>
> Well, yes, I could, but this would just re-state what the respective
> section of the big comment at the top of mm.c effectively says.
Oh, never mind then, it just took me some time to figure out why you
set iommu_dont_flush_iotlb without doing any _legacy iommu calls. I
then realized get_page_and_type was doing such calls.
> Anyway - as long as Paul's "remove late (on-demand) construction of
> IOMMU page tables" would go in any time soon, this will all become
> unnecessary anyway.
>
> >> +{
> >> +put_page_and_type(page);
> >> +flush_flags |= IOMMUF_readable | IOMMUF_writable;
> >> +}
> >> +else if ( !rc )
> >> +rc = -EBUSY;
> >
> > Is it fine to return an error here? AFAICT you could have a RO page
> > shared with Xen with PGT_none, and not having an iommu mapping for it
> > would be expected, hence returning an error seems wrong?
>
> No, pages shared with Xen don't live on d->page_list (which is what the
> loop iterates over).
So then there should be no PGT_none pages in d->page_list?
The only user I can find of PGT_none is share_xen_page_with_guest.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/boot: Don't explicitly map the VGA region as UC-
On 06/09/2019 12:06, Roger Pau Monné wrote: > On Thu, Sep 05, 2019 at 08:04:18PM +0100, Andrew Cooper wrote: >> All 64-bit capable processors use PAT, and with PAT, it is explicitly >> permitted to have mappings with a cacheability different to MTRRs. >> >> On a native system with a real legacy VGA region, MTRRs will cause the region >> to be UC-. When booting virtualised, this range may be RAM and not a legacy >> VGA region, at which point it wants to be WB. >> >> Use WB mapping in the pagetables, such that in systems without a legacy VGA >> region, the RAM between 0xa and 0xc doesn't become unnecesserily UC-. >> However, we still must use small pages to avoid the undefined behaviour >> caused >> by superpages crossing MTRRs of different cacheability. >> >> While adjusting the pagetable construction, switch from pfn to idx for >> consistency with all the other construction logic. >> >> Signed-off-by: Andrew Cooper > Reviewed-by: Roger Pau Monné > >> --- >> CC: Jan Beulich >> CC: Wei Liu >> CC: Roger Pau Monné >> >> As a future optimisation, Xen could rewrite l2_identmap with a superpage if >> it >> finds that MTRRs are disabled. However, this probably needs to wait until >> Xen >> no longer unconditionally assumes a legacy VGA region to be present in the >> e820 if it finds something other than a hole > Is that still the case? I remember dealing with it when working on the > shim, and I thought the code to unconditionally set a hole in > 0xa-0xc was removed. copy_e820_map() still has the broken logic. I don't recall exactly what state the proposed fixes were in, and I certainly don't have time to dust them off right now. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/shadow: fold p2m page accounting into sh_min_allocation()
On Thu, Sep 05, 2019 at 10:34:47AM +0200, Jan Beulich wrote: > This is to make the function live up to the promise its name makes. And > it simplifies all callers. > > Suggested-by: Andrew Cooper > Signed-off-by: Jan Beulich Reviewed-by: Roger Pau Monné Thanks. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] RFC: Criteria for checking in core scheduling series
There was a discussion on the community call about the core scheduling series being developed by Juergen Gross [1]. The conclusion can be summarized as follows: * We normally wait to check in series until they are quite good -- all the i's dotted and all the t's crossed * This is for several reasons; primarily because once code gets checked in, it rarely gets looked at again. In particular, there's nothing stopping the submitter from neglecting to do important clean-ups, in spite of their best intentions; leaving the maintainer or the rest of the community to do it. * However, for particularly long, complicated series like the core scheduling series, this can have significant downsides. Rebasing a 60-patch branch regularly is a lot of churn for little value; and core parts of the series which are mostly complete are currently only getting sporadic dev testing rather than the wide range of testing they would get from being in staging. * XenServer and SuSE are both long-term community members with a strong incentive to maintain and improve the feature; so the risk of the feature being left for the community to maintian is relatively now. With all those things in mind, the conclusion was to lower the "check-in" threshold from what it normally is, in order to allow the series to be checked in in the near future, in enough time at least for the "default off" to be well-tested by the 4.13 release. The criteria we sketched out were: * All the patches still need appropriate Ack / R-b's * There should be reason to believe that the series will have little to no impact on "thread mode" (threads being the unit of scheduling; i.e., the status quo) WRT the second point, apparently XenServer have been testing the series regularly for some time, and are satisfied from a testing perspective that there is no significant degradation for the series when in "thread mode". So this would really be a recommendation / license to the various maintainers involved; primarily Dario, I think (since I probably won't have time to review the series). No decisions are official until discussed on xen-devel; so the decision will not be considered official until a few days have passed without objection. And of course, if anyone at the meeting had a different understanding of what was said, or has something to add, please do so. Thanks, -George [1] https://patchew.org/Xen/20190809145833.1020-1-jgr...@suse.com/ ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/boot: Don't explicitly map the VGA region as UC-
On Thu, Sep 05, 2019 at 08:04:18PM +0100, Andrew Cooper wrote: > All 64-bit capable processors use PAT, and with PAT, it is explicitly > permitted to have mappings with a cacheability different to MTRRs. > > On a native system with a real legacy VGA region, MTRRs will cause the region > to be UC-. When booting virtualised, this range may be RAM and not a legacy > VGA region, at which point it wants to be WB. > > Use WB mapping in the pagetables, such that in systems without a legacy VGA > region, the RAM between 0xa and 0xc doesn't become unnecesserily UC-. > However, we still must use small pages to avoid the undefined behaviour caused > by superpages crossing MTRRs of different cacheability. > > While adjusting the pagetable construction, switch from pfn to idx for > consistency with all the other construction logic. > > Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné > --- > CC: Jan Beulich > CC: Wei Liu > CC: Roger Pau Monné > > As a future optimisation, Xen could rewrite l2_identmap with a superpage if it > finds that MTRRs are disabled. However, this probably needs to wait until Xen > no longer unconditionally assumes a legacy VGA region to be present in the > e820 if it finds something other than a hole Is that still the case? I remember dealing with it when working on the shim, and I thought the code to unconditionally set a hole in 0xa-0xc was removed. Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8 2/6] domain: introduce XEN_DOMCTL_CDF_iommu flag
> -Original Message- [snip] > > diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml > > index 35958b94d5..bdf3f2e395 100644 > > --- a/tools/ocaml/libs/xc/xenctrl.ml > > +++ b/tools/ocaml/libs/xc/xenctrl.ml > > @@ -56,7 +56,13 @@ type arch_domainconfig = > > | ARM of xen_arm_arch_domainconfig > > | X86 of xen_x86_arch_domainconfig > > > > -type domain_create_flag = CDF_HVM | CDF_HAP > > +type domain_create_flag = > > + | CDF_HVM > > + | CDF_HAP > > + | CDF_S3_INTEGRITY > > + | CDF_OOS_OFF > > + | CDF_XS_DOMAIN > > + | CDF_IOMMU > > This patch is only adding the last flag, but you are adding more here. I > understand that you are just re-syncing the type with Xen. IHMO, this > should belong in a separate patch as we may want to backport it. > > If backporting is not necessary, then the change should at least be > mentioned in the commit message as this seems a bit off-topic. > The apparently extraneous flag additions are because of the way that the code at http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/ocaml/libs/xc/xenctrl_stubs.c;hb=HEAD#l149 works. TL;DR the index of the item in the list needs to match the bit position in the flags field. Since you queried it I guess it'd better have a comment in the code. Paul > Cheers, > > [1] https://lists.xen.org/archives/html/xen-devel/2019-08/msg01974.html > > -- > Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] IOMMU/x86: make page type checks consistent when mapping pages
On 06.09.2019 11:37, Roger Pau Monné wrote:
> On Wed, Jul 03, 2019 at 12:18:45PM +, Jan Beulich wrote:
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -829,13 +829,13 @@ guest_physmap_add_page(struct domain *d,
>>*
>>* Retain this property by grabbing a writable type ref and then
>>* dropping it immediately. The result will be pages that have a
>> - * writable type (and an IOMMU entry), but a count of 0 (such that
>> - * any guest-requested type changes succeed and remove the IOMMU
>> - * entry).
>> + * writable type (and an IOMMU entry if necessary), but a count of 0
>> + * (such that any guest-requested type changes succeed and remove
>> the
>> + * IOMMU entry).
>>*/
>> for ( i = 0; i < (1UL << page_order); ++i, ++page )
>> {
>> -if ( !need_iommu_pt_sync(d) )
>> +if ( !iommu_enabled )
>
> That's kind of a strong check for a domain that might never use the
> iommu at all. Isn't it fine to just rely on
> arch_iommu_populate_page_table finding non-writable pages and thus not
> adding them to the iommu page-tables?
No - the code change here is to take care of page additions to
the domain after it has booted.
>> --- a/xen/drivers/passthrough/iommu.c
>> +++ b/xen/drivers/passthrough/iommu.c
>> @@ -192,28 +192,46 @@ void __hwdom_init iommu_hwdom_init(struc
>> unsigned int i = 0, flush_flags = 0;
>> int rc = 0;
>>
>> +this_cpu(iommu_dont_flush_iotlb) = true;
>> +
>> page_list_for_each ( page, >page_list )
>> {
>> -unsigned long mfn = mfn_x(page_to_mfn(page));
>> -unsigned long dfn = mfn_to_gmfn(d, mfn);
>> -unsigned int mapping = IOMMUF_readable;
>> -int ret;
>> -
>> -if ( ((page->u.inuse.type_info & PGT_count_mask) == 0) ||
>> - ((page->u.inuse.type_info & PGT_type_mask)
>> - == PGT_writable_page) )
>> -mapping |= IOMMUF_writable;
>> -
>> -ret = iommu_map(d, _dfn(dfn), _mfn(mfn), 0, mapping,
>> -_flags);
>> -
>> -if ( !rc )
>> -rc = ret;
>> +switch ( page->u.inuse.type_info & PGT_type_mask )
>> +{
>> +case PGT_none:
>> +if ( is_pv_domain(d) )
>> +{
>> +ASSERT(!(page->u.inuse.type_info & PGT_count_mask));
>> +if ( get_page_and_type(page, d, PGT_writable_page) )
>
> Could you add a comment that get_page_and_type will add an iommu
> entry if succeeding?
Well, yes, I could, but this would just re-state what the respective
section of the big comment at the top of mm.c effectively says.
Anyway - as long as Paul's "remove late (on-demand) construction of
IOMMU page tables" would go in any time soon, this will all become
unnecessary anyway.
>> +{
>> +put_page_and_type(page);
>> +flush_flags |= IOMMUF_readable | IOMMUF_writable;
>> +}
>> +else if ( !rc )
>> +rc = -EBUSY;
>
> Is it fine to return an error here? AFAICT you could have a RO page
> shared with Xen with PGT_none, and not having an iommu mapping for it
> would be expected, hence returning an error seems wrong?
No, pages shared with Xen don't live on d->page_list (which is what the
loop iterates over).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH -tip v3 1/2] x86: xen: insn: Decode Xen and KVM emulate-prefix signature
On Fri, 6 Sep 2019 09:34:36 +0200
Peter Zijlstra wrote:
> On Fri, Sep 06, 2019 at 10:45:48AM +0900, Masami Hiramatsu wrote:
>
> > diff --git a/arch/x86/include/asm/xen/interface.h
> > b/arch/x86/include/asm/xen/interface.h
> > index 62ca03ef5c65..fe33a9798708 100644
> > --- a/arch/x86/include/asm/xen/interface.h
> > +++ b/arch/x86/include/asm/xen/interface.h
> > @@ -379,12 +379,15 @@ struct xen_pmu_arch {
> > * Prefix forces emulation of some non-trapping instructions.
> > * Currently only CPUID.
> > */
> > +#include
> > +
> > #ifdef __ASSEMBLY__
> > -#define XEN_EMULATE_PREFIX .byte 0x0f,0x0b,0x78,0x65,0x6e ;
> > +#define XEN_EMULATE_PREFIX .byte __XEN_EMULATE_PREFIX ;
> > #define XEN_CPUID XEN_EMULATE_PREFIX cpuid
> > #else
> > -#define XEN_EMULATE_PREFIX ".byte 0x0f,0x0b,0x78,0x65,0x6e ; "
> > +#define XEN_EMULATE_PREFIX ".byte " __XEN_EMULATE_PREFIX_STR " ; "
> > #define XEN_CPUID XEN_EMULATE_PREFIX "cpuid"
> > +
> > #endif
>
> Possibly you can do something like:
>
> #define XEN_EMULATE_PREFIX__ASM_FORM(.byte __XEN_EMULATE_PREFIX ;)
> #define XEN_CPUID XEN_EMULATE_PREFIX __ASM_FORM(cpuid)
Oops, this doesn't work, since __ASM_FORM(x) uses #x directly
# define __ASM_FORM(x) " " #x " "
which doesn't expand "x" if x is a macro. We have to use __stringify
like
# include
# define __ASM_FORM(x) " " __stringify(x) " "
So this needs aonther patch in the series :)
Thank you,
--
Masami Hiramatsu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC Patch] xen/pt: Emulate FLR capability
On Fri, Sep 06, 2019 at 05:01:09PM +0800, Chao Gao wrote: > On Thu, Aug 29, 2019 at 12:21:11PM +0200, Roger Pau Monné wrote: > >On Thu, Aug 29, 2019 at 05:02:27PM +0800, Chao Gao wrote: > >> Currently, for a HVM on Xen, no reset method is virtualized. So in a VM's > >> perspective, assigned devices cannot be reset. But some devices rely on PCI > >> reset to recover from hardware hangs. When being assigned to a VM, those > >> devices cannot be reset and won't work any longer if a hardware hang > >> occurs. > >> We have to reboot VM to trigger PCI reset on host to recover the device. > >> > >> This patch exposes FLR capability to VMs if the assigned device can be > >> reset on > >> host. When VM initiates an FLR to a device, qemu cleans up the device > >> state, > >> (including disabling of intx and/or MSI and unmapping BARs from guest, > >> deleting > >> emulated registers), then initiate PCI reset through 'reset' knob under the > >> device's sysfs, finally initialize the device again. > > > >I think you likely need to deassign the device from the VM, perform > >the reset, and then assign the device again, so that there's no Xen > >internal state carried over prior to the reset? > > Yes. It is the safest way. But here I want to present the feature as FLR > (such that the device driver in guest can issue PCI reset whenever > needed and no change is needed to device driver). Current device > deassignment notifies guest that the device is going to be removed In which way does a guest get notified? AFAICT XEN_DOMCTL_deassign_device doesn't do any kind of guest notification, it just tears down the device. > It is not the standard PCI reset. Is it possible to make guest unaware > of the device deassignment to emulate a standard PCI reset? That would be my expectation. Such deassignment/assignment should be completely transparent from a guest PoV. My suggestion for doing the reassignment is to ensure there's no device state carried over. > In my mind, > we can expose do_pci_remove/add to qemu or rewrite them in qemu (but > don't remove the device from guest's PCI hierarchy). Do you think it is > the right direction? Doing all this cleanup without reassigning the device seems more complicated and likely to miss stuff to cleanup IMO, but as long as you can guarantee there's no state carried over from before the reset it should be fine. I think you also need some dom0 cooperation for this, so that for example the BARs are correctly re-positioned after the reset? Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] IOMMU/x86: make page type checks consistent when mapping pages
On Wed, Jul 03, 2019 at 12:18:45PM +, Jan Beulich wrote:
> There are currently three more or less different checks:
> - _get_page_type() adjusts the IOMMU mappings according to the new type
>alone,
> - arch_iommu_populate_page_table() wants just the type to be
>PGT_writable_page,
> - iommu_hwdom_init() additionally permits all other types with a type
>refcount of zero.
> The canonical one is in _get_page_type(), and as of XSA-288
> arch_iommu_populate_page_table() also has no need anymore to deal with
> PGT_none pages. In the PV Dom0 case, however, PGT_none pages are still
> necessary to consider, since in that case pages don't get handed to
> guest_physmap_add_entry(). Furthermore, the function so far also
> established r/o mappings, which is not in line with the rules set forth
> by the XSA-288 change.
>
> For arch_iommu_populate_page_table() to not encounter PGT_none pages
> anymore even in cases where the IOMMU gets enabled for a domain only
> when it is already running, replace the IOMMU dependency in
> guest_physmap_add_entry()'s handling of PV guests to check just the
> system wide state instead of the domain property.
>
> Unfortunately (partially) replacing the iommu_map() call in
> iommu_hwdom_init() implies resurrecting the flush suppression that got
> previously eliminated. Note that the call to iommu_map() can't be
> removed at this point in time - Dom0's initial allocation gets its page
> types set before iommu_hwdom_init() runs.
>
> Signed-off-by: Jan Beulich
> ---
> v3: Re-base.
> v2: Fix IOTLB flushing. Exclude PVH. Use type safe local variables.
>
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -829,13 +829,13 @@ guest_physmap_add_page(struct domain *d,
>*
>* Retain this property by grabbing a writable type ref and then
>* dropping it immediately. The result will be pages that have a
> - * writable type (and an IOMMU entry), but a count of 0 (such that
> - * any guest-requested type changes succeed and remove the IOMMU
> - * entry).
> + * writable type (and an IOMMU entry if necessary), but a count of 0
> + * (such that any guest-requested type changes succeed and remove the
> + * IOMMU entry).
>*/
> for ( i = 0; i < (1UL << page_order); ++i, ++page )
> {
> -if ( !need_iommu_pt_sync(d) )
> +if ( !iommu_enabled )
That's kind of a strong check for a domain that might never use the
iommu at all. Isn't it fine to just rely on
arch_iommu_populate_page_table finding non-writable pages and thus not
adding them to the iommu page-tables?
> /* nothing */;
> else if ( get_page_and_type(page, d, PGT_writable_page) )
> put_page_and_type(page);
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -192,28 +192,46 @@ void __hwdom_init iommu_hwdom_init(struc
> unsigned int i = 0, flush_flags = 0;
> int rc = 0;
>
> +this_cpu(iommu_dont_flush_iotlb) = true;
> +
> page_list_for_each ( page, >page_list )
> {
> -unsigned long mfn = mfn_x(page_to_mfn(page));
> -unsigned long dfn = mfn_to_gmfn(d, mfn);
> -unsigned int mapping = IOMMUF_readable;
> -int ret;
> -
> -if ( ((page->u.inuse.type_info & PGT_count_mask) == 0) ||
> - ((page->u.inuse.type_info & PGT_type_mask)
> - == PGT_writable_page) )
> -mapping |= IOMMUF_writable;
> -
> -ret = iommu_map(d, _dfn(dfn), _mfn(mfn), 0, mapping,
> -_flags);
> -
> -if ( !rc )
> -rc = ret;
> +switch ( page->u.inuse.type_info & PGT_type_mask )
> +{
> +case PGT_none:
> +if ( is_pv_domain(d) )
> +{
> +ASSERT(!(page->u.inuse.type_info & PGT_count_mask));
> +if ( get_page_and_type(page, d, PGT_writable_page) )
Could you add a comment that get_page_and_type will add an iommu
entry if succeeding?
> +{
> +put_page_and_type(page);
> +flush_flags |= IOMMUF_readable | IOMMUF_writable;
> +}
> +else if ( !rc )
> +rc = -EBUSY;
Is it fine to return an error here? AFAICT you could have a RO page
shared with Xen with PGT_none, and not having an iommu mapping for it
would be expected, hence returning an error seems wrong?
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 141058: regressions - FAIL
flight 141058 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/141058/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 12 guest-start fail REGR. vs. 140282 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 140282 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 140282 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 140282 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 140282 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 140282 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-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-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-libvirt-xsm 13 migrate-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-libvirt-xsm 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-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 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-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-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 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-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-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 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-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-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-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: qemuu74aa913fe62e54f4cb077df51346d6448d57494b baseline version: qemuuafd760539308a5524accf964107cdb1d54a059e3 Last test of basis 140282 2019-08-18 05:36:51 Z 19 days Failing since140361 2019-08-19 11:36:26 Z 17 days 21 attempts Testing same since 141058 2019-09-05 16:13:06 Z0 days1 attempts People who touched revisions under test: Alberto Garcia Aleksandar Markovic Alex Bennée Alexey Kardashevskiy Andrew Jeffery Andrey Shinkevich Anthony PERARD Aurelien Jarno BALATON Zoltan Bandan Das Bastian Koppelmann Carlo Marcelo
Re: [Xen-devel] [PATCH v8 6/6] introduce a 'passthrough' configuration option to xl.cfg...
> -Original Message- > From: Julien Grall > Sent: 06 September 2019 10:06 > To: Paul Durrant ; xen-devel@lists.xenproject.org > Cc: Jan Beulich ; Ian Jackson ; > Wei Liu ; > Andrew Cooper ; George Dunlap > ; Konrad Rzeszutek > Wilk ; Stefano Stabellini ; > Tim (Xen.org) > ; Anthony Perard ; Christian Lindig > ; David Scott ; Volodymyr > Babchuk > ; Roger Pau Monne > Subject: Re: [PATCH v8 6/6] introduce a 'passthrough' configuration option to > xl.cfg... > > Hi Paul, > > On 9/6/19 9:08 AM, Paul Durrant wrote: > >> -Original Message- > >> From: Julien Grall > >> Sent: 05 September 2019 21:28 > >> To: Paul Durrant ; xen-devel@lists.xenproject.org > >> Cc: Jan Beulich ; Ian Jackson ; > >> Wei Liu ; > >> Andrew Cooper ; George Dunlap > >> ; Konrad > Rzeszutek > >> Wilk ; Stefano Stabellini > >> ; Tim (Xen.org) > >> ; Anthony Perard ; Christian > >> Lindig > >> ; David Scott ; Volodymyr > >> Babchuk > >> ; Roger Pau Monne > >> Subject: Re: [PATCH v8 6/6] introduce a 'passthrough' configuration option > >> to xl.cfg... > >> > >> Hi, > >> > >> On 9/2/19 3:50 PM, Paul Durrant wrote: > >>> ...and hence the ability to disable IOMMU mappings, and control EPT > >>> sharing. > >>> > >>> This patch introduces a new 'libxl_passthrough' enumeration into > >>> libxl_domain_create_info. The value will be set by xl either when it > >>> parses > >>> a new 'passthrough' option in xl.cfg, or implicitly if there is > >>> passthrough > >>> hardware specified for the domain. > >>> > >>> If the value of the passthrough configuration option is 'disabled' then > >>> the XEN_DOMCTL_CDF_iommu flag will be clear in the xen_domctl_createdomain > >>> flags, thus allowing the toolstack to control whether the domain gets > >>> IOMMU mappings or not (where previously they were globally set). > >>> > >>> If the value of the passthrough configuration option is 'sync_pt' then > >>> a new 'iommu_opts' field in xen_domctl_createdomain will be set with the > >>> value XEN_DOMCTL_IOMMU_no_sharept. This will override the global default > >>> set in iommu_hap_pt_share, thus allowing the toolstack to control whether > >>> EPT sharing is used for the domain. > >>> > >>> NOTE: The 'iommu_memkb' overhead in libxl_domain_build_info will only be > >>> set to zero if passthrough is 'disabled'. It is not safe to set > >>> the > >>> overhead to zero in the 'share_pt' case because the toolstack has > >>> no > >>> means of knowing whether the hardware actually supports IOMMU page > >>> table sharing. > >>> > >>> Signed-off-by: Paul Durrant > >>> Reviewed-by: Jan Beulich > >>> --- > >>> Cc: Ian Jackson > >>> Cc: Wei Liu > >>> Cc: Andrew Cooper > >>> Cc: George Dunlap > >>> Cc: Julien Grall > >>> Cc: Konrad Rzeszutek Wilk > >>> Cc: Stefano Stabellini > >>> Cc: Tim Deegan , > >>> Cc: Anthony PERARD > >>> Cc: Christian Lindig > >>> Cc: David Scott > >>> Cc: Volodymyr Babchuk > >>> Cc: "Roger Pau Monné" > >>> > >>> Previously part of series > >>> https://lists.xenproject.org/archives/html/xen-devel/2019- > 07/msg02267.html > >>> > >>> v7: > >>>- Added missing breaks > >>>- Added missing ocaml binding changes > >>> > >>> v6: > >>>- Remove the libxl_physinfo() call since it's usefulness is limited to > >>> x86 > >>> > >>> v5: > >>>- Expand xen_domctl_createdomain flags field and hence bump interface > >>> version > >>>- Fix spelling mistakes in context line > >>> --- > >>>docs/man/xl.cfg.5.pod.in| 52 +++ > >>>tools/libxl/libxl.h | 5 + > >>>tools/libxl/libxl_create.c | 9 ++ > >>>tools/libxl/libxl_types.idl | 7 ++ > >>>tools/ocaml/libs/xc/xenctrl.ml | 4 + > >>>tools/ocaml/libs/xc/xenctrl.mli | 4 + > >>>tools/ocaml/libs/xc/xenctrl_stubs.c | 15 ++- > >>>tools/xl/xl_parse.c | 140 ++-- > >>>xen/arch/arm/domain.c | 10 +- > >>>xen/arch/x86/domain.c | 2 +- > >>>xen/common/domain.c | 7 ++ > >>>xen/common/domctl.c | 13 --- > >>>xen/drivers/passthrough/iommu.c | 13 ++- > >>>xen/include/public/domctl.h | 6 +- > >>>xen/include/xen/iommu.h | 19 ++-- > >>>15 files changed, 229 insertions(+), 77 deletions(-) > >>> > >>> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in > >>> index c99d40307e..fd35685e9e 100644 > >>> --- a/docs/man/xl.cfg.5.pod.in > >>> +++ b/docs/man/xl.cfg.5.pod.in > >>> @@ -605,6 +605,58 @@ option should only be used with a trusted device > >>> tree. > >>>Note that the partial device tree should avoid using the phandle 65000 > >>>which is reserved by the toolstack. > >>> > >>> +=item B > >>> + > >>> +Specify whether IOMMU mappings are enabled for the domain and hence > >>> whether > >>> +it will be enabled for passthrough hardware. Valid values for this option > >>>
Re: [Xen-devel] [PATCH v5 3/4] xen: refactor debugtrace data
On 06.09.19 11:10, Jan Beulich wrote:
On 06.09.2019 10:49, Juergen Gross wrote:
On 05.09.19 16:43, Jan Beulich wrote:
On 05.09.2019 16:36, Juergen Gross wrote:
On 05.09.19 14:46, Juergen Gross wrote:
On 05.09.19 14:37, Jan Beulich wrote:
On 05.09.2019 14:27, Juergen Gross wrote:
On 05.09.19 14:22, Jan Beulich wrote:
On 05.09.2019 14:12, Juergen Gross wrote:
On 05.09.19 14:01, Jan Beulich wrote:
On 05.09.2019 13:39, Juergen Gross wrote:
As a preparation for per-cpu buffers do a little refactoring of the
debugtrace data: put the needed buffer admin data into the buffer as
it will be needed for each buffer. In order not to limit buffer size
switch the related fields from unsigned int to unsigned long, as on
huge machines with RAM in the TB range it might be interesting to
support buffers >4GB.
Just as a further remark in this regard:
void debugtrace_printk(const char *fmt, ...)
{
static char buf[DEBUG_TRACE_ENTRY_SIZE];
- static unsigned int count, last_count, last_prd;
+ static unsigned int count, last_count;
How long do we think will it take until their wrapping will become
an issue with such huge buffers?
Count wrapping will not result in any misbehavior of tracing. With
per-cpu buffers it might result in ambiguity regarding sorting the
entries, but I guess chances are rather low this being a real issue.
BTW: wrapping of count is not related to buffer size, but to the
amount of trace data written.
Sure, but the chance of ambiguity increases with larger buffer sizes.
Well, better safe than sorry. Switching to unsigned long will rarely
hurt, so I'm going to do just that. The only downside will be some waste
of buffer space for very long running traces with huge amounts of
entries.
Hmm, true. Maybe we could get someone else's opinion on this - anyone?
TBH, I wouldn't be concerned about the buffer space. In case there are
really billions of entries, the difference between a 10-digit count
value and maybe a 15 digit one (and that is already a massive amount)
isn't that large. The average printed size of count with about
4 billion entries is 9.75 digits (and not just 5 :-) ).
Another option would be to let count wrap at e.g. 4 billion (or even 1
million) and add a wrap count. Each buffer struct would contain the
wrap count of the last entry, and when hitting a higher wrap count a
new entry like ("wrap %u->%u", old_wrap, new_wrap) would be printed.
This saves buffer space without loosing information.
This sounds quite neat.
I'm adding a new patch for that purpose, as it is adding a new feature.
Any preferences for the max value of count? I'm in favor of limiting it
to 6-digit numbers as those are much easier to compare by just looking
at them.
I'm not overly fussed; personally I'd probably wrap at 30 bits, making it
generally up to 8 digits, just very slightly going into the 9-digit range.
2^30 is a 10-digit number. :-)
But wrapping at 100.000.000 is fine, too, as it is just
if ( count == 1 )
and that is not required to be a nice binary number.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC Patch] xen/pt: Emulate FLR capability
> -Original Message- > From: Chao Gao > Sent: 06 September 2019 10:01 > To: Roger Pau Monne > Cc: xen-devel@lists.xenproject.org; qemu-de...@nongnu.org; Stefano Stabellini > ; Anthony Perard ; Paul > Durrant > ; Jan Beulich > Subject: Re: [RFC Patch] xen/pt: Emulate FLR capability > > On Thu, Aug 29, 2019 at 12:21:11PM +0200, Roger Pau Monné wrote: > >On Thu, Aug 29, 2019 at 05:02:27PM +0800, Chao Gao wrote: > >> Currently, for a HVM on Xen, no reset method is virtualized. So in a VM's > >> perspective, assigned devices cannot be reset. But some devices rely on PCI > >> reset to recover from hardware hangs. When being assigned to a VM, those > >> devices cannot be reset and won't work any longer if a hardware hang > >> occurs. > >> We have to reboot VM to trigger PCI reset on host to recover the device. > >> > >> This patch exposes FLR capability to VMs if the assigned device can be > >> reset on > >> host. When VM initiates an FLR to a device, qemu cleans up the device > >> state, > >> (including disabling of intx and/or MSI and unmapping BARs from guest, > >> deleting > >> emulated registers), then initiate PCI reset through 'reset' knob under the > >> device's sysfs, finally initialize the device again. > > > >I think you likely need to deassign the device from the VM, perform > >the reset, and then assign the device again, so that there's no Xen > >internal state carried over prior to the reset? > > Yes. It is the safest way. But here I want to present the feature as FLR > (such that the device driver in guest can issue PCI reset whenever > needed and no change is needed to device driver). Current device > deassignment notifies guest that the device is going to be removed > It is not the standard PCI reset. Is it possible to make guest unaware > of the device deassignment to emulate a standard PCI reset? It should be, I would have thought. QEMU emulates all config space so any config access by the guest would be unaffected by de-assignment. The BARs and interrupts would be unmapped... but that's what you'd want anyway. > In my mind, > we can expose do_pci_remove/add to qemu or rewrite them in qemu (but > don't remove the device from guest's PCI hierarchy). Do you think it is > the right direction? Long term I think we want to get pass-through emulation out of QEMU and into Xen. Paul > > Thanks > Chao ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH -tip v3 1/2] x86: xen: insn: Decode Xen and KVM emulate-prefix signature
On Fri, Sep 06, 2019 at 05:51:43PM +0900, Masami Hiramatsu wrote: > On Fri, 6 Sep 2019 17:45:19 +0900 > Masami Hiramatsu wrote: > > > > > > > How about we make this asm/virt_prefix.h or something and include: > > > > > > /* > > > * Virt escape sequences to trigger instruction emulation; > > > * ideally these would decode to 'whole' instruction and not destroy > > > * the instruction stream; sadly this is not true for the 'kvm' one :/ > > > */ > > > > > > #define __XEN_EMULATE_PREFIX 0x0f,0x0b,0x78,0x65,0x6e /* ud2 ; .ascii > > > "xen" */ > > > #define __KVM_EMULATE_PREFIX 0x0f,0x0b,0x6b,0x76,0x6d/* ud2 ; .ascii > > > "kvm" */ > > BTW, what should we call it, "emulate prefix" or "virt prefix"? > "virt prefix" sounds too generic to me. So I rather like emulate_prefix.h. Works for me; and yeah, just see what is best for the other things. I only started down that road because the Xen and KVM 'prefixes' were initialized so inconsistently. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 3/4] xen: refactor debugtrace data
On 06.09.2019 10:49, Juergen Gross wrote:
> On 05.09.19 16:43, Jan Beulich wrote:
>> On 05.09.2019 16:36, Juergen Gross wrote:
>>> On 05.09.19 14:46, Juergen Gross wrote:
On 05.09.19 14:37, Jan Beulich wrote:
> On 05.09.2019 14:27, Juergen Gross wrote:
>> On 05.09.19 14:22, Jan Beulich wrote:
>>> On 05.09.2019 14:12, Juergen Gross wrote:
On 05.09.19 14:01, Jan Beulich wrote:
> On 05.09.2019 13:39, Juergen Gross wrote:
>> As a preparation for per-cpu buffers do a little refactoring of the
>> debugtrace data: put the needed buffer admin data into the buffer as
>> it will be needed for each buffer. In order not to limit buffer size
>> switch the related fields from unsigned int to unsigned long, as on
>> huge machines with RAM in the TB range it might be interesting to
>> support buffers >4GB.
>
> Just as a further remark in this regard:
>
>> void debugtrace_printk(const char *fmt, ...)
>> {
>> static char buf[DEBUG_TRACE_ENTRY_SIZE];
>> - static unsigned int count, last_count, last_prd;
>> + static unsigned int count, last_count;
>
> How long do we think will it take until their wrapping will become
> an issue with such huge buffers?
Count wrapping will not result in any misbehavior of tracing. With
per-cpu buffers it might result in ambiguity regarding sorting the
entries, but I guess chances are rather low this being a real issue.
BTW: wrapping of count is not related to buffer size, but to the
amount of trace data written.
>>>
>>> Sure, but the chance of ambiguity increases with larger buffer sizes.
>>
>> Well, better safe than sorry. Switching to unsigned long will rarely
>> hurt, so I'm going to do just that. The only downside will be some waste
>> of buffer space for very long running traces with huge amounts of
>> entries.
>
> Hmm, true. Maybe we could get someone else's opinion on this - anyone?
TBH, I wouldn't be concerned about the buffer space. In case there are
really billions of entries, the difference between a 10-digit count
value and maybe a 15 digit one (and that is already a massive amount)
isn't that large. The average printed size of count with about
4 billion entries is 9.75 digits (and not just 5 :-) ).
>>>
>>> Another option would be to let count wrap at e.g. 4 billion (or even 1
>>> million) and add a wrap count. Each buffer struct would contain the
>>> wrap count of the last entry, and when hitting a higher wrap count a
>>> new entry like ("wrap %u->%u", old_wrap, new_wrap) would be printed.
>>> This saves buffer space without loosing information.
>>
>> This sounds quite neat.
>
> I'm adding a new patch for that purpose, as it is adding a new feature.
>
> Any preferences for the max value of count? I'm in favor of limiting it
> to 6-digit numbers as those are much easier to compare by just looking
> at them.
I'm not overly fussed; personally I'd probably wrap at 30 bits, making it
generally up to 8 digits, just very slightly going into the 9-digit range.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8 6/6] introduce a 'passthrough' configuration option to xl.cfg...
Hi Paul, On 9/6/19 9:08 AM, Paul Durrant wrote: -Original Message- From: Julien Grall Sent: 05 September 2019 21:28 To: Paul Durrant ; xen-devel@lists.xenproject.org Cc: Jan Beulich ; Ian Jackson ; Wei Liu ; Andrew Cooper ; George Dunlap ; Konrad Rzeszutek Wilk ; Stefano Stabellini ; Tim (Xen.org) ; Anthony Perard ; Christian Lindig ; David Scott ; Volodymyr Babchuk ; Roger Pau Monne Subject: Re: [PATCH v8 6/6] introduce a 'passthrough' configuration option to xl.cfg... Hi, On 9/2/19 3:50 PM, Paul Durrant wrote: ...and hence the ability to disable IOMMU mappings, and control EPT sharing. This patch introduces a new 'libxl_passthrough' enumeration into libxl_domain_create_info. The value will be set by xl either when it parses a new 'passthrough' option in xl.cfg, or implicitly if there is passthrough hardware specified for the domain. If the value of the passthrough configuration option is 'disabled' then the XEN_DOMCTL_CDF_iommu flag will be clear in the xen_domctl_createdomain flags, thus allowing the toolstack to control whether the domain gets IOMMU mappings or not (where previously they were globally set). If the value of the passthrough configuration option is 'sync_pt' then a new 'iommu_opts' field in xen_domctl_createdomain will be set with the value XEN_DOMCTL_IOMMU_no_sharept. This will override the global default set in iommu_hap_pt_share, thus allowing the toolstack to control whether EPT sharing is used for the domain. NOTE: The 'iommu_memkb' overhead in libxl_domain_build_info will only be set to zero if passthrough is 'disabled'. It is not safe to set the overhead to zero in the 'share_pt' case because the toolstack has no means of knowing whether the hardware actually supports IOMMU page table sharing. Signed-off-by: Paul Durrant Reviewed-by: Jan Beulich --- Cc: Ian Jackson Cc: Wei Liu Cc: Andrew Cooper Cc: George Dunlap Cc: Julien Grall Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan , Cc: Anthony PERARD Cc: Christian Lindig Cc: David Scott Cc: Volodymyr Babchuk Cc: "Roger Pau Monné" Previously part of series https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02267.html v7: - Added missing breaks - Added missing ocaml binding changes v6: - Remove the libxl_physinfo() call since it's usefulness is limited to x86 v5: - Expand xen_domctl_createdomain flags field and hence bump interface version - Fix spelling mistakes in context line --- docs/man/xl.cfg.5.pod.in| 52 +++ tools/libxl/libxl.h | 5 + tools/libxl/libxl_create.c | 9 ++ tools/libxl/libxl_types.idl | 7 ++ tools/ocaml/libs/xc/xenctrl.ml | 4 + tools/ocaml/libs/xc/xenctrl.mli | 4 + tools/ocaml/libs/xc/xenctrl_stubs.c | 15 ++- tools/xl/xl_parse.c | 140 ++-- xen/arch/arm/domain.c | 10 +- xen/arch/x86/domain.c | 2 +- xen/common/domain.c | 7 ++ xen/common/domctl.c | 13 --- xen/drivers/passthrough/iommu.c | 13 ++- xen/include/public/domctl.h | 6 +- xen/include/xen/iommu.h | 19 ++-- 15 files changed, 229 insertions(+), 77 deletions(-) diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in index c99d40307e..fd35685e9e 100644 --- a/docs/man/xl.cfg.5.pod.in +++ b/docs/man/xl.cfg.5.pod.in @@ -605,6 +605,58 @@ option should only be used with a trusted device tree. Note that the partial device tree should avoid using the phandle 65000 which is reserved by the toolstack. +=item B + +Specify whether IOMMU mappings are enabled for the domain and hence whether +it will be enabled for passthrough hardware. Valid values for this option +are: + +=over 4 + +=item B + +IOMMU mappings are disabled for the domain and so hardware may not be +passed through. + +This option is the default if no passthrough hardware is specified +in the domain's configuration. + +=item B + +This option means that IOMMU mappings will be synchronized with the +domain's P2M table as follows: + +For a PV domain, all writable pages assigned to the domain are identity +mapped by MFN in the IOMMU page table. Thus a device driver running in the +domain may program passthrough hardware for DMA using MFN values +(i.e. host/machine frame numbers) looked up in its P2M. + +For an HVM domain, all non-foreign RAM pages present in its P2M will be +mapped by GFN in the IOMMU page table. Thus a device driver running in the +domain may program passthrough hardware using GFN values (i.e. guest +physical frame numbers) without any further translation. + +This option is the default if the domain is PV and passthrough hardware +is specified in the configuration. + +This option is not available on Arm. I don't particularly like the idea to allow the user (or any external toolstack) to rely on
Re: [Xen-devel] [RFC Patch] xen/pt: Emulate FLR capability
On Thu, Aug 29, 2019 at 12:21:11PM +0200, Roger Pau Monné wrote: >On Thu, Aug 29, 2019 at 05:02:27PM +0800, Chao Gao wrote: >> Currently, for a HVM on Xen, no reset method is virtualized. So in a VM's >> perspective, assigned devices cannot be reset. But some devices rely on PCI >> reset to recover from hardware hangs. When being assigned to a VM, those >> devices cannot be reset and won't work any longer if a hardware hang occurs. >> We have to reboot VM to trigger PCI reset on host to recover the device. >> >> This patch exposes FLR capability to VMs if the assigned device can be reset >> on >> host. When VM initiates an FLR to a device, qemu cleans up the device state, >> (including disabling of intx and/or MSI and unmapping BARs from guest, >> deleting >> emulated registers), then initiate PCI reset through 'reset' knob under the >> device's sysfs, finally initialize the device again. > >I think you likely need to deassign the device from the VM, perform >the reset, and then assign the device again, so that there's no Xen >internal state carried over prior to the reset? Yes. It is the safest way. But here I want to present the feature as FLR (such that the device driver in guest can issue PCI reset whenever needed and no change is needed to device driver). Current device deassignment notifies guest that the device is going to be removed It is not the standard PCI reset. Is it possible to make guest unaware of the device deassignment to emulate a standard PCI reset? In my mind, we can expose do_pci_remove/add to qemu or rewrite them in qemu (but don't remove the device from guest's PCI hierarchy). Do you think it is the right direction? Thanks Chao ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH -tip v3 1/2] x86: xen: insn: Decode Xen and KVM emulate-prefix signature
On Fri, 6 Sep 2019 17:45:19 +0900 Masami Hiramatsu wrote: > > > > How about we make this asm/virt_prefix.h or something and include: > > > > /* > > * Virt escape sequences to trigger instruction emulation; > > * ideally these would decode to 'whole' instruction and not destroy > > * the instruction stream; sadly this is not true for the 'kvm' one :/ > > */ > > > > #define __XEN_EMULATE_PREFIX 0x0f,0x0b,0x78,0x65,0x6e /* ud2 ; .ascii > > "xen" */ > > #define __KVM_EMULATE_PREFIX 0x0f,0x0b,0x6b,0x76,0x6d /* ud2 ; .ascii > > "kvm" */ BTW, what should we call it, "emulate prefix" or "virt prefix"? "virt prefix" sounds too generic to me. So I rather like emulate_prefix.h. Thank you, -- Masami Hiramatsu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 3/4] xen: refactor debugtrace data
On 05.09.19 16:43, Jan Beulich wrote:
On 05.09.2019 16:36, Juergen Gross wrote:
On 05.09.19 14:46, Juergen Gross wrote:
On 05.09.19 14:37, Jan Beulich wrote:
On 05.09.2019 14:27, Juergen Gross wrote:
On 05.09.19 14:22, Jan Beulich wrote:
On 05.09.2019 14:12, Juergen Gross wrote:
On 05.09.19 14:01, Jan Beulich wrote:
On 05.09.2019 13:39, Juergen Gross wrote:
As a preparation for per-cpu buffers do a little refactoring of the
debugtrace data: put the needed buffer admin data into the buffer as
it will be needed for each buffer. In order not to limit buffer size
switch the related fields from unsigned int to unsigned long, as on
huge machines with RAM in the TB range it might be interesting to
support buffers >4GB.
Just as a further remark in this regard:
void debugtrace_printk(const char *fmt, ...)
{
static char buf[DEBUG_TRACE_ENTRY_SIZE];
- static unsigned int count, last_count, last_prd;
+ static unsigned int count, last_count;
How long do we think will it take until their wrapping will become
an issue with such huge buffers?
Count wrapping will not result in any misbehavior of tracing. With
per-cpu buffers it might result in ambiguity regarding sorting the
entries, but I guess chances are rather low this being a real issue.
BTW: wrapping of count is not related to buffer size, but to the
amount of trace data written.
Sure, but the chance of ambiguity increases with larger buffer sizes.
Well, better safe than sorry. Switching to unsigned long will rarely
hurt, so I'm going to do just that. The only downside will be some waste
of buffer space for very long running traces with huge amounts of
entries.
Hmm, true. Maybe we could get someone else's opinion on this - anyone?
TBH, I wouldn't be concerned about the buffer space. In case there are
really billions of entries, the difference between a 10-digit count
value and maybe a 15 digit one (and that is already a massive amount)
isn't that large. The average printed size of count with about
4 billion entries is 9.75 digits (and not just 5 :-) ).
Another option would be to let count wrap at e.g. 4 billion (or even 1
million) and add a wrap count. Each buffer struct would contain the
wrap count of the last entry, and when hitting a higher wrap count a
new entry like ("wrap %u->%u", old_wrap, new_wrap) would be printed.
This saves buffer space without loosing information.
This sounds quite neat.
I'm adding a new patch for that purpose, as it is adding a new feature.
Any preferences for the max value of count? I'm in favor of limiting it
to 6-digit numbers as those are much easier to compare by just looking
at them.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8 5/6] iommu: tidy up iommu_use_hap_pt() and need_iommu_pt_sync() macros
Hi Paul,
On 9/6/19 8:59 AM, Paul Durrant wrote:
-Original Message-
From: Julien Grall
Sent: 05 September 2019 20:38
To: Paul Durrant ; xen-devel@lists.xenproject.org
Cc: Jan Beulich ; Andrew Cooper ;
George Dunlap
; Ian Jackson ; Konrad
Rzeszutek Wilk
; Stefano Stabellini ; Tim (Xen.org)
;
Wei Liu ; Volodymyr Babchuk ; Roger
Pau Monne
Subject: Re: [PATCH v8 5/6] iommu: tidy up iommu_use_hap_pt() and
need_iommu_pt_sync() macros
Hi Paul,
On 9/2/19 3:50 PM, Paul Durrant wrote:
Thes macros really ought to live in the common xen/iommu.h header rather
then being distributed amongst architecture specific iommu headers and
xen/sched.h. This patch moves them there.
NOTE: Disabling 'sharept' in the command line iommu options should really
be hard error on ARM (as opposed to just being ignored), so define
'iommu_hap_pt_share' to be true for ARM then then gate parsing the
command line option on '#ifndef iommu_hap_pt_share'.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
Cc: Volodymyr Babchuk
Cc: "Roger Pau Monné"
Previously part of
https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02267.html
v7:
- Re-work the ARM handling of 'sharept' as suggested by Jan
- Make sure that need_iommu_pt_sync() always evaluates its argument
---
xen/drivers/passthrough/iommu.c | 8 +++-
xen/include/asm-arm/iommu.h | 3 ---
xen/include/asm-x86/iommu.h | 4
xen/include/xen/iommu.h | 19 ++-
xen/include/xen/sched.h | 6 --
5 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 4f71db95ea..aaf3b9fac0 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -49,7 +49,11 @@ int8_t __hwdom_initdata iommu_hwdom_reserved = -1;
* default until we find a good solution to resolve it.
*/
bool_t __read_mostly iommu_intpost;
-bool_t __read_mostly iommu_hap_pt_share = 1;
+
+#ifndef iommu_hap_pt_share
+bool __read_mostly iommu_hap_pt_share = true;
+#endif
+
bool_t __read_mostly iommu_debug;
bool_t __read_mostly amd_iommu_perdev_intremap = 1;
@@ -102,8 +106,10 @@ static int __init parse_iommu_param(const char *s)
iommu_hwdom_passthrough = val;
else if ( (val = parse_boolean("dom0-strict", s, ss)) >= 0 )
iommu_hwdom_strict = val;
+#ifndef iommu_hap_pt_share
else if ( (val = parse_boolean("sharept", s, ss)) >= 0 )
iommu_hap_pt_share = val;
+#endif
else
rc = -EINVAL;
diff --git a/xen/include/asm-arm/iommu.h b/xen/include/asm-arm/iommu.h
index 1577e83d2b..77a94b29eb 100644
--- a/xen/include/asm-arm/iommu.h
+++ b/xen/include/asm-arm/iommu.h
@@ -20,9 +20,6 @@ struct arch_iommu
void *priv;
};
-/* Always share P2M Table between the CPU and the IOMMU */
-#define iommu_use_hap_pt(d) is_iommu_enabled(d)
-
const struct iommu_ops *iommu_get_ops(void);
void iommu_set_ops(const struct iommu_ops *ops);
diff --git a/xen/include/asm-x86/iommu.h b/xen/include/asm-x86/iommu.h
index 5071afd6a5..85741f7c96 100644
--- a/xen/include/asm-x86/iommu.h
+++ b/xen/include/asm-x86/iommu.h
@@ -86,10 +86,6 @@ struct iommu_init_ops {
extern const struct iommu_init_ops *iommu_init_ops;
-/* Are we using the domain P2M table as its IOMMU pagetable? */
-#define iommu_use_hap_pt(d) \
-(hap_enabled(d) && is_iommu_enabled(d) && iommu_hap_pt_share)
-
void iommu_update_ire_from_apic(unsigned int apic, unsigned int reg,
unsigned int value);
unsigned int iommu_read_apic_from_ire(unsigned int apic, unsigned int reg);
int iommu_setup_hpet_msi(struct msi_desc *);
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 4b6871936c..87f9129b99 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -55,7 +55,13 @@ static inline bool_t dfn_eq(dfn_t x, dfn_t y)
extern bool_t iommu_enable, iommu_enabled;
extern bool_t force_iommu, iommu_verbose, iommu_igfx;
extern bool_t iommu_snoop, iommu_qinval, iommu_intremap, iommu_intpost;
-extern bool_t iommu_hap_pt_share;
+
+#ifdef CONFIG_ARM
+#define iommu_hap_pt_share true
+#else
+extern bool iommu_hap_pt_share;
+#endif
I don't particularly like #ifdef CONFIG_ in common header. How
about other arch? I can see two solutions:
1) Move the define in asm/iommu.h. This would require to move the
declaration a bit later and then protect as you did in iommu.c
2) Replace CONFIG_ARM with a new Kconfig selected by Arm only so far.
I had wondered about a Kconfig but I can't really think of a good name. How
about CONFIG_FORCE_PT_SHARE?
I would add "IOMMU" in the name just to make clear this is related to
IOMMU. So maybe CONFIG_IOMMU_FORCE_PT_SHARE.
Cheers,
--
Julien Grall
Re: [Xen-devel] [PATCH -tip v3 1/2] x86: xen: insn: Decode Xen and KVM emulate-prefix signature
On Fri, 6 Sep 2019 09:34:36 +0200
Peter Zijlstra wrote:
> On Fri, Sep 06, 2019 at 10:45:48AM +0900, Masami Hiramatsu wrote:
>
> > diff --git a/arch/x86/include/asm/xen/interface.h
> > b/arch/x86/include/asm/xen/interface.h
> > index 62ca03ef5c65..fe33a9798708 100644
> > --- a/arch/x86/include/asm/xen/interface.h
> > +++ b/arch/x86/include/asm/xen/interface.h
> > @@ -379,12 +379,15 @@ struct xen_pmu_arch {
> > * Prefix forces emulation of some non-trapping instructions.
> > * Currently only CPUID.
> > */
> > +#include
> > +
> > #ifdef __ASSEMBLY__
> > -#define XEN_EMULATE_PREFIX .byte 0x0f,0x0b,0x78,0x65,0x6e ;
> > +#define XEN_EMULATE_PREFIX .byte __XEN_EMULATE_PREFIX ;
> > #define XEN_CPUID XEN_EMULATE_PREFIX cpuid
> > #else
> > -#define XEN_EMULATE_PREFIX ".byte 0x0f,0x0b,0x78,0x65,0x6e ; "
> > +#define XEN_EMULATE_PREFIX ".byte " __XEN_EMULATE_PREFIX_STR " ; "
> > #define XEN_CPUID XEN_EMULATE_PREFIX "cpuid"
> > +
> > #endif
>
> Possibly you can do something like:
>
> #define XEN_EMULATE_PREFIX__ASM_FORM(.byte __XEN_EMULATE_PREFIX ;)
> #define XEN_CPUID XEN_EMULATE_PREFIX __ASM_FORM(cpuid)
Hmm, OK. But should I split this change from insn decoder change?
>
> > #endif /* _ASM_X86_XEN_INTERFACE_H */
> > diff --git a/arch/x86/include/asm/xen/prefix.h
> > b/arch/x86/include/asm/xen/prefix.h
> > new file mode 100644
> > index ..f901be0d7a95
> > --- /dev/null
> > +++ b/arch/x86/include/asm/xen/prefix.h
> > @@ -0,0 +1,10 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef _TOOLS_ASM_X86_XEN_PREFIX_H
> > +#define _TOOLS_ASM_X86_XEN_PREFIX_H
> > +
> > +#include
> > +
> > +#define __XEN_EMULATE_PREFIX 0x0f,0x0b,0x78,0x65,0x6e
> > +#define __XEN_EMULATE_PREFIX_STR __stringify(__XEN_EMULATE_PREFIX)
> > +
> > +#endif
>
> How about we make this asm/virt_prefix.h or something and include:
>
> /*
> * Virt escape sequences to trigger instruction emulation;
> * ideally these would decode to 'whole' instruction and not destroy
> * the instruction stream; sadly this is not true for the 'kvm' one :/
> */
>
> #define __XEN_EMULATE_PREFIX 0x0f,0x0b,0x78,0x65,0x6e /* ud2 ; .ascii "xen"
> */
> #define __KVM_EMULATE_PREFIX 0x0f,0x0b,0x6b,0x76,0x6d/* ud2 ; .ascii
> "kvm" */
OK, and in that case I think we should do this in separated patch from
this change.
>
> > diff --git a/arch/x86/lib/insn.c b/arch/x86/lib/insn.c
> > index 0b5862ba6a75..b7eb50187db9 100644
> > --- a/arch/x86/lib/insn.c
> > +++ b/arch/x86/lib/insn.c
>
> > @@ -58,6 +61,37 @@ void insn_init(struct insn *insn, const void *kaddr, int
> > buf_len, int x86_64)
> > insn->addr_bytes = 4;
> > }
> >
> > +static const insn_byte_t xen_prefix[] = { __XEN_EMULATE_PREFIX };
> > +/* See handle_ud()@arch/x86/kvm/x86.c */
> > +static const insn_byte_t kvm_prefix[] = "\xf\xbkvm";
>
> Then you can make this consistent; maybe even something like:
>
> static const insn_byte_t *virt_prefix[] = {
> { __XEN_EMULATE_PREFIX },
> { __KVM_EMULATE_PREFIX },
> { NULL },
> };
>
> And then change emulate_prefix_size to emulate_prefix_index ?
Hmm, how we can get the length of those emulate prefixes?
For struct insn, since the size information is important, other
sub fields have "nbyte" field so that caller can find the actual
bytes from original byte stream.
Maybe we can have struct emulate_prefix { .nbyte, .type }; and
define enum etc.. but for me, it seems a bit over engineering.
(since no one use that feature)
Thank you,
--
Masami Hiramatsu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8 6/6] introduce a 'passthrough' configuration option to xl.cfg...
> -Original Message- > From: Julien Grall > Sent: 05 September 2019 21:28 > To: Paul Durrant ; xen-devel@lists.xenproject.org > Cc: Jan Beulich ; Ian Jackson ; > Wei Liu ; > Andrew Cooper ; George Dunlap > ; Konrad Rzeszutek > Wilk ; Stefano Stabellini ; > Tim (Xen.org) > ; Anthony Perard ; Christian Lindig > ; David Scott ; Volodymyr > Babchuk > ; Roger Pau Monne > Subject: Re: [PATCH v8 6/6] introduce a 'passthrough' configuration option to > xl.cfg... > > Hi, > > On 9/2/19 3:50 PM, Paul Durrant wrote: > > ...and hence the ability to disable IOMMU mappings, and control EPT > > sharing. > > > > This patch introduces a new 'libxl_passthrough' enumeration into > > libxl_domain_create_info. The value will be set by xl either when it parses > > a new 'passthrough' option in xl.cfg, or implicitly if there is passthrough > > hardware specified for the domain. > > > > If the value of the passthrough configuration option is 'disabled' then > > the XEN_DOMCTL_CDF_iommu flag will be clear in the xen_domctl_createdomain > > flags, thus allowing the toolstack to control whether the domain gets > > IOMMU mappings or not (where previously they were globally set). > > > > If the value of the passthrough configuration option is 'sync_pt' then > > a new 'iommu_opts' field in xen_domctl_createdomain will be set with the > > value XEN_DOMCTL_IOMMU_no_sharept. This will override the global default > > set in iommu_hap_pt_share, thus allowing the toolstack to control whether > > EPT sharing is used for the domain. > > > > NOTE: The 'iommu_memkb' overhead in libxl_domain_build_info will only be > >set to zero if passthrough is 'disabled'. It is not safe to set the > >overhead to zero in the 'share_pt' case because the toolstack has no > >means of knowing whether the hardware actually supports IOMMU page > >table sharing. > > > > Signed-off-by: Paul Durrant > > Reviewed-by: Jan Beulich > > --- > > Cc: Ian Jackson > > Cc: Wei Liu > > Cc: Andrew Cooper > > Cc: George Dunlap > > Cc: Julien Grall > > Cc: Konrad Rzeszutek Wilk > > Cc: Stefano Stabellini > > Cc: Tim Deegan > > Cc: Anthony PERARD > > Cc: Christian Lindig > > Cc: David Scott > > Cc: Volodymyr Babchuk > > Cc: "Roger Pau Monné" > > > > Previously part of series > > https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02267.html > > > > v7: > > - Added missing breaks > > - Added missing ocaml binding changes > > > > v6: > > - Remove the libxl_physinfo() call since it's usefulness is limited to x86 > > > > v5: > > - Expand xen_domctl_createdomain flags field and hence bump interface > > version > > - Fix spelling mistakes in context line > > --- > > docs/man/xl.cfg.5.pod.in| 52 +++ > > tools/libxl/libxl.h | 5 + > > tools/libxl/libxl_create.c | 9 ++ > > tools/libxl/libxl_types.idl | 7 ++ > > tools/ocaml/libs/xc/xenctrl.ml | 4 + > > tools/ocaml/libs/xc/xenctrl.mli | 4 + > > tools/ocaml/libs/xc/xenctrl_stubs.c | 15 ++- > > tools/xl/xl_parse.c | 140 ++-- > > xen/arch/arm/domain.c | 10 +- > > xen/arch/x86/domain.c | 2 +- > > xen/common/domain.c | 7 ++ > > xen/common/domctl.c | 13 --- > > xen/drivers/passthrough/iommu.c | 13 ++- > > xen/include/public/domctl.h | 6 +- > > xen/include/xen/iommu.h | 19 ++-- > > 15 files changed, 229 insertions(+), 77 deletions(-) > > > > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in > > index c99d40307e..fd35685e9e 100644 > > --- a/docs/man/xl.cfg.5.pod.in > > +++ b/docs/man/xl.cfg.5.pod.in > > @@ -605,6 +605,58 @@ option should only be used with a trusted device tree. > > Note that the partial device tree should avoid using the phandle 65000 > > which is reserved by the toolstack. > > > > +=item B > > + > > +Specify whether IOMMU mappings are enabled for the domain and hence whether > > +it will be enabled for passthrough hardware. Valid values for this option > > +are: > > + > > +=over 4 > > + > > +=item B > > + > > +IOMMU mappings are disabled for the domain and so hardware may not be > > +passed through. > > + > > +This option is the default if no passthrough hardware is specified > > +in the domain's configuration. > > + > > +=item B > > + > > +This option means that IOMMU mappings will be synchronized with the > > +domain's P2M table as follows: > > + > > +For a PV domain, all writable pages assigned to the domain are identity > > +mapped by MFN in the IOMMU page table. Thus a device driver running in the > > +domain may program passthrough hardware for DMA using MFN values > > +(i.e. host/machine frame numbers) looked up in its P2M. > > + > > +For an HVM domain, all non-foreign RAM pages present in its P2M will be > > +mapped by GFN in the IOMMU page table. Thus a device driver running in the >
Re: [Xen-devel] [PATCH v8 6/6] introduce a 'passthrough' configuration option to xl.cfg...
> -Original Message-
> From: Julien Grall
> Sent: 05 September 2019 20:59
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Ian Jackson ;
> Wei Liu ;
> Andrew Cooper ; George Dunlap
> ; Konrad Rzeszutek
> Wilk ; Stefano Stabellini ;
> Tim (Xen.org)
> ; Anthony Perard ; Christian Lindig
> ; David Scott ; Volodymyr
> Babchuk
> ; Roger Pau Monne
> Subject: Re: [PATCH v8 6/6] introduce a 'passthrough' configuration option to
> xl.cfg...
>
> Hi,
>
> On 9/2/19 3:50 PM, Paul Durrant wrote:
> > @@ -263,9 +263,17 @@ struct domain_iommu {
> > DECLARE_BITMAP(features, IOMMU_FEAT_count);
> >
> > /*
> > - * Does the guest reqire mappings to be synchonized, to maintain
> > - * the default dfn == pfn map. (See comment on dfn at the top of
> > - * include/xen/mm.h).
> > + * Does the guest share HAP mapping with the IOMMU? This is always
> > + * true for ARM systems and may be true for x86 systems where the
> > + * the hardware is capable.
> > + */
>
> I am worried that such comment may rot over the time. For instance, if
> we either add a new architecture or decide to stop sharing PT on Arm.
>
> I vaguely recall some potential issues with the MSI doorbells that would
> require us to unshare the PT when they will be supported in guest.
>
> I would suggest to either refers to the implementation of
> iommu_use_hap_pt() or drop completely the second sentence.
Ok, I'll just drop the sentence.
Paul
>
> > +bool hap_pt_share;
> > +
> > +/*
> > + * Does the guest require mappings to be synchronized, to maintain
> > + * the default dfn == pfn map? (See comment on dfn at the top of
> > + * include/xen/mm.h). Note that hap_pt_share == false does not
> > + * necessarily imply this is true.
> >*/
> > bool need_sync;
> > };
> > @@ -275,8 +283,7 @@ struct domain_iommu {
> > #define iommu_clear_feature(d, f) clear_bit(f, dom_iommu(d)->features)
> >
> > /* Are we using the domain P2M table as its IOMMU pagetable? */
> > -#define iommu_use_hap_pt(d) \
> > -(hap_enabled(d) && is_iommu_enabled(d) && iommu_hap_pt_share)
> > +#define iommu_use_hap_pt(d) (dom_iommu(d)->hap_pt_share)
> >
> > /* Does the IOMMU pagetable need to be kept synchronized with the P2M */
> > #ifdef CONFIG_HAS_PASSTHROUGH
> >
>
> Cheers,
>
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8 5/6] iommu: tidy up iommu_use_hap_pt() and need_iommu_pt_sync() macros
> -Original Message-
> From: Julien Grall
> Sent: 05 September 2019 20:38
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Konrad
> Rzeszutek Wilk
> ; Stefano Stabellini ; Tim
> (Xen.org) ;
> Wei Liu ; Volodymyr Babchuk ; Roger
> Pau Monne
>
> Subject: Re: [PATCH v8 5/6] iommu: tidy up iommu_use_hap_pt() and
> need_iommu_pt_sync() macros
>
> Hi Paul,
>
> On 9/2/19 3:50 PM, Paul Durrant wrote:
> > Thes macros really ought to live in the common xen/iommu.h header rather
> > then being distributed amongst architecture specific iommu headers and
> > xen/sched.h. This patch moves them there.
> >
> > NOTE: Disabling 'sharept' in the command line iommu options should really
> >be hard error on ARM (as opposed to just being ignored), so define
> >'iommu_hap_pt_share' to be true for ARM then then gate parsing the
> >command line option on '#ifndef iommu_hap_pt_share'.
> >
> > Signed-off-by: Paul Durrant
> > Reviewed-by: Jan Beulich
> > ---
> > Cc: Andrew Cooper
> > Cc: George Dunlap
> > Cc: Ian Jackson
> > Cc: Julien Grall
> > Cc: Konrad Rzeszutek Wilk
> > Cc: Stefano Stabellini
> > Cc: Tim Deegan
> > Cc: Wei Liu
> > Cc: Volodymyr Babchuk
> > Cc: "Roger Pau Monné"
> >
> > Previously part of
> > https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02267.html
> >
> > v7:
> > - Re-work the ARM handling of 'sharept' as suggested by Jan
> > - Make sure that need_iommu_pt_sync() always evaluates its argument
> > ---
> > xen/drivers/passthrough/iommu.c | 8 +++-
> > xen/include/asm-arm/iommu.h | 3 ---
> > xen/include/asm-x86/iommu.h | 4
> > xen/include/xen/iommu.h | 19 ++-
> > xen/include/xen/sched.h | 6 --
> > 5 files changed, 25 insertions(+), 15 deletions(-)
> >
> > diff --git a/xen/drivers/passthrough/iommu.c
> > b/xen/drivers/passthrough/iommu.c
> > index 4f71db95ea..aaf3b9fac0 100644
> > --- a/xen/drivers/passthrough/iommu.c
> > +++ b/xen/drivers/passthrough/iommu.c
> > @@ -49,7 +49,11 @@ int8_t __hwdom_initdata iommu_hwdom_reserved = -1;
> >* default until we find a good solution to resolve it.
> >*/
> > bool_t __read_mostly iommu_intpost;
> > -bool_t __read_mostly iommu_hap_pt_share = 1;
> > +
> > +#ifndef iommu_hap_pt_share
> > +bool __read_mostly iommu_hap_pt_share = true;
> > +#endif
> > +
> > bool_t __read_mostly iommu_debug;
> > bool_t __read_mostly amd_iommu_perdev_intremap = 1;
> >
> > @@ -102,8 +106,10 @@ static int __init parse_iommu_param(const char *s)
> > iommu_hwdom_passthrough = val;
> > else if ( (val = parse_boolean("dom0-strict", s, ss)) >= 0 )
> > iommu_hwdom_strict = val;
> > +#ifndef iommu_hap_pt_share
> > else if ( (val = parse_boolean("sharept", s, ss)) >= 0 )
> > iommu_hap_pt_share = val;
> > +#endif
> > else
> > rc = -EINVAL;
> >
> > diff --git a/xen/include/asm-arm/iommu.h b/xen/include/asm-arm/iommu.h
> > index 1577e83d2b..77a94b29eb 100644
> > --- a/xen/include/asm-arm/iommu.h
> > +++ b/xen/include/asm-arm/iommu.h
> > @@ -20,9 +20,6 @@ struct arch_iommu
> > void *priv;
> > };
> >
> > -/* Always share P2M Table between the CPU and the IOMMU */
> > -#define iommu_use_hap_pt(d) is_iommu_enabled(d)
> > -
> > const struct iommu_ops *iommu_get_ops(void);
> > void iommu_set_ops(const struct iommu_ops *ops);
> >
> > diff --git a/xen/include/asm-x86/iommu.h b/xen/include/asm-x86/iommu.h
> > index 5071afd6a5..85741f7c96 100644
> > --- a/xen/include/asm-x86/iommu.h
> > +++ b/xen/include/asm-x86/iommu.h
> > @@ -86,10 +86,6 @@ struct iommu_init_ops {
> >
> > extern const struct iommu_init_ops *iommu_init_ops;
> >
> > -/* Are we using the domain P2M table as its IOMMU pagetable? */
> > -#define iommu_use_hap_pt(d) \
> > -(hap_enabled(d) && is_iommu_enabled(d) && iommu_hap_pt_share)
> > -
> > void iommu_update_ire_from_apic(unsigned int apic, unsigned int reg,
> > unsigned int value);
> > unsigned int iommu_read_apic_from_ire(unsigned int apic, unsigned int
> > reg);
> > int iommu_setup_hpet_msi(struct msi_desc *);
> > diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
> > index 4b6871936c..87f9129b99 100644
> > --- a/xen/include/xen/iommu.h
> > +++ b/xen/include/xen/iommu.h
> > @@ -55,7 +55,13 @@ static inline bool_t dfn_eq(dfn_t x, dfn_t y)
> > extern bool_t iommu_enable, iommu_enabled;
> > extern bool_t force_iommu, iommu_verbose, iommu_igfx;
> > extern bool_t iommu_snoop, iommu_qinval, iommu_intremap, iommu_intpost;
> > -extern bool_t iommu_hap_pt_share;
> > +
> > +#ifdef CONFIG_ARM
> > +#define iommu_hap_pt_share true
> > +#else
> > +extern bool iommu_hap_pt_share;
> > +#endif
>
> I don't particularly like #ifdef CONFIG_ in common header. How
> about other arch? I can see two solutions:
>
> 1) Move the define in asm/iommu.h. This would require to
Re: [Xen-devel] [PATCH v8 4/6] remove late (on-demand) construction of IOMMU page tables
> -Original Message-
> From: Julien Grall
> Sent: 05 September 2019 21:21
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Alexandru Isaila ; Razvan Cojocaru
> ; Jan
> Beulich ; Stefano Stabellini ;
> Volodymyr Babchuk
> ; Andrew Cooper ;
> George Dunlap
> ; Ian Jackson ; Konrad
> Rzeszutek Wilk
> ; Tim (Xen.org) ; Wei Liu
> ; Roger Pau Monne
> ; Tamas K Lengyel ; Petre Pircalabu
>
> Subject: Re: [PATCH v8 4/6] remove late (on-demand) construction of IOMMU
> page tables
>
> Hi,
>
> On 9/2/19 3:50 PM, Paul Durrant wrote:
> > diff --git a/tools/libxl/libxl_mem.c b/tools/libxl/libxl_mem.c
> > index 448a2af8fd..fd6f33312e 100644
> > --- a/tools/libxl/libxl_mem.c
> > +++ b/tools/libxl/libxl_mem.c
> > @@ -461,15 +461,17 @@ int libxl_domain_need_memory(libxl_ctx *ctx,
> > if (rc) goto out;
> >
> > *need_memkb = b_info->target_memkb;
> > +*need_memkb += b_info->shadow_memkb + b_info->iommu_memkb;
>
> AFAICT, iommu_memkb will be non-0 even when the IOMMU share the
> page-table with the CPUs. If so, why is this required for that case?
The toostack can't know about shared EPT as there's no mechanism to tell it.
Once patch #6 goes in though, the toolstack will be able to select shared and
forego the overhead. However, I've just realized that of course this means that
the domain may fail due to lack of resources on a host which doesn't support
shared EPT so I think I'm going to have to add add extra info (following on
from Roger's recent patch) so the toolstack can know whether shared EPT is
available.
Paul
>
> > +
> > switch (b_info->type) {
> > case LIBXL_DOMAIN_TYPE_PVH:
> > case LIBXL_DOMAIN_TYPE_HVM:
> > -*need_memkb += b_info->shadow_memkb + LIBXL_HVM_EXTRA_MEMORY;
> > +*need_memkb += LIBXL_HVM_EXTRA_MEMORY;
> > if (libxl_defbool_val(b_info->device_model_stubdomain))
> > *need_memkb += 32 * 1024;
> > break;
> > case LIBXL_DOMAIN_TYPE_PV:
> > -*need_memkb += b_info->shadow_memkb + LIBXL_PV_EXTRA_MEMORY;
> > +*need_memkb += LIBXL_PV_EXTRA_MEMORY;
> > break;
> > default:
> > rc = ERROR_INVAL;
> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > index b61399ce36..d94b7453cb 100644
> > --- a/tools/libxl/libxl_types.idl
> > +++ b/tools/libxl/libxl_types.idl
> > @@ -486,6 +486,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
> > ("target_memkb",MemKB),
> > ("video_memkb", MemKB),
> > ("shadow_memkb",MemKB),
> > +("iommu_memkb", MemKB),
>
> I think you want a corresponding LIBXL_HAVE in libxl.h to tell external
> toolstack whether the field exist.
>
> > ("rtc_timeoffset", uint32),
> > ("exec_ssidref",uint32),
> > ("exec_ssid_label", string),
>
> Cheers,
>
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8 2/6] domain: introduce XEN_DOMCTL_CDF_iommu flag
> -Original Message-
> From: Julien Grall
> Sent: 05 September 2019 21:06
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne ; Jan Beulich ;
> Christian Lindig
> ; David Scott ; Ian Jackson
> ;
> Wei Liu ; Andrew Cooper ; George
> Dunlap
> ; Konrad Rzeszutek Wilk ;
> Stefano Stabellini
> ; Tim (Xen.org) ; Volodymyr Babchuk
>
> Subject: Re: [PATCH v8 2/6] domain: introduce XEN_DOMCTL_CDF_iommu flag
>
> Hi,
>
> On 9/2/19 3:50 PM, Paul Durrant wrote:
> > diff --git a/xen/common/domain.c b/xen/common/domain.c
> > index e9d2c613e0..7dfb257c50 100644
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -301,7 +301,8 @@ static int sanitise_domain_config(struct
> > xen_domctl_createdomain *config)
> > XEN_DOMCTL_CDF_hap |
> > XEN_DOMCTL_CDF_s3_integrity |
> > XEN_DOMCTL_CDF_oos_off |
> > - XEN_DOMCTL_CDF_xs_domain) )
> > + XEN_DOMCTL_CDF_xs_domain |
> > + XEN_DOMCTL_CDF_iommu) )
> > {
> > dprintk(XENLOG_INFO, "Unknown CDF flags %#x\n", config->flags);
> > return -EINVAL;
> > @@ -320,6 +321,12 @@ static int sanitise_domain_config(struct
> > xen_domctl_createdomain *config)
> > return -EINVAL;
> > }
> >
> > +if ( (config->flags & XEN_DOMCTL_CDF_iommu) && !iommu_enabled )
> > +{
> > +dprintk(XENLOG_INFO, "IOMMU is not enabled\n");
> > +return -EINVAL;
> > +}
> > +
>
> Looking at this patch again, the implementation of
> arch_sanitise_domain_config() for Arm will only accepts config->flags to
> be equal to CDF_hvm_guest | CDF_hap.
>
> So after this patch, it will not be possible to create any domain when
> CDF_iommu is set.
You're right, I'm not sure how I missed that. I think I had changed it in
development then managed to lose the hunk. Clearly ARM needs to accept the flag
too.
Paul
>
> Cheers,
>
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [ANNOUNCE] Minutes for September 5th Community Call
Minutes are at https://cryptpad.fr/pad/#/2/pad/view/kpV4XxFWKjAF1fbIckIV87BVTRVRFlL913YWaFD0waI/embed/present/ and attached Lars 2019-09 Community Call.pdf Description: 2019-09 Community Call.pdf ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
