[linux-linus test] 161343: regressions - FAIL

flight 161343 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/161343/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i3

[xen-unstable test] 161340: tolerable FAIL - PUSHED

flight 161340 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/161340/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 161317 test-armhf-armhf-libvirt 16 save

[qemu-mainline test] 161334: regressions - FAIL

flight 161334 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/161334/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs. 152631 test-amd64-i3

Re: [RFC v2 0/7] add function support to IDL

On Wed, Mar 3, 2021 at 8:41 AM Nick Rosbrook wrote: > > On Wed, Mar 03, 2021 at 09:48:02AM +, Ian Jackson wrote: > > Nick Rosbrook writes ("[RFC v2 0/7] add function support to IDL"): > > > At a Xen Summit design session for the golang bindings (see [1]), we > > > agreed that it would be benef

[libvirt test] 161345: regressions - FAIL

flight 161345 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/161345/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-amd64-libvirt

[xen-4.12-testing test] 161330: regressions - FAIL

flight 161330 xen-4.12-testing real [real] flight 161359 xen-4.12-testing real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/161330/ http://logs.test-lab.xenproject.org/osstest/logs/161359/ Regressions :-( Tests which did not succeed and are blocking, including tests which could

Re: [PATCH v3] evtchn/fifo: don't enforce higher than necessary alignment

Hi, On 21/04/2021 15:36, Jan Beulich wrote: Neither the code nor the original commit provide any justification for the need to 8-byte align the struct in all cases. Enforce just as much alignment as the structure actually needs - 4 bytes - by using alignof() instead of a literal number. I had

Re: [PATCH v2 00/20] further population of xen/lib/

Hi Jan, On 21/04/2021 15:15, Jan Beulich wrote: This is to dissolve / move xen/common/string.c. One benefit of moving these functions into an archive is that we can drop some of the related __HAVE_ARCH_* #define-s: By living in an archive, the per-arch functions will preempt any loading of the r

Re: [PATCH v2 17/20] lib: move/rename strnicmp() to strncasecmp()

Hi Jan, On 21/04/2021 15:25, Jan Beulich wrote: While moving the implementation, also rename it to match strcasecmp(), allowing the similar use of a compiler builting in this case as well. NIT: I think you meant builtin here. Cheers, -- Julien Grall

Re: [PATCH 9/9] xen/arm64: Remove READ/WRITE_SYSREG32 helper macros

Hi Michal, On 20/04/2021 08:08, Michal Orzel wrote: AArch64 system registers are 64bit whereas AArch32 ones are 32bit or 64bit. MSR/MRS are expecting 64bit values thus we should get rid of helpers READ/WRITE_SYSREG32 in favour of using READ/WRITE_SYSREG. We should also use register_t type when r

Re: [PATCH 8/9] arm: Change type of hsr to register_t

Hi Michal, On 20/04/2021 08:08, Michal Orzel wrote: AArch64 system registers are 64bit whereas AArch32 ones are 32bit or 64bit. MSR/MRS are expecting 64bit values thus we should get rid of helpers READ/WRITE_SYSREG32 in favour of using READ/WRITE_SYSREG. We should also use register_t type when r

Re: [PATCH v2 15/21] libs/guest: obtain a compatible cpu policy from two input ones

On Wed, Apr 21, 2021 at 01:26:49PM +0200, Roger Pau Monné wrote: > On Wed, Apr 21, 2021 at 10:22:39AM +, Wei Liu wrote: > > On Tue, Apr 13, 2021 at 04:01:33PM +0200, Roger Pau Monne wrote: > > > Introduce a helper to obtain a compatible cpu policy based on two > > > input cpu policies. Currentl

Re: [PATCH 7/9] arm/time,vtimer: Get rid of READ/WRITE_SYSREG32

Hi Michal, On 20/04/2021 08:08, Michal Orzel wrote: AArch64 system registers are 64bit whereas AArch32 ones are 32bit or 64bit. MSR/MRS are expecting 64bit values thus we should get rid of helpers READ/WRITE_SYSREG32 in favour of using READ/WRITE_SYSREG. We should also use register_t type when r

Re: Ping: [PATCH v5 0/6] evtchn: (not so) recent XSAs follow-on

On 21/04/2021 16:23, Jan Beulich wrote: On 27.01.2021 09:13, Jan Beulich wrote: These are grouped into a series largely because of their origin, not so much because there are (heavy) dependencies among them. The main change from v4 is the dropping of the two patches trying to do away with the

Re: [PATCH 7/8] x86/EFI: keep debug info in xen.efi

On 21.04.2021 17:30, Roger Pau Monné wrote: > On Wed, Apr 21, 2021 at 03:06:36PM +0200, Jan Beulich wrote: >> On 21.04.2021 13:15, Roger Pau Monné wrote: >>> On Thu, Apr 01, 2021 at 11:47:03AM +0200, Jan Beulich wrote: --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -312

