n/domU1/evtchn@11 compatible "xen,evtchn-v1"
fdt set /chosen/domU1/evtchn@11 xen,evtchn <11 0xfffe>
fdt mknod /chosen/domU1 evtchn@13
fdt set /chosen/domU1/evtchn@13 phandle <0xfffb>
fdt set /chosen/domU1/evtchn@13 compatible "xen,evtchn-v1"
fdt set /chosen/domU1/e
OGRESS(sci):
> -ret = sci_relinquish_resources(d);
> - if ( ret )
> -return ret;
>
> PROGRESS(p2m_root):
> /*
> --
> 2.34.1
>
>
--
Regards,
Oleksandr Tyshchenko
Komarianskyi
Reviewed-by: Oleksandr Tyshchenko
Initially I was slightly worried about ...
---
Changes in V7:
- fixed the condition in the is_espi assert for non-eSPI builds: the
previous condition was mistakenly added with a wrong check and led to
triggering asserts for all non-eSPI INTIDs
appropriate config is disabled, or GIC HW doesn't
support eSPI, the existing functionality will remain the same.
Signed-off-by: Leonid Komarianskyi
Reviewed-by: Oleksandr Tyshchenko
---
Changes in V6:
- removed unnecessary parentheses in gic_is_valid_espi()
- updated gic_is_valid_line(): i
and ESPI_IDX2INTID
into appropriate inline functions introduced in the previous patch
- minor change: changed int to unsigned int for nr_espis
Reviewed-by: Oleksandr Tyshchenko
preferably with NIT below
Changes in V5:
- removed the has_espi field because it can be determined by checking
whet
On 04.09.25 08:52, Leonid Komarianskyi wrote:
Hi Julien, Volodymyr and Oleksandr,
Hello all
Thank you for your comments.
On 04.09.25 02:04, Julien Grall wrote:
Hi,
On 03/09/2025 22:37, Volodymyr Babchuk wrote:
Hi Oleksandr,
Oleksandr Tyshchenko writes:
[...]
+static inline
On 04.09.25 18:10, Leonid Komarianskyi wrote:
> Hello Oleksandr,
Hello Leonid
>
> Thank you for your comment.
>
> On 04.09.25 17:37, Oleksandr Tyshchenko wrote:
>>
>>
>> On 03.09.25 17:30, Leonid Komarianskyi wrote:
>>
>> Hello Leonid
>>
roper interrupt precedence
in the system.
The priority assignment now follows ARM GIC best practices:
- SGIs (0-15): GIC_PRI_IPI (higher priority)
- PPIs/SPIs (16+): GIC_PRI_IRQ (standard priority)
Signed-off-by: Mykola Kvach
Reviewed-by: Oleksandr Tyshchenko
---
xen/arch/arm/irq.
On 04.09.25 00:37, Volodymyr Babchuk wrote:
Hi Oleksandr,
Hello Volodymyr
Oleksandr Tyshchenko writes:
[...]
+static inline uint32_t vgic_get_reg_offset(uint32_t reg, uint32_t spi_base,
+ uint32_t espi_base)
+{
+if ( reg < espi_b
vgic_store_irouter to reflect parameter
changes
- minor change: changed the macros ESPI_INTID2IDX and ESPI_IDX2INTID
into appropriate inline functions introduced in the previous patch
Reviewed-by: Oleksandr Tyshchenko
preferably with the comments below
Changes in V5:
- since eSPI-specific defines
On 03.09.25 13:25, Mykola Kvach wrote:
Hi Oleksandr,
Hello Mykola
On Wed, Sep 3, 2025 at 1:01 PM Oleksandr Tyshchenko
wrote:
On 02.09.25 01:10, Mykola Kvach wrote:
Hello Mykola
From: Oleksandr Tyshchenko
Store and restore active context and micro-TLB registers.
Tested on R
On 02.09.25 01:10, Mykola Kvach wrote:
Hello Mykola
> From: Oleksandr Tyshchenko
>
> Store and restore active context and micro-TLB registers.
>
> Tested on R-Car H3 Starter Kit.
>
> Signed-off-by: Oleksandr Tyshchenko
> Signed-off-by: Mykola Kvach
> ---
&g
fioreq_gfn cannot be returned), please
refer to arch_ioreq_server_map_pages(). On Arm64, only the Acquire
Resource infrastructure is used to query and map the IOREQ Server pages.
Signed-off-by: Oleksandr Tyshchenko
---
xen/include/public/arch-arm.h | 1 -
1 file changed, 1 deletion(-)
diff -
On 29.08.25 19:06, Leonid Komarianskyi wrote:
Hello Leonid
Implemented support for GICv3.1 extended SPI registers for vGICv3,
allowing the emulation of eSPI-specific behavior for guest domains.
The implementation includes read and write emulation for eSPI-related
registers (e.g., GICD_ISENA
On 02.09.25 10:27, Orzel, Michal wrote:
Hello Michal
On 01/09/2025 14:58, Oleksandr Tyshchenko wrote:
The said sub-op is not supported on Arm64, since it:
- does not support the buffered emulation (so bufioreq_port/bufioreq_gfn
cannot be returned), please refer to
On 01.09.25 21:00, Leonid Komarianskyi wrote:
Hello Oleksandr,
Hello Leonid
Thank you for your review.
On 31.08.25 18:58, Oleksandr Tyshchenko wrote:
On 29.08.25 23:45, Volodymyr Babchuk wrote:
Hello Leonid, Volodymyr
Hi Leonid,
Leonid Komarianskyi writes:
This change
On 02.09.25 01:10, Mykola Kvach wrote:
Hello Mykola
From: Oleksandr Tyshchenko
This is done using generic iommu_suspend/resume functions that cause
IOMMU driver specific suspend/resume handlers to be called for enabled
IOMMU (if one has suspend/resume driver handlers implemented).
Signed
On 02.09.25 20:43, Mykola Kvach wrote:
Hi Oleksandr,
Hello Mykola
On Tue, Sep 2, 2025 at 7:49 PM Oleksandr Tyshchenko wrote:
On 02.09.25 01:10, Mykola Kvach wrote:
Hello Mykola
From: Mykola Kvach
On ARM, the first 32 interrupts (SGIs and PPIs) are banked per-CPU
and not
On 02.09.25 17:36, Julien Grall wrote:
> Hi Oleksandr,
Hello Julien
>
> On 02/09/2025 15:00, Oleksandr Tyshchenko wrote:
>>
>>
>> On 02.09.25 15:19, Julien Grall wrote:
>>
>> Hello Julien
>>
>>> On 02/09/2025 13:10, Orzel, Michal wrote:
gfn cannot be returned), please
refer to arch_ioreq_server_map_pages(). On Arm, only the Acquire
Resource infrastructure is used to query and map the IOREQ Server pages.
Signed-off-by: Oleksandr Tyshchenko
---
V2:
- s/Arm64/Arm
- drop from dm_op() in xen/arch/arm/dm.c
- upd
On 02.09.25 01:10, Mykola Kvach wrote:
Hello Mykola
From: Mykola Kvach
On ARM, the first 32 interrupts (SGIs and PPIs) are banked per-CPU
and not restored by gic_resume (for secondary cpus).
This patch introduces restore_local_irqs_on_resume, a function that
restores the state of local in
On 02.09.25 01:10, Mykola Kvach wrote:
Hello Mykola
From: Mykola Kvach
System suspend may lead to a state where GIC would be powered down.
Therefore, Xen should save/restore the context of GIC on suspend/resume.
Note that the context consists of states of registers which are
controlled b
On 02.09.25 15:19, Julien Grall wrote:
Hello Julien
> On 02/09/2025 13:10, Orzel, Michal wrote:
>>
>>
>> On 02/09/2025 13:54, Julien Grall wrote:
>>> Hi,
>>>
>>> On 02/09/2025 11:18, Orzel, Michal wrote:
>>>>
>>>>
>&g
by adding "select GICV3" to the RCAR4 Kconfig entry.
Fixes: 336fc7a19b49 ("xen/arm: platform: Add support for R-Car Gen4")
Signed-off-by: Oleksandr Tyshchenko
---
xen/arch/arm/platforms/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/arm/platforms/Kconfig b
On 29.08.25 23:45, Volodymyr Babchuk wrote:
Hello Leonid, Volodymyr
Hi Leonid,
Leonid Komarianskyi writes:
This change introduces resource management in the VGIC to handle
extended SPIs introduced in GICv3.1. The pending_irqs and
allocated_irqs arrays are resized to support the required
Is is the same as
for regular SPIs
- removed ifdefs for eSPI-specific offsets to reduce the number of
ifdefs and code duplication in further changes
- removed reviewed-by as moving offset from ifdefs requires additional
confirmation from reviewers
Reviewed-by: Oleksandr Tyshchenko
Ch
Kconfig option.
Signed-off-by: Leonid Komarianskyi
---
Changes in V5:
- no functional changes introduced by this version compared with V4, only
minor fixes and removal of ifdefs for macroses
- added TODO comment, suggested by Oleksandr Tyshchenko
- changed int to unsigned int for irqs
refactoring also simplifies the implementation of eSPI support in future
changes.
Signed-off-by: Leonid Komarianskyi
Reviewed-by: Volodymyr Babchuk
Acked-by: Julien Grall
Reviewed-by: Oleksandr Tyshchenko
with one NIT ...
---
Changes in V5:
- fixed a minor nit: changed %d to %u in the warning
On 28.08.25 19:40, Oleksii Moisieiev wrote:
Hello Oleksii
the patch lgtm, just some NITs
From: Grygorii Strashko
Add documentation section for Simple Arm SCMI over SMC calls forwarding
driver (EL3).
Signed-off-by: Grygorii Strashko
Signed-off-by: Oleksii Moisieiev
---
Changes in v6:
-
On 28.08.25 19:40, Oleksii Moisieiev wrote:
Hello Oleksii
the patch lgtm, just some comments
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 fir
On 28.08.25 19:40, Oleksii Moisieiev wrote:
Hello Oleksii
the patch lgtm, just some comments
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 sof
On 28.08.25 19:40, Oleksii Moisieiev wrote:
Hello Oleksii
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-throu
On 28.08.25 22:09, Leonid Komarianskyi wrote:
Hello Oleksandr,
Hello Leonid
Thank you for your comment and suggestions.
On 28.08.25 20:34, Oleksandr Tyshchenko wrote:
On 27.08.25 21:24, Leonid Komarianskyi wrote:
Hello Leonid
This change introduces resource management in the VGIC
On 29.08.25 00:36, Mykola Kvach wrote:
Hi Oleksandr,
Hello Mykola
Thank you for your review.
On Tue, Aug 26, 2025 at 6:51 PM Oleksandr Tyshchenko
wrote:
On 07.08.25 08:16, Mykola Kvach wrote:
Hello Mykola,
In general patch looks good to me, just one question below ...
From
Komarianskyi
Reviewed-by: Volodymyr Babchuk
---
Changes in V4:
- removed redundant line with 'default n' in Kconfig, as it is disabled
by default, without explicit specification
- added reviewed-by from Volodymyr Babchuk
only NITs below
Reviewed-by: Oleksandr Tyshchenko
Cha
supporting it), it will return the regular SPI
range, as it works currently. There are no functional changes compared
with the previous patch version
- removed VGIC_DEF_MAX_SPI macro, to reduce the number of ifdefs
very good, thanks, only NIT below
Reviewed-by: Oleksandr Tyshchenko
On 27.08.25 21:24, Leonid Komarianskyi wrote:
Hello Leonid
This change introduces resource management in the VGIC to handle
extended SPIs introduced in GICv3.1. The pending_irqs and
allocated_irqs arrays are resized to support the required
number of eSPIs, based on what is supported by the h
ded a log banner with eSPI information, similar to the one for
regular SPI
- added newline after ifdef and before gic_is_valid_line
- added reviewed-by from Volodymyr Babchuk
only NITs below
Reviewed-by: Oleksandr Tyshchenko
Changes in V3:
- add __init attribute to gicv3_dist_espi_common
- added vgic_is_valid_line implementation for new-vgic, because
vgic_is_valid_line is called from generic code. It is necessary to fix
the build for new-vgic.
The comments I provided are addressed (thanks), so you can add my:
Reviewed-by: Oleksandr Tyshchenko
[snip]
On 22.07.25 14:41, Oleksii Moisieiev wrote:
Hello Oleksii
[I will try to not repeat comments provided by Stefano in separate letter]
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.
On 27.08.25 16:38, Leonid Komarianskyi wrote:
Hello Oleksandr,
Hello Leonid
Thank you for your good question, I was thinking about that as well.
On 27.08.25 13:25, Oleksandr Tyshchenko wrote:
On 26.08.25 17:05, Leonid Komarianskyi wrote:
Hello Leonid,
In general patch looks good
On 27.08.25 14:13, Leonid Komarianskyi wrote:
Hello Oleksandr,
Hello Leonid
Thank you for your close review.
On 26.08.25 22:57, Oleksandr Tyshchenko wrote:
On 26.08.25 17:05, Leonid Komarianskyi wrote:
Hello Leonid
Implemented support for GICv3.1 extended SPI registers for vGICv3
On 27.08.25 13:25, Leonid Komarianskyi wrote:
Hello Leonid
Hello Volodymyr,
Thank you for your suggestion.
On 27.08.25 02:08, Volodymyr Babchuk wrote:
Hi Leonid,
Leonid Komarianskyi writes:
The Dom0 and DomUs logic for the dom0less configuration in create_dom0()
and arch_create_domUs(
On 26.08.25 17:05, Leonid Komarianskyi wrote:
Hello Leonid,
In general patch looks good to me, just one question below ...
Introduced appropriate register definitions, helper macros,
and initialization of required GICv3.1 distributor registers
to support eSPI. This type of interrupt is han
On 26.08.25 17:05, Leonid Komarianskyi wrote:
Hello Leonid
Currently, Xen does not support eSPI interrupts, leading
to a data abort when such interrupts are defined in the DTS.
This patch introduces a separate array to initialize up to
1024 interrupt descriptors in the eSPI range and adds
On 26.08.25 17:05, Leonid Komarianskyi wrote:
Hello Leonid
Implemented support for GICv3.1 extended SPI registers for vGICv3,
allowing the emulation of eSPI-specific behavior for guest domains.
The implementation includes read and write emulation for eSPI-related
registers (e.g., GICD_ISENA
On 07.08.25 08:16, Mykola Kvach wrote:
Hello Mykola,
In general patch looks good to me, just one question below ...
From: Volodymyr Babchuk
Implement suspend and resume callbacks for the SCIF UART driver,
enabled when CONFIG_SYSTEM_SUSPEND is set. This allows proper
handling of UART stat
On 26.08.25 16:42, Mykola Kvach wrote:
Hello Mykola, Volodymyr
Hi Volodymyr,
On Sat, Aug 23, 2025 at 8:55 PM Volodymyr Babchuk
wrote:
Hi,
Mykola Kvach writes:
From: Oleksandr Tyshchenko
This is done using generic iommu_suspend/resume functions that cause
IOMMU driver specific
On 07.08.25 15:33, Leonid Komarianskyi wrote:
Hello everyone!
Hello Leonid,
### Background
Unlike the Linux kernel, which has supported extended shared peripheral
interrupts (eSPIs) since 2019 [1], Xen currently lacks support for this
interrupt range. For SoCs with GICv3.1+, this feature
On 07.08.25 15:33, Leonid Komarianskyi wrote:
Hello Leonid
This change introduces resource management in the VGIC to handle
extended SPIs introduced in GICv3.1. The pending_irqs and
allocated_irqs arrays are resized to support the required
number of eSPIs, based on what is supported by the
On 07.08.25 15:33, Leonid Komarianskyi wrote:
Hello Leonid
Introduced appropriate register definitions, helper macros,
and initialization of required GICv3.1 distributor registers
to support eSPI. This type of interrupt is handled in the
same way as regular SPI interrupts, with the followin
On 07.08.25 15:33, Leonid Komarianskyi wrote:
Hello Leonid
The Dom0 configuration logic in create_dom0() has been updated
to account for extended SPIs when supported by the hardware and
enabled with CONFIG_GICV3_ESPI. These changes ensure the proper
calculation of the maximum number of SPIs
On 07.08.25 15:33, Leonid Komarianskyi wrote:
Hello Leonid
Introduced two new helper functions for vGIC: vgic_is_valid_irq and
vgic_is_shared_irq. The functions are similar to the newly introduced
gic_is_valid_irq and gic_is_shared_irq, but they verify whether a vIRQ
is available for a spec
On 07.08.25 15:33, Leonid Komarianskyi wrote:
Hello Leonid
Implemented support for GICv3.1 extended SPI registers for vGICv3,
allowing the emulation of eSPI-specific behavior for guest domains.
The implementation includes read and write emulation for eSPI-related
registers (e.g., GICD_ISENA
Fix the incorrect condition that causes hvm_alloc_legacy_ioreq_gfn()
to return INVALID_GFN even if the HVM param was installed properly by
the toolstack.
Fixes: 3486f398a3dd (' x86/hvm/ioreq: allow ioreq servers to use
HVM_PARAM_[BUF]IOREQ_PFN')
Signed-off-by: Oleksandr Tyshchenko
Properly emulate the full register")
Signed-off-by: Oleksandr Tyshchenko
---
xen/arch/arm/vgic-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index f20249f731..4369c55177 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arc
: c4d6bbdc12e5 ("xen/arm: vgic-v3: Support 32-bit access for 64-bit
registers")
Signed-off-by: Oleksandr Tyshchenko
Acked-by: Julien Grall
---
V2:
- s/data about/guest data abort in the description
- add A-b
- move goto to the next line
---
---
xen/arch/arm/vgic-v3.c | 3 ++-
1 fi
On 20.05.25 18:02, Julien Grall wrote:
> Hi Oleksandr,
Hello Julien
>
> On 20/05/2025 14:47, Oleksandr Tyshchenko wrote:
>> An attempt to write access the register (i.e. GICR_PROPBASER,
>> GICR_PENDBASER)
>> which should be ignored (i.e. no virtual ITS present
On 20.05.25 17:24, Andrew Cooper wrote:
Hello Andrew
> On 20/05/2025 2:47 pm, Oleksandr Tyshchenko wrote:
>> An attempt to write access the register (i.e. GICR_PROPBASER, GICR_PENDBASER)
>> which should be ignored (i.e. no virtual ITS present) causes the data about
>
> Do
2-bit access for 64-bit
registers")
Signed-off-by: Oleksandr Tyshchenko
---
xen/arch/arm/vgic-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 2eaa48fadb..b366b046a2 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm
On 27.03.25 00:39, Julien Grall wrote:
> Hi Oleksandr,
Hello Julien
>
> On 26/03/2025 11:45, Oleksandr Tyshchenko wrote:
>> Also it is not entirely clear what we should do with acpi_disabled=true
>> during declaration (what current patch does), even if we decided to
On 27.03.25 00:33, Julien Grall wrote:
Hello Julien
> Hi,
>
> On 26/03/2025 08:57, Orzel, Michal wrote:
>>
>>
>> On 25/03/2025 17:54, Oleksandr Tyshchenko wrote:
>>>
>>>
>>> On 25.03.25 18:09, Julien Grall wrote:
>>>
>>>
On 26.03.25 10:57, Orzel, Michal wrote:
Hello Michal, Julien
>
>
> On 25/03/2025 17:54, Oleksandr Tyshchenko wrote:
>>
>>
>> On 25.03.25 18:09, Julien Grall wrote:
>>
>>
>>> Hi Oleksandr,
>>
>> Hello Julien
>>
>>&g
On 19.03.25 14:37, Jan Beulich wrote:
Hello Jan, all.
On 19.03.2025 13:05, Mykyta Poturai wrote:
On 18.03.25 16:26, Jan Beulich wrote:
On 18.03.2025 14:31, Mykyta Poturai wrote:
On 18.03.25 12:11, Jan Beulich wrote:
On 18.03.2025 10:10, Mykyta Poturai wrote:
On 15.01.24 11:35, Jan Beul
en().
Signed-off-by: Oleksandr Tyshchenko
---
The RFC since I am not sure whether the description is precise
and the fix is correct.
Below the dump, w/o and w/ the fix applied. I also added prints
for the processed memory ranges with "OT:" for the visibility:
On 25.03.25 18:09, Julien Grall wrote:
> Hi Oleksandr,
Hello Julien
>
> On 25/03/2025 16:05, Oleksandr Tyshchenko wrote:
>>>>> Furthermore, what happen if we decide to use ACPI afterwards? Wouldn't
>>>>> this mean that the static regions w
On 25.03.25 17:47, Julien Grall wrote:
Hello Julien, Michal.
> Hi Michal,
>
> On 25/03/2025 15:35, Orzel, Michal wrote:
>>
>>
>> On 25/03/2025 16:23, Julien Grall wrote:
>>>
>>>
>>> Hi Oleksandr, Michal,
>>>
>>> On 25/
an issue and match to acpi_boot_table_init().
Suggested-by: Michal Orzel
Signed-off-by: Oleksandr Tyshchenko
---
V2:
- drop post-commit remark
- use the approach suggested by Michal
- update commit subject (WAS xen/device-tree: Switch back to
dt_unreserved_regions() in boot allocator
On 25.03.25 10:46, Orzel, Michal wrote:
Hello Michal
>
>
> On 24/03/2025 22:27, Oleksandr Tyshchenko wrote:
>>
>>
>> On the device-tree-based Arm64 system, if Xen is built with
>> CONFIG_ACPI=y, CONFIG_STATIC_MEMORY=y, and the static memory range
>> i
Hello all.
Please, ignore this second email, it was sent by mistake.
--
Regards,
Oleksandr Tyshchenko
en().
Signed-off-by: Oleksandr Tyshchenko
---
The RFC since I am not sure whether the description is precise
and the fix is correct.
Below the dump, w/o and w/ the fix applied. I also added prints
for the processed memory ranges with "OT:" for the visibility:
On 20.03.25 09:30, Jan Beulich wrote:
Hello Jan, Mykyta, all
On 19.03.2025 21:42, Oleksandr Tyshchenko wrote:
On 19.03.25 14:37, Jan Beulich wrote:
On 19.03.2025 13:05, Mykyta Poturai wrote:
On 18.03.25 16:26, Jan Beulich wrote:
On 18.03.2025 14:31, Mykyta Poturai wrote:
On 18.03.25
From: Oleksandr Tyshchenko
This is actually what the caller acquire_resource() expects on any kind
of error (the comment on top of resource_max_frames() also suggests that).
Otherwise, the caller will treat -errno as a valid value and propagate incorrect
nr_frames to the VM. As a possible
On 17.02.25 23:09, Andrew Cooper wrote:
Hello.
On 17/02/2025 8:48 pm, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The sign of the presence of a corresponding bugfix is an error
returned on querying the size of an unknown for Xen resource type.
Signed-off-by: Oleksandr
From: Oleksandr Tyshchenko
The sign of the presence of a corresponding bugfix is an error
returned on querying the size of an unknown for Xen resource type.
Signed-off-by: Oleksandr Tyshchenko
---
Refer https://patchew.org/Xen/20250217102741.4122367-1-olekst...@gmail.com/
Current patch should
On 17.02.25 15:52, Andrew Cooper wrote:
Hello
On 17/02/2025 1:11 pm, Oleksandr Tyshchenko wrote:
On 17.02.25 13:09, Andrew Cooper wrote:
Hello Andrew
On 17/02/2025 10:27 am, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This is actually what the caller acquire_resource
On 17.02.25 13:09, Andrew Cooper wrote:
Hello Andrew
On 17/02/2025 10:27 am, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This is actually what the caller acquire_resource() expects on any kind
of error (the comment on top of resource_max_frames() also suggests that
From: Oleksandr Tyshchenko
This is actually what the caller acquire_resource() expects on any kind
of error (the comment on top of resource_max_frames() also suggests that).
Otherwise, the caller will treat -errno as a valid value and propagate incorrect
nr_frames to the VM. As a possible
On 17.02.25 11:18, Jan Beulich wrote:
Hello Jan
On 16.02.2025 22:19, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This is actually what the caller acquire_resource() expects on any kind
of error (the comment on top of resource_max_frames() also suggests that).
Otherwise, the
From: Oleksandr Tyshchenko
This is actually what the caller acquire_resource() expects on any kind
of error (the comment on top of resource_max_frames() also suggests that).
Otherwise, the caller will treat -errno as a valid value and propagate incorrect
nr_frames to the VM. As a possible
From: Oleksandr Tyshchenko
Add common requirements for a physical device assignment to Arm64
and AMD64 PVH domains.
Signed-off-by: Oleksandr Tyshchenko
---
Previous discussion (V1) here:
https://lists.xenproject.org/archives/html/xen-devel/2024-10/msg00534.html
V2:
A lot of changes
On 09.10.24 10:26, Julien Grall wrote:
Hi,
Hello Julien
On 07/10/2024 19:55, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Add common requirements for a physical device assignment to Arm64
and AMD64 PVH domains.
Signed-off-by: Oleksandr Tyshchenko
---
Based on:
[PATCH
On 09.10.24 09:36, Bertrand Marquis wrote:
Hi Oleksandr,
Hello Bertrand
On 8 Oct 2024, at 20:53, Oleksandr Tyshchenko wrote:
On 08.10.24 09:17, Bertrand Marquis wrote:
Hi,
Hello Bertrand
On 7 Oct 2024, at 20:55, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Add
On 09.10.24 01:46, Stefano Stabellini wrote:
Hello Stefano
On Tue, 8 Oct 2024, Oleksandr Tyshchenko wrote:
On 7 Oct 2024, at 20:55, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Add common requirements for a physical device assignment to Arm64
and AMD64 PVH domains.
Signed
On 08.10.24 09:17, Bertrand Marquis wrote:
Hi,
Hello Bertrand
On 7 Oct 2024, at 20:55, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Add common requirements for a physical device assignment to Arm64
and AMD64 PVH domains.
Signed-off-by: Oleksandr Tyshchenko
---
Based on
From: Oleksandr Tyshchenko
Add common requirements for a physical device assignment to Arm64
and AMD64 PVH domains.
Signed-off-by: Oleksandr Tyshchenko
---
Based on:
[PATCH] docs: fusa: Replace VM with domain
https://patchew.org/Xen/20241007182603.826807-1-ayan.kumar.hal...@amd.com
On 07.04.24 05:43, Peng Fan wrote:
Hi Oleksandr,
Hello Peng
Subject: [PATCH 2/2] xen/arm: Add i.MX UART driver
From: Oleksandr Tyshchenko
The i.MX UART Documentation:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
nxp.com%2Fwebapp%2FDownload%3FcolCode
On 04.04.24 09:54, Michal Orzel wrote:
Hi Oleksandr,
Hello Michal
sorry for the late response
On 02/04/2024 14:05, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The i.MX UART Documentation:
https://www.nxp.com/webapp/Download?colCode=IMX8MMRM
Chapter 16.2 Universal
On 03.04.24 13:11, Michal Orzel wrote:
Hi Oleksandr,
Hello Michal
sorry for the late response
On 02/04/2024 14:05, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Tested on i.MX 8M Mini only, but I guess, it should be
suitable for other i.MX8M* SoCs (those UART device tree
From: Oleksandr Tyshchenko
This is needed to have a possibility of assigning a specified number
of shared peripheral interrupts (SPIs) to domain.
Signed-off-by: Oleksandr Tyshchenko
Signed-off-by: Stefano Stabellini
---
README.md| 5 +
scripts/uboot-script-gen | 4
2
From: Oleksandr Tyshchenko
uImage is the Image that has a U-Boot wrapper, it doesn't contain
"executable" string which subsequent "file" command is looking for
when inspecting it.
Below the proof:
otyshchenko@EPUAKYIW03DD:~/work/xen_tests/input$ file -L binaries/uImage
From: Oleksandr Tyshchenko
Use DOMU_GRANT_VER to set "max_grant_version" dt property.
Use DOMU_GRANT_FRAMES to set "max_grant_frames" dt property.
Use DOMU_MAPTRACK_FRAMES to set "max_maptrack_frames" dt property.
Signed-off-by: Oleksandr Tyshchenko
---
From: Oleksandr Tyshchenko
Introduce new option DOMU_VPL011[nr] that can be set to 0
or 1 (default).
Also align "console=ttyAMA0" Linux cmd arg setting with "vpl011" presense.
Suggested-by: Michal Orzel
Signed-off-by: Oleksandr Tyshchenko
---
README.md
From: Oleksandr Tyshchenko
Hello all,
this is a collection of patches (#2-5) for improving the dom0less support
and a patch (#1) for dealing with uImage.
Oleksandr Tyshchenko (5):
uboot-script-gen: Update to deal with uImage which is not executable
uboot-script-gen: Extend DOMU_ENHANCED
From: Oleksandr Tyshchenko
We need some Xen services to be available within single dom0less DomU.
Just using "enabled" will lead to Xen panic because of no Dom0.
(XEN)
(XEN) Panic on CPU 0:
(XEN) At the moment, Xenstore support requires
On 08.04.24 20:38, Hildebrand, Stewart via groups.io wrote:
> On 4/8/24 09:19, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko
>>
>> Please refer to chapter "Device Passthrough":
>> https://urldefense.com/v3/__https://groups.io/g/amd-xen-s
From: Oleksandr Tyshchenko
Please refer to chapter "Device Passthrough":
https://groups.io/g/amd-xen-safety/message/1300
Create corresponding directory and README file.
Signed-off-by: Oleksandr Tyshchenko
---
V2:
- add R-b
- update README
- lower case for platform, s/
From: Oleksandr Tyshchenko
The i.MX UART Documentation:
https://www.nxp.com/webapp/Download?colCode=IMX8MMRM
Chapter 16.2 Universal Asynchronous Receiver/Transmitter (UART)
Tested on i.MX 8M Mini only, but I guess, it should be
suitable for other i.MX8M* SoCs (those UART device tree nodes
From: Oleksandr Tyshchenko
Hello all.
This small series contains early printk and full UART support
for i.MX 8M Mini EVKB [1].
Tested on i.MX 8M Mini only to which I had an access, but from my
understanding, this UART support should be suitable for other i.MX8M* SoCs
(those UART device tree
From: Oleksandr Tyshchenko
Tested on i.MX 8M Mini only, but I guess, it should be
suitable for other i.MX8M* SoCs (those UART device tree nodes
contain "fsl,imx6q-uart" compatible string).
Signed-off-by: Oleksandr Tyshchenko
---
I selected the following configs for enabling ea
1 - 100 of 778 matches
Mail list logo
