Re: multiboot2 and module2 boot issues via GRUB2

On 01.04.2021 03:06, Roman Shaposhnik wrote: > And the obvious next question: is my EVE usecase esoteric enough that > I should just go ahead and do a custom GRUB patch or is there a more > general interest in this? Not sure if it ought to be a grub patch - the issue could as well be dealt with in

Ping: [PATCH 5/5] x86: don't build unused entry code when !PV32

On 04.01.2021 16:53, Roger Pau Monné wrote: > On Mon, Jan 04, 2021 at 02:56:12PM +0100, Jan Beulich wrote: >> On 28.12.2020 16:30, Roger Pau Monné wrote: >>> I would like to have Andrew's opinion on this one (as you and him tend >>> to modify more asm code than myself). There are quite a lot of >>>

Ping: [PATCH 4/5] x86/PV: restrict TLB flushing after mod_l[234]_entry()

On 11.01.2021 14:22, Jan Beulich wrote: > On 11.01.2021 14:00, Roger Pau Monné wrote: >> On Tue, Nov 03, 2020 at 11:57:33AM +0100, Jan Beulich wrote: >>> Just like we avoid to invoke remote root pt flushes when all uses of an >>> L4 table can be accounted for locally, the same can be done for all o

Ping²: [PATCH v2] x86/PV: make post-migration page state consistent

On 23.11.2020 13:50, Jan Beulich wrote: > On 23.11.2020 13:26, Andrew Cooper wrote: >> On 20/11/2020 12:48, Jan Beulich wrote: >>> On 04.11.2020 08:56, Jan Beulich wrote: When a page table page gets de-validated, its type reference count drops to zero (and PGT_validated gets cleared), but

Ping²: [PATCH] x86emul: de-duplicate scatters to the same linear address

On 17.02.2021 09:32, Jan Beulich wrote: > On 05.02.2021 12:28, Jan Beulich wrote: >> On 05.02.2021 11:41, Andrew Cooper wrote: >>> On 10/11/2020 13:26, Jan Beulich wrote: The SDM specifically allows for earlier writes to fully overlapping ranges to be dropped. If a guest did so, hvmemul_p

Ping: [PATCH] libxg: don't use max policy in xc_cpuid_xend_policy()

On 23.11.2020 14:58, Jan Beulich wrote: > On 06.11.2020 16:58, Wei Liu wrote: >> On Thu, Nov 05, 2020 at 04:56:53PM +0100, Jan Beulich wrote: >>> Using max undermines the separation between default and max. For example, >>> turning off AVX512F on an MPX-capable system silently turns on MPX, >>> des

Ping²: [PATCH] x86/CPUID: move some static masks into .init

On 31.07.2020 16:55, Jan Beulich wrote: > On 15.07.2020 09:45, Jan Beulich wrote: >> Except for hvm_shadow_max_featuremask and deep_features they're >> referenced by __init functions only. >> >> Signed-off-by: Jan Beulich >> >> --- a/xen/arch/x86/cpuid.c >> +++ b/xen/arch/x86/cpuid.c >> @@ -16,12

Ping: [PATCH v2] x86: refine guest_mode()

On 27.05.2020 18:23, Jan Beulich wrote: > The 2nd of the assertions as well as the macro's return value have been > assuming we're on the primary stack. While for most IST exceptions we > switch back to the main one when user mode was interrupted, for #DF we > intentionally never do, and hence a #D

[PATCH] x86/ucode: log blob date also for AMD

Like Intel, AMD also records the date in their blobs. The field was merely misnamed as "data_code" so far; this was perhaps meant to be "date_code". Split it into individual fields, just like we did for Intel some time ago, and extend the message logged after a successful update. Signed-off-by: Ja

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

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

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

