Re: [Xen-devel] [PATCH v2 1/6] x86/vmx: Fix handing of MSR_DEBUGCTL on VMExit
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Thursday, May 31, 2018 1:35 AM > > Currently, whenever the guest writes a nonzero value to MSR_DEBUGCTL, > Xen > updates a host MSR load list entry with the current hardware value of > MSR_DEBUGCTL. > > On VMExit, hardware automatically resets MSR_DEBUGCTL to 0. Later, > when the > guest writes to MSR_DEBUGCTL, the current value in hardware (0) is fed > back > into guest load list. As a practical result, `ler` debugging gets lost on any > PCPU which has ever scheduled an HVM vcpu, and the common case when > `ler` > debugging isn't active, guest actions result in an unnecessary load list entry > repeating the MSR_DEBUGCTL reset. > > Restoration of Xen's debugging setting needs to happen from the very first > vmexit. Due to the automatic reset, Xen need take no action in the general > case, and only needs to load a value when debugging is active. > > This could be fixed by using a host MSR load list entry set up during > construct_vmcs(). However, a more efficient option is to use an alternative > block in the VMExit path, keyed on whether hypervisor debugging has been > enabled. > > In order to set this up, drop the per cpu ler_msr variable (as there is no > point having it per cpu when it will be the same everywhere), and use a > single > read_mostly variable instead. Split calc_ler_msr() out of percpu_traps_init() > for clarity. > > Finally, clean up do_debug(). Reinstate LBR early to help catch cascade > errors, which allows for the removal of the out label. > > Signed-off-by: Andrew Cooper nice cleanup. Reviewed-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/6] x86: Improvements to ler debugging
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Monday, May 28, 2018 10:28 PM > > * Command line documentation for what the option does. > * Implement a canonicalise_addr() helper and replace the opencoded use > in >sign_extend_msr() > * Canonicalise the ler pointers and print symbol information. > > Signed-off-by: Andrew Cooper Reviewed-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 4/6] x86/vmx: Simplify PAT handling during vcpu construction
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Monday, May 28, 2018 10:28 PM > > The host PAT value is a compile time constant, and doesn't need to be read > out > of hardware. Merge this if block into the previous block, which has an > identical condition. > > Signed-off-by: Andrew Cooper Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 5/6] x86/vmx: Defer vmx_vmcs_exit() as long as possible in construct_vmcs()
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Monday, May 28, 2018 10:28 PM > > paging_update_paging_modes() and vmx_vlapic_msr_changed() both > operate on the > VMCS being constructed. Avoid dropping and re-acquiring the reference > multiple times. > Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 6/6] x86/vmx: Drop VMX signal for full real-mode
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Monday, May 28, 2018 10:28 PM > > The hvmloader code which used this signal was deleted 10 years ago (c/s > 50b12df83 "x86 vmx: Remove vmxassist"). Furthermore, the value gets > discarded > anyway because the HVM domain builder unconditionally sets %rax to 0 in > the > same action it uses to set %rip to the appropriate entrypoint. > > Signed-off-by: Andrew Cooper Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen 4.11.0 RC5 test result
We performed Xen 4.11 RC5 testing on Intel Xeon Skylake, Broadwell server, Intel Atom Denverton platforms, verified many functional features, which include new feature MBA on Xen 4.11. We'd like to share the result out. Except Nested, other feature all passed of testing. https://wiki.xenproject.org/wiki/Nested_Virtualization_in_Xen We also integrated XTF into our testing, 65 xtf cases run pass on those Intel platforms above. Features Test Result MBA Pass Local MCE Pass UMIP Pass AVX512 Pass Protection keys Pass Altp2m Pass RDT(CMT, CAT, CDP, MBM, L2 CAT) Pass VT-d PI Pass XSAVES Pass MPX Pass PML (Page-modification Logging) Pass Nested Buggy VT-d/SR-IOV Pass RAS Pass ACPI Pass Best Regards, Xudong ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.9 test] 123759: regressions - FAIL
flight 123759 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/123759/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-rumprun-amd64 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-xl-xsm 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-xl-pvhv2-amd 7 xen-bootfail REGR. vs. 122969 test-amd64-amd64-qemuu-nested-amd 7 xen-bootfail REGR. vs. 122969 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. 122969 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail REGR. vs. 122969 test-amd64-amd64-xl 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 122969 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 122969 test-amd64-amd64-xl-multivcpu 7 xen-bootfail REGR. vs. 122969 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-examine 8 reboot fail REGR. vs. 122969 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-pvshim7 xen-boot fail pass in 123648 test-armhf-armhf-xl 6 xen-installfail pass in 123648 test-amd64-amd64-xl-qemuu-ovmf-amd64 16 guest-localmigrate/x10 fail pass in 123648 test-amd64-i386-xl-qemuu-ws16-amd64 15 guest-saverestore.2 fail pass in 123648 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 7 xen-boot fail REGR. vs. 122969 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 13 migrate-support-check fail in 123648 never pass test-armhf-armhf-xl 14 saverestore-support-check fail in 123648 never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stopfail in 123648 never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122969 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122969 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122969 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122969 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 122969 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail 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 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 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-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-sto
Re: [Xen-devel] Xen 4.11.0 RC5 test result
+ Juergen Thanks, -Xudong From: Hao, Xudong Sent: Tuesday, June 5, 2018 4:47 PM To: xen-de...@lists.xen.org Cc: Julien Grall ; Lars Kurth Subject: Xen 4.11.0 RC5 test result We performed Xen 4.11 RC5 testing on Intel Xeon Skylake, Broadwell server, Intel Atom Denverton platforms, verified many functional features, which include new feature MBA on Xen 4.11. We'd like to share the result out. Except Nested, other feature all passed of testing. https://wiki.xenproject.org/wiki/Nested_Virtualization_in_Xen We also integrated XTF into our testing, 65 xtf cases run pass on those Intel platforms above. Features Test Result MBA Pass Local MCE Pass UMIP Pass AVX512 Pass Protection keys Pass Altp2m Pass RDT(CMT, CAT, CDP, MBM, L2 CAT) Pass VT-d PI Pass XSAVES Pass MPX Pass PML (Page-modification Logging) Pass Nested Buggy VT-d/SR-IOV Pass RAS Pass ACPI Pass Best Regards, Xudong ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 0/10] arm: more kconfig configurability and small default configs
Hi Stefano, On 06/04/2018 10:53 PM, Stefano Stabellini wrote: Hi all, This patch series is the first step toward building a small certifiable Xen hypervisor for ARM boards. How much code size can be reduced ? any ballpark figure First, the series makes a few changes to allow disabling more kconfig options: most of them already exist but cannot be disabled. Then, it introduces a reference kconfig for Renesas RCar (due to popular demand, candidate for certifications), Xilinx MPSoC, and for QEMU aarch64 (not for certifications, but useful for debugging). The last patch in the series adds a convenient cloc target to count the total lines of code of the source files built. As a consequence of these changes, some options will become user-visible and not dependent on CONFIG_EXPERT. It does not mean that Xen Project will security support all possible combinations of kconfig options. Instead, there will be a small set of pre-canned configurations that will be supported. See: https://marc.info/?l=xen-devel&m=152424389512432 Cheers, Stefano Stefano Stabellini (10): arm: remove the ARM HDLCD driver arm: make it possible to disable HAS_GICV3 arm: rename HAS_GICV3 to GICV3 Make MEM_ACCESS configurable make it possible to enable/disable UART drivers arm: make it possible to disable the SMMU driver arm: add a tiny kconfig configuration arm: add ALL, QEMU, Rcar3 and MPSoC configs xen: add per-platform defaults for NR_CPUS xen: add cloc target tools/firmware/xen-dir/shim.config | 2 +- xen/Makefile | 12 ++ xen/arch/Kconfig | 4 + xen/arch/arm/Kconfig | 17 +- xen/arch/arm/Makefile| 4 +- xen/arch/arm/configs/tiny.conf | 43 + xen/arch/arm/platforms/Kconfig | 54 ++ xen/arch/arm/platforms/Makefile | 2 +- xen/arch/arm/platforms/vexpress.c| 35 xen/arch/arm/vgic.c | 2 +- xen/arch/arm/vgic/vgic.c | 2 +- xen/arch/x86/Kconfig | 2 +- xen/common/Kconfig | 10 +- xen/common/Makefile | 2 +- xen/common/domctl.c | 2 +- xen/drivers/char/Kconfig | 15 +- xen/drivers/passthrough/Kconfig | 12 ++ xen/drivers/passthrough/arm/Makefile | 2 +- xen/drivers/video/Kconfig| 3 - xen/drivers/video/Makefile | 1 - xen/drivers/video/arm_hdlcd.c| 281 --- xen/include/asm-arm/gic.h| 4 +- xen/include/asm-arm/platforms/vexpress.h | 6 - xen/include/asm-arm/vgic.h | 4 +- xen/include/xen/mem_access.h | 4 +- xen/include/xsm/dummy.h | 2 +- xen/include/xsm/xsm.h| 4 +- xen/xsm/dummy.c | 2 +- xen/xsm/flask/hooks.c| 4 +- 29 files changed, 175 insertions(+), 362 deletions(-) create mode 100644 xen/arch/arm/configs/tiny.conf create mode 100644 xen/arch/arm/platforms/Kconfig delete mode 100644 xen/drivers/video/arm_hdlcd.c ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] multiboot2: clarify usage of the address tag
Add a note to spell out that if the address tag is not present the file should be loaded using the elf header. Signed-off-by: Roger Pau Monné --- Cc: Daniel Kiper Cc: xen-devel@lists.xenproject.org --- doc/multiboot.texi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/doc/multiboot.texi b/doc/multiboot.texi index 2e2d7e74a..196f9c17a 100644 --- a/doc/multiboot.texi +++ b/doc/multiboot.texi @@ -509,6 +509,12 @@ assumes that no bss segment is present. @end table +Note: This information does not need to be provided if the kernel +image is in elf format, but it must be provided if the image is in +a.out format or in some other format. Compliant boot loaders must be +able to load images that are either in elf format or contain the +address tag embedded in the Multiboot header. + @subsection The entry address tag of Multiboot2 header @example -- 2.17.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Branching off 4.11
Ian is just preparing to tag 4.11-rc6 on current master. I plan to initiate branching off 4.11 after that. Are there any objections? Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen 4.11.0 RC5 test result
On 05/06/18 09:49, Hao, Xudong wrote: > > > > Except Nested, other feature all passed of testing. > > https://wiki.xenproject.org/wiki/Nested_Virtualization_in_Xen > Do you have any further information? ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Branching off 4.11
Juergen Gross writes ("Branching off 4.11"):
> Ian is just preparing to tag 4.11-rc6 on current master. I plan to
> initiate branching off 4.11 after that. Are there any objections?
We should have staging==master to branch. So would everyone please
refrain from committing anything.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen Project Security Process Whitepaper v1 is ready for community review
On Mon, Jun 4, 2018 at 3:55 PM, Lars Kurth wrote: > 2.2.3 B. Git baseline of patches > This created quite a bit of discussion and we did learn a few things: > * From the thread, having to cherry pick a small (around 5-6) patches have to > be cherry-picked for XSAs to apply to tarballs this appears to be seen as OK > for most users. More patches are a problem > * Recently this issue has become much worse, because some security fixes (or > pre-requisites for them) have been developed in public and some XSAs required > significant backporting to be able to be run > * A point release has usually <50% security fixes > * There is no appetite amongst existing point release maintainers to maintain > a staging branch and an XSA + pre-requisites only branch > > In other words, we are at a stale-mate. I see two ways around it > a) Find an additional volunteer to maintain XSA + pre-requisites only > branches for releases > b) Find some tooling/test based solution which exposes issues applying XSAs > on the last releases of a staging branch for a point release. This is a > little bit of a half-baked idea, but it may be worthwhile looking into. > For example, we could create an OSSTEST, that checks out the last released > stable branch and applies outstanding XSAs and pre-requisites based on the > meta-info to it (e.g. via xsatool or a variant thereof). This test would > fail, if an XSA does not apply, which implies that the pre-requisites are > incomplete. If all XSAs apply, we can run the full OSSTEST on it. The test > could also produce a list of git commits from staging that include XSAs and > pre-requisites that can be applied in order. This should in theory - if > doable - help downstreams which are struggling with this problem, while > flagging up potential issues to stable maintainers early. Any thoughts? Would > this be workable and if so, would it actually help? Here's a question: What would it take for most downstreams to update to staging when a public release was made? Suppose we did this: 1. When we predisclose an issue, freeze the stable branches until the embargo lifts -- no backports. 2. When the embargo lifts, addition to the patches, we release a new point release, complete with signed tag and tarball. 3. We only do non-security point releases if we go 4 months without a security-prompted point release. At the moment the release process is quite manual, which isn't terrible for one point release every 4 months per supported release, but would significantly increase the workload if we did it for every supported version for every XSA. We'd have to invest quite a bit in automating that process, which would make it only worth it if a significant number of people would find that useful. The other thing we could probably do is write a tool which would automatically determine the minimum number of 'extra' patches to backport from the stable branch to allow the patch to apply and build. The issue with that, of course, is that such a branch will be an artificial branch which has almost no testing. -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen Project Security Process Whitepaper v1 is ready for community review
On Tue, Jun 05, 2018 at 11:34:28AM +0100, George Dunlap wrote: > On Mon, Jun 4, 2018 at 3:55 PM, Lars Kurth wrote: > > > 2.2.3 B. Git baseline of patches > > This created quite a bit of discussion and we did learn a few things: > > * From the thread, having to cherry pick a small (around 5-6) patches have > > to be cherry-picked for XSAs to apply to tarballs this appears to be seen > > as OK for most users. More patches are a problem > > * Recently this issue has become much worse, because some security fixes > > (or pre-requisites for them) have been developed in public and some XSAs > > required significant backporting to be able to be run > > * A point release has usually <50% security fixes > > * There is no appetite amongst existing point release maintainers to > > maintain a staging branch and an XSA + pre-requisites only branch > > > > In other words, we are at a stale-mate. I see two ways around it > > a) Find an additional volunteer to maintain XSA + pre-requisites only > > branches for releases > > b) Find some tooling/test based solution which exposes issues applying XSAs > > on the last releases of a staging branch for a point release. This is a > > little bit of a half-baked idea, but it may be worthwhile looking into. > > For example, we could create an OSSTEST, that checks out the last released > > stable branch and applies outstanding XSAs and pre-requisites based on the > > meta-info to it (e.g. via xsatool or a variant thereof). This test would > > fail, if an XSA does not apply, which implies that the pre-requisites are > > incomplete. If all XSAs apply, we can run the full OSSTEST on it. The test > > could also produce a list of git commits from staging that include XSAs and > > pre-requisites that can be applied in order. This should in theory - if > > doable - help downstreams which are struggling with this problem, while > > flagging up potential issues to stable maintainers early. Any thoughts? > > Would this be workable and if so, would it actually help? > > Here's a question: What would it take for most downstreams to update > to staging when a public release was made? > > Suppose we did this: > 1. When we predisclose an issue, freeze the stable branches until the > embargo lifts -- no backports. > 2. When the embargo lifts, addition to the patches, we release a new > point release, complete with signed tag and tarball. > 3. We only do non-security point releases if we go 4 months without a > security-prompted point release. IMO this would significantly ease handling of XSAs, at least for us. This does mean we'll need to test things using stable branch (not previous point release) during embargo period - as the point release would be available only after lifting the embargo, but I think that's manageable. What if at the predisclose time there are some commits in staging (not stable), which breaks things (in terms of osstest)? Would them be bypassed (XSA applied on top of stable, then rebase staging on top of new stable)? Or something else? > At the moment the release process is quite manual, which isn't > terrible for one point release every 4 months per supported release, > but would significantly increase the workload if we did it for every > supported version for every XSA. We'd have to invest quite a bit in > automating that process, which would make it only worth it if a > significant number of people would find that useful. Alternatively this could be triggered only if there are conflicting changes in stable branch, since last point release (but free stable anyway, to not leak info about the patches). This should reduce probability of very frequent point releases (the more recent point release is, the more likely XSA will apply without problems). This could be determined mostly automatically by trying to apply patches on the most recent point release. > The other thing we could probably do is write a tool which would > automatically determine the minimum number of 'extra' patches to > backport from the stable branch to allow the patch to apply and build. > The issue with that, of course, is that such a branch will be an > artificial branch which has almost no testing. I'm bit worried about such solution, although this is exactly what we do right now. With exception that a) it isn't automated b) we do testing on our own (and probably others do to, duplicating this work). -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen 4.11 RC6
Hi all, Xen 4.11 rc6 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.11.0-rc6 For your convenience there is also a tarball at: https://downloads.xenproject.org/release/xen/4.11.0-rc6/xen-4.11.0-rc6.tar.gz And the signature is at: https://downloads.xenproject.org/release/xen/4.11.0-rc6/xen-4.11.0-rc6.tar.gz.sig Please send bug reports and test reports to xen-devel@lists.xenproject.org. When sending bug reports, please CC relevant maintainers and me (jgr...@suse.com). This will be the last RC before branching 4.11 off the Xen main trunk. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen Project Security Process Whitepaper v1 is ready for community review
>>> On 05.06.18 at 13:03, wrote: > On Tue, Jun 05, 2018 at 11:34:28AM +0100, George Dunlap wrote: >> On Mon, Jun 4, 2018 at 3:55 PM, Lars Kurth wrote: >> >> > 2.2.3 B. Git baseline of patches >> > This created quite a bit of discussion and we did learn a few things: >> > * From the thread, having to cherry pick a small (around 5-6) patches have > to be cherry-picked for XSAs to apply to tarballs this appears to be seen as > OK for most users. More patches are a problem >> > * Recently this issue has become much worse, because some security fixes > (or pre-requisites for them) have been developed in public and some XSAs > required significant backporting to be able to be run >> > * A point release has usually <50% security fixes >> > * There is no appetite amongst existing point release maintainers to > maintain a staging branch and an XSA + pre-requisites only branch >> > >> > In other words, we are at a stale-mate. I see two ways around it >> > a) Find an additional volunteer to maintain XSA + pre-requisites only > branches for releases >> > b) Find some tooling/test based solution which exposes issues applying >> > XSAs > on the last releases of a staging branch for a point release. This is a > little bit of a half-baked idea, but it may be worthwhile looking into. >> > For example, we could create an OSSTEST, that checks out the last released > stable branch and applies outstanding XSAs and pre-requisites based on the > meta-info to it (e.g. via xsatool or a variant thereof). This test would > fail, if an XSA does not apply, which implies that the pre-requisites are > incomplete. If all XSAs apply, we can run the full OSSTEST on it. The test > could also produce a list of git commits from staging that include XSAs and > pre-requisites that can be applied in order. This should in theory - if > doable - help downstreams which are struggling with this problem, while > flagging up potential issues to stable maintainers early. Any thoughts? Would > this be workable and if so, would it actually help? >> >> Here's a question: What would it take for most downstreams to update >> to staging when a public release was made? >> >> Suppose we did this: >> 1. When we predisclose an issue, freeze the stable branches until the >> embargo lifts -- no backports. >> 2. When the embargo lifts, addition to the patches, we release a new >> point release, complete with signed tag and tarball. >> 3. We only do non-security point releases if we go 4 months without a >> security-prompted point release. > > IMO this would significantly ease handling of XSAs, at least for us. > This does mean we'll need to test things using stable branch (not > previous point release) during embargo period - as the point release > would be available only after lifting the embargo, but I think that's > manageable. > > What if at the predisclose time there are some commits in staging (not > stable), which breaks things (in terms of osstest)? Would them be > bypassed (XSA applied on top of stable, then rebase staging on top of > new stable)? Or something else? I don't think we should get into the business of re-basing any of the main branches of xen.git. If anything, then merging. But I further think we also shouldn't break the strict staging -> stable workflow with the osstest push gate in between. Some delay between public disclosure and release of the new stable version will hence be unavoidable. (Just take the current situation as an example, where we're blocked on an osstest issue [according to my investigation, at least] with two stable releases - we simply have to wait for the osstest issue to be dealt with first, and for the pushes of the branches then to eventually happen.) Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf baseline-only test] 74780: all pass
This run is configured for baseline tests only. flight 74780 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74780/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 38c977c148e92e2af17c5d346d9b4b2e7a18680a baseline version: ovmf c4061d18ef531147a58075f7f011a25b598d6aee Last test of basis74774 2018-06-02 19:52:16 Z2 days Testing same since74780 2018-06-04 21:48:27 Z0 days1 attempts People who touched revisions under test: Jan Dabros Marcin Wojtas 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.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 38c977c148e92e2af17c5d346d9b4b2e7a18680a Author: Marcin Wojtas Date: Fri Jun 1 21:58:13 2018 +0800 MdeModulePkg PeiCore: Check error status when processing boot FV Until now the possible errors returned from processing boot firmware volume were not checked, which could cause misbehavior in further booting stages. Add relevant assert. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marcin Wojtas Signed-off-by: Jan Dabros Reviewed-by: Liming Gao Reviewed-by: Star Zeng ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen Project Security Process Whitepaper v1 is ready for community review
On Tue, Jun 05, 2018 at 05:44:48AM -0600, Jan Beulich wrote: > >>> On 05.06.18 at 13:03, wrote: > > On Tue, Jun 05, 2018 at 11:34:28AM +0100, George Dunlap wrote: > >> On Mon, Jun 4, 2018 at 3:55 PM, Lars Kurth wrote: > >> > >> > 2.2.3 B. Git baseline of patches > >> > This created quite a bit of discussion and we did learn a few things: > >> > * From the thread, having to cherry pick a small (around 5-6) patches > >> > have > > to be cherry-picked for XSAs to apply to tarballs this appears to be seen > > as > > OK for most users. More patches are a problem > >> > * Recently this issue has become much worse, because some security fixes > > (or pre-requisites for them) have been developed in public and some XSAs > > required significant backporting to be able to be run > >> > * A point release has usually <50% security fixes > >> > * There is no appetite amongst existing point release maintainers to > > maintain a staging branch and an XSA + pre-requisites only branch > >> > > >> > In other words, we are at a stale-mate. I see two ways around it > >> > a) Find an additional volunteer to maintain XSA + pre-requisites only > > branches for releases > >> > b) Find some tooling/test based solution which exposes issues applying > >> > XSAs > > on the last releases of a staging branch for a point release. This is a > > little bit of a half-baked idea, but it may be worthwhile looking into. > >> > For example, we could create an OSSTEST, that checks out the last > >> > released > > stable branch and applies outstanding XSAs and pre-requisites based on the > > meta-info to it (e.g. via xsatool or a variant thereof). This test would > > fail, if an XSA does not apply, which implies that the pre-requisites are > > incomplete. If all XSAs apply, we can run the full OSSTEST on it. The test > > could also produce a list of git commits from staging that include XSAs and > > pre-requisites that can be applied in order. This should in theory - if > > doable - help downstreams which are struggling with this problem, while > > flagging up potential issues to stable maintainers early. Any thoughts? > > Would > > this be workable and if so, would it actually help? > >> > >> Here's a question: What would it take for most downstreams to update > >> to staging when a public release was made? > >> > >> Suppose we did this: > >> 1. When we predisclose an issue, freeze the stable branches until the > >> embargo lifts -- no backports. > >> 2. When the embargo lifts, addition to the patches, we release a new > >> point release, complete with signed tag and tarball. > >> 3. We only do non-security point releases if we go 4 months without a > >> security-prompted point release. > > > > IMO this would significantly ease handling of XSAs, at least for us. > > This does mean we'll need to test things using stable branch (not > > previous point release) during embargo period - as the point release > > would be available only after lifting the embargo, but I think that's > > manageable. > > > > What if at the predisclose time there are some commits in staging (not > > stable), which breaks things (in terms of osstest)? Would them be > > bypassed (XSA applied on top of stable, then rebase staging on top of > > new stable)? Or something else? > > I don't think we should get into the business of re-basing any of the > main branches of xen.git. If anything, then merging. But I further > think we also shouldn't break the strict staging -> stable workflow > with the osstest push gate in between. Some delay between public > disclosure and release of the new stable version will hence be > unavoidable. (Just take the current situation as an example, where > we're blocked on an osstest issue [according to my investigation, at > least] with two stable releases - we simply have to wait for the > osstest issue to be dealt with first, and for the pushes of the > branches then to eventually happen.) Makes sense. Does it mean in all the cases point release would happen with a delay from XSA public release? How long does it take for osstest to push things (assuming no problems)? -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 123792: regressions - FAIL
flight 123792 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/123792/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 123554 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail REGR. vs. 123554 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-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 123554 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 123554 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 123554 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 123554 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 123554 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 123554 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 123554 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 123554 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 123554 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-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-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: linux29dcea88779c856c7dc92040a0c01233263101d4 baseline version: linux0512e0134582ef85dee77d51aae77dcd1edec495 Last test of basis 123554 2018-06-01 13:09:41 Z3 days Failing since123655 2018-06-03 01:45:35 Z2 days2 attempts Testing same since 123792 2018-06-04 07:33:26 Z1 days1 attempts -
Re: [Xen-devel] Xen Project Security Process Whitepaper v1 is ready for community review
>>> On 05.06.18 at 14:07, wrote: > On Tue, Jun 05, 2018 at 05:44:48AM -0600, Jan Beulich wrote: >> >>> On 05.06.18 at 13:03, wrote: >> > On Tue, Jun 05, 2018 at 11:34:28AM +0100, George Dunlap wrote: >> >> Suppose we did this: >> >> 1. When we predisclose an issue, freeze the stable branches until the >> >> embargo lifts -- no backports. >> >> 2. When the embargo lifts, addition to the patches, we release a new >> >> point release, complete with signed tag and tarball. >> >> 3. We only do non-security point releases if we go 4 months without a >> >> security-prompted point release. >> > >> > IMO this would significantly ease handling of XSAs, at least for us. >> > This does mean we'll need to test things using stable branch (not >> > previous point release) during embargo period - as the point release >> > would be available only after lifting the embargo, but I think that's >> > manageable. >> > >> > What if at the predisclose time there are some commits in staging (not >> > stable), which breaks things (in terms of osstest)? Would them be >> > bypassed (XSA applied on top of stable, then rebase staging on top of >> > new stable)? Or something else? >> >> I don't think we should get into the business of re-basing any of the >> main branches of xen.git. If anything, then merging. But I further >> think we also shouldn't break the strict staging -> stable workflow >> with the osstest push gate in between. Some delay between public >> disclosure and release of the new stable version will hence be >> unavoidable. (Just take the current situation as an example, where >> we're blocked on an osstest issue [according to my investigation, at >> least] with two stable releases - we simply have to wait for the >> osstest issue to be dealt with first, and for the pushes of the >> branches then to eventually happen.) > > Makes sense. Does it mean in all the cases point release would happen > with a delay from XSA public release? How long does it take for osstest > to push things (assuming no problems)? A day or two. Remember that osstest will be quite busy at such times, testing all active branches at the same time. But please don't forget: "No problems" is rather a rare exception than the rule. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [distros-debian-snapshot test] 74781: tolerable FAIL
flight 74781 distros-debian-snapshot real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74781/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-i386-weekly-netinst-pygrub 10 debian-di-install fail like 74758 test-amd64-i386-amd64-weekly-netinst-pygrub 10 debian-di-install fail like 74758 test-amd64-amd64-amd64-weekly-netinst-pygrub 10 debian-di-install fail like 74758 test-amd64-amd64-i386-weekly-netinst-pygrub 10 debian-di-install fail like 74758 test-amd64-i386-i386-daily-netboot-pvgrub 11 guest-start fail like 74758 test-amd64-amd64-amd64-current-netinst-pygrub 10 debian-di-install fail like 74758 test-amd64-amd64-amd64-daily-netboot-pvgrub 11 guest-start fail like 74758 test-amd64-i386-amd64-daily-netboot-pygrub 10 debian-di-install fail like 74758 test-armhf-armhf-armhf-daily-netboot-pygrub 10 debian-di-install fail like 74758 test-amd64-i386-i386-current-netinst-pygrub 10 debian-di-install fail like 74758 test-amd64-amd64-i386-current-netinst-pygrub 10 debian-di-install fail like 74758 test-amd64-i386-amd64-current-netinst-pygrub 10 debian-di-install fail like 74758 baseline version: flight 74758 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-daily-netboot-pvgrub fail test-amd64-i386-i386-daily-netboot-pvgrubfail test-amd64-i386-amd64-daily-netboot-pygrub fail test-armhf-armhf-armhf-daily-netboot-pygrub fail test-amd64-amd64-i386-daily-netboot-pygrub pass test-amd64-amd64-amd64-current-netinst-pygrubfail test-amd64-i386-amd64-current-netinst-pygrub fail test-amd64-amd64-i386-current-netinst-pygrub fail test-amd64-i386-i386-current-netinst-pygrub fail test-amd64-amd64-amd64-weekly-netinst-pygrub fail test-amd64-i386-amd64-weekly-netinst-pygrub fail test-amd64-amd64-i386-weekly-netinst-pygrub fail test-amd64-i386-i386-weekly-netinst-pygrub 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.xs.citrite.net/~osstest/testlogs/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
Re: [Xen-devel] [PATCH v1 1/2] x86/mm: Add mem access rights to NPT
On Mi, 2018-05-30 at 14:56 +0100, Andrew Cooper wrote: > On 30/05/18 12:29, Jan Beulich wrote: > > > > > > > > > > > > > > > > > > > On 30.05.18 at 13:20, wrote: > > > On Mi, 2018-05-30 at 03:52 -0600, Jan Beulich wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 30.05.18 at 11:04, wrote: > > > > > Sorry for the misunderstanding, I wanted to clarify if the > > > > > 59:56 > > > > > bits > > > > > are fully ok to be used or if not then where should I use 4 > > > > > bits to > > > > > store the mem access info? > > > > I thought I had sufficiently explained this - you have two > > > > options: > > > > 1) Make sure (via some prereq patch(es)) bit 59 has no other > > > > use, and > > > >then use 59:56. > > > > 2) Use another range that's provably having no other use, e.g. > > > >58:55. > > > I've checked and bits 40:52 are defined in asm/page.h for page > > > flags. > > 40:52? Hardly. > > > > > > > > I've tried bits 53:56 and there where some problems with the > > > guest not > > > starting or the image freezing, > > Well, you'll have to explain this (perhaps just to yourself). > > > > > > > > bits 62 and 63 are not free so 59:56 is > > > the only space to be used for this purpose and is seems to > > > function > > > correctly. > > Well - as said before, bit 59 is not available for use without some > > prereq work. > There are no software available bits in the top of an AMD IOMMU PTE. > Bits 59:62 are defined, while bits 52:58 are strictly reserved and > fault > if used. > > I'm also not convinced of the safety of our current uses of bits 9:11 > which are software available in the regular pagetables, but have > specific meaning in the IOMMU entries. > > If the code IOMMU code disables page sharing, then lets go one small > step further and prohibit its use entirely. There is no point trying > to > maintain compatibility for an option which isn't used, especially if > it > gets in the way of improvements like this in the SVM code. > Another idea is to save the mem access info in a radix tree like on the ARM side and we can store the radix tree root in the p2m_domain. I think that this is the fastest and cleanest way to solve the free bits problem. Is this a suitable way to go? Thanks, Alex This email was scanned by Bitdefender ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v1 04/13] xen/arm: Add ARCH_WORKAROUND_2 probing
As for Spectre variant-2, we rely on SMCCC 1.1 to provide the discovery
mechanism for detecting the SSBD mitigation.
A new capability is also allocated for that purpose, and a config
option.
This is part of XSA-263.
Signed-off-by: Julien Grall
---
Changes in v2:
- Add the switch in this patch rather than the next one.
- s/supported/required/
---
xen/arch/arm/Kconfig | 10 +++
xen/arch/arm/cpuerrata.c | 57
xen/include/asm-arm/cpuerrata.h | 21 +++
xen/include/asm-arm/cpufeature.h | 3 ++-
xen/include/asm-arm/smccc.h | 7 +
5 files changed, 97 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 8174c0c635..0e2d027060 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -73,6 +73,16 @@ config SBSA_VUART_CONSOLE
Allows a guest to use SBSA Generic UART as a console. The
SBSA Generic UART implements a subset of ARM PL011 UART.
+config ARM_SSBD
+ bool "Speculative Store Bypass Disable" if EXPERT = "y"
+ depends on HAS_ALTERNATIVE
+ default y
+ help
+ This enables mitigation of bypassing of previous stores by speculative
+ loads.
+
+ If unsure, say Y.
+
endmenu
menu "ARM errata workaround via the alternative framework"
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 1baa20654b..aa86c7c0fe 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -235,6 +235,57 @@ static int enable_ic_inv_hardening(void *data)
#endif
+#ifdef CONFIG_ARM_SSBD
+
+/*
+ * Assembly code may use the variable directly, so we need to make sure
+ * it fits in a register.
+ */
+DEFINE_PER_CPU_READ_MOSTLY(register_t, ssbd_callback_required);
+
+static bool has_ssbd_mitigation(const struct arm_cpu_capabilities *entry)
+{
+struct arm_smccc_res res;
+bool required;
+
+if ( smccc_ver < SMCCC_VERSION(1, 1) )
+return false;
+
+/*
+ * The probe function return value is either negative (unsupported
+ * or mitigated), positive (unaffected), or zero (requires
+ * mitigation). We only need to do anything in the last case.
+ */
+arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
+ ARM_SMCCC_ARCH_WORKAROUND_2_FID, &res);
+switch ( (int)res.a0 )
+{
+case ARM_SMCCC_NOT_SUPPORTED:
+return false;
+
+case ARM_SMCCC_NOT_REQUIRED:
+return false;
+
+case ARM_SMCCC_SUCCESS:
+required = true;
+break;
+
+case 1: /* Mitigation not required on this CPU. */
+required = true;
+break;
+
+default:
+ASSERT_UNREACHABLE();
+return false;
+}
+
+if ( required )
+this_cpu(ssbd_callback_required) = 1;
+
+return required;
+}
+#endif
+
#define MIDR_RANGE(model, min, max) \
.matches = is_affected_midr_range, \
.midr_model = model,\
@@ -336,6 +387,12 @@ static const struct arm_cpu_capabilities arm_errata[] = {
.enable = enable_ic_inv_hardening,
},
#endif
+#ifdef CONFIG_ARM_SSBD
+{
+.capability = ARM_SSBD,
+.matches = has_ssbd_mitigation,
+},
+#endif
{},
};
diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index 4e45b237c8..e628d3ff56 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -27,9 +27,30 @@ static inline bool check_workaround_##erratum(void)
\
CHECK_WORKAROUND_HELPER(766422, ARM32_WORKAROUND_766422, CONFIG_ARM_32)
CHECK_WORKAROUND_HELPER(834220, ARM64_WORKAROUND_834220, CONFIG_ARM_64)
+CHECK_WORKAROUND_HELPER(ssbd, ARM_SSBD, CONFIG_ARM_SSBD)
#undef CHECK_WORKAROUND_HELPER
+#ifdef CONFIG_ARM_SSBD
+
+#include
+
+DECLARE_PER_CPU(register_t, ssbd_callback_required);
+
+static inline bool cpu_require_ssbd_mitigation(void)
+{
+return this_cpu(ssbd_callback_required);
+}
+
+#else
+
+static inline bool cpu_require_ssbd_mitigation(void)
+{
+return false;
+}
+
+#endif
+
#endif /* __ARM_CPUERRATA_H__ */
/*
* Local variables:
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index e557a095af..2a5c075d3b 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -43,8 +43,9 @@
#define SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT 5
#define SKIP_CTXT_SWITCH_SERROR_SYNC 6
#define ARM_HARDEN_BRANCH_PREDICTOR 7
+#define ARM_SSBD 8
-#define ARM_NCAPS 8
+#define ARM_NCAPS 9
#ifndef __ASSEMBLY__
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 8342cc33fe..a6804cec99 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -258,7 +258,14 @@ struct arm_smccc_res {
ARM_SMCCC_OWNER_ARCH, \
0x8000)
+#define ARM_SMCCC_ARCH_WORKAROUND_2_FID \
+ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL,
[Xen-devel] [PATCH v1 12/13] xen/arm: smccc: Fix indentation in ARM_SMCCC_ARCH_WORKAROUND_1_FID
Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
---
Changes in v2:
- Add Stefano's acked-by
---
xen/include/asm-arm/smccc.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index a6804cec99..74c13f8419 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -254,9 +254,9 @@ struct arm_smccc_res {
#define ARM_SMCCC_ARCH_WORKAROUND_1_FID \
ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
- ARM_SMCCC_CONV_32,\
- ARM_SMCCC_OWNER_ARCH, \
- 0x8000)
+ ARM_SMCCC_CONV_32, \
+ ARM_SMCCC_OWNER_ARCH,\
+ 0x8000)
#define ARM_SMCCC_ARCH_WORKAROUND_2_FID \
ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v1 01/13] xen/arm: domain: Zero the per-vCPU cpu_info
A stack is allocated per vCPU to be used by Xen. The allocation is done with alloc_xenheap_pages that does not zero the memory returned. However the top of the stack is containing information that will be used to store the initial state of the vCPU (see struct cpu_info). Some of the fields may not be initialized and will lead to use/leak bits of previous memory in some cases on the first run of vCPU (AFAICT this only happen on vCPU0 for Dom0). This is part of XSA-263. Signed-off-by: Julien Grall --- Changes in v2: - Zero only cpu_info --- xen/arch/arm/domain.c | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index ec0f042bf7..5a2a9a6b83 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -550,6 +550,7 @@ int vcpu_initialise(struct vcpu *v) v->arch.cpu_info = (struct cpu_info *)(v->arch.stack + STACK_SIZE - sizeof(struct cpu_info)); +memset(v->arch.cpu_info, 0, sizeof(*v->arch.cpu_info)); memset(&v->arch.saved_context, 0, sizeof(v->arch.saved_context)); v->arch.saved_context.sp = (register_t)v->arch.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 v1 03/13] xen/arm: setup: Check errata for boot CPU later on
Some errata will rely on the SMCCC version which is detected by psci_init(). This is part of XSA-263. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- Changes in v2: - Add Stefano's reviewed-by --- xen/arch/arm/setup.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 1d6f6bf37e..ac93de4786 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -171,8 +171,6 @@ static void __init processor_id(void) } processor_setup(); - -check_local_cpu_errata(); } void dt_unreserved_regions(paddr_t s, paddr_t e, @@ -779,6 +777,12 @@ void __init start_xen(unsigned long boot_phys_offset, printk(XENLOG_INFO "SMP: Allowing %u CPUs\n", cpus); nr_cpu_ids = cpus; +/* + * Some errata relies on SMCCC version which is detected by psci_init() + * (called from smp_init_cpus()). + */ +check_local_cpu_errata(); + init_xen_time(); gic_init(); -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v1 13/13] xen/arm: Avoid to use current everywhere in enter_hypervisor_head
Using current is fairly expensive, so save up into a variable.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- Add Stefano's reviewed-by
---
xen/arch/arm/traps.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 315fc61f77..bde303261e 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2024,8 +2024,10 @@ static void enter_hypervisor_head(struct cpu_user_regs
*regs)
{
if ( guest_mode(regs) )
{
+struct vcpu *v = current;
+
/* If the guest has disabled the workaround, bring it back on. */
-if ( needs_ssbd_flip(current) )
+if ( needs_ssbd_flip(v) )
arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
/*
@@ -2034,8 +2036,8 @@ static void enter_hypervisor_head(struct cpu_user_regs
*regs)
* but the crucial bit is "On taking a vSError interrupt, HCR_EL2.VSE
* (alias of HCR.VA) is cleared to 0."
*/
-if ( current->arch.hcr_el2 & HCR_VA )
-current->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
+if ( v->arch.hcr_el2 & HCR_VA )
+v->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
#ifdef CONFIG_NEW_VGIC
/*
@@ -2045,11 +2047,11 @@ static void enter_hypervisor_head(struct cpu_user_regs
*regs)
* TODO: Investigate whether this is necessary to do on every
* trap and how it can be optimised.
*/
-vtimer_update_irqs(current);
-vcpu_update_evtchn_irq(current);
+vtimer_update_irqs(v);
+vcpu_update_evtchn_irq(v);
#endif
-vgic_sync_from_lrs(current);
+vgic_sync_from_lrs(v);
}
}
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v1 09/13] xen/arm64: Add generic assembly macros
Add assembly macros to simplify assembly code: - adr_cpu_info: Get the address to the current cpu_info structure - ldr_this_cpu: Load a per-cpu value This is part of XSA-263. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- Changes in v2: - Add Stefano's reviewed-by --- xen/include/asm-arm/arm64/macros.h | 25 + xen/include/asm-arm/macros.h | 2 +- 2 files changed, 26 insertions(+), 1 deletion(-) create mode 100644 xen/include/asm-arm/arm64/macros.h diff --git a/xen/include/asm-arm/arm64/macros.h b/xen/include/asm-arm/arm64/macros.h new file mode 100644 index 00..9c5e676b37 --- /dev/null +++ b/xen/include/asm-arm/arm64/macros.h @@ -0,0 +1,25 @@ +#ifndef __ASM_ARM_ARM64_MACROS_H +#define __ASM_ARM_ARM64_MACROS_H + +/* + * @dst: Result of get_cpu_info() + */ +.macro adr_cpu_info, dst +add \dst, sp, #STACK_SIZE +and \dst, \dst, #~(STACK_SIZE - 1) +sub \dst, \dst, #CPUINFO_sizeof +.endm + +/* + * @dst: Result of READ_ONCE(per_cpu(sym, smp_processor_id())) + * @sym: The name of the per-cpu variable + * @tmp: scratch register + */ +.macro ldr_this_cpu, dst, sym, tmp +ldr \dst, =per_cpu__\sym +mrs \tmp, tpidr_el2 +ldr \dst, [\dst, \tmp] +.endm + +#endif /* __ASM_ARM_ARM64_MACROS_H */ + diff --git a/xen/include/asm-arm/macros.h b/xen/include/asm-arm/macros.h index 5d837cb38b..1d4bb41d15 100644 --- a/xen/include/asm-arm/macros.h +++ b/xen/include/asm-arm/macros.h @@ -8,7 +8,7 @@ #if defined (CONFIG_ARM_32) # include #elif defined(CONFIG_ARM_64) -/* No specific ARM64 macros for now */ +# include #else # error "unknown ARM variant" #endif -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v1 11/13] xen/arm: Kconfig: Move HARDEN_BRANCH_PREDICTOR under "Architecture features"
At the moment, HARDEN_BRANCH_PREDICTOR is not in any section making impossible for the user to unselect it. Also, it looks like we require to use 'expert = "y"' for showing the option in expert mode. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- Changes in v2: - Add Stefano's reviewed-by --- xen/arch/arm/Kconfig | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 0e2d027060..4212c58171 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -83,6 +83,23 @@ config ARM_SSBD If unsure, say Y. +config HARDEN_BRANCH_PREDICTOR + bool "Harden the branch predictor against aliasing attacks" if EXPERT = "y" + default y + help + Speculation attacks against some high-performance processors rely on + being able to manipulate the branch predictor for a victim context by + executing aliasing branches in the attacker context. Such attacks + can be partially mitigated against by clearing internal branch + predictor state and limiting the prediction logic in some situations. + + This config option will take CPU-specific actions to harden the + branch predictor against aliasing attacks and may rely on specific + instruction sequences or control bits being set by the system + firmware. + + If unsure, say Y. + endmenu menu "ARM errata workaround via the alternative framework" @@ -197,23 +214,6 @@ config ARM64_ERRATUM_834220 endmenu -config HARDEN_BRANCH_PREDICTOR - bool "Harden the branch predictor against aliasing attacks" if EXPERT - default y - help - Speculation attacks against some high-performance processors rely on - being able to manipulate the branch predictor for a victim context by - executing aliasing branches in the attacker context. Such attacks - can be partially mitigated against by clearing internal branch - predictor state and limiting the prediction logic in some situations. - - This config option will take CPU-specific actions to harden the - branch predictor against aliasing attacks and may rely on specific - instruction sequences or control bits being set by the system - firmware. - - If unsure, say Y. - config ARM64_HARDEN_BRANCH_PREDICTOR def_bool y if ARM_64 && HARDEN_BRANCH_PREDICTOR -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v1 06/13] xen/arm: Add ARCH_WORKAROUND_2 support for guests
In order to offer ARCH_WORKAROUND_2 support to guests, we need to track the
state of the workaround per-vCPU. The field 'pad' in cpu_info is now
repurposed to store flags easily accessible in assembly.
As the hypervisor will always run with the workaround enabled, we may
need to enable (on guest exit) or disable (on guest entry) the
workaround.
A follow-up patch will add fastpath for the workaround for arm64 guests.
Note that check_workaround_ssbd() is used instead of ssbd_get_state()
because the former is implemented using an alternative. Thefore the code
will be shortcut on affected platform.
This is part of XSA-263.
Signed-off-by: Julien Grall
---
Changes in v2:
- Fix the condition in need_ssbd_flip()
---
xen/arch/arm/domain.c | 8
xen/arch/arm/traps.c | 20
xen/arch/arm/vsmc.c | 37 +
xen/include/asm-arm/current.h | 6 +-
4 files changed, 70 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 5a2a9a6b83..4baecc2447 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -21,6 +21,7 @@
#include
#include
+#include
#include
#include
#include
@@ -572,6 +573,13 @@ int vcpu_initialise(struct vcpu *v)
if ( (rc = vcpu_vtimer_init(v)) != 0 )
goto fail;
+/*
+ * The workaround 2 (i.e SSBD mitigation) is enabled by default if
+ * supported.
+ */
+if ( get_ssbd_state() == ARM_SSBD_RUNTIME )
+v->arch.cpu_info->flags |= CPUINFO_WORKAROUND_2_FLAG;
+
return rc;
fail:
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 5c18e918b0..315fc61f77 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2011,10 +2011,23 @@ inject_abt:
inject_iabt_exception(regs, gva, hsr.len);
}
+static inline bool needs_ssbd_flip(struct vcpu *v)
+{
+if ( !check_workaround_ssbd() )
+return false;
+
+return !(v->arch.cpu_info->flags & CPUINFO_WORKAROUND_2_FLAG) &&
+ cpu_require_ssbd_mitigation();
+}
+
static void enter_hypervisor_head(struct cpu_user_regs *regs)
{
if ( guest_mode(regs) )
{
+/* If the guest has disabled the workaround, bring it back on. */
+if ( needs_ssbd_flip(current) )
+arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 1, NULL);
+
/*
* If we pended a virtual abort, preserve it until it gets cleared.
* See ARM ARM DDI 0487A.j D1.14.3 (Virtual Interrupts) for details,
@@ -2260,6 +2273,13 @@ void leave_hypervisor_tail(void)
*/
SYNCHRONIZE_SERROR(SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT);
+/*
+ * The hypervisor runs with the workaround always present.
+ * If the guest wants it disabled, so be it...
+ */
+if ( needs_ssbd_flip(current) )
+arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2_FID, 0, NULL);
+
return;
}
local_irq_enable();
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 40a80d5760..c4ccae6030 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -104,6 +105,23 @@ static bool handle_arch(struct cpu_user_regs *regs)
if ( cpus_have_cap(ARM_HARDEN_BRANCH_PREDICTOR) )
ret = 0;
break;
+case ARM_SMCCC_ARCH_WORKAROUND_2_FID:
+switch ( get_ssbd_state() )
+{
+case ARM_SSBD_UNKNOWN:
+case ARM_SSBD_FORCE_DISABLE:
+break;
+
+case ARM_SSBD_RUNTIME:
+ret = ARM_SMCCC_SUCCESS;
+break;
+
+case ARM_SSBD_FORCE_ENABLE:
+case ARM_SSBD_MITIGATED:
+ret = ARM_SMCCC_NOT_REQUIRED;
+break;
+}
+break;
}
set_user_reg(regs, 0, ret);
@@ -114,6 +132,25 @@ static bool handle_arch(struct cpu_user_regs *regs)
case ARM_SMCCC_ARCH_WORKAROUND_1_FID:
/* No return value */
return true;
+
+case ARM_SMCCC_ARCH_WORKAROUND_2_FID:
+{
+bool enable = (uint32_t)get_user_reg(regs, 1);
+
+/*
+ * ARM_WORKAROUND_2_FID should only be called when mitigation
+ * state can be changed at runtime.
+ */
+if ( unlikely(get_ssbd_state() != ARM_SSBD_RUNTIME) )
+return true;
+
+if ( enable )
+get_cpu_info()->flags |= CPUINFO_WORKAROUND_2_FLAG;
+else
+get_cpu_info()->flags &= ~CPUINFO_WORKAROUND_2_FLAG;
+
+return true;
+}
}
return false;
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
index 7a0971fdea..f9819b34fc 100644
--- a/xen/include/asm-arm/current.h
+++ b/xen/include/asm-arm/current.h
@@ -7,6 +7,10 @@
#include
#include
+/* Tell whether the gue
[Xen-devel] [PATCH v1 00/13] xen/arm: SSBD (aka Spectre-v4) mitigation (XSA-263)
Hi all, This patch series implement the Xen hypervisor side of the "Spectre-v4" (CVE-2018-3639) mitigation known as "Speculative Store Bypass Disable" (SSBD). More information can be found at: https://bugs.chromium.org/p/project-zero/issues/detail?id=1528 https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability For all released Arm Cortex-A that are affected by this issue, then the preferred mitigation is simply to set a chicken bit in the firmware during CPU initialization and therefore no change to Xen is required. Other CPUs may require the chicken bit to be toggled dynamically (for example, when switching between kernel-mode and hypervisor-mode) and this is achieve by calling into EL3 via an SMC which has been published as part of the latest SMCCC specification: https://developer.arm.com/cache-speculation-vulnerability-firmware-specification as well as an ATF update for the released ARM cores affected by SSBD: https://github.com/ARM-software/arm-trusted-firmware/pull/1392 These patches provide the following: 1. Safe probing of firmware to establish which CPUs in the system require calling into EL3 as part of the mitigation 2. A command-line option to force SSBD mitigation to be always on, always off, or dynamically toggled (default) for CPUs that require the EL3 call. 3. An initial implementation of the call via Xen, which exposes the mitigation to the guest via an HVC interface. This patch also provides bug fix and new infrastructure require to implement the mitigation: 1. Zeroed each vCPU stack 2. Provide generic assembly macros 3. Provide alternative callback (RFC) A branch can be found with all the patches at: https://xenbits.xen.org/git-http/people/julieng/xen-unstable.git branch ssbd/v2 Cheers, Julien Grall (13): xen/arm: domain: Zero the per-vCPU cpu_info xen/arm64: entry: Use named label in guest_sync xen/arm: setup: Check errata for boot CPU later on xen/arm: Add ARCH_WORKAROUND_2 probing xen/arm: Add command line option to control SSBD mitigation xen/arm: Add ARCH_WORKAROUND_2 support for guests xen/arm: Simplify alternative patching of non-writable region xen/arm: alternatives: Add dynamic patching feature xen/arm64: Add generic assembly macros xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_2 xen/arm: Kconfig: Move HARDEN_BRANCH_PREDICTOR under "Architecture features" xen/arm: smccc: Fix indentation in ARM_SMCCC_ARCH_WORKAROUND_1_FID xen/arm: Avoid to use current everywhere in enter_hypervisor_head docs/misc/xen-command-line.markdown | 18 + xen/arch/arm/Kconfig| 44 +++ xen/arch/arm/alternative.c | 86 +++-- xen/arch/arm/arm64/asm-offsets.c| 2 + xen/arch/arm/arm64/entry.S | 48 +++- xen/arch/arm/cpuerrata.c| 150 xen/arch/arm/domain.c | 9 +++ xen/arch/arm/setup.c| 8 +- xen/arch/arm/traps.c| 32 ++-- xen/arch/arm/vsmc.c | 37 + xen/include/asm-arm/alternative.h | 44 +-- xen/include/asm-arm/arm64/macros.h | 25 ++ xen/include/asm-arm/cpuerrata.h | 42 ++ xen/include/asm-arm/cpufeature.h| 3 +- xen/include/asm-arm/current.h | 6 +- xen/include/asm-arm/macros.h| 2 +- xen/include/asm-arm/smccc.h | 13 +++- 17 files changed, 491 insertions(+), 78 deletions(-) create mode 100644 xen/include/asm-arm/arm64/macros.h -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v1 08/13] xen/arm: alternatives: Add dynamic patching feature
This is based on the Linux commit dea5e2a4c5bc "arm64: alternatives: Add
dynamic patching feature" written by Marc Zyngier:
We've so far relied on a patching infrastructure that only gave us
a single alternative, without any way to provide a range of potential
replacement instructions. For a single feature, this is an all or
nothing thing.
It would be interesting to have a more flexible grained way of patching the
kernel though, where we could dynamically tune the code that gets injected.
In order to achive this, let's introduce a new form of dynamic patching,
assiciating a callback to a patching site. This callback gets source and
target locations of the patching request, as well as the number of
instructions to be patched.
Dynamic patching is declared with the new ALTERNATIVE_CB and alternative_cb
directives:
asm volatile(ALTERNATIVE_CB("mov %0, #0\n", callback)
: "r" (v));
or
alternative_cb callback
mov x0, #0
alternative_cb_end
where callback is the C function computing the alternative.
Reviewed-by: Christoffer Dall
Reviewed-by: Catalin Marinas
Signed-off-by: Marc Zyngier
This is part of XSA-263.
Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
---
Changes in v2:
- Fix typo in the commit message
- Add Stefano's acked-by
---
xen/arch/arm/alternative.c| 48 +--
xen/include/asm-arm/alternative.h | 44 +++
2 files changed, 75 insertions(+), 17 deletions(-)
diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 936cf04956..52ed7edf69 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -30,6 +30,8 @@
#include
#include
#include
+/* XXX: Move ARCH_PATCH_INSN_SIZE out of livepatch.h */
+#include
#include
/* Override macros from asm/page.h to make them work with mfn_t */
@@ -94,6 +96,23 @@ static u32 get_alt_insn(const struct alt_instr *alt,
return insn;
}
+static void patch_alternative(const struct alt_instr *alt,
+ const uint32_t *origptr,
+ uint32_t *updptr, int nr_inst)
+{
+const uint32_t *replptr;
+unsigned int i;
+
+replptr = ALT_REPL_PTR(alt);
+for ( i = 0; i < nr_inst; i++ )
+{
+uint32_t insn;
+
+insn = get_alt_insn(alt, origptr + i, replptr + i);
+updptr[i] = cpu_to_le32(insn);
+}
+}
+
/*
* The region patched should be read-write to allow __apply_alternatives
* to replacing the instructions when necessary.
@@ -105,33 +124,38 @@ static int __apply_alternatives(const struct alt_region
*region,
paddr_t update_offset)
{
const struct alt_instr *alt;
-const u32 *replptr, *origptr;
+const u32 *origptr;
u32 *updptr;
+alternative_cb_t alt_cb;
printk(XENLOG_INFO "alternatives: Patching with alt table %p -> %p\n",
region->begin, region->end);
for ( alt = region->begin; alt < region->end; alt++ )
{
-u32 insn;
-int i, nr_inst;
+int nr_inst;
-if ( !cpus_have_cap(alt->cpufeature) )
+/* Use ARM_CB_PATCH as an unconditional patch */
+if ( alt->cpufeature < ARM_CB_PATCH &&
+ !cpus_have_cap(alt->cpufeature) )
continue;
-BUG_ON(alt->alt_len != alt->orig_len);
+if ( alt->cpufeature == ARM_CB_PATCH )
+BUG_ON(alt->alt_len != 0);
+else
+BUG_ON(alt->alt_len != alt->orig_len);
origptr = ALT_ORIG_PTR(alt);
updptr = (void *)origptr + update_offset;
-replptr = ALT_REPL_PTR(alt);
-nr_inst = alt->alt_len / sizeof(insn);
+nr_inst = alt->orig_len / ARCH_PATCH_INSN_SIZE;
-for ( i = 0; i < nr_inst; i++ )
-{
-insn = get_alt_insn(alt, origptr + i, replptr + i);
-*(updptr + i) = cpu_to_le32(insn);
-}
+if ( alt->cpufeature < ARM_CB_PATCH )
+alt_cb = patch_alternative;
+else
+alt_cb = ALT_REPL_PTR(alt);
+
+alt_cb(alt, origptr, updptr, nr_inst);
/* Ensure the new instructions reached the memory and nuke */
clean_and_invalidate_dcache_va_range(origptr,
diff --git a/xen/include/asm-arm/alternative.h
b/xen/include/asm-arm/alternative.h
index 4e33d1cdf7..9b4b02811b 100644
--- a/xen/include/asm-arm/alternative.h
+++ b/xen/include/asm-arm/alternative.h
@@ -3,6 +3,8 @@
#include
+#define ARM_CB_PATCH ARM_NCAPS
+
#ifndef __ASSEMBLY__
#include
@@ -18,16 +20,24 @@ struct alt_instr {
};
/* Xen: helpers used by common code. */
-#define __ALT_PTR(a,f) ((u32 *)((void *)&(a)->f + (a)->f))
+#define __ALT_PTR(a,f) ((void *)&(a)->f + (a)->f)
#define ALT_ORIG_PTR(a)__AL
[Xen-devel] [PATCH v1 07/13] xen/arm: Simplify alternative patching of non-writable region
During the MMU setup process, Xen will set SCTLR_EL2.WNX
(Write-Non-eXecutable) bit. Because of that, the alternative code need
to re-mapped the region in a difference place in order to modify the
text section.
At the moment, the function patching the code is only aware of the
re-mapped region. This requires the caller to mess with Xen internal in
order to have function such as is_active_kernel_text() working.
All the interaction with Xen internal can be removed by specify the
offset between the region patch and the writable region for updating the
instruction
This simplification will also make easier to integrate dynamic patching
a in a follow-up patch. Indeed, the callback address should be in
a original region and not re-mapped only which is writeable non-executable.
This is part of XSA-263.
Signed-off-by: Julien Grall
---
Cc: Konrad Rzeszutek Wilk
Changes in v2:
- Add commit message
- Remove comment in the code that does not make sense anymore
---
xen/arch/arm/alternative.c | 42 +-
1 file changed, 13 insertions(+), 29 deletions(-)
diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 9ffdc475d6..936cf04956 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -97,12 +97,16 @@ static u32 get_alt_insn(const struct alt_instr *alt,
/*
* The region patched should be read-write to allow __apply_alternatives
* to replacing the instructions when necessary.
+ *
+ * @update_offset: Offset between the region patched and the writable
+ * region for the update. 0 if the patched region is writable.
*/
-static int __apply_alternatives(const struct alt_region *region)
+static int __apply_alternatives(const struct alt_region *region,
+paddr_t update_offset)
{
const struct alt_instr *alt;
-const u32 *replptr;
-u32 *origptr;
+const u32 *replptr, *origptr;
+u32 *updptr;
printk(XENLOG_INFO "alternatives: Patching with alt table %p -> %p\n",
region->begin, region->end);
@@ -118,6 +122,7 @@ static int __apply_alternatives(const struct alt_region
*region)
BUG_ON(alt->alt_len != alt->orig_len);
origptr = ALT_ORIG_PTR(alt);
+updptr = (void *)origptr + update_offset;
replptr = ALT_REPL_PTR(alt);
nr_inst = alt->alt_len / sizeof(insn);
@@ -125,7 +130,7 @@ static int __apply_alternatives(const struct alt_region
*region)
for ( i = 0; i < nr_inst; i++ )
{
insn = get_alt_insn(alt, origptr + i, replptr + i);
-*(origptr + i) = cpu_to_le32(insn);
+*(updptr + i) = cpu_to_le32(insn);
}
/* Ensure the new instructions reached the memory and nuke */
@@ -162,9 +167,6 @@ static int __apply_alternatives_multi_stop(void *unused)
paddr_t xen_size = _end - _start;
unsigned int xen_order = get_order_from_bytes(xen_size);
void *xenmap;
-struct virtual_region patch_region = {
-.list = LIST_HEAD_INIT(patch_region.list),
-};
BUG_ON(patched);
@@ -177,31 +179,13 @@ static int __apply_alternatives_multi_stop(void *unused)
/* Re-mapping Xen is not expected to fail during boot. */
BUG_ON(!xenmap);
-/*
- * If we generate a new branch instruction, the target will be
- * calculated in this re-mapped Xen region. So we have to register
- * this re-mapped Xen region as a virtual region temporarily.
- */
-patch_region.start = xenmap;
-patch_region.end = xenmap + xen_size;
-register_virtual_region(&patch_region);
+region.begin = __alt_instructions;
+region.end = __alt_instructions_end;
-/*
- * Find the virtual address of the alternative region in the new
- * mapping.
- * alt_instr contains relative offset, so the function
- * __apply_alternatives will patch in the re-mapped version of
- * Xen.
- */
-region.begin = (void *)__alt_instructions - (void *)_start + xenmap;
-region.end = (void *)__alt_instructions_end - (void *)_start + xenmap;
-
-ret = __apply_alternatives(®ion);
+ret = __apply_alternatives(®ion, xenmap - (void *)_start);
/* The patching is not expected to fail during boot. */
BUG_ON(ret != 0);
-unregister_virtual_region(&patch_region);
-
vunmap(xenmap);
/* Barriers provided by the cache flushing */
@@ -235,7 +219,7 @@ int apply_alternatives(const struct alt_instr *start, const
struct alt_instr *en
.end = end,
};
-return __apply_alternatives(®ion);
+return __apply_alternatives(®ion, 0);
}
/*
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v1 02/13] xen/arm64: entry: Use named label in guest_sync
This will improve readability for future changes. This is part of XSA-263. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- Changes in v2: - Add Stefano's reviewed-by --- xen/arch/arm/arm64/entry.S | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S index ffa9a1c492..e2344e565f 100644 --- a/xen/arch/arm/arm64/entry.S +++ b/xen/arch/arm/arm64/entry.S @@ -226,11 +226,11 @@ guest_sync: mrs x1, esr_el2 lsr x1, x1, #HSR_EC_SHIFT /* x1 = ESR_EL2.EC */ cmp x1, #HSR_EC_HVC64 -b.ne1f /* Not a HVC skip fastpath. */ +b.neguest_sync_slowpath /* Not a HVC skip fastpath. */ mrs x1, esr_el2 and x1, x1, #0x /* Check the immediate [0:16] */ -cbnzx1, 1f /* should be 0 for HVC #0 */ +cbnzx1, guest_sync_slowpath /* should be 0 for HVC #0 */ /* * Fastest path possible for ARM_SMCCC_ARCH_WORKAROUND_1. @@ -241,7 +241,7 @@ guest_sync: * be encoded as an immediate for cmp. */ eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID -cbnzw0, 1f +cbnzw0, guest_sync_slowpath /* * Clobber both x0 and x1 to prevent leakage. Note that thanks @@ -250,7 +250,7 @@ guest_sync: mov x1, xzr eret -1: +guest_sync_slowpath: /* * x0/x1 may have been scratch by the fast path above, so avoid * to save them. -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v1 10/13] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_2
The function ARM_SMCCC_ARCH_WORKAROUND_2 will be called by the guest for
enabling/disabling the ssbd mitigation. So we want the handling to
be as fast as possible.
The new sequence will forward guest's ARCH_WORKAROUND_2 call to EL3 and
also track the state of the workaround per-vCPU.
Note that since we need to execute branches, this always executes after
the spectre-v2 mitigation.
This code is based on KVM counterpart "arm64: KVM: Handle guest's
ARCH_WORKAROUND_2 requests" written by Marc Zyngier.
This is part of XSA-263.
Signed-off-by: Julien Grall
---
Changes in v2:
- Combine the 2 consecutive eor instructions in a single one.
---
xen/arch/arm/arm64/asm-offsets.c | 2 ++
xen/arch/arm/arm64/entry.S | 42 +++-
xen/arch/arm/cpuerrata.c | 18 +
3 files changed, 61 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/arm64/asm-offsets.c b/xen/arch/arm/arm64/asm-offsets.c
index ce24e44473..f5c696d092 100644
--- a/xen/arch/arm/arm64/asm-offsets.c
+++ b/xen/arch/arm/arm64/asm-offsets.c
@@ -22,6 +22,7 @@
void __dummy__(void)
{
OFFSET(UREGS_X0, struct cpu_user_regs, x0);
+ OFFSET(UREGS_X1, struct cpu_user_regs, x1);
OFFSET(UREGS_LR, struct cpu_user_regs, lr);
OFFSET(UREGS_SP, struct cpu_user_regs, sp);
@@ -45,6 +46,7 @@ void __dummy__(void)
BLANK();
DEFINE(CPUINFO_sizeof, sizeof(struct cpu_info));
+ OFFSET(CPUINFO_flags, struct cpu_info, flags);
OFFSET(VCPU_arch_saved_context, struct vcpu, arch.saved_context);
diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
index e2344e565f..97b05f53ea 100644
--- a/xen/arch/arm/arm64/entry.S
+++ b/xen/arch/arm/arm64/entry.S
@@ -1,4 +1,6 @@
#include
+#include
+#include
#include
#include
#include
@@ -241,7 +243,7 @@ guest_sync:
* be encoded as an immediate for cmp.
*/
eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
-cbnzw0, guest_sync_slowpath
+cbnzw0, check_wa2
/*
* Clobber both x0 and x1 to prevent leakage. Note that thanks
@@ -250,6 +252,44 @@ guest_sync:
mov x1, xzr
eret
+check_wa2:
+/* ARM_SMCCC_ARCH_WORKAROUND_2 handling */
+eor w0, w0, #(ARM_SMCCC_ARCH_WORKAROUND_1_FID ^
ARM_SMCCC_ARCH_WORKAROUND_2_FID)
+cbnzw0, guest_sync_slowpath
+#ifdef CONFIG_ARM_SSBD
+alternative_cb arm_enable_wa2_handling
+b wa2_end
+alternative_cb_end
+/* Sanitize the argument */
+mov x0, #-(UREGS_kernel_sizeof - UREGS_X1) /* x0 := offset of
guest's x1 on the stack */
+ldr x1, [sp, x0]/* Load guest's x1 */
+cmp w1, wzr
+csetx1, ne
+
+/*
+ * Update the guest flag. At this stage sp point after the field
+ * guest_cpu_user_regs in cpu_info.
+ */
+adr_cpu_info x2
+ldr x0, [x2, #CPUINFO_flags]
+bfi x0, x1, #CPUINFO_WORKAROUND_2_FLAG_SHIFT, #1
+str x0, [x2, #CPUINFO_flags]
+
+/* Check that we actually need to perform the call */
+ldr_this_cpu x0, ssbd_callback_required, x2
+cbz x0, wa2_end
+
+mov w0, #ARM_SMCCC_ARCH_WORKAROUND_2_FID
+smc #0
+
+wa2_end:
+/* Don't leak data from the SMC call */
+mov x1, xzr
+mov x2, xzr
+mov x3, xzr
+#endif /* !CONFIG_ARM_SSBD */
+mov x0, xzr
+eret
guest_sync_slowpath:
/*
* x0/x1 may have been scratch by the fast path above, so avoid
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 4292008692..7455f09f26 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
/* Override macros from asm/page.h to make them work with mfn_t */
@@ -272,6 +273,23 @@ static int __init parse_spec_ctrl(const char *s)
}
custom_param("spec-ctrl", parse_spec_ctrl);
+/* Arm64 only for now as for Arm32 the workaround is currently handled in C. */
+#ifdef CONFIG_ARM_64
+void __init arm_enable_wa2_handling(const struct alt_instr *alt,
+const uint32_t *origptr,
+uint32_t *updptr, int nr_inst)
+{
+BUG_ON(nr_inst != 1);
+
+/*
+ * Only allow mitigation on guest ARCH_WORKAROUND_2 if the SSBD
+ * state allow it to be flipped.
+ */
+if ( get_ssbd_state() == ARM_SSBD_RUNTIME )
+*updptr = aarch64_insn_gen_nop();
+}
+#endif
+
/*
* Assembly code may use the variable directly, so we need to make sure
* it fits in a register.
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v1 05/13] xen/arm: Add command line option to control SSBD mitigation
On a system where the firmware implements ARCH_WORKAROUND_2, it may be
useful to either permanently enable or disable the workaround for cases
where the user decides that they'd rather not get a trap overhead, and
keep the mitigation permanently on or off instead of switching it on
exception entry/exit. In any case, default to mitigation being enabled.
The new command line option is implemented as list of one option to
follow x86 option and also allow to extend it more easily in the future.
Note that for convenience, the full implemention of the workaround is
done in the .matches callback.
Lastly, a accessor is provided to know the state of the mitigation.
After this patch, there are 3 methods complementing each other to find the
state of the mitigation:
- The capability ARM_SSBD indicates the platform is affected by the
vulnerability. This will also return false if the user decide to force
disabled the mitigation (spec-ctrl="ssbd=force-disable"). The
capability is useful for putting shortcut in place using alternative.
- ssbd_state indicates the global state of the mitigation (e.g
unknown, force enable...). The global state is required to report
the state to a guest.
- The per-cpu ssbd_callback_required indicates whether a pCPU
requires to call the SMC. This allows to shortcut SMC call
and save an entry/exit to EL3.
This is part of XSA-263.
Signed-off-by: Julien Grall
---
Changes in v2:
- Move out some code to the previous patch.
- Update the commit message with more background
---
docs/misc/xen-command-line.markdown | 18
xen/arch/arm/cpuerrata.c| 91 +
xen/include/asm-arm/cpuerrata.h | 21 +
3 files changed, 122 insertions(+), 8 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index 8712a833a2..962028b6ed 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1756,6 +1756,24 @@ enforces the maximum theoretically necessary timeout of
670ms. Any number
is being interpreted as a custom timeout in milliseconds. Zero or boolean
false disable the quirk workaround, which is also the default.
+### spec-ctrl (Arm)
+> `= List of [ ssbd=force-disable|runtime|force-enable ]`
+
+Controls for speculative execution sidechannel mitigations.
+
+The option `ssbd=` is used to control the state of Speculative Store
+Bypass Disable (SSBD) mitigation.
+
+* `ssbd=force-disable` will keep the mitigation permanently off. The guest
+will not be able to control the state of the mitigation.
+* `ssbd=runtime` will always turn on the mitigation when running in the
+hypervisor context. The guest will be to turn on/off the mitigation for
+itself by using the firmware interface ARCH\_WORKAROUND\_2.
+* `ssbd=force-enable` will keep the mitigation permanently on. The guest will
+not be able to control the state of the mitigation.
+
+By default SSBD will be mitigated at runtime (i.e `ssbd=runtime`).
+
### spec-ctrl (x86)
> `= List of [ , xen=, {pv,hvm,msr-sc,rsb}=,
> bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb,ssbd}= ]`
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index aa86c7c0fe..4292008692 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -237,6 +237,41 @@ static int enable_ic_inv_hardening(void *data)
#ifdef CONFIG_ARM_SSBD
+enum ssbd_state ssbd_state = ARM_SSBD_RUNTIME;
+
+static int __init parse_spec_ctrl(const char *s)
+{
+const char *ss;
+int rc = 0;
+
+do {
+ss = strchr(s, ',');
+if ( !ss )
+ss = strchr(s, '\0');
+
+if ( !strncmp(s, "ssbd=", 5) )
+{
+s += 5;
+
+if ( !strncmp(s, "force-disable", ss - s) )
+ssbd_state = ARM_SSBD_FORCE_DISABLE;
+else if ( !strncmp(s, "runtime", ss - s) )
+ssbd_state = ARM_SSBD_RUNTIME;
+else if ( !strncmp(s, "force-enable", ss - s) )
+ssbd_state = ARM_SSBD_FORCE_ENABLE;
+else
+rc = -EINVAL;
+}
+else
+rc = -EINVAL;
+
+s = ss + 1;
+} while ( *ss );
+
+return rc;
+}
+custom_param("spec-ctrl", parse_spec_ctrl);
+
/*
* Assembly code may use the variable directly, so we need to make sure
* it fits in a register.
@@ -251,19 +286,17 @@ static bool has_ssbd_mitigation(const struct
arm_cpu_capabilities *entry)
if ( smccc_ver < SMCCC_VERSION(1, 1) )
return false;
-/*
- * The probe function return value is either negative (unsupported
- * or mitigated), positive (unaffected), or zero (requires
- * mitigation). We only need to do anything in the last case.
- */
arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
ARM_SMCCC_ARCH_WORKAROUND_2_FID, &res);
+
switch ( (int)res.a0 )
{
case ARM_SMCCC_NOT_SUPPORTED:
Re: [Xen-devel] [PATCH] scripts/add_maintainers.pl: New script
Hi all, I tried this script on a new series and noticed that something was not working as I was expecting. I have a patch modifying the following files: xen/arch/arm/domain_build.c xen/include/asm-arm/domain.h When using the scripts with just "-d .", I get the following person CCed: Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Julien Grall Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu The same patch with get_maintainers.pl only give the following person: Stefano Stabellini Julien Grall It looks like to me the problem is because the option "-f" has been given to get_maintainers.pl. The option works on file and not a patch. I think what you want to do is remove the -f option. I will send a patch for that. Cheers, On 05/15/2018 06:10 PM, Ian Jackson wrote: From: Lars Kurth e This provides a much better workflow when using git format-patch and git send-email, with get_maintainer.pl. The tool covers step 2 of the following workflow Step 1: git format-patch ... -o ... Step 2: ./scripts/add_maintainers.pl -d This overwrites *.patch files in Step 3: git send-email -to xen-devel@lists.xenproject.org /*.patchxm I manually tested all options and the most common combinations on Mac. Changes since v1: - Added RAB (indicated by Juergen on IRC that this is OK) - Remove trailing whitespaces - Renamed --prefix to --reroll-count - Cleaned up short options -v, ... to be in line with git - Added --tags|-t option to add AB, RAB and RB emails to CC list - Added --insert|-i mode to allow for people adding CCs to commit message instead of the e-mail header (the header is the default) - Moved common code into functions - Added logic, such that the tool only insert's To: and Cc: statements which were not there before, allowing for running the tool multiple times on the same Changes since v2: - Deleted --version and related infrastructure - Added subroutine prototypes - Removed AT and @lists declaration and used \@ in literals - Changed usage message and options based on feedback - Improved error handling - Removed occurances of index() and replaced with regex - Removed non-perl idioms - Moved uniq statements to normalize and added info on what normalize does - Read L: tags from MAINTAINERS file instead of using heuristic - Fixed issues related to metacharacters in getmaintainers() - Allow multiple -a | --arg values (because of this renamed --args) - Identify tags via regex - CC's from tags are only inserted in the mail header, never the body - That is unless the new option --tagscc is used - Added policy processing which includes reworking insert() - Replaced -i|--insert with -p|--inspatch and -c|--inscover now using policies - Added new policies to cover for all user requests - Rewrote help message to center around usage of policies - Reordered some code (e.g. help string first to make code more easily readable) Changes since v3: - Made help message clearer - Replaced PROCESSING POLICY with LOCATION - Renamed --inspatch (top|ccbody|cc---|none) | -p (top|ccbody|cc---|none) to --patchcc (header|commit|comment|none) | -p (header|commit|comment|none) - Renamed --inscover (top|ccend|none) | -c (top|ccend|none) to --covercc (header|end|none) | -c (header|end|none) - Renamed variables and functions in the code to match the options - Changed $patch_prefix processing - Changed search expression for identifying cover letters - Renamed $readmailinglists to $getmailinglists_done - Use array form of open - More file error handling (using IO::Handle) - Fixed buggy AND in if statement - Removed check whether getmaintainers exists for future proofing - Add logic to work out --reroll-count Changes since v4: - Strip some trailing whitespace from the code - writefile() now uses the .tmp-and-rename pattern to avoid data loss - Provide --get-maintainers= option to specify replacement for get_maintainers.pl. This is useful for Ian's usecase, since it allows --get-maintainers=true, to avoid adding any MAINTAINERS-based info anywhere while still adding other CCs (eg from -t) everywhere. - Refactor normalize() somewhat so that it uses only %seen, and does not any longer modify its argument arrays. - De-dupe case-insensitively (by making normalize use lc). Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Julien Grall Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu Signed-off-by: Lars Kurth Release-acked-by: Juergen Gross Signed-off-by: Ian Jackson --- scripts/add_maintainers.pl | 548 + 1 file changed, 548 insertions(+) create mode 100755 scripts/add_maintainers.pl diff --git a/scripts/add_maintainers.pl b/scripts/add_maintainers.pl new file mode 100755 index 000..0f4a4cf --- /dev/null +++ b/scripts/add_maintainers.pl @@ -0,0 +1,548 @@ +#!/usr/bin/perl -w +# (c) 2018, Lars Kurth +# +# Add main
Re: [Xen-devel] [xen-unstable test] 123379: regressions - FAIL
Juergen Gross writes ("Re: [Xen-devel] [xen-unstable test] 123379: regressions
- FAIL"):
> Before that there was:
>
> 2018-05-30 22:12:49.320+: xc: Failed to get types for pfn batch (14
> = Bad address): Internal error
This seems to be the only message about the root cause.
> But looking at the messages issued some seconds before that I see some
> xenstore watch related messages in:
>
> http://logs.test-lab.xenproject.org/osstest/logs/123379/test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm/huxelrebe1---var-log-libvirt-libxl-libxl-driver.log
I think this is all a red herring.
What I see happening is:
2018-05-30 22:12:44.695+: libxl:
libxl_event.c:636:libxl__ev_xswatch_register: watch w=0xb40005e8
wpath=/local/domain/3/control/shutdown token=2/b: register slotnum=2
libxl starts watching the domain's shutdown control node. I think
this is done from near libxl_dom_suspend.c:202.
2018-05-30 22:12:44.696+: libxl: libxl_event.c:573:watchfd_callback: watch
w=0xb40005e8 wpath=/local/domain/3/control/shutdown token=2/b: event
epath=/local/domain/3/control/shutdown
The watch we just set triggers. This happens with every xenstore
watch, after it is set up - ie, it does not mean that anything had
written the node.
2018-05-30 22:12:44.696+: libxl:
libxl_event.c:673:libxl__ev_xswatch_deregister: watch w=0xb40005e8
wpath=/local/domain/3/control/shutdown token=2/b: deregister slotnum=2
libxl stops watching the domain's shutdown control node. This is
done, I think, by domain_suspend_common_pvcontrol_suspending
(libxl_dom_suspend.c:222).
We can conclude that
if (!rc && !domain_suspend_pvcontrol_acked(state))
was not taken. It seems unlikely that rc!=0, because the
node is read in xswait_xswatch_callback using libxl__xs_read_checked
which I think would log a message. So probably
/local/domain/3/control/shutdown was `suspend', meaning the domain had
indeed acked the suspend request.
2018-05-30 22:12:44.696+: libxl:
libxl_event.c:636:libxl__ev_xswatch_register: watch w=0xb40005f8
wpath=@releaseDomain token=2/c: register slotnum=2
This is the watch registration in domain_suspend_common_wait_guest.
2018-05-30 22:12:44.696+: libxl: libxl_event.c:548:watchfd_callback: watch
w=0xb40005f8 epath=/local/domain/3/control/shutdown token=2/b: counter != c
This is a watch event for the watch we set up at 2018-05-30
22:12:44.696+. You can tell because the token is the same. But
that watch was cancelled within libxl at 2018-05-30
22:12:44.696+. libxl's watch handling machinery knows this, and
discards the event. "counter != c", libxl_event.c:547.
It does indeed use the same slot in the libxl xswatch data structure,
but libxl can distinguish it by the counter and the event path. (In
any case xs watch handlers should tolerate spurious events and be
idempotent, although that does not matter here.)
I think this must be the watch event from the guest actually writing
its acknowledgement to the control node - we would indeed expect two
such events, one generated by the watch setup, and one from the
guest's write. The timing meant that here we processed the guest's
written value as a result of the first watch event. This is fine.
2018-05-30 22:12:44.696+: libxl: libxl_event.c:573:watchfd_callback: watch
w=0xb40005f8 wpath=@releaseDomain token=2/c: event epath=@releaseDomain
This is the immediate-auto-firing of the @releaseDomain event set up
at 2018-05-30 22:12:44.696+. libxl's xswatch machinery looks this
up in slot 2 and finds that the counter and paths are right, so it
will dispatch it to suspend_common_wait_guest_watch which is a
frontend for suspend_common_wait_guest_check.
In the absence of log messages from that function we can conclude that
!(info.flags & XEN_DOMINF_shutdown)
ie the guest has not shut down yet.
2018-05-30 22:12:44.720+: libxl: libxl_event.c:573:watchfd_callback: watch
w=0xb2a26708 wpath=@releaseDomain token=3/0: event epath=@releaseDomain
This is a watch event which was set up much earlier at 2018-05-30
21:58:02.182+. The surrounding context there (references to
domain_death_xswatch_callback) makes it clear that this is pursuant to
libxl_evenable_domain_death - ie, libvirt asked libxl to monitor for
the death of the domain.
2018-05-30 22:12:44.724+: libxl:
libxl_domain.c:816:domain_death_xswatch_callback: shutdown reporting
The output here is a bit perplexing. I don't understand how we can
have the message "shutdown reporting" without any previous message
"Exists shutdown_reported=%d" or "[evg=%p] nentries=%d rc=%d %ld..%ld"
both of which seem to precede the "shutdown reporting" message in
domain_death_xswatch_callback.
However, we can conclude that, at this point, libxl finds that
got->flags & XEN_DOMINF_shutdown
and it decides to inform libvirt that the domain has shut down,
by providing a DOMAIN_SHUTDOWN libxl event.
(This event is not passed to libvirt immediately yet because it lives
on either (a) a queue
Re: [Xen-devel] [PATCH v1 1/2] x86/mm: Add mem access rights to NPT
>>> On 05.06.18 at 16:45, wrote: > On Mi, 2018-05-30 at 14:56 +0100, Andrew Cooper wrote: >> On 30/05/18 12:29, Jan Beulich wrote: >> > >> > > >> > > > >> > > > > >> > > > > On 30.05.18 at 13:20, wrote: >> > > On Mi, 2018-05-30 at 03:52 -0600, Jan Beulich wrote: >> > > > >> > > > > >> > > > > > >> > > > > > > >> > > > > > > On 30.05.18 at 11:04, wrote: >> > > > > Sorry for the misunderstanding, I wanted to clarify if the >> > > > > 59:56 >> > > > > bits >> > > > > are fully ok to be used or if not then where should I use 4 >> > > > > bits to >> > > > > store the mem access info? >> > > > I thought I had sufficiently explained this - you have two >> > > > options: >> > > > 1) Make sure (via some prereq patch(es)) bit 59 has no other >> > > > use, and >> > > >then use 59:56. >> > > > 2) Use another range that's provably having no other use, e.g. >> > > >58:55. >> > > I've checked and bits 40:52 are defined in asm/page.h for page >> > > flags. >> > 40:52? Hardly. >> > >> > > >> > > I've tried bits 53:56 and there where some problems with the >> > > guest not >> > > starting or the image freezing, >> > Well, you'll have to explain this (perhaps just to yourself). >> > >> > > >> > > bits 62 and 63 are not free so 59:56 is >> > > the only space to be used for this purpose and is seems to >> > > function >> > > correctly. >> > Well - as said before, bit 59 is not available for use without some >> > prereq work. >> There are no software available bits in the top of an AMD IOMMU PTE. >> Bits 59:62 are defined, while bits 52:58 are strictly reserved and >> fault >> if used. >> >> I'm also not convinced of the safety of our current uses of bits 9:11 >> which are software available in the regular pagetables, but have >> specific meaning in the IOMMU entries. >> >> If the code IOMMU code disables page sharing, then lets go one small >> step further and prohibit its use entirely. There is no point trying >> to >> maintain compatibility for an option which isn't used, especially if >> it >> gets in the way of improvements like this in the SVM code. >> > Another idea is to save the mem access info in a radix tree like on the > ARM side and we can store the radix tree root in the p2m_domain. > > I think that this is the fastest and cleanest way to solve the free > bits problem. But it adds extra (memory, lookup time) overhead. > Is this a suitable way to go? If no other option exists - perhaps. But that's more a question to be answered by George. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-unstable test] 123379: regressions - FAIL
>> test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2 I thought I would reply again with the key point from my earlier mail highlighted, and go a bit further. The first thing to go wrong in this was: 2018-05-30 22:12:49.320+: xc: Failed to get types for pfn batch (14 = Bad address): Internal error 2018-05-30 22:12:49.483+: xc: Save failed (14 = Bad address): Internal error 2018-05-30 22:12:49.648+: libxl-save-helper: complete r=-1: Bad address You can see similar messages in the other logfile: 2018-05-30 22:12:49.650+: libxl: libxl_stream_write.c:350:libxl__xc_domain_save_done: Domain 3:saving domain: domain responded to suspend request: Bad address All of these are reports of the same thing: xc_get_pfn_type_batch at xc_sr_save.c:133 failed with EFAULT. I'm afraid I don't know why. There is no corresponding message in the host's serial log nor the dom0 kernel log. Ian. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 123797: tolerable FAIL - PUSHED
flight 123797 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/123797/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 123579 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 123579 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 123579 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 123579 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 123579 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 123579 test-amd64-i386-xl-pvshim12 guest-start fail 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-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-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-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 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-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-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: qemuuafd76ffba966a072a7bbd0048bdf3b2ab69d3d4a baseline version: qemuu392fba9f583223786f844dce9b2e7f9a0ce0147a Last test of basis 123579 2018-06-01 20:18:21 Z3 days Testing same since 123797 2018-06-04 09:37:34 Z1 days1 attempts People who touched revisions under test: Alessandro Pilotti Alex Williamson Alexey Kardashevskiy Corey Minyard Cornelia Huck Eduardo Otubo Jay Zhou Justin Terry (VM) Ján Tomko Laszlo Ersek Lucian Petrut Marc-André Lureau Markus Armbruster Michael S. Tsirkin Paolo Bonzini Patryk Olszewski Peter Maydell Philippe Mathieu-Daudé Richard Henderson Thomas Huth Tristan Burgess Yi Min Zhao jobs: build-amd64-xsm pass build-arm64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass bu
[Xen-devel] [PATCH for-4.11] scripts/add_maintainers.pl: Don't call get_maintainers.pl with -f
The option -f of scripts/get_maintainers.pl will return the maintainers
of a given file, *not* the list of maintainers if the file was a patch.
The output expected of add_maintainers is the latter, so drop the option
-f.
Signed-off-by: Julien Grall
---
This patch is candidate for Xen 4.11. Without it add_maintainers.pl
will not return the correct maintainers. IHMO, it should be fixed
ASAP to avoid promoting a broken scripts.
---
scripts/add_maintainers.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/add_maintainers.pl b/scripts/add_maintainers.pl
index 99e4724112..09e9f6609f 100755
--- a/scripts/add_maintainers.pl
+++ b/scripts/add_maintainers.pl
@@ -420,7 +420,7 @@ sub ismailinglist ($) {
sub getmaintainers ($$$) {
my ($file, $rto, $rcc) = @_;
my $fh;
-open($fh, "-|", $get_maintainer, @get_maintainer_args, '-f', $file)
+open($fh, "-|", $get_maintainer, @get_maintainer_args, $file)
or die "Failed to open '$get_maintainer'\n";
while(my $line = <$fh>) {
chomp $line;
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC] xen: Don't use memory_region_init_ram_nomigrate() in pci_assign_dev_load_option_rom()
On Fri, Jun 01, 2018 at 06:59:10PM +0100, Peter Maydell wrote: > The xen pci_assign_dev_load_option_rom() currently creates a RAM > memory region with memory_region_init_ram_nomigrate(), and then > manually registers it with vmstate_register_ram(). In fact for > its only callsite, the 'owner' pointer we use for the init call > and the '&dev->qdev' pointer we use for the vmstate_register_ram() > call refer to the same object. Simplify the function to only > take a pointer to the device once instead of twice, and use > memory_region_init_ram() which automatically does the vmstate > register for us. > > Signed-off-by: Peter Maydell > --- > This is a fairly trivial no-behaviour-change code cleanup, but > I've marked it as RFC because I don't have a setup for doing > more than just compile-testing Xen related patches. > This was found as part of a sweep through for code using > the _nomigrate versions of functions. That patch looks fine, and seams fine after hacking my way into testing the change. Acked-by: Anthony PERARD Thanks, -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 6/7] xen/libfdt: Put all libfdt in init
Libfdt is used for: - Unflatten the Flatten Device-Tree (FDT) blob - Create Device-Tree for the Hardware-Domain Both use are done during the initialization of Xen. So move all the libfdt to init. Note that the runes was borrowed from libelf Makefile. Signed-off-by: Julien Grall --- xen/common/libfdt/Makefile | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile index 7578fe9c50..d81f54b6b8 100644 --- a/xen/common/libfdt/Makefile +++ b/xen/common/libfdt/Makefile @@ -1,5 +1,13 @@ include Makefile.libfdt -obj-y += $(LIBFDT_OBJS) +SECTIONS := text data $(SPECIAL_DATA_SECTIONS) + +obj-y += libfdt.o CFLAGS += -I$(BASEDIR)/include/xen/libfdt/ + +libfdt.o: libfdt-temp.o Makefile + $(OBJCOPY) $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@ + +libfdt-temp.o: $(LIBFDT_OBJS) + $(LD) $(LDFLAGS) -r -o $@ $^ -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 7/7] xen/arm: setup: Move in init code only used at boot in setup.c
Some of the functions implemented in setup.c are only used at boot but
not yet marked as such.
Signed-off-by: Julien Grall
---
xen/arch/arm/setup.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 1d6f6bf37e..fe7384fd30 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -175,7 +175,7 @@ static void __init processor_id(void)
check_local_cpu_errata();
}
-void dt_unreserved_regions(paddr_t s, paddr_t e,
+void __init dt_unreserved_regions(paddr_t s, paddr_t e,
void (*cb)(paddr_t, paddr_t), int first)
{
int i, nr = fdt_num_mem_rsv(device_tree_flattened);
@@ -201,9 +201,9 @@ void dt_unreserved_regions(paddr_t s, paddr_t e,
cb(s, e);
}
-struct bootmodule *add_boot_module(bootmodule_kind kind,
- paddr_t start, paddr_t size,
- const char *cmdline)
+struct bootmodule __init *add_boot_module(bootmodule_kind kind,
+ paddr_t start, paddr_t size,
+ const char *cmdline)
{
struct bootmodules *mods = &bootinfo.modules;
struct bootmodule *mod;
@@ -434,7 +434,7 @@ static paddr_t __init get_xen_paddr(void)
return paddr;
}
-static void init_pdx(void)
+static void __init init_pdx(void)
{
paddr_t bank_start, bank_size, bank_end;
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/7] xen/arm: Shrink down Xen on Arm
Hi all, This series remove some unused code from Xen and also move some part under __init if only used during boot. The major change of this patch is removing support libelf in Xen (see #4 and #5). Cheers, Julien Grall (7): xen/arm: Remove the variable dom0_11_mapping and open-code the value xen/arm: domain_build: Move in init all code/data of domain_build.c xen/arm: kernel: Move in init all the code/data of kernel.c xen/arm: Drop support for loading ELF Dom0 kernel xen: Don't build libelf for Arm xen/libfdt: Put all libfdt in init xen/arm: setup: Move in init code only used at boot in setup.c xen/arch/arm/Makefile| 4 +- xen/arch/arm/domain_build.c | 137 ++- xen/arch/arm/kernel.c| 103 xen/arch/arm/kernel.h| 10 +--- xen/arch/arm/setup.c | 10 ++-- xen/arch/x86/Kconfig | 1 + xen/common/Kconfig | 3 + xen/common/Makefile | 2 +- xen/common/libfdt/Makefile | 10 +++- xen/include/asm-arm/domain.h | 4 +- 10 files changed, 107 insertions(+), 177 deletions(-) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3/7] xen/arm: kernel: Move in init all the code/data of kernel.c
The file kernel.c only contains code/data used during the
initialization. So move everything to init and mark the file as such.
Signed-off-by: Julien Grall
---
xen/arch/arm/Makefile | 2 +-
xen/arch/arm/kernel.c | 32
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 6c4afe27cc..a5bd44e59d 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -25,7 +25,7 @@ obj-y += guest_walk.o
obj-y += hvm.o
obj-y += io.o
obj-y += irq.o
-obj-y += kernel.o
+obj-y += kernel.init.o
obj-$(CONFIG_LIVEPATCH) += livepatch.o
obj-y += mem_access.o
obj-y += mm.o
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 8fdfd91543..b29028f7d0 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -46,7 +46,7 @@ struct minimal_dtb_header {
* @paddr: source physical address
* @len: length to copy
*/
-void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
+void __init copy_from_paddr(void *dst, paddr_t paddr, unsigned long len)
{
void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
@@ -68,8 +68,8 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long
len)
clear_fixmap(FIXMAP_MISC);
}
-static void place_modules(struct kernel_info *info,
- paddr_t kernbase, paddr_t kernend)
+static void __init place_modules(struct kernel_info *info,
+ paddr_t kernbase, paddr_t kernend)
{
/* Align DTB and initrd size to 2Mb. Linux only requires 4 byte alignment
*/
const struct bootmodule *mod = info->initrd_bootmodule;
@@ -122,7 +122,7 @@ static void place_modules(struct kernel_info *info,
info->initrd_paddr = info->dtb_paddr + dtb_len;
}
-static paddr_t kernel_zimage_place(struct kernel_info *info)
+static paddr_t __init kernel_zimage_place(struct kernel_info *info)
{
paddr_t load_addr;
@@ -154,7 +154,7 @@ static paddr_t kernel_zimage_place(struct kernel_info *info)
return load_addr;
}
-static void kernel_zimage_load(struct kernel_info *info)
+static void __init kernel_zimage_load(struct kernel_info *info)
{
paddr_t load_addr = kernel_zimage_place(info);
paddr_t paddr = info->zimage.kernel_addr;
@@ -190,8 +190,8 @@ static void kernel_zimage_load(struct kernel_info *info)
/*
* Check if the image is a uImage and setup kernel_info
*/
-static int kernel_uimage_probe(struct kernel_info *info,
- paddr_t addr, paddr_t size)
+static int __init kernel_uimage_probe(struct kernel_info *info,
+ paddr_t addr, paddr_t size)
{
struct {
__be32 magic; /* Image Header Magic Number */
@@ -318,8 +318,8 @@ static __init int kernel_decompress(struct bootmodule *mod)
/*
* Check if the image is a 64-bit Image.
*/
-static int kernel_zimage64_probe(struct kernel_info *info,
- paddr_t addr, paddr_t size)
+static int __init kernel_zimage64_probe(struct kernel_info *info,
+paddr_t addr, paddr_t size)
{
/* linux/Documentation/arm64/booting.txt */
struct {
@@ -372,8 +372,8 @@ static int kernel_zimage64_probe(struct kernel_info *info,
/*
* Check if the image is a 32-bit zImage and setup kernel_info
*/
-static int kernel_zimage32_probe(struct kernel_info *info,
- paddr_t addr, paddr_t size)
+static int __init kernel_zimage32_probe(struct kernel_info *info,
+paddr_t addr, paddr_t size)
{
uint32_t zimage[ZIMAGE32_HEADER_LEN/4];
uint32_t start, end;
@@ -421,7 +421,7 @@ static int kernel_zimage32_probe(struct kernel_info *info,
return 0;
}
-static void kernel_elf_load(struct kernel_info *info)
+static void __init kernel_elf_load(struct kernel_info *info)
{
/*
* TODO: can the ELF header be used to find the physical address
@@ -444,8 +444,8 @@ static void kernel_elf_load(struct kernel_info *info)
free_xenheap_pages(info->elf.kernel_img, info->elf.kernel_order);
}
-static int kernel_elf_probe(struct kernel_info *info,
-paddr_t addr, paddr_t size)
+static int __init kernel_elf_probe(struct kernel_info *info,
+ paddr_t addr, paddr_t size)
{
int rc;
@@ -496,7 +496,7 @@ err:
return rc;
}
-int kernel_probe(struct kernel_info *info)
+int __init kernel_probe(struct kernel_info *info)
{
struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
int rc;
@@ -534,7 +534,7 @@ int kernel_probe(struct kernel_info *info)
return rc;
}
-void kernel_load(struct kernel_info *info)
+void __init kernel_load(struct kernel_info *info)
{
info->load(info);
}
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/7] xen/arm: Remove the variable dom0_11_mapping and open-code the value
Dom0 (aka hardware domain on Arm) is always direct mapped. Rather than
using a global variable to store a const, directly open-code it or
replace the use with is_domain_direct_mapped(...) macros.
This will also help a follow-up patch to move all domain_build.c in
init.
Signed-off-by: Julien Grall
---
xen/arch/arm/domain_build.c | 4 +---
xen/include/asm-arm/domain.h | 4 ++--
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 11cdf05091..3c414c7f73 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -28,8 +28,6 @@
static unsigned int __initdata opt_dom0_max_vcpus;
integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
-int dom0_11_mapping = 1;
-
static u64 __initdata dom0_mem;
static int __init parse_dom0_mem(const char *s)
@@ -261,7 +259,7 @@ static void allocate_memory(struct domain *d, struct
kernel_info *kinfo)
* TODO: Implement memory bank allocation when DOM0 is not direct
* mapped
*/
-BUG_ON(!dom0_11_mapping);
+BUG_ON(!is_domain_direct_mapped(d));
printk("Allocating 1:1 mappings totalling %ldMB for dom0:\n",
/* Don't want format this as PRIpaddr (16 digit hex) */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 7ba6528a74..280c3951fd 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -31,8 +31,8 @@ enum domain_type {
#define is_64bit_domain(d) (0)
#endif
-extern int dom0_11_mapping;
-#define is_domain_direct_mapped(d) ((d) == hardware_domain && dom0_11_mapping)
+/* The hardware domain has always its memory direct mapped. */
+#define is_domain_direct_mapped(d) ((d) == hardware_domain)
struct vtimer {
struct vcpu *v;
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/7] xen/arm: domain_build: Move in init all code/data of domain_build.c
The file domain_build.c only contains code/data used during the
initialization. So move everything to init and mark the file as such.
Signed-off-by: Julien Grall
---
xen/arch/arm/Makefile | 2 +-
xen/arch/arm/domain_build.c | 133 +++-
2 files changed, 70 insertions(+), 65 deletions(-)
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index a9533b107e..6c4afe27cc 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -12,7 +12,7 @@ obj-y += cpufeature.o
obj-y += decode.o
obj-y += device.o
obj-y += domain.o
-obj-y += domain_build.o
+obj-y += domain_build.init.o
obj-y += domctl.o
obj-$(EARLY_PRINTK) += early_printk.o
obj-y += gic.o
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 3c414c7f73..1351572da1 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -77,7 +77,7 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
return alloc_vcpu(dom0, 0, 0);
}
-static unsigned int get_11_allocation_size(paddr_t size)
+static unsigned int __init get_11_allocation_size(paddr_t size)
{
/*
* get_order_from_bytes returns the order greater than or equal to
@@ -95,10 +95,10 @@ static unsigned int get_11_allocation_size(paddr_t size)
* Returns false if the memory would be below bank 0 or we have run
* out of banks. In this case it will free the pages.
*/
-static bool insert_11_bank(struct domain *d,
- struct kernel_info *kinfo,
- struct page_info *pg,
- unsigned int order)
+static bool __init insert_11_bank(struct domain *d,
+ struct kernel_info *kinfo,
+ struct page_info *pg,
+ unsigned int order)
{
int res, i;
mfn_t smfn;
@@ -243,7 +243,7 @@ fail:
* (as described above) we allow higher allocations and continue until
* that runs out (or we have allocated sufficient dom0 memory).
*/
-static void allocate_memory(struct domain *d, struct kernel_info *kinfo)
+static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
{
const unsigned int min_low_order =
get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
@@ -367,8 +367,8 @@ static void allocate_memory(struct domain *d, struct
kernel_info *kinfo)
}
}
-static int write_properties(struct domain *d, struct kernel_info *kinfo,
-const struct dt_device_node *node)
+static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
+ const struct dt_device_node *node)
{
const char *bootargs = NULL;
const struct dt_property *prop, *status = NULL;
@@ -494,8 +494,10 @@ static int write_properties(struct domain *d, struct
kernel_info *kinfo,
typedef __be32 gic_interrupt_t[3];
-static void set_interrupt_ppi(gic_interrupt_t interrupt, unsigned int irq,
- unsigned int cpumask, unsigned int level)
+static void __init set_interrupt_ppi(gic_interrupt_t interrupt,
+ unsigned int irq,
+ unsigned int cpumask,
+ unsigned int level)
{
__be32 *cells = interrupt;
@@ -514,8 +516,8 @@ static void set_interrupt_ppi(gic_interrupt_t interrupt,
unsigned int irq,
* "interrupts": contains the list of interrupts
* "interrupt-parent": link to the GIC
*/
-static int fdt_property_interrupts(void *fdt, gic_interrupt_t *intr,
- unsigned num_irq)
+static int __init fdt_property_interrupts(void *fdt, gic_interrupt_t *intr,
+ unsigned num_irq)
{
int res;
@@ -529,10 +531,10 @@ static int fdt_property_interrupts(void *fdt,
gic_interrupt_t *intr,
return res;
}
-static int make_memory_node(const struct domain *d,
-void *fdt,
-const struct dt_device_node *parent,
-const struct kernel_info *kinfo)
+static int __init make_memory_node(const struct domain *d,
+ void *fdt,
+ const struct dt_device_node *parent,
+ const struct kernel_info *kinfo)
{
int res, i;
int reg_size = dt_child_n_addr_cells(parent) +
dt_child_n_size_cells(parent);
@@ -575,9 +577,9 @@ static int make_memory_node(const struct domain *d,
static void evtchn_allocate(struct domain *d);
-static int make_hypervisor_node(struct domain *d,
-const struct kernel_info *kinfo,
-const struct dt_device_node *parent)
+static int __init make_hypervisor_node(struct domain *d,
+ const struct kernel_info *kinfo,
+
[Xen-devel] [PATCH 5/7] xen: Don't build libelf for Arm
Now that ELF support has been dropped to boot Dom0, no-one is using libelf within the hypervisor. Introduce a config option to select libelf on x86 and keep unselected for Arm. Signed-off-by: Julien Grall --- xen/arch/x86/Kconfig | 1 + xen/common/Kconfig | 3 +++ xen/common/Makefile | 2 +- 3 files changed, 5 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index f64fc56739..3d388133ef 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -12,6 +12,7 @@ config X86 select HAS_CPUFREQ select HAS_EHCI select HAS_EX_TABLE + select HAS_ELF select HAS_GDBSX select HAS_IOPORTS select HAS_KEXEC diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 9043dce937..3cf551c736 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -17,6 +17,9 @@ config HAS_ALTERNATIVE config HAS_DEVICE_TREE bool +config HAS_ELF +bool + config HAS_EX_TABLE bool diff --git a/xen/common/Makefile b/xen/common/Makefile index 24d4752ccc..3cc808bd83 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -78,5 +78,5 @@ obj-$(CONFIG_TMEM) += $(tmem-y) subdir-$(CONFIG_COVERAGE) += coverage subdir-$(CONFIG_UBSAN) += ubsan -subdir-y += libelf +subdir-$(CONFIG_HAS_ELF) += libelf subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4/7] xen/arm: Drop support for loading ELF Dom0 kernel
The code has been around since the beginning of Xen Arm. However, I am
not aware of any user and the code is pretty bogus:
1) It is assuming virtual address == physical address.
2) The cache is not cleaned after the Image is loaded but the Image
is started with Cache disabled.
3) There are not clear ABI with the guest.
Xen is currently supporting 3 other formats (zImage, Image, U-boot Image)
as well as gzip compressed version of each formats. All of them are well
documented and widely use.
Signed-off-by: Julien Grall
---
Given the state, I doubt anyone is using the ELF format with Xen
on Arm. By dropping this code, it also allows us to remove the
built-in libelf (~1.2K lines) from Xen.
---
xen/arch/arm/kernel.c | 77 ---
xen/arch/arm/kernel.h | 10 +--
2 files changed, 1 insertion(+), 86 deletions(-)
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index b29028f7d0..000d9397e1 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -421,81 +421,6 @@ static int __init kernel_zimage32_probe(struct kernel_info
*info,
return 0;
}
-static void __init kernel_elf_load(struct kernel_info *info)
-{
-/*
- * TODO: can the ELF header be used to find the physical address
- * to load the image to? Instead of assuming virt == phys.
- */
-info->entry = info->elf.parms.virt_entry;
-
-place_modules(info,
- info->elf.parms.virt_kstart,
- info->elf.parms.virt_kend);
-
-printk("Loading ELF image into guest memory\n");
-info->elf.elf.dest_base = (void*)(unsigned
long)info->elf.parms.virt_kstart;
-info->elf.elf.dest_size =
- info->elf.parms.virt_kend - info->elf.parms.virt_kstart;
-
-elf_load_binary(&info->elf.elf);
-
-printk("Free temporary kernel buffer\n");
-free_xenheap_pages(info->elf.kernel_img, info->elf.kernel_order);
-}
-
-static int __init kernel_elf_probe(struct kernel_info *info,
- paddr_t addr, paddr_t size)
-{
-int rc;
-
-memset(&info->elf.elf, 0, sizeof(info->elf.elf));
-
-info->elf.kernel_order = get_order_from_bytes(size);
-info->elf.kernel_img = alloc_xenheap_pages(info->elf.kernel_order, 0);
-if ( info->elf.kernel_img == NULL )
-panic("Cannot allocate temporary buffer for kernel");
-
-copy_from_paddr(info->elf.kernel_img, addr, size);
-
-if ( (rc = elf_init(&info->elf.elf, info->elf.kernel_img, size )) != 0 )
-goto err;
-#ifdef CONFIG_VERBOSE_DEBUG
-elf_set_verbose(&info->elf.elf);
-#endif
-elf_parse_binary(&info->elf.elf);
-if ( (rc = elf_xen_parse(&info->elf.elf, &info->elf.parms)) != 0 )
-goto err;
-
-#ifdef CONFIG_ARM_64
-if ( elf_32bit(&info->elf.elf) )
-info->type = DOMAIN_32BIT;
-else if ( elf_64bit(&info->elf.elf) )
-info->type = DOMAIN_64BIT;
-else
-{
-printk("Unknown ELF class\n");
-rc = -EINVAL;
-goto err;
-}
-#endif
-
-info->load = kernel_elf_load;
-
-if ( elf_check_broken(&info->elf.elf) )
-printk("Xen: warning: ELF kernel broken: %s\n",
- elf_check_broken(&info->elf.elf));
-
-return 0;
-err:
-if ( elf_check_broken(&info->elf.elf) )
-printk("Xen: ELF kernel broken: %s\n",
- elf_check_broken(&info->elf.elf));
-
-free_xenheap_pages(info->elf.kernel_img, info->elf.kernel_order);
-return rc;
-}
-
int __init kernel_probe(struct kernel_info *info)
{
struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
@@ -528,8 +453,6 @@ int __init kernel_probe(struct kernel_info *info)
rc = kernel_uimage_probe(info, mod->start, mod->size);
if (rc < 0)
rc = kernel_zimage32_probe(info, mod->start, mod->size);
-if (rc < 0)
-rc = kernel_elf_probe(info, mod->start, mod->size);
return rc;
}
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
index 6d695097b5..47eacb5ba9 100644
--- a/xen/arch/arm/kernel.h
+++ b/xen/arch/arm/kernel.h
@@ -6,7 +6,6 @@
#ifndef __ARCH_ARM_KERNEL_H__
#define __ARCH_ARM_KERNEL_H__
-#include
#include
#include
@@ -45,13 +44,6 @@ struct kernel_info {
#endif
paddr_t start; /* 32-bit zImage only */
} zimage;
-
-struct {
-struct elf_binary elf;
-struct elf_dom_parms parms;
-unsigned kernel_order;
-void *kernel_img;
-} elf;
};
};
@@ -60,7 +52,7 @@ struct kernel_info {
*
* Sets in info:
* ->type
- * ->load hook, and sets loader specific variables ->{zimage,elf}
+ * ->load hook, and sets loader specific variables ->zimage
*/
int kernel_probe(struct kernel_info *info);
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 01/10] xen/arm64: Added handling of the trapped access to OSLSR register
Hi Mirela,
On 01/06/18 14:17, Mirela Simonovic wrote:
Linux/dom0 accesses OSLSR register when saving CPU context during the
suspend procedure. Xen traps access to this register, but has no handling
for it. Consequently, Xen injects undef exception to linux, causing it to
crash. This patch adds handling of the trapped access to OSLSR as read
only as a fixed value.
Can you please mention that you introduced handle_ro_read_val() and
rework handle_ro_raz()?
Signed-off-by: Mirela Simonovic
Reviewed-by: Stefano Stabellini
Acked-by: Julien Grall
The reviewed-by/acked-by tags should only be kept when there are minor
changes in the code (and the reviewer is happy with them). This is very
important for the former as the tag means the reviewer read your code
and confirm this is correct.
As you change quite a bit the patch, those 2 tags should have been removed.
Stefano, are you still happy with the Reviewed-by?
---
CC: Stefano Stabellini
CC: Julien Grall
---
Changes in v2:
- Commit message fix (arm64 related change instead of arm)
- Add Stefano's reviewed-by
Changes in v3:
- Added Julien's acked-by
Changes in v5:
-Insted of zero the reading of OSLSR_EL1 should return set bit 3
-Implement new helper handle_ro_read_val() to support read only as a value.
handle_ro_read_val() reuses the implementation of handle_ro_raz() and
extends it with additional argument for passing the value to be returned
-Use handle_ro_read_val() for handle_ro_raz() implementation to avoid code
duplication
-Fix commit message to reflect changes made in this version
---
xen/arch/arm/arm64/vsysreg.c | 4 +++-
xen/arch/arm/traps.c | 26 ++
xen/include/asm-arm/traps.h | 4
3 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
index c57ac12503..6e60824572 100644
--- a/xen/arch/arm/arm64/vsysreg.c
+++ b/xen/arch/arm/arm64/vsysreg.c
@@ -57,13 +57,15 @@ void do_sysreg(struct cpu_user_regs *regs,
* ARMv8 (DDI 0487A.d): D1-1509 Table D1-58
*
* Unhandled:
- *OSLSR_EL1
*DBGPRCR_EL1
*/
case HSR_SYSREG_OSLAR_EL1:
return handle_wo_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
case HSR_SYSREG_OSDLR_EL1:
return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
+case HSR_SYSREG_OSLSR_EL1:
+return handle_ro_read_val(regs, regidx, hsr.sysreg.read, hsr, 1,
+ 1 << 3);
/*
* MDCR_EL2.TDA
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 5c18e918b0..d71adfa745 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1739,12 +1739,13 @@ void handle_wo_wi(struct cpu_user_regs *regs,
advance_pc(regs, hsr);
}
-/* Read only as read as zero */
-void handle_ro_raz(struct cpu_user_regs *regs,
- int regidx,
- bool read,
- const union hsr hsr,
- int min_el)
+/* Read only as value provided with 'val' argument of this function */
+void handle_ro_read_val(struct cpu_user_regs *regs,
+int regidx,
+bool read,
+const union hsr hsr,
+int min_el,
+register_t val)
{
ASSERT((min_el == 0) || (min_el == 1));
@@ -1753,13 +1754,22 @@ void handle_ro_raz(struct cpu_user_regs *regs,
if ( !read )
return inject_undef_exception(regs, hsr);
-/* else: raz */
-set_user_reg(regs, regidx, 0);
+set_user_reg(regs, regidx, val);
advance_pc(regs, hsr);
}
+/* Read only as read as zero */
+inline void handle_ro_raz(struct cpu_user_regs *regs,
+ int regidx,
+ bool read,
+ const union hsr hsr,
+ int min_el)
+{
+handle_ro_read_val(regs, regidx, read, hsr, min_el, 0);
+}
+
void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
{
register_t ttbcr = READ_SYSREG(TCR_EL1);
diff --git a/xen/include/asm-arm/traps.h b/xen/include/asm-arm/traps.h
index a0e5e92ebb..70b52d1d16 100644
--- a/xen/include/asm-arm/traps.h
+++ b/xen/include/asm-arm/traps.h
@@ -27,6 +27,10 @@ void handle_wo_wi(struct cpu_user_regs *regs, int regidx,
bool read,
void handle_ro_raz(struct cpu_user_regs *regs, int regidx, bool read,
const union hsr hsr, int min_el);
+/* Read only as value provided with 'val' argument */
+void handle_ro_read_val(struct cpu_user_regs *regs, int regidx, bool read,
+const union hsr hsr, int min_el, register_t val);
+
/* Co-processor registers emulation (see arch/arm/vcpreg.c). */
void do_cp15_32(struct cpu_user_regs *regs, const union hsr hsr);
void do_cp15_64(struct cpu_user_regs *regs, const union hsr hsr);
--
Julien Grall
___
Xen-devel
Re: [Xen-devel] [PATCH v5 05/10] xen/arm: Setup virtual paging for non-boot CPUs on hotplug/resume
Hi Mirela,
On 01/06/18 14:17, Mirela Simonovic wrote:
In existing code the virtual paging for non-boot CPUs is setup only on boot.
The setup is triggered from start_xen() after all CPUs are brought online.
In other words, the initialization of VTCR_EL2 register is done out of the
cpu_up/start_secondary() control flow. However, the cpu_up flow is also used
to hotplug non-boot CPUs on resume from suspend to RAM state, in which case
the virtual paging will not be configured.
With this patch the setting of paging is triggered from start_secondary()
function using cpu starting notifier (notify_cpu_starting() call). The
notifier is registered in p2m.c using init call. This has to be done with
init call rather than presmp_init because the registered callback depends
on vtcr configuration value which is setup after the presmp init calls
are executed (do_presmp_initcalls() called from start_xen()). Init calls
are executed after initial virtual paging is set up for all CPUs on boot.
This ensures that no callback can fire until the vtcr value is calculated
by Xen and virtual paging is set up initially for all CPUs. Also, this way
the virtual paging setup in boot scenario remains unchanged.
It is assumed here that after the system completed the boot, CPUs that
execute start_secondary() were booted as well when the Xen itself was
booted. According to this assumption non-boot CPUs will always be compliant
with the VTCR_EL2 value that was selected by Xen on boot.
Currently, there is no mechanism to trigger hotplugging of a CPU. This
will be added with the suspend to RAM support for ARM, where the hotplug
of non-boot CPUs will be triggered via enable_nonboot_cpus() call.
Signed-off-by: Mirela Simonovic
Reviewed-by: Julien Grall
Cheers,
---
CC: Stefano Stabellini
CC: Julien Grall
---
Changes in v2:
-Fix commit message
-Save configured VTCR_EL2 value into static variable that will be used
by non-boot CPUs on hotplug
-Add setup_virt_paging_secondary() and invoke it from start_secondary()
if that CPU has to setup virtual paging (if the system state is not boot)
Changes in v3:
-Fix commit message
-Remove setup_virt_paging_secondary() and use notifier to setup virtual
paging for non-boot CPU on hotplug.
-In setup_virt_paging() use vtcr static variable instead of local val
-In setup_virt_paging_one() use vtcr static variable instead of provided
argument
Changes in v4:
-Add includes alphabetically
-Add newline before return in cpu_virt_paging_init()
-Fix indentation in cpu_virt_paging_callback() definition
-Use local val in setup_virt_paging() for calculation, assign it to vtcr
after the calculation is done
-Remove priority initialization in the notifier structure (priority
doesn't matter here)
Changes in v5:
-Define vtcr as uint32_t instead uint64_t
---
xen/arch/arm/p2m.c | 53 -
1 file changed, 48 insertions(+), 5 deletions(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index d43c3aa896..14791388ad 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -8,6 +8,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -1451,10 +1453,12 @@ err:
return page;
}
-static void __init setup_virt_paging_one(void *data)
+/* VTCR value to be configured by all CPUs. Set only once by the boot CPU */
+static uint32_t __read_mostly vtcr;
+
+static void setup_virt_paging_one(void *data)
{
-unsigned long val = (unsigned long)data;
-WRITE_SYSREG32(val, VTCR_EL2);
+WRITE_SYSREG32(vtcr, VTCR_EL2);
isb();
}
@@ -1538,10 +1542,49 @@ void __init setup_virt_paging(void)
/* It is not allowed to concatenate a level zero root */
BUG_ON( P2M_ROOT_LEVEL == 0 && P2M_ROOT_ORDER > 0 );
-setup_virt_paging_one((void *)val);
-smp_call_function(setup_virt_paging_one, (void *)val, 1);
+vtcr = val;
+setup_virt_paging_one(NULL);
+smp_call_function(setup_virt_paging_one, NULL, 1);
+}
+
+static int cpu_virt_paging_callback(struct notifier_block *nfb,
+unsigned long action,
+void *hcpu)
+{
+switch ( action )
+{
+case CPU_STARTING:
+ASSERT(system_state != SYS_STATE_boot);
+setup_virt_paging_one(NULL);
+break;
+default:
+break;
+}
+
+return NOTIFY_DONE;
}
+static struct notifier_block cpu_virt_paging_nfb = {
+.notifier_call = cpu_virt_paging_callback,
+};
+
+static int __init cpu_virt_paging_init(void)
+{
+register_cpu_notifier(&cpu_virt_paging_nfb);
+
+return 0;
+}
+/*
+ * Initialization of the notifier has to be done at init rather than
presmp_init
+ * phase because: the registered notifier is used to setup virtual paging for
+ * non-boot CPUs after the initial virtual paging for all CPUs is already
setup,
+ * i.e. when a non-boot CPU is hotplugged after the system has booted. In other
+ * words, the notifier s
[Xen-devel] [linux-next test] 123795: regressions - FAIL
flight 123795 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/123795/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 123554 test-amd64-amd64-xl-xsm 10 debian-install fail REGR. vs. 123554 test-amd64-i386-xl-xsm 10 debian-install fail REGR. vs. 123554 test-amd64-i386-qemut-rhel6hvm-intel 10 redhat-install fail REGR. vs. 123554 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 123554 test-amd64-i386-xl-shadow10 debian-install fail REGR. vs. 123554 test-amd64-i386-freebsd10-amd64 10 freebsd-install fail REGR. vs. 123554 test-amd64-amd64-libvirt-pair 16 debian-install/dst_host fail REGR. vs. 123554 test-amd64-amd64-xl-multivcpu 10 debian-install fail REGR. vs. 123554 test-amd64-i386-freebsd10-i386 10 freebsd-installfail REGR. vs. 123554 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 123554 test-amd64-amd64-libvirt-xsm 10 debian-install fail REGR. vs. 123554 test-amd64-amd64-xl-pvhv2-amd 10 debian-install fail REGR. vs. 123554 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 123554 test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install fail REGR. vs. 123554 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 123554 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 123554 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 123554 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 123554 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 123554 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 123554 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 123554 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 123554 test-amd64-amd64-amd64-pvgrub 16 guest-saverestore.2 fail REGR. vs. 123554 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 123554 test-amd64-i386-xl-qemuu-debianhvm-amd64 13 guest-saverestore fail REGR. vs. 123554 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 123554 test-amd64-i386-xl-raw 10 debian-di-installfail REGR. vs. 123554 test-amd64-amd64-libvirt-vhd 10 debian-di-installfail REGR. vs. 123554 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 123554 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-install fail REGR. vs. 123554 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install fail REGR. vs. 123554 test-amd64-i386-xl-qemut-win7-amd64 10 windows-install fail REGR. vs. 123554 build-arm64-pvops 6 kernel-build fail REGR. vs. 123554 test-armhf-armhf-examine 8 reboot fail REGR. vs. 123554 test-armhf-armhf-xl-xsm 7 xen-boot fail REGR. vs. 123554 test-armhf-armhf-xl-vhd 7 xen-boot fail REGR. vs. 123554 test-armhf-armhf-xl-multivcpu 7 xen-bootfail REGR. vs. 123554 test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 123554 test-armhf-armhf-libvirt 7 xen-boot fail REGR. vs. 123554 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 123554 test-armhf-armhf-xl-credit2 7 xen-boot fail REGR. vs. 123554 test-armhf-armhf-xl-cubietruck 7 xen-boot fail REGR. vs. 123554 test-armhf-armhf-libvirt-raw 7 xen-boot fail REGR. vs. 123554 test-armhf-armhf-libvirt-xsm 10 debian-install fail REGR. vs. 123554 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 123554 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 7 xen-boot fail REGR. vs. 123554 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-xl 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-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-su
Re: [Xen-devel] [PATCH v5 04/10] Make MEM_ACCESS configurable
Hi, On 04/06/18 18:24, Stefano Stabellini wrote: Select MEM_ACCESS_ALWAYS_ON on x86 to mark that MEM_ACCESS is not configurable on x86. Avoid selecting it on ARM. Rename HAS_MEM_ACCESS to MEM_ACCESS everywhere. Add a prompt and a description to MEM_ACCESS in xen/common/Kconfig. The result is that the user-visible option is MEM_ACCESS, and it is configurable only on ARM (disabled by default). It would be nice to mention in the commit message the shortcoming for Arm. Because you are just removing the guest interface, all the arch-specific infrastructure is still present. The purpose is to reduce code size. The option doesn't depend on EXPERT because it would be nice to ecurity-support configurations without s/ecurity-support/security-support/ MEM_ACCESS and a non-expert should be able to disable it. Suggested-by: Julien Grall Signed-off-by: Stefano Stabellini Acked-by: Jan Beulich CC: andrew.coop...@citrix.com CC: george.dun...@eu.citrix.com CC: ian.jack...@eu.citrix.com CC: jbeul...@suse.com CC: julien.gr...@arm.com CC: konrad.w...@oracle.com CC: sstabell...@kernel.org CC: t...@xen.org CC: wei.l...@citrix.com --- Changes in v5: - change MEM_ACCESS_ALWAYS_ON to bool - change default for MEM_ACCESS, default y if MEM_ACCESS_ALWAYS_ON Changes in v4: - remove HAS_MEM_ACCESS - move MEM_ACCESS_ALWAYS_ON to common - combile default and bool to def_bool Changes in v3: - keep HAS_MEM_ACCESS to mark that an arch can do MEM_ACCESS - introduce MEM_ACCESS_ALWAYS_ON - the main MEM_ACCESS option is in xen/common/Kconfig Changes in v2: - patch added --- tools/firmware/xen-dir/shim.config | 2 +- xen/arch/arm/Kconfig | 1 - xen/arch/x86/Kconfig | 2 +- xen/common/Kconfig | 10 +- xen/common/Makefile| 2 +- xen/common/domctl.c| 2 +- xen/include/xen/mem_access.h | 4 ++-- xen/include/xsm/dummy.h| 2 +- xen/include/xsm/xsm.h | 4 ++-- xen/xsm/dummy.c| 2 +- xen/xsm/flask/hooks.c | 4 ++-- You probably want an ack from Daniel here (CCed him). 11 files changed, 21 insertions(+), 14 deletions(-) diff --git a/tools/firmware/xen-dir/shim.config b/tools/firmware/xen-dir/shim.config index 4d5630f..21d7075 100644 --- a/tools/firmware/xen-dir/shim.config +++ b/tools/firmware/xen-dir/shim.config @@ -29,7 +29,7 @@ CONFIG_COMPAT=y CONFIG_CORE_PARKING=y CONFIG_HAS_ALTERNATIVE=y CONFIG_HAS_EX_TABLE=y -CONFIG_HAS_MEM_ACCESS=y +CONFIG_MEM_ACCESS=y CONFIG_HAS_MEM_PAGING=y CONFIG_HAS_MEM_SHARING=y CONFIG_HAS_PDX=y diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 66adce4..2b87111 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -17,7 +17,6 @@ config ARM def_bool y select HAS_ALTERNATIVE select HAS_DEVICE_TREE - select HAS_MEM_ACCESS select HAS_PASSTHROUGH select HAS_PDX diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index f64fc56..9a85fe9 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -15,7 +15,7 @@ config X86 select HAS_GDBSX select HAS_IOPORTS select HAS_KEXEC - select HAS_MEM_ACCESS + select MEM_ACCESS_ALWAYS_ON select HAS_MEM_PAGING select HAS_MEM_SHARING select HAS_NS16550 diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 9043dce..db6bb2d 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -20,9 +20,17 @@ config HAS_DEVICE_TREE config HAS_EX_TABLE bool -config HAS_MEM_ACCESS +config MEM_ACCESS_ALWAYS_ON bool +config MEM_ACCESS + def_bool MEM_ACCESS_ALWAYS_ON + prompt "Memory Access and VM events" if !MEM_ACCESS_ALWAYS_ON + ---help--- + + Framework to configure memory access types for guests and receive + related events in userspace. + config HAS_MEM_PAGING bool diff --git a/xen/common/Makefile b/xen/common/Makefile index 24d4752..6f2b3fc 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -22,7 +22,7 @@ obj-y += lib.o obj-$(CONFIG_NEEDS_LIST_SORT) += list_sort.o obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o obj-y += lzo.o -obj-$(CONFIG_HAS_MEM_ACCESS) += mem_access.o +obj-$(CONFIG_MEM_ACCESS) += mem_access.o obj-y += memory.o obj-y += monitor.o obj-y += multicall.o diff --git a/xen/common/domctl.c b/xen/common/domctl.c index 9b7bc08..891ad58 100644 --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -1085,7 +1085,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) copyback = 1; break; -#ifdef CONFIG_HAS_MEM_ACCESS +#ifdef CONFIG_MEM_ACCESS case XEN_DOMCTL_set_access_required: if ( unlikely(current->domain == d) ) /* no domain_pause() */ ret = -EPERM; diff --git a/xen/include/xen/mem_access.h b/xen/include/xen/mem_access.h index 5ab34c1..7e95eab 100644 --- a/xen/include/xen/mem_
Re: [Xen-devel] [PATCH v5 05/10] make it possible to enable/disable UART drivers
Hi Stefano, On 04/06/18 18:24, Stefano Stabellini wrote: All the UART drivers are silent options. Add one line descriptions so that can be de/selected via menuconfig. Add an x86 dependency to HAS_EHCI: EHCI PCI has not been used on ARM. In fact, it depends on PCI, and moreover we have drivers for several embedded UARTs for various ARM boards. It is probably worth mentioning that NS16550 is still not selectable on x86. Signed-off-by: Stefano Stabellini Acked-by: Julien Grall CC: jbeul...@suse.com CC: andrew.coop...@citrix.com --- Changes in v4: - improve commit message - remove prompt for HAS_EHCI Changes in v3: - NS16550 prompt if ARM Changes in v2: - make HAS_EHCI depend on x86 --- xen/drivers/char/Kconfig | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig index cc78ec3..b1f07f8 100644 --- a/xen/drivers/char/Kconfig +++ b/xen/drivers/char/Kconfig @@ -1,11 +1,11 @@ config HAS_NS16550 - bool + bool "NS16550 UART driver" if ARM default y help This selects the 16550-series UART support. For most systems, say Y. config HAS_CADENCE_UART - bool + bool "Xilinx Cadence UART driver" default y depends on ARM_64 help @@ -13,7 +13,7 @@ config HAS_CADENCE_UART based board, say Y. config HAS_MVEBU - bool + bool "Marvell MVEBU UART driver" default y depends on ARM_64 help @@ -21,7 +21,7 @@ config HAS_MVEBU based board, say Y. config HAS_PL011 - bool + bool "ARM PL011 UART driver" default y depends on ARM help @@ -29,7 +29,7 @@ config HAS_PL011 an Integrator/PP2, Integrator/CP or Versatile platform, say Y. config HAS_EXYNOS4210 - bool + bool "Samsung Exynos 4210 UART driver" default y depends on ARM_32 help @@ -37,7 +37,7 @@ config HAS_EXYNOS4210 Exynos based board, say Y. config HAS_OMAP - bool + bool "Texas Instruments OMAP UART driver" default y depends on ARM_32 help @@ -45,7 +45,7 @@ config HAS_OMAP Instruments based CPU, say Y. config HAS_SCIF - bool + bool "SuperH SCI(F) UART driver" default y depends on ARM help @@ -54,6 +54,7 @@ config HAS_SCIF config HAS_EHCI bool + depends on X86 help This selects the USB based EHCI debug port to be used as a UART. If you have an x86 based system with USB, say Y. -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 07/10] arm: add a tiny kconfig configuration
Hi Stefano, On 04/06/18 18:24, Stefano Stabellini wrote: Add a tiny kconfig configuration. Enabled NULL and Credit schedulers. Support only 8 cpus. It only carries non-default options (use make I don't see where 8 CPUs would only be supported as the default value is 128 cpus. olddefconfig to produce a complete .config file). With all the series I did the following things: 1) copy tiny.config to .config 2) make olddefconfig 3) make menuconfig and select QEMU After 1) the numbers of CPUs are set to 128. After 3) I would expect the number of CPUs to go down to 8. Unfortunately this is not the cases. So your command does not seem to be enough here. Signed-off-by: Stefano Stabellini --- --- xen/arch/arm/configs/tiny.conf | 43 ++ 1 file changed, 43 insertions(+) create mode 100644 xen/arch/arm/configs/tiny.conf diff --git a/xen/arch/arm/configs/tiny.conf b/xen/arch/arm/configs/tiny.conf new file mode 100644 index 000..e9a5e65 --- /dev/null +++ b/xen/arch/arm/configs/tiny.conf @@ -0,0 +1,43 @@ +CONFIG_ARM_64=y This config targets arm64. So I would name it tiny64.conf. +CONFIG_ARM=y + +# +# Architecture Features +# +# CONFIG_GICV3 is not set +# CONFIG_MEM_ACCESS is not set +# CONFIG_SBSA_VUART_CONSOLE is not set + +# +# Common Features +# +# CONFIG_TMEM is not set + +# +# Schedulers +# +# CONFIG_SCHED_CREDIT2 is not set +# CONFIG_SCHED_RTDS is not set +# CONFIG_SCHED_ARINC653 is not set +CONFIG_SCHED_NULL=y +CONFIG_SCHED_NULL_DEFAULT=y +CONFIG_SCHED_DEFAULT="null" +# CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS is not set + +# +# Device Drivers +# +# CONFIG_HAS_NS16550 is not set +# CONFIG_HAS_CADENCE_UART is not set +# CONFIG_HAS_MVEBU is not set +# CONFIG_HAS_PL011 is not set +# CONFIG_HAS_SCIF is not set +# CONFIG_ARM_SMMU is not set + +# +# Debugging Options +# +# CONFIG_DEBUG is not set +# CONFIG_FRAME_POINTER is not set +# CONFIG_VERBOSE_DEBUG is not set +# CONFIG_SCRUB_DEBUG is not set Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 0/10] arm: more kconfig configurability and small default configs
On 04/06/18 18:23, Stefano Stabellini wrote: Hi all, This patch series is the first step toward building a small certifiable Xen hypervisor for ARM boards. First, the series makes a few changes to allow disabling more kconfig options: most of them already exist but cannot be disabled. Then, it introduces a reference kconfig for Renesas RCar (due to popular demand, candidate for certifications), Xilinx MPSoC, and for QEMU aarch64 (not for certifications, but useful for debugging). The last patch in the series adds a convenient cloc target to count the total lines of code of the source files built. As a consequence of these changes, some options will become user-visible and not dependent on CONFIG_EXPERT. It does not mean that Xen Project will security support all possible combinations of kconfig options. Instead, there will be a small set of pre-canned configurations that will be supported. See: https://marc.info/?l=xen-devel&m=152424389512432 George, Ian, Jan, shall SUPPORT.MD be updated to reflect the Kconfig changes? I am mostly thinking about the board support and the fact that more options on Arm are selectable by the users. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 08/10] arm: add ALL, QEMU, Rcar3 and MPSoC configs
Hi Stefano, On 04/06/18 18:24, Stefano Stabellini wrote: Add a "Platform Support" choice with four kconfig options: QEMU, RCAR3, MPSOC and ALL. They enable the required options for their hardware platform. ALL enables all available platforms and it's the default. It doesn't automatically select any of the related drivers, otherwise they cannot be disabled. ALL is implemented by selecting hidden options corresponding to QEMU, MPSOC and RCAR3. In the case of the MPSOC that has a platform file under arch/arm/platforms/, build the file if MPSOC. Signed-off-by: Stefano Stabellini CC: artem_myga...@epam.com CC: volodymyr_babc...@epam.com --- Changes in v5: - turn platform support into a choice - add ALL Changes in v4: - fix GICv3/GICV3 - default y to all options - build xilinx-zynqmp if MPSOC --- xen/arch/arm/Kconfig| 2 ++ xen/arch/arm/platforms/Kconfig | 54 + xen/arch/arm/platforms/Makefile | 2 +- 3 files changed, 57 insertions(+), 1 deletion(-) create mode 100644 xen/arch/arm/platforms/Kconfig diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 2b87111..75cacfb 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -213,6 +213,8 @@ config ARM64_HARDEN_BRANCH_PREDICTOR config ARM32_HARDEN_BRANCH_PREDICTOR def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR +source "arch/arm/platforms/Kconfig" + source "common/Kconfig" source "drivers/Kconfig" diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig new file mode 100644 index 000..8b3bedd --- /dev/null +++ b/xen/arch/arm/platforms/Kconfig @@ -0,0 +1,54 @@ +choice + prompt "Platform Support" + default ALL + ---help--- + Choose which hardware platform to enable in Xen. + + If unsure, choose ALL. + +config ALL + bool "All Platforms" + select MPSOC_PLATFORM + select QEMU_PLATFORM + select RCAR3_PLATFORM + ---help--- + Enable support for all available hardware platforms. This is slightly untrue. A user would be able to disable GICV3 for instance. So hardware such as QEMU would not be supported. So I think you want to clarify the description with something similar to what you wrote in the commit message. The rest looks good to me. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 09/10] xen: add per-platform defaults for NR_CPUS
Hi Stefano, On 04/06/18 18:24, Stefano Stabellini wrote: Add specific per-platform defaults for NR_CPUS. Note that the order of the defaults matter: they need to go first, otherwise the generic defaults will be applied. This is done so that Xen builds customized for a specific hardware platform can have the right NR_CPUS number. Signed-off-by: Stefano Stabellini CC: jbeul...@suse.com CC: andrew.coop...@citrix.com --- xen/arch/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/xen/arch/Kconfig b/xen/arch/Kconfig index cf0acb7..ed8f3d8 100644 --- a/xen/arch/Kconfig +++ b/xen/arch/Kconfig @@ -3,6 +3,10 @@ config NR_CPUS int "Maximum number of physical CPUs" range 1 4095 default "256" if X86 + default "128" if ARM && ALL I would drop this has this is cover by "if ARM" below. + default "8" if ARM && RCAR3 + default "4" if ARM && QEMU + default "4" if ARM && MPSOC default "128" if ARM ---help--- Specifies the maximum number of physical CPUs which Xen will support. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] PROBLEM: xen-netfront: ethtool settings changed in 4.4.134 causing packet loss
When upgrading from 4.4.132 to 4.4.135 I started observing about 3% packet loss on PV on HVM domU interfaces. Specifically TX dropped packets (As reported by ifconfig). It seems that the default ethtool settings have changed. Previously (4.4.132): tx-checksumming: on tx-checksum-ipv4: on [fixed] tx-checksum-ip-generic: off [fixed] tx-checksum-ipv6: on tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off [fixed] scatter-gather: on tx-scatter-gather: on tx-scatter-gather-fraglist: off [fixed] tcp-segmentation-offload: on tx-tcp-segmentation: on tx-tcp-ecn-segmentation: off [fixed] tx-tcp6-segmentation: on udp-fragmentation-offload: off [fixed] generic-segmentation-offload: on Now (4.4.135): tx-checksumming: on tx-checksum-ipv4: on [fixed] tx-checksum-ip-generic: off [fixed] tx-checksum-ipv6: off tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off [fixed] scatter-gather: off tx-scatter-gather: off tx-scatter-gather-fraglist: off [fixed] tcp-segmentation-offload: off tx-tcp-segmentation: off tx-tcp-ecn-segmentation: off [fixed] tx-tcp6-segmentation: off udp-fragmentation-offload: off [fixed] generic-segmentation-offload: off [requested on] Manually running 'ethtool -K INT tso on sg on' on all interfaces stops the packet loss again. They're then set like this: tx-checksumming: on tx-checksum-ipv4: on [fixed] tx-checksum-ip-generic: off [fixed] tx-checksum-ipv6: off tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off [fixed] scatter-gather: on tx-scatter-gather: on tx-scatter-gather-fraglist: off [fixed] tcp-segmentation-offload: on tx-tcp-segmentation: on tx-tcp-ecn-segmentation: off [fixed] tx-tcp6-segmentation: off [requested on] udp-fragmentation-offload: off [fixed] generic-segmentation-offload: on I've traced it to a commit in 4.4.134: 6be4fe832954db3b359b72107a6c60e34d939b26 xen-netfront: Fix race between device setup and open [ Upstream commit f599c64fdf7d9c108e8717fb04bc41c680120da4 ] https://patchwork.kernel.org/patch/10328969/ Once that is reverted on 4.4.135, the ethtool settings are as 4.4.132 and there is no packet loss. The VMs and hypervisor are all running CentOS 7.5. The hypervisor is on the centos-virt provided kernel, and the VMs are using kernel-lt from elrepo. # xl info host : blah release: 4.9.86-30.el7.x86_64 version: #1 SMP Mon Mar 5 16:58:23 UTC 2018 machine: x86_64 nr_cpus: 40 max_cpu_id : 191 nr_nodes : 2 cores_per_socket : 10 threads_per_core : 2 cpu_mhz: 2197 hw_caps: b7ebfbff:77fef3ff:2c100800:0121:0001:001cbfbb::0100 virt_caps : hvm hvm_directio total_memory : 81826 free_memory: 13237 sharing_freed_memory : 0 sharing_used_memory: 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 8 xen_extra : .3-5.el7 xen_version: 4.8.3-5.el7 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params: virt_start=0x8000 xen_changeset : Thu Apr 26 23:28:44 2018 -0700 git:10d7690-dirty xen_commandline: placeholder dom0_mem=4096M,max:4096M cpuinfo com1=115200,8n1 console=com1,tty loglvl=all guest_loglvl=all gnttab_max_frames=1024 cpufreq=none max_cstate=0 cc_compiler: gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28) cc_compile_by : mockbuild cc_compile_domain : centos.org cc_compile_date: Tue May 8 17:17:55 UTC 2018 build_id : 484fda280c1d4a21346da47907cd1a8e9aba99df xend_config_format : 4 Please let me know anything else I can provide. Thanks ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 0/10] arm: more kconfig configurability and small default configs
On 04/06/18 18:23, Stefano Stabellini wrote: Hi all, Hi, This patch series is the first step toward building a small certifiable Xen hypervisor for ARM boards. First, the series makes a few changes to allow disabling more kconfig options: most of them already exist but cannot be disabled. Then, it introduces a reference kconfig for Renesas RCar (due to popular demand, candidate for certifications), Xilinx MPSoC, and for QEMU aarch64 (not for certifications, but useful for debugging). The last patch in the series adds a convenient cloc target to count the total lines of code of the source files built. As a consequence of these changes, some options will become user-visible and not dependent on CONFIG_EXPERT. It does not mean that Xen Project will security support all possible combinations of kconfig options. Instead, there will be a small set of pre-canned configurations that will be supported. See: https://marc.info/?l=xen-devel&m=152424389512432 Cheers, Stefano Stefano Stabellini (10): arm: remove the ARM HDLCD driver I have merged this patch in my next branch. I will wait the answer about SUPPORT.MD before merging the other acked patch. Cheers, arm: make it possible to disable HAS_GICV3 arm: rename HAS_GICV3 to GICV3 Make MEM_ACCESS configurable make it possible to enable/disable UART drivers arm: make it possible to disable the SMMU driver arm: add a tiny kconfig configuration arm: add ALL, QEMU, Rcar3 and MPSoC configs xen: add per-platform defaults for NR_CPUS xen: add cloc target tools/firmware/xen-dir/shim.config | 2 +- xen/Makefile | 12 ++ xen/arch/Kconfig | 4 + xen/arch/arm/Kconfig | 17 +- xen/arch/arm/Makefile| 4 +- xen/arch/arm/configs/tiny.conf | 43 + xen/arch/arm/platforms/Kconfig | 54 ++ xen/arch/arm/platforms/Makefile | 2 +- xen/arch/arm/platforms/vexpress.c| 35 xen/arch/arm/vgic.c | 2 +- xen/arch/arm/vgic/vgic.c | 2 +- xen/arch/x86/Kconfig | 2 +- xen/common/Kconfig | 10 +- xen/common/Makefile | 2 +- xen/common/domctl.c | 2 +- xen/drivers/char/Kconfig | 15 +- xen/drivers/passthrough/Kconfig | 12 ++ xen/drivers/passthrough/arm/Makefile | 2 +- xen/drivers/video/Kconfig| 3 - xen/drivers/video/Makefile | 1 - xen/drivers/video/arm_hdlcd.c| 281 --- xen/include/asm-arm/gic.h| 4 +- xen/include/asm-arm/platforms/vexpress.h | 6 - xen/include/asm-arm/vgic.h | 4 +- xen/include/xen/mem_access.h | 4 +- xen/include/xsm/dummy.h | 2 +- xen/include/xsm/xsm.h| 4 +- xen/xsm/dummy.c | 2 +- xen/xsm/flask/hooks.c| 4 +- 29 files changed, 175 insertions(+), 362 deletions(-) create mode 100644 xen/arch/arm/configs/tiny.conf create mode 100644 xen/arch/arm/platforms/Kconfig delete mode 100644 xen/drivers/video/arm_hdlcd.c -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 01/10] xen/arm64: Added handling of the trapped access to OSLSR register
On 05/06/18 18:24, Julien Grall wrote: Hi Mirela, On 01/06/18 14:17, Mirela Simonovic wrote: Linux/dom0 accesses OSLSR register when saving CPU context during the suspend procedure. Xen traps access to this register, but has no handling for it. Consequently, Xen injects undef exception to linux, causing it to crash. This patch adds handling of the trapped access to OSLSR as read only as a fixed value. Can you please mention that you introduced handle_ro_read_val() and rework handle_ro_raz()? Signed-off-by: Mirela Simonovic Reviewed-by: Stefano Stabellini Acked-by: Julien Grall The reviewed-by/acked-by tags should only be kept when there are minor changes in the code (and the reviewer is happy with them). This is very important for the former as the tag means the reviewer read your code and confirm this is correct. As you change quite a bit the patch, those 2 tags should have been removed. Stefano, are you still happy with the Reviewed-by? Stefano mentioned on IRC he was happy with the reviewed-by kept. I will go ahead with merging the series. For this patch, I will add the following in the commit message: "For convenience, introduce a new helper handle_ro_read_val() based on handle_ro_raz() that will return a specified value on read and re-implement handle_ro_raz() based on the new helper". Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 123811: all pass - PUSHED
flight 123811 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/123811/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 0b6457efabf6f47bc55690874dde82d2f8616abc baseline version: ovmf 38c977c148e92e2af17c5d346d9b4b2e7a18680a Last test of basis 123791 2018-06-04 05:40:24 Z1 days Testing same since 123811 2018-06-05 02:42:48 Z0 days1 attempts People who touched revisions under test: Long Qin 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 38c977c148..0b6457efab 0b6457efabf6f47bc55690874dde82d2f8616abc -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.11] scripts/add_maintainers.pl: Don't call get_maintainers.pl with -f
On 05/06/18 18:39, Julien Grall wrote: > The option -f of scripts/get_maintainers.pl will return the maintainers > of a given file, *not* the list of maintainers if the file was a patch. > > The output expected of add_maintainers is the latter, so drop the option > -f. > > Signed-off-by: Julien Grall Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 00/10] xen/arm64: Suspend preconditions and CPU hotplug fixes
Hi, Thank you for the series. I have pushed the series in a branch "next" and will merge it once Xen 4.11 has been released. One thing that has not been handled in this series is moving the interrupts used by Xen (e.g UART, SMMU...) away from the core that is powerdown. This is required by the PSCI-spec (see 5.5 in DEN0022C) to avoid errorneous state. I think this will be quite critical for suspend/resume as we want the wake-up even to happen on CPU0 (the one who called PSCI_suspend). Cheers, On 01/06/18 14:17, Mirela Simonovic wrote: This patch set contains fixes that are required as precondition for suspend to RAM support, including the CPU hotplug which is required to suspend non-boot CPUs. The first two patches in this series: 1) xen/arm64: Added handling of the trapped access to OSLSR register 2) xen/arm: Ignore write to GICD_ISACTIVERn registers (vgic-v2) are required to avoid Dom0 crashes when Dom0 performs its own suspend. This patch set does not include the implementation of virtual PSCI system suspend call that would allow guests to finalize their suspend procedures. This will be submitted in the following series. Remaining of the patches are related to enabling CPU hotplug for non-boot CPUs is resume scenario. CPU hotplug of non-boot CPUs will be used for suspend to RAM support for ARM. In suspend procedure, the hot-unplug of non-boot CPUs will be triggered with disable_nonboot_cpus(), while the hotplug is triggered with enable_nonboot_cpus(). Using these calls, the physical non-boot CPUs could be powered down/up on suspend/resume, respectively, if the underlying firmware allows so. Calls to enable/disable_nonboot_cpus() functions currently do not exist in Xen ARM code. This will be added with the suspend to RAM support for ARM. When non-boot pCPUs are hot-unplugged their interrupts are migrated to the boot pCPU. This series also includes a fix that would restore the interrupts affinity once non-boot pCPUs are hotplugged. Here only SPIs used by guests are covered. Migration of Xen internal SPIs is not covered. According to my understanding Xen internal SPIs are routed to the boot CPU which initializes the respective devices. Therefore, there is no need to migrate Xen internal SPIs. The code is tested on Xilinx Zynq UltraScale+ MPSoC/ZCU102 board (includes physical power down/up of non-boot CPUs). The testing requires additional patches for issuing system suspend. These patches and instructions for testing will be submitted later, when we get closer to the final version of the series. --- Changes in v2: -Rename cover-letter title and emphasize that 2 patches from this series are not specific to CPU hotplug (my initial fault, splitting it now could be confusing) -Fix cover-letter explanations -Address all the issues and comments as discussed on mailing list for v1 -Add 3 patches to ensure that suspend/resume does not cause any memory leaks. All the memory allocated when a CPU was hotplugged is now freed when the CPU is hot-unplugged. -Remove from the v1 series the patch which incorrectly dealt with an issue: [PATCH 4/7] xen/arm: When CPU dies, free percpu area immediatelly One solution to the issue addressed by the patch above is to add rcu_barrier() prior to calling enable_nonboot_cpus() during the suspend. This is how it is done in x86 suspend implementation. Until the discussion here https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg01199.html doesn't conclude differently, I need to assume that adding rcu_barrier() prior to calling enable_nonboot_cpus() as it is done for x86 is the right way to go. Therefore, the fix to the issue will be part of the suspend to RAM series. Changes in v3: -Add acked-by where needed -Fix CPU_OFF PSCI implementation (physical interface) -Use notifiers to implement freeing memory and releasing interrupts on CPU hotplug -Use notifier to trigger setup of virtual paging for non-boot CPUs on CPU hotplug -Add enabling errata workarounds on CPU hotplug, also based on a notifier -Remove patch: [PATCH v2 10/10] xen/arm: Call check_local_cpu_errata for secondary CPU only on boot Changes in v4: -Add acked-by/reviewed-by where needed -Cleanup: use smp_processor_id() instead of get_processor_id(), fixed indentation, add includes alphabetically, add newline before return, etc. -Disable timers prior to releasing timer interrupts -Initialize cpu_smpboot notifier at presmp_init rather than init phase -In the last patch of the series errata notifier now returns an error Changes in v5: -Introduce handle_ro_read_val() to handle traps as read-only as fixed value -Fix handling accesses to OSLSR_EL1 -Fix variable type in 5th patch --- CC: Stefano Stabellini CC: Julien Grall CC: George Dunlap CC: Dario Faggioli --- Mirela Simonovic (10): xen/arm64: Added handling of the trapped access to OSLSR register xen/arm: Ignore write to GICD_ISACTIVERn registers (vgic-v2) xen/arm: Implement CPU_OFF PSCI call (physical interface) xen/arm: Remo
Re: [Xen-devel] [PATCH for-4.11] scripts/add_maintainers.pl: Don't call get_maintainers.pl with -f
On 05/06/2018, 19:15, "Juergen Gross" wrote: On 05/06/18 18:39, Julien Grall wrote: > The option -f of scripts/get_maintainers.pl will return the maintainers > of a given file, *not* the list of maintainers if the file was a patch. > > The output expected of add_maintainers is the latter, so drop the option > -f. > > Signed-off-by: Julien Grall Release-acked-by: Juergen Gross Reviewed-by: lars.ku...@citrix.com This change in behaviour was mistakenly introduced in one of the later revisions (can't recall which), when we refactored the call to get_maintainers.pl Lars ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.1 baseline-only test] 74766: tolerable FAIL
This run is configured for baseline tests only. flight 74766 linux-4.1 real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74766/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win10-i386 10 windows-install fail baseline untested test-armhf-armhf-libvirt 14 saverestore-support-check fail baseline untested test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail baseline untested test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail baseline untested test-amd64-i386-xl-qemut-debianhvm-amd64 15 guest-saverestore.2 fail baseline untested test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail baseline untested test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail baseline untested test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail baseline untested test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail baseline untested test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail baseline untested test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail baseline untested test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 13 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-win10-i386 17 guest-stop fail never pass version targeted for testing: linuxc4ff7514e71ddb85d05f262cd40f841f494775c8 baseline version: linux2d61e08a1024d0cf15c26889285004e46c9f0b14 Last test of basis74485 2018-04-05 12:20:42 Z 61 days Testing same since74766 2018-05-31 04:54:18 Z5 days1 attempts 516 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-armhf-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
[Xen-devel] [xen-unstable test] 123799: trouble: broken/fail/pass
flight 123799 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/123799/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-5 broken Tests which are failing intermittently (not blocking): test-xtf-amd64-amd64-54 host-install(4) broken pass in 123670 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 123670 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 123670 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 123670 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 123670 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 123670 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 123670 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 123670 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 123670 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 123670 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 123670 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-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-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-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-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-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail 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 06f542f8f2e446c01bd0edab51e9450af7f6e05b baseline version: xen 06f542f8f2e446c01bd0edab51e9450af7f6e05b Last test of basis 123799 2018-06-04 11:02:20 Z1 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm
Re: [Xen-devel] [xen-unstable test] 123799: trouble: broken/fail/pass
On 05/06/2018 21:28, osstest service owner wrote: > flight 123799 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/123799/ > > Failures and problems with tests :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-xtf-amd64-amd64-5 broken > > Tests which are failing intermittently (not blocking): > test-xtf-amd64-amd64-54 host-install(4) broken pass in > 123670 Erm - something is very wonky here. At the point that this test thinks it failed to install, there was a different set of going on on the machine. The machine very definitely wasn't in the middle of being installed. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline baseline-only test] 74765: regressions - FAIL
This run is configured for baseline tests only. flight 74765 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74765/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-multivcpu 20 guest-start/debian.repeat fail REGR. vs. 74638 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail blocked in 74638 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail like 74638 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail like 74638 test-armhf-armhf-libvirt 12 guest-start fail like 74638 test-armhf-armhf-xl-credit2 12 guest-start fail like 74638 test-armhf-armhf-libvirt-xsm 12 guest-start fail like 74638 test-armhf-armhf-xl-midway 12 guest-start fail like 74638 test-armhf-armhf-xl-xsm 12 guest-start fail like 74638 test-armhf-armhf-xl-multivcpu 12 guest-start fail like 74638 test-armhf-armhf-xl-rtds 12 guest-start fail like 74638 test-armhf-armhf-xl 12 guest-start fail like 74638 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 74638 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail like 74638 test-armhf-armhf-xl-vhd 10 debian-di-installfail like 74638 test-armhf-armhf-libvirt-raw 10 debian-di-installfail like 74638 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-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass version targeted for testing: qemuue609fa71e89c81fbe2670411be62da95dfb093e0 baseline version: qemuu27e757e29cc79f3f104d2a84d17cdb3b4c11c8ff Last test of basis74638 2018-04-24 11:46:01 Z 42 days Testing same since74765 2018-05-31 00:25:29 Z5 days1 attempts People who touched revisions under test: Aaron Lindsay Abdallah Bouassida Alberto Garcia Alex Bennée Alexey Kardashevskiy Alexey Perevalov Alistair Francis Andrew Morton Andy Whitcroft Anthony PERARD Babu Moger BALATON Zoltan Bandan Das Bastian Koppelmann Bharat Bhushan Bharata B Rao Boqun Feng Changpeng Liu Christian Borntraeger Christophe Lyon Claudio Imbrenda Collin Walling Cornelia Huck Cédric Le Goater Cédric Le Goater Daniel Henrique Barboza Daniel P. Berrangé Daniel P. Berrangé David Gibson David Hildenbrand Dr. David Alan Gilbert Edgar E. Iglesias Eduardo Habkost Elie Tournier Elie Tournier Emilio G. Cota Eric Auger Eric Blake Fam Zheng Francisco Iglesias Geert Uytterhoeven Geoffrey McRae Gerd Hoffmann Greg Kurz Halil Pasic Henry Wertz Ian Jackson Igor Druzhinin Igor Mammedov Jakub Jelen Jan Kiszka Jason Andryuk Jason Wang Jeff Cody Jie Wang Jingqi Liu Jintack Lim Joe Perches John Snow John Thomson Jonathan Helman Juan Quintela Kevin Wolf KONRAD Frederic Konrad Rzeszutek Wilk Laszlo Ersek Laurent Vivier Laurent Vivier Lidong Chen Lidong Chen Linus Torvalds Marc-André Lureau Marcel Apfelbaum Marcel Apfelbaum Mark Cave-Ayland Markus Armbruster Mathew Maidment Max Filippov Max Reitz Michael Clark Michael Matz Michael S. Tsirkin Michael Tokarev Michael Walle Michal Privoznik Murilo Opsfelder Araujo Olaf Hering Palmer Dabbelt Paolo Bonzini Pasi Savanainen Patrick Oppenlander Paul Durrant Pavel Dovgalyuk Peter Maydell Peter Wu Peter Xu Petr Tesarik Philippe Mathieu-Daudé Prem Mallappa Richard Henderson Richard Henderson Roman Kagan Ross Lagerwall Ross Zwisler Sai Pavan Boddu Sai Pavan Boddu Serhii Popovych Stafford Hor
[Xen-devel] [libvirt test] 123814: tolerable all pass - PUSHED
flight 123814 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/123814/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 123575 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 123575 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 123575 test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 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-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass version targeted for testing: libvirt 076a2b409667dd9f716a2a2085e1ffea9d58fe8b baseline version: libvirt e36b1f6583324133405c7f4552a9da51e6c61161 Last test of basis 123575 2018-06-01 18:49:37 Z4 days Testing same since 123814 2018-06-05 04:19:23 Z0 days1 attempts People who touched revisions under test: Daniel Veillard Jim Fehlig Jiri Denemark Ján Tomko Martin Kletzander jobs: build-amd64-xsm pass build-arm64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summ
[Xen-devel] [xen-4.7-testing baseline-only test] 74747: trouble: broken/fail/pass
This run is configured for baseline tests only. flight 74747 xen-4.7-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74747/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-raw broken test-armhf-armhf-libvirt-raw 4 host-install(4) broken REGR. vs. 74570 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail like 74570 test-armhf-armhf-libvirt 12 guest-start fail like 74570 test-armhf-armhf-libvirt-xsm 12 guest-start fail like 74570 test-armhf-armhf-xl 12 guest-start fail like 74570 test-armhf-armhf-xl-credit2 12 guest-start fail like 74570 test-armhf-armhf-xl-midway 12 guest-start fail like 74570 test-armhf-armhf-xl-multivcpu 12 guest-start fail like 74570 test-armhf-armhf-xl-xsm 12 guest-start fail like 74570 test-armhf-armhf-xl-rtds 12 guest-start fail like 74570 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail like 74570 test-armhf-armhf-xl-vhd 10 debian-di-installfail like 74570 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail 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-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-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-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen ce22cc35df523db025983f303c201d9cef6179db baseline version: xen 9680710bed1c174ced7a170cb94e30b4ae4fff5e Last test of basis74570 2018-04-10 07:18:24 Z 56 days Testing same since74747 2018-05-25 23:49:01 Z 10 days1 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Ian Jackson Jan Beulich Juergen Gross Kevin Tian Roger Pau Monné Sergey Dyasli Wei Liu Xen Project Security Team jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumprun pass build-i386-rumprun pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5
[Xen-devel] [xen-4.9-testing test] 123801: regressions - FAIL
flight 123801 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/123801/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-migrupgrade 10 xen-boot/src_hostfail REGR. vs. 123122 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-ws16-amd64 14 guest-localmigrate fail in 123590 pass in 123801 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail in 123676 pass in 123473 test-armhf-armhf-xl 6 xen-install fail in 123676 pass in 123801 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat fail in 123676 pass in 123801 test-armhf-armhf-xl-rtds 12 guest-start fail in 123676 pass in 123801 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail pass in 123590 test-amd64-i386-xl-qemut-win7-amd64 13 guest-saverestore fail pass in 123676 test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail pass in 123676 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-ws16-amd64 18 guest-start/win.repeat fail in 123473 like 122960 test-amd64-i386-xl-qemut-ws16-amd64 18 guest-start/win.repeat fail in 123473 like 123122 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail in 123590 like 123122 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 123590 like 123122 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail in 123676 like 122960 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 123676 like 123122 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122960 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail like 123009 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 123009 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 123122 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 123122 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 123122 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 123122 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-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 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-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-ar
[Xen-devel] [xen-4.9-testing baseline-only test] 74746: regressions - FAIL
This run is configured for baseline tests only. flight 74746 xen-4.9-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74746/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail REGR. vs. 74654 test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-saverestore.2 fail REGR. vs. 74654 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail REGR. vs. 74654 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 74654 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 74654 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail REGR. vs. 74654 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail blocked in 74654 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail like 74654 test-armhf-armhf-libvirt 12 guest-start fail like 74654 test-armhf-armhf-xl-multivcpu 12 guest-start fail like 74654 test-armhf-armhf-xl 12 guest-start fail like 74654 test-armhf-armhf-xl-xsm 12 guest-start fail like 74654 test-armhf-armhf-libvirt-xsm 12 guest-start fail like 74654 test-armhf-armhf-xl-credit2 12 guest-start fail like 74654 test-armhf-armhf-xl-midway 12 guest-start fail like 74654 test-armhf-armhf-xl-rtds 12 guest-start fail like 74654 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail like 74654 test-armhf-armhf-xl-vhd 10 debian-di-installfail like 74654 test-armhf-armhf-libvirt-raw 10 debian-di-installfail like 74654 test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-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-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 74fa9552c1e3ef79bd4db0a67fc538bbd61b7561 baseline version: xen 7866e115f9c624b0669997fcc393b489ef3c38a2 Last test of basis74654 2018-04-30 22:16:54 Z 36 days Testing same since74746 2018-05-25 13:16:23 Z 11 days1 attempts People who touched revisions under test: Andrew Cooper David Wang George Dunlap Jan Beulich Juergen Gross Olaf Hering Paul Durrant Roger Pau Monné Xen Project Security Team jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumprun pass build-i386-rumprun pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf
[Xen-devel] [linux-3.18 test] 123803: regressions - FAIL
flight 123803 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/123803/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 6 xen-buildfail REGR. vs. 123274 build-i386-libvirt6 libvirt-build fail in 123594 REGR. vs. 123274 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-xsm 7 xen-boot fail in 123594 pass in 123803 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 123683 pass in 123594 test-armhf-armhf-xl-xsm8 host-ping-check-xen fail in 123683 pass in 123803 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail pass in 123683 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 1 build-check(1) blocked in 123594 n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked in 123594 n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 123594 n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked in 123594 n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-examine 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail in 123683 like 123274 test-armhf-armhf-libvirt 14 saverestore-support-check fail in 123683 like 123274 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 123683 like 123274 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 123683 never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 123683 never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail in 123683 never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail in 123683 never pass test-armhf-armhf-xl-rtds13 migrate-support-check fail in 123683 never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail in 123683 never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 123683 never pass test-armhf-armhf-xl 13 migrate-support-check fail in 123683 never pass test-armhf-armhf-xl 14 saverestore-support-check fail in 123683 never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail in 123683 never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail in 123683 never pass test-armhf-armhf-libvirt13 migrate-support-check fail in 123683 never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 123683 never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 123683 never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 123683 never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail in 123683 never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail in 123683 never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 123274 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 123274 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 123274 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 123274 build-arm64-pvops 6 kernel-build fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail 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-amd64-libvirt 13 migrate-support-c
[Xen-devel] [ovmf baseline-only test] 74783: all pass
This run is configured for baseline tests only. flight 74783 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74783/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 0b6457efabf6f47bc55690874dde82d2f8616abc baseline version: ovmf 38c977c148e92e2af17c5d346d9b4b2e7a18680a Last test of basis74780 2018-06-04 21:48:27 Z1 days Testing same since74783 2018-06-05 18:27:36 Z0 days1 attempts People who touched revisions under test: Long Qin 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.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 0b6457efabf6f47bc55690874dde82d2f8616abc Author: Long Qin Date: Thu May 24 16:08:51 2018 +0800 CryptoPkg: Remove deprecated function usage in X509GetCommonName() BZ#: https://bugzilla.tianocore.org/show_bug.cgi?id=923 X509_NAME_get_text_by_NID() used in X509GetCommonName() implementation is one legacy function which have various limitations. The returned data may be not usable when the target cert contains multicharacter string type like a BMPString or a UTF8String. This patch replaced the legacy function usage with more general X509_NAME_get_index_by_NID() / X509_NAME_get_entry() APIs for X509 CommonName retrieving. Tests: Validated the commonName retrieving with test certificates containing PrintableString or BMPString data. Cc: Ye Ting Cc: Michael Turner Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Long Qin Reviewed-by: Ye Ting ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [Xen-20] Clearing of GICD_ICACTIVER register at boot time.
From: Chaitanya Deshpande
Signed-off-by: Chaitanya Deshpande
---
xen/arch/arm/gic-v2.c| 6 +-
xen/arch/arm/gic-v3.c| 5 +
xen/arch/arm/vgic-v2.c | 5 +
xen/arch/arm/vgic-v3.c | 5 +
xen/arch/arm/vgic/vgic-mmio-v2.c | 5 +
5 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index d2dcafb..6bd7e43 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -5,7 +5,6 @@
*
* Tim Deegan
* Copyright (c) 2011 Citrix Systems.
- *
* 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
@@ -1247,6 +1246,11 @@ static int __init gicv2_init(void)
{
uint32_t aliased_offset = 0;
+/* Clear GIC register at boot time */
+uint32_t *gicd_icactiver;
+gicd_icactiver = (uint32_t*) GICD_ICACTIVER;
+*gicd_icactiver = 0;
+
if ( acpi_disabled )
gicv2_dt_init();
else
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index b2ed0f8..f61d2b3 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1738,6 +1738,11 @@ static int __init gicv3_init(void)
uint32_t reg;
unsigned int intid_bits;
+/* Clear GIC register at boot time */
+uint32_t *gicd_icactiver;
+gicd_icactiver = (uint32_t*) GICD_ICACTIVER;
+*gicd_icactiver = 0;
+
if ( !cpu_has_gicv3 )
{
dprintk(XENLOG_ERR, "GICv3: driver requires system register
support\n");
diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 646d1f3..d8b2761 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -727,6 +727,11 @@ static const struct vgic_ops vgic_v2_ops = {
int vgic_v2_init(struct domain *d, int *mmio_count)
{
+/* Clear GIC register at boot time */
+uint32_t *gicd_icactiver;
+gicd_icactiver = (uint32_t*) GICD_ICACTIVER;
+*gicd_icactiver = 0;
+
if ( !vgic_v2_hw.enabled )
{
printk(XENLOG_G_ERR
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 4b42739..6fe0dac 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1791,6 +1791,11 @@ static const struct vgic_ops v3_ops = {
int vgic_v3_init(struct domain *d, int *mmio_count)
{
+/* Clear GIC register at boot time */
+uint32_t *gicd_icactiver;
+gicd_icactiver = (uint32_t*) GICD_ICACTIVER;
+*gicd_icactiver = 0;
+
if ( !vgic_v3_hw.enabled )
{
printk(XENLOG_G_ERR
diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c b/xen/arch/arm/vgic/vgic-mmio-v2.c
index 2e507b1..863b4d6 100644
--- a/xen/arch/arm/vgic/vgic-mmio-v2.c
+++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
@@ -305,6 +305,11 @@ static const struct vgic_register_region
vgic_v2_dist_registers[] = {
unsigned int vgic_v2_init_dist_iodev(struct vgic_io_device *dev)
{
+/* Clear GIC register at boot time */
+uint32_t *gicd_icactiver;
+gicd_icactiver = (uint32_t*) GICD_ICACTIVER;
+*gicd_icactiver = 0;
+
dev->regions = vgic_v2_dist_registers;
dev->nr_regions = ARRAY_SIZE(vgic_v2_dist_registers);
--
2.7.4
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
