Hello everyone,
I would like to announce that Xen 4.21 is expected to be released
on Wednesday, March 5, (not on original date due to final preparation
details).
Thanks in advance, and have a great weekend!
Best regards,
Oleksii
Most of Xen's LOCK prefixes are already without semicolon, but we have a few
still remaining in the tree.
As noted in the Linux patch, this adversly affects size/inlining decisions,
and prevents the assembler from diagnosing some classes of error.
No functional change.
Link: https://lore.kernel.
On 2/18/25 3:35 PM, Roger Pau Monne wrote:
When building a PVH dom0 Xen attempts to map all (relevant) MMIO regions
into the p2m for dom0 access. However the information Xen has about the
host memory map is limited. Xen doesn't have access to any resources
described in ACPI dynamic tables, an
Hello everyone,
I realized I made a mistake— the correct version should be 4.20, not 4.21.
Apologies for the confusion!
Thanks for your understanding.
~ Oleksii
On 2/28/25 9:07 PM, Oleksii Kurochko wrote:
Hello everyone,
I would like to announce that Xen 4.21 is expected to be released
on We
'G' stands for "imafd_zicsr_zifencei".
Extensions 'f' and 'd' aren't really needed for Xen, and allowing floating
point registers to be used can lead to crashes.
Extensions 'i', 'm', 'a', 'zicsr', and 'zifencei' are necessary for the
operation of Xen, which is why they are used explicitly (uncond
On 2025-02-28 04:36, Roger Pau Monné wrote:
On Thu, Feb 27, 2025 at 01:28:11PM -0500, Jason Andryuk wrote:
On 2025-02-27 05:23, Roger Pau Monné wrote:
On Wed, Feb 26, 2025 at 04:11:25PM -0500, Jason Andryuk wrote:
To work around this, we can, for per-device IRTs, program the hardware
to use
Supported ISA extensions are specified in the device tree within the CPU
node, using two properties: `riscv,isa-extensions` and `riscv,isa`.
Currently, Xen does not support the `riscv,isa-extensions` property and
will be added in the future.
The `riscv,isa` property is parsed for each CPU, and th
Considering that the Zbb extension is supported since GCC version 12 [1]
and that older GCC versions do not support Z extensions in -march (I haven't
faced this issue for GCC >=11.2), leading to compilation failures,
the baseline version for GCC is set to 12.2 and for GNU binutils to 2.39.
The GCC
According to riscv/booting.txt, it is expected that Zbb should be supported.
Drop ANDN_INSN() in asm/cmpxchg.h as Zbb is mandatory now so `andn`
instruction could be used directly.
Signed-off-by: Oleksii Kurochko
---
Changes in V8:
- Drop ANDN_INSN() in asm/cmpxchg.h as Zbb is mandatory now so
On Thu, Feb 27, 2025 at 04:10:25PM +0100, Jürgen Groß wrote:
> On 26.02.25 16:55, Anthony PERARD wrote:
> > On Tue, Feb 25, 2025 at 08:30:33AM +0100, Juergen Gross wrote:
> > > Channels work differently than other device types: their devid should
> > > be -1 initially in order to distinguish them f
On Tue, Feb 18, 2025 at 05:26:18PM +0100, Philippe Mathieu-Daudé wrote:
> Per Stefano:
>
> For ARM 32-bit, I do not think we ever had many deployments,
> as most are 64-bit. Even when there are deployments, they do
> not typically use QEMU, as QEMU is less important for Xen on
> ARM compar
Implement early_fdt_map() function, that is responsible to map the
device tree blob in the early stages of the boot process, since at
this stage the MPU C data structure are not yet initialised, it is
using low level APIs to write into the MPU registers at a fixed
MPU region number.
The MPU memory
On 27/02/2025 8:11 am, Jan Beulich wrote:
> On 26.02.2025 18:20, Andrew Cooper wrote:
>> --- a/xen/arch/riscv/include/asm/bitops.h
>> +++ b/xen/arch/riscv/include/asm/bitops.h
>> @@ -125,6 +125,13 @@ static inline void clear_bit(int nr, volatile void *p)
>> #undef NOT
>> #undef __AMO
>>
>> +#de
Introduce the MPU memory mapping flags in asm/page.h.
Signed-off-by: Luca Fancellu
---
xen/arch/arm/include/asm/page.h | 25 +
1 file changed, 25 insertions(+)
diff --git a/xen/arch/arm/include/asm/page.h b/xen/arch/arm/include/asm/page.h
index 69f817d1e68a..22f7d2c6cb30
Introduce few utility function to manipulate and handle the
pr_t type.
Signed-off-by: Luca Fancellu
---
xen/arch/arm/include/asm/arm64/mpu.h | 36
1 file changed, 36 insertions(+)
diff --git a/xen/arch/arm/include/asm/arm64/mpu.h
b/xen/arch/arm/include/asm/arm64/mp
Currently the function setup_pagetables() take care to initialise
the mappings on MMU system; MPU systems don't have page tables,
but needs to track the status of the MPU programmed regions.
So rename setup_pagetables() into setup_mappings() and implement the
function on MPU systems, start introdu
The define HYPERVISOR_VIRT_START is required by the common code,
even if MPU system doesn't use virtual memory, define it in
mpu/layout.h in order to reuse existing code.
Disable a check in the linker script for arm for !MMU systems.
Signed-off-by: Luca Fancellu
---
xen/arch/arm/include/asm/mpu
From: Penny Zheng
Introduce pr_t typedef which is a structure having the prbar
and prlar members, each being structured as the registers of
the aarch64 armv8-r architecture.
Introduce the array 'xen_mpumap' that will store a view of
the content of the MPU regions.
Introduce MAX_MPU_REGIONS macr
Provide a function that creates a pr_t object from a memory
range and some attributes.
Signed-off-by: Luca Fancellu
---
xen/arch/arm/include/asm/arm64/mpu.h | 15 ++
xen/arch/arm/include/asm/mpu/mm.h| 3 ++
xen/arch/arm/mpu/mm.c| 73
3 files
From: Penny Zheng
virt_to_maddr and maddr_to_virt are used widely in Xen code. So
even there is no VMSA in MPU system, we keep the interface in MPU to
don't change the existing common code.
In order to do that, move the virt_to_maddr() definition to mmu/mm.h,
instead for maddr_to_virt() it's mor
Hi all,
This is the first chunk of work to support MPU and R82 on Xen, this serie
reaches the early boot stages until setup_pagetables() which will be renamed
in one of the commit on the serie to have a more generic name between MPU and
MMU memory management subsystem.
Luca Fancellu (7):
arm/mp
On 2/28/25 3:59 PM, Milan Djokic wrote:
From: Slavisa Petrovic
This patch implements copy_to_guest/copy_from_guest functions for RISC-V.
These functions are designed to facilitate data exchange between guest and
hypervisor.
Signed-off-by: Milan Djokic
Signed-off-by: Slavisa Petrovic
---
Teste
On Tue, Feb 18, 2025 at 05:26:17PM +0100, Philippe Mathieu-Daudé wrote:
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Anthony PERARD
Thanks,
--
Anthony PERARD
On Tue, Feb 18, 2025 at 05:26:16PM +0100, Philippe Mathieu-Daudé wrote:
> Have "hw/xen/xen-bus" include the bare minimal set of headers.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Anthony PERARD
Thanks,
--
Anthony PERARD
On 28/02/2025 2:59 pm, Milan Djokic wrote:
> From: Slavisa Petrovic
>
> This patch implements copy_to_guest/copy_from_guest functions for RISC-V.
> These functions are designed to facilitate data exchange between guest and
> hypervisor.
>
> Signed-off-by: Milan Djokic
> Signed-off-by: Slavisa Pe
On Tue, Feb 18, 2025 at 05:26:15PM +0100, Philippe Mathieu-Daudé wrote:
> Have "hw/xen/xen-hvm-common.h" include the bare minimal set
> of headers. Adapt sources to avoid errors when refactoring
> unrelated headers such:
>
> include/hw/xen/xen-hvm-common.h:71:5: error: unknown type name
> ‘xene
Describe the usage of devices 5853:0002 and 5853:C000.
Signed-off-by: Frediano Ziglio
---
docs/man/xen-pci-device-reservations.7.pod | 9 +
1 file changed, 9 insertions(+)
diff --git a/docs/man/xen-pci-device-reservations.7.pod
b/docs/man/xen-pci-device-reservations.7.pod
index 9ddf3a1
Currently, the uboot-script-gen does not account for reserved memory
regions in the device tree. This oversight can lead to scenarios where
one or more boot modules overlap with a reserved region. As a result,
Xen will always crash upon detecting this overlap. However, the crash
will be silent (wit
From: Slavisa Petrovic
This patch implements copy_to_guest/copy_from_guest functions for RISC-V.
These functions are designed to facilitate data exchange between guest and
hypervisor.
Signed-off-by: Milan Djokic
Signed-off-by: Slavisa Petrovic
---
Tested on qemu with xcp-ng latest branch
htt
On 23.05.24 01:59, Stewart Hildebrand wrote:
> This is next version of vPCI rework. Aim of this series is to prepare
> ground for introducing PCI support on ARM platform.
>
> in v16:
> - minor updates - see individual patches
>
> in v15:
> - reorder so ("arm/vpci: honor access size when retur
On Wed, Feb 26, 2025 at 03:10:21PM -0500, Jason Andryuk wrote:
> It is valid for a PCI device to not have a legacy IRQ. In that case, do
> not print an error to keep the lgs clean.
>
> This relies on pciback being updated to return -ENOENT for a missing
> GSI.
>
> Fixes: b93e5981d258 ("tools: Ad
On Wed, Feb 26, 2025 at 03:10:21PM -0500, Jason Andryuk wrote:
> It is valid for a PCI device to not have a legacy IRQ. In that case, do
> not print an error to keep the lgs clean.
^ logs?
>
> This relies on pciback being updated to return -ENOENT for a missing
>
Hi Ayan,
> On 28 Feb 2025, at 12:51, Ayan Kumar Halder wrote:
>
>
> On 28/02/2025 08:56, Julien Grall wrote:
>> Hi,
> Hi Julien/Bertrand,
>>
>> On 27/02/2025 15:09, Ayan Kumar Halder wrote:
>>> In the current patch, we have defined the requirements which are common for
>>> all the commands.
>>
Hi Ayan,
> On 28 Feb 2025, at 12:07, Ayan Kumar Halder wrote:
>
>
> On 28/02/2025 07:54, Bertrand Marquis wrote:
>> Hi Ayan,
> Hi Bertrand,
>>
>>> On 27 Feb 2025, at 20:29, Ayan Kumar Halder wrote:
>>>
>>>
>>> On 27/02/2025 17:15, Bertrand Marquis wrote:
Hi Ayan,
>>> Hi Bertrand,
>>>
On Thu, Feb 27, 2025 at 03:41:54PM +, Andrew Cooper wrote:
> On 27/02/2025 2:50 pm, Frediano Ziglio wrote:
> > On XenServer on Windows machine a platform device with ID 2 instead of
> > 1 is used.
> >
> > This device is mainly identical to device 1 but due to some Windows
> > update behaviour i
On Thu, Feb 27, 2025 at 3:41 PM Andrew Cooper wrote:
>
> On 27/02/2025 2:50 pm, Frediano Ziglio wrote:
> > On XenServer on Windows machine a platform device with ID 2 instead of
> > 1 is used.
> >
> > This device is mainly identical to device 1 but due to some Windows
> > update behaviour it was d
On 28/02/2025 08:56, Julien Grall wrote:
Hi,
Hi Julien/Bertrand,
On 27/02/2025 15:09, Ayan Kumar Halder wrote:
In the current patch, we have defined the requirements which are
common for
all the commands.
Signed-off-by: Ayan Kumar Halder
---
Changes from -
v1 - 1. Fixed `XenProd~version
Attempt to reduce the MSI entry writes, and the associated checking whether
memory decoding and MSI-X is enabled for the PCI device, when the MSI data
hasn't changed.
When using Interrupt Remapping the MSI entry will contain an index into
the remapping table, and it's in such remapping table where
On 26.02.25 12:48, Jan Beulich wrote:
> On 26.02.2025 10:58, Mykyta Poturai wrote:
>> On 10.02.25 12:52, Jan Beulich wrote:
>>> On 10.02.2025 11:30, Mykyta Poturai wrote:
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -20,6 +20,7 @@
#include
On Wed, 2025-02-26 at 18:18 -0800, Sean Christopherson wrote:
> This... snowballed a bit.
>
> The bulk of the changes are in kvmclock and TSC, but pretty much every
> hypervisor's guest-side code gets touched at some point. I am reaonsably
> confident in the correctness of the KVM changes. For a
On 28/02/2025 07:54, Bertrand Marquis wrote:
Hi Ayan,
Hi Bertrand,
On 27 Feb 2025, at 20:29, Ayan Kumar Halder wrote:
On 27/02/2025 17:15, Bertrand Marquis wrote:
Hi Ayan,
Hi Bertrand,
I have just some clarifications.
On 27 Feb 2025, at 16:09, Ayan Kumar Halder wrote:
In the curre
Hi Julien/Luca,
On 28/02/2025 09:22, Julien Grall wrote:
On 26/02/2025 08:28, Luca Fancellu wrote:
Hi Julien,
Hi Luca,
#ifdef CONFIG_EARLY_PRINTK
diff --git a/xen/arch/arm/include/asm/arm64/mpu.h
b/xen/arch/arm/include/asm/mpu.h
Why not in include/mpu/ ?
Do you mean include/asm/mpu
On 2025-02-28 11:06, Andrew Cooper wrote:
This ought to have been part of the original patch, so as to avoid
breaking
CI.
Fixes: 31c0d6fdf421 ("xen/bsearch: Split out of lib.h into it's own
header")
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Anthony PERARD
CC
This ought to have been part of the original patch, so as to avoid breaking
CI.
Fixes: 31c0d6fdf421 ("xen/bsearch: Split out of lib.h into it's own header")
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Gra
On Thu, Feb 27, 2025 at 02:12:58PM +, Alejandro Vallejo wrote:
> Hi,
>
> On Wed Feb 26, 2025 at 5:33 PM GMT, Roger Pau Monné wrote:
> > On Wed, Feb 26, 2025 at 02:11:23PM +0100, Jan Beulich wrote:
> > > On 18.02.2025 15:22, Alejandro Vallejo wrote:
> > > > @@ -1621,6 +1624,14 @@ static int cf_
On Thu, Feb 27, 2025 at 01:28:11PM -0500, Jason Andryuk wrote:
> On 2025-02-27 05:23, Roger Pau Monné wrote:
> > On Wed, Feb 26, 2025 at 04:11:25PM -0500, Jason Andryuk wrote:
> > > When the
> > > ath11k driver passes the guest address and data to the hardware, it
> > > generates faults when there
On 26/02/2025 08:28, Luca Fancellu wrote:
Hi Julien,
Hi Luca,
#ifdef CONFIG_EARLY_PRINTK
diff --git a/xen/arch/arm/include/asm/arm64/mpu.h
b/xen/arch/arm/include/asm/mpu.h
Why not in include/mpu/ ?
Do you mean include/asm/mpu? or something different?
Yes, sorry typo, I mean includ
On Thu, Feb 27, 2025 at 08:38:27PM +, Andrew Cooper wrote:
> I've raised this during review before, but:
>
> > (XEN) [ 1.209230] AMD-Vi: IOMMU Extended Features:
> > (XEN) [ 1.213998] - Peripheral Page Service Request
> > (XEN) [ 1.218849] - x2APIC
> > (XEN) [ 1.221536] - NX bit
>
Hi,
On 27/02/2025 15:09, Ayan Kumar Halder wrote:
In the current patch, we have defined the requirements which are common for
all the commands.
Signed-off-by: Ayan Kumar Halder
---
Changes from -
v1 - 1. Fixed `XenProd~version_hyp_ret_val~1` requirement as Xen does not return
0 for success in
On 15/02/25 8:25 PM, Greg KH wrote:
> On Sat, Feb 15, 2025 at 02:39:46PM +0100, Jürgen Groß wrote:
>> On 15.02.25 13:34, Greg KH wrote:
>>> On Sat, Feb 15, 2025 at 12:47:57PM +0100, Jürgen Groß wrote:
On 12.02.25 16:12, Harshit Mogalapalli wrote:
> Hi Salvatore,
>
> On 12/02/25 0
50 matches
Mail list logo
