On 11.02.2025 13:04, Juergen Gross wrote:
> In case xen_swiotlb_alloc_coherent() needed to create a contiguous
> region only for other reason than the memory not being compliant with
> the device's DMA mask, there is no reason why this contiguous region
> should be destroyed by xen_swiotlb_free_coh
Hi,
I hope this email finds you well.
My name is Surya Prakash Shukla, and I am currently working on a project
involving the development of Android Trout on the Xen Hypervisor. I have been
exploring various aspects of virtualization and have found the Xen Project to
be an invaluable resource in
On 11.02.2025 13:04, Juergen Gross wrote:
> When mapping a buffer for DMA via .map_page or .map_sg DMA operations,
> there is no need to check the machine frames to be aligned according
> to the mapped areas size. All what is needed in these cases is that the
> buffer is contiguous at machine level
On Tue, 11 Feb 2025, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Xen console driver has vpl011-related logic which shall belong vpl011 emulator
> code (Arm port). Move vpl011-related code from arch-independent console driver
> to Arm's vpl011.c.
>
> Signed-off-by: Denis Mukhin
> ---
> Link
On Tue, 11 Feb 2025, Juergen Gross wrote:
> In case xen_swiotlb_alloc_coherent() needed to create a contiguous
> region only for other reason than the memory not being compliant with
> the device's DMA mask, there is no reason why this contiguous region
> should be destroyed by xen_swiotlb_free_coh
On Tue, 11 Feb 2025, Juergen Gross wrote:
> When mapping a buffer for DMA via .map_page or .map_sg DMA operations,
> there is no need to check the machine frames to be aligned according
> to the mapped areas size. All what is needed in these cases is that the
> buffer is contiguous at machine level
Hi Oleksandr,
This morning, we had a discussion among maintainers, and the suggested
approach moving forward is as follows:
- First, it would be helpful to see a sample of the proposed changes
applied to a single source file as an example. If you could provide
such a patch, it would help adva
On Tue, 11 Feb 2025, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Move resource definitions to a new architecture-agnostic shared header file.
>
> Signed-off-by: Denis Mukhin
Reviewed-by: Stefano Stabellini
> ---
> Changes in v2:
> - Formatting fixes
> - Link to v1:
> https://lore.kerne
On Tue, Feb 11, 2025 at 09:43:23AM -0800, Sean Christopherson wrote:
> It conflates two very different things: host/bare metal support for memory
> encryption, and SEV guest support. For kernels that will never run in a VM,
> pulling in all the SEV guest code just to enable host-side support for S
Hi Harshit,
On Sun, Feb 09, 2025 at 01:45:38AM +0530, Harshit Mogalapalli wrote:
> Hi Salvatore,
>
> On 08/02/25 21:26, Salvatore Bonaccorso wrote:
> > Hi Juergen, hi all,
> >
> > Radoslav Bodó reported in Debian an issue after updating our kernel
> > from 6.1.112 to 6.1.115. His report in full
On Tue, Feb 11, 2025, Borislav Petkov wrote:
> On Tue, Feb 11, 2025 at 09:25:47AM -0800, Sean Christopherson wrote:
> > Because obviously optimizing code that's called once during boot is super
> > critical?
>
> Because let's stick 'em where they belong and keep headers containing only
> small, tr
On Tue, Feb 11, 2025 at 03:06:08PM +0100, Roger Pau Monné wrote:
> On Tue, Feb 11, 2025 at 11:19:23AM +0100, Jan Beulich wrote:
> > On 11.02.2025 10:10, Luca Fancellu wrote:
> > >>> 3) The size of the patch after applying clang-format is huge. Really.
> > >>> Something
> > >>> like 9 MB. Even if e
On Tue, Feb 11, 2025 at 09:25:47AM -0800, Sean Christopherson wrote:
> Because obviously optimizing code that's called once during boot is super
> critical?
Because let's stick 'em where they belong and keep headers containing only
small, trivial and inlineable functions. Having unusually big func
On Tue, Feb 11, 2025 at 12:02:04PM +0100, Roger Pau Monne wrote:
> Hello,
>
> The following series aims to prevent local APIC errors from stalling the
> shtudown process. On XenServer testing we have seen reports of AMD
> boxes sporadically getting stuck in a spam of:
>
> APIC error on CPU0: 00(
On Tue, Feb 11, 2025 at 10:38:41AM +0100, Jan Beulich wrote:
> on_selected_cpus() asserts that it's only passed online CPUs. Between
> __cpu_disable() removing a CPU from the online map and fixup_eoi()
> cleaning up for the CPU being offlined there's a window, though, where
> the CPU in question ca
On Tue, Feb 11, 2025, Borislav Petkov wrote:
> On Fri, Jan 31, 2025 at 06:17:05PM -0800, Sean Christopherson wrote:
>
> > Add a TODO to call out that AMD_MEM_ENCRYPT is a mess and doesn't depend on
> > HYPERVISOR_GUEST because it gates both guest and host code.
>
> Why is it a mess?
>
> I don't
On Fri, Jan 31, 2025 at 06:17:05PM -0800, Sean Christopherson wrote:
Drop:
jailhouse-...@googlegroups.com
Alexey Makhalov
from Cc as they're bouncing.
> Add a TODO to call out that AMD_MEM_ENCRYPT is a mess and doesn't depend on
> HYPERVISOR_GUEST because it gates both guest and host code.
Wh
On Tue, Feb 11, 2025, Borislav Petkov wrote:
> On Fri, Jan 31, 2025 at 06:17:03PM -0800, Sean Christopherson wrote:
> > Extract retrieval of TSC frequency information from CPUID into standalone
> > helpers so that TDX guest support and kvmlock can reuse the logic. Provide
> > a version that includ
The description of the design session was:
PVH: limitations, requirements & future considerations
A general discussion on PVH from both guest and Dom0 perspectives, covering:
Trade-offs and key limitations
Required work for PCI passthrough and SR-IOV support
Dom0 feasibility: kern
On 11.02.2025 15:48, Roger Pau Monne wrote:
> Attempt to disable MSI(-X) capabilities on all PCI devices know by Xen at
> shutdown. Doing such disabling should facilitate kexec chained kernel from
> booting more reliably, as device MSI(-X) interrupt generation should be
> quiesced.
>
> Only attem
On 11.02.2025 17:50, Oleksii Kurochko wrote:
> On 2/11/25 4:47 PM, Jan Beulich wrote:
>> On 11.02.2025 16:28, Oleksii Kurochko wrote:
>>> On 2/11/25 11:01 AM, Jan Beulich wrote:
On 11.02.2025 10:53, Oleksii Kurochko wrote:
> On 2/10/25 5:19 PM, Jan Beulich wrote:
>> On 07.02.2025 21:07
On 2/11/25 4:47 PM, Jan Beulich wrote:
On 11.02.2025 16:28, Oleksii Kurochko wrote:
On 2/11/25 11:01 AM, Jan Beulich wrote:
On 11.02.2025 10:53, Oleksii Kurochko wrote:
On 2/10/25 5:19 PM, Jan Beulich wrote:
On 07.02.2025 21:07, Oleksii Kurochko wrote:
+/*
+ * The canonical order of ISA ext
On 06.02.2025 09:32, Penny Zheng wrote:
> --- a/xen/arch/x86/acpi/cpufreq/amd-cppc.c
> +++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
> @@ -13,7 +13,61 @@
>
> #include
> #include
> +#include
> +#include
> #include
> +#include
> +
> +#define MSR_AMD_CPPC_CAP1 0xc00102b0
> +#defi
On Tue, Feb 11, 2025, Borislav Petkov wrote:
> On Fri, Jan 31, 2025 at 06:17:02PM -0800, Sean Christopherson wrote:
> > And if the host provides the core crystal frequency in CPUID.0x15, then KVM
> > guests can use that for the APIC timer period instead of manually
> > calibrating the frequency.
>
On 11/02/25 06:22, Dave Hansen wrote:
> On 2/11/25 05:33, Valentin Schneider wrote:
>>> 2. It's wrong to assume that TLB entries are only populated for
>>> addresses you access - thanks to speculative execution, you have to
>>> assume that the CPU might be populating random TLB entries all over
>>>
On 11/02/25 14:03, Mark Rutland wrote:
> On Tue, Feb 11, 2025 at 02:33:51PM +0100, Valentin Schneider wrote:
>> On 10/02/25 23:08, Jann Horn wrote:
>> > 2. It's wrong to assume that TLB entries are only populated for
>> > addresses you access - thanks to speculative execution, you have to
>> > assu
From: Denis Mukhin
Move resource definitions to a new architecture-agnostic shared header file.
Signed-off-by: Denis Mukhin
---
Changes in v2:
- Formatting fixes
- Link to v1:
https://lore.kernel.org/xen-devel/20250207231814.3863449-1-dmuk...@ford.com/
---
xen/common/device-tree/device-tree.c
On 11.02.2025 16:28, Oleksii Kurochko wrote:
>
> On 2/11/25 11:01 AM, Jan Beulich wrote:
>> On 11.02.2025 10:53, Oleksii Kurochko wrote:
>>> On 2/10/25 5:19 PM, Jan Beulich wrote:
On 07.02.2025 21:07, Oleksii Kurochko wrote:
> +/*
> + * The canonical order of ISA extension names in th
On 2/11/25 11:01 AM, Jan Beulich wrote:
On 11.02.2025 10:53, Oleksii Kurochko wrote:
On 2/10/25 5:19 PM, Jan Beulich wrote:
On 07.02.2025 21:07, Oleksii Kurochko wrote:
+/*
+ * The canonical order of ISA extension names in the ISA string is defined in
+ * chapter 27 of the unprivileged specif
When mapping a buffer for DMA via .map_page or .map_sg DMA operations,
there is no need to check the machine frames to be aligned according
to the mapped areas size. All what is needed in these cases is that the
buffer is contiguous at machine level.
So carve out the alignment check from range_str
On 11.02.25 14:32, Julien Grall wrote:
On 11/02/2025 11:57, Orzel, Michal wrote:
On 11/02/2025 12:18, Grygorii Strashko wrote:
The dt_device_for_passthrough() is called many times during Xen
initialization and Dom0 creation. On every call it traverses struct
dt_device_node properties lis
On 2025-02-11 07:08, Jan Beulich wrote:
On 06.02.2025 09:32, Penny Zheng wrote:
--- /dev/null
+++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
@@ -0,0 +1,64 @@
+static bool __init amd_cppc_handle_option(const char *s, const char *end)
+{
+int ret;
+
+ret = parse_boolean("verbose", s, end);
On Fri, Jan 31, 2025 at 06:17:03PM -0800, Sean Christopherson wrote:
> Extract retrieval of TSC frequency information from CPUID into standalone
> helpers so that TDX guest support and kvmlock can reuse the logic. Provide
> a version that includes the multiplier math as TDX in particular does NOT
Attempt to disable MSI(-X) capabilities on all PCI devices know by Xen at
shutdown. Doing such disabling should facilitate kexec chained kernel from
booting more reliably, as device MSI(-X) interrupt generation should be
quiesced.
Only attempt to disable MSI(-X) on all devices in the crash contex
In case xen_swiotlb_alloc_coherent() needed to create a contiguous
region only for other reason than the memory not being compliant with
the device's DMA mask, there is no reason why this contiguous region
should be destroyed by xen_swiotlb_free_coherent() later. Destroying
this region should be do
On Fri, Jan 31, 2025 at 06:17:02PM -0800, Sean Christopherson wrote:
> And if the host provides the core crystal frequency in CPUID.0x15, then KVM
> guests can use that for the APIC timer period instead of manually
> calibrating the frequency.
Hmm, so that part: what's stopping the host from fakin
On 2/11/25 05:33, Valentin Schneider wrote:
>> 2. It's wrong to assume that TLB entries are only populated for
>> addresses you access - thanks to speculative execution, you have to
>> assume that the CPU might be populating random TLB entries all over
>> the place.
> Gotta love speculation. Now it
On Tue, Feb 11, 2025 at 12:34:41PM +0100, Jan Beulich wrote:
> On 11.02.2025 12:02, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/crash.c
> > +++ b/xen/arch/x86/crash.c
> > @@ -175,6 +175,13 @@ static void nmi_shootdown_cpus(void)
> > */
> > x2apic_enabled = (current_local_apic_m
On Tue, Feb 11, 2025 at 12:23:56PM +0100, Jan Beulich wrote:
> On 11.02.2025 12:02, Roger Pau Monne wrote:
> > The current shutdown logic in smp_send_stop() will disable the APs while
> > having interrupts enabled on the BSP or possibly other APs. On AMD systems
> > this can lead to local APIC erro
On Tue, Feb 11, 2025 at 11:19:23AM +0100, Jan Beulich wrote:
> On 11.02.2025 10:10, Luca Fancellu wrote:
> >>> 3) The size of the patch after applying clang-format is huge. Really.
> >>> Something
> >>> like 9 MB. Even if everyone agrees that the approach is good and we can
> >>> proceed
> >>> wi
On Tue, Feb 11, 2025 at 02:33:51PM +0100, Valentin Schneider wrote:
> On 10/02/25 23:08, Jann Horn wrote:
> > On Mon, Feb 10, 2025 at 7:36 PM Valentin Schneider
> > wrote:
> >> What if isolated CPUs unconditionally did a TLBi as late as possible in
> >> the stack right before returning to userspa
On 06.02.2025 09:32, Penny Zheng wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -56,6 +56,8 @@ bool __initdata amd_virt_spec_ctrl;
>
> static bool __read_mostly fam17_c6_disabled;
>
> +DEFINE_PER_CPU_READ_MOSTLY(uint64_t, max_freq_mhz);
Such an AMD-only variable wou
On 10/02/25 23:08, Jann Horn wrote:
> On Mon, Feb 10, 2025 at 7:36 PM Valentin Schneider
> wrote:
>> What if isolated CPUs unconditionally did a TLBi as late as possible in
>> the stack right before returning to userspace? This would mean that upon
>> re-entering the kernel, an isolated CPU's TLB
While fixing some common/arch boundaries for UBSAN support on other
architectures, the following debugging patch:
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index c1f2d1b89d43..58d1d048d339 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -504,6 +504,8 @@ voi
On 2/11/25 1:23 PM, Andrew Cooper wrote:
On 11/02/2025 7:31 am,dm...@proton.me wrote:
From: Denis Mukhin
Signed-off-by: Denis Mukhin
Acked-by: Andrew Cooper
CC Oleksii for 4.20 consideration.
Release-Acked-By: Oleksii Kurochko
Thanks.
~ Oleksii
---
tools/hotplug/Linux/init.d/syscon
On 11/02/2025 11:57, Orzel, Michal wrote:
On 11/02/2025 12:18, Grygorii Strashko wrote:
The dt_device_for_passthrough() is called many times during Xen
initialization and Dom0 creation. On every call it traverses struct
dt_device_node properties list and compares compares properties name wi
Patch 1 removes an unneeded alignment requirement, which resulted in
exhausting the SWIOTLB with normal use cases.
Patch 2 is an optimization to avoid destroying a contiguous region
without any need to do so.
There will be probably another patch following to allow larger
contiguous regions to be
On 11/02/2025 7:31 am, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Signed-off-by: Denis Mukhin
Acked-by: Andrew Cooper
CC Oleksii for 4.20 consideration.
> ---
> tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/to
On 06.02.2025 09:32, Penny Zheng wrote:
> --- /dev/null
> +++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
> @@ -0,0 +1,64 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * amd-cppc.c - AMD Processor CPPC Frequency Driver
> + *
> + * Copyright (C) 2025 Advanced Micro Devices, Inc. All Rights
On 11/02/2025 12:18, Grygorii Strashko wrote:
>
>
> The dt_device_for_passthrough() is called many times during Xen
> initialization and Dom0 creation. On every call it traverses struct
> dt_device_node properties list and compares compares properties name with
double "compares"
> "xen,passth
On 2025/2/10 20:30, Mark Rutland wrote:
> On Sat, Feb 08, 2025 at 09:15:08AM +0800, Jinjie Ruan wrote:
>> On 2024/12/6 18:17, Jinjie Ruan wrote:
>>> Currently, x86, Riscv, Loongarch use the generic entry. Convert arm64
>>> to use the generic entry infrastructure from kernel/entry/*. The generic
On 11.02.2025 12:02, Roger Pau Monne wrote:
> Add a new hook to inhibit interrupt generation by the IOMMU(s). Note the
> hook is currently only implemented for x86 IOMMUs. The purpose is to
> disable interrupt generation at shutdown so any kexec chained image finds
> the IOMMU(s) in a quiesced st
On 11.02.2025 12:02, Roger Pau Monne wrote:
> --- a/xen/arch/x86/crash.c
> +++ b/xen/arch/x86/crash.c
> @@ -175,6 +175,13 @@ static void nmi_shootdown_cpus(void)
> */
> x2apic_enabled = (current_local_apic_mode() == APIC_MODE_X2APIC);
>
> +if ( !pcidevs_locked() )
> +
On 2025/2/10 20:24, Mark Rutland wrote:
> On Fri, Dec 06, 2024 at 06:17:33PM +0800, Jinjie Ruan wrote:
>> Currently, x86, Riscv, Loongarch use the generic entry. Convert arm64
>> to use the generic entry infrastructure from kernel/entry/*.
>> The generic entry makes maintainers' work easier and
On 11.02.2025 12:02, Roger Pau Monne wrote:
> The current shutdown logic in smp_send_stop() will disable the APs while
> having interrupts enabled on the BSP or possibly other APs. On AMD systems
> this can lead to local APIC errors:
>
> APIC error on CPU0: 00(08), Receive accept error
>
> Such e
The dt_device_for_passthrough() is called many times during Xen
initialization and Dom0 creation. On every call it traverses struct
dt_device_node properties list and compares compares properties name with
"xen,passthrough" which is runtime overhead. This can be optimized by
marking dt_device_node
Hello,
The following series aims to prevent local APIC errors from stalling the
shtudown process. On XenServer testing we have seen reports of AMD
boxes sporadically getting stuck in a spam of:
APIC error on CPU0: 00(08), Receive accept error
Messages during shutdown, as a result of device inte
On 06.02.2025 09:32, Penny Zheng wrote:
> --- a/xen/arch/x86/platform_hypercall.c
> +++ b/xen/arch/x86/platform_hypercall.c
> @@ -572,6 +572,10 @@ ret_t do_platform_op(
> break;
> }
>
> +case XEN_PM_CPPC:
> +ret = set_cppc_pminfo(op->u.set_pminfo.id,
> &
On Tue, Feb 11, 2025 at 10:31:41AM +0100, Roger Pau Monné wrote:
> One question that seems to have been dropped from my previous email:
> would it be feasible to apply the updated style to newly added chunks
> of code only, but not to the (unmodified) surrounding context?
There's a tool that can f
Add a new hook to inhibit interrupt generation by the IOMMU(s). Note the
hook is currently only implemented for x86 IOMMUs. The purpose is to
disable interrupt generation at shutdown so any kexec chained image finds
the IOMMU(s) in a quiesced state.
It would also prevent "Receive accept error" b
Move the disabling of interrupt sources so it's done ahead of the offlining
of APs. This is to prevent AMD systems triggering "Receive accept error"
when interrupts target CPUs that are no longer online.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Changes since v1:
- New in thi
The solely remaining caller always passes the same globally available
parameters. Drop the parameters and modify fixup_irqs() to use
cpu_online_map in place of the input mask parameter, and always be verbose
in its output printing.
While there remove some of the checks given the single context wh
The current shutdown logic in smp_send_stop() will disable the APs while
having interrupts enabled on the BSP or possibly other APs. On AMD systems
this can lead to local APIC errors:
APIC error on CPU0: 00(08), Receive accept error
Such error message can be printed in a loop, thus blocking the s
Attempt to disable MSI(-X) capabilities on all PCI devices know by Xen at
shutdown. Doing such disabling should facilitate kexec chained kernel from
booting more reliably, as device MSI(-X) interrupt generation should be
quiesced. Only attempt to disable MSI(-X) on all devices in the crash
contex
On 06.02.2025 09:32, Penny Zheng wrote:
> Add Collaborative Processor Performance Control feature flag for
> AMD processors.
>
> amd-cppc is the AMD CPU performance scaling driver that
> introduces a new CPU frequency control mechanism on modern AMD
> APU and CPU series.
> There are two types of h
On Tue, Feb 11, 2025 at 11:14:55AM +0100, Jan Beulich wrote:
> On 11.02.2025 10:01, Roger Pau Monné wrote:
> > Is it possible for clang-format to be applied exclusively to newly
> > added chunks of code, while keeping the surroundings untouched?
>
> I, too, was wondering about this, at least as a
On 11.02.2025 11:26, Roger Pau Monné wrote:
> On Tue, Feb 11, 2025 at 09:49:54AM +, Luca Fancellu wrote:
>> Hi Roger,
>>
>>
>> 5) You name it. I think many people in the community can name their
>> points for
>> and against clang-format.
>
> What are the parts of our co
On 10.02.2025 22:16, Oleksandr Andrushchenko wrote:
> So, in this attempt, I would suggest the following approach:
> I think that I could start sending patches after the latest .clang-format 21
> for
> some part of Xen, ARM code base for example, using work already done by Luca.
Taking the sugges
On Tue, Feb 11, 2025 at 09:49:54AM +, Luca Fancellu wrote:
> Hi Roger,
>
>
> 5) You name it. I think many people in the community can name their
> points for
> and against clang-format.
> >>>
> >>> What are the parts of our coding style that clang-format cannot
> >>> cor
On 11.02.2025 10:10, Luca Fancellu wrote:
>>> 3) The size of the patch after applying clang-format is huge. Really.
>>> Something
>>> like 9 MB. Even if everyone agrees that the approach is good and we can
>>> proceed
>>> with it, it is highly unlikely anyone will be able to review it. Considerin
On 11.02.2025 10:01, Roger Pau Monné wrote:
> Is it possible for clang-format to be applied exclusively to newly
> added chunks of code, while keeping the surroundings untouched?
I, too, was wondering about this, at least as a data point. However,
especially for files that aren't in a single style
On 11.02.2025 10:53, Oleksii Kurochko wrote:
> On 2/10/25 5:19 PM, Jan Beulich wrote:
>> On 07.02.2025 21:07, Oleksii Kurochko wrote:
>>> +/*
>>> + * The canonical order of ISA extension names in the ISA string is defined
>>> in
>>> + * chapter 27 of the unprivileged specification.
>>> + *
>>> + *
Hi Andrew,
On 10/02/2025 22:23, Andrew Cooper wrote:
On 10/02/2025 9:23 pm, Julien Grall wrote:
Hi Andrew,
On 08/02/2025 00:02, Andrew Cooper wrote:
While fixing some common/arch boundaries for UBSAN support on other
architectures, the following debugging patch:
diff --git a/xen/arch/arm
On 2/10/25 5:19 PM, Jan Beulich wrote:
On 07.02.2025 21:07, Oleksii Kurochko wrote:
+/*
+ * The canonical order of ISA extension names in the ISA string is defined in
+ * chapter 27 of the unprivileged specification.
+ *
+ * The specification uses vague wording, such as should, when it comes to
Hi Roger,
5) You name it. I think many people in the community can name their points
for
and against clang-format.
>>>
>>> What are the parts of our coding style that clang-format cannot
>>> correctly represent? Could you make a list of what would need to
>>> change in Xen
on_selected_cpus() asserts that it's only passed online CPUs. Between
__cpu_disable() removing a CPU from the online map and fixup_eoi()
cleaning up for the CPU being offlined there's a window, though, where
the CPU in question can still appear in an action's cpu_eoi_map. Remove
offline CPUs, as th
On Tue, Feb 11, 2025 at 09:10:38AM +, Luca Fancellu wrote:
> Hi Roger,
>
> >>
> >> 3) The size of the patch after applying clang-format is huge. Really.
> >> Something
> >> like 9 MB. Even if everyone agrees that the approach is good and we can
> >> proceed
> >> with it, it is highly unlike
On 11.02.2025 08:43, Denis Mukhin wrote:
>> On 08.02.2025 03:54, Stefano Stabellini wrote:
>>> On Fri, 7 Feb 2025, dm...@proton.me wrote:
>>>
Move resource definitions to a new architecture-agnostic shared header
file.
Signed-off-by: Denis Mukhin dmuk...@ford.com
>>>
>>> Review
On 11.02.2025 09:38, Roger Pau Monné wrote:
> On Mon, Feb 10, 2025 at 07:29:35PM +0100, Oleksii Kurochko wrote:
>> On 2/10/25 11:02 AM, Roger Pau Monné wrote:
>>> This should have had a 'for-4.20?' tag in the subject name, as
>>> otherwise we will need to add an errata to the release notes to notic
On 2/10/25 5:53 PM, Jan Beulich wrote:
On 07.02.2025 14:13, Oleksii Kurochko wrote:
--- a/xen/arch/riscv/pt.c
+++ b/xen/arch/riscv/pt.c
@@ -238,11 +238,10 @@ pte_t pt_walk(vaddr_t va, unsigned int *pte_level)
/* Update an entry at the level @target. */
static int pt_update_entry(mfn_t r
On Tue, Feb 11, 2025 at 10:22:57AM +0800, Jiqian Chen wrote:
> Some devices, like AMDGPU, support resizable bar capability,
> but vpci of Xen doesn't support this feature, so they fail
> to resize bars and then cause probing failure.
>
> According to PCIe spec, each bar that supports resizing has
On 11.02.2025 09:50, Roger Pau Monné wrote:
> On Tue, Feb 11, 2025 at 07:39:12AM +0100, Jan Beulich wrote:
>> On 06.02.2025 16:06, Roger Pau Monne wrote:
>>> The following series aims to prevent local APIC errors from stalling the
>>> shtudown process. On XenServer testing we have seen reports of
On 2/10/25 5:32 PM, Jan Beulich wrote:
On 07.02.2025 14:13, Oleksii Kurochko wrote:
--- a/xen/arch/riscv/pt.c
+++ b/xen/arch/riscv/pt.c
@@ -185,6 +185,57 @@ static int pt_next_level(bool alloc_tbl, pte_t **table,
unsigned int offset)
return XEN_TABLE_NORMAL;
}
+/*
+ * _pt_walk() pe
Hi Roger,
>>
>> 3) The size of the patch after applying clang-format is huge. Really.
>> Something
>> like 9 MB. Even if everyone agrees that the approach is good and we can
>> proceed
>> with it, it is highly unlikely anyone will be able to review it. Considering
>> that new patches are being
On Mon, Feb 10, 2025 at 11:16:09PM +0200, Oleksandr Andrushchenko wrote:
> Hello, everybody!
>
> What is the rationale behind introducing a tool to help with coding style
> verification? I will partially quote Viktor Mitin here [2]:
>
> "The Xen Project has a coding standard in place, but like ma
On Tue, Feb 11, 2025 at 07:39:12AM +0100, Jan Beulich wrote:
> On 06.02.2025 16:06, Roger Pau Monne wrote:
> > The following series aims to prevent local APIC errors from stalling the
> > shtudown process. On XenServer testing we have seen reports of AMD
> > boxes sporadically getting stuck in a s
On Mon, Feb 10, 2025 at 07:29:35PM +0100, Oleksii Kurochko wrote:
> Hello Roger,
>
> On 2/10/25 11:02 AM, Roger Pau Monné wrote:
> > Hello,
> >
> > This should have had a 'for-4.20?' tag in the subject name, as
> > otherwise we will need to add an errata to the release notes to notice
> > that re
87 matches
Mail list logo
