On 30.01.2025 21:17, Jason Andryuk wrote:
> On 2025-01-21 11:13, Teddy Astie wrote:
>> +/**
>> + * IOMMU_alloc_nested
>> + * Create a nested IOMMU context (needs IOMMUCAP_nested).
>> + *
>> + * This context uses a platform-specific page table from domain address
>> space
>> + * specified in pgtabl
On 30.01.2025 22:31, Bjorn Helgaas wrote:
> On Thu, Jan 30, 2025 at 10:30:33AM +0100, Jan Beulich wrote:
>> On 30.01.2025 05:55, Marek Marczykowski-Górecki wrote:
>>> (XEN) d0v1 conf read cf8 0x80010088 bytes 2 offset 2 data 0x9
>
> PCIe Cap at 0x80, PCI_EXP_DEVCTL is 0x08, PCI_EXP_DEVSTA is 0x0a.
On Thu, 30 Jan 2025, Jürgen Groß wrote:
> Can you try the attached patch, please? I don't have a system at hand
> showing the problem.
>
> From cff43e997f79a95dc44e02debaeafe5f127f40bb Mon Sep 17 00:00:00 2001
> From: Juergen Gross
> Date: Thu, 30 Jan 2025 09:56:57 +0100
> Subject: [PATCH] x86/xen
On 2025/01/30 19:37, Philippe Mathieu-Daudé wrote:
(Series fully reviewed)
Since v1:
- Use g_strconcat (Akihiko)
In preparation of running QTests using HVF on Darwin,
make qtest_has_accel() generic.
Note, this also allow running other accelerators such
Xen, WHPX, ...
Philippe Mathieu-Daudé (2
On Wed, Jan 29, 2025 at 03:54:59PM -0500, Demi Marie Obenour wrote:
> On 1/8/25 12:05 PM, Simona Vetter wrote:
> > On Fri, Dec 27, 2024 at 10:24:29AM +0800, Huang, Honglei1 wrote:
> >>
> >> On 2024/12/22 9:59, Demi Marie Obenour wrote:
> >>> On 12/20/24 10:35 AM, Simona Vetter wrote:
> On Fri,
On Tue, Jan 21, 2025 at 5:19 AM Sergiy Kibrik wrote:
>
> Use more generic CONFIG_VM_EVENT name throughout Xen code instead of
> CONFIG_MEM_ACCESS. This reflects the fact that vm_event is a higher level
> feature, with mem_access & monitor depending on it.
>
> Suggested-by: Jan Beulich
> Suggested
On Thu, Jan 30, 2025 at 8:24 AM Jan Beulich wrote:
>
> On 21.01.2025 11:19, Sergiy Kibrik wrote:
> > Use more generic CONFIG_VM_EVENT name throughout Xen code instead of
> > CONFIG_MEM_ACCESS. This reflects the fact that vm_event is a higher level
> > feature, with mem_access & monitor depending o
On 31.01.2025 01:26, Tamas K Lengyel wrote:
> On Thu, Jan 30, 2025 at 8:24 AM Jan Beulich wrote:
>>
>> On 21.01.2025 11:19, Sergiy Kibrik wrote:
>>> Use more generic CONFIG_VM_EVENT name throughout Xen code instead of
>>> CONFIG_MEM_ACCESS. This reflects the fact that vm_event is a higher level
>>
On 30.01.2025 22:14, Stefano Stabellini wrote:
> On Thu, 30 Jan 2025, Jan Beulich wrote:
>> On 26.12.2024 17:57, Daniel P. Smith wrote:
>>> Look for a subnode of type `multiboot,kernel` within a domain node. If
>>> found,
>>> process the reg property for the MB1 module index. If the bootargs prope
On 30.01.25 21:28, Stefano Stabellini wrote:
On Thu, 30 Jan 2025, Jürgen Groß wrote:
Can you try the attached patch, please? I don't have a system at hand
showing the problem.
From cff43e997f79a95dc44e02debaeafe5f127f40bb Mon Sep 17 00:00:00 2001
From: Juergen Gross
Date: Thu, 30 Jan 2025 09:
On 31.01.2025 01:33, Tamas K Lengyel wrote:
> On Tue, Jan 21, 2025 at 5:25 AM Sergiy Kibrik wrote:
>> --- a/xen/arch/arm/vsmc.c
>> +++ b/xen/arch/arm/vsmc.c
>> @@ -330,7 +330,8 @@ void do_trap_smc(struct cpu_user_regs *regs, const union
>> hsr hsr)
>> }
>>
>> /* If monitor is enabled, l
On 26.12.2024 17:57, Daniel P. Smith wrote:
> --- a/xen/arch/x86/domain-builder/fdt.c
> +++ b/xen/arch/x86/domain-builder/fdt.c
> @@ -13,14 +13,77 @@
>
> #include "fdt.h"
>
> +static int __init find_hyperlaunch_node(const void *fdt)
> +{
> +int hv_node = fdt_path_offset(fdt, "/chosen/hyper
On 26.12.2024 17:57, Daniel P. Smith wrote:
> Look for a subnode of type `multiboot,kernel` within a domain node. If found,
> process the reg property for the MB1 module index. If the bootargs property is
> present and there was not an MB1 string, then use the command line from the
> device tree de
On 26.12.2024 17:57, Daniel P. Smith wrote:
> If a command line is not provided through the bootloader's mechanism, e.g.
> muiltboot module string field, then use one from the device tree if present.
> The device tree command line is located in the bootargs property of the
> `multiboot,kernel` node
On 26.12.2024 17:57, Daniel P. Smith wrote:
> Look for a subnode of type `multiboot,ramdisk` within a domain node. If
> found, process the reg property for the MB1 module index.
Unlike for cmdline it doesn't look to be mix-and-match here.
> --- a/xen/arch/x86/domain-builder/fdt.c
> +++ b/xen/arch
On 28.01.2025 17:33, Alejandro Vallejo wrote:
> Replace uses of the LAPIC_ID() macro with accesses to the
> cpu_to_apicid[] lookup table. This table contains the APIC IDs of each
> vCPU as probed at runtime rather than assuming a predefined relation.
>
> Moved smp_initialise() ahead of apic_setup(
On 28.01.2025 17:33, Alejandro Vallejo wrote:
> MP Tables have no means of representing APIC IDs wider than 255. At the
> moment the effect is wrapping around which would give a corrupted table
> with duplicate APIC IDs (some of them possibly the broadcast 255).
>
> Skip writing it altogether. Whi
On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
> From: Denis Mukhin
>
> Add separate menu for configuring HVM build-time settings to help organizing
> HVM-specific options.
>
> Signed-off-by: Denis Mukhin
Largely: Why not. Question is whether what is being moved now may
eventually requi
On 21.01.2025 11:23, Sergiy Kibrik wrote:
> Following the renaming of Xen build option.
>
> Signed-off-by: Sergiy Kibrik
> ---
> automation/eclair_analysis/xen_arm_config | 2 +-
> automation/eclair_analysis/xen_x86_config | 2 +-
> automation/gitlab-ci/build.yaml | 2 +-
> 3 files cha
On 26.12.2024 17:57, Daniel P. Smith wrote:
> Currently, the inclusion of libfdt is controlled by the CONFIG_HAS_DEVICE_TREE
> kconfig flag. This flag also changes behavior in a few places, such as boot
> module processing for XSM. To support the ability to include libfdt without
> changing these b
On 26.12.2024 17:57, Daniel P. Smith wrote:
> Hyperlaunch domain builder will be the consolidated boot time domain building
> logic framework. Introduces the config option to enable this domain builder to
> and turn on the ability to load the domain configuration via a flattened
> device
> tree.
On 26.12.2024 17:57, Daniel P. Smith wrote:
> 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
(Not going to repea
On 26.12.2024 17:57, Daniel P. Smith wrote:
> 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
I can't spot anything like this in the code changes.
> --- a/xen/arch/x86/domain-builder/fdt.c
> +++ b/xen/arch/x
On 26.12.2024 17:57, Daniel P. Smith wrote:
> --- a/xen/arch/x86/dom0_build.c
> +++ b/xen/arch/x86/dom0_build.c
> @@ -609,6 +609,14 @@ int __init construct_dom0(struct boot_domain *bd)
>
> process_pending_softirqs();
>
> +/* If param dom0_size was not set and HL config provided memory
On 26.12.2024 17:57, Daniel P. Smith wrote:
> Add a domid field to struct boot_domain to hold the assigned domain id for the
> domain. During initialization, ensure all instances of struct boot_domain have
> the invalid domid to ensure that the domid must be set either by convention or
> configurat
On 26.12.2024 17:57, Daniel P. Smith wrote:
> @@ -759,9 +758,10 @@ static int __init pvh_load_kernel(
> /* Free temporary buffers. */
> free_boot_modules();
>
> -if ( cmdline != NULL )
> +if ( bd->cmdline != NULL )
> {
> -rc = hvm_copy_to_guest_phys(last_addr, cmdli
On 29.01.25 19:46, Harshvardhan Jha wrote:
On 30/01/25 12:13 AM, Jürgen Groß wrote:
On 29.01.25 19:35, Harshvardhan Jha wrote:
On 29/01/25 4:52 PM, Juergen Gross wrote:
On 29.01.25 10:15, Harshvardhan Jha wrote:
On 29/01/25 2:34 PM, Greg KH wrote:
On Wed, Jan 29, 2025 at 02:29:48PM +0530,
On 26.12.2024 17:57, Daniel P. Smith wrote:
> @@ -596,9 +597,10 @@ int __init dom0_setup_permissions(struct domain *d)
> return rc;
> }
>
> -int __init construct_dom0(struct boot_info *bi, struct domain *d)
> +int __init construct_dom0(struct boot_domain *bd)
Pointer-to-const? Domain const
In order for amd_iommu_detect_one_acpi()'s call to pci_ro_device() to
have permanent effect, pci_segments_init() needs to be called ahead of
making it there. Without this we're losing segment 0's r/o map, and thus
we're losing write-protection of the PCI devices representing IOMMUs.
Which in turn m
Despite all the verbosity with "iommu=debug", information on the IOMMUs
themselves was missing.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -911,6 +911,11 @@ static int __init parse_ivhd_block(const
return -
The three patches are functionally independent, and they're presented
here merely in the order I came to notice the respective issues. At least
patch 2 wants seriously considering for 4.20.
1: AMD/IOMMU: drop stray MSI enabling
2: x86/PCI: init segments earlier
3: AMD/IOMMU: log IVHD contents
Jan
While the 2nd of the commits referenced below should have moved the call
to amd_iommu_msi_enable() instead of adding another one, the situation
wasn't quite right even before: It can't have done any good to enable
MSI when no IRQ was allocated for it, yet.
Fixes: 5f569f1ac50e ("AMD/IOMMU: allow en
On 21.01.2025 11:19, Sergiy Kibrik wrote:
> Use more generic CONFIG_VM_EVENT name throughout Xen code instead of
> CONFIG_MEM_ACCESS. This reflects the fact that vm_event is a higher level
> feature, with mem_access & monitor depending on it.
>
> Suggested-by: Jan Beulich
I don't think this is a
On 21.01.2025 11:21, Sergiy Kibrik wrote:
> Replace more general CONFIG_HVM option with CONFIG_VM_EVENT which is more
> relevant and specific to monitoring. This is only to clarify at build level
> to which subsystem this file belongs.
>
> No functional change here, as VM_EVENT depends on HVM.
>
On 21.01.2025 11:19, Sergiy Kibrik wrote:
> @@ -58,7 +58,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned
> long flag,
> return NULL;
> }
>
> -#endif /*CONFIG_MEM_ACCESS*/
> +#endif /*CONFIG_VM_EVENT*/
Oh, also - as you touch this anyway: Would you mind adding the mising blank
On 21.01.2025 11:25, Sergiy Kibrik wrote:
> --- a/xen/include/xen/monitor.h
> +++ b/xen/include/xen/monitor.h
> @@ -27,8 +27,17 @@
> struct domain;
> struct xen_domctl_monitor_op;
>
> +#ifdef CONFIG_VM_EVENT
> int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop);
> void mon
On 26.12.2024 17:57, Daniel P. Smith wrote:
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -81,6 +81,8 @@ obj-$(CONFIG_COMPAT) += x86_64/platform_hypercall.o
> obj-y += sysctl.o
> endif
>
> +obj-y += domain-builder/
The set of subdirs needed in $(obj-y) is specified at the to
On Wed, 29 Jan 2025, Stefano Stabellini wrote:
> On Wed, 29 Jan 2025, Edgar E. Iglesias wrote:
> > On Tue, Jan 28, 2025 at 03:58:14PM -0800, Stefano Stabellini wrote:
> > > On Tue, 28 Jan 2025, Edgar E. Iglesias wrote:
> > > > On Tue, Jan 28, 2025 at 03:15:44PM +0100, Olaf Hering wrote:
> > > > > H
On 26.12.2024 17:57, Daniel P. Smith wrote:
> --- a/xen/arch/x86/domain-builder/fdt.c
> +++ b/xen/arch/x86/domain-builder/fdt.c
> @@ -147,6 +147,17 @@ static int __init process_domain_node(
> bd->max_pages = PFN_DOWN(kb * SZ_1K);
> printk(" max memory: %ld kb\n", kb);
>
On Thu, Jan 30, 2025 at 10:30:33AM +0100, Jan Beulich wrote:
> On 30.01.2025 05:55, Marek Marczykowski-Górecki wrote:
> > I've added logging of all config read/write to this device. Full log at
> > [1].
> ...
I suspect there's something wrong with the Root Port RRS SV
configuration.
Can you add t
On Tue, Jan 21, 2025 at 5:25 AM Sergiy Kibrik wrote:
>
> From: Stefano Stabellini
>
> Extend coverage of CONFIG_VM_EVENT option and make the build of VM events
> and monitoring support optional.
> This is to reduce code size on Arm when this option isn't enabled.
>
> CC: Jan Beulich
> CC: Tamas
On Thu, 30 Jan 2025, Jan Beulich wrote:
> On 26.12.2024 17:57, Daniel P. Smith wrote:
> > Look for a subnode of type `multiboot,kernel` within a domain node. If
> > found,
> > process the reg property for the MB1 module index. If the bootargs property
> > is
> > present and there was not an MB1 s
Hi Teddy,
Thanks for working on this. I'm curious about your plans for this:
On 2025-01-21 11:13, Teddy Astie wrote:
+/**
+ * IOMMU_alloc_nested
+ * Create a nested IOMMU context (needs IOMMUCAP_nested).
+ *
+ * This context uses a platform-specific page table from domain address space
+ * spe
On 29.01.2025 17:25, Roger Pau Monné wrote:
> On Tue, Jan 28, 2025 at 06:42:38PM +, Alejandro Vallejo wrote:
>> On Tue Jan 28, 2025 at 5:45 PM GMT, Roger Pau Monné wrote:
>>> On Tue, Jan 28, 2025 at 04:33:39PM +, Alejandro Vallejo wrote:
The hypervisor, hvmloader and the toolstack curr
On 30.01.2025 05:55, Marek Marczykowski-Górecki wrote:
> I've added logging of all config read/write to this device. Full log at
> [1].
>
> A little explanation:
> - it's done in pci_conf_read/pci_conf_write in
> https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/pci.c;h=97b792e578f1
(Series fully reviewed)
Since v1:
- Use g_strconcat (Akihiko)
In preparation of running QTests using HVF on Darwin,
make qtest_has_accel() generic.
Note, this also allow running other accelerators such
Xen, WHPX, ...
Philippe Mathieu-Daudé (2):
tests/qtest: Extract qtest_qom_has_concrete_type
Since commit b14a0b7469f ("accel: Use QOM classes for accel types")
accelerators are registered as QOM objects. Use QOM as a generic
API to query for available accelerators. This is in particular
useful to query hardware accelerators such HFV, Xen or WHPX which
otherwise have their definitions pois
Extract qtest_qom_has_concrete_type() out of qtest_has_device()
in order to re-use it in the following commit.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Thomas Huth
---
tests/qtest/libqtest.c | 89 --
1 file changed, 51 insertions(+), 38 deletion
48 matches
Mail list logo
