[PATCH v13A 24/35] x86/fred: Add a NMI entry stub for FRED

From: "H. Peter Anvin (Intel)" On a FRED system, NMIs nest both with themselves and faults, transient information is saved into the stack frame, and NMI unblocking only happens when the stack frame indicates that so should happen. Thus, the NMI entry stub for FRED is really quite small... Signe

hvmloader - allow_memory_relocate overlaps

I am wondering if the variable "allow_memory_relocate" is still relevant today and if its default value is still relevant. Should it be defined to 0 by default instead of 1 (it seems to be a workaround for qemu-traditional, so maybe an outdated default value ? ) ? Code extract: tools/firmware/

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

flight 184146 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/184146/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184143 test-amd64-amd64-xl-qemut-win7-amd64

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

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

xen | Successful pipeline for staging | a60067f3

Pipeline #1108858445 has passed! Project: xen ( https://gitlab.com/xen-project/xen ) Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging ) Commit: a60067f3 ( https://gitlab.com/xen-project/xen/-/commit/a60067f39882a4f40547fc0cd8177bac89cb01b7 ) Commit Message: docs/misra/ru

Re: [XEN PATCH] automation/eclair: add deviations for MISRA C:2012 Rule 16.3

On Fri, 15 Dec 2023, Federico Serafini wrote: > MISRA C:2012 Rule 16.3 states that an unconditional break statement > shall terminate every switch-clause. > > Update ECLAIR configuration to take into account: > - continue, goto, return statements; > - functions that do not give the control bac

Re: [PATCH v2] docs/misra/rules.rst: add Rule 17.1

On Fri, 15 Dec 2023, Julien Grall wrote: > Hi Stefano, > > On 09/12/2023 01:39, Stefano Stabellini wrote: > > > > Signed-off-by: Stefano Stabellini > > --- > > Changes in v2: > > - separated 17.1 in its own patch > > - add a comment > > > > diff --git a/docs/misra/rules.rst b/docs/misra/rules.r

Re: [XEN PATCH] automation/eclair: update configuration of MISRA C:2012 Rule 5.6

On Fri, 15 Dec 2023, Federico Serafini wrote: > On 15/12/23 10:12, Federico Serafini wrote: > > Deviate typedef names that are delberately defined multiple times. > > > > Update docs/misra/deviations.rst accordingly. > > > > Tag Rule 5.6 as clean. > > > > Signed-off-by: Federico Serafini > > --

Re: [XEN PATCH 5/7] xen/arm: traps: add ASSERT_UNREACHABLE() where needed

On Fri, 15 Dec 2023, Nicola Vetrini wrote: > On 2023-12-14 23:32, Stefano Stabellini wrote: > > On Thu, 14 Dec 2023, Julien Grall wrote: > > > Hi, > > > > > > On 13/12/2023 14:02, Nicola Vetrini wrote: > > > > On 2023-12-12 16:49, Julien Grall wrote: > > > > > Hi, > > > > > > > > > > On 11/12/2023

Re: [PATCH 1/2] driver/char: Drop run_in_exception_handler() ifdefary

On Fri, 15 Dec 2023, Andrew Cooper wrote: > Since commit 60a9b0715055 ("xen: introduce CONFIG_GENERIC_BUG_FRAME"), the new > common bug.h provides an implementation of run_in_exception_handler() in all > cases, making the #else here dead. > > Signed-off-by: Andrew Cooper Reviewed-by: Stefano Sta

Re: [XEN PATCH v3 3/3] xen/mm: add declaration for first_valid_mfn

On Fri, 15 Dec 2023, Jan Beulich wrote: > On 14.12.2023 20:10, Julien Grall wrote: > > On 14/12/2023 14:15, George Dunlap wrote: > >> But I do think that it's fair to ask Julien to think about a suitable > >> wording, since the comment is in a sense to remind him (or other ARM > >> maintainers) wha

Re: [PATCH 9/9] xen: add SAF deviation for safe cast removal.

On Fri, 15 Dec 2023, Jan Beulich wrote: > On 14.12.2023 23:04, Stefano Stabellini wrote: > > On Thu, 14 Dec 2023, Jan Beulich wrote: > >> On 14.12.2023 13:07, Simone Ballarin wrote: > >>> --- a/docs/misra/safe.json > >>> +++ b/docs/misra/safe.json > >>> @@ -28,6 +28,14 @@ > >>> }, > >>>

