Ping?
On 30.07.25 14:23, Juergen Gross wrote:
Live update is now working with the PVH variant of xenstore-stubdom.
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
SUPPORT.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/SUPPORT.md b/SUPPORT.md
index 6a82a92189..eb
Ping?
On 30.07.25 14:23, Juergen Gross wrote:
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
CHANGELOG.md | 1 +
1 file changed, 1 insertion(+)
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 5f31ca08fe..d118bb1c8c 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -26,6 +26,7 @@ The form
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Monday, August 18, 2025 4:31 PM
> To: Penny, Zheng ; Oleksii Kurochko
>
> Cc: Huang, Ray ; Andrew Cooper
> ; Roger Pau Monné ;
> Anthony PERARD ; Orzel, Michal
> ; Julien Grall ; Stefano Stabellini
> ; xen-devel@lists.xenproject.o
On Thu, Aug 14, 2025 at 09:11:11AM +0200, Jan Beulich wrote:
> On 13.08.2025 00:30, dm...@proton.me wrote:
> > From: Denis Mukhin
> >
> > Currently, there are two different domain ID allocation implementations:
> >
> > 1) Sequential IDs allocation in dom0less Arm code based on max_init_domid;
>
On Tue, 18 Aug 2025, Jan Beulich wrote:
> On 19.08.2025 01:45, Stefano Stabellini wrote:
> > On Mon, 18 Aug 2025, Dmytro Prokopchuk1 wrote:
> >> On 8/4/25 11:02, Jan Beulich wrote:
> >>> On 02.08.2025 19:48, Dmytro Prokopchuk1 wrote:
> There are a lot of MISRA C R17.7 violations in the XEN.
>
On Tue, Aug 19, 2025 at 08:37:00PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Block layer maps MMIO memory through dma_map_phys() interface
> with help of DMA_ATTR_MMIO attribute. There is a need to unmap
> that memory with the appropriate unmap function, something which
> wasn't p
On 19/08/2025 1:04 pm, Jan Beulich wrote:
> On 15.08.2025 22:41, Andrew Cooper wrote:
>> We want a consistent MSR API, and these want to be named rdmsr() and wrmsr(),
>> but not with their current APIs. The current rdmsr() flavours writing to
>> their parameters by name makes code that reads like
Rule 11.1 states as following: "Conversions shall not be performed
between a pointer to a function and any other type."
The conversion from unsigned long or (void *) to a function pointer
is safe in Xen because the architectures it supports (e.g., x86 and
ARM) guarantee compatible representations
On Tue, Aug 19, 2025, at 20:20, Keith Busch wrote:
> On Tue, Aug 19, 2025 at 08:36:58PM +0300, Leon Romanovsky wrote:
>> static bool blk_dma_map_direct(struct request *req, struct device *dma_dev,
>> struct blk_dma_iter *iter, struct phys_vec *vec)
>> {
>> -iter->addr = dma_ma
On 18/08/2025 8:57 am, Jan Beulich wrote:
> --- a/xen/arch/x86/include/asm/mm.h
> +++ b/xen/arch/x86/include/asm/mm.h
> @@ -464,6 +464,16 @@ extern bool opt_pv_linear_pt;
> ASSERT(((_p)->count_info & PGC_count_mask) != 0); \
> ASSERT(page_get_owner(_p) == (_d))
>
> +#define RAM
On Tue, Aug 19, 2025 at 08:36:59PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Make sure that CPU is not synced and IOMMU is configured to take
> MMIO path by providing newly introduced DMA_ATTR_MMIO attribute.
We may have a minor patch conflict here with my unmerged dma metadata
s
On 8/19/25 18:42, Jan Beulich wrote:
> On 19.08.2025 16:32, Dmytro Prokopchuk1 wrote:
>> On 8/19/25 16:25, Jan Beulich wrote:
>>> On 19.08.2025 15:12, Dmytro Prokopchuk1 wrote:
MISRA C Rule 2.1 states: "A project shall not contain unreachable code."
The function 'PrintErrMesg()' is
On 19/08/2025 6:18 pm, Roger Pau Monne wrote:
> Otherwise the PCI accesses to segments different than the first one done by
> the IOMMU initialization code would silently fail by returning all ones.
>
> Introduce a new helper, called pci_setup(), and move both the creation of
> PCI segment 0 intern
On Tue, Aug 19, 2025 at 08:36:55PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Introduce new DMA mapping functions dma_map_phys() and dma_unmap_phys()
> that operate directly on physical addresses instead of page+offset
> parameters. This provides a more efficient interface for driv
On Tue, Aug 19, 2025 at 08:36:58PM +0300, Leon Romanovsky wrote:
> static bool blk_dma_map_direct(struct request *req, struct device *dma_dev,
> struct blk_dma_iter *iter, struct phys_vec *vec)
> {
> - iter->addr = dma_map_page(dma_dev, phys_to_page(vec->paddr),
> -
On 2025-08-18 03:57, Jan Beulich wrote:
The classification is pretty E820-centric anyway, and all uses of the
function are now in x86-only code.
Switch the boolean return type to properly use bool while at it.
Signed-off-by: Jan Beulich
Reviewed-by: Jason Andryuk
On 2025-08-18 03:55, Jan Beulich wrote:
Its uses in offline_page() and query_page_offline() make it reachable on
Arm, as long as XEN_SYSCTL_page_offline_op doesn't have any Arm-specific
code added. It being reachable was even mentioned in the commit
introducing it, claiming it "clearly shouldn't
From: Leon Romanovsky
Extend base DMA page API to handle MMIO flow and follow
existing dma_map_resource() implementation to rely on dma_map_direct()
only to take DMA direct path.
Signed-off-by: Leon Romanovsky
---
kernel/dma/mapping.c | 26 +-
1 file changed, 21 inserti
From: Leon Romanovsky
Convert the KMSAN DMA handling function from page-based to physical
address-based interface.
The refactoring renames kmsan_handle_dma() parameters from accepting
(struct page *page, size_t offset, size_t size) to (phys_addr_t phys,
size_t size). The existing semantics where
From: Leon Romanovsky
Block layer maps MMIO memory through dma_map_phys() interface
with help of DMA_ATTR_MMIO attribute. There is a need to unmap
that memory with the appropriate unmap function, something which
wasn't possible before adding new REQ attribute to block layer in
previous patch.
Si
From: Leon Romanovsky
Rename the IOMMU DMA mapping functions to better reflect their actual
calling convention. The functions iommu_dma_map_page() and
iommu_dma_unmap_page() are renamed to iommu_dma_map_phys() and
iommu_dma_unmap_phys() respectively, as they already operate on physical
addresses
From: Leon Romanovsky
In case peer-to-peer transaction traverses through host bridge,
the IOMMU needs to have IOMMU_MMIO flag, together with skip of
CPU sync.
The latter was handled by provided DMA_ATTR_SKIP_CPU_SYNC flag,
but IOMMU flag was missed, due to assumption that such memory
can be trea
From: Leon Romanovsky
Introduce new DMA mapping functions dma_map_phys() and dma_unmap_phys()
that operate directly on physical addresses instead of page+offset
parameters. This provides a more efficient interface for drivers that
already have physical addresses available.
The new functions are
From: Leon Romanovsky
Convert HMM DMA operations from the legacy page-based API to the new
physical address-based dma_map_phys() and dma_unmap_phys() functions.
This demonstrates the preferred approach for new code that should use
physical addresses directly rather than page+offset parameters.
T
From: Leon Romanovsky
General dma_direct_map_resource() is going to be removed
in next patch, so simply open-code it in xen driver.
Reviewed-by: Juergen Gross
Signed-off-by: Leon Romanovsky
---
drivers/xen/swiotlb-xen.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(
From: Leon Romanovsky
After introduction of dma_map_phys(), there is no need to convert
from physical address to struct page in order to map page. So let's
use it directly.
Signed-off-by: Leon Romanovsky
---
block/blk-mq-dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --g
From: Leon Romanovsky
Convert the DMA direct mapping functions to accept physical addresses
directly instead of page+offset parameters. The functions were already
operating on physical addresses internally, so this change eliminates
the redundant page-to-physical conversion at the API boundary.
From: Leon Romanovsky
Make sure that CPU is not synced and IOMMU is configured to take
MMIO path by providing newly introduced DMA_ATTR_MMIO attribute.
Signed-off-by: Leon Romanovsky
---
block/blk-mq-dma.c | 13 +++--
include/linux/blk-mq-dma.h | 6 +-
include/linux/blk_ty
From: Leon Romanovsky
As a preparation for following map_page -> map_phys API conversion,
let's rename trace_dma_*map_page() to be trace_dma_*map_phys().
Signed-off-by: Leon Romanovsky
---
include/trace/events/dma.h | 4 ++--
kernel/dma/mapping.c | 4 ++--
2 files changed, 4 insertions(+
From: Leon Romanovsky
Combine iommu_dma_*map_phys with iommu_dma_*map_resource interfaces in
order to allow single phys_addr_t flow.
In the following patches, the iommu_dma_map_resource() will be removed
in favour of iommu_dma_map_phys(..., attrs | DMA_ATTR_MMIO) flow.
Signed-off-by: Leon Roman
From: Leon Romanovsky
This will replace the hacky use of DMA_ATTR_SKIP_CPU_SYNC to avoid
touching the possibly non-KVA MMIO memory.
Also correct the incorrect caching attribute for the IOMMU, MMIO
memory should not be cachable inside the IOMMU mapping or it can
possibly create system problems. S
Changelog:
v4:
* Fixed kbuild error with mismatch in kmsan function declaration due to
rebase error.
v3: https://lore.kernel.org/all/cover.1755193625.git.l...@kernel.org
* Fixed typo in "cacheable" word
* Simplified kmsan patch a lot to be simple argument refactoring
v2: https://lore.kernel.o
From: Leon Romanovsky
This patch introduces the DMA_ATTR_MMIO attribute to mark DMA buffers
that reside in memory-mapped I/O (MMIO) regions, such as device BARs
exposed through the host bridge, which are accessible for peer-to-peer
(P2P) DMA.
This attribute is especially useful for exporting dev
From: Leon Romanovsky
Convert the DMA debug infrastructure from page-based to physical address-based
mapping as a preparation to rely on physical address for DMA mapping routines.
The refactoring renames debug_dma_map_page() to debug_dma_map_phys() and
changes its signature to accept a phys_addr
Otherwise the PCI accesses to segments different than the first one done by
the IOMMU initialization code would silently fail by returning all ones.
Introduce a new helper, called pci_setup(), and move both the creation of
PCI segment 0 internal data structures, plus the parsing of ACPI MMCFG
tabl
On 19.08.2025 15:52, Andrew Cooper wrote:
> On 18/08/2025 12:27 pm, Jan Beulich wrote:
>> On 15.08.2025 22:41, Andrew Cooper wrote:
>>> ... on capable toolchains.
>>>
>>> This avoids needing to hold rc in a register across the RDMSR, and in most
>>> cases removes direct testing and branching based
On 19.08.2025 15:35, Andrew Cooper wrote:
> On 19/08/2025 2:28 pm, Andrew Cooper wrote:
>> On 18/08/2025 12:23 pm, Jan Beulich wrote:
>>> On 15.08.2025 22:41, Andrew Cooper wrote:
... in preparation to be able to use asm goto.
Notably this mean that the value parameter must be taken
On 19.08.2025 16:32, Dmytro Prokopchuk1 wrote:
> On 8/19/25 16:25, Jan Beulich wrote:
>> On 19.08.2025 15:12, Dmytro Prokopchuk1 wrote:
>>> MISRA C Rule 2.1 states: "A project shall not contain unreachable code."
>>>
>>> The function 'PrintErrMesg()' is implemented to never return control to
>>> it
On 8/19/25 16:25, Jan Beulich wrote:
> On 19.08.2025 15:12, Dmytro Prokopchuk1 wrote:
>> MISRA C Rule 2.1 states: "A project shall not contain unreachable code."
>>
>> The function 'PrintErrMesg()' is implemented to never return control to
>> its caller. At the end of its execution, it calls 'ble
On 18/08/2025 12:27 pm, Jan Beulich wrote:
> On 15.08.2025 22:41, Andrew Cooper wrote:
>> ... on capable toolchains.
>>
>> This avoids needing to hold rc in a register across the RDMSR, and in most
>> cases removes direct testing and branching based on rc, as the fault label
>> can
>> be rearrange
On 19/08/2025 2:28 pm, Andrew Cooper wrote:
> On 18/08/2025 12:23 pm, Jan Beulich wrote:
>> On 15.08.2025 22:41, Andrew Cooper wrote:
>>> ... in preparation to be able to use asm goto.
>>>
>>> Notably this mean that the value parameter must be taken by pointer rather
>>> than by value.
>>>
>>> No f
On 18/08/2025 12:23 pm, Jan Beulich wrote:
> On 15.08.2025 22:41, Andrew Cooper wrote:
>> ... in preparation to be able to use asm goto.
>>
>> Notably this mean that the value parameter must be taken by pointer rather
>> than by value.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper
On 19.08.2025 15:12, Dmytro Prokopchuk1 wrote:
> MISRA C Rule 2.1 states: "A project shall not contain unreachable code."
>
> The function 'PrintErrMesg()' is implemented to never return control to
> its caller. At the end of its execution, it calls 'blexit()', which, in
> turn, invokes '__builtin
On 15.08.2025 22:41, Andrew Cooper wrote:
> It turns out that using the higher level helpers adjacent like this leads to
> terrible code generation. Due to -fno-strict-alising, the store into state->
> invalidates the read_cr4() address calculation (which is really cpu_info->cr4
> under the hood),
MISRA C Rule 2.1 states: "A project shall not contain unreachable code."
The function 'PrintErrMesg()' is implemented to never return control to
its caller. At the end of its execution, it calls 'blexit()', which, in
turn, invokes '__builtin_unreachable()'. This makes the 'return false;'
statement
On 15.08.2025 22:41, Andrew Cooper wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2733,8 +2733,8 @@ static uint64_t cf_check vmx_get_reg(struct vcpu *v,
> unsigned int reg)
> case MSR_SHADOW_GS_BASE:
> if ( v != curr )
> return v->arch
On 15.08.2025 22:41, Andrew Cooper wrote:
> Right now they're inline in {read,write}_gs_shadow(), but we're going to need
> to use these elsewhere to support FRED.
But why "kern"? We're not dealing with GS in kernel / user terms, but in
real / shadow ones. I'm also not quite happy with the double
On 19/08/2025 11:42 am, Jan Beulich wrote:
> On 15.08.2025 22:41, Andrew Cooper wrote:
>> Now that content has been split out, minimise the header files as msr.h is
>> included by many translation units. A few more TUs were pulling dependencies
>> in transitively, so fix them up.
>>
>> Give asm/ti
On 15.08.2025 22:41, Andrew Cooper wrote:
> Most MSR accesses have compile time constant indexes. By using the immediate
> form when available, the decoder can start issuing uops directly for the
> relevant MSR, rather than having to issue uops to implement "switch (%ecx)".
> Modern CPUs have tens
On 15.08.2025 22:41, Andrew Cooper wrote:
> --- a/xen/arch/x86/nmi.c
> +++ b/xen/arch/x86/nmi.c
> @@ -218,16 +218,16 @@ void disable_lapic_nmi_watchdog(void)
> return;
> switch (boot_cpu_data.x86_vendor) {
> case X86_VENDOR_AMD:
> -wrmsr(MSR_K7_EVNTSEL0, 0, 0);
> +
On 18.08.2025 13:34, Andrew Cooper wrote:
> On 15/08/2025 9:41 pm, Andrew Cooper wrote:
>> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
>> index 530b9eb39abc..9c6b8c291d6e 100644
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -329,6 +329,7 @@ stati
On 15.08.2025 22:41, Andrew Cooper wrote:
> We want a consistent MSR API, and these want to be named rdmsr() and wrmsr(),
> but not with their current APIs. The current rdmsr() flavours writing to
> their parameters by name makes code that reads like invalid C, and is
> unergonomic to use in lots
On 15.08.2025 22:41, Andrew Cooper wrote:
> We're about to turn the rdmsr() macro into a real function, at which point
> Eclair complains that we're now shadowing an identifer.
>
> Rename rdmsr to is_rdmsr.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
> -
Define the requirements which are common for all the commands.
Signed-off-by: Ayan Kumar Halder
---
Changes from -
v1 - 1. Fixed `XenProd~version_hyp_ret_val~1` requirement as Xen does not return
0 for success in all the cases.
2. Reworded the requirements so as to write them from Xen's perspect
We have written the requirements for some of the commands of the XEN_VERSION
hypercall.
Signed-off-by: Ayan Kumar Halder
---
Changes from -
v1 - 1. Reworded the requirement so as to avoid mentioining variable names
or hardcoded strings. Otherwise, one would need to change the requirement
each ti
On 15.08.2025 22:41, Andrew Cooper wrote:
> Now that content has been split out, minimise the header files as msr.h is
> included by many translation units. A few more TUs were pulling dependencies
> in transitively, so fix them up.
>
> Give asm/time.h an SPDX tag, and strip trailing whitespace.
On 15.08.2025 22:41, Andrew Cooper wrote:
> With asm/tsc.h split out, asm/time.h shouldn't be including asm/msr.h, but it
> turns out that an outrageous number of files (even some headers) are pulling
> their dependentices transitively through asm/time.h -> asm/msr.h
>
> Most are asm/msr{,-index}.
On 15.08.2025 22:41, Andrew Cooper wrote:
> Now there is a local header, asm/cpu-user-regs.h is a far better place for
> these to live.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
On 19.08.2025 12:26, Petr Beneš wrote:
> On Tue, Aug 19, 2025 at 8:45 AM Jan Beulich wrote:
>> Just to mention, also affecting your MAX_ALTP2M series: It is on you to chase
>> missing acks. It would of course be nice for this work of yours to not go in
>> only at the last minute, or even miss 4.21
On Tue, Aug 19, 2025 at 8:45 AM Jan Beulich wrote:
> Just to mention, also affecting your MAX_ALTP2M series: It is on you to chase
> missing acks. It would of course be nice for this work of yours to not go in
> only at the last minute, or even miss 4.21.
Thank you, I've been watching the timelin
60 matches
Mail list logo
