Move the current logic to use the matrix keyword to generate a task for
each version of FreeBSD we want to build Xen on. The matrix keyword
however cannot be used in YAML aliases, so it needs to be explicitly used
inside of each task, which creates a bit of duplication. At least abstract
the Free
Even before its recent movement to the scheduler's private data
structure it looks to have been wrong to update the field under lock,
but then read it with the lock no longer held.
Coverity-ID: 1644500
Fixes: 9f0c658baedc ("arinc: add cpu-pool support to scheduler")
Signed-off-by: Jan Beulich
---
[Public]
Hi,
> -Original Message-
> From: Jan Beulich
> Sent: Monday, March 24, 2025 10:28 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andrew Cooper
> ; Roger Pau Monné ;
> Anthony PERARD ; Orzel, Michal
> ; Julien Grall ; Stefano Stabellini
> ; xen-devel@lists.xenproject.org
> Subject: Re
On 24.03.2025 16:29, Oleksii Kurochko wrote:
>
> On 3/20/25 8:36 AM, Jan Beulich wrote:
>> On 19.03.2025 18:29, Oleksii Kurochko wrote:
>>> On 3/17/25 4:24 PM, Jan Beulich wrote:
On 11.03.2025 17:19, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/time.c
> @@ -0,0 +
On the device-tree-based Arm64 system, if Xen is built with
CONFIG_ACPI=y, CONFIG_STATIC_MEMORY=y, and the static memory range
is provided in the host device tree, the BUG is triggered in
common/page_alloc.c during Xen's early boot. The BUG occurs when
the first page from the static range is fed to
> > with Xen dropping usage the variable is unneeded.
> > > > > > >
> > > > > > > This fixes using devices behind a VMD bridge on Xen PV hardware
> > > > > > > domains.
> > > > > > >
> > &
ble is unneeded.
> > > > > >
> > > > > > This fixes using devices behind a VMD bridge on Xen PV hardware
> > > > > > domains.
> > > > > >
> > > > > > Albeit Devices behind a VMD bridge are not known to Xen, th
behind a VMD bridge on Xen PV hardware
> > > > > domains.
> > > > >
> > > > > Albeit Devices behind a VMD bridge are not known to Xen, that doesn't
> > > > > mean
> > > > > Linux cannot use them. By inhibiting the usage of
On 14.03.25 01:48, Stefano Stabellini wrote:
On Tue, 11 Mar 2025, Grygorii Strashko wrote:
The commit 3e322bef8bc0 ("xen/arm: firmware: Add SCMI over SMC calls
handling layer") introduces simple driver which forwards SCMI over SMC
calls from hwdom/dom0 to EL3 firmware (TF-A) with a single SCM
On 24/03/2025 12:03 pm, Jan Beulich wrote:
> As per observation in practice, initrd->cmdline_pa is not normally zero.
> Hence so far we always appended at least one byte. That alone may
> already render insufficient the "allocation" made by find_memory().
> Things would be worse when there's actual
t; > > bodge devices behind a VMD bridge do work fine when use from a Linux Xen
> > > > hardware domain. That's the whole point of the series.
> > > >
> > > > Signed-off-by: Roger Pau Monné
> > > > Reviewed-by: Thomas Gleixner
From: Arnd Bergmann
Modules without a description now cause a warning:
WARNING: modpost: missing MODULE_DESCRIPTION() in
drivers/xen/xenbus/xenbus_probe_frontend.o
Signed-off-by: Arnd Bergmann
---
drivers/xen/xenbus/xenbus_probe_frontend.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/
On Monday, March 24th, 2025 at 6:51 AM, Andrew Cooper
wrote:
>
>
> On 20/03/2025 11:05 pm, dm...@proton.me wrote:
>
> > Add new macro APIC_VECTOR_VALID() to validate the interrupt vector
> > range as per [1]. This macro replaces hardcoded checks against the
> > open-coded value 16 in LAPIC an
On Monday, March 24th, 2025 at 5:36 AM, Jan Beulich wrote:
>
>
> On 21.03.2025 00:05, dm...@proton.me wrote:
>
> > Add new macro APIC_VECTOR_VALID() to validate the interrupt vector
> > range as per [1]. This macro replaces hardcoded checks against the
> > open-coded value 16 in LAPIC and virt
On 06.03.2025 09:39, Penny Zheng wrote:
> --- a/xen/drivers/cpufreq/cpufreq.c
> +++ b/xen/drivers/cpufreq/cpufreq.c
> @@ -353,7 +353,13 @@ int cpufreq_add_cpu(unsigned int cpu)
> if (hw_all || (cpumask_weight(cpufreq_dom->map) ==
> pmpt->domain_info.num_processors)) {
>
On 24/03/2025 16:22, Alejandro Vallejo wrote:
>
>
> On Mon Mar 24, 2025 at 1:08 PM GMT, Michal Orzel wrote:
>>
>>
>> On 19/03/2025 15:01, Alejandro Vallejo wrote:
>>>
>>> Doesn't this regenerate the golang bindings?
>> FYI, it does not. The bindings are already there for NrSpis and default
>>
Hi Anthony,
Thanks a lot for your comments.
On 14.03.25 18:23, Anthony PERARD wrote:
On Tue, Mar 11, 2025 at 01:16:14PM +0200, Grygorii Strashko wrote:
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 8e1422104e50..7edf272386e3 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/
On 06.03.2025 09:39, Penny Zheng wrote:
> XEN_PROCESSOR_PM_xxx are used to set xen_processor_pmbits only, which is
> a Xen-internal variable only. Although PV Dom0 passed these bits in si->flags,
> they haven't been used anywhere.
Please be careful with "not used anywhere". See e.g.
https://xenbit
On Mon Mar 24, 2025 at 1:08 PM GMT, Michal Orzel wrote:
>
>
> On 19/03/2025 15:01, Alejandro Vallejo wrote:
> >
> > Doesn't this regenerate the golang bindings?
> FYI, it does not. The bindings are already there for NrSpis and default value
> is
> does not result in a change (for verification I c
On 3/20/25 8:36 AM, Jan Beulich wrote:
On 19.03.2025 18:29, Oleksii Kurochko wrote:
On 3/17/25 4:24 PM, Jan Beulich wrote:
On 11.03.2025 17:19, Oleksii Kurochko wrote:
--- /dev/null
+++ b/xen/arch/riscv/time.c
@@ -0,0 +1,38 @@
+#include
+#include
+#include
+#include
+
+unsigned long __ro_
On 06.03.2025 09:39, Penny Zheng wrote:
> This commit fixes core frequency calculation for AMD Family 1Ah CPUs, due to
> a change in the PStateDef MSR layout in AMD Family 1Ah+.
> In AMD Family 1Ah+, Core current operating frequency in MHz is calculated as
> follows:
Why 1Ah+? In the code you corr
On 24/03/25 10:47, Jan Beulich wrote:
> Even before its recent movement to the scheduler's private data structure it
> looks
> to have been wrong to update the field under lock, but then read it with the
> lock
> no longer held.
>
> Coverity-ID: 1644500
> Fixes: 9f0c658baedc ("arinc: add cpu-poo
On 06.03.2025 09:39, Penny Zheng wrote:
> Bypass cnstruction and deconstruction for px statistic info(
> cpufreq_statistic_init and cpufreq_statistic_exit) in cpufreq
> CPPC mode.
You say what you do, but not why.
> --- a/xen/drivers/cpufreq/utility.c
> +++ b/xen/drivers/cpufreq/utility.c
> @@ -9
On 24.03.25 16:36, Jan Beulich wrote:
On 24.03.2025 15:25, Grygorii Strashko wrote:
On 11.03.25 13:43, Jan Beulich wrote:> On 11.03.2025 12:16, Grygorii Strashko
wrote:
@@ -851,6 +852,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
u_domctl)
case XEN_DOMCTL_deassign_device
hardware domain. That's the whole point of the series.
> > >
> > > Signed-off-by: Roger Pau Monné
> > > Reviewed-by: Thomas Gleixner
> > > Acked-by: Juergen Gross
> >
> > Acked-by: Bjorn Helgaas
> >
> > I assume you'll
Hi Stefano,
On 14.03.25 01:48, Stefano Stabellini wrote:
On Tue, 11 Mar 2025, Grygorii Strashko wrote:
The introduced SCI (System Control Interface) subsystem provides unified
interface to integrate in Xen SCI drivers which adds support for ARM
firmware (EL3, SCP) based software interfaces (lik
On 06.03.2025 09:39, Penny Zheng wrote:
> This commit includes the following modification:
> - Introduce helper function cpufreq_cmdline_parse_xen and
> cpufreq_cmdline_parse_hwp to tidy the different parsing path
> - Add helper cpufreq_opts_contain to ignore user redundant setting,
> like "cpufreq
Hi Stefano,
Thanks for your comments.
On 14.03.25 01:48, Stefano Stabellini wrote:
On Tue, 11 Mar 2025, Grygorii Strashko wrote:
From: Oleksii Moisieiev
This patch adds the basic framework for ARM SCI mediator. SCI is System
Control Interface, which is designed to redirect requests from the
On 24.03.2025 15:25, Grygorii Strashko wrote:
> On 11.03.25 13:43, Jan Beulich wrote:> On 11.03.2025 12:16, Grygorii Strashko
> wrote:
>>> @@ -851,6 +852,18 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
>>> u_domctl)
>>> case XEN_DOMCTL_deassign_device:
>>> case XEN_DOMCTL_ge
When VM to VM support is activated and there is no suitable FF-A support
in the firmware, enable FF-A support for VMs to allow using it for VM to
VM communications.
If there is OP-TEE running in the secure world and using the non FF-A
communication system, having CONFIG_FFA_VM_TO_VM could be non fu
On 06.03.2025 09:39, Penny Zheng wrote:
> In order to provide backward compatibility with existing governors
> that represent performance as frequencies, like ondemand, the _CPC
> table can optionally provide processor frequency range values, Lowest
> frequency and Norminal frequency, to let OS use
Hi Jan,
Thank you for your comments.
On 11.03.25 13:43, Jan Beulich wrote:> On 11.03.2025 12:16, Grygorii Strashko
wrote:
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -526,6 +526,12 @@ S: Supported
F:xen/arch/arm/include/asm/tee/
F:xen/arch/arm/tee/
+SCI MEDIATORS
+M: Oleksii Moi
On 06.03.2025 09:39, Penny Zheng wrote:
> --- a/xen/include/public/platform.h
> +++ b/xen/include/public/platform.h
> @@ -363,12 +363,12 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_getidletime_t);
> #define XEN_PM_PX 1
> #define XEN_PM_TX 2
> #define XEN_PM_PDC 3
> +#define XEN_PM_PSD 4
>
> /* Px
Add support for indirect messages between VMs.
This is only enabled if CONFIG_FFA_VM_TO_VM is selected.
Signed-off-by: Bertrand Marquis
---
Changes in v4:
- Use a local copy of the message header to prevent a TOC/TOU possible
issue when using the payload size
Changes in v3:
- Move vm to vm indi
Add a new command line parameter "tee=" to be used to explicitly select
what tee mediator is to be used by Xen and fail if it does not exist
or the probe function for it failed.
Without specifying which tee is to be used, Xen will use the first one
for which the probe function succeeds which depen
Hi,
> On 24 Mar 2025, at 14:53, Bertrand Marquis wrote:
>
> Create a CONFIG_FFA_VM_TO_VM parameter to activate FFA communication
> between VMs.
> When activated list VMs in the system with FF-A support in part_info_get.
>
> When VM to VM is activated, Xen will be tainted as Insecure and a
> mes
On 21.03.2025 10:26, Sergiy Kibrik wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -695,9 +695,12 @@ int hvm_domain_initialise(struct domain *d,
> if ( hvm_tsc_scaling_supported )
> d->arch.hvm.tsc_scaling_ratio = hvm_default_tsc_scaling_ratio;
>
> -rc
Add support to raise a Rx buffer full notification to a VM.
This function will be used for indirect message support between VM and
is only activated if CONFIG_FFA_VM_TO_VM is selected.
Even if there are 32 framework notifications possible, right now only
one is defined so the implementation is sim
Create a CONFIG_FFA_VM_TO_VM parameter to activate FFA communication
between VMs.
When activated list VMs in the system with FF-A support in part_info_get.
When VM to VM is activated, Xen will be tainted as Insecure and a
message is displayed to the user during the boot as there is no
filtering of
This patch serie adds support to use FF-A between VM for communications
using indirect messages.
It adds a Kconfig parameter to enable this feature and marks it as
experimental as for now there is no system to restrict communication
rights between VM using this system.
It also adds support to use
On 20/03/2025 11:05 pm, dm...@proton.me wrote:
> Add new macro APIC_VECTOR_VALID() to validate the interrupt vector
> range as per [1]. This macro replaces hardcoded checks against the
> open-coded value 16 in LAPIC and virtual LAPIC code and simplifies
> the code a bit.
>
> [1] Intel SDM volume 3A
On 24/03/2025 1:37 pm, Jan Beulich wrote:
> On 21.03.2025 10:26, Sergiy Kibrik wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -695,9 +695,12 @@ int hvm_domain_initialise(struct domain *d,
>> if ( hvm_tsc_scaling_supported )
>> d->arch.hvm.tsc_scaling_rati
On 2025-03-24 13:50, Jan Beulich wrote:
On 18.03.2025 03:34, Volodymyr Babchuk wrote:
Both GCC and Clang support -fstack-protector feature, which add stack
canaries to functions where stack corruption is possible. This patch
makes general preparations to enable this feature on different
supporte
On 21.03.2025 17:17, Oleksii Kurochko wrote:
> H provides additional instructions and CSRs that control the new stage of
> address translation and support hosting a guest OS in virtual S-mode
> (VS-mode).
>
> According to the Unprivileged Architecture (version 20240411) specification:
> ```
> Tabl
Hi Jan,
On 24/03/2025 12:05, Jan Beulich wrote:
> On 24.03.2025 10:00, Oleksii Moisieiev wrote:
>> Hi Jan,
>>
>> Let me answer one of your comment. Please see below:
>>
>> On 11/03/2025 13:43, Jan Beulich wrote:
>>> On 11.03.2025 12:16, Grygorii Strashko wrote:
--- a/MAINTAINERS
+++ b/MA
On 19/03/2025 15:01, Alejandro Vallejo wrote:
>
>
> On Tue Mar 18, 2025 at 9:00 AM GMT, Michal Orzel wrote:
>> We are missing a way to detect whether a user provided a value for
>> nr_spis equal to 0 or did not provide any value (default is also 0) which
>> can cause issues when calculated nr_
Hi Jens,
> On 24 Mar 2025, at 11:48, Jens Wiklander wrote:
>
> Hi Bertrand,
>
> On Mon, Mar 24, 2025 at 10:15 AM Bertrand Marquis
> wrote:
>>
>> When VM to VM support is activated and there is no suitable FF-A support
>> in the firmware, enable FF-A support for VMs to allow using it for VM to
Hi Jens,
> On 24 Mar 2025, at 11:41, Jens Wiklander wrote:
>
> Hi Bertrand,
>
> On Mon, Mar 24, 2025 at 10:15 AM Bertrand Marquis
> wrote:
>>
>> Add support for indirect messages between VMs.
>> This is only enabled if CONFIG_FFA_VM_TO_VM is selected.
>>
>> Signed-off-by: Bertrand Marquis
>
Hi Jens,
> On 24 Mar 2025, at 11:24, Jens Wiklander wrote:
>
> On Mon, Mar 24, 2025 at 10:15 AM Bertrand Marquis
> wrote:
>>
>> Create a CONFIG_FFA_VM_TO_VM parameter to activate FFA communication
>> between VMs.
>> When activated list VMs in the system with FF-A support in part_info_get.
>>
On 18.03.2025 03:34, Volodymyr Babchuk wrote:
> Both GCC and Clang support -fstack-protector feature, which add stack
> canaries to functions where stack corruption is possible. This patch
> makes general preparations to enable this feature on different
> supported architectures:
>
> - Added CONF
As per observation in practice, initrd->cmdline_pa is not normally zero.
Hence so far we always appended at least one byte. That alone may
already render insufficient the "allocation" made by find_memory().
Things would be worse when there's actually a (perhaps long) command
line.
Skip setup when
Create a CONFIG_FFA_VM_TO_VM parameter to activate FFA communication
between VMs.
When activated list VMs in the system with FF-A support in part_info_get.
When VM to VM is activated, Xen will be tainted as Insecure and a
message is displayed to the user during the boot as there is no
filtering of
On 21.03.2025 10:26, Sergiy Kibrik wrote:
> Add config option HVM_VIRIDIAN that covers viridian code within HVM.
> Calls to viridian functions guarded by is_viridian_domain() and related
> macros.
> Having this option may be beneficial by reducing code footprint for systems
> that are not using Hy
On 24.03.2025 12:18, Jürgen Groß wrote:
> On 24.03.25 11:30, Samuel Thibault wrote:
>> Jan Beulich, le lun. 24 mars 2025 11:21:48 +0100, a ecrit:
>>> On 23.03.2025 15:57, Jürgen Groß wrote:
On 23.03.25 01:01, Samuel Thibault wrote:
> Juergen Gross, le ven. 21 mars 2025 10:31:44 +0100, a ec
Hi Stefano,
On 21/03/2025 23:11, Stefano Stabellini wrote:
On Fri, 21 Mar 2025, Julien Grall wrote:
Hi Stefano,
On 21/03/2025 21:14, Stefano Stabellini wrote:
When booting from U-Boot bootefi, there can be a high number of
neighboring RAM banks. See for example:
(XEN) RAM: -
On 24.03.25 11:30, Samuel Thibault wrote:
Jan Beulich, le lun. 24 mars 2025 11:21:48 +0100, a ecrit:
On 23.03.2025 15:57, Jürgen Groß wrote:
On 23.03.25 01:01, Samuel Thibault wrote:
Juergen Gross, le ven. 21 mars 2025 10:31:44 +0100, a ecrit:
Add a file operations fstat hook to the 9pfs fron
On 24.03.2025 12:00, Mykola Kvach wrote:
> On Fri, Mar 21, 2025 at 4:04 PM Jan Beulich wrote:
>>
>> On 21.03.2025 10:50, Mykola Kvach wrote:
>>> On Thu, Mar 13, 2025 at 5:34 PM Jan Beulich wrote:
On 05.03.2025 10:11, Mykola Kvach wrote:
> +void watchdog_domain_resume(struct domain *d)
>>
Jan Beulich, le lun. 24 mars 2025 11:21:48 +0100, a ecrit:
> On 23.03.2025 15:57, Jürgen Groß wrote:
> > On 23.03.25 01:01, Samuel Thibault wrote:
> >> Juergen Gross, le ven. 21 mars 2025 10:31:44 +0100, a ecrit:
> >>> Add a file operations fstat hook to the 9pfs frontend.
> >>>
> >>> Signed-off-by
On Fri, Mar 21, 2025 at 4:04 PM Jan Beulich wrote:
>
> On 21.03.2025 10:50, Mykola Kvach wrote:
> > On Thu, Mar 13, 2025 at 5:34 PM Jan Beulich wrote:
> >> On 05.03.2025 10:11, Mykola Kvach wrote:
> >>> +void watchdog_domain_resume(struct domain *d)
> >>> +{
> >>> +unsigned int i;
> >>> +
> >
Hi Bertrand,
On Mon, Mar 24, 2025 at 10:15 AM Bertrand Marquis
wrote:
>
> When VM to VM support is activated and there is no suitable FF-A support
> in the firmware, enable FF-A support for VMs to allow using it for VM to
> VM communications.
> If there is OP-TEE running in the secure world and u
Hi Bertrand,
On Mon, Mar 24, 2025 at 10:15 AM Bertrand Marquis
wrote:
>
> Add support for indirect messages between VMs.
> This is only enabled if CONFIG_FFA_VM_TO_VM is selected.
>
> Signed-off-by: Bertrand Marquis
> ---
> Changes in v3:
> - Move vm to vm indirect message handling in a sub func
Hi Bertrand,
On Mon, Mar 24, 2025 at 10:15 AM Bertrand Marquis
wrote:
>
> Add support to raise a Rx buffer full notification to a VM.
> This function will be used for indirect message support between VM and
> is only activated if CONFIG_FFA_VM_TO_VM is selected.
>
> Even if there are 32 framework
On Mon, Mar 24, 2025 at 10:15 AM Bertrand Marquis
wrote:
>
> Create a CONFIG_FFA_VM_TO_VM parameter to activate FFA communication
> between VMs.
> When activated list VMs in the system with FF-A support in part_info_get.
>
> When VM to VM is activated, Xen will be tainted as Insecure and a
> messa
HI,
On Fri, Mar 21, 2025 at 4:58 PM Grygorii Strashko
wrote:
>
>
>
> On 21.03.25 11:48, Mykola Kvach wrote:
> > Hi,
> >
> > On Wed, Mar 12, 2025 at 12:29 AM Julien Grall wrote:
> >>
> >> Hi,
> >>
> >> On 05/03/2025 09:11, Mykola Kvach wrote:
> >>> From: Mykola Kvach
> >>>
> >>> This option enab
On 24.03.2025 07:11, Penny, Zheng wrote:
> [Public]
>
> Hi,
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Friday, March 14, 2025 5:27 PM
>> To: Penny, Zheng
>> Cc: Huang, Ray ; Stabellini, Stefano
>> ; Andrew Cooper ;
>> Anthony PERARD ; Orzel, Michal
>> ; Julien Grall ; Roger P
On 21.03.2025 17:01, Andrew Cooper wrote:
> On 17/03/2025 11:38 am, Jan Beulich wrote:
>> On 11.03.2025 22:10, Andrew Cooper wrote:
>>> In order to support FRED, we're going to have to remove the {ds..gs} fields
>>> from struct cpu_user_regs, meaning that it is going to have to become a
>>> differe
On 24.03.2025 08:59, Penny, Zheng wrote:
> [Public]
>
> Hi,
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Friday, March 14, 2025 12:33 AM
>> To: Penny, Zheng
>> Cc: Huang, Ray ; Stefano Stabellini
>> ; Julien Grall ; Bertrand Marquis
>> ; Orzel, Michal ;
>> Volodymyr Babchuk ; A
On 21.03.2025 16:11, Andrew Cooper wrote:
> On 17/03/2025 12:15 pm, Jan Beulich wrote:
>> On 11.03.2025 22:10, Andrew Cooper wrote:
>>> In order to support FRED, we're going to have to remove the {ds..gs} fields
>>> from struct cpu_user_regs, meaning that it is going to have to become a
>>> differe
On 21.03.2025 18:13, Andrew Cooper wrote:
> On 17/03/2025 11:42 am, Jan Beulich wrote:
>> On 11.03.2025 22:10, Andrew Cooper wrote:
>>> --- a/xen/include/xlat.lst
>>> +++ b/xen/include/xlat.lst
>>> @@ -34,8 +34,6 @@
>>> ? pmu_intel_ctxt arch-x86/pmu.h
>>> ? pmu_regs
On 21.03.2025 22:30, Stefano Stabellini wrote:
> On Thu, 20 Mar 2025, Jan Beulich wrote:
>> On 19.03.2025 00:40, Stefano Stabellini wrote:
>>> Evtchn fifos are not needed on smaller systems; the older interface is
>>> lightweight and sufficient. Make it possible to disable evtchn fifo.
>>>
>>> Sign
On 22.03.2025 00:09, Stefano Stabellini wrote:
> On Thu, 20 Mar 2025, Jan Beulich wrote:
>> On 20.03.2025 01:57, Stefano Stabellini wrote:
>>> On Wed, 19 Mar 2025, Jan Beulich wrote:
What about xenctl_bitmap_to_bitmap()?
>>>
>>> Let me see first if I managed to handle bitmap_to_xenctl_bitmap
On 21.03.2025 16:53, Jürgen Groß wrote:
> On 21.03.25 14:51, Jan Beulich wrote:
>> On 21.03.2025 10:24, Juergen Gross wrote:
>>> +/* e_type */
>>> +#define ET_NONE 0 /* No file type */
>>> +#define ET_REL 1 /* relocatable file */
>>> +#define ET_EXEC 2
This patch serie adds support to use FF-A between VM for communications
using indirect messages.
It adds a Kconfig parameter to enable this feature and marks it as
experimental as for now there is no system to restrict communication
rights between VM using this system.
It also adds support to use
Add support to raise a Rx buffer full notification to a VM.
This function will be used for indirect message support between VM and
is only activated if CONFIG_FFA_VM_TO_VM is selected.
Even if there are 32 framework notifications possible, right now only
one is defined so the implementation is sim
When VM to VM support is activated and there is no suitable FF-A support
in the firmware, enable FF-A support for VMs to allow using it for VM to
VM communications.
If there is OP-TEE running in the secure world and using the non FF-A
communication system, having CONFIG_FFA_VM_TO_VM could be non fu
Add support for indirect messages between VMs.
This is only enabled if CONFIG_FFA_VM_TO_VM is selected.
Signed-off-by: Bertrand Marquis
---
Changes in v3:
- Move vm to vm indirect message handling in a sub function to simplify
lock handling and make implementation easier to read
Changes in v2:
Add a new command line parameter "tee=" to be used to explicitly select
what tee mediator is to be used by Xen and fail if it does not exist
or the probe function for it failed.
Without specifying which tee is to be used, Xen will use the first one
for which the probe function succeeds which depen
Hi Jan,
Let me answer one of your comment. Please see below:
On 11/03/2025 13:43, Jan Beulich wrote:
> On 11.03.2025 12:16, Grygorii Strashko wrote:
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -526,6 +526,12 @@ S: Supported
>> F: xen/arch/arm/include/asm/tee/
[snip]
>> --- a/xen/includ
On 20/03/2025 17:46, Anthony PERARD wrote:
>
>
> On Tue, Mar 18, 2025 at 10:00:13AM +0100, Michal Orzel wrote:
>> We are missing a way to detect whether a user provided a value for
>> nr_spis equal to 0 or did not provide any value (default is also 0) which
>> can cause issues when calculated
[Public]
Hi,
> -Original Message-
> From: Jan Beulich
> Sent: Friday, March 14, 2025 12:33 AM
> To: Penny, Zheng
> Cc: Huang, Ray ; Stefano Stabellini
> ; Julien Grall ; Bertrand Marquis
> ; Orzel, Michal ;
> Volodymyr Babchuk ; Andrew Cooper
> ; Anthony PERARD ;
> Roger Pau Monné ; Ali
80 matches
Mail list logo
