On 22.07.2025 02:05, Alejandro Vallejo wrote:
> Hi,
>
> Really minor changes wrt v7
>
> 1. s/BOOTMOD_XSM/BOOTMOD_XSM_POLICY/
> 2. Remove stale obj-y statements in the last patch
>
> pipeline:
> https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/1940366600
>
> v7:
> https://lo
On 22.07.2025 08:59, Penny, Zheng wrote:
> [Public]
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Tuesday, July 22, 2025 1:33 PM
>> To: Penny, Zheng
>> Cc: Huang, Ray ; Stefano Stabellini
>> ; Andrew Cooper ; Roger
>> Pau Monné ; Anthony PERARD
>> ; Orzel, Michal ; Julien
>> Gral
On 22.07.2025 07:04, Penny Zheng wrote:
> Function getdomaininfo() is not only invoked by domctl-op, but also sysctl-op,
> so it shall better live in domain.c, rather than domctl.c. Which is also
> applied for arch_get_domain_info(). Style corrections shall be applied at
> the same time while movin
Hi greg k-h,
On 2025/7/16 16:08, Greg KH wrote:
Signed-off-by: WangYuli
Is your name all one word like that, or should there be a " " between
them?
If I were to follow Western naming conventions, my name would be written
as 'Yuli Wang'.
However, frankly, I find it unnecessary and can't be
There are some spelling mistakes of 'notifer' in comments which
should be 'notifier'.
Fix them and add it to scripts/spelling.txt.
WangYuli (8):
KVM: x86: Fix typo "notifer"
cxl: mce: Fix typo "notifer"
drm/xe: Fix typo "notifer"
net: mvneta: Fix typo "notifer"
wifi: brcmfmac: Fix typo
There is a spelling mistake of 'notifer' in the comment which
should be 'notifier'.
Acked-by: Arend van Spriel
Signed-off-by: WangYuli
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadco
There are some spelling mistakes of 'notifer' which should be 'notifier'.
Signed-off-by: WangYuli
---
arch/x86/kvm/i8254.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
index 739aa6c0d0c3..9ff55112900a 100644
--- a/arch/x86/kv
There is a spelling mistake of 'notifer' in the comment which
should be 'notifier'.
Reviewed-by: Simon Horman
Signed-off-by: WangYuli
---
drivers/net/ethernet/marvell/mvneta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c
b/drivers/ne
According to the context, "mce_notifer" should be "mce_notifier".
Fixes: 516e5bd0b6bf ("cxl: Add mce notifier to emit aliased address for
extended linear cache")
Reviewed-by: Jonathan Cameron
Reviewed-by: Dave Jiang
Signed-off-by: WangYuli
---
drivers/cxl/core/mce.h | 2 +-
1 file changed, 1
There is a spelling mistake of 'notifer' in the comment which
should be 'notifier'.
Reviewed-by: Andy Shevchenko
Signed-off-by: WangYuli
---
drivers/tty/serial/8250/8250_dw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_dw.c
b/drivers/tty/ser
This typo was not listed in scripts/spelling.txt, thus it was more
difficult to detect. Add it for convenience.
Reviewed-by: Jonathan Cameron
Signed-off-by: WangYuli
---
scripts/spelling.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/spelling.txt b/scripts/spelling.txt
index c9
There is a spelling mistake of 'notifer' in the comment which
should be 'notifier'.
Signed-off-by: WangYuli
---
drivers/gpu/drm/xe/xe_vm_types.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xe/xe_vm_types.h b/drivers/gpu/drm/xe/xe_vm_types.h
index 1979e9bdb
There is a spelling mistake of 'notifer' in the comment which
should be 'notifier'.
Reviewed-by: Juergen Gross
Signed-off-by: WangYuli
---
include/xen/xenbus.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
index 3f90bdd387b6..00b
Trying to boot a compressed kernel with UBSAN enabled, results in the
following warning:
(XEN) UBSAN: Undefined behaviour in common/device-tree/kernel.c:21:12
(XEN) load of misaligned address 0a0040f89867 for type 'uint32_t'
(XEN) which requires 4 byte alignment
...
(XEN)[<0a529964>
On Tue, Jul 22, 2025 at 03:22:18PM +0800, WangYuli wrote:
> Hi greg k-h,
>
> On 2025/7/16 16:08, Greg KH wrote:
> > > Signed-off-by: WangYuli
> > Is your name all one word like that, or should there be a " " between
> > them?
>
> If I were to follow Western naming conventions, my name would be w
All,
the release is due in the 1st week of August. Please point out backports you
find
missing from the respective staging branch, but which you consider relevant.
Jan
On 16.07.2025 23:25, Volodymyr Babchuk wrote:
> GCC 15 (with commit "Add prime path coverage to gcc/gcov") added a
> new, tenth counter. Reflect this in gcc_4_7.c.
>
> Signed-off-by: Volodymyr Babchuk
Acked-by: Jan Beulich
On 18.07.2025 12:11, Grygorii Strashko wrote:
> From: Grygorii Strashko
>
> On platforms without PIRQ support evtchn_move_pirqs()/send_guest_pirq()
> functions are unreachable (Misra rule 2.1).
>
> Move these function under CONFIG_HAS_PIRQ ifdefs to fix Misra rule 2.1
> violation and resolve cal
On 17.07.2025 09:31, Andrii Sultanov wrote:
> Following on from 250d87dc3ff9 ("x86/msi: Change __msi_set_enable() to
> take pci_sbdf_t"), make struct amd_iommu contain pci_sbdf_t directly
> instead of specifying seg+bdf separately and regenerating sbdf_t from them,
> which simplifies code.
>
> Blo
On 17.07.2025 09:31, Andrii Sultanov wrote:
> Following a similar change to amd_iommu struct, make two more structs
> take pci_sbdf_t directly instead of seg and bdf separately. This lets us
> drop several conversions from the latter to the former and simplifies
> several comparisons and assignment
Since we move "!PV_SHIM_EXCLUSIVE" dependency from CONFIG_HVM, there is
a chance that a randconfig picking both PV_SHIM_EXCLUSIVE=y and HVM=y results
in hvm.c being built, but monitor.c not being built, which leaves
functions like monitor_traps(), etc, undefined, causing linking to fail.
So we move
Not only domctl-op could do foreign updates to guest state, some hypercall,
like HVMOP_set_param, could also do, and they all need domctl_lock for
syncronization.
Later, we will introduce CONFIG_DOMCTL to wrap domctl.c. In order to
continue using domctl_lock when CONFIG_DOMCTL not defined, we'd lik
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, July 22, 2025 3:16 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Stefano Stabellini
> ; Julien Grall ; Bertrand Marquis
> ; Orzel, Michal ;
> Volodymyr Babchuk ; Andrew Cooper
> ; Anthony PERARD ;
> Roger Pau Monné ; Daniel P.
On 2025-07-21 20:19, Jason Andryuk wrote:
Expose a domain's capabilities - control, hardware or xenstore - through
stable get domain state hypercall.
The xenstore domain can use this information to assign appropriate
permissions on connections.
Repurpose the 16bit pad field for this purpose.
S
From: Denis Mukhin
Introduce domain_console for grouping data structures used for integrating
domain's diagnostic console with Xen's console driver.
Group all pbuf-related data structures under domain_console. Rename the moved
fields to plain .buf, .idx and .lock names, since all uses of the fi
On 2025-07-22 14:07, Teddy Astie wrote:
do_sched_op(SCHEDOP_yield) just calls vcpu_yield(). Remove the indirection
through the hypercall handler and use the function directly.
Perform the same for SCHEDOP_block.
Not a functional change.
Signed-off-by: Teddy Astie
---
xen/arch/x86/hvm/hvm.c
Stewart,
> EXT email: be mindful of links/attachments.
>
> Hi,
>
> It largely looks OK to me, just a few small comments below.
>
> On 7/18/25 05:16, Anderson Choi wrote:
>> ARINC653 specificaion requires partition scheduling to be
>> deterministic
>
> Typo: s/specificaion/specification/
>
Addr
On Tue, 22 Jul 2025, Jan Beulich wrote:
> On 22.07.2025 07:04, Penny Zheng wrote:
> > Function getdomaininfo() is not only invoked by domctl-op, but also
> > sysctl-op,
> > so it shall better live in domain.c, rather than domctl.c. Which is also
> > applied for arch_get_domain_info(). Style correc
On Mon, 21 Jul 2025, Jason Andryuk wrote:
> Expose a domain's capabilities - control, hardware or xenstore - through
> stable get domain state hypercall.
>
> The xenstore domain can use this information to assign appropriate
> permissions on connections.
>
> Repurpose the 16bit pad field for this
On 22.07.2025 14:09, Jason Andryuk wrote:
> On 2025-07-21 20:19, Jason Andryuk wrote:
>> Expose a domain's capabilities - control, hardware or xenstore - through
>> stable get domain state hypercall.
>>
>> The xenstore domain can use this information to assign appropriate
>> permissions on connecti
On 22.07.2025 02:19, Jason Andryuk wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -195,6 +195,14 @@ static void set_domain_state_info(struct
> xen_domctl_get_domain_state *info,
> info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DYING;
> if ( d->is_dying == DOMDYING_d
On 22/07/2025 06:50, Jason Andryuk wrote:
> On 2025-07-22 03:46, Michal Orzel wrote:
>> Trying to boot a compressed kernel with UBSAN enabled, results in the
>> following warning:
>> (XEN) UBSAN: Undefined behaviour in common/device-tree/kernel.c:21:12
>> (XEN) load of misaligned address 0a0
On 23.07.25 08:28, Jan Beulich wrote:
On 22.07.2025 02:19, Jason Andryuk wrote:
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -195,6 +195,14 @@ static void set_domain_state_info(struct
xen_domctl_get_domain_state *info,
info->state |= XEN_DOMCTL_GETDOMSTATE_STATE_DYING;
On 23.07.25 08:25, Jan Beulich wrote:
On 22.07.2025 14:09, Jason Andryuk wrote:
On 2025-07-21 20:19, Jason Andryuk wrote:
Expose a domain's capabilities - control, hardware or xenstore - through
stable get domain state hypercall.
The xenstore domain can use this information to assign appropria
On 23.07.2025 08:34, Jürgen Groß wrote:
> On 23.07.25 08:28, Jan Beulich wrote:
>> On 22.07.2025 02:19, Jason Andryuk wrote:
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -195,6 +195,14 @@ static void set_domain_state_info(struct
>>> xen_domctl_get_domain_state *info,
>>>
Hi,
> On 23 Jul 2025, at 08:33, Orzel, Michal wrote:
>
>
>
> On 22/07/2025 06:50, Jason Andryuk wrote:
>> On 2025-07-22 03:46, Michal Orzel wrote:
>>> Trying to boot a compressed kernel with UBSAN enabled, results in the
>>> following warning:
>>> (XEN) UBSAN: Undefined behaviour in common/dev
On 2025/7/21 22:16, Roger Pau Monné wrote:
> On Wed, Jul 09, 2025 at 05:34:28AM +, Chen, Jiqian wrote:
>> On 2025/7/9 13:32, Jan Beulich wrote:
>>> On 09.07.2025 07:29, Chen, Jiqian wrote:
On 2025/7/8 22:10, Jan Beulich wrote:
> On 04.07.2025 09:07, Jiqian Chen wrote:
>> --- a/xen/
On 22.07.2025 12:41, Oleksii Kurochko wrote:
> On 7/21/25 2:18 PM, Jan Beulich wrote:
>> On 18.07.2025 11:52, Oleksii Kurochko wrote:
>>> On 7/17/25 12:25 PM, Jan Beulich wrote:
On 17.07.2025 10:56, Oleksii Kurochko wrote:
> On 7/16/25 6:18 PM, Jan Beulich wrote:
>> On 16.07.2025 18:07
On 22.07.2025 13:41, Oleksii Moisieiev wrote:
> This commit introduces two helper functions, `__memcpy_fromio` and
> `__memcpy_toio`, to provide a robust mechanism for copying data between
> standard memory and memory-mapped I/O (MMIO) space for the ARM
> architecture.
>
> These functions are desi
On 22.07.2025 13:41, Oleksii Moisieiev wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1105,6 +1105,15 @@ which serves as Driver domain. The SCMI will be
> disabled for Dom0/hwdom and
> SCMI nodes removed from Dom0/hwdom device tree.
> (for exampl
On 22.07.2025 14:37, Alejandro Vallejo wrote:
> On Tue Jul 22, 2025 at 2:18 PM CEST, Jan Beulich wrote:
>> On 22.07.2025 13:59, Alejandro Vallejo wrote:
>>> Reduce the scope of every variable so they are reinitialised. "iommu",
>>> for instance, isn't being cleared, so the wrong flags may make it t
On 7/22/25 12:41 PM, Oleksii Kurochko wrote:
On 7/21/25 2:18 PM, Jan Beulich wrote:
On 18.07.2025 11:52, Oleksii Kurochko wrote:
On 7/17/25 12:25 PM, Jan Beulich wrote:
On 17.07.2025 10:56, Oleksii Kurochko wrote:
On 7/16/25 6:18 PM, Jan Beulich wrote:
On 16.07.2025 18:07, Oleksii Kurochk
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
Change -ENOPNOTSUPP error code to -ENXIO when iommu is disabled during
iommu_do_domctl call. As was discussed in [1]
[0]:
https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2506171701190.1780597@ubuntu-linux-20-04-desktop/
Signed-off-by: Oleksii Moisieiev
---
Changes in v5:
- set error code
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
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
---
Changes in v5:
- rename dom0_scmi_smc_passthrough in documentation
.../arm/firmware/arm-scmi.rst
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 |
+---
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
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
This commit introduces two helper functions, `__memcpy_fromio` and
`__memcpy_toio`, to provide a robust mechanism for copying data between
standard memory and memory-mapped I/O (MMIO) space for the ARM
architecture.
These functions are designed to handle memory transfers safely,
accounting for pot
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
It deals with a single domain, and will be called on a later patch
by a new function parse_dom0less_node(), so the new name is apt.
Also, pass parameters using boot_domain instead as the plan is to use it
as dumping gound for all the extracted information from the bindings.
Not a functional chang
Later patches move the bindings to a separate function and expect the
outputs to land in fields of a boot_domain. Adjust llc_color_str to
live inside boot_domain so it can be parsed later on.
Not a functional change.
Signed-off-by: Alejandro Vallejo
---
xen/common/device-tree/dom0less-build.c |
Reduce the scope of every variable so they are reinitialised. "iommu",
for instance, isn't being cleared, so the wrong flags may make it to
domains that should not have them.
Fixes: 1d2b4f3049fd("xen/arm, doc: Add a DT property to specify...")
Signed-off-by: Alejandro Vallejo
---
This is implicit
Hi,
pipeline:
https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/1941315850
With boot_domain common between architectures, we're now in a position to use
it as the common ground to dump results of dom0less bindings. This series is
largely code motion with a few tweaks to make it sim
In preparation for it to be usable on x86 with IBT, tag targets of
function pointers with cf_check
Signed-off-by: Alejandro Vallejo
Acked-by: Stefano Stabellini
Reviewed-by: Jason Andryuk
Reviewed-by: Edgar E. Iglesias
---
xen/common/device-tree/device-tree.c | 28 ++--
From: Alejandro Vallejo
When later on x86 starts using this file in later patches it won't find
device_tree.h because it's only transitively included by arm.
Make it explicit.
Not a functional change.
Signed-off-by: Alejandro Vallejo
Acked-by: Stefano Stabellini
Reviewed-by: Jason Andryuk
-
On 22.07.2025 13:34, Oleksii Kurochko wrote:
>
> On 7/22/25 12:41 PM, Oleksii Kurochko wrote:
>>
>>
>> On 7/21/25 2:18 PM, Jan Beulich wrote:
>>> On 18.07.2025 11:52, Oleksii Kurochko wrote:
On 7/17/25 12:25 PM, Jan Beulich wrote:
> On 17.07.2025 10:56, Oleksii Kurochko wrote:
>> On 7
In later patches boot_domain becomes the common ground for the bindings
to drop the extracted information. In preparation for the bindings
themselves to be in a separate function, introduce kernel_info early in
the domain construction loop.
This simplifies a later diff, turning it into a strict cu
It's meant to be usable by anyone with CONFIG_DOM0LESS_BOOT.
While moving, replace an inclusion of public/domctl.h by a forward
declaration.
Signed-off-by: Alejandro Vallejo
---
xen/arch/arm/dom0less-build.c | 2 +-
xen/arch/arm/domain_build.c | 2 +-
x
Add the arguments that create_domain() takes to boot_domain. This creates
a consistent place to drop the outputs of the dom0less bindings.
Not a functional change. Later patches use these fields as the outputs of
the dom0less parsing functions.
Signed-off-by: Alejandro Vallejo
Acked-by: Stefano
The builder in common code already does this, but it's not callable
independently from a separate location. Create a function x86 can
call to use its own domain builder, using createdomain arguments
as the parsed data.
The bindings are moved on the next patch so it's strict code motion.
Signed-of
Let the function return an errno, so fallible bindings are not precluded.
Signed-off-by: Alejandro Vallejo
---
xen/arch/arm/dom0less-build.c | 6 --
xen/common/device-tree/dom0less-build.c | 3 ++-
xen/include/xen/dom0less-build.h| 6 +++---
3 files changed, 9 insertions(+)
On 7/21/25 3:39 PM, Jan Beulich wrote:
On 18.07.2025 16:37, Oleksii Kurochko wrote:
On 7/2/25 12:28 PM, Jan Beulich wrote:
On 02.07.2025 12:09, Jan Beulich wrote:
On 10.06.2025 15:05, Oleksii Kurochko wrote:
@@ -613,3 +612,91 @@ void __iomem *ioremap(paddr_t pa, size_t len)
{
retur
On 22.07.2025 14:03, Oleksii Kurochko wrote:
> On 7/21/25 3:39 PM, Jan Beulich wrote:
>> On 18.07.2025 16:37, Oleksii Kurochko wrote:
>>> On 7/2/25 12:28 PM, Jan Beulich wrote:
On 02.07.2025 12:09, Jan Beulich wrote:
> On 10.06.2025 15:05, Oleksii Kurochko wrote:
>> @@ -613,3 +612,91 @
On 22.07.2025 13:59, Alejandro Vallejo wrote:
> From: Alejandro Vallejo
>
> When later on x86 starts using this file in later patches it won't find
> device_tree.h because it's only transitively included by arm.
>
> Make it explicit.
>
> Not a functional change.
>
> Signed-off-by: Alejandro Va
On 22.07.2025 15:31, Alejandro Vallejo wrote:
> On Tue Jul 22, 2025 at 2:57 PM CEST, Jan Beulich wrote:
>> On 22.07.2025 14:37, Alejandro Vallejo wrote:
>>> On Tue Jul 22, 2025 at 2:18 PM CEST, Jan Beulich wrote:
On 22.07.2025 13:59, Alejandro Vallejo wrote:
> Reduce the scope of every var
On 7/21/25 3:42 PM, Jan Beulich wrote:
On 18.07.2025 16:49, Oleksii Kurochko wrote:
On 7/2/25 12:09 PM, Jan Beulich wrote:
On 10.06.2025 15:05, Oleksii Kurochko wrote:
Implement the mfn_valid() macro to verify whether a given MFN is valid by
checking that it falls within the range [start_page
On 22.07.25 11:23, Jan Beulich wrote:
On 18.07.2025 12:11, Grygorii Strashko wrote:
From: Grygorii Strashko
On platforms without PIRQ support evtchn_move_pirqs()/send_guest_pirq()
functions are unreachable (Misra rule 2.1).
Move these function under CONFIG_HAS_PIRQ ifdefs to fix Misra rule
On Tue, 2025-07-22 at 15:34 +0800, WangYuli wrote:
> There is a spelling mistake of 'notifer' in the comment which
> should be 'notifier'.
>
> Signed-off-by: WangYuli
Reviewed-by: Thomas Hellström
> ---
> drivers/gpu/drm/xe/xe_vm_types.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
On 22.07.2025 13:59, Alejandro Vallejo wrote:
> Reduce the scope of every variable so they are reinitialised. "iommu",
> for instance, isn't being cleared, so the wrong flags may make it to
> domains that should not have them.
Yet "for instance" isn't quite right, is it? "iommu" is the only one wh
On 22.07.2025 13:41, Oleksii Moisieiev wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1096,6 +1096,15 @@ affinities to prefer but be not limited to the
> specified node(s).
>
> Pin dom0 vcpus to their respective pcpus
>
> +### scmi_smc_passthr
On 22.07.2025 13:41, Oleksii Moisieiev wrote:
> Change -ENOPNOTSUPP error code to -ENXIO when iommu is disabled during
> iommu_do_domctl call. As was discussed in [1]
>
> [0]:
> https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2506171701190.1780597@ubuntu-linux-20-04-desktop/
Hmm, I can't r
On 22.07.2025 13:41, Oleksii Moisieiev wrote:
> @@ -859,7 +860,25 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
> u_domctl)
> case XEN_DOMCTL_test_assign_device:
> case XEN_DOMCTL_deassign_device:
> case XEN_DOMCTL_get_device_group:
> +int ret1;
> +
>
On Tue Jul 22, 2025 at 2:18 PM CEST, Jan Beulich wrote:
> On 22.07.2025 13:59, Alejandro Vallejo wrote:
>> Reduce the scope of every variable so they are reinitialised. "iommu",
>> for instance, isn't being cleared, so the wrong flags may make it to
>> domains that should not have them.
>
> Yet "fo
On Tue Jul 22, 2025 at 2:10 PM CEST, Jan Beulich wrote:
> On 22.07.2025 13:59, Alejandro Vallejo wrote:
>> From: Alejandro Vallejo
>>
>> When later on x86 starts using this file in later patches it won't find
>> device_tree.h because it's only transitively included by arm.
>>
>> Make it explicit
Add a guest config parameter "xenstore_feature_mask" allowing to limit
the Xenstore features the guest can see and use. This can be needed in
order to allow migrating a guest to a host running a Xenstore version
providing less features than the source host.
Signed-off-by: Juergen Gross
---
docs/
Xen currently uses an ASID scheme where:
- ASIDs are cycled where a "TLB flush" is performed
- When ASIDs wrap around, perform a full TLB flush
- In exceptional cases, stop using ASIDs
However, the TLB control mode used only flushes the current active ASID of
the logical processor. Which mean that
On 7/22/25 2:00 PM, Jan Beulich wrote:
On 22.07.2025 13:34, Oleksii Kurochko wrote:
On 7/22/25 12:41 PM, Oleksii Kurochko wrote:
On 7/21/25 2:18 PM, Jan Beulich wrote:
On 18.07.2025 11:52, Oleksii Kurochko wrote:
On 7/17/25 12:25 PM, Jan Beulich wrote:
On 17.07.2025 10:56, Oleksii Kurochko
Ping for additional reviews. Especially patches 3, 4, and 5, which cover
a wide range of drivers..
Am 13.06.25 um 11:00 schrieb Thomas Zimmermann:
Dumb-buffer pitch and size is specified by width, height, bits-per-pixel
plus various hardware-specific alignments. The calculation of these
values
Ping for additional reviews. Especially patches 3, 4, and 5, which cover
a wide range of drivers..
Am 13.06.25 um 11:00 schrieb Thomas Zimmermann:
Dumb-buffer pitch and size is specified by width, height, bits-per-pixel
plus various hardware-specific alignments. The calculation of these
values
On 22.07.2025 16:25, Oleksii Kurochko wrote:
> On 7/22/25 2:00 PM, Jan Beulich wrote:
>> On 22.07.2025 13:34, Oleksii Kurochko wrote:
>>> On 7/22/25 12:41 PM, Oleksii Kurochko wrote:
On 7/21/25 2:18 PM, Jan Beulich wrote:
> On 18.07.2025 11:52, Oleksii Kurochko wrote:
>> On 7/17/25 12:
On Tue Jul 22, 2025 at 9:00 AM CEST, Jan Beulich wrote:
> On 22.07.2025 02:05, Alejandro Vallejo wrote:
>> Hi,
>>
>> Really minor changes wrt v7
>>
>> 1. s/BOOTMOD_XSM/BOOTMOD_XSM_POLICY/
>> 2. Remove stale obj-y statements in the last patch
>>
This pipeline turned green on the build each c
On Tue Jul 22, 2025 at 2:57 PM CEST, Jan Beulich wrote:
> On 22.07.2025 14:37, Alejandro Vallejo wrote:
>> On Tue Jul 22, 2025 at 2:18 PM CEST, Jan Beulich wrote:
>>> On 22.07.2025 13:59, Alejandro Vallejo wrote:
Reduce the scope of every variable so they are reinitialised. "iommu",
for i
On 17.07.2025 19:51, Alejandro Vallejo wrote:
> Make alloc_dom0_vcpu0() viable as a general vcpu0 allocator. Keep
> behaviour on any hwdom/ctldom identical to that dom0 used to have, and
> make non-dom0 have auto node affinity.
>
> Rename the function to alloc_dom_vcpu0() to reflect this change in
On 16.07.2025 22:15, Petr Beneš wrote:
> From: Petr Beneš
>
> Wrap the p2m_is_altp2m() check with IS_ENABLED(CONFIG_ALTP2M) to allow the
> compiler to short-circuit the condition at build time when ALTP2M is disabled.
>
> Signed-off-by: Petr Beneš
Reviewed-by: Jan Beulich
On 16.07.2025 22:15, Petr Beneš wrote:
> From: Petr Beneš
>
> The p2m_altp2m_check() stub was previously declared on all architectures,
> even though the altp2m feature is only supported on x86. This patch removes
> the unused stub definitions from ARM, PPC, and RISC-V, and wraps the actual
> usa
On 7/21/25 3:34 PM, Jan Beulich wrote:
On 17.07.2025 18:37, Oleksii Kurochko wrote:
On 7/2/25 11:25 AM, Jan Beulich wrote:
On 10.06.2025 15:05, Oleksii Kurochko wrote:
Add support for down large memory mappings ("superpages") in the RISC-V
p2m mapping so that smaller, more precise mappings ("
On Wed, Jul 16, 2025 at 06:31:03PM +0200, Jan Beulich wrote:
> On 16.07.2025 18:00, Roger Pau Monne wrote:
> > In a livepatch payload relocations will refer to included functions. If
> > that function happens to be a replacement for an existing Xen function, the
> > relocations on the livepatch pa
On Mon, Jul 21, 2025 at 04:51:33PM +0100, Ross Lagerwall wrote:
> On Wed, Jul 16, 2025 at 5:00 PM Roger Pau Monne wrote:
> >
> > In a livepatch payload relocations will refer to included functions. If
> > that function happens to be a replacement for an existing Xen function, the
> > relocations
On 22.07.2025 17:02, Roger Pau Monné wrote:
> On Wed, Jul 16, 2025 at 06:31:03PM +0200, Jan Beulich wrote:
>> On 16.07.2025 18:00, Roger Pau Monne wrote:
>>> In a livepatch payload relocations will refer to included functions. If
>>> that function happens to be a replacement for an existing Xen fu
On 22.07.2025 16:57, Oleksii Kurochko wrote:
>
> On 7/21/25 3:34 PM, Jan Beulich wrote:
>> On 17.07.2025 18:37, Oleksii Kurochko wrote:
>>> On 7/2/25 11:25 AM, Jan Beulich wrote:
On 10.06.2025 15:05, Oleksii Kurochko wrote:
> Add support for down large memory mappings ("superpages") in th
On Tue Jul 22, 2025 at 4:45 PM CEST, Jan Beulich wrote:
> On 17.07.2025 19:51, Alejandro Vallejo wrote:
>> Make alloc_dom0_vcpu0() viable as a general vcpu0 allocator. Keep
>> behaviour on any hwdom/ctldom identical to that dom0 used to have, and
>> make non-dom0 have auto node affinity.
>>
>> Ren
On July 22, 2025 12:57:33 AM PDT, Greg KH wrote:
>On Tue, Jul 22, 2025 at 03:22:18PM +0800, WangYuli wrote:
>> Hi greg k-h,
>>
>> On 2025/7/16 16:08, Greg KH wrote:
>> > > Signed-off-by: WangYuli
>> > Is your name all one word like that, or should there be a " " between
>> > them?
>>
>> If I we
Hi Jan,
On 22/07/2025 15:21, Jan Beulich wrote:
> On 22.07.2025 13:41, Oleksii Moisieiev wrote:
>> --- a/docs/misc/xen-command-line.pandoc
>> +++ b/docs/misc/xen-command-line.pandoc
>> @@ -1096,6 +1096,15 @@ affinities to prefer but be not limited to the
>> specified node(s).
>>
>> Pin dom0
On 16.07.2025 22:15, Petr Beneš wrote:
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -2686,8 +2686,8 @@ static int cf_check hvmemul_tlb_op(
> return rc;
> }
>
> -static int cf_check hvmemul_vmfunc(
> -struct x86_emulate_ctxt *ctxt)
> +#ifdef CONFIG_ALTP2M
>
On 7/22/25 4:35 PM, Jan Beulich wrote:
On 22.07.2025 16:25, Oleksii Kurochko wrote:
On 7/22/25 2:00 PM, Jan Beulich wrote:
On 22.07.2025 13:34, Oleksii Kurochko wrote:
On 7/22/25 12:41 PM, Oleksii Kurochko wrote:
On 7/21/25 2:18 PM, Jan Beulich wrote:
On 18.07.2025 11:52, Oleksii Kurochko w
On 2025-07-22 03:46, Michal Orzel wrote:
Trying to boot a compressed kernel with UBSAN enabled, results in the
following warning:
(XEN) UBSAN: Undefined behaviour in common/device-tree/kernel.c:21:12
(XEN) load of misaligned address 0a0040f89867 for type 'uint32_t'
(XEN) which requires 4 byte
do_sched_op(SCHEDOP_yield) just calls vcpu_yield(). Remove the indirection
through the hypercall handler and use the function directly.
Perform the same for SCHEDOP_block.
Not a functional change.
Signed-off-by: Teddy Astie
---
xen/arch/x86/hvm/hvm.c | 3 ++-
xen/arch/x86/hvm/svm
1 - 100 of 127 matches
Mail list logo
