[linux-5.4 test] 174618: regressions - trouble: fail/pass/starved

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

RE: [PATCH for-4.17 v2] hvm/apic: repurpose the reporting of the APIC assist options

Hi Roger, > Subject: Re: [PATCH for-4.17 v2] hvm/apic: repurpose the reporting of the > APIC assist options > > On 04/11/2022 16:18, Roger Pau Monne wrote: > > The current reporting of the hardware assisted APIC options is done by > > checking "virtualize APIC accesses" which is not very

Re: Revert of the 4.17 hypercall handler changes Re: [PATCH-for-4.17] xen: fix generated code for calling hypercall handlers

> On 4 Nov 2022, at 05:01, Andrew Cooper wrote: > > The series claims "This is beneficial to performance and avoids > speculation issues.", c/s 8523851dbc4. > > That half sentence is literally the sum total of justification given for > this being related to speculation. The cover letter,

Re: [PATCH for-4.17 v2] hvm/apic: repurpose the reporting of the APIC assist options

On 04/11/2022 16:18, Roger Pau Monne wrote: The current reporting of the hardware assisted APIC options is done by checking "virtualize APIC accesses" which is not very helpful, as that feature doesn't avoid a vmexit, instead it does provide some help in order to detect APIC MMIO accesses in

Re: [PATCH for-4.17 2/2] hvm/apic: repurpose the reporting of the APIC assist options

On 04/11/2022 16:10, Roger Pau Monné wrote: On Fri, Nov 04, 2022 at 04:05:05PM +, Paul Durrant wrote: On 04/11/2022 16:01, Roger Pau Monné wrote: On Fri, Nov 04, 2022 at 03:55:54PM +, Paul Durrant wrote: On 04/11/2022 14:22, Roger Pau Monne wrote: The current reporting of the

Re: [PATCH v2 5/5] x86: switch to cpu_feature_enabled() for X86_FEATURE_XENPV

On 11/4/22 00:27, Juergen Gross wrote: > Convert the remaining cases of static_cpu_has(X86_FEATURE_XENPV) and > boot_cpu_has(X86_FEATURE_XENPV) to use cpu_feature_enabled(), allowing > more efficient code in case the kernel is configured without > CONFIG_XEN_PV. As with the rest: Acked-by: Dave

[xen-unstable test] 174616: tolerable trouble: fail/pass/starved

flight 174616 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/174616/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-examine 5 host-install broken pass in 174607

Re: [XEN v2] xen/Arm: Enforce alignment check for atomic read/write

Hi Ayan, > On 4 Nov 2022, at 16:23, Ayan Kumar Halder wrote: > > From: Ayan Kumar Halder > > Refer ARM DDI 0487I.a ID081822, B2.2.1 > "Requirements for single-copy atomicity > > - A read that is generated by a load instruction that loads a single > general-purpose register and is aligned to

[XEN v2] xen/Arm: Enforce alignment check for atomic read/write

From: Ayan Kumar Halder Refer ARM DDI 0487I.a ID081822, B2.2.1 "Requirements for single-copy atomicity - A read that is generated by a load instruction that loads a single general-purpose register and is aligned to the size of the read in the instruction is single-copy atomic. -A write that is

[PATCH for-4.17 v2] hvm/apic: repurpose the reporting of the APIC assist options

The current reporting of the hardware assisted APIC options is done by checking "virtualize APIC accesses" which is not very helpful, as that feature doesn't avoid a vmexit, instead it does provide some help in order to detect APIC MMIO accesses in vmexit processing. Repurpose the current

Re: [PATCH for-4.17 2/2] hvm/apic: repurpose the reporting of the APIC assist options

On Fri, Nov 04, 2022 at 04:05:05PM +, Paul Durrant wrote: > On 04/11/2022 16:01, Roger Pau Monné wrote: > > On Fri, Nov 04, 2022 at 03:55:54PM +, Paul Durrant wrote: > > > On 04/11/2022 14:22, Roger Pau Monne wrote: > > > > The current reporting of the hardware assisted APIC options is

Re: [PATCH for-4.17 2/2] hvm/apic: repurpose the reporting of the APIC assist options

On 04/11/2022 16:01, Roger Pau Monné wrote: On Fri, Nov 04, 2022 at 03:55:54PM +, Paul Durrant wrote: On 04/11/2022 14:22, Roger Pau Monne wrote: The current reporting of the hardware assisted APIC options is done by checking "virtualize APIC accesses" which is not very helpful, as that

