Re: [PATCH v2 1/4] x86/xen: remove 32-bit Xen PV guest support
On 03.07.20 00:59, Boris Ostrovsky wrote:
On 7/1/20 7:06 AM, Juergen Gross wrote:
Xen is requiring 64-bit machines today and since Xen 4.14 it can be
built without 32-bit PV guest support. There is no need to carry the
burden of 32-bit PV guest support in the kernel any longer, as new
guests can be either HVM or PVH, or they can use a 64 bit kernel.
Remove the 32-bit Xen PV support from the kernel.
Signed-off-by: Juergen Gross
---
arch/x86/entry/entry_32.S | 109 +--
arch/x86/include/asm/proto.h | 2 +-
arch/x86/include/asm/segment.h | 2 +-
arch/x86/kernel/head_32.S | 31 ---
arch/x86/xen/Kconfig | 3 +-
arch/x86/xen/Makefile | 3 +-
arch/x86/xen/apic.c| 17 --
arch/x86/xen/enlighten_pv.c| 48 +
Should we drop PageHighMem() test in set_aliased_prot()?
(And there are few other places where is is used, in mmu_pv.c)
Yes, will drop those.
@@ -555,13 +547,8 @@ static void xen_load_tls(struct thread_struct *t, unsigned
int cpu)
* exception between the new %fs descriptor being loaded and
* %fs being effectively cleared at __switch_to().
*/
- if (paravirt_get_lazy_mode() == PARAVIRT_LAZY_CPU) {
-#ifdef CONFIG_X86_32
- lazy_load_gs(0);
-#else
I think this also needs an adjustment to the preceding comment.
Yes.
-#ifdef CONFIG_X86_PAE
-static void xen_set_pte_atomic(pte_t *ptep, pte_t pte)
-{
- trace_xen_mmu_set_pte_atomic(ptep, pte);
- __xen_set_pte(ptep, pte);
Probably not for this series but I wonder whether __xen_set_pte() should
continue to use hypercall now that we are 64-bit only.
As Andrew wrote already the hypercall will be cheaper.
I'll adjust the comment, though.
@@ -654,14 +621,12 @@ static int __xen_pgd_walk(struct mm_struct *mm, pgd_t
*pgd,
Comment above should be updated.
Yes.
Juergen
[ovmf test] 151550: all pass - PUSHED
flight 151550 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/151550/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 0622a7b1b203ad4ab1675533e958792fc1afc12b baseline version: ovmf c8edb70945099fd35a0997d3f3db105efc144e13 Last test of basis 151532 2020-07-02 07:45:27 Z0 days Testing same since 151550 2020-07-02 20:09:20 Z0 days1 attempts People who touched revisions under test: Pierre Gondois jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git c8edb70945..0622a7b1b2 0622a7b1b203ad4ab1675533e958792fc1afc12b -> xen-tested-master
[linux-linus test] 151540: regressions - FAIL
flight 151540 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151540/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 151214 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 151214 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 151214 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 151214 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151214 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 151214 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 151214 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-amd64-i386-libvirt-xsm 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-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop 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-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linuxcd77006e01b3198c75fb7819b3d0ff89709539bb baseline version: linux1b5044021070efa3259f3e9548dc35d1eb6aa844 Last test of basis 151214 2020-06-18 02:27:46 Z 15 days Failing since151236 2020-06-19 19:10:35 Z 13 days 17 attempts Testing same since 151540 2020-07-02 13:31:21 Z0 days1 attempts
[qemu-upstream-unstable test] 151544: tolerable FAIL - PUSHED
flight 151544 qemu-upstream-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151544/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 149875 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 149875 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 149875 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 149875 test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-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-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-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-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 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-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail 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-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass version targeted for testing: qemuuea6d3cd1ed79d824e605a70c3626bc437c386260 baseline version: qemuu410cc30fdc590417ae730d635bbc70257adf6750 Last test of basis 149875 2020-04-29 12:38:30 Z 64 days Testing same since 151544 2020-07-02 15:39:12 Z0 days1 attempts People who touched revisions under test: Anthony PERARD Paolo Bonzini 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
Re: [PATCH v2 1/4] x86/xen: remove 32-bit Xen PV guest support
On 7/2/20 7:24 PM, Andrew Cooper wrote:
> On 02/07/2020 23:59, Boris Ostrovsky wrote:
>> On 7/1/20 7:06 AM, Juergen Gross wrote:
>>>
>>> -#ifdef CONFIG_X86_PAE
>>> -static void xen_set_pte_atomic(pte_t *ptep, pte_t pte)
>>> -{
>>> - trace_xen_mmu_set_pte_atomic(ptep, pte);
>>> - __xen_set_pte(ptep, pte);
>> Probably not for this series but I wonder whether __xen_set_pte() should
>> continue to use hypercall now that we are 64-bit only.
> The hypercall path is a SYSCALL (and SYSRET out).
>
> The "writeable" PTE path is a #PF, followed by an x86 instruction
> emulation, which then reaches the same logic as the hypercall path (and
> an IRET out).
Then we should at least update the comment.
-boris
Re: [PATCH v2 1/4] x86/xen: remove 32-bit Xen PV guest support
On 02/07/2020 23:59, Boris Ostrovsky wrote:
> On 7/1/20 7:06 AM, Juergen Gross wrote:
>>
>> -#ifdef CONFIG_X86_PAE
>> -static void xen_set_pte_atomic(pte_t *ptep, pte_t pte)
>> -{
>> -trace_xen_mmu_set_pte_atomic(ptep, pte);
>> -__xen_set_pte(ptep, pte);
>
> Probably not for this series but I wonder whether __xen_set_pte() should
> continue to use hypercall now that we are 64-bit only.
The hypercall path is a SYSCALL (and SYSRET out).
The "writeable" PTE path is a #PF, followed by an x86 instruction
emulation, which then reaches the same logic as the hypercall path (and
an IRET out).
~Andrew
Re: [PATCH v2 1/4] x86/xen: remove 32-bit Xen PV guest support
On 7/1/20 7:06 AM, Juergen Gross wrote:
> Xen is requiring 64-bit machines today and since Xen 4.14 it can be
> built without 32-bit PV guest support. There is no need to carry the
> burden of 32-bit PV guest support in the kernel any longer, as new
> guests can be either HVM or PVH, or they can use a 64 bit kernel.
>
> Remove the 32-bit Xen PV support from the kernel.
>
> Signed-off-by: Juergen Gross
> ---
> arch/x86/entry/entry_32.S | 109 +--
> arch/x86/include/asm/proto.h | 2 +-
> arch/x86/include/asm/segment.h | 2 +-
> arch/x86/kernel/head_32.S | 31 ---
> arch/x86/xen/Kconfig | 3 +-
> arch/x86/xen/Makefile | 3 +-
> arch/x86/xen/apic.c| 17 --
> arch/x86/xen/enlighten_pv.c| 48 +
Should we drop PageHighMem() test in set_aliased_prot()?
(And there are few other places where is is used, in mmu_pv.c)
> @@ -555,13 +547,8 @@ static void xen_load_tls(struct thread_struct *t,
> unsigned int cpu)
>* exception between the new %fs descriptor being loaded and
>* %fs being effectively cleared at __switch_to().
>*/
> - if (paravirt_get_lazy_mode() == PARAVIRT_LAZY_CPU) {
> -#ifdef CONFIG_X86_32
> - lazy_load_gs(0);
> -#else
I think this also needs an adjustment to the preceding comment.
>
> -#ifdef CONFIG_X86_PAE
> -static void xen_set_pte_atomic(pte_t *ptep, pte_t pte)
> -{
> - trace_xen_mmu_set_pte_atomic(ptep, pte);
> - __xen_set_pte(ptep, pte);
Probably not for this series but I wonder whether __xen_set_pte() should
continue to use hypercall now that we are 64-bit only.
> @@ -654,14 +621,12 @@ static int __xen_pgd_walk(struct mm_struct *mm, pgd_t
> *pgd,
Comment above should be updated.
-boris
Re: [PATCH][next] xen-netfront: remove redundant assignment to variable 'act'
From: Colin King
Date: Thu, 2 Jul 2020 15:22:23 +0100
> From: Colin Ian King
>
> The variable act is being initialized with a value that is
> never read and it is being updated later with a new value. The
> initialization is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
Applied, thank you.
[xen-unstable test] 151528: regressions - FAIL
flight 151528 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151528/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151506 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151506 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 151506 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 151506 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 151506 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151506 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151506 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 151506 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 151506 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 151506 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-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-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-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-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-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 0dbed3ad3366734fd23ee3fd1f9989c8c96b6052 baseline version: xen 23ca7ec0ba620db52a646d80e22f9703a6589f66 Last test of basis 151506 2020-07-01 10:55:16 Z1 days Testing same since 151528 2020-07-02 04:45:56 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Stefano Stabellini Volodymyr Babchuk jobs: build-amd64-xsm pass
Re: [PATCH v2 1/2] xen/xenbus: avoid large structs and arrays on the stack
On 7/1/20 8:16 AM, Juergen Gross wrote: > xenbus_map_ring_valloc() and its sub-functions are putting quite large > structs and arrays on the stack. This is problematic at runtime, but > might also result in build failures (e.g. with clang due to the option > -Werror,-Wframe-larger-than=... used). > > Fix that by moving most of the data from the stack into a dynamically > allocated struct. Performance is no issue here, as > xenbus_map_ring_valloc() is used only when adding a new PV device to > a backend driver. > > While at it move some duplicated code from pv/hvm specific mapping > functions to the single caller. > > Reported-by: Arnd Bergmann > Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky
Re: [PATCH v4 02/10] x86/vmx: add IPT cpu feature
- 2 lip 2020 o 10:34, Jan Beulich jbeul...@suse.com napisał(a): > On 02.07.2020 10:10, Roger Pau Monné wrote: >> On Wed, Jul 01, 2020 at 10:42:55PM +0100, Andrew Cooper wrote: >>> On 30/06/2020 13:33, Michał Leszczyński wrote: diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c index ca94c2bedc..b73d824357 100644 --- a/xen/arch/x86/hvm/vmx/vmcs.c +++ b/xen/arch/x86/hvm/vmx/vmcs.c @@ -291,6 +291,12 @@ static int vmx_init_vmcs_config(void) _vmx_cpu_based_exec_control &= ~(CPU_BASED_CR8_LOAD_EXITING | CPU_BASED_CR8_STORE_EXITING); +rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap); + +/* Check whether IPT is supported in VMX operation. */ +vmtrace_supported = cpu_has_ipt && +(_vmx_misc_cap & VMX_MISC_PT_SUPPORTED); >>> >>> There is a subtle corner case here. vmx_init_vmcs_config() is called on >>> all CPUs, and is supposed to level things down safely if we find any >>> asymmetry. >>> >>> If instead you go with something like this: >>> >>> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c >>> index b73d824357..6960109183 100644 >>> --- a/xen/arch/x86/hvm/vmx/vmcs.c >>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c >>> @@ -294,8 +294,8 @@ static int vmx_init_vmcs_config(void) >>> rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap); >>> >>> /* Check whether IPT is supported in VMX operation. */ >>> - vmtrace_supported = cpu_has_ipt && >>> - (_vmx_misc_cap & VMX_MISC_PT_SUPPORTED); >>> + if ( !(_vmx_misc_cap & VMX_MISC_PT_SUPPORTED) ) >>> + vmtrace_supported = false; >> >> This is also used during hotplug, so I'm not sure it's safe to turn >> vmtrace_supported off during runtime, where VMs might be already using >> it. IMO it would be easier to just set it on the BSP, and then refuse >> to bring up any AP that doesn't have the feature. > > +1 > > IOW I also don't think that "vmx_init_vmcs_config() ... is supposed to > level things down safely". Instead I think the expectation is for > CPU onlining to fail if a CPU lacks features compared to the BSP. As > can be implied from what Roger says, doing like what you suggest may > be fine during boot, but past that only at times where we know there's > no user of a certain feature, and where discarding the feature flag > won't lead to other inconsistencies (which may very well mean "never"). > > Jan Ok, I will modify it in a way Roger suggested for the previous patch version. CPU onlining will fail if there is an inconsistency. Best regards, Michał Leszczyński CERT Polska
Re: [PATCH v4 02/10] x86/vmx: add IPT cpu feature
- 2 lip 2020 o 16:31, Julien Grall jul...@xen.org napisał(a): > On 02/07/2020 15:17, Jan Beulich wrote: >> On 02.07.2020 16:14, Julien Grall wrote: >>> On 02/07/2020 14:30, Jan Beulich wrote: On 02.07.2020 11:57, Julien Grall wrote: > On 02/07/2020 10:18, Jan Beulich wrote: >> On 02.07.2020 10:54, Julien Grall wrote: >>> On 02/07/2020 09:50, Jan Beulich wrote: On 02.07.2020 10:42, Julien Grall wrote: > On 02/07/2020 09:29, Jan Beulich wrote: > Another way to do it, would be the toolstack to do the mapping. At which > point, you still need an hypercall to do the mapping (probably the > hypercall acquire). There may not be any mapping to do in such a contrived, fixed-range environment. This scenario was specifically to demonstrate that the way the mapping gets done may be arch-specific (here: a no-op) despite the allocation not being so. >>> You are arguing on extreme cases which I don't think is really helpful >>> here. Yes if you want to map at a fixed address in a guest you may not >>> need the acquire hypercall. But in most of the other cases (see has for >>> the tools) you will need it. >>> >>> So what's the problem with requesting to have the acquire hypercall >>> implemented in common code? >> >> Didn't we start out by you asking that there be as little common code >> as possible for the time being? > > Well as I said I am not in favor of having the allocation in common > code, but if you want to keep it then you also want to implement > map/unmap in the common code ([1], [2]). > >> I have no issue with putting the >> acquire implementation there ... > This was definitely not clear given how you argued with extreme cases... > > Cheers, > > [1] <9a3f4d58-e5ad-c7a1-6c5f-42aa92101...@xen.org> > [2] > > -- > Julien Grall Guys, could you express your final decision on this topic? While I understand the discussion and the arguments you've raised, I would like to know what particular elements should be moved where. So are we going abstract way, or non-abstract-x86 only way? Best regards, Michał Leszczyński CERT Polska
[ovmf test] 151532: all pass - PUSHED
flight 151532 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/151532/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf c8edb70945099fd35a0997d3f3db105efc144e13 baseline version: ovmf 00217f1919270007d7a911f89b32e39b9dcaa907 Last test of basis 151465 2020-06-30 01:43:31 Z2 days Testing same since 151532 2020-07-02 07:45:27 Z0 days1 attempts People who touched revisions under test: Irene Park jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 00217f1919..c8edb70945 c8edb70945099fd35a0997d3f3db105efc144e13 -> xen-tested-master
[qemu-mainline test] 151518: regressions - FAIL
flight 151518 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/151518/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-vhd 10 debian-di-installfail REGR. vs. 151065 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-armhf-armhf-xl-vhd 10 debian-di-installfail REGR. vs. 151065 test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 151065 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 151065 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-rtds 15 guest-stop fail pass in 151500 Tests which did not succeed, but are not blocking: 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-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 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 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail
Re: Build problems in kdd.c with xen-4.14.0-rc4
On Tue, Jun 30, Michael Young wrote:
> I get the following errors when trying to build xen-4.14.0-rc4
This happens to work for me.
Olaf
---
tools/debugger/kdd/kdd.c | 8
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/tools/debugger/kdd/kdd.c
+++ b/tools/debugger/kdd/kdd.c
@@ -742,25 +742,25 @@ static void kdd_tx(kdd_state *s)
int i;
/* Fix up the checksum before we send */
for (i = 0; i < s->txp.h.len; i++)
sum += s->txp.payload[i];
s->txp.h.sum = sum;
kdd_log_pkt(s, "TX", >txp);
len = s->txp.h.len + sizeof (kdd_hdr);
if (s->txp.h.dir == KDD_DIR_PKT)
/* Append the mysterious 0xaa byte to each packet */
-s->txb[len++] = 0xaa;
+s->txp.payload[len++] = 0xaa;
(void) blocking_write(s->fd, s->txb, len);
}
/* Send an acknowledgement to the client */
static void kdd_send_ack(kdd_state *s, uint32_t id, uint16_t type)
{
s->txp.h.dir = KDD_DIR_ACK;
s->txp.h.type = type;
s->txp.h.len = 0;
s->txp.h.id = id;
@@ -775,25 +775,25 @@ static void kdd_send_cmd(kdd_state *s, uint32_t subtype,
size_t extra)
s->txp.h.type = KDD_PKT_CMD;
s->txp.h.len = sizeof (kdd_cmd) + extra;
s->txp.h.id = (s->next_id ^= 1);
s->txp.h.sum = 0;
s->txp.cmd.subtype = subtype;
kdd_tx(s);
}
/* Cause the client to print a string */
static void kdd_send_string(kdd_state *s, char *fmt, ...)
{
uint32_t len = 0x - sizeof (kdd_msg);
-char *buf = (char *) s->txb + sizeof (kdd_hdr) + sizeof (kdd_msg);
+char *buf = (char *) >txp + sizeof (kdd_hdr) + sizeof (kdd_msg);
va_list ap;
va_start(ap, fmt);
len = vsnprintf(buf, len, fmt, ap);
va_end(ap);
s->txp.h.dir = KDD_DIR_PKT;
s->txp.h.type = KDD_PKT_MSG;
s->txp.h.len = sizeof (kdd_msg) + len;
s->txp.h.id = (s->next_id ^= 1);
s->txp.h.sum = 0;
s->txp.msg.subtype = KDD_MSG_PRINT;
@@ -807,25 +807,25 @@ static void kdd_break(kdd_state *s)
{
uint16_t ilen;
KDD_LOG(s, "Break\n");
if (s->running)
kdd_halt(s->guest);
s->running = 0;
{
unsigned int i;
/* XXX debug pattern */
for (i = 0; i < 0x100 ; i++)
-s->txb[sizeof (kdd_hdr) + i] = i;
+s->txp.payload[sizeof (kdd_hdr) + i] = i;
}
/* Send a state-change message to the client so it knows we've stopped */
s->txp.h.dir = KDD_DIR_PKT;
s->txp.h.type = KDD_PKT_STC;
s->txp.h.len = sizeof (kdd_stc);
s->txp.h.id = (s->next_id ^= 1);
s->txp.stc.subtype = KDD_STC_STOP;
s->txp.stc.stop.cpu = s->cpuid;
s->txp.stc.stop.ncpus = kdd_count_cpus(s->guest);
s->txp.stc.stop.kthread = 0; /* Let the debugger figure it out */
s->txp.stc.stop.status = KDD_STC_STATUS_BREAKPOINT;
signature.asc
Description: PGP signature
[PATCH v2 02/11] xenbus: add freeze/thaw/restore callbacks support
From: Munehisa Kamata
Since commit b3e96c0c7562 ("xen: use freeze/restore/thaw PM events for
suspend/resume/chkpt"), xenbus uses PMSG_FREEZE, PMSG_THAW and
PMSG_RESTORE events for Xen suspend. However, they're actually assigned
to xenbus_dev_suspend(), xenbus_dev_cancel() and xenbus_dev_resume()
respectively, and only suspend and resume callbacks are supported at
driver level. To support PM suspend and PM hibernation, modify the bus
level PM callbacks to invoke not only device driver's suspend/resume but
also freeze/thaw/restore.
Note that we'll use freeze/restore callbacks even for PM suspend whereas
suspend/resume callbacks are normally used in the case, becausae the
existing xenbus device drivers already have suspend/resume callbacks
specifically designed for Xen suspend. So we can allow the device
drivers to keep the existing callbacks wihtout modification.
[Anchal Agarwal: Changelog]:
RFC v1->v2: Refactored the callbacks code
v1->v2: Use dev_warn instead of pr_warn, naming/initialization
conventions
Signed-off-by: Agarwal Anchal
Signed-off-by: Munehisa Kamata
---
drivers/xen/xenbus/xenbus_probe.c | 96 ++-
include/xen/xenbus.h | 3 +
2 files changed, 84 insertions(+), 15 deletions(-)
diff --git a/drivers/xen/xenbus/xenbus_probe.c
b/drivers/xen/xenbus/xenbus_probe.c
index 38725d97d909..715919aacd28 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
#include
#include
@@ -599,16 +600,33 @@ int xenbus_dev_suspend(struct device *dev)
struct xenbus_driver *drv;
struct xenbus_device *xdev
= container_of(dev, struct xenbus_device, dev);
+ bool xen_suspend = xen_is_xen_suspend();
DPRINTK("%s", xdev->nodename);
if (dev->driver == NULL)
return 0;
drv = to_xenbus_driver(dev->driver);
- if (drv->suspend)
- err = drv->suspend(xdev);
- if (err)
- dev_warn(dev, "suspend failed: %i\n", err);
+ if (xen_suspend) {
+ if (drv->suspend)
+ err = drv->suspend(xdev);
+ } else {
+ if (drv->freeze) {
+ err = drv->freeze(xdev);
+ if (!err) {
+ free_otherend_watch(xdev);
+ free_otherend_details(xdev);
+ return 0;
+ }
+ }
+ }
+
+ if (err) {
+ dev_warn(>dev, "%s %s failed: %d\n", xen_suspend ?
+ "suspend" : "freeze", xdev->nodename, err);
+ return err;
+ }
+
return 0;
}
EXPORT_SYMBOL_GPL(xenbus_dev_suspend);
@@ -619,6 +637,7 @@ int xenbus_dev_resume(struct device *dev)
struct xenbus_driver *drv;
struct xenbus_device *xdev
= container_of(dev, struct xenbus_device, dev);
+ bool xen_suspend = xen_is_xen_suspend();
DPRINTK("%s", xdev->nodename);
@@ -627,23 +646,34 @@ int xenbus_dev_resume(struct device *dev)
drv = to_xenbus_driver(dev->driver);
err = talk_to_otherend(xdev);
if (err) {
- dev_warn(dev, "resume (talk_to_otherend) failed: %i\n", err);
+ dev_warn(>dev, "%s (talk_to_otherend) %s failed: %d\n",
+ xen_suspend ? "resume" : "restore",
+ xdev->nodename, err);
return err;
}
- xdev->state = XenbusStateInitialising;
+ if (xen_suspend) {
+ xdev->state = XenbusStateInitialising;
+ if (drv->resume)
+ err = drv->resume(xdev);
+ } else {
+ if (drv->restore)
+ err = drv->restore(xdev);
+ }
- if (drv->resume) {
- err = drv->resume(xdev);
- if (err) {
- dev_warn(dev, "resume failed: %i\n", err);
- return err;
- }
+ if (err) {
+ dev_warn(>dev, "%s %s failed: %d\n",
+ xen_suspend ? "resume" : "restore",
+ xdev->nodename, err);
+ return err;
}
err = watch_otherend(xdev);
if (err) {
- dev_warn(dev, "resume (watch_otherend) failed: %d\n", err);
+ dev_warn(>dev, "%s (watch_otherend) %s failed: %d.\n",
+ xen_suspend ? "resume" : "restore",
+ xdev->nodename, err);
+
return err;
}
@@ -653,8 +683,44 @@ EXPORT_SYMBOL_GPL(xenbus_dev_resume);
int xenbus_dev_cancel(struct device *dev)
{
- /* Do nothing */
- DPRINTK("cancel");
+ int err;
+ struct xenbus_driver *drv;
+ struct xenbus_device *xendev =
[PATCH v2 10/11] xen: Update sched clock offset to avoid system instability in hibernation
Save/restore xen_sched_clock_offset in syscore suspend/resume during PM
hibernation. Commit '867cefb4cb1012: ("xen: Fix x86 sched_clock() interface
for xen")' fixes xen guest time handling during migration. A similar issue
is seen during PM hibernation when system runs CPU intensive workload.
Post resume pvclock resets the value to 0 however, xen sched_clock_offset
is never updated. System instability is seen during resume from hibernation
when system is under heavy CPU load. Since xen_sched_clock_offset is not
updated, system does not see the monotonic clock value and the scheduler
would then think that heavy CPU hog tasks need more time in CPU, causing
the system to freeze
Signed-off-by: Anchal Agarwal
---
arch/x86/xen/suspend.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index 10cd14326472..4d8b1d2390b9 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -95,6 +95,7 @@ static int xen_syscore_suspend(void)
gnttab_suspend();
xen_manage_runstate_time(-1);
+ xen_save_sched_clock_offset();
xrfp.domid = DOMID_SELF;
xrfp.gpfn = __pa(HYPERVISOR_shared_info) >> PAGE_SHIFT;
ret = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, );
@@ -110,6 +111,12 @@ static void xen_syscore_resume(void)
xen_hvm_map_shared_info();
pvclock_resume();
+ /*
+* Restore xen_sched_clock_offset during resume to maintain
+* monotonic clock value
+*/
+ xen_restore_sched_clock_offset();
+
xen_manage_runstate_time(0);
gnttab_resume();
}
--
2.20.1
[PATCH v2 09/11] xen: Introduce wrapper for save/restore sched clock offset
Introduce wrappers for save/restore xen_sched_clock_offset to be
used by PM hibernation code to avoid system instability during resume.
Signed-off-by: Anchal Agarwal
---
arch/x86/xen/time.c| 15 +--
arch/x86/xen/xen-ops.h | 2 ++
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index c8897aad13cd..676950eb0cb5 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -386,12 +386,23 @@ static const struct pv_time_ops xen_time_ops __initconst
= {
static struct pvclock_vsyscall_time_info *xen_clock __read_mostly;
static u64 xen_clock_value_saved;
+/*This is needed to maintain a monotonic clock value during PM hibernation */
+void xen_save_sched_clock_offset(void)
+{
+ xen_clock_value_saved = xen_clocksource_read() - xen_sched_clock_offset;
+}
+
+void xen_restore_sched_clock_offset(void)
+{
+ xen_sched_clock_offset = xen_clocksource_read() - xen_clock_value_saved;
+}
+
void xen_save_time_memory_area(void)
{
struct vcpu_register_time_memory_area t;
int ret;
- xen_clock_value_saved = xen_clocksource_read() - xen_sched_clock_offset;
+ xen_save_sched_clock_offset();
if (!xen_clock)
return;
@@ -434,7 +445,7 @@ void xen_restore_time_memory_area(void)
out:
/* Need pvclock_resume() before using xen_clocksource_read(). */
pvclock_resume();
- xen_sched_clock_offset = xen_clocksource_read() - xen_clock_value_saved;
+ xen_restore_sched_clock_offset();
}
static void xen_setup_vsyscall_time_info(void)
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 41e9e9120f2d..f4b78b19493b 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -70,6 +70,8 @@ void xen_save_time_memory_area(void);
void xen_restore_time_memory_area(void);
void xen_init_time_ops(void);
void xen_hvm_init_time_ops(void);
+void xen_save_sched_clock_offset(void);
+void xen_restore_sched_clock_offset(void);
irqreturn_t xen_debug_interrupt(int irq, void *dev_id);
--
2.20.1
[PATCH v2 07/11] xen-netfront: add callbacks for PM suspend and hibernation
From: Munehisa Kamata
Add freeze, thaw and restore callbacks for PM suspend and hibernation
support. The freeze handler simply disconnects the frotnend from the
backend and frees resources associated with queues after disabling the
net_device from the system. The restore handler just changes the
frontend state and let the xenbus handler to re-allocate the resources
and re-connect to the backend. This can be performed transparently to
the rest of the system. The handlers are used for both PM suspend and
hibernation so that we can keep the existing suspend/resume callbacks
for Xen suspend without modification. Freezing netfront devices is
normally expected to finish within a few hundred milliseconds, but it
can rarely take more than 5 seconds and hit the hard coded timeout,
it would depend on backend state which may be congested and/or have
complex configuration. While it's rare case, longer default timeout
seems a bit more reasonable here to avoid hitting the timeout.
Also, make it configurable via module parameter so that we can cover
broader setups than what we know currently.
[Anchal Agarwal: Changelog]:
RFCv1->RFCv2: Variable name fix and checkpatch.pl fixes]
Signed-off-by: Anchal Agarwal
Signed-off-by: Munehisa Kamata
---
drivers/net/xen-netfront.c | 98 +-
1 file changed, 97 insertions(+), 1 deletion(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 482c6c8b0fb7..65edcdd6e05f 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include
#include
@@ -56,6 +57,12 @@
#include
#include
+enum netif_freeze_state {
+ NETIF_FREEZE_STATE_UNFROZEN,
+ NETIF_FREEZE_STATE_FREEZING,
+ NETIF_FREEZE_STATE_FROZEN,
+};
+
/* Module parameters */
#define MAX_QUEUES_DEFAULT 8
static unsigned int xennet_max_queues;
@@ -63,6 +70,12 @@ module_param_named(max_queues, xennet_max_queues, uint,
0644);
MODULE_PARM_DESC(max_queues,
"Maximum number of queues per virtual interface");
+static unsigned int netfront_freeze_timeout_secs = 10;
+module_param_named(freeze_timeout_secs,
+ netfront_freeze_timeout_secs, uint, 0644);
+MODULE_PARM_DESC(freeze_timeout_secs,
+"timeout when freezing netfront device in seconds");
+
static const struct ethtool_ops xennet_ethtool_ops;
struct netfront_cb {
@@ -160,6 +173,10 @@ struct netfront_info {
struct netfront_stats __percpu *tx_stats;
atomic_t rx_gso_checksum_fixup;
+
+ int freeze_state;
+
+ struct completion wait_backend_disconnected;
};
struct netfront_rx_info {
@@ -721,6 +738,21 @@ static int xennet_close(struct net_device *dev)
return 0;
}
+static int xennet_disable_interrupts(struct net_device *dev)
+{
+ struct netfront_info *np = netdev_priv(dev);
+ unsigned int num_queues = dev->real_num_tx_queues;
+ unsigned int queue_index;
+ struct netfront_queue *queue;
+
+ for (queue_index = 0; queue_index < num_queues; ++queue_index) {
+ queue = >queues[queue_index];
+ disable_irq(queue->tx_irq);
+ disable_irq(queue->rx_irq);
+ }
+ return 0;
+}
+
static void xennet_move_rx_slot(struct netfront_queue *queue, struct sk_buff
*skb,
grant_ref_t ref)
{
@@ -1301,6 +1333,8 @@ static struct net_device *xennet_create_dev(struct
xenbus_device *dev)
np->queues = NULL;
+ init_completion(>wait_backend_disconnected);
+
err = -ENOMEM;
np->rx_stats = netdev_alloc_pcpu_stats(struct netfront_stats);
if (np->rx_stats == NULL)
@@ -1794,6 +1828,50 @@ static int xennet_create_queues(struct netfront_info
*info,
return 0;
}
+static int netfront_freeze(struct xenbus_device *dev)
+{
+ struct netfront_info *info = dev_get_drvdata(>dev);
+ unsigned long timeout = netfront_freeze_timeout_secs * HZ;
+ int err = 0;
+
+ xennet_disable_interrupts(info->netdev);
+
+ netif_device_detach(info->netdev);
+
+ info->freeze_state = NETIF_FREEZE_STATE_FREEZING;
+
+ /* Kick the backend to disconnect */
+ xenbus_switch_state(dev, XenbusStateClosing);
+
+ /* We don't want to move forward before the frontend is diconnected
+* from the backend cleanly.
+*/
+ timeout = wait_for_completion_timeout(>wait_backend_disconnected,
+ timeout);
+ if (!timeout) {
+ err = -EBUSY;
+ xenbus_dev_error(dev, err, "Freezing timed out;"
+"the device may become inconsistent state");
+ return err;
+ }
+
+ /* Tear down queues */
+ xennet_disconnect_backend(info);
+ xennet_destroy_queues(info);
+
+ info->freeze_state = NETIF_FREEZE_STATE_FROZEN;
+
+ return err;
+}
+
+static int
[PATCH v2 06/11] xen-blkfront: add callbacks for PM suspend and hibernation
From: Munehisa Kamata
S4 power transisiton states are much different than xen
suspend/resume. Former is visible to the guest and frontend drivers should
be aware of the state transistions and should be able to take appropriate
actions when needed. In transition to S4 we need to make sure that at least
all the in-flight blkif requests get completed, since they probably contain
bits of the guest's memory image and that's not going to get saved any
other way. Hence, re-issuing of in-flight requests as in case of xen resume
will not work here. This is in contrast to xen-suspend where we need to
freeze with as little processing as possible to avoid dirtying RAM late in
the migration cycle and we know that in-flight data can wait.
Add freeze, thaw and restore callbacks for PM suspend and hibernation
support. All frontend drivers that needs to use PM_HIBERNATION/PM_SUSPEND
events, need to implement these xenbus_driver callbacks. The freeze handler
stops block-layer queue and disconnect the frontend from the backend while
freeing ring_info and associated resources. Before disconnecting from the
backend, we need to prevent any new IO from being queued and wait for
existing IO to complete. Freeze/unfreeze of the queues will guarantee
that there are no requests in use on the shared ring. However, for sanity
we should check state of the ring before disconnecting to make sure that
there are no outstanding requests to be processed on the ring.
The restore handler re-allocates ring_info, unquiesces and unfreezes the
queue and re-connect to the backend, so that rest of the kernel can
continue to use the block device transparently.
Note:For older backends,if a backend doesn't have commit'12ea729645ace'
xen/blkback: unmap all persistent grants when frontend gets disconnected,
the frontend may see massive amount of grant table warning when freeing
resources.
[ 36.852659] deferring g.e. 0xf9 (pfn 0x)
[ 36.855089] xen:grant_table: WARNING:e.g. 0x112 still in use!
In this case, persistent grants would need to be disabled.
[Anchal Agarwal: Changelog]:
RFC v1->v2: Removed timeout per request before disconnect during
blkfront freeze.
Added queue freeze/quiesce to the blkfront_freeze
Code cleanup
RFC v2->v3: None
RFC v3->v1: Code cleanup, Refractoring
v1->v2: * remove err variable in blkfront_freeze
* BugFix: error handling if rings are still busy
after queue freeze/quiesce and returnign driver to
connected state
* add TODO if blkback fails to disconnect on freeze
* Code formatting
Signed-off-by: Anchal Agarwal
Signed-off-by: Munehisa Kamata
---
drivers/block/xen-blkfront.c | 122 +--
1 file changed, 118 insertions(+), 4 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 3b889ea950c2..9e3ed1b9f509 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -48,6 +48,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -80,6 +82,8 @@ enum blkif_state {
BLKIF_STATE_DISCONNECTED,
BLKIF_STATE_CONNECTED,
BLKIF_STATE_SUSPENDED,
+ BLKIF_STATE_FREEZING,
+ BLKIF_STATE_FROZEN,
};
struct grant {
@@ -219,6 +223,7 @@ struct blkfront_info
struct list_head requests;
struct bio_list bio_list;
struct list_head info_list;
+ struct completion wait_backend_disconnected;
};
static unsigned int nr_minors;
@@ -1005,6 +1010,7 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16
sector_size,
info->sector_size = sector_size;
info->physical_sector_size = physical_sector_size;
blkif_set_queue_limits(info);
+ init_completion(>wait_backend_disconnected);
return 0;
}
@@ -1353,6 +1359,8 @@ static void blkif_free(struct blkfront_info *info, int
suspend)
unsigned int i;
struct blkfront_ring_info *rinfo;
+ if (info->connected == BLKIF_STATE_FREEZING)
+ goto free_rings;
/* Prevent new requests being issued until we fix things up. */
info->connected = suspend ?
BLKIF_STATE_SUSPENDED : BLKIF_STATE_DISCONNECTED;
@@ -1360,6 +1368,7 @@ static void blkif_free(struct blkfront_info *info, int
suspend)
if (info->rq)
blk_mq_stop_hw_queues(info->rq);
+free_rings:
for_each_rinfo(info, rinfo, i)
blkif_free_ring(rinfo);
@@ -1563,8 +1572,10 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
struct blkfront_ring_info *rinfo = (struct blkfront_ring_info *)dev_id;
struct blkfront_info *info = rinfo->dev_info;
- if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
+ if (unlikely(info->connected != BLKIF_STATE_CONNECTED &&
+ info->connected != BLKIF_STATE_FREEZING)) {
return IRQ_HANDLED;
+ }
[PATCH v2 08/11] x86/xen: save and restore steal clock during PM hibernation
Save/restore steal times in syscore suspend/resume during PM
hibernation. Commit '5e25f5db6abb9: ("xen/time: do not
decrease steal time after live migration on xen")' fixes xen
guest steal time handling during migration. A similar issue is seen
during PM hibernation.
Currently, steal time accounting code in scheduler expects steal clock
callback to provide monotonically increasing value. If the accounting
code receives a smaller value than previous one, it uses a negative
value to calculate steal time and results in incorrectly updated idle
and steal time accounting. This breaks userspace tools which read
/proc/stat.
top - 08:05:35 up 2:12, 3 users, load average: 0.00, 0.07, 0.23
Tasks: 80 total, 1 running, 79 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,30100.0%id, 0.0%wa, 0.0%hi,
0.0%si,-1253874204672.0%st
This can actually happen when a Xen PVHVM guest gets restored from
hibernation, because such a restored guest is just a fresh domain from
Xen perspective and the time information in runstate info starts over
from scratch.
Changelog:
v1->v2: Removed patches that introduced new function calls for saving/restoring
sched clock offset and using existing ones that are used during LM
Signed-off-by: Anchal Agarwal
---
arch/x86/xen/suspend.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index e8c924e93fc5..10cd14326472 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -94,10 +94,9 @@ static int xen_syscore_suspend(void)
int ret;
gnttab_suspend();
-
+ xen_manage_runstate_time(-1);
xrfp.domid = DOMID_SELF;
xrfp.gpfn = __pa(HYPERVISOR_shared_info) >> PAGE_SHIFT;
-
ret = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, );
if (!ret)
HYPERVISOR_shared_info = _dummy_shared_info;
@@ -111,7 +110,7 @@ static void xen_syscore_resume(void)
xen_hvm_map_shared_info();
pvclock_resume();
-
+ xen_manage_runstate_time(0);
gnttab_resume();
}
--
2.20.1
[PATCH v2 00/11] Fix PM hibernation in Xen guests
Hello,
This series fixes PM hibernation for hvm guests running on xen hypervisor.
The running guest could now be hibernated and resumed successfully at a
later time. The fixes for PM hibernation are added to block and
network device drivers i.e xen-blkfront and xen-netfront. Any other driver
that needs to add S4 support if not already, can follow same method of
introducing freeze/thaw/restore callbacks.
The patches had been tested against upstream kernel and xen4.11. Large
scale testing is also done on Xen based Amazon EC2 instances. All this testing
involved running memory exhausting workload in the background.
Doing guest hibernation does not involve any support from hypervisor and
this way guest has complete control over its state. Infrastructure
restrictions for saving up guest state can be overcome by guest initiated
hibernation.
These patches were send out as RFC before and all the feedback had been
incorporated in the patches. The last v1 could be found here:
[v1]: https://lkml.org/lkml/2020/5/19/1312
All comments and feedback from v1 had been incorporated in v2 series.
Any comments/suggestions are welcome
Known issues:
1.KASLR causes intermittent hibernation failures. VM fails to resumes and
has to be restarted. I will investigate this issue separately and shouldn't
be a blocker for this patch series.
2. During hibernation, I observed sometimes that freezing of tasks fails due
to busy XFS workqueuei[xfs-cil/xfs-sync]. This is also intermittent may be 1
out of 200 runs and hibernation is aborted in this case. Re-trying hibernation
may work. Also, this is a known issue with hibernation and some
filesystems like XFS has been discussed by the community for years with not an
effectve resolution at this point.
Testing How to:
---
1. Setup xen hypervisor on a physical machine[ I used Ubuntu 16.04 +upstream
xen-4.11]
2. Bring up a HVM guest w/t kernel compiled with hibernation patches
[I used ubuntu18.04 netboot bionic images and also Amazon Linux on-prem images].
3. Create a swap file size=RAM size
4. Update grub parameters and reboot
5. Trigger pm-hibernation from within the VM
Example:
Set up a file-backed swap space. Swap file size>=Total memory on the system
sudo dd if=/dev/zero of=/swap bs=$(( 1024 * 1024 )) count=4096 # 4096MiB
sudo chmod 600 /swap
sudo mkswap /swap
sudo swapon /swap
Update resume device/resume offset in grub if using swap file:
resume=/dev/xvda1 resume_offset=200704 no_console_suspend=1
Execute:
sudo pm-hibernate
OR
echo disk > /sys/power/state && echo reboot > /sys/power/disk
Compute resume offset code:
"
#!/usr/bin/env python
import sys
import array
import fcntl
#swap file
f = open(sys.argv[1], 'r')
buf = array.array('L', [0])
#FIBMAP
ret = fcntl.ioctl(f.fileno(), 0x01, buf)
print buf[0]
"
Aleksei Besogonov (1):
PM / hibernate: update the resume offset on SNAPSHOT_SET_SWAP_AREA
Anchal Agarwal (4):
x86/xen: Introduce new function to map HYPERVISOR_shared_info on
Resume
x86/xen: save and restore steal clock during PM hibernation
xen: Introduce wrapper for save/restore sched clock offset
xen: Update sched clock offset to avoid system instability in
hibernation
Munehisa Kamata (5):
xen/manage: keep track of the on-going suspend mode
xenbus: add freeze/thaw/restore callbacks support
x86/xen: add system core suspend and resume callbacks
xen-blkfront: add callbacks for PM suspend and hibernation
xen-netfront: add callbacks for PM suspend and hibernation
Thomas Gleixner (1):
genirq: Shutdown irq chips in suspend/resume during hibernation
arch/x86/xen/enlighten_hvm.c | 7 ++
arch/x86/xen/suspend.c| 53 +
arch/x86/xen/time.c | 15 +++-
arch/x86/xen/xen-ops.h| 3 +
drivers/block/xen-blkfront.c | 122 +-
drivers/net/xen-netfront.c| 98 +++-
drivers/xen/events/events_base.c | 1 +
drivers/xen/manage.c | 60 +++
drivers/xen/xenbus/xenbus_probe.c | 96 +++
include/linux/irq.h | 2 +
include/xen/xen-ops.h | 3 +
include/xen/xenbus.h | 3 +
kernel/irq/chip.c | 2 +-
kernel/irq/internals.h| 1 +
kernel/irq/pm.c | 31 +---
kernel/power/user.c | 6 +-
16 files changed, 470 insertions(+), 33 deletions(-)
--
2.20.1
[PATCH v2 03/11] x86/xen: Introduce new function to map HYPERVISOR_shared_info on Resume
Introduce a small function which re-uses shared page's PA allocated
during guest initialization time in reserve_shared_info() and not
allocate new page during resume flow.
It also does the mapping of shared_info_page by calling
xen_hvm_init_shared_info() to use the function.
Changelog:
v1->v2: Remove extra check for shared_info_pfn to be NULL
Signed-off-by: Anchal Agarwal
---
arch/x86/xen/enlighten_hvm.c | 6 ++
arch/x86/xen/xen-ops.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 3e89b0067ff0..d91099928746 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -28,6 +28,12 @@
static unsigned long shared_info_pfn;
+void xen_hvm_map_shared_info(void)
+{
+ xen_hvm_init_shared_info();
+ HYPERVISOR_shared_info = __va(PFN_PHYS(shared_info_pfn));
+}
+
void xen_hvm_init_shared_info(void)
{
struct xen_add_to_physmap xatp;
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 53b224fd6177..41e9e9120f2d 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -54,6 +54,7 @@ void xen_enable_sysenter(void);
void xen_enable_syscall(void);
void xen_vcpu_restore(void);
+void xen_hvm_map_shared_info(void);
void xen_hvm_init_shared_info(void);
void xen_unplug_emulated_devices(void);
--
2.20.1
[PATCH v2 01/11] xen/manage: keep track of the on-going suspend mode
From: Munehisa Kamata
Guest hibernation is different from xen suspend/resume/live migration.
Xen save/restore does not use pm_ops as is needed by guest hibernation.
Hibernation in guest follows ACPI path and is guest inititated , the
hibernation image is saved within guest as compared to later modes
which are xen toolstack assisted and image creation/storage is in
control of hypervisor/host machine.
To differentiate between Xen suspend and PM hibernation, keep track
of the on-going suspend mode by mainly using a new PM notifier.
Introduce simple functions which help to know the on-going suspend mode
so that other Xen-related code can behave differently according to the
current suspend mode.
Since Xen suspend doesn't have corresponding PM event, its main logic
is modfied to acquire pm_mutex and set the current mode.
Though, acquirng pm_mutex is still right thing to do, we may
see deadlock if PM hibernation is interrupted by Xen suspend.
PM hibernation depends on xenwatch thread to process xenbus state
transactions, but the thread will sleep to wait pm_mutex which is
already held by PM hibernation context in the scenario. Xen shutdown
code may need some changes to avoid the issue.
[Anchal Agarwal: Changelog]:
RFC v1->v2: Code refactoring
v1->v2: Remove unused functions for PM SUSPEND/PM hibernation
Signed-off-by: Anchal Agarwal
Signed-off-by: Munehisa Kamata
---
drivers/xen/manage.c | 60 +++
include/xen/xen-ops.h | 1 +
2 files changed, 61 insertions(+)
diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index cd046684e0d1..69833fd6cfd1 100644
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -40,6 +41,20 @@ enum shutdown_state {
/* Ignore multiple shutdown requests. */
static enum shutdown_state shutting_down = SHUTDOWN_INVALID;
+enum suspend_modes {
+ NO_SUSPEND = 0,
+ XEN_SUSPEND,
+ PM_HIBERNATION,
+};
+
+/* Protected by pm_mutex */
+static enum suspend_modes suspend_mode = NO_SUSPEND;
+
+bool xen_is_xen_suspend(void)
+{
+ return suspend_mode == XEN_SUSPEND;
+}
+
struct suspend_info {
int cancelled;
};
@@ -99,6 +114,10 @@ static void do_suspend(void)
int err;
struct suspend_info si;
+ lock_system_sleep();
+
+ suspend_mode = XEN_SUSPEND;
+
shutting_down = SHUTDOWN_SUSPEND;
err = freeze_processes();
@@ -162,6 +181,10 @@ static void do_suspend(void)
thaw_processes();
out:
shutting_down = SHUTDOWN_INVALID;
+
+ suspend_mode = NO_SUSPEND;
+
+ unlock_system_sleep();
}
#endif /* CONFIG_HIBERNATE_CALLBACKS */
@@ -387,3 +410,40 @@ int xen_setup_shutdown_event(void)
EXPORT_SYMBOL_GPL(xen_setup_shutdown_event);
subsys_initcall(xen_setup_shutdown_event);
+
+static int xen_pm_notifier(struct notifier_block *notifier,
+ unsigned long pm_event, void *unused)
+{
+ switch (pm_event) {
+ case PM_SUSPEND_PREPARE:
+ case PM_HIBERNATION_PREPARE:
+ case PM_RESTORE_PREPARE:
+ suspend_mode = PM_HIBERNATION;
+ break;
+ case PM_POST_SUSPEND:
+ case PM_POST_RESTORE:
+ case PM_POST_HIBERNATION:
+ /* Set back to the default */
+ suspend_mode = NO_SUSPEND;
+ break;
+ default:
+ pr_warn("Receive unknown PM event 0x%lx\n", pm_event);
+ return -EINVAL;
+ }
+
+ return 0;
+};
+
+static struct notifier_block xen_pm_notifier_block = {
+ .notifier_call = xen_pm_notifier
+};
+
+static int xen_setup_pm_notifier(void)
+{
+ if (!xen_hvm_domain())
+ return -ENODEV;
+
+ return register_pm_notifier(_pm_notifier_block);
+}
+
+subsys_initcall(xen_setup_pm_notifier);
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 39a5580f8feb..2521d6a306cd 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -40,6 +40,7 @@ u64 xen_steal_clock(int cpu);
int xen_setup_shutdown_event(void);
+bool xen_is_xen_suspend(void);
extern unsigned long *xen_contiguous_bitmap;
#if defined(CONFIG_XEN_PV) || defined(CONFIG_ARM) || defined(CONFIG_ARM64)
--
2.20.1
Re: Kexec and libxenctlr.so
Hi Wei, On 26/06/2020 12:08, Wei Liu wrote: On Thu, Jun 11, 2020 at 03:57:37PM +0100, Julien Grall wrote: Hi all, kexec-tools has an option to load dynamically libxenctlr.so (not .so.4.x) (see [1]). Given that the library has never been considered stable, it is probably a disaster that is waiting to happen. Looking at the tree kexec is using the follow libxc functions: - xc_kexec_get_range() - xc_kexec_load() - xc_kexec_unload() - xc_kexec_status() - xc_kexec_exec() - xc_version() - xc_interface_open() - xc_interface_close() - xc_get_max_cpus() - xc_get_machine_memory_map() I think it is uncontroversial that we want a new stable library for all the xc_kexec_* functions (maybe libxenexec)? That sounds fine to me. Looking at the list of functions, all the xc_kexec_* ones are probably already rather stable. That's my understanding as well. Although, we may want to rethink some of the hypercalls (such as KEXEC_cmd_kexec_get_range) in the future as they have different layout between 32-bit and 64-bit. Thanksfully this wasn't exposed outside of libxc, so it shouldn't be an issue to have a stable library. For xc_interface_open / close, they are perhaps used only to obtain an xc handle such that it can be used to make hypercalls. You new kexec library is going to expose its own handle with a xencall handle wrapped inside, so you can do away with an xc handle. I have already a PoC for the new library. I had to tweak a bit the list of helpers as some use hypercalls arguments directly. Below, the proposed interface: /* Callers who don't care don't need to #include */ struct xentoollog_logger; typedef struct xenkexec_handle xenkexec_handle; typedef struct xenkexec_segments xenkexec_segments; xenkexec_handle *xenkexec_open(struct xentoollog_logger *logger, unsigned int open_flags); int xenkexec_close(xenkexec_handle *khdl); int xenkexec_exec(xenkexec_handle *khdl, int type); int xenkexec_get_range(xenkexec_handle *khdl, int range, int nr, uint64_t *size, uint64_t *start); int xenkexec_load(xenkexec_handle *khdl, uint8_t type, uint16_t arch, uint64_t entry_maddr, uint32_t nr_segments, xenkexec_segments *segments); int xenkexec_unload(xenkexec_handle *khdl, int type); int xenkexec_status(xenkexec_handle *khdl, int type); xenkexec_segments *xenkexec_allocate_segments(xenkexec_handle *khdl, unsigned int nr); void xenkexec_free_segments(xenkexec_handle *khdl, xenkexec_segments *segs); int xenkexec_update_segment(xenkexec_handle *khdl, xenkexec_segments *segs, unsigned int idx, void *buffer, size_t buffer_size, uint64_t dest_maddr, size_t dest_size); However I am not entirely sure where to put the others. I am thinking to introduce libxensysctl for xc_get_max_cpus() as it is a XEN_SYSCTL. We could possibly include xc_get_machine_memory_map() (despite it is a XENMEM_). Introducing an libxensysctl before we stabilise sysctl interface seems wrong to me. We can bury the call inside libxenkexec itself for the time being. That would work for me. For xc_version(), I am thinking to extend libxentoolcore to also include "stable xen API". If you can do without an xc handle, do you still need to call xc_version? Looking at kexec, xc_version() is used by crashdump to determine which architecture is used by Xen (in this case 32-bit x86 vs 64-bit x86). The was introcuded by commit: commit cdbc9b011fe43407908632d842e3a39e495e48d9 Author: Ian Campbell Date: Fri Mar 16 10:10:24 2007 + Set crash dump ELF header e_machine field based on underlying hypervisor architecture. This is necessary when running Xen with a 64 bit hypervisor and 32 bit domain 0 since the CPU crash notes will be 64 bit. Detecting the hypervisor archiecture requires libxenctrl and therefore this support is optional and disabled by default. Signed-off-by: Ian Campbell Acked-by: Magnus Damm Signed-off-by: Simon Horman As we drop support for 32-bit Xen quite a long time ago, we may be able to remove the call to xc_version(). Cheers, -- Julien Grall
Re: [Xen ARM64] Save coredump log when xen/dom0 crash on ARM64?
Hello, On 02/07/2020 02:41, jinchen wrote: Hello xen experts: Is there any way to save xen and dom0 core dump log when xen or dom0 crash on ARM64 platform? Usually all the crash stack trace (Xen and Dom0) should be output on the Xen Console. ?0?2 ?0?2 I find that the kdump seems can't?0?2run on ARM64 platform? We don't have support for kdump/kexec on Arm in Xen yet. ?0?2 ?0?2 Are there any?0?2patches?0?2or other way to achive this goal? I am not aware of any patches, but they would be welcomed. For other way, it depends what exactly you expect. Do you need more than the stack trace? Cheers, -- Julien Grall
Re: [PATCH v4 03/10] tools/libxl: add vmtrace_pt_size parameter
- 2 lip 2020 o 11:00, Roger Pau Monné roger@citrix.com napisał(a):
> On Tue, Jun 30, 2020 at 02:33:46PM +0200, Michał Leszczyński wrote:
>> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
>> index 59bdc28c89..7b8289d436 100644
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -92,6 +92,7 @@ struct xen_domctl_createdomain {
>> uint32_t max_evtchn_port;
>> int32_t max_grant_frames;
>> int32_t max_maptrack_frames;
>> +uint8_t vmtrace_pt_order;
>
> I've been thinking about this, and even though this is a domctl (so
> not a stable interface) we might want to consider using a size (or a
> number of pages) here rather than an order. IPT also supports
> TOPA mode (kind of a linked list of buffers) that would allow for
> sizes not rounded to order boundaries to be used, since then only each
> item in the linked list needs to be rounded to an order boundary, so
> you could for example use three 4K pages in TOPA mode AFAICT.
>
> Roger.
In previous versions it was "size" but it was requested to change it
to "order" in order to shrink the variable size from uint64_t to
uint8_t, because there is limited space for xen_domctl_createdomain
structure.
How should I proceed?
Best regards,
Michał Leszczyński
CERT Polska
Re: [PATCH v2 0/4] Remove 32-bit Xen PV guest support
On 02.07.20 16:48, Brian Gerst wrote: On Wed, Jul 1, 2020 at 7:07 AM Juergen Gross wrote: The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the kernel running as 32-bit PV guest, so dropping this mode makes sense from security point of view, too. One thing that you missed is removing VDSO_NOTE_NONEGSEG_BIT from vdso32/note.S. With that removed there is no difference from the 64-bit version. Oh, this means we can probably remove arch/x86/xen/vdso.h completely. Otherwise this series looks good to me. Thanks, Juergen
Re: [PATCH v4 10/10] tools/proctrace: add proctrace tool
On 30/06/2020 13:33, Michał Leszczyński wrote: > diff --git a/tools/proctrace/COPYING b/tools/proctrace/COPYING > new file mode 100644 > index 00..c0a841112c > --- /dev/null > +++ b/tools/proctrace/COPYING The top-level COPYING file is GPL2. There shouldn't be any need to include a second copy here. > diff --git a/tools/proctrace/Makefile b/tools/proctrace/Makefile > new file mode 100644 > index 00..2983c477fe > --- /dev/null > +++ b/tools/proctrace/Makefile > @@ -0,0 +1,48 @@ > +# Copyright (C) CERT Polska - NASK PIB > +# Author: Michał Leszczyński > +# > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; under version 2 of the License. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > + > +XEN_ROOT=$(CURDIR)/../.. > +include $(XEN_ROOT)/tools/Rules.mk > + > +CFLAGS += -Werror > +CFLAGS += $(CFLAGS_libxenevtchn) > +CFLAGS += $(CFLAGS_libxenctrl) > +LDLIBS += $(LDLIBS_libxenctrl) > +LDLIBS += $(LDLIBS_libxenevtchn) > +LDLIBS += $(LDLIBS_libxenforeignmemory) > + > +.PHONY: all > +all: build > + > +.PHONY: build > +build: proctrace > + > +.PHONY: install > +install: build > + $(INSTALL_DIR) $(DESTDIR)$(sbindir) > + $(INSTALL_PROG) proctrace $(DESTDIR)$(sbindir)/proctrace > + > +.PHONY: uninstall > +uninstall: > + rm -f $(DESTDIR)$(sbindir)/proctrace > + > +.PHONY: clean > +clean: > + $(RM) -f $(DEPS_RM) You need to remove proctrace as well, for `make clean` to have the intended semantics. > + > +.PHONY: distclean > +distclean: clean > + > +iptlive: iptlive.o Makefile > + $(CC) $(LDFLAGS) $< -o $@ $(LDLIBS) $(APPEND_LDFLAGS) This rule looks to be totally unused? > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +#define BUF_SIZE (16384 * XC_PAGE_SIZE) This hardcodes the size of the buffer which is configurable per VM. Mapping the buffer fails when it is smaller than this. It appears there is still outstanding bug from the acquire_resource work which never got fixed. The guest_handle_is_null(xmar.frame_list) path in Xen is supposed to report the size of the resource, not the size of Xen's local buffer, so userspace can ask "how large is this resource". I'll try and find some time to fix this and arrange for backports, but the current behaviour is nonsense, and problematic for new users. ~Andrew
RE: [PATCH v5] xen: fix build without pci passthrough
> -Original Message-
> From: Xen-devel On Behalf Of Anthony
> PERARD
> Sent: 02 July 2020 15:26
> To: Paul Durrant
Emails to this address are probably going to /dev/null by now :-)
> Cc: xen-devel@lists.xenproject.org; Roger Pau Monné
> Subject: Re: [PATCH v5] xen: fix build without pci passthrough
>
> On Thu, Jun 04, 2020 at 02:31:41PM -0400, Paolo Bonzini wrote:
> > From: Anthony PERARD
> >
> > Xen PCI passthrough support may not be available and thus the global
> > variable "has_igd_gfx_passthru" might be compiled out. Common code
> > should not access it in that case.
> >
> > Unfortunately, we can't use CONFIG_XEN_PCI_PASSTHROUGH directly in
> > xen-common.c so this patch instead move access to the
> > has_igd_gfx_passthru variable via function and those functions are
> > also implemented as stubs. The stubs will be used when QEMU is built
> > without passthrough support.
> >
> > Now, when one will want to enable igd-passthru via the -machine
> > property, they will get an error message if QEMU is built without
> > passthrough support.
> >
> > Fixes: 46472d82322d0 ('xen: convert "-machine igd-passthru" to an
> > accelerator property')
> > Reported-by: Roger Pau Monné
> > Signed-off-by: Anthony PERARD
> > Message-Id: <20200603160442.3151170-1-anthony.per...@citrix.com>
> > Signed-off-by: Paolo Bonzini
>
> Hi Paul,
>
> Can I backport this patch to qemu-xen-4.14? It allows to build qemu
> without pci passthrough support which seems to be important for FreeBSD
> as PT with QEMU is only available on Linux.
>
> (There's a fix to the patch that I would backport as well. "xen:
> Actually fix build without passthrough")
>
> Thanks.
I have no objection to make this fix for 4.14.
Cheers,
Paul
>
> > ---
> > accel/xen/xen-all.c | 4 ++--
> > hw/Makefile.objs | 2 +-
> > hw/i386/pc_piix.c| 2 +-
> > hw/xen/Makefile.objs | 3 ++-
> > hw/xen/xen_pt.c | 12 +++-
> > hw/xen/xen_pt.h | 6 --
> > hw/xen/xen_pt_stub.c | 22 ++
> > 7 files changed, 43 insertions(+), 8 deletions(-)
> > create mode 100644 hw/xen/xen_pt_stub.c
> >
> > diff --git a/accel/xen/xen-all.c b/accel/xen/xen-all.c
> > index f3edc65ec9..0c24d4b191 100644
> > --- a/accel/xen/xen-all.c
> > +++ b/accel/xen/xen-all.c
> > @@ -137,12 +137,12 @@ static void xen_change_state_handler(void *opaque,
> > int running,
> >
> > static bool xen_get_igd_gfx_passthru(Object *obj, Error **errp)
> > {
> > -return has_igd_gfx_passthru;
> > +return xen_igd_gfx_pt_enabled();
> > }
> >
> > static void xen_set_igd_gfx_passthru(Object *obj, bool value, Error **errp)
> > {
> > -has_igd_gfx_passthru = value;
> > +xen_igd_gfx_pt_set(value, errp);
> > }
> >
> > static void xen_setup_post(MachineState *ms, AccelState *accel)
> > diff --git a/hw/Makefile.objs b/hw/Makefile.objs
> > index 660e2b4373..4cbe5e4e57 100644
> > --- a/hw/Makefile.objs
> > +++ b/hw/Makefile.objs
> > @@ -35,7 +35,7 @@ devices-dirs-y += usb/
> > devices-dirs-$(CONFIG_VFIO) += vfio/
> > devices-dirs-y += virtio/
> > devices-dirs-y += watchdog/
> > -devices-dirs-y += xen/
> > +devices-dirs-$(CONFIG_XEN) += xen/
> > devices-dirs-$(CONFIG_MEM_DEVICE) += mem/
> > devices-dirs-$(CONFIG_NUBUS) += nubus/
> > devices-dirs-y += semihosting/
> > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> > index eea964e72b..054d3aa9f7 100644
> > --- a/hw/i386/pc_piix.c
> > +++ b/hw/i386/pc_piix.c
> > @@ -377,7 +377,7 @@ static void pc_init_isa(MachineState *machine)
> > #ifdef CONFIG_XEN
> > static void pc_xen_hvm_init_pci(MachineState *machine)
> > {
> > -const char *pci_type = has_igd_gfx_passthru ?
> > +const char *pci_type = xen_igd_gfx_pt_enabled() ?
> > TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE :
> > TYPE_I440FX_PCI_DEVICE;
> >
> > pc_init1(machine,
> > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
> > index 340b2c5096..3fc715e595 100644
> > --- a/hw/xen/Makefile.objs
> > +++ b/hw/xen/Makefile.objs
> > @@ -1,6 +1,7 @@
> > # xen backend driver support
> > -common-obj-$(CONFIG_XEN) += xen-legacy-backend.o xen_devconfig.o
> > xen_pvdev.o xen-bus.o xen-bus-
> helper.o xen-backend.o
> > +common-obj-y += xen-legacy-backend.o xen_devconfig.o xen_pvdev.o xen-bus.o
> > xen-bus-helper.o xen-
> backend.o
> >
> > obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
> > obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o
> > xen_pt_graphics.o xen_pt_msi.o
> > obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt_load_rom.o
> > +obj-$(call $(lnot, $(CONFIG_XEN_PCI_PASSTHROUGH))) += xen_pt_stub.o
> > diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
> > index 81d5ad8da7..ab84443d5e 100644
> > --- a/hw/xen/xen_pt.c
> > +++ b/hw/xen/xen_pt.c
> > @@ -65,7 +65,17 @@
> > #include "qemu/range.h"
> > #include "exec/address-spaces.h"
> >
> > -bool has_igd_gfx_passthru;
> > +static bool has_igd_gfx_passthru;
> > +
> > +bool xen_igd_gfx_pt_enabled(void)
> > +{
> > +
Re: [PATCH v2 0/4] Remove 32-bit Xen PV guest support
On Wed, Jul 1, 2020 at 7:07 AM Juergen Gross wrote: > > The long term plan has been to replace Xen PV guests by PVH. The first > victim of that plan are now 32-bit PV guests, as those are used only > rather seldom these days. Xen on x86 requires 64-bit support and with > Grub2 now supporting PVH officially since version 2.04 there is no > need to keep 32-bit PV guest support alive in the Linux kernel. > Additionally Meltdown mitigation is not available in the kernel running > as 32-bit PV guest, so dropping this mode makes sense from security > point of view, too. One thing that you missed is removing VDSO_NOTE_NONEGSEG_BIT from vdso32/note.S. With that removed there is no difference from the 64-bit version. Otherwise this series looks good to me. -- Brian Gerst
[libvirt test] 151527: regressions - FAIL
flight 151527 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/151527/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs. 151496 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs. 151496 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151496 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 151496 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-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-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 7fa7f7eeb6e969e002845928e155914da2fc8cd0 baseline version: libvirt e7998ebeaf15e4e8825be0dd97aa1316f194f00d Last test of basis 151496 2020-07-01 04:23:43 Z1 days Testing same since 151527 2020-07-02 04:29:15 Z0 days1 attempts People who touched revisions under test: Daniel Henrique Barboza Daniel P. Berrangé Michal Privoznik 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 http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing.
Re: [PATCH v4 02/10] x86/vmx: add IPT cpu feature
On 02/07/2020 15:17, Jan Beulich wrote: On 02.07.2020 16:14, Julien Grall wrote: On 02/07/2020 14:30, Jan Beulich wrote: On 02.07.2020 11:57, Julien Grall wrote: On 02/07/2020 10:18, Jan Beulich wrote: On 02.07.2020 10:54, Julien Grall wrote: On 02/07/2020 09:50, Jan Beulich wrote: On 02.07.2020 10:42, Julien Grall wrote: On 02/07/2020 09:29, Jan Beulich wrote: Another way to do it, would be the toolstack to do the mapping. At which point, you still need an hypercall to do the mapping (probably the hypercall acquire). There may not be any mapping to do in such a contrived, fixed-range environment. This scenario was specifically to demonstrate that the way the mapping gets done may be arch-specific (here: a no-op) despite the allocation not being so. You are arguing on extreme cases which I don't think is really helpful here. Yes if you want to map at a fixed address in a guest you may not need the acquire hypercall. But in most of the other cases (see has for the tools) you will need it. So what's the problem with requesting to have the acquire hypercall implemented in common code? Didn't we start out by you asking that there be as little common code as possible for the time being? Well as I said I am not in favor of having the allocation in common code, but if you want to keep it then you also want to implement map/unmap in the common code ([1], [2]). I have no issue with putting the acquire implementation there ... This was definitely not clear given how you argued with extreme cases... Cheers, [1] <9a3f4d58-e5ad-c7a1-6c5f-42aa92101...@xen.org> [2] -- Julien Grall
Re: [PATCH v5] xen: fix build without pci passthrough
On Thu, Jun 04, 2020 at 02:31:41PM -0400, Paolo Bonzini wrote:
> From: Anthony PERARD
>
> Xen PCI passthrough support may not be available and thus the global
> variable "has_igd_gfx_passthru" might be compiled out. Common code
> should not access it in that case.
>
> Unfortunately, we can't use CONFIG_XEN_PCI_PASSTHROUGH directly in
> xen-common.c so this patch instead move access to the
> has_igd_gfx_passthru variable via function and those functions are
> also implemented as stubs. The stubs will be used when QEMU is built
> without passthrough support.
>
> Now, when one will want to enable igd-passthru via the -machine
> property, they will get an error message if QEMU is built without
> passthrough support.
>
> Fixes: 46472d82322d0 ('xen: convert "-machine igd-passthru" to an accelerator
> property')
> Reported-by: Roger Pau Monné
> Signed-off-by: Anthony PERARD
> Message-Id: <20200603160442.3151170-1-anthony.per...@citrix.com>
> Signed-off-by: Paolo Bonzini
Hi Paul,
Can I backport this patch to qemu-xen-4.14? It allows to build qemu
without pci passthrough support which seems to be important for FreeBSD
as PT with QEMU is only available on Linux.
(There's a fix to the patch that I would backport as well. "xen:
Actually fix build without passthrough")
Thanks.
> ---
> accel/xen/xen-all.c | 4 ++--
> hw/Makefile.objs | 2 +-
> hw/i386/pc_piix.c| 2 +-
> hw/xen/Makefile.objs | 3 ++-
> hw/xen/xen_pt.c | 12 +++-
> hw/xen/xen_pt.h | 6 --
> hw/xen/xen_pt_stub.c | 22 ++
> 7 files changed, 43 insertions(+), 8 deletions(-)
> create mode 100644 hw/xen/xen_pt_stub.c
>
> diff --git a/accel/xen/xen-all.c b/accel/xen/xen-all.c
> index f3edc65ec9..0c24d4b191 100644
> --- a/accel/xen/xen-all.c
> +++ b/accel/xen/xen-all.c
> @@ -137,12 +137,12 @@ static void xen_change_state_handler(void *opaque, int
> running,
>
> static bool xen_get_igd_gfx_passthru(Object *obj, Error **errp)
> {
> -return has_igd_gfx_passthru;
> +return xen_igd_gfx_pt_enabled();
> }
>
> static void xen_set_igd_gfx_passthru(Object *obj, bool value, Error **errp)
> {
> -has_igd_gfx_passthru = value;
> +xen_igd_gfx_pt_set(value, errp);
> }
>
> static void xen_setup_post(MachineState *ms, AccelState *accel)
> diff --git a/hw/Makefile.objs b/hw/Makefile.objs
> index 660e2b4373..4cbe5e4e57 100644
> --- a/hw/Makefile.objs
> +++ b/hw/Makefile.objs
> @@ -35,7 +35,7 @@ devices-dirs-y += usb/
> devices-dirs-$(CONFIG_VFIO) += vfio/
> devices-dirs-y += virtio/
> devices-dirs-y += watchdog/
> -devices-dirs-y += xen/
> +devices-dirs-$(CONFIG_XEN) += xen/
> devices-dirs-$(CONFIG_MEM_DEVICE) += mem/
> devices-dirs-$(CONFIG_NUBUS) += nubus/
> devices-dirs-y += semihosting/
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index eea964e72b..054d3aa9f7 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -377,7 +377,7 @@ static void pc_init_isa(MachineState *machine)
> #ifdef CONFIG_XEN
> static void pc_xen_hvm_init_pci(MachineState *machine)
> {
> -const char *pci_type = has_igd_gfx_passthru ?
> +const char *pci_type = xen_igd_gfx_pt_enabled() ?
> TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE :
> TYPE_I440FX_PCI_DEVICE;
>
> pc_init1(machine,
> diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
> index 340b2c5096..3fc715e595 100644
> --- a/hw/xen/Makefile.objs
> +++ b/hw/xen/Makefile.objs
> @@ -1,6 +1,7 @@
> # xen backend driver support
> -common-obj-$(CONFIG_XEN) += xen-legacy-backend.o xen_devconfig.o xen_pvdev.o
> xen-bus.o xen-bus-helper.o xen-backend.o
> +common-obj-y += xen-legacy-backend.o xen_devconfig.o xen_pvdev.o xen-bus.o
> xen-bus-helper.o xen-backend.o
>
> obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
> obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o
> xen_pt_graphics.o xen_pt_msi.o
> obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt_load_rom.o
> +obj-$(call $(lnot, $(CONFIG_XEN_PCI_PASSTHROUGH))) += xen_pt_stub.o
> diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
> index 81d5ad8da7..ab84443d5e 100644
> --- a/hw/xen/xen_pt.c
> +++ b/hw/xen/xen_pt.c
> @@ -65,7 +65,17 @@
> #include "qemu/range.h"
> #include "exec/address-spaces.h"
>
> -bool has_igd_gfx_passthru;
> +static bool has_igd_gfx_passthru;
> +
> +bool xen_igd_gfx_pt_enabled(void)
> +{
> +return has_igd_gfx_passthru;
> +}
> +
> +void xen_igd_gfx_pt_set(bool value, Error **errp)
> +{
> +has_igd_gfx_passthru = value;
> +}
>
> #define XEN_PT_NR_IRQS (256)
> static uint8_t xen_pt_mapped_machine_irq[XEN_PT_NR_IRQS] = {0};
> diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
> index 179775db7b..6e9cec95f3 100644
> --- a/hw/xen/xen_pt.h
> +++ b/hw/xen/xen_pt.h
> @@ -5,6 +5,9 @@
> #include "hw/pci/pci.h"
> #include "xen-host-pci-device.h"
>
> +bool xen_igd_gfx_pt_enabled(void);
> +void xen_igd_gfx_pt_set(bool value, Error **errp);
> +
> void xen_pt_log(const PCIDevice *d, const char *f, ...)
[PATCH][next] xen-netfront: remove redundant assignment to variable 'act'
From: Colin Ian King
The variable act is being initialized with a value that is
never read and it is being updated later with a new value. The
initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/net/xen-netfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 468f3f6f1425..860a0cce346d 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -856,7 +856,7 @@ static u32 xennet_run_xdp(struct netfront_queue *queue,
struct page *pdata,
{
struct xdp_frame *xdpf;
u32 len = rx->status;
- u32 act = XDP_PASS;
+ u32 act;
int err;
xdp->data_hard_start = page_address(pdata);
--
2.27.0
Re: [PATCH v4 02/10] x86/vmx: add IPT cpu feature
On 02.07.2020 16:14, Julien Grall wrote: > Hi, > > On 02/07/2020 14:30, Jan Beulich wrote: >> On 02.07.2020 11:57, Julien Grall wrote: >>> Hi, >>> >>> On 02/07/2020 10:18, Jan Beulich wrote: On 02.07.2020 10:54, Julien Grall wrote: > > > On 02/07/2020 09:50, Jan Beulich wrote: >> On 02.07.2020 10:42, Julien Grall wrote: >>> On 02/07/2020 09:29, Jan Beulich wrote: I'm with Andrew here, fwiw, as long as the little bit of code that is actually put in common/ or include/xen/ doesn't imply arbitrary restrictions on acceptable values. >>> Well yes the code is simple. However, the code as it is wouldn't be >>> usuable on other architecture without additional work (aside arch >>> specific code). For instance, there is no way to map the buffer outside >>> of Xen as it is all x86 specific. >>> >>> If you want the allocation to be in the common code, then the >>> infrastructure to map/unmap the buffer should also be in common code. >>> Otherwise, there is no point to allocate it in common. >> >> I don't think I agree here - I see nothing wrong with exposing of >> the memory being arch specific, when allocation is generic. This >> is no different from, in just x86, allocation logic being common >> to PV and HVM, but exposing being different for both. > > Are you suggesting that the way it would be exposed may be different for > other architecture? Why not? To take a possibly extreme example - consider an arch where (for bare metal) the buffer is specified to appear at a fixed range of addresses. >>> >>> I am probably missing something here... The current goal is the buffer >>> will be mapped in the dom0. Most likely the way to map it will be using >>> the acquire hypercall (unless you invent a brand new one...). >>> >>> For a guest, you could possibly reserve a fixed range and then map it >>> when creating the vCPU in Xen. But then, you will likely want a fixed >>> size... So why would you bother to ask the user to define the size? >> >> Because there may be the option to only populate part of the fixed >> range? > > It was yet another extreme case ;). Yes, sure - just to demonstrate my point. >>> Another way to do it, would be the toolstack to do the mapping. At which >>> point, you still need an hypercall to do the mapping (probably the >>> hypercall acquire). >> >> There may not be any mapping to do in such a contrived, fixed-range >> environment. This scenario was specifically to demonstrate that the >> way the mapping gets done may be arch-specific (here: a no-op) >> despite the allocation not being so. > You are arguing on extreme cases which I don't think is really helpful > here. Yes if you want to map at a fixed address in a guest you may not > need the acquire hypercall. But in most of the other cases (see has for > the tools) you will need it. > > So what's the problem with requesting to have the acquire hypercall > implemented in common code? Didn't we start out by you asking that there be as little common code as possible for the time being? I have no issue with putting the acquire implementation there ... Jan
Re: [PATCH v4 02/10] x86/vmx: add IPT cpu feature
Hi, On 02/07/2020 14:30, Jan Beulich wrote: On 02.07.2020 11:57, Julien Grall wrote: Hi, On 02/07/2020 10:18, Jan Beulich wrote: On 02.07.2020 10:54, Julien Grall wrote: On 02/07/2020 09:50, Jan Beulich wrote: On 02.07.2020 10:42, Julien Grall wrote: On 02/07/2020 09:29, Jan Beulich wrote: I'm with Andrew here, fwiw, as long as the little bit of code that is actually put in common/ or include/xen/ doesn't imply arbitrary restrictions on acceptable values. Well yes the code is simple. However, the code as it is wouldn't be usuable on other architecture without additional work (aside arch specific code). For instance, there is no way to map the buffer outside of Xen as it is all x86 specific. If you want the allocation to be in the common code, then the infrastructure to map/unmap the buffer should also be in common code. Otherwise, there is no point to allocate it in common. I don't think I agree here - I see nothing wrong with exposing of the memory being arch specific, when allocation is generic. This is no different from, in just x86, allocation logic being common to PV and HVM, but exposing being different for both. Are you suggesting that the way it would be exposed may be different for other architecture? Why not? To take a possibly extreme example - consider an arch where (for bare metal) the buffer is specified to appear at a fixed range of addresses. I am probably missing something here... The current goal is the buffer will be mapped in the dom0. Most likely the way to map it will be using the acquire hypercall (unless you invent a brand new one...). For a guest, you could possibly reserve a fixed range and then map it when creating the vCPU in Xen. But then, you will likely want a fixed size... So why would you bother to ask the user to define the size? Because there may be the option to only populate part of the fixed range? It was yet another extreme case ;). Another way to do it, would be the toolstack to do the mapping. At which point, you still need an hypercall to do the mapping (probably the hypercall acquire). There may not be any mapping to do in such a contrived, fixed-range environment. This scenario was specifically to demonstrate that the way the mapping gets done may be arch-specific (here: a no-op) despite the allocation not being so. You are arguing on extreme cases which I don't think is really helpful here. Yes if you want to map at a fixed address in a guest you may not need the acquire hypercall. But in most of the other cases (see has for the tools) you will need it. So what's the problem with requesting to have the acquire hypercall implemented in common code? Cheers, -- Julien Grall
Re: [PATCH v4 02/10] x86/vmx: add IPT cpu feature
On 02.07.2020 11:57, Julien Grall wrote: > Hi, > > On 02/07/2020 10:18, Jan Beulich wrote: >> On 02.07.2020 10:54, Julien Grall wrote: >>> >>> >>> On 02/07/2020 09:50, Jan Beulich wrote: On 02.07.2020 10:42, Julien Grall wrote: > On 02/07/2020 09:29, Jan Beulich wrote: >> I'm with Andrew here, fwiw, as long as the little bit of code that >> is actually put in common/ or include/xen/ doesn't imply arbitrary >> restrictions on acceptable values. > Well yes the code is simple. However, the code as it is wouldn't be > usuable on other architecture without additional work (aside arch > specific code). For instance, there is no way to map the buffer outside > of Xen as it is all x86 specific. > > If you want the allocation to be in the common code, then the > infrastructure to map/unmap the buffer should also be in common code. > Otherwise, there is no point to allocate it in common. I don't think I agree here - I see nothing wrong with exposing of the memory being arch specific, when allocation is generic. This is no different from, in just x86, allocation logic being common to PV and HVM, but exposing being different for both. >>> >>> Are you suggesting that the way it would be exposed may be different for >>> other architecture? >> >> Why not? To take a possibly extreme example - consider an arch >> where (for bare metal) the buffer is specified to appear at a >> fixed range of addresses. > > I am probably missing something here... The current goal is the buffer > will be mapped in the dom0. Most likely the way to map it will be using > the acquire hypercall (unless you invent a brand new one...). > > For a guest, you could possibly reserve a fixed range and then map it > when creating the vCPU in Xen. But then, you will likely want a fixed > size... So why would you bother to ask the user to define the size? Because there may be the option to only populate part of the fixed range? > Another way to do it, would be the toolstack to do the mapping. At which > point, you still need an hypercall to do the mapping (probably the > hypercall acquire). There may not be any mapping to do in such a contrived, fixed-range environment. This scenario was specifically to demonstrate that the way the mapping gets done may be arch-specific (here: a no-op) despite the allocation not being so. Jan
[linux-linus test] 151513: regressions - FAIL
flight 151513 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151513/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214 Tests which are failing intermittently (not blocking): test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 guest-saverestore fail in 151494 pass in 151513 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail pass in 151494 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 151214 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 151214 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 151214 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151214 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 151214 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 151214 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-amd64-i386-libvirt-xsm 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-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop 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-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linux7c30b859a947535f2213277e827d7ac7dcff9c84 baseline version: linux1b5044021070efa3259f3e9548dc35d1eb6aa844 Last test of basis 151214 2020-06-18 02:27:46 Z 14 days Failing since151236 2020-06-19 19:10:35 Z 12 days 16 attempts Testing
[xen-unstable-smoke test] 151535: tolerable all pass - PUSHED
flight 151535 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/151535/ 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 be63d9d47f571a60d70f8fb630c03871312d9655 baseline version: xen 0dbed3ad3366734fd23ee3fd1f9989c8c96b6052 Last test of basis 151515 2020-07-01 21:04:44 Z0 days Testing same since 151535 2020-07-02 10:00:52 Z0 days1 attempts People who touched revisions under test: Bertrand Marquis Jan Beulich Julien Grall Roger Pau Monné 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 0dbed3ad33..be63d9d47f be63d9d47f571a60d70f8fb630c03871312d9655 -> smoke
Community Call CANCELLED this month
Hey all, Rather than holding the community call this month, I think people should submit design sessions for topics they want to discuss: https://design-sessions.xenproject.org We’ll pick up again in August. -George
Re: [PATCH 3/6] x86/entry/64/compat: Fix Xen PV SYSENTER frame setup
Andy Lutomirski writes:
> On Wed, Jul 1, 2020 at 8:42 AM Brian Gerst wrote:
> > On Fri, Jun 26, 2020 at 1:30 PM Andy Lutomirski wrote:
>> >
>> > The SYSENTER frame setup was nonsense. It worked by accident
>> > because the normal code into which the Xen asm jumped
>> > (entry_SYSENTER_32/compat) threw away SP without touching the stack.
>> > entry_SYSENTER_compat was recently modified such that it relied on
>> > having a valid stack pointer, so now the Xen asm needs to invoke it
>> > with a valid stack.
>> >
>> > Fix it up like SYSCALL: use the Xen-provided frame and skip the bare
>> > metal prologue.
>> >
>> > Cc: Boris Ostrovsky
>> > Cc: Juergen Gross
>> > Cc: Stefano Stabellini
>> > Cc: xen-devel@lists.xenproject.org
>> > Fixes: 1c3e5d3f60e2 ("x86/entry: Make entry_64_compat.S objtool clean")
>> > Signed-off-by: Andy Lutomirski
>> > ---
>> > arch/x86/entry/entry_64_compat.S | 1 +
>> > arch/x86/xen/xen-asm_64.S| 20
>> > 2 files changed, 17 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/arch/x86/entry/entry_64_compat.S
>> > b/arch/x86/entry/entry_64_compat.S
>> > index 7b9d8150f652..381a6de7de9c 100644
>> > --- a/arch/x86/entry/entry_64_compat.S
>> > +++ b/arch/x86/entry/entry_64_compat.S
>> > @@ -79,6 +79,7 @@ SYM_CODE_START(entry_SYSENTER_compat)
>> > pushfq /* pt_regs->flags (except IF = 0)
>> > */
>> > pushq $__USER32_CS/* pt_regs->cs */
>> > pushq $0 /* pt_regs->ip = 0 (placeholder) */
>> > +SYM_INNER_LABEL(entry_SYSENTER_compat_after_hwframe, SYM_L_GLOBAL)
>>
>> This skips over the section that truncates the syscall number to
>> 32-bits. The comments present some doubt that it is actually
>> necessary, but the Xen path shouldn't differ from native. That code
>> should be moved after this new label.
>
> Whoops. I thought I caught that myself, but apparently not. I'll fix it.
Darn. I already applied that lot. Can you please send a delta fix?
Thanks,
tglx
[linux-5.4 test] 151516: tolerable FAIL - PUSHED
flight 151516 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/151516/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: 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 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-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-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 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-amd64-amd64-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-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-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-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-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-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: linuxe75220890bf6b37c5f7b1dbd81d8292ed6d96643 baseline version: linux4e9688ad3d36e8f73c73e435f53da5ae1cd91a70 Last test of basis 151339 2020-06-24 16:09:27 Z7 days Testing same since 151503 2020-07-01 09:18:19 Z1 days2 attempts People who touched revisions under test: Aaron Plattner Aditya Pakki Al Cooper Al Viro Alan Stern Alex Deucher Alexander Lobakin Alexei Starovoitov Andrew Morton Anna Schumaker Anton Eidelman Ard Biesheuvel Ariel Elior Bernard Zhao Borislav Petkov Charles Keepax Chihhao Chen Christian
Re: [PATCH v4 03/10] tools/libxl: add vmtrace_pt_size parameter
Hi Michał,
On Tue, Jun 30, 2020 at 02:33:46PM +0200, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Allow to specify the size of per-vCPU trace buffer upon
> domain creation. This is zero by default (meaning: not enabled).
>
> Signed-off-by: Michal Leszczynski
> ---
>
> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> index 0532739c1f..78f434b722 100644
> --- a/docs/man/xl.cfg.5.pod.in
> +++ b/docs/man/xl.cfg.5.pod.in
> @@ -278,6 +278,16 @@ memory=8096 will report significantly less memory
> available for use
> than a system with maxmem=8096 memory=8096 due to the memory overhead
> of having to track the unused pages.
>
> +=item B
I don't like much this new configuration name. To me, "pt" sound like
passthrough, as in pci passthrough. But it seems to be for "processor
trace" (or tracing), isn't it? So if it is, then we have "trace" twice
in the name and I don't think that configuration is about tracing the
processor tracing feature. (Also I don't think we need to state "vm" in
the name easier as every configuration option should be about a vm.)
How about a name that is easier to understand without having to know all
the possible abbreviations? Maybe "processor_trace_buffer_size" or
similar?
> +
> +Specifies the size of processor trace buffer that would be allocated
> +for each vCPU belonging to this domain. Disabled (i.e. B
> +by default. This must be set to non-zero value in order to be able to
> +use processor tracing features with this domain.
> +
> +B: The size value must be between 4 kB and 4 GB and it must
> +be also a power of 2.
Maybe the configuration variable could take KBYTES for kilo-bytes
instead of just BYTES since the min is 4kB?
Also that item seems to be in the "Memory Allocation" section, but I
don't think that's a good place as the other options are for the size of
guest RAM. I don't know in which section this would be better but maybe
"Other Options" would be OK.
> =back
>
> =head3 Guest Virtual NUMA Configuration
> diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
> index 61b4ef7b7e..4eba224590 100644
> --- a/tools/xl/xl_parse.c
> +++ b/tools/xl/xl_parse.c
> @@ -1861,6 +1861,26 @@ void parse_config_data(const char *config_source,
> }
> }
>
> +if (!xlu_cfg_get_long(config, "vmtrace_pt_size", , 1) && l) {
> +int32_t shift = 0;
> +
> +if (l & (l - 1))
> +{
> +fprintf(stderr, "ERROR: pt buffer size must be a power of 2\n");
It would be better to state the option name in the error message.
> +exit(1);
> +}
> +
> +while (l >>= 1) ++shift;
> +
> +if (shift <= XEN_PAGE_SHIFT)
> +{
> +fprintf(stderr, "ERROR: too small pt buffer\n");
> +exit(1);
> +}
> +
> +b_info->vmtrace_pt_order = shift - XEN_PAGE_SHIFT;
> +}
> +
> if (!xlu_cfg_get_list(config, "ioports", , _ioports, 0)) {
> b_info->num_ioports = num_ioports;
> b_info->ioports = calloc(num_ioports, sizeof(*b_info->ioports));
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 0a33e0dfd6..27dcfbac8c 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 59bdc28c89..7b8289d436 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
I don't think it's wise to modify the toolstack, the hypervisor, and the
hypercall ABI in the same patch. Can you change this last two files in a
separate patch?
Thank you,
--
Anthony PERARD
Re: [PATCH v4 02/10] x86/vmx: add IPT cpu feature
Hi, On 02/07/2020 10:18, Jan Beulich wrote: On 02.07.2020 10:54, Julien Grall wrote: On 02/07/2020 09:50, Jan Beulich wrote: On 02.07.2020 10:42, Julien Grall wrote: On 02/07/2020 09:29, Jan Beulich wrote: I'm with Andrew here, fwiw, as long as the little bit of code that is actually put in common/ or include/xen/ doesn't imply arbitrary restrictions on acceptable values. Well yes the code is simple. However, the code as it is wouldn't be usuable on other architecture without additional work (aside arch specific code). For instance, there is no way to map the buffer outside of Xen as it is all x86 specific. If you want the allocation to be in the common code, then the infrastructure to map/unmap the buffer should also be in common code. Otherwise, there is no point to allocate it in common. I don't think I agree here - I see nothing wrong with exposing of the memory being arch specific, when allocation is generic. This is no different from, in just x86, allocation logic being common to PV and HVM, but exposing being different for both. Are you suggesting that the way it would be exposed may be different for other architecture? Why not? To take a possibly extreme example - consider an arch where (for bare metal) the buffer is specified to appear at a fixed range of addresses. I am probably missing something here... The current goal is the buffer will be mapped in the dom0. Most likely the way to map it will be using the acquire hypercall (unless you invent a brand new one...). For a guest, you could possibly reserve a fixed range and then map it when creating the vCPU in Xen. But then, you will likely want a fixed size... So why would you bother to ask the user to define the size? Another way to do it, would be the toolstack to do the mapping. At which point, you still need an hypercall to do the mapping (probably the hypercall acquire). If so, this is one more reason to not impose a way for allocating the buffer in the common code until another arch add support for vmtrace. I'm still not seeing why allocation and exposure need to be done at the same place. If I were going to add support for CoreSight on Arm, then the acquire hypercall is likely going to be the way to go for mapping the resource in the tools. At which point this will need to be common. I am still not entirely happy to define the interface yet, but this would still be better than trying to make the allocation in common code and the leaving the mapping aside. After all, this is a "little bit" more code. Cheers, -- Julien Grall
Re: [PATCH v4 02/10] x86/vmx: add IPT cpu feature
On 02.07.2020 10:54, Julien Grall wrote: > > > On 02/07/2020 09:50, Jan Beulich wrote: >> On 02.07.2020 10:42, Julien Grall wrote: >>> On 02/07/2020 09:29, Jan Beulich wrote: I'm with Andrew here, fwiw, as long as the little bit of code that is actually put in common/ or include/xen/ doesn't imply arbitrary restrictions on acceptable values. >>> Well yes the code is simple. However, the code as it is wouldn't be >>> usuable on other architecture without additional work (aside arch >>> specific code). For instance, there is no way to map the buffer outside >>> of Xen as it is all x86 specific. >>> >>> If you want the allocation to be in the common code, then the >>> infrastructure to map/unmap the buffer should also be in common code. >>> Otherwise, there is no point to allocate it in common. >> >> I don't think I agree here - I see nothing wrong with exposing of >> the memory being arch specific, when allocation is generic. This >> is no different from, in just x86, allocation logic being common >> to PV and HVM, but exposing being different for both. > > Are you suggesting that the way it would be exposed may be different for > other architecture? Why not? To take a possibly extreme example - consider an arch where (for bare metal) the buffer is specified to appear at a fixed range of addresses. This would then want to be this way in the virtualized case as well. There'd be no point in using any common logic mapping the buffer at a guest requested address. Instead it would simply appear at the arch mandated one, without the guest needing to take any action. > If so, this is one more reason to not impose a way for allocating the > buffer in the common code until another arch add support for vmtrace. I'm still not seeing why allocation and exposure need to be done at the same place. Jan
Re: [PATCH v4 03/10] tools/libxl: add vmtrace_pt_size parameter
On Tue, Jun 30, 2020 at 02:33:46PM +0200, Michał Leszczyński wrote:
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 59bdc28c89..7b8289d436 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -92,6 +92,7 @@ struct xen_domctl_createdomain {
> uint32_t max_evtchn_port;
> int32_t max_grant_frames;
> int32_t max_maptrack_frames;
> +uint8_t vmtrace_pt_order;
I've been thinking about this, and even though this is a domctl (so
not a stable interface) we might want to consider using a size (or a
number of pages) here rather than an order. IPT also supports
TOPA mode (kind of a linked list of buffers) that would allow for
sizes not rounded to order boundaries to be used, since then only each
item in the linked list needs to be rounded to an order boundary, so
you could for example use three 4K pages in TOPA mode AFAICT.
Roger.
Re: [PATCH v4 02/10] x86/vmx: add IPT cpu feature
On 02/07/2020 09:50, Jan Beulich wrote: On 02.07.2020 10:42, Julien Grall wrote: On 02/07/2020 09:29, Jan Beulich wrote: I'm with Andrew here, fwiw, as long as the little bit of code that is actually put in common/ or include/xen/ doesn't imply arbitrary restrictions on acceptable values. Well yes the code is simple. However, the code as it is wouldn't be usuable on other architecture without additional work (aside arch specific code). For instance, there is no way to map the buffer outside of Xen as it is all x86 specific. If you want the allocation to be in the common code, then the infrastructure to map/unmap the buffer should also be in common code. Otherwise, there is no point to allocate it in common. I don't think I agree here - I see nothing wrong with exposing of the memory being arch specific, when allocation is generic. This is no different from, in just x86, allocation logic being common to PV and HVM, but exposing being different for both. Are you suggesting that the way it would be exposed may be different for other architecture? If so, this is one more reason to not impose a way for allocating the buffer in the common code until another arch add support for vmtrace. Cheers, -- Julien Grall
Re: [PATCH v4 02/10] x86/vmx: add IPT cpu feature
On 02.07.2020 10:42, Julien Grall wrote: > On 02/07/2020 09:29, Jan Beulich wrote: >> I'm with Andrew here, fwiw, as long as the little bit of code that >> is actually put in common/ or include/xen/ doesn't imply arbitrary >> restrictions on acceptable values. > Well yes the code is simple. However, the code as it is wouldn't be > usuable on other architecture without additional work (aside arch > specific code). For instance, there is no way to map the buffer outside > of Xen as it is all x86 specific. > > If you want the allocation to be in the common code, then the > infrastructure to map/unmap the buffer should also be in common code. > Otherwise, there is no point to allocate it in common. I don't think I agree here - I see nothing wrong with exposing of the memory being arch specific, when allocation is generic. This is no different from, in just x86, allocation logic being common to PV and HVM, but exposing being different for both. Jan
Re: [PATCH v4 02/10] x86/vmx: add IPT cpu feature
Hi Jan, On 02/07/2020 09:29, Jan Beulich wrote: On 01.07.2020 20:09, Julien Grall wrote: On 01/07/2020 19:06, Andrew Cooper wrote: On 01/07/2020 19:02, Julien Grall wrote: On 01/07/2020 18:26, Andrew Cooper wrote: For the sake of what is literally just one byte in common code, I stand my original suggestion of this being a common interface. It is not something which should be x86 specific. This argument can also be used against putting in common code. What I am the most concern of is we are trying to guess how the interface will look like for another architecture. Your suggested interface may work, but this also may end up to be a complete mess. So I think we want to wait for a new architecture to use vmtrace before moving to common code. This is not going to be a massive effort to move that bit in common if needed. I suggest you read the series. Already went through the series and ... The only thing in common code is the bit of the interface saying "I'd like buffers this big please". ... I stand by my point. There is no need to have this code in common code until someone else need it. This code can be easily implemented in arch_domain_create(). I'm with Andrew here, fwiw, as long as the little bit of code that is actually put in common/ or include/xen/ doesn't imply arbitrary restrictions on acceptable values. Well yes the code is simple. However, the code as it is wouldn't be usuable on other architecture without additional work (aside arch specific code). For instance, there is no way to map the buffer outside of Xen as it is all x86 specific. If you want the allocation to be in the common code, then the infrastructure to map/unmap the buffer should also be in common code. Otherwise, there is no point to allocate it in common. Cheers, -- Julien Grall
Re: [PATCH v2] xen/displif: Protocol version 2
On 02.07.20 09:59, Oleksandr Andrushchenko wrote: On 7/2/20 10:20 AM, Jürgen Groß wrote: On 01.07.20 14:07, Oleksandr Andrushchenko wrote: On 7/1/20 1:46 PM, Jürgen Groß wrote: On 01.07.20 09:19, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko 1. Add protocol version as an integer Version string, which is in fact an integer, is hard to handle in the code that supports different protocol versions. To simplify that also add the version as an integer. 2. Pass buffer offset with XENDISPL_OP_DBUF_CREATE There are cases when display data buffer is created with non-zero offset to the data start. Handle such cases and provide that offset while creating a display buffer. 3. Add XENDISPL_OP_GET_EDID command Add an optional request for reading Extended Display Identification Data (EDID) structure which allows better configuration of the display connectors over the configuration set in XenStore. With this change connectors may have multiple resolutions defined with respect to detailed timing definitions and additional properties normally provided by displays. If this request is not supported by the backend then visible area is defined by the relevant XenStore's "resolution" property. If backend provides extended display identification data (EDID) with XENDISPL_OP_GET_EDID request then EDID values must take precedence over the resolutions defined in XenStore. 4. Bump protocol version to 2. Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Juergen Gross Thank you, do you want me to prepare the same for the kernel so you have it at hand when the time comes? It should be added to the kernel only when really needed (i.e. a user of the new functionality is showing up). We have a patch for that which adds EDID to the existing PV DRM frontend, so while upstreaming those changes I will also include changes to the protocol in the kernel series: for that we need the header in Xen tree first, right? Yes. Juergen
Re: [PATCH v4 02/10] x86/vmx: add IPT cpu feature
On 02.07.2020 10:10, Roger Pau Monné wrote: > On Wed, Jul 01, 2020 at 10:42:55PM +0100, Andrew Cooper wrote: >> On 30/06/2020 13:33, Michał Leszczyński wrote: >>> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c >>> index ca94c2bedc..b73d824357 100644 >>> --- a/xen/arch/x86/hvm/vmx/vmcs.c >>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c >>> @@ -291,6 +291,12 @@ static int vmx_init_vmcs_config(void) >>> _vmx_cpu_based_exec_control &= >>> ~(CPU_BASED_CR8_LOAD_EXITING | CPU_BASED_CR8_STORE_EXITING); >>> >>> +rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap); >>> + >>> +/* Check whether IPT is supported in VMX operation. */ >>> +vmtrace_supported = cpu_has_ipt && >>> +(_vmx_misc_cap & VMX_MISC_PT_SUPPORTED); >> >> There is a subtle corner case here. vmx_init_vmcs_config() is called on >> all CPUs, and is supposed to level things down safely if we find any >> asymmetry. >> >> If instead you go with something like this: >> >> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c >> index b73d824357..6960109183 100644 >> --- a/xen/arch/x86/hvm/vmx/vmcs.c >> +++ b/xen/arch/x86/hvm/vmx/vmcs.c >> @@ -294,8 +294,8 @@ static int vmx_init_vmcs_config(void) >> rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap); >> >> /* Check whether IPT is supported in VMX operation. */ >> - vmtrace_supported = cpu_has_ipt && >> - (_vmx_misc_cap & VMX_MISC_PT_SUPPORTED); >> + if ( !(_vmx_misc_cap & VMX_MISC_PT_SUPPORTED) ) >> + vmtrace_supported = false; > > This is also used during hotplug, so I'm not sure it's safe to turn > vmtrace_supported off during runtime, where VMs might be already using > it. IMO it would be easier to just set it on the BSP, and then refuse > to bring up any AP that doesn't have the feature. +1 IOW I also don't think that "vmx_init_vmcs_config() ... is supposed to level things down safely". Instead I think the expectation is for CPU onlining to fail if a CPU lacks features compared to the BSP. As can be implied from what Roger says, doing like what you suggest may be fine during boot, but past that only at times where we know there's no user of a certain feature, and where discarding the feature flag won't lead to other inconsistencies (which may very well mean "never"). Jan
Re: [PATCH v4 02/10] x86/vmx: add IPT cpu feature
On 01.07.2020 20:09, Julien Grall wrote: > On 01/07/2020 19:06, Andrew Cooper wrote: >> On 01/07/2020 19:02, Julien Grall wrote: >>> On 01/07/2020 18:26, Andrew Cooper wrote: For the sake of what is literally just one byte in common code, I stand my original suggestion of this being a common interface. It is not something which should be x86 specific. >>> >>> This argument can also be used against putting in common code. What I >>> am the most concern of is we are trying to guess how the interface >>> will look like for another architecture. Your suggested interface may >>> work, but this also may end up to be a complete mess. >>> >>> So I think we want to wait for a new architecture to use vmtrace >>> before moving to common code. This is not going to be a massive effort >>> to move that bit in common if needed. >> >> I suggest you read the series. > > Already went through the series and ... > >> >> The only thing in common code is the bit of the interface saying "I'd >> like buffers this big please". > > ... I stand by my point. There is no need to have this code in common > code until someone else need it. This code can be easily implemented in > arch_domain_create(). I'm with Andrew here, fwiw, as long as the little bit of code that is actually put in common/ or include/xen/ doesn't imply arbitrary restrictions on acceptable values. For example, unless there is proof that for all architectures of interest currently or in the not too distant future an order value is fine (as opposed to a size one), then an order field would be fine to live in common code imo. Otherwise it would need to be a size one, with per-arch enforcement of further imposed restrictions (like needing to be a power of 2). Jan
Re: [PATCH v2 0/4] Remove 32-bit Xen PV guest support
On Wed, Jul 01, 2020 at 01:06:46PM +0200, Juergen Gross wrote: > The long term plan has been to replace Xen PV guests by PVH. The first > victim of that plan are now 32-bit PV guests, as those are used only > rather seldom these days. Xen on x86 requires 64-bit support and with > Grub2 now supporting PVH officially since version 2.04 there is no > need to keep 32-bit PV guest support alive in the Linux kernel. > Additionally Meltdown mitigation is not available in the kernel running > as 32-bit PV guest, so dropping this mode makes sense from security > point of view, too. Hooray!!! Much thanks!
Re: [PATCH v4 02/10] x86/vmx: add IPT cpu feature
On Wed, Jul 01, 2020 at 10:42:55PM +0100, Andrew Cooper wrote: > On 30/06/2020 13:33, Michał Leszczyński wrote: > > diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c > > index ca94c2bedc..b73d824357 100644 > > --- a/xen/arch/x86/hvm/vmx/vmcs.c > > +++ b/xen/arch/x86/hvm/vmx/vmcs.c > > @@ -291,6 +291,12 @@ static int vmx_init_vmcs_config(void) > > _vmx_cpu_based_exec_control &= > > ~(CPU_BASED_CR8_LOAD_EXITING | CPU_BASED_CR8_STORE_EXITING); > > > > +rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap); > > + > > +/* Check whether IPT is supported in VMX operation. */ > > +vmtrace_supported = cpu_has_ipt && > > +(_vmx_misc_cap & VMX_MISC_PT_SUPPORTED); > > There is a subtle corner case here. vmx_init_vmcs_config() is called on > all CPUs, and is supposed to level things down safely if we find any > asymmetry. > > If instead you go with something like this: > > diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c > index b73d824357..6960109183 100644 > --- a/xen/arch/x86/hvm/vmx/vmcs.c > +++ b/xen/arch/x86/hvm/vmx/vmcs.c > @@ -294,8 +294,8 @@ static int vmx_init_vmcs_config(void) > rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap); > > /* Check whether IPT is supported in VMX operation. */ > - vmtrace_supported = cpu_has_ipt && > - (_vmx_misc_cap & VMX_MISC_PT_SUPPORTED); > + if ( !(_vmx_misc_cap & VMX_MISC_PT_SUPPORTED) ) > + vmtrace_supported = false; This is also used during hotplug, so I'm not sure it's safe to turn vmtrace_supported off during runtime, where VMs might be already using it. IMO it would be easier to just set it on the BSP, and then refuse to bring up any AP that doesn't have the feature. TBH I don't think we are likely to find any system with such configuration, but seems more robust than changing vmtrace_supported at runtime. Roger.
Re: [PATCH v2] xen/displif: Protocol version 2
On 7/2/20 10:20 AM, Jürgen Groß wrote: > On 01.07.20 14:07, Oleksandr Andrushchenko wrote: >> On 7/1/20 1:46 PM, Jürgen Groß wrote: >>> On 01.07.20 09:19, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko 1. Add protocol version as an integer Version string, which is in fact an integer, is hard to handle in the code that supports different protocol versions. To simplify that also add the version as an integer. 2. Pass buffer offset with XENDISPL_OP_DBUF_CREATE There are cases when display data buffer is created with non-zero offset to the data start. Handle such cases and provide that offset while creating a display buffer. 3. Add XENDISPL_OP_GET_EDID command Add an optional request for reading Extended Display Identification Data (EDID) structure which allows better configuration of the display connectors over the configuration set in XenStore. With this change connectors may have multiple resolutions defined with respect to detailed timing definitions and additional properties normally provided by displays. If this request is not supported by the backend then visible area is defined by the relevant XenStore's "resolution" property. If backend provides extended display identification data (EDID) with XENDISPL_OP_GET_EDID request then EDID values must take precedence over the resolutions defined in XenStore. 4. Bump protocol version to 2. Signed-off-by: Oleksandr Andrushchenko >>> >>> Reviewed-by: Juergen Gross >> >> Thank you, do you want me to prepare the same for the kernel so >> >> you have it at hand when the time comes? > > It should be added to the kernel only when really needed (i.e. a user of > the new functionality is showing up). We have a patch for that which adds EDID to the existing PV DRM frontend, so while upstreaming those changes I will also include changes to the protocol in the kernel series: for that we need the header in Xen tree first, right? > > > Juergen Thank you, Oleksandr
RE: Ping: [PATCH] build: tweak variable exporting for make 3.82
> -Original Message-
> From: Jan Beulich
> Sent: 02 July 2020 08:45
> To: Paul Durrant
> Cc: Anthony PERARD ;
> xen-devel@lists.xenproject.org; Andrew Cooper
> ; George Dunlap ; Ian
> Jackson
> ; Julien Grall ; Wei Liu
> ; Stefano Stabellini
>
> Subject: Ping: [PATCH] build: tweak variable exporting for make 3.82
>
> On 29.06.2020 18:30, Anthony PERARD wrote:
> > On Fri, Jun 26, 2020 at 05:02:30PM +0200, Jan Beulich wrote:
> >> While I've been running into an issue here only because of an additional
> >> local change I'm carrying, to be able to override just the compiler in
> >> $(XEN_ROOT)/.config (rather than the whole tool chain), in
> >> config/StdGNU.mk:
> >>
> >> ifeq ($(filter-out default undefined,$(origin CC)),)
> >>
> >> I'd like to propose to nevertheless correct the underlying issue:
> >> Exporting an unset variable changes its origin from "undefined" to
> >> "file". This comes into effect because of our adding of -rR to
> >> MAKEFLAGS, which make 3.82 wrongly applies also upon re-invoking itself
> >> after having updated auto.conf{,.cmd}.
> >>
> >> Move the export statement past $(XEN_ROOT)/config/$(XEN_OS).mk inclusion
> >> such that the variables already have their designated values at that
> >> point, while retaining their initial origin up to the point they get
> >> defined.
> >>
> >> Signed-off-by: Jan Beulich
> >>
> >> --- a/xen/Makefile
> >> +++ b/xen/Makefile
> >> @@ -17,8 +17,6 @@ export XEN_BUILD_HOST?= $(shell hostnam
> >> PYTHON_INTERPRETER:= $(word 1,$(shell which python3 python
> >> python2 2>/dev/null) python)
> >> export PYTHON ?= $(PYTHON_INTERPRETER)
> >>
> >> -export CC CXX LD
> >> -
> >> export BASEDIR := $(CURDIR)
> >> export XEN_ROOT := $(BASEDIR)/..
> >>
> >> @@ -42,6 +40,8 @@ export TARGET_ARCH := $(shell echo $
> >> # Allow someone to change their config file
> >> export KCONFIG_CONFIG ?= .config
> >>
> >> +export CC CXX LD
> >> +
> >> .PHONY: default
> >> default: build
> >
> > That patch is fine and it is probably better to export a variable that
> > has a value rather than before the variable is set.
> >
> > Reviewed-by: Anthony PERARD
>
> Paul - thoughts either way as to 4.14? If not to go in now, I
> definitely intend to backport it. (And in fact I'm meanwhile
> considering to enter a make bug for the behavior, unless its
> behavior has changed in later versions.)
>
I agree with Anthony's statement so I'm happy for this to go in 4.14.
Release-acked-by: Paul Durrant
Ping: [PATCH] build: tweak variable exporting for make 3.82
On 29.06.2020 18:30, Anthony PERARD wrote:
> On Fri, Jun 26, 2020 at 05:02:30PM +0200, Jan Beulich wrote:
>> While I've been running into an issue here only because of an additional
>> local change I'm carrying, to be able to override just the compiler in
>> $(XEN_ROOT)/.config (rather than the whole tool chain), in
>> config/StdGNU.mk:
>>
>> ifeq ($(filter-out default undefined,$(origin CC)),)
>>
>> I'd like to propose to nevertheless correct the underlying issue:
>> Exporting an unset variable changes its origin from "undefined" to
>> "file". This comes into effect because of our adding of -rR to
>> MAKEFLAGS, which make 3.82 wrongly applies also upon re-invoking itself
>> after having updated auto.conf{,.cmd}.
>>
>> Move the export statement past $(XEN_ROOT)/config/$(XEN_OS).mk inclusion
>> such that the variables already have their designated values at that
>> point, while retaining their initial origin up to the point they get
>> defined.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -17,8 +17,6 @@ export XEN_BUILD_HOST ?= $(shell hostnam
>> PYTHON_INTERPRETER := $(word 1,$(shell which python3 python python2
>> 2>/dev/null) python)
>> export PYTHON ?= $(PYTHON_INTERPRETER)
>>
>> -export CC CXX LD
>> -
>> export BASEDIR := $(CURDIR)
>> export XEN_ROOT := $(BASEDIR)/..
>>
>> @@ -42,6 +40,8 @@ export TARGET_ARCH := $(shell echo $
>> # Allow someone to change their config file
>> export KCONFIG_CONFIG ?= .config
>>
>> +export CC CXX LD
>> +
>> .PHONY: default
>> default: build
>
> That patch is fine and it is probably better to export a variable that
> has a value rather than before the variable is set.
>
> Reviewed-by: Anthony PERARD
Paul - thoughts either way as to 4.14? If not to go in now, I
definitely intend to backport it. (And in fact I'm meanwhile
considering to enter a make bug for the behavior, unless its
behavior has changed in later versions.)
Thanks, Jan
Re: [PATCH v2 0/7] x86: compat header generation and checking adjustments
On 02.07.2020 09:34, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 01 July 2020 11:23
>> To: xen-devel@lists.xenproject.org
>> Cc: Andrew Cooper ; George Dunlap
>> ; Ian
>> Jackson ; Julien Grall ; Wei Liu
>> ; Stefano
>> Stabellini ; Roger Pau Monné ;
>> Paul Durrant
>>
>> Subject: [PATCH v2 0/7] x86: compat header generation and checking
>> adjustments
>>
>> As was pointed out by 0e2e54966af5 ("mm: fix public declaration of
>> struct xen_mem_acquire_resource"), we're not currently handling structs
>> correctly that have uint64_aligned_t fields. Patch 2 demonstrates that
>> there was also an issue with XEN_GUEST_HANDLE_64().
>>
>> Only the 1st patch was previously sent, but the approach chosen has
>> been changed altogether. All later patches are new. For 4.14 I think
>> at least patch 1 should be considered.
>
> It's now quite a large patch.
Most parts being entirely mechanical, though. But still ...
> Since xen_mem_acquire_resouce() has been fixed, patch #1 (as you say
> in the comment there) is addressing a latent issue and so I’d prefer
> not to take what is now quite a large patch into 4.14.
... fair enough.
Jan
RE: [PATCH v2 0/7] x86: compat header generation and checking adjustments
> -Original Message-
> From: Jan Beulich
> Sent: 01 July 2020 11:23
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Julien Grall ; Wei Liu
> ; Stefano
> Stabellini ; Roger Pau Monné ;
> Paul Durrant
>
> Subject: [PATCH v2 0/7] x86: compat header generation and checking adjustments
>
> As was pointed out by 0e2e54966af5 ("mm: fix public declaration of
> struct xen_mem_acquire_resource"), we're not currently handling structs
> correctly that have uint64_aligned_t fields. Patch 2 demonstrates that
> there was also an issue with XEN_GUEST_HANDLE_64().
>
> Only the 1st patch was previously sent, but the approach chosen has
> been changed altogether. All later patches are new. For 4.14 I think
> at least patch 1 should be considered.
It's now quite a large patch. Since xen_mem_acquire_resouce() has been fixed,
patch #1 (as you say in the comment there) is addressing a latent issue and so
I’d prefer not to take what is now quite a large patch into 4.14.
Paul
>
> 1: x86: fix compat header generation
> 2: x86/mce: add compat struct checking for XEN_MC_inject_v2
> 3: x86/mce: bring hypercall subop compat checking in sync again
> 4: x86/dmop: add compat struct checking for
> XEN_DMOP_map_mem_type_to_ioreq_server
> 5: x86: generalize padding field handling
> 6: flask: drop dead compat translation code
> 7: x86: only generate compat headers actually needed
>
> Jan
Re: [PATCH v2] xen/displif: Protocol version 2
On 01.07.20 14:07, Oleksandr Andrushchenko wrote: On 7/1/20 1:46 PM, Jürgen Groß wrote: On 01.07.20 09:19, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko 1. Add protocol version as an integer Version string, which is in fact an integer, is hard to handle in the code that supports different protocol versions. To simplify that also add the version as an integer. 2. Pass buffer offset with XENDISPL_OP_DBUF_CREATE There are cases when display data buffer is created with non-zero offset to the data start. Handle such cases and provide that offset while creating a display buffer. 3. Add XENDISPL_OP_GET_EDID command Add an optional request for reading Extended Display Identification Data (EDID) structure which allows better configuration of the display connectors over the configuration set in XenStore. With this change connectors may have multiple resolutions defined with respect to detailed timing definitions and additional properties normally provided by displays. If this request is not supported by the backend then visible area is defined by the relevant XenStore's "resolution" property. If backend provides extended display identification data (EDID) with XENDISPL_OP_GET_EDID request then EDID values must take precedence over the resolutions defined in XenStore. 4. Bump protocol version to 2. Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Juergen Gross Thank you, do you want me to prepare the same for the kernel so you have it at hand when the time comes? It should be added to the kernel only when really needed (i.e. a user of the new functionality is showing up). Juergen