Re: [RFC XEN PATCH v3 2/3] x86/pvh: Add (un)map_pirq and setup_gsi for PVH dom0

On Fri, 15 Dec 2023, Roger Pau Monné wrote: > On Fri, Dec 15, 2023 at 09:24:22AM +0100, Jan Beulich wrote: > > On 14.12.2023 23:49, Stefano Stabellini wrote: > > > On Thu, 14 Dec 2023, Roger Pau Monné wrote: > > >> On Thu, Dec 14, 2023 at 10:58:24AM +0100, Jan Beulich wrote: > > >>> On 14.12.2023 1

[xen-unstable test] 184145: tolerable FAIL

flight 184145 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/184145/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-raw 8 xen-boot fail pass in 184141 Tests which did not succeed, but

Re: [PATCH v6 3/9] iommu/arm: Introduce iommu_add_dt_pci_sideband_ids API

Hi Stewart, On 09/11/2023 18:27, Stewart Hildebrand wrote: From: Oleksandr Tyshchenko The main purpose of this patch is to add a way to register PCI device (which is behind the IOMMU) using the generic PCI-IOMMU DT bindings [1] before assigning that device to a domain. This behaves similarly

Re: [PATCH 1/3] xen/ppc: Enable Boot Allocator

Hi Shawn, On 15/12/2023 02:50, Shawn Anastasio wrote: Hi Julien, Thank you for the feedback. Most of your points will be addressed by following your suggestion of moving ARM's bootfdt.c to common, but I wanted to respond with a few points of clarification. On 12/1/23 5:23 PM, Julien Grall wrot

RE: [PATCH v13 24/35] x86/fred: Add a NMI entry stub for FRED

> So we have recently discovered an overlooked interaction with VT-x. > Immediately before VMENTER and after VMEXIT, CR2 is live with the > *guest* CR2. Regardless of if the guest uses FRED or not, this is guest > state and SHOULD NOT be corrupted. Furthermore, host state MUST NOT leak > into the g

Re: [PATCH 2/2] xen/bug: Complete outstanding TODO

Hi Andrew, On 15/12/2023 18:14, Andrew Cooper wrote: Since this TODO was written, BUILD_BUG_ON() has been moved out of xen/lib.h into xen/macros.h, which has done all the hard work. Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Jan Beulich CC: Stefano Stabellini CC: Wei Liu CC: Ju

Re: [PATCH 1/2] driver/char: Drop run_in_exception_handler() ifdefary

Hi Andrew, On 15/12/2023 18:14, Andrew Cooper wrote: Since commit 60a9b0715055 ("xen: introduce CONFIG_GENERIC_BUG_FRAME"), the new common bug.h provides an implementation of run_in_exception_handler() in all cases, making the #else here dead. This reminds me, I need to look at using CONFIG_GE

Re: [XEN PATCH 5/7] xen/arm: traps: add ASSERT_UNREACHABLE() where needed

Hi, On 15/12/2023 14:08, Nicola Vetrini wrote: Yes, I would go with 3., replace advance_pc with domain_crash. Assuming that it would also solve the violation in ECLAIR. It needs to be prefixed with an ASSERT_UNREACHABLE(), though, because it's still a violation if there is no execution path l

[PATCH 0/2] xen: run_in_exception_handler() cleanup

Cleanup from looking at "[XEN RFC] xen/bug: introduce bug_fn_nonconst_t to validate run_in_exception_handle()". Not really relevant to the MISRA side of things. Gitlab run: https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1108032069 Andrew Cooper (2): driver/char: Drop run_in_ex

[PATCH 1/2] driver/char: Drop run_in_exception_handler() ifdefary

Since commit 60a9b0715055 ("xen: introduce CONFIG_GENERIC_BUG_FRAME"), the new common bug.h provides an implementation of run_in_exception_handler() in all cases, making the #else here dead. Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Jan Beulich CC: Stefano Stabellini CC: Wei Liu

[PATCH 2/2] xen/bug: Complete outstanding TODO

Since this TODO was written, BUILD_BUG_ON() has been moved out of xen/lib.h into xen/macros.h, which has done all the hard work. Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Jan Beulich CC: Stefano Stabellini CC: Wei Liu CC: Julien Grall CC: Federico Serafini --- xen/include/xen/