Re: [PATCH for-4.17 2/2] hvm/apic: repurpose the reporting of the APIC assist options

On Fri, Nov 04, 2022 at 03:55:54PM +, Paul Durrant wrote: > On 04/11/2022 14:22, Roger Pau Monne wrote: > > The current reporting of the hardware assisted APIC options is done by > > checking "virtualize APIC accesses" which is not very helpful, as that > > feature doesn't avoid a vmexit,

Re: [PATCH for-4.17 2/2] hvm/apic: repurpose the reporting of the APIC assist options

On 04/11/2022 14:22, Roger Pau Monne wrote: The current reporting of the hardware assisted APIC options is done by checking "virtualize APIC accesses" which is not very helpful, as that feature doesn't avoid a vmexit, instead it does provide some help in order to detect APIC MMIO accesses in

Re: [PATCH for-4.17 1/2] viridian: suggest MSR APIC accesses if MSR accesses are accelerated

On 04/11/2022 14:22, Roger Pau Monne wrote: The "APIC register virtualization" Intel hardware feature applies to both MMIO or MSR APIC accesses depending on whether "virtualize x2APIC mode" is also available. As such also suggest MSR APIC accesses if both "APIC register virtualization" and

Re: [PATCH v2 4/5] x86: remove X86_FEATURE_XENPV usage in setup_cpu_entry_area()

On 11/4/22 00:27, Juergen Gross wrote: > Testing of X86_FEATURE_XENPV in setup_cpu_entry_area() can be removed, > as this code path is 32-bit only, and Xen PV guests are not supporting > 32-bit mode. Acked-by: Dave Hansen

Re: [PATCH v2 3/5] x86: drop 32-bit Xen PV guest code in update_task_stack()

On 11/4/22 00:26, Juergen Gross wrote: > Testing for Xen PV guest mode in a 32-bit only code section can be > dropped, as Xen PV guests are supported in 64-bit mode only. > > While at it switch from boot_cpu_has() to cpu_feature_enabled() in the > 64-bit part of the code. Acked-by: Dave Hansen

RE: [PATCH for-4.17 0/2] vapic: followup from assisted APIC series

Hi Roger, Thanks for the patches, > Subject: [PATCH for-4.17 0/2] vapic: followup from assisted APIC series > > Hello, > > Patch 1 is a plain bugfix for a feature we expose in viridian, which is > kind of unrelated to the series but patch 2 in its current form depends > on it. > > Patch 2 is

RE: [PATCH for-4.17] Revert "x86/HVM: also dump stacks from show_execution_state()"

Hi Roger, > -Original Message- > From: Roger Pau Monne > Subject: [PATCH for-4.17] Revert "x86/HVM: also dump stacks from > show_execution_state()" > > This reverts commit adb715db698bc8ec3b88c24eb88b21e9da5b6c07. > > The dumping of stacks for HVM guests is problematic, since it

Re: [PATCH for-4.17] Revert "x86/HVM: also dump stacks from show_execution_state()"

On 04/11/2022 14:43, Roger Pau Monne wrote: > This reverts commit adb715db698bc8ec3b88c24eb88b21e9da5b6c07. > > The dumping of stacks for HVM guests is problematic, since it requires > taking the p2m lock in order to walk the guest page tables and the > p2m. > > The suggested solution to the issue

Re: [PATCH v2 2/5] x86: remove unneeded 64-bit dependency in arch_enter_from_user_mode()

On 11/4/22 00:26, Juergen Gross wrote: > The check for 64-bit mode when testing X86_FEATURE_XENPV isn't needed, > as Xen PV guests are no longer supported in 32-bit mode. Tiniest nit if you revise this: please call out that this "no longer supported" thing is enforced in Kconfig. It's not just

Re: [PATCH v2 1/5] x86: add X86_FEATURE_XENPV to disabled-features.h

On 11/4/22 00:26, Juergen Gross wrote: > Add X86_FEATURE_XENPV to the features handled specially in > disabled-features.h. Acked-by: Dave Hansen

[libvirt test] 174614: tolerable all pass - PUSHED

flight 174614 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/174614/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 174598 test-armhf-armhf-libvirt-raw 15

[PATCH for-4.17] Revert "x86/HVM: also dump stacks from show_execution_state()"

