Re: [Xen-devel] [XEN PATCH] xen/arch/x86/Makefile: Remove $(guard) use from $(TARGET).efi target
On 19.11.2019 18:58, Anthony PERARD wrote:
> Following the patch 65d104984c04 ("x86: fix race to build
> arch/x86/efi/relocs-dummy.o"), the error message
> nm: 'efi/relocs-dummy.o': No such file"
> started to appear on system which can't build the .efi target. This is
> because relocs-dummy.o isn't built anymore.
> The error is printed by the evaluation of VIRT_BASE and ALT_BASE which
> aren't use anyway.
>
> But, we don't need that file as we don't want to build `$(TARGET).efi'
> anyway. On such system, $(guard) evaluate to the shell builtin ':',
> which prevent any of the shell commands in `$(TARGET).efi' from been
> executed.
>
> Even if $(guard) is evaluated opon use, it depends on $(XEN_BUILD_PE)
> which is evaluated at the assignment. So, we can replace $(guard) in
> $(TARGET).efi by having two different rules depending on
> $(XEN_BUILD_PE) instead.
>
> The change with this patch is that none of the dependency of
> $(TARGET).efi will be built if the linker doesn't support PE
> and VIRT_BASE and ALT_BASE don't get evaluated anymore, so nm will not
> complain about the missing relocs-dummy.o file anymore.
>
> Since prelink-efi.o isn't built on system that can't build
> $(TARGET).efi anymore, we can remove the $(guard) variable everywhere.
And indeed the need for it had disappeared with 18cd4997d2 ("x86/efi:
move the logic to detect PE build support").
> Reported-by: Jan Beulich
> Signed-off-by: Anthony PERARD
Reviewed-by: Jan Beulich
Also Cc-ing Jürgen, as this addresses a (cosmetic) regression from
65d104984c ("x86: fix race to build arch/x86/efi/relocs-dummy.o").
> @@ -178,8 +178,6 @@ CFLAGS-$(XEN_BUILD_EFI) += -DXEN_BUILD_EFI
>
> $(TARGET).efi: VIRT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A
> VIRT_START$$,,p')
> $(TARGET).efi: ALT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A
> ALT_START$$,,p')
> -# Don't use $(wildcard ...) here - at least make 3.80 expands this too early!
> -$(TARGET).efi: guard = $(if $(filter y,$(XEN_BUILD_PE)),,:)
It is particularly telling that the comment here had been stale
as of that earlier change from Roger, as the (shell level)
wildcard use was the whole reason for needing $(guard) here.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13] x86/cpuid: Fix Lisbon/Magny-Cours Opterons WRT SSSE3/SSE4A
On 19.11.2019 18:00, Andrew Cooper wrote: > c/s ff66ccefe5 "x86/CPUID: adjust SSEn dependencies" made SSE4A depend on > SSSE3, but these processors really do have have SSE4A without SSSE3. > > This manifests as an upgrade regression, as the SSE4A feature disappears from > view. > > Adjust the SSE4A feature to depend on SSE3 rather than SSSE3. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Nevertheless a remark: > --- a/xen/tools/gen-cpuid.py > +++ b/xen/tools/gen-cpuid.py > @@ -205,9 +205,10 @@ def crunch_numbers(state): > # than to SSE. > SSE2: [SSE3, LM, AESNI, PCLMULQDQ, SHA, GFNI], > > -# Other SSEn each depend on their predecessor versions. > -SSE3: [SSSE3], > -SSSE3: [SSE4_1, SSE4A], > +# Other SSEn each depend on their predecessor versions. AMD > +# Lisbon/Magny-Cours processors implemented SSE4A without SSSE3. > +SSE3: [SSSE3, SSE4A], > +SSSE3: [SSE4_1], > SSE4_1: [SSE4_2], If we'd be taking the SDM by the word, this would still be too restrictive. I suppose though it's been more a copy-and-paste effect that has lead to: "Before an application attempts to use the SIMD subset of SSE3 extensions, the application should follow the steps illustrated in Section 11.6.2, “Checking for SSE/SSE2 Support.” Next, use the additional step provided below: • Check that the processor supports the SIMD and x87 SSE3 extensions (if CPUID.01H:ECX.SSE3[bit 0] = 1)." "Before an application attempts to use the SSSE3 extensions, the application should follow the steps illustrated in Section 11.6.2, “Checking for SSE/SSE2 Support.” Next, use the additional step provided below: • Check that the processor supports SSSE3 (if CPUID.01H:ECX.SSSE3[bit 9] = 1)." Which would imply SSSE3 only takes SSE2 (and implicitly SSE) as prereq. As opposed: "Before an application attempts to use SSE4.1 instructions, the application should follow the steps illustrated in Section 11.6.2, “Checking for SSE/SSE2 Support.” Next, use the additional step provided below: Check that the processor supports SSE4.1 (if CPUID.01H:ECX.SSE4_1[bit 19] = 1), SSE3 (if CPUID.01H:ECX.SSE3[bit 0] = 1), and SSSE3 (if CPUID.01H:ECX.SSSE3[bit 9] = 1)." Similar text is there for for SSE4.2, taking additionally SSE4.1 as prereq. I'll fire off an email to Intel requesting clarification. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Ping: [PATCH 0/2] x86/Xen/32: xen_iret_crit_fixup adjustments
On 20.11.2019 03:39, Boris Ostrovsky wrote:
> On 11/19/19 9:17 PM, Boris Ostrovsky wrote:
>> On 11/19/19 12:50 PM, Boris Ostrovsky wrote:
>>> On 11/19/19 7:58 AM, Jan Beulich wrote:
On 11.11.2019 15:30, Jan Beulich wrote:
> The first patch here fixes another regression from 3c88c692c287
> ("x86/stackframe/32: Provide consistent pt_regs"), besides the
> one already addressed by
> https://lists.xenproject.org/archives/html/xen-devel/2019-10/msg01988.html.
> The second patch is a minimal bit of cleanup on top.
>
> 1: make xen_iret_crit_fixup independent of frame layout
> 2: simplify xen_iret_crit_fixup's ring check
Seeing that the other regression fix has been taken into -tip,
what is the situation here? Should 5.4 really ship with this
still unfixed?
>>> I am still unable to boot a 32-bit guest with those patches, crashing in
>>> int3_exception_notify with regs->sp zero.
>>>
>>> When I revert to 3c88c692c287 the guest actually boots so my (?) problem
>>> was introduced somewhere in-between.
>> Nevermind this. I didn't read your patches correctly.
>
> BTW, I'd rather this not go into 5.4 this late. 3c88c692c287 has been
> there since 5.2 and noone complained.
Afaict the issues were introduced in 5.3, and my first patch (including
a note [complaint if you will] of the second issue) was sent around
5.4-rc2. This has been blocking osstest's linux-linus forever since, so
even without my mail everyone could have been aware by paying attention
to the flight reports (the bisection ones, unfortunately, are pretty
useless here, as in cases like this one they seem to tend to point at
huge merge commits).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Ping: [PATCH 0/2] x86/Xen/32: xen_iret_crit_fixup adjustments
On 19.11.2019 18:50, Boris Ostrovsky wrote:
> On 11/19/19 7:58 AM, Jan Beulich wrote:
>> On 11.11.2019 15:30, Jan Beulich wrote:
>>> The first patch here fixes another regression from 3c88c692c287
>>> ("x86/stackframe/32: Provide consistent pt_regs"), besides the
>>> one already addressed by
>>> https://lists.xenproject.org/archives/html/xen-devel/2019-10/msg01988.html.
>>> The second patch is a minimal bit of cleanup on top.
>>>
>>> 1: make xen_iret_crit_fixup independent of frame layout
>>> 2: simplify xen_iret_crit_fixup's ring check
>> Seeing that the other regression fix has been taken into -tip,
>> what is the situation here? Should 5.4 really ship with this
>> still unfixed?
>
>
> I am still unable to boot a 32-bit guest with those patches, crashing in
> int3_exception_notify with regs->sp zero.
>
> When I revert to 3c88c692c287 the guest actually boots so my (?) problem
> was introduced somewhere in-between.
In order to even get as far as the patches here taking effect
you first need "x86/stackframe/32: repair 32-bit Xen PV" (which
is what "the other regression fix" in my ping refers to).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 144209: tolerable FAIL - PUSHED
flight 144209 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/144209/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 144197 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 144197 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 144197 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 144197 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 144197 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 144197 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 144197 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-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-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 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 version targeted for testing: qemuu6e5d4999c761ffa082f60d72a14e5c953515b417 baseline version: qemuu369e8f5bbd8a5301bde6fae22b93fe9288c552a5 Last test of basis 144197 2019-11-18 11:36:46 Z1 days Failing since144202 2019-11-18 23:36:52 Z1 days2 attempts Testing same since 144209 2019-11-19 15:02:51 Z0 days1 attempts People who touched revisions under test: Alex Williamson Alexey Kardashevskiy Andrey Shinkevich David Gibson Eric Blake Gerd Hoffmann Greg Kurz Jens Freimann Jiri Denemark Kevin Wolf Laurent Vivier Laurent Vivier Michal Privoznik Paolo Bonzini Peter Krempa Peter Maydell Vladimir Sementsov-Ogievskiy Wolfgang Bumiller jobs: build-amd64-xsm
Re: [Xen-devel] [PATCH for-4.13 0/3] Fix PV shim ballooning problems
On 01.11.19 21:24, Andrew Cooper wrote: I decided to dust off my early CPUID adjustments work in an effort to get patch 3 in a sensible state for 4.13. Ever so slightly RFC for 4.13 given where we are in the release, but this is fairly self contained. Andrew Cooper (2): x86/boot: Remove cached CPUID data from the trampoline x86/boot: Cache cpu_has_hypervisor very early on boot Sergey Dyasli (1): x86/e820: fix 640k - 1M region reservation logic xen/arch/x86/apic.c | 2 +- xen/arch/x86/boot/head.S| 13 +++-- xen/arch/x86/boot/trampoline.S | 13 + xen/arch/x86/boot/wakeup.S | 13 ++--- xen/arch/x86/cpu/common.c | 3 --- xen/arch/x86/cpu/intel.c| 1 + xen/arch/x86/e820.c | 4 ++-- xen/arch/x86/efi/efi-boot.h | 12 xen/arch/x86/guest/xen.c| 6 +- xen/arch/x86/mm.c | 3 +-- xen/include/asm-x86/processor.h | 2 +- 11 files changed, 33 insertions(+), 39 deletions(-) For the series: Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.12-testing test] 144207: regressions - FAIL
flight 144207 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/144207/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 144035 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail in 144201 pass in 144207 test-amd64-amd64-livepatch7 xen-boot fail pass in 144201 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 144007 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-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-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-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-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 0138da196c8c334589a25144d4d69bf6553e2658 baseline version: xen 278e46ae8f99485915ae662e7905c8333a55048a Last test of basis 144035 2019-11-12 00:36:50 Z8
Re: [Xen-devel] Ping: [PATCH 0/2] x86/Xen/32: xen_iret_crit_fixup adjustments
On 11/19/19 9:17 PM, Boris Ostrovsky wrote:
> On 11/19/19 12:50 PM, Boris Ostrovsky wrote:
>> On 11/19/19 7:58 AM, Jan Beulich wrote:
>>> On 11.11.2019 15:30, Jan Beulich wrote:
The first patch here fixes another regression from 3c88c692c287
("x86/stackframe/32: Provide consistent pt_regs"), besides the
one already addressed by
https://lists.xenproject.org/archives/html/xen-devel/2019-10/msg01988.html.
The second patch is a minimal bit of cleanup on top.
1: make xen_iret_crit_fixup independent of frame layout
2: simplify xen_iret_crit_fixup's ring check
>>> Seeing that the other regression fix has been taken into -tip,
>>> what is the situation here? Should 5.4 really ship with this
>>> still unfixed?
>> I am still unable to boot a 32-bit guest with those patches, crashing in
>> int3_exception_notify with regs->sp zero.
>>
>> When I revert to 3c88c692c287 the guest actually boots so my (?) problem
>> was introduced somewhere in-between.
> Nevermind this. I didn't read your patches correctly.
BTW, I'd rather this not go into 5.4 this late. 3c88c692c287 has been
there since 5.2 and noone complained.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 00/12] livepatch: new features and fixes
On Thu, Nov 14, 2019 at 01:06:41PM +, Pawel Wieczorkiewicz wrote:
> This series introduces new features to the livepatch functionality as
> briefly discussed during Xen Developer Summit 2019: [a] and [b].
> It also provides a few fixes and some small improvements.
>
> Main changes in v4:
> - Fix various typos and minor issues
> - Simplify arch_livepatch_{apply,revert} by using
> common_livepatch_{apply,revert}
> - Improve python bindings and fix few issues
This is https://github.com/konradwilk/xen.git (your patches on top of staging):
On ARM64:
root@hikey960:/home/linaro# xl info
host : hikey960
release: 4.12.0-linaro-hikey960+
version: #3 SMP PREEMPT Mon Jul 17 13:26:13 EDT 2017
machine: aarch64
nr_cpus: 8
max_cpu_id : 7
nr_nodes : 1
cores_per_socket : 1
threads_per_core : 1
cpu_mhz: 1.920
hw_caps:
:::::::
virt_caps : hvm hap
total_memory : 2262
free_memory: 713
sharing_freed_memory : 0
sharing_used_memory: 0
outstanding_claims : 0
free_cpus : 0
xen_major : 4
xen_minor : 13
xen_extra : .0-rc
xen_version: 4.13.0-rc
xen_caps : xen-3.0-aarch64 xen-3.0-armv7l
xen_scheduler : credit2
xen_pagesize : 4096
platform_params: virt_start=0x20
xen_changeset : Thu Nov 14 13:06:52 2019 + git:9f5f25f07a
xen_commandline: console=dtuart dtuart=/soc/serial@fff32000 efi=no-rs
dom0_mem=1500M hmp-unsafe=true
cc_compiler: gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
cc_compile_by : linaro
cc_compile_domain : lan
cc_compile_date: Wed Nov 20 02:06:10 UTC 2019
build_id : 8bf9ec5fc0053f4d4fc3b7d256b66ec86f8e5ccc
xend_config_format : 4
root@hikey960:/home/linaro# cd xen.git
root@hikey960:/home/linaro/xen.git# readelf -n xen-sy
readelf: Error: 'xen-sy': No such file
root@hikey960:/home/linaro/xen.git# cd xen
root@hikey960:/home/linaro/xen.git/xen# readelf -n xen-syms
Displaying notes found in: .note.gnu.build-id
Owner Data size Description
GNU 0x0014 NT_GNU_BUILD_ID (unique build ID
bitstring)
Build ID: 8bf9ec5fc0053f4d4fc3b7d256b66ec86f8e5ccc
root@hikey960:/home/linaro/xen.git/xen# cd test/livepatch/
root@hikey960:/home/linaro/xen.git/xen/test/livepatch# xen-livepatch list
Nothing to list
root@hikey960:/home/linaro/xen.git/xen/test/livepatch# xen-livepatch load
xen_hello_world.livepatch
Uploading xen_hello_world.livepatch... completed
Applying xen_hello_world... failed
Error 22: Invalid argument
Unloading xen_hello_world... failed
Error 22: Invalid argument
root@hikey960:/home/linaro/xen.git/xen/test/livepatch# git log
commit 9f5f25f07a64e1b447f7bd124182a1c5ef422d6f
Author: Pawel Wieczorkiewicz
Date: Thu Nov 14 13:06:52 2019 +
livepatch: Add metadata runtime retrieval mechanism
...
root@hikey960:/home/linaro/xen.git/xen/test/livepatch#xl dmesg -c
(XEN) Checking for initrd in /chosen
(XEN) RAM: - 1abf
(XEN) RAM: 1ad88000 - 31ff
(XEN) RAM: 32101000 - 3dff
(XEN) RAM: 4000 - 5af25fff
(XEN) RAM: 89cc - b8767fff
(XEN) RAM: b9ac - b9ac8fff
(XEN) RAM: b9bfb000 - b9cb
(XEN) RAM: b9d62000 - b9e0
(XEN) RAM: ba1d - ba1dbfff
(XEN) RAM: ba1dc000 - bdc46fff
(XEN) RAM: bdc47000 - bdd06fff
(XEN) RAM: bdd07000 - bddd6fff
(XEN) RAM: bddd7000 - bf00
(XEN) RAM: bf01 - bf012fff
(XEN) RAM: bf013000 - bf19
(XEN) RAM: bf1a - bf1e
(XEN) RAM: bf24 - bf24efff
(XEN) RAM: bf24f000 - bfff
(XEN)
(XEN) MODULE[0]: b8773000 - b88be900 Xen
(XEN) MODULE[1]: b8768000 - b8773000 Device Tree
(XEN) MODULE[2]: b88c9000 - b9885a00 Kernel
(XEN) RESVD[0]: 3200 - 320f
(XEN)
(XEN) CMDLINE[b88c9000]:chosen console=tty0 console=hvc0
root=/dev/sdd10 rw efi=noruntime
(XEN)
(XEN) Command line: console=dtuart dtuart=/soc/serial@fff32000 efi=no-rs
dom0_mem=1500M hmp-unsafe=true
(XEN) parameter "efi" unknown!
(XEN) Domain heap initialised
(XEN) Booting using Device Tree
(XEN) Platform: Generic System
(XEN) Looking for dtuart at "/soc/serial@fff32000", options ""
Xen 4.13.0-rc
(XEN) Xen version 4.13.0-rc (linaro@lan) (gcc (Debian 6.3.0-18+deb9u1) 6.3.0
20170516) debug=y Wed Nov 20 02:06:10 UTC 2019
(XEN) Latest ChangeSet: Thu Nov 14 13:06:52 2019 + git:9f5f25f07a
(XEN) build-id:
Re: [Xen-devel] Ping: [PATCH 0/2] x86/Xen/32: xen_iret_crit_fixup adjustments
On 11/19/19 12:50 PM, Boris Ostrovsky wrote:
> On 11/19/19 7:58 AM, Jan Beulich wrote:
>> On 11.11.2019 15:30, Jan Beulich wrote:
>>> The first patch here fixes another regression from 3c88c692c287
>>> ("x86/stackframe/32: Provide consistent pt_regs"), besides the
>>> one already addressed by
>>> https://lists.xenproject.org/archives/html/xen-devel/2019-10/msg01988.html.
>>> The second patch is a minimal bit of cleanup on top.
>>>
>>> 1: make xen_iret_crit_fixup independent of frame layout
>>> 2: simplify xen_iret_crit_fixup's ring check
>> Seeing that the other regression fix has been taken into -tip,
>> what is the situation here? Should 5.4 really ship with this
>> still unfixed?
>
> I am still unable to boot a 32-bit guest with those patches, crashing in
> int3_exception_notify with regs->sp zero.
>
> When I revert to 3c88c692c287 the guest actually boots so my (?) problem
> was introduced somewhere in-between.
Nevermind this. I didn't read your patches correctly.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.11-testing test] 144206: regressions - FAIL
flight 144206 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/144206/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 144025 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 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-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 74507046dbd2c5d2991eeabd1af39af0d6b29d70 baseline version: xen 006b2041242129896fbd30135b3dc6f575894a07 Last test of basis 144025 2019-11-11 17:36:00 Z8 days Testing same since 144058 2019-11-12 18:05:56 Z7 days 12 attempts
Re: [Xen-devel] Ryzen 3xxx works with Windows
On 18.11.2019 17:25, George Dunlap wrote: Where were these values collected -- on a PV dom0? Or from within the guest? Neither. Bare metal kernel - no Xen at all. Could you try this with `0111` instead? Works. '1000' crashes again. Now it is clear that 7 is the maximum Windows accepts. Regards Andreas ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 144205: regressions - FAIL
flight 144205 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/144205/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 144042 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 144042 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 144020 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 144042 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 144042 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 144042 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 144042 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 144042 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 144042 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 144042 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 144042 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 144042 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 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-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-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-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-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-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-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen e28eed55a41e4d70c3bd7b0efb1668dd93d8bed6 baseline version: xen a458d3bd0d2585275c128556ec0cbd818c6a7b0d Last test of basis 144042 2019-11-12 09:07:51 Z7 days Failing since144067 2019-11-13 02:19:05 Z6 days 11 attempts Testing same since
Re: [Xen-devel] [PATCH 6/8] drm/xen: Simplify fb_create
On Fri, Nov 15, 2019 at 10:33:24AM +, Oleksandr Andrushchenko wrote:
> On 11/15/19 11:21 AM, Daniel Vetter wrote:
> > The current code is a pretty good wtf moment, since we drop the
> > reference before we use it. It's not a big deal, because a) we only
> > use the pointer, so doesn't blow up and the real reason b) fb->obj[0]
> > already holds a full reference for us.
> >
> > Might as well take the real pointer ins't of complicated games that
> > baffle.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Oleksandr Andrushchenko
> > Cc: xen-devel@lists.xenproject.org
> Reviewed-by: Oleksandr Andrushchenko
Thanks for taking a look, pushed to drm-misc-next.
-Daniel
> > ---
> > drivers/gpu/drm/xen/xen_drm_front_kms.c | 9 +
> > 1 file changed, 1 insertion(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
> > b/drivers/gpu/drm/xen/xen_drm_front_kms.c
> > index ff506bc99414..4f34c5208180 100644
> > --- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
> > +++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
> > @@ -63,14 +63,7 @@ fb_create(struct drm_device *dev, struct drm_file *filp,
> > if (IS_ERR_OR_NULL(fb))
> > return fb;
> >
> > - gem_obj = drm_gem_object_lookup(filp, mode_cmd->handles[0]);
> > - if (!gem_obj) {
> > - DRM_ERROR("Failed to lookup GEM object\n");
> > - ret = -ENOENT;
> > - goto fail;
> > - }
> > -
> > - drm_gem_object_put_unlocked(gem_obj);
> > + gem_obj = fb->obj[0];
> >
> > ret = xen_drm_front_fb_attach(drm_info->front_info,
> > xen_drm_front_dbuf_to_cookie(gem_obj),
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/nested-hap: Fix handling of L0_ERROR
On 19/11/2019 15:23, Jan Beulich wrote:
> On 19.11.2019 15:58, Andrew Cooper wrote:
>> On 19/11/2019 11:13, Jan Beulich wrote:
>>> On 18.11.2019 19:15, Andrew Cooper wrote:
>>> I take it you imply that L0_ERROR would need raising (as per the
>>> auxiliary code fragment adding the "(access_x && *page_order)"
>>> check), but I wonder whether that would really be correct. This
>>> depends on what L0_ERROR really is supposed to mean: An error
>>> because of actual L0 settings (x=0 in our case), or an error
>>> because of intended L0 settings (x=1 in our case). After all a
>>> violation of just the p2m_access (which also affects r/w/x)
>>> doesn't get reported by nestedhap_walk_L0_p2m() as L0_ERROR
>>> either (and hence would, as it seems to me, lead to a similar
>>> live lock).
>>>
>>> Therefore I wonder whether your initial idea of doing the
>>> shattering right here wouldn't be the better course of action.
>>> nestedhap_fix_p2m() could either install the large page and then
>>> shatter it right away, or it could install just the individual
>>> small page. Together with the different npfec adjustment model
>>> suggested below (leading to npfec.present to also get updated in
>>> the DONE case) a similar "insn-fetch && present" conditional (to
>>> that introduced for XSA-304) could then be used there.
>>>
>>> Even better - by making the violation checking around the
>>> original XSA-304 addition a function (together with the 304
>>> addition), such a function might then be reusable here. This
>>> might then address the p2m_access related live lock as well.
>> This is all unrelated to the patch.
> I don't think so.
This patch is not a fix for the XSA-304 livelock.
It is a independent bug discovered while investigating the livelock.
It may, or may not, form part of the XSA-304 livelock bugfix, depending
on how the rest of the investigation goes.
> At the very least defining what exactly L0_ERROR
> is intended to mean is pretty relevant here.
The intent of the code is clear (at least, to me).
It means #NPF/EPT_VIOLATION/EPT_MISCONFIG in the L01 part of the nested
walk.
@@ -181,6 +180,18 @@ nestedhap_walk_L0_p2m(struct p2m_domain *p2m, paddr_t
L1_gpa, paddr_t *L0_gpa,
*L0_gpa = (mfn_x(mfn) << PAGE_SHIFT) + (L1_gpa & ~PAGE_MASK);
out:
__put_gfn(p2m, L1_gpa >> PAGE_SHIFT);
+
+/*
+ * When reporting L0_ERROR, rewrite nfpec to match what would have
occured
+ * if hardware had walked the L0, rather than the combined L02.
+ */
+if ( rc == NESTEDHVM_PAGEFAULT_L0_ERROR )
+{
+npfec->present = !mfn_eq(mfn, INVALID_MFN);
>>> To be in line with the conditional a few lines up from here,
>>> wouldn't this better be !mfn_valid(mfn)?
>> That's not how the return value from get_gfn_*() works, and would break
>> the MMIO case.
> How that (for the latter part of your reply)? The MMIO case produces
> NESTEDHVM_PAGEFAULT_DIRECT_MMIO, i.e. doesn't even enter this if().
> Hence my remark elsewhere that the MMIO cases isn't taken care of in
> the first place.
>
>>> Should there ever be a case to clear the flag when it was set? If
>>> a mapping has gone away between the time the exit condition was
>>> detected and the time we re-evaluate things here, I think it
>>> should still report "present" back to the caller.
>> No - absolutely not. We must report the property of the L0 walk, as we
>> found it.
>>
>> Pretending it was present when it wasn't is a sure-fire way of leaving
>> further bugs lurking.
> But if npfec.present is set, it surely was set at the time of the
> hardware walk. And _that's_ what npfec is supposed to represent.
>
>>> Taking both
>>> remarks together I'm thinking of
>>>
>>> if ( mfn_valid(mfn) )
>>> npfec->present = 1;
>>>
+npfec->gla_valid = 0;
>>> For this, one the question is whose linear address is meant here.
>> The linear address (which was L2's) is nonsensical when we've taken an
>> L0 fault. This is why it is clobbered unconditionally.
> And this is also why I was saying ...
>
>>> If it's L2's, then it shouldn't be cleared. If it's L1's, then
>>> it would seem to me that it should have been avoided to set the
>>> field, or at least it should have been cleared the moment we're
>>> past L12 handling.
> ... this. If it's nonsensical, it shouldn't have been set to begin
> with, or be squashed earlier than here.
There seems to be a lot of confusion here.
This is the correct place to discard it.
Hardware did a real walk of L02 and got a real gpa and npfec (optionally
with a real gla), that overall identified "something went wrong".
Upon interpreting "what went wrong", Xen may decide that it is a problem
in the L01 walk, rather than the L12 or combined L02.
A problem in the L01 walk is handled by returning L0_ERROR back to the
common code, discarding the current NPF/EPT_VIOLATION/MISCONFIG context,
and synthesizing the state that would have occurred if
[Xen-devel] [xen-unstable-smoke test] 144210: tolerable all pass - PUSHED
flight 144210 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/144210/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass version targeted for testing: xen 0273d8e24249d14f5964f6b2193a53a1fb99ce9e baseline version: xen e28eed55a41e4d70c3bd7b0efb1668dd93d8bed6 Last test of basis 144203 2019-11-19 00:00:38 Z0 days Testing same since 144210 2019-11-19 17:01:30 Z0 days1 attempts People who touched revisions under test: Anthony PERARD Ian Jackson Oleksandr Grytsov jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git e28eed55a4..0273d8e242 0273d8e24249d14f5964f6b2193a53a1fb99ce9e -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] arch: arm: vgic-v3: fix GICD_ISACTIVER range
Hi Andre, On 12/11/2019 12:46, Andre Przywara wrote: On Mon, 11 Nov 2019 11:01:07 -0800 (PST) Stefano Stabellini wrote: On Sat, 9 Nov 2019, Julien Grall wrote: On Sat, 9 Nov 2019, 04:27 Stefano Stabellini, wrote: On Thu, 7 Nov 2019, Peng Fan wrote: > The end should be GICD_ISACTIVERN not GICD_ISACTIVER. > > Signed-off-by: Peng Fan Reviewed-by: Stefano Stabellini To be honest, I am not sure the code is correct. A read to those registers should tell you the list of interrupts active. As we always return 0, this will not return the correct state of the GIC. I know that returning the list of actives interrupts is complicated with the old vGIC, but I don't think silently ignoring it is a good idea. The question here is why the guest accessed those registers? What is it trying to figure out? I see Linux querying the active state (IRQCHIP_STATE_ACTIVE) at two relevant points for ARM: - In kernel/irq/manage.c, in __synchronize_hardirq(). - In KVM's arch timer emulation code. I think the latter is of no concern (yet), but the first might actually trigger. At the moment it's beyond me what it actually does, but maybe some IRQ changes (RT, threaded IRQs?) trigger this now?\ It happens I am sitting right next to Marc now, so I had a chat with him about this :). Let me try to summarize the discussion here. __synchronize_hardirq() is used to ensure that all active interrupts have been handled before continuing. When sync_chip == false, we only ensure that all in progress interrupts (from Linux PoV) are handled before continue. sync_chip == true will additionally ensure that any interrupt that were acknowledge but not yet marked as in progress by the kernel are also handled. The assumption is this is called after the interrupt has been masked/disabled. The call to __synchronize_hardirq() in free_irq() (as reported by Peng stack trace) was introduced recently (see [1]). It is not entirely clear whether this would affect anyone using Linux 5.4 or just a limited subset of users. Anyhow, this is a genuine bug and I think returning 0 is only papering over the bug with no long-term resolution. As Marc pointed out, Even the old vGIC in KVM was not spec compliant and thankfully this was fixed in the new vGIC. As I said in a different sub-thread, I would reluctanly be ok to see returning 0 as long as we have add a warning for *every* access. Long-term, the current vGIC should really get killed. Cheers, [1] 62e0468650c30f0298822c580f382b16328119f6 "genirq: Add optional hardware synchronization for shutdown" -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 12/14] drm/amdgpu: Use mmu_interval_notifier instead of hmm_mirror
I test v3 and it works fine.
Regards,
Philip
On 2019-11-12 3:22 p.m., Jason Gunthorpe wrote:
From: Jason Gunthorpe
Convert the collision-retry lock around hmm_range_fault to use the one now
provided by the mmu_interval notifier.
Although this driver does not seem to use the collision retry lock that
hmm provides correctly, it can still be converted over to use the
mmu_interval_notifier api instead of hmm_mirror without too much trouble.
This also deletes another place where a driver is associating additional
data (struct amdgpu_mn) with a mmu_struct.
Signed-off-by: Philip Yang
Reviewed-by: Philip Yang
Tested-by: Philip Yang
Signed-off-by: Jason Gunthorpe
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 4 +
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 14 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c| 148 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h| 49 --
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 116 --
5 files changed, 94 insertions(+), 237 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 47700302a08b7f..1bcedb9b477dce 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1738,6 +1738,10 @@ static int update_invalid_user_pages(struct
amdkfd_process_info *process_info,
return ret;
}
+ /*
+* FIXME: Cannot ignore the return code, must hold
+* notifier_lock
+*/
amdgpu_ttm_tt_get_user_pages_done(bo->tbo.ttm);
/* Mark the BO as valid unless it was invalidated
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 82823d9a8ba887..22c989bca7514c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -603,8 +603,6 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser *p,
e->tv.num_shared = 2;
amdgpu_bo_list_get_list(p->bo_list, >validated);
- if (p->bo_list->first_userptr != p->bo_list->num_entries)
- p->mn = amdgpu_mn_get(p->adev, AMDGPU_MN_TYPE_GFX);
INIT_LIST_HEAD();
amdgpu_vm_get_pd_bo(>vm, >validated, >vm_pd);
@@ -1287,11 +1285,11 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
if (r)
goto error_unlock;
- /* No memory allocation is allowed while holding the mn lock.
-* p->mn is hold until amdgpu_cs_submit is finished and fence is added
-* to BOs.
+ /* No memory allocation is allowed while holding the notifier lock.
+* The lock is held until amdgpu_cs_submit is finished and fence is
+* added to BOs.
*/
- amdgpu_mn_lock(p->mn);
+ mutex_lock(>adev->notifier_lock);
/* If userptr are invalidated after amdgpu_cs_parser_bos(), return
* -EAGAIN, drmIoctl in libdrm will restart the amdgpu_cs_ioctl.
@@ -1334,13 +1332,13 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
amdgpu_vm_move_to_lru_tail(p->adev, >vm);
ttm_eu_fence_buffer_objects(>ticket, >validated, p->fence);
- amdgpu_mn_unlock(p->mn);
+ mutex_unlock(>adev->notifier_lock);
return 0;
error_abort:
drm_sched_job_cleanup(>base);
- amdgpu_mn_unlock(p->mn);
+ mutex_unlock(>adev->notifier_lock);
error_unlock:
amdgpu_job_free(job);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
index 9fe1c31ce17a30..828b5167ff128f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
@@ -50,28 +50,6 @@
#include "amdgpu.h"
#include "amdgpu_amdkfd.h"
-/**
- * amdgpu_mn_lock - take the write side lock for this notifier
- *
- * @mn: our notifier
- */
-void amdgpu_mn_lock(struct amdgpu_mn *mn)
-{
- if (mn)
- down_write(>lock);
-}
-
-/**
- * amdgpu_mn_unlock - drop the write side lock for this notifier
- *
- * @mn: our notifier
- */
-void amdgpu_mn_unlock(struct amdgpu_mn *mn)
-{
- if (mn)
- up_write(>lock);
-}
-
/**
* amdgpu_mn_invalidate_gfx - callback to notify about mm change
*
@@ -94,6 +72,9 @@ static bool amdgpu_mn_invalidate_gfx(struct
mmu_interval_notifier *mni,
return false;
mutex_lock(>notifier_lock);
+
+ mmu_interval_set_seq(mni, cur_seq);
+
r = dma_resv_wait_timeout_rcu(bo->tbo.base.resv, true, false,
MAX_SCHEDULE_TIMEOUT);
mutex_unlock(>notifier_lock);
@@ -127,6 +108,9 @@ static bool amdgpu_mn_invalidate_hsa(struct
mmu_interval_notifier *mni,
return false;
mutex_lock(>notifier_lock);
+
+ mmu_interval_set_seq(mni, cur_seq);
+
amdgpu_amdkfd_evict_userptr(bo->kfd_bo, bo->notifier.mm);
mutex_unlock(>notifier_lock);
@@
Re: [Xen-devel] [XEN PATCH for-4.13] tools/configure: Honour XEN_COMPILE_ARCH and _TARGET_ for shim
On Tue, 19 Nov 2019 at 16:47, Ian Jackson wrote:
[...]
>
> > >From 1a8de36699b9042c30797e05f7a5f4313d7f7ad1 Mon Sep 17 00:00:00 2001
> > From: Ian Jackson
> > Date: Tue, 29 Oct 2019 17:45:30 +
> > Subject: [PATCH] tools/configure: Honour XEN_COMPILE_ARCH and _TARGET_ for
> > shim
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> >
> > The pvshim can only be built 64-bit because the hypervisor is only
> > 64-bit nowadays. The hypervisor build supports XEN_COMPILE_ARCH and
> > XEN_TARGET_ARCH which override the information from uname. The pvshim
> > build runs out of the tools/ directory but calls the hypervisor build
> > system.
> >
> > If one runs in a Linux 32-bit userland with a 64-bit kernel, one used
> > to be able to set XEN_COMPILE_ARCH. But nowadays this does not work.
> > configure sees the target cpu as 64-bit and tries to build pvshim.
> > The build prints
> > echo "*** Xen x86/32 target no longer supported!"
> > and doesn't build anything. Then the subsequent Makefiles try to
> > install the non-built pieces.
> >
> > Fix this anomaly by causing configure to honour the Xen hypervisor way
> > of setting the target architecture.
> >
> > In principle this user behaviour is not handled quite right, because
> > configure will still see 64-bit and so all the autoconf-based
> > architecture testing will see 64-bit rather than 32-bit x86. But the
> > tools are in fact generally quite portable: this particular location
> > in configure{.ac,} is the only place in tools/ where 64-bit x86 is
> > treated differently from 32-bit x86, so the fix is sufficient and
> > correct for this use case.
> >
> > It remains the case that XEN_COMPILE_ARCH or XEN_TARGET_ARCH to a
> > non-x86 architecture, when configure thinks things are x86, or vice
> > versa, will not work right.
> >
> > (This is a bugfix to 8845155c831c
> > pvshim: make PV shim build selectable from configure
> > which inadvertantly deleted the logic to only build the shim for
> > XEN_TARGET_ARCH != x86_32.)
> >
> > I have rerun autogen.sh, so this patch contains the fix to configure
> > as well as the source fix to configure.ac.
> >
> > Fixes: 8845155c831c59e867ee3dd31ee63e0cc6c7dcf2
> > Signed-off-by: Ian Jackson
> > CC: Olaf Hering
> > CC: Roger Pau Monné
> > Release-acked-by: Jürgen Groß
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-4.13.0-rc] kexec/kdump failure with cpu Intel(R) Xeon(R) Gold 6242 CPU
On 12/11/2019 11:38, Dietmar Hahn wrote:
> Hi,
>
> on a new machine with cpu Intel(R) Xeon(R) Gold 6242 CPU the kexec/kdump
> doesn't work with current xen-4.13.0-rc.
> The last output of the xen console is:
>
> (XEN) Hardware Dom0 crashed: Executing kexec image on cpu5
> (XEN) Shot down all CPUs
>
> After short delay the system reboots.
>
> It seems the fixes mentioned in the thread
> https://lists.xenproject.org/archives/html/xen-devel/2019-10/msg01948.html
> aren't enough.
>
> I built xen-4.11 with the patches but no success.
> On an older system with xen-4.4 the kdump works.
For 4.11 you need this fix as well: 12c36f577d45 ("iommu: leave IOMMU
enabled by default during kexec crash transition"). I'm pretty certain
xen-4.4 wouldn't work on your new system as well.
Igor
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V2 2/2] x86/mm: Make use of the default access param from xc_altp2m_create_view
On Mon, Nov 18, 2019 at 2:53 AM Jan Beulich wrote:
>
> On 18.11.2019 09:38, Alexandru Stefan ISAILA wrote:
> > On 12.11.2019 14:02, Jan Beulich wrote:
> >> On 06.11.2019 16:35, Alexandru Stefan ISAILA wrote:
> >>> @@ -2572,17 +2574,36 @@ int p2m_init_altp2m_by_id(struct domain *d,
> >>> unsigned int idx)
> >>> altp2m_list_lock(d);
> >>>
> >>> if ( d->arch.altp2m_eptp[idx] == mfn_x(INVALID_MFN) )
> >>> -rc = p2m_activate_altp2m(d, idx);
> >>> +rc = p2m_activate_altp2m(d, idx, hostp2m->default_access);
> >>>
> >>> altp2m_list_unlock(d);
> >>> return rc;
> >>> }
> >>>
> >>> -int p2m_init_next_altp2m(struct domain *d, uint16_t *idx)
> >>> +int p2m_init_next_altp2m(struct domain *d, uint16_t *idx,
> >>> + uint16_t hvmmem_default_access)
> >>> {
> >>> int rc = -EINVAL;
> >>> unsigned int i;
> >>>
> >>> +static const p2m_access_t memaccess[] = {
> >>> +#define ACCESS(ac) [XENMEM_access_##ac] = p2m_access_##ac
> >>> +ACCESS(n),
> >>> +ACCESS(r),
> >>> +ACCESS(w),
> >>> +ACCESS(rw),
> >>> +ACCESS(x),
> >>> +ACCESS(rx),
> >>> +ACCESS(wx),
> >>> +ACCESS(rwx),
> >>> +ACCESS(rx2rw),
> >>> +ACCESS(n2rwx),
> >>> +#undef ACCESS
> >>> +};
> >>> +
> >>> +if ( hvmmem_default_access > XENMEM_access_default )
> >>> +return rc;
> >>> +
> >>> altp2m_list_lock(d);
> >>>
> >>> for ( i = 0; i < MAX_ALTP2M; i++ )
> >>> @@ -2590,7 +2611,7 @@ int p2m_init_next_altp2m(struct domain *d, uint16_t
> >>> *idx)
> >>> if ( d->arch.altp2m_eptp[i] != mfn_x(INVALID_MFN) )
> >>> continue;
> >>>
> >>> -rc = p2m_activate_altp2m(d, i);
> >>> +rc = p2m_activate_altp2m(d, i, memaccess[hvmmem_default_access]);
> >>
> >> Aren't you open-coding xenmem_access_to_p2m_access() here? In
> >> no event should there be two instances of the same static array.
> >
> > I did this because xenmem_access_to_p2m_access() is defined static in
> > x86/mm/mem_access.c. If it's ok to have it defined in mem_access.h then
> > I can go with that and drop this part of the code.
>
> I see no reason why this wouldn't be a reasonable step, allowing to
> avoid code duplication. Looks like the function is even suitably
> named already for making non-static.
Sounds fine to me too.
Thanks,
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] livepatch-build-tools regression
> On 18. Nov 2019, at 18:41, Sergey Dyasli wrote: > > On 18/11/2019 17:28, Wieczorkiewicz, Pawel wrote: >> >> Could you build the lp with debug (-d) and provide me with the >> create-diff-object.log file? >> > > I've attached the log. Btw, I think I provided all the necessary information > for others to repeat my experiment. > Sorry for another request, but I do not seem to be able to reproduce this locally. Could you send me the livepatch module binary that fails to upload? > -- > Thanks, > Sergey > Best Regards, Pawel Wieczorkiewicz Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [XEN PATCH] xen/arch/x86/Makefile: Remove $(guard) use from $(TARGET).efi target
Following the patch 65d104984c04 ("x86: fix race to build
arch/x86/efi/relocs-dummy.o"), the error message
nm: 'efi/relocs-dummy.o': No such file"
started to appear on system which can't build the .efi target. This is
because relocs-dummy.o isn't built anymore.
The error is printed by the evaluation of VIRT_BASE and ALT_BASE which
aren't use anyway.
But, we don't need that file as we don't want to build `$(TARGET).efi'
anyway. On such system, $(guard) evaluate to the shell builtin ':',
which prevent any of the shell commands in `$(TARGET).efi' from been
executed.
Even if $(guard) is evaluated opon use, it depends on $(XEN_BUILD_PE)
which is evaluated at the assignment. So, we can replace $(guard) in
$(TARGET).efi by having two different rules depending on
$(XEN_BUILD_PE) instead.
The change with this patch is that none of the dependency of
$(TARGET).efi will be built if the linker doesn't support PE
and VIRT_BASE and ALT_BASE don't get evaluated anymore, so nm will not
complain about the missing relocs-dummy.o file anymore.
Since prelink-efi.o isn't built on system that can't build
$(TARGET).efi anymore, we can remove the $(guard) variable everywhere.
Reported-by: Jan Beulich
Signed-off-by: Anthony PERARD
---
xen/arch/x86/Makefile | 40 +---
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index a6df19e901b3..a0b2f4ab1577 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -120,20 +120,20 @@ prelink_lto.o: $(ALL_OBJS)
$(LD_LTO) -r -o $@ $^
prelink-efi_lto.o: $(ALL_OBJS) efi/runtime.o efi/compat.o
- $(guard) $(LD_LTO) -r -o $@ $(filter-out %/efi/built_in.o,$^)
+ $(LD_LTO) -r -o $@ $(filter-out %/efi/built_in.o,$^)
# Link it with all the binary objects
prelink.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS)) prelink_lto.o
$(LD) $(LDFLAGS) -r -o $@ $^
prelink-efi.o: $(patsubst %/built_in.o,%/built_in_bin.o,$(ALL_OBJS))
prelink-efi_lto.o efi/boot.init.o
- $(guard) $(LD) $(LDFLAGS) -r -o $@ $^
+ $(LD) $(LDFLAGS) -r -o $@ $^
else
prelink.o: $(ALL_OBJS)
$(LD) $(LDFLAGS) -r -o $@ $^
prelink-efi.o: $(ALL_OBJS) efi/boot.init.o efi/runtime.o efi/compat.o
- $(guard) $(LD) $(LDFLAGS) -r -o $@ $(filter-out %/efi/built_in.o,$^)
+ $(LD) $(LDFLAGS) -r -o $@ $(filter-out %/efi/built_in.o,$^)
endif
$(TARGET)-syms: prelink.o xen.lds
@@ -178,8 +178,6 @@ CFLAGS-$(XEN_BUILD_EFI) += -DXEN_BUILD_EFI
$(TARGET).efi: VIRT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A
VIRT_START$$,,p')
$(TARGET).efi: ALT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A
ALT_START$$,,p')
-# Don't use $(wildcard ...) here - at least make 3.80 expands this too early!
-$(TARGET).efi: guard = $(if $(filter y,$(XEN_BUILD_PE)),,:)
ifneq ($(build_id_linker),)
ifeq ($(call ld-ver-build-id,$(LD) $(filter -m%,$(EFI_LDFLAGS))),y)
@@ -197,27 +195,31 @@ note_file :=
endif
note_file_option ?= $(note_file)
+ifeq ($(filter y,$(XEN_BUILD_PE)),y)
$(TARGET).efi: prelink-efi.o $(note_file) efi.lds efi/relocs-dummy.o
efi/mkreloc
$(foreach base, $(VIRT_BASE) $(ALT_BASE), \
- $(guard) $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $<
efi/relocs-dummy.o \
+ $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $<
efi/relocs-dummy.o \
$(BASEDIR)/common/symbols-dummy.o $(note_file_option)
-o $(@D)/.$(@F).$(base).0 &&) :
- $(guard) efi/mkreloc $(foreach base,$(VIRT_BASE)
$(ALT_BASE),$(@D)/.$(@F).$(base).0) >$(@D)/.$(@F).0r.S
- $(guard) $(NM) -pa --format=sysv $(@D)/.$(@F).$(VIRT_BASE).0 \
- | $(guard) $(BASEDIR)/tools/symbols $(all_symbols) --sysv
--sort >$(@D)/.$(@F).0s.S
- $(guard) $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0r.o
$(@D)/.$(@F).0s.o
+ efi/mkreloc $(foreach base,$(VIRT_BASE)
$(ALT_BASE),$(@D)/.$(@F).$(base).0) >$(@D)/.$(@F).0r.S
+ $(NM) -pa --format=sysv $(@D)/.$(@F).$(VIRT_BASE).0 \
+ | $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort
>$(@D)/.$(@F).0s.S
+ $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0r.o $(@D)/.$(@F).0s.o
$(foreach base, $(VIRT_BASE) $(ALT_BASE), \
- $(guard) $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< \
+ $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< \
$(@D)/.$(@F).0r.o $(@D)/.$(@F).0s.o $(note_file_option)
-o $(@D)/.$(@F).$(base).1 &&) :
- $(guard) efi/mkreloc $(foreach base,$(VIRT_BASE)
$(ALT_BASE),$(@D)/.$(@F).$(base).1) >$(@D)/.$(@F).1r.S
- $(guard) $(NM) -pa --format=sysv $(@D)/.$(@F).$(VIRT_BASE).1 \
- | $(guard) $(BASEDIR)/tools/symbols $(all_symbols) --sysv
--sort >$(@D)/.$(@F).1s.S
- $(guard) $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1r.o
$(@D)/.$(@F).1s.o
- $(guard) $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T efi.lds -N $< \
+ efi/mkreloc
Re: [Xen-devel] Ping: [PATCH 0/2] x86/Xen/32: xen_iret_crit_fixup adjustments
On 11/19/19 7:58 AM, Jan Beulich wrote:
> On 11.11.2019 15:30, Jan Beulich wrote:
>> The first patch here fixes another regression from 3c88c692c287
>> ("x86/stackframe/32: Provide consistent pt_regs"), besides the
>> one already addressed by
>> https://lists.xenproject.org/archives/html/xen-devel/2019-10/msg01988.html.
>> The second patch is a minimal bit of cleanup on top.
>>
>> 1: make xen_iret_crit_fixup independent of frame layout
>> 2: simplify xen_iret_crit_fixup's ring check
> Seeing that the other regression fix has been taken into -tip,
> what is the situation here? Should 5.4 really ship with this
> still unfixed?
I am still unable to boot a 32-bit guest with those patches, crashing in
int3_exception_notify with regs->sp zero.
When I revert to 3c88c692c287 the guest actually boots so my (?) problem
was introduced somewhere in-between.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13] tools/configure: Honour XEN_COMPILE_ARCH and _TARGET_ for shim
On Tue, Nov 12, 2019 at 11:57:32AM +, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [XEN PATCH for-4.13] tools/configure:
> Honour XEN_COMPILE_ARCH and _TARGET_ for shim"):
> > Andrew Cooper writes ("Re: [Xen-devel] [XEN PATCH for-4.13]
> > tools/configure: Honour XEN_COMPILE_ARCH and _TARGET_ for shim"):
> > > On 29/10/2019 17:57, Ian Jackson wrote:
> > > > The pvshim can only be built 64-bit because the hypervisor is only
> > > > 64-bit nowadays. The hypervisor build supports XEN_COMPILE_ARCH and
> > > > XEN_TARGET_ARCH which override the information from uname. The pvshim
> > > > build runs out of the tools/ directory but calls the hypervisor build
> > > > system.
> > > >
> > > > If one runs in a Linux 32-bit userland with a 64-bit kernel, one used
> > > > to be able to set XEN_COMPILE_ARCH. But nowadays this does not work.
> > >
> > > This looks to be a bugfix to 8845155c831c59e867ee3dd31ee63e0cc6c7dcf2 ?
> > >
> > > In particular, this deleted the logic to only build the shim for
> > > XEN_TARGET_ARCH != x86_32.
> >
> > Yes. I have added a note about that to the commit message (stealing
> > your text, thanks) and now I am CCing the author and requester of that
> > commit, for form's sake.
>
> Andrew, did you want to ack this ? Or do you have further comments ?
> I have a release-ack...
>
> Thanks,
> Ian.
>
> From 1a8de36699b9042c30797e05f7a5f4313d7f7ad1 Mon Sep 17 00:00:00 2001
> From: Ian Jackson
> Date: Tue, 29 Oct 2019 17:45:30 +
> Subject: [PATCH] tools/configure: Honour XEN_COMPILE_ARCH and _TARGET_ for
> shim
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> The pvshim can only be built 64-bit because the hypervisor is only
> 64-bit nowadays. The hypervisor build supports XEN_COMPILE_ARCH and
> XEN_TARGET_ARCH which override the information from uname. The pvshim
> build runs out of the tools/ directory but calls the hypervisor build
> system.
>
> If one runs in a Linux 32-bit userland with a 64-bit kernel, one used
> to be able to set XEN_COMPILE_ARCH. But nowadays this does not work.
> configure sees the target cpu as 64-bit and tries to build pvshim.
> The build prints
> echo "*** Xen x86/32 target no longer supported!"
> and doesn't build anything. Then the subsequent Makefiles try to
> install the non-built pieces.
>
> Fix this anomaly by causing configure to honour the Xen hypervisor way
> of setting the target architecture.
>
> In principle this user behaviour is not handled quite right, because
> configure will still see 64-bit and so all the autoconf-based
> architecture testing will see 64-bit rather than 32-bit x86. But the
> tools are in fact generally quite portable: this particular location
> in configure{.ac,} is the only place in tools/ where 64-bit x86 is
> treated differently from 32-bit x86, so the fix is sufficient and
> correct for this use case.
>
> It remains the case that XEN_COMPILE_ARCH or XEN_TARGET_ARCH to a
> non-x86 architecture, when configure thinks things are x86, or vice
> versa, will not work right.
>
> (This is a bugfix to 8845155c831c
> pvshim: make PV shim build selectable from configure
> which inadvertantly deleted the logic to only build the shim for
> XEN_TARGET_ARCH != x86_32.)
>
> I have rerun autogen.sh, so this patch contains the fix to configure
> as well as the source fix to configure.ac.
>
> Fixes: 8845155c831c59e867ee3dd31ee63e0cc6c7dcf2
> Signed-off-by: Ian Jackson
> CC: Olaf Hering
> CC: Roger Pau Monné
Reviewed-by: Roger Pau Monné
Thanks.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 12/12] livepatch: Add python bindings for livepatch operations
On 11/14/19 1:06 PM, Pawel Wieczorkiewicz wrote:
> Extend the XC python bindings library to support also all common
> livepatch operations and actions.
>
> Add the python bindings for the following operations:
> - status (pyxc_livepatch_status):
> Requires a payload name as an input.
> Returns a status dict containing a state string and a return code
> integer.
> - action (pyxc_livepatch_action):
> Requires a payload name and an action id as an input. Timeout and
> flags are optional parameters.
> Returns None or throws an exception.
> - upload (pyxc_livepatch_upload):
> Requires a payload name and a module's filename as an input.
> Returns None or throws an exception.
> - list (pyxc_livepatch_list):
> Takes no parameters.
> Returns a list of dicts containing each payload's:
> * name as a string
> * state as a string
> * return code as an integer
> * list of metadata key=value strings
>
> Each functions throws an exception error based on the errno value
> received from its corresponding libxc function call.
>
> Signed-off-by: Pawel Wieczorkiewicz
> Reviewed-by: Martin Mazein
> Reviewed-by: Andra-Irina Paraschiv
> Reviewed-by: Leonard Foerster
> Reviewed-by: Norbert Manthey
> Acked-by: Marek Marczykowski-Górecki
> ---
snip
> +static PyObject *pyxc_livepatch_upload(XcObject *self,
> + PyObject *args,
> + PyObject *kwds)
> +{
> +unsigned char *fbuf = MAP_FAILED;
> +char *name, *filename;
> +struct stat buf;
> +int fd = 0, rc = -1, saved_errno;
Does fd actually need to be initialized here?
Also, initializing it to 0 seems odd because 0 is a valid fd.
> +ssize_t len;
> +
> +static char *kwd_list[] = { "name", "filename", NULL };
> +
> +if ( !PyArg_ParseTupleAndKeywords(args, kwds, "ss", kwd_list,
> + , ))
> +goto error;
> +
> +fd = open(filename, O_RDONLY);
> +if ( fd < 0 )
> +goto error;
> +
> +if ( fstat(fd, ) != 0 )
> +goto error_fd;
> +
> +len = buf.st_size;
> +fbuf = mmap(0, len, PROT_READ, MAP_PRIVATE, fd, 0);
> +if ( fbuf == MAP_FAILED )
> +goto error_fd;
> +
> +rc = xc_livepatch_upload(self->xc_handle, name, fbuf, len);
> +
> +saved_errno = errno;
> +munmap(fbuf, len);
> +errno = saved_errno;
> +
> +error_fd:
> +close(fd);
> +error:
> +return rc ? pyxc_error_to_exception(self->xc_handle) : Py_None;
> +}
snip> static PyMethodDef pyxc_methods[] = {
> { "domain_create",
>(PyCFunction)pyxc_domain_create,
> @@ -2542,6 +2761,44 @@ static PyMethodDef pyxc_methods[] = {
>"Returns: [int]: 0 on all permission granted; -1 if any permissions
> are \
> denied\n" },
>
> +{ "livepatch_status",
> + (PyCFunction)pyxc_livepatch_status,
> + METH_KEYWORDS, "\n"
> + "Gets current state and return code for a specified module.\n"
> + " name [str]: Module name to be used\n"
> + "Returns: [dict] on success; throwing an exception on error\n"
> + " state[int]: Module current state: CHECKED or APPLIED\n"
> + " rc [int]: Return code of last module's operation\n" },
> +
> +{ "livepatch_upload",
> + (PyCFunction)pyxc_livepatch_upload,
> + METH_KEYWORDS, "\n"
> + "Uploads a module with specified name from filename.\n"
> + " name [str]: Module name to be used\n"
> + " filename [str]: Filename of a module to be uploaded\n"
> + "Returns: None on success; throwing an exception on error\n" },
> +
> +{ "livepatch_action",
> + (PyCFunction)pyxc_livepatch_action,
> + METH_KEYWORDS, "\n"
> + "Performs an action (unload, revert, apply or replace) on a specified \
> + module.\n"
> + " name [str]: Module name to be used\n"
> + " action [uint]: Action enum id\n"
> + " timeout [uint]: Action scheduled execution timeout\n"
> + " flags [ulong]: Flags specifying action's extra parameters\n"
Should this be uint and not ulong?
I expect these things could be fixed up on commit.
Reviewed-by: Ross Lagerwall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 11/12] livepatch: Add metadata runtime retrieval mechanism
On 11/14/19 1:06 PM, Pawel Wieczorkiewicz wrote: > Extend the livepatch list operation to fetch also payloads' metadata. > This is achieved by extending the sysctl list interface with 2 extra > guest handles: > * metadata - an array of arbitrary size strings > * metadata_len - an array of metadata strings' lengths (uin32_t each) > > Payloads' metadata is a string of arbitrary size and does not have an > upper bound limit. It may also vary in size between payloads. > > In order to let the userland allocate enough space for the incoming > data add a metadata total size field to the list sysctl operation and > fill it with total size of all payloads' metadata. > > Extend the libxc to handle the metadata back-to-back data transfers > as well as metadata length array data transfers. > > The xen-livepatch userland tool is extended to always display the > metadata for each received module. The metadata is received with the > following format: key=value\0key=value\0...key=value\0. The format is > modified to the following one: key=value;key=value;...key=value. > The new format allows to easily parse the metadata for a given module > by a machine. > > Signed-off-by: Pawel Wieczorkiewicz > Reviewed-by: Andra-Irina Paraschiv > Reviewed-by: Martin Pohlack > Reviewed-by: Norbert Manthey > Signed-off-by: Konrad Rzeszutek Wilk > --- Reviewed-by: Ross Lagerwall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13] x86/cpuid: Fix Lisbon/Magny-Cours Opterons WRT SSSE3/SSE4A
On 19.11.19 18:00, Andrew Cooper wrote: c/s ff66ccefe5 "x86/CPUID: adjust SSEn dependencies" made SSE4A depend on SSSE3, but these processors really do have have SSE4A without SSSE3. This manifests as an upgrade regression, as the SSE4A feature disappears from view. Adjust the SSE4A feature to depend on SSE3 rather than SSSE3. Signed-off-by: Andrew Cooper Release-acked-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.13] x86/cpuid: Fix Lisbon/Magny-Cours Opterons WRT SSSE3/SSE4A
c/s ff66ccefe5 "x86/CPUID: adjust SSEn dependencies" made SSE4A depend on SSSE3, but these processors really do have have SSE4A without SSSE3. This manifests as an upgrade regression, as the SSE4A feature disappears from view. Adjust the SSE4A feature to depend on SSE3 rather than SSSE3. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné CC: Juergen Gross For 4.13. Regression from 4.12 --- xen/tools/gen-cpuid.py | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py index 434a6ebf04..2e76f9abc0 100755 --- a/xen/tools/gen-cpuid.py +++ b/xen/tools/gen-cpuid.py @@ -205,9 +205,10 @@ def crunch_numbers(state): # than to SSE. SSE2: [SSE3, LM, AESNI, PCLMULQDQ, SHA, GFNI], -# Other SSEn each depend on their predecessor versions. -SSE3: [SSSE3], -SSSE3: [SSE4_1, SSE4A], +# Other SSEn each depend on their predecessor versions. AMD +# Lisbon/Magny-Cours processors implemented SSE4A without SSSE3. +SSE3: [SSSE3, SSE4A], +SSSE3: [SSE4_1], SSE4_1: [SSE4_2], # AMD specify no relationship between POPCNT and SSE4.2. Intel -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13] xen: Fix race to build arch/x86/efi/relocs-dummy.o
On Tue, Nov 19, 2019 at 05:32:53PM +0100, Jan Beulich wrote: > On 19.11.2019 17:27, Jan Beulich wrote: > > On 14.11.2019 19:05, Anthony PERARD wrote: > >> With $(TARGET).efi depending on efi/relocs-dummy.o, arch/x86/Makefile > >> will attempt to build that object. This result in the dependency file > >> been generated with relocs-dummy.o depending on efi/relocs-dummy.o. > >> > >> Then, when arch/x86/efi/Makefile tries to build relocs-dummy.o, well > >> efi/relocs-dummy.S doesn't exist. > >> > >> Have only one makefile responsible for building relocs-dummy.o. > > > > On a system with too old a tool chain for the EFI build to get > > enabled I now get about a dozen instances per build of > > > > nm: 'efi/relocs-dummy.o': No such file > > > > I don't suppose you did try out your change in such an oldish > > environment? I assume the problem are these two lines: > > > > $(TARGET).efi: VIRT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, > > A VIRT_START$$,,p') > > $(TARGET).efi: ALT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A > > ALT_START$$,,p') > > > > I'm not sure it is well defined when make would evaluate such > > target specific variable assignments (i.e. I'm not sure this > > doesn't point out an issue even on EFI capable tool chains). > > Then again these not using := should cause them to get > > evaluated only upon use, i.e. never. > > Ah, this was wrong - the $(guard) prefix causes them to get > evaluated even when xen.efi cannot be built. So I guess this is > just a cosmetic issue then, which would however still be nice > to see addressed. That $(guard) thing is weird, and can probably be replace now. I'll try to remove that thing, and also avoid having $(TARGET).efi depending on efi/relocs-dummy.o when it isn't going to be built (when XEN_BUILD_EFI=n). -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13] efi: do not use runtime services table with efi=no-rs
On 17.11.19 00:47, Marek Marczykowski-Górecki wrote: Before df6631 "efi: use directmap to access runtime services table" all usages of efi_rs pointer were guarded by efi_rs_enter(), which implicitly refused to operate with efi=no-rs (by checking if efi_l4_pgtable is NULL - which is the case for efi=no-rs). The said commit (re)moved that call as unneeded for just reading content of efi_rs structure - to avoid unnecessary page tables switch. But it neglected to check if efi_rs access is legal. Fix this by adding explicit check for runtime service being enabled in the cases that do not use efi_rs_enter(). Reported-by: Roman Shaposhnik Fixes: df6631 "efi: use directmap to access runtime services table" Signed-off-by: Marek Marczykowski-Górecki 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] [XEN PATCH for-4.13] tools/configure: Honour XEN_COMPILE_ARCH and _TARGET_ for shim
Ian Jackson writes ("Re: [Xen-devel] [XEN PATCH for-4.13] tools/configure:
Honour XEN_COMPILE_ARCH and _TARGET_ for shim"):
> Andrew, did you want to ack this ? Or do you have further comments ?
> I have a release-ack...
Hrm. get_maintainer thinks this is for Wei. CC'd.
Ian.
> >From 1a8de36699b9042c30797e05f7a5f4313d7f7ad1 Mon Sep 17 00:00:00 2001
> From: Ian Jackson
> Date: Tue, 29 Oct 2019 17:45:30 +
> Subject: [PATCH] tools/configure: Honour XEN_COMPILE_ARCH and _TARGET_ for
> shim
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> The pvshim can only be built 64-bit because the hypervisor is only
> 64-bit nowadays. The hypervisor build supports XEN_COMPILE_ARCH and
> XEN_TARGET_ARCH which override the information from uname. The pvshim
> build runs out of the tools/ directory but calls the hypervisor build
> system.
>
> If one runs in a Linux 32-bit userland with a 64-bit kernel, one used
> to be able to set XEN_COMPILE_ARCH. But nowadays this does not work.
> configure sees the target cpu as 64-bit and tries to build pvshim.
> The build prints
> echo "*** Xen x86/32 target no longer supported!"
> and doesn't build anything. Then the subsequent Makefiles try to
> install the non-built pieces.
>
> Fix this anomaly by causing configure to honour the Xen hypervisor way
> of setting the target architecture.
>
> In principle this user behaviour is not handled quite right, because
> configure will still see 64-bit and so all the autoconf-based
> architecture testing will see 64-bit rather than 32-bit x86. But the
> tools are in fact generally quite portable: this particular location
> in configure{.ac,} is the only place in tools/ where 64-bit x86 is
> treated differently from 32-bit x86, so the fix is sufficient and
> correct for this use case.
>
> It remains the case that XEN_COMPILE_ARCH or XEN_TARGET_ARCH to a
> non-x86 architecture, when configure thinks things are x86, or vice
> versa, will not work right.
>
> (This is a bugfix to 8845155c831c
> pvshim: make PV shim build selectable from configure
> which inadvertantly deleted the logic to only build the shim for
> XEN_TARGET_ARCH != x86_32.)
>
> I have rerun autogen.sh, so this patch contains the fix to configure
> as well as the source fix to configure.ac.
>
> Fixes: 8845155c831c59e867ee3dd31ee63e0cc6c7dcf2
> Signed-off-by: Ian Jackson
> CC: Olaf Hering
> CC: Roger Pau Monné
> Release-acked-by: Jürgen Groß
> ---
> tools/configure| 2 +-
> tools/configure.ac | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/configure b/tools/configure
> index 82947ad308..d9ccce6d2b 100755
> --- a/tools/configure
> +++ b/tools/configure
> @@ -9711,7 +9711,7 @@ fi
> else
>
> cpu=`test -z "$target_cpu" && echo "$host_cpu" || echo "$target_cpu"`
> -case "$cpu" in
> +case "${XEN_COMPILE_ARCH-${XEN_TARGET_ARCH-$cpu}}" in
> x86_64)
> pvshim="y";;
> *) pvshim="n";;
> diff --git a/tools/configure.ac b/tools/configure.ac
> index 674bd5809d..a8d8ce5ffe 100644
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -479,7 +479,7 @@ AC_ARG_ENABLE([pvshim],
> [Disable pvshim build (enabled by default on 64bit x86)]),
> [AS_IF([test "x$enable_pvshim" = "xno"], [pvshim=n], [pvshim=y])], [
> cpu=`test -z "$target_cpu" && echo "$host_cpu" || echo "$target_cpu"`
> -case "$cpu" in
> +case "${XEN_COMPILE_ARCH-${XEN_TARGET_ARCH-$cpu}}" in
> x86_64)
> pvshim="y";;
> *) pvshim="n";;
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13 v2 4/4] libxl: gentypes: initialise array elements in json
Anthony PERARD writes ("Re: [Xen-devel] [XEN PATCH for-4.13 v2 4/4] libxl:
gentypes: initialise array elements in json"):
> On Tue, Oct 29, 2019 at 03:54:36PM +, Ian Jackson wrote:
> > +lambda(by): ("&" if by == idl.PASS_BY_REFERENCE else
> > "")+
>
> The syntax for using `lambda' is without "()" for the list of parameters.
> python3 complains about it.
Oh. Thanks.
> With that fix:
> Acked-by: Anthony PERARD
Thanks, fixed and pushed.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 10/12] livepatch: Handle arbitrary size names with the list operation
On 11/14/19 1:06 PM, Pawel Wieczorkiewicz wrote: > The payloads' name strings can be of arbitrary size (typically small > with an upper bound of XEN_LIVEPATCH_NAME_SIZE). > Current implementation of the list operation interface allows to copy > names in the XEN_LIVEPATCH_NAME_SIZE chunks regardless of its actual > size and enforces space allocation requirements on userland tools. > > To unify and simplify the interface, handle the name strings of > arbitrary size by copying them in adhering chunks to the userland. > In order to let the userland allocate enough space for the incoming > data add an auxiliary interface xc_livepatch_list_get_sizes() that > provides the current number of payload entries and the total size of > all name strings. This is achieved by extending the sysctl list > interface with an extra fields: name_total_size. > > The xc_livepatch_list_get_sizes() issues the livepatch sysctl list > operation with the nr field set to 0. In this mode the operation > returns the number of payload entries and calculates the total sizes > for all payloads' names. > When the sysctl operation is issued with a non-zero nr field (for > instance with a value obtained earlier with the prior call to the > xc_livepatch_list_get_sizes()) the new field name_total_size provides > the total size of actually copied data. > > Extend the libxc to handle the name back-to-back data transfers. > > The xen-livepatch tool is modified to start the list operation with a > call to the xc_livepatch_list_get_sizes() to obtain the actual number > of payloads as well as the necessary space for names. > The tool now always requests the actual number of entries and leaves > the preemption handling to the libxc routine. The libxc still returns > 'done' and 'left' parameters with the same semantic allowing the tool > to detect anomalies and react to them. At the moment it is expected > that the tool receives the exact number of entries as requested. > The xen-livepatch tool has been also modified to handle the name > back-to-back transfers correctly. > > Signed-off-by: Pawel Wieczorkiewicz > Reviewed-by: Andra-Irina Paraschiv > Reviewed-by: Bjoern Doebel > Reviewed-by: Martin Pohlack > Signed-off-by: Konrad Rzeszutek Wilk > --- Reviewed-by: Ross Lagerwall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/3] x86/boot: Remove cached CPUID data from the trampoline
On 19.11.2019 16:15, Andrew Cooper wrote:
> On 13/11/2019 13:29, Jan Beulich wrote:
>> On 13.11.2019 14:22, Andrew Cooper wrote:
>>> I am not convinced the behaviour is worth changing, and I don't have
>>> time for this scope creep.
>> There's no scope creep here at all.
>
> Yes - it really is scope creep.
>
> This patch does not change the behaviour of Xen in the case of poor
> virtualisation of the bit. Xen will still crash either way.
So I have to apologize. What I didn't notice is
if (disable & MSR_IA32_MISC_ENABLE_XD_DISABLE) {
write_efer(read_efer() | EFER_NX);
printk(KERN_INFO
"re-enabled NX (Execute Disable) protection\n");
}
in early_init_intel(). I simply didn't expect we'd already have
such a blind EFER write. I therefore agree now that this is a
pre-existing bug that you don't make any worse.
Reviewed-by: Jan Beulich
> I have explained, repeatedly now, why I am not inclined to fix this. It
> is a bug which doesn't exist in practice.
I should have been looking more closely; the lack of sufficient
context did misguide me.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13] xen: Fix race to build arch/x86/efi/relocs-dummy.o
On 19.11.2019 17:27, Jan Beulich wrote: > On 14.11.2019 19:05, Anthony PERARD wrote: >> With $(TARGET).efi depending on efi/relocs-dummy.o, arch/x86/Makefile >> will attempt to build that object. This result in the dependency file >> been generated with relocs-dummy.o depending on efi/relocs-dummy.o. >> >> Then, when arch/x86/efi/Makefile tries to build relocs-dummy.o, well >> efi/relocs-dummy.S doesn't exist. >> >> Have only one makefile responsible for building relocs-dummy.o. > > On a system with too old a tool chain for the EFI build to get > enabled I now get about a dozen instances per build of > > nm: 'efi/relocs-dummy.o': No such file > > I don't suppose you did try out your change in such an oldish > environment? I assume the problem are these two lines: > > $(TARGET).efi: VIRT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A > VIRT_START$$,,p') > $(TARGET).efi: ALT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A > ALT_START$$,,p') > > I'm not sure it is well defined when make would evaluate such > target specific variable assignments (i.e. I'm not sure this > doesn't point out an issue even on EFI capable tool chains). > Then again these not using := should cause them to get > evaluated only upon use, i.e. never. Ah, this was wrong - the $(guard) prefix causes them to get evaluated even when xen.efi cannot be built. So I guess this is just a cosmetic issue then, which would however still be nice to see addressed. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH for-4.13] xen: Fix race to build arch/x86/efi/relocs-dummy.o
On 14.11.2019 19:05, Anthony PERARD wrote: > With $(TARGET).efi depending on efi/relocs-dummy.o, arch/x86/Makefile > will attempt to build that object. This result in the dependency file > been generated with relocs-dummy.o depending on efi/relocs-dummy.o. > > Then, when arch/x86/efi/Makefile tries to build relocs-dummy.o, well > efi/relocs-dummy.S doesn't exist. > > Have only one makefile responsible for building relocs-dummy.o. On a system with too old a tool chain for the EFI build to get enabled I now get about a dozen instances per build of nm: 'efi/relocs-dummy.o': No such file I don't suppose you did try out your change in such an oldish environment? I assume the problem are these two lines: $(TARGET).efi: VIRT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A VIRT_START$$,,p') $(TARGET).efi: ALT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A ALT_START$$,,p') I'm not sure it is well defined when make would evaluate such target specific variable assignments (i.e. I'm not sure this doesn't point out an issue even on EFI capable tool chains). Then again these not using := should cause them to get evaluated only upon use, i.e. never. But that's clearly not the case here; of course make is also the now pretty dated 3.81 one. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC 2/7] WIP: Compilation with ARM DS-6 compiler
Hi Artem, On 19/11/2019 15:16, Artem Mygaiev wrote: Unfortunately this is not the case - we need to specify 2 different targets: 1st is for GNU tools which are still used when building with armclang, for debug symbols dumping etc. (there is no replacement in Arm toolstack for them, and this is not on safety critical path so we are fine) and 2nd is for armclang itself because it has its own triplets definition which is not consistent with those used by GNU tools. Well, in theory they may be different for clang. It just happens they are both similar at the moment. There were also some concern to use CROSS_COMPILE as --target (see [1]), so I think we want to introduce a new option that would happen to be equal to CROSS_COMPILE for clang. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/nested-hap: Fix handling of L0_ERROR
On 19.11.2019 15:58, Andrew Cooper wrote:
> On 19/11/2019 11:13, Jan Beulich wrote:
>> On 18.11.2019 19:15, Andrew Cooper wrote:
>> I take it you imply that L0_ERROR would need raising (as per the
>> auxiliary code fragment adding the "(access_x && *page_order)"
>> check), but I wonder whether that would really be correct. This
>> depends on what L0_ERROR really is supposed to mean: An error
>> because of actual L0 settings (x=0 in our case), or an error
>> because of intended L0 settings (x=1 in our case). After all a
>> violation of just the p2m_access (which also affects r/w/x)
>> doesn't get reported by nestedhap_walk_L0_p2m() as L0_ERROR
>> either (and hence would, as it seems to me, lead to a similar
>> live lock).
>>
>> Therefore I wonder whether your initial idea of doing the
>> shattering right here wouldn't be the better course of action.
>> nestedhap_fix_p2m() could either install the large page and then
>> shatter it right away, or it could install just the individual
>> small page. Together with the different npfec adjustment model
>> suggested below (leading to npfec.present to also get updated in
>> the DONE case) a similar "insn-fetch && present" conditional (to
>> that introduced for XSA-304) could then be used there.
>>
>> Even better - by making the violation checking around the
>> original XSA-304 addition a function (together with the 304
>> addition), such a function might then be reusable here. This
>> might then address the p2m_access related live lock as well.
>
> This is all unrelated to the patch.
I don't think so. At the very least defining what exactly L0_ERROR
is intended to mean is pretty relevant here. The other two
paragraphs may or may not be considered related, depending how
things overall are supposed to work.
>>> @@ -181,6 +180,18 @@ nestedhap_walk_L0_p2m(struct p2m_domain *p2m, paddr_t
>>> L1_gpa, paddr_t *L0_gpa,
>>> *L0_gpa = (mfn_x(mfn) << PAGE_SHIFT) + (L1_gpa & ~PAGE_MASK);
>>> out:
>>> __put_gfn(p2m, L1_gpa >> PAGE_SHIFT);
>>> +
>>> +/*
>>> + * When reporting L0_ERROR, rewrite nfpec to match what would have
>>> occured
>>> + * if hardware had walked the L0, rather than the combined L02.
>>> + */
>>> +if ( rc == NESTEDHVM_PAGEFAULT_L0_ERROR )
>>> +{
>>> +npfec->present = !mfn_eq(mfn, INVALID_MFN);
>> To be in line with the conditional a few lines up from here,
>> wouldn't this better be !mfn_valid(mfn)?
>
> That's not how the return value from get_gfn_*() works, and would break
> the MMIO case.
How that (for the latter part of your reply)? The MMIO case produces
NESTEDHVM_PAGEFAULT_DIRECT_MMIO, i.e. doesn't even enter this if().
Hence my remark elsewhere that the MMIO cases isn't taken care of in
the first place.
>> Should there ever be a case to clear the flag when it was set? If
>> a mapping has gone away between the time the exit condition was
>> detected and the time we re-evaluate things here, I think it
>> should still report "present" back to the caller.
>
> No - absolutely not. We must report the property of the L0 walk, as we
> found it.
>
> Pretending it was present when it wasn't is a sure-fire way of leaving
> further bugs lurking.
But if npfec.present is set, it surely was set at the time of the
hardware walk. And _that's_ what npfec is supposed to represent.
>> Taking both
>> remarks together I'm thinking of
>>
>> if ( mfn_valid(mfn) )
>> npfec->present = 1;
>>
>>> +npfec->gla_valid = 0;
>> For this, one the question is whose linear address is meant here.
>
> The linear address (which was L2's) is nonsensical when we've taken an
> L0 fault. This is why it is clobbered unconditionally.
And this is also why I was saying ...
>> If it's L2's, then it shouldn't be cleared. If it's L1's, then
>> it would seem to me that it should have been avoided to set the
>> field, or at least it should have been cleared the moment we're
>> past L12 handling.
... this. If it's nonsensical, it shouldn't have been set to begin
with, or be squashed earlier than here.
>> And then there is the question of overall flow here. On the basis
>> of npfec not being of any interest anymore to the caller's caller
>> if reporting back DONE (but as per far above it might help our
>> immediate caller) I wonder whether
>
> That is far too subtle and complicated. I'm not included to make the
> code any harder to follow than it already is.
I have to admit I don't see how this is any more complicated than
your variant. I'm merely suggesting adjustments to npfec to get done
at slightly different points in time, with the possible benefit of
an easier route to addressing the live lock(s). It possibly being
more subtle can be compensated by adequate commenting.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC 2/7] WIP: Compilation with ARM DS-6 compiler
Hi Julien On Mon, 2019-11-18 at 06:18 +, Julien Grall wrote: > > On 14/11/2019 14:12, Artem Mygaiev wrote: > > Hello Julien > > Hi, > > > On Thu, 2019-11-14 at 08:19 +0900, Julien Grall wrote: > > > > > > On Thu, 14 Nov 2019, 02:15 Artem Mygaiev, < > > > artem_myga...@epam.com > > > > wrote: > > > > Hi Jan, > > > > > > > > Sorry for delayed reply > > > > > > > > On Thu, 2019-11-07 at 08:31 +0100, Jan Beulich wrote: > > > > > On 06.11.2019 23:08, Artem Mygaiev wrote: > > > > > > On Wed, Nov 6, 2019 at 4:28 PM Jan Beulich < > > > > > > jbeul...@suse.com > > > > > > > > > > > > > wrote: > > > > > > > On 06.11.2019 10:19, Andrii Anisov wrote: > > > > > > > > --- a/Config.mk > > > > > > > > +++ b/Config.mk > > > > > > > > @@ -221,7 +221,9 @@ CFLAGS += -Wall -Wstrict-prototypes > > > > > > > > > > > > > > > > $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration- > > > > > > > > after- > > > > > > > > statement) > > > > > > > > $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after- > > > > > > > > statement) > > > > > > > > +ifneq ($(armds),y) > > > > > > > > $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set- > > > > > > > > variable) > > > > > > > > +endif > > > > > > > > $(call cc-option-add,CFLAGS,CC,-Wno-unused-local- > > > > > > > > typedefs) > > > > > > > > > > > > > > > > LDFLAGS += $(foreach i, $(EXTRA_LIB), -L$(i)) > > > > > > > > > > > > > > ... this would be necessary. > > > > > > > > > > > > I am very sorry, this patch does not have a proper > > > > > > description > > > > > > indeed. > > > > > > > > > > > > For this particular change - arm clang does not undestand > > > > > > -Wno-unused-but-set-variable > > > > > > option at all, that is why it is under !$(armds) > > > > > > > > > > But avoiding to add options which the compiler doesn't > > > > > understand > > > > > is the purpose of using cc-option-add, rather than blindly > > > > > adding > > > > > them to CFLAGS. What am I missing here? > > > > > > > > You are right, the script shall check the compiler option and > > > > avoid > > > > including it to CFLAGS. But armclang require '--target=...' to > > > > be > > > > specified in order to operate properly, and the proper fix > > > > shall be > > > > something like this (instead of 'ifneq' hack above): > > > > > > > > diff --git a/Config.mk b/Config.mk > > > > index 01487a7..abe8e44 100644 > > > > --- a/Config.mk > > > > +++ b/Config.mk > > > > @@ -107,7 +107,7 @@ cc-option = $(shell if test -z "`echo > > > > 'void*p=1;' | \ > > > > # Usage: $(call cc-option-add CFLAGS,CC,-march=winchip-c6) > > > > cc-option-add = $(eval $(call cc-option-add- > > > > closure,$(1),$(2),$(3))) > > > > define cc-option-add-closure > > > > -ifneq ($$(call cc-option,$$($(2)),$(3),n),n) > > > > +ifneq ($$(call cc-option,$$($(2) $(1)),$(3),n),n) > > > > $(1) += $(3) > > > > endif > > > > endef > > > > > > > > so that CFLAGS that are already defined and include ' > > > > --target=...' > > > > option from config/arm*.mk are passed to compiler to make it > > > > happy. > > > > I > > > > am not sure if this breaks anything else so decided to go with > > > > ugly > > > > 'ifneq' hack and check how this can be solved later on. > > > > > > > > > Why not including --target in CC variable as this was suggested > > > for > > > clang? > > > > In case of armclang --target is not the same as CROSS_COMPILE, we > > would > > need to introduce an extra variable instead of CFLAGS and then pass > > it > > to the compiler in similar way -target passed to clang: > > IHMO, --target (armds) and -target (clang) are exactly the same. You > specify the targeted architecture to build. So I think we need a > similar > approach in the both case. Although, in clang there are a default > one > when not specified. Unfortunately this is not the case - we need to specify 2 different targets: 1st is for GNU tools which are still used when building with armclang, for debug symbols dumping etc. (there is no replacement in Arm toolstack for them, and this is not on safety critical path so we are fine) and 2nd is for armclang itself because it has its own triplets definition which is not consistent with those used by GNU tools. > > I agree that using CROSS_COMPILE is a bit of a stretch (even on > clang). > There was actually a lenghty discussion (see [1]) about the meaning > of > CROSS_COMPILE. Maybe we want to introduce a new variable (e.g. > TARGET) > that can be used to pass the triplet. > > > diff --git a/config/StdGNU.mk b/config/StdGNU.mk > > index 3bf3462..4bcfc58 100644 > > --- a/config/StdGNU.mk > > +++ b/config/StdGNU.mk > > @@ -3,8 +3,8 @@ AR = $(CROSS_COMPILE)ar > > LD = $(CROSS_COMPILE)ld > > ifeq ($(clang),y) > > ifeq ($(armds),y) > > -CC = armclang > > -CXX= armclang > > +CC = armclang --target=$(ARMDS_TARGET) > > +CXX= armclang --target=$(ARMDS_TARGET) > > LD_LTO = armlink --verbose --no_scanlib > > LD
Re: [Xen-devel] [PATCH 1/3] x86/boot: Remove cached CPUID data from the trampoline
On 13/11/2019 13:29, Jan Beulich wrote: > On 13.11.2019 14:22, Andrew Cooper wrote: >> I am not convinced the behaviour is worth changing, and I don't have >> time for this scope creep. > There's no scope creep here at all. Yes - it really is scope creep. This patch does not change the behaviour of Xen in the case of poor virtualisation of the bit. Xen will still crash either way. I have explained, repeatedly now, why I am not inclined to fix this. It is a bug which doesn't exist in practice. You are welcome to fix this yourself, in separate change to match the separate scope, when you are not blocking a 4.13 fix with your request. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 144202: regressions - FAIL
flight 144202 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/144202/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt 19 leak-check/check fail REGR. vs. 144197 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 144197 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 144197 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 144197 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 144197 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 144197 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 144197 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 144197 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-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-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 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-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-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 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 version targeted for testing: qemuua5c2a235103ab366ad5318636ec138e52c6dcfa4 baseline version: qemuu369e8f5bbd8a5301bde6fae22b93fe9288c552a5 Last test of basis 144197 2019-11-18 11:36:46 Z1 days Testing same since 144202 2019-11-18 23:36:52 Z0 days1 attempts People who touched revisions under test: Alexey Kardashevskiy David Gibson Gerd Hoffmann Greg Kurz Jiri Denemark Kevin Wolf Laurent Vivier Laurent Vivier Peter Krempa Peter Maydell Vladimir Sementsov-Ogievskiy jobs: build-amd64-xsm pass build-arm64-xsm
Re: [Xen-devel] [PATCH] x86/nested-hap: Fix handling of L0_ERROR
On 19/11/2019 11:13, Jan Beulich wrote:
> On 18.11.2019 19:15, Andrew Cooper wrote:
>> When nestedhvm_hap_nested_page_fault() returns L0_ERROR,
>> hvm_hap_nested_page_fault() operates on the adjusted gpa. However, it
>> operates with the original npfec, which is no longer be correct.
> Nit: Perhaps "may" instead of "is"?
I wrote it that way first, but then changed my mind.
npfec is definitely wrong, by virtue of being from the wrong walk. Its
value may change when being adjusted to the correct walk.
>
>> In particular, it is possible to get a nested fault where the translation is
>> not present in L12 (and therefore L02), while it is present in L01.
> I'm afraid I don't see the connection to the issue at hand, where
> we have a page present in both L01 and L12, just not in L02. And
> there's also no L0_ERROR here - both the initial (propagation) and
> the subsequent (live-locking) exits report DONE according to what
> I thought was the outcome of yesterday's discussion on irc.
Forget the XSA-304 livelock. That aspect of things is still not fixed.
This is a real bug in L0_ERROR handling (which happens to be the second
part of the problem when the livelock is addressed in one possible way.)
> I take it you imply that L0_ERROR would need raising (as per the
> auxiliary code fragment adding the "(access_x && *page_order)"
> check), but I wonder whether that would really be correct. This
> depends on what L0_ERROR really is supposed to mean: An error
> because of actual L0 settings (x=0 in our case), or an error
> because of intended L0 settings (x=1 in our case). After all a
> violation of just the p2m_access (which also affects r/w/x)
> doesn't get reported by nestedhap_walk_L0_p2m() as L0_ERROR
> either (and hence would, as it seems to me, lead to a similar
> live lock).
>
> Therefore I wonder whether your initial idea of doing the
> shattering right here wouldn't be the better course of action.
> nestedhap_fix_p2m() could either install the large page and then
> shatter it right away, or it could install just the individual
> small page. Together with the different npfec adjustment model
> suggested below (leading to npfec.present to also get updated in
> the DONE case) a similar "insn-fetch && present" conditional (to
> that introduced for XSA-304) could then be used there.
>
> Even better - by making the violation checking around the
> original XSA-304 addition a function (together with the 304
> addition), such a function might then be reusable here. This
> might then address the p2m_access related live lock as well.
This is all unrelated to the patch.
>
>> When handling an L0_ERROR, adjust npfec as well as gpa.
> The gpa adjustment referred to here is not in nestedhap_walk_L0_p2m()
> but in nestedhvm_hap_nested_page_fault(), if I'm not mistaken?
The layers where adjustments are made are spread out. I was referring
to the whole process of handling L0_ERROR.
>
>> @@ -181,6 +180,18 @@ nestedhap_walk_L0_p2m(struct p2m_domain *p2m, paddr_t
>> L1_gpa, paddr_t *L0_gpa,
>> *L0_gpa = (mfn_x(mfn) << PAGE_SHIFT) + (L1_gpa & ~PAGE_MASK);
>> out:
>> __put_gfn(p2m, L1_gpa >> PAGE_SHIFT);
>> +
>> +/*
>> + * When reporting L0_ERROR, rewrite nfpec to match what would have
>> occured
>> + * if hardware had walked the L0, rather than the combined L02.
>> + */
>> +if ( rc == NESTEDHVM_PAGEFAULT_L0_ERROR )
>> +{
>> +npfec->present = !mfn_eq(mfn, INVALID_MFN);
> To be in line with the conditional a few lines up from here,
> wouldn't this better be !mfn_valid(mfn)?
That's not how the return value from get_gfn_*() works, and would break
the MMIO case.
> Should there ever be a case to clear the flag when it was set? If
> a mapping has gone away between the time the exit condition was
> detected and the time we re-evaluate things here, I think it
> should still report "present" back to the caller.
No - absolutely not. We must report the property of the L0 walk, as we
found it.
Pretending it was present when it wasn't is a sure-fire way of leaving
further bugs lurking.
> Taking both
> remarks together I'm thinking of
>
> if ( mfn_valid(mfn) )
> npfec->present = 1;
>
>> +npfec->gla_valid = 0;
> For this, one the question is whose linear address is meant here.
The linear address (which was L2's) is nonsensical when we've taken an
L0 fault. This is why it is clobbered unconditionally.
> If it's L2's, then it shouldn't be cleared. If it's L1's, then
> it would seem to me that it should have been avoided to set the
> field, or at least it should have been cleared the moment we're
> past L12 handling.
>
> And then there is the question of overall flow here. On the basis
> of npfec not being of any interest anymore to the caller's caller
> if reporting back DONE (but as per far above it might help our
> immediate caller) I wonder whether
That is far too subtle and complicated. I'm not included to make the
code any harder to follow than it
Re: [Xen-devel] arm/vtimer: Physical timer emulation and the physical counter
Adding, Artem as this is potentially of interest to the FuSa group? Lars > On 14 Nov 2019, at 13:33, Jeff Kubascik wrote: > > Hello, > > I'm working on a port of a RTOS (RTEMS) to Xen on ARM, and came across an > interesting finding in how Xen emulates the physical timer on ARM. > > In testing different configurations of the port, I have the RTOS configured to > use the ARM generic physical timer. The driver operates the physical timer in > the "CompareView" mode, where the timer condition is met when the physical > counter reaches the programmed CompareValue. > > The driver initializes the physical timer by first reading the physical > counter > register CNTPCT, adding the systick interval, and then writing the result to > the > CompareValue register CNTP_CVAL. This appears to be valid behavior based on my > understanding of the ARMV8 Architecture Reference Manual, since the physical > timer "offset" is specified to be zero. > > Xen will trap accesses to the physical timer registers - CNTP_CTL, CNTP_CVAL, > and CNTP_TVAL, which happens in xen/arch/arm/vtimer.c. Xen will add or remove > an > offset phys_timer_base.offset when reading or writing to the > CNTP_CVAL/CNTP_TVAL > registers. This offset is determined when the vtimer is initialized on guest > creation. > > However, Xen does not trap access to the physical counter register CNTPCT. > This > means the guest has direct access to the register. It also means the offset is > not applied here. I believe this is a problem, because the physical timer is > no > longer consistent with the physical counter from the guest's perspective - > there > is a non-zero, unknown offset between the two. > > This was a problem for the RTOS, since it was reading the physical counter > register (Xen does not apply an offset), adding some interval, and then > setting > the CompareValue register (Xen applies the offset), resulting in a long delay > before the timer expires. > > I was able to fix this by adding code in Xen to trap access to CNTPCT and > applying the offset - I can submit the patch if there is interest. However, I > was curious if there was an reason for not trapping/ emulating access to the > physical counter register and applying the offset? > > Sincerely, > Jeff Kubascik > > ___ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] wall clock drift on Coffee Lake / C24x mainboard (HPET broken?), best practices
On 19.11.2019 15:31, Andreas Kinzler wrote: > On 19.11.2019 10:29, Jan Beulich wrote: >> Now would you be up to checking whether, rather than via BIOS >> settings (which not all BIOSes may offer) the same can be >> achieved by using Xen's command line option "max_cstate="? >> Also did you check whether further limiting C state use would > > I cannot try on production machines. I may have a slot on lab machines > but I cannot promise. > > > further improve the situation? And did you possibly also check > > whether telling Xen not to use the HPET would make a difference? > > Which other clocksource do you prefer? Is Xen tested (field-proven) on > that other clocksource? "acpi" (i.e. the PM timer) ought to be fine. That's what Xen was primarily using before HPET became commonly exposed by the ACPI tables. "tsc" ought to be fine too on single-socket systems. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 144204: regressions - FAIL
flight 144204 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/144204/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. 144165 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 144165 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 144165 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 144165 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass version targeted for testing: libvirt af5aa266ed91c572cba3f61e685094e7078d12b4 baseline version: libvirt 5a5e92000d12a671f491c5fb90677f63b1ae7e75 Last test of basis 144165 2019-11-16 04:19:01 Z3 days Failing since144181 2019-11-17 04:18:56 Z2 days3 attempts Testing same since 144204 2019-11-19 04:19:20 Z0 days1 attempts People who touched revisions under test: Daniel P. Berrangé Erik Skultety Jonathon Jongsma Ján Tomko Michal Privoznik Pavel Hrdina jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairfail test-amd64-i386-libvirt-pair fail 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
Re: [Xen-devel] wall clock drift on Coffee Lake / C24x mainboard (HPET broken?), best practices
On 19.11.2019 10:29, Jan Beulich wrote: On 18.11.2019 20:35, Andreas Kinzler wrote: On 15.11.2019 12:01, Andreas Kinzler wrote: On 14.11.2019 12:29, Jan Beulich wrote: On 14.11.2019 00:10, Andreas Kinzler wrote: I came across the following: https://lkml.org/lkml/2019/8/29/536 Could that be the reason for the problem mentioned below? Xen is using HPET as clocksource on the platform/mainboard. Is there an (easy) way to verify if Xen uses PC10? Hence I can only suggest that you try again with limited or no use of C states, to at least get a hint as to a possible I changed the BIOS setting to a limit of PC7 and it is now running. I have to wait for the result. Thanks. Previously the drift after 4 days uptime was 60 sec. Now after 4 days uptime drift is 9 sec. So setting the package c-state limit to PC7 was a success. 9s still seems quite a lot to me, but yes, it's an improvement. It seems it is even better than some other platforms now. Some snapshot measurements from running systems: Xeon E3-1230v5 (Skylake): drift of 4 sec per day (23.999MHz HPET) Xeon E3-1240v6 (Kaby Lake): drift of 1.9 sec per day (23.999MHz HPET) Xeon E3-1240v5 (Skylake): drift of 4.85 sec per day (23.999MHz HPET) Xeon E5-1620v4 (Broadwell): drift of 2.7 sec per day (14.318MHz HPET) All these values are not great, but it is OK for me. Now would you be up to checking whether, rather than via BIOS settings (which not all BIOSes may offer) the same can be achieved by using Xen's command line option "max_cstate="? Also did you check whether further limiting C state use would I cannot try on production machines. I may have a slot on lab machines but I cannot promise. > further improve the situation? And did you possibly also check > whether telling Xen not to use the HPET would make a difference? Which other clocksource do you prefer? Is Xen tested (field-proven) on that other clocksource? Regards Andreas ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Likely regression in efi=no-rs option
On Mon, Nov 18, 2019 at 11:15:43PM -0800, Roman Shaposhnik wrote: > On Sun, Nov 17, 2019 at 5:27 PM Marek Marczykowski-Górecki > wrote: > > > > On Sun, Nov 17, 2019 at 05:06:11PM -0800, Roman Shaposhnik wrote: > > > Rich, Marek, thanks a million for quick replies -- I'll try your > > > suggestions tomorrow in my lab. > > > > To make use of the change, enable "EFI: call SetVirtualAddressMap()" in > > menuconfig (Common Features), visible only with XEN_CONFIG_EXPERT=y. > > Hm. It seems I had trouble building with your patch. Is there any chance I can > simply force it from the make side? > > Or to ask it differently, if I simply do make defconfig what can I just add > that > option to the config file? You need to enable XEN_CONFIG_EXPERT=y anyway, just like this: export XEN_CONFIG_EXPERT=y Then, the option is CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP=y -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/Xen/32: simplify xen_iret_crit_fixup's ring check
On 11.11.19 15:32, Jan Beulich wrote: This can be had with two instead of six insns, by just checking the high CS.RPL bit. Also adjust the comment - there would be no #GP in the mentioned cases, as there's no segment limit violation or alike. Instead there'd be #PF, but that one reports the target EIP of said branch, not the address of the branch insn itself. Signed-off-by: Jan Beulich Reviewed-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 1/2] x86/Xen/32: make xen_iret_crit_fixup independent of frame layout
On 11.11.19 15:32, Jan Beulich wrote:
Now that SS:ESP always get saved by SAVE_ALL, this also needs to be
accounted for in xen_iret_crit_fixup. Otherwise the old_ax value gets
interpreted as EFLAGS, and hence VM86 mode appears to be active all
the time, leading to random "vm86_32: no user_vm86: BAD" log messages
alongside processes randomly crashing.
Since following the previous model (sitting after SAVE_ALL) would
further complicate the code _and_ retain the dependency of
xen_iret_crit_fixup on frame manipulations done by entry_32.S, switch
things around and do the adjustment ahead of SAVE_ALL.
Fixes: 3c88c692c287 ("x86/stackframe/32: Provide consistent pt_regs")
Signed-off-by: Jan Beulich
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Ping: [PATCH 0/2] x86/Xen/32: xen_iret_crit_fixup adjustments
On 11.11.2019 15:30, Jan Beulich wrote:
> The first patch here fixes another regression from 3c88c692c287
> ("x86/stackframe/32: Provide consistent pt_regs"), besides the
> one already addressed by
> https://lists.xenproject.org/archives/html/xen-devel/2019-10/msg01988.html.
> The second patch is a minimal bit of cleanup on top.
>
> 1: make xen_iret_crit_fixup independent of frame layout
> 2: simplify xen_iret_crit_fixup's ring check
Seeing that the other regression fix has been taken into -tip,
what is the situation here? Should 5.4 really ship with this
still unfixed?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [XEN PATCH] x86/domctl: Have XEN_DOMCTL_getpageframeinfo3 preemptible
On 19.11.2019 13:08, Anthony PERARD wrote:
> This hypercall can take a long time to finish because it attempts to
> grab the `hostp2m' lock up to 1024 times. The accumulated wait for the
> lock can take several seconds.
Which means several milliseconds on average per lock acquire. This
points (again) at a (the) bigger problem of p2m lock contention.
Therefore I'm afraid that, while the change here is an improvement,
it's only curing symptoms rather than the cause.
Seeing that p2m_get_page_from_gfn() uses a read lock (but sadly is
the only function doing so), one route could be to investigate
whether further paths could get away with just read locking. Fair
parts of e.g. the nested page fault handling don't really seem to
require a write lock, but there is this comment
/*
* Take a lock on the host p2m speculatively, to avoid potential
* locking order problems later and to handle unshare etc.
*/
pointing out the possible issues with downgrading the lock to just
a read one.
Another route to consider would be to avoid taking the lock once
per iteration, and instead process several GFNs at a time within
a single lock holding sequence.
> Notes:
> I don't know if it's a correct way to make the hypercall preemptible,
> the patch kind of modify the response, but libxc doesn't seems to care.
I think that's acceptable for domctl-s, but would better be
accompanied by a comment adjustment/addition to public/domctl.h.
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -425,6 +425,18 @@ long arch_do_domctl(
> ret = -EFAULT;
> break;
> }
> +
> +if ( hypercall_preempt_check() ) {
You don't want this on the last iteration. You also better don't
do this when there's no p2m lock involved to begin with, i.e.
for non-translated guests. This should then be accompanied by a
comment justifying the special casing.
Also the opening brace (one more below here) goes on its own line.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] arm/vtimer: Physical timer emulation and the physical counter
Hi, On 17/11/2019 22:32, Stewart Hildebrand wrote: CC'ing Julien's new email address For Xen-devel, I have filter to get in my inbox all e-mails where my @arm.com is CCed :). On Thursday, November 14, 2019 2:33 PM, Jeff Kubascik wrote: Hello, I'm working on a port of a RTOS (RTEMS) to Xen on ARM, and came across an interesting finding in how Xen emulates the physical timer on ARM. In testing different configurations of the port, I have the RTOS configured to use the ARM generic physical timer. The driver operates the physical timer in the "CompareView" mode, where the timer condition is met when the physical counter reaches the programmed CompareValue. The driver initializes the physical timer by first reading the physical counter register CNTPCT, adding the systick interval, and then writing the result to the CompareValue register CNTP_CVAL. This appears to be valid behavior based on my understanding of the ARMV8 Architecture Reference Manual, since the physical timer "offset" is specified to be zero. Xen will trap accesses to the physical timer registers - CNTP_CTL, CNTP_CVAL, and CNTP_TVAL, which happens in xen/arch/arm/vtimer.c. Xen will add or remove an offset phys_timer_base.offset when reading or writing to the CNTP_CVAL/CNTP_TVAL registers. This offset is determined when the vtimer is initialized on guest creation. However, Xen does not trap access to the physical counter register CNTPCT. This means the guest has direct access to the register. It also means the offset is not applied here. I believe this is a problem, because the physical timer is no longer consistent with the physical counter from the guest's perspective - there is a non-zero, unknown offset between the two. This was a problem for the RTOS, since it was reading the physical counter register (Xen does not apply an offset), adding some interval, and then setting the CompareValue register (Xen applies the offset), resulting in a long delay before the timer expires. The description makes sense. I was able to fix this by adding code in Xen to trap access to CNTPCT and applying the offset - I can submit the patch if there is interest. However, I was curious if there was an reason for not trapping/ emulating access to the physical counter register and applying the offset? This is definitely a bug in the emulation. But I am not entirely sure we actually want to trap the physical counter register as this has a cost. The only reasons to trap physical timer registers is to ensure the counter starts at 0 for the guest. I am not entirely convinced this is useful as we don' t yet support migration. Even with migration, we may want to not trap the registers until the guest has been migrated to save cost. But, the timer code looks a bit fishy, the hypervisor should use the hypervisor timer but we seem to have code to handle the interrupt for the physical timer (see arch/arm/time.c) but not configure it. Looking at the log, this seems to be a left-over from early Xen that was not removed by 6c76cb8cb5 "xen/arm: Some clean up in time.c". So I think we can handle the physical timer in similar fashion to the virtual timer. This should likely improve performance for OS still using the physcial timer (AFAIK linux arm64 will use the virt timer by default). @Jeff, would you mind to have a look at it? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13 v1 1/2] libxl: introduce new backend type VINPUT
On Mon, Nov 18, 2019 at 7:55 PM Ian Jackson wrote:
>
> Oleksandr Grytsov writes ("[PATCH v1 1/2] libxl: introduce new backend type
> VINPUT"):
> > From: Oleksandr Grytsov
> >
> > There are two kind of VKBD devices: with QEMU backend and user space
> > backend. In current implementation they can't be distinguished as both use
> > VKBD backend type. As result, user space KBD backend is started and
> > stopped as QEMU backend. This commit adds new device kind VINPUT to be
> > used as backend type for user space KBD backend.
>
> Thank you for this patch and thank you for the explanations.
>
> Acked-by: Ian Jackson
>
> I wasn't able to find a posting of this patch before the last posting
> date for 4.13 of the 13th of September. Have I missed it ? We might
> be able to justify a freeze exception on the grounds that this change
> affects only vkb users but it would be a matter for the RM (CC'd).
>
This commit was submitted with patcheset [1].
Earlier I've submitted the patch to solve the issue with patchest [2].
But that patchet was totally wrong.
>
> I would like to change the "linux" to "pv" or something else, for
> 4.13, at least.
I will submit V2 with renaming and comments addressed for second commit [3]
of the patchset.
>
> Ian.
[1] https://marc.info/?l=xen-devel=157054390006691=2
[2] https://marc.info/?l=xen-devel=151326089604524=2
[3] https://marc.info/?l=xen-devel=157054391506708=2
--
Best Regards,
Oleksandr Grytsov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.12-testing test] 144201: regressions - FAIL
flight 144201 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/144201/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 144035 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail pass in 144195 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 144007 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-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-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-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-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 0138da196c8c334589a25144d4d69bf6553e2658 baseline version: xen 278e46ae8f99485915ae662e7905c8333a55048a Last test of basis 144035 2019-11-12 00:36:50 Z7 days Testing same since 144059 2019-11-12 19:10:11 Z6 days 11 attempts
[Xen-devel] [XEN PATCH] x86/domctl: Have XEN_DOMCTL_getpageframeinfo3 preemptible
This hypercall can take a long time to finish because it attempts to
grab the `hostp2m' lock up to 1024 times. The accumulated wait for the
lock can take several seconds.
This can easily happen with a guest with 32 vcpus and plenty of RAM,
during localhost migration.
Signed-off-by: Anthony PERARD
---
Notes:
I don't know if it's a correct way to make the hypercall preemptible,
the patch kind of modify the response, but libxc doesn't seems to care.
Is it fine to modify the domctl_t that the domain (dom0) provides?
If not, where could we store the progress made?
xen/arch/x86/domctl.c | 12
1 file changed, 12 insertions(+)
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 43e368d63bb9..5c0a7462e63b 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -425,6 +425,18 @@ long arch_do_domctl(
ret = -EFAULT;
break;
}
+
+if ( hypercall_preempt_check() ) {
+domctl->u.getpageframeinfo3.num = num - i - 1;
+domctl->u.getpageframeinfo3.array.p =
+guest_handle + ((i + 1) * width);
+if ( __copy_to_guest(u_domctl, domctl, 1) ) {
+ret = -EFAULT;
+break;
+}
+return hypercall_create_continuation(__HYPERVISOR_domctl,
+ "h", u_domctl);
+}
}
break;
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/nested-hap: Fix handling of L0_ERROR
On 18.11.2019 19:15, Andrew Cooper wrote:
> When nestedhvm_hap_nested_page_fault() returns L0_ERROR,
> hvm_hap_nested_page_fault() operates on the adjusted gpa. However, it
> operates with the original npfec, which is no longer be correct.
Nit: Perhaps "may" instead of "is"?
> In particular, it is possible to get a nested fault where the translation is
> not present in L12 (and therefore L02), while it is present in L01.
I'm afraid I don't see the connection to the issue at hand, where
we have a page present in both L01 and L12, just not in L02. And
there's also no L0_ERROR here - both the initial (propagation) and
the subsequent (live-locking) exits report DONE according to what
I thought was the outcome of yesterday's discussion on irc.
I take it you imply that L0_ERROR would need raising (as per the
auxiliary code fragment adding the "(access_x && *page_order)"
check), but I wonder whether that would really be correct. This
depends on what L0_ERROR really is supposed to mean: An error
because of actual L0 settings (x=0 in our case), or an error
because of intended L0 settings (x=1 in our case). After all a
violation of just the p2m_access (which also affects r/w/x)
doesn't get reported by nestedhap_walk_L0_p2m() as L0_ERROR
either (and hence would, as it seems to me, lead to a similar
live lock).
Therefore I wonder whether your initial idea of doing the
shattering right here wouldn't be the better course of action.
nestedhap_fix_p2m() could either install the large page and then
shatter it right away, or it could install just the individual
small page. Together with the different npfec adjustment model
suggested below (leading to npfec.present to also get updated in
the DONE case) a similar "insn-fetch && present" conditional (to
that introduced for XSA-304) could then be used there.
Even better - by making the violation checking around the
original XSA-304 addition a function (together with the 304
addition), such a function might then be reusable here. This
might then address the p2m_access related live lock as well.
> When handling an L0_ERROR, adjust npfec as well as gpa.
The gpa adjustment referred to here is not in nestedhap_walk_L0_p2m()
but in nestedhvm_hap_nested_page_fault(), if I'm not mistaken?
> @@ -181,6 +180,18 @@ nestedhap_walk_L0_p2m(struct p2m_domain *p2m, paddr_t
> L1_gpa, paddr_t *L0_gpa,
> *L0_gpa = (mfn_x(mfn) << PAGE_SHIFT) + (L1_gpa & ~PAGE_MASK);
> out:
> __put_gfn(p2m, L1_gpa >> PAGE_SHIFT);
> +
> +/*
> + * When reporting L0_ERROR, rewrite nfpec to match what would have
> occured
> + * if hardware had walked the L0, rather than the combined L02.
> + */
> +if ( rc == NESTEDHVM_PAGEFAULT_L0_ERROR )
> +{
> +npfec->present = !mfn_eq(mfn, INVALID_MFN);
To be in line with the conditional a few lines up from here,
wouldn't this better be !mfn_valid(mfn)?
Should there ever be a case to clear the flag when it was set? If
a mapping has gone away between the time the exit condition was
detected and the time we re-evaluate things here, I think it
should still report "present" back to the caller. Taking both
remarks together I'm thinking of
if ( mfn_valid(mfn) )
npfec->present = 1;
> +npfec->gla_valid = 0;
For this, one the question is whose linear address is meant here.
If it's L2's, then it shouldn't be cleared. If it's L1's, then
it would seem to me that it should have been avoided to set the
field, or at least it should have been cleared the moment we're
past L12 handling.
And then there is the question of overall flow here. On the basis
of npfec not being of any interest anymore to the caller's caller
if reporting back DONE (but as per far above it might help our
immediate caller) I wonder whether
static int
nestedhap_walk_L0_p2m(struct p2m_domain *p2m, paddr_t L1_gpa, paddr_t *L0_gpa,
p2m_type_t *p2mt, p2m_access_t *p2ma,
unsigned int *page_order, struct npfec *npfec)
{
mfn_t mfn;
int rc;
/* walk L0 P2M table */
mfn = get_gfn_type_access(p2m, L1_gpa >> PAGE_SHIFT, p2mt, p2ma,
0, page_order);
rc = NESTEDHVM_PAGEFAULT_DIRECT_MMIO;
if ( *p2mt == p2m_mmio_direct )
goto direct_mmio_out;
rc = NESTEDHVM_PAGEFAULT_MMIO;
if ( *p2mt == p2m_mmio_dm )
goto out;
rc = NESTEDHVM_PAGEFAULT_L0_ERROR;
/*
* When reporting L0_ERROR, rewrite nfpec to match what would have occurred
* if hardware had walked the L0, rather than the combined L02.
*/
npfec->gla_valid = 0;
npfec->kind = npfec_kind_unknown;
if ( !mfn_valid(mfn) )
goto out;
npfec->present = 1;
if ( npfec->write_access && p2m_is_readonly(*p2mt) )
goto out;
if ( p2m_is_paging(*p2mt) || p2m_is_shared(*p2mt) || !p2m_is_ram(*p2mt) )
goto out;
rc = NESTEDHVM_PAGEFAULT_DONE;
direct_mmio_out:
*L0_gpa = (mfn_x(mfn) << PAGE_SHIFT) + (L1_gpa & ~PAGE_MASK);
out:
[Xen-devel] [tip: x86/urgent] x86/stackframe/32: Repair 32-bit Xen PV
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 189eb7f3d7ec70ceeaa195221ddfd95016e10ace
Gitweb:
https://git.kernel.org/tip/189eb7f3d7ec70ceeaa195221ddfd95016e10ace
Author:Jan Beulich
AuthorDate:Mon, 18 Nov 2019 16:21:12 +01:00
Committer: Ingo Molnar
CommitterDate: Tue, 19 Nov 2019 09:01:59 +01:00
x86/stackframe/32: Repair 32-bit Xen PV
Once again RPL checks have been introduced which don't account for a
32-bit kernel living in ring 1 when running in a PV Xen domain. The
case in FIXUP_FRAME has been preventing boot. Adjust BUG_IF_WRONG_CR3
as well to guard against future uses of the macro on a code path
reachable when running in PV mode under Xen; I have to admit that I
stopped at a certain point trying to figure out whether there are
present ones.
Signed-off-by: Jan Beulich
Cc:
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: xen-devel@lists.xenproject.org
Fixes: 3c88c692c287 ("x86/stackframe/32: Provide consistent pt_regs")
Signed-off-by: Ingo Molnar
---
arch/x86/entry/entry_32.S | 4 ++--
arch/x86/include/asm/segment.h | 12
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index f83ca5a..3f847d8 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -172,7 +172,7 @@
ALTERNATIVE "jmp .Lend_\@", "", X86_FEATURE_PTI
.if \no_user_check == 0
/* coming from usermode? */
- testl $SEGMENT_RPL_MASK, PT_CS(%esp)
+ testl $USER_SEGMENT_RPL_MASK, PT_CS(%esp)
jz .Lend_\@
.endif
/* On user-cr3? */
@@ -217,7 +217,7 @@
testl $X86_EFLAGS_VM, 4*4(%esp)
jnz .Lfrom_usermode_no_fixup_\@
#endif
- testl $SEGMENT_RPL_MASK, 3*4(%esp)
+ testl $USER_SEGMENT_RPL_MASK, 3*4(%esp)
jnz .Lfrom_usermode_no_fixup_\@
orl $CS_FROM_KERNEL, 3*4(%esp)
diff --git a/arch/x86/include/asm/segment.h b/arch/x86/include/asm/segment.h
index ac38929..6669164 100644
--- a/arch/x86/include/asm/segment.h
+++ b/arch/x86/include/asm/segment.h
@@ -31,6 +31,18 @@
*/
#define SEGMENT_RPL_MASK 0x3
+/*
+ * When running on Xen PV, the actual privilege level of the kernel is 1,
+ * not 0. Testing the Requested Privilege Level in a segment selector to
+ * determine whether the context is user mode or kernel mode with
+ * SEGMENT_RPL_MASK is wrong because the PV kernel's privilege level
+ * matches the 0x3 mask.
+ *
+ * Testing with USER_SEGMENT_RPL_MASK is valid for both native and Xen PV
+ * kernels because privilege level 2 is never used.
+ */
+#define USER_SEGMENT_RPL_MASK 0x2
+
/* User mode is privilege level 3: */
#define USER_RPL 0x3
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.11-testing test] 144200: regressions - FAIL
flight 144200 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/144200/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 144025 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-shadow 18 guest-localmigrate/x10 fail in 144194 pass in 144200 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-saverestore fail pass in 144194 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail in 144194 never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 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-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 74507046dbd2c5d2991eeabd1af39af0d6b29d70 baseline version: xen
Re: [Xen-devel] wall clock drift on Coffee Lake / C24x mainboard (HPET broken?), best practices
On 18.11.2019 20:35, Andreas Kinzler wrote: > On 15.11.2019 12:01, Andreas Kinzler wrote: >> On 14.11.2019 12:29, Jan Beulich wrote: >>> On 14.11.2019 00:10, Andreas Kinzler wrote: I came across the following: https://lkml.org/lkml/2019/8/29/536 Could that be the reason for the problem mentioned below? Xen is using HPET as clocksource on the platform/mainboard. Is there an (easy) way to verify if Xen uses PC10? >>> Hence I can only suggest that you try again with limited or no >>> use of C states, to at least get a hint as to a possible >> I changed the BIOS setting to a limit of PC7 and it is now running. I >> have to wait for the result. Thanks. > > Previously the drift after 4 days uptime was 60 sec. Now after 4 days > uptime drift is 9 sec. So setting the package c-state limit to PC7 was a > success. 9s still seems quite a lot to me, but yes, it's an improvement. Now would you be up to checking whether, rather than via BIOS settings (which not all BIOSes may offer) the same can be achieved by using Xen's command line option "max_cstate="? Also did you check whether further limiting C state use would further improve the situation? And did you possibly also check whether telling Xen not to use the HPET would make a difference? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V2 1/2] x86/altp2m: Add hypercall to set a range of sve bits
On 19.11.2019 10:05, Alexandru Stefan ISAILA wrote: > On 18.11.2019 16:09, Jan Beulich wrote: >> On 18.11.2019 14:39, Alexandru Stefan ISAILA wrote: >>> For this HVMOP_ALTP2M_INTERFACE_VERSION shout be increased. I will leave >>> it to Tamas to decide if we will need a different structure for >>> xen_hvm_altp2m_suppress_ve_multi to keep the compatibility. >> >> Wasn't is that due to the possible guest exposure it was decided >> that the interface version approach was not suitable here, and hence >> it shouldn't be bumped any further? >> > > That is correct but there was also requested to add the new opaque field > so I don't know how to have that an still keep the same version. New sub-op? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen hiding thermal capabilities from Dom0
On 19.11.2019 06:23, Rishi wrote: > ok, thanks for clearing it up. Would a patch be accepted if this > option of showing EAX leaf is selectively done through command line > (default disabled)? In general I'd expect this to be rather unlikely, but I guess much would depend on the actual reasoning done in the description. > On longer run, what is an expected sane model of virtualizing this? > With some guidance, may be I or someone else can code to bring the > functionality back. Which functionality? So far you've talked of only CPUID bits I think, without explaining at all what functionality you want to have that depends on these. In general, as said earlier, CPU management is the hypervisor's responsibility, so I'd rather not see this virtualized, but the hypervisor be put into a position of doing whatever is needed. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] x86/stackframe/32: repair 32-bit Xen PV
* Jan Beulich wrote:
> Once again RPL checks have been introduced which don't account for a
> 32-bit kernel living in ring 1 when running in a PV Xen domain. The
> case in FIXUP_FRAME has been preventing boot. Adjust BUG_IF_WRONG_CR3
> as well to guard against future uses of the macro on a code path
> reachable when running in PV mode under Xen; I have to admit that I
> stopped at a certain point trying to figure out whether there are
> present ones.
>
> Fixes: 3c88c692c287 ("x86/stackframe/32: Provide consistent pt_regs")
> Signed-off-by: Jan Beulich
> ---
> v3: Move USER_SEGMENT_RPL_MASK definition to segment.h. Further explain
> the BUG_IF_WRONG_CR3 adjustment.
> v2: Avoid #ifdef and alter comment along the lines of Andy's suggestion.
Since the breakage was introduced in v5.3, I've added a Cc: stable line.
Thanks,
Ingo
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