Re: [PATCH 6/8] x86/EFI: avoid use of GNU ld's --disable-reloc-section when possible

On 21.04.2021 17:20, Roger Pau Monné wrote: > On Wed, Apr 21, 2021 at 02:03:49PM +0200, Jan Beulich wrote: >> On 21.04.2021 12:21, Roger Pau Monné wrote: >>> On Thu, Apr 01, 2021 at 11:46:44AM +0200, Jan Beulich wrote: @@ -189,7 +208,11 @@ EFI_LDFLAGS += --no-insert-timestamp endif

Re: [PATCH v2 0/8] assorted replacement of x[mz]alloc_bytes()

On 21.04.2021 17:23, Andrew Cooper wrote: > On 21/04/2021 15:54, Jan Beulich wrote: >> In the long run I think we want to do away with these type-unsafe >> interfaces, the more that they also request (typically) excess >> alignment. This series of entirely independent patches is >> eliminating the

Re: [PATCH 7/8] x86/EFI: keep debug info in xen.efi

On Wed, Apr 21, 2021 at 03:06:36PM +0200, Jan Beulich wrote: > On 21.04.2021 13:15, Roger Pau Monné wrote: > > On Thu, Apr 01, 2021 at 11:47:03AM +0200, Jan Beulich wrote: > >> ... provided the linker supports it (which it does as of commit > >> 2dfa8341e079 ["ELF DWARF in PE output"]). > >> > >> W

Ping: [PATCH v5 0/6] evtchn: (not so) recent XSAs follow-on

On 27.01.2021 09:13, Jan Beulich wrote: > These are grouped into a series largely because of their origin, > not so much because there are (heavy) dependencies among them. > The main change from v4 is the dropping of the two patches trying > to do away with the double event lock acquires in interdo

Re: [PATCH v2 0/8] assorted replacement of x[mz]alloc_bytes()

On 21/04/2021 15:54, Jan Beulich wrote: > In the long run I think we want to do away with these type-unsafe > interfaces, the more that they also request (typically) excess > alignment. This series of entirely independent patches is > eliminating the instances where it's relatively clear that they'

Re: [PATCH 6/8] x86/EFI: avoid use of GNU ld's --disable-reloc-section when possible

