On 17.09.2025 23:55, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/p2m.c
> +++ b/xen/arch/riscv/p2m.c
> @@ -96,6 +96,41 @@ void __init gstage_mode_detect(void)
> local_hfence_gvma_all();
> }
>
> +/*
> + * Force a synchronous P2M TLB flush.
> + *
> + * Must be called with the p2m lock held.
On 17.09.2025 23:55, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/p2m.c
> +++ b/xen/arch/riscv/p2m.c
> @@ -16,6 +16,7 @@
> #include
>
> unsigned long __ro_after_init gstage_mode;
> +unsigned int __ro_after_init gstage_root_level;
>
> void __init gstage_mode_detect(void)
> {
> @@ -53,6 +5
On 17.09.2025 23:55, Oleksii Kurochko wrote:
> - Extended p2m_type_t with additional types: p2m_mmio_direct,
> p2m_ext_storage.
> - Added macros to classify memory types: P2M_RAM_TYPES.
> - Introduced helper predicates: p2m_is_ram(), p2m_is_any_ram().
> - Introduce arch_dt_passthrough() to tell h
On 17.09.2025 23:55, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/p2m.c
> +++ b/xen/arch/riscv/p2m.c
> @@ -3,6 +3,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -95,6 +96,70 @@ void __init gstage_mode_detect(void)
> local_hfence_gvma_all(
On 17.09.2025 23:55, Oleksii Kurochko wrote:
> Introduce the following things:
> - Update p2m_domain structure, which describe per p2m-table state, with:
> - lock to protect updates to p2m.
> - pool with pages used to construct p2m.
> - back pointer to domain structure.
> - p2m_init() to init
On 17.09.2025 23:55, Oleksii Kurochko wrote:
> @@ -151,6 +152,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
>
> gstage_mode_detect();
>
> +vmid_init();
Like for the earlier patch, I'm not convinced this is a function good
to call from the top-level start_xen(). The two
On 19.09.2025 18:31, Grygorii Strashko wrote:
> --- a/xen/arch/x86/hvm/Kconfig
> +++ b/xen/arch/x86/hvm/Kconfig
> @@ -62,6 +62,17 @@ config ALTP2M
>
> If unsure, stay with defaults.
>
> +config VIRIDIAN
> + bool "Hyper-V enlightenments for guests" if EXPERT
> + depends on AMD_SV
On 18.09.2025 19:17, Grygorii Strashko wrote:
> On 18.09.25 18:41, Jan Beulich wrote:
>> On 16.09.2025 15:41, Grygorii Strashko wrote:
>>> --- a/xen/arch/x86/hvm/viridian/viridian.c
>>> +++ b/xen/arch/x86/hvm/viridian/viridian.c
>>> @@ -1116,14 +1116,14 @@ static int cf_check viridian_save_domain_c
Hi Jan,
Thank you for your comments.
On 19.09.25 18:29, Jan Beulich wrote:
On 18.09.2025 19:17, Grygorii Strashko wrote:
On 18.09.25 18:41, Jan Beulich wrote:
On 16.09.2025 15:41, Grygorii Strashko wrote:
--- a/xen/arch/x86/hvm/viridian/viridian.c
+++ b/xen/arch/x86/hvm/viridian/viridian.c
@
On Fri, Sep 12, 2025 at 12:03:27PM +0300, Leon Romanovsky wrote:
> On Fri, Sep 12, 2025 at 12:25:38AM +0200, Marek Szyprowski wrote:
> > >
> > > This series does the core code and modern flows. A followup series
> > > will give the same treatment to the legacy dma_ops implementation.
> >
> > Appli
Reviewed-by: Yeoreum Yun
On Mon, Sep 08, 2025 at 08:39:25AM +0100, Kevin Brodsky wrote:
> This function has only ever been used in arch/x86, so there is no
> need for other architectures to implement it. Remove it from
> linux/pgtable.h and all architectures besides x86.
>
> The arm64 implementat
you agree with above, I can queue this
series with above touched up, then no need to repost.
I guess I will rewrite this patch, restoring the VFIOQuirk example, and
re-check if this whole section is structured logically and consistently.
Regards,
Akihiko Odaki
On 2025/09/19 3:23, Peter Xu wrote:
On Thu, Sep 18, 2025 at 12:20:49PM -0400, Peter Xu wrote:
On Thu, Sep 18, 2025 at 05:29:34PM +0200, BALATON Zoltan wrote:
On Thu, 18 Sep 2025, Peter Xu wrote:
On Wed, Sep 17, 2025 at 07:13:25PM +0900, Akihiko Odaki wrote:
Based-on:
("[PATCH v2 00/14] hw/pc
On 07.09.2025 18:15, Bernhard Kaindl wrote:
> During the review of the 3rd commit of the NUMA claims v1 series, it
> was found to be concerning (performance-wise) add add another array
> like this that randomly written from all nodes:
>
> +/* Per-node counts of free pages */
> +static unsigned lon
On 08.09.25 09:39, Kevin Brodsky wrote:
Commit 49147beb0ccb ("x86/xen: allow nesting of same lazy mode")
originally introduced support for nested lazy sections (LAZY_MMU and
LAZY_CPU). It later got reverted by commit c36549ff8d84 as its
implementation turned out to be intolerant to preemption.
N
On 10.09.2025 09:38, Penny Zheng wrote:
> --- a/xen/common/sched/core.c
> +++ b/xen/common/sched/core.c
> @@ -1402,10 +1402,12 @@ int vcpu_set_hard_affinity(struct vcpu *v, const
> cpumask_t *affinity)
> return vcpu_set_affinity(v, affinity, v->sched_unit->cpu_hard_affinity);
> }
>
> +#ifd
On 11/09/2025 4:06 am, Marek Marczykowski-Górecki wrote:
> On Wed, Sep 10, 2025 at 11:23:12PM +0100, Andrew Cooper wrote:
>> diff --git a/automation/build/debian/13-x86_64.dockerfile
>> b/automation/build/debian/13-x86_64.dockerfile
>> new file mode 100644
>> index ..20e9d2f3f52d
>> --
On Fri, Sep 12, 2025 at 03:44:24PM +0100, Andrew Cooper wrote:
> Randconfig with GCC-14 (Debian Trixie) found:
>
> In file included from arch/x86/x86_emulate/x86_emulate.c:11,
>from arch/x86/x86_emulate.c:27:
> arch/x86/x86_emulate/x86_emulate.c: In function 'x86_emulate':
On 11.09.2025 13:53, Alejandro Vallejo wrote:
> PVH guests have no DM, so this causes the guest to fetch the online CPU
> bitmap from an unbacked 0xaf00 PIO port when executing the GPE handler.
>
> Seeing how ACPI CPU hotplug is the only event delivered via GPE, remove
> the GPE handler in additio
On 16.09.2025 19:37, dmuk...@xen.org wrote:
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -608,6 +608,9 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
> /* DOMID_INVALID is used to identify pages with unknown owner. */
> #define DOMID_INVALIDxen_mk_uint(0x7FF4)
>
> +/
On Thu Sep 11, 2025 at 5:04 PM CEST, Jan Beulich wrote:
> On 11.09.2025 14:03, Andrew Cooper wrote:
>> On 11/09/2025 12:53 pm, Alejandro Vallejo wrote:
>>> CPU hotplug relies on the online CPU bitmap being provided on PIO 0xaf00
>>> by the device model. The GPE handler checks this and compares it a
On Thu, Sep 18, 2025 at 04:03:49PM -0400, Peter Xu wrote:
> On Wed, Sep 17, 2025 at 07:13:26PM +0900, Akihiko Odaki wrote:
> > Children are automatically unparented so manually unparenting is
> > unnecessary.
> >
> > Worse, automatic unparenting happens before the instance_finalize()
> > callback
On 2025-09-03 03:49, victorm.l...@amd.com wrote:
From: Victor Lira
Filtering jobs using the selected jobs regex is missing for
qemu-export/yocto- jobs when running regular pipelines and eclair jobs
when running scheduled pipelines.
Add the missing rules to filter out those jobs, and set a defa
On Wed, Sep 17, 2025 at 07:13:26PM +0900, Akihiko Odaki wrote:
> Children are automatically unparented so manually unparenting is
> unnecessary.
>
> Worse, automatic unparenting happens before the instance_finalize()
> callback of the parent gets called, so object_unparent() calls in
> the callbac
On Wed, Sep 17, 2025 at 02:23:35PM +0100, Daniel P. Berrangé wrote:
> On Wed, Sep 17, 2025 at 02:17:35PM +0100, Daniel P. Berrangé wrote:
> > On Wed, Sep 17, 2025 at 09:24:04PM +0900, Akihiko Odaki wrote:
> > > On 2025/09/17 20:57, Daniel P. Berrangé wrote:
> > > > On Wed, Sep 17, 2025 at 07:13:25P
On Fri, Sep 12, 2025 at 03:02:15PM +0200, David Hildenbrand wrote:
> How would that work with nesting? I feel like there is a fundamental problem
> with nesting with what you describe but I might be wrong.
My picture is - flush on each lazy_mmu_disable(), pause on lazy_mmu_pause()
and honour only
On Thu, Sep 18, 2025 at 12:20:49PM -0400, Peter Xu wrote:
> On Thu, Sep 18, 2025 at 05:29:34PM +0200, BALATON Zoltan wrote:
> > On Thu, 18 Sep 2025, Peter Xu wrote:
> > > On Wed, Sep 17, 2025 at 07:13:25PM +0900, Akihiko Odaki wrote:
> > > > Based-on:
> > > > ("[PATCH v2 00/14] hw/pci-host/raven c
On Fri, Sep 12, 2025 at 03:44:22PM +0100, Andrew Cooper wrote:
> cpio needs to be in Tools (general) now that it's used by the general build
> script. Merge the rest of the test phase jobs into one group, to avoid being
> overly fine-grain.
>
> No functional change.
>
> Signed-off-by: Andrew Coo
On Wed, Aug 27, 2025 at 09:16:38PM -0400, Jason Andryuk wrote:
> On 2025-08-27 01:57, Jan Beulich wrote:
> > Callers observing errors elsewhere may be confused by the ENOSYS that
> > the Flask operation would yield on a Flask-disabled hypervisor.
> >
> > Signed-off-by: Jan Beulich
> > ---
> > Of
On 09.09.2025 10:14, Mykola Kvach wrote:
> On Tue, Sep 9, 2025 at 9:57 AM Jan Beulich wrote:
>> On 09.09.2025 08:29, Mykola Kvach wrote:
>>> Then, in domain_shutdown(), we can call need_hwdom_shutdown() instead
>>> of directly checking is_hardware_domain(d). This keeps the logic
>>> readable and a
On Fri, Sep 12, 2025 at 11:49:12AM +0200, Jürgen Groß wrote:
> On 11.09.25 17:11, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > The steps:
> > 1. Have domU netfront ("untrusted" here) and domU netback
> > ("sys-firewall-alt" here).
> > 2. Pause frontend
> > 3. Shutdown backend
> > 4. Unpause f
On 18.09.25 18:41, Jan Beulich wrote:
On 16.09.2025 15:41, Grygorii Strashko wrote:
--- a/xen/arch/x86/hvm/Kconfig
+++ b/xen/arch/x86/hvm/Kconfig
@@ -62,6 +62,16 @@ config ALTP2M
If unsure, stay with defaults.
+config HVM_VIRIDIAN
I may have said so already on v1: I'm not quite c
On 18.09.25 18:19, Jan Beulich wrote:
On 18.09.2025 17:15, Grygorii Strashko wrote:
On 16.09.25 16:41, Grygorii Strashko wrote:
--- a/xen/arch/x86/hvm/Kconfig
+++ b/xen/arch/x86/hvm/Kconfig
@@ -62,6 +62,16 @@ config ALTP2M
If unsure, stay with defaults.
+config HVM_VIRIDIAN
+
On Thu, Sep 18, 2025 at 05:29:34PM +0200, BALATON Zoltan wrote:
> On Thu, 18 Sep 2025, Peter Xu wrote:
> > On Wed, Sep 17, 2025 at 07:13:25PM +0900, Akihiko Odaki wrote:
> > > Based-on:
> > > ("[PATCH v2 00/14] hw/pci-host/raven clean ups")
> >
> > Could I ask why this is a dependency?
>
> It re
On Thu, 18 Sep 2025, Peter Xu wrote:
On Wed, Sep 17, 2025 at 07:13:25PM +0900, Akihiko Odaki wrote:
Based-on:
("[PATCH v2 00/14] hw/pci-host/raven clean ups")
Could I ask why this is a dependency?
It removes an address_space usage from raven so this series does not have
to change that and
On 17.09.2025 23:55, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/p2m.c
> @@ -0,0 +1,91 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +unsigned long __ro_after_init gstage_
On 16.09.2025 15:41, Grygorii Strashko wrote:
> --- a/xen/arch/x86/hvm/Kconfig
> +++ b/xen/arch/x86/hvm/Kconfig
> @@ -62,6 +62,16 @@ config ALTP2M
>
> If unsure, stay with defaults.
>
> +config HVM_VIRIDIAN
I may have said so already on v1: I'm not quite convinced of the need
or useful
On 18.09.2025 17:15, Grygorii Strashko wrote:
> On 16.09.25 16:41, Grygorii Strashko wrote:
>> --- a/xen/arch/x86/hvm/Kconfig
>> +++ b/xen/arch/x86/hvm/Kconfig
>> @@ -62,6 +62,16 @@ config ALTP2M
>>
>>If unsure, stay with defaults.
>>
>> +config HVM_VIRIDIAN
>> +bool "Hyper-V enli
Hi All,
On 16.09.25 16:41, Grygorii Strashko wrote:
From: Sergiy Kibrik
Add config option HVM_VIRIDIAN that covers viridian code within HVM.
Calls to viridian functions guarded by is_viridian_domain() and related macros.
Having this option may be beneficial by reducing code footprint for syste
On 18.09.2025 14:16, Mykyta Poturai wrote:
> --- a/config/arm64.mk
> +++ b/config/arm64.mk
> @@ -1,5 +1,6 @@
> CONFIG_ARM := y
> CONFIG_ARM_64 := y
> +CONFIG_HOTPLUG := y
>
> CONFIG_XEN_INSTALL_SUFFIX :=
>
> --- a/config/x86_32.mk
> +++ b/config/x86_32.mk
> @@ -3,6 +3,7 @@ CONFIG_X86_32 := y
On 18.09.2025 15:35, Julien Grall wrote:
> On 18/09/2025 13:16, Mykyta Poturai wrote:
>> +static long cpu_hotplug_sysctl(struct xen_sysctl_cpu_hotplug *hotplug)
>> +{
>> +bool up;
>> +
>> +switch (hotplug->op) {
>> +case XEN_SYSCTL_CPU_HOTPLUG_ONLINE:
>> +if ( hotplug->c
On Wed, Sep 17, 2025 at 07:13:25PM +0900, Akihiko Odaki wrote:
> Based-on:
> ("[PATCH v2 00/14] hw/pci-host/raven clean ups")
Could I ask why this is a dependency?
--
Peter Xu
Hi Mykyta,
On 18/09/2025 13:16, Mykyta Poturai wrote:
Implement XEN_SYSCTL_CPU_HOTPLUG_* calls to allow for enabling/disabling
CPU cores in runtime.
Signed-off-by: Mykyta Poturai
---
xen/arch/arm/sysctl.c | 67 +++
1 file changed, 67 insertions(+)
di
Hi Mykyta,
On 18/09/2025 13:16, Mykyta Poturai wrote:
When stopping a core deinit_timer_interrupt is called in non-alloc
context, which causes xfree in release_irq to fail an assert.
To fix this, switch to a statically allocated irqaction that does not
need to be freed in release_irq.
> > Sign
ter_lazy_mmu_mode() {3}
arch_leave_lazy_mmu_mode() {4}
With the approach this series takes, call {2} is made safe by passing a
special parameter (say LAZY_MMU_FLUSH) that forces lazy_mmu to be fully
exited - and call {3} will then re-enter lazy_mmu. This works regardless
of whether __kasan_p
On Fri, Sep 12, 2025 at 03:44:26PM +0100, Andrew Cooper wrote:
> With the exception of the custom IBT job, copy all Debian 12 jobs making
> Debian 13 versions, then trim the Debian 12 ranconfig jobs.
>
> Update the test jobs using Debian 12 to use 13.
>
> Signed-off-by: Andrew Cooper
> Reviewed-
On Tue, Sep 09, 2025 at 06:15:27PM +0100, Andrew Cooper wrote:
> We have a mix of root and non-root containers, and are trying to become
> rootless. This can cause the local CPIO fragements to end up being user:user
> in the test environment.
>
> Nothing seems to go wrong so far, but it's a trap
On 18.09.25 04:45, kernel test robot wrote:
Hi Juergen,
kernel test robot noticed the following build warnings:
[auto build test WARNING on tip/sched/core]
[also build test WARNING on kvm/queue kvm/next linus/master v6.17-rc6
next-20250917]
[cannot apply to tip/x86/core kvm/linux-next]
[If you
Hi Juergen,
kernel test robot noticed the following build errors:
[auto build test ERROR on tip/sched/core]
[also build test ERROR on kvm/queue kvm/next linus/master v6.17-rc6
next-20250917]
[cannot apply to tip/x86/core kvm/linux-next]
[If your patch is applied to the wrong git tree, kindly dro
Hi Juergen,
kernel test robot noticed the following build warnings:
[auto build test WARNING on tip/sched/core]
[also build test WARNING on kvm/queue kvm/next linus/master v6.17-rc6
next-20250917]
[cannot apply to tip/x86/core kvm/linux-next]
[If your patch is applied to the wrong git tree, kind
Hi Juergen,
kernel test robot noticed the following build errors:
[auto build test ERROR on tip/sched/core]
[also build test ERROR on kvm/queue kvm/next linus/master v6.17-rc6
next-20250917]
[cannot apply to tip/x86/core kvm/linux-next]
[If your patch is applied to the wrong git tree, kindly dro
Hi all,
Just a quick note to say that this series is committed.
Oleksii M you might want to check that everything is in order.
Cheers,
Stefano
On Mon, 8 Sep 2025, Oleksii Moisieiev wrote:
> On 08/09/2025 17:31, Oleksii Kurochko wrote:
> > Hello Oleksii,
> > On 9/8/25 4:21 PM, Oleksii Moisieie
On 9/9/25 11:53 PM, Stefano Stabellini wrote:
On Tue, 9 Sep 2025, Marek Marczykowski-Górecki wrote:
On Sat, Aug 09, 2025 at 11:12:01PM +0100, Andrew Cooper wrote:
I know it's past the last-post deadline, but Trixie was only released today.
In terms of backports, we should at least go back to
FYI, I significant number of these patches got a review already. I
intent to merge these and then send out the others for each driver
individually.
Am 21.08.25 um 10:17 schrieb Thomas Zimmermann:
Dumb-buffer pitch and size is specified by width, height, bits-per-pixel
plus various hardware-spe
On 2025-09-03 03:55, Jan Beulich wrote:
Along the lines of what b89f8f054f96 ("x86/apic: Drop sync_Arb_IDs()")
said, the function is dead logic as well: All 64-bit capable Intel systems
have (at least) xAPIC (if not x2APIC).
Even if Eclair can't know it, such code is violating Misra rule 2.2 (de
On 07.09.2025 16:37, scan-ad...@coverity.com wrote:
> ** CID 1665362: Integer handling issues (INTEGER_OVERFLOW)
> /xen/lib/find-next-bit.c: 104 in find_next_zero_bit()
>
>
> _
> *** CID 1
On 12.09.2025 06:52, Penny Zheng wrote:
> Function vm_event_is_enabled() is introduced to check if vm event is enabled,
> and also make the checking conditional upon CONFIG_VM_EVENT, which could help
> DCE a lot calls/codes, such as hvm_monitor_io(), etc when VM_EVENT=n.
> In-place assertion of arc
On 17.09.2025 23:45, Anthony PERARD wrote:
> From: Anthony PERARD
>
> It is sometime unwelcome for the config of the hypervisor to change.
>
> Make output will be something like that:
> tools/kconfig/conf --syncconfig Kconfig
>
> *** The configuration requires explicit update.
>
> make[
On 9/8/25 11:04 AM, Mykola Kvach wrote:
Hi Denis and Stefano
I’d like to acknowledge the significant effort that went into this patch
series -- it’s clear that a lot of work has been invested.
On Sat, Sep 6, 2025 at 5:02 AM Stefano Stabellini
wrote:
Oleksii and all,
I would like to conside
On Thu Sep 11, 2025 at 5:07 PM CEST, Jan Beulich wrote:
> On 11.09.2025 13:53, Alejandro Vallejo wrote:
>> PVH guests have no DM, so this causes the guest to fetch the online CPU
>> bitmap from an unbacked 0xaf00 PIO port when executing the GPE handler.
>>
>> Seeing how ACPI CPU hotplug is the onl
On 11.09.2025 17:36, Alejandro Vallejo wrote:
> On Thu Sep 11, 2025 at 5:07 PM CEST, Jan Beulich wrote:
>> On 11.09.2025 13:53, Alejandro Vallejo wrote:
>>> ---
>>> v2:
>>> * Adjusted commit message
>>> * All other tags except S-by moved to patch 1.
>>
>> This will want backporting; I expect fi
cleanup_msi().
>> * Given the code in vpci_remove_registers() an error in the removal of
>> registers would likely imply memory corruption, at which point it's
>> best to fully disable the device. So, Rollback the last two modifications
>> of v7.
>>
>
Hi Oleksii,
On 08/09/2025 17:11, Oleksii Kurochko wrote:
> Hello everyone,
> Based on the message from the previous version, the MISRA issues have been
> fixed,
> and aside from one remaining documentation patch ("docs: arm: add docs for
> SCMI
> over SMC calls forwarding driver"), the patch ser
On Thu Sep 11, 2025 at 10:24 AM CEST, Gerald Elder-Vass wrote:
> Commit 59a1d6d3ea1e introduced Shim's LoadImage protocol and unloads the
> image after loading it (for verification purposes) regardless of the
> returned status. The protocol API implies this is the correct behaviour
> but we should
Hi Michal,
Thank you for the patch and the detailed explanation.
On Tue, Sep 9, 2025 at 10:42 AM Michal Orzel wrote:
>
> Commit 061d6782756f modified load_file() to take load command as
> argument but did not change all the invocations (e.g. loading standalone
> Linux, bitstream, etc.) which bro
Hi Jan,
On 11/09/2025 09:14, Jan Beulich wrote:
Other projects have long switched to xz and/or lzip.
Tidy things some as well: With the removal of qemu from the tarball,
intermediately extracting the tarball again has become wasteful. Drop
that. Invoke compressors using asynchronous lists, to r
On 9/17/25 17:16, Jan Beulich wrote:
> On 17.09.2025 15:59, Dmytro Prokopchuk1 wrote:
>>
>>
>> On 9/16/25 23:03, Jan Beulich wrote:
>>> On 16.09.2025 21:35, Dmytro Prokopchuk1 wrote:
On 9/16/25 17:27, Jan Beulich wrote:
> On 16.09.2025 14:45, Dmytro Prokopchuk1 wrote:
>> --
On Thu Sep 11, 2025 at 4:52 PM CEST, Jan Beulich wrote:
> On 11.09.2025 13:53, Alejandro Vallejo wrote:
>> CPU hotplug relies on the online CPU bitmap being provided on PIO 0xaf00
>> by the device model. The GPE handler checks this and compares it against
>> the "online" flag on each MADT LAPIC ent
On Wed Sep 10, 2025 at 5:31 PM CEST, Jan Beulich wrote:
> On 10.09.2025 17:16, Alejandro Vallejo wrote:
>> On Wed Sep 10, 2025 at 5:02 PM CEST, Jan Beulich wrote:
>>> On 10.09.2025 16:49, Alejandro Vallejo wrote:
CPU hotplug relies on the guest having access to the legacy online CPU
bitma
On 08.09.2025 13:04, Alejandro Vallejo wrote:
> On Mon Sep 8, 2025 at 12:19 PM CEST, Jan Beulich wrote:
>> On 07.09.2025 16:37, scan-ad...@coverity.com wrote:
>>> ** CID 1665362: Integer handling issues (INTEGER_OVERFLOW)
>>> /xen/lib/find-next-bit.c: 104 in find_next_zero_bit()
>>
On 08.09.2025 23:11, dmuk...@xen.org wrote:
> --- a/xen/include/xen/8250-uart.h
> +++ b/xen/include/xen/8250-uart.h
> @@ -32,6 +32,7 @@
> #define UART_MCR 0x04/* Modem control*/
> #define UART_LSR 0x05/* line status */
> #define UART_MSR 0x06
On 09.09.25 04:16, Andrew Morton wrote:
On Mon, 8 Sep 2025 08:39:24 +0100 Kevin Brodsky wrote:
The main change enabling nesting is patch 2, following the approach
suggested by Catalin Marinas [4]: have enter() return some state and
the matching leave() take that state.
This is so totally th
On Tue, Sep 09, 2025 at 12:05:41PM +0200, Jan Beulich wrote:
> On 08.09.2025 23:11, dmuk...@xen.org wrote:
> > --- a/xen/include/xen/8250-uart.h
> > +++ b/xen/include/xen/8250-uart.h
> > @@ -32,6 +32,7 @@
> > #define UART_MCR 0x04/* Modem control*/
> > #define UART_LSR
On 11.09.25 17:11, Marek Marczykowski-Górecki wrote:
Hi,
The steps:
1. Have domU netfront ("untrusted" here) and domU netback
("sys-firewall-alt" here).
2. Pause frontend
3. Shutdown backend
4. Unpause frontend
5. Detach network (in my case attaching another one follows just after,
but I believe
On 17.09.2025 06:49, Alexander M. Merritt wrote:
> Hi all, it was requested I send the notes I took during the design discussion
> on the ABI / APIs to the list.
Thanks much. We will want to try to have notes taken more systematically
today.
Jan
I also took notes during this session - as usual apologies for any misquotes
etc:
Christopher Clark (CC): Preparing a collection of docs to understand the
problem space and what we want to achieve ahead of doing the work
- List of API/ABIs
- List of known limitations / issues / concerns with the
On Wed, Sep 17, 2025 at 07:13:32PM +0900, Akihiko Odaki wrote:
> Children are automatically unparented so manually unparenting is
> unnecessary.
>
> Worse, automatic unparenting happens before the instance_finalize()
> callback of the parent gets called, so object_unparent() calls in
> the callbac
On Wed, Sep 17, 2025 at 07:13:31PM +0900, Akihiko Odaki wrote:
> Children are automatically unparented so manually unparenting is
> unnecessary.
>
> Worse, automatic unparenting happens before the instance_finalize()
> callback of the parent gets called, so object_unparent() calls in
> the callbac
On Wed, Sep 17, 2025 at 07:13:30PM +0900, Akihiko Odaki wrote:
> Children are automatically unparented so manually unparenting is
> unnecessary.
>
> Worse, automatic unparenting happens before the instance_finalize()
> callback of the parent gets called, so object_unparent() calls in
> the callbac
On Wed, Sep 17, 2025 at 07:13:29PM +0900, Akihiko Odaki wrote:
> Children are automatically unparented so manually unparenting is
> unnecessary.
>
> Worse, automatic unparenting happens before the instance_finalize()
> callback of the parent gets called, so object_unparent() calls in
> the callbac
On Wed, Sep 17, 2025 at 07:13:28PM +0900, Akihiko Odaki wrote:
> Children are automatically unparented so manually unparenting is
> unnecessary.
>
> Worse, automatic unparenting happens before the instance_finalize()
> callback of the parent gets called, so object_unparent() calls in
> the callbac
On Wed, Sep 17, 2025 at 07:13:27PM +0900, Akihiko Odaki wrote:
> Children are automatically unparented so manually unparenting is
> unnecessary.
>
> Worse, automatic unparenting happens before the insntance_finalize()
> callback of the parent gets called, so object_unparent() calls in
> the callba
On Wed, Sep 17, 2025 at 07:13:26PM +0900, Akihiko Odaki wrote:
> Children are automatically unparented so manually unparenting is
> unnecessary.
>
> Worse, automatic unparenting happens before the instance_finalize()
> callback of the parent gets called, so object_unparent() calls in
> the callbac
On 9/16/25 23:03, Jan Beulich wrote:
> On 16.09.2025 21:35, Dmytro Prokopchuk1 wrote:
>>
>>
>> On 9/16/25 17:27, Jan Beulich wrote:
>>> On 16.09.2025 14:45, Dmytro Prokopchuk1 wrote:
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -98,6 +98,23 @@ Deviations relat
On 2025/09/17 20:57, Daniel P. Berrangé wrote:
On Wed, Sep 17, 2025 at 07:13:25PM +0900, Akihiko Odaki wrote:
Based-on:
("[PATCH v2 00/14] hw/pci-host/raven clean ups")
Supersedes: <20240829-memory-v1-1-ac07af2f4...@daynix.com>
("[PATCH] docs/devel: Prohibit calling object_unparent() for memor
On Wed, Sep 17, 2025 at 02:17:35PM +0100, Daniel P. Berrangé wrote:
> On Wed, Sep 17, 2025 at 09:24:04PM +0900, Akihiko Odaki wrote:
> > On 2025/09/17 20:57, Daniel P. Berrangé wrote:
> > > On Wed, Sep 17, 2025 at 07:13:25PM +0900, Akihiko Odaki wrote:
> > > > Based-on:
> > > > ("[PATCH v2 00/14]
On Wed, Sep 17, 2025 at 09:24:04PM +0900, Akihiko Odaki wrote:
> On 2025/09/17 20:57, Daniel P. Berrangé wrote:
> > On Wed, Sep 17, 2025 at 07:13:25PM +0900, Akihiko Odaki wrote:
> > > Based-on:
> > > ("[PATCH v2 00/14] hw/pci-host/raven clean ups")
> > >
> > > Supersedes: <20240829-memory-v1-1-a
On 17.09.2025 15:59, Dmytro Prokopchuk1 wrote:
>
>
> On 9/16/25 23:03, Jan Beulich wrote:
>> On 16.09.2025 21:35, Dmytro Prokopchuk1 wrote:
>>>
>>>
>>> On 9/16/25 17:27, Jan Beulich wrote:
On 16.09.2025 14:45, Dmytro Prokopchuk1 wrote:
> --- a/docs/misra/deviations.rst
> +++ b/docs/m
On 16.09.2025 22:51, Andrew Cooper wrote:
> On 16/09/2025 1:05 pm, Jan Beulich wrote:
>> On 16.09.2025 19:37, dmuk...@xen.org wrote:
>>> --- a/xen/include/public/xen.h
>>> +++ b/xen/include/public/xen.h
>>> @@ -608,6 +608,9 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
>>> /* DOMID_INVALID is used to i
On Wed, Sep 17, 2025 at 07:13:25PM +0900, Akihiko Odaki wrote:
> Based-on:
> ("[PATCH v2 00/14] hw/pci-host/raven clean ups")
>
> Supersedes: <20240829-memory-v1-1-ac07af2f4...@daynix.com>
> ("[PATCH] docs/devel: Prohibit calling object_unparent() for memory region")
>
> Children are automatical
Hi Julien,
Thank you for the review.
On Sat, Sep 13, 2025 at 2:30 AM Julien Grall wrote:
>
> Hi Mykola,
>
> On 01/09/2025 23:10, Mykola Kvach wrote:
> > From: Mirela Simonovic
> >
> > System suspend may lead to a state where GIC would be powered down.
> > Therefore, Xen should save/restore the
Hi Julien,
Thank you for the review.
On Sat, Sep 13, 2025 at 2:45 AM Julien Grall wrote:
>
> Hi Mykola,
>
> On 01/09/2025 23:10, Mykola Kvach wrote:
> > From: Mykola Kvach
> >
> > If we call disable_nonboot_cpus on ARM64 with system_state set
> > to SYS_STATE_suspend, the following assertion wi
On 16.09.2025 21:35, Dmytro Prokopchuk1 wrote:
>
>
> On 9/16/25 17:27, Jan Beulich wrote:
>> On 16.09.2025 14:45, Dmytro Prokopchuk1 wrote:
>>> --- a/docs/misra/deviations.rst
>>> +++ b/docs/misra/deviations.rst
>>> @@ -98,6 +98,23 @@ Deviations related to MISRA C:2012 Rules:
>>> even wh
On 16/09/2025 1:05 pm, Jan Beulich wrote:
> On 16.09.2025 19:37, dmuk...@xen.org wrote:
>> --- a/xen/include/public/xen.h
>> +++ b/xen/include/public/xen.h
>> @@ -608,6 +608,9 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
>> /* DOMID_INVALID is used to identify pages with unknown owner. */
>> #define
Hi Ayan,
On 12.09.25 20:00, Ayan Kumar Halder wrote:
Introduce CONFIG_GICV3_SELFTEST to enclose tests for GICv3 driver.
Test that Xen is able to generate SGIs.
Signed-off-by: Ayan Kumar Halder
---
One of the aim of functional safety is to test hw/sw interface. This means that
Xen is able to co
On 9/16/25 12:32 PM, Grygorii Strashko wrote:
From: Grygorii Strashko
Since commit b99227347230 ("x86: Fix AMD_SVM and INTEL_VMX dependency") the
AMD-V support can be gracefully disabled, but it still keeps SVM
code partially built-in, because HVM code uses mix of:
- "cpu_has_svm" macro, which
On 16/09/2025 10:37 am, dmuk...@xen.org wrote:
> From: Denis Mukhin
>
> Add a new symbol DOMID_ANY aliasing DOMID_INVALID to improve the readability
> of the code.
>
> Update all relevant domid_alloc() call sites.
>
> Amends: 2d5065060710 ("xen/domain: unify domain ID allocation")
> Signed-off-by
On 16/09/2025 9:57 am, Grygorii Strashko wrote:
> Hi Jan,
>
> On 16.09.25 17:34, Jan Beulich wrote:
>> On 16.09.2025 12:32, Grygorii Strashko wrote:
>>> From: Grygorii Strashko
>>>
>>> Since commit b99227347230 ("x86: Fix AMD_SVM and INTEL_VMX
>>> dependency") the
>>> HVM Intel VT-x support can be
Hi Jan,
On 16.09.25 17:34, Jan Beulich wrote:
On 16.09.2025 12:32, Grygorii Strashko wrote:
From: Grygorii Strashko
Since commit b99227347230 ("x86: Fix AMD_SVM and INTEL_VMX dependency") the
HVM Intel VT-x support can be gracefully disabled, but it still keeps VMX
code partially built-in, be
On 12/09/2025 10:47 am, Grygorii Strashko wrote:
> From: Grygorii Strashko
>
> Use define X86_MODE_64BIT instead of constant in hvm_hypercall() for "mode"
> conditional check to improve code readability.
>
> Signed-off-by: Grygorii Strashko
Acked-by: Andrew Cooper
but this really needs to wait
1 - 100 of 56534 matches
Mail list logo
