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):
test-armhf-
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
-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
=
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
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
> > stubdom
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
b/docs/man/xl-network-configuration.5.
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 VI
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 acces
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 V
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 ++
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 (e.g
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
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 interrup
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 repl
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, defau
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. Enabling
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 user
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 b
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 consta
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
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 commonly
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 Zucchelli
> 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
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.
Signed-
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
> refus
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 CONFIG_
*-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 f
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 all
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 5cbfb93abea4410be396b
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 fun
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
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
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 ID
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
---
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
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 | 128
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 +-
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.
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 delet
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.
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, 6
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
xen_arch_doma
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.
Not
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 t
-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* netb
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
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 migrate-s
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 952b5cf94c8727b65e04d
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
test-armhf-ar
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
o
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 destr
51 matches
Mail list logo