Except for an additional prereq Arm and x86 have the same needs here, and Arm can also benefit from the recent x86 side improvement. Recurse into arch/*/ only for a phony include target (doing nothing on Arm), and handle asm-offsets itself entirely locally to xen/Makefile. Signed-off-by: Jan Beuli

[libvirt test] 160634: regressions - FAIL

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

[PATCH 0/6] VT-d: assorted cleanup

This is effectively the other "half" of what was submitted as 4.15 candidates in "[PATCH 0/4][4.15?] VT-d: mostly S3 related corrections". 1: improve save/restore of registers across S3 2: don't open-code dmar_readl() 3: bring print_qi_regs() in line with print_iommu_regs() 4: qinval indexes are o

[PATCH 1/6] VT-d: improve save/restore of registers across S3

The static allocation of the save space is not only very inefficient (most of the array slots won't ever get used), but is also the sole reason for a build-time upper bound on the number of IOMMUs. Introduce a structure containing just the one needed field we can't (easily) restore from other in-me

[PATCH 2/6] VT-d: don't open-code dmar_readl()

While at it also drop the unnecessary use of a local variable there. Signed-off-by: Jan Beulich --- a/xen/drivers/passthrough/vtd/iommu.c +++ b/xen/drivers/passthrough/vtd/iommu.c @@ -990,8 +990,7 @@ static void __do_iommu_page_fault(struct } clear_overflow: /* clear primary fault ove

Re: multiboot2 and module2 boot issues via GRUB2

On Thu, Apr 01, 2021 at 09:31:07AM +0200, Jan Beulich wrote: > On 01.04.2021 03:06, Roman Shaposhnik wrote: > > And the obvious next question: is my EVE usecase esoteric enough that > > I should just go ahead and do a custom GRUB patch or is there a more > > general interest in this? > > Not sure

[PATCH 3/6] VT-d: bring print_qi_regs() in line with print_iommu_regs()

Shorten the names printed. There's also no need to go through a local variable. While at it also constify the function's parameter. Signed-off-by: Jan Beulich --- a/xen/drivers/passthrough/vtd/qinval.c +++ b/xen/drivers/passthrough/vtd/qinval.c @@ -33,18 +33,11 @@ static int __must_check inv

[PATCH 4/6] VT-d: qinval indexes are only up to 19 bits wide

There's no need for 64-bit accesses to these registers (outside of initial setup and dumping). Also remove some stray blanks. Signed-off-by: Jan Beulich --- a/xen/drivers/passthrough/vtd/qinval.c +++ b/xen/drivers/passthrough/vtd/qinval.c @@ -42,14 +42,13 @@ static void print_qi_regs(const stru

[PATCH 5/6] VT-d: avoid pointless use of 64-bit constants

When the respective registers are just 32 bits wide there's no point in making corresponding constants 64-bit ones. Signed-off-by: Jan Beulich --- a/xen/drivers/passthrough/vtd/iommu.h +++ b/xen/drivers/passthrough/vtd/iommu.h @@ -121,30 +121,30 @@ #define DMA_TLB_IVA_HINT(x) u64)x) & 1) <<

[PATCH 6/6] VT-d: drop unused #define-s

Signed-off-by: Jan Beulich --- a/xen/drivers/passthrough/vtd/iommu.h +++ b/xen/drivers/passthrough/vtd/iommu.h @@ -471,26 +471,12 @@ struct qinval_entry { /* Queue invalidation head/tail shift */ #define QINVAL_INDEX_SHIFT 4 -#define qinval_present(v) ((v).lo & 1) -#define qinval_fault_disabl

Re: [PATCH 03/21] libs/guest: introduce xc_cpu_policy_t

On Wed, Mar 31, 2021 at 09:10:13PM +0100, Andrew Cooper wrote: > On 23/03/2021 09:58, Roger Pau Monne wrote: > > Introduce an opaque type that is used to store the CPUID and MSRs > > policies of a domain. Such type uses the existing cpu_policy structure > > to store the data, but doesn't expose the

Revert NR_CPUS=1 fix from 4.15 (was: Re: [PATCH] fix for_each_cpu() again for NR_CPUS=1)