This reverts commit adb715db698bc8ec3b88c24eb88b21e9da5b6c07. The dumping of stacks for HVM guests is problematic, since it requires taking the p2m lock in order to walk the guest page tables and the p2m. The suggested solution to the issue is to introduce and use a lockless p2m walker, that

[PATCH for-4.17 0/2] vapic: followup from assisted APIC series

Hello, Patch 1 is a plain bugfix for a feature we expose in viridian, which is kind of unrelated to the series but patch 2 in its current form depends on it. Patch 2 is the actual meat and changes which features get reported as part of the x{2,}APIC assist flag. This is an attempt to repurpose

[PATCH for-4.17 1/2] viridian: suggest MSR APIC accesses if MSR accesses are accelerated

The "APIC register virtualization" Intel hardware feature applies to both MMIO or MSR APIC accesses depending on whether "virtualize x2APIC mode" is also available. As such also suggest MSR APIC accesses if both "APIC register virtualization" and "virtualize x2APIC mode" features are available.

[PATCH for-4.17 2/2] hvm/apic: repurpose the reporting of the APIC assist options

The current reporting of the hardware assisted APIC options is done by checking "virtualize APIC accesses" which is not very helpful, as that feature doesn't avoid a vmexit, instead it does provide some help in order to detect APIC MMIO accesses in vmexit processing. Repurpose the current

[ovmf test] 174623: all pass - PUSHED

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

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

flight 174622 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/174622/ 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

[ovmf test] 174620: all pass - PUSHED

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

Re: [XEN v2 12/12] xen/Arm: GICv3: Enable GICv3 for AArch32

On 04/11/2022 12:30, Julien Grall wrote: > > > > > > On Fri, 4 Nov 2022 at 12:09, Ayan Kumar Halder > wrote: > > > On 04/11/2022 09:55, Michal Orzel wrote: > > Hi Ayan, > Hi Michal, > > > > On 31/10/2022 16:13, Ayan Kumar Halder wrote:

Re: [XEN v2 12/12] xen/Arm: GICv3: Enable GICv3 for AArch32

On Fri, 4 Nov 2022 at 12:09, Ayan Kumar Halder wrote: > > On 04/11/2022 09:55, Michal Orzel wrote: > > Hi Ayan, > Hi Michal, > > > > On 31/10/2022 16:13, Ayan Kumar Halder wrote: > >> > >> Refer ARM DDI 0487G.b ID072021, > >> D13.2.86 - > >> ID_PFR1_EL1, AArch32 Processor Feature Register 1 > >>

Re: [XEN v2 12/12] xen/Arm: GICv3: Enable GICv3 for AArch32

On 04/11/2022 09:55, Michal Orzel wrote: Hi Ayan, Hi Michal, On 31/10/2022 16:13, Ayan Kumar Halder wrote: Refer ARM DDI 0487G.b ID072021, D13.2.86 - ID_PFR1_EL1, AArch32 Processor Feature Register 1 GIC, bits[31:28] == 0b0001 for GIC3.0 on Aarch32 One can now enable GICv3 on AArch32

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

flight 174621 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/174621/ 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

Re: [PATCH v3 23/23] drm/fb-helper: Clarify use of last_close and output_poll_changed

On 11/3/22 16:14, Thomas Zimmermann wrote: > Clarify documentation in the use of struct drm_driver.last_close and > struct drm_mode_config_funcs.output_poll_changed. Those callbacks should > not be said for fbdev implementations on top of struct drm_client_funcs. > > Signed-off-by: Thomas

Re: [PATCH for-4.17 v3 1/2] amd/virt_ssbd: set SSBD at vCPU context switch

On Fri, Nov 04, 2022 at 09:10:21AM +0100, Jan Beulich wrote: > On 03.11.2022 18:02, Roger Pau Monne wrote: > > The current logic for AMD SSBD context switches it on every > > vm{entry,exit} if the Xen and guest selections don't match. This is > > expensive when not using SPEC_CTRL, and hence

Re: [PATCH v3 20/23] drm/fb-helper: Set flag in struct drm_fb_helper for leaking physical addresses

On 11/3/22 16:14, Thomas Zimmermann wrote: > Uncouple the parameter drm_leak_fbdev_smem from the implementation by > setting a flag in struct drm_fb_helper. This will help to move the > generic fbdev emulation into its own source file, while keeping the > parameter in drm_fb_helper.c. No