On Wed, Apr 21, 2021 at 02:03:49PM +0200, Jan Beulich wrote: > On 21.04.2021 12:21, Roger Pau Monné wrote: > > On Thu, Apr 01, 2021 at 11:46:44AM +0200, Jan Beulich wrote: > >> @@ -189,7 +208,11 @@ EFI_LDFLAGS += --no-insert-timestamp > >> endif > >> > >> $(TARGET).efi: VIRT_BASE = 0x$(shell $(

Re: [PATCH 6/9] arm/page: Get rid of READ/WRITE_SYSREG32

Hi Michal, On 20/04/2021 08:08, Michal Orzel wrote: AArch64 system registers are 64bit whereas AArch32 ones are 32bit or 64bit. MSR/MRS are expecting 64bit values thus we should get rid of helpers READ/WRITE_SYSREG32 in favour of using READ/WRITE_SYSREG. We should also use register_t type when r

Re: [PATCH] tools/xenstored: Wire properly the command line option -M/--path-max

On 21.04.21 16:02, Julien Grall wrote: From: Julien Grall The command line option -M/--path-max was meant to be added by commit 924bf8c793cb "tools/xenstore: rework path length check" but this wasn't wired through properly. Fix it by adding the missing "case 'M':". Fixes: 924bf8c793cb ("tools

[PATCH v2 8/8] Arm/optee: don't open-code xzalloc_flex_struct()

The current use of xzalloc_bytes() in optee is nearly an open-coded version of xzalloc_flex_struct(), which was introduced after the driver was merged. The main difference is xzalloc_bytes() will also force the allocation to be SMP_CACHE_BYTES aligned and therefore avoid sharing the cache line. W

[PATCH v2 7/8] video/lfb: avoid effectively open-coding xzalloc_array()

There is a difference in generated code: xzalloc_bytes() forces SMP_CACHE_BYTES alignment. But if code really cared about such higher than default alignment, it should request so explicitly rather than using a type-unsafe interface. And if e.g. cache line sharing was a concern, the allocator itself

[PATCH v2 6/8] kexec: avoid effectively open-coding xzalloc_flex_struct()

There is a difference in generated code: xzalloc_bytes() forces SMP_CACHE_BYTES alignment. But if code really cared about such higher than default alignment, it should request so explicitly rather than using a type-unsafe interface. And if e.g. cache line sharing was a concern, the allocator itself

[PATCH v2 5/8] EFI/runtime: avoid effectively open-coding x{m,z}alloc_array()

There is a difference in generated code: x{m,z}alloc_bytes() forces SMP_CACHE_BYTES alignment. But if code really cared about such higher than default alignment, it should request so explicitly rather than using a type-unsafe interface. And if e.g. cache line sharing was a concern, the allocator it

[PATCH v2 4/8] x86/IRQ: avoid over-alignment in alloc_pirq_struct()

In particular in the PV case xzalloc_bytes() forcing SMP_CACHE_BYTES alignment is counterproductive, as the allocation size there is only 40 bytes. And if the code really cared about such higher than default alignment, it should request so explicitly rather than using a type- unsafe interface. Plus

[PATCH v2 3/8] x86/oprofile: avoid effectively open-coding xmalloc_array()

There is a difference in generated code: xmalloc_bytes() forces SMP_CACHE_BYTES alignment. But if code really cared about such higher than default alignment, it should request so explicitly rather than using a type-unsafe interface. And if e.g. cache line sharing was a concern, the allocator itself

[PATCH v2 2/8] x86/HVM: avoid effectively open-coding xmalloc_array()

There is a difference in generated code: xmalloc_bytes() forces SMP_CACHE_BYTES alignment. But if code really cared about such higher than default alignment, it should request so explicitly rather than using a type-unsafe interface. And if e.g. cache line sharing was a concern, the allocator itself

[PATCH v2 1/8] x86/MCE: avoid effectively open-coding xmalloc_array()

There is a difference in generated code: xmalloc_bytes() forces SMP_CACHE_BYTES alignment. But if code really cared about such higher than default alignment, it should request so explicitly rather than using a type-unsafe interface. And if e.g. cache line sharing was a concern, the allocator itself

Re: [PATCH 4/8] x86/EFI: redo .reloc section bounds determination

On Wed, Apr 21, 2021 at 12:44:13PM +0200, Jan Beulich wrote: > On 21.04.2021 11:46, Roger Pau Monné wrote: > > On Thu, Apr 01, 2021 at 11:45:38AM +0200, Jan Beulich wrote: > >> There's no need to link relocs-dummy.o into the ELF binary. The two > >> symbols needed can as well be provided by the lin

[PATCH v2 0/8] assorted replacement of x[mz]alloc_bytes()

In the long run I think we want to do away with these type-unsafe interfaces, the more that they also request (typically) excess alignment. This series of entirely independent patches is eliminating the instances where it's relatively clear that they're not just "blob" allocations. v2 only has com

[ovmf test] 161326: all pass - PUSHED

flight 161326 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/161326/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf d3b0d007a135284981fa750612a47234b83976f9 baseline version: ovmf 0bbc20727598421c4e47d

[PATCH v3] evtchn/fifo: don't enforce higher than necessary alignment

Neither the code nor the original commit provide any justification for the need to 8-byte align the struct in all cases. Enforce just as much alignment as the structure actually needs - 4 bytes - by using alignof() instead of a literal number. While relaxation of the requirements is intended here,

[PATCH v10 11/13] x86/mm: drop old page table APIs

From: Hongyan Xia Two sets of old APIs, alloc/free_xen_pagetable() and lXe_to_lYe(), are now dropped to avoid the dependency on direct map. There are two special cases which still have not been re-written into the new APIs, thus need special treatment: rpt in smpboot.c cannot use ephemeral mapp

[PATCH v10 13/13] x86/mm: drop _new suffix for page table APIs

From: Wei Liu No functional change. Signed-off-by: Wei Liu Signed-off-by: Hongyan Xia Acked-by: Jan Beulich --- xen/arch/x86/mm.c| 44 xen/arch/x86/smpboot.c | 6 +++--- xen/arch/x86/x86_64/mm.c | 2 +- xen/include/asm-x86/mm.h | 4 ++--

[PATCH v10 10/13] x86/smpboot: switch clone_mapping() to new APIs

From: Wei Liu Signed-off-by: Wei Liu Signed-off-by: Hongyan Xia Reviewed-by: Jan Beulich --- Changed in v10: - switch to unmap_domain_page() for pl3e in the middle because it is guaranteed to be overwritten later. Changed in v7: - change patch title - remove initialiser of pl3e. - combine

[PATCH v10 12/13] x86: switch to use domheap page for page tables

From: Hongyan Xia Signed-off-by: Wei Liu Signed-off-by: Hongyan Xia Reviewed-by: Jan Beulich --- Changed in v8: - const qualify pg in alloc_xen_pagetable_new(). --- xen/arch/x86/mm.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/

Re: [PATCH 3/8] x86/EFI: program headers are an ELF concept

On 21.04.2021 16:21, Roger Pau Monné wrote: > On Wed, Apr 21, 2021 at 12:36:16PM +0200, Jan Beulich wrote: >> On 21.04.2021 11:11, Roger Pau Monné wrote: >>> On Thu, Apr 01, 2021 at 11:45:09AM +0200, Jan Beulich wrote: While they apparently do no harm when building xen.efi, their use is p

[PATCH v2 20/20] lib: move strsep()

Allow the function to be individually linkable, discardable, and overridable. Signed-off-by: Jan Beulich --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -40,7 +40,6 @@ obj-y += softirq.o obj-y += smp.o obj-y += spinlock.o obj-y += stop_machine.o -obj-y += string.o obj-y += symbols.o

[PATCH v2 19/20] lib: move strpbrk()

Allow the function to be individually linkable, discardable, and overridable. Signed-off-by: Jan Beulich --- a/xen/common/string.c +++ b/xen/common/string.c @@ -8,26 +8,6 @@ #include #include -#ifndef __HAVE_ARCH_STRPBRK -/** - * strpbrk - Find the first occurrence of a set of characters -

[PATCH v2 18/20] lib: move strspn()

Allow the function to be individually linkable, discardable, and overridable. In fact the function is unused at present, and hence will now get omitted from the final binaries. Signed-off-by: Jan Beulich --- a/xen/common/string.c +++ b/xen/common/string.c @@ -8,33 +8,6 @@ #include #include

[PATCH v2 17/20] lib: move/rename strnicmp() to strncasecmp()

While moving the implementation, also rename it to match strcasecmp(), allowing the similar use of a compiler builting in this case as well. Allow the function to be individually linkable, discardable, and overridable. Signed-off-by: Jan Beulich --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/

[PATCH v2 16/20] lib: move strcasecmp()

Allow the function to be individually linkable, discardable, and overridable. Signed-off-by: Jan Beulich --- a/xen/common/string.c +++ b/xen/common/string.c @@ -41,21 +41,6 @@ int strnicmp(const char *s1, const char } #endif -#ifndef __HAVE_ARCH_STRCASECMP -int (strcasecmp)(const char *s1, c

[PATCH v2 15/20] lib: move strstr()

Allow the function to be individually linkable, discardable, and overridable. Signed-off-by: Jan Beulich --- a/xen/common/string.c +++ b/xen/common/string.c @@ -131,27 +131,6 @@ char * strsep(char **s, const char *ct) } #endif -#ifndef __HAVE_ARCH_STRSTR -/** - * strstr - Find the first subs

[PATCH v2 14/20] lib: move strrchr()

Allow the function to be individually linkable, discardable, and overridable. Signed-off-by: Jan Beulich --- a/xen/common/string.c +++ b/xen/common/string.c @@ -56,24 +56,6 @@ int (strcasecmp)(const char *s1, const c } #endif -#ifndef __HAVE_ARCH_STRRCHR -/** - * strrchr - Find the last occu

[PATCH v2 13/20] lib: move strchr()

Allow the function to be individually linkable, discardable, and overridable. Signed-off-by: Jan Beulich --- a/xen/common/string.c +++ b/xen/common/string.c @@ -56,21 +56,6 @@ int (strcasecmp)(const char *s1, const c } #endif -#ifndef __HAVE_ARCH_STRCHR -/** - * strchr - Find the first occur

[PATCH v2 12/20] lib: move strlcat()

Allow the function to be individually linkable, discardable, and overridable. Signed-off-by: Jan Beulich --- a/xen/common/string.c +++ b/xen/common/string.c @@ -56,35 +56,6 @@ int (strcasecmp)(const char *s1, const c } #endif -#ifndef __HAVE_ARCH_STRLCAT -/** - * strlcat - Append a %NUL term

[PATCH v2 11/20] lib: move strlcpy()

Allow the function to be individually linkable, discardable, and overridable. Signed-off-by: Jan Beulich --- a/xen/common/string.c +++ b/xen/common/string.c @@ -56,32 +56,6 @@ int (strcasecmp)(const char *s1, const c } #endif -#ifndef __HAVE_ARCH_STRLCPY -/** - * strlcpy - Copy a %NUL termin

[PATCH v2 10/20] lib: move strncmp()

Allow the function to be individually linkable, discardable, and overridable. Signed-off-by: Jan Beulich --- a/xen/common/string.c +++ b/xen/common/string.c @@ -111,27 +111,6 @@ size_t strlcat(char *dest, const char *s EXPORT_SYMBOL(strlcat); #endif -#ifndef __HAVE_ARCH_STRNCMP -/** - * strn

[PATCH v2 09/20] lib: move strcmp()

Allow the function to be individually linkable, discardable, and overridable. Signed-off-by: Jan Beulich --- a/xen/common/string.c +++ b/xen/common/string.c @@ -111,25 +111,6 @@ size_t strlcat(char *dest, const char *s EXPORT_SYMBOL(strlcat); #endif -#ifndef __HAVE_ARCH_STRCMP -/** - * strcm

[PATCH v2 08/20] lib: move strnlen()

Allow the function to be individually linkable, discardable, and overridable. Signed-off-by: Jan Beulich --- a/xen/common/string.c +++ b/xen/common/string.c @@ -184,22 +184,6 @@ char *(strrchr)(const char *s, int c) } #endif -#ifndef __HAVE_ARCH_STRNLEN -/** - * strnlen - Find the length of

[PATCH v2 07/20] lib: move strlen()

Allow the function to be individually linkable, discardable, and overridable. Signed-off-by: Jan Beulich --- a/xen/common/string.c +++ b/xen/common/string.c @@ -184,21 +184,6 @@ char *(strrchr)(const char *s, int c) } #endif -#ifndef __HAVE_ARCH_STRLEN -/** - * strlen - Find the length of a

Re: [PATCH 3/8] x86/EFI: program headers are an ELF concept

On Wed, Apr 21, 2021 at 12:36:16PM +0200, Jan Beulich wrote: > On 21.04.2021 11:11, Roger Pau Monné wrote: > > On Thu, Apr 01, 2021 at 11:45:09AM +0200, Jan Beulich wrote: > >> While they apparently do no harm when building xen.efi, their use is > >> potentially misleading. Conditionalize their use

[PATCH v2 06/20] lib: move memchr_inv()

Allow the function to be individually linkable, discardable, and overridable. Signed-off-by: Jan Beulich --- a/xen/common/string.c +++ b/xen/common/string.c @@ -311,26 +311,6 @@ char *(strstr)(const char *s1, const cha } #endif -/** - * memchr_inv - Find an unmatching character in an area of

[PATCH v2 05/20] lib: move memchr()

Allow the function to be individually linkable, discardable, and overridable. Signed-off-by: Jan Beulich --- a/xen/common/string.c +++ b/xen/common/string.c @@ -311,28 +311,6 @@ char *(strstr)(const char *s1, const cha } #endif -#ifndef __HAVE_ARCH_MEMCHR -/** - * memchr - Find a character i

[PATCH v2 04/20] lib: move memcmp()

Allow the function to be individually linkable, discardable, and overridable. Signed-off-by: Jan Beulich --- a/xen/common/string.c +++ b/xen/common/string.c @@ -311,25 +311,6 @@ char *(strstr)(const char *s1, const cha } #endif -#ifndef __HAVE_ARCH_MEMCMP -/** - * memcmp - Compare two areas

[PATCH v2 03/20] lib: move memmove()

By moving the function into an archive, x86 doesn't need to announce anymore that is has its own implementation - symbol resolution by the linker will now guarantee that the generic function remains unused, and the forwarding to the compiler built-in gets done by the common header anyway. Allow th

[PATCH v2 02/20] lib: move memcpy()

By moving the function into an archive, x86 doesn't need to announce anymore that is has its own implementation - symbol resolution by the linker will now guarantee that the generic function remains unused, and the forwarding to the compiler built-in gets done by the common header anyway. Allow th

[PATCH v2 01/20] lib: move memset()

By moving the function into an archive, x86 doesn't need to announce anymore that is has its own implementation - symbol resolution by the linker will now guarantee that the generic function remains unused, and the forwarding to the compiler built-in gets done by the common header anyway. Allow th

[PATCH v10 09/13] x86/smpboot: add exit path for clone_mapping()

From: Wei Liu We will soon need to clean up page table mappings in the exit path. No functional change. Signed-off-by: Wei Liu Signed-off-by: Hongyan Xia Acked-by: Jan Beulich --- Changed in v7: - edit commit message. - begin with rc = 0 and set it to -ENOMEM ahead of if(). --- xen/arch/x8

[PATCH v10 07/13] efi: use new page table APIs in copy_mapping

From: Wei Liu Signed-off-by: Wei Liu Signed-off-by: Hongyan Xia Reviewed-by: Jan Beulich --- Changed in v8: - remove redundant commit message. - unmap l3src based on va instead of mfn. - re-structure if condition around l3dst. Changed in v7: - hoist l3 variables out of the loop to avoid repe

[PATCH v10 08/13] efi: switch to new APIs in EFI code

From: Wei Liu Signed-off-by: Wei Liu Signed-off-by: Hongyan Xia Reviewed-by: Jan Beulich --- Changed in v7: - add blank line after declaration. - rename efi_l4_pgtable into efi_l4t. - pass the mapped efi_l4t to copy_mapping() instead of map it again. - use the alloc_map_clear_xen_pt() API. -

[PATCH v10 05/13] x86_64/mm: switch to new APIs in paging_init

From: Wei Liu Map and unmap pages instead of relying on the direct map. Signed-off-by: Wei Liu Signed-off-by: Hongyan Xia Reviewed-by: Jan Beulich --- Changed in v9: - remove an unnecessary l3mfn variable. Changed in v8: - replace l3/2_ro_mpt_mfn with just mfn since their lifetimes do not

[PATCH v10 06/13] x86_64/mm: switch to new APIs in setup_m2p_table

From: Wei Liu While doing so, avoid repetitive mapping of l2_ro_mpt by keeping it across loops, and only unmap and map it when crossing 1G boundaries. Signed-off-by: Wei Liu Signed-off-by: Hongyan Xia Reviewed-by: Jan Beulich --- Changed in v8: - re-structure if condition around l2_ro_mpt. -

[PATCH v10 04/13] x86_64/mm: introduce pl2e in paging_init

From: Wei Liu We will soon map and unmap pages in paging_init(). Introduce pl2e so that we can use l2_ro_mpt to point to the page table itself. No functional change. Signed-off-by: Wei Liu Acked-by: Jan Beulich --- Changed in v7: - reword commit message. --- xen/arch/x86/x86_64/mm.c | 16 ++

[PATCH v10 03/13] x86/mm: switch to new APIs in modify_xen_mappings

From: Wei Liu Page tables allocated in that function should be mapped and unmapped now. Note that pl2e now maybe mapped and unmapped in different iterations, so we need to add clean-ups for that. Signed-off-by: Wei Liu Signed-off-by: Hongyan Xia Reviewed-by: Jan Beulich --- Changed in v7: -

[PATCH v10 02/13] x86/mm: switch to new APIs in map_pages_to_xen

From: Wei Liu Page tables allocated in that function should be mapped and unmapped now. Take the opportunity to avoid a potential double map in map_pages_to_xen() by initialising pl1e to NULL and only map it if it was not mapped earlier. Signed-off-by: Wei Liu Signed-off-by: Hongyan Xia ---

[PATCH v10 01/13] x86/mm: rewrite virt_to_xen_l*e

From: Wei Liu Rewrite those functions to use the new APIs. Modify its callers to unmap the pointer returned. Since alloc_xen_pagetable_new() is almost never useful unless accompanied by page clearing and a mapping, introduce a helper alloc_map_clear_xen_pt() for this sequence. Signed-off-by: Wei

[PATCH v10 00/13] switch to domheap for Xen page tables

From: Hongyan Xia This series rewrites all the remaining functions and finally makes the switch from xenheap to domheap for Xen page tables, so that they no longer need to rely on the direct map, which is a big step towards removing the direct map. --- Changed in v10: - rebase. - address comment

[PATCH v2 00/20] further population of xen/lib/

This is to dissolve / move xen/common/string.c. One benefit of moving these functions into an archive is that we can drop some of the related __HAVE_ARCH_* #define-s: By living in an archive, the per-arch functions will preempt any loading of the respective functions (objects) from the archive. (Do

Re: [PATCH] tools/xenstored: Wire properly the command line option -M/--path-max

> On 21 Apr 2021, at 15:02, Julien Grall wrote: > > From: Julien Grall > > The command line option -M/--path-max was meant to be added by > commit 924bf8c793cb "tools/xenstore: rework path length check" but this > wasn't wired through properly. > > Fix it by adding the missing "case 'M':".

Re: [PATCH] build: centralize / unify asm-offsets generation

On 20.04.2021 18:20, Roger Pau Monné wrote: > On Tue, Apr 20, 2021 at 05:47:49PM +0200, Jan Beulich wrote: >> On 20.04.2021 17:29, Roger Pau Monné wrote: >>> On Thu, Apr 01, 2021 at 10:33:47AM +0200, Jan Beulich wrote: @@ -399,7 +399,11 @@ include/xen/compile.h: include/xen/compi @sed

[PATCH] tools/xenstored: Wire properly the command line option -M/--path-max

From: Julien Grall The command line option -M/--path-max was meant to be added by commit 924bf8c793cb "tools/xenstore: rework path length check" but this wasn't wired through properly. Fix it by adding the missing "case 'M':". Fixes: 924bf8c793cb ("tools/xenstore: rework path length check") Sig

Re: x86: memset() / clear_page() / page scrubbing

On 15.04.2021 18:21, Andrew Cooper wrote: > On 14/04/2021 09:12, Jan Beulich wrote: >> On 13.04.2021 15:17, Andrew Cooper wrote: >>> Do you have actual numbers from these experiments? >> Attached is the collected raw output from a number of systems. > > Wow Tulsa is vintage.  Is that new enough to

Re: [PATCH v9 10/13] x86/smpboot: switch clone_mapping() to new APIs

On Tue, 2021-04-20 at 14:32 +0200, Jan Beulich wrote: > On 06.04.2021 13:05, Hongyan Xia wrote: > > @@ -742,51 +742,58 @@ static int clone_mapping(const void *ptr, > > root_pgentry_t *rpt) > > } > > } > > > > +UNMAP_DOMAIN_PAGE(pl1e); > > +UNMAP_DOMAIN_PAGE(pl2e); > > +U

