On Wednesday, February 19th, 2025 at 5:52 AM, Jan Beulich
wrote:
>
>
> On 18.02.2025 09:31, dm...@proton.me wrote:
>
> > @@ -546,31 +555,23 @@ static void __serial_rx(char c)
> > * getting stuck.
> > */
> > send_global_virq(VIRQ_CONSOLE);
> > - break;
> > -
> > + }
> > #ifdef CONFIG_SBSA_VUAR
On Friday, February 21st, 2025 at 4:04 PM, Stefano Stabellini
wrote:
>
>
> On Wed, 19 Feb 2025, Jan Beulich wrote:
>
> > On 18.02.2025 09:31, dm...@proton.me wrote:
> >
> > > @@ -546,31 +555,23 @@ static void __serial_rx(char c)
> > > * getting stuck.
> > > */
> > > send_global_virq(VIRQ_CON
On Fri, 21 Feb 2025, Andrew Cooper wrote:
> First, rename $TAG to $COMMITTISH. We already pass tags, branches (well, only
> master) and full SHAs into this script.
>
> Xen uses master for QEMU_UPSTREAM_REVISION, and has done for other trees too
> in the path. Apparently we've never specified a d
On Thu, 19 Dec 2024, Sergiy Kibrik wrote:
> From: Stefano Stabellini
>
> It can be beneficial for some dom0less systems to further reduce Xen footprint
> and disable some hypercalls handling code, which may not to be used & required
> in such systems. Each hypercall has a separate option to keep
There are few places which check pv_shim console under CONFIG_PV_SHIM or
CONFIG_X86 in xen console driver.
Instead of #ifdef-ing, use new consoled_is_enabled() in switch_serial_input()
and __serial_rx() (where pv_shim condition is now detected correctly).
Signature of consoled_guest_{rx,tx} has c
On Wed, 19 Feb 2025, Jan Beulich wrote:
> On 18.02.2025 09:31, dm...@proton.me wrote:
> > @@ -546,31 +555,23 @@ static void __serial_rx(char c)
> > * getting stuck.
> > */
> > send_global_virq(VIRQ_CONSOLE);
> > -break;
> > -
> > +}
> > #ifdef CONFIG_SBSA_V
First, rename $TAG to $COMMITTISH. We already pass tags, branches (well, only
master) and full SHAs into this script.
Xen uses master for QEMU_UPSTREAM_REVISION, and has done for other trees too
in the path. Apparently we've never specified a different branch, because the
git-clone rune only pul
Set the baseline for the compiler and binutils to >=12.2 for GCC and
>=2.39 for GNU binutils, as Xen's GitLab CI will use the Debian 12
container for RISCV-64 testing. Therefore, these versions are expected
to be the minimum supported versions.
Signed-off-by: Oleksii Kurochko
---
README | 3 +++
On Fri, Feb 21, 2025 at 08:52:47PM +, Denis Mukhin wrote:
> Also, since there's a build-time configuration parameter along with the
> boot-time
> configuration, perhaps it makes sense to retire boot-time setting in favor of
> build-time setting?
IMO boot time setting is still useful to have,
On Wednesday, February 19th, 2025 at 5:41 AM, Jan Beulich
wrote:
>
>
> On 17.02.2025 22:33, dm...@proton.me wrote:
>
> > Add Xen version printout to 'h' keyhandler output.
> >
> > That is useful for debugging systems that have been left intact for a long
> > time.
> >
> > Signed-off-by: Den
Add Xen version printout to 'h' keyhandler output.
That is useful for debugging systems that have been left intact for a long
time.
Signed-off-by: Denis Mukhin
Reviewed-by: Jan Beulich
---
Changes since v5:
- moved new code outside of #ifdef BUILD_ID
---
xen/common/keyhandler.c| 4
x
On Thursday, February 20th, 2025 at 1:53 AM, Jiqian Chen
wrote:
>
>
> From: Sergiy Kibrik sergiy_kib...@epam.com
>
>
> Introduce config option X86_STDVGA so that stdvga driver can be
> disabled on systems that don't need it.
>
> What's more, in function emulation_flags_ok, to check if toolstack
On Tuesday, February 18th, 2025 at 8:05 AM, Jan Beulich
wrote:
>
>
> On 12.02.2025 23:31, dm...@proton.me wrote:
>
> > --- a/xen/drivers/char/Kconfig
> > +++ b/xen/drivers/char/Kconfig
> > @@ -96,6 +96,18 @@ config SERIAL_TX_BUFSIZE
> >
> > Default value is 32768 (32KiB).
> >
> > +config CONRING
Fix two misaligned reads from the FDT in the opal setup code to avoid
tripping UBSAN failures. Without this change, UBSAN-enabled builds on
PPC will fail on boot before the serial console is even initialized.
Reported-by: Andrew Cooper
Signed-off-by: Shawn Anastasio
---
xen/arch/ppc/opal.c | 18
On Mon, Feb 17, 2025 at 04:26:59PM +, Frediano Ziglio wrote:
> Although code is compiled with -fpic option data is not position
> independent. This causes data pointer to become invalid if
> code is not relocated properly which is what happens for
> efi_multiboot2 which is called by multiboot e
On 21/02/2025 8:10 pm, Andrew Cooper wrote:
> On 21/02/2025 8:08 pm, Shawn Anastasio wrote:
>> Fix two misaligned reads from the FDT in the opal setup code to avoid
>> tripping UBSAN failures. Without this change, UBSAN-enabled builds on
>> PPC will fail on boot before the serial console is even in
Xen's memory management APIs map_pages_to_xen, modify_xen_mappings,
set_fixmap, ioremap_attr, and __vmap all use an unsigned int to
represent architecture-dependent page table entry flags. This assumption
is not well-suited for PPC/radix where some flags go past 32-bits, so
introduce the pte_attr_t
Introduce a new header, mm-types.h, which will be used to define
architecture-specific types pertinent to memory management. This will be
used by a future commit to enable >32 bit PTE flags.
Signed-off-by: Shawn Anastasio
Suggested-by: Jan Beulich
---
Changes in v3:
- Introduced this file per
On 21/02/2025 8:08 pm, Shawn Anastasio wrote:
> Fix two misaligned reads from the FDT in the opal setup code to avoid
> tripping UBSAN failures. Without this change, UBSAN-enabled builds on
> PPC will fail on boot before the serial console is even initialized.
>
> Reported-by: Andrew Cooper
> Sign
From: Andrew Cooper
Signed-off-by: Andrew Cooper
Signed-off-by: Shawn Anastasio
---
Changes from Andrew's v1:
- Define dump_execution_state in the same manner as risc-v
automation/gitlab-ci/build.yaml | 3 +++
xen/arch/ppc/Kconfig | 1 +
xen/arch/ppc/include/asm/process
Extend Andrew's UBSAN enablement work to ppc.
Andrew Cooper (1):
PPC: Activate UBSAN in testing
Shawn Anastasio (1):
xen/ppc: Fix opal.c's misaligned DT reads to avoid tripping UBSAN
automation/gitlab-ci/build.yaml | 3 +++
xen/arch/ppc/Kconfig | 1 +
xen/arch/ppc/inc
Hi Andrew,
On 2/7/25 6:02 PM, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
> ---
> CC: Shawn Anastasio
>
> This compiles, but something is up with the console and nothing useful comes
> out.
I tracked this down to ubsan tripping due to an unaligned access in
opal.c, before the serial co
On 20/02/2025 10:56 pm, Stefano Stabellini wrote:
> automation: upgrade arm32 kernel from bullseye to bookworm
>
> Signed-off-by: Stefano Stabellini
>
> diff --git a/automation/scripts/qemu-smoke-dom0less-arm32.sh
> b/automation/scripts/qemu-smoke-dom0less-arm32.sh
> index 41f6e5d8e6..0c94e662aa
On 2/21/25 1:30 PM, Jan Beulich wrote:
On 21.02.2025 12:57, Oleksii Kurochko wrote:
On 2/21/25 9:35 AM, Jan Beulich wrote:
On 20.02.2025 18:44, Oleksii Kurochko wrote:
There are two reasons for that:
1. In the README, GCC baseline is chosen to be 12.2, whereas Debian 11
uses GCC 10.2.1.
On Fri, Feb 21, 2025 at 01:44:00PM +0100, Jan Beulich wrote:
> On 21.02.2025 13:04, Roger Pau Monne wrote:
> > The MMIO_CONF_BASE reports the base of the MCFG range on AMD systems.
> > Currently Linux is unconditionally attempting to read the MSR without a
> > safe MSR accessor, and since Xen doesn
On Fri, Feb 21, 2025 at 12:34:21PM +, Andrew Cooper wrote:
> On 21/02/2025 12:04 pm, Roger Pau Monne wrote:
> > The MMIO_CONF_BASE reports the base of the MCFG range on AMD systems.
> > Currently Linux is unconditionally attempting to read the MSR without a
> > safe MSR accessor, and since Xen
On 21.02.2025 13:04, Roger Pau Monne wrote:
> The MMIO_CONF_BASE reports the base of the MCFG range on AMD systems.
> Currently Linux is unconditionally attempting to read the MSR without a
> safe MSR accessor, and since Xen doesn't allow access to it Linux reports
> the following error:
>
> unche
On 21/02/2025 12:04 pm, Roger Pau Monne wrote:
> The MMIO_CONF_BASE reports the base of the MCFG range on AMD systems.
> Currently Linux is unconditionally attempting to read the MSR without a
> safe MSR accessor, and since Xen doesn't allow access to it Linux reports
> the following error:
>
> unc
On 21.02.2025 12:57, Oleksii Kurochko wrote:
>
> On 2/21/25 9:35 AM, Jan Beulich wrote:
>> On 20.02.2025 18:44, Oleksii Kurochko wrote:
>>> There are two reasons for that:
>>> 1. In the README, GCC baseline is chosen to be 12.2, whereas Debian 11
>>> uses GCC 10.2.1.
>> Which README is this? N
On 21.02.2025 12:57, Oleksii Kurochko wrote:
>
> On 2/21/25 9:35 AM, Jan Beulich wrote:
>> On 20.02.2025 18:44, Oleksii Kurochko wrote:
>>> There are two reasons for that:
>>> 1. In the README, GCC baseline is chosen to be 12.2, whereas Debian 11
>>> uses GCC 10.2.1.
>> Which README is this? N
On 21/02/2025 11:52 am, Oleksii Kurochko wrote:
>
>
> On 2/20/25 10:54 PM, Stefano Stabellini wrote:
>> Signed-off-by: Stefano Stabellini
>> ---
>> This is possible thanks to "resolve the last 3 MISRA R16.6 violations"
>> being committed.
>>
>> Requesting a release ack. Successful pipeline:
>> htt
The MMIO_CONF_BASE reports the base of the MCFG range on AMD systems.
Currently Linux is unconditionally attempting to read the MSR without a
safe MSR accessor, and since Xen doesn't allow access to it Linux reports
the following error:
unchecked MSR access error: RDMSR from 0xc0010058 at rIP: 0xf
On 2/21/25 9:35 AM, Jan Beulich wrote:
On 20.02.2025 18:44, Oleksii Kurochko wrote:
There are two reasons for that:
1. In the README, GCC baseline is chosen to be 12.2, whereas Debian 11
uses GCC 10.2.1.
Which README is this? Not the one at the root of the tree, afaics, which
continues to
On 2/20/25 10:54 PM, Stefano Stabellini wrote:
Signed-off-by: Stefano Stabellini
---
This is possible thanks to "resolve the last 3 MISRA R16.6 violations"
being committed.
Requesting a release ack. Successful pipeline:
https://gitlab.com/xen-project/people/sstabellini/xen/-/pipelines/168137913
Dear Mykyta,
Thank you so much for your reply. The information you provided is extremely
useful to me.
I will test the PCI passthrough function according to the WIP branches. I
will also promptly provide feedback on related issues. I hope that this can
offer some help in the development of the P
On Thu, Feb 20, 2025 at 02:56:20PM -0800, Stefano Stabellini wrote:
> automation: upgrade arm32 kernel from bullseye to bookworm
>
> Signed-off-by: Stefano Stabellini
Reviewed-by: Roger Pau Monné
Thanks, Roger.
Hi Thomas,
On Fri, 21 Feb 2025 at 10:19, Thomas Zimmermann wrote:
> Am 20.02.25 um 11:53 schrieb Tomi Valkeinen:
> > This change also first calls the drm_driver_color_mode_format(), which
> > could change the behavior even more, but afaics at the moment does not.
>
> Because currently each driver
Hi
Am 21.02.25 um 10:57 schrieb Geert Uytterhoeven:
Hi Thomas,
On Fri, 21 Feb 2025 at 10:19, Thomas Zimmermann wrote:
Am 20.02.25 um 11:53 schrieb Tomi Valkeinen:
This change also first calls the drm_driver_color_mode_format(), which
could change the behavior even more, but afaics at the mom
Hi
Am 20.02.25 um 11:53 schrieb Tomi Valkeinen:
Hi,
On 20/02/2025 12:05, Thomas Zimmermann wrote:
Hi
Am 20.02.25 um 10:18 schrieb Tomi Valkeinen:
[...]
+ * Color modes of 10, 12, 15, 30 and 64 are only supported for use by
+ * legacy user space. Please don't use them in new code. Other modes
On 20.02.2025 18:44, Oleksii Kurochko wrote:
> There are two reasons for that:
> 1. In the README, GCC baseline is chosen to be 12.2, whereas Debian 11
>uses GCC 10.2.1.
Which README is this? Not the one at the root of the tree, afaics, which
continues to mention only x86 and Arm.
Jan
40 matches
Mail list logo