RE: [PATCH v6 00/11] xen/arm: Add Armv8-R64 MPU support to Xen - Part#1

Sorry for the wrong patch version. This is the first version of this series. Cheers, Wei Chen > -Original Message- > From: Wei Chen > Sent: 2022年11月4日 18:08 > To: xen-devel@lists.xenproject.org > Cc: nd ; Wei Chen ; Stefano Stabellini > ; Julien Grall ; Bertrand Marquis > ; Volodymyr

[PATCH v6 09/11] xen/arm64: create boot-time MPU protection regions

From: Penny Zheng Like boot-time page table in MMU system, we need a boot-time MPU protection region configuration in MPU system so Xen can fetch code and data from normal memory. This operation need to access Armv8-R MPU system registers, but these system registers are not supported in GCC

[PATCH v6 10/11] xen/arm64: introduce helpers for MPU enable/disable

From: Penny Zheng We need some helpers for Xen to enable/disable MPU in boot-time and runtime. For MPU enable helper, we know that it's an essential requirement of MPU system. But for MPU disable, we need to use it for some special situations. For example, in the progress of tranferring from

[PATCH v6 11/11] xen/arm64: add setup_fixmap and remove_identity_mapping for MPU

From: Penny Zheng setup_fixmap and remove_identity_mapping are two functions that are used in Xen boot-time code flow. We implement these two functions for MPU system, in this case, the code flow in head.S doesn't need to use #ifdef to gate MPU/MMU code. In MMU system, setup_fixmap is used for

[PATCH v6 08/11] xen/arm64: move MMU related code from head.S to head_mmu.S

There are lots of MMU specific code in head.S. This code will not be used in MPU systems. If we use #ifdef to gate them, the code will become messy and hard to maintain. So we move MMU related code to head_mmu.S, and keep common code still in head.S. As we need to access "fail" and "puts"

[PATCH v6 06/11] xen/arm: split MMU and MPU config files from config.h

Xen defines some global configuration macros for Arm in config.h. We still want to use it for Armv8-R systems, but there are some address related macros that are defined for MMU systems. These macros will not be used by MPU systems, Adding ifdefery with CONFIG_HAS_MPU to gate these macros will

[PATCH v6 07/11] xen/arm: implement FIXMAP_ADDR for MPU systems

FIXMAP is a special virtual address section for Xen to map some physical ram or device memory temporarily in initialization for MMU systems. FIXMAP_ADDR will return a virtual address by index for special purpose phys-to-virt mapping usage. For example, FIXMAP_ADDR(FIXMAP_CONSOLE) for early console

[PATCH v6 04/11] xen/arm: adjust Xen TLB helpers for Armv8-R64 PMSA

>From Arm ARM Supplement of Armv8-R AArch64 (DDI 0600A) [1], section D1.6.2 TLB maintenance instructions. We know that Armv8-R AArch64 permits an implementation to cache stage 1 VMSAv8-64 and stage 2 PMSAv8-64 attributes as a common entry for the Secure EL1&0 translation regime. But for Xen

[PATCH v6 05/11] xen/arm: define Xen start address for FVP BaseR platform

On Armv8-A, Xen has a fixed virtual start address (link address too) for all Armv8-A platforms. In an MMU based system, Xen can map its loaded address to this virtual start address. So, on Armv8-A platforms, the Xen start address does not need to be configurable. But on Armv8-R platforms, there is

[PATCH v6 01/11] xen/arm: remove xen_phys_start and xenheap_phys_end from config.h

These two variables are stale variables, they only have declarations in config.h, they don't have any definition and no any code is using these two variables. So in this patch, we remove them from config.h. Signed-off-by: Wei Chen --- xen/arch/arm/include/asm/config.h | 2 -- 1 file changed, 2

[PATCH v6 03/11] xen/arm: disable EFI boot services for MPU systems

Current EFI boot services support of Arm64 could not work well for Armv8-R64 system that only has MPU in EL2. That is because EFI boot services may need some relocation support or partial PIE/PIC support. But these will not be supported in the initial stage of porting Xen to MPU systems. So in

[PATCH v6 00/11] xen/arm: Add Armv8-R64 MPU support to Xen - Part#1

The Armv-R architecture profile was designed to support use cases that have a high sensitivity to deterministic execution. (e.g. Fuel Injection, Brake control, Drive trains, Motor control etc) Arm announced Armv8-R in 2013, it is the latest generation Arm architecture targeted at the Real-time

[PATCH v6 02/11] xen/arm: add iounmap after initrd has been loaded in domain_build

domain_build use ioremap_wc to map a new non-cacheable virtual address for initrd. After Xen copy initrd from this address to guest, this new allocated virtual address has not been unmapped. So in this patch, we add an iounmap to the end of domain_build, after Xen loaded initrd to guest memory.

Re: [XEN v2 09/12] xen/Arm: GICv3: Define GIC registers for AArch32

On 04/11/2022 09:27, Michal Orzel wrote: Hi Ayan, Hi Michal, On 03/11/2022 21:14, Ayan Kumar Halder wrote: On 03/11/2022 15:08, Michal Orzel wrote: Hi Ayan, Hi Michal, On 31/10/2022 16:13, Ayan Kumar Halder wrote: The title is a bit ambiguous given that the previous patches were also

Re: [XEN v2 12/12] xen/Arm: GICv3: Enable GICv3 for AArch32

Hi Ayan, On 31/10/2022 16:13, Ayan Kumar Halder wrote: > > > Refer ARM DDI 0487G.b ID072021, > D13.2.86 - > ID_PFR1_EL1, AArch32 Processor Feature Register 1 > > GIC, bits[31:28] == 0b0001 for GIC3.0 on Aarch32 > > One can now enable GICv3 on AArch32 systems. However, ITS is not supported. >

Re: [[PATCH for-4.17 v1]] tools/ocaml/xenstored/store.ml: fix build error

On 3 Nov 2022, at 18:42, Edwin Török mailto:edvin.to...@citrix.com>> wrote: Fixes: db471408edd46 "tools/ocaml/xenstored: Fix quota bypass on domain shutdown" Signed-off-by: Edwin Török mailto:edvin.to...@citrix.com>> --- tools/ocaml/xenstored/store.ml | 2 +- 1 file changed, 1 insertion(+),

Re: [XEN v2 09/12] xen/Arm: GICv3: Define GIC registers for AArch32

Hi Ayan, On 03/11/2022 21:14, Ayan Kumar Halder wrote: > > On 03/11/2022 15:08, Michal Orzel wrote: >> Hi Ayan, > Hi Michal, >> >> On 31/10/2022 16:13, Ayan Kumar Halder wrote: >> The title is a bit ambiguous given that the previous patches were also >> defining GIC registers. >> Maybe adding

Re: [PATCH for-4.17 v3 1/2] amd/virt_ssbd: set SSBD at vCPU context switch

On 03.11.2022 18:02, Roger Pau Monne wrote: > The current logic for AMD SSBD context switches it on every > vm{entry,exit} if the Xen and guest selections don't match. This is > expensive when not using SPEC_CTRL, and hence should be avoided as > much as possible. > > When SSBD is not being set

Re: [PATCH] xen/sched: try harder to find a runnable unit in rt_schedule()

On Fri, 2022-10-21 at 12:39 +0200, Juergen Gross wrote: > Instead of directly falling back to the idle unit in case the top > unit from the run queue happened to be not runnable, consult the run > queue again. > > Suggested-by: Dario Faggioli > Signed-off-by: Juergen Gross > Reviewed-by: Dario

Re: [PATCH] xen/notifier: simplify using notifier_[to|from]_errno()

On Fri, 2022-10-28 at 13:41 +0200, Juergen Gross wrote: > Today all users of notifier_from_errno() and notifier_to_errno() are > Handling the success case the same way, by using > >   !rc ? NOTIFY_DONE : notifier_from_errno(rc) > > or > >   (notifier_rc == NOTIFY_DONE) ? 0 :

RE: [PATCH-for-4.17 v3] xen/sched: migrate timers to correct cpus after suspend

Hi Juergen, > On Wed, 2022-11-02 at 16:00 +0100, Juergen Gross wrote: > > Today all timers are migrated to cpu 0 when the system is being > > suspended. They are not migrated back after resuming the system > > again. > > > > This results (at least) to visible problems with the credit > >

Re: [PATCH-for-4.17 v3] xen/sched: migrate timers to correct cpus after suspend

On Wed, 2022-11-02 at 16:00 +0100, Juergen Gross wrote: > Today all timers are migrated to cpu 0 when the system is being > suspended. They are not migrated back after resuming the system > again. > > This results (at least) to visible problems with the credit > scheduler, > as the timer isn't

Re: Need updates on some release blockers

On 04.11.2022 04:06, Henry Wang wrote: > 4. Patch: x86 :Enable interrupts around dump_execstate() [5] > - I think your opinion is needed so that the discussion can continue whether > this > patch can process or the previous patch needs to be reverted. On the last x86 maintainer meeting the

Re: Revert of the 4.17 hypercall handler changes Re: [PATCH-for-4.17] xen: fix generated code for calling hypercall handlers

On 04.11.2022 06:01, Andrew Cooper wrote: > On 03/11/2022 16:36, Juergen Gross wrote: >> The code generated for the call_handlers_*() macros needs to avoid >> undefined behavior when multiple handlers share the same priority. >> The issue is the hypercall number being unverified fed into the

[qemu-mainline test] 174609: tolerable FAIL - PUSHED

flight 174609 qemu-mainline real [real] flight 174619 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/174609/ http://logs.test-lab.xenproject.org/osstest/logs/174619/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking):

[PATCH v2 5/5] x86: switch to cpu_feature_enabled() for X86_FEATURE_XENPV

Convert the remaining cases of static_cpu_has(X86_FEATURE_XENPV) and boot_cpu_has(X86_FEATURE_XENPV) to use cpu_feature_enabled(), allowing more efficient code in case the kernel is configured without CONFIG_XEN_PV. Signed-off-by: Juergen Gross --- arch/x86/kernel/cpu/amd.c| 2 +-

[PATCH v2 3/5] x86: drop 32-bit Xen PV guest code in update_task_stack()

Testing for Xen PV guest mode in a 32-bit only code section can be dropped, as Xen PV guests are supported in 64-bit mode only. While at it switch from boot_cpu_has() to cpu_feature_enabled() in the 64-bit part of the code. Signed-off-by: Juergen Gross --- arch/x86/include/asm/switch_to.h | 7

[PATCH v2 4/5] x86: remove X86_FEATURE_XENPV usage in setup_cpu_entry_area()

Testing of X86_FEATURE_XENPV in setup_cpu_entry_area() can be removed, as this code path is 32-bit only, and Xen PV guests are not supporting 32-bit mode. Signed-off-by: Juergen Gross --- V2: - new patch --- arch/x86/mm/cpu_entry_area.c | 8 ++-- 1 file changed, 2 insertions(+), 6

[PATCH v2 2/5] x86: remove unneeded 64-bit dependency in arch_enter_from_user_mode()

The check for 64-bit mode when testing X86_FEATURE_XENPV isn't needed, as Xen PV guests are no longer supported in 32-bit mode. While at it switch from boot_cpu_has() to cpu_feature_enabled(). Signed-off-by: Juergen Gross --- arch/x86/include/asm/entry-common.h | 4 ++-- 1 file changed, 2

[PATCH v2 1/5] x86: add X86_FEATURE_XENPV to disabled-features.h

Add X86_FEATURE_XENPV to the features handled specially in disabled-features.h. Signed-off-by: Juergen Gross --- arch/x86/include/asm/disabled-features.h | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/disabled-features.h

[PATCH v2 0/5] x86: Switch X86_FEATURE_XENPV to cpu_feature_enabled() use

Make especially kernels without CONFIG_XEN_PV more efficient by using cpu_feature_enabled(X86_FEATURE_XENPV) instead of boot_cpu_has() and friends. Changes in V2: - new patch 4 Juergen Gross (5): x86: add X86_FEATURE_XENPV to disabled-features.h x86: remove unneeded 64-bit dependency in

Re: [PATCH v14 16/17] tests/qtest: netdev: test stream and dgram backends

在 2022/11/3 17:33, Laurent Vivier 写道: On 10/28/22 07:04, Jason Wang wrote: 在 2022/10/21 17:09, Laurent Vivier 写道: Signed-off-by: Laurent Vivier Acked-by: Michael S. Tsirkin --- I got this: 63/63 ERROR:../tests/qtest/netdev-socket.c:139:test_stream_inet_ipv6: assertion failed (resp ==

[ovmf test] 174613: all pass - PUSHED

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

[linux-5.4 test] 174608: regressions - FAIL

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