[PATCH net-next 16/24] net: netkit, veth, tun, virt*: Use nested-BH locking for XDP redirect.

The per-CPU variables used during bpf_prog_run_xdp() invocation and later during xdp_do_redirect() rely on disabled BH for their protection. Without locking in local_bh_disable() on PREEMPT_RT these data structure require explicit locking. This is a follow-up on the previous change which introduce

Re: Crashes under Xen with Radeon graphics card

On 15.12.23 17:19, Deucher, Alexander wrote: [AMD Official Use Only - General] -Original Message- From: Juergen Gross Sent: Friday, December 15, 2023 11:13 AM To: Deucher, Alexander ; lkml ; xen-devel@lists.xenproject.org; amd- g...@lists.freedesktop.org Cc: Koenig, Christian ; Pan, Xi

RE: Crashes under Xen with Radeon graphics card

[AMD Official Use Only - General] > -Original Message- > From: Juergen Gross > Sent: Friday, December 15, 2023 11:13 AM > To: Deucher, Alexander ; lkml ker...@vger.kernel.org>; xen-devel@lists.xenproject.org; amd- > g...@lists.freedesktop.org > Cc: Koenig, Christian ; Pan, Xinhui > > Su

RE: Crashes under Xen with Radeon graphics card

[Public] > -Original Message- > From: Juergen Gross > Sent: Friday, December 15, 2023 6:57 AM > To: lkml ; xen-devel@lists.xenproject.org; amd- > g...@lists.freedesktop.org > Cc: Deucher, Alexander ; Koenig, Christian > ; Pan, Xinhui > Subject: Crashes under Xen with Radeon graphics card

Re: Crashes under Xen with Radeon graphics card

On 15.12.23 17:04, Deucher, Alexander wrote: [Public] -Original Message- From: Juergen Gross Sent: Friday, December 15, 2023 6:57 AM To: lkml ; xen-devel@lists.xenproject.org; amd- g...@lists.freedesktop.org Cc: Deucher, Alexander ; Koenig, Christian ; Pan, Xinhui Subject: Crashes und

[libvirt test] 184144: tolerable all pass - PUSHED

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

Re: [PATCH] x86: allow non-BIGMEM configs to boot on >= 16Tb systems

On Wed, Jun 07, 2023 at 08:17:30AM +0200, Jan Beulich wrote: > While frame table setup, directmap init, and boot allocator population > respect all intended bounds, the logic passing memory to the heap > allocator which wasn't passed to the boot allocator fails to respect > max_{pdx,pfn}. This then

[PATCH v3 4/7] x86/iommu: introduce a rangeset to perform hwdom IOMMU setup

This change just introduces the boilerplate code in order to use a rangeset when setting up the hardware domain IOMMU mappings. The rangeset is never populated in this patch, so it's a non-functional change as far as the mappings the domain gets established. Note there will be a change for HVM do

[PATCH v3 6/7] x86/iommu: switch hwdom IOMMU to use a rangeset

The current loop that iterates from 0 to the maximum RAM address in order to setup the IOMMU mappings is highly inefficient, and it will get worse as the amount of RAM increases. It's also not accounting for any reserved regions past the last RAM address. Instead of iterating over memory addresse

[PATCH v3 3/7] amd-vi: set IOMMU page table levels based on guest reported paddr width

However take into account the minimum number of levels required by unity maps when setting the page table levels. The previous setting of the page table levels for PV guests based on the highest RAM address was bogus, as there can be other non-RAM regions past the highest RAM address that need to

[PATCH v3 0/7] x86/iommu: improve setup time of hwdom IOMMU

Hello, The aim of the series is to reduce boot time setup of IOMMU page tables for dom0. The first patch is completely unrelated leftover work from XSA-445, just included in the series because it's IOMMU code. Second and third patches are a pre-req, as further patches can end up attempting to cr

[PATCH v3 2/7] x86/p2m: move and rename paging_max_paddr_bits()

The function also supports non-paging domains, and hence it being placed in p2m.h and named with the paging_ prefix is misleading. Move to x86 domain.c and rename to domain_max_paddr_bits(). Moving to a different header is non trivial, as the function depends on helpers declared in p2m.h. There'

