[KERNEL PATCH v10 1/3] xen/pci: Add a function to reset device for xen

When device on dom0 side has been reset, the vpci on Xen side won't get notification, so that the cached state in vpci is all out of date with the real device state. To solve that problem, add a new function to clear all vpci device state when device is reset on dom0 side. And call that function i

[KERNEL PATCH v10 2/3] xen/pvh: Setup gsi for passthrough device

In PVH dom0, the gsis don't get registered, but the gsi of a passthrough device must be configured for it to be able to be mapped into a domU. When assigning a device to passthrough, proactively setup the gsi of the device during that process. Signed-off-by: Jiqian Chen Signed-off-by: Huang Rui

[KERNEL PATCH v10 3/3] xen/privcmd: Add new syscall to get gsi from dev

On PVH dom0, when passthrough a device to domU, QEMU and xl tools want to use gsi number to do pirq mapping, see QEMU code xen_pt_realize->xc_physdev_map_pirq, and xl code pci_add_dm_done->xc_physdev_map_pirq, but in current codes, the gsi number is got from file /sys/bus/pci/devices//irq, that is

[KERNEL PATCH v10 0/3] Support device passthrough when dom0 is PVH on Xen

Hi All, This is v10 series to support passthrough on Xen when dom0 is PVH. v9->v10 changes: * patch#1: Added Reviewed-by of Stefano. * patch#2: Added Reviewed-by of Stefano. * patch#3: Changed the macro wrapping "pcistub_get_gsi_from_sbdf" from "CONFIG_XEN_PCIDEV_BACKEND" to "CONFIG_XEN_ACPI".

Re: [KERNEL PATCH v9 3/3] xen/privcmd: Add new syscall to get gsi from dev

On 2024/9/23 16:04, Juergen Gross wrote: > On 23.09.24 09:58, Juergen Gross wrote: >> On 23.09.24 07:49, Chen, Jiqian wrote: >>> On 2024/9/21 05:17, Stefano Stabellini wrote: On Fri, 20 Sep 2024, Chen, Jiqian wrote: > On 2024/9/19 06:49, Stefano Stabellini wrote: >> On Thu, 12 Sep 2024

[linux-linus test] 187830: tolerable FAIL - PUSHED

flight 187830 linux-linus real [real] flight 187836 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/187830/ http://logs.test-lab.xenproject.org/osstest/logs/187836/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-

[ovmf test] 187833: all pass - PUSHED

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

[qemu-mainline test] 187825: regressions - FAIL

flight 187825 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/187825/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 20 debian-hvm-install/l1/l2 fail REGR. vs. 187720 Tests whi

[ovmf test] 187829: all pass - PUSHED

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

Re: [PATCH v3] x86/efi: Use generic PE/COFF structures

On 23/09/2024 6:50 pm, Milan Djokic wrote: > From: Nikola Jelic > > Adapted x86 efi parser and mkreloc utility to use generic PE header > (efi/pe.h), instead of locally defined structures for each component. > > Signed-off-by: Nikola Jelic > Signed-off-by: Milan Djokic Acked-by: Andrew Cooper

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

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

[PATCH v3] x86/efi: Use generic PE/COFF structures

From: Nikola Jelic Adapted x86 efi parser and mkreloc utility to use generic PE header (efi/pe.h), instead of locally defined structures for each component. Signed-off-by: Nikola Jelic Signed-off-by: Milan Djokic --- Changes in V3: - Add xen/include among include dirs for mkreloc, instead of

Re: [PATCH 07/10] xen/arm: ffa: Transmit RXTX buffers to the SPMC

Hi, On Thu, Sep 19, 2024 at 2:20 PM Bertrand Marquis wrote: > > When an RXTX buffer is mapped by a VM transmit it to the SPMC when it > supports RX_ACQUIRE. > As a consequence of that, we must acquire the RX buffer of a VM from the > SPMC when we want to use it: > - create a generic acquire and r

[PATCH] x86/cpufeature: Reposition cpu_has_{lfence_dispatch,nscb}

LFENCE_DISPATCH used to be a synthetic feature, but was given a real CPUID bit by AMD. The define wasn't moved when this was changed. NSCB has always been a real CPUID bit, and was misplaced when introduced in the synthetic block alongside LFENCE_DISPATCH. Signed-off-by: Andrew Cooper --- CC: J

Re: [PATCH v3] docs: fusa: Add Assumption of Use (AoU)

On 19/09/2024 13:01, Bertrand Marquis wrote: Hi Ayan, Hi Bertrand, On 16 Sep 2024, at 14:18, Ayan Kumar Halder wrote: From: Michal Orzel AoU are the assumptions that Xen relies on other components (eg platform platform, domains) to fulfill its requirements. In our case, platform means a

Re: [PATCH] tools/libxs: Style consistency improvements

On 23.09.24 17:54, Andrew Cooper wrote: This is mostly Linux sytle. Make the file self-consistent. Drop trailing Nit: s/sytle/style/ whitespace, and use tabs consistently. No functional change. Signed-off-by: Andrew Cooper Reviewed-by: Juergen Gross Juergen OpenPGP_0xB0DE9DD628BF

Re: [PATCH v4 3/3] x86: Align output sections for UEFI CA memory mitigation requirements

On Mon, Sep 23, 2024 at 4:54 PM Jan Beulich wrote: > > On 19.09.2024 10:00, Frediano Ziglio wrote: > > All loadable sections should be page aligned. > > What about .buildid? .reloc otoh is discardable, and hence presumably okay > if mis-aligned. > > Jan Currently, internally we have a patch to ma

Re: [PATCH 2/3] xen/livepatch: do Xen build-id check earlier

On Mon, Sep 23, 2024 at 12:04:30PM +0100, Andrew Cooper wrote: > On 20/09/2024 10:36 am, Roger Pau Monne wrote: > > The check against the expected Xen build ID should be done ahead of > > attempting > > to apply the alternatives contained in the livepatch. > > > > If the CPUID in the alternatives

Re: [PATCH] x86: enable long section names for xen.efi

On Mon, Sep 23, 2024 at 4:39 PM Jan Beulich wrote: > > While for our present .data.read_mostly it may be deemed tolerable that > the name is truncated to .data.re, for the planned .init.trampoline an > abbreviation to .init.tr would end up pretty meaningless. Engage the > long section names extens

Re: [PATCH] hw/xen: Remove deadcode

On Tue, Sep 17, 2024 at 09:03:09AM +, Anthony PERARD wrote: > On Tue, Sep 17, 2024 at 01:22:12AM +0100, d...@treblig.org wrote: > > From: "Dr. David Alan Gilbert" > > > > xen_be_copy_grant_refs is unused since 2019's > > 19f87870ba ("xen: remove the legacy 'xen_disk' backend") > > > > xen_

[PATCH] tools/libxs: Style consistency improvements

This is mostly Linux sytle. Make the file self-consistent. Drop trailing whitespace, and use tabs consistently. No functional change. Signed-off-by: Andrew Cooper --- CC: Anthony PERARD CC: Juergen Gross >From the SIGPIPE work, but not submitted at the time. --- tools/libs/store/xs.c | 74

Re: [PATCH v4 3/3] x86: Align output sections for UEFI CA memory mitigation requirements

On 19.09.2024 10:00, Frediano Ziglio wrote: > All loadable sections should be page aligned. What about .buildid? .reloc otoh is discardable, and hence presumably okay if mis-aligned. Jan

Re: [PATCH] x86: enable long section names for xen.efi

On 23/09/2024 4:39 pm, Jan Beulich wrote: > While for our present .data.read_mostly it may be deemed tolerable that > the name is truncated to .data.re, for the planned .init.trampoline an > abbreviation to .init.tr would end up pretty meaningless. Engage the > long section names extension that GNU

Re: [PATCH v4 2/3] x86: Split output sections for UEFI CA memory mitigation requirements

On 19.09.2024 10:00, Frediano Ziglio wrote: > Split code and data to satisfy W^X requirement. > > Signed-off-by: Frediano Ziglio Acked-by: Jan Beulich as long as it goes on top of the long section names enabling patch. Jan

[linux-linus test] 187822: tolerable FAIL - PUSHED

flight 187822 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/187822/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 187816 test-amd64-amd64-xl-qemuu-win7-amd64

Re: [PATCH v4 1/3] x86: Put trampoline in separate .init.trampoline section

On 23.09.2024 17:31, Frediano Ziglio wrote: > On Mon, Sep 23, 2024 at 4:17 PM Jan Beulich wrote: >> >> On 19.09.2024 10:00, Frediano Ziglio wrote: >>> This change put the trampoline in a separate, not executable section. >>> The trampoline contains a mix of code and data (data which >>> is modifie

[PATCH] x86: enable long section names for xen.efi

While for our present .data.read_mostly it may be deemed tolerable that the name is truncated to .data.re, for the planned .init.trampoline an abbreviation to .init.tr would end up pretty meaningless. Engage the long section names extension that GNU ld has had support for already in 2.22 (which we

Re: [PATCH v4 1/3] x86: Put trampoline in separate .init.trampoline section

On Mon, Sep 23, 2024 at 4:17 PM Jan Beulich wrote: > > On 19.09.2024 10:00, Frediano Ziglio wrote: > > This change put the trampoline in a separate, not executable section. > > The trampoline contains a mix of code and data (data which > > is modified from C code during early start so must be writ

Re: [PATCH v4 1/3] x86: Put trampoline in separate .init.trampoline section

On 19.09.2024 10:00, Frediano Ziglio wrote: > This change put the trampoline in a separate, not executable section. > The trampoline contains a mix of code and data (data which > is modified from C code during early start so must be writable). > This is in preparation for W^X patch in order to sati

Re: [XEN PATCH v5] x86/intel: optional build of PSR support

On 18.09.2024 11:15, Sergiy Kibrik wrote: > changes in v5: > - simplify psr_cmt_enabled() > - move PSR config option and add description What you did is not so much add a description, but ... > --- a/xen/arch/x86/Kconfig > +++ b/xen/arch/x86/Kconfig > @@ -231,6 +231,9 @@ config TBOOT > >

[PATCH v2 0/4] hw/arm: xenpvh: Enable PCI for ARM PVH

From: "Edgar E. Iglesias" Enable PCI on the ARM PVH machine. First we add a way to control the use of buffered IOREQ's since those are not supported on Xen/ARM. Finally we enable the PCI support. I've published some instructions on how to try this including the work in progress Xen side of the P

[PATCH v2 2/4] hw/xen: xenpvh: Disable buffered IOREQs for ARM

From: "Edgar E. Iglesias" Add a way to enable/disable buffered IOREQs for PVH machines and disable them for ARM. ARM does not support buffered IOREQ's nor the legacy way to map IOREQ info pages. See the following for more details: https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=2fbd7e60

[PATCH v2 3/4] hw/xen: xenpvh: Add pci-intx-irq-base property

From: "Edgar E. Iglesias" Acked-by: Stefano Stabellini Signed-off-by: Edgar E. Iglesias --- hw/xen/xen-pvh-common.c | 36 1 file changed, 36 insertions(+) diff --git a/hw/xen/xen-pvh-common.c b/hw/xen/xen-pvh-common.c index 76a9b2b945..218ac851cf 100644 --

[PATCH v2 1/4] hw/xen: Expose handle_bufioreq in xen_register_ioreq

From: "Edgar E. Iglesias" Expose handle_bufioreq in xen_register_ioreq(). This is to allow machines to enable or disable buffered ioreqs. No functional change since all callers still set it to HVM_IOREQSRV_BUFIOREQ_ATOMIC. Signed-off-by: Edgar E. Iglesias --- hw/i386/xen/xen-hvm.c |

[PATCH v2 4/4] hw/arm: xenpvh: Enable PCI for ARM PVH

From: "Edgar E. Iglesias" Enable PCI support for the ARM Xen PVH machine. Reviewed-by: Stefano Stabellini Signed-off-by: Edgar E. Iglesias --- hw/arm/xen-pvh.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/hw/arm/xen-pvh.c b/hw/arm/xen-pvh.c index 28af3910ea..33f0dd5982

Re: [PATCH v1 2/2] xen: move per-cpu area management into common code

On Sun, 2024-09-22 at 10:43 +0200, Andrew Cooper wrote: > > > diff --git a/xen/common/percpu.c b/xen/common/percpu.c > > > new file mode 100644 > > > index 00..3837ef5714 > > > --- /dev/null > > > +++ b/xen/common/percpu.c > > > @@ -0,0 +1,127 @@ > > > +/* SPDX-License-Identifier: GPL-2.0 *

Re: [XEN PATCH v2] x86/mwait-idle: add dependency on general Intel CPU support

On 18.09.2024 11:19, Sergiy Kibrik wrote: > Currently mwait_idle driver in Xen only implements support for Intel CPUs. > Thus in order to reduce dead code in non-Intel build configurations it can > be made explicitly dependant on CONFIG_INTEL option. > > Signed-off-by: Sergiy Kibrik Acked-by: Ja

Re: [PATCH v2 5/5] xen/common: move device initialization code to common code

On 17.09.2024 18:15, Oleksii Kurochko wrote: > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -12,6 +12,14 @@ config CORE_PARKING > bool > depends on NR_CPUS > 1 > > +config DEVICE_INIT > + bool > + default !X86 This can simply be "def_bool y" as ... > + depend

[PATCH] x86/APIC: Remove x2APIC pure cluster mode

With the introduction of mixed x2APIC mode (using cluster addressing for IPIs and physical for external interrupts) the use of pure cluster mode doesn't have any benefit. Remove the mode itself, leaving only the code required for logical addressing when sending IPIs. Implements: https://gitlab.co

Re: [PATCH 3/3] x86/boot: Rewrite EFI start part in C

On 16.09.2024 10:25, Frediano Ziglio wrote: > On Sun, Sep 15, 2024 at 8:00 AM Jan Beulich wrote: >> On 10.09.2024 18:16, Frediano Ziglio wrote: >>> -.Lefi_multiboot2_proto: >>> -/* Zero EFI SystemTable, EFI ImageHandle addresses and cmdline. */ >>> -xor %esi,%esi >>> -x

Re: [PATCH 3/3] x86/alternatives: relax apply BUGs during runtime

On 23/09/2024 2:06 pm, Roger Pau Monné wrote: > On Mon, Sep 23, 2024 at 12:17:51PM +0100, Andrew Cooper wrote: >> On 20/09/2024 10:36 am, Roger Pau Monne wrote: >>> alternatives is used both at boot time, and when loading livepatch payloads. >>> While for the former it makes sense to panic, it's no

Re: [PATCH 1/3] xen/livepatch: simplify and unify logic in prepare_payload()

On Mon, Sep 23, 2024 at 01:01:57PM +0200, Jan Beulich wrote: > On 20.09.2024 11:36, Roger Pau Monne wrote: > > The following sections: .note.gnu.build-id, .livepatch.xen_depends and > > .livepatch.depends are mandatory and ensured to be present by > > check_special_sections() before prepare_payload

Re: [PATCH 3/3] x86/alternatives: relax apply BUGs during runtime

On Mon, Sep 23, 2024 at 12:17:51PM +0100, Andrew Cooper wrote: > On 20/09/2024 10:36 am, Roger Pau Monne wrote: > > alternatives is used both at boot time, and when loading livepatch payloads. > > While for the former it makes sense to panic, it's not useful for the > > later, as > > for livepatch

Re: [PATCH v2] x86/traps: Re-enable interrupts after reading cr2 in the #PF handler

On 23.09.2024 12:14, Alejandro Vallejo wrote: > On Fri Sep 20, 2024 at 3:12 PM BST, Roger Pau Monné wrote: >> On Wed, Sep 18, 2024 at 02:05:54PM +0100, Alejandro Vallejo wrote: >>> Moves sti directly after the cr2 read and immediately after the #PF >>> handler. >> >> I think you need to add some co

Re: [PATCH 04/10] xen/arm: ffa: Fine granular call support

Hi, On Sun, Sep 22, 2024 at 3:04 PM Julien Grall wrote: > > Hi Bertrand, > > On 19/09/2024 14:19, Bertrand Marquis wrote: > > Create a bitmap to store which feature is supported or not by the > > firmware and use it to filter which calls done to the firmware. > > > > With this enabled. allow FF-A

Re: [PATCH] x86/boot: Drop stale comment about zeroing the stack

On Mon, Sep 23, 2024 at 12:32 PM Jan Beulich wrote: > ... > > > > Acked-by: Frediano Ziglio > > Frediano, just FYI on the formal aspects here (which we don't always follow to > the letter, but still): If you had offered Reviewed-by:, Andrew would have > been > fine to commit with just that. You

Re: [PATCH v1 1/2] xen: introduce common macros for per-CPU sections defintion

On 23.09.2024 13:53, Andrew Cooper wrote: > On 23/09/2024 12:48 pm, oleksii.kuroc...@gmail.com wrote: >> On Mon, 2024-09-23 at 12:56 +0200, Jan Beulich wrote: >>> On 19.09.2024 17:59, Oleksii Kurochko wrote: --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -321,14 +321,7

Re: [PATCH 2/3] xen/livepatch: do Xen build-id check earlier

On 23/09/2024 12:04 pm, Andrew Cooper wrote: > On 20/09/2024 10:36 am, Roger Pau Monne wrote: >> The check against the expected Xen build ID should be done ahead of >> attempting >> to apply the alternatives contained in the livepatch. >> >> If the CPUID in the alternatives patching data is out of

Re: [PATCH] x86/shutdown: mask LVTERR ahead of offlining CPUs

On 20.09.2024 10:35, Roger Pau Monné wrote: > On Thu, Sep 19, 2024 at 10:19:49PM +0200, Andrew Cooper wrote: >> On 19/09/2024 4:27 pm, Roger Pau Monne wrote: >>> @@ -364,6 +369,18 @@ void smp_send_stop(void) >>> fixup_irqs(cpumask_of(cpu), 0); >>> local_irq_enable(); >>> >>> +

Re: [PATCH v1 1/2] xen: introduce common macros for per-CPU sections defintion

On 23/09/2024 12:48 pm, oleksii.kuroc...@gmail.com wrote: > On Mon, 2024-09-23 at 12:56 +0200, Jan Beulich wrote: >> On 19.09.2024 17:59, Oleksii Kurochko wrote: >>> --- a/xen/arch/x86/xen.lds.S >>> +++ b/xen/arch/x86/xen.lds.S >>> @@ -321,14 +321,7 @@ SECTIONS >>>    DECL_SECTION(.bss) { >>>  

Re: [PATCH v1 1/2] xen: introduce common macros for per-CPU sections defintion

On Mon, 2024-09-23 at 12:56 +0200, Jan Beulich wrote: > On 19.09.2024 17:59, Oleksii Kurochko wrote: > > --- a/xen/arch/x86/xen.lds.S > > +++ b/xen/arch/x86/xen.lds.S > > @@ -321,14 +321,7 @@ SECTIONS > >    DECL_SECTION(.bss) { > >     __bss_start = .; > >     *(.bss.page_aligned*) > > -  

Re: [PATCH] x86/boot: Drop stale comment about zeroing the stack

On 16.09.2024 15:16, Frediano Ziglio wrote: > On Mon, Sep 16, 2024 at 12:58 PM Andrew Cooper > wrote: >> >> This used to be true, but was altered by commit 37786b23b027 ("x86/cet: >> Remove >> writeable mapping of the BSPs shadow stack") which moved cpu0_stack into >> .init.bss.stack_aligned. >>

Re: [PATCH v2 2/4] xen/arm: mpu: Define Xen start address for MPU systems

On 19/09/2024 13:42, Julien Grall wrote: Hi Ayan, Hi Julien, On 18/09/2024 19:51, Ayan Kumar Halder wrote: From: Wei Chen 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 virtua

Re: [PATCH 3/3] x86/alternatives: relax apply BUGs during runtime

On 20/09/2024 10:36 am, Roger Pau Monne wrote: > alternatives is used both at boot time, and when loading livepatch payloads. > While for the former it makes sense to panic, it's not useful for the later, > as > for livepatches it's possible to fail to load the livepatch if alternatives > cannot b

Re: [PATCH v2] x86/efi: Use generic PE/COFF structures

> > Not strong about, a change like > > $ git diff > diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile > index 286c003ec3..00ab091634 100644 > --- a/xen/arch/x86/Makefile > +++ b/xen/arch/x86/Makefile > @@ -88,6 +88,8 @@ extra-y += xen.lds > hostprogs-y += boot/mkelf32 > hostprogs-y += efi

Re: [PATCH 3/3] x86/alternatives: relax apply BUGs during runtime

On 20.09.2024 11:36, Roger Pau Monne wrote: > @@ -198,9 +201,17 @@ static void init_or_livepatch _apply_alternatives(struct > alt_instr *start, > uint8_t buf[MAX_PATCH_LEN]; > unsigned int total_len = a->orig_len + a->pad_len; > > -BUG_ON(a->repl_len > total_len); > -

[xen-unstable test] 187818: trouble: broken/fail/pass

flight 187818 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/187818/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-raw broken Tests which are fail

Re: [PATCH 1/4] dt-overlay: Fix NULL pointer dereference

Hi Julien, On 20/09/2024 10:29, Julien Grall wrote: > > > Hi Michal, > > On 19/09/2024 12:42, Michal Orzel wrote: >> Attempt to attach an overlay (xl dt-overlay attach) to a domain without >> first adding this overlay to Xen (xl dt-overlay add) results in an >> overlay track entry being NULL in

Re: [PATCH 2/3] xen/livepatch: do Xen build-id check earlier

On 20/09/2024 10:36 am, Roger Pau Monne wrote: > The check against the expected Xen build ID should be done ahead of attempting > to apply the alternatives contained in the livepatch. > > If the CPUID in the alternatives patching data is out of the scope of the > running Xen featureset the BUG() in

Re: [PATCH 2/3] xen/livepatch: do Xen build-id check earlier

On 20.09.2024 11:36, Roger Pau Monne wrote: > The check against the expected Xen build ID should be done ahead of attempting > to apply the alternatives contained in the livepatch. > > If the CPUID in the alternatives patching data is out of the scope of the > running Xen featureset the BUG() in _

Re: [PATCH 1/3] xen/livepatch: simplify and unify logic in prepare_payload()

On 20.09.2024 11:36, Roger Pau Monne wrote: > The following sections: .note.gnu.build-id, .livepatch.xen_depends and > .livepatch.depends are mandatory and ensured to be present by > check_special_sections() before prepare_payload() is called. > > Simplify the logic in prepare_payload() by introdu

Re: [PATCH 1/3] xen/livepatch: simplify and unify logic in prepare_payload()

On 23.09.2024 11:43, Andrew Cooper wrote: > On 23/09/2024 8:46 am, Roger Pau Monné wrote: >> On Sun, Sep 22, 2024 at 11:19:01AM +0200, Andrew Cooper wrote: >>> On 20/09/2024 11:36 am, Roger Pau Monne wrote: +{ +const Elf_Note *n = sec->load_addr; +int rc; + +ASS

Re: [PATCH v1 1/2] xen: introduce common macros for per-CPU sections defintion

On 19.09.2024 17:59, Oleksii Kurochko wrote: > --- a/xen/arch/x86/xen.lds.S > +++ b/xen/arch/x86/xen.lds.S > @@ -321,14 +321,7 @@ SECTIONS >DECL_SECTION(.bss) { > __bss_start = .; > *(.bss.page_aligned*) > - . = ALIGN(PAGE_SIZE); > - __per_cpu_start = .; > - *(

Re: [PATCH 4/4] dt-overlay: Support target-path being root node

On 20/09/2024 05:54, Stefano Stabellini wrote: > > > On Thu, 19 Sep 2024, Michal Orzel wrote: >> Even though in most cases device nodes are not present directly under >> the root node, it's a perfectly valid configuration (e.g. Qemu virt >> machine dtb). At the moment, we don't handle this sce

Re: [PATCH 3/4] dt-overlay: Remove ASSERT_UNREACHABLE from add_nodes()

Hi Julien, On 20/09/2024 10:35, Julien Grall wrote: > > > Hi Michal, > > On 19/09/2024 12:42, Michal Orzel wrote: >> The assumption stated in the comment that the code will never get there >> is incorrect. It's enough for the target-path to be incorrect (i.e. user >> error), which will lead to

Re: [PATCH] ioreq: don't wrongly claim "success" in ioreq_send_buffered()

On 23.09.2024 11:55, Nicola Vetrini wrote: > On 2024-09-23 11:47, Jan Beulich wrote: >> On 16.09.2024 23:27, Julien Grall wrote: >>> On 11/09/2024 13:19, Jan Beulich wrote: Returning a literal number is a bad idea anyway when all other returns use IOREQ_STATUS_* values. While that's

Re: [PATCH v2 1/5] xen: define ACPI and DT device info sections macros

On Mon, 2024-09-23 at 12:08 +0200, Jan Beulich wrote: > On 17.09.2024 18:15, Oleksii Kurochko wrote: > > --- a/xen/include/xen/xen.lds.h > > +++ b/xen/include/xen/xen.lds.h > > @@ -114,6 +114,21 @@ > >   > >  /* List of constructs other than *_SECTIONS in alphabetical order. > > */ > >   > > +#defi

Re: [PATCH v2] x86/efi: Use generic PE/COFF structures

On Mon, Sep 23, 2024 at 9:56 AM Milan Đokić wrote: > > Hello Frediano, > Thank you for your feedback > > > > On Thu, Sep 19, 2024 at 11:42 AM Milan Đokić > > wrote: > > > > > > Hello everyone, > > > > > > Any comments on v2 patch? > > > Just checking if you missed this email or didn't have time

Re: Xen 4.20 release schedule proposal

On Thu, 2024-09-19 at 21:30 +0200, Julien Grall wrote: > > > On 19/09/2024 18:10, Oleksii Kurochko wrote: > > Hello everyone, > > > > Following the 8-month release cycle, also taking into account that > > 4.19 > > has been released 27.07.24 and the next "good" month for release > > should > > be

Re: [PATCH v2 4/4] xen/arm: mpu: Implement a dummy enable_secondary_cpu_mm

On 18.09.2024 19:51, Ayan Kumar Halder wrote: > Secondary cpus initialization is not yet supported. Thus, we print an > appropriate message and put the secondary cpus in WFE state. > > Signed-off-by: Ayan Kumar Halder > --- > Changes from :- > > v1 - 1. NR_CPUS is defined as 1 for MPU Not quite

Re: [PATCH v2 1/4] xen/arm: mpu: Introduce choice between MMU and MPU

On 18.09.2024 19:50, Ayan Kumar Halder wrote: > --- a/xen/arch/arm/Kconfig > +++ b/xen/arch/arm/Kconfig > @@ -58,10 +58,24 @@ config PADDR_BITS > default 40 if ARM_PA_BITS_40 > default 48 if ARM_64 > > +choice > + prompt "Memory management system" > + default MMU if ARM Why t

Re: [PATCH v2] x86/traps: Re-enable interrupts after reading cr2 in the #PF handler

On Fri Sep 20, 2024 at 3:12 PM BST, Roger Pau Monné wrote: > On Wed, Sep 18, 2024 at 02:05:54PM +0100, Alejandro Vallejo wrote: > > Moves sti directly after the cr2 read and immediately after the #PF > > handler. > > I think you need to add some context about why this is needed, iow: > avoid corrup

Re: [PATCH v2 1/5] xen: define ACPI and DT device info sections macros

On 17.09.2024 18:15, Oleksii Kurochko wrote: > --- a/xen/include/xen/xen.lds.h > +++ b/xen/include/xen/xen.lds.h > @@ -114,6 +114,21 @@ > > /* List of constructs other than *_SECTIONS in alphabetical order. */ > > +#define USE_DECL_SECTION(x) DECL_SECTION(x) > + > +#define NOUSE_DECL_SECTION(x

Re: [PATCH v2] docs/misra: add R17.2 and R18.2

On 23/09/2024 11:03 am, Jan Beulich wrote: > On 18.09.2024 22:23, Stefano Stabellini wrote: >> --- a/docs/misra/rules.rst >> +++ b/docs/misra/rules.rst >> @@ -561,6 +561,13 @@ maintainers if you want to suggest a change. >> - The features of shall not be used >> - >> >> + * - `Rule

Re: [PATCH v1 2/2] xen: move per-cpu area management into common code

On 23/09/2024 10:26 am, oleksii.kuroc...@gmail.com wrote: > On Sun, 2024-09-22 at 10:43 +0200, Andrew Cooper wrote: >> On 22/09/2024 10:23 am, Julien Grall wrote: >>> On 19/09/2024 17:59, Oleksii Kurochko wrote: diff --git a/xen/arch/x86/percpu.c b/xen/arch/x86/percpu.c index 3205eacea6..

Re: [PATCH v2 1/5] xen: define ACPI and DT device info sections macros

On 19.09.2024 23:05, Shawn Anastasio wrote: > On 9/17/24 11:15 AM, Oleksii Kurochko wrote: >> --- a/xen/include/xen/xen.lds.h >> +++ b/xen/include/xen/xen.lds.h >> @@ -114,6 +114,21 @@ >> >> /* List of constructs other than *_SECTIONS in alphabetical order. */ >> >> +#define USE_DECL_SECTION(x

Re: [PATCH v2] docs/misra: add R17.2 and R18.2

On 18.09.2024 22:23, Stefano Stabellini wrote: > --- a/docs/misra/rules.rst > +++ b/docs/misra/rules.rst > @@ -561,6 +561,13 @@ maintainers if you want to suggest a change. > - The features of shall not be used > - > > + * - `Rule 17.2 >

Re: [XEN PATCH] x86/hvm: make ACPI PM timer support optional

On 18.09.2024 15:35, Sergiy Kibrik wrote: > 18.09.24 12:41, Roger Pau Monné: >> On Wed, Sep 18, 2024 at 12:29:39PM +0300, Sergiy Kibrik wrote: >>> 16.09.24 22:57, Stefano Stabellini: On Mon, 16 Sep 2024, Roger Pau Monné wrote: > On Mon, Sep 16, 2024 at 09:37:57AM +0300, Sergiy Kibrik wrote

Re: [PATCH] ioreq: don't wrongly claim "success" in ioreq_send_buffered()

On 2024-09-23 11:47, Jan Beulich wrote: On 16.09.2024 23:27, Julien Grall wrote: On 11/09/2024 13:19, Jan Beulich wrote: Returning a literal number is a bad idea anyway when all other returns use IOREQ_STATUS_* values. While that's maybe intended on Arm (mapping to IO_ABORT), Arm doesn't su

Re: [PATCH v1 2/2] xen: move per-cpu area management into common code

Hi Julien, On Sun, 2024-09-22 at 10:23 +0200, Julien Grall wrote: > > +} >  > +#endif> + > > +#ifndef ARCH_CPU_PERCPU_CALLBACK > > +inline int arch_cpu_percpu_callback(struct notifier_block *nfb, > > +    unsigned long action, void > > *hcpu) > > I am not entirely

Re: [PATCH] ioreq: don't wrongly claim "success" in ioreq_send_buffered()

On 16.09.2024 23:27, Julien Grall wrote: > On 11/09/2024 13:19, Jan Beulich wrote: >> Returning a literal number is a bad idea anyway when all other returns >> use IOREQ_STATUS_* values. While that's maybe intended on Arm (mapping >> to IO_ABORT), > > Arm doesn't support buffered ioreq (see ioreq

Re: [PATCH 1/3] xen/livepatch: simplify and unify logic in prepare_payload()

On 23/09/2024 8:46 am, Roger Pau Monné wrote: > On Sun, Sep 22, 2024 at 11:19:01AM +0200, Andrew Cooper wrote: >> On 20/09/2024 11:36 am, Roger Pau Monne wrote: >>> +{ >>> +const Elf_Note *n = sec->load_addr; >>> +int rc; >>> + >>> +ASSERT(sec); >> This needs to turn back into a runtime

Re: [PATCH v1 2/2] xen: move per-cpu area management into common code

On Sun, 2024-09-22 at 10:43 +0200, Andrew Cooper wrote: > On 22/09/2024 10:23 am, Julien Grall wrote: > > On 19/09/2024 17:59, Oleksii Kurochko wrote: > > > diff --git a/xen/arch/x86/percpu.c b/xen/arch/x86/percpu.c > > > index 3205eacea6..33bded8cac 100644 > > > --- a/xen/arch/x86/percpu.c > > > +

Re: [PATCH v2 1/4] xen/arm: mpu: Introduce choice between MMU and MPU

On 19/09/2024 13:33, Julien Grall wrote: Hi Ayan, Hi Julien, On 18/09/2024 19:50, Ayan Kumar Halder wrote: There are features in the forthcoming patches which are dependent on MPU. For eg fixed start address. Also, some of the Xen features (eg STATIC_MEMORY) will be selected by the MPU conf

Re: [PATCH v1 3/3] xen/common: move device initialization code to common code

On 23.09.2024 10:51, oleksii.kuroc...@gmail.com wrote: > On Mon, 2024-09-23 at 09:20 +0200, Jan Beulich wrote: >> On 16.09.2024 17:51, oleksii.kuroc...@gmail.com wrote: >>> On Fri, 2024-09-13 at 19:45 +0200, Jan Beulich wrote: On 13.09.2024 16:35, oleksii.kuroc...@gmail.com wrote: > On Thu

Re: [PATCH v2] x86/efi: Use generic PE/COFF structures

Hello Frediano, Thank you for your feedback > > On Thu, Sep 19, 2024 at 11:42 AM Milan Đokić > wrote: > > > > Hello everyone, > > > > Any comments on v2 patch? > > Just checking if you missed this email or didn't have time for review. > > > > BR, > > Milan > > > > Hi, > it does look good to me.

Re: [PATCH v1 3/3] xen/common: move device initialization code to common code

On Mon, 2024-09-23 at 09:20 +0200, Jan Beulich wrote: > On 16.09.2024 17:51, oleksii.kuroc...@gmail.com wrote: > > On Fri, 2024-09-13 at 19:45 +0200, Jan Beulich wrote: > > > On 13.09.2024 16:35, oleksii.kuroc...@gmail.com wrote: > > > > On Thu, 2024-09-12 at 17:28 +0200, Jan Beulich wrote: > > > >

[ovmf test] 187824: all pass - PUSHED

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

Re: [KERNEL PATCH v9 3/3] xen/privcmd: Add new syscall to get gsi from dev

On 23.09.24 09:58, Juergen Gross wrote: On 23.09.24 07:49, Chen, Jiqian wrote: On 2024/9/21 05:17, Stefano Stabellini wrote: On Fri, 20 Sep 2024, Chen, Jiqian wrote: On 2024/9/19 06:49, Stefano Stabellini wrote: On Thu, 12 Sep 2024, Jiqian Chen wrote: On PVH dom0, when passthrough a device t

Re: [KERNEL PATCH v9 3/3] xen/privcmd: Add new syscall to get gsi from dev

On 23.09.24 07:49, Chen, Jiqian wrote: On 2024/9/21 05:17, Stefano Stabellini wrote: On Fri, 20 Sep 2024, Chen, Jiqian wrote: On 2024/9/19 06:49, Stefano Stabellini wrote: On Thu, 12 Sep 2024, Jiqian Chen wrote: On PVH dom0, when passthrough a device to domU, QEMU and xl tools want to use gsi

[qemu-mainline test] 187817: regressions - FAIL

flight 187817 qemu-mainline real [real] flight 187823 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/187817/ http://logs.test-lab.xenproject.org/osstest/logs/187823/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be

Re: [PATCH 1/3] xen/livepatch: simplify and unify logic in prepare_payload()

On Sun, Sep 22, 2024 at 11:19:01AM +0200, Andrew Cooper wrote: > On 20/09/2024 11:36 am, Roger Pau Monne wrote: > > diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c > > index d93a556bcda2..cea47ffe4c84 100644 > > --- a/xen/common/livepatch.c > > +++ b/xen/common/livepatch.c > > @@ -647,

Re: [PATCH v4] x86/msi: fix locking for SR-IOV devices

On 18.09.2024 16:11, Stewart Hildebrand wrote: > On 8/28/24 06:36, Jan Beulich wrote: >> On 27.08.2024 05:59, Stewart Hildebrand wrote: >>> +list_for_each_entry_safe(vf_pdev, tmp, >>> &pdev->physfn.vf_list, >>> + virtfn.entry) >>> +

Re: [PATCH v1 3/3] xen/common: move device initialization code to common code

On 16.09.2024 17:51, oleksii.kuroc...@gmail.com wrote: > On Fri, 2024-09-13 at 19:45 +0200, Jan Beulich wrote: >> On 13.09.2024 16:35, oleksii.kuroc...@gmail.com wrote: >>> On Thu, 2024-09-12 at 17:28 +0200, Jan Beulich wrote: On 11.09.2024 12:04, Oleksii Kurochko wrote: > --- a/xen/common