On Fri, Jan 19, 2024 at 05:22:25PM +0800, Kunwu Chan wrote:
> On 2024/1/17 18:40, Markus Elfring wrote:
> > > kasprintf() returns a pointer to dynamically allocated memory
> > > which can be NULL upon failure. Ensure the allocation was successful
> > > by checking the pointer validity.
> > …
> > >
On 2024/1/22 16:30, Dan Carpenter wrote:
On Fri, Jan 19, 2024 at 05:22:25PM +0800, Kunwu Chan wrote:
On 2024/1/17 18:40, Markus Elfring wrote:
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the point
flight 184419 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184419/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-credit1 8 xen-boot fail pass in 184415
Tests which did not succeed, but
>> How do you think about to refer to the function name
>> instead of the file name in the patch subject?
>>
> The main goal is to assign a errno to rc. So use 'fail_mem is good to
> understand.
You responded with information which can fit to the patch body.
How do you think about consequences f
On 19.01.2024 16:25, Anthony PERARD wrote:
> On Fri, Jan 19, 2024 at 09:43:30AM +0100, Michal Orzel wrote:
>> Is my understanding correct that by switching from extra-y to targets we are
>> preventing these objects to
>> appear in non-init-objects (and thus having COV_FLAGS appended) while
>> ret
>>> How do you think about to use another label like “e_nomem”?
>> I'll add a new label to simply the code.
>
> I'm not a Xen maintainer so I can't really comment on their style choices.
Linux contributors can discuss various implementation details.
> However, as one of the kernel-janitors list
On 19.01.2024 17:37, Kelly Choi wrote:
> On Thu, Jan 18, 2024 at 10:09 AM Yann Dirson wrote:
>> On 1/17/24 18:10, Kelly Choi wrote:
>>> A survey was recently conducted to identify how the community as a whole
>>> feels about a certain situation. It was not intended to ban specific
>>> wording or c
On 17.01.2024 18:10, Kelly Choi wrote:
> Hi everyone,
>
> I've spent a bit of time talking to various individuals and the advisory
> board about setting up a new Community Process Group.
>
> A survey was recently conducted to identify how the community as a whole
> feels about a certain situation
On Fri, Jan 19, 2024 at 8:32 PM Elliott Mitchell wrote:
>
> On Sun, Jan 14, 2024 at 10:54:24PM +0100, Paul Leiber wrote:
> >
> > Am 22.10.2023 um 07:42 schrieb Paul Leiber:
> > > Am 13.10.2023 um 20:56 schrieb Paul Leiber:
> > >> Hi Xen developers list,
> > >>
> > >> TL;DR:
> > >> --
> > >>
>
On 19.01.2024 11:36, Roger Pau Monné wrote:
> On Mon, Jan 15, 2024 at 03:40:19PM +0100, Jan Beulich wrote:
>> Leverage the new infrastructure in xen/linkage.h to also switch to per-
>> function sections (when configured), deriving the specific name from the
>> "base" section in use at the time FUNC
On Mon, Jan 22, 2024 at 11:04:41AM +0100, Jan Beulich wrote:
> On 19.01.2024 16:25, Anthony PERARD wrote:
> > On Fri, Jan 19, 2024 at 09:43:30AM +0100, Michal Orzel wrote:
> >> Is my understanding correct that by switching from extra-y to targets we
> >> are preventing these objects to
> >> appear
The minimal function size requirements for an x86 livepatch are either 5 bytes
(for jmp) or 9 bytes (for endbr + jmp), 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
On 22.01.2024 11:54, Anthony PERARD wrote:
> On Mon, Jan 22, 2024 at 11:04:41AM +0100, Jan Beulich wrote:
>> On 19.01.2024 16:25, Anthony PERARD wrote:
>>> On Fri, Jan 19, 2024 at 09:43:30AM +0100, Michal Orzel wrote:
Is my understanding correct that by switching from extra-y to targets we
>>
On Mon, Jan 22, 2024 at 10:54:13AM +, Anthony PERARD wrote:
> On Mon, Jan 22, 2024 at 11:04:41AM +0100, Jan Beulich wrote:
> > On 19.01.2024 16:25, Anthony PERARD wrote:
> > > On Fri, Jan 19, 2024 at 09:43:30AM +0100, Michal Orzel wrote:
> > >> Is my understanding correct that by switching from
On 22/01/2024 12:05, Anthony PERARD wrote:
>
>
> On Mon, Jan 22, 2024 at 10:54:13AM +, Anthony PERARD wrote:
>> On Mon, Jan 22, 2024 at 11:04:41AM +0100, Jan Beulich wrote:
>>> On 19.01.2024 16:25, Anthony PERARD wrote:
On Fri, Jan 19, 2024 at 09:43:30AM +0100, Michal Orzel wrote:
>>>
On 22.01.2024 12:02, Roger Pau Monne wrote:
> The minimal function size requirements for an x86 livepatch are either 5 bytes
> (for jmp) or 9 bytes (for endbr + jmp), and always 4 bytes on Arm. Ensure
> that
> distance between functions entry points is always at least of the minimal
> required si
On 22.01.2024 12:05, Anthony PERARD wrote:
> On Mon, Jan 22, 2024 at 10:54:13AM +, Anthony PERARD wrote:
>> On Mon, Jan 22, 2024 at 11:04:41AM +0100, Jan Beulich wrote:
>>> On 19.01.2024 16:25, Anthony PERARD wrote:
On Fri, Jan 19, 2024 at 09:43:30AM +0100, Michal Orzel wrote:
> Is my
At the moment, trying to run xencov read/reset (calling SYSCTL_coverage_op
under the hood) results in a crash. This is due to a profiler trying to
access data in the .init.* sections (libfdt for Arm and libelf for x86)
that are stripped after boot. Normally, the build system compiles any
*.init.o f
Hi all,
After receiving community feedback, our monthly calls will be recorded.
This will enable members who couldn't attend on the day to listen in on
discussions.
Currently, these are unlisted and published on our new YouTube channel.
Only users with the specific link below will be able to acce
On Mon, Jan 22, 2024 at 12:31 AM Demi Marie Obenour
wrote:
>
> On Fri, Sep 29, 2023 at 05:42:16PM +0100, George Dunlap wrote:
> > The basic credit2 algorithm goes something like this:
> >
> > 1. All vcpus start with the same number of credits; about 10ms worth
> > if everyone has the same weight
>
On Mon, Jan 22, 2024 at 11:54:14AM +, George Dunlap wrote:
> The other issue I have with this (and essentially where I got stuck
> developing credit2 in the first place) is testing: how do you ensure
> that it has the properties that you expect?
Audio is actually quite nice use case at this,
On Mon, Jan 22, 2024 at 12:17 PM Marek Marczykowski-Górecki
wrote:
>
> On Mon, Jan 22, 2024 at 11:54:14AM +, George Dunlap wrote:
> > The other issue I have with this (and essentially where I got stuck
> > developing credit2 in the first place) is testing: how do you ensure
> > that it has the
Hi all,
A reminder our next social will be on *Wednesday 21st February 2024 in
Cambridge! *
Please reply to me directly if you're interested in attending.
Have a chance to connect with the community! Food and drinks will be
provided.
Many thanks,
Kelly Choi
Community Manager
Xen Project
-
On Mon, Jan 22, 2024 at 12:25:58PM +, George Dunlap wrote:
> On Mon, Jan 22, 2024 at 12:17 PM Marek Marczykowski-Górecki
> wrote:
> >
> > On Mon, Jan 22, 2024 at 11:54:14AM +, George Dunlap wrote:
> > > The other issue I have with this (and essentially where I got stuck
> > > developing cr
On Mon, Jan 22, 2024 at 12:50 PM Marek Marczykowski-Górecki
wrote:
>
> On Mon, Jan 22, 2024 at 12:25:58PM +, George Dunlap wrote:
> > On Mon, Jan 22, 2024 at 12:17 PM Marek Marczykowski-Górecki
> > wrote:
> > >
> > > On Mon, Jan 22, 2024 at 11:54:14AM +, George Dunlap wrote:
> > > > The o
On Mon, Jan 22, 2024 at 1:02 PM George Dunlap wrote:
> 2. two VMs running kernbench, but not competing for vcpu
> 3. four VMs running kernbench, competing for vcpus
Sorry, this should be competing for *P*cpus
-George
flight 184422 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184422/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184418
test-amd64-amd64-xl-qemut-win7-amd64
On Tue, Dec 05, 2023 at 02:49:56AM -0800, Xin Li wrote:
> From: "H. Peter Anvin (Intel)"
>
> Add CONFIG_X86_FRED to to make
> cpu_feature_enabled() work correctly with FRED.
>
> Originally-by: Megha Dey
> Signed-off-by: H. Peter Anvin (Intel)
> Tested-by: Shan Kang
> Signed-off-by: Xin Li
>
flight 184423 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184423/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0b09397dfa0123b9a27c2c52fd2ddafd7a902137
baseline version:
ovmf 0c6d29be8b1731ff6880d
On Tue, Dec 05, 2023 at 02:49:57AM -0800, Xin Li wrote:
> Warning: use of this parameter will taint the kernel
> and may cause unknown problems.
>
> + fred[X86-64]
> + Enable flexible return and event delivery
Let's
On 15.01.2024 15:38, Jan Beulich wrote:
> Use the generic framework in xen/linkage.h. No change in generated code
> except of course the converted symbols change to be hidden ones.
>
> Signed-off-by: Jan Beulich
The other architectures have been at least partly switched; would be nice
for PPC to
On 15.01.2024 15:36, Jan Beulich wrote:
> Use the generic framework in xen/linkage.h. No change in generated code
> except for the changed padding value (noticable when config.gz isn't a
> multiple of 4 in size). Plus of course the converted symbols change to
> be hidden ones.
>
> Note that ASM_IN
elf_load_binary() isn't the primary source of brokenness being
indicated. Therefore make the respective PVH log message there
conditional (much like PV has it), and add another instance when
elf_xen_parse() failed (again matching behavior in the PV case).
Make the PV side match the (new) use of %p
Unlike (synchronous) exception handlers, interrupt handlers don't normally
have a need to know the outer context's register state. Similarly, the vast
majority of key handlers has no need for such.
1: IRQ: generalize [gs]et_irq_regs()
2: serial: fake IRQ-regs context in poll handlers
3: keyhandler
Use static_assert_unreachable() to improve readability and anticipate
the build failure (from a linker error to an assembler error) in case
of wrong size.
Signed-off-by: Federico Serafini
---
xen/arch/x86/include/asm/uaccess.h | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --
Introduce macro static_assert_unreachable(), use it to replace
__{get,put}_user_bad() and update ECLAIR configuration to allow the use of
such macro at the end of switch-caluses.
Federico Serafini (3):
xen: introduce static_assert_unreachable()
x86/uaccess: replace __{get,put}_user_bad() with
Introduce macro static_asser_unreachable() to check that a program
point is considered unreachable by the static analysis performed by the
compiler, even at optimization level -O0.
The use of such macro will lead to one of the following outcomes:
- the program point identified by the macro is cons
Move functions (and their data) to common code, and invoke the functions
on Arm as well. This is in preparation of dropping the register
parameters from handler functions.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Reviewed-by: Julien Grall
---
To limit visibility of the per-CPU data
Update ECLAIR configuration to consider safe switch clauses ending
with static_assert_unreachable().
Update docs/misra/deviations.rst accordingly.
Signed-off-by: Federico Serafini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 4
docs/misra/deviations.rst| 4
In preparation of dropping the register parameters from
serial_[rt]x_interrupt() and in turn from IRQ handler functions,
register state needs making available another way for the few key
handlers which need it. Fake IRQ-like state.
Signed-off-by: Jan Beulich
---
The use of guest_cpu_user_regs() i
In preparation for further removal of regs parameters, drop it here. In
the two places where it's actually needed, retrieve IRQ context if
available, or else guest context.
Suggested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
As an alternative to the new boolean parameter, I wonder if we c
It's simply not needed anymore.
Signed-off-by: Jan Beulich
---
v2: Re-base over earlier (new/split) patches.
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -527,7 +527,7 @@ static void switch_serial_input(void)
printk("\n");
}
-static void __serial_rx(char c, struct
They're simply not needed anymore.
Signed-off-by: Jan Beulich
---
v2: Setting of IRQ regs split off to an earlier patch.
--- a/xen/drivers/char/cadence-uart.c
+++ b/xen/drivers/char/cadence-uart.c
@@ -51,7 +51,7 @@ static void cuart_interrupt(int irq, voi
/* ACK. */
if ( statu
It's simply not needed anymore. Note how Linux made this change many
years ago already, in 2.6.19 (late 2006, see [1]).
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Acked-by: Julien Grall
[1] https://git.kernel.org/torvalds/c/7d12e780e003f93433d49ce78cfedf4b4c52adc5
---
v2: Arm build
The only place it was needed is in the spurious handler, and there we
can use get_irq_regs() instead.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -1324,7 +1324,7 @@ int reprogram_timer(s_time_t timeout)
return apic_tmict || !
On 22.01.2024 14:48, Federico Serafini wrote:
> Introduce macro static_asser_unreachable() to check that a program
> point is considered unreachable by the static analysis performed by the
> compiler, even at optimization level -O0.
Is it really intended to limit use of this macro to cases where e
It's not needed anymore. This is in preparation of dropping the register
parameters from IRQ handler functions.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
--- a/xen/arch/x86/guest/xen/xen.c
+++ b/xen/arch/x86/guest/xen/xen.c
@@ -181,7 +181,7 @@ static void cf_check xen_evtchn_upcall(
On Mon, Jan 22, 2024 at 12:39:55PM +0100, Michal Orzel wrote:
> At the moment, trying to run xencov read/reset (calling SYSCTL_coverage_op
> under the hood) results in a crash. This is due to a profiler trying to
> access data in the .init.* sections (libfdt for Arm and libelf for x86)
> that are s
On 22.01.2024 15:46, Anthony PERARD wrote:
> On Mon, Jan 22, 2024 at 12:39:55PM +0100, Michal Orzel wrote:
>> At the moment, trying to run xencov read/reset (calling SYSCTL_coverage_op
>> under the hood) results in a crash. This is due to a profiler trying to
>> access data in the .init.* sections
flight 184424 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184424/
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
On 22.12.2023 16:12, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/cmpxchg.h
> @@ -0,0 +1,496 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/* Copyright (C) 2014 Regents of the University of California */
> +
> +#ifndef _ASM_RISCV_CMPXCHG_H
> +#define _ASM_RISCV_
On 22.12.2023 16:12, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/atomic.h
> @@ -0,0 +1,384 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Taken and modified from Linux.
> + *
> + * Copyright (C) 2007 Red Hat, Inc. All Rights Reserved.
> + * Copyright (
Le mer. 17 janv. 2024 à 03:20, Mario Limonciello
a écrit :
> On 1/16/2024 10:18, Jan Beulich wrote:
> > On 16.01.2024 16:52, Sébastien Chaumat wrote:
> >> Le mar. 2 janv. 2024 à 21:23, Sébastien Chaumat a
> >> écrit :
> >>
> >>>
> >>> output of gpioinfo
>
> kernel alone :
>
> >>
flight 184425 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184425/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 313f9f01552227138e08a7a7f44be48e5ba20a99
baseline version:
ovmf 0b09397dfa0123b9a27c2
On Mon, Jan 22, 2024 at 12:21:47PM +0100, Jan Beulich wrote:
> On 22.01.2024 12:02, Roger Pau Monne wrote:
> > The minimal function size requirements for an x86 livepatch are either 5
> > bytes
> > (for jmp) or 9 bytes (for endbr + jmp), and always 4 bytes on Arm. Ensure
> > that
> > distance be
On Mon, Jan 22, 2024 at 11:50:08AM +0100, Jan Beulich wrote:
> On 19.01.2024 11:36, Roger Pau Monné wrote:
> > On Mon, Jan 15, 2024 at 03:40:19PM +0100, Jan Beulich wrote:
> >> Leverage the new infrastructure in xen/linkage.h to also switch to per-
> >> function sections (when configured), deriving
It is bad form to have inter-function fallthrough. It only functions right
now because alignment padding bytes are NOPs.
However, it also interferes with livepatching binary diffs, because the
implicit grouping of the two functions isn't expressed in the ELF metadata.
Signed-off-by: Andrew Coope
Patch 1 is a bugfix. Patches 2 and 3 are to improve livepatchability.
Andrew Cooper (3):
x86/entry: Fix ELF metadata for NMI and handle_ist_exception
x86/entry: Make #PF/NMI/INT0x82 more amenable to livepatching
x86/entry: Make intra-funciton symbols properly local
xen/arch/x86/x86_64/com
handle_ist_exception isn't part of the NMI handler, just like handle_exception
isn't part of #PF.
Fixes: b3a9037550df ("x86: annotate entry points with type and size")
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Konrad Rzeszutek Wilk
CC: Ross Lagerwall
Each of these symbols are local to their main function. By not having them
globally visible, livepatch's binary diffing logic can reason about the
functions properly.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Konrad Rzeszutek Wilk
CC: Ross Lagerwall
It is bad form to have inter-function fallthrough. It only functions right
now because alignment padding bytes are NOPs.
However, it also interferes with livepatching binary diffs, because the
implicit grouping of the two functions isn't expressed in the ELF metadata.
Signed-off-by: Andrew Coope
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2023-46838 / XSA-448
version 2
Linux: netback processing of zero-length transmit fragment
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
On 22/01/2024 6:17 pm, Andrew Cooper wrote:
> It is bad form to have inter-function fallthrough. It only functions right
> now because alignment padding bytes are NOPs.
>
> However, it also interferes with livepatching binary diffs, because the
> implicit grouping of the two functions isn't expres
When HWP is active, the cpufreq P-state information is not updated. In
that case, return -ENODEV instead of bogus, incomplete info. The xenpm
command already supports skipping results when -ENODEV is returned, so
it is re-used when -EOPNOTSUPP might be more accurate.
Similarly, set_cpufreq_para(
I've been mentioning this on a regular basis, but the state of MCE
handling with Xen seems poor.
I find the present handling of MCE in Xen an odd choice. Having Xen do
most of the handling of MCE events is a behavior matching a traditional
stand-alone hypervisor. Yet Xen was originally pushing a
I am only addressing a couple of Jan's points below.
On Mon, 22 Jan 2024, Jan Beulich wrote:
> > A CPG will be your second point of call, where you can escalate matters
> > quickly for a democratic solution.
>
> Between informal voting and this "second point of call", where does
> formal voting
On Fri, Jan 05, 2024 at 02:22:17PM +0800, Jiqian Chen wrote:
> There is a need for some scenarios to use gsi sysfs.
> For example, when xen passthrough a device to dumU, it will
> use gsi to map pirq, but currently userspace can't get gsi
> number.
> So, add gsi sysfs for that and for other potenti
In an effort to separate intentional arithmetic wrap-around from
unexpected wrap-around, we need to refactor places that depend on this
kind of math. One of the most common code patterns of this is:
VAR + value < VAR
Notably, this is considered "undefined behavior" for signed and pointer
flight 184426 xen-unstable real [real]
flight 184428 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184426/
http://logs.test-lab.xenproject.org/osstest/logs/184428/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armh
Hi Jan,
On 1/22/24 7:20 AM, Jan Beulich wrote:
> On 15.01.2024 15:38, Jan Beulich wrote:
>> Use the generic framework in xen/linkage.h. No change in generated code
>> except of course the converted symbols change to be hidden ones.
>>
>> Signed-off-by: Jan Beulich
>
> The other architectures hav
flight 184427 linux-linus real [real]
flight 184430 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184427/
http://logs.test-lab.xenproject.org/osstest/logs/184430/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-
On 22.01.2024 23:47, Stefano Stabellini wrote:
> On Mon, 22 Jan 2024, Jan Beulich wrote:
>> What definitely needs clarifying is what "review" is: Are R-b tags
>> counted, or is it the number of replies sent commenting on patches?
>
> Yes, I think this needs to be clarified. I would say Reviewed-by
On 22.01.2024 18:27, Roger Pau Monné wrote:
> On Mon, Jan 22, 2024 at 12:21:47PM +0100, Jan Beulich wrote:
>> On 22.01.2024 12:02, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/xen.lds.S
>>> +++ b/xen/arch/x86/xen.lds.S
>>> @@ -99,6 +99,10 @@ SECTIONS
>>> *(.text)
>>> #ifdef CONFIG_CC_SPLI
On 23.01.2024 01:27, Kees Cook wrote:
> --- a/drivers/net/xen-netback/hash.c
> +++ b/drivers/net/xen-netback/hash.c
> @@ -345,7 +345,7 @@ u32 xenvif_set_hash_mapping(struct xenvif *vif, u32 gref,
> u32 len,
> .flags = GNTCOPY_source_gref
> }};
>
> - if ((off + len < off)
74 matches
Mail list logo