On Wed, Mar 31, 2021 at 04:52:47PM +0200, Jan Beulich wrote: > Unfortunately aa50f45332f1 ("xen: fix for_each_cpu when NR_CPUS=1") has > caused quite a bit of fallout with gcc10, e.g. (there are at least two > more similar ones, and I didn't bother trying to find them all): > > In file included fr

Re: [PATCH v3 01/11] x86/hvm: drop vcpu parameter from vlapic EOI callbacks

On Wed, Mar 31, 2021 at 05:24:24PM +0100, Andrew Cooper wrote: > On 31/03/2021 17:02, Jan Beulich wrote: > > On 31.03.2021 12:32, Roger Pau Monne wrote: > >> EOIs are always executed in guest vCPU context, so there's no reason to > >> pass a vCPU parameter around as can be fetched from current. > >

Re: [PATCH v3 02/11] x86/hvm: drop domain parameter from vioapic/vpic EOI callbacks

On Wed, Mar 31, 2021 at 06:04:43PM +0200, Jan Beulich wrote: > On 31.03.2021 12:32, Roger Pau Monne wrote: > > EOIs are always executed in guest vCPU context, so there's no reason to > > pass a domain parameter around as can be fetched from current->domain. > > > > No functional change intended. >

Re: Revert NR_CPUS=1 fix from 4.15 (was: Re: [PATCH] fix for_each_cpu() again for NR_CPUS=1)

On 01.04.2021 11:00, Roger Pau Monné wrote: > On Wed, Mar 31, 2021 at 04:52:47PM +0200, Jan Beulich wrote: >> Unfortunately aa50f45332f1 ("xen: fix for_each_cpu when NR_CPUS=1") has >> caused quite a bit of fallout with gcc10, e.g. (there are at least two >> more similar ones, and I didn't bother t

Re: [PATCH v3 02/11] x86/hvm: drop domain parameter from vioapic/vpic EOI callbacks

On 01.04.2021 11:15, Roger Pau Monné wrote: > On Wed, Mar 31, 2021 at 06:04:43PM +0200, Jan Beulich wrote: >> On 31.03.2021 12:32, Roger Pau Monne wrote: >>> EOIs are always executed in guest vCPU context, so there's no reason to >>> pass a domain parameter around as can be fetched from current->do

[PATCH 0/8] x86/EFI: build adjustments

So far we've taken care of just the immediate breakage caused by binutils 2.36. But we can also take advantage, in particular to avoid "manually" creating base relocations for xen.efi. Since it was requested and is possible with up-to-date binutils, inclusion of debug info in xen.efi is another par

[PATCH 1/8] x86/EFI: drop stale section special casing when generating base relocs

As of commit a6066af5b142 ("xen/init: Annotate all command line parameter infrastructure as const") .init.setup has been part of .init. As of commit 544ad7f5caf5 ("xen/init: Move initcall infrastructure into .init.data") .initcall* have been part of .init. Hence neither can be encountered as a stan

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

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 sections would also be wrongly placed ahead of all "normal" ones. Since, for the time being, we build xen.efi with

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

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 resulting binaries. Signed-off-by: Jan Beulich --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -34,13 +34

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

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 the generated assembler source. Signed-off-by: Jan Beulich --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefi

[PATCH 5/8] x86: drop use of prelink-efi.o

Now that its contents matches prelink.o, use that one uniformly. Signed-off-by: Jan Beulich --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -142,18 +142,12 @@ prelink_lto.o: $(ALL_OBJS) $(ALL_LIBS) # Link it with all the binary objects prelink.o: $(patsubst %/built_in.o,%/built_in_b

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

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 at some point last year (prior to that this would have got done only f

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

... 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 (relative or absolute) relocations. If relocations were resolvable (or absent)

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

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 reason to advance . for establishing __2M_rwdata_end, as all data pas

Re: Revert NR_CPUS=1 fix from 4.15 (was: Re: [PATCH] fix for_each_cpu() again for NR_CPUS=1)

On Thu, Apr 01, 2021 at 11:26:03AM +0200, Jan Beulich wrote: > On 01.04.2021 11:00, Roger Pau Monné wrote: > > On Wed, Mar 31, 2021 at 04:52:47PM +0200, Jan Beulich wrote: > >> Unfortunately aa50f45332f1 ("xen: fix for_each_cpu when NR_CPUS=1") has > >> caused quite a bit of fallout with gcc10, e.g

[PATCH v4 0/3] x86/time: calibration rendezvous adjustments

The first patch was, under a different title and with a different approach, already part of the prior series of the same subject. The other two patches are new, resulting from me spotting further room for improvement (or so I hope). 1: latch to-be-written TSC value early in rendezvous loop 2: yiel

[PATCH v4 1/3] x86/time: latch to-be-written TSC value early in rendezvous loop

To reduce latency on time_calibration_tsc_rendezvous()'s last loop iteration, read the value to be written on the last iteration at the end of the loop body (i.e. in particular at the end of the second to last iteration). On my single-socket 18-core Skylake system this reduces the average loop exi

[PATCH v4 2/3] x86/time: yield to hyperthreads after updating TSC during rendezvous

Since we'd like the updates to be done as synchronously as possible, make an attempt at yielding immediately after the TSC write. Signed-off-by: Jan Beulich --- v4: New. --- a/xen/arch/x86/time.c +++ b/xen/arch/x86/time.c @@ -1708,7 +1708,14 @@ static void time_calibration_tsc_rendezv

[PATCH v4 3/3] x86/time: avoid reading the platform timer in rendezvous functions

Reading the platform timer isn't cheap, so we'd better avoid it when the resulting value is of no interest to anyone. The consumer of master_stime, obtained by time_calibration_{std,tsc}_rendezvous() and propagated through this_cpu(cpu_calibration), is local_time_calibration(). With CONSTANT_TSC t

[linux-linus test] 160625: regressions - FAIL

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

[PATCH 00/23] further population of xen/lib/

This is to dissolve / move xen/common/lib.c and 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)

[PATCH 01/23] lib: move muldiv64()

Make this a separate archive member under lib/. While doing so, don't move latently broken x86 assembly though: Fix the constraints, such that properly extending inputs to 64-bit won't just be a side effect of needing to copy registers, and such that we won't fail to clobber %rdx. Signed-off-by: J

[PATCH 02/23] lib: move 64-bit div/mod compiler helpers

These were built for 32-bit architectures only (the same code could, with some tweaking, sensibly be used to provide TI-mode helpers on 64-bit arch-es) - retain this property, while still avoiding to have a CU without any contents at all. For this, Arm's CONFIG_64BIT gets generalized. Signed-off-b

[PATCH 03/23] string: drop redundant declarations

These standard functions shouldn't need custom declarations. The only case where redundancy might be needed is if there were inline functions there. But we don't have any here (anymore). Prune the per-arch headers of duplicate declarations while moving the asm/string.h inclusion past the declaratio

[PATCH 04/23] 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. Signed-o

[PATCH 05/23] 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. Signed-o

[PATCH 06/23] 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. Signed-o

[PATCH 07/23] lib: move memcmp()

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 of memory - * @cs: One area of memory - * @ct: Another area of memory - * @coun

[PATCH 08/23] lib: move memchr()

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 in an area of memory. - * @s: The memory area - * @c: The byte to search for - *

[PATCH 09/23] lib: move memchr_inv()

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 memory. - * @s: The memory area - * @c: The byte that is expected - * @n: The

[PATCH] x86/viridian: EOI MSR should always happen in affected vCPU context

The HV_X64_MSR_EOI wrmsr should always happen with the target vCPU as current, as there's no support for EOI'ing interrupts on a remote vCPU. While there also turn the unconditional assert at the top of the function into an error on non-debug builds. No functional change intended. Requested-by:

[PATCH 10/23] lib: move strlen()

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 string - * @s: The string to be sized - */ -size_t (strlen)(const char * s) -{

[PATCH 11/23] lib: move strnlen()

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 a length-limited string - * @s: The string to be sized - * @count: The maximum

[PATCH 12/23] lib: move strcmp()

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 -/** - * strcmp - Compare two strings - * @cs: One string - * @ct: Another string - */ -int (

[PATCH 13/23] lib: move strncmp()

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 -/** - * strncmp - Compare two length-limited strings - * @cs: One string - * @ct: Another s

[PATCH 14/23] lib: move strlcpy()

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 terminated string into a sized buffer - * @dest: Where to copy the string to - * @src

[PATCH 15/23] lib: move strlcat()

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 terminated string into a sized buffer - * @dest: Where to copy the string to - * @s

[PATCH 16/23] lib: move strchr()

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 occurrence of a character in a string - * @s: The string to be searched - * @c: The

[PATCH 17/23] lib: move strrchr()

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 occurrence of a character in a string - * @s: The string to be searched - * @c: The

[PATCH 18/23] lib: move strstr()

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 substring in a %NUL terminated string - * @s1: The string to be searched - * @s2: T

[PATCH 19/23] lib: move strcasecmp()

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, const char *s2) -{ -int c1, c2; - -do -{ -c1 = tolower(*s1++

[PATCH 20/23] 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. Signed-off-by: Jan Beulich --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -1223,8 +1223,8 @@ static int __init map_range_to_domain(

[PATCH 21/23] lib: move strspn()

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 -#ifndef __HAVE_ARCH_STRSPN -/** - * strspn - Calculate the length of the ini

[PATCH 22/23] lib: move strpbrk()

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 - * @cs: The string to be searched - * @ct: The characters to search for - */ -c

[PATCH 23/23] lib: move strsep()

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 obj-y += tasklet.o obj-y += time.o --- a/xen/common/string.c +++ /dev/null @@

Re: [PATCH] x86/viridian: EOI MSR should always happen in affected vCPU context

On 01/04/2021 11:22, Roger Pau Monne wrote: The HV_X64_MSR_EOI wrmsr should always happen with the target vCPU as current, as there's no support for EOI'ing interrupts on a remote vCPU. While there also turn the unconditional assert at the top of the function into an error on non-debug builds.

Re: [PATCH] x86/viridian: EOI MSR should always happen in affected vCPU context

On 01.04.2021 12:22, Roger Pau Monne wrote: > The HV_X64_MSR_EOI wrmsr should always happen with the target vCPU > as current, as there's no support for EOI'ing interrupts on a remote > vCPU. > > While there also turn the unconditional assert at the top of the > function into an error on non-debug

Re: [PATCH v3 01/11] x86/hvm: drop vcpu parameter from vlapic EOI callbacks

On 31.03.2021 12:32, Roger Pau Monne wrote: > EOIs are always executed in guest vCPU context, so there's no reason to > pass a vCPU parameter around as can be fetched from current. While not overly problematic, I'd like to point out that there's not a single vcpu parameter being dropped here - in

Re: [PATCH] x86/ucode: log blob date also for AMD

On 01/04/2021 09:28, Jan Beulich wrote: > Like Intel, AMD also records the date in their blobs. The field was > merely misnamed as "data_code" so far; this was perhaps meant to be > "date_code". Split it into individual fields, just like we did for Intel > some time ago, and extend the message logg

Re: [PATCH] libxg: don't use max policy in xc_cpuid_xend_policy()

On 05/11/2020 15:56, Jan Beulich wrote: > Using max undermines the separation between default and max. For example, > turning off AVX512F on an MPX-capable system silently turns on MPX, > despite this not being part of the default policy anymore. Since the > information is used only for determining

Re: [PATCH 1/8] x86/EFI: drop stale section special casing when generating base relocs

On 01/04/2021 10:44, Jan Beulich wrote: > As of commit a6066af5b142 ("xen/init: Annotate all command line > parameter infrastructure as const") .init.setup has been part of .init. > As of commit 544ad7f5caf5 ("xen/init: Move initcall infrastructure into > .init.data") .initcall* have been part of .

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

Hi Jan, On 01/04/2021 11:14, Jan Beulich wrote: This is to dissolve / move xen/common/lib.c and 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

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

On 01/04/2021 10:44, 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 sections would also be > wrongly placed ahead of all "normal" ones. S

[ANNOUNCEMENT] XenSummit CFP Extended to 9 April

FYI, The CFP for the XenSummit has been extended from 2 April (tomorrow) to 9 April. -George Dunlap

Re: [PATCH] x86/viridian: EOI MSR should always happen in affected vCPU context

On 01/04/2021 11:22, Roger Pau Monne wrote: > The HV_X64_MSR_EOI wrmsr should always happen with the target vCPU > as current, as there's no support for EOI'ing interrupts on a remote > vCPU. > > While there also turn the unconditional assert at the top of the > function into an error on non-debug

Re: [PATCH] x86/hvm: Fix double free from vlapic_init() early error path

On 31/03/2021 15:03, Jan Beulich wrote: > On 31.03.2021 15:31, Andrew Cooper wrote: >> vlapic_init()'s caller calls vlapic_destroy() on error. Therefore, the error >> path from __map_domain_page_global() failing would doubly free >> vlapic->regs_page. > I'm having difficulty seeing this. What I fi

Re: [PATCH 05/21] libs/guest: introduce helper to fetch a domain cpu policy

On 31/03/2021 12:06, Roger Pau Monné wrote: > On Tue, Mar 30, 2021 at 05:37:02PM +0200, Jan Beulich wrote: >> On 23.03.2021 10:58, Roger Pau Monne wrote: >>> Such helper is based on the existing functions to fetch a CPUID and >>> MSR policies, but uses the xc_cpu_policy_t type to return the data to

Re: [PATCH] x86/viridian: EOI MSR should always happen in affected vCPU context

On 01.04.2021 14:44, Andrew Cooper wrote: > On 01/04/2021 11:22, Roger Pau Monne wrote: >> The HV_X64_MSR_EOI wrmsr should always happen with the target vCPU >> as current, as there's no support for EOI'ing interrupts on a remote >> vCPU. >> >> While there also turn the unconditional assert at the

[PATCH for-4.15 2/7] CHANGELOG.md: xl PCI configuration doc, xenstore MTU entries

Signed-off-by: George Dunlap --- CC: Paul Durrant CC: Ian Jackson CC: Wei Liu --- CHANGELOG.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index f7ce6682b9..086a0e50d0 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -15,6 +15,7 @@ The forma

[PATCH for-4.15 7/7] CHANGELOG.md: irq-max-guests

Signed-off-by: George Dunlap --- CC: Igor Druzhinin CC: Jan Beulich CC: Ian Jackson --- CHANGELOG.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 9c272a0113..7237b0a020 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -33,6 +33,7 @@ The format is based o

[PATCH for-4.15 5/7] CHANGELOG.md: Various new entries, mostly x86

...Grouped mostly by submitter / maintainer Signed-off-by: George Dunlap --- CC: Ian Jackson CC: Andrew Cooper CC: Jan Beulich CC: Roger Pau Monne --- CHANGELOG.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index b3325a8371..2f26cd5c87 100644 --- a/CHA

[PATCH for-4.15 1/7] CHANGELOG.md: Mention XEN_SCRIPT_DIR

Signed-off-by: George Dunlap --- CC: Olaf Hering CC: Ian Jackson --- CHANGELOG.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 8964bacf73..f7ce6682b9 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -22,6 +22,8 @@ The format is based on [Keep a Change

[PATCH for-4.15 3/7] CHANGELOG.md: Some additional affordances in various xl subcommands

Signed-off-by: George Dunlap Signed-off-by: Ian Jackson --- CC: Ian Jackson --- CHANGELOG.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 086a0e50d0..a12dab1c33 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -25,6 +25,7 @@ The format is based on [Keep a

[PATCH for-4.15 6/7] CHANGELOG.md: Various entries, mostly xenstore

...grouped by submitters / maintainers Signed-off-by: George Dunlap --- CC: Juergen Gross CC: Jan Beulich CC: Ian Jackson --- CHANGELOG.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 2f26cd5c87..9c272a0113 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.

[PATCH for-4.15 4/7] CHANGELOG.md: Mention various ARM errata

Signed-off-by: George Dunlap --- CC: Ian Jackson CC: Stefano Stabellini CC: Julien Grall --- CHANGELOG.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index a12dab1c33..b3325a8371 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -26,6 +26,7 @@ The format is ba

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

On 01.04.2021 13:54, Julien Grall wrote: > On 01/04/2021 11:14, Jan Beulich wrote: >> This is to dissolve / move xen/common/lib.c and 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 >>

Re: [PATCH] x86/hvm: Fix double free from vlapic_init() early error path

On 01.04.2021 15:20, Andrew Cooper wrote: > On 31/03/2021 15:03, Jan Beulich wrote: >> On 31.03.2021 15:31, Andrew Cooper wrote: >>> vlapic_init()'s caller calls vlapic_destroy() on error. Therefore, the >>> error >>> path from __map_domain_page_global() failing would doubly free >>> vlapic->regs

Re: [PATCH] x86/hvm: Fix double free from vlapic_init() early error path

On 01/04/2021 14:45, Jan Beulich wrote: > On 01.04.2021 15:20, Andrew Cooper wrote: >> On 31/03/2021 15:03, Jan Beulich wrote: >>> On 31.03.2021 15:31, Andrew Cooper wrote: vlapic_init()'s caller calls vlapic_destroy() on error. Therefore, the error path from __map_domain_page_glob

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

On 01.04.2021 14:01, Andrew Cooper wrote: > On 01/04/2021 10:44, 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 sections would also be

Re: [PATCH for-4.15 6/7] CHANGELOG.md: Various entries, mostly xenstore

On 01.04.21 15:38, George Dunlap wrote: ...grouped by submitters / maintainers Signed-off-by: George Dunlap Reviewed-by: Juergen Gross Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature

Re: [PATCH 04/21] libs/guest: introduce helper to fetch a system cpu policy

On 23/03/2021 09:58, Roger Pau Monne wrote: > Such helper is based on the existing functions to fetch a CPUID and > MSR policies, but uses the xc_cpu_policy_t type to return the data to > the caller. > > Note some helper functions are introduced, those are split from > xc_cpu_policy_get_system beca

Re: [PATCH for-4.15 6/7] CHANGELOG.md: Various entries, mostly xenstore

On 01/04/2021 14:38, George Dunlap wrote: > ...grouped by submitters / maintainers > > Signed-off-by: George Dunlap > --- > CC: Juergen Gross > CC: Jan Beulich > CC: Ian Jackson > --- > CHANGELOG.md | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/CHANGELOG.md b/CHANGELOG.md > index

Re: [PATCH 5/5] x86: don't build unused entry code when !PV32

On Wed, Nov 25, 2020 at 09:51:33AM +0100, Jan Beulich wrote: > Except for the initial part of cstar_enter compat/entry.S is all dead > code in this case. Further, along the lines of the PV conditionals we > already have in entry.S, make code PV32-conditional there too (to a > fair part because this

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

Hi Jan, On 01/04/2021 14:43, Jan Beulich wrote: On 01.04.2021 13:54, Julien Grall wrote: On 01/04/2021 11:14, Jan Beulich wrote: This is to dissolve / move xen/common/lib.c and xen/common/string.c. One benefit of moving these functions into an archive is that we can drop some of the related __

Re: [PATCH for-4.15 4/7] CHANGELOG.md: Mention various ARM errata

On 01.04.2021 15:38, George Dunlap wrote: > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -26,6 +26,7 @@ The format is based on [Keep a > Changelog](https://keepachangelog.com/en/1.0.0/) > - Added XEN_SCRIPT_DIR configuration option to specify location for Xen > scripts, rather than hard-coding

Re: [PATCH] x86/CPUID: move some static masks into .init

On Wed, Jul 15, 2020 at 09:45:47AM +0200, Jan Beulich wrote: > Except for hvm_shadow_max_featuremask and deep_features they're > referenced by __init functions only. > > Signed-off-by: Jan Beulich AFAICT those are still only used by __init functions: Acked-by: Roger Pau Monné And making those

Re: [PATCH for-4.15 6/7] CHANGELOG.md: Various entries, mostly xenstore

> On Apr 1, 2021, at 3:00 PM, Andrew Cooper wrote: > > On 01/04/2021 14:38, George Dunlap wrote: >> ...grouped by submitters / maintainers >> >> Signed-off-by: George Dunlap >> --- >> CC: Juergen Gross >> CC: Jan Beulich >> CC: Ian Jackson >> --- >> CHANGELOG.md | 3 +++ >> 1 file changed,

Re: [PATCH for-4.15 5/7] CHANGELOG.md: Various new entries, mostly x86

On 01.04.2021 15:38, George Dunlap wrote: > ...Grouped mostly by submitter / maintainer > > Signed-off-by: George Dunlap Acked-by: Jan Beulich

[xen-unstable-smoke test] 160641: tolerable all pass - PUSHED

flight 160641 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/160641/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 1

  1   2   >