[Xen-devel] [ovmf baseline-only test] 75145: tolerable FAIL
This run is configured for baseline tests only. flight 75145 ovmf real [real] http://osstest.xensource.com/osstest/logs/75145/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75143 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75143 version targeted for testing: ovmf 36faa23c46824e3cf9beff8648a56816cbf58f49 baseline version: ovmf 0fa0e56ee002cf369f7f4a1076eac52f813e03f0 Last test of basis75143 2018-08-30 07:25:43 Z0 days Testing same since75145 2018-08-31 01:05:37 Z0 days1 attempts People who touched revisions under test: Carsey, Jaben Dandan Bi Jaben Carsey Jian J Wang Laszlo Ersek Ruiyu Ni shenglei Star Zeng jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 36faa23c46824e3cf9beff8648a56816cbf58f49 Author: shenglei Date: Wed Aug 22 09:46:41 2018 +0800 MdeModulePkg EhciPei: Remove a redundant function The function UsbHcUnlinkMemBlock that is never called and its related comments have been removed. It is missed in the patch series according to the log in https://bugzilla.tianocore.org/show_bug.cgi?id=1062 v2:Update the title. Cc: Star Zeng Cc: Eric Dong Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: shenglei Reviewed-by: Star Zeng commit 7475ac5157962b570aa0d1afd0811518b729b5fd Author: Dandan Bi Date: Mon Aug 27 13:21:48 2018 +0800 ShellPkg/SmbiosView: Update SmbiosView for SMBIOS3.2.0 REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1099 Update SmbiosView to parse the new definitions which are introduced in SMBIOS3.2.0 V2: 1. Add structure length check before dump the fileds in Type 9 and Type 17 in case some fileds are not organized and reported by drivers. 2. Dump the InterfaceTypeSpecificData in Type 42. V3: 1. Correct the structure length in Type17. 2. Remove the redundant check "if (PeerGroupCount > 0)" in Type 9. 3. Use the Uint16 filed instead of Bits field in union MEMORY_DEVICE_OPERATING_MODE_CAPABILITY to dump data. Cc: Jaben Carsey Cc: Ruiyu Ni Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi Reviewed-by: Star Zeng commit 79e4f2a56ac7cee477c2f84ff65f766814cc1836 Author: Ruiyu Ni Date: Wed Aug 29 11:39:06 2018 +0800 EmulatorPkg: formalize line endings The patch is the result of running "BaseTools/Scripts/FormatDosFiles.py EmulatorPkg/" No functionality impact. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni Reviewed-by: Hao A Wu Cc: Liming Gao commit a07533fab100db41c04d9044503438ac00039d82 Author: Star Zeng Date: Tue Aug 28 13:34:03 2018 +0800 Maintainers.txt: Update maintainer of MdeModulePkg Add Jian J Wang and remove Eric Dong . Eric is focusing on UefiCpuPkg. Cc: Jian J Wang Cc: Eric Dong Cc: Michael D Kinney Cc: Laszlo Ersek Cc: Andrew Fish Cc: Leif Lindholm Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng Reviewed-by: Jian J Wang Reviewed-by: Eric Dong Acked-by: Laszlo Ersek commit 94c04559374df0d1cecea32114df7be6d5931db9 Author: Carsey, Jaben Date: Sat Aug 25 00:33:17 2018 +0800 BaseTools: Create and use a shared value for 'MSFT' from DataType I see lots of 'MSFT' throughout code and this can reduce them. Cc: Bob Feng Cc: Yonghong Zhu Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jaben
[Xen-devel] [BUG] Fun with quoting
The man page for xf.cfg doesn't say much about strings in the Xen configuration files, instead it simply says: "STRING" A string, surrounded by either single or double quotes. But if the STRING is part of a SPEC_STRING, the quotes should be omitted. Nothing about whether single-quotes have any effect different from double-quotes or not. This also says nothing of escape sequences for inside those strings. This is a problem because a few strings inside VM configuration files can quite legitimately contain interesting characters. Of note on Unix a filename has almost no limitations. Only the null character is illegal in a filename, while backslashes and quotes are quite legitimate. So some things I tried with domain configuration files with the `xl` from Xen 4.8.4. This system has the Devuan Linux distribution, which is mostly identical to Debian. This is the section "disk". 'vdev=xvda,format=raw,access=rw,target=/dev/disk/by-partlabel/a\x2fstring' Running `xl -N create -c xl.cfg`: xl.cfg:45: config parsing error near `'vdev=xvda,format=raw,access=rw,target=/dev/disk/by-partlabel/a\x2fstring': invalid digit after backslash hexnumerical character escape in quoted string Failed to parse config: Invalid argument (return code 1) Next: (trying for the hex value of a backslash) 'vdev=xvda,format=raw,access=rw,target=/dev/disk/by-partlabel/a\x5cx2fstring' Resulted in the same error message. Next: 'vdev=xvda,format=raw,access=rw,target=/dev/disk/by-partlabel/a\\x2fstring' Running `xl -N create -c xl.cfg`, I've trimmed most of the output, what I believe is the crucial portion is: "pdev_path": "/dev/disk/by-partlabel/a\\x2fstring", Okay, looks legitimate. Retry without the "-N" and: libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/block add [999] exited with error status 1 This was in fact caused by the /etc/xen/scripts/block script giving an error. Eventually I traced this down and the crucial command was `xenstore-read "$XENBUS_PATH/params"` which was resulting in the string "/dev/disk/by-partlabel/a\\x2fstring". There seem to be inconsistencies in quoting of strings. What I feel should really have occured is for `xl`/libxl to translate the string into "/dev/disk/by-partlabel/a\x2fstring", and then when outputting the data due to the -N re-quoted it back to "/dev/disk/by-partlabel/a\\x2fstring". I believe `xl -N` should have instead output: "pdev_path": "/dev/disk/by-partlabel/ax2fstring", Since the internal string had both backslashes. If you're wondering how I managed to do this, "a/string" is legitimate for a slice label, this makes things easier in some ways and harder in some ways. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-upstream-unstable baseline-only test] 75144: regressions - FAIL
This run is configured for baseline tests only. flight 75144 qemu-upstream-unstable real [real] http://osstest.xensource.com/osstest/logs/75144/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 75079 test-amd64-amd64-i386-pvgrub 19 guest-start/debian.repeat fail REGR. vs. 75079 test-amd64-i386-xl-raw 10 debian-di-install fail REGR. vs. 75079 Tests which did not succeed, but are not blocking: test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail like 75079 test-armhf-armhf-libvirt 12 guest-start fail like 75079 test-armhf-armhf-xl-multivcpu 12 guest-start fail like 75079 test-armhf-armhf-xl-midway 12 guest-start fail like 75079 test-armhf-armhf-xl-credit2 12 guest-start fail like 75079 test-armhf-armhf-xl-rtds 12 guest-start fail like 75079 test-armhf-armhf-xl 12 guest-start fail like 75079 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 75079 test-armhf-armhf-xl-vhd 10 debian-di-installfail like 75079 test-armhf-armhf-libvirt-raw 10 debian-di-installfail like 75079 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail like 75079 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-qemuu-ws16-amd64 10 windows-installfail never pass test-amd64-i386-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-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-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-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass version targeted for testing: qemuude5b678ca4dcdfa83e322491d478d66df56c1986 baseline version: qemuu4f080070a9809bde857851e68a3aeff0c4b9b6a6 Last test of basis75079 2018-08-17 10:55:31 Z 13 days Testing same since75144 2018-08-30 15:22:22 Z0 days1 attempts People who touched revisions under test: Marcel Apfelbaum jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl fail test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-amd64-xl-pvhv2-amdpass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass
[Xen-devel] [xen-4.9-testing test] 126969: regressions - FAIL
flight 126969 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/126969/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stopfail REGR. vs. 124248 Tests which are failing intermittently (not blocking): test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail in 126710 pass in 126969 test-amd64-amd64-xl-rtds 10 debian-install fail in 126710 pass in 126969 test-amd64-amd64-xl-qemut-ws16-amd64 14 guest-localmigrate fail pass in 126710 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail blocked in 124328 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail in 126710 blocked in 124328 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail in 126710 like 124248 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 126710 like 124328 test-amd64-amd64-xl-qemuu-ws16-amd64 14 guest-localmigratefail like 124248 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 124248 test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 124248 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 124328 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 124328 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 124328 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 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-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-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail 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-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-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-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail 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-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen 71e51140fdeb98c8fefc3a7067b554212bb61ac9 baseline version: xen 238007d6fae9447bf5e8e73d67ae9fb844e7ff2a Last test of basis 124328 2018-06-17 23:39:07 Z 74 days Failing since124807 2018-06-28 17:38:04 Z 63 days 41 attempts Testing same since 126296 2018-08-21 01:12:38 Z 10 days8 attempts People who touched revisions under test: Andrew Cooper Christian Lindig George Dunlap Ian Jackson Jan Beulich Juergen Gross Julien Grall Kevin Tian Lars Kurth Paul Durrant Stefano Stabellini Stefano Stabellini Stewart Hildebrand Wei Liu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass
Re: [Xen-devel] [PATCH 5/7] x86/vtx: Rename arch_vmx_struct to vmx_vcpu
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Thursday, August 30, 2018 11:47 PM > > On 30/08/18 15:54, Jan Beulich wrote: > On 28.08.18 at 19:39, wrote: > >> The suffix and prefix are redundant, and the name is curiously odd. > Rename it > >> to vmx_vcpu to be consistent with all the other similar structures. > >> > >> No functional change. > >> > >> Signed-off-by: Andrew Cooper > >> --- > >> CC: Jan Beulich > >> CC: Wei Liu > >> CC: Roger Pau Monné > >> CC: Jun Nakajima > >> CC: Kevin Tian > >> > >> Some of the local pointers are named arch_vmx. I'm open to renaming > them to > >> just vmx (like all the other local pointers) if people are happy with the > >> additional patch delta. > > I'd be fine with that. With or without > > Acked-by: Jan Beulich > > TBH, I was hoping for a comment from Kevin on this question. > > Given that the net diffstat including the pointer renames is: > > andrewcoop@andrewcoop:/local/xen.git/xen$ git d HEAD^ --stat > xen/arch/x86/hvm/vmx/vmcs.c | 44 > ++-- > xen/arch/x86/hvm/vmx/vmx.c | 4 ++-- > xen/include/asm-x86/hvm/vcpu.h | 2 +- > xen/include/asm-x86/hvm/vmx/vmcs.h | 2 +- > 4 files changed, 26 insertions(+), 26 deletions(-) > > I've decided to go ahead and do them, to improve the eventual code > consistency. yes, please go ahead. I didn't note that open earlier. Thanks Kevin ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf baseline-only test] 75143: tolerable FAIL
This run is configured for baseline tests only. flight 75143 ovmf real [real] http://osstest.xensource.com/osstest/logs/75143/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75140 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75140 version targeted for testing: ovmf 0fa0e56ee002cf369f7f4a1076eac52f813e03f0 baseline version: ovmf f25cd80e4d823fa6f7d970d9f0ddb935327446ba Last test of basis75140 2018-08-29 15:56:26 Z1 days Testing same since75143 2018-08-30 07:25:43 Z0 days1 attempts People who touched revisions under test: Carsey, Jaben Jaben Carsey jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 0fa0e56ee002cf369f7f4a1076eac52f813e03f0 Author: Carsey, Jaben Date: Tue Aug 28 06:08:08 2018 +0800 BaseTools: AutoGen.py remove unused import AutoGen does not use anything defined in BuildClassObject Cc: Yonghong Zhu Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jaben Carsey Reviewed-by: Yonghong Zhu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 126988: all pass - PUSHED
flight 126988 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/126988/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 36faa23c46824e3cf9beff8648a56816cbf58f49 baseline version: ovmf 497a5fb1d8f834e1bc84d3496d7f2228bf99f7df Last test of basis 126959 2018-08-29 19:12:34 Z1 days Testing same since 126988 2018-08-30 09:11:30 Z0 days1 attempts People who touched revisions under test: Carsey, Jaben Dandan Bi Jaben Carsey Jian J Wang Laszlo Ersek Ruiyu Ni shenglei Star Zeng jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 497a5fb1d8..36faa23c46 36faa23c46824e3cf9beff8648a56816cbf58f49 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 7/7] x86/hvm: Drop hvm_{vmx,svm} shorthands
On 31/08/18 00:14, Boris Ostrovsky wrote:
> On 08/30/2018 07:11 PM, Boris Ostrovsky wrote:
>> On 08/28/2018 01:39 PM, Andrew Cooper wrote:
>>> By making {vmx,svm} in hvm_vcpu into an anonymous union (consistent with
>>> domain side of things), the hvm_{vmx,svm} defines can be dropped, and all
>>> code
>>> refer to the correctly-named fields. This means that the data hierachy is
>>> no
>>> longer obscured from grep/cscope/tags/etc.
>>>
>>> Reformat one comment and switch one bool_t to bool while making changes.
>>>
>>> No functional change.
>>>
>>> Signed-off-by: Andrew Cooper
>>>
>> Do we still support pre-4.6 gcc?
> Or 4.4.6? I don't remember.
I'm aware of that bug and it is 4.6 iirc.
However, in this case there are no initialisers. The memory starts off
as a zeroed heap page and has a plethora of init() functions call on it
to set things up.
>
> -boris
>
>
>> They have a bug that doesn't allow
>> initializers for anonymous structs/unions. I don't know whether we have
>> any for vmx/svm, but I thought I'd mention this just in case.
>>
>> Other than that, for SVM bits in patches 3,4,6 and 7
>>
>> Reviewed-by: Boris Ostrovsky
Thanks.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 126952: regressions - FAIL
flight 126952 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/126952/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-shadow 20 guest-start/debian.repeat fail REGR. vs. 126854 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 126854 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 126854 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 126854 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 126854 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 126854 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 126854 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 126854 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 126854 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 126854 build-amd64-xen-xsm-freebsd 7 xen-build-freebsdfail never pass build-amd64-xen-freebsd 7 xen-build-freebsdfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-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-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-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-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 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 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-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-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 targeted for testing: xen b28cd21c36288a01ae61ed4f557802abc8ee03e4 baseline version: xen 36e29dd9e580cb0f847f5ac1e72afdb5febe3e99 Last test of basis 126854 2018-08-28 12:14:33 Z2 days Testing same since 126952 2018-08-29 15:25:50 Z1 days1 attempts People who touched revisions under test: Andrew Cooper Daniel De Graaf Gopalasetty, Manoj Jan Beulich Julien Grall Kevin Tian Wei Liu Zhenzhong Duan jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-amd64-xen-freebsd fail build-amd64-xen-xsm-freebsd fail build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev
Re: [Xen-devel] [PATCH 7/7] x86/hvm: Drop hvm_{vmx,svm} shorthands
On 08/30/2018 07:11 PM, Boris Ostrovsky wrote:
> On 08/28/2018 01:39 PM, Andrew Cooper wrote:
>> By making {vmx,svm} in hvm_vcpu into an anonymous union (consistent with
>> domain side of things), the hvm_{vmx,svm} defines can be dropped, and all
>> code
>> refer to the correctly-named fields. This means that the data hierachy is no
>> longer obscured from grep/cscope/tags/etc.
>>
>> Reformat one comment and switch one bool_t to bool while making changes.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper
>>
> Do we still support pre-4.6 gcc?
Or 4.4.6? I don't remember.
-boris
> They have a bug that doesn't allow
> initializers for anonymous structs/unions. I don't know whether we have
> any for vmx/svm, but I thought I'd mention this just in case.
>
> Other than that, for SVM bits in patches 3,4,6 and 7
>
> Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 7/7] x86/hvm: Drop hvm_{vmx,svm} shorthands
On 08/28/2018 01:39 PM, Andrew Cooper wrote:
> By making {vmx,svm} in hvm_vcpu into an anonymous union (consistent with
> domain side of things), the hvm_{vmx,svm} defines can be dropped, and all code
> refer to the correctly-named fields. This means that the data hierachy is no
> longer obscured from grep/cscope/tags/etc.
>
> Reformat one comment and switch one bool_t to bool while making changes.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
>
Do we still support pre-4.6 gcc? They have a bug that doesn't allow
initializers for anonymous structs/unions. I don't know whether we have
any for vmx/svm, but I thought I'd mention this just in case.
Other than that, for SVM bits in patches 3,4,6 and 7
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus bisection] complete test-amd64-i386-qemuu-rhel6hvm-intel
branch xen-unstable xenbranch xen-unstable job test-amd64-i386-qemuu-rhel6hvm-intel testid redhat-install Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: qemuu git://xenbits.xen.org/qemu-xen.git Bug introduced: 4f080070a9809bde857851e68a3aeff0c4b9b6a6 Bug not present: 43139135a8938de44f66333831d3a8655d07663a Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/127009/ (Revision log too long, omitted.) For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-qemuu-rhel6hvm-intel.redhat-install.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-qemuu-rhel6hvm-intel.redhat-install --summary-out=tmp/127009.bisection-summary --basis-template=125898 --blessings=real,real-bisect linux-linus test-amd64-i386-qemuu-rhel6hvm-intel redhat-install Searching for failure / basis pass: 126888 fail [host=albana1] / 125898 [host=debina1] 125702 [host=italia0] 125676 [host=fiano1] 125657 [host=elbling1] 125648 [host=baroque1] 125639 [host=debina1] 125585 [host=debina0] 125551 [host=baroque0] 125520 [host=albana0] 125501 [host=chardonnay0] 125401 [host=huxelrebe1] 125285 [host=italia0] 125129 [host=baroque1] 125069 [host=debina0] 125041 [host=albana0] 124994 ok. Failure / basis pass flights: 126888 / 124994 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest 050cdc6c9501abcd64720b8cc3e7941efee9547d c530a75c1e6a472b0eb9558310b518f0dfcd8860 9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 4f080070a9809bde857851e68a3aeff0c4b9b6a6 a923919797c39d51ea0b808ea691bed20fe8e072 Basis pass fc36def997cfd6cbff3eda4f82853a5c311c5466 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a 437211cb696515ee5bd5dae0ab72866c9f382a33 Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#fc36def997cfd6cbff3eda4f82853a5c311c5466-050cdc6c9501abcd64720b8cc3e7941efee9547d git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-9c0eed618f37dd5b4a57c8b3fbc48ef8913e3149 git://xenbits.xen.org/qemu-xen.git#43139135a8938de44f66333831d3a8655d07663a-4f080070a9809bde857851e68a3aeff0c4b9b6a6 git://xenbits.xen.org/xen.git#437211cb696515ee5bd5dae0ab72866c9f382a33-a923919797c39d51ea0b808ea691bed20fe8e072 adhoc-revtuple-generator: tree discontiguous: linux-2.6 adhoc-revtuple-generator: tree discontiguous: qemu-xen Loaded 2006 nodes in revision graph Searching for test results: 124938 [host=elbling1] 124994 pass fc36def997cfd6cbff3eda4f82853a5c311c5466 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a 437211cb696515ee5bd5dae0ab72866c9f382a33 125041 [host=albana0] 125069 [host=debina0] 125167 [host=italia0] 125129 [host=baroque1] 125242 [host=italia0] 125285 [host=italia0] 125401 [host=huxelrebe1] 125501 [host=chardonnay0] 125551 [host=baroque0] 125520 [host=albana0] 125585 [host=debina0] 125648 [host=baroque1] 125639 [host=debina1] 125657 [host=elbling1] 125676 [host=fiano1] 125702 [host=italia0] 125898 [host=debina1] 125921 blocked irrelevant 126069 blocked irrelevant 126202 blocked irrelevant 126310 blocked irrelevant 126412 blocked irrelevant 126577 blocked fc36def997cfd6cbff3eda4f82853a5c311c5466 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 4f080070a9809bde857851e68a3aeff0c4b9b6a6 3a2b8525b883baa87fe89b3da58f5c09fa599b99 126523 blocked fc36def997cfd6cbff3eda4f82853a5c311c5466 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a 437211cb696515ee5bd5dae0ab72866c9f382a33 126540 blocked fc36def997cfd6cbff3eda4f82853a5c311c5466 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a 318b32fe7ce4ef6cba9d078e2e26040dbdbfb6f8 126529 blocked irrelevant 126532 blocked
Re: [Xen-devel] Problems booting 32-bit PV; just me or more widespread?
On 08/29/2018 08:51 PM, Andy Smith wrote:
> Hi,
>
> I'm sorry this is a long email, but I wanted to explain everything
> that I have tried, because it seems like quite a few different
> versions of 32-bit upstream Linux kernel no longer boot as PV guest
> and I'm surprised I am the first to encounter this. Probably I
> have done something wrong.
>
> I cannot get any of the Ubuntu packaged 32-bit mainline kernels
> after v4.13.16 that are found at
> http://kernel.ubuntu.com/~kernel-ppa/mainline/ to boot in 32-bit PV
> mode. All of them from v4.14.0rc1 onwards crash on xl create either
> saying "error: no XEN note found."
Don't know what this error is, perhaps kernel was not compiled with
CONFIG_XEN.
> or else immediately producing a
> kernel panic like:
>
> .
> .
> .
> [ 0.114370] clocksource: jiffies: mask: 0x max_cycles: 0x,
> max_idle_ns: 764504178510 ns
> [ 0.114382] futex hash table entries: 256 (order: 2, 16384 bytes)
> [ 0.114423] pinctrl core: initialized pinctrl subsystem
> [ 0.134326] RTC time: 165:165:165, date: 165/165/65
> [ 0.134442] NET: Registered protocol family 16
> [ 0.134457] xen:grant_table: Grant tables using version 1 layout
> [ 0.134502] Grant table initialized
> [ 0.134544] audit: initializing netlink subsys (disabled)
> [ 0.134611] audit: type=2000 audit(1535307799.132:1): state=initialized
> audit_enabled=0 res=1
> [ 0.134678] EISA bus registered
> [ 0.136019] PCI: setting up Xen PCI frontend stub
> [ 0.136073] BUG: unable to handle kernel paging request at edc21fd9
> [ 0.136084] IP: eisa_bus_probe+0x19/0x36
> [ 0.136089] *pdpt = 01ee6027 *pde = 29cc6067 *pte =
>
> [ 0.136100] Oops: [#1] SMP
> [ 0.136105] Modules linked in:
> [ 0.136111] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-33-generic
> #36-Ubuntu
> [ 0.136120] EIP: eisa_bus_probe+0x19/0x36
> [ 0.136125] EFLAGS: 00010246 CPU: 0
> [ 0.136130] EAX: edc21fd9 EBX: ECX: 01e0d000 EDX: 0200
> [ 0.136138] ESI: c1d0d452 EDI: c1dd34a4 EBP: e9c89f24 ESP: e9c89f24
> [ 0.136145] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: e021
> [ 0.136154] CR0: 80050033 CR2: edc21fd9 CR3: 01e1 CR4: 00042660
> [ 0.136166] Call Trace:
> [ 0.136173] do_one_initcall+0x49/0x174
> [ 0.136179] ? parse_args+0x143/0x390
> [ 0.136187] ? set_debug_rodata+0x14/0x14
> [ 0.136193] kernel_init_freeable+0x149/0x1c5
> [ 0.136201] ? rest_init+0xa0/0xa0
> [ 0.136207] kernel_init+0xd/0xf0
> [ 0.136213] ret_from_fork+0x2e/0x38
> [ 0.14] Code: ff b8 df 43 ae c1 e8 35 1b 88 ff e8 20 12 88 ff c9 c3 3e 8d
> 74 26 00 55 b9 04 00 00 00 31 d2 b8 d9 ff 0f 00 89 e5 e8 35 8d 35 ff <8b> 10
> 81 fa 45 49 53 41 75 0a c7 05 a0 76 ed c1 01 00 00 00 e8
> [ 0.14] EIP: eisa_bus_probe+0x19/0x36 SS:ESP: e021:e9c89f24
> [ 0.14] CR2: edc21fd9
> [ 0.14] ---[ end trace 8c00b3cb7d4f06ba ]---
> [ 0.140013] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0009
>
> (that one was from the currently-packaged linux-image-generic in
> Ubuntu 18.04 LTS).
Yes, this looks like it was broken by f7eaf6e00fd5 ("x86/boot: Move EISA
setup to a separate file").
We used to use fixmap for EISA addresses, but not anymore. If you can
build your own kernel you could try the patch below (may be
whitespace-damaged)
-boris
diff --git a/arch/x86/kernel/eisa.c b/arch/x86/kernel/eisa.c
index f260e452e4f8..133e16c2fbc6 100644
--- a/arch/x86/kernel/eisa.c
+++ b/arch/x86/kernel/eisa.c
@@ -9,7 +9,12 @@
static __init int eisa_bus_probe(void)
{
- void __iomem *p = ioremap(0x0FFFD9, 4);
+ void __iomem *p;
+
+ if (EISA_bus == -1)
+ return 0;
+
+ p = ioremap(0x0FFFD9, 4);
if (readl(p) == 'E' + ('I'<<8) + ('S'<<16) + ('A'<<24))
EISA_bus = 1;
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 1163e33121fb..b78ef1a67943 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -12,6 +12,10 @@
#include
#include
#include
+#ifdef CONFIG_EISA
+#include
+#endif
+
#include
#include
@@ -854,6 +858,10 @@ char * __init xen_memory_setup(void)
e820__update_table(e820_table);
+#ifdef CONFIG_EISA
+ EISA_bus = -1;
+#endif
+
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 126966: regressions - FAIL
flight 126966 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/126966/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 123814 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 123814 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 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 1 build-check(1) blocked n/a version targeted for testing: libvirt fe67e3e28e9887248610e6106d6245741acb7f96 baseline version: libvirt 076a2b409667dd9f716a2a2085e1ffea9d58fe8b Last test of basis 123814 2018-06-05 04:19:23 Z 86 days Failing since123840 2018-06-06 04:19:28 Z 85 days 66 attempts Testing same since 126966 2018-08-29 21:34:35 Z0 days1 attempts People who touched revisions under test: Ales Musil Andrea Bolognani Anya Harter Bing Niu Bjoern Walk Bobo Du Boris Fiuczynski Brijesh Singh Changkuo Shi Chen Hanxiao Christian Ehrhardt Clementine Hayat Cole Robinson Dan Kenigsberg Daniel Nicoletti Daniel P. Berrangé Daniel Veillard Eric Blake Erik Skultety Fabiano Fidêncio Filip Alac Han Han intrigeri intrigeri Jamie Strandboge Jie Wang Jim Fehlig Jiri Denemark John Ferlan Julio Faracco Ján Tomko Kashyap Chamarthy Katerina Koukiou Laine Stump Laszlo Ersek Lubomir Rintel Luyao Huang Marc Hartmayer Marc Hartmayer Marcos Paulo de Souza Marek Marczykowski-Górecki Martin Kletzander Matthias Bolte Michal Privoznik Michal Prívozník Nikolay Shirokovskiy Pavel Hrdina Peter Krempa Pino Toscano Radostin Stoyanov Ramy Elkest ramyelkest Richard W.M. Jones Roman Bogorodskiy Roman Bolshakov Shi Lei Shichangkuo Shivaprasad G Bhat Simon Kobyda Stefan Bader Stefan Berger Sukrit Bhatnagar Tomáš Golembiovský Vitaly Kuznetsov w00251574 Weilun Zhu xinhua.Cao jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-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-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pairblocked test-amd64-i386-libvirt-pair blocked test-armhf-armhf-libvirt-raw blocked test-amd64-amd64-libvirt-vhd 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
Re: [Xen-devel] [PATCH v3 12/12] xen/domain: Allocate d->vcpu[] in domain_create()
On 30/08/18 20:46, Julien Grall wrote: > Hi Andrew, > > On 08/29/2018 03:40 PM, Andrew Cooper wrote: >> For ARM, the call to arch_domain_create() needs to have completed before >> domain_max_vcpus() will return the correct upper bound. >> >> For each arch's dom0's, drop the temporary max_vcpus parameter, and >> allocation >> of dom0->vcpu. >> >> With d->max_vcpus now correctly configured before evtchn_init(), the >> poll mask >> can be constructed suitably for the domain, rather than for the >> worst-case >> setting. >> >> Due to the evtchn_init() fixes, it no longer calls >> domain_max_vcpus(), and >> ARM's two implementations of vgic_max_vcpus() no longer need work >> around the >> out-of-order call. >> >> From this point on, d->max_vcpus and d->vcpus[] are valid for any >> domain which >> can be looked up by domid. >> >> The XEN_DOMCTL_max_vcpus hypercall is modified to reject any call >> attempt with >> max != d->max_vcpus, which does match the older semantics (not that >> it is >> obvious from the code). The logic to allocate d->vcpu[] is dropped, >> but at >> this point the hypercall still needs making to allocate each vcpu. >> >> Signed-off-by: Andrew Cooper > > With one request below, for the ARM + Common code: > > Acked-by: Julien Grall > > FAOD, I agree with your position to avoid the renaming. > > [...] > >> diff --git a/xen/common/domctl.c b/xen/common/domctl.c >> index 58e51b2..8a803b3 100644 >> --- a/xen/common/domctl.c >> +++ b/xen/common/domctl.c >> @@ -547,6 +547,13 @@ long >> do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) >> break; >> } >> + /* >> + * Note: The parameter passed to XEN_DOMCTL_max_vcpus must match >> the value >> + * passed to XEN_DOMCTL_createdomain. This hypercall is in the >> process of >> + * being removed (once the failure paths in domain_create() have >> been >> + * improved), but is still required in the short term to >> allocate the >> + * vcpus themselves. >> + */ > > This comment might be more useful in the public header. This is > usually the first place I would look for description of a domctl. Ok - will do. That said, it is very likely that the next person to read this will be me when I finally remove it (hopefully in 4.12). ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 12/12] xen/domain: Allocate d->vcpu[] in domain_create()
Hi Andrew, On 08/29/2018 03:40 PM, Andrew Cooper wrote: For ARM, the call to arch_domain_create() needs to have completed before domain_max_vcpus() will return the correct upper bound. For each arch's dom0's, drop the temporary max_vcpus parameter, and allocation of dom0->vcpu. With d->max_vcpus now correctly configured before evtchn_init(), the poll mask can be constructed suitably for the domain, rather than for the worst-case setting. Due to the evtchn_init() fixes, it no longer calls domain_max_vcpus(), and ARM's two implementations of vgic_max_vcpus() no longer need work around the out-of-order call. From this point on, d->max_vcpus and d->vcpus[] are valid for any domain which can be looked up by domid. The XEN_DOMCTL_max_vcpus hypercall is modified to reject any call attempt with max != d->max_vcpus, which does match the older semantics (not that it is obvious from the code). The logic to allocate d->vcpu[] is dropped, but at this point the hypercall still needs making to allocate each vcpu. Signed-off-by: Andrew Cooper With one request below, for the ARM + Common code: Acked-by: Julien Grall FAOD, I agree with your position to avoid the renaming. [...] diff --git a/xen/common/domctl.c b/xen/common/domctl.c index 58e51b2..8a803b3 100644 --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -547,6 +547,13 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) break; } +/* + * Note: The parameter passed to XEN_DOMCTL_max_vcpus must match the value + * passed to XEN_DOMCTL_createdomain. This hypercall is in the process of + * being removed (once the failure paths in domain_create() have been + * improved), but is still required in the short term to allocate the + * vcpus themselves. + */ This comment might be more useful in the public header. This is usually the first place I would look for description of a domctl. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 6/12] xen/gnttab: Pass max_{grant, maptrack}_frames into grant_table_create()
Hi Andrew,
On 08/29/2018 10:38 AM, Andrew Cooper wrote:
... rather than setting the limits up after domain_create() has completed.
This removes the common gnttab infrastructure for calculating the number of
dom0 grant frames (as the common grant table code is not an appropriate place
for it to live), opting instead to require the dom0 construction code to pass
a sane value in via the configuration.
In practice, this now means that there is never a partially constructed grant
table for a reference-able domain.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Reviewed-by: Julien Grall
Cheers,
---
CC: Stefano Stabellini
CC: Julien Grall
CC: Wei Liu
v2:
* Split/rearrange to avoid the post-domain-create error path.
v3:
* Retain gnttab_dom0_frames() for ARM. Sadly needs to be a macro as
opt_max_grant_frames isn't declared until later in xen/grant_table.h
---
xen/arch/arm/setup.c | 3 +++
xen/arch/x86/setup.c | 3 +++
xen/common/domain.c | 3 ++-
xen/common/grant_table.c | 16 +++-
xen/include/asm-arm/grant_table.h | 6 ++
xen/include/asm-x86/grant_table.h | 5 -
xen/include/xen/grant_table.h | 6 ++
7 files changed, 15 insertions(+), 27 deletions(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 45f3841..501a9d5 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -693,6 +694,8 @@ void __init start_xen(unsigned long boot_phys_offset,
struct domain *dom0;
struct xen_domctl_createdomain dom0_cfg = {
.max_evtchn_port = -1,
+.max_grant_frames = gnttab_dom0_frames(),
+.max_maptrack_frames = opt_max_maptrack_frames,
};
dcache_line_bytes = read_dcache_line_bytes();
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index dd11815..8440643 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1,6 +1,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -682,6 +683,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
struct xen_domctl_createdomain dom0_cfg = {
.flags = XEN_DOMCTL_CDF_s3_integrity,
.max_evtchn_port = -1,
+.max_grant_frames = opt_max_grant_frames,
+.max_maptrack_frames = opt_max_maptrack_frames,
};
/* Critical region without IDT or TSS. Any fault is deadly! */
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 171d25e..1dcab8d 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -366,7 +366,8 @@ struct domain *domain_create(domid_t domid,
goto fail;
init_status |= INIT_evtchn;
-if ( (err = grant_table_create(d)) != 0 )
+if ( (err = grant_table_create(d, config->max_grant_frames,
+ config->max_maptrack_frames)) != 0 )
goto fail;
init_status |= INIT_gnttab;
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index ad55cfa..f08341e 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -3567,9 +3567,8 @@ do_grant_table_op(
#include "compat/grant_table.c"
#endif
-int
-grant_table_create(
-struct domain *d)
+int grant_table_create(struct domain *d, unsigned int max_grant_frames,
+ unsigned int max_maptrack_frames)
{
struct grant_table *t;
int ret = 0;
@@ -3587,11 +3586,7 @@ grant_table_create(
t->domain = d;
d->grant_table = t;
-if ( d->domain_id == 0 )
-{
-ret = grant_table_init(d, t, gnttab_dom0_frames(),
- opt_max_maptrack_frames);
-}
+ret = grant_table_set_limits(d, max_maptrack_frames, max_maptrack_frames);
return ret;
}
@@ -4049,11 +4044,6 @@ static int __init gnttab_usage_init(void)
}
__initcall(gnttab_usage_init);
-unsigned int __init gnttab_dom0_frames(void)
-{
-return min(opt_max_grant_frames, gnttab_dom0_max());
-}
-
/*
* Local variables:
* mode: C
diff --git a/xen/include/asm-arm/grant_table.h
b/xen/include/asm-arm/grant_table.h
index 5113b91..d8fde01 100644
--- a/xen/include/asm-arm/grant_table.h
+++ b/xen/include/asm-arm/grant_table.h
@@ -30,10 +30,8 @@ void gnttab_mark_dirty(struct domain *d, mfn_t mfn);
* Only use the text section as it's always present and will contain
* enough space for a large grant table
*/
-static inline unsigned int gnttab_dom0_max(void)
-{
-return PFN_DOWN(_etext - _stext);
-}
+#define gnttab_dom0_frames() \
+min_t(unsigned int, opt_max_grant_frames, PFN_DOWN(_etext - _stext))
#define gnttab_init_arch(gt) \
({ \
diff --git
Re: [Xen-devel] [PATCH RFCv2 6/6] memory-hotplug.txt: Add some details about locking internals
Reviewed-by: Pavel Tatashin On 8/21/18 6:44 AM, David Hildenbrand wrote: > Let's document the magic a bit, especially why device_hotplug_lock is > required when adding/removing memory and how it all play together with > requests to online/offline memory from user space. > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFCv2 5/6] powerpc/powernv: hold device_hotplug_lock in memtrace_offline_pages()
Reviewed-by: Pavel Tatashin
On 8/21/18 6:44 AM, David Hildenbrand wrote:
> Let's perform all checking + offlining + removing under
> device_hotplug_lock, so nobody can mess with these devices via
> sysfs concurrently.
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: Rashmica Gupta
> Cc: Balbir Singh
> Cc: Michael Neuling
> Signed-off-by: David Hildenbrand
> ---
> arch/powerpc/platforms/powernv/memtrace.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/memtrace.c
> b/arch/powerpc/platforms/powernv/memtrace.c
> index ef7181d4fe68..473e59842ec5 100644
> --- a/arch/powerpc/platforms/powernv/memtrace.c
> +++ b/arch/powerpc/platforms/powernv/memtrace.c
> @@ -74,9 +74,13 @@ static bool memtrace_offline_pages(u32 nid, u64 start_pfn,
> u64 nr_pages)
> {
> u64 end_pfn = start_pfn + nr_pages - 1;
>
> + lock_device_hotplug();
> +
> if (walk_memory_range(start_pfn, end_pfn, NULL,
> - check_memblock_online))
> + check_memblock_online)) {
> + unlock_device_hotplug();
> return false;
> + }
>
> walk_memory_range(start_pfn, end_pfn, (void *)MEM_GOING_OFFLINE,
> change_memblock_state);
> @@ -84,14 +88,16 @@ static bool memtrace_offline_pages(u32 nid, u64
> start_pfn, u64 nr_pages)
> if (offline_pages(start_pfn, nr_pages)) {
> walk_memory_range(start_pfn, end_pfn, (void *)MEM_ONLINE,
> change_memblock_state);
> + unlock_device_hotplug();
> return false;
> }
>
> walk_memory_range(start_pfn, end_pfn, (void *)MEM_OFFLINE,
> change_memblock_state);
>
> - remove_memory(nid, start_pfn << PAGE_SHIFT, nr_pages << PAGE_SHIFT);
> + __remove_memory(nid, start_pfn << PAGE_SHIFT, nr_pages << PAGE_SHIFT);
>
> + unlock_device_hotplug();
> return true;
> }
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFCv2 4/6] powerpc/powernv: hold device_hotplug_lock when calling device_online()
Reviewed-by: Pavel Tatashin
On 8/21/18 6:44 AM, David Hildenbrand wrote:
> device_online() should be called with device_hotplug_lock() held.
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: Rashmica Gupta
> Cc: Balbir Singh
> Cc: Michael Neuling
> Signed-off-by: David Hildenbrand
> ---
> arch/powerpc/platforms/powernv/memtrace.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/platforms/powernv/memtrace.c
> b/arch/powerpc/platforms/powernv/memtrace.c
> index 8f1cd4f3bfd5..ef7181d4fe68 100644
> --- a/arch/powerpc/platforms/powernv/memtrace.c
> +++ b/arch/powerpc/platforms/powernv/memtrace.c
> @@ -229,9 +229,11 @@ static int memtrace_online(void)
>* we need to online the memory ourselves.
>*/
> if (!memhp_auto_online) {
> + lock_device_hotplug();
> walk_memory_range(PFN_DOWN(ent->start),
> PFN_UP(ent->start + ent->size - 1),
> NULL, online_mem_block);
> + unlock_device_hotplug();
> }
>
> /*
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFCv2 3/6] mm/memory_hotplug: fix online/offline_pages called w.o. mem_hotplug_lock
On 8/21/18 6:44 AM, David Hildenbrand wrote:
> There seem to be some problems as result of 30467e0b3be ("mm, hotplug:
> fix concurrent memory hot-add deadlock"), which tried to fix a possible
> lock inversion reported and discussed in [1] due to the two locks
> a) device_lock()
> b) mem_hotplug_lock
>
> While add_memory() first takes b), followed by a) during
> bus_probe_device(), onlining of memory from user space first took b),
> followed by a), exposing a possible deadlock.
>
> In [1], and it was decided to not make use of device_hotplug_lock, but
> rather to enforce a locking order.
>
> The problems I spotted related to this:
>
> 1. Memory block device attributes: While .state first calls
>mem_hotplug_begin() and the calls device_online() - which takes
>device_lock() - .online does no longer call mem_hotplug_begin(), so
>effectively calls online_pages() without mem_hotplug_lock.
>
> 2. device_online() should be called under device_hotplug_lock, however
>onlining memory during add_memory() does not take care of that.
>
> In addition, I think there is also something wrong about the locking in
>
> 3. arch/powerpc/platforms/powernv/memtrace.c calls offline_pages()
>without locks. This was introduced after 30467e0b3be. And skimming over
>the code, I assume it could need some more care in regards to locking
>(e.g. device_online() called without device_hotplug_lock - but I'll
>not touch that for now).
>
> Now that we hold the device_hotplug_lock when
> - adding memory (e.g. via add_memory()/add_memory_resource())
> - removing memory (e.g. via remove_memory())
> - device_online()/device_offline()
>
> We can move mem_hotplug_lock usage back into
> online_pages()/offline_pages().
>
> Why is mem_hotplug_lock still needed? Essentially to make
> get_online_mems()/put_online_mems() be very fast (relying on
> device_hotplug_lock would be very slow), and to serialize against
> addition of memory that does not create memory block devices (hmm).
>
> [1] http://driverdev.linuxdriverproject.org/pipermail/ driverdev-devel/
> 2015-February/065324.html
>
> This patch is partly based on a patch by Vitaly Kuznetsov.
Reviewed-by: Pavel Tatashin
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.9 test] 126938: regressions - FAIL
flight 126938 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/126938/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rumprun-i386 12 guest-start fail REGR. vs. 125183 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 125183 test-amd64-amd64-rumprun-amd64 12 guest-startfail REGR. vs. 125183 test-amd64-amd64-xl-multivcpu 12 guest-start fail REGR. vs. 125183 test-amd64-amd64-xl-pvshim 12 guest-start fail REGR. vs. 125183 test-amd64-amd64-xl-xsm 12 guest-start fail REGR. vs. 125183 test-amd64-amd64-pair21 guest-start/debian fail REGR. vs. 125183 test-amd64-amd64-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-amd64-xl-shadow 12 guest-start fail REGR. vs. 125183 test-amd64-i386-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-i386-qemut-rhel6hvm-intel 10 redhat-install fail REGR. vs. 125183 test-amd64-i386-xl 12 guest-start fail REGR. vs. 125183 test-amd64-i386-xl-shadow12 guest-start fail REGR. vs. 125183 test-amd64-amd64-xl-credit2 12 guest-start fail REGR. vs. 125183 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 125183 test-amd64-amd64-xl 12 guest-start fail REGR. vs. 125183 test-amd64-amd64-pygrub 10 debian-di-installfail REGR. vs. 125183 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 125183 test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 125183 test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 125183 test-amd64-amd64-i386-pvgrub 10 debian-di-installfail REGR. vs. 125183 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 125183 test-amd64-i386-pair 21 guest-start/debian fail REGR. vs. 125183 test-amd64-i386-xl-xsm 12 guest-start fail REGR. vs. 125183 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 125183 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 125183 test-amd64-amd64-amd64-pvgrub 10 debian-di-install fail REGR. vs. 125183 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 125183 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 125183 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 125183 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install fail REGR. vs. 125183 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-i386-xl-qemut-win7-amd64 10 windows-install fail REGR. vs. 125183 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-i386-xl-raw 10 debian-di-installfail REGR. vs. 125183 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125183 test-armhf-armhf-xl-credit2 12 guest-start fail REGR. vs. 125183 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 125183 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125183 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 125183 test-amd64-amd64-libvirt-vhd 10 debian-di-installfail REGR. vs. 125183 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-install fail REGR. vs. 125183 test-armhf-armhf-xl-multivcpu 12 guest-start fail REGR. vs. 125183 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install fail REGR. vs. 125183 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 125183 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install
Re: [Xen-devel] [PATCH RFCv2 1/6] mm/memory_hotplug: make remove_memory() take the device_hotplug_lock
> +
> +void __ref remove_memory(int nid, u64 start, u64 size)
Remove __ref, otherwise looks good:
Reviewed-by: Pavel Tatashin
> +{
> + lock_device_hotplug();
> + __remove_memory(nid, start, size);
> + unlock_device_hotplug();
> +}
> EXPORT_SYMBOL_GPL(remove_memory);
> #endif /* CONFIG_MEMORY_HOTREMOVE */
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFCv2 2/6] mm/memory_hotplug: make add_memory() take the device_hotplug_lock
On 8/21/18 6:44 AM, David Hildenbrand wrote:
> add_memory() currently does not take the device_hotplug_lock, however
> is aleady called under the lock from
> arch/powerpc/platforms/pseries/hotplug-memory.c
> drivers/acpi/acpi_memhotplug.c
> to synchronize against CPU hot-remove and similar.
>
> In general, we should hold the device_hotplug_lock when adding memory
> to synchronize against online/offline request (e.g. from user space) -
> which already resulted in lock inversions due to device_lock() and
> mem_hotplug_lock - see 30467e0b3be ("mm, hotplug: fix concurrent memory
> hot-add deadlock"). add_memory()/add_memory_resource() will create memory
> block devices, so this really feels like the right thing to do.
>
> Holding the device_hotplug_lock makes sure that a memory block device
> can really only be accessed (e.g. via .online/.state) from user space,
> once the memory has been fully added to the system.
>
> The lock is not held yet in
> drivers/xen/balloon.c
> arch/powerpc/platforms/powernv/memtrace.c
> drivers/s390/char/sclp_cmd.c
> drivers/hv/hv_balloon.c
> So, let's either use the locked variants or take the lock.
>
> Don't export add_memory_resource(), as it once was exported to be used
> by XEN, which is never built as a module. If somebody requires it, we
> also have to export a locked variant (as device_hotplug_lock is never
> exported).
Reviewed-by: Pavel Tatashin
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/6] xen/arm: add RCAR2 kconfig
On Tue, 28 Aug 2018, Julien Grall wrote: > (Switching to my Arm e-mail) > > Hi, > > On 24/08/18 20:31, Stefano Stabellini wrote: > > On Fri, 24 Aug 2018, Julien Grall wrote: > > > Hi, > > > > > > On 24/08/18 00:33, Stefano Stabellini wrote: > > > > Add a kconfig option for Renesas Rcar2 platforms. > > > > > > > > Signed-off-by: Stefano Stabellini > > > > Reviewed-by: Andrii Anisov > > > > CC: iurii.konovale...@globallogic.com > > > > --- > > > >xen/arch/arm/platforms/Kconfig | 11 +++ > > > >xen/arch/arm/platforms/Makefile | 2 +- > > > >2 files changed, 12 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/xen/arch/arm/platforms/Kconfig > > > > b/xen/arch/arm/platforms/Kconfig > > > > index a43c938..e54825a 100644 > > > > --- a/xen/arch/arm/platforms/Kconfig > > > > +++ b/xen/arch/arm/platforms/Kconfig > > > > @@ -53,6 +53,13 @@ config SUNXI > > > > Enable all the required drivers for Allwinnder sunxi > > > > platforms, > > > > including Pine64, OrangePi, CubieBoard, etc. > > > >+config RCAR2 > > > > + bool "Renesas R-Car Gen2" > > > > + depends on ARM_32 > > > > + select HAS_SCIF > > > > + ---help--- > > > > + Enable all the required drivers for Renesas R-Car Gen2. > > > > > > Technically the UART is not required. By selecting it, you give no way to > > > the > > > user to remove it. > > > > I don't know of a way to select the UART driver by default, which is the > > desired configuration for the majority, while still allowing users to > > remove it if they want to. > > You can't do this directly with Kconfig. Linux is solving the problem by > introducing "config fragment" and using scripts/kconfig/merge_config.sh to > merge the fragments. > > The scripts exists on Xen in xen/xen/tools/kconfig/. So if you provide > a fragment for tiny and R-Car, you could merge both in a single one. > > This would also give the freedom for the user to tailor a bit more his > .config. I don't mind the config fragment approach but it is very low on my priority list at the moment. We discussed removing the selects from the new platform kconfigs, but I am now thinking of dropping the platform specific options introduced by the series altogether and only send the ALL32_PLAT, ALL64_PLAT and NO_PLAT options (only the last 2 patches). ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.7] x86/spec-ctrl: Fix backport of 1fdb25a614b
Refreshing XenServer's patchqueue has shown that I missed this adjustment in
the upstream backports of the final version of the XSA-273 fixes.
The code does work in 4.7 and earlier, but only because the eventual value of
(opt_pv_l1tf & OPT_PV_L1TF_DOMx) is within range of a char.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/include/asm-x86/shadow.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/include/asm-x86/shadow.h b/xen/include/asm-x86/shadow.h
index de09e81..c720008 100644
--- a/xen/include/asm-x86/shadow.h
+++ b/xen/include/asm-x86/shadow.h
@@ -215,8 +215,8 @@ void pv_l1tf_tasklet(unsigned long data);
static inline void pv_l1tf_domain_init(struct domain *d)
{
d->arch.pv_domain.check_l1tf =
-opt_pv_l1tf & (is_hardware_domain(d)
- ? OPT_PV_L1TF_DOM0 : OPT_PV_L1TF_DOMU);
+!!(opt_pv_l1tf & (is_hardware_domain(d)
+ ? OPT_PV_L1TF_DOM0 : OPT_PV_L1TF_DOMU));
#ifdef CONFIG_SHADOW_PAGING
tasklet_init(>arch.paging.shadow.pv_l1tf_tasklet,
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/2] x86/spec-ctrl: add support for modifying SSBD via LS_CFG MSR
On Thu, Aug 30, 2018 at 09:49:58AM -0600, Jan Beulich wrote:
> >>> On 27.08.18 at 18:55, wrote:
> > Adds support for modifying the LS_CFG MSR to enable SSBD on supporting
> > AMD CPUs. There needs to be locking logic for family 17h with SMT
> > enabled since both threads share the same MSR. Otherwise, a core just
> > needs to write to the LS_CFG MSR. For more information see:
> > https://developer.amd.com/wp-content/resources/124441_AMD64_SpeculativeStoreB
> >
> > ypassDisable_Whitepaper_final.pdf
> >
> > Signed-off-by: Brian Woods
> > ---
> > xen/arch/x86/cpu/amd.c| 13 +--
> > xen/arch/x86/smpboot.c| 3 +
> > xen/arch/x86/spec_ctrl.c | 172
> > +-
> > xen/include/asm-x86/cpufeatures.h | 1 +
> > xen/include/asm-x86/spec_ctrl.h | 2 +
> > 5 files changed, 181 insertions(+), 10 deletions(-)
> >
> > diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
> > index 6e65ae7427..e96f14268e 100644
> > --- a/xen/arch/x86/cpu/amd.c
> > +++ b/xen/arch/x86/cpu/amd.c
> > @@ -601,8 +601,8 @@ static void init_amd(struct cpuinfo_x86 *c)
> > }
> >
> > /*
> > -* If the user has explicitly chosen to disable Memory Disambiguation
> > -* to mitigiate Speculative Store Bypass, poke the appropriate MSR.
> > +* Poke the LS_CFG MSR to see if the mitigation for Speculative
> > +* Store Bypass is available.
> > */
> > if (!ssbd_amd_ls_cfg_mask) {
> > int bit = -1;
> > @@ -615,14 +615,9 @@ static void init_amd(struct cpuinfo_x86 *c)
> >
> > if (bit >= 0)
> > ssbd_amd_ls_cfg_mask = 1ull << bit;
> > - }
> >
> > - if (ssbd_amd_ls_cfg_mask && !rdmsr_safe(MSR_AMD64_LS_CFG, value)) {
> > - ssbd_amd_ls_cfg_av = true;
> > - if (opt_ssbd) {
> > - value |= ssbd_amd_ls_cfg_mask;
> > - wrmsr_safe(MSR_AMD64_LS_CFG, value);
> > - }
> > + if (ssbd_amd_ls_cfg_mask && !rdmsr_safe(MSR_AMD64_LS_CFG,
> > value))
> > + ssbd_amd_ls_cfg_av = true;
> > }
> >
> > /* MFENCE stops RDTSC speculation */
> > diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
> > index 7e76cc3d68..b103b46dee 100644
> > --- a/xen/arch/x86/smpboot.c
> > +++ b/xen/arch/x86/smpboot.c
> > @@ -376,6 +376,9 @@ void start_secondary(void *unused)
> > if ( boot_cpu_has(X86_FEATURE_IBRSB) )
> > wrmsrl(MSR_SPEC_CTRL, default_xen_spec_ctrl);
> >
> > +if ( default_xen_ssbd_amd_ls_cfg_en )
> > +ssbd_amd_ls_cfg_set(true);
> > +
> > if ( xen_guest )
> > hypervisor_ap_setup();
> >
> > diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
> > index b32c12c6c0..89cc444f56 100644
> > --- a/xen/arch/x86/spec_ctrl.c
> > +++ b/xen/arch/x86/spec_ctrl.c
> > @@ -20,6 +20,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -58,8 +59,17 @@ paddr_t __read_mostly l1tf_addr_mask, __read_mostly
> > l1tf_safe_maddr;
> > static bool __initdata cpu_has_bug_l1tf;
> > static unsigned int __initdata l1d_maxphysaddr;
> >
> > +/* for SSBD support for AMD via LS_CFG */
> > +#define SSBD_AMD_MAX_SOCKET 4
>
> Oh, went up from 2 to 4? But still not a dynamic upper bound?
>
Well, 4 was just to be safe. 2 is more than reasonable IMO. Having it
dynamic seems like a lot of work to save 8 bytes (or after the bump to
4, 24 bytes) when it doesn't get used.
> > +struct ssbd_amd_ls_cfg_smt_status {
> > +spinlock_t lock;
> > +uint32_t mask;
> > +} __attribute__ ((aligned (64)));
>
> Ehem. See the respective comment on patch 1. To put it bluntly,
> I'm not willing to look at patches where prior comments were not
> addressed, the more that you had verbally agreed to use
> SMP_CACHE_BYTES here.
>
> Jan
>
Well, a rebasing failed and I had to regenerate the patches from a
diff of the v3 patches combined, and I missed fixing that one part.
I'm terrible sorry I missed that one fix.
--
Brian Woods
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 5/6] xen/arm: smccc: Add wrapper to automatically select the calling convention
Hi Julien,
On 24.08.18 19:58, Julien Grall wrote:
Signed-off-by: Julien Grall
---
xen/arch/arm/psci.c | 4
xen/include/asm-arm/cpufeature.h | 3 ++-
xen/include/asm-arm/smccc.h | 8
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 3cf5ecf0f3..941eec921b 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -118,6 +119,9 @@ static void __init psci_init_smccc(void)
smccc_ver = ret;
}
+if ( smccc_ver >= SMCCC_VERSION(1, 1) )
+cpus_set_cap(ARM_SMCCC_1_1);
+
printk(XENLOG_INFO "Using SMC Calling Convention v%u.%u\n",
SMCCC_VERSION_MAJOR(smccc_ver), SMCCC_VERSION_MINOR(smccc_ver));
}
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index 9c297c521c..c9c4046f5f 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -44,8 +44,9 @@
#define SKIP_CTXT_SWITCH_SERROR_SYNC 6
#define ARM_HARDEN_BRANCH_PREDICTOR 7
#define ARM_SSBD 8
+#define ARM_SMCCC_1_1 9
-#define ARM_NCAPS 9
+#define ARM_NCAPS 10
#ifndef __ASSEMBLY__
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 1ed6cbaa48..7c39c530e2 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
+#include
@@ -213,6 +213,7 @@ struct arm_smccc_res {
*/
#ifdef CONFIG_ARM_32
#define arm_smccc_1_0_smc(...) arm_smccc_1_1_smc(__VA_ARGS__)
+#define arm_smccc_smc(...) arm_smccc_1_1_smc(__VA_ARGS__)
#else
void __arm_smccc_1_0_smc(register_t a0, register_t a1, register_t a2,
@@ -254,6 +255,13 @@ void __arm_smccc_1_0_smc(register_t a0, register_t a1,
register_t a2,
#define arm_smccc_1_0_smc(...) \
__arm_smccc_1_0_smc_count(__count_args(__VA_ARGS__), __VA_ARGS__)
+#define arm_smccc_smc(...) \
+do {\
+if ( !cpus_have_const_cap(ARM_SMCCC_1_1) ) \
+arm_smccc_1_0_smc(__VA_ARGS__); \
+else\
+arm_smccc_1_1_smc(__VA_ARGS__); \
+} while ( 0 )
#endif /* CONFIG_ARM_64 */
#endif /* __ASSEMBLY__ */
--
Volodymyr Babchuk
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 4/6] xen/arm: cpufeature: Add helper to check constant caps
Hi Julien,
On 24.08.18 19:58, Julien Grall wrote:
Some capababilities are set right during boot and will never change
afterwards. At the moment, the function cpu_have_caps will check whether
the cap is enabled from the memory.
It is possible to avoid the load from the memory by using an
ALTERNATIVE. With that the check is just reduced to 1 instruction.
Signed-off-by: Julien Grall
---
This is the static key for the poor. At some point we might want to
introduce something similar to static key in Xen.
---
xen/include/asm-arm/cpufeature.h | 12
1 file changed, 12 insertions(+)
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index 3de6b54301..9c297c521c 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -63,6 +63,18 @@ static inline bool cpus_have_cap(unsigned int num)
return test_bit(num, cpu_hwcaps);
}
+#include
+/* System capability check for constant cap */
+#define cpus_have_const_cap(num) ({ \
+bool __ret; \
+\
+asm volatile (ALTERNATIVE("mov %0, #0", \
+ "mov %0, #1", \
+ num) \
+ : "=r" (__ret)); \
+\
+__ret; \
+})
+
static inline void cpus_set_cap(unsigned int num)
{
if (num >= ARM_NCAPS)
--
Volodymyr Babchuk
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 126996: tolerable all pass - PUSHED
flight 126996 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/126996/ 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 version targeted for testing: xen f04955e18502035121776f6e09d83ae5a36c773c baseline version: xen fc5e7213f4f84b28c0557c8dbe16573f76932866 Last test of basis 126991 2018-08-30 11:00:44 Z0 days Testing same since 126996 2018-08-30 15:01:02 Z0 days1 attempts People who touched revisions under test: Andrew Cooper jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass 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 fc5e7213f4..f04955e185 f04955e18502035121776f6e09d83ae5a36c773c -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-3.18 test] 126926: regressions - FAIL
flight 126926 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/126926/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-xsm 12 guest-start fail REGR. vs. 126042 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 126042 test-amd64-i386-rumprun-i386 12 guest-start fail REGR. vs. 126042 test-amd64-amd64-xl-pvshim 12 guest-start fail REGR. vs. 126042 test-amd64-amd64-xl-shadow 12 guest-start fail REGR. vs. 126042 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 126042 test-amd64-amd64-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 126042 test-amd64-i386-qemut-rhel6hvm-intel 10 redhat-install fail REGR. vs. 126042 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-rumprun-amd64 12 guest-startfail REGR. vs. 126042 test-amd64-amd64-xl-multivcpu 12 guest-start fail REGR. vs. 126042 test-amd64-amd64-xl-xsm 12 guest-start fail REGR. vs. 126042 test-amd64-i386-xl-shadow12 guest-start fail REGR. vs. 126042 test-amd64-amd64-xl-credit2 12 guest-start fail REGR. vs. 126042 test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 126042 test-amd64-i386-xl 12 guest-start fail REGR. vs. 126042 test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 126042 test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 126042 test-amd64-amd64-pair21 guest-start/debian fail REGR. vs. 126042 test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 126042 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 126042 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 126042 test-amd64-i386-pair 21 guest-start/debian fail REGR. vs. 126042 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 126042 test-amd64-i386-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-xl 12 guest-start fail REGR. vs. 126042 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 126042 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-libvirt-pair 21 guest-start/debian fail REGR. vs. 126042 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-pygrub 10 debian-di-installfail REGR. vs. 126042 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-i386-pvgrub 10 debian-di-installfail REGR. vs. 126042 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-amd64-pvgrub 10 debian-di-install fail REGR. vs. 126042 test-amd64-i386-xl-raw 10 debian-di-installfail REGR. vs. 126042 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 126042 test-armhf-armhf-xl-arndale 12 guest-start fail REGR. vs. 126042 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 126042 test-amd64-amd64-libvirt-vhd 10 debian-di-installfail REGR. vs. 126042 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 126042 test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install fail REGR. vs. 126042 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 126042 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 126042 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 126042 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install fail REGR. vs. 126042 test-amd64-i386-xl-qemut-win7-amd64 10 windows-install fail REGR. vs. 126042 test-armhf-armhf-xl-cubietruck 12 guest-startfail REGR. vs. 126042 test-armhf-armhf-xl-credit2 12 guest-start
Re: [Xen-devel] [PATCH] xen: Fix inconsistent callers of panic()
On 30/08/18 15:07, Jan Beulich wrote: On 30.08.18 at 14:31, wrote: >> Callers are inconsistent with whether they pass a newline to panic(), >> including adjacent calls in the same function using different styles. >> >> painc() not expecting a newline is inconsistent with most other printing >> functions, which is most likely why we've gained so many inconsistencies. >> >> Switch panic() to expect a newline, and update all callers which currently >> lack a newline to include one. >> >> This actually reduces the size of .rodata (0x07e3e8 down to 0x07e3a8) because >> a number of strings are passed to both panic() and printk(). As they >> previously differed by \n alone, they couldn't be merged. > I agree this is a nice side effect, but ... > >> Signed-off-by: Andrew Cooper >> --- >> CC: Jan Beulich >> CC: Wei Liu >> CC: Stefano Stabellini >> CC: Julien Grall >> >> (Restricted to the core arch maintainers as this is a tree-wide piece of >> cleanup with no functional impact to other areas.) >> >> The observant amongst you might realise that this reverts parts of c/s >> 51ad90aea21c - What can I say? Several years of hindsight is very useful, >> and >> at the time I did ask the maintainers which option they thought would be >> better... > ... I think both the earlier and this change are heading in the > wrong direction: I would much rather see the newline omitted > everywhere, _including_ in panic() itself: This causes one line > less to scroll off the screen in case you don't have a serial > console. I don't expect that suggestion would get anywhere if you put it to a vote with The REST. For one, it breaks any ability to construct a single line of text from multiple printk() calls (which we have plenty of examples of in the codebase), and it further deviates from everyone’s expectation of how printk() works (which is the very reason we've picked up all these inconsistencies since I last made them consistent). IMO, such a change would be detrimental, because either the code will get out of sync again (most likely), or there will extra review aggravation as people submitting code to normal expectations have their code rejected. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-next test] 126932: regressions - FAIL
flight 126932 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/126932/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 126781 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 126781 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 126781 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. 126781 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail REGR. vs. 126781 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 126781 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 126781 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 126781 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 126781 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 126781 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 126781 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 126781 test-amd64-amd64-xl-pvshim7 xen-boot fail REGR. vs. 126781 test-amd64-amd64-examine 8 reboot fail REGR. vs. 126781 test-amd64-amd64-libvirt 7 xen-boot fail REGR. vs. 126781 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qcow210 debian-di-install fail blocked in 126781 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail blocked in 126781 test-amd64-amd64-xl-multivcpu 12 guest-startfail blocked in 126781 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail blocked in 126781 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-installfail blocked in 126781 test-amd64-amd64-xl-rtds 12 guest-start fail blocked in 126781 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail blocked in 126781 test-amd64-i386-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail blocked in 126781 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail like 126781 test-amd64-amd64-rumprun-amd64 12 guest-start fail like 126781 test-amd64-i386-rumprun-i386 12 guest-start fail like 126781 test-amd64-amd64-xl-shadow 12 guest-start fail like 126781 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-installfail like 126781 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail like 126781 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail like 126781 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail like 126781 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 126781 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail like 126781 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail like 126781 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail like 126781 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-installfail like 126781 test-amd64-i386-freebsd10-i386 11 guest-start fail like 126781 test-amd64-amd64-xl-xsm 12 guest-start fail like 126781 test-amd64-amd64-xl 12 guest-start fail like 126781 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail like 126781 test-amd64-i386-xl 12 guest-start fail like 126781 test-amd64-amd64-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail like 126781 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail like 126781 test-amd64-i386-xl-xsm 12 guest-start fail like 126781 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-installfail like 126781 test-amd64-amd64-pygrub 7 xen-boot fail like 126781 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail like 126781 test-amd64-i386-libvirt 12 guest-start fail like 126781 test-amd64-i386-xl-shadow12 guest-start fail like 126781 test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail like 126781 test-amd64-amd64-libvirt-vhd 10 debian-di-installfail like 126781 test-amd64-amd64-libvirt-xsm 12 guest-start fail like 126781 test-amd64-i386-freebsd10-amd64 11 guest-startfail like 126781 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail like 126781 test-amd64-amd64-xl-credit2 12 guest-start fail like 126781 test-amd64-i386-pair 21 guest-start/debian fail like 126781 test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail like 126781 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail like
Re: [Xen-devel] [PATCH v1 1/6] arm: add SMC wrapper that is compatible with SMCCC
On 30/08/18 15:48, Volodymyr Babchuk wrote: Hi Julien, Hi, On 22.08.18 19:46, Julien Grall wrote: [...] +++ b/xen/arch/arm/arm32/smc.S @@ -0,0 +1,39 @@ +/* + * xen/arch/arm/arm32/smc.S + * + * Wrapper for Secure Monitors Calls + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. Xen is GPLv2 only. Can you please update the copyright accordingly? I'll fix this, no problem. But I can see number of files with this clause "either version 2 of the License, or (at your option) any later version". Do maintainers/code owners plan to update existing files? It is not easy to re-license of a file. You need to get an agreement from all the contributors of the file. Lars did try in the past, but this didn't receive any support from the community. Also, are there any plans to switch to SPDX-Licence-Identifier? I am not aware of any plan for this. But that would definitely avoid licensing issues because of the wording. This would need to be discussed within the community before going forward. Feel free to kick a thread for it with the committers in CC. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/6] xen/arm: SMCCC fixup and improvement
Hi Julien, On 24.08.18 19:58, Julien Grall wrote: Hi all, This patch series contains fixup and improvement for the SMCCC subsystem. Patch #1 - #2 are candidates for backporting. I tested this patches together with my TEE patch series and all is working fine both with SMCCC 1.0 and SMCCC 1.1. So you can have my Tested-by: Volodymyr Babchuk for this this 6 patches. Cheers, Julien Grall (3): xen/arm: cpufeature: Add helper to check constant caps xen/arm: smccc: Add wrapper to automatically select the calling convention xen/arm: Replace call_smc with arm_smccc_smc Marc Zyngier (2): xen/arm: smccc-1.1: Make return values unsigned long xen/arm: smccc-1.1: Handle function result as parameters Volodymyr Babchuk (1): xen/arm: add SMC wrapper that is compatible with SMCCC v1.0 xen/arch/arm/Makefile| 1 - xen/arch/arm/arm64/Makefile | 1 + xen/arch/arm/arm64/asm-offsets.c | 5 +++ xen/arch/arm/arm64/smc.S | 32 + xen/arch/arm/platforms/exynos5.c | 3 +- xen/arch/arm/platforms/seattle.c | 4 +- xen/arch/arm/psci.c | 41 - xen/arch/arm/smc.S | 21 - xen/include/asm-arm/cpufeature.h | 15 ++- xen/include/asm-arm/processor.h | 3 -- xen/include/asm-arm/smccc.h | 97 +--- 11 files changed, 167 insertions(+), 56 deletions(-) create mode 100644 xen/arch/arm/arm64/smc.S delete mode 100644 xen/arch/arm/smc.S -- Volodymyr Babchuk ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen: Improvements to domain_crash()
On 30/08/18 17:01, Razvan Cojocaru wrote:
> On 8/30/18 6:31 PM, Andrew Cooper wrote:
>> There original reason for this patch was to fix a livepatching problem;
>> unnecesserily large livepatchs due to the use of __LINE__.
>>
>> A second problem is one of debugability. A number of domain_crash()
>> invocations have no logging at all, and number of others only have logging
>> when compiled with a debug hypervisor.
>>
>> Change the interface to require the caller to pass a printk() message, which
>> is emitted at guest error level. This should ensure that every time a domain
>> is crashed, an informative log message is also present.
>>
>> Update all callers to either merge with a previous printk(), or invent an
>> informative log message. A few select callers are switched to the
>> non-printing version, when they've already emitted a relevent state dump.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: George Dunlap
>> CC: Jan Beulich
>> CC: Konrad Rzeszutek Wilk
>> CC: Stefano Stabellini
>> CC: Tim Deegan
>> CC: Wei Liu
>> CC: Julien Grall
>> CC: Jun Nakajima
>> CC: Kevin Tian
>> CC: Boris Ostrovsky
>> CC: Suravee Suthikulpanit
>> CC: Brian Woods
>> CC: Roger Pau Monné
>> CC: Juergen Gross
>> CC: Dario Faggioli
>> CC: Paul Durrant
>> CC: Razvan Cojocaru
>> CC: Tamas K Lengyel
>>
>> It is unfortunate that this is one monolithic patch, but I can't find any
>> reasonable way to split it up.
>> ---
>> xen/arch/arm/mem_access.c | 12 ++
>> xen/arch/arm/traps.c| 6 +--
>> xen/arch/x86/cpu/mcheck/mcaction.c | 2 +-
>> xen/arch/x86/domain.c | 13 ++
>> xen/arch/x86/hvm/emulate.c | 9 ++--
>> xen/arch/x86/hvm/hvm.c | 74
>> -
>> xen/arch/x86/hvm/intercept.c| 25 +++
>> xen/arch/x86/hvm/io.c | 3 +-
>> xen/arch/x86/hvm/ioreq.c| 19 +
>> xen/arch/x86/hvm/svm/svm.c | 53 ++-
>> xen/arch/x86/hvm/viridian.c | 2 +-
>> xen/arch/x86/hvm/vlapic.c | 5 +--
>> xen/arch/x86/hvm/vmx/realmode.c | 2 +-
>> xen/arch/x86/hvm/vmx/vmcs.c | 2 +-
>> xen/arch/x86/hvm/vmx/vmx.c | 55 ++--
>> xen/arch/x86/hvm/vmx/vvmx.c | 4 +-
>> xen/arch/x86/hvm/vpt.c | 10 ++---
>> xen/arch/x86/mm.c | 9 ++--
>> xen/arch/x86/mm/hap/hap.c | 7 +---
>> xen/arch/x86/mm/hap/nested_hap.c| 9 ++--
>> xen/arch/x86/mm/mem_access.c| 5 +--
>> xen/arch/x86/mm/p2m-pod.c | 19 -
>> xen/arch/x86/mm/p2m.c | 35 ++--
>> xen/arch/x86/mm/shadow/common.c | 42 +++
>> xen/arch/x86/mm/shadow/multi.c | 17
>> xen/arch/x86/msi.c | 2 +-
>> xen/arch/x86/pv/iret.c | 30 ++---
>> xen/arch/x86/traps.c| 8 ++--
>> xen/arch/x86/x86_emulate/x86_emulate.c | 2 +-
>> xen/arch/x86/xstate.c | 14 +++
>> xen/common/compat/grant_table.c | 2 +-
>> xen/common/compat/memory.c | 6 +--
>> xen/common/domain.c | 2 +-
>> xen/common/grant_table.c| 17 +++-
>> xen/common/memory.c | 2 +-
>> xen/common/page_alloc.c | 2 +-
>> xen/common/wait.c | 12 ++
>> xen/drivers/passthrough/amd/iommu_map.c | 25 +--
>> xen/drivers/passthrough/iommu.c | 8 ++--
>> xen/drivers/passthrough/pci.c | 2 +-
>> xen/drivers/passthrough/vtd/iommu.c | 2 +-
>> xen/include/xen/sched.h | 10 +++--
>> 42 files changed, 253 insertions(+), 332 deletions(-)
>>
>> diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
>> index ba4ec78..be99fbd 100644
>> --- a/xen/arch/arm/mem_access.c
>> +++ b/xen/arch/arm/mem_access.c
>> @@ -293,12 +293,7 @@ bool p2m_mem_access_check(paddr_t gpa, vaddr_t gla,
>> const struct npfec npfec)
>> {
>> /* No listener */
>> if ( p2m->access_required )
>> -{
>> -gdprintk(XENLOG_INFO, "Memory access permissions failure, "
>> - "no vm_event listener VCPU %d, dom %d\n",
>> - v->vcpu_id, v->domain->domain_id);
>> -domain_crash(v->domain);
>> -}
>> +domain_crash(v->domain, "No vm_event listener\n");
>> else
>> {
>> /* n2rwx was already handled */
>> @@ -337,8 +332,9 @@ bool p2m_mem_access_check(paddr_t gpa, vaddr_t gla,
>> const struct npfec npfec)
>> req->u.mem_access.flags |= npfec.write_access ? MEM_ACCESS_W : 0;
>> req->u.mem_access.flags |= npfec.insn_fetch ? MEM_ACCESS_X : 0;
>>
>> -if ( monitor_traps(v, (xma
Re: [Xen-devel] [PATCH 7/7] x86/hvm: Drop hvm_{vmx,svm} shorthands
On 30/08/18 02:39, Tian, Kevin wrote:
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: Wednesday, August 29, 2018 1:39 AM
>>
>> By making {vmx,svm} in hvm_vcpu into an anonymous union (consistent
>> with
>> domain side of things), the hvm_{vmx,svm} defines can be dropped, and all
>> code
>> refer to the correctly-named fields. This means that the data hierachy is no
>> longer obscured from grep/cscope/tags/etc.
>>
>> Reformat one comment and switch one bool_t to bool while making
>> changes.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Kevin Tian
>
> one small note. In coverletter:
>
> " This series started by trying to address the bug in patch 7,
> and ballooned somewhat."
>
> there is no bug per se in this patch, right?
I should probably have said issue rather than bug. I was referring to
the obscuring of data from grep/cscope/tags/etc.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1] xen: creating debug info is optional
>>> On 30.08.18 at 17:59, wrote: > Am Thu, 30 Aug 2018 09:23:47 -0600 > schrieb "Jan Beulich" : > >> Reusing? It's been gone since 4.9, and ./INSTALL talks about it as >> a tool stack only thing. > > It does not, it is in the general "make" section. Quote from ./INSTALL in my copy of the master tree: "Per default some parts of the tools code will print additional runtime debug. This option can be used to disable such code paths. debug=y debug_symbols=y" Note the word "tools" in there. > I do not see any valid reason to diverge further. ??? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 4/7] x86/hvm: Rename v->arch.hvm_vcpu to v->arch.hvm
On 30/08/18 15:52, Jan Beulich wrote: On 28.08.18 at 19:39, wrote: On 28.08.18 at 19:39, wrote: >> The trailing _vcpu suffix is redundant, but adds to code volume. Drop it. >> >> Reflow lines as appropriate, and switch to using the new XFREE/etc wrappers >> where applicable. > I couldn't find any such conversion, so perhaps better to delete that > part of the description. Fixed. > >> No functional change. >> >> Signed-off-by: Andrew Cooper > Reviewed-by: Jan Beulich Thanks. > >> @@ -3888,19 +3886,19 @@ void hvm_vcpu_reset_state(struct vcpu *v, uint16_t >> cs, uint16_t ip) >> v->arch.user_regs.rip = ip; >> memset(>arch.debugreg, 0, sizeof(v->arch.debugreg)); >> >> -v->arch.hvm_vcpu.guest_cr[0] = X86_CR0_ET; >> +v->arch.hvm.guest_cr[0] = X86_CR0_ET; >> hvm_update_guest_cr(v, 0); >> >> -v->arch.hvm_vcpu.guest_cr[2] = 0; >> +v->arch.hvm.guest_cr[2] = 0; >> hvm_update_guest_cr(v, 2); >> >> -v->arch.hvm_vcpu.guest_cr[3] = 0; >> +v->arch.hvm.guest_cr[3] = 0; >> hvm_update_guest_cr(v, 3); >> >> -v->arch.hvm_vcpu.guest_cr[4] = 0; >> +v->arch.hvm.guest_cr[4] = 0; >> hvm_update_guest_cr(v, 4); >> >> -v->arch.hvm_vcpu.guest_efer = 0; >> +v->arch.hvm.guest_efer = 0; >> hvm_update_guest_efer(v); > Noticing this, a thought unrelated to this series: Wouldn't we be better off > setting all the structure fields first, and only then invoke all the > functions? > Just like arch_set_info_hvm_guest() does? Actually, arch_set_info_hvm_guest() is broken in a related way. When nested virt is in the mix, the usual rules for which control bits can be changed are relaxed, and you can get into a number of corner cases where these helpers don't do the correct thing. (e.g. when a 32bit PAE guest tries vmexiting to a PCID hypervisor). Resolving this mess is on the todo list, which includes this function, and others. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen: Improvements to domain_crash()
On 8/30/18 6:31 PM, Andrew Cooper wrote:
> There original reason for this patch was to fix a livepatching problem;
> unnecesserily large livepatchs due to the use of __LINE__.
>
> A second problem is one of debugability. A number of domain_crash()
> invocations have no logging at all, and number of others only have logging
> when compiled with a debug hypervisor.
>
> Change the interface to require the caller to pass a printk() message, which
> is emitted at guest error level. This should ensure that every time a domain
> is crashed, an informative log message is also present.
>
> Update all callers to either merge with a previous printk(), or invent an
> informative log message. A few select callers are switched to the
> non-printing version, when they've already emitted a relevent state dump.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: George Dunlap
> CC: Jan Beulich
> CC: Konrad Rzeszutek Wilk
> CC: Stefano Stabellini
> CC: Tim Deegan
> CC: Wei Liu
> CC: Julien Grall
> CC: Jun Nakajima
> CC: Kevin Tian
> CC: Boris Ostrovsky
> CC: Suravee Suthikulpanit
> CC: Brian Woods
> CC: Roger Pau Monné
> CC: Juergen Gross
> CC: Dario Faggioli
> CC: Paul Durrant
> CC: Razvan Cojocaru
> CC: Tamas K Lengyel
>
> It is unfortunate that this is one monolithic patch, but I can't find any
> reasonable way to split it up.
> ---
> xen/arch/arm/mem_access.c | 12 ++
> xen/arch/arm/traps.c| 6 +--
> xen/arch/x86/cpu/mcheck/mcaction.c | 2 +-
> xen/arch/x86/domain.c | 13 ++
> xen/arch/x86/hvm/emulate.c | 9 ++--
> xen/arch/x86/hvm/hvm.c | 74
> -
> xen/arch/x86/hvm/intercept.c| 25 +++
> xen/arch/x86/hvm/io.c | 3 +-
> xen/arch/x86/hvm/ioreq.c| 19 +
> xen/arch/x86/hvm/svm/svm.c | 53 ++-
> xen/arch/x86/hvm/viridian.c | 2 +-
> xen/arch/x86/hvm/vlapic.c | 5 +--
> xen/arch/x86/hvm/vmx/realmode.c | 2 +-
> xen/arch/x86/hvm/vmx/vmcs.c | 2 +-
> xen/arch/x86/hvm/vmx/vmx.c | 55 ++--
> xen/arch/x86/hvm/vmx/vvmx.c | 4 +-
> xen/arch/x86/hvm/vpt.c | 10 ++---
> xen/arch/x86/mm.c | 9 ++--
> xen/arch/x86/mm/hap/hap.c | 7 +---
> xen/arch/x86/mm/hap/nested_hap.c| 9 ++--
> xen/arch/x86/mm/mem_access.c| 5 +--
> xen/arch/x86/mm/p2m-pod.c | 19 -
> xen/arch/x86/mm/p2m.c | 35 ++--
> xen/arch/x86/mm/shadow/common.c | 42 +++
> xen/arch/x86/mm/shadow/multi.c | 17
> xen/arch/x86/msi.c | 2 +-
> xen/arch/x86/pv/iret.c | 30 ++---
> xen/arch/x86/traps.c| 8 ++--
> xen/arch/x86/x86_emulate/x86_emulate.c | 2 +-
> xen/arch/x86/xstate.c | 14 +++
> xen/common/compat/grant_table.c | 2 +-
> xen/common/compat/memory.c | 6 +--
> xen/common/domain.c | 2 +-
> xen/common/grant_table.c| 17 +++-
> xen/common/memory.c | 2 +-
> xen/common/page_alloc.c | 2 +-
> xen/common/wait.c | 12 ++
> xen/drivers/passthrough/amd/iommu_map.c | 25 +--
> xen/drivers/passthrough/iommu.c | 8 ++--
> xen/drivers/passthrough/pci.c | 2 +-
> xen/drivers/passthrough/vtd/iommu.c | 2 +-
> xen/include/xen/sched.h | 10 +++--
> 42 files changed, 253 insertions(+), 332 deletions(-)
>
> diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
> index ba4ec78..be99fbd 100644
> --- a/xen/arch/arm/mem_access.c
> +++ b/xen/arch/arm/mem_access.c
> @@ -293,12 +293,7 @@ bool p2m_mem_access_check(paddr_t gpa, vaddr_t gla,
> const struct npfec npfec)
> {
> /* No listener */
> if ( p2m->access_required )
> -{
> -gdprintk(XENLOG_INFO, "Memory access permissions failure, "
> - "no vm_event listener VCPU %d, dom %d\n",
> - v->vcpu_id, v->domain->domain_id);
> -domain_crash(v->domain);
> -}
> +domain_crash(v->domain, "No vm_event listener\n");
> else
> {
> /* n2rwx was already handled */
> @@ -337,8 +332,9 @@ bool p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const
> struct npfec npfec)
> req->u.mem_access.flags |= npfec.write_access ? MEM_ACCESS_W : 0;
> req->u.mem_access.flags |= npfec.insn_fetch ? MEM_ACCESS_X : 0;
>
> -if ( monitor_traps(v, (xma != XENMEM_access_n2rwx), req) < 0 )
> -domain_crash(v->domain);
> +rc = monitor_traps(v, (xma != XENMEM_access_n2rwx), req);
>
Re: [Xen-devel] [PATCH v6 01/14] iommu: introduce the concept of BFN...
>>> On 23.08.18 at 11:46, wrote: > --- a/xen/include/xen/mm.h > +++ b/xen/include/xen/mm.h > @@ -26,6 +26,11 @@ > * A linear idea of a guest physical address space. For an auto-translated > * guest, pfn == gfn while for a non-translated guest, pfn != gfn. > * > + * bfn: Bus Frame Number (definitions in include/xen/iommu.h) > + * The linear frame numbers of IOMMU address space. All initiators for > (i.e. > + * all devices assigned to) a guest share a single IOMMU address space and, > + * by default, Xen will ensure bfn == pfn. The code changes are purely mechanical and hence fine, but I have to admit I continue to struggle with the "bus" part in the name here: I don't think it is any less ambiguous than GFN, because which bus are you thinking about here? The (virtual) one as seen by the guest, aiui. The physical (host) one would be at least as natural to be indexed by such typed/named variables. I'd somehow like it to be made explicit in the name whose view these represent. GBFN? VBFN? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1] xen: creating debug info is optional
Am Thu, 30 Aug 2018 09:23:47 -0600 schrieb "Jan Beulich" : > Reusing? It's been gone since 4.9, and ./INSTALL talks about it as > a tool stack only thing. It does not, it is in the general "make" section. I do not see any valid reason to diverge further. Olaf pgp7_TmCXnfBQ.pgp Description: Digitale Signatur von OpenPGP ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFCv2 0/6] mm: online/offline_pages called w.o. mem_hotplug_lock
On 8/30/18 8:31 AM, David Hildenbrand wrote: > On 21.08.2018 12:44, David Hildenbrand wrote: >> This is the same approach as in the first RFC, but this time without >> exporting device_hotplug_lock (requested by Greg) and with some more >> details and documentation regarding locking. Tested only on x86 so far. >> > > I'll be on vacation for two weeks starting on Saturday. If there are no > comments I'll send this as !RFC once I return. > I am studying this series, will send my comments later today. Pavel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/2] x86/spec-ctrl: add support for modifying SSBD via LS_CFG MSR
>>> On 27.08.18 at 18:55, wrote:
> Adds support for modifying the LS_CFG MSR to enable SSBD on supporting
> AMD CPUs. There needs to be locking logic for family 17h with SMT
> enabled since both threads share the same MSR. Otherwise, a core just
> needs to write to the LS_CFG MSR. For more information see:
> https://developer.amd.com/wp-content/resources/124441_AMD64_SpeculativeStoreB
> ypassDisable_Whitepaper_final.pdf
>
> Signed-off-by: Brian Woods
> ---
> xen/arch/x86/cpu/amd.c| 13 +--
> xen/arch/x86/smpboot.c| 3 +
> xen/arch/x86/spec_ctrl.c | 172
> +-
> xen/include/asm-x86/cpufeatures.h | 1 +
> xen/include/asm-x86/spec_ctrl.h | 2 +
> 5 files changed, 181 insertions(+), 10 deletions(-)
>
> diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
> index 6e65ae7427..e96f14268e 100644
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -601,8 +601,8 @@ static void init_amd(struct cpuinfo_x86 *c)
> }
>
> /*
> - * If the user has explicitly chosen to disable Memory Disambiguation
> - * to mitigiate Speculative Store Bypass, poke the appropriate MSR.
> + * Poke the LS_CFG MSR to see if the mitigation for Speculative
> + * Store Bypass is available.
>*/
> if (!ssbd_amd_ls_cfg_mask) {
> int bit = -1;
> @@ -615,14 +615,9 @@ static void init_amd(struct cpuinfo_x86 *c)
>
> if (bit >= 0)
> ssbd_amd_ls_cfg_mask = 1ull << bit;
> - }
>
> - if (ssbd_amd_ls_cfg_mask && !rdmsr_safe(MSR_AMD64_LS_CFG, value)) {
> - ssbd_amd_ls_cfg_av = true;
> - if (opt_ssbd) {
> - value |= ssbd_amd_ls_cfg_mask;
> - wrmsr_safe(MSR_AMD64_LS_CFG, value);
> - }
> + if (ssbd_amd_ls_cfg_mask && !rdmsr_safe(MSR_AMD64_LS_CFG,
> value))
> + ssbd_amd_ls_cfg_av = true;
> }
>
> /* MFENCE stops RDTSC speculation */
> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
> index 7e76cc3d68..b103b46dee 100644
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -376,6 +376,9 @@ void start_secondary(void *unused)
> if ( boot_cpu_has(X86_FEATURE_IBRSB) )
> wrmsrl(MSR_SPEC_CTRL, default_xen_spec_ctrl);
>
> +if ( default_xen_ssbd_amd_ls_cfg_en )
> +ssbd_amd_ls_cfg_set(true);
> +
> if ( xen_guest )
> hypervisor_ap_setup();
>
> diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
> index b32c12c6c0..89cc444f56 100644
> --- a/xen/arch/x86/spec_ctrl.c
> +++ b/xen/arch/x86/spec_ctrl.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -58,8 +59,17 @@ paddr_t __read_mostly l1tf_addr_mask, __read_mostly
> l1tf_safe_maddr;
> static bool __initdata cpu_has_bug_l1tf;
> static unsigned int __initdata l1d_maxphysaddr;
>
> +/* for SSBD support for AMD via LS_CFG */
> +#define SSBD_AMD_MAX_SOCKET 4
Oh, went up from 2 to 4? But still not a dynamic upper bound?
> +struct ssbd_amd_ls_cfg_smt_status {
> +spinlock_t lock;
> +uint32_t mask;
> +} __attribute__ ((aligned (64)));
Ehem. See the respective comment on patch 1. To put it bluntly,
I'm not willing to look at patches where prior comments were not
addressed, the more that you had verbally agreed to use
SMP_CACHE_BYTES here.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 5/7] x86/vtx: Rename arch_vmx_struct to vmx_vcpu
On 30/08/18 15:54, Jan Beulich wrote: On 28.08.18 at 19:39, wrote: >> The suffix and prefix are redundant, and the name is curiously odd. Rename >> it >> to vmx_vcpu to be consistent with all the other similar structures. >> >> No functional change. >> >> Signed-off-by: Andrew Cooper >> --- >> CC: Jan Beulich >> CC: Wei Liu >> CC: Roger Pau Monné >> CC: Jun Nakajima >> CC: Kevin Tian >> >> Some of the local pointers are named arch_vmx. I'm open to renaming them to >> just vmx (like all the other local pointers) if people are happy with the >> additional patch delta. > I'd be fine with that. With or without > Acked-by: Jan Beulich TBH, I was hoping for a comment from Kevin on this question. Given that the net diffstat including the pointer renames is: andrewcoop@andrewcoop:/local/xen.git/xen$ git d HEAD^ --stat xen/arch/x86/hvm/vmx/vmcs.c | 44 ++-- xen/arch/x86/hvm/vmx/vmx.c | 4 ++-- xen/include/asm-x86/hvm/vcpu.h | 2 +- xen/include/asm-x86/hvm/vmx/vmcs.h | 2 +- 4 files changed, 26 insertions(+), 26 deletions(-) I've decided to go ahead and do them, to improve the eventual code consistency. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 1/2] x86/spec-ctrl: add AMD SSBD LS_CFG in init print
>>> On 27.08.18 at 18:54, wrote:
> Edit the initialization code for AMD's SSBD via the LS_CFG MSR and
> enable it to pass the status to the initial spec-ctrl print_details at
> boot.
>
> Signed-off-by: Brian Woods
> ---
I think I had indicated so before: A brief revision log is expected here,
in particular to aid people having looked at prior versions of a patch.
Whether you also put such a log in the cover letter is up to you, but
there it's not normally going to be patch specific.
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -604,7 +604,7 @@ static void init_amd(struct cpuinfo_x86 *c)
>* If the user has explicitly chosen to disable Memory Disambiguation
>* to mitigiate Speculative Store Bypass, poke the appropriate MSR.
>*/
> - if (opt_ssbd) {
> + if (!ssbd_amd_ls_cfg_mask) {
> int bit = -1;
>
> switch (c->x86) {
> @@ -613,8 +613,14 @@ static void init_amd(struct cpuinfo_x86 *c)
> case 0x17: bit = 10; break;
> }
>
> - if (bit >= 0 && !rdmsr_safe(MSR_AMD64_LS_CFG, value)) {
> - value |= 1ull << bit;
> + if (bit >= 0)
> + ssbd_amd_ls_cfg_mask = 1ull << bit;
> + }
> +
> + if (ssbd_amd_ls_cfg_mask && !rdmsr_safe(MSR_AMD64_LS_CFG, value)) {
> + ssbd_amd_ls_cfg_av = true;
"av" is standing for "avail" I guess? If so, I'd prefer if you spelled it out.
Also two of the three comments given on v2 still apply here. Please
address _all_ comments either verbally or by code changes before
sending a new version.
> --- a/xen/arch/x86/spec_ctrl.c
> +++ b/xen/arch/x86/spec_ctrl.c
> @@ -58,6 +58,9 @@ paddr_t __read_mostly l1tf_addr_mask, __read_mostly
> l1tf_safe_maddr;
> static bool __initdata cpu_has_bug_l1tf;
> static unsigned int __initdata l1d_maxphysaddr;
>
> +bool ssbd_amd_ls_cfg_av;
__read_mostly (afaict)
Also the variable seems pointless - this ...
> +uint64_t __read_mostly ssbd_amd_ls_cfg_mask;
... variable being (non-)zero should suffice as indication.
Otherwise the definition of this variable in this file looks
wrong, as there's no reference to it in here.
> @@ -281,11 +284,12 @@ static void __init print_details(enum ind_thunk thunk,
> uint64_t caps)
> printk("Speculative mitigation facilities:\n");
>
> /* Hardware features which pertain to speculative mitigations. */
> -printk(" Hardware features:%s%s%s%s%s%s%s%s%s%s\n",
> +printk(" Hardware features:%s%s%s%s%s%s%s%s%s%s%s\n",
> (_7d0 & cpufeat_mask(X86_FEATURE_IBRSB)) ? " IBRS/IBPB" : "",
> (_7d0 & cpufeat_mask(X86_FEATURE_STIBP)) ? " STIBP" : "",
> (_7d0 & cpufeat_mask(X86_FEATURE_L1D_FLUSH)) ? " L1D_FLUSH" : "",
> (_7d0 & cpufeat_mask(X86_FEATURE_SSBD)) ? " SSBD" : "",
> + ssbd_amd_ls_cfg_av ? " LS_CFG_SSBD" : "",
> (e8b & cpufeat_mask(X86_FEATURE_IBPB)) ? " IBPB" : "",
> (caps & ARCH_CAPABILITIES_IBRS_ALL) ? " IBRS_ALL" : "",
> (caps & ARCH_CAPABILITIES_RDCL_NO) ? " RDCL_NO" : "",
> @@ -305,7 +309,7 @@ static void __init print_details(enum ind_thunk thunk,
> uint64_t caps)
> "\n");
>
> /* Settings for Xen's protection, irrespective of guests. */
> -printk(" Xen settings: BTI-Thunk %s, SPEC_CTRL: %s%s, Other:%s%s\n",
> +printk(" Xen settings: BTI-Thunk %s, SPEC_CTRL: %s%s%s, Other:%s%s\n",
> thunk == THUNK_NONE ? "N/A" :
> thunk == THUNK_RETPOLINE ? "RETPOLINE" :
> thunk == THUNK_LFENCE? "LFENCE" :
> @@ -314,6 +318,8 @@ static void __init print_details(enum ind_thunk thunk,
> uint64_t caps)
> (default_xen_spec_ctrl & SPEC_CTRL_IBRS) ? "IBRS+" : "IBRS-",
> !boot_cpu_has(X86_FEATURE_SSBD) ? "" :
> (default_xen_spec_ctrl & SPEC_CTRL_SSBD) ? " SSBD+" : " SSBD-",
> + !ssbd_amd_ls_cfg_av ? "" :
> + opt_ssbd ? " LS_CFG_SSBD+" : "
> LS_CFG_SSBD-",
> opt_ibpb ? " IBPB" : "",
> opt_l1d_flush ? " L1D_FLUSH" : "");
>
> diff --git a/xen/include/asm-x86/spec_ctrl.h b/xen/include/asm-x86/spec_ctrl.h
> index 8f8aad40bb..1b9101a988 100644
> --- a/xen/include/asm-x86/spec_ctrl.h
> +++ b/xen/include/asm-x86/spec_ctrl.h
> @@ -50,6 +50,9 @@ extern int8_t opt_pv_l1tf;
> */
> extern paddr_t l1tf_addr_mask, l1tf_safe_maddr;
>
> +extern bool ssbd_amd_ls_cfg_av;
> +extern uint64_t ssbd_amd_ls_cfg_mask;
> +
> static inline void init_shadow_spec_ctrl_state(void)
> {
> struct cpu_info *info = get_cpu_info();
> --
> 2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] xen: Improvements to domain_crash()
There original reason for this patch was to fix a livepatching problem;
unnecesserily large livepatchs due to the use of __LINE__.
A second problem is one of debugability. A number of domain_crash()
invocations have no logging at all, and number of others only have logging
when compiled with a debug hypervisor.
Change the interface to require the caller to pass a printk() message, which
is emitted at guest error level. This should ensure that every time a domain
is crashed, an informative log message is also present.
Update all callers to either merge with a previous printk(), or invent an
informative log message. A few select callers are switched to the
non-printing version, when they've already emitted a relevent state dump.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Julien Grall
CC: Jun Nakajima
CC: Kevin Tian
CC: Boris Ostrovsky
CC: Suravee Suthikulpanit
CC: Brian Woods
CC: Roger Pau Monné
CC: Juergen Gross
CC: Dario Faggioli
CC: Paul Durrant
CC: Razvan Cojocaru
CC: Tamas K Lengyel
It is unfortunate that this is one monolithic patch, but I can't find any
reasonable way to split it up.
---
xen/arch/arm/mem_access.c | 12 ++
xen/arch/arm/traps.c| 6 +--
xen/arch/x86/cpu/mcheck/mcaction.c | 2 +-
xen/arch/x86/domain.c | 13 ++
xen/arch/x86/hvm/emulate.c | 9 ++--
xen/arch/x86/hvm/hvm.c | 74 -
xen/arch/x86/hvm/intercept.c| 25 +++
xen/arch/x86/hvm/io.c | 3 +-
xen/arch/x86/hvm/ioreq.c| 19 +
xen/arch/x86/hvm/svm/svm.c | 53 ++-
xen/arch/x86/hvm/viridian.c | 2 +-
xen/arch/x86/hvm/vlapic.c | 5 +--
xen/arch/x86/hvm/vmx/realmode.c | 2 +-
xen/arch/x86/hvm/vmx/vmcs.c | 2 +-
xen/arch/x86/hvm/vmx/vmx.c | 55 ++--
xen/arch/x86/hvm/vmx/vvmx.c | 4 +-
xen/arch/x86/hvm/vpt.c | 10 ++---
xen/arch/x86/mm.c | 9 ++--
xen/arch/x86/mm/hap/hap.c | 7 +---
xen/arch/x86/mm/hap/nested_hap.c| 9 ++--
xen/arch/x86/mm/mem_access.c| 5 +--
xen/arch/x86/mm/p2m-pod.c | 19 -
xen/arch/x86/mm/p2m.c | 35 ++--
xen/arch/x86/mm/shadow/common.c | 42 +++
xen/arch/x86/mm/shadow/multi.c | 17
xen/arch/x86/msi.c | 2 +-
xen/arch/x86/pv/iret.c | 30 ++---
xen/arch/x86/traps.c| 8 ++--
xen/arch/x86/x86_emulate/x86_emulate.c | 2 +-
xen/arch/x86/xstate.c | 14 +++
xen/common/compat/grant_table.c | 2 +-
xen/common/compat/memory.c | 6 +--
xen/common/domain.c | 2 +-
xen/common/grant_table.c| 17 +++-
xen/common/memory.c | 2 +-
xen/common/page_alloc.c | 2 +-
xen/common/wait.c | 12 ++
xen/drivers/passthrough/amd/iommu_map.c | 25 +--
xen/drivers/passthrough/iommu.c | 8 ++--
xen/drivers/passthrough/pci.c | 2 +-
xen/drivers/passthrough/vtd/iommu.c | 2 +-
xen/include/xen/sched.h | 10 +++--
42 files changed, 253 insertions(+), 332 deletions(-)
diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
index ba4ec78..be99fbd 100644
--- a/xen/arch/arm/mem_access.c
+++ b/xen/arch/arm/mem_access.c
@@ -293,12 +293,7 @@ bool p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const
struct npfec npfec)
{
/* No listener */
if ( p2m->access_required )
-{
-gdprintk(XENLOG_INFO, "Memory access permissions failure, "
- "no vm_event listener VCPU %d, dom %d\n",
- v->vcpu_id, v->domain->domain_id);
-domain_crash(v->domain);
-}
+domain_crash(v->domain, "No vm_event listener\n");
else
{
/* n2rwx was already handled */
@@ -337,8 +332,9 @@ bool p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const
struct npfec npfec)
req->u.mem_access.flags |= npfec.write_access ? MEM_ACCESS_W : 0;
req->u.mem_access.flags |= npfec.insn_fetch ? MEM_ACCESS_X : 0;
-if ( monitor_traps(v, (xma != XENMEM_access_n2rwx), req) < 0 )
-domain_crash(v->domain);
+rc = monitor_traps(v, (xma != XENMEM_access_n2rwx), req);
+if ( rc < 0 )
+domain_crash(v->domain, "monitor_traps() returned %d\n", rc);
xfree(req);
}
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 9ae64ae..151794b 100644
--- a/xen/arch/arm/traps.c
+++
Re: [Xen-devel] [PATCH] x86/mm: Drop {HAP,SHADOW}_ERROR() wrappers
>>> On 30.08.18 at 17:20, wrote:
> On 30/08/18 16:15, Jan Beulich wrote:
> On 28.08.18 at 20:11, wrote:
>>> @@ -2478,9 +2478,7 @@ sh_map_and_validate_gl4e(struct vcpu *v, mfn_t gl4mfn,
>>> shadow_l4_index,
>>> validate_gl4e);
>>> #else // ! GUEST_PAGING_LEVELS >= 4
>>> -SHADOW_ERROR("called in wrong paging mode!\n");
>>> -BUG();
>>> -return 0;
>>> +BUG(); /* Called in wrong paging mode! */
>>> #endif
>>> }
>> Isn't this going to break the build for certain older gcc versions?
>> ISTR some similar problems in the past.
>
> Perhaps, but since this code was written, BUG() has gained an
> unreachable() hint. As other examples of this code like this compile, I
> don't think this is going to be a problem.
The problem(s) I think I recall certainly post-date the introduction of
unreachable(). Perhaps whether a compiler would produce a
diagnostic depends on other factors as well. I'm not objecting to this
going in unchanged; in the worst case we'll have to re-introduce the
"return" later on.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1] xen: creating debug info is optional
>>> On 30.08.18 at 17:10, wrote: > Creating debug info during build is not strictly required at runtime. > Make it optional by reusing the existing 'debug_symbols=n' knob. Reusing? It's been gone since 4.9, and ./INSTALL talks about it as a tool stack only thing. If we wanted to re-introduce anything like this, it should be done via Kconfig option. But note that without debug info the quality of certain linker errors decreases, which is why I would recommend against doing so. Also please send patches _To_ the list, with maintainers _Cc_-ed. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/mm: Drop {HAP,SHADOW}_ERROR() wrappers
On 30/08/18 16:15, Jan Beulich wrote:
On 28.08.18 at 20:11, wrote:
>> --- a/xen/arch/x86/mm/hap/hap.c
>> +++ b/xen/arch/x86/mm/hap/hap.c
>> @@ -304,10 +304,11 @@ static void hap_free_p2m_page(struct domain *d, struct
>> page_info *pg)
>> /* Should still have no owner and count zero. */
>> if ( owner || (pg->count_info & PGC_count_mask) )
>> {
>> -HAP_ERROR("d%d: Odd p2m page %"PRI_mfn" d=%d c=%lx
>> t=%"PRtype_info"\n",
>> - d->domain_id, mfn_x(page_to_mfn(pg)),
>> - owner ? owner->domain_id : DOMID_INVALID,
>> - pg->count_info, pg->u.inuse.type_info);
>> +printk(XENLOG_ERR
>> + "d%d: Odd p2m page %"PRI_mfn" d=%d c=%lx t=%"PRtype_info"\n",
>> + d->domain_id, mfn_x(page_to_mfn(pg)),
>> + owner ? owner->domain_id : DOMID_INVALID,
>> + pg->count_info, pg->u.inuse.type_info);
>> WARN();
> This being WARN(), perhaps then also XENLOG_WARNING?
Oh - absolutely.
>
>> @@ -2478,9 +2478,7 @@ sh_map_and_validate_gl4e(struct vcpu *v, mfn_t gl4mfn,
>> shadow_l4_index,
>> validate_gl4e);
>> #else // ! GUEST_PAGING_LEVELS >= 4
>> -SHADOW_ERROR("called in wrong paging mode!\n");
>> -BUG();
>> -return 0;
>> +BUG(); /* Called in wrong paging mode! */
>> #endif
>> }
> Isn't this going to break the build for certain older gcc versions?
> ISTR some similar problems in the past.
Perhaps, but since this code was written, BUG() has gained an
unreachable() hint. As other examples of this code like this compile, I
don't think this is going to be a problem.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] libxl: made vm mac address assignment deterministic
Uses MD5 on the host mac address, vm name and vif index to generate the
last three bytes of the vm mac address (for each vm).
It uses the vif index to account for multiple vifs.
MD5 code is originally from the public domain (written by Colin Plumb in
1993), files found in xen/tools/blktap2/drivers/.
Reported-by: George Dunlap
Signed-off-by: Joshua Perrett
---
tools/libxl/Makefile| 2 +-
tools/libxl/libxl_nic.c | 65 ++--
tools/libxl/md5.c | 266
tools/libxl/md5.h | 26 +
4 files changed, 352 insertions(+), 7 deletions(-)
create mode 100644 tools/libxl/md5.c
create mode 100644 tools/libxl/md5.h
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 6da342ed61..6e7db11367 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -142,7 +142,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o
libxl_pci.o \
libxl_9pfs.o libxl_domain.o libxl_vdispl.o \
libxl_pvcalls.o libxl_vsnd.o libxl_vkb.o $(LIBXL_OBJS-y)
LIBXL_OBJS += libxl_genid.o
-LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
+LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o md5.o
LIBXL_TESTS += timedereg
LIBXL_TESTS_PROGS = $(LIBXL_TESTS) fdderegrace
diff --git a/tools/libxl/libxl_nic.c b/tools/libxl/libxl_nic.c
index 01b711b84e..9a1c0fb16f 100644
--- a/tools/libxl/libxl_nic.c
+++ b/tools/libxl/libxl_nic.c
@@ -17,6 +17,18 @@
#include "libxl_internal.h"
+#include
+
+#include "md5.h"
+
+#ifdef __linux__
+#include
+#include
+#include
+#include
+#include
+#endif
+
int libxl_mac_to_device_nic(libxl_ctx *ctx, uint32_t domid,
const char *mac, libxl_device_nic *nic)
{
@@ -53,8 +65,38 @@ int libxl_mac_to_device_nic(libxl_ctx *ctx, uint32_t domid,
return rc;
}
+static int libxl__get_host_mac(libxl__gc *gc, unsigned char *buf)
+{
+int rc = -1;
+#ifdef __linux__
+struct ifaddrs *iface_list;
+
+if (getifaddrs(_list) == 0) {
+for (struct ifaddrs *iface = iface_list;
+iface != NULL; iface = iface->ifa_next) {
+if (iface->ifa_addr && iface->ifa_addr->sa_family == AF_PACKET) {
+struct sockaddr_ll *s = (struct sockaddr_ll *)iface->ifa_addr;
+if (s->sll_halen == 6) {
+memcpy(buf, s->sll_addr, 6);
+if(buf[0] || buf[1] || buf[2] || buf[3] || buf[4] ||
buf[5]) {
+rc = 0;
+break;
+}
+}
+}
+}
+freeifaddrs(iface_list);
+} else {
+LOG(ERROR, "getifaddrs\n");
+}
+#endif
+
+return rc;
+}
+
static int libxl__device_nic_setdefault(libxl__gc *gc, uint32_t domid,
-libxl_device_nic *nic, bool hotplug)
+libxl_device_nic *nic, const char
*name,
+const int nic_index, bool hotplug)
{
int rc;
@@ -65,11 +107,22 @@ static int libxl__device_nic_setdefault(libxl__gc *gc,
uint32_t domid,
if (!nic->model) return ERROR_NOMEM;
}
if (libxl__mac_is_default(>mac)) {
-const uint8_t *r;
-libxl_uuid uuid;
+uint8_t r[16];
+
+MD5_CTX ctx;
+MD5Init();
+
+uint8_t hostmac[6] = {0};
+
+if(libxl__get_host_mac(gc, hostmac) == 0) {
+MD5Update(, hostmac, sizeof(hostmac));
+} else {
+LOGD(WARN, domid, "failed to get host mac address, will generate
vm mac address without\n");
+}
-libxl_uuid_generate();
-r = libxl_uuid_bytearray();
+MD5Update(, (uint8_t *) name, strlen(name));
+MD5Update(, (uint8_t *) _index, sizeof(nic_index));
+MD5Final(r, );
nic->mac[0] = 0x00;
nic->mac[1] = 0x16;
@@ -478,7 +531,7 @@ int libxl__device_nic_set_devids(libxl__gc *gc,
libxl_domain_config *d_config,
* but qemu needs the nic information to be complete.
*/
ret = libxl__device_nic_setdefault(gc, domid, _config->nics[i],
- false);
+ d_config->c_info.name, i, false);
if (ret) {
LOGD(ERROR, domid, "Unable to set nic defaults for nic %d", i);
goto out;
diff --git a/tools/libxl/md5.c b/tools/libxl/md5.c
new file mode 100644
index 00..88ea13938a
--- /dev/null
+++ b/tools/libxl/md5.c
@@ -0,0 +1,266 @@
+/* start - public domain MD5 implementation */
+/*
+ * This code implements the MD5 message-digest algorithm.
+ * The algorithm is due to Ron Rivest. This code was
+ * written by Colin Plumb in 1993, no copyright is claimed.
+ * This code is in the public domain; do with it what you wish.
+ *
+ * Equivalent code is available from RSA Data Security, Inc.
+ * This code has been tested
Re: [Xen-devel] [PATCH] x86/hvm: Fix mapping corner case during task switching.
>>> On 28.08.18 at 20:17, wrote: > hvm_map_entry() can fail for a number of reasons, including for a misaligned > LDT/GDT access which crosses a 4K boundary. Architecturally speaking, this > should be fixed, but Long Mode doesn't support task switches, and no 32bit OS > is going to misalign its LDT/GDT base, which is why this task isn't very high > on the TODO list. > > However, the hvm_map_fail error label returns failure without raising an > exception, which interferes with hvm_task_switch()'s exception tracking, and > can cause it to finish and return to guest context as if the task switch had > completed successfully. > > Resolve this corner case by folding all the failure paths together, which > causes an hvm_map_entry() failure to result in #TS[SEL]. hvm_unmap_entry() > copes fine with a NULL pointer so can be called unconditionally. > > In practice, this is just a latent corner case as all hvm_map_entry() failures > crash the domain, but it should be fixed nevertheless. > > Finally, rename hvm_load_segment_selector() to task_switch_load_seg() to avoid > giving the impression that it is usable for general segment loading. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/mm: Drop {HAP,SHADOW}_ERROR() wrappers
>>> On 28.08.18 at 20:11, wrote:
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -304,10 +304,11 @@ static void hap_free_p2m_page(struct domain *d, struct
> page_info *pg)
> /* Should still have no owner and count zero. */
> if ( owner || (pg->count_info & PGC_count_mask) )
> {
> -HAP_ERROR("d%d: Odd p2m page %"PRI_mfn" d=%d c=%lx
> t=%"PRtype_info"\n",
> - d->domain_id, mfn_x(page_to_mfn(pg)),
> - owner ? owner->domain_id : DOMID_INVALID,
> - pg->count_info, pg->u.inuse.type_info);
> +printk(XENLOG_ERR
> + "d%d: Odd p2m page %"PRI_mfn" d=%d c=%lx t=%"PRtype_info"\n",
> + d->domain_id, mfn_x(page_to_mfn(pg)),
> + owner ? owner->domain_id : DOMID_INVALID,
> + pg->count_info, pg->u.inuse.type_info);
> WARN();
This being WARN(), perhaps then also XENLOG_WARNING?
> @@ -2478,9 +2478,7 @@ sh_map_and_validate_gl4e(struct vcpu *v, mfn_t gl4mfn,
> shadow_l4_index,
> validate_gl4e);
> #else // ! GUEST_PAGING_LEVELS >= 4
> -SHADOW_ERROR("called in wrong paging mode!\n");
> -BUG();
> -return 0;
> +BUG(); /* Called in wrong paging mode! */
> #endif
> }
Isn't this going to break the build for certain older gcc versions?
ISTR some similar problems in the past.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v1] xen: creating debug info is optional
Creating debug info during build is not strictly required at runtime. Make it optional by reusing the existing 'debug_symbols=n' knob. This slightly reduces build time and diskusage, if specified. Signed-off-by: Olaf Hering --- xen/Rules.mk | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/xen/Rules.mk b/xen/Rules.mk index 47c954425d..740b0235e1 100644 --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -55,7 +55,10 @@ endif CFLAGS += -nostdinc -fno-builtin -fno-common CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith -CFLAGS += -pipe -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h +ifeq ($(debug_symbols),y) +CFLAGS += -g +endif +CFLAGS += -pipe -D__XEN__ -include $(BASEDIR)/include/xen/config.h CFLAGS += '-D__OBJECT_FILE__="$@"' ifneq ($(clang),y) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] tmem: delete
Just kidding (for now), but according to our agreement it would be ripe: No adjustments towards the better have been made for more than a year, i.e. in particular nothing has happened with it for the entire 4.11 and 4.10 release cycles. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-upstream-unstable test] 126937: tolerable FAIL - PUSHED
flight 126937 qemu-upstream-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/126937/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail in 126844 pass in 126937 test-armhf-armhf-xl-vhd 11 guest-startfail pass in 126844 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 126844 never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 126844 never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125919 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125919 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125919 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125919 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-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 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-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-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 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-amd64-amd64-libvirt-vhd 12 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-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 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-libvirt-raw 12 migrate-support-checkfail 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: qemuude5b678ca4dcdfa83e322491d478d66df56c1986 baseline version: qemuu4f080070a9809bde857851e68a3aeff0c4b9b6a6 Last test of basis 125919 2018-08-15 11:37:57 Z 15 days Testing same since 126844 2018-08-28 09:37:15 Z2 days2 attempts People who touched revisions under test: Marcel Apfelbaum jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm
Re: [Xen-devel] [PATCH 7/7] x86/hvm: Drop hvm_{vmx,svm} shorthands
>>> On 28.08.18 at 19:39, wrote:
> By making {vmx,svm} in hvm_vcpu into an anonymous union (consistent with
> domain side of things), the hvm_{vmx,svm} defines can be dropped, and all code
> refer to the correctly-named fields. This means that the data hierachy is no
> longer obscured from grep/cscope/tags/etc.
>
> Reformat one comment and switch one bool_t to bool while making changes.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 6/7] x86/svm: Rename arch_svm_struct to svm_vcpu
>>> On 28.08.18 at 19:39, wrote: > The suffix and prefix are redundant, and the name is curiously odd. Rename it > to svm_vcpu to be consistent with all the other similar structures. > > No functional change. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Wei Liu > CC: Roger Pau Monné > CC: Boris Ostrovsky > CC: Suravee Suthikulpanit > CC: Brian Woods > > All of the local pointers are named arch_svm. I'm open to renaming them to > just svm if people are happy with the additional patch delta. Same here - with or without 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 5/7] x86/vtx: Rename arch_vmx_struct to vmx_vcpu
>>> On 28.08.18 at 19:39, wrote: > The suffix and prefix are redundant, and the name is curiously odd. Rename it > to vmx_vcpu to be consistent with all the other similar structures. > > No functional change. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Wei Liu > CC: Roger Pau Monné > CC: Jun Nakajima > CC: Kevin Tian > > Some of the local pointers are named arch_vmx. I'm open to renaming them to > just vmx (like all the other local pointers) if people are happy with the > additional patch delta. I'd be fine with that. With or without 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 4/7] x86/hvm: Rename v->arch.hvm_vcpu to v->arch.hvm
>>> On 28.08.18 at 19:39, wrote: >>> On 28.08.18 at 19:39, wrote: > The trailing _vcpu suffix is redundant, but adds to code volume. Drop it. > > Reflow lines as appropriate, and switch to using the new XFREE/etc wrappers > where applicable. I couldn't find any such conversion, so perhaps better to delete that part of the description. > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich > @@ -3888,19 +3886,19 @@ void hvm_vcpu_reset_state(struct vcpu *v, uint16_t > cs, uint16_t ip) > v->arch.user_regs.rip = ip; > memset(>arch.debugreg, 0, sizeof(v->arch.debugreg)); > > -v->arch.hvm_vcpu.guest_cr[0] = X86_CR0_ET; > +v->arch.hvm.guest_cr[0] = X86_CR0_ET; > hvm_update_guest_cr(v, 0); > > -v->arch.hvm_vcpu.guest_cr[2] = 0; > +v->arch.hvm.guest_cr[2] = 0; > hvm_update_guest_cr(v, 2); > > -v->arch.hvm_vcpu.guest_cr[3] = 0; > +v->arch.hvm.guest_cr[3] = 0; > hvm_update_guest_cr(v, 3); > > -v->arch.hvm_vcpu.guest_cr[4] = 0; > +v->arch.hvm.guest_cr[4] = 0; > hvm_update_guest_cr(v, 4); > > -v->arch.hvm_vcpu.guest_efer = 0; > +v->arch.hvm.guest_efer = 0; > hvm_update_guest_efer(v); Noticing this, a thought unrelated to this series: Wouldn't we be better off setting all the structure fields first, and only then invoke all the functions? Just like arch_set_info_hvm_guest() does? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1 1/6] arm: add SMC wrapper that is compatible with SMCCC
Hi Julien, On 22.08.18 19:46, Julien Grall wrote: [...] +++ b/xen/arch/arm/arm32/smc.S @@ -0,0 +1,39 @@ +/* + * xen/arch/arm/arm32/smc.S + * + * Wrapper for Secure Monitors Calls + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. Xen is GPLv2 only. Can you please update the copyright accordingly? I'll fix this, no problem. But I can see number of files with this clause "either version 2 of the License, or (at your option) any later version". Do maintainers/code owners plan to update existing files? Also, are there any plans to switch to SPDX-Licence-Identifier? -- Volodymyr Babchuk ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 3/7] xen/hvm: Rename d->arch.hvm_domain to d->arch.hvm
>>> On 28.08.18 at 19:39, wrote:
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -173,7 +173,7 @@ static DEFINE_RCU_READ_LOCK(msixtbl_rcu_lock);
> */
> static bool msixtbl_initialised(const struct domain *d)
> {
> -return !!d->arch.hvm_domain.msixtbl_list.next;
> +return !!d->arch.hvm.msixtbl_list.next;
How about dropping the !! here at the same time?
> @@ -1643,7 +1643,7 @@ void vmx_vcpu_flush_pml_buffer(struct vcpu *v)
>
> bool_t vmx_domain_pml_enabled(const struct domain *d)
> {
> -return !!(d->arch.hvm_domain.vmx.status & VMX_DOMAIN_PML_ENABLED);
> +return !!(d->arch.hvm.vmx.status & VMX_DOMAIN_PML_ENABLED);
> }
And here.
> @@ -112,7 +112,7 @@ static void vpic_update_int_output(struct hvm_hw_vpic
> *vpic)
> if ( vpic->is_master )
> {
> /* Master INT line is connected in Virtual Wire Mode. */
> -struct vcpu *v = vpic_domain(vpic)->arch.hvm_domain.i8259_target;
> +struct vcpu *v = vpic_domain(vpic)->arch.hvm.i8259_target;
> if ( v != NULL )
And adding a blank line here?
In any event
Reviewed-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 126991: tolerable all pass - PUSHED
flight 126991 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/126991/ 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 version targeted for testing: xen fc5e7213f4f84b28c0557c8dbe16573f76932866 baseline version: xen aed19fb5370df48527fba82c88c6b7411776283a Last test of basis 126985 2018-08-30 08:00:33 Z0 days Testing same since 126991 2018-08-30 11:00:44 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Jan Beulich Kevin Tian Zhenzhong Duan jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass 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 aed19fb537..fc5e7213f4 fc5e7213f4f84b28c0557c8dbe16573f76932866 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC] xen/vsprintf: Introduce %pd formatter for domains
>>> On 30.08.18 at 15:06, wrote:
> This allows all system domids to be printed by name, rather than special
> casing the idle vcpus alone.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: George Dunlap
> CC: Jan Beulich
> CC: Konrad Rzeszutek Wilk
> CC: Stefano Stabellini
> CC: Tim Deegan
> CC: Wei Liu
> CC: Julien Grall
>
> RFC, because this was proposed before but rejected at the time. I'm looking
> to try and turn errors like this:
>
> (XEN) mm.c:1023:d0v2 pg_owner d32754 l1e_owner d0, but real_pg_owner d0
> (XEN) mm.c:1099:d0v2 Error getting mfn 810020 (pfn 59db1) from L1 entry
> 800810020227 for l1e_owner d0, pg_owner d32754
>
> into the slightly more helpful:
>
> (XEN) mm.c:1022:d0v2 pg_owner dXEN l1e_owner d0, but real_pg_owner d0
> (XEN) mm.c:1098:d0v2 Error getting mfn 810020 (pfn 59db1) from L1 entry
> 800810020227 for l1e_owner d0, pg_owner dXEN
>
> although even in this case, the former printk has an awkward corner case of a
> possibly NULL domain pointer, which can possibly only reasonably be fixed
> inside pointer() itself.
Or in print_domain(), producing "NULL".
> --- a/docs/misc/printk-formats.txt
> +++ b/docs/misc/printk-formats.txt
> @@ -28,5 +28,8 @@ Symbol/Function pointers:
>
> Domain and vCPU information:
>
> + %pd Domain from a 'struct domain *d' (printed as d, but
> with
> + system domains represented by name, e.g. 'dIDLE')
This looks a little awkward - how about d etc?
> --- a/xen/common/vsprintf.c
> +++ b/xen/common/vsprintf.c
> @@ -264,6 +264,41 @@ static char *string(char *str, char *end, const char *s,
> return str;
> }
>
> +/* Print a domain as d or d for system domains. */
> +static char *print_domain(char *str, char *end, const struct domain *d)
> +{
> +const char *name = NULL;
> +
> +if ( str < end )
> +*str++ = 'd';
I would guess you've copied this idiom from somewhere, and if so
it would be good to know where we still have got such broken
construct(s) left: The increment needs to happen outside of the
if(), for snprintf() et al to return a large enough number. See e.g.
string(). Perhaps best to do this like you do ...
> +static char *print_vcpu(char *str, char *end, const struct vcpu *v)
> +{
> +str = print_domain(str, end, v->domain);
> +
> +if ( str < end )
> +*str = 'v';
> +
> +return number(str + 1, end, v->vcpu_id, 10, -1, -1, 0);
... here.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen: Fix inconsistent callers of panic()
>>> On 30.08.18 at 14:31, wrote: > Callers are inconsistent with whether they pass a newline to panic(), > including adjacent calls in the same function using different styles. > > painc() not expecting a newline is inconsistent with most other printing > functions, which is most likely why we've gained so many inconsistencies. > > Switch panic() to expect a newline, and update all callers which currently > lack a newline to include one. > > This actually reduces the size of .rodata (0x07e3e8 down to 0x07e3a8) because > a number of strings are passed to both panic() and printk(). As they > previously differed by \n alone, they couldn't be merged. I agree this is a nice side effect, but ... > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Wei Liu > CC: Stefano Stabellini > CC: Julien Grall > > (Restricted to the core arch maintainers as this is a tree-wide piece of > cleanup with no functional impact to other areas.) > > The observant amongst you might realise that this reverts parts of c/s > 51ad90aea21c - What can I say? Several years of hindsight is very useful, and > at the time I did ask the maintainers which option they thought would be > better... ... I think both the earlier and this change are heading in the wrong direction: I would much rather see the newline omitted everywhere, _including_ in panic() itself: This causes one line less to scroll off the screen in case you don't have a serial console. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 4/6] VMX: correct PDPTE load checks
>>> On 28.08.18 at 15:12, wrote:
> On 19/07/18 11:49, Jan Beulich wrote:
>> Checking the low 5 bits of CR3 is not the job of vmx_load_pdptrs().
>> Instead it should #GP upon bad PDPTE values, rather than causing a VM
>> entry failure.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -1361,20 +1361,18 @@ static void vmx_set_interrupt_shadow(str
>> __vmwrite(GUEST_INTERRUPTIBILITY_INFO, intr_shadow);
>> }
>>
>> -static void vmx_load_pdptrs(struct vcpu *v)
>> +static bool vmx_load_pdptrs(struct vcpu *v)
>> {
>> unsigned long cr3 = v->arch.hvm_vcpu.guest_cr[3];
>> -uint64_t *guest_pdptes;
>> +uint64_t *guest_pdptes, valid_mask;
>> struct page_info *page;
>> p2m_type_t p2mt;
>> char *p;
>> +unsigned int i;
>>
>> /* EPT needs to load PDPTRS into VMCS for PAE. */
>> if ( !hvm_pae_enabled(v) || (v->arch.hvm_vcpu.guest_efer & EFER_LMA) )
>> -return;
>> -
>> -if ( (cr3 & 0x1fUL) && !hvm_pcid_enabled(v) )
>> -goto crash;
>> +return true;
>>
>> page = get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT, ,
>> P2M_UNSHARE);
>
> cr3 needs truncating to 32 bits before doing this. The upper bits of
> cr3 can remain set after transitioning away from long mode, which will
> cause this emulation to do the wrong thing.
In which case the easiest thing would be to change the variable's
type. I've done this, albeit it's sort of orthogonal to what the patch
has been meaning to do till now.
>> -/*
>> - * We do not check the PDPTRs for validity. The CPU will do this during
>> - * vm entry, and we can handle the failure there and crash the guest.
>> - * The only thing we could do better here is #GP instead.
>> - */
>> +valid_mask = ((1ULL << v->domain->arch.cpuid->extd.maxphysaddr) - 1) &
>> + (PAGE_MASK | _PAGE_AVAIL | _PAGE_PRESENT);
>
> How did you come across this list? The only valid bits are Present, PWT
> and PCD, while the upper nibble of control bits is documented as ignored
> rather than reserved.
As to the upper nibble (_PAGE_AVAIL I assume, which are only 3 bits) -
that's what the mask sets. As the name says, it's a collection of bits
which are valid to be set here (which necessarily includes ignored bits;
we're only interested in its inverted value for masking purposes).
As to PWT and PCD, the set above was based on the foot note to
section "Checks on Guest Page-Directory-Pointer-Table Entries"
saying
"This implies that (1) bits 11:9 in each PDPTE are ignored; and (2) if bit 0
(present) is clear in one of the PDPTEs, bits 63:1 of that PDPTE are
ignored."
But I now realize that I've wrongly implied this to be a complete
description.
>> +for ( i = 0; i < 4; ++i )
>> +if ( (guest_pdptes[i] & _PAGE_PRESENT) &&
>> + (guest_pdptes[i] & ~valid_mask) )
>> +{
>> +if ( v == current )
>> +hvm_inject_hw_exception(TRAP_gp_fault, 0);
>
> The function is void for the same reason why this isn't correct. We are
> in the hvm_update_* path rather than the set_* path, which is beyond the
> point of being able to unwind (and why I haven't yet got around to
> fixing this function).
>
> The only way I can see of fixing this is plumbing everything into a new
> paging_set_cr3() callback, which can return X86EMUL_EXCEPTION and fail
> the hvm_set_cr3() call.
Hmm, I see. I'll see about doing this. But why would this be a paging
hook? It looks to me as if this wants to be another entry in hvm_funcs,
also taking into consideration that on AMD/NPT the PDPTRs are
documented not to work the "normal" way. If it was a paging one,
where would you call it from?
I'm also anticipating a further complication: If we split the function,
how would we guarantee that the read/check one has always been
invoked before the load one? After all we'd have to latch the values
read from memory in the former in order to use the validated values
in the latter. This is in particular because hvm_update_guest_cr3()
looks to be called from a number of paths not having come though
hvm_set_cr3() (which anyway itself invokes paging_update_cr3()).
A pretty good (or bad) example is hvmop_flush_tlb_all(), in
particular considering the comment there.
Bottom line - I think the patch here is an improvement in its own right,
and further improvements should perhaps be done separately. In
the meantime I wonder whether the failure path in
vmx_update_guest_cr() could attempt some rollback (the prior CR3
value must have been fine after all, leaving aside the fact that the
it may have been loaded with CR4.PAE still clear, which is a rather
fragile way of changing paging modes anyway).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH RFC] xen/vsprintf: Introduce %pd formatter for domains
This allows all system domids to be printed by name, rather than special
casing the idle vcpus alone.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Julien Grall
RFC, because this was proposed before but rejected at the time. I'm looking
to try and turn errors like this:
(XEN) mm.c:1023:d0v2 pg_owner d32754 l1e_owner d0, but real_pg_owner d0
(XEN) mm.c:1099:d0v2 Error getting mfn 810020 (pfn 59db1) from L1 entry
800810020227 for l1e_owner d0, pg_owner d32754
into the slightly more helpful:
(XEN) mm.c:1022:d0v2 pg_owner dXEN l1e_owner d0, but real_pg_owner d0
(XEN) mm.c:1098:d0v2 Error getting mfn 810020 (pfn 59db1) from L1 entry
800810020227 for l1e_owner d0, pg_owner dXEN
although even in this case, the former printk has an awkward corner case of a
possibly NULL domain pointer, which can possibly only reasonably be fixed
inside pointer() itself.
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date: Wed Aug 29 16:16:50 2018 +
#
# On branch xen-pd
# Your branch is ahead of 'origin/staging' by 1 commit.
# (use "git push" to publish your local commits)
#
# Changes to be committed:
# modified: ../docs/misc/printk-formats.txt
# modified: common/vsprintf.c
#
# Untracked files:
# System.map-after
# System.map-before
# dis-after
# dis-before
# headers-after
# headers-before
# include/asm-x86/asm-macros.h
# wl-a
# wl-b
# xen-after
# xen-before
# xen-syms-after
# xen-syms-before
#
---
docs/misc/printk-formats.txt | 3 +++
xen/common/vsprintf.c| 57 +++-
2 files changed, 49 insertions(+), 11 deletions(-)
diff --git a/docs/misc/printk-formats.txt b/docs/misc/printk-formats.txt
index 525108f..6d2c617 100644
--- a/docs/misc/printk-formats.txt
+++ b/docs/misc/printk-formats.txt
@@ -28,5 +28,8 @@ Symbol/Function pointers:
Domain and vCPU information:
+ %pd Domain from a 'struct domain *d' (printed as d, but with
+ system domains represented by name, e.g. 'dIDLE')
+
%pv Domain and vCPU ID from a 'struct vcpu *' (printed as
"dv")
diff --git a/xen/common/vsprintf.c b/xen/common/vsprintf.c
index f92fb67..918a39d 100644
--- a/xen/common/vsprintf.c
+++ b/xen/common/vsprintf.c
@@ -264,6 +264,41 @@ static char *string(char *str, char *end, const char *s,
return str;
}
+/* Print a domain as d or d for system domains. */
+static char *print_domain(char *str, char *end, const struct domain *d)
+{
+const char *name = NULL;
+
+if ( str < end )
+*str++ = 'd';
+
+switch ( d->domain_id )
+{
+case DOMID_SELF:name = "SELF";break;
+case DOMID_IO: name = "IO"; break;
+case DOMID_XEN: name = "XEN"; break;
+case DOMID_COW: name = "COW"; break;
+case DOMID_INVALID: name = "INVALID"; break;
+case DOMID_IDLE:name = "IDLE";break;
+}
+
+if ( name )
+return string(str, end, name, -1, -1, 0);
+else
+return number(str, end, d->domain_id, 10, -1, -1, 0);
+}
+
+/* Print a vcpu as dv */
+static char *print_vcpu(char *str, char *end, const struct vcpu *v)
+{
+str = print_domain(str, end, v->domain);
+
+if ( str < end )
+*str = 'v';
+
+return number(str + 1, end, v->vcpu_id, 10, -1, -1, 0);
+}
+
static char *pointer(char *str, char *end, const char **fmt_ptr,
const void *arg, int field_width, int precision,
int flags)
@@ -273,6 +308,15 @@ static char *pointer(char *str, char *end, const char
**fmt_ptr,
/* Custom %p suffixes. See XEN_ROOT/docs/misc/printk-formats.txt */
switch ( fmt[1] )
{
+case 'd': /* d from a struct domain */
+{
+const struct domain *d = arg;
+
+++*fmt_ptr;
+
+return print_domain(str, end, d);
+}
+
case 'h': /* Raw buffer as hex string. */
{
const uint8_t *hex_buffer = arg;
@@ -374,17 +418,8 @@ static char *pointer(char *str, char *end, const char
**fmt_ptr,
const struct vcpu *v = arg;
++*fmt_ptr;
-if ( unlikely(v->domain->domain_id == DOMID_IDLE) )
-str = string(str, end, "IDLE", -1, -1, 0);
-else
-{
-if ( str < end )
-*str = 'd';
-str = number(str + 1, end, v->domain->domain_id, 10, -1, -1, 0);
-}
-if ( str < end )
-*str = 'v';
-return number(str + 1, end, v->vcpu_id, 10, -1, -1, 0);
+
+return print_vcpu(str, end, v);
}
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] xen/ARM+sched: Don't opencode %pv in printk()'s
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Stefano Stabellini
CC: Julien Grall
CC: George Dunlap
CC: Dario Faggioli
---
xen/arch/arm/gic-vgic.c | 12 ++--
xen/common/sched_null.c | 15 ++-
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index fd63906..990399c 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -94,8 +94,8 @@ void gic_raise_inflight_irq(struct vcpu *v, unsigned int
virtual_irq)
}
#ifdef GIC_DEBUG
else
-gdprintk(XENLOG_DEBUG, "trying to inject irq=%u into d%dv%d, when it
is still lr_pending\n",
- virtual_irq, v->domain->domain_id, v->vcpu_id);
+gdprintk(XENLOG_DEBUG, "trying to inject irq=%u into %pv, when it is
still lr_pending\n",
+ virtual_irq, v);
#endif
}
@@ -201,8 +201,8 @@ static void gic_update_one_lr(struct vcpu *v, int i)
gic_hw_ops->write_lr(i, _val);
}
else
-gdprintk(XENLOG_WARNING, "unable to inject hw irq=%d into
d%dv%d: already active in LR%d\n",
- irq, v->domain->domain_id, v->vcpu_id, i);
+gdprintk(XENLOG_WARNING, "unable to inject hw irq=%d into %pv:
already active in LR%d\n",
+ irq, v, i);
}
}
else if ( lr_val.pending )
@@ -210,8 +210,8 @@ static void gic_update_one_lr(struct vcpu *v, int i)
int q __attribute__ ((unused)) =
test_and_clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
#ifdef GIC_DEBUG
if ( q )
-gdprintk(XENLOG_DEBUG, "trying to inject irq=%d into d%dv%d, when
it is already pending in LR%d\n",
-irq, v->domain->domain_id, v->vcpu_id, i);
+gdprintk(XENLOG_DEBUG, "trying to inject irq=%d into %pv, when it
is already pending in LR%d\n",
+irq, v, i);
#endif
}
else
diff --git a/xen/common/sched_null.c b/xen/common/sched_null.c
index 784db71..7b039b7 100644
--- a/xen/common/sched_null.c
+++ b/xen/common/sched_null.c
@@ -344,7 +344,7 @@ static void vcpu_assign(struct null_private *prv, struct
vcpu *v,
v->processor = cpu;
cpumask_clear_cpu(cpu, >cpus_free);
-dprintk(XENLOG_G_INFO, "%d <-- d%dv%d\n", cpu, v->domain->domain_id,
v->vcpu_id);
+dprintk(XENLOG_G_INFO, "%d <-- %pv\n", cpu, v);
if ( unlikely(tb_init_done) )
{
@@ -365,7 +365,7 @@ static void vcpu_deassign(struct null_private *prv, struct
vcpu *v,
per_cpu(npc, cpu).vcpu = NULL;
cpumask_set_cpu(cpu, >cpus_free);
-dprintk(XENLOG_G_INFO, "%d <-- NULL (d%dv%d)\n", cpu,
v->domain->domain_id, v->vcpu_id);
+dprintk(XENLOG_G_INFO, "%d <-- NULL (%pv)\n", cpu, v);
if ( unlikely(tb_init_done) )
{
@@ -460,8 +460,7 @@ static void null_vcpu_insert(const struct scheduler *ops,
struct vcpu *v)
*/
spin_lock(>waitq_lock);
list_add_tail(>waitq_elem, >waitq);
-dprintk(XENLOG_G_WARNING, "WARNING: d%dv%d not assigned to any CPU!\n",
-v->domain->domain_id, v->vcpu_id);
+dprintk(XENLOG_G_WARNING, "WARNING: %pv not assigned to any CPU!\n",
v);
spin_unlock(>waitq_lock);
}
spin_unlock_irq(lock);
@@ -649,8 +648,7 @@ static void null_vcpu_migrate(const struct scheduler *ops,
struct vcpu *v,
if ( list_empty(>waitq_elem) )
{
list_add_tail(>waitq_elem, >waitq);
-dprintk(XENLOG_G_WARNING, "WARNING: d%dv%d not assigned to any
CPU!\n",
-v->domain->domain_id, v->vcpu_id);
+dprintk(XENLOG_G_WARNING, "WARNING: %pv not assigned to any
CPU!\n", v);
}
spin_unlock(>waitq_lock);
}
@@ -804,8 +802,7 @@ static void null_dump_pcpu(const struct scheduler *ops, int
cpu)
cpumask_scnprintf(cpustr, sizeof(cpustr), per_cpu(cpu_core_mask, cpu));
printk("core=%s", cpustr);
if ( per_cpu(npc, cpu).vcpu != NULL )
-printk(", vcpu=d%dv%d", per_cpu(npc, cpu).vcpu->domain->domain_id,
- per_cpu(npc, cpu).vcpu->vcpu_id);
+printk(", vcpu=%pv", per_cpu(npc, cpu).vcpu);
printk("\n");
/* current VCPU (nothing to say if that's the idle vcpu) */
@@ -870,7 +867,7 @@ static void null_dump(const struct scheduler *ops)
printk(", ");
if ( loop % 24 == 0 )
printk("\n\t");
-printk("d%dv%d", nvc->vcpu->domain->domain_id, nvc->vcpu->vcpu_id);
+printk("%pv", nvc->vcpu);
}
printk("\n");
spin_unlock(>waitq_lock);
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [distros-debian-wheezy test] 75142: regressions - FAIL
flight 75142 distros-debian-wheezy real [real] http://osstest.xensource.com/osstest/logs/75142/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-i386-wheezy-netboot-pvgrub 10 debian-di-install fail REGR. vs. 75110 test-amd64-i386-amd64-wheezy-netboot-pygrub 10 debian-di-install fail REGR. vs. 75110 baseline version: flight 75110 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass test-amd64-i386-i386-wheezy-netboot-pvgrub fail test-amd64-i386-amd64-wheezy-netboot-pygrub fail test-amd64-amd64-i386-wheezy-netboot-pygrub pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] xen: Fix inconsistent callers of panic()
Callers are inconsistent with whether they pass a newline to panic(),
including adjacent calls in the same function using different styles.
painc() not expecting a newline is inconsistent with most other printing
functions, which is most likely why we've gained so many inconsistencies.
Switch panic() to expect a newline, and update all callers which currently
lack a newline to include one.
This actually reduces the size of .rodata (0x07e3e8 down to 0x07e3a8) because
a number of strings are passed to both panic() and printk(). As they
previously differed by \n alone, they couldn't be merged.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
(Restricted to the core arch maintainers as this is a tree-wide piece of
cleanup with no functional impact to other areas.)
The observant amongst you might realise that this reverts parts of c/s
51ad90aea21c - What can I say? Several years of hindsight is very useful, and
at the time I did ask the maintainers which option they thought would be
better...
---
xen/arch/arm/arm32/vfp.c | 2 +-
xen/arch/arm/arm64/traps.c | 2 +-
xen/arch/arm/domain_build.c | 20 ++--
xen/arch/arm/gic-v2.c| 24
xen/arch/arm/gic-v3-its.c| 4 ++--
xen/arch/arm/gic-v3.c| 14 +++---
xen/arch/arm/gic.c | 10 +-
xen/arch/arm/kernel.c| 8
xen/arch/arm/mm.c| 2 +-
xen/arch/arm/p2m.c | 2 +-
xen/arch/arm/platform.c | 2 +-
xen/arch/arm/platforms/xgene-storm.c | 6 +++---
xen/arch/arm/setup.c | 12 ++--
xen/arch/arm/smpboot.c | 2 +-
xen/arch/arm/time.c | 8
xen/arch/arm/traps.c | 8
xen/arch/arm/vgic/vgic.c | 2 +-
xen/arch/x86/acpi/power.c| 2 +-
xen/arch/x86/alternative.c | 2 +-
xen/arch/x86/apic.c | 5 ++---
xen/arch/x86/cpu/mcheck/mce.c| 4 ++--
xen/arch/x86/guest/xen.c | 18 +-
xen/arch/x86/hvm/dom0_build.c| 2 +-
xen/arch/x86/hvm/svm/intr.c | 2 +-
xen/arch/x86/io_apic.c | 8
xen/arch/x86/mm/mm-locks.h | 2 +-
xen/arch/x86/mpparse.c | 10 +-
xen/arch/x86/numa.c | 2 +-
xen/arch/x86/pv/dom0_build.c | 20 ++--
xen/arch/x86/pv/shim.c | 2 +-
xen/arch/x86/setup.c | 16
xen/arch/x86/smpboot.c | 4 ++--
xen/arch/x86/tboot.c | 2 +-
xen/arch/x86/time.c | 6 +++---
xen/arch/x86/traps.c | 16
xen/arch/x86/x86_64/mm.c | 2 +-
xen/arch/x86/x86_64/traps.c | 2 +-
xen/common/domain.c | 2 +-
xen/common/gunzip.c | 2 +-
xen/common/schedule.c| 2 +-
xen/common/ubsan/ubsan.c | 2 +-
xen/common/warning.c | 2 +-
xen/drivers/char/console.c | 2 +-
xen/drivers/passthrough/iommu.c | 5 ++---
xen/drivers/passthrough/pci.c| 2 +-
xen/drivers/passthrough/vtd/dmar.h | 2 +-
xen/drivers/passthrough/vtd/iommu.c | 4 ++--
xen/xsm/flask/hooks.c| 4 ++--
48 files changed, 141 insertions(+), 143 deletions(-)
diff --git a/xen/arch/arm/arm32/vfp.c b/xen/arch/arm/arm32/vfp.c
index 5b80053..0069acd 100644
--- a/xen/arch/arm/arm32/vfp.c
+++ b/xen/arch/arm/arm32/vfp.c
@@ -80,7 +80,7 @@ static __init int vfp_init(void)
vfparch = (vfpsid & FPSID_ARCH_MASK) >> FPSID_ARCH_BIT;
if ( vfparch < 2 )
-panic("Xen only support VFP 3");
+panic("Xen only support VFP 3\n");
return 0;
}
diff --git a/xen/arch/arm/arm64/traps.c b/xen/arch/arm/arm64/traps.c
index 38470a1..e524019 100644
--- a/xen/arch/arm/arm64/traps.c
+++ b/xen/arch/arm/arm64/traps.c
@@ -40,7 +40,7 @@ void do_bad_mode(struct cpu_user_regs *regs, int reason)
local_irq_disable();
show_execution_state(regs);
-panic("bad mode");
+panic("bad mode\n");
}
/*
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index e1c79b2..745153d 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -125,7 +125,7 @@ static bool __init insert_11_bank(struct domain *d,
res = guest_physmap_add_page(d, _gfn(mfn_x(smfn)), smfn, order);
if ( res )
-panic("Failed map pages to DOM0: %d", res);
+panic("Failed map pages to DOM0: %d\n", res);
kinfo->unassigned_mem -= size;
@@ -289,7 +289,7 @@ static void __init allocate_memory(struct domain *d, struct
kernel_info *kinfo)
/* Failed to allocate bank0 under 4GB */
if ( is_32bit_domain(d) )
-panic("Unable to allocate first memory bank.");
Re: [Xen-devel] [PATCH RFCv2 0/6] mm: online/offline_pages called w.o. mem_hotplug_lock
On 21.08.2018 12:44, David Hildenbrand wrote: > This is the same approach as in the first RFC, but this time without > exporting device_hotplug_lock (requested by Greg) and with some more > details and documentation regarding locking. Tested only on x86 so far. > I'll be on vacation for two weeks starting on Saturday. If there are no comments I'll send this as !RFC once I return. Thanks! > -- > > Reading through the code and studying how mem_hotplug_lock is to be used, > I noticed that there are two places where we can end up calling > device_online()/device_offline() - online_pages()/offline_pages() without > the mem_hotplug_lock. And there are other places where we call > device_online()/device_offline() without the device_hotplug_lock. > > While e.g. > echo "online" > /sys/devices/system/memory/memory9/state > is fine, e.g. > echo 1 > /sys/devices/system/memory/memory9/online > Will not take the mem_hotplug_lock. However the device_lock() and > device_hotplug_lock. > > E.g. via memory_probe_store(), we can end up calling > add_memory()->online_pages() without the device_hotplug_lock. So we can > have concurrent callers in online_pages(). We e.g. touch in online_pages() > basically unprotected zone->present_pages then. > > Looks like there is a longer history to that (see Patch #2 for details), > and fixing it to work the way it was intended is not really possible. We > would e.g. have to take the mem_hotplug_lock in device/base/core.c, which > sounds wrong. > > Summary: We had a lock inversion on mem_hotplug_lock and device_lock(). > More details can be found in patch 3 and patch 6. > > I propose the general rules (documentation added in patch 6): > > 1. add_memory/add_memory_resource() must only be called with >device_hotplug_lock. > 2. remove_memory() must only be called with device_hotplug_lock. This is >already documented and holds for all callers. > 3. device_online()/device_offline() must only be called with >device_hotplug_lock. This is already documented and true for now in core >code. Other callers (related to memory hotplug) have to be fixed up. > 4. mem_hotplug_lock is taken inside of add_memory/remove_memory/ >online_pages/offline_pages. > > To me, this looks way cleaner than what we have right now (and easier to > verify). And looking at the documentation of remove_memory, using > lock_device_hotplug also for add_memory() feels natural. > > > RFC -> RFCv2: > - Don't export device_hotplug_lock, provide proper remove_memory/add_memory > wrappers. > - Split up the patches a bit. > - Try to improve powernv memtrace locking > - Add some documentation for locking that matches my knowledge > > David Hildenbrand (6): > mm/memory_hotplug: make remove_memory() take the device_hotplug_lock > mm/memory_hotplug: make add_memory() take the device_hotplug_lock > mm/memory_hotplug: fix online/offline_pages called w.o. > mem_hotplug_lock > powerpc/powernv: hold device_hotplug_lock when calling device_online() > powerpc/powernv: hold device_hotplug_lock in memtrace_offline_pages() > memory-hotplug.txt: Add some details about locking internals > > Documentation/memory-hotplug.txt | 39 +++- > arch/powerpc/platforms/powernv/memtrace.c | 14 +++-- > .../platforms/pseries/hotplug-memory.c| 8 +-- > drivers/acpi/acpi_memhotplug.c| 4 +- > drivers/base/memory.c | 22 +++ > drivers/xen/balloon.c | 3 + > include/linux/memory_hotplug.h| 4 +- > mm/memory_hotplug.c | 59 +++ > 8 files changed, 115 insertions(+), 38 deletions(-) > -- Thanks, David / dhildenb ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/pv: Deprecate support for paging out the LDT
>>> On 30.08.18 at 14:27, wrote: > On 30/08/18 13:25, Jan Beulich wrote: > On 30.08.18 at 11:55, wrote: >>> --- a/xen/arch/x86/Kconfig >>> +++ b/xen/arch/x86/Kconfig >>> @@ -164,3 +164,26 @@ endmenu >>> source "common/Kconfig" >>> >>> source "drivers/Kconfig" >>> + >>> +menu "Deprecated Functionality" >>> + >>> +config LEGACY_PV_LDT_PAGING >>> + def_bool n >> Can this please simply be "bool" and depend on PV right away > > Sure. (I believe this patch actually predicates CONFIG_PV entirely). > >> (maybe the name would then also better have PV_ first, but >> I'll leave that part up to you)? With that >> Reviewed-by: Jan Beulich > > Perhaps drop it to just CONFIG_PV_LDT_PAGING ? The LEGACY part is > rather redundant. I was about to suggest that and then didn't, assuming you had put it there on purpose. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/pv: Deprecate support for paging out the LDT
On 30/08/18 13:25, Jan Beulich wrote: On 30.08.18 at 11:55, wrote: >> --- a/xen/arch/x86/Kconfig >> +++ b/xen/arch/x86/Kconfig >> @@ -164,3 +164,26 @@ endmenu >> source "common/Kconfig" >> >> source "drivers/Kconfig" >> + >> +menu "Deprecated Functionality" >> + >> +config LEGACY_PV_LDT_PAGING >> +def_bool n > Can this please simply be "bool" and depend on PV right away Sure. (I believe this patch actually predicates CONFIG_PV entirely). > (maybe the name would then also better have PV_ first, but > I'll leave that part up to you)? With that > Reviewed-by: Jan Beulich Perhaps drop it to just CONFIG_PV_LDT_PAGING ? The LEGACY part is rather redundant. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/HVM: drop hvm_fetch_from_guest_linear()
>>> On 30.08.18 at 14:22, wrote: > On 30/08/18 13:02, Jan Beulich wrote: > On 30.08.18 at 13:18, wrote: >>> On 30/08/18 12:09, Jan Beulich wrote: @@ -2512,9 +2512,10 @@ void hvm_emulate_init_per_insn( hvm_access_insn_fetch, _ctxt->seg_reg[x86_seg_cs], ) && - hvm_fetch_from_guest_linear(hvmemul_ctxt->insn_buf, addr, - sizeof(hvmemul_ctxt->insn_buf), - pfec, NULL) == HVMTRANS_okay) ? + hvm_copy_from_guest_linear(hvmemul_ctxt->insn_buf, addr, +sizeof(hvmemul_ctxt->insn_buf), +pfec | PFEC_insn_fetch, NULL, +NULL) == HVMTRANS_okay) ? >>> Does this even compile? You seem to have an extra NULL here and several >>> later places. >> It does - with "x86/HVM: implement memory read caching" also >> applied. IOW - I'm sorry, insufficient re-ordering work done >> when moving these two ahead. > > Does it? This patch has a mix of callers with 4 and 5 parameters, which > is why I noticed it in the first place. Right, hence the need for that other (re-based) patch on top. I believe I've now moved things suitably between both patches. > With it fixed up to compile, and preferably with the other adjustment > included, Reviewed-by: Andrew Cooper Thanks (and yes, I've followed the other suggestion too), Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/pv: Deprecate support for paging out the LDT
>>> On 30.08.18 at 11:55, wrote: > --- a/xen/arch/x86/Kconfig > +++ b/xen/arch/x86/Kconfig > @@ -164,3 +164,26 @@ endmenu > source "common/Kconfig" > > source "drivers/Kconfig" > + > +menu "Deprecated Functionality" > + > +config LEGACY_PV_LDT_PAGING > + def_bool n Can this please simply be "bool" and depend on PV right away (maybe the name would then also better have PV_ first, but I'll leave that part up to you)? With that 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 1/2] x86/HVM: drop hvm_fetch_from_guest_linear()
On 30/08/18 13:02, Jan Beulich wrote: On 30.08.18 at 13:18, wrote: >> On 30/08/18 12:09, Jan Beulich wrote: >>> @@ -2512,9 +2512,10 @@ void hvm_emulate_init_per_insn( >>> hvm_access_insn_fetch, >>> _ctxt->seg_reg[x86_seg_cs], >>> ) && >>> - hvm_fetch_from_guest_linear(hvmemul_ctxt->insn_buf, addr, >>> - sizeof(hvmemul_ctxt->insn_buf), >>> - pfec, NULL) == HVMTRANS_okay) ? >>> + hvm_copy_from_guest_linear(hvmemul_ctxt->insn_buf, addr, >>> +sizeof(hvmemul_ctxt->insn_buf), >>> +pfec | PFEC_insn_fetch, NULL, >>> +NULL) == HVMTRANS_okay) ? >> Does this even compile? You seem to have an extra NULL here and several >> later places. > It does - with "x86/HVM: implement memory read caching" also > applied. IOW - I'm sorry, insufficient re-ordering work done > when moving these two ahead. Does it? This patch has a mix of callers with 4 and 5 parameters, which is why I noticed it in the first place. With it fixed up to compile, and preferably with the other adjustment included, Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/HVM: drop hvm_fetch_from_guest_linear()
>>> On 30.08.18 at 13:18, wrote: > On 30/08/18 12:09, Jan Beulich wrote: >> @@ -2512,9 +2512,10 @@ void hvm_emulate_init_per_insn( >> hvm_access_insn_fetch, >> _ctxt->seg_reg[x86_seg_cs], >> ) && >> - hvm_fetch_from_guest_linear(hvmemul_ctxt->insn_buf, addr, >> - sizeof(hvmemul_ctxt->insn_buf), >> - pfec, NULL) == HVMTRANS_okay) ? >> + hvm_copy_from_guest_linear(hvmemul_ctxt->insn_buf, addr, >> +sizeof(hvmemul_ctxt->insn_buf), >> +pfec | PFEC_insn_fetch, NULL, >> +NULL) == HVMTRANS_okay) ? > > Does this even compile? You seem to have an extra NULL here and several > later places. It does - with "x86/HVM: implement memory read caching" also applied. IOW - I'm sorry, insufficient re-ordering work done when moving these two ahead. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/HVM: drop hvm_fetch_from_guest_linear()
On 30/08/18 12:09, Jan Beulich wrote: > @@ -3758,8 +3749,9 @@ void hvm_ud_intercept(struct cpu_user_re > if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->rip, > sizeof(sig), hvm_access_insn_fetch, > cs, ) && > - (hvm_fetch_from_guest_linear(sig, addr, sizeof(sig), > - walk, NULL) == HVMTRANS_okay) && > + (hvm_copy_from_guest_linear(sig, addr, sizeof(sig), > + walk | PFEC_insn_fetch, NULL, > + NULL) == HVMTRANS_okay) && This would be more simple by folding PFEC_insn_fetch into the initialisation of walk, as this whole expression is just an instruction fetch. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/HVM: drop hvm_fetch_from_guest_linear()
On 30/08/18 12:09, Jan Beulich wrote:
> It can easily be expressed through hvm_copy_from_guest_linear(), and in
> two cases this even simplifies callers.
>
> Suggested-by: Paul Durrant
> Signed-off-by: Jan Beulich
I really like this piece of cleanup, but...
> ---
> v2: New.
>
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1060,6 +1060,8 @@ static int __hvmemul_read(
> pfec |= PFEC_implicit;
> else if ( hvmemul_ctxt->seg_reg[x86_seg_ss].dpl == 3 )
> pfec |= PFEC_user_mode;
> +if ( access_type == hvm_access_insn_fetch )
> +pfec |= PFEC_insn_fetch;
>
> rc = hvmemul_virtual_to_linear(
> seg, offset, bytes, , access_type, hvmemul_ctxt, );
> @@ -1071,9 +1073,7 @@ static int __hvmemul_read(
> (vio->mmio_gla == (addr & PAGE_MASK)) )
> return hvmemul_linear_mmio_read(addr, bytes, p_data, pfec,
> hvmemul_ctxt, 1);
>
> -rc = ((access_type == hvm_access_insn_fetch) ?
> - hvm_fetch_from_guest_linear(p_data, addr, bytes, pfec, ) :
> - hvm_copy_from_guest_linear(p_data, addr, bytes, pfec, ));
> +rc = hvm_copy_from_guest_linear(p_data, addr, bytes, pfec, );
>
> switch ( rc )
> {
> @@ -2512,9 +2512,10 @@ void hvm_emulate_init_per_insn(
> hvm_access_insn_fetch,
> _ctxt->seg_reg[x86_seg_cs],
> ) &&
> - hvm_fetch_from_guest_linear(hvmemul_ctxt->insn_buf, addr,
> - sizeof(hvmemul_ctxt->insn_buf),
> - pfec, NULL) == HVMTRANS_okay) ?
> + hvm_copy_from_guest_linear(hvmemul_ctxt->insn_buf, addr,
> +sizeof(hvmemul_ctxt->insn_buf),
> +pfec | PFEC_insn_fetch, NULL,
> +NULL) == HVMTRANS_okay) ?
Does this even compile? You seem to have an extra NULL here and several
later places.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH RFC 2/2] x86/HVM: split page straddling emulated accesses in more cases
Assuming consecutive linear addresses map to all RAM or all MMIO is not
correct. Nor is assuming that a page straddling MMIO access will access
the same emulating component for both parts of the access. If a guest
RAM read fails with HVMTRANS_bad_gfn_to_mfn and if the access straddles
a page boundary, issue accesses separately for both parts.
Signed-off-by: Jan Beulich
---
RFC: This clearly wants mirroring to the write path, and perhaps also
to the fallback code on the RMW path. But I'd like to get a sense
first on how welcome the general approach is.
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1041,6 +1041,48 @@ static inline int hvmemul_linear_mmio_wr
pfec, hvmemul_ctxt, translate);
}
+static int linear_read(unsigned long addr, unsigned int bytes, void *p_data,
+ uint32_t pfec, struct hvm_emulate_ctxt *hvmemul_ctxt)
+{
+pagefault_info_t pfinfo;
+int rc = hvm_copy_from_guest_linear(p_data, addr, bytes, pfec, );
+
+switch ( rc )
+{
+unsigned int offset, part1;
+
+case HVMTRANS_okay:
+return X86EMUL_OKAY;
+
+case HVMTRANS_bad_linear_to_gfn:
+x86_emul_pagefault(pfinfo.ec, pfinfo.linear, _ctxt->ctxt);
+return X86EMUL_EXCEPTION;
+
+case HVMTRANS_bad_gfn_to_mfn:
+if ( pfec & PFEC_insn_fetch )
+return X86EMUL_UNHANDLEABLE;
+
+offset = addr & ~PAGE_MASK;
+if ( offset + bytes <= PAGE_SIZE )
+return hvmemul_linear_mmio_read(addr, bytes, p_data, pfec,
+hvmemul_ctxt, 0);
+
+/* Split the access at the page boundary. */
+part1 = PAGE_SIZE - offset;
+rc = linear_read(addr, part1, p_data, pfec, hvmemul_ctxt);
+if ( rc == X86EMUL_OKAY )
+rc = linear_read(addr + part1, bytes - part1, p_data + part1,
+ pfec, hvmemul_ctxt);
+return rc;
+
+case HVMTRANS_gfn_paged_out:
+case HVMTRANS_gfn_shared:
+return X86EMUL_RETRY;
+}
+
+return X86EMUL_UNHANDLEABLE;
+}
+
static int __hvmemul_read(
enum x86_segment seg,
unsigned long offset,
@@ -1049,11 +1091,9 @@ static int __hvmemul_read(
enum hvm_access_type access_type,
struct hvm_emulate_ctxt *hvmemul_ctxt)
{
-struct vcpu *curr = current;
-pagefault_info_t pfinfo;
unsigned long addr, reps = 1;
uint32_t pfec = PFEC_page_present;
-struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
+struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
int rc;
if ( is_x86_system_segment(seg) )
@@ -1073,28 +1113,7 @@ static int __hvmemul_read(
(vio->mmio_gla == (addr & PAGE_MASK)) )
return hvmemul_linear_mmio_read(addr, bytes, p_data, pfec,
hvmemul_ctxt, 1);
-rc = hvm_copy_from_guest_linear(p_data, addr, bytes, pfec, );
-
-switch ( rc )
-{
-case HVMTRANS_okay:
-break;
-case HVMTRANS_bad_linear_to_gfn:
-x86_emul_pagefault(pfinfo.ec, pfinfo.linear, _ctxt->ctxt);
-return X86EMUL_EXCEPTION;
-case HVMTRANS_bad_gfn_to_mfn:
-if ( access_type == hvm_access_insn_fetch )
-return X86EMUL_UNHANDLEABLE;
-
-return hvmemul_linear_mmio_read(addr, bytes, p_data, pfec,
hvmemul_ctxt, 0);
-case HVMTRANS_gfn_paged_out:
-case HVMTRANS_gfn_shared:
-return X86EMUL_RETRY;
-default:
-return X86EMUL_UNHANDLEABLE;
-}
-
-return X86EMUL_OKAY;
+return linear_read(addr, bytes, p_data, pfec, hvmemul_ctxt);
}
static int hvmemul_read(
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/2] x86/HVM: drop hvm_fetch_from_guest_linear()
It can easily be expressed through hvm_copy_from_guest_linear(), and in
two cases this even simplifies callers.
Suggested-by: Paul Durrant
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1060,6 +1060,8 @@ static int __hvmemul_read(
pfec |= PFEC_implicit;
else if ( hvmemul_ctxt->seg_reg[x86_seg_ss].dpl == 3 )
pfec |= PFEC_user_mode;
+if ( access_type == hvm_access_insn_fetch )
+pfec |= PFEC_insn_fetch;
rc = hvmemul_virtual_to_linear(
seg, offset, bytes, , access_type, hvmemul_ctxt, );
@@ -1071,9 +1073,7 @@ static int __hvmemul_read(
(vio->mmio_gla == (addr & PAGE_MASK)) )
return hvmemul_linear_mmio_read(addr, bytes, p_data, pfec,
hvmemul_ctxt, 1);
-rc = ((access_type == hvm_access_insn_fetch) ?
- hvm_fetch_from_guest_linear(p_data, addr, bytes, pfec, ) :
- hvm_copy_from_guest_linear(p_data, addr, bytes, pfec, ));
+rc = hvm_copy_from_guest_linear(p_data, addr, bytes, pfec, );
switch ( rc )
{
@@ -2512,9 +2512,10 @@ void hvm_emulate_init_per_insn(
hvm_access_insn_fetch,
_ctxt->seg_reg[x86_seg_cs],
) &&
- hvm_fetch_from_guest_linear(hvmemul_ctxt->insn_buf, addr,
- sizeof(hvmemul_ctxt->insn_buf),
- pfec, NULL) == HVMTRANS_okay) ?
+ hvm_copy_from_guest_linear(hvmemul_ctxt->insn_buf, addr,
+sizeof(hvmemul_ctxt->insn_buf),
+pfec | PFEC_insn_fetch, NULL,
+NULL) == HVMTRANS_okay) ?
sizeof(hvmemul_ctxt->insn_buf) : 0;
}
else
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3296,15 +3296,6 @@ enum hvm_translation_result hvm_copy_fro
PFEC_page_present | pfec, pfinfo);
}
-enum hvm_translation_result hvm_fetch_from_guest_linear(
-void *buf, unsigned long addr, int size, uint32_t pfec,
-pagefault_info_t *pfinfo)
-{
-return __hvm_copy(buf, addr, size, current,
- HVMCOPY_from_guest | HVMCOPY_linear,
- PFEC_page_present | PFEC_insn_fetch | pfec, pfinfo);
-}
-
unsigned long copy_to_user_hvm(void *to, const void *from, unsigned int len)
{
int rc;
@@ -3758,8 +3749,9 @@ void hvm_ud_intercept(struct cpu_user_re
if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->rip,
sizeof(sig), hvm_access_insn_fetch,
cs, ) &&
- (hvm_fetch_from_guest_linear(sig, addr, sizeof(sig),
- walk, NULL) == HVMTRANS_okay) &&
+ (hvm_copy_from_guest_linear(sig, addr, sizeof(sig),
+ walk | PFEC_insn_fetch, NULL,
+ NULL) == HVMTRANS_okay) &&
(memcmp(sig, "\xf\xbxen", sizeof(sig)) == 0) )
{
regs->rip += sizeof(sig);
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -164,8 +164,9 @@ const struct x86_emulate_ops *shadow_ini
(!hvm_translate_virtual_addr(
x86_seg_cs, regs->rip, sizeof(sh_ctxt->insn_buf),
hvm_access_insn_fetch, sh_ctxt, ) &&
- !hvm_fetch_from_guest_linear(
- sh_ctxt->insn_buf, addr, sizeof(sh_ctxt->insn_buf), 0, NULL))
+ !hvm_copy_from_guest_linear(
+ sh_ctxt->insn_buf, addr, sizeof(sh_ctxt->insn_buf),
+ PFEC_insn_fetch, NULL, NULL))
? sizeof(sh_ctxt->insn_buf) : 0;
return _shadow_emulator_ops;
@@ -198,8 +199,9 @@ void shadow_continue_emulation(struct sh
(!hvm_translate_virtual_addr(
x86_seg_cs, regs->rip, sizeof(sh_ctxt->insn_buf),
hvm_access_insn_fetch, sh_ctxt, ) &&
- !hvm_fetch_from_guest_linear(
- sh_ctxt->insn_buf, addr, sizeof(sh_ctxt->insn_buf), 0, NULL))
+ !hvm_copy_from_guest_linear(
+ sh_ctxt->insn_buf, addr, sizeof(sh_ctxt->insn_buf),
+ PFEC_insn_fetch, NULL, NULL))
? sizeof(sh_ctxt->insn_buf) : 0;
sh_ctxt->insn_buf_eip = regs->rip;
}
--- a/xen/arch/x86/mm/shadow/hvm.c
+++ b/xen/arch/x86/mm/shadow/hvm.c
@@ -122,10 +122,10 @@ hvm_read(enum x86_segment seg,
if ( rc || !bytes )
return rc;
-if ( access_type == hvm_access_insn_fetch )
-rc = hvm_fetch_from_guest_linear(p_data, addr, bytes, 0, );
-else
-rc = hvm_copy_from_guest_linear(p_data, addr, bytes, 0, );
+rc = hvm_copy_from_guest_linear(p_data, addr, bytes,
+(access_type == hvm_access_insn_fetch
+
[Xen-devel] [PATCH 0/2] x86/HVM: emulation adjustments
1: drop hvm_fetch_from_guest_linear() 2: split page straddling emulated accesses in more cases Patch 2 is incomplete at this time, and hence only RFC. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-4.9-testing test] 126201: regressions - FAIL
On Fri, Aug 24, 2018 at 09:58:02AM +0100, Wei Liu wrote: > On Wed, Aug 22, 2018 at 04:52:27PM -0600, Jim Fehlig wrote: > > On 08/21/2018 05:14 AM, Jan Beulich wrote: > > > > > > On 21.08.18 at 03:11, wrote: > > > > flight 126201 xen-4.9-testing real [real] > > > > http://logs.test-lab.xenproject.org/osstest/logs/126201/ > > > > > > > > Regressions :-( > > > > > > > > Tests which did not succeed and are blocking, > > > > including tests which could not be run: > > > > test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail > > > > REGR. vs. 124328 > > > > > > Something needs to be done about this, as this continued failure is > > > blocking the 4.9.3 release. I did mail about this on Aug 2nd already > > > for flight 125710, I've got back from Wei: > > > > > > > This is libvirtd's error message. > > > > > > > > The remote host can't obtain the state change log due to it is already > > > > held by another task/thread. It could be a libvirt / libxl bug. > > > > > > > > 2018-08-01 16:12:13.433+: 3491: warning : > > > > libxlDomainObjBeginJob:151 : > > > > Cannot start job (modify) for domain debian.guest.osstest; current job > > > > is (modify) owned by (24975) > > > > I took a closer look at the logs and it appears the finish phase of > > migration fails to acquire the domain job lock since it is already held by > > the perform phase. In the perform phase, after the vm has been transferred > > to the dst, the qemu process associated with the vm is started. For whatever > > reason that takes a long time on this host: > > > > 2018-08-19 17:05:19.182+: libxl: libxl_dm.c:2235:libxl__spawn_local_dm: > > Domain 1:Spawning device-model /usr/local/lib/xen/bin/qemu-system-i386 with > > arguments: ... > > 2018-08-19 17:05:19.188+: libxl: libxl_exec.c:398:spawn_watch_event: > > domain 1 device model: spawn watch p=(null) > > This is a spurious event after the watch has been set up. > > > ... > > 2018-08-19 17:05:51.529+: libxl: libxl_event.c:573:watchfd_callback: > > watch w=0x7f84a0047ee8 wpath=/local/domain/0/device-model/1/state token=2/1: > > event epath=/local/domain/0/device-model/1/state > > 2018-08-19 17:05:51.529+: libxl: libxl_exec.c:398:spawn_watch_event: > > domain 1 device model: spawn watch p=running > > So it has taken 32s for QEMU to write "running" in xenstore. This, > however, is still within the timeout limit set by libxl (60s). > I haven't been able to reliably reproduce the timeout. One thing I observe is that libvirt picks qdisk backend while xl picks phys backend. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 126985: tolerable all pass - PUSHED
flight 126985 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/126985/ 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 version targeted for testing: xen aed19fb5370df48527fba82c88c6b7411776283a baseline version: xen 66235dd9f014e46b125c0f461c2f18a799de4d25 Last test of basis 126961 2018-08-29 20:03:42 Z0 days Testing same since 126985 2018-08-30 08:00:33 Z0 days1 attempts People who touched revisions under test: Wei Liu jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass 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 66235dd9f0..aed19fb537 aed19fb5370df48527fba82c88c6b7411776283a -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/2] MMIO emulation fixes
On Thu, Aug 30, Jan Beulich wrote:
> approach): One is Paul's idea of making null_handler actually retrieve
> RAM contents when (part of) the access touches RAM. Another might
This works for me:
static int null_read(const struct hvm_io_handler *io_handler,
uint64_t addr,
uint32_t size,
uint64_t *data)
{
struct vcpu *curr = current;
struct domain *currd = curr->domain;
p2m_type_t p2mt = p2m_invalid;
unsigned long gmfn = paddr_to_pfn(addr);
struct page_info *page;
char *p;
get_gfn_query_unlocked(currd, gmfn, );
if ( p2mt != p2m_ram_rw )
{
*data = ~0ul;
}
else
{
page = get_page_from_gfn(currd, gmfn, NULL, P2M_UNSHARE);
if ( ! page )
{
memset(data, 0xee, size);
}
else
{
p = (char *)__map_domain_page(page) + (addr & ~PAGE_MASK);
memcpy(data, p, size);
unmap_domain_page(p);
put_page(page);
}
}
return X86EMUL_OKAY;
}
Olaf
signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1] tools/mkrpm: switch payload to gzip to reduce turnaround time
On Thu, Aug 30, 2018 at 12:05:11PM +0200, Olaf Hering wrote: > rpmbuild -bb spents alot of time in compressing the binaries. Reduce the > turnaround time of 'make rpmball' by using gzip as compression tool. > This reduces the buildtime from 'w9.xzdio'/138 seconds to 'w1.gzdio'/88 > seconds in my environment. > The downside is an increased filesize of xen.rpm, 19MB vs. 37MB. > > Signed-off-by: Olaf Hering Per my understanding, this target is mostly for developers to conveniently create an rpm file for testing. I don't think I would care about the increased size, but I will let others voice their opinions. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-4.7-testing test] 126907: regressions - FAIL
On Thu, Aug 30, 2018 at 03:12:25AM -0600, Jan Beulich wrote: > >>> On 30.08.18 at 10:51, wrote: > > On Thu, Aug 30, 2018 at 01:49:44AM -0600, Jan Beulich wrote: > >> >>> On 30.08.18 at 06:42, wrote: > >> > flight 126907 xen-4.7-testing real [real] > >> > http://logs.test-lab.xenproject.org/osstest/logs/126907/ > >> > > >> > Regressions :-( > >> > > >> > Tests which did not succeed and are blocking, > >> > including tests which could not be run: > >> > test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail > >> > REGR. vs. 125057 > >> > > >> > Tests which are failing intermittently (not blocking): > >> > test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 126716 > >> > pass in 126907 > >> > test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail > >> > in 126716 pass in 126907 > >> > >> Interesting - the test has moved to the chardonnays now, and > >> hence it succeeded this time. > > > > That's because ... > > > > Right, I have started a repro flight. Let's see how it goes. > > It will probably have a side effect that the failed job will run > > on other hosts so it will pass. > > Oh, that's what you've meant. I suppose there's no way to prevent > eventual false pushes from happening? From my understanding of osstest's scheduler that's not possible at the moment. Wei. > > Jan > > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v1] tools/mkrpm: switch payload to gzip to reduce turnaround time
rpmbuild -bb spents alot of time in compressing the binaries. Reduce the
turnaround time of 'make rpmball' by using gzip as compression tool.
This reduces the buildtime from 'w9.xzdio'/138 seconds to 'w1.gzdio'/88
seconds in my environment.
The downside is an increased filesize of xen.rpm, 19MB vs. 37MB.
Signed-off-by: Olaf Hering
---
tools/misc/mkrpm | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/misc/mkrpm b/tools/misc/mkrpm
index f9363a1456..ae40e1a4c4 100644
--- a/tools/misc/mkrpm
+++ b/tools/misc/mkrpm
@@ -37,6 +37,7 @@ Group: System/Hypervisor
URL: http://xenbits.xenproject.org/xen.git
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
+%define _binary_payload w1.gzdio
%define __spec_install_post /usr/lib/rpm/brp-compress || :
%define debug_package %{nil}
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] x86/pv: Deprecate support for paging out the LDT
This code is believed to be vestigial remnant of the PV Windows XP port. It
is not used by Linux, NetBSD, Solaris or MiniOS. Furthermore the
implementation is incomplete; it only functions for a present => not-present
transition, rather than a present => read/write transition.
The for_each_vcpu() is one scalability limitation for PV guests, which can't
reasonably be altered to be continuable. Most importantly however, is that
this only codepath which plays with descriptor frames of a remote vcpu.
A side effect of dropping support for paging the LDT out is that the LDT no
longer automatically cleans itself up on domain destruction. Cover this by
explicitly releasing the LDT frames at the same time as the GDT frames.
Finally, leave some asserts around to confirm the expected behaviour of all
the functions playing with PGT_seg_desc_page references.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: George Dunlap
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Julien Grall
v2:
* Make an explicit time statement, specifically avoiding second guessing the
future naming scheme or timelines.
---
xen/arch/x86/Kconfig| 23 +++
xen/arch/x86/domain.c | 7 ++-
xen/arch/x86/mm.c | 4 +++-
xen/arch/x86/pv/descriptor-tables.c | 10 ++
xen/arch/x86/pv/domain.c| 2 ++
xen/arch/x86/pv/mm.c| 6 ++
xen/include/asm-x86/domain.h| 2 ++
7 files changed, 48 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 73ab8f8..6c89db1 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -164,3 +164,26 @@ endmenu
source "common/Kconfig"
source "drivers/Kconfig"
+
+menu "Deprecated Functionality"
+
+config LEGACY_PV_LDT_PAGING
+ def_bool n
+ prompt "PV LDT Paging-out support"
+ ---help---
+ For a very long time, the PV ABI has included the ability to page
+ out the LDT by transitioning its mapping to not-present. This
+ functionality is believed to only exist for the PV Windows XP port
+ which never came to anything.
+
+ The implementation contains a vCPU scalability limitation in a
+ position which is prohibitively complicated to resolve. As the
+ feature is believed to be unused in practice, removing the feature
+ is the easiest remediation.
+
+ If you discover a usecase which is broken by this option being off,
+ please contact xen-devel@lists.xenproject.org urgently. Baring
+ something unexpected, the code and this option will be deleted 2
+ releases after Xen 4.12.
+
+endmenu
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 4cdcd5d..64b40c7 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1955,11 +1955,8 @@ int domain_relinquish_resources(struct domain *d)
{
for_each_vcpu ( d, v )
{
-/*
- * Relinquish GDT mappings. No need for explicit unmapping of
- * the LDT as it automatically gets squashed with the guest
- * mappings.
- */
+/* Relinquish GDT/LDT mappings. */
+pv_destroy_ldt(v);
pv_destroy_gdt(v);
}
}
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 7da9a04..5aae19c 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1178,7 +1178,6 @@ void put_page_from_l1e(l1_pgentry_t l1e, struct domain
*l1e_owner)
unsigned long pfn = l1e_get_pfn(l1e);
struct page_info *page;
struct domain*pg_owner;
-struct vcpu *v;
if ( !(l1e_get_flags(l1e) & _PAGE_PRESENT) || is_iomem_page(_mfn(pfn)) )
return;
@@ -1219,12 +1218,14 @@ void put_page_from_l1e(l1_pgentry_t l1e, struct domain
*l1e_owner)
}
else
{
+#ifdef CONFIG_LEGACY_PV_LDT_PAGING
/* We expect this is rare so we blow the entire shadow LDT. */
if ( unlikely(((page->u.inuse.type_info & PGT_type_mask) ==
PGT_seg_desc_page)) &&
unlikely(((page->u.inuse.type_info & PGT_count_mask) != 0)) &&
(l1e_owner == pg_owner) )
{
+struct vcpu *v;
cpumask_t *mask = this_cpu(scratch_cpumask);
cpumask_clear(mask);
@@ -1243,6 +1244,7 @@ void put_page_from_l1e(l1_pgentry_t l1e, struct domain
*l1e_owner)
if ( !cpumask_empty(mask) )
flush_tlb_mask(mask);
}
+#endif /* CONFIG_LEGACY_PV_LDT_PAGING */
put_page(page);
}
}
diff --git a/xen/arch/x86/pv/descriptor-tables.c
b/xen/arch/x86/pv/descriptor-tables.c
index 9b84cbe..93fd6e2 100644
--- a/xen/arch/x86/pv/descriptor-tables.c
+++ b/xen/arch/x86/pv/descriptor-tables.c
@@ -37,10 +37,14 @@ bool pv_destroy_ldt(struct vcpu *v)
Re: [Xen-devel] [PATCH] xentrace: handle sparse cpu ids correctly in xen trace buffer handling
On 30/08/18 10:26, Jan Beulich wrote:
On 30.08.18 at 09:52, wrote:
>> @@ -202,7 +202,7 @@ static int alloc_trace_bufs(unsigned int pages)
>> * Allocate buffers for all of the cpus.
>> * If any fails, deallocate what you have so far and exit.
>> */
>> -for_each_online_cpu(cpu)
>> +for_each_present_cpu(cpu)
>> {
>> offset = t_info_first_offset + (cpu * pages);
>> t_info->mfn_offset[cpu] = offset;
>
> Doesn't this go a little too far? Why would you allocate buffers for CPUs
> which can never be brought online? There ought to be a middle ground,
> where online-able CPUs have buffers allocated, but non-online-able ones
> won't. On larger systems I guess the difference may be quite noticable.
According to the comments in include/xen/cpumask.h cpu_present_map
represents the populated cpus.
I know that currently there is no support for onlining a parked cpu
again, but I think having to think about Xentrace buffer allocation in
case onlining of parked cpus is added would be a nearly 100% chance to
introduce a bug.
Xentrace is used for testing purposes only. So IMHO allocating some more
memory is acceptable.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-4.7-testing test] 126907: regressions - FAIL
>>> On 30.08.18 at 10:51, wrote: > On Thu, Aug 30, 2018 at 01:49:44AM -0600, Jan Beulich wrote: >> >>> On 30.08.18 at 06:42, wrote: >> > flight 126907 xen-4.7-testing real [real] >> > http://logs.test-lab.xenproject.org/osstest/logs/126907/ >> > >> > Regressions :-( >> > >> > Tests which did not succeed and are blocking, >> > including tests which could not be run: >> > test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail >> > REGR. vs. 125057 >> > >> > Tests which are failing intermittently (not blocking): >> > test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 126716 >> > pass in 126907 >> > test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail in >> > 126716 pass in 126907 >> >> Interesting - the test has moved to the chardonnays now, and >> hence it succeeded this time. > > That's because ... > > Right, I have started a repro flight. Let's see how it goes. > It will probably have a side effect that the failed job will run > on other hosts so it will pass. Oh, that's what you've meant. I suppose there's no way to prevent eventual false pushes from happening? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 126959: all pass - PUSHED
flight 126959 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/126959/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 497a5fb1d8f834e1bc84d3496d7f2228bf99f7df baseline version: ovmf 0fa0e56ee002cf369f7f4a1076eac52f813e03f0 Last test of basis 126919 2018-08-29 05:34:58 Z1 days Testing same since 126959 2018-08-29 19:12:34 Z0 days1 attempts People who touched revisions under test: shenglei jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 0fa0e56ee0..497a5fb1d8 497a5fb1d8f834e1bc84d3496d7f2228bf99f7df -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-4.7-testing test] 126907: regressions - FAIL
On Thu, Aug 30, 2018 at 01:49:44AM -0600, Jan Beulich wrote: > >>> On 30.08.18 at 06:42, wrote: > > flight 126907 xen-4.7-testing real [real] > > http://logs.test-lab.xenproject.org/osstest/logs/126907/ > > > > Regressions :-( > > > > Tests which did not succeed and are blocking, > > including tests which could not be run: > > test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. > > vs. 125057 > > > > Tests which are failing intermittently (not blocking): > > test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 126716 > > pass in 126907 > > test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail in > > 126716 pass in 126907 > > Interesting - the test has moved to the chardonnays now, and > hence it succeeded this time. That's because ... Right, I have started a repro flight. Let's see how it goes. It will probably have a side effect that the failed job will run on other hosts so it will pass. Wei. > > Jan > > > > ___ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] BUG: sched=credit2 crashes system when using cpupools
On 2018-08-30 18:33, Jan Beulich wrote: On 30.08.18 at 06:01, wrote: Managed to get the same crash log when adding CPUs to Pool-1 as follows: Create the pool: (XEN) Initializing Credit2 scheduler (XEN) load_precision_shift: 18 (XEN) load_window_shift: 30 (XEN) underload_balance_tolerance: 0 (XEN) overload_balance_tolerance: -3 (XEN) runqueues arrangement: socket (XEN) cap enforcement granularity: 10ms (XEN) load tracking window length 1073741824 ns Add the CPUs: (XEN) Adding cpu 12 to runqueue 0 (XEN) First cpu on runqueue, activating (XEN) Removing cpu 12 from runqueue 0 (XEN) Adding cpu 13 to runqueue 0 (XEN) Removing cpu 13 from runqueue 0 (XEN) Adding cpu 14 to runqueue 0 (XEN) Removing cpu 14 from runqueue 0 (XEN) Xen BUG at sched_credit2.c:3452 credit2 still not being the default - do things work if you don't override the default (of using credit1)? I guess the problem is connected to the "Removing cpu from runqueue 0", considering this BUG_ON(!cpumask_test_cpu(cpu, >active)); is what triggers. Anyway - as Jürgen says, something for the scheduler maintainers to look into. Yep - I just want to confirm that we tested this in BOTH NUMA configurations - and credit2 crashed on both. I switched back to sched=credit, and it seems to work as expected: # xl cpupool-list Name CPUs Sched Active Domain count Pool-node0 12credit y 3 Pool-node1 12credit y 0 I've updated the subject - as this isn't a NUMA issue at all. -- Steven Haigh ? net...@crc.id.au ? http://www.crc.id.au ? +61 (3) 9001 6090? 0412 935 897 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen: fill topology info for online cpus only
On 30/08/18 10:43, Jan Beulich wrote:
On 30.08.18 at 10:31, wrote:
>> On 30/08/18 10:16, Jan Beulich wrote:
>> On 29.08.18 at 20:23, wrote:
The topology information obtainable via XEN_SYSCTL_cputopoinfo is
filled rather weird: the size of the array is derived from the highest
online cpu number, while the data is set to "invalid" for not present
cpus only.
With smt=0 the information for parked threads is all zero, so it should
be best to return "invalid" information for offline cpus.
On a dual core system without this patch xl info -n will print:
cpu_topology :
cpu:coresocket node
0: 000
1: 000
2: 100
>>>
>>> But there's nothing wrong here. The interesting part is what would be
>>> printed for CPU 3 (perhaps on a more than two cores system). After
>>> all topology is valid irrespective of whether a CPU is online - it all
>>> depends on whether the hypervisor still has the information available.
>>> It is for a reason that cpu_smpboot_free() invalidates certain fields
>>> only upon CPU removal:
>>>
>>> if ( remove )
>>> {
>>> c[cpu].phys_proc_id = XEN_INVALID_SOCKET_ID;
>>> c[cpu].cpu_core_id = XEN_INVALID_CORE_ID;
>>> c[cpu].compute_unit_id = INVALID_CUID;
>>>
>>> On a 6-core system I see
>>>
>>> cpu:coresocket node
>>> 0: 000
>>> 1: 000
>>> 2: 100
>>> 3: 100
>>> 4: 200
>>> 5: 200
>>> 6: 800
>>> 7: 800
>>> 8: 900
>>> 9: 900
>>> 10: 1000
>>>
>>> which looks fine to me, apart from the missing info on CPU 11.
>>
>> I can change the patch to print the information for the offline cpus
>> (including the now missing ones), too.
>>
>> What is the preferred solution?
>
> Well, by implication from my earlier reply I think adding the missing
> CPU's info would be better. Let's see what others think.
Okay.
I'll do that and add another patch adding "(offline)" to the output in
case a cpu is offline.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen: fill topology info for online cpus only
On 30/08/18 10:44, Jan Beulich wrote:
On 30.08.18 at 10:37, wrote:
>> On Thu, Aug 30, 2018 at 10:31:16AM +0200, Juergen Gross wrote:
>>> On 30/08/18 10:16, Jan Beulich wrote:
>>> On 29.08.18 at 20:23, wrote:
> The topology information obtainable via XEN_SYSCTL_cputopoinfo is
> filled rather weird: the size of the array is derived from the highest
> online cpu number, while the data is set to "invalid" for not present
> cpus only.
>
> With smt=0 the information for parked threads is all zero, so it should
> be best to return "invalid" information for offline cpus.
>
> On a dual core system without this patch xl info -n will print:
>
> cpu_topology :
> cpu:coresocket node
> 0: 000
> 1: 000
> 2: 100
But there's nothing wrong here. The interesting part is what would be
printed for CPU 3 (perhaps on a more than two cores system). After
all topology is valid irrespective of whether a CPU is online - it all
depends on whether the hypervisor still has the information available.
It is for a reason that cpu_smpboot_free() invalidates certain fields
only upon CPU removal:
if ( remove )
{
c[cpu].phys_proc_id = XEN_INVALID_SOCKET_ID;
c[cpu].cpu_core_id = XEN_INVALID_CORE_ID;
c[cpu].compute_unit_id = INVALID_CUID;
On a 6-core system I see
cpu:coresocket node
0: 000
1: 000
2: 100
3: 100
4: 200
5: 200
6: 800
7: 800
8: 900
9: 900
10: 1000
which looks fine to me, apart from the missing info on CPU 11.
>>>
>>> I can change the patch to print the information for the offline cpus
>>> (including the now missing ones), too.
>>>
>>
>> That is fine too. I just don't like inconsistent output. :p
>>
>> P.S. you probably want to add a new field to the existing interface to
>> indicate if a cpu is online.
>
> And if we extend the interface anyway, also the thread ID (as iirc
> pointed out as missing recently by George).
Ha, yes!
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen: fill topology info for online cpus only
>>> On 30.08.18 at 10:37, wrote:
> On Thu, Aug 30, 2018 at 10:31:16AM +0200, Juergen Gross wrote:
>> On 30/08/18 10:16, Jan Beulich wrote:
>> On 29.08.18 at 20:23, wrote:
>> >> The topology information obtainable via XEN_SYSCTL_cputopoinfo is
>> >> filled rather weird: the size of the array is derived from the highest
>> >> online cpu number, while the data is set to "invalid" for not present
>> >> cpus only.
>> >>
>> >> With smt=0 the information for parked threads is all zero, so it should
>> >> be best to return "invalid" information for offline cpus.
>> >>
>> >> On a dual core system without this patch xl info -n will print:
>> >>
>> >> cpu_topology :
>> >> cpu:coresocket node
>> >> 0: 000
>> >> 1: 000
>> >> 2: 100
>> >
>> > But there's nothing wrong here. The interesting part is what would be
>> > printed for CPU 3 (perhaps on a more than two cores system). After
>> > all topology is valid irrespective of whether a CPU is online - it all
>> > depends on whether the hypervisor still has the information available.
>> > It is for a reason that cpu_smpboot_free() invalidates certain fields
>> > only upon CPU removal:
>> >
>> > if ( remove )
>> > {
>> > c[cpu].phys_proc_id = XEN_INVALID_SOCKET_ID;
>> > c[cpu].cpu_core_id = XEN_INVALID_CORE_ID;
>> > c[cpu].compute_unit_id = INVALID_CUID;
>> >
>> > On a 6-core system I see
>> >
>> > cpu:coresocket node
>> > 0: 000
>> > 1: 000
>> > 2: 100
>> > 3: 100
>> > 4: 200
>> > 5: 200
>> > 6: 800
>> > 7: 800
>> > 8: 900
>> > 9: 900
>> > 10: 1000
>> >
>> > which looks fine to me, apart from the missing info on CPU 11.
>>
>> I can change the patch to print the information for the offline cpus
>> (including the now missing ones), too.
>>
>
> That is fine too. I just don't like inconsistent output. :p
>
> P.S. you probably want to add a new field to the existing interface to
> indicate if a cpu is online.
And if we extend the interface anyway, also the thread ID (as iirc
pointed out as missing recently by George).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen: fill topology info for online cpus only
>>> On 30.08.18 at 10:31, wrote:
> On 30/08/18 10:16, Jan Beulich wrote:
> On 29.08.18 at 20:23, wrote:
>>> The topology information obtainable via XEN_SYSCTL_cputopoinfo is
>>> filled rather weird: the size of the array is derived from the highest
>>> online cpu number, while the data is set to "invalid" for not present
>>> cpus only.
>>>
>>> With smt=0 the information for parked threads is all zero, so it should
>>> be best to return "invalid" information for offline cpus.
>>>
>>> On a dual core system without this patch xl info -n will print:
>>>
>>> cpu_topology :
>>> cpu:coresocket node
>>> 0: 000
>>> 1: 000
>>> 2: 100
>>
>> But there's nothing wrong here. The interesting part is what would be
>> printed for CPU 3 (perhaps on a more than two cores system). After
>> all topology is valid irrespective of whether a CPU is online - it all
>> depends on whether the hypervisor still has the information available.
>> It is for a reason that cpu_smpboot_free() invalidates certain fields
>> only upon CPU removal:
>>
>> if ( remove )
>> {
>> c[cpu].phys_proc_id = XEN_INVALID_SOCKET_ID;
>> c[cpu].cpu_core_id = XEN_INVALID_CORE_ID;
>> c[cpu].compute_unit_id = INVALID_CUID;
>>
>> On a 6-core system I see
>>
>> cpu:coresocket node
>> 0: 000
>> 1: 000
>> 2: 100
>> 3: 100
>> 4: 200
>> 5: 200
>> 6: 800
>> 7: 800
>> 8: 900
>> 9: 900
>> 10: 1000
>>
>> which looks fine to me, apart from the missing info on CPU 11.
>
> I can change the patch to print the information for the offline cpus
> (including the now missing ones), too.
>
> What is the preferred solution?
Well, by implication from my earlier reply I think adding the missing
CPU's info would be better. Let's see what others think.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] tools/libxl: correct vcpu affinity output with sparse physical cpu map
>>> On 30.08.18 at 10:11, wrote: > On 30/08/18 10:07, Jan Beulich wrote: > On 29.08.18 at 20:23, wrote: >>> With not all physical cpus online (i.e. with smt=0) the output of hte >> >> I think you mean "e.g." instead of "i.e." here, as there are other >> means to have some CPUs offline. > > I used it in the meaning of "namely", in order to highlight the recent > change to Xen making it more clear why the change is IMO important. Iirc it was Ian who told me a while ago that our German based use of "namely" in cases like this isn't really appropriate; I'm not sure I've fully understood where "namely" would be usable or not, so I'm simply trying to avoid it now in most cases, and I'm therefore not sure if it was appropriate to be used here. I'm also not sure whether my assignment of meaning to "i.e." is really correct, but I'd generally view it as an analogue of "that is", rather than the "specifically" you appear to mean here. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen: fill topology info for online cpus only
On Thu, Aug 30, 2018 at 10:31:16AM +0200, Juergen Gross wrote:
> On 30/08/18 10:16, Jan Beulich wrote:
> On 29.08.18 at 20:23, wrote:
> >> The topology information obtainable via XEN_SYSCTL_cputopoinfo is
> >> filled rather weird: the size of the array is derived from the highest
> >> online cpu number, while the data is set to "invalid" for not present
> >> cpus only.
> >>
> >> With smt=0 the information for parked threads is all zero, so it should
> >> be best to return "invalid" information for offline cpus.
> >>
> >> On a dual core system without this patch xl info -n will print:
> >>
> >> cpu_topology :
> >> cpu:coresocket node
> >> 0: 000
> >> 1: 000
> >> 2: 100
> >
> > But there's nothing wrong here. The interesting part is what would be
> > printed for CPU 3 (perhaps on a more than two cores system). After
> > all topology is valid irrespective of whether a CPU is online - it all
> > depends on whether the hypervisor still has the information available.
> > It is for a reason that cpu_smpboot_free() invalidates certain fields
> > only upon CPU removal:
> >
> > if ( remove )
> > {
> > c[cpu].phys_proc_id = XEN_INVALID_SOCKET_ID;
> > c[cpu].cpu_core_id = XEN_INVALID_CORE_ID;
> > c[cpu].compute_unit_id = INVALID_CUID;
> >
> > On a 6-core system I see
> >
> > cpu:coresocket node
> > 0: 000
> > 1: 000
> > 2: 100
> > 3: 100
> > 4: 200
> > 5: 200
> > 6: 800
> > 7: 800
> > 8: 900
> > 9: 900
> > 10: 1000
> >
> > which looks fine to me, apart from the missing info on CPU 11.
>
> I can change the patch to print the information for the offline cpus
> (including the now missing ones), too.
>
That is fine too. I just don't like inconsistent output. :p
P.S. you probably want to add a new field to the existing interface to
indicate if a cpu is online.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