[PATCH v3 1/7] iommu/vt-d: do not assume page table levels for quarantine domain

Like XSA-445, do not assume IOMMU page table levels on VT-d are always set based on DEFAULT_DOMAIN_ADDRESS_WIDTH and instead fetch the value set by intel_iommu_domain_init() from the domain iommu structure. This prevents changes to intel_iommu_domain_init() possibly getting the levels out of sync

[PATCH v3 5/7] x86/iommu: remove regions not to be mapped

Introduce the code to remove regions not to be mapped from the rangeset that will be used to setup the IOMMU page tables for the hardware domain. This change also introduces two new functions: remove_xen_ranges() and vpci_subtract_mmcfg() that copy the logic in xen_in_range() and vpci_is_mmcfg_add

[PATCH v3 7/7] x86/iommu: cleanup unused functions

Remove xen_in_range() and vpci_is_mmcfg_address() now that hey are unused. Adjust comments to point to the new functions that replace the existing ones. No functional change. Signed-off-by: Roger Pau Monné --- Changes since v2: - Do remove vpci_is_mmcfg_address(). --- Can be squashed with the

Re: [XEN PATCH 5/7] xen/arm: traps: add ASSERT_UNREACHABLE() where needed

Hi Julien, Yes, I would go with 3., replace advance_pc with domain_crash. Assuming that it would also solve the violation in ECLAIR. It needs to be prefixed with an ASSERT_UNREACHABLE(), though, because it's still a violation if there is no execution path leading to domain_crash(), but othe

Re: [PATCH v2] livepatch-build-tools: allow livepatching version.c

On Fri, Dec 15, 2023 at 11:47:18AM +, Ross Lagerwall wrote: > On Thu, Dec 14, 2023 at 8:54 AM Roger Pau Monne wrote: > > > > Currently version.o is explicitly ignored as the file would change as a > > result > > of the orignal and the patched build having possibly different dates, times > >

Re: [PATCH] Fix C compatibility issue in mini-os

On 15.12.23 13:29, Jan Beulich wrote: On 15.12.2023 13:23, Florian Weimer wrote: * Jan Beulich: On 15.12.2023 12:59, Florian Weimer wrote: The cc-option check always fails (that, it picks the second option unconditionally) if the compiler does not support implicit conversion from integers to

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

flight 184143 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/184143/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 183973 test-amd64-amd64-xl-qemut-win7-amd64

Re: [PATCH] Fix C compatibility issue in mini-os

On 15.12.2023 13:23, Florian Weimer wrote: > * Jan Beulich: > >> On 15.12.2023 12:59, Florian Weimer wrote: >>> The cc-option check always fails (that, it picks the second option >>> unconditionally) if the compiler does not support implicit conversion >>> from integers to pointers. Just drop the

Re: [PATCH] Fix C compatibility issue in mini-os

* Jan Beulich: > On 15.12.2023 12:59, Florian Weimer wrote: >> The cc-option check always fails (that, it picks the second option >> unconditionally) if the compiler does not support implicit conversion >> from integers to pointers. Just drop the initialization because it >> seems unnecessary in

Re: [PATCH] Fix C compatibility issue in mini-os

On 15.12.2023 12:59, Florian Weimer wrote: > The cc-option check always fails (that, it picks the second option > unconditionally) if the compiler does not support implicit conversion > from integers to pointers. Just drop the initialization because it > seems unnecessary in this context. Did you

[PATCH] Fix C compatibility issue in mini-os

The cc-option check always fails (that, it picks the second option unconditionally) if the compiler does not support implicit conversion from integers to pointers. Just drop the initialization because it seems unnecessary in this context. Related to:

Crashes under Xen with Radeon graphics card

