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

2024-05-08 Thread osstest service owner
flight 185947 linux-linus real [real] flight 185948 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/185947/ http://logs.test-lab.xenproject.org/osstest/logs/185948/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking):

Re: [PATCH] gunzip: don't leak memory on error paths

2024-05-08 Thread Andrew Cooper
On 06/05/2024 9:08 am, Jan Beulich wrote: > While decompression errors are likely going to be fatal to Xen's boot > process anyway, the latest with the goal of doing multiple decompressor > runs it is likely better to avoid leaks even on error paths. All the > more when this way code size actually

Xen Security Advisory 457 v3 (CVE-2024-27393) - Linux/xen-netfront: Memory leak due to missing cleanup function

2024-05-08 Thread Xen . org security team
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2024-27393 / XSA-457 version 3 Linux/xen-netfront: Memory leak due to missing cleanup function UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION

Re: [PATCH 3/7] xen/p2m: put reference for superpage

2024-05-08 Thread Julien Grall
Hi, CC-ing Roger as he is working on adding support for the foreign mapping on x86. Although, I am not expecting any implication as only 4KB mapping should be supported. On 08/05/2024 22:05, Julien Grall wrote: On 07/05/2024 14:30, Luca Fancellu wrote: On 7 May 2024, at 14:20, Julien Grall

Re: [PATCH v7 2/6] x86/hvm: Allow access to registers on the same page as MSI-X table

