Hi all,
> diff --git a/xen/arch/arm/include/asm/mpu/regions.inc
> b/xen/arch/arm/include/asm/mpu/regions.inc
> index 47868a152662..dc0306f8c5fc 100644
> --- a/xen/arch/arm/include/asm/mpu/regions.inc
> +++ b/xen/arch/arm/include/asm/mpu/regions.inc
> @@ -1,22 +1,50 @@
> /* SPDX-License-Identifier
On 29/04/2025 17:20, Luca Fancellu wrote:
> From: Penny Zheng
>
> Introduce pr_t typedef which is a structure having the prbar
> and prlar members, each being structured as the registers of
> the aarch64 armv8-r architecture.
>
> Signed-off-by: Penny Zheng
> Signed-off-by: Wei Chen
> Signed
On 30.04.2025 04:17, Volodymyr Babchuk wrote:
> Julien Grall writes:
>>> --- /dev/null
>>> +++ b/xen/arch/arm/include/asm/libafl_qemu_defs.h
>>> @@ -0,0 +1,37 @@
>>
>> Missing license. Also, is this file taken from somewhere?
>>
>
> I add MIT license, as libafl is dual licensed under Apache-2 and
On 29/04/2025 17:20, Luca Fancellu wrote:
> Document the requirement needed to boot Xen on Armv8-R platforms.
>
> Signed-off-by: Luca Fancellu
> ---
> v4 changes:
> - New patch
> ---
> docs/misc/arm/booting.txt | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/docs/misc/arm/b
On 29.04.2025 23:52, Stefano Stabellini wrote:
> On Tue, 29 Apr 2025, Jan Beulich wrote:
>> 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:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
On 30.04.2025 00:02, Stefano Stabellini wrote:
> On Tue, 29 Apr 2025, Jan Beulich wrote:
>> On 29.04.2025 01:21, 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
On 30.04.2025 00:54, Stefano Stabellini wrote:
> On Tue, 29 Apr 2025, Jan Beulich wrote:
>> 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
From: Ilpo Järvinen Sent: Tuesday, April 29,
2025 2:46 AM
>
> On Sun, 27 Apr 2025, Xin Li (Intel) wrote:
>
> > For some reason, there are some TSC-related functions in the MSR
> > header even though there is a tsc.h header.
> >
> > To facilitate the relocation of rdtsc{,_ordered}() from
> > to
Hi Julien,
Julien Grall writes:
[...]
>> diff --git a/xen/arch/arm/include/asm/libafl_qemu.h
>> b/xen/arch/arm/include/asm/libafl_qemu.h
>> new file mode 100644
>> index 00..b90cf48b9a
>> --- /dev/null
>> +++ b/xen/arch/arm/include/asm/libafl_qemu.h
>> @@ -0,0 +1,54 @@
>> +#ifndef LI
Hi Marek,
On Wed, Apr 23, 2025 at 8:42 AM Marek Marczykowski-Górecki
wrote:
>
> On Sat, Jun 01, 2024 at 12:48:33AM +0200, Marek Marczykowski-Górecki wrote:
> > On Tue, Mar 26, 2024 at 11:00:50AM +, Julien Grall wrote:
> > > Hi Marek,
> > >
> > > +Juergen for visibility
> > >
> > > When sendin
I noticed that non-PCI device passthrough on Arm is not
security supported. Is this just because the code has not
been sufficiently tested yet, or is it because there is
some fundamental problem with the code or with the hardware
features it uses?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
On Tue, 29 Apr 2025, Mykyta Poturai wrote:
> 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 mappin
On Tue, 29 Apr 2025, Mykyta Poturai wrote:
> 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 chec
On Tue, 29 Apr 2025, Mykyta Poturai wrote:
> 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 th
On Tue, 29 Apr 2025, Jan Beulich wrote:
> 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
On Tue, 29 Apr 2025 at 15:22, Andrew Cooper wrote:
>
> Oh, I didn't realise there was also a perf difference too, but Agner Fog
> agrees.
The perf difference is exactly because of the issue where the non-rep
one acts as a cmov, and has basically two inputs (the bits to test in
the source, and the
On 29/04/2025 11:04 pm, Linus Torvalds wrote:
> On Tue, 29 Apr 2025 at 14:59, Andrew Cooper wrote:
>> do_variable_ffs() doesn't quite work.
>>
>> REP BSF is LZCNT, and unconditionally writes it's output operand, and
>> defeats the attempt to preload with -1.
>>
>> Drop the REP prefix, and it shoul
On Tue, 29 Apr 2025, Jan Beulich wrote:
> 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
>
On April 29, 2025 3:04:30 PM PDT, Linus Torvalds
wrote:
>On Tue, 29 Apr 2025 at 14:59, Andrew Cooper wrote:
>>
>> do_variable_ffs() doesn't quite work.
>>
>> REP BSF is LZCNT, and unconditionally writes it's output operand, and
>> defeats the attempt to preload with -1.
>>
>> Drop the REP prefix
On Tue, 29 Apr 2025 at 14:59, Andrew Cooper wrote:
>
> do_variable_ffs() doesn't quite work.
>
> REP BSF is LZCNT, and unconditionally writes it's output operand, and
> defeats the attempt to preload with -1.
>
> Drop the REP prefix, and it should work as intended.
Bah. That's what I get for just
On Tue, 29 Apr 2025, Jan Beulich wrote:
> On 29.04.2025 01:21, 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
On 29/04/2025 10:53 pm, Linus Torvalds wrote:
> I just did
>
> gcc -m32 -O2 -S -fomit-frame-pointer t.c
>
> (with, and without that -m32) and looked at the result to see that it
> looks sane. No *actual* testing.
do_variable_ffs() doesn't quite work.
REP BSF is LZCNT, and unconditionally writ
On Tue, 29 Apr 2025 at 14:24, H. Peter Anvin wrote:
>
> Could you file a gcc bug? Gcc shouldn't generate worse code than inline asm
> ...
Honestly, I've given up on that idea.
That's basically what the bug report I reported about clts was - gcc
generating worse code than inline asm.
But why wo
On Tue, 29 Apr 2025, Jan Beulich wrote:
> 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
> >>>
On April 29, 2025 1:12:48 PM PDT, Linus Torvalds
wrote:
>On Tue, 29 Apr 2025 at 12:13, Andrew Cooper wrote:
>>
>> That would improve code generation for 32bit, but generally regress 64bit.
>>
>> Preloading the destination register with -1 is better than the CMOV form
>> emitted by the builtin; B
On Tue, 29 Apr 2025 at 12:13, Andrew Cooper wrote:
>
> That would improve code generation for 32bit, but generally regress 64bit.
>
> Preloading the destination register with -1 is better than the CMOV form
> emitted by the builtin; BSF's habit of conditionally not writing the
> destination regist
Hi Ayan,
>> diff --git a/xen/arch/arm/mpu/mm.c b/xen/arch/arm/mpu/mm.c
>> index 40ccf99adc94..2e0aeb486ff8 100644
>> --- a/xen/arch/arm/mpu/mm.c
>> +++ b/xen/arch/arm/mpu/mm.c
>> @@ -9,6 +9,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> struct page_info *frame_t
On 29/04/2025 7:05 pm, Linus Torvalds wrote:
> On Tue, 29 Apr 2025 at 07:38, Andrew Cooper wrote:
>> I tried that. (The thread started as a question around
>> __builtin_constant_p() but did grow to cover __builtin_ffs().)
> Maybe we could do something like
>
>#define ffs(x) \
> (stati
On Tue, 29 Apr 2025 at 07:38, Andrew Cooper wrote:
>
> I tried that. (The thread started as a question around
> __builtin_constant_p() but did grow to cover __builtin_ffs().)
Maybe we could do something like
#define ffs(x) \
(statically_true((x) != 0) ? __ffs(x)+1 : __builtin_ffs(x))
5.15-stable review patch. If anyone has any objections, please let me know.
--
From: Kees Cook
[ Upstream commit 1c3dfc7c6b0f551fdca3f7c1f1e4c73be8adb17d ]
When a character array without a terminating NUL character has a static
initializer, GCC 15's -Wunterminated-string-initi
On 4/29/2025 2:45 AM, Ilpo Järvinen wrote:
On Sun, 27 Apr 2025, Xin Li (Intel) wrote:
For some reason, there are some TSC-related functions in the MSR
header even though there is a tsc.h header.
To facilitate the relocation of rdtsc{,_ordered}() from
to and to eventually eliminate the inclus
Hi Luca,
On 29/04/2025 16:20, Luca Fancellu wrote:
CAUTION: This message has originated from an External Source. Please use proper
judgment and caution when opening attachments, clicking links, or responding to
this email.
Provide a function that creates a pr_t object from a memory
range and
Hi Luca,
On 29/04/2025 16:20, Luca Fancellu wrote:
CAUTION: This message has originated from an External Source. Please use proper
judgment and caution when opening attachments, clicking links, or responding to
this email.
Document the requirement needed to boot Xen on Armv8-R platforms.
Si
5.10-stable review patch. If anyone has any objections, please let me know.
--
From: Kees Cook
[ Upstream commit 1c3dfc7c6b0f551fdca3f7c1f1e4c73be8adb17d ]
When a character array without a terminating NUL character has a static
initializer, GCC 15's -Wunterminated-string-initi
5.4-stable review patch. If anyone has any objections, please let me know.
--
From: Kees Cook
[ Upstream commit 1c3dfc7c6b0f551fdca3f7c1f1e4c73be8adb17d ]
When a character array without a terminating NUL character has a static
initializer, GCC 15's -Wunterminated-string-initia
On 14.04.2025 09:40, Penny Zheng wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -515,7 +515,7 @@ If set, force use of the performance counters for
> oprofile, rather than detectin
> available support.
>
> ### cpufreq
> -> `= none | {{ | xen } {
On 29/04/2025 9:16 am, Jan Beulich wrote:
> Multicall compat translation and hypercall continuation handling can
> also be shrunk to the processing of just (up to) 5 arguments.
>
> Take the opportunity to
> - make exceeding the limit noisy in hypercall_create_continuation(),
> - use speculation-saf
Provide a function that creates a pr_t object from a memory
range and some attributes.
Signed-off-by: Luca Fancellu
---
v4 changes:
- update helper comments
- rename XN_EL2_ENABLED to PRBAR_EL2_XN_ENABLED
- protected pr_of_xenaddr() with #ifdef Arm64 until Arm32
can build with it
---
xen/a
Introduce few utility function to manipulate and handle the
pr_t type.
Signed-off-by: Luca Fancellu
---
v4 changes:
- Modify comment on top of the helpers. Clarify pr_set_limit
takes exclusive address.
Protected common code with #ifdef Arm64 until Arm32 is ready
with pr_t
---
xen/arch/
Hi all,
This is the first chunk of work to support MPU and R82 on Xen, this serie
reaches the early boot stages just before early_fdt_map(), just to give an idea
about which stage of the boot is reached.
v4:
- dropped setup_mpu() patch and early_fdt_map() patch (needs rework)
- add new patches:
From: Penny Zheng
Introduce pr_t typedef which is a structure having the prbar
and prlar members, each being structured as the registers of
the aarch64 armv8-r architecture.
Signed-off-by: Penny Zheng
Signed-off-by: Wei Chen
Signed-off-by: Luca Fancellu
---
Changes in v4:
- Fixed typos, chan
Implement some utility function in order to access the MPU regions
from the C world.
Signed-off-by: Luca Fancellu
---
v4 changes:
- moved back PRBAR0_EL2/PRLAR0_EL2 to mm.c and protect
them with CONFIG_ARM_64, changed comments, fixed typos and code
style
- Add PRBAR_EL2_(n) definition, to
Provide some data structure in the C world to track the MPU
status, these structures will be filled at boot by the assembly
early code with the boot MPU regions and afterwards they will be
used at runtime.
Provide methods to update a bitmap created with DECLARE_BITMAP
from the assembly code for bo
Introduce the MPU memory mapping flags in asm/page.h.
Signed-off-by: Luca Fancellu
---
v4 changes:
- no changes, I'm not sure how I can merge XN and Permission flags.
---
xen/arch/arm/include/asm/page.h | 25 +
1 file changed, 25 insertions(+)
diff --git a/xen/arch/arm/
Document the requirement needed to boot Xen on Armv8-R platforms.
Signed-off-by: Luca Fancellu
---
v4 changes:
- New patch
---
docs/misc/arm/booting.txt | 8
1 file changed, 8 insertions(+)
diff --git a/docs/misc/arm/booting.txt b/docs/misc/arm/booting.txt
index 21ae74837dcc..719af74f
On 29/04/2025 4:13 am, H. Peter Anvin wrote:
> 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:
On April 29, 2025 3:08:03 AM PDT, Ingo Molnar wrote:
>
>* Linus Torvalds wrote:
>
>> 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()
>> > interf
On 14.04.2025 09:40, Penny Zheng wrote:
> --- a/xen/arch/x86/acpi/cpufreq/amd-cppc.c
> +++ b/xen/arch/x86/acpi/cpufreq/amd-cppc.c
> @@ -14,7 +14,56 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> +#include
> +#include
> +
> +#define amd_cppc_err(cpu, fmt, args..
On 14.04.2025 09:40, Penny Zheng wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -57,7 +57,6 @@ bool __initdata amd_virt_spec_ctrl;
> static bool __read_mostly fam17_c6_disabled;
>
> static uint64_t attr_const amd_parse_freq(unsigned char c, uint64_t value);
> -#define
On 29/04/2025 2:38 pm, Jan Beulich wrote:
> ..., which actually also helps readability (imo).
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 29/04/2025 2:37 pm, Jan Beulich wrote:
> Error paths of cpufreq_statistic_init() correctly free the base
> structure pointer, but the per-CPU variable would still hold it, mis-
> guiding e.g. cpufreq_statistic_update(). Defer installing of the pointer
> there until the structure was fully popula
On 29/04/2025 9:54 am, Jan Beulich wrote:
> Unlike the ones converting to/from frame numbers, these don't have type-
> safe overrides, and they also can't gain any within our present type
> system. Unsurprisingly we also don't have any uses of the underscore-
> prefixed variants.
>
> Signed-off-by:
..., which actually also helps readability (imo).
Signed-off-by: Jan Beulich
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -130,10 +130,10 @@ int cpufreq_statistic_init(unsigned int
return -ENOMEM;
}
-pxpt->u.total = pmpt->perf.state_count;
-p
Error paths of cpufreq_statistic_init() correctly free the base
structure pointer, but the per-CPU variable would still hold it, mis-
guiding e.g. cpufreq_statistic_update(). Defer installing of the pointer
there until the structure was fully populated.
Fixes: 755af07edba1 ("x86/cpufreq: don't use
On Tue Apr 29, 2025 at 2:00 PM BST, Jan Beulich wrote:
> On 29.04.2025 14:36, Alejandro Vallejo wrote:
>> Not very many changes here. Just:
>>
>> v5->v6:
>> * Denis' suggestion to rename a few helpers to fdt_*
>> * Change to last patch to only pass CDF_iommu to domains with
>> DOMAIN_CAPS_
On 14.04.2025 09:40, Penny Zheng wrote:
> We need to bypass construction of px statistic info in
> cpufreq_statistic_init() for amd-cppc mode, as P-states is not necessary
> there.
Is it really "need"? What goes wrong if we went through this initialization?
For now it feels more like an optimizat
On 29.04.2025 14:36, Alejandro Vallejo wrote:
> Not very many changes here. Just:
>
> v5->v6:
> * Denis' suggestion to rename a few helpers to fdt_*
> * Change to last patch to only pass CDF_iommu to domains with
> DOMAIN_CAPS_HARDWARE.
>
> I _think_ this addresses all feedback I got so f
On 14.04.2025 09:40, Penny Zheng wrote:
> @@ -514,5 +515,16 @@ acpi_cpufreq_driver = {
>
> int __init acpi_cpufreq_register(void)
> {
> -return cpufreq_register_driver(&acpi_cpufreq_driver);
> +int ret;
> +
> +ret = cpufreq_register_driver(&acpi_cpufreq_driver);
> +if ( ret )
>
On 29/04/2025 1:48 pm, Roger Pau Monné wrote:
> On Tue, Apr 29, 2025 at 01:36:43PM +0100, Andrew Cooper wrote:
>> It turns out that QEMU built in staging-4.19 (only) depends on it.
>>
>> But, GCC can emit libgcc calls for arbitrary reasons, so include it
>> unconditionally.
> Is there a fixes tag f
On Tue, Apr 29, 2025 at 01:36:43PM +0100, Andrew Cooper wrote:
> It turns out that QEMU built in staging-4.19 (only) depends on it.
>
> But, GCC can emit libgcc calls for arbitrary reasons, so include it
> unconditionally.
Is there a fixes tag for this, or it has always been this way?
> Signed-o
From: "Daniel P. Smith"
Introduce the ability to assign capabilities to a domain via its definition in
device tree. The capability property is a bitfield in both the device tree and
`struct boot_domain`.
Signed-off-by: Daniel P. Smith
Signed-off-by: Jason Andryuk
Signed-off-by: Alejandro Valle
From: "Daniel P. Smith"
Introduce the ability to specify the desired domain id for the domain
definition. The domain id will be populated in the domid property of the
domain node in the device tree configuration.
Signed-off-by: Daniel P. Smith
Signed-off-by: Alejandro Vallejo
Reviewed-by: Deni
From: "Daniel P. Smith"
Introduce the `cpus` property, named as such for dom0less compatibility, that
represents the maximum number of vcpus to allocate for a domain. In the device
tree, it will be encoded as a u32 value.
Signed-off-by: Daniel P. Smith
Reviewed-by: Jason Andryuk
Signed-off-by:
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 in the module list. If the bootargs property is present and
there was not an MB1 string, then use the command line from
From: "Daniel P. Smith"
Add support to read the command line from the hyperlaunch device tree.
The device tree command line is located in the "bootargs" property of the
"multiboot,kernel" node.
A boot loader command line, e.g. a grub module string field, takes
precendence over the device tree on
From: "Daniel P. Smith"
Enable selecting the mode in which the domain will be built and ran. This
includes:
- whether it will be either a 32/64 bit domain
- if it will be run as a PV or HVM domain
- and if it will require a device model (not applicable for dom0)
In the device tree, this w
From: "Daniel P. Smith"
Look for a subnode of type `multiboot,ramdisk` within a domain node and
parse via the fdt_read_multiboot_module() helper. After a successful
helper call, the module index is returned and the module is guaranteed
to be in the module list.
Fix unused typo in adjacent commen
From: "Daniel P. Smith"
Add three properties, memory, mem-min, and mem-max, to the domain node device
tree parsing to define the memory allocation for a domain. All three fields are
expressed in kb and written as a u64 in the device tree entries.
Signed-off-by: Daniel P. Smith
Reviewed-by: Jaso
Hyperlaunch mandates either a reg or module-index DT prop on nodes that
contain `multiboot,module" under their "compatible" prop. This patch
introduces a helper to generically find such index, appending the module
to the list of modules if it wasn't already (i.e: because it's given via
the "reg" pr
Hi,
Not very many changes here. Just:
v5->v6:
* Denis' suggestion to rename a few helpers to fdt_*
* Change to last patch to only pass CDF_iommu to domains with
DOMAIN_CAPS_HARDWARE.
I _think_ this addresses all feedback I got so far and I don't expect
anything major remaining before com
From: "Daniel P. Smith"
Introduce the domain builder which is capable of consuming a device tree as the
first boot module. If it finds a device tree as the first boot module, it will
set its type to BOOTMOD_FDT. This change only detects the boot module and
continues to boot with slight change to
From: "Daniel P. Smith"
Hyperlaunch domain builder will be the consolidated boot time domain
building logic framework. Introduce the config option to enable this
domain builder to eventually turn on the ability to load the domain
configuration via a flattened device tree.
Signed-off-by: Daniel P
From: "Daniel P. Smith"
Add the ability to detect both a formal hyperlaunch device tree or a dom0less
device tree. If the hyperlaunch device tree is found, then count the number of
domain entries, reporting an error if more than one is found.
Signed-off-by: Daniel P. Smith
Signed-off-by: Jason
It turns out that QEMU built in staging-4.19 (only) depends on it.
But, GCC can emit libgcc calls for arbitrary reasons, so include it
unconditionally.
Signed-off-by: Andrew Cooper
---
CC: Marek Marczykowski-Górecki
CC: Anthony PERARD
CC: Jan Beulich
---
scripts/alpine-rootfs.sh | 1 +
1 fil
On Tue, Apr 29, 2025 at 12:06:04PM +0800, Chen Linxuan via B4 Relay wrote:
> 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 onl
On 29.04.2025 13:52, Mykyta Poturai wrote:
> @@ -75,6 +76,11 @@ static int __init acpi_pci_init(void)
> }
> #endif
>
> +bool arch_pci_device_physdevop(void)
> +{
> +return iommu_enabled;
> +}
I'm not an Arm maintainer, but if I was, I'd demand that a clarifying comment
was added here.
> -
Hi Ayan,
> +/*
> + * There is no actual ns bit in hardware. It is used here for
> + * compatibility with Armr64 code. Thus, we are reusing a res0
> bit for ns.
typo: Arm64.
>>> Ack
> + */
H, this would mean someone may mistakenly s
On 28/04/2025 20:04, Luca Fancellu wrote:
Hi Ayan,
Hi Luca,
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 fo
On 29.04.25 14:01, Jan Beulich wrote:
On 29.04.2025 13:06, Juergen Gross wrote:
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -59,6 +59,7 @@ OBJS += optionroms.o 32bitbios_support.o rombios.o
CFLAGS += -DENABLE_ROMBIOS
ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-b
On 29.04.2025 13:06, Juergen Gross wrote:
> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -59,6 +59,7 @@ OBJS += optionroms.o 32bitbios_support.o rombios.o
> CFLAGS += -DENABLE_ROMBIOS
> ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
> ROMS += $(ROMBIOS_
On 29.04.2025 12:48, Alejandro Vallejo wrote:
> On Tue Apr 29, 2025 at 9:28 AM BST, Jan Beulich wrote:
>> On 28.04.2025 21: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
>>>
From: Stewart Hildebrand
Enable the use of IOMMU + PCI in dom0 without having to specify
"pci-passthrough=yes". Due to possible platform specific dependencies
of the PCI host, we rely on dom0 to initialize it and perform
a PHYSDEVOP_pci_device_add call to add each device to SMMU.
Because pci_pas
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: 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: 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: 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: 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
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: 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
On 29.04.2025 12:46, Roger Pau Monné wrote:
> On Tue, Apr 29, 2025 at 12:23:05PM +0200, Jan Beulich wrote:
>> On 29.04.2025 12:12, Roger Pau Monne wrote:
>>> Several handlers have the same necessity of reading or writing from or to
>>> an MMIO region using 1, 2, 4 or 8 bytes accesses. So far this
On 28.04.25 21:15, Julien Grall wrote:
> 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, Myky
On 29.04.2025 12:36, Jan Beulich wrote:
> On 14.04.2025 09:40, Penny Zheng wrote:
>> --- a/xen/drivers/cpufreq/cpufreq.c
>> +++ b/xen/drivers/cpufreq/cpufreq.c
>> @@ -71,6 +71,49 @@ unsigned int __initdata cpufreq_xen_cnt = 1;
>>
>> static int __init cpufreq_cmdline_parse(const char *s, const ch
On Mon Apr 28, 2025 at 8:57 PM 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 p
On Tue Apr 29, 2025 at 9:15 AM BST, Roger Pau Monné wrote:
> On Mon, Apr 28, 2025 at 12:50:55PM +0100, Alejandro Vallejo wrote:
>> 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 Mon
With the drop of qemu-traditional "make stubdom" no longer requires
"make tools" to have finished.
It is enough to add "install-tools-public-headers" as a prereq of
"install-stubdom".
Signed-off-by: Juergen Gross
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/M
Remove the code in tools for running a guest with qemu-traditional.
This covers xl, libxl, libacpi, hvmloader and the related python and
go bindings.
Signed-off-by: Juergen Gross
---
V2:
- Keep most of the removed comment in hvmloader, while removing parts
of another one (Jan Beulich)
V3:
- kee
Remove qemu traditional from the tree.
Signed-off-by: Juergen Gross
Acked-by: Oleksii Kurochko # CHANGELOG.md
---
V3:
- remove another ioemu reference in INSTALL (Anthony Perard)
- remove generating stubdompath.sh and related makefile helpers
(Anthony Perard)
---
.gitignore
In preparation to no longer support qemu-traditional (including
qemu-stubdom), remove it from documentation.
Signed-off-by: Juergen Gross
---
V2:
- mention "qemu_xen_traditional" in xenstore-paths.pandoc as a removed
device model variant (Andrew Cooper)
- don't drop Config.mk related documentat
Remove the qemu-traditional support. This includes the Mini-OS
based ioemu-stubdom.
Don't remove ROMBIOS for now, as it can be used with qemu (XenServer
is doing that).
After adding the series a run of autoconf should be done.
Changes in V2:
- addressed comments
Changes in V3:
- patches 1 and 5
On Tue Apr 29, 2025 at 9:28 AM BST, Jan Beulich wrote:
> On 28.04.2025 21: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.
>
> Hmm, I should have a
1 - 100 of 121 matches
Mail list logo
