On 29.04.2025 03:27, Stefano Stabellini wrote:
> On Mon, 28 Apr 2025, Jan Beulich wrote:
>> On 26.04.2025 01:42, victorm.l...@amd.com wrote:
>>> From: Nicola Vetrini
>>>
>>> Rule 19.1 states: "An object shall not be assigned or copied
>>> to an overlapping object". Since the "call" and "compat_cal
On 28.04.2025 22:00, Stefano Stabellini wrote:
> On Mon, 28 Apr 2025, Jan Beulich wrote:
>> On 25.04.2025 22:19, Stefano Stabellini wrote:
>>> From: Xenia Ragiadakou
>>>
>>> Dom0 PVH might need XENMEM_exchange when passing contiguous memory
>>> addresses to firmware or co-processors not behind an
From: Chen Linxuan
Presume that kernel is compiled for x86_64 with gcc version 13.3.0:
make allmodconfig
make KCFLAGS="-fno-inline-small-functions -fno-inline-functions-called-once"
This results some objtool warnings:
vmlinux.o: warning: objtool: rseq_update_cpu_node_id+0x14c: call to
r
From: Chen Linxuan
Presume that kernel is compiled for x86_64 with gcc version 13.3.0:
make allmodconfig
make KCFLAGS="-fno-inline-small-functions -fno-inline-functions-called-once"
This results a objtool warning:
vmlinux.o: warning: objtool: __sanitizer_cov_trace_pc+0xc: call to
canoni
From: Winston Wen
Presume that kernel is compiled for x86_64 with gcc version 13.3.0:
make defconfig
./scripts/kconfig/merge_config.sh .config <(
echo CONFIG_TCG_TPM=y
echo CONFIG_HW_RANDOM=m
)
make KCFLAGS="-fno-inline-small-functions -fno-inline-functions-called-once"
This res
From: Winston Wen
On x86_64 with gcc version 13.3.0, I build drivers/nvme/host/pci.c
with:
make defconfig
./scripts/kconfig/merge_config.sh .config <(
echo CONFIG_BLK_DEV_NVME=m
)
make KCFLAGS="-fno-inline-small-functions -fno-inline-functions-called-once" \
drivers/nvme/host/pci
From: Chen Linxuan
Add a new kernel hacking option CONFIG_NO_AUTO_INLINE that prevents the
compiler from auto-inlining functions not explicitly marked with the
'inline' keyword.
This enhancement improves function tracer capabilities as it can only
trace functions that haven't been inlined by the
From: Winston Wen
Presume that kernel is compiled for x86_64 with gcc version 13.3.0:
make defconfig
./scripts/kconfig/merge_config.sh .config <(
echo CONFIG_VFIO=m
echo CONFIG_VIRTIO_PCI=y
echo CONFIG_VIRTIO_PCI_LIB_LEGACY=y
echo CONFIG_VIRTIO_VFIO_PCI=m
echo CONFIG_VIRT
This series introduces a new kernel configuration option NO_AUTO_INLINE,
which can be used to disable the automatic inlining of functions.
This will allow the function tracer to trace more functions
because it only traces functions that the compiler has not inlined.
Previous discussions can be fo
From: Chen Linxuan
Presume that kernel is compiled for x86_64 with gcc version 13.3.0:
make allmodconfig
make KCFLAGS="-fno-inline-small-functions -fno-inline-functions-called-once"
This results a modpost warning:
WARNING: modpost: vmlinux: section mismatch in reference: xen_pgd_walk+0x4
From: Winston Wen
On x86_64 with gcc version 13.3.0, I compile mm/page_alloc.c with:
make defconfig
make KCFLAGS="-fno-inline-small-functions -fno-inline-functions-called-once" \
mm/page_alloc.o
Then I get a compile error:
CALLscripts/checksyscalls.sh
DESCEND objtool
IN
On 28.04.2025 22:02, Stefano Stabellini wrote:
> On Mon, 28 Apr 2025, Teddy Astie wrote:
>> Hello Stefano,
>>
>> Le 25/04/2025 à 22:21, Stefano Stabellini a écrit :
>>> From: Xenia Ragiadakou
>>>
>>> Dom0 PVH might need XENMEM_exchange when passing contiguous memory
>>> addresses to firmware or co
On 29.04.2025 01:21, Stefano Stabellini wrote:
> On Mon, 28 Apr 2025, Jan Beulich wrote:
>> On 26.04.2025 02:00, victorm.l...@amd.com wrote:
>>> From: Federico Serafini
>>>
>>> MISRA C Rule 14.3 states that "Controlling expressions shall not be
>>> invariant".
>>>
>>> Add a SAF comment to deviate
On April 28, 2025 7:25:17 PM PDT, Andrew Cooper
wrote:
>On 29/04/2025 3:00 am, H. Peter Anvin wrote:
>> On April 28, 2025 5:12:13 PM PDT, Andrew Cooper
>> wrote:
>>> On 28/04/2025 10:38 pm, H. Peter Anvin wrote:
On April 28, 2025 9:14:45 AM PDT, Linus Torvalds
wrote:
> On Mon, 2
On Mon, 28 Apr 2025 at 19:00, H. Peter Anvin wrote:
>
> Now, question: can we just use __builtin_*() for these? I think gcc should
> always generate inline code for these on x86.
Yeah, I think we can just use __builtin_ffs() directly and get rid of
all the games.
Not all gcc builtins are great:
On 29/04/2025 3:00 am, H. Peter Anvin wrote:
> On April 28, 2025 5:12:13 PM PDT, Andrew Cooper
> wrote:
>> On 28/04/2025 10:38 pm, H. Peter Anvin wrote:
>>> On April 28, 2025 9:14:45 AM PDT, Linus Torvalds
>>> wrote:
On Mon, 28 Apr 2025 at 00:05, Ingo Molnar wrote:
> And once we remov
On April 28, 2025 5:12:13 PM PDT, Andrew Cooper
wrote:
>On 28/04/2025 10:38 pm, H. Peter Anvin wrote:
>> On April 28, 2025 9:14:45 AM PDT, Linus Torvalds
>> wrote:
>>> On Mon, 28 Apr 2025 at 00:05, Ingo Molnar wrote:
And once we remove 486, I think we can do the optimization below to
On Mon, 28 Apr 2025, Jan Beulich wrote:
> On 26.04.2025 01:42, victorm.l...@amd.com wrote:
> > From: Nicola Vetrini
> >
> > Rule 19.1 states: "An object shall not be assigned or copied
> > to an overlapping object". Since the "call" and "compat_call" are
>
> Was this taken from patch 2 without e
On 28/04/2025 10:38 pm, H. Peter Anvin wrote:
> On April 28, 2025 9:14:45 AM PDT, Linus Torvalds
> wrote:
>> On Mon, 28 Apr 2025 at 00:05, Ingo Molnar wrote:
>>> And once we remove 486, I think we can do the optimization below to
>>> just assume the output doesn't get clobbered by BS*L in the ze
On Sat, 26 Apr 2025, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Introduce conring_flush() to ensure all messages kept in the internal
> console ring are sent to all physical consoles (serial, VGA (x86))
> after their initialization is completed.
>
> Resolves: https://gitlab.com/xen-project/
On Sat, 26 Apr 2025, dm...@proton.me wrote:
> From: Denis Mukhin
>
> guest_console_write() duplicates the code from __putstr(), eliminate code
> duplication.
>
> Introduce console_puts() for writing a buffer to console devices.
>
> Also, introduce internal console flags to control which console
On Mon, 28 Apr 2025, Jan Beulich wrote:
> On 26.04.2025 02:00, victorm.l...@amd.com wrote:
> > From: Federico Serafini
> >
> > MISRA C Rule 14.3 states that "Controlling expressions shall not be
> > invariant".
> >
> > Add a SAF comment to deviate the rule for build configurations without
> > CO
On Mon, 28 Apr 2025, Jan Beulich wrote:
> On 26.04.2025 01:42, victorm.l...@amd.com wrote:
> > From: Nicola Vetrini
> >
> > Rule 19.1 states: "An object shall not be assigned or copied
> > to an overlapping object". Since the "call" and "compat_call" are
> > fields of the same union, reading from
On Fri, 25 Apr 2025, victorm.l...@amd.com wrote:
> From: Federico Serafini
>
> Tag MISRA C Rule 19.1 as clean to avoid regressions.
>
> Signed-off-by: Federico Serafini
> Signed-off-by: Victor Lira
Assuming the other patches get committed and the rule is clean
Acked-by: Stefano Stabellini
On Fri, 25 Apr 2025, victorm.l...@amd.com wrote:
> From: Federico Serafini
>
> MISRA C Rule 14.3 is already tagged as clean: add it to the
> monitored set to avoid regressions.
>
> Signed-off-by: Federico Serafini
> Signed-off-by: Victor Lira
Assuming the previous patch gets accepted:
Acked-
On Tue, 29 Apr 2025, Andrei Cherechesu wrote:
> Everything looks good to me, briefly tested it locally as well.
Thank you! Committed.
On April 28, 2025 9:14:45 AM PDT, Linus Torvalds
wrote:
>On Mon, 28 Apr 2025 at 00:05, Ingo Molnar wrote:
>>
>> And once we remove 486, I think we can do the optimization below to
>> just assume the output doesn't get clobbered by BS*L in the zero-case,
>> right?
>
>We probably can't, because wh
On 2025-04-28 07:29, Jan Beulich wrote:
16-bit quantities, no matter whether expressed as uint16_t or as
bitfield, will be promoted to plain int before doing any arithmetic on
them. Shifting such values by 16 will therefore shift into the sign bit,
which is UB if that bit becomes set. To account
Hi Stefano,
On 28/04/2025 23:55, Andrei Cherechesu wrote:
> From: Andrei Cherechesu
>
> Normally, the Imagebuilder would precompute the sizes of the loaded
> binaries and addresses where they are loaded before generating the
> script, and the sizes and addresses that needed to be provided to
> Xe
On 2025-04-28 15:57, Ariadne Conill wrote:
Previously Xen placed the hypercall page at the highest possible MFN,
but this caused problems on systems where there is more than 36 bits
of physical address space.
In general, it also seems unreliable to assume that the highest possible
MFN is not alr
From: Andrei Cherechesu
Normally, the Imagebuilder would precompute the sizes of the loaded
binaries and addresses where they are loaded before generating the
script, and the sizes and addresses that needed to be provided to
Xen via /chosen would be hardcoded in the boot script.
Added an option
On Mon, 28 Apr 2025, Andrei Cherechesu wrote:
> Hi Stefano,
>
> On 26/04/2025 02:35, Stefano Stabellini wrote:
> > From: Andrei Cherechesu
> >
> > Normally, the Imagebuilder would precompute the sizes of the loaded
> > binaries and addresses where they are loaded before generating the script,
>
On Sat, 26 Apr 2025, dm...@proton.me wrote:
> On Fri, Apr 25, 2025 at 04:35:06PM -0700, Stefano Stabellini wrote:
> > From: Andrei Cherechesu
> >
> > Normally, the Imagebuilder would precompute the sizes of the loaded
> > binaries and addresses where they are loaded before generating the
> > scri
On Mon, Apr 28, 2025 at 08:47:01AM +0200, Jan Beulich wrote:
> On 26.04.2025 00:18, Stefano Stabellini wrote:
> > On Thu, 3 Apr 2025, dm...@proton.me wrote:
> >> From: Denis Mukhin
> >>
> >> Move console_locks_busted handling inside conring_puts() to remove
> >> tasklet code duplication.
> >>
> >>
On Mon, Apr 28, 2025 at 08:50:52AM +0200, Jan Beulich wrote:
> On 26.04.2025 20:50, dm...@proton.me wrote:
> > From: Denis Mukhin
> >
> > Move console_locks_busted handling inside conring_puts() to remove
> > tasklet code duplication.
> >
> > Signed-off-by: Denis Mukhin
> > Reviewed-by: Stefano S
On Mon, 28 Apr 2025, Teddy Astie wrote:
> Hello Stefano,
>
> Le 25/04/2025 à 22:21, Stefano Stabellini a écrit :
> > From: Xenia Ragiadakou
> >
> > Dom0 PVH might need XENMEM_exchange when passing contiguous memory
> > addresses to firmware or co-processors not behind an IOMMU.
> >
> > XENMEM_exc
On Mon, Apr 28, 2025 at 11:14:25AM +0200, Jan Beulich wrote:
> On 22.04.2025 23:54, dm...@proton.me wrote:
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -66,6 +66,57 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
> > static struct domain *domain_hash[DOMAIN_HASH_SIZE];
> > struc
On Mon, 28 Apr 2025, Jan Beulich wrote:
> On 25.04.2025 22:19, Stefano Stabellini wrote:
> > From: Xenia Ragiadakou
> >
> > Dom0 PVH might need XENMEM_exchange when passing contiguous memory
> > addresses to firmware or co-processors not behind an IOMMU.
>
> I definitely don't understand the fir
Previously Xen placed the hypercall page at the highest possible MFN,
but this caused problems on systems where there is more than 36 bits
of physical address space.
In general, it also seems unreliable to assume that the highest possible
MFN is not already reserved for some other purpose.
Fixes:
On Mon, Apr 28, 2025 at 01:58:56PM +0200, Jan Beulich wrote:
> On 26.04.2025 09:28, dm...@proton.me wrote:
> > @@ -1957,8 +1955,7 @@ void cf_check vmx_do_resume(void)
> > hvm_do_resume(v);
> >
> > /* Sync host CR4 in case its value has changed. */
> > -__vmread(HOST_CR4, &host_cr4);
>
On Mon, Apr 28, 2025 at 12:39:36PM +0100, Andrew Cooper wrote:
> On 26/04/2025 8:27 am, dm...@proton.me wrote:
> > From: Denis Mukhin
> >
> > The current implementation of __vmread() returns the result via pointer
> > argument which leads to excess code in some places.
> >
> > Introduce a new vmre
On Mon, Apr 28, 2025 at 12:48:42PM +0100, Andrew Cooper wrote:
> On 26/04/2025 8:27 am, dm...@proton.me wrote:
> > From: Denis Mukhin
> >
> > Convert the DR7 type to `unsigned int` and fix the accesses where necessary.
> >
> > [1]
> > https://lore.kernel.org/xen-devel/0d01646b-83e3-4a02-b365-d149
> On 25 Apr 2025, at 14:32, Julien Grall wrote:
>
> Hi Ayan
>
> On 25/04/2025 13:00, Ayan Kumar Halder wrote:
+unsigned int ns:1; /* Reserved 0 by hardware */
+unsigned int res0:1; /* Reserved 0 by hardware */
>> Then, we can change this on Arm32 as well.
+
Hi Ayan,
> On 25 Apr 2025, at 13:00, Ayan Kumar Halder wrote:
>
> Hi Julien,
>
> cc-ed Luca for feedback on specific points.
>
> On 18/04/2025 05:54, Julien Grall wrote:
>> Hi Ayan,
>>
>> On 18/04/2025 00:55, Ayan Kumar Halder wrote:
>>> Add the definitions for HPRBAR<0..31>, HPRLAR<0..31> an
Hi Mykyta,
On 28/04/2025 15:28, Mykyta Poturai wrote:
On 28.04.25 15:55, Julien Grall wrote:
Hi,
On 28/04/2025 13:31, Mykyta Poturai wrote:
On 28.04.25 11:54, Julien Grall wrote:
Hi Mykyta,
On 14/03/2025 13:34, Mykyta Poturai wrote:
From: Stewart Hildebrand
Enable the use of IOMMU + PCI
Hi Stefano,
On 26/04/2025 02:35, Stefano Stabellini wrote:
> From: Andrei Cherechesu
>
> Normally, the Imagebuilder would precompute the sizes of the loaded binaries
> and addresses where they are loaded before generating the script, and the
> sizes and addresses that needed to be provided to X
On Mon, 28 Apr 2025 at 00:14, Ingo Molnar wrote:
>
> And, just out of intellectual curiosity, I also tried to measure the
> code generation price of the +1 standards-quirk in the fls()/ffs()
> interface as well:
>
> ... and unless I messed up the patch, it seems to have a surprisingly
> low impact
On Mon, 28 Apr 2025 at 00:05, Ingo Molnar wrote:
>
> And once we remove 486, I think we can do the optimization below to
> just assume the output doesn't get clobbered by BS*L in the zero-case,
> right?
We probably can't, because who knows what "Pentium" CPU's are out there.
Or even if Pentium r
On 14.04.2025 09:40, Penny Zheng wrote:
> In order to provide backward compatibility with existing governors
> that represent performance as frequency, like ondemand, the _CPC
> table can optionally provide processor frequency range values, Lowest
> frequency and Norminal frequency, to let OS use L
On 2025-04-28 11:04, Jan Beulich wrote:
On 28.04.2025 10:09, Nicola Vetrini wrote:
On 2025-04-28 08:15, Jan Beulich wrote:
On 25.04.2025 17:53, Nicola Vetrini wrote:
On 2025-04-25 10:07, Jan Beulich wrote:
On 24.04.2025 23:45, Stefano Stabellini wrote:
On Thu, 24 Apr 2025, Jan Beulich wrote:
Hi everyone,
*IMPORTANT: Due to public holidays in several countries, May's community
call has been moved to Wednesday, 7 May 2025.*
We’re getting ready for May's Xen Project Community Call on *Wednesday, 7
May 2025* at *15:00 UTC* (4 pm UK time). We’d love for you to join. Feel
free to just obse
On 28.04.25 17:31, Alejandro Vallejo wrote:
On Mon Apr 28, 2025 at 4:15 PM BST, Jürgen Groß wrote:
On 28.04.25 17:12, Alejandro Vallejo wrote:
On Thu Apr 24, 2025 at 10:41 AM BST, Anthony PERARD wrote:
On Tue, Apr 08, 2025 at 02:35:20PM +0200, Juergen Gross wrote:
@@ -1903,10 +1894,7 @@ it ma
On Mon Apr 28, 2025 at 4:15 PM BST, Jürgen Groß wrote:
> On 28.04.25 17:12, Alejandro Vallejo wrote:
>> On Thu Apr 24, 2025 at 10:41 AM BST, Anthony PERARD wrote:
>>> On Tue, Apr 08, 2025 at 02:35:20PM +0200, Juergen Gross wrote:
@@ -1903,10 +1894,7 @@ it may be useful to request a different o
On 14.04.2025 09:40, Penny Zheng wrote:
> --- a/xen/drivers/cpufreq/cpufreq.c
> +++ b/xen/drivers/cpufreq/cpufreq.c
> @@ -191,9 +191,31 @@ int cpufreq_limit_change(unsigned int cpu)
> return __cpufreq_set_policy(data, &policy);
> }
>
> -int cpufreq_add_cpu(unsigned int cpu)
> +static int ge
On 28.04.25 17:12, Alejandro Vallejo wrote:
On Thu Apr 24, 2025 at 10:41 AM BST, Anthony PERARD wrote:
On Tue, Apr 08, 2025 at 02:35:20PM +0200, Juergen Gross wrote:
@@ -1903,10 +1894,7 @@ it may be useful to request a different one, like UEFI.
=item B
-Loads ROMBIOS, a 16-bit x86 compa
On Thu Apr 24, 2025 at 10:41 AM BST, Anthony PERARD wrote:
> On Tue, Apr 08, 2025 at 02:35:20PM +0200, Juergen Gross wrote:
>> @@ -1903,10 +1894,7 @@ it may be useful to request a different one, like
>> UEFI.
>>
>> =item B
>>
>> -Loads ROMBIOS, a 16-bit x86 compatible BIOS. This is used by de
On 28.04.25 15:55, Julien Grall wrote:
> Hi,
>
> On 28/04/2025 13:31, Mykyta Poturai wrote:
>> On 28.04.25 11:54, Julien Grall wrote:
>>> Hi Mykyta,
>>>
>>> On 14/03/2025 13:34, Mykyta Poturai wrote:
From: Stewart Hildebrand
Enable the use of IOMMU + PCI in dom0 without having to s
On 2025-04-28 02:41, Jan Beulich wrote:
On 26.04.2025 03:53, Daniel P. Smith wrote:
On 4/23/25 15:27, Jason Andryuk wrote:
On 2025-04-19 18:08, Daniel P. Smith wrote:
The bzimage logic uses the unit global orig_image_len to hold the
original
module length for the kernel when the headroom is
On April 28, 2025 12:14:40 AM PDT, Ingo Molnar wrote:
>
>* Ingo Molnar wrote:
>
>> And once we remove 486, I think we can do the optimization below to
>> just assume the output doesn't get clobbered by BS*L in the
>> zero-case, right?
>>
>> In the text size space it's a substantial optimizatio
On 24.04.25 16:43, Anthony PERARD wrote:
On Tue, Apr 08, 2025 at 02:35:22PM +0200, Juergen Gross wrote:
diff --git a/INSTALL b/INSTALL
index 88c1464816..786e3da996 100644
--- a/INSTALL
+++ b/INSTALL
There's one "--enable-ioemu-stubdom" left in this file.
Oh, thanks for noticing.
diff --g
On 24.04.25 15:41, Anthony PERARD wrote:
On Tue, Apr 08, 2025 at 02:35:21PM +0200, Juergen Gross wrote:
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index c3c61ca060..a00acdd45b 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -1
Hi,
On 28/04/2025 13:31, Mykyta Poturai wrote:
On 28.04.25 11:54, Julien Grall wrote:
Hi Mykyta,
On 14/03/2025 13:34, Mykyta Poturai wrote:
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 c
On 24.04.25 11:41, Anthony PERARD wrote:
On Tue, Apr 08, 2025 at 02:35:20PM +0200, Juergen Gross wrote:
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index 7339c44efd..ccf0c58895 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -895,12 +895,6 @@ is used.
On 28.04.25 11:54, Julien Grall wrote:
> Hi Mykyta,
>
> On 14/03/2025 13:34, Mykyta Poturai wrote:
>> 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 PHYSDEVO
On Mon, Apr 28, 2025, at 09:14, Ingo Molnar wrote:
>
> ... and unless I messed up the patch, it seems to have a surprisingly
> low impact - maybe because the compiler can amortize its cost by
> adjusting all dependent code mostly at build time, so the +1 doesn't
> end up being generated most of
On 26.04.2025 09:28, dm...@proton.me wrote:
> @@ -1957,8 +1955,7 @@ void cf_check vmx_do_resume(void)
> hvm_do_resume(v);
>
> /* Sync host CR4 in case its value has changed. */
> -__vmread(HOST_CR4, &host_cr4);
> -if ( host_cr4 != read_cr4() )
> +if ( vmread(HOST_CR4) != rea
On Mon Apr 28, 2025 at 12:07 PM BST, Andrew Cooper wrote:
> On 28/04/2025 11:55 am, Alejandro Vallejo wrote:
>> On Mon Apr 28, 2025 at 10:41 AM BST, Roger Pau Monné wrote:
>>> On Fri, Apr 25, 2025 at 04:43:31PM -0700, Ariadne Conill wrote:
Previously Xen placed the hypercall page at the highes
On 26/04/2025 8:27 am, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Convert the DR7 type to `unsigned int` and fix the accesses where necessary.
>
> [1]
> https://lore.kernel.org/xen-devel/0d01646b-83e3-4a02-b365-d149d2664...@citrix.com/
>
> Signed-off-by: Denis Mukhin
> ---
> xen/arch/x86/h
On 26/04/2025 8:27 am, dm...@proton.me wrote:
> From: Denis Mukhin
>
> The current implementation of __vmread() returns the result via pointer
> argument which leads to excess code in some places.
>
> Introduce a new vmread() function as suggested in [1].
>
> [1]
> https://lore.kernel.org/xen-dev
On 28.04.2025 13:26, Mykyta Poturai wrote:
> On 28.04.25 12:01, Jan Beulich wrote:
>> On 28.04.2025 10:21, Mykyta Poturai wrote:
>>> On 17.03.25 17:07, Jan Beulich wrote:
On 14.03.2025 14:34, Mykyta Poturai wrote:
> --- a/xen/arch/arm/pci/pci.c
> +++ b/xen/arch/arm/pci/pci.c
> @@ -
16-bit quantities, no matter whether expressed as uint16_t or as
bitfield, will be promoted to plain int before doing any arithmetic on
them. Shifting such values by 16 will therefore shift into the sign bit,
which is UB if that bit becomes set. To account for all reads and all
writes accessing opp
On 28.04.25 12:01, Jan Beulich wrote:
> On 28.04.2025 10:21, Mykyta Poturai wrote:
>> On 17.03.25 17:07, Jan Beulich wrote:
>>> On 14.03.2025 14:34, Mykyta Poturai wrote:
--- a/xen/arch/arm/pci/pci.c
+++ b/xen/arch/arm/pci/pci.c
@@ -16,9 +16,18 @@
#include
#include
On 28.04.2025 12:43, Oleksii Kurochko wrote:
>
> On 4/28/25 8:31 AM, Jan Beulich wrote:
>> On 25.04.2025 19:07, Oleksii Kurochko wrote:
>>> On 4/15/25 3:45 PM, Jan Beulich wrote:
On 15.04.2025 15:39, Oleksii Kurochko wrote:
> On 4/10/25 5:53 PM, Jan Beulich wrote:
>> On 08.04.2025 17:
On 26/04/2025 12:43 am, Ariadne Conill wrote:
> diff --git a/xen/arch/x86/guest/hyperv/hyperv.c
> b/xen/arch/x86/guest/hyperv/hyperv.c
> index 6989af38f1..0305374a06 100644
> --- a/xen/arch/x86/guest/hyperv/hyperv.c
> +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> @@ -98,7 +98,13 @@ static void __init
On 28/04/2025 11:55 am, Alejandro Vallejo wrote:
> On Mon Apr 28, 2025 at 10:41 AM BST, Roger Pau Monné wrote:
>> On Fri, Apr 25, 2025 at 04:43:31PM -0700, Ariadne Conill wrote:
>>> Previously Xen placed the hypercall page at the highest possible MFN,
>>> but this caused problems on systems where t
On Fri Apr 25, 2025 at 11:32 PM BST, Daniel P. Smith wrote:
> On 4/24/25 12:10, Alejandro Vallejo wrote:
>> From: "Daniel P. Smith"
>>
>> Look for a subnode of type `multiboot,kernel` within a domain node. If
>> found, locate it using the multiboot module helper to generically ensure
>> it lives
On 28.04.2025 12:33, Alejandro Vallejo wrote:
> On Fri Apr 25, 2025 at 11:04 PM BST, Daniel P. Smith wrote:
>> On 4/25/25 11:22, Alejandro Vallejo wrote:
>>> On Sat Apr 19, 2025 at 11:07 PM BST, Daniel P. Smith wrote:
Convert alloc_dom0_vcpu0() to dom0_set_affinity(), making it only set up
>>
On Mon Apr 28, 2025 at 10:41 AM BST, Roger Pau Monné wrote:
> On Fri, Apr 25, 2025 at 04:43:31PM -0700, Ariadne Conill wrote:
>> Previously Xen placed the hypercall page at the highest possible MFN,
>> but this caused problems on systems where there is more than 36 bits
>> of physical address space
On 4/28/25 8:31 AM, Jan Beulich wrote:
On 25.04.2025 19:07, Oleksii Kurochko wrote:
On 4/15/25 3:45 PM, Jan Beulich wrote:
On 15.04.2025 15:39, Oleksii Kurochko wrote:
On 4/10/25 5:53 PM, Jan Beulich wrote:
On 08.04.2025 17:57, Oleksii Kurochko wrote:
+{
+const __be32 *cell;
+int ac
On Sat Apr 26, 2025 at 12:43 AM BST, Ariadne Conill wrote:
> Previously Xen placed the hypercall page at the highest possible MFN,
> but this caused problems on systems where there is more than 36 bits
> of physical address space.
>
> In general, it also seems unreliable to assume that the highest
On Fri Apr 25, 2025 at 11:04 PM BST, Daniel P. Smith wrote:
> On 4/25/25 11:22, Alejandro Vallejo wrote:
>> On Sat Apr 19, 2025 at 11:07 PM BST, Daniel P. Smith wrote:
>>> Convert alloc_dom0_vcpu0() to dom0_set_affinity(), making it only set up the
>>> node affinity based on command line parameters
On Fri, Apr 25, 2025 at 04:43:31PM -0700, Ariadne Conill wrote:
> Previously Xen placed the hypercall page at the highest possible MFN,
> but this caused problems on systems where there is more than 36 bits
> of physical address space.
>
> In general, it also seems unreliable to assume that the hi
On 26.04.2025 09:27, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Convert the DR7 type to `unsigned int` and fix the accesses where necessary.
>
> [1]
> https://lore.kernel.org/xen-devel/0d01646b-83e3-4a02-b365-d149d2664...@citrix.com/
>
> Signed-off-by: Denis Mukhin
Reviewed-by: Jan Beul
On 26.04.2025 09:27, dm...@proton.me wrote:
> From: Denis Mukhin
>
> The current implementation of __vmread() returns the result via pointer
> argument which leads to excess code in some places.
>
> Introduce a new vmread() function as suggested in [1].
>
> [1]
> https://lore.kernel.org/xen-de
On 22.04.2025 23:54, dm...@proton.me wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -66,6 +66,57 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
> static struct domain *domain_hash[DOMAIN_HASH_SIZE];
> struct domain *domain_list;
>
> +/* Domain ID allocator */
> +static unsigne
On 23.04.2025 13:22, Julien Grall wrote:
> On 22/04/2025 22:54, dm...@proton.me wrote:
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -66,6 +66,57 @@ DEFINE_RCU_READ_LOCK(domlist_read_lock);
>> static struct domain *domain_hash[DOMAIN_HASH_SIZE];
>> struct domain *domain_list;
On 28.04.2025 10:09, Nicola Vetrini wrote:
> On 2025-04-28 08:15, Jan Beulich wrote:
>> On 25.04.2025 17:53, Nicola Vetrini wrote:
>>> On 2025-04-25 10:07, Jan Beulich wrote:
On 24.04.2025 23:45, Stefano Stabellini wrote:
> On Thu, 24 Apr 2025, Jan Beulich wrote:
>> On 23.04.2025 19:54
On 28.04.2025 10:21, Mykyta Poturai wrote:
> On 17.03.25 17:07, Jan Beulich wrote:
>> On 14.03.2025 14:34, Mykyta Poturai wrote:
>>> --- a/xen/arch/arm/pci/pci.c
>>> +++ b/xen/arch/arm/pci/pci.c
>>> @@ -16,9 +16,18 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>
On 28.04.2025 10:12, Oleksii Kurochko wrote:
> On 4/17/25 8:25 AM, Jan Beulich wrote:
>> On 16.04.2025 21:05, Oleksii Kurochko wrote:
>>> On 4/15/25 2:46 PM, Jan Beulich wrote:
On 08.04.2025 17:57, Oleksii Kurochko wrote:
> Introduce interrupt controller descriptor for host APLIC to descri
Hi Mykyta,
On 14/03/2025 13:34, Mykyta Poturai wrote:
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.
It wo
On 17.03.25 17:07, Jan Beulich wrote:
> On 14.03.2025 14:34, Mykyta Poturai wrote:
>> --- a/xen/arch/arm/pci/pci.c
>> +++ b/xen/arch/arm/pci/pci.c
>> @@ -16,9 +16,18 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>>
>> +bool is_pci_passthrough_enabled
On 4/17/25 8:25 AM, Jan Beulich wrote:
On 16.04.2025 21:05, Oleksii Kurochko wrote:
On 4/15/25 2:46 PM, Jan Beulich wrote:
On 08.04.2025 17:57, Oleksii Kurochko wrote:
Introduce interrupt controller descriptor for host APLIC to describe
the low-lovel hardare. It includes implementation of the
Hello Stefano,
Le 25/04/2025 à 22:21, Stefano Stabellini a écrit :
> From: Xenia Ragiadakou
>
> Dom0 PVH might need XENMEM_exchange when passing contiguous memory
> addresses to firmware or co-processors not behind an IOMMU.
>
> XENMEM_exchange was blocked for HVM/PVH DomUs, and accidentally it
>
On 2025-04-28 08:15, Jan Beulich wrote:
On 25.04.2025 17:53, Nicola Vetrini wrote:
On 2025-04-25 10:07, Jan Beulich wrote:
On 24.04.2025 23:45, Stefano Stabellini wrote:
On Thu, 24 Apr 2025, Jan Beulich wrote:
On 23.04.2025 19:54, victorm.l...@amd.com wrote:
From: Nicola Vetrini
MISRA C Ru
On Fri, Apr 25, 2025 at 04:57:18PM +0200, Jan Beulich wrote:
> Without doing so we could trigger the ASSERT_UNREACHABLE() in
> subpage_mmio_write_emulate(). A comment there actually says this
> validation would already have been done ...
>
> Fixes: 8847d6e23f97 ("x86/mm: add API for marking only p
On 26.04.2025 02:00, victorm.l...@amd.com wrote:
> From: Federico Serafini
>
> MISRA C Rule 14.3 states that "Controlling expressions shall not be
> invariant".
>
> Add a SAF comment to deviate the rule for build configurations without
> CONFIG_LLC_COLORING enabled.
I was surprised by this supp
On 26.04.2025 01:42, victorm.l...@amd.com wrote:
> From: Nicola Vetrini
>
> Rule 19.1 states: "An object shall not be assigned or copied
> to an overlapping object". Since the "call" and "compat_call" are
> fields of the same union, reading from one member and writing to
> the other violates the
On 26.04.2025 01:42, victorm.l...@amd.com wrote:
> From: Nicola Vetrini
>
> Rule 19.1 states: "An object shall not be assigned or copied
> to an overlapping object". Since the "call" and "compat_call" are
Was this taken from patch 2 without editing?
> --- a/xen/arch/x86/x86_emulate/x86_emulate.
* Ingo Molnar wrote:
> And once we remove 486, I think we can do the optimization below to
> just assume the output doesn't get clobbered by BS*L in the
> zero-case, right?
>
> In the text size space it's a substantial optimization on x86-32
> defconfig:
>
> text databs
On 25.04.2025 22:19, Stefano Stabellini wrote:
> From: Xenia Ragiadakou
>
> Dom0 PVH might need XENMEM_exchange when passing contiguous memory
> addresses to firmware or co-processors not behind an IOMMU.
I definitely don't understand the firmware part: It's subject to the
same transparent P2M t
1 - 100 of 102 matches
Mail list logo