Re: [PATCH 2/8] x86/EFI: sections may not live at VA 0 in PE binaries

On 21.04.2021 14:57, Roger Pau Monné wrote: > So from a bit of searching I just did it seems like stab sections > where used during the 90s with ELF, but that this has long been > superseded by DWARF 2 becoming the default in the late 90s, hence I > think it would be fine to just remove those secti

Re: [PATCH 8/8] x86/EFI: don't have an overly large image size

On 21.04.2021 13:18, Roger Pau Monné wrote: > On Thu, Apr 01, 2021 at 11:47:35AM +0200, Jan Beulich wrote: >> While without debug info the difference is benign (so far), since we pad >> the image to 16Mb anyway, forcing the .reloc section to a 2Mb boundary >> causes subsequent .debug_* sections to

Re: [PATCH 7/8] x86/EFI: keep debug info in xen.efi

On 21.04.2021 13:15, Roger Pau Monné wrote: > On Thu, Apr 01, 2021 at 11:47:03AM +0200, Jan Beulich wrote: >> ... provided the linker supports it (which it does as of commit >> 2dfa8341e079 ["ELF DWARF in PE output"]). >> >> Without mentioning debugging sections, the linker would put them at >> VA

Re: [PATCH 2/8] x86/EFI: sections may not live at VA 0 in PE binaries

