On 04.02.2025 08:45, Jan Beulich wrote:
> On 03.02.2025 18:18, Roger Pau Monné wrote:
>> On Mon, Feb 03, 2025 at 05:27:24PM +0100, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_64/mmconfig-shared.c
>>> +++ b/xen/arch/x86/x86_64/mmconfig-shared.c
>>> @@ -402,6 +402,9 @@ void __init acpi_mmcfg_init(v
On 03.02.2025 18:18, Roger Pau Monné wrote:
> On Mon, Feb 03, 2025 at 05:27:24PM +0100, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_64/mmconfig-shared.c
>> +++ b/xen/arch/x86/x86_64/mmconfig-shared.c
>> @@ -402,6 +402,9 @@ void __init acpi_mmcfg_init(void)
>> {
>> bool valid = true;
>>
>>
Supported ISA extensions are specified in the device tree within the CPU
node, using two properties: `riscv,isa-extensions` and `riscv,isa`.
Currently, Xen does not support the `riscv,isa-extensions` property, as
all available device tree source (DTS) files in the Linux kernel (v6.12-rc3)
and DTBs
On 03.02.2025 18:04, Andrew Cooper wrote:
> On 03/02/2025 4:27 pm, Jan Beulich wrote:
>> Have callers invoke pci_add_segment() directly instead. On x86 move the
>> invocation back to acpi_mmcfg_init(), where it was prior to
>> ("x86/PCI: init segments earlier").
>> ---
>
> Need a SoB.
On 03.02.2025 17:38, Oleksii Kurochko wrote:
>
> On 2/3/25 5:22 PM, Jan Beulich wrote:
>> The first two patches are functionally independent, and they're presented
>> here merely in the order I came to notice the respective issues. At least
>> patch 2 wants seriously considering for 4.20.
>>
>> Wh
From: Maksym Planeta
[ Upstream commit 6d002348789bc16e9203e9818b7a3688787e3b29 ]
Function xen_pin_page calls xen_pte_lock, which in turn grab page
table lock (ptlock). When locking, xen_pte_lock expect mm->page_table_lock
to be held before grabbing ptlock, but this does not happen when pinning
From: Maksym Planeta
[ Upstream commit 6d002348789bc16e9203e9818b7a3688787e3b29 ]
Function xen_pin_page calls xen_pte_lock, which in turn grab page
table lock (ptlock). When locking, xen_pte_lock expect mm->page_table_lock
to be held before grabbing ptlock, but this does not happen when pinning
From: Maksym Planeta
[ Upstream commit 6d002348789bc16e9203e9818b7a3688787e3b29 ]
Function xen_pin_page calls xen_pte_lock, which in turn grab page
table lock (ptlock). When locking, xen_pte_lock expect mm->page_table_lock
to be held before grabbing ptlock, but this does not happen when pinning
From: Maksym Planeta
[ Upstream commit 6d002348789bc16e9203e9818b7a3688787e3b29 ]
Function xen_pin_page calls xen_pte_lock, which in turn grab page
table lock (ptlock). When locking, xen_pte_lock expect mm->page_table_lock
to be held before grabbing ptlock, but this does not happen when pinning
From: Maksym Planeta
[ Upstream commit 6d002348789bc16e9203e9818b7a3688787e3b29 ]
Function xen_pin_page calls xen_pte_lock, which in turn grab page
table lock (ptlock). When locking, xen_pte_lock expect mm->page_table_lock
to be held before grabbing ptlock, but this does not happen when pinning
From: Maksym Planeta
[ Upstream commit 6d002348789bc16e9203e9818b7a3688787e3b29 ]
Function xen_pin_page calls xen_pte_lock, which in turn grab page
table lock (ptlock). When locking, xen_pte_lock expect mm->page_table_lock
to be held before grabbing ptlock, but this does not happen when pinning
From: Maksym Planeta
[ Upstream commit 6d002348789bc16e9203e9818b7a3688787e3b29 ]
Function xen_pin_page calls xen_pte_lock, which in turn grab page
table lock (ptlock). When locking, xen_pte_lock expect mm->page_table_lock
to be held before grabbing ptlock, but this does not happen when pinning
On Mon, Feb 3, 2025 at 2:36 AM Jan Beulich wrote:
>
> On 01.02.2025 00:36, Tamas K Lengyel wrote:
> > On Fri, Jan 31, 2025 at 1:30 AM Jan Beulich wrote:
> >> On 31.01.2025 01:26, Tamas K Lengyel wrote:
> >>> On Thu, Jan 30, 2025 at 8:24 AM Jan Beulich wrote:
> On 21.01.2025 11:19, Sergiy Ki
+Xen maintainers
On Mon, 3 Feb 2025, Richard Henderson wrote:
> On 2/3/25 04:54, Paolo Bonzini wrote:
> > On 2/3/25 04:18, Richard Henderson wrote:
> > > v1: 20250128004254.33442-1-richard.hender...@linaro.org
> > >
> > > For v2, immediately disable 64-on-32 TCG.
> > >
> > > I *suspect* that we
On Mon, Feb 03, 2025, Nikunj A Dadhania wrote:
> Sean Christopherson writes:
> > Extract retrieval of TSC frequency information from CPUID into standalone
> > helpers so that TDX guest support and kvmlock can reuse the logic. Provide
>
> s/kvmlock/kvmclock
>
> > a version that includes the mult
On Mon, Feb 03, 2025, Tom Lendacky wrote:
> On 1/31/25 20:17, Sean Christopherson wrote:
> > Add a "tsc_properties" set of flags and use it to annotate whether the
> > TSC operates at a known and/or reliable frequency when registering a
> > paravirtual TSC calibration routine. Currently, each PV f
On Mon, 3 Feb 2025, Teddy Astie wrote:
> Hello Jason,
>
> Le 30/01/2025 à 21:17, Jason Andryuk a écrit :
> > Hi Teddy,
> >
> > Thanks for working on this. I'm curious about your plans for this:
> >
> > On 2025-01-21 11:13, Teddy Astie wrote:
> >> +/**
> >> + * IOMMU_alloc_nested
> >> + * Create a
On Mon, Feb 03, 2025 at 05:27:24PM +0100, Jan Beulich wrote:
> Have callers invoke pci_add_segment() directly instead. On x86 move the
> invocation back to acpi_mmcfg_init(), where it was prior to
> ("x86/PCI: init segments earlier").
> ---
> v2: New.
>
> --- a/xen/arch/arm/pci/pci.c
On 03/02/2025 4:27 pm, Jan Beulich wrote:
> Have callers invoke pci_add_segment() directly instead. On x86 move the
> invocation back to acpi_mmcfg_init(), where it was prior to
> ("x86/PCI: init segments earlier").
> ---
Need a SoB.
I definitely prefer this version of the fix, but I
On 03.02.2025 17:48, Andrew Cooper wrote:
> On 03/02/2025 4:26 pm, Jan Beulich wrote:
>> ... now that static initialization is possible. Use RADIX_TREE() for
>> pci_segments and ivrs_maps.
>>
>> Requested-by: Andrew Cooper
>> Signed-off-by: Jan Beulich
>
> I'd not considered having RADIX_TREE()
On 03/02/2025 4:38 pm, Oleksii Kurochko wrote:
> On 2/3/25 5:22 PM, Jan Beulich wrote:
>> The first two patches are functionally independent, and they're presented
>> here merely in the order I came to notice the respective issues. At least
>> patch 2 wants seriously considering for 4.20.
>>
>> Whi
On Mon, Feb 03, 2025 at 05:24:10PM +0100, Jan Beulich wrote:
> While the 2nd of the commits referenced below should have moved the call
> to amd_iommu_msi_enable() instead of adding another one, the situation
> wasn't quite right even before: It can't have done any good to enable
> MSI when no IRQ
On 03/02/2025 4:26 pm, Jan Beulich wrote:
> ... now that static initialization is possible. Use RADIX_TREE() for
> pci_segments and ivrs_maps.
>
> Requested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
I'd not considered having RADIX_TREE() but it's nicer than my attempt.
However,
> --- a/xe
On 03/02/2025 4:25 pm, Jan Beulich wrote:
> They aren't used anymore.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 2/3/25 5:22 PM, Jan Beulich wrote:
The first two patches are functionally independent, and they're presented
here merely in the order I came to notice the respective issues. At least
patch 2 wants seriously considering for 4.20.
While alternatives were considered for patch 2, it's left as it
On 03.02.2025 16:50, Oleksii Kurochko wrote:
> On 1/27/25 12:23 PM, Jan Beulich wrote:
>> On 08.01.2025 12:13, Oleksii Kurochko wrote:
>>> Nothing changed. Only some functions declaration are moved to asm-generic
>>> header as they are expected to be used by common code of domain builing or
>>> dom
On 03/02/2025 4:25 pm, Jan Beulich wrote:
> These were needed by TMEM only, which is long gone. The Linux original
> doesn't have such either. This effectively reverts one of the "Other
> changes" from 8dc6738dbb3c ("Update radix-tree.[ch] from upstream Linux
> to gain RCU awareness").
>
> Positive
While the 2nd of the commits referenced below should have moved the call
to amd_iommu_msi_enable() instead of adding another one, the situation
wasn't quite right even before: It can't have done any good to enable
MSI when no IRQ was allocated for it, yet.
The other call to amd_iommu_msi_enable(),
On 03.02.2025 16:34, Oleksii Kurochko wrote:
>
> On 1/27/25 12:15 PM, Jan Beulich wrote:
>> On 08.01.2025 12:13, Oleksii Kurochko wrote:
>>> Move the following parts to asm-generic with the following changes:
>>> - struct kernel_info:
>>>- Create arch_kernel_info for arch specific kernel infor
Have callers invoke pci_add_segment() directly instead. On x86 move the
invocation back to acpi_mmcfg_init(), where it was prior to
("x86/PCI: init segments earlier").
---
v2: New.
--- a/xen/arch/arm/pci/pci.c
+++ b/xen/arch/arm/pci/pci.c
@@ -88,7 +88,8 @@ static int __init pci_init(v
On 03.02.2025 17:24, Oleksii Kurochko wrote:
> On 2/3/25 5:03 PM, Jan Beulich wrote:
>> On 03.02.2025 16:05, Oleksii Kurochko wrote:
>>> On 1/27/25 3:47 PM, Jan Beulich wrote:
> +static bool is_lowercase_extension_name(const char *str)
> +{
> +/*
> + * `str` could contain fu
On 03.02.2025 17:25, Jan Beulich wrote:
> These were needed by TMEM only, which is long gone. The Linux original
> doesn't have such either. This effectively reverts one of the "Other
> changes" from 8dc6738dbb3c ("Update radix-tree.[ch] from upstream Linux
> to gain RCU awareness").
>
> Positive
... now that static initialization is possible. Use RADIX_TREE() for
pci_segments and ivrs_maps.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -31,7 +31,7 @@ static struct task
They aren't used anymore.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/common/radix-tree.c
+++ b/xen/common/radix-tree.c
@@ -60,16 +60,14 @@ static void cf_check _rcu_node_free(stru
xfree(rcu_node);
}
-static struct radix_tree_node *radix_tree_node_alloc(
- struct radix_tre
These were needed by TMEM only, which is long gone. The Linux original
doesn't have such either. This effectively reverts one of the "Other
changes" from 8dc6738dbb3c ("Update radix-tree.[ch] from upstream Linux
to gain RCU awareness").
Positive side effect: Two cf_check go away.
While there also
On 2/3/25 5:03 PM, Jan Beulich wrote:
On 03.02.2025 16:05, Oleksii Kurochko wrote:
On 1/27/25 3:47 PM, Jan Beulich wrote:
+static bool is_lowercase_extension_name(const char *str)
+{
+/*
+ * `str` could contain full riscv,isa string from device tree so one
+ * of the stop condionit
In order for amd_iommu_detect_one_acpi()'s call to pci_ro_device() to
have permanent effect, pci_segments_init() needs to be called ahead of
making it there. Without this we're losing segment 0's r/o map, and thus
we're losing write-protection of the PCI devices representing IOMMUs.
Which in turn m
The first two patches are functionally independent, and they're presented
here merely in the order I came to notice the respective issues. At least
patch 2 wants seriously considering for 4.20.
While alternatives were considered for patch 2, it's left as it was in v1
for now. The disposition there
On 03/02/2025 3:53 pm, Jan Beulich wrote:
> On 03.02.2025 15:19, Andrew Cooper wrote:
>> On 03/02/2025 8:41 am, Jan Beulich wrote:
>>> On 02.02.2025 14:50, Andrew Cooper wrote:
On 30/01/2025 11:11 am, Jan Beulich wrote:
> While the 2nd of the commits referenced below should have moved the
On 03.02.2025 16:05, Oleksii Kurochko wrote:
> On 1/27/25 3:47 PM, Jan Beulich wrote:
>>> +static bool is_lowercase_extension_name(const char *str)
>>> +{
>>> +/*
>>> + * `str` could contain full riscv,isa string from device tree so one
>>> + * of the stop condionitions is checking for
On 03.02.2025 15:19, Andrew Cooper wrote:
> On 03/02/2025 8:41 am, Jan Beulich wrote:
>> On 02.02.2025 14:50, Andrew Cooper wrote:
>>> On 30/01/2025 11:11 am, Jan Beulich wrote:
While the 2nd of the commits referenced below should have moved the call
to amd_iommu_msi_enable() instead of a
On 1/27/25 12:23 PM, Jan Beulich wrote:
On 08.01.2025 12:13, Oleksii Kurochko wrote:
Nothing changed. Only some functions declaration are moved to asm-generic
header as they are expected to be used by common code of domain builing or
dom0less.
Signed-off-by: Oleksii Kurochko
---
xen/arch/arm
On 03.02.2025 15:23, Andrew Cooper wrote:
> On 03/02/2025 1:03 pm, Jan Beulich wrote:
>> On 03.02.2025 14:00, Jan Beulich wrote:
>>> On 03.02.2025 13:45, Roger Pau Monné wrote:
On Thu, Jan 30, 2025 at 12:12:31PM +0100, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_64/mmconfig-shared.c
>
On 1/27/25 12:19 PM, Jan Beulich wrote:
On 08.01.2025 12:13, Oleksii Kurochko wrote:
Except moving Arm's static-memory.h to asm-generic #ifdef header guard
is updated: s/__ASM_STATIC_MEMORY_H_/__ASM_GENERIC_STATIC_MEMORY_H__.
Update arm/include/asm/Makefile to use asm-generic version of
static
On 1/27/25 12:15 PM, Jan Beulich wrote:
On 08.01.2025 12:13, Oleksii Kurochko wrote:
Move the following parts to asm-generic with the following changes:
- struct kernel_info:
- Create arch_kernel_info for arch specific kernel information.
At the moment, it contains domain_type for Arm.
On 03/02/2025 9:09 am, Jan Beulich wrote:
> On 02.02.2025 15:46, Andrew Cooper wrote:
>> On 30/01/2025 11:12 am, Jan Beulich wrote:
>>> In order for amd_iommu_detect_one_acpi()'s call to pci_ro_device() to
>>> have permanent effect, pci_segments_init() needs to be called ahead of
>>> making it ther
On 1/27/25 12:12 PM, Jan Beulich wrote:
On 08.01.2025 12:13, Oleksii Kurochko wrote:
Unify the API for creating DomUs and checking for Dom0less mode across
architectures, including Arm and RISC-V, with potential applicability
for PPC.
That is you mean to re-use it for RISC-V?
Yes, I will re-
On 1/27/25 3:47 PM, Jan Beulich wrote:
+*dt_cpuid = dt_read_paddr(prop, dt_n_addr_cells(cpu));
+
+return 0;
+}
+
+/*
+ * The canonical order of ISA extension names in the ISA string is defined in
+ * chapter 27 of the unprivileged specification.
+ *
+ * The specification uses vague wordi
On 1/31/25 20:17, Sean Christopherson wrote:
> Add a "tsc_properties" set of flags and use it to annotate whether the
> TSC operates at a known and/or reliable frequency when registering a
> paravirtual TSC calibration routine. Currently, each PV flow manually
> sets the associated feature flags,
On 1/27/25 7:56 PM, Katz, Jonathan wrote:
Tested on xcp-ng vm on esx 8 that previously failed to boot when
performance counters were not enabled.
- patched host
- rebooted host
- host still came up normally
- shut host down
- turned off performance counters on vm
- booted host
- host still cam
On 03/02/2025 1:03 pm, Jan Beulich wrote:
> On 03.02.2025 14:00, Jan Beulich wrote:
>> On 03.02.2025 13:45, Roger Pau Monné wrote:
>>> On Thu, Jan 30, 2025 at 12:12:31PM +0100, Jan Beulich wrote:
--- a/xen/arch/x86/x86_64/mmconfig-shared.c
+++ b/xen/arch/x86/x86_64/mmconfig-shared.c
On 03/02/2025 8:41 am, Jan Beulich wrote:
> On 02.02.2025 14:50, Andrew Cooper wrote:
>> On 30/01/2025 11:11 am, Jan Beulich wrote:
>>> While the 2nd of the commits referenced below should have moved the call
>>> to amd_iommu_msi_enable() instead of adding another one, the situation
>>> wasn't quit
Hi Bertrand,
On 2/3/25 11:42 AM, Bertrand Marquis wrote:
Hi Jens,
Thanks a lot for the finding.
On 3 Feb 2025, at 11:21, Jens Wiklander wrote:
The notification bitmask is in passed in the FF-A ABI in two 32-bit
registers w3 and w4. The lower 32-bits should go in w3 and the higher in
w4. Thes
When pt_update() is called with arguments (..., INVALID_MFN, ..., 0 or 1),
it indicates that a mapping is being destroyed/modifyed.
In the case when modifying or destroying a mapping, it is necessary to
search until a leaf node is found, instead of searching for a page table
entry based on the pre
vmap_to_mfn() uses virt_to_maddr(), which is designed to work with VA from
either the direct map region or Xen's linkage region (XEN_VIRT_START).
An assertion will occur if it is used with other regions, in particular for
the VMAP region.
Since RISC-V lacks a hardware feature to request the MMU to
RISC-V doesn't have hardware feature to ask MMU to translate
virtual address to physical address ( like Arm has, for example ),
so software page table walking is implemented.
As pte_walk() returns pte_t and it requires inclusion of
in , the following compilation started to occur after this
inclus
Introduce pt_walk(), which does software page table walking to resolve the
following issues:
1. vmap_to_mfn() uses virt_to_maddr(), which is designed to work with VA
from either the direct map region or Xen's linkage region (XEN_VIRT_START),
thereby an assertion will occur if it is used with
On 03.02.2025 14:00, Jan Beulich wrote:
> On 03.02.2025 13:45, Roger Pau Monné wrote:
>> On Thu, Jan 30, 2025 at 12:12:31PM +0100, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_64/mmconfig-shared.c
>>> +++ b/xen/arch/x86/x86_64/mmconfig-shared.c
>>> @@ -402,8 +402,6 @@ void __init acpi_mmcfg_init(v
On 03.02.2025 13:45, Roger Pau Monné wrote:
> On Thu, Jan 30, 2025 at 12:12:31PM +0100, Jan Beulich wrote:
>> In order for amd_iommu_detect_one_acpi()'s call to pci_ro_device() to
>> have permanent effect, pci_segments_init() needs to be called ahead of
>> making it there. Without this we're losing
On Thu, Jan 30, 2025 at 12:12:31PM +0100, Jan Beulich wrote:
> In order for amd_iommu_detect_one_acpi()'s call to pci_ro_device() to
> have permanent effect, pci_segments_init() needs to be called ahead of
> making it there. Without this we're losing segment 0's r/o map, and thus
> we're losing wri
On 03/02/2025 8:42 am, Jan Beulich wrote:
> On 02.02.2025 14:48, Andrew Cooper wrote:
>> This removes the unnecessary work of splitting a 32-bit number across
>> 4 registers, and recombining later. Bloat-o-meter reports:
>>
>> add/remove: 0/0 grow/shrink: 0/9 up/down: 0/-295 (-295)
>> Function
Hello Jason,
Le 30/01/2025 à 21:17, Jason Andryuk a écrit :
> Hi Teddy,
>
> Thanks for working on this. I'm curious about your plans for this:
>
> On 2025-01-21 11:13, Teddy Astie wrote:
>> +/**
>> + * IOMMU_alloc_nested
>> + * Create a nested IOMMU context (needs IOMMUCAP_nested).
>> + *
>> + *
Hi Jens,
Thanks a lot for the finding.
> On 3 Feb 2025, at 11:21, Jens Wiklander wrote:
>
> The notification bitmask is in passed in the FF-A ABI in two 32-bit
> registers w3 and w4. The lower 32-bits should go in w3 and the higher in
> w4. These two registers has unfortunately been swapped for
The notification bitmask is in passed in the FF-A ABI in two 32-bit
registers w3 and w4. The lower 32-bits should go in w3 and the higher in
w4. These two registers has unfortunately been swapped for
FFA_NOTIFICATION_BIND and FFA_NOTIFICATION_UNBIND in the FF-A mediator.
So fix that by using the co
On 02.02.2025 15:46, Andrew Cooper wrote:
> On 30/01/2025 11:12 am, Jan Beulich wrote:
>> In order for amd_iommu_detect_one_acpi()'s call to pci_ro_device() to
>> have permanent effect, pci_segments_init() needs to be called ahead of
>> making it there. Without this we're losing segment 0's r/o map
Oh cool, thanks a lot for the explanation.
I added the "vzeroupper" and Xen crashes so it looks like the CPUID
emulation is buggy. Also I was able to try it using a VM (same debian
testing) running on virt-manager+kvm and it works fine (Xen in debug mode).
I will have a look by printing the xstate
On 02.02.2025 14:48, Andrew Cooper wrote:
> This removes the unnecessary work of splitting a 32-bit number across
> 4 registers, and recombining later. Bloat-o-meter reports:
>
> add/remove: 0/0 grow/shrink: 0/9 up/down: 0/-295 (-295)
> Function old new
On 02.02.2025 14:50, Andrew Cooper wrote:
> On 30/01/2025 11:11 am, Jan Beulich wrote:
>> While the 2nd of the commits referenced below should have moved the call
>> to amd_iommu_msi_enable() instead of adding another one, the situation
>> wasn't quite right even before: It can't have done any good
68 matches
Mail list logo
