On 07.02.2025 22:33, dm...@proton.me wrote:
> Add is_console_printable() to implement a common check for printable
> characters
> in the UART emulation and guest logging code.
>
> Signed-off-by: Denis Mukhin
> ---
> xen/arch/arm/vuart.c | 5 ++---
> xen/arch/x86/hvm/hvm.c | 5 ++---
>
On 2/7/25 2:30 PM, Jan Beulich wrote:
On 07.02.2025 14:13, Oleksii Kurochko wrote:
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 parti
On 2/7/25 11:01 PM, Andrew Cooper wrote:
Without this, RISC-V isn't running boot time selftests when they're compiled
in.
Signed-off-by: Andrew Cooper
---
CC: Oleksii Kurochko
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
https:
On 2/7/25 11:01 PM, Andrew Cooper wrote:
JAL has a maximium displacement of 2M. To branch further, it needs pairing
with an AUIPC instruction. CALL is a pseudo-op which allows the linker to
pick the appropriate sequence while processing relaxations.
This avoids a build failure of the form:
Hello everyone,
The hard code freeze date for Xen 4.20 is started from February 07, 2025
to February 21, 2025.
Bug fixes for serious bugs (including regressions), and low-risk fixes
only may continue to be accepted by maintainers beyond this point.
For straightforward bugs and fixes, an R-Ack i
On 2/8/25 1:02 AM, Andrew Cooper wrote:
Right now, run_in_exception_handler() takes an input in an arbitrary register,
and clobbers BUG_FN_REG. This causes the compiler to calculate fn in the
wrong regsiter.
Probably, we should give a chance for the patch which suggests to use
GENERIC_BUG_FR
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
>
> Reviewed-by: Stefano Stabellini
Hmm, don't you think ...
>> @@ -70,22 +71,8 @@
>> #
On 2/8/25 1:02 AM, Andrew Cooper wrote:
Three architectures have an identical dump_execution_state(), and PPC has a
stub for show_execution_state() that just isn't wired up yet.
show_execution_state() is declared in a common header, meaning that
dump_execution_state() really ought to be too. M
On 08.02.2025 01:02, Andrew Cooper wrote:
> Three architectures have an identical dump_execution_state(), and PPC has a
> stub for show_execution_state() that just isn't wired up yet.
>
> show_execution_state() is declared in a common header, meaning that
> dump_execution_state() really ought to b
On 2/7/25 11:01 PM, Andrew Cooper wrote:
One bugfix, and two minor patches to get UBSAN working with RISCV. They
should be considered for 4.20 at this juncture.
Considering that RISC-V port isn't really usable and changes are quite
straightforward
and low risk:
Release-Acked-By: Oleksii Kur
On 2/7/25 11:01 PM, Andrew Cooper wrote:
RISC-V has less complicated headers, so update ubsan.c to pull in everything
it needs. Provide dump_execution_state(), and update the printk() message to
make it more obvious that it's an outstanding task.
As with commit 8ef2ac727e21 ("automation: enabl
On 06.02.2025 16:06, Roger Pau Monne wrote:
> --- a/xen/arch/x86/crash.c
> +++ b/xen/arch/x86/crash.c
> @@ -177,6 +177,7 @@ static void nmi_shootdown_cpus(void)
>
> disable_IO_APIC();
> hpet_disable();
> +pci_disable_msi_all();
> }
Apart from my concern below regar
On 10.02.2025 11:30, Mykyta Poturai wrote:
> This series introduces SMMU handling for PCIe passthrough on ARM. These
> patches
> should be able to be upstreamed independently from the vPCI series [1]. See
> [2]
> for notes about test cases.
>
> [1] https://lists.xenproject.org/archives/html/xen-
On Mon, Feb 10, 2025 at 11:20:20AM +0100, Jan Beulich wrote:
> On 06.02.2025 16:06, 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 10.02.2025 11:30, Mykyta Poturai wrote:
> --- a/xen/include/xen/iommu.h
> +++ b/xen/include/xen/iommu.h
> @@ -238,6 +238,14 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl, struct
> domain *d,
> */
> int iommu_remove_dt_device(struct dt_device_node *np);
>
> +/*
> + * Status code indic
On Mon, Feb 10, 2025 at 11:24:58AM +0100, Jan Beulich wrote:
> On 06.02.2025 16:06, Roger Pau Monne wrote:
> > 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 th
On 10.02.25 12:42, Jan Beulich wrote:
> On 10.02.2025 11:30, Mykyta Poturai wrote:
>> This series introduces SMMU handling for PCIe passthrough on ARM. These
>> patches
>> should be able to be upstreamed independently from the vPCI series [1]. See
>> [2]
>> for notes about test cases.
>>
>> v7-v8
On 10.02.2025 11:30, Mykyta Poturai wrote:
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #ifdef CONFIG_X86
> @@ -744,6 +745,18 @@ int __init
> iommu_get_extra_reserved_devi
On 10.02.2025 11:30, Mykyta Poturai wrote:
> From: Stewart Hildebrand
>
> Enable the use of IOMMU + PCI in dom0 without having to specify
> "pci-passthrough=yes".
Why? It _is_ passing through, even if Dom0 is special.
> @@ -83,9 +84,9 @@ static int __init pci_init(void)
> {
> /*
> *
On 08/02/2025 01:02, Andrew Cooper wrote:
>
>
> Right now, run_in_exception_handler() takes an input in an arbitrary register,
> and clobbers BUG_FN_REG. This causes the compiler to calculate fn in the
> wrong regsiter.
>
> Instead, use `register asm()` which is the normal way of tying regis
On Fri, Dec 06, 2024 at 06:17:23PM +0800, Jinjie Ruan wrote:
> The generic entry code expects architecture code to provide
> regs_irqs_disabled(regs) function, but arm64 does not have this and
> provides inerrupts_enabled(regs), which has the opposite polarity.
>
> In preparation for moving arm64
On 06.02.2025 16:06, 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.
Yet then ...
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -663,6 +663,12 @@ void iom
On 08/02/2025 01: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/setup.c b/xen/arch/arm/setup.c
> index c1f2d1b89d43..58d1d048d339 100644
> --- a/xen/arch/arm
On 06.02.2025 16:06, 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
On 06.02.2025 16:06, Roger Pau Monne wrote:
> 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é
> ---
>
From: Oleksandr Andrushchenko
Implement support for PCI devices in the SMMU driver. Make arm_smmu_master
structure to hold a pointer to the device to allow it to hold PCI devices.
Trigger iommu-map parsing when new PCI device is added. Add checks to
assign/deassign functions to ensure PCI devices
From: Oleksandr Tyshchenko
The main purpose of this patch is to add a way to register PCI device
(which is behind the IOMMU) using the generic PCI-IOMMU DT bindings [1]
before assigning that device to a domain.
This behaves similarly to the existing iommu_add_dt_device API, except it
handles PCI
From: Rahul Singh
Implement support for PCI devices in the SMMU driver. Trigger iommu-map
parsing when new PCI device is added. Add checks to assign/deassign
functions to ensure PCI devices are handled correctly. Implement basic
quarantining.
All pci devices are automatically assigned to hardwar
From: Rahul Singh
When ITS is enabled and PCI devices that are behind an SMMU generate an
MSI interrupt, SMMU fault will be observed as there is currently no
mapping in p2m table for the ITS translation register (GITS_TRANSLATER).
A mapping is required in the iommu page tables so that the device
From: Rahul Singh
Current code skip the mapping for PCI bridge MMIO region to dom0 when
pci_passthrough_enabled flag is set. Mapping should be skip when
has_vpci(d) is enabled for the domain, as we need to skip the mapping
only when VPCI handler are registered for ECAM.
Signed-off-by: Rahul Sing
From: Oleksandr Tyshchenko
Move code for processing DT IOMMU specifier to a separate helper.
This helper will be re-used for adding PCI devices by the subsequent
patches as we will need exact the same actions for processing
DT PCI-IOMMU specifier.
While at it introduce DT_NO_IOMMU to avoid magic
This series introduces SMMU handling for PCIe passthrough on ARM. These patches
should be able to be upstreamed independently from the vPCI series [1]. See [2]
for notes about test cases.
[1] https://lists.xenproject.org/archives/html/xen-devel/2023-10/msg00660.html
[2] https://lists.xenproject.or
From: Stewart Hildebrand
Handle phantom functions in iommu_add_dt_pci_sideband_ids(). Each phantom
function will have a unique requestor ID (RID)/BDF. On ARM, we need to
map/translate the RID/BDF to an AXI stream ID for each phantom function
according to the pci-iommu device tree mapping [1]. The
From: Stewart Hildebrand
Enable the use of IOMMU + PCI in dom0 without having to specify
"pci-passthrough=yes". We rely on dom0 to initialize the PCI controller
and perform a PHYSDEVOP_pci_device_add call to add each device to SMMU.
Enable pci_init() for initializing Xen's internal PCI subsystem
On 07.02.2025 21:00, Oleksii Kurochko wrote:
>
> On 2/7/25 5:47 PM, Oleksii Kurochko wrote:
>>
>>
>> On 2/4/25 12:47 PM, Jan Beulich wrote:
+const struct riscv_isa_ext_data __initconst riscv_isa_ext[] = {
+RISCV_ISA_EXT_DATA(i, RISCV_ISA_EXT_i),
+RISCV_ISA_EXT_DATA(m, RISCV_
On 06.02.2025 16:08, Roger Pau Monné wrote:
> On Tue, Feb 04, 2025 at 02:04:35PM +0100, Jan Beulich wrote:
>> Have callers invoke pci_add_segment() directly instead: With radix tree
>> initialization moved out of the function, its name isn't quite
>> describing anymore what it actually does.
>>
>>
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 reboot can sometimes fail on AMD boxes.
Also adding Oleksii.
Thanks, Roger.
On Thu, Feb 06, 2025 at 04:06:10PM +0100, Roger Pau Monne wrote:
> Hello,
On Fri, Dec 06, 2024 at 06:17:24PM +0800, Jinjie Ruan wrote:
> The generic entry code uses irqentry_state_t to track lockdep and RCU
> state across exception entry and return. For historical reasons, arm64
> embeds similar fields within its pt_regs structure.
>
> In preparation for moving arm64 ov
On 10.02.2025 11:46, Roger Pau Monné wrote:
> On Mon, Feb 10, 2025 at 11:20:20AM +0100, Jan Beulich wrote:
>> On 06.02.2025 16:06, 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 A
On Mon, Feb 10, 2025 at 11:01:04AM +0100, Jan Beulich wrote:
> On 06.02.2025 16:08, Roger Pau Monné wrote:
> > On Tue, Feb 04, 2025 at 02:04:35PM +0100, Jan Beulich wrote:
> >> Have callers invoke pci_add_segment() directly instead: With radix tree
> >> initialization moved out of the function, its
On Fri, Dec 06, 2024 at 06:17:30PM +0800, Jinjie Ruan wrote:
> In generic entry, when PREEMPT_DYNAMIC is enabled or disabled, two
> different helpers are used to check whether resched is required
> and some common code is reused.
>
> In preparation for moving arm64 over to the generic entry code,
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
> > entry makes maintainers' work easier and c
On Fri, Dec 06, 2024 at 06:17:31PM +0800, Jinjie Ruan wrote:
> As Mark pointed out, do not try to switch to *all* the
> generic entry code in one go. The regular entry state management
> (e.g. enter_from_user_mode() and exit_to_user_mode()) is largely
> separate from the syscall state management. M
On Fri, Dec 06, 2024 at 06:17:27PM +0800, Jinjie Ruan wrote:
> The generic entry code uses preempt_count() and need_resched() helpers to
> check if it is time to resched. Currently, arm64 use its own check logic,
> that is "READ_ONCE(current_thread_info()->preempt_count == 0", which is
> equivalent
On Fri, Dec 06, 2024 at 06:17:32PM +0800, Jinjie Ruan wrote:
> ARM64 requires an additional check whether to reschedule on return
> from interrupt.
>
> Add arch_irqentry_exit_need_resched() as the default NOP
> implementation and hook it up into the need_resched() condition in
> raw_irqentry_exit_
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 root, vaddr_t virt,
> -
On Sat, Feb 08, 2025, Michael Kelley wrote:
> From: Sean Christopherson Sent: Friday, February 7, 2025
> 9:23 AM
> >
> > Dropping a few people/lists whose emails are bouncing.
> >
> > On Fri, Jan 31, 2025, Sean Christopherson wrote:
> > > @@ -369,6 +369,11 @@ void __init kvmclock_init(void)
> >
On 07/02/25 19:37, Frederic Weisbecker wrote:
> Le Fri, Feb 07, 2025 at 06:06:45PM +0100, Valentin Schneider a écrit :
>>
>> S I've been thinking...
>>
>> Isn't
>>
>> (context_tracking.state & CT_RCU_WATCHING)
>>
>> pretty much a proxy for knowing whether a CPU is executing in kernelspace,
>>
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
> + * ordering, so for our purpo
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() performs software page table wa
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 codes
> more elegant.
>
> Switch arm64 to gener
On Fri, Dec 06, 2024 at 06:17:25PM +0800, Jinjie Ruan wrote:
> The generic entry code try to reschedule every time when the kernel
> mode non-NMI exception return. At the moment, arm64 only reschedule every
> time when EL1 irq exception return;
I think this is a bit unclear, and should say somethi
On Fri, Dec 06, 2024 at 06:17:26PM +0800, Jinjie Ruan wrote:
> The generic entry do preempt_schedule_irq() by checking if need_resched()
> satisfied, but arm64 has some of its own additional checks such as
> GIC priority masking.
>
> In preparation for moving arm64 over to the generic entry code,
On 10.02.25 12:56, Jan Beulich wrote:
> On 10.02.2025 11:30, Mykyta Poturai wrote:
>> From: Stewart Hildebrand
>>
>> Enable the use of IOMMU + PCI in dom0 without having to specify
>> "pci-passthrough=yes".
>
> Why? It _is_ passing through, even if Dom0 is special.
Do you think it would be bette
On 10.02.2025 12:28, Mykyta Poturai wrote:
> On 10.02.25 12:56, Jan Beulich wrote:
>> On 10.02.2025 11:30, Mykyta Poturai wrote:
>>> From: Stewart Hildebrand
>>>
>>> Enable the use of IOMMU + PCI in dom0 without having to specify
>>> "pci-passthrough=yes".
>>
>> Why? It _is_ passing through, even
On Fri, Dec 06, 2024 at 06:17:28PM +0800, Jinjie Ruan wrote:
> The generic entry has the same logic as need_irq_preemption()
> macro and use a helper function to check other resched condition.
>
> In preparation for moving arm64 over to the generic entry code,
> check and expand need_irq_preemptio
On Fri, Dec 06, 2024 at 06:17:29PM +0800, Jinjie Ruan wrote:
> The generic entry check PREEMPTION for both PREEMPT_DYNAMIC
> enabled and PREEMPT_DYNAMIC disabled.
>
> Whether PREEMPT_DYNAMIC enabled or not, PREEMPTION should
> be enabled to allow reschedule before EL1 exception return, so
> move P
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 reboot can sometimes fail on AMD boxes.
Also adding Oleksii.
Thanks, Roger.
On Thu, Feb 0
On 17/01/25 16:52, Jann Horn wrote:
> On Fri, Jan 17, 2025 at 4:25 PM Valentin Schneider
> wrote:
>> On 14/01/25 19:16, Jann Horn wrote:
>> > On Tue, Jan 14, 2025 at 6:51 PM Valentin Schneider
>> > wrote:
>> >> vunmap()'s issued from housekeeping CPUs are a relatively common source of
>> >> int
Hi,
On 08/02/2025 00:02, Andrew Cooper wrote:
Right now, run_in_exception_handler() takes an input in an arbitrary register,
and clobbers BUG_FN_REG. This causes the compiler to calculate fn in the
wrong regsiter.
Just to confirm, you mean, the compiler is not clever enough to notice
that th
On 10/02/2025 09:21, Oleksii Kurochko wrote:
On 2/8/25 1:02 AM, Andrew Cooper wrote:
Right now, run_in_exception_handler() takes an input in an arbitrary register,
and clobbers BUG_FN_REG. This causes the compiler to calculate fn in the
wrong regsiter.
Probably, we should give a chance fo
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
two registers, PCI_REBAR_CAP and PCI_REBAR_CTRL. So, add
handlers to su
On 10/02/2025 9:03 am, Oleksii Kurochko wrote:
>
>
> On 2/7/25 11:01 PM, Andrew Cooper wrote:
>> RISC-V has less complicated headers, so update ubsan.c to pull in everything
>> it needs. Provide dump_execution_state(), and update the printk() message to
>> make it more obvious that it's an outstan
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 many projects, the
standard is only enforced through peer review. Such mistakes slip t
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/setup.c b/xen/arch/arm/setup.c
index c1f2d1b89d43..58d1d048d339 100644
--- a/xen/arch/arm/set
Thanks Oleksandr for the summary. Adding a few maintainers in CC
On Mon, 10 Feb 2025, 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 Projec
Hi all,
We have received requests to introduce Dom0less vCPU affinity bindings
to allow configuring which pCPUs a given vCPU is allowed to run on.
After considering different approaches, I am thinking of using the
following binding format:
vcpu0 {
compatible = "xen,vcpu-affinity";
On 25/1/25 19:13, Philippe Mathieu-Daudé wrote:
Philippe Mathieu-Daudé (9):
hw/sysbus: Use sizeof(BusState) in main_system_bus_create()
hw/sysbus: Declare QOM types using DEFINE_TYPES() macro
hw/sysbus: Introduce TYPE_DYNAMIC_SYS_BUS_DEVICE
hw/vfio: Have VFIO_PLATFORM devices inherit
On 10/02/2025 10:13 am, Orzel, Michal wrote:
>
> On 08/02/2025 01: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/setup.c b/xen/arch/arm/setup.c
>> index c1f2d1b89
On 10/02/2025 9:31 pm, Julien Grall wrote:
>
>
> On 10/02/2025 09:21, Oleksii Kurochko wrote:
>>
>> On 2/8/25 1:02 AM, Andrew Cooper wrote:
>>> Right now, run_in_exception_handler() takes an input in an arbitrary
>>> register,
>>> and clobbers BUG_FN_REG. This causes the compiler to calculate fn
>
On 10/02/2025 9:29 pm, Julien Grall wrote:
> Hi,
>
> On 08/02/2025 00:02, Andrew Cooper wrote:
>> Right now, run_in_exception_handler() takes an input in an arbitrary
>> register,
>> and clobbers BUG_FN_REG. This causes the compiler to calculate fn in
>> the
>> wrong regsiter.
>
> Just to confirm,
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 wouldn't contain any kernel
> range transla
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/setup.c b/xen/arch/arm/setup.c
>> index
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 spam of:
>
> APIC error on CPU0: 00(08), Receive accept error
>
> Me
From: Denis Mukhin
Add is_console_printable() to implement a common check for printable characters
in the UART emulation and guest logging code.
Signed-off-by: Denis Mukhin
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- switched from tabs to 4 spaces
- Link to v1:
https://lore.kernel.or
From: Denis Mukhin
Signed-off-by: Denis Mukhin
---
tools/hotplug/Linux/init.d/sysconfig.xencommons.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
index 1bdd830d8a..17
On Monday, February 10th, 2025 at 1:27 AM, Jan Beulich
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
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 to the original patch:
https://lore.kernel.org/xen-devel/20
78 matches
Mail list logo
