On 19.05.2025 23:34, Stefano Stabellini wrote:
> On Mon, 19 May 2025, Jan Beulich wrote:
>> On 19.05.2025 15:52, Andrew Cooper wrote:
>>> Signed-off-by: Andrew Cooper
>>
>> Is this to please Misra in some way?
>>
>>> --- a/xen/include/xen/compile.h.in
>>> +++ b/xen/include/xen/compile.h.in
>>> @@
On 19.05.2025 21:23, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Currently, hypervisor code has two different non-system domain ID allocation
> implementations:
>
> (a) Sequential IDs allocation in dom0less Arm code based on max_init_domid;
>
> (b) Sequential IDs allocation in XEN_DOMCT
On 19.05.2025 22:12, dm...@proton.me wrote:
> From: Denis Mukhin
>
> The physical console input rotation depends on max_init_domid symbol, which is
> managed differently across architectures.
>
> Instead of trying to manage max_init_domid in the arch-common code the console
> input rotation code
On 19.05.2025 21:23, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Embedded deployments of Xen do not need to have support for more than dozen of
> domains.
>
> Introduce build-time configuration option to limit the number of domains
> during
> run-time.
I fear I don't see the (sufficiently
On 19.05.2025 22:12, dm...@proton.me wrote:
> --- a/xen/arch/arm/vpl011.c
> +++ b/xen/arch/arm/vpl011.c
> @@ -78,12 +78,11 @@ static void vpl011_write_data_xen(struct domain *d,
> uint8_t data)
> unsigned long flags;
> struct vpl011 *vpl011 = &d->arch.vpl011;
> struct vpl011_xen_bac
On 19.05.2025 21:23, dm...@proton.me wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -2424,6 +2424,9 @@ domid_t domid_alloc(domid_t domid)
> }
> else
> {
> +domid_t reserved;
> +
> +reserved = __test_and_set_bit(get_initial_domain_id(), domid_bitma
On 19.05.2025 22:12, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Update the function name as per naming notation in the console driver.
>
> No functional change.
>
> Signed-off-by: Denis Mukhin
Acked-by: Jan Beulich
On 09.05.2025 11:05, Jiqian Chen wrote:
> When init_msi() fails, the previous new changes will hide MSI
> capability, it can't rely on vpci_deassign_device() to remove
> all MSI related resources anymore, those resources must be
> removed in cleanup function of MSI.
That's because vpci_deassign_de
On 2025/5/19 14:56, Jan Beulich wrote:
> On 19.05.2025 08:43, Chen, Jiqian wrote:
>> On 2025/5/18 22:20, Jan Beulich wrote:
>>> On 09.05.2025 11:05, Jiqian Chen wrote:
@@ -827,6 +827,34 @@ static int vpci_init_capability_list(struct pci_dev
*pdev)
On 2025/5/18 22:47, Jan Beulich wrote:
> On 09.05.2025 11:05, Jiqian Chen wrote:
>> --- a/xen/include/xen/pci_regs.h
>> +++ b/xen/include/xen/pci_regs.h
>> @@ -448,7 +448,10 @@
>> /* Extended Capabilities (PCI-X 2.0 and Express) */
>> #define PCI_EXT_CAP_ID(header) ((header) & 0x
On 2025/5/19 14:30, Jan Beulich wrote:
> On 09.05.2025 11:05, Jiqian Chen wrote:
>> vpci_remove_register() only supports removing a register in a time,
>> but the follow-on changes need to remove all registers within a range.
>> So, refactor it to support removing all matched registers in a calling
On 5/16/25 11:45 AM, Roger Pau Monne wrote:
The current underlying implementation of GNTTABOP_cache_flush on x86 won't
work as expected. The provided {clean,invalidate}_dcache_va_range()
helpers only do a local pCPU cache flush, so the cache of previous pCPUs
where the vCPU might have run are n
On 09.05.2025 11:05, Jiqian Chen wrote:
> vpci_remove_register() only supports removing a register in a time,
> but the follow-on changes need to remove all registers within a range.
> So, refactor it to support removing all matched registers in a calling
> time.
Generally I'm a little wary of cha
On 2025/5/19 14:54, Jan Beulich wrote:
> On 09.05.2025 11:05, Jiqian Chen wrote:
>> --- a/xen/drivers/vpci/rebar.c
>> +++ b/xen/drivers/vpci/rebar.c
>> @@ -49,6 +49,26 @@ static void cf_check rebar_ctrl_write(const struct
>> pci_dev *pdev,
>> bar->guest_addr = bar->addr;
>> }
>>
>> +static
On 2025/5/18 22:44, Jan Beulich wrote:
> On 09.05.2025 11:05, Jiqian Chen wrote:
>> @@ -83,6 +99,100 @@ static int assign_virtual_sbdf(struct pci_dev *pdev)
>>
>> #endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */
>>
>> +static struct vpci_register *vpci_get_register(struct vpci *vpci,
>> +
On Mon, May 19, 2025 at 07:35:49AM +, Chen, Jiqian wrote:
> On 2025/5/18 22:44, Jan Beulich wrote:
> > On 09.05.2025 11:05, Jiqian Chen wrote:
> >> +static int vpci_capability_mask(struct pci_dev *pdev, unsigned int cap)
> >
> > What's the word "mask" indicating here? The function doesn't retu
On Sun, May 18, 2025 at 01:38:02PM +0200, Jan Beulich wrote:
> On 16.05.2025 11:45, Roger Pau Monne wrote:
> > Avoid the cache flush if the domain is not yet running. There shouldn't be
> > any cached data resulting from domain accesses that need flushing, as the
> > domain hasn't run yet.
>
> Th
On Mon, May 19, 2025 at 08:30:22AM +0200, Jan Beulich wrote:
> On 09.05.2025 11:05, Jiqian Chen wrote:
> > vpci_remove_register() only supports removing a register in a time,
> > but the follow-on changes need to remove all registers within a range.
> > So, refactor it to support removing all match
On Sun, May 18, 2025 at 01:44:49PM +0200, Jan Beulich wrote:
> On 16.05.2025 11:45, Roger Pau Monne wrote:
> > The current cache flushing done in memory_type_changed() is too wide, and
> > this doesn't scale on boxes with high number of CPUs. Attempt to limit
> > cache flushes as a result of p2m t
On 5/15/25 10:06 AM, Jan Beulich wrote:
On 06.05.2025 18:51, Oleksii Kurochko wrote:
--- a/xen/arch/riscv/include/asm/intc.h
+++ b/xen/arch/riscv/include/asm/intc.h
@@ -8,6 +8,8 @@
#ifndef ASM__RISCV__INTERRUPT_CONTOLLER_H
#define ASM__RISCV__INTERRUPT_CONTOLLER_H
+#include
If you need
On Tue, Apr 29, 2025 at 01:06:31PM +0200, Juergen Gross wrote:
> In preparation to no longer support qemu-traditional (including
> qemu-stubdom), remove it from documentation.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Anthony PERARD
Thanks,
--
Anthony PERARD
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, April 29, 2025 8:52 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andrew Cooper
> ; Anthony PERARD ;
> Orzel, Michal ; Julien Grall ; Roger Pau
> Monné ; Stefano Stabellini ;
> xen-
> de...@lists.xenproject.org
> Subject: Re:
On 19.05.2025 08:56, Chen, Jiqian wrote:
> On 2025/5/18 22:34, Jan Beulich wrote:
>> On 09.05.2025 11:05, Jiqian Chen wrote:
>>> --- a/xen/drivers/vpci/msi.c
>>> +++ b/xen/drivers/vpci/msi.c
>>> @@ -270,7 +270,7 @@ static int cf_check init_msi(struct pci_dev *pdev)
>>>
>>> return 0;
>>> }
>
On 19.05.2025 09:13, Chen, Jiqian wrote:
> On 2025/5/19 14:56, Jan Beulich wrote:
>> On 19.05.2025 08:43, Chen, Jiqian wrote:
>>> On 2025/5/18 22:20, Jan Beulich wrote:
On 09.05.2025 11:05, Jiqian Chen wrote:
> @@ -827,6 +827,34 @@ static int vpci_init_capability_list(struct pci_dev
>
On 19.05.2025 09:41, Chen, Jiqian wrote:
> On 2025/5/18 22:47, Jan Beulich wrote:
>> On 09.05.2025 11:05, Jiqian Chen wrote:
>>> --- a/xen/include/xen/pci_regs.h
>>> +++ b/xen/include/xen/pci_regs.h
>>> @@ -448,7 +448,10 @@
>>> /* Extended Capabilities (PCI-X 2.0 and Express) */
>>> #define PCI_E
On 19.05.2025 11:16, Oleksii Kurochko wrote:
>
> On 5/15/25 10:06 AM, Jan Beulich wrote:
>> On 06.05.2025 18:51, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/include/asm/intc.h
>>> +++ b/xen/arch/riscv/include/asm/intc.h
>>> @@ -8,6 +8,8 @@
>>> #ifndef ASM__RISCV__INTERRUPT_CONTOLLER_H
>>>
On 19.05.2025 10:36, Penny, Zheng wrote:
> [Public]
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Tuesday, April 29, 2025 8:52 PM
>> To: Penny, Zheng
>> Cc: Huang, Ray ; Andrew Cooper
>> ; Anthony PERARD ;
>> Orzel, Michal ; Julien Grall ; Roger
>> Pau
>> Monné ; Stefano Stabell
On 19.05.2025 13:08, Roger Pau Monné wrote:
> On Sun, May 18, 2025 at 01:44:49PM +0200, Jan Beulich wrote:
>> On 16.05.2025 11:45, Roger Pau Monne wrote:
>>> Not sure whether this attempt to reduce cache flushing should get some
>>> mention in the CHANGELOG.
>>
>> Err on the side of adding an entry
On Tue, Apr 29, 2025 at 01:06:32PM +0200, Juergen Gross wrote:
> diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
> index 34f6753f61..227b5ceafb 100644
> --- a/tools/libacpi/mk_dsdt.c
> +++ b/tools/libacpi/mk_dsdt.c
> @@ -105,7 +81,7 @@ int main(int argc, char **argv)
> {
> unsi
On 19.05.25 15:30, Anthony PERARD wrote:
On Tue, Apr 29, 2025 at 01:06:32PM +0200, Juergen Gross wrote:
diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index 34f6753f61..227b5ceafb 100644
--- a/tools/libacpi/mk_dsdt.c
+++ b/tools/libacpi/mk_dsdt.c
@@ -105,7 +81,7 @@ int main(int a
On Sun, May 18, 2025 at 07:31:49PM -0400, Rich Persaud wrote:
> If there's no stable URL for the TXT spec, can we mirror the relevant
> doc(s) somewhere in the Xen docs tree? A trusted archive of the spec
> for trusted execution.
>
> Rich
By "unversioned link to Software Development Guide" I meant
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
---
xen/include/xen/compile.h.in | 3 +++
xen/tools/process-banner.sed | 5 +
2 files changed, 8 insertions(+)
diff --git a/xen/include/xen/c
On Tue, Apr 29, 2025 at 01:06:33PM +0200, Juergen Gross wrote:
> Remove qemu traditional from the tree.
>
> Signed-off-by: Juergen Gross
> Acked-by: Oleksii Kurochko # CHANGELOG.md
Reviewed-by: Anthony PERARD
Thanks,
--
Anthony PERARD
On Tue, Apr 29, 2025 at 01:06:34PM +0200, Juergen Gross wrote:
> With the drop of qemu-traditional "make stubdom" no longer requires
> "make tools" to have finished.
>
> It is enough to add "install-tools-public-headers" as a prereq of
> "install-stubdom".
>
> Signed-off-by: Juergen Gross
Acked
Rules 5.3, 11.2 and 16.6 are already listed in clean_guidelines_common and
apply to all architectures. There's no need for arm64 to give them a second
time.
Signed-off-by: Andrew Cooper
---
CC: Stefano Stabellini
CC: consult...@bugseng.com
CC: Nicola Vetrini
I've left the x86/arm split as-be
On Mon, May 19, 2025 at 03:10:17PM +0200, Jan Beulich wrote:
> On 19.05.2025 09:13, Chen, Jiqian wrote:
> > On 2025/5/19 14:56, Jan Beulich wrote:
> >> On 19.05.2025 08:43, Chen, Jiqian wrote:
> >>> On 2025/5/18 22:20, Jan Beulich wrote:
> On 09.05.2025 11:05, Jiqian Chen wrote:
> > @@ -82
Hi,
On 17/05/25 01:57, Andrew Cooper wrote:
+-config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated file, do not
edit! \\*/$, begin-2))"}
-config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated file, do not
edit! \\*/$, begin-3))"}
These seem to only differ by
On Mon, May 19, 2025 at 03:22:32PM +0200, Jan Beulich wrote:
> On 19.05.2025 13:08, Roger Pau Monné wrote:
> > On Sun, May 18, 2025 at 01:44:49PM +0200, Jan Beulich wrote:
> >> On 16.05.2025 11:45, Roger Pau Monne wrote:
> >>> Not sure whether this attempt to reduce cache flushing should get some
>
On 5/15/25 10:42 AM, Jan Beulich wrote:
On 06.05.2025 18:51, Oleksii Kurochko wrote:
imsic_init() is introduced to parse device tree node, which has the following
bindings [2], and based on the parsed information update IMSIC configuration
which is stored in imsic_cfg.
The following helpers ar
On 2025-05-19 16:07, Andrew Cooper wrote:
Rules 5.3, 11.2 and 16.6 are already listed in clean_guidelines_common
and
apply to all architectures. There's no need for arm64 to give them a
second
time.
Thanks.
Signed-off-by: Andrew Cooper
Reviewed-by: Nicola Vetrini
---
CC: Stefano Stab
From: Grygorii Strashko
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 SCMI OSPM agent
support. While it is working gracefully for hwdom/dom0 use
Inroducing V4 RFC patch series on top of the Xen version 4.20-rc2
which includes implementation of the SCI SCMI SMC multi-agent support.
Patch 1 "xen/arm: add generic SCI subsystem"
- rebased and refactored
- introduced DEVICE_ARM_SCI DT device class and used for SCI drivers probing
instead of cu
This patch introduces SCI driver to support for ARM EL3 Trusted Firmware-A
(TF-A) which provides SCMI interface with multi-agnet support, as shown
below.
+-+
| |
| EL3 TF-A SCMI |
+---
From: Grygorii Strashko
Add documentation section for Simple Arm SCMI over SMC/HVC calls forwarding
driver (EL3).
Signed-off-by: Grygorii Strashko
Signed-off-by: Oleksii Moisieiev
---
.../arm/firmware/arm-scmi.rst | 177 ++
docs/hypervisor-guide/arm/index.rs
From: Grygorii Strashko
Proposal description to add separate SCMI DT node for Xen management agent
under "chosen" or xen-config node, like Hyperlaunch "xen,config".
This proposal introduces a new approach to the Xen multi-domain
configuration, where all Xen-specific configuration has been moved
From: Grygorii Strashko
Add chained handling of assigned DT devices to support access-controller
functionality through SCI framework, so DT device assign request can be
passed to FW for processing and enabling VM access to requested device
(for example, device power management through FW interfac
From: Grygorii Strashko
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 (like SCMI) that are used in
system management. The SCI subsystem allows to add drive
From: Grygorii Strashko
Add SCI SCMI SMC multi-agent driver documentation.
It includes a detailed description of the SCMI multi-agent driver.
This document explains the driver's functionality, configuration,
and the compilation process. The Xen SCMI multi-agent driver is
designed to provide SCMI
This patch adds the basic framework for ARM SCI mediator. SCI is System
Control Interface, which is designed to redirect requests from the Domains
to ARM specific Firmware (for example SCMI). This will allow the devices,
passed-through to the different Domains, to access to the System resources
(su
On 5/15/25 11:06 AM, Jan Beulich wrote:
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -9,19 +9,121 @@
* Copyright (c) 2024-2025 Vates
*/
+#include
#include
#include
#include
+#include
#include
#include
+#include
+
+#include "aplic-priv.h"
Besides this,
On 2025/5/18 22:20, Jan Beulich wrote:
> On 09.05.2025 11:05, Jiqian Chen wrote:
>> @@ -827,6 +827,34 @@ static int vpci_init_capability_list(struct pci_dev
>> *pdev)
>> PCI_STATUS_RSVDZ_MASK);
>> }
>>
>> +static int vpci_init_ext_capability_lis
Hello,
Le 06/05/2025 à 18:53, Oleksii Kurochko a écrit :
> Introduce ioremap_attr() as a shared helper to implement architecture-specific
> +#include
>
> #include
> #include
> @@ -583,3 +584,36 @@ void *__init arch_vmap_virt_end(void)
> {
> return (void *)(VMAP_VIRT_START + VMAP_VIR
On 5/12/2025 1:45 AM, Xin Li (Intel) wrote:
Convert a native_wrmsr() use to native_wrmsrq() to zap meaningless type
conversions when a u64 MSR value is splitted into two u32.
Signed-off-by: Xin Li (Intel)
---
arch/x86/coco/sev/core.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-
On 19.05.2025 16:33, Roger Pau Monné wrote:
> On Mon, May 19, 2025 at 03:22:32PM +0200, Jan Beulich wrote:
>> On 19.05.2025 13:08, Roger Pau Monné wrote:
>>> On Sun, May 18, 2025 at 01:44:49PM +0200, Jan Beulich wrote:
On 16.05.2025 11:45, Roger Pau Monne wrote:
> Not sure whether this att
On 19.05.2025 17:19, Oleksii Kurochko wrote:
> On 5/15/25 10:42 AM, Jan Beulich wrote:
>> On 06.05.2025 18:51, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/riscv/include/asm/imsic.h
>>> @@ -0,0 +1,65 @@
>>> +/* SPDX-License-Identifier: MIT */
>>> +
>>> +/*
>>> + * xen/arch/riscv/ims
On 19.05.2025 17:26, Oleksii Kurochko wrote:
> On 5/15/25 10:42 AM, Jan Beulich wrote:
>>> + node->name, imsic_cfg.msi[cpuid].base_addr + reloff);
>>> +imsic_cfg.msi[cpuid].offset = 0;
>>> +imsic_cfg.msi[cpuid].base_addr = 0;
>>> +continue;
>>>
On 19.05.2025 18:09, Oleksii Kurochko wrote:
> On 5/15/25 11:06 AM, Jan Beulich wrote:
>>> +/* Set interrupt type and default priority for all interrupts */
>>> +for ( i = 1; i <= aplic_info.num_irqs; i++ )
>>> +{
>>> +writel(0, &aplic.regs->sourcecfg[i - 1]);
>> What guarantees
On 19.05.2025 17:50, Oleksii Moisieiev wrote:
> --- a/xen/arch/arm/firmware/sci.c
> +++ b/xen/arch/arm/firmware/sci.c
> @@ -126,6 +126,43 @@ int sci_assign_dt_device(struct domain *d, struct
> dt_device_node *dev)
> return 0;
> }
>
> +int sci_do_domctl(struct xen_domctl *domctl, struct dom
On 19.05.2025 15:52, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
Is this to please Misra in some way?
> --- a/xen/include/xen/compile.h.in
> +++ b/xen/include/xen/compile.h.in
> @@ -1,3 +1,6 @@
> +#ifndef XEN_COMPILE_H
> +#define XEN_COMPILE_H
> +
> #define XEN_COMPILE_DATE "@@date@
On 2025-05-19 21:10, Jan Beulich wrote:
On 19.05.2025 15:52, Andrew Cooper wrote:
Signed-off-by: Andrew Cooper
Is this to please Misra in some way?
Directive 4.10: "Precautions shall be taken in order to prevent the
contents of a header file being included more than once". One approach
i
The patch series adds new library calls for allocating domain IDs.
Patch 1 introduces new domid_{alloc,free} calls.
Patch 2 adjusts hardware domain ID treatment on Arm.
Patch 3 introduces new CONFIG_MAX_DOMID parameter to limit the number of
domains during run-time.
Link to v6:
https://lore.kern
From: Denis Mukhin
Remove the hardcoded domain ID 0 allocation for hardware domain and replace it
with a call to get_initial_domain_id() (returns the value of hardware_domid on
Arm).
Update domid_alloc(DOMID_INVALID) case to ensure that get_initial_domain_id()
ID is skipped during domain ID allo
From: Denis Mukhin
Currently, hypervisor code has two different non-system domain ID allocation
implementations:
(a) Sequential IDs allocation in dom0less Arm code based on max_init_domid;
(b) Sequential IDs allocation in XEN_DOMCTL_createdomain; does not use
max_init_domid (both Arm
From: Denis Mukhin
Embedded deployments of Xen do not need to have support for more than dozen of
domains.
Introduce build-time configuration option to limit the number of domains during
run-time.
Suggested-by: Julien Grall
Signed-off-by: Denis Mukhin
---
Changes since v6:
- new patch
---
xe
On Sun, May 18, 2025 at 10:57:44AM +0200, Jan Beulich wrote:
> On 16.05.2025 04:04, dm...@proton.me wrote:
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -85,7 +85,7 @@ void __init domid_init(void)
> > *
> > * If hint is outside of valid [0..DOMID_FIRST_RESERVED - 1] range o
On Sun, May 18, 2025 at 10:52:24AM +0200, Jan Beulich wrote:
> On 16.05.2025 04:04, dm...@proton.me wrote:
> > From: Denis Mukhin
> >
> > Currently, hypervisor code has two different non-system domain ID allocation
> > implementations:
> >
> > (a) Sequential IDs allocation in dom0less Arm code b
From: Denis Mukhin
Introduce conring_flush() to ensure all messages kept in the internal
console ring are sent to all physical consoles (serial, VGA (x86))
after their initialization is completed.
Rename dump_console_ring_key to conring_dump_keyhandler to match the
notation for conring managemen
From: Denis Mukhin
Move conring tasklet code close to conring definitions in the console driver
and rename conring tasklet variables by adding conring_ prefix for better
readability.
No functional change.
Signed-off-by: Denis Mukhin
Reviewed-by: Stefano Stabellini
---
Changes since v4:
- adde
xen/console: few cleanups in console driver
The patch series introduces a few cleanups aimed at reducing code duplication
in the console driver and improving readability.
Originally, patches 2 and 3 were part of NS16550 emulator v3 series [1].
Patch 1 performs a cleanup in conring console.
Patc
From: Denis Mukhin
guest_console_write() duplicates the code from __putstr(), eliminate code
duplication.
Introduce console_send() for sending a message on console devices.
Also, introduce internal console flags to control which console devices
should be used.
No functional change intended.
S
From: Denis Mukhin
Update the function name as per naming notation in the console driver.
No functional change.
Signed-off-by: Denis Mukhin
---
Changes since v2:
- rebased
- Link to v2:
https://lore.kernel.org/xen-devel/20250331230508.440198-5-dmuk...@ford.com/
---
xen/drivers/char/console.c
From: Denis Mukhin
Add new flag to domain structure for marking permission to intercept
the physical console input by the domain.
Update console input switch logic accordingly.
No functional change intended.
Signed-off-by: Denis Mukhin
---
Changes since v2:
- rebased
- Link to v2:
https://lo
From: Denis Mukhin
The physical console input rotation depends on max_init_domid symbol, which is
managed differently across architectures.
Instead of trying to manage max_init_domid in the arch-common code the console
input rotation code can be reworked by removing dependency on max_init_domid
From: Denis Mukhin
Update the symbol name to match the code better.
No functional change.
Signed-off-by: Denis Mukhin
---
Changes since v2:
- new patch
---
xen/drivers/char/console.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/xen/drivers/char/console.c
The patch series originates from the NS16550 UART emulator series [1] (x86)
which requires ability to switch physical console input to a PVH/HVM domain
with an emulated UART.
Currently, on x86, console input can be rotated in round-robin manner only
between dom0, PV shim, and Xen itself. On Arm th
From: Denis Mukhin
Add console_get_domid() to the console driver to retrieve the current console
owner domain ID.
Use the function in vpl011 emulator which leads to simpler code.
Make console_{get,put}_domain() private to the console driver.
No functional change intended.
Signed-off-by: Denis
On May 19, 2025, at 9:43 AM, Sergii Dmytruk wrote:
>
> On Sun, May 18, 2025 at 07:31:49PM -0400, Rich Persaud wrote:
>> If there's no stable URL for the TXT spec, can we mirror the relevant
>> doc(s) somewhere in the Xen docs tree? A trusted archive of the spec
>> for trusted execution.
>>
>> R
On Mon, 19 May 2025, Jan Beulich wrote:
> On 19.05.2025 15:52, Andrew Cooper wrote:
> > Signed-off-by: Andrew Cooper
>
> Is this to please Misra in some way?
>
> > --- a/xen/include/xen/compile.h.in
> > +++ b/xen/include/xen/compile.h.in
> > @@ -1,3 +1,6 @@
> > +#ifndef XEN_COMPILE_H
> > +#defin
On Mon, 19 May 2025, Federico Serafini wrote:
> Hi,
>
> On 17/05/25 01:57, Andrew Cooper wrote:
> >
> > > +-config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated
> > > file, do not edit! \\*/$, begin-2))"}
> > > -config=MC3A2.D4.10,reports+={safe, "first_area(text(^/\\* Generated
On Mon, 19 May 2025, Nicola Vetrini wrote:
> On 2025-05-19 16:07, Andrew Cooper wrote:
> > Rules 5.3, 11.2 and 16.6 are already listed in clean_guidelines_common and
> > apply to all architectures. There's no need for arm64 to give them a second
> > time.
> >
>
> Thanks.
>
> > Signed-off-by: An
Hi Stefano,
On 17/05/2025 00:21, Stefano Stabellini wrote:
From: Federico Serafini
MISRA C Directive 4.10 states that:
"Precautions shall be taken in order to prevent the contents of a
header file being included more than once".
Add inclusion guards where missing to address violations of the
On Mon, 19 May 2025, dm...@proton.me wrote:
> From: Denis Mukhin
>
> guest_console_write() duplicates the code from __putstr(), eliminate code
> duplication.
>
> Introduce console_send() for sending a message on console devices.
>
> Also, introduce internal console flags to control which consol
On Mon, 19 May 2025, Oleksii Moisieiev wrote:
> From: Grygorii Strashko
>
> 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 (like SCMI) that are used in
On Mon, 19 May 2025, Oleksii Moisieiev wrote:
> This patch adds the basic framework for ARM SCI mediator. SCI is System
> Control Interface, which is designed to redirect requests from the Domains
> to ARM specific Firmware (for example SCMI). This will allow the devices,
> passed-through to the di
On Mon, 19 May 2025, Oleksii Moisieiev wrote:
> From: Grygorii Strashko
>
> 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 SCMI OSPM agent
>
85 matches
Mail list logo