2024-05-08 Thread Marek Marczykowski-Górecki
On Wed, May 08, 2024 at 06:09:48PM +0200, Roger Pau Monné wrote: > On Tue, May 07, 2024 at 02:44:02PM +0200, Marek Marczykowski-Górecki wrote: > > Some devices (notably Intel Wifi 6 AX210 card) keep auxiliary registers > > on the same page as MSI-X table. Device model (especially one in > >

[RFC PATCH v2 4/5] docs/man: document VIF vlan keyword

2024-05-08 Thread Leigh Brown
Document the new `vlan' keyword in xl-network-configuration(5). Signed-off-by: Leigh Brown --- docs/man/xl-network-configuration.5.pod.in | 38 ++ 1 file changed, 38 insertions(+) diff --git a/docs/man/xl-network-configuration.5.pod.in

[RFC PATCH v2 2/5] tools/xl: add vlan keyword to vif option

2024-05-08 Thread Leigh Brown
Update parse_nic_config() to support a new `vlan' keyword. This keyword specifies the VLAN configuration to assign to the VIF when attaching it to the bridge port, on operating systems that support the capability (e.g. Linux). The vlan keyword will allow one or more VLANs to be configured on the

[RFC PATCH v2 0/5] Add bridge VLAN support

2024-05-08 Thread Leigh Brown
Hello all, I realised over the weekend that there is a valid use case for providing a VIF to a domain that has access to multiple VLANs, e.g. a router. Yes, you can create a VIF per VLAN, but if you start having several VLANs (as I do), it would be nicer to create a single interface that has

[RFC PATCH v2 1/5] tools/libs/light: Add vlan field to libxl_device_nic

2024-05-08 Thread Leigh Brown
Add `vlan' string field to libxl_device_nic, to allow a VLAN configuration to be specified for the VIF when adding it to the bridge device. Update libxl_nic.c to read and write the vlan field from the xenstore. This provides the capability for supported operating systems (e.g. Linux) to perform

[RFC PATCH v2 5/5] tools/examples: Example Linux bridge VLAN config

2024-05-08 Thread Leigh Brown
Add a new directory linux-bridge-vlan with examples files showing how to configure systemd-networkd to support a bridge VLAN configuration. Signed-off-by: Leigh Brown --- tools/examples/linux-bridge-vlan/README | 68 +++ tools/examples/linux-bridge-vlan/br0.netdev | 7

[RFC PATCH v2 3/5] tools/hotplug/Linux: Add bridge VLAN support

2024-05-08 Thread Leigh Brown
Update add_to_bridge shell function to read the vlan parameter from xenstore and set the bridge VLAN configuration for the VID. Add additional helper functions to parse the vlan specification, which consists of one or more of the follow: a) single VLAN (e.g. 10). b) contiguous range of VLANs

Re: [PATCH 3/7] xen/p2m: put reference for superpage

2024-05-08 Thread Julien Grall
On 07/05/2024 14:30, Luca Fancellu wrote: Hi Julien, Hi Luca, On 7 May 2024, at 14:20, Julien Grall wrote: Hi Luca, On 23/04/2024 09:25, Luca Fancellu wrote: From: Penny Zheng We are doing foreign memory mapping for static shared memory, and there is a great possibility that it could

Re: [PATCH 02/15] xen/arm/gic: Enable interrupt assignment to running VM

2024-05-08 Thread Julien Grall
Hi Henry, On 08/05/2024 08:49, Henry Wang wrote: On 5/8/2024 5:54 AM, Julien Grall wrote: Hi Henry, What if the DT overlay is unloaded and then reloaded? Wouldn't the same interrupt be re-used? As a more generic case, this could also be a new bitstream for the FPGA. But even if the

Re: [PATCH for-4.19 v2 2/3] xen/x86: enable altp2m at create domain domctl

2024-05-08 Thread Petr Beneš
On Wed, May 8, 2024 at 9:38 PM Andrew Cooper wrote: > Both fields can reasonably share uint32_t, but could you work with Petr > to make both halfs of this land cleanly. Hi, I think creating a new anonymous struct "altp2m" within `struct domain` would be a good fit. uint16_t for my MAX_ALTP2M

Re: [PATCH v2 1/3] x86: allow to suppress port-alias probing

2024-05-08 Thread Jason Andryuk
On 2023-12-18 09:47, Jan Beulich wrote: By default there's already no use for this when we run in shim mode. Plus there may also be a need to suppress the probing in case of issues with it. Before introducing further port alias probing, introduce a command line option allowing to bypass it,

Re: [PATCH for-4.19 v2 2/3] xen/x86: enable altp2m at create domain domctl

2024-05-08 Thread Andrew Cooper
On 08/05/2024 12:23 pm, Roger Pau Monne wrote: > Enabling it using an HVM param is fragile, and complicates the logic when > deciding whether options that interact with altp2m can also be enabled. > > Leave the HVM param value for consumption by the guest, but prevent it from > being set.

Re: [PATCH net] xen-netfront: Add missing skb_mark_for_recycle

2024-05-08 Thread Greg KH
On Tue, May 07, 2024 at 02:57:08PM +0100, Andrew Cooper wrote: > Hello, > > Please could we request a CVE for "xen-netfront: Add missing > skb_mark_for_recycle" which is 037965402a010898d34f4e35327d22c0a95cd51f > in Linus' tree. > > This is a kernel memory leak trigger-able from unprivileged

Re: [PATCH v2 4/8] tools/hvmloader: Wake APs with hypercalls and not with INIT+SIPI+SIPI

2024-05-08 Thread Andrew Cooper
On 08/05/2024 1:39 pm, Alejandro Vallejo wrote: > Removes a needless assembly entry point and simplifies the codebase by > allowing > hvmloader to wake APs it doesn't know the APIC ID of. > > Signed-off-by: Alejandro Vallejo This is basically independent of the rest of the series, and it would

[XEN PATCH v3] x86/IOMMU: address violations of MISRA C:2012 Rule 14.4

2024-05-08 Thread Nicola Vetrini
From: Maria Celeste Cesario The xen sources contain violations of MISRA C:2012 Rule 14.4 whose headline states: "The controlling expression of an if statement and the controlling expression of an iteration-statement shall have essentially Boolean type". Add comparisons to avoid using enum

Re: [XEN PATCH] xen/mem_access: address violations of MISRA C: 2012 Rule 8.4

2024-05-08 Thread Tamas K Lengyel
On Wed, May 8, 2024 at 12:26 PM Julien Grall wrote: > > Hi Tamas, > > On 08/05/2024 17:01, Tamas K Lengyel wrote: > > On Wed, May 8, 2024 at 10:02 AM Alessandro Zucchelli > > wrote: > >> > >> On 2024-05-03 11:32, Julien Grall wrote: > >>> Hi, > >>> > >>> On 03/05/2024 08:09, Alessandro Zucchelli

Re: [PATCH] x86/ucode: Distinguish "ucode already up to date"

2024-05-08 Thread Roger Pau Monné
On Wed, May 08, 2024 at 05:18:42PM +0100, Andrew Cooper wrote: > Right now, Xen returns -ENOENT for both "the provided blob isn't correct for > this CPU", and "the blob isn't newer than what's loaded". > > This in turn causes xen-ucode to exit with an error, when "nothing to do" is > more

Re: [XEN PATCH] xen/mem_access: address violations of MISRA C: 2012 Rule 8.4

2024-05-08 Thread Julien Grall
Hi Tamas, On 08/05/2024 17:01, Tamas K Lengyel wrote: On Wed, May 8, 2024 at 10:02 AM Alessandro Zucchelli wrote: On 2024-05-03 11:32, Julien Grall wrote: Hi, On 03/05/2024 08:09, Alessandro Zucchelli wrote: On 2024-04-29 17:58, Jan Beulich wrote: On 29.04.2024 17:45, Alessandro

Re: [PATCH 2/2] xen/arm: Fix MISRA regression on R1.1, flexible array member not at the end

2024-05-08 Thread Luca Fancellu
> On 2 May 2024, at 19:35, Stefano Stabellini wrote: > > On Tue, 30 Apr 2024, Luca Fancellu wrote: >> Commit 2209c1e35b47 ("xen/arm: Introduce a generic way to access memory >> bank structures") introduced a MISRA regression for Rule 1.1 because a >> flexible array member is introduced in the

[PATCH] x86/ucode: Distinguish "ucode already up to date"

2024-05-08 Thread Andrew Cooper
Right now, Xen returns -ENOENT for both "the provided blob isn't correct for this CPU", and "the blob isn't newer than what's loaded". This in turn causes xen-ucode to exit with an error, when "nothing to do" is more commonly a success condition. Handle EEXIST specially and exit cleanly.

Re: [PATCH v7 2/6] x86/hvm: Allow access to registers on the same page as MSI-X table

2024-05-08 Thread Roger Pau Monné
On Tue, May 07, 2024 at 02:44:02PM +0200, Marek Marczykowski-Górecki wrote: > Some devices (notably Intel Wifi 6 AX210 card) keep auxiliary registers > on the same page as MSI-X table. Device model (especially one in > stubdomain) cannot really handle those, as direct writes to that page is >

Re: [XEN PATCH] xen/mem_access: address violations of MISRA C: 2012 Rule 8.4

2024-05-08 Thread Tamas K Lengyel
On Wed, May 8, 2024 at 10:02 AM Alessandro Zucchelli wrote: > > On 2024-05-03 11:32, Julien Grall wrote: > > Hi, > > > > On 03/05/2024 08:09, Alessandro Zucchelli wrote: > >> On 2024-04-29 17:58, Jan Beulich wrote: > >>> On 29.04.2024 17:45, Alessandro Zucchelli wrote: > Change #ifdef

[PATCH v1 1/1] xen/xenbus: Use *-y instead of *-objs in Makefile

2024-05-08 Thread Andy Shevchenko
*-objs suffix is reserved rather for (user-space) host programs while usually *-y suffix is used for kernel drivers (although *-objs works for that purpose for now). Let's correct the old usages of *-objs in Makefiles. Signed-off-by: Andy Shevchenko --- Note, the original approach is weirdest

Re: [XEN PATCH] xen/mem_access: address violations of MISRA C: 2012 Rule 8.4

2024-05-08 Thread Alessandro Zucchelli
On 2024-05-03 11:32, Julien Grall wrote: Hi, On 03/05/2024 08:09, Alessandro Zucchelli wrote: On 2024-04-29 17:58, Jan Beulich wrote: On 29.04.2024 17:45, Alessandro Zucchelli wrote: Change #ifdef CONFIG_MEM_ACCESS by OR-ing defined(CONFIG_ARM), allowing asm/mem_access.h to be included in

[ovmf test] 185946: all pass - PUSHED

2024-05-08 Thread osstest service owner
flight 185946 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/185946/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf b82c9631da39ca5a1f0702185a46fea60446dd0a baseline version: ovmf

Re: [PATCH 4/7] xen/arm: Parse xen,shared-mem when host phys address is not provided

2024-05-08 Thread Luca Fancellu
Hi Michal, > On 8 May 2024, at 13:09, Michal Orzel wrote: > > Hi Luca, > > On 23/04/2024 10:25, Luca Fancellu wrote: >> >> >> Handle the parsing of the 'xen,shared-mem' property when the host physical >> address is not provided, this commit is introducing the logic to parse it, >> but the

[PATCH v2 7/8] xen/x86: Derive topologically correct x2APIC IDs from the policy

2024-05-08 Thread Alejandro Vallejo
Implements the helper for mapping vcpu_id to x2apic_id given a valid topology in a policy. The algo is written with the intention of extending it to leaves 0x1f and e26 in the future. Toolstack doesn't set leaf 0xb and the HVM default policy has it cleared, so the leaf is not implemented. In that

[PATCH v2 2/8] xen/x86: Simplify header dependencies in x86/hvm

2024-05-08 Thread Alejandro Vallejo
Otherwise it's not possible to call functions described in hvm/vlapic.h from the inline functions of hvm/hvm.h. This is because a static inline in vlapic.h depends on hvm.h, and pulls it transitively through vpt.h. The ultimate cause is having hvm.h included in any of the "v*.h" headers, so break

[PATCH v2 1/8] xen/x86: Add initial x2APIC ID to the per-vLAPIC save area

2024-05-08 Thread Alejandro Vallejo
This allows the initial x2APIC ID to be sent on the migration stream. The hardcoded mapping x2apic_id=2*vcpu_id is maintained for the time being. Given the vlapic data is zero-extended on restore, fix up migrations from hosts without the field by setting it to the old convention if zero. x2APIC

[PATCH v2 5/8] tools/hvmloader: Retrieve (x2)APIC IDs from the APs themselves

2024-05-08 Thread Alejandro Vallejo
Make it so the APs expose their own APIC IDs in a LUT. We can use that LUT to populate the MADT, decoupling the algorithm that relates CPU IDs and APIC IDs from hvmloader. While at this also remove ap_callin, as writing the APIC ID may serve the same purpose. Signed-off-by: Alejandro Vallejo

[PATCH v2 8/8] xen/x86: Synthesise domain topologies

2024-05-08 Thread Alejandro Vallejo
Expose sensible topologies in leaf 0xb. At the moment it synthesises non-HT systems, in line with the previous code intent. Signed-off-by: Alejandro Vallejo --- v2: * Zap the topology leaves of (pv/hvm)_(def/max)_policy rather than the host policy --- tools/libs/guest/xg_cpuid_x86.c | 62

[PATCH v2 6/8] xen/lib: Add topology generator for x86

2024-05-08 Thread Alejandro Vallejo
Add a helper to populate topology leaves in the cpu policy from threads/core and cores/package counts. No functional change, as it's not connected to anything yet. Signed-off-by: Alejandro Vallejo --- v2: * New patch. Extracted from v1/patch6 --- tools/tests/cpu-policy/test-cpu-policy.c |

[PATCH v2 4/8] tools/hvmloader: Wake APs with hypercalls and not with INIT+SIPI+SIPI

2024-05-08 Thread Alejandro Vallejo
Removes a needless assembly entry point and simplifies the codebase by allowing hvmloader to wake APs it doesn't know the APIC ID of. Signed-off-by: Alejandro Vallejo --- v2: * New patch. Replaces adding cpu policy to hvmloader in v1. --- tools/firmware/hvmloader/smp.c | 111

[PATCH v2 0/8] x86: Expose consistent topology to guests

2024-05-08 Thread Alejandro Vallejo
v1 -> v2: * v1/patch 4 replaced by a different strategy (See patches 4 and 5 in v2): * Have hvmloader populate MADT with the real APIC IDs as read by the APs themselves rather than giving it knowledge on how to derive them. * Removed patches 2 and 3 in v1, as no longer relevant.

[PATCH v2 3/8] x86/vlapic: Move lapic_load_hidden migration checks to the check hook

2024-05-08 Thread Alejandro Vallejo
While at it, add a check for the reserved field in the hidden save area. Signed-off-by: Alejandro Vallejo --- v2: * New patch. Addresses the missing check for rsvd_zero in v1. --- xen/arch/x86/hvm/vlapic.c | 41 --- 1 file changed, 30 insertions(+), 11

Re: [PATCH 4/7] xen/arm: Parse xen,shared-mem when host phys address is not provided

2024-05-08 Thread Michal Orzel
Hi Luca, On 23/04/2024 10:25, Luca Fancellu wrote: > > > Handle the parsing of the 'xen,shared-mem' property when the host physical > address is not provided, this commit is introducing the logic to parse it, > but the functionality is still not implemented and will be part of future > commits.

[PATCH for-4.19 v2 1/3] xen/x86: account number of foreign mappings in the p2m

2024-05-08 Thread Roger Pau Monne
Such information will be needed in order to remove foreign mappings during teardown for HVM guests. Right now the introduced counter is not consumed. Signed-off-by: Roger Pau Monné --- Changes since v1: - Drop max_gfn accounting. --- xen/arch/x86/include/asm/p2m.h | 6 ++ 1 file changed,

[PATCH for-4.19 v2 2/3] xen/x86: enable altp2m at create domain domctl

2024-05-08 Thread Roger Pau Monne
Enabling it using an HVM param is fragile, and complicates the logic when deciding whether options that interact with altp2m can also be enabled. Leave the HVM param value for consumption by the guest, but prevent it from being set. Enabling is now done using the misc_flags field in

[PATCH for-4.19 v2 3/3] xen/x86: remove foreign mappings from the p2m on teardown

2024-05-08 Thread Roger Pau Monne
Iterate over the p2m up to the maximum recorded gfn and remove any foreign mappings, in order to drop the underlying page references and thus don't keep extra page references if a domain is destroyed while still having foreign mappings on it's p2m. The logic is similar to the one used on Arm.

[PATCH for-4.19 v2 0/3] xen/x86: support foreign mappings for HVM/PVH

2024-05-08 Thread Roger Pau Monne
Hello, The following series attempts to solve a shortcoming of HVM/PVH guests with the lack of support for foreign mappings. Such lack of support prevents using PVH based guests as stubdomains for example. Add support in a way similar to how it's done on Arm, by iterating over the p2m based on

Xen Security Advisory 457 v2 - Linux/xen-netfront: Memory leak due to missing cleanup function

2024-05-08 Thread Xen . org security team
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-457 version 2 Linux/xen-netfront: Memory leak due to missing cleanup function UPDATES IN VERSION 2 * Clarify the XSA is in netfront and *not*

[XEN PATCH v3] tools/lsevtchn: Use errno macro to handle hypercall error cases

2024-05-08 Thread Matthew Barnes
Currently, lsevtchn aborts its event channel enumeration when it hits its first hypercall error, namely: * When an event channel doesn't exist at the specified port * When the event channel is owned by Xen lsevtchn does not distinguish between different hypercall errors, which results in lsevtchn

[libvirt test] 185943: tolerable all pass - PUSHED

2024-05-08 Thread osstest service owner
flight 185943 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/185943/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185934 test-amd64-amd64-libvirt 15

[ovmf test] 185945: all pass - PUSHED

2024-05-08 Thread osstest service owner
flight 185945 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/185945/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 5cbfb93abea4410be396b5230da4ad2f6c972788 baseline version: ovmf

[xen-unstable test] 185942: tolerable FAIL

2024-05-08 Thread osstest service owner
flight 185942 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/185942/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in 185940 pass in 185942

Re: [PATCH 02/15] xen/arm/gic: Enable interrupt assignment to running VM

2024-05-08 Thread Henry Wang
Hi Julien, On 5/8/2024 5:54 AM, Julien Grall wrote: Hi Henry, What if the DT overlay is unloaded and then reloaded? Wouldn't the same interrupt be re-used? As a more generic case, this could also be a new bitstream for the FPGA. But even if the interrupt is brand new every time for the DT

Re: Referencing domain struct from interrupt handler

2024-05-08 Thread Jens Wiklander
Hi Jan, On Fri, May 3, 2024 at 12:32 PM Jan Beulich wrote: > > On 03.05.2024 09:45, Jens Wiklander wrote: > > Hi Xen maintainers, > > > > In my patch series [XEN PATCH v4 0/5] FF-A notifications [1] I need to > > get a reference to a domain struct from a domain ID and keep it from > > being

Re: [PATCH 2/7] xen/arm: Wrap shared memory mapping code in one function

2024-05-08 Thread Michal Orzel
On 07/05/2024 16:15, Luca Fancellu wrote: > > > Hi Michal, > > > > int __init process_shm(struct domain *d, struct kernel_info *kinfo, > const struct dt_device_node *node) > { > @@ -249,32 +290,10 @@ int __init process_shm(struct domain *d, struct

[ovmf test] 185944: all pass - PUSHED

2024-05-08 Thread osstest service owner
flight 185944 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/185944/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 952b5cf94c8727b65e04d3d507c0134743be2a66 baseline version: ovmf