On Thu, Jan 18, 2024 at 01:23:56AM -0500, Patrick Plenefisch wrote:
> On Wed, Jan 17, 2024 at 3:46 AM Jan Beulich wrote:
>
> > On 17.01.2024 07:12, Patrick Plenefisch wrote:
> > > On Tue, Jan 16, 2024 at 4:33 AM Jan Beulich wrote:
> > >
> > >> On 16.01.2024 01:22, Patrick Plenefisch wrote:
> For
On Thu, Jan 18, 2024 at 3:27 AM Roger Pau Monné
wrote:
> On Thu, Jan 18, 2024 at 01:23:56AM -0500, Patrick Plenefisch wrote:
> > On Wed, Jan 17, 2024 at 3:46 AM Jan Beulich wrote:
> >
> > > On 17.01.2024 07:12, Patrick Plenefisch wrote:
> > > > On Tue, Jan 16, 2024 at 4:33 AM Jan Beulich
> wrot
On 18.01.2024 07:23, Patrick Plenefisch wrote:
> On Wed, Jan 17, 2024 at 3:46 AM Jan Beulich wrote:
>> On 17.01.2024 07:12, Patrick Plenefisch wrote:
>>> I'm currently talking to the vendor's support team and testing a beta
>> BIOS
>>> for unrelated reasons, is there something specific I should fo
Hi Shawn,
On 18/01/2024 01:36, Shawn Anastasio wrote:
Hi Julien,
On 12/20/23 7:49 AM, Julien Grall wrote:
Hi,
On 15/12/2023 02:44, Shawn Anastasio wrote:
diff --git a/xen/common/device-tree/bootfdt.c
b/xen/common/device-tree/bootfdt.c
index 796ac01c18..7ddfcc7e2a 100644
--- a/xen/common/devi
On 17/01/2024 08:44, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 16/01/2024 15:37, Julien Grall wrote:
From: Julien Grall
With the upcoming work to color Xen, the binary will not be anymore
physically contiguous. This will be a problem during boot as the
assembly code will need to w
Hi Michal,
On 17/01/2024 08:53, Michal Orzel wrote:
On 16/01/2024 15:37, Julien Grall wrote:
From: Julien Grall
With the upcoming work to color Xen, the binary will not be anymore
physically contiguous. This will be a problem during boot as the
assembly code will need to work out where ea
On 17/01/2024 17:38, Carlo Nonato wrote:
Hi Julien
Hi Carlo,
On Tue, Jan 16, 2024 at 3:37 PM Julien Grall wrote:
From: Julien Grall
In order to confirm the early boot code is self-contained, allocate a
separate trampoline region for secondary to boot from it.
[...]
@@ -304,6 +307
Hi Carlo,
On 17/01/2024 17:38, Carlo Nonato wrote:
On Tue, Jan 16, 2024 at 12:59 PM Julien Grall wrote:
Hi,
On 15/01/2024 16:16, Julien Grall wrote:
On 15/01/2024 15:43, Carlo Nonato wrote:
Hi Julien,
Hi Carlo,
On Mon, Jan 15, 2024 at 12:18 PM Julien Grall wrote:
On 15/01/2024 10:11,
On Wed, 2024-01-17 at 14:42 +0100, Jan Beulich wrote:
> On 17.01.2024 12:37, Oleksii wrote:
> > > > >
> > > > > > > Also you want to make sure asm-generic/bitops/bitops-
> > > > > > > bits.h
> > > > > > > is
> > > > > > > really in use here, or else an arch overriding / not
> > > > > > > using
> >
On Thu, Jan 18, 2024 at 03:34:13AM -0500, Patrick Plenefisch wrote:
> On Thu, Jan 18, 2024 at 3:27 AM Roger Pau Monné
> wrote:
>
> > On Thu, Jan 18, 2024 at 01:23:56AM -0500, Patrick Plenefisch wrote:
> > > On Wed, Jan 17, 2024 at 3:46 AM Jan Beulich wrote:
> > >
> > > > On 17.01.2024 07:12, Pat
Hi all,
On 1/17/24 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 situa
On 18.01.2024 10:43, Oleksii wrote:
> On Wed, 2024-01-17 at 14:42 +0100, Jan Beulich wrote:
>> On 17.01.2024 12:37, Oleksii wrote:
>>
Also you want to make sure asm-generic/bitops/bitops-
bits.h
is
really in use here, or else an arch overriding / not
On 22.12.2023 16:12, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/bitops/bitops-bits.h
> @@ -0,0 +1,10 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_GENERIC_BITOPS_BITS_H_
> +#define _ASM_GENERIC_BITOPS_BITS_H_
> +
> +#define BITOP_BITS_PER_WORD 32
> +#
On 17/01/2024 9:37 am, Jan Beulich wrote:
> --- a/xen/arch/x86/ioport_emulate.c
> +++ b/xen/arch/x86/ioport_emulate.c
> @@ -8,11 +8,10 @@
> #include
> #include
>
> -unsigned int (*__read_mostly ioemul_handle_quirk)(
> -uint8_t opcode, char *io_emul_stub, struct cpu_user_regs *regs);
> +bo
On 18.01.2024 12:04, Andrew Cooper wrote:
> On 17/01/2024 9:37 am, Jan Beulich wrote:
>> --- a/xen/arch/x86/ioport_emulate.c
>> +++ b/xen/arch/x86/ioport_emulate.c
>> @@ -8,11 +8,10 @@
>> #include
>> #include
>>
>> -unsigned int (*__read_mostly ioemul_handle_quirk)(
>> -uint8_t opcode, ch
On 18/01/2024 11:09 am, Jan Beulich wrote:
> On 18.01.2024 12:04, Andrew Cooper wrote:
>> On 17/01/2024 9:37 am, Jan Beulich wrote:
>>> --- a/xen/arch/x86/ioport_emulate.c
>>> +++ b/xen/arch/x86/ioport_emulate.c
>>> @@ -8,11 +8,10 @@
>>> #include
>>> #include
>>>
>>> -unsigned int (*__read_mo
At the moment, trying to run xencov read/reset (calling SYSCTL_coverage_op
under the hood) results in a crash. This is due to an attempt to
access code in the .init.* sections (libfdt for Arm and libelf for x86)
that are stripped after boot. Normally, the build system compiles any
*.init.o file wit
On Thu, Jan 18, 2024 at 10:46:26AM +0100, Roger Pau Monné wrote:
> On Thu, Jan 18, 2024 at 03:34:13AM -0500, Patrick Plenefisch wrote:
> > On Thu, Jan 18, 2024 at 3:27 AM Roger Pau Monné
> > wrote:
> >
> > > On Thu, Jan 18, 2024 at 01:23:56AM -0500, Patrick Plenefisch wrote:
> > > > On Wed, Jan 1
On 18.01.2024 13:06, 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 an attempt to
> access code in the .init.* sections (libfdt for Arm and libelf for x86)
> that are stripped after boot. Normally
On 18/01/2024 12:06 pm, 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 an attempt to
> access code in the .init.* sections
Minor point, but for coverage it's only data. It's the per-basic-block
Hi all,
A reminder that we have our community call today.
Please find details below on how to join.
Many thanks,
Kelly Choi
Community Manager
Xen Project
-- Forwarded message -
From: Kelly Choi
Date: Wed, Jan 3, 2024 at 2:22 PM
Subject: [ANNOUNCE] Call for agenda items for Com
Hi Jan,
On 11/01/2024 07:31, Jan Beulich wrote:
There are exactly two handlers which care about the registers. Have
handle_keypress() make the pointer available via a per-CPU variable,
thus eliminating the need to pass it to all IRQ key handlers, making
sure that a console-invoked key's handling
Hi Jan,
On 11/01/2024 07:32, Jan Beulich wrote:
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: Julien Grall
---
To limit vis
flight 184388 xen-unstable real [real]
flight 184391 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184388/
http://logs.test-lab.xenproject.org/osstest/logs/184391/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armh
Hi Jan,
On 11/01/2024 07:35, Jan Beulich wrote:
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
This patch will need to be adjusted to compile on Arm. If you
incorporate the changes from Micha
Hi Jan,
On Tue, Jan 9, 2024 at 11:33 AM Jan Beulich wrote:
>
> On 09.01.2024 11:28, Jan Beulich wrote:
> > On 02.01.2024 10:51, Carlo Nonato wrote:
> >> v5:
> >> - Carlo Nonato as the new author
> >> - the colored allocator balances color usage for each domain and it
> >> searches
> >> linearl
Hi Jan,
On 18/01/2024 14:12, Jan Beulich wrote:
>
>
> On 18.01.2024 13:06, 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 an attempt to
>> access code in the .init.* sections (libfdt for Arm
On Mon, Jan 15, 2024 at 03:34:05PM +0100, Jan Beulich wrote:
> Recent gas versions generate minimalistic Dwarf debug info for items
> annotated as functions and having their sizes specified [1]. Furthermore
> generating live patches wants items properly annotated. "Borrow" Arm's
> END() and (remote
flight 184389 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184389/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184367
test-armhf-armhf-libvirt-qcow2 15 saveres
On 18.01.2024 15:40, Michal Orzel wrote:
> On 18/01/2024 14:12, Jan Beulich wrote:
>> On 18.01.2024 13:06, 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 an attempt to
>>> access code in the .
On 18.01.2024 15:06, Julien Grall wrote:
> On 11/01/2024 07:31, Jan Beulich wrote:
>> There are exactly two handlers which care about the registers. Have
>> handle_keypress() make the pointer available via a per-CPU variable,
>> thus eliminating the need to pass it to all IRQ key handlers, making
>
On 18.01.2024 15:17, Julien Grall wrote:
> On 11/01/2024 07:35, Jan Beulich wrote:
>> 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
>
> This patch will need to be adjusted to compile on A
On 17.01.2024 18:02, Roger Pau Monné wrote:
> On Mon, Jan 15, 2024 at 03:34:05PM +0100, Jan Beulich wrote:
>> Recent gas versions generate minimalistic Dwarf debug info for items
>> annotated as functions and having their sizes specified [1]. Furthermore
>> generating live patches wants items prope
On 18.01.2024 15:52, Roger Pau Monné wrote:
> On Mon, Jan 15, 2024 at 03:34:05PM +0100, Jan Beulich wrote:
>> Recent gas versions generate minimalistic Dwarf debug info for items
>> annotated as functions and having their sizes specified [1]. Furthermore
>> generating live patches wants items prope
On Thu, Jan 18, 2024 at 4:46 AM Roger Pau Monné
wrote:
> >
> > Luckily linux logs are mercifully short. Append this to
> > xen-4.18p_grub_linuxoffset_pvh.log:
> >
> > [0.778770] i2c_designware AMDI0010:00: Unknown Synopsys component
> type:
> > 0x
> > [0.914664] amd_gpio AMDI0030:
On Thu, Jan 18, 2024 at 02:12:21PM +0100, Jan Beulich wrote:
> On 18.01.2024 13:06, 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 an attempt to
> > access code in the .init.* sections (libfdt
On Mon, Jan 15, 2024 at 03:34:56PM +0100, Jan Beulich wrote:
> @@ -625,7 +627,7 @@ ENTRY(dom_crash_sync_extable)
>
> /* No special register assumptions. */
> #ifdef CONFIG_PV
> -ENTRY(continue_pv_domain)
> +FUNC(continue_pv_domain)
> ENDBR64
> call check_wakeup_from_wait
> r
flight 184390 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184390/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-amd 22 guest-start/debian.repeat fail REGR. vs.
184270
build-i386
flight 184395 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184395/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 264636d8e6983e0f6dc6be2fca9d84ec81315954
baseline version:
ovmf 59f024c76ee57c2bec847
flight 184397 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184397/
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
flight 184396 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184396/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184270
test-amd64-amd64-xl-qemut-win7-amd64
flight 184399 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184399/
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
flight 184400 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184400/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9d3fe85fcc8ff386ee0814a4dad03bbf7dc54594
baseline version:
ovmf 264636d8e6983e0f6dc6b
43 matches
Mail list logo