On Wed, Apr 21, 2021 at 12:32:42PM +0200, Jan Beulich wrote: > On 21.04.2021 10:52, Roger Pau Monné wrote: > > On Thu, Apr 01, 2021 at 11:44:45AM +0200, Jan Beulich wrote: > >> PE binaries specify section addresses by (32-bit) RVA. GNU ld up to at > >> least 2.36 would silently truncate the (negati

[xen-4.14-testing test] 161324: tolerable FAIL - PUSHED

flight 161324 xen-4.14-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/161324/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 161048 test-amd64-i386-xl-qemuu-win7-am

Re: [PATCH] xen/arm: Ensure the vCPU context is seen before clearing the _VPF_down

Hi Stefano, On 21/04/2021 01:38, Stefano Stabellini wrote: On Tue, 20 Apr 2021, Julien Grall wrote: AFAICT, there is nothing in the implementation of XEN_DOMCTL_getvcpucontext that justify the extra barrier (assuming we consider vcpu_pause() as a full memory barrier). From your e-mail, I also

Re: [PATCH 6/8] x86/EFI: avoid use of GNU ld's --disable-reloc-section when possible

On 21.04.2021 12:21, Roger Pau Monné wrote: > On Thu, Apr 01, 2021 at 11:46:44AM +0200, Jan Beulich wrote: >> @@ -189,7 +208,11 @@ EFI_LDFLAGS += --no-insert-timestamp >> endif >> >> $(TARGET).efi: VIRT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, >> A VIRT_START$$,,p') >> +ifeq ($(M

Re: [PATCH v2] xen/pci: Refactor PCI MSI interrupts related code

Hi Jan, > On 21 Apr 2021, at 10:33 am, Jan Beulich wrote: > > On 21.04.2021 11:15, Rahul Singh wrote: >> Hi Roger, >> >>> On 21 Apr 2021, at 9:16 am, Roger Pau Monné wrote: >>> >>> On Wed, Apr 21, 2021 at 08:07:08AM +, Rahul Singh wrote: Hi Jan, > On 20 Apr 2021, at 4:36 pm

Re: [PATCH v9 01/13] x86/mm: rewrite virt_to_xen_l*e

On 21.04.2021 13:33, Hongyan Xia wrote: > On Tue, 2021-04-20 at 14:17 +0200, Jan Beulich wrote: >> On 06.04.2021 13:05, Hongyan Xia wrote: >>> @@ -5305,6 +5339,8 @@ int map_pages_to_xen( >>> pl1e = virt_to_xen_l1e(virt); >>> if ( pl1e == NULL ) >>>

Re: [PATCH v9 01/13] x86/mm: rewrite virt_to_xen_l*e

On Tue, 2021-04-20 at 14:17 +0200, Jan Beulich wrote: > On 06.04.2021 13:05, Hongyan Xia wrote: > > From: Wei Liu > > > > Rewrite those functions to use the new APIs. Modify its callers to > > unmap > > the pointer returned. Since alloc_xen_pagetable_new() is almost > > never > > useful unless ac

Re: [PATCH v2] VT-d: Don't assume register-based invalidation is always supported

On Wed, Apr 21, 2021 at 11:23:13AM +0200, Jan Beulich wrote: >On 20.04.2021 18:17, Roger Pau Monné wrote: >> On Tue, Apr 20, 2021 at 05:38:51PM +0200, Jan Beulich wrote: >>> On 20.04.2021 17:08, Roger Pau Monné wrote: On Thu, Apr 02, 2020 at 04:06:06AM +0800, Chao Gao wrote: > --- a/xen/dr

Re: [PATCH v2 15/21] libs/guest: obtain a compatible cpu policy from two input ones

On Wed, Apr 21, 2021 at 10:22:39AM +, Wei Liu wrote: > On Tue, Apr 13, 2021 at 04:01:33PM +0200, Roger Pau Monne wrote: > > Introduce a helper to obtain a compatible cpu policy based on two > > input cpu policies. Currently this is done by and'ing all CPUID leaves > > and MSR entries, except fo

Re: [PATCH 8/8] x86/EFI: don't have an overly large image size

On Thu, Apr 01, 2021 at 11:47:35AM +0200, Jan Beulich wrote: > While without debug info the difference is benign (so far), since we pad > the image to 16Mb anyway, forcing the .reloc section to a 2Mb boundary > causes subsequent .debug_* sections to go farther beyond 16Mb than > needed. There's no

Re: [PATCH 7/8] x86/EFI: keep debug info in xen.efi

On Thu, Apr 01, 2021 at 11:47:03AM +0200, Jan Beulich wrote: > ... provided the linker supports it (which it does as of commit > 2dfa8341e079 ["ELF DWARF in PE output"]). > > Without mentioning debugging sections, the linker would put them at > VA 0, thus making them unreachable by 32-bit (relativ

Re: [PATCH 4/8] x86/EFI: redo .reloc section bounds determination

On 21.04.2021 11:46, Roger Pau Monné wrote: > On Thu, Apr 01, 2021 at 11:45:38AM +0200, Jan Beulich wrote: >> There's no need to link relocs-dummy.o into the ELF binary. The two >> symbols needed can as well be provided by the linker script. Then our >> mkreloc tool also doesn't need to put them in

Re: [PATCH 3/8] x86/EFI: program headers are an ELF concept

On 21.04.2021 11:11, Roger Pau Monné wrote: > On Thu, Apr 01, 2021 at 11:45:09AM +0200, Jan Beulich wrote: >> While they apparently do no harm when building xen.efi, their use is >> potentially misleading. Conditionalize their use to be for just the ELF >> binary we produce. >> >> No change to the

Re: [PATCH 2/8] x86/EFI: sections may not live at VA 0 in PE binaries

On 21.04.2021 10:52, Roger Pau Monné wrote: > On Thu, Apr 01, 2021 at 11:44:45AM +0200, Jan Beulich wrote: >> PE binaries specify section addresses by (32-bit) RVA. GNU ld up to at >> least 2.36 would silently truncate the (negative) difference when a >> section is placed below the image base. Such

Re: [PATCH v4] tools: create libxensaverestore

On Thu, Apr 15, 2021 at 03:11:38PM +0200, Olaf Hering wrote: > Move all save/restore related code from libxenguest.so into a separate > library libxensaverestore.so. The only consumer is libxl-save-helper. > There is no need to have the moved code mapped all the time in binaries > where libxenguest

Re: [PATCH v3] tools: create libxensaverestore

On Tue, Apr 13, 2021 at 07:20:27PM +0200, Olaf Hering wrote: > Move all save/restore related code from libxenguest.so into a separate > library libxensaverestore.so. The only consumer is libxl-save-helper. > There is no need to have the moved code mapped all the time in binaries > where libxenguest

Re: [PATCH v2 15/21] libs/guest: obtain a compatible cpu policy from two input ones

On Tue, Apr 13, 2021 at 04:01:33PM +0200, Roger Pau Monne wrote: > Introduce a helper to obtain a compatible cpu policy based on two > input cpu policies. Currently this is done by and'ing all CPUID leaves > and MSR entries, except for MSR_ARCH_CAPABILITIES which has the RSBA > bit or'ed. > I tho

[PATCH v4 3/3] unzstd: make helper symbols static

While for the original library's purposes these functions of course want to be externally exposed, we don't need this, and we also don't want this both to prevent unintended use and to keep the name space tidy. (When functions have no callers at all, wrap them with a suitable #ifdef.) This has the

[PATCH v4 2/3] xen/decompress: drop STATIC and INIT

Except for one last instance, all users have been removed in earlier changes. Requested-by: Andrew Cooper Signed-off-by: Jan Beulich Acked-by: Julien Grall --- v3: New. --- a/xen/arch/arm/efi/efi-dom0.c +++ b/xen/arch/arm/efi/efi-dom0.c @@ -28,7 +28,7 @@ #include #include #include "../../

Re: [PATCH 6/8] x86/EFI: avoid use of GNU ld's --disable-reloc-section when possible

On Thu, Apr 01, 2021 at 11:46:44AM +0200, Jan Beulich wrote: > As of commit 6fa7408d72b3 ("ld: don't generate base relocations in PE > output for absolute symbols") I'm feeling sufficiently confident in GNU > ld to use its logic for generating base relocations, which was enabled > for executables a

  1   2   >