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)
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
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
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):
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
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):
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
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
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
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
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,
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
-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
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
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
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
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
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
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),
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
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
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 :
>
>
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
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
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
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
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
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
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
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 ||
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
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 (
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,
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
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()
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|
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
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
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
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
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:
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
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
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
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
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
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 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 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
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
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
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: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
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
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
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
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
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
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
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 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
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
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
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
> >>
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
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 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
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
>>> 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 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
>>
>> 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
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,
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
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.
> > …
> > >
74 matches
Mail list logo
