Re: [PATCH 3/6] x86/cpuid: Rename FSCAPINTS to X86_NR_FEAT

On 04.05.2023 21:39, Andrew Cooper wrote: > The latter is more legible, and consistent with X86_NR_{CAPS,SYNTH,BUG} which > already exist. > > No functional change. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich And in the light of this the name choice in the earlier patch is probably

Re: [PATCH 2/6] x86/cpuid: Rename NCAPINTS to X86_NR_CAPS

On 04.05.2023 21:39, Andrew Cooper wrote: > The latter is more legible, and consistent with X86_NR_{SYNTH,BUG} which > already exist. > > No functional change. > > Signed-off-by: Andrew Cooper I can live with this as-is, so Acked-by: Jan Beulich yet ... > --- a/xen/arch/x86/include/asm/cpufea

Re: [PATCH 1/6] x86/cpu-policy: Drop build time cross-checks of featureset sizes

On 04.05.2023 21:39, Andrew Cooper wrote: > These BUILD_BUG_ON()s exist to cover the curious absence of a diagnostic for > code which looks like: > > uint32_t foo[1] = { 1, 2, 3 }; > > However, GCC 12 at least does now warn for this: > > foo.c:1:24: error: excess elements in array initialize

Re: [PATCH v3 04/14 RESEND] cpufreq: Add Hardware P-State (HWP) driver

On 05.05.2023 17:35, Jason Andryuk wrote: > On Fri, May 5, 2023 at 3:01 AM Jan Beulich wrote: >> >> On 04.05.2023 18:56, Jason Andryuk wrote: >>> On Thu, May 4, 2023 at 9:11 AM Jan Beulich wrote: On 01.05.2023 21:30, Jason Andryuk wrote: > --- a/docs/misc/xen-command-line.pandoc > ++

Re: [PATCH RFC] build: respect top-level .config also for out-of-tree hypervisor builds

On 05.05.2023 18:08, Anthony PERARD wrote: > On Wed, Mar 15, 2023 at 03:58:59PM +0100, Jan Beulich wrote: >> With in-tree builds Config.mk includes a .config file (if present) from >> the top-level directory. Similar functionality is wanted with out-of- >> tree builds. Yet the concept of "top-level

[ovmf test] 180573: all pass - PUSHED

flight 180573 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/180573/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 8dbf868e02c71b407e31f9b41b5266169c702812 baseline version: ovmf 4dea9e4a0e9db43124043

Re: [PATCH] libxl: arm: Allow grant mappings for backends running on Dom0

On 05-05-23, 16:11, Oleksandr Tyshchenko wrote: > I was going to propose an idea, but I have just realized that you already > voiced it here [1] )) > So what you proposed there sounds reasonable to me. > > I will just rephrase it according to my understanding: > > We probably need to consider tra

[linux-linus test] 180571: regressions - FAIL

flight 180571 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/180571/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-qcow2 19 guest-start/debian.repeat fail REGR. vs. 180278 test-armhf-armh

[linux-linus test] 180570: regressions - FAIL

flight 180570 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/180570/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit1 8 xen-boot fail REGR. vs. 180278 Tests which are fai

[linux-linus test] 180567: regressions - FAIL

flight 180567 linux-linus real [real] flight 180569 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/180567/ http://logs.test-lab.xenproject.org/osstest/logs/180569/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run

[xen-unstable test] 180566: tolerable FAIL

flight 180566 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/180566/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-libvirt 7 xen-installfail pass in 180555 test-amd64-i386-xl-qemut-stubdom