Hi, I recently stumbled over a test system which showed crashes probably resulting from memory being overwritten randomly. The problem is occurring only in Dom0 when running under Xen. It seems to be present since at least kernel 6.3 (I didn't go back further yet), and it seems NOT to be present

Re: [PATCH v2] livepatch-build-tools: allow livepatching version.c

On Thu, Dec 14, 2023 at 8:54 AM Roger Pau Monne wrote: > > Currently version.o is explicitly ignored as the file would change as a result > of the orignal and the patched build having possibly different dates, times or > changeset strings (by the patched build appending -dirty). > > Fix such diffe

[PATCH v4 2/4] xen/x86: introduce self modifying code test

Introduce a helper to perform checks related to self modifying code, and start by creating a simple test to check that alternatives have been applied. Such test is hooked into the boot process and called just after alternatives have been applied. In case of failure a message is printed, and the h

[PATCH v4 0/4] xen/x86: add testing for self modifying code and livepatch

Hello, The following series contains a misc set of fixes and improvements. There's one improvement for the hypervisor to set function alignment for livepatch builds in order to make sure there's always enough space in a function to be live-patched. Following patches attempt to introduce a set of

[PATCH v4 1/4] x86/livepatch: align functions to ensure minimal distance between entry points

The minimal function size requirements for livepatch are either 5 bytes (for jmp) or 9 bytes (for endbr + jmp) on x86, and always 4 bytes on Arm. Ensure that distance between functions entry points is always at least of the minimal required size for livepatch instruction replacement to be successf

[PATCH v4 3/4] x86/livepatch: introduce a basic live patch test to gitlab CI

Introduce a basic livepatch test using the interface to run self modifying tests. The introduced test relies on changing a function from returning false to returning true. To simplify the burden of keeping a patch that can be provided to livepatch-build-tools, introduce two new files: one contain

[PATCH v4 4/4] automation: add x86-64 livepatching test

Introduce a new gitlab tests for livepatching, using livepatch-build-tools, which better reflects how downstreams build live patches rather than the in-tree tests. The tests applies the dummy in-tree patch example, checks that the patch is applied correctly and then reverts and unloads it. Signed

Re: [XEN PATCH 5/7] xen/arm: traps: add ASSERT_UNREACHABLE() where needed

On 2023-12-14 23:32, Stefano Stabellini wrote: On Thu, 14 Dec 2023, Julien Grall wrote: Hi, On 13/12/2023 14:02, Nicola Vetrini wrote: > On 2023-12-12 16:49, Julien Grall wrote: > > Hi, > > > > On 11/12/2023 12:32, Julien Grall wrote: > > > Hi, > > > > > > On 11/12/2023 10:30, Nicola Vetrini wr

Re: [PATCH v2] docs/misra/rules.rst: add Rule 17.1

Hi Stefano, On 09/12/2023 01:39, Stefano Stabellini wrote: Signed-off-by: Stefano Stabellini --- Changes in v2: - separated 17.1 in its own patch - add a comment diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst index 8a659d8d47..f29b4c3d9a 100644 --- a/docs/misra/rules.rst +++ b/docs/

Re: [PATCH] docs/misra/rules.rst: add Rule 16.2

Hi Stefano, On 08/12/2023 00:18, Stefano Stabellini wrote: Signed-off-by: Stefano Stabellini Acked-by: Julien Grall Cheers, -- Julien Grall

Re: [XEN PATCH v3 3/3] xen/mm: add declaration for first_valid_mfn

Hi, On 15/12/2023 09:59, Nicola Vetrini wrote: +extern mfn_t first_valid_mfn; +    /*     * Create only non-leaf page table entries for the     * page range in Xen virtual address space. ... I still disagree with the placement here (should be xen/numa.h imo), I don't care too much about whic

Re: [XEN PATCH v3 3/3] xen/mm: add declaration for first_valid_mfn

Hi Jan, Julien +extern mfn_t first_valid_mfn; + /* * Create only non-leaf page table entries for the * page range in Xen virtual address space. ... I still disagree with the placement here (should be xen/numa.h imo), I don't care too much about which header is used. So I am ok w

Re: [XEN PATCH v3 3/3] xen/mm: add declaration for first_valid_mfn

Hi Jan, On 15/12/2023 08:03, Jan Beulich wrote: On 14.12.2023 20:10, Julien Grall wrote: On 14/12/2023 14:15, George Dunlap wrote: But I do think that it's fair to ask Julien to think about a suitable wording, since the comment is in a sense to remind him (or other ARM maintainers) what's need

Re: [XEN PATCH] automation/eclair: add deviations for MISRA C:2012 Rule 16.3

On 15/12/23 10:26, Federico Serafini wrote: MISRA C:2012 Rule 16.3 states that an unconditional break statement shall terminate every switch-clause. Update ECLAIR configuration to take into account: - continue, goto, return statements; - functions that do not give the control back; - fa

Re: [PATCH v6 2/5] xen/vpci: move xen_domctl_createdomain vPCI flag to common

Hi Stewart, > On 29 Nov 2023, at 9:25 pm, Stewart Hildebrand > wrote: > > On 11/14/23 04:11, Jan Beulich wrote: >> On 13.11.2023 23:21, Stewart Hildebrand wrote: >>> @@ -709,10 +710,17 @@ int arch_sanitise_domain_config(struct >>> xen_domctl_createdomain *config) >>> return -EINVAL; >>

Re: [XEN PATCH] automation/eclair: update configuration of MISRA C:2012 Rule 5.6

On 15/12/23 10:12, Federico Serafini wrote: Deviate typedef names that are delberately defined multiple times. Update docs/misra/deviations.rst accordingly. Tag Rule 5.6 as clean. Signed-off-by: Federico Serafini --- automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++ automation/e

[XEN PATCH] automation/eclair: add deviations for MISRA C:2012 Rule 16.3

MISRA C:2012 Rule 16.3 states that an unconditional break statement shall terminate every switch-clause. Update ECLAIR configuration to take into account: - continue, goto, return statements; - functions that do not give the control back; - fallthrough pseudo-keyword; - macro BUG(); - co

[XEN PATCH] automation/eclair: update configuration of MISRA C:2012 Rule 5.6

Deviate typedef names that are delberately defined multiple times. Update docs/misra/deviations.rst accordingly. Tag Rule 5.6 as clean. Signed-off-by: Federico Serafini --- automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++ automation/eclair_analysis/ECLAIR/tagging.ecl| 2 +- doc

Re: [RFC XEN PATCH v3 2/3] x86/pvh: Add (un)map_pirq and setup_gsi for PVH dom0

On Fri, Dec 15, 2023 at 09:24:22AM +0100, Jan Beulich wrote: > On 14.12.2023 23:49, Stefano Stabellini wrote: > > On Thu, 14 Dec 2023, Roger Pau Monné wrote: > >> On Thu, Dec 14, 2023 at 10:58:24AM +0100, Jan Beulich wrote: > >>> On 14.12.2023 10:55, Roger Pau Monné wrote: > One way to bodge t

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

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

Re: [RFC XEN PATCH v3 2/3] x86/pvh: Add (un)map_pirq and setup_gsi for PVH dom0

On Fri, Dec 15, 2023 at 07:20:24AM +, Chen, Jiqian wrote: > diff --git a/tools/libs/light/libxl_pci.c b/tools/libs/light/libxl_pci.c > index d3507d13a029..f665d17afbf5 100644 > --- a/tools/libs/light/libxl_pci.c > +++ b/tools/libs/light/libxl_pci.c > @@ -1486,6 +1486,7 @@ static void pci_add_dm

Re: [RFC XEN PATCH v3 2/3] x86/pvh: Add (un)map_pirq and setup_gsi for PVH dom0

On 14.12.2023 23:49, Stefano Stabellini wrote: > On Thu, 14 Dec 2023, Roger Pau Monné wrote: >> On Thu, Dec 14, 2023 at 10:58:24AM +0100, Jan Beulich wrote: >>> On 14.12.2023 10:55, Roger Pau Monné wrote: One way to bodge this would be to detect whether the caller of XEN_DOMCTL_irq_permis

Re: [RFC XEN PATCH v3 2/3] x86/pvh: Add (un)map_pirq and setup_gsi for PVH dom0

On Thu, Dec 14, 2023 at 02:49:18PM -0800, Stefano Stabellini wrote: > On Thu, 14 Dec 2023, Roger Pau Monné wrote: > > On Thu, Dec 14, 2023 at 10:58:24AM +0100, Jan Beulich wrote: > > > On 14.12.2023 10:55, Roger Pau Monné wrote: > > > > On Thu, Dec 14, 2023 at 08:55:45AM +, Chen, Jiqian wrote:

Re: [XEN PATCH v3 3/3] xen/mm: add declaration for first_valid_mfn

On 14.12.2023 20:10, Julien Grall wrote: > On 14/12/2023 14:15, George Dunlap wrote: >> But I do think that it's fair to ask Julien to think about a suitable >> wording, since the comment is in a sense to remind him (or other ARM >> maintainers) what's needed, and since the eventual solution will b