On 7/25/25 03:58, Roger Pau Monné wrote:
> On Thu, Jul 24, 2025 at 06:44:32PM +0200, Roger Pau Monné wrote:
>> On Wed, Jul 23, 2025 at 12:37:41PM -0400, Stewart Hildebrand wrote:
>>> @@ -283,7 +297,48 @@ static int __init apply_map(struct domain *d, const
>>> struct pci_dev *pdev,
>>> return
In vcpu_create after scheduler data is allocated, if
vmtrace_alloc_buffer fails, it will jump to the wrong cleanup label
resulting in a memory leak.
Move sched_destroy_vcpu and destroy_waitqueue_vcpu to vcpu_teardown.
Make vcpu_teardown idempotent: deal with NULL unit.
Fix vcpu_runstate_get (call
On Fri, Aug 01, 2025 at 08:02:56AM +0200, Jan Beulich wrote:
> On 31.07.2025 22:55, dm...@proton.me wrote:
> > On Wed, Jul 09, 2025 at 04:57:44PM +0200, Jan Beulich wrote:
> >> On 24.06.2025 05:56, dm...@proton.me wrote:
> >>> @@ -458,16 +459,16 @@ struct arch_domain
> >>> } __cacheline_aligned;
>
On Fri, Aug 01, 2025 at 10:08:54AM +, Grygorii Strashko wrote:
> From: Grygorii Strashko
>
> Hence prerequisite patch was merged [1] arch specific pIRQ callback can now
> be dropped for arches without pIRQ support as those callback become
> unreachable.
>
> [1] commit 341f271cf86f ("xen/evt
On Fri, Aug 01, 2025 at 03:54:30PM +, Grygorii Strashko wrote:
> From: Grygorii Strashko
>
> Call stack for dom0less hwdom case (1:1) memory:
> create_domUs
> |-construct_domU
> |-construct_hwdom()
> |-allocate_memory_11()
>
> And allocate_memory_11() uses "dom0_mem" as:
> min_low_orde
On Fri, Aug 01, 2025 at 09:30:34AM +0200, Jan Beulich wrote:
> Them not being altered by any means, their __read_mostly attribute is
> actually counter-productive: It causes the compiler to instantiate the
> variables, when already with just the attributes dropped the compiler
> can constant-propag
On Fri, Aug 01, 2025 at 12:44:57PM +0100, Frediano Ziglio wrote:
> On Fri, Aug 1, 2025 at 12:25 PM Andrew Cooper
> wrote:
> >
> > Hello,
> >
> > There's a long-standing irritation in Xen, whereby printk()'s which
> > occur prior to console_init_preirq() get half-lost.
> >
> > They end up in the c
From: Grygorii Strashko
Call stack for dom0less hwdom case (1:1) memory:
create_domUs
|-construct_domU
|-construct_hwdom()
|-allocate_memory_11()
And allocate_memory_11() uses "dom0_mem" as:
min_low_order =
get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
In case of dom0less boo
On Fri, Jul 25, 2025 at 03:31:12PM -0500, Aaron Rainbolt wrote:
> Xen traditionally allows customizing guest behavior by passing arguments
> to the VM kernel via the kernel command line. This is no longer possible
> when using GRUB with Xen, as the kernel command line is decided by the
> GRUB confi
On Fri, Aug 1, 2025 at 12:25 PM Andrew Cooper wrote:
>
> Hello,
>
> There's a long-standing irritation in Xen, whereby printk()'s which
> occur prior to console_init_preirq() get half-lost.
>
> They end up in the console ring, and hence are available via `xl dmesg`,
> but they're missing from seri
Hello,
There's a long-standing irritation in Xen, whereby printk()'s which
occur prior to console_init_preirq() get half-lost.
They end up in the console ring, and hence are available via `xl dmesg`,
but they're missing from serial console.
e.g. these 4 lines don't escape
(XEN) Enabling loc
On 8/1/25 13:53, Jan Beulich wrote:
> On 01.08.2025 12:48, Dmytro Prokopchuk1 wrote:
>> The conversion from a function pointer with the 'noreturn' attribute
>> ('void noreturn (*)(...)') to a function pointer type ('void (*)(...)'
>> causes type incompatibility according to MISRA C Rule 11.1, whi
On 2025-08-01 12:53, Jan Beulich wrote:
On 01.08.2025 12:48, Dmytro Prokopchuk1 wrote:
The conversion from a function pointer with the 'noreturn' attribute
('void noreturn (*)(...)') to a function pointer type ('void (*)(...)'
causes type incompatibility according to MISRA C Rule 11.1, which
for
On 01.08.2025 12:48, Dmytro Prokopchuk1 wrote:
> The conversion from a function pointer with the 'noreturn' attribute
> ('void noreturn (*)(...)') to a function pointer type ('void (*)(...)'
> causes type incompatibility according to MISRA C Rule 11.1, which
> forbids conversions between incompatib
The conversion from a function pointer with the 'noreturn' attribute
('void noreturn (*)(...)') to a function pointer type ('void (*)(...)'
causes type incompatibility according to MISRA C Rule 11.1, which
forbids conversions between incompatible function pointer types.
The violation occurs at the
On 01/08/2025 11:08 am, Grygorii Strashko wrote:
> From: Grygorii Strashko
>
> Hence prerequisite patch was merged [1] arch specific pIRQ callback can now
> be dropped for arches without pIRQ support as those callback become
> unreachable.
>
> [1] commit 341f271cf86f ("xen/evtchn: fully restrict
From: Grygorii Strashko
Hence prerequisite patch was merged [1] arch specific pIRQ callback can now
be dropped for arches without pIRQ support as those callback become unreachable.
[1] commit 341f271cf86f ("xen/evtchn: fully restrict concept of pIRQ for arches
with pIRQ support only")
Grygorii
From: Grygorii Strashko
Hence all common pIRQ code is under CONFIG_HAS_PIRQ idefs corresponding PPC
arch pIRQ callbacks become unreachable, so drop them.
Signed-off-by: Grygorii Strashko
---
xen/arch/ppc/stubs.c | 20
1 file changed, 20 deletions(-)
diff --git a/xen/arch/
From: Grygorii Strashko
Hence all common pIRQ code is under CONFIG_HAS_PIRQ idefs corresponding
RISCV arch pIRQ callbacks become unreachable, so drop them.
Signed-off-by: Grygorii Strashko
---
xen/arch/riscv/stubs.c | 20
1 file changed, 20 deletions(-)
diff --git a/xen/a
From: Grygorii Strashko
Hence all common pIRQ code is under CONFIG_HAS_PIRQ idefs corresponding Arm
arch pIRQ callbacks become unreachable, so drop them.
Signed-off-by: Grygorii Strashko
---
xen/arch/arm/irq.c | 29 -
1 file changed, 29 deletions(-)
diff --git a/xe
On Thu, Jul 31, 2025 at 4:35 PM Jan Beulich wrote:
>
> On 25.07.2025 17:06, Edwin Török wrote:
> > Using `aa2u` tool.
> >
> > Signed-off-by: Edwin Török
>
> How come the use of that tool made ...
>
> > --- a/xen/include/public/arch-x86/pmu.h
> > +++ b/xen/include/public/arch-x86/pmu.h
> > @@ -75,
From: Luca Fancellu
Currently pci_add_device is called from hypercalls requested by Dom0
to add pci devices and when the device has no domain associated with
it, it is assumed that hardware_domain is the owner.
On the dom0less scenario, the enumeration is performed by the
firmware and Xen at boo
This series adds basic PCI device enumeration in Xen. This will allow us to not
rely on Dom0 enumeration for supported controllers, which will enable PCI
passthrough for dom0less setups.
Enumeration is disabled by default and can be enabled with "pci-scan" cmdline
option. Discovered devices are ad
From: Luca Fancellu
Create add_discovered_pci_devices function that calls pci_device_add
on every PCI device discovered.
The devices will be added to dom_io so that they can be assigned
later to other domains.
Signed-off-by: Luca Fancellu
Signed-off-by: Mykyta Poturai
---
(cherry picked from c
From: Edward Pickup
This patch adds a Xen boot arguments that, if enabled, causes a call to
existing code to scan pci devices enumerated by the firmware.
This patch also makes an existing debug function viewable outside its
translation unit, and uses this to dump the PCI devices found.
The debug
On 31.07.2025 23:42, dm...@proton.me wrote:
> On Thu, Jul 31, 2025 at 08:54:10AM +0200, Jan Beulich wrote:
>> On 30.07.2025 20:31, dm...@proton.me wrote:
>>> On Wed, Jul 30, 2025 at 10:12:54AM +0200, Jan Beulich wrote:
On 30.07.2025 05:13, dm...@proton.me wrote:
> From: Denis Mukhin
>
On 31.07.2025 23:28, dm...@proton.me wrote:
> On Thu, Jul 31, 2025 at 08:23:16AM +0200, Jan Beulich wrote:
>> On 30.07.2025 20:06, dm...@proton.me wrote:
>>> On Wed, Jul 30, 2025 at 07:35:04AM +0200, Jan Beulich wrote:
On 30.07.2025 00:18, dm...@proton.me wrote:
> On Mon, Jul 28, 2025 at 1
Them not being altered by any means, their __read_mostly attribute is
actually counter-productive: It causes the compiler to instantiate the
variables, when already with just the attributes dropped the compiler
can constant-propagate the values into the sole use site. Make the
situation yet more ex
Hi,
A gentle ping for someone to review this :-)
Thanks
Bertrand
> On 17 Jul 2025, at 14:11, Bertrand Marquis wrote:
>
> Add support for indirect messages between VMs.
> This is only enabled if CONFIG_FFA_VM_TO_VM is selected.
>
> Signed-off-by: Bertrand Marquis
> Reviewed-by: Jens Wiklander
Hi,
A gentle ping for someone to review this :-)
Thanks
Bertrand
> On 17 Jul 2025, at 14:11, Bertrand Marquis wrote:
>
> When VM to VM support is activated and there is no suitable FF-A support
> in the firmware, enable FF-A support for VMs to allow using it for VM to
> VM communications.
> If
Hi,
A gentle ping for someone to review this :-)
Thanks
Bertrand
> On 17 Jul 2025, at 14:11, Bertrand Marquis wrote:
>
> Create a CONFIG_FFA_VM_TO_VM parameter to activate FFA communication
> between VMs.
> When activated list VMs in the system with FF-A support in part_info_get.
>
> When VM
31 matches
Mail list logo
