On 05.06.2025 19:40, Alejandro Vallejo wrote:
> On Thu Jun 5, 2025 at 7:28 PM CEST, Alejandro Vallejo wrote:
>> On Mon Jun 2, 2025 at 7:00 PM CEST, Andrew Cooper wrote:
>>> On 30/05/2025 1:02 pm, Alejandro Vallejo wrote:
These types resemble each other very closely in layout and intent, and
>>
On Thu, Jun 05, 2025 at 10:58:48PM +0100, Julien Grall wrote:
> Hi Denis,
>
> On 28/05/2025 23:50, dm...@proton.me wrote:
> > From: Denis Mukhin
> >
> > From: Denis Mukhin
> >
> > Currently, hypervisor code has two different domain ID allocation
> > implementations:
> >
> >(a) Sequential IDs
On 05.06.2025 21:47, Alejandro Vallejo wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -42,8 +42,10 @@
> #include
> #include
> #include
> +
> #include
> #include
> +#include
>
> #ifdef CONFIG_PV_SHIM
> #include
> --- a/xen/include/xen/grant_table.h
> ++
On 05.06.2025 21:47, Alejandro Vallejo wrote:
> --- a/xen/include/asm-generic/device.h
> +++ b/xen/include/asm-generic/device.h
> @@ -1,14 +1,20 @@
> /* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * This header helps DTB-based architectures abstract away where a particular
> + * device came
On 06.06.2025 02:09, Stefano Stabellini wrote:
> On Thu, 5 Jun 2025, Jan Beulich wrote:
>> On 05.06.2025 14:26, Nicola Vetrini wrote:
>>> On 2025-06-05 14:22, Nicola Vetrini wrote:
On 2025-06-05 09:17, Jan Beulich wrote:
> On 05.06.2025 01:49, victorm.l...@amd.com wrote:
>> From: Nicol
On 06.06.2025 02:07, Stefano Stabellini wrote:
> On Thu, 5 Jun 2025, Jan Beulich wrote:
>> On 05.06.2025 01:09, Stefano Stabellini wrote:
>>> --- a/xen/scripts/Makefile.asm-generic
>>> +++ b/xen/scripts/Makefile.asm-generic
>>> @@ -32,7 +32,12 @@ old-headers := $(wildcard $(obj)/*.h)
>>> unwanted
On 2025/6/5 20:50, Roger Pau Monné wrote:
> On Mon, May 26, 2025 at 05:45:53PM +0800, Jiqian Chen wrote:
>> + }; \
>> + static vpci_capability_t *const finit##_entry \
>> + __used_section(".data.vpci") = &finit##_t
>
> IMO this should better use .rodata instead of .data.
Is belo
On 05.06.2025 18:08, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 05, 2025 at 06:05:02PM +0200, Jan Beulich wrote:
>> On 05.06.2025 16:51, Marek Marczykowski-Górecki wrote:
>>> On Thu, Jun 05, 2025 at 04:42:53PM +0200, Jan Beulich wrote:
Why is it that this ring is dependent upon Xen's posi
On 05.06.2025 18:48, Alejandro Vallejo wrote:
> On Thu Jun 5, 2025 at 4:20 PM CEST, Jan Beulich wrote:
>> On 05.06.2025 16:15, Alejandro Vallejo wrote:
>>> On Mon Jun 2, 2025 at 4:24 PM CEST, Jan Beulich wrote:
On 02.06.2025 16:19, Alejandro Vallejo wrote:
> On Mon Jun 2, 2025 at 9:51 AM C
On Thu, Jun 05, 2025 at 11:20:32PM +0100, Julien Grall wrote:
> Hi Jan,
>
> On 04/06/2025 13:55, Jan Beulich wrote:
> > On 31.05.2025 01:19, dm...@proton.me wrote:
> >> --- a/xen/common/domain.c
> >> +++ b/xen/common/domain.c
> >> @@ -2461,6 +2461,39 @@ void domid_free(domid_t domid)
> >> sp
On 2025/6/5 19:24, Roger Pau Monné wrote:
> On Mon, May 26, 2025 at 05:45:52PM +0800, Jiqian Chen wrote:
>> Add a new function to emulate extended capability list for dom0,
>> and call it in init_header(). So that it will be easy to hide a
>> extended capability whose initialization fails.
>>
>> As
Hi, @Julien Grall
On Wed, Jun 4, 2025 at 2:00 AM Julien Grall wrote:
>
> Hi Mykola,
>
> On 27/05/2025 10:18, Mykola Kvach wrote:
> > From: Mykola Kvach
> >
> > This patch adds support for the PSCI SYSTEM_SUSPEND function in the vPSCI
> > (virtual PSCI) interface, allowing guests to request suspe
On Thu, 5 Jun 2025, Jan Beulich wrote:
> On 05.06.2025 01:09, Stefano Stabellini wrote:
> > --- a/xen/scripts/Makefile.asm-generic
> > +++ b/xen/scripts/Makefile.asm-generic
> > @@ -32,7 +32,12 @@ old-headers := $(wildcard $(obj)/*.h)
> > unwanted:= $(filter-out $(generic-y) $(generated-y),$(o
On Thu, 5 Jun 2025, Jan Beulich wrote:
> On 05.06.2025 14:26, Nicola Vetrini wrote:
> > On 2025-06-05 14:22, Nicola Vetrini wrote:
> >> On 2025-06-05 09:17, Jan Beulich wrote:
> >>> On 05.06.2025 01:49, victorm.l...@amd.com wrote:
> From: Nicola Vetrini
>
> Function `reboot_machine'
MISRA D4.10 requires to have proper header guards in place in all header
files. Add header guards for generated asm generic headers as well.
Suggested-by: Jan Beulich
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- write to $@.new and move the file
- change the header guard name
---
xen/
On Thu, 5 Jun 2025, Jan Beulich wrote:
> On 05.06.2025 03:17, dm...@proton.me wrote:
> > On Wed, Jun 04, 2025 at 12:36:17PM +0200, Jan Beulich wrote:
> >> On 02.06.2025 21:17, dm...@proton.me wrote:
> >>> From: Denis Mukhin
> >>>
> >>> Add common emulation_flags for configuring domain emulation fe
On Thu, 5 Jun 2025, Jan Beulich wrote:
> On 05.06.2025 01:35, Stefano Stabellini wrote:
> > From: Alessandro Zucchelli
> >
> > MISRA C Rule 21.16 states the following: "The pointer arguments to
> > the Standard Library function `memcmp' shall point to either a pointer
> > type, an essentially sig
On Thu, 5 Jun 2025, Alejandro Vallejo wrote:
> On Mon Jun 2, 2025 at 10:25 PM CEST, Daniel P. Smith wrote:
> >> +/* Helper to read a big number; size is in cells (not bytes) */
> >> +static inline u64 dt_read_number(const __be32 *cell, int size)
> >> +{
> >> +u64 r = 0;
> >> +
> >> +while (
Hi Oleksii & Stefano,
On 23/05/2025 21:06, Stefano Stabellini wrote:
+SCMI SMC multi-agent support
+
+
+For enabling the ARM SCMI SMC multi-agent support (enabled by
CONFIG_SCMI_SMC_MA)
+the Xen specific SCMI Agent's configuration shell be provided in the Host DT
+ac
Hi Oleksii,
On 19/05/2025 16:50, Oleksii Moisieiev wrote:
> > MAINTAINERS | 6 +
.../arm/firmware/arm-scmi-proposal.rst| 224 +
.../arm/firmware/arm-scmi.rst | 442 +
docs/hypervisor-guide/arm/index.rst | 9
Hi Jan,
On 04/06/2025 13:55, Jan Beulich wrote:
On 31.05.2025 01:19, dm...@proton.me wrote:
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -2461,6 +2461,39 @@ void domid_free(domid_t domid)
spin_unlock(&domid_lock);
}
+/*
+ * Find the ID of the next possible console owner do
Hi Denis,
On 28/05/2025 23:50, dm...@proton.me wrote:
From: Denis Mukhin
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).
I am not entirely why this is done
Hi Denis,
On 28/05/2025 23:50, dm...@proton.me wrote:
From: Denis Mukhin
From: Denis Mukhin
Currently, hypervisor code has two different domain ID allocation
implementations:
(a) Sequential IDs allocation in dom0less Arm code based on max_init_domid;
(b) Sequential IDs allocation in
On 6/5/25 02:45, Orzel, Michal wrote:
> On 04/06/2025 21:51, Stewart Hildebrand wrote:
>> On 6/4/25 03:00, Orzel, Michal wrote:
>>> On 03/06/2025 23:15, Stewart Hildebrand wrote:
On 5/14/25 03:31, Orzel, Michal wrote:
> On 13/05/2025 21:54, Stewart Hildebrand wrote:
>> Similarly to fba
On Thu, May 29, 2025 at 11:40 PM Teddy Astie wrote:
> Hello Christopher,
>
Hi Teddy, thanks for the review.
>
> Le 28/05/2025 à 23:13, Christopher Clark a écrit :
> > Adds approachable documentation describing system components and
> > introduces the support statement for feature status.
> ...
Part of an unpicking process to extract bootfdt contents independent of
bootinfo to a separate file for x86 to take.
With this, bootfdt.h can be cleanly included from x86. A later patch
extracts the definitions so the functions may be called too.
Not a functional change.
Signed-off-by: Alejandro
... without CONFIG_HAS_DEVICE_TREE
Signed-off-by: Alejandro Vallejo
---
xen/common/Kconfig | 1 +
xen/common/Makefile | 2 +-
xen/common/device-tree/Makefile | 8
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/xen/common/Kconfig b/xen/common/Kcon
Without picking CONFIG_HAS_DEVICE_TREE.
In order to do that. Allow CONFIG_DOM0LESS_BOOT to enable a subset
of the common/device-tree/ directory. x86 doesn't want dom0less-build.c,
as that's tightly integrated still to the ARM way of building domains.
Requires "unsupported" for the time being unti
This will be required later by x86 code in order to do early identification
of boot modules when booting off a DTB.
Not a functional change.
Signed-off-by: Alejandro Vallejo
Reviewed-by: Stefano Stabellini
---
xen/common/device-tree/bootfdt.c | 18 ++
xen/common/device-tre
... back into bootfdt.c
These will be required by x86 later on to detect modules in the early scan of
the FDT. They are independent of bootinfo, so it's cleaner for them to exist in
a separate file.
Not a functional change.
Signed-off-by: Alejandro Vallejo
---
xen/common/device-tree/Makefile
... which means, device-tree.c stops requiring strictly CONFIG_HAS_DEVICE_TREE
and may function without it.
Not a functional change on architectures that currently use these files,
as they already select CONFIG_HAS_DEVICE_TREE.
Signed-off-by: Alejandro Vallejo
---
xen/common/device-tree/device-
This file will eventually contain bootfdt helpers that make heavy use of
bootinfo. To simplify git history do the rename here explicitly. A later
patch extracts bootinfo-independent helpers into bootfdt.c.
Doing so here would needlessly pollute the diffs.
Not a functional change.
Signed-off-by:
No functional change intended.
Signed-off-by: Alejandro Vallejo
---
v2:
* Replaces the previous patch in which kernel_info replaced boot_domain
---
xen/arch/x86/dom0_build.c | 2 +-
xen/arch/x86/hvm/dom0_build.c | 6 ++---
xen/arch/x86/include/asm/boot-domain.h | 33 ---
There's some pretense this header may be used without
CONFIG_HAS_DEVICE_TREE, but that's just wishful thinking. Only x86 lacks
that option, and it fully overrides this header, typedeffing struct
pci_dev to be device_t.
Furthermore there's an include for xen/device_tree.h halfway through the
header
Create a struct header with the contents common to kernel_info and
boot_domain, and define that header in common code. This enables x86 to
use that header as-is.
Not a functional change.
Signed-off-by: Alejandro Vallejo
---
v2:
* New patch
---
xen/arch/arm/dom0less-build.c | 8
These types resemble each other very closely in layout and intent, and
with "struct bootmodule" already in common code it makes perfect sense
to merge them. In order to do so, add an arch-specific area for
x86-specific tidbits.
Signed-off-by: Alejandro Vallejo
--
v2:
* Remove spurious fdt_cmdli
v2 pipeline:
https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/185576
v1: https://lore.kernel.org/xen-devel/20250530120242.39398-1-agarc...@amd.com/
Original cover letter:
This is the aftermath of this discussion:
https://lore.kernel.org/xen-devel/da1wwruqlcag.ztvr1hxj8...
Part of an unpicking process to extract bootfdt contents independent of bootinfo
to a separate file for x86 to take.
Move functions required for early FDT parsing from device_tree.h and arm's
setup.h onto bootfdt.h
Declaration motion only. Not a functional change.
Signed-off-by: Alejandro Vallej
Not a functional change
Signed-off-by: Alejandro Vallejo
---
v2:
* Remove both links rather than just one.
---
xen/arch/arm/include/asm/grant_table.h | 1 -
xen/common/device-tree/dom0less-build.c | 1 +
xen/common/grant_table.c| 2 ++
xen/include/xen/grant_table.h |
A later patch removes boot_module and replaces its uses with bootmodule.
The equivalent field for "type" doesn't have BOOTMOD_UNKNOWN as a zero
value, so it must be explicitly set in the static xen_boot_info.
Not a functional change.
Signed-off-by: Alejandro Vallejo
Reviewed-by: Stefano Stabelli
In preparation for x86 to start using bootmodule instead of boot_module
Signed-off-by: Alejandro Vallejo
---
v2:
* Added microcode detection in early probing
---
xen/common/device-tree/bootfdt.c | 2 ++
xen/common/device-tree/bootinfo.c | 1 +
xen/include/xen/bootfdt.h | 1 +
3 files
On Sat May 31, 2025 at 2:39 AM CEST, dmkhn wrote:
> On Fri, May 30, 2025 at 02:02:23PM +0200, Alejandro Vallejo wrote:
>> ... back into bootfdt.c
>>
>> These will be required by x86 later on to detect modules in the early scan of
>> the FDT. They are independent of bootinfo, so it's cleaner for th
On Sat May 31, 2025 at 3:42 AM CEST, Stefano Stabellini wrote:
> On Fri, 30 May 2025, Alejandro Vallejo wrote:
>> Part of an unpicking process to extract bootfdt contents independent of
>> bootinfo to a separate file for x86 to take.
>>
>> With this, bootfdt.h can be cleanly included from x86. A l
On Mon Jun 2, 2025 at 10:25 PM CEST, Daniel P. Smith wrote:
>> +/* Helper to read a big number; size is in cells (not bytes) */
>> +static inline u64 dt_read_number(const __be32 *cell, int size)
>> +{
>> +u64 r = 0;
>> +
>> +while ( size-- )
>> +r = (r << 32) | be32_to_cpu(*(cell++)
Le 05/06/2025 à 12:28, Jan Beulich a écrit :
> Stop the compiler from inlining non-trivial memset() and memcpy() (for
> memset() see e.g. map_vcpu_info() or kimage_load_segments() for
> examples). This way we even keep the compiler from using REP STOSQ /
> REP MOVSQ when we'd prefer REP STOSB / REP
On 5/30/25 6:17 AM, Sergii Dmytruk wrote:
From: Krystian Hebel
This file is built twice: for early 32b mode without paging to measure
MBI and for 64b code to measure dom0 kernel and initramfs. Since MBI
is small, the first case uses TPM to do the hashing. Kernel and
initramfs on the other hand
On Thu Jun 5, 2025 at 7:28 PM CEST, Alejandro Vallejo wrote:
> On Mon Jun 2, 2025 at 7:00 PM CEST, Andrew Cooper wrote:
>> On 30/05/2025 1:02 pm, Alejandro Vallejo wrote:
>>> These types resemble each other very closely in layout and intent, and
>>> with "struct bootmodule" already in common code i
Hi,
Please submit your talk for Xen summit.
Details - https://sessionize.com/xen-summit-2025/
You can find the talks for our previous summit at
https://tinyurl.com/4ak2ys8x
Kind regards,
Ayan
On Mon Jun 2, 2025 at 7:00 PM CEST, Andrew Cooper wrote:
> On 30/05/2025 1:02 pm, Alejandro Vallejo wrote:
>> These types resemble each other very closely in layout and intent, and
>> with "struct bootmodule" already in common code it makes perfect sense
>> to merge them. In order to do so, add an
On 05/06/2025 6:06 pm, Teddy Astie wrote:
> Le 05/06/2025 à 12:27, Jan Beulich a écrit :
>> Move the function to its own assembly file. Having it in C just for the
>> entire body to be an asm() isn't really helpful. Then have two flavors:
>> A "basic" version using qword steps for the bulk of the o
On 05/06/2025 11:25 am, Jan Beulich wrote:
> --- a/xen/arch/x86/alternative.c
> +++ b/xen/arch/x86/alternative.c
> @@ -195,12 +195,16 @@ void *place_ret(void *ptr)
> * executing.
> *
> * "noinline" to cause control flow change and thus invalidate I$ and
> - * cause refetch after modification.
On Sat May 31, 2025 at 2:59 AM CEST, Stefano Stabellini wrote:
> On Fri, 30 May 2025, Alejandro Vallejo wrote:
>> In preparation for x86 to start using bootmodule instead of boot_module
>>
>> Signed-off-by: Alejandro Vallejo
>
> Reviewed-by: Stefano Stabellini
Thanks.
Note to self though, I sh
On Mon Jun 2, 2025 at 9:55 AM CEST, Jan Beulich wrote:
> On 30.05.2025 14:02, Alejandro Vallejo wrote:
>> A later patch removes boot_module and replaces its uses with bootmodule.
>> The equivalent field for "type" doesn't have BOOTMOD_UNKNOWN as a zero
>> value, so it must be explicitly set in the
On Tue Jun 3, 2025 at 9:04 AM CEST, Jan Beulich wrote:
> On 02.06.2025 18:39, Alejandro Vallejo wrote:
>> On Mon Jun 2, 2025 at 4:51 PM CEST, Jan Beulich wrote:
>>> On 02.06.2025 16:30, Alejandro Vallejo wrote:
On Mon Jun 2, 2025 at 9:53 AM CEST, Jan Beulich wrote:
> On 30.05.2025 14:02, A
Le 05/06/2025 à 12:27, Jan Beulich a écrit :
> Move the function to its own assembly file. Having it in C just for the
> entire body to be an asm() isn't really helpful. Then have two flavors:
> A "basic" version using qword steps for the bulk of the operation, and an
> ERMS version for modern hard
On 05/06/2025 2:24 pm, Jan Beulich wrote:
> On 05.06.2025 14:14, Andrew Cooper wrote:
>> On 05/06/2025 1:02 pm, Jan Beulich wrote:
>>> On 05.06.2025 13:16, Andrew Cooper wrote:
The format of the buildid is a property of the binary, not a property of
how
it was loaded. This fixes bu
Le 05/06/2025 à 12:26, Jan Beulich a écrit :
> Move the function to its own assembly file. Having it in C just for the
> entire body to be an asm() isn't really helpful. Then have two flavors:
> A "basic" version using qword steps for the bulk of the operation, and an
> ERMS version for modern hard
On Thu Jun 5, 2025 at 4:20 PM CEST, Jan Beulich wrote:
> On 05.06.2025 16:15, Alejandro Vallejo wrote:
>> On Mon Jun 2, 2025 at 4:24 PM CEST, Jan Beulich wrote:
>>> On 02.06.2025 16:19, Alejandro Vallejo wrote:
On Mon Jun 2, 2025 at 9:51 AM CEST, Jan Beulich wrote:
> On 30.05.2025 14:02, A
On Fri, Mar 14, 2025 at 05:24:54PM +, Alejandro Vallejo wrote:
> These are effectively the sum of free memory in all zones of each node.
> It's an optimization to avoid doing that operation frequently in
> following patches that introduce exact-node claims.
>
> Signed-off-by: Alejandro Vallejo
On Fri, Mar 14, 2025 at 05:24:53PM +, Alejandro Vallejo wrote:
> With a single global count for the claims it's easy to substract
> domain_tot_pages() from the claim so the number given in the hypercall
> is the real reservation of the domain. This is the current behaviour.
>
> However, a late
The Xen PCI device (vendor ID 0x5853) exposed to x86 HVM guests doesn't
have the functionality of a traditional PCI device. The exposed MMIO BAR
is used by some guests (including Linux) as a safe place to map foreign
memory, including the grant table itself.
Traditionally BARs from devices have t
On Thu, Jun 05, 2025 at 06:05:02PM +0200, Jan Beulich wrote:
> On 05.06.2025 16:51, Marek Marczykowski-Górecki wrote:
> > On Thu, Jun 05, 2025 at 04:42:53PM +0200, Jan Beulich wrote:
> >> Why is it that this ring is dependent upon Xen's position? If the ring was
> >> dynamically allocated, it would
On 05.06.2025 16:51, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 05, 2025 at 04:42:53PM +0200, Jan Beulich wrote:
>> On 26.05.2025 17:39, Marek Marczykowski-Górecki wrote:
>>> On Mon, May 26, 2025 at 04:08:17PM +0100, Andrew Cooper wrote:
On 25/05/2025 3:15 pm, Marek Marczykowski-Górecki w
On 05.06.2025 17:17, Teddy Astie wrote:
> Le 05/06/2025 à 16:51, Jan Beulich a écrit :
>> On 30.05.2025 10:48, Teddy Astie wrote:
>>> +/*
>>> + * If single context invalidation is not supported, we escalate to
>>> + * use all context invalidation.
>>> + */
>>> +if ( likely(cpu_h
Update Kconfig to select GENERIC_UART_INIT for basic UART init ( find a dt node
and call device specific device_init() ).
Drop `default n if RISCV` statement for config HAS_NS16550 as now ns16550 is
ready to be compiled and used by RISC-V. Also, make the config user selectable
for everyone except
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 are introduces for imsic_init() usage:
- imsic_parse_node() parses IMSIC node from DTS
Implement functions necessarry to have working external interrupts in
hypervisor mode. The following changes are done:
- Add a common function intc_handle_external_irq() to call APLIC specific
function to handle an interrupt.
- Update do_trap() function to handle IRQ_S_EXT case; add the che
The patch series introduces basic UART support (in interrupt mode) and support
of
interrupts for hypervisor mode.
To implement this the following has been added:
- APLIC and IMISC initialization.
- Introduce of intc_hw_operations abstraction.
- Introduce some APLIC and IMSIC operations.
- Introdu
Introduce intc_init() to initialize the interrupt controller using the
registered hardware ops.
Also add intc_route_irq_to_xen() to route IRQs to Xen, with support for
setting IRQ type and priority via new internal helpers intc_set_irq_type()
and intc_set_irq_priority().
Call intc_init() to do bas
Introduce support for IRQ setup on RISC-V by implementing setup_irq() and
__setup_irq(), adapted and extended from an initial implementation by [1].
__setup_irq() does the following:
- Sets up an IRQ action.
- Validates that shared IRQs have non-NULL `dev_id` and are only used when
existin
Introduce interrupt controller descriptor for host APLIC to describe
the low-lovel hardare. It includes implementation of the following functions:
- aplic_irq_startup()
- aplic_irq_enable()
- aplic_irq_disable()
- aplic_set_irq_affinity()
As APLIC is used in MSI mode it requires to enable/disa
aplic_init() function does the following few things:
- checks that IMSIC in device tree node ( by checking msi-parent property
in APLIC node ) is present as current one implmenetaion of AIA is
supported only MSI method.
- initialize IMSIC based on IMSIC device tree node
- Read value of AP
Introduce the intc_hw_operations structure to encapsulate interrupt
controller-specific data and operations. This structure includes:
- A pointer to interrupt controller information (`intc_info`)
- Callbacks to initialize the controller and set IRQ type/priority
- A reference to an interupt control
Implements dt_processor_hartid() to get the hart ID of the given
device tree node and do some checks if CPU is available and given device
tree node has proper riscv,isa property.
As a helper function dt_get_hartid() is introduced to deal specifically
with reg propery of a CPU device node.
Signed-
On Mon, May 26, 2025 at 05:45:59PM +0800, Jiqian Chen wrote:
> When init_msix() fails, current logic return fail and free MSIX-related
> resources in vpci_deassign_device(). But the previous new changes will
> hide MSIX capability and return success, it can't reach
> vpci_deassign_device() to remov
On 6/5/25 4:19 PM, Jan Beulich wrote:
Won't be enough to flushing of guest TLB only during context switch?
"only" is interesting here. Context switches are a relatively frequent
operation, which in addition you want to be fast. If a flush is necessary
there for correctness (e.g. when VMIDs aren
On 6/5/25 02:31, Jan Beulich wrote:
> On 05.06.2025 01:35, Stefano Stabellini wrote:
>> From: Alessandro Zucchelli
>>
>> MISRA C Rule 21.16 states the following: "The pointer arguments to
>> the Standard Library function `memcmp' shall point to either a pointer
>> type, an essentially signed type,
On Mon, May 26, 2025 at 05:45:58PM +0800, Jiqian Chen wrote:
> When init_msi() fails, current logic return fail and free MSI-related
> resources in vpci_deassign_device(). But the previous new changes will
> hide MSI capability and return success, it can't reach
> vpci_deassign_device() to remove r
Le 05/06/2025 à 16:51, Jan Beulich a écrit :
> On 30.05.2025 10:48, Teddy Astie wrote:
>> Introduce vpid_sync_vcpu_context to do a single-context invalidation
>> on the vpid attached to the vcpu as a alternative to per-gva and all-contexts
>> invlidations.
>>
>> Signed-off-by: Teddy Astie
>> ---
>
On Mon, May 26, 2025 at 05:45:57PM +0800, Jiqian Chen wrote:
> When init_rebar() fails, current logic return fail and free Rebar-related
> resources in vpci_deassign_device(). But the previous new changes will
> hide Rebar capability and return success, it can't reach
> vpci_deassign_device() to re
On Mon, May 26, 2025 at 05:45:56PM +0800, 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
"So, refactor it to s
On Thu, Jun 05, 2025 at 04:42:53PM +0200, Jan Beulich wrote:
> On 26.05.2025 17:39, Marek Marczykowski-Górecki wrote:
> > On Mon, May 26, 2025 at 04:08:17PM +0100, Andrew Cooper wrote:
> >> On 25/05/2025 3:15 pm, Marek Marczykowski-Górecki wrote:
> >>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x
On 30.05.2025 10:48, Teddy Astie wrote:
> Introduce vpid_sync_vcpu_context to do a single-context invalidation
> on the vpid attached to the vcpu as a alternative to per-gva and all-contexts
> invlidations.
>
> Signed-off-by: Teddy Astie
> ---
> Extracted from SEV series.
> This will be used for
On Mon, May 26, 2025 at 05:45:55PM +0800, Jiqian Chen wrote:
> When vpci fails to initialize a extended capability of device, it
> just returns an error and vPCI gets disabled for the whole device.
>
> So, add function to hide extended capability when initialization
> fails. And remove the failed
On 25.05.2025 16:15, Marek Marczykowski-Górecki wrote:
> The input handling is already implemented, and that limitation is not
> there anymore.
>
> Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Jan Beulich
On 05.06.2025 16:10, Oleksii Kurochko wrote:
>
> On 6/2/25 1:04 PM, Jan Beulich wrote:
>> On 23.05.2025 11:44, Oleksii Kurochko wrote:
>>> On 5/22/25 6:09 PM, Jan Beulich wrote:
On 22.05.2025 17:53, Oleksii Kurochko wrote:
> On 5/20/25 3:37 PM, Jan Beulich wrote:
>> On 09.05.2025 17:5
On 26.05.2025 17:39, Marek Marczykowski-Górecki wrote:
> On Mon, May 26, 2025 at 04:08:17PM +0100, Andrew Cooper wrote:
>> On 25/05/2025 3:15 pm, Marek Marczykowski-Górecki wrote:
>>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>>> index 25189541244d..3ef819a252e4 100644
>>> --- a/xen/
Hi Michal/Julien,
On 05/06/2025 08:44, Orzel, Michal wrote:
On 04/06/2025 19:43, Ayan Kumar Halder wrote:
Do the arm32 equivalent initialization for commit id ca5df936c4.
This is not a good commit msg.
Also, we somewhat require passing 12 char long IDs.
Modify Arm32 assembly boot code to re
On 6/2/25 1:08 PM, Jan Beulich wrote:
On 23.05.2025 12:27, Oleksii Kurochko wrote:
On 5/20/25 4:38 PM, Jan Beulich wrote:
On 09.05.2025 17:57, Oleksii Kurochko wrote:
--- a/xen/arch/riscv/p2m.c
+++ b/xen/arch/riscv/p2m.c
@@ -1,4 +1,12 @@
#include
+/*
+ * Because of general_preempt_check()
On 05.06.2025 16:15, Alejandro Vallejo wrote:
> On Mon Jun 2, 2025 at 4:24 PM CEST, Jan Beulich wrote:
>> On 02.06.2025 16:19, Alejandro Vallejo wrote:
>>> On Mon Jun 2, 2025 at 9:51 AM CEST, Jan Beulich wrote:
On 30.05.2025 14:02, Alejandro Vallejo wrote:
> --- a/xen/include/asm-generic/d
On Mon Jun 2, 2025 at 4:24 PM CEST, Jan Beulich wrote:
> On 02.06.2025 16:19, Alejandro Vallejo wrote:
>> On Mon Jun 2, 2025 at 9:51 AM CEST, Jan Beulich wrote:
>>> On 30.05.2025 14:02, Alejandro Vallejo wrote:
--- a/xen/include/asm-generic/device.h
+++ b/xen/include/asm-generic/device.h
On 6/2/25 1:04 PM, Jan Beulich wrote:
On 23.05.2025 11:44, Oleksii Kurochko wrote:
On 5/22/25 6:09 PM, Jan Beulich wrote:
On 22.05.2025 17:53, Oleksii Kurochko wrote:
On 5/20/25 3:37 PM, Jan Beulich wrote:
On 09.05.2025 17:57, Oleksii Kurochko wrote:
+static struct page_info *p2m_get_clean_
On 05/06/2025 1:36 pm, Gang Ji wrote:
> The 2 missed ones are: register_runstate_phys_area and
> register_vcpu_time_phys_area.
Fixes: d5df44275e7a ("domain: introduce GADDR based runstate area registration
alternative")
Fixes: 60e544a8c58f ("x86: introduce GADDR based secondary time area
registr
On 05.06.2025 13:16, Andrew Cooper wrote:
> There's already C outside of the ifdefary, proving that it's not included in
> any assembly files.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
Hi Michal,
On 05/06/2025 08:06, Orzel, Michal wrote:
On 04/06/2025 19:43, Ayan Kumar Halder wrote:
Introduce pr_t typedef which is a structure having the prbar and prlar members,
each being structured as the registers of the AArch32 Armv8-R architecture.
Also, define MPU_REGION_RES0 to 0 as t
On Sat May 31, 2025 at 2:51 AM CEST, Stefano Stabellini wrote:
> On Fri, 30 May 2025, Alejandro Vallejo wrote:
>> ... as they can be forward-declared changing arrays for pointers in the
>> function
>> declarations.
>>
>> No functional change.
>>
>> Signed-off-by: Alejandro Vallejo
>> ---
>> xe
On Mon, May 26, 2025 at 05:45:54PM +0800, Jiqian Chen wrote:
> When vpci fails to initialize a legacy capability of device, it just
> returns an error and vPCI gets disabled for the whole device. That
> most likely renders the device unusable, plus possibly causing issues
> to Xen itself if guest
On Thu, Jun 05, 2025 at 03:08:07PM +0200, Jan Beulich wrote:
> On 05.06.2025 14:20, Marek Marczykowski-Górecki wrote:
> > On Thu, Jun 05, 2025 at 02:02:21PM +0200, Jan Beulich wrote:
> >> On 05.06.2025 13:16, Andrew Cooper wrote:
> >>> The format of the buildid is a property of the binary, not a pr
Hi Ayan,
>>> +/* Hypervisor Protection Region Base Address Register */
>>> +typedef union {
>>> +struct {
>>> +unsigned int xn:1; /* Execute-Never */
>>> +unsigned int ap_0:1; /* Acess Permission */
>>> +unsigned long ro:1; /* Access Permission AP[1] */
>
On 04/06/2025 20:19, Luca Fancellu wrote:
Hi Ayan,
Hi Luca,
On 4 Jun 2025, at 18:43, Ayan Kumar Halder wrote:
Introduce pr_t typedef which is a structure having the prbar and prlar members,
each being structured as the registers of the AArch32 Armv8-R architecture.
Also, define MPU_REGIO
1 - 100 of 158 matches
Mail list logo
