Re: [PATCH v9 02/15] xen: introduce generic non-atomic test_*bit()

On 15.05.2024 19:03, Oleksii K. wrote: > On Wed, 2024-05-15 at 17:41 +0200, Jan Beulich wrote: >> On 15.05.2024 17:29, Oleksii K. wrote: >>> On Wed, 2024-05-15 at 10:52 +0200, Jan Beulich wrote: On 06.05.2024 12:15, Oleksii Kurochko wrote: > The following generic functions were introduced:

Re: [XEN PATCH 2/4] x86/hvm: address violations of MISRA C Rule 20.7

On 2024-05-16 01:18, Stefano Stabellini wrote: On Wed, 15 May 2024, Nicola Vetrini wrote: MISRA C Rule 20.7 states: "Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses". Therefore, some macro definitions should gain additional parentheses to ensure that

Re: [PATCH V3 (resend) 01/19] x86: Create per-domain mapping of guest_root_pt

On 15.05.2024 20:25, Elias El Yandouzi wrote: > However, I noticed quite a weird bug while doing some testing. I may > need your expertise to find the root cause. Looks like you've overflowed the dom0 kernel stack, most likely because of recurring nested exceptions. > In the case where I have mo

Re: [XEN PATCH v2 08/15] x86/vpmu: guard vmx/svm calls with cpu_has_{vmx,svm}

On 16.05.2024 02:44, Stefano Stabellini wrote: > On Wed, 15 May 2024, Sergiy Kibrik wrote: >> If VMX/SVM disabled in the build, we may still want to have vPMU drivers for >> PV guests. Yet some calls to vmx/svm-related routines needs to be guarded >> then. >> >> Signed-off-by: Sergiy Kibrik > >

Re: [XEN PATCH v2 12/15] x86/vmx: guard access to cpu_has_vmx_* in common code

On 16.05.2024 02:50, Stefano Stabellini wrote: > On Wed, 15 May 2024, Sergiy Kibrik wrote: >> There're several places in common code, outside of arch/x86/hvm/vmx, >> where cpu_has_vmx_* get accessed without checking if VMX present first. >> We may want to guard these macros, as they read global var

Re: [XEN PATCH v2 14/15] iommu/vt-d: guard vmx_pi_hooks_* calls with cpu_has_vmx

On 16.05.2024 02:54, Stefano Stabellini wrote: > On Wed, 15 May 2024, Sergiy Kibrik wrote: >> VMX posted interrupts support can now be excluded from x86 build along with >> VMX code itself, but still we may want to keep the possibility to use >> VT-d IOMMU driver in non-HVM setups. >> So we guard v

Re: [PATCH] hotplug: Restore block-tap phy compatibility

On 16.05.2024 04:22, Jason Andryuk wrote: > From: Jason Andryuk > > From: Jason Andryuk Two identical From: (also in another patch of yours, while in yet another one you have two _different_ ones, when only one will survive into the eventual commit anyway)? > backendtype=phy using the blktap k

Re: [PATCH] xen/sched: set all sched_resource data inside locked region for new cpu

On 15.05.2024 17:27, Andrew Cooper wrote: > On 15/05/2024 4:25 pm, Juergen Gross wrote: >> When adding a cpu to a scheduler, set all data items of struct >> sched_resource inside the locked region, as otherwise a race might >> happen (e.g. when trying to access the cpupool of the cpu): >> >> (XEN)

Re: [PATCH v2] include/ctype.h: fix MISRA R10.2 violation

On 16.05.2024 00:52, Stefano Stabellini wrote: > The value returned by __toupper is used in arithmetic operations causing > MISRA C 10.2 violations. Cast to plain char in the toupper macro. Also > do the same in tolower for consistency. > > Signed-off-by: Stefano Stabellini Acked-by: Jan Beulich

[xen-unstable test] 186007: tolerable FAIL - PUSHED

flight 186007 xen-unstable real [real] flight 186012 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/186007/ http://logs.test-lab.xenproject.org/osstest/logs/186012/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armh

Re: preparations for 4.17.4

On 27.03.2024 13:23, Jan Beulich wrote: > the release is due in two to three weeks. Please point out backports you find > missing from the respective staging branch, but which you consider relevant. > > Note that this is going to be the last Xen Project coordinated ordinary stable > release from t

Re: [PATCH V3 (resend) 14/19] Rename mfn_to_virt() calls

On 13.05.2024 15:40, Elias El Yandouzi wrote: > Until directmap gets completely removed, we'd still need to > keep some calls to mfn_to_virt() for xenheap pages or when the > directmap is enabled. > > Rename the macro to mfn_to_directmap_virt() to flag them and > prevent further use of mfn_to_virt

Re: [PATCH v14 1/5] vpci/header: emulate PCI_COMMAND register for guests

On 14.05.2024 16:33, Stewart Hildebrand wrote: > From: Oleksandr Andrushchenko > > Xen and/or Dom0 may have put values in PCI_COMMAND which they expect > to remain unaltered. PCI_COMMAND_SERR bit is a good example: while the > guest's (domU) view of this will want to be zero (for now), the host >

Re: [PATCH V3 (resend) 06/19] x86: Add a boot option to enable and disable the direct map

On Wed, May 15, 2024 at 03:54:51PM +0200, Jan Beulich wrote: > On 14.05.2024 11:20, Roger Pau Monné wrote: > > On Mon, May 13, 2024 at 01:40:33PM +, Elias El Yandouzi wrote: > >> --- a/docs/misc/xen-command-line.pandoc > >> +++ b/docs/misc/xen-command-line.pandoc > >> @@ -799,6 +799,18 @@ that

Re: [PATCH v14 2/5] vpci: add initial support for virtual PCI bus topology

On 14.05.2024 16:33, Stewart Hildebrand wrote: > From: Oleksandr Andrushchenko > > Assign SBDF to the PCI devices being passed through with bus 0. > The resulting topology is where PCIe devices reside on the bus 0 of the > root complex itself (embedded endpoints). > This implementation is limited

Re: [PATCH V3 (resend) 06/19] x86: Add a boot option to enable and disable the direct map

On 16.05.2024 11:19, Roger Pau Monné wrote: > On Wed, May 15, 2024 at 03:54:51PM +0200, Jan Beulich wrote: >> On 14.05.2024 11:20, Roger Pau Monné wrote: >>> On Mon, May 13, 2024 at 01:40:33PM +, Elias El Yandouzi wrote: --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-comm

Re: [XEN PATCH v3 2/6] x86/intel: move vmce_has_lmce() routine to header

On 14.05.2024 10:20, Sergiy Kibrik wrote: > Moving this function out of mce_intel.c would make it possible to disable > build of Intel MCE code later on, because the function gets called from > common x86 code. Why "would"? "Will" or "is going to" would seem more to the point to me. But anyway. >

Re: [XEN PATCH v3 5/6] x86/MCE: add default switch case in init_nonfatal_mce_checker()

On 14.05.2024 10:26, Sergiy Kibrik wrote: > The default switch case block is likely wanted here, to handle situation > e.g. of unexpected c->x86_vendor value -- then no mcheck init is done, but > misleading message still gets logged anyway. With "likely" dropped I'm okay with this as far as the ad

Re: [XEN PATCH v3 5/6] x86/MCE: add default switch case in init_nonfatal_mce_checker()

On 16.05.2024 11:44, Jan Beulich wrote: > On 14.05.2024 10:26, Sergiy Kibrik wrote: >> The default switch case block is likely wanted here, to handle situation >> e.g. of unexpected c->x86_vendor value -- then no mcheck init is done, but >> misleading message still gets logged anyway. > > With "li

[XEN PATCH v8 0/5] Support device passthrough when dom0 is PVH on Xen

Hi All, This is v8 series to support passthrough when dom0 is PVH v6->v7 changes: * patch#2: Add the domid check(domid == DOMID_SELF) to prevent self map when guest doesn't use pirq. That check was missed in the previous version. * patch#4: Due to changes in the implementation of obtain

[XEN PATCH v8 2/5] x86/pvh: Allow (un)map_pirq when dom0 is PVH

If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for a passthrough device by using gsi, see xen_pt_realize->xc_physdev_map_pirq and pci_add_dm_done->xc_physdev_map_pirq. Then xc_physdev_map_pirq will call into Xen, but in hvm_physdev_op, PHYSDEVOP_map_pirq is not allowed because currd is

[XEN PATCH v8 3/5] x86/pvh: Add PHYSDEVOP_setup_gsi for PVH dom0

On PVH dom0, the gsis don't get registered, but the gsi of a passthrough device must be configured for it to be able to be mapped into a hvm domU. On Linux kernel side, it calles PHYSDEVOP_setup_gsi for passthrough devices to register gsi when dom0 is PVH. So, add PHYSDEVOP_setup_gsi for above purp

[XEN PATCH v8 1/5] xen/vpci: Clear all vpci status of device

When a device has been reset on dom0 side, the vpci on Xen side won't get notification, so the cached state in vpci is all out of date compare with the real device state. To solve that problem, add a new hypercall to clear all vpci device state. When the state of device is reset on dom0 side, dom0

[RFC XEN PATCH v8 4/5] tools: Add new function to get gsi from dev

In PVH dom0, it uses the linux local interrupt mechanism, when it allocs irq for a gsi, it is dynamic, and follow the principle of applying first, distributing first. And irq number is alloced from small to large, but the applying gsi number is not, may gsi 38 comes before gsi 28, that causes the i

[RFC XEN PATCH v8 5/5] domctl: Add XEN_DOMCTL_gsi_permission to grant gsi

Some type of domain don't have PIRQ, like PVH, when passthrough a device to guest on PVH dom0, callstack pci_add_dm_done->XEN_DOMCTL_irq_permission will failed at domain_pirq_to_irq. So, add a new hypercall to grant/revoke gsi permission when dom0 is not PV or dom0 has not PIRQ flag. Signed-off-b

Re: [XEN PATCH v3 6/6] x86/MCE: optional build of AMD/Intel MCE code

On 14.05.2024 10:28, Sergiy Kibrik wrote: > --- a/xen/arch/x86/cpu/mcheck/mce.c > +++ b/xen/arch/x86/cpu/mcheck/mce.c > @@ -38,6 +38,10 @@ DEFINE_PER_CPU_READ_MOSTLY(unsigned int, nr_mce_banks); > unsigned int __read_mostly firstbank; > unsigned int __read_mostly ppin_msr; > uint8_t __read_mostl

[PATCH v2 1/8] xen/common/dt-overlay: Fix lock issue when add/remove the device

If CONFIG_DEBUG=y, below assertion will be triggered: (XEN) Assertion 'rw_is_locked(&dt_host_lock)' failed at drivers/passthrough/device_tree.c:146 (XEN) [ Xen-4.19-unstable arm64 debug=y Not tainted ] [...] (XEN) Xen call trace: (XEN)[<0a257418>] iommu_remove_dt_device+0x8c

[PATCH v2 0/8] Remaining patches for dynamic node programming using overlay dtbo

Hi all, This is the remaining series for the full functional "dynamic node programming using overlay dtbo" feature. The first part [1] has already been merged. Quoting from the original series, the first part has already made Xen aware of new device tree node which means updating the dt_host with

[PATCH v2 4/8] tools/arm: Introduce the "nr_spis" xl config entry

Currently, the number of SPIs allocated to the domain is only configurable for Dom0less DomUs. Xen domains are supposed to be platform agnostics and therefore the numbers of SPIs for libxl guests should not be based on the hardware. Introduce a new xl config entry for Arm to provide a method for u

[PATCH v2 8/8] docs: Add device tree overlay documentation

From: Vikram Garhwal Signed-off-by: Vikram Garhwal Signed-off-by: Stefano Stabellini Signed-off-by: Henry Wang --- v2: - Update the content based on the changes in this version. --- docs/misc/arm/overlay.txt | 99 +++ 1 file changed, 99 insertions(+) creat

[PATCH v2 6/8] xen/arm: Add XEN_DOMCTL_dt_overlay DOMCTL and related operations

In order to support the dynamic dtbo device assignment to a running VM, the add/remove of the DT overlay and the attach/detach of the device from the DT overlay should happen separately. Therefore, repurpose the existing XEN_SYSCTL_dt_overlay to only add the DT overlay to Xen device tree, instead o

[PATCH v2 2/8] tools/xl: Correct the help information and exit code of the dt-overlay command

Fix the name mismatch in the xl dt-overlay command, the command name should be "dt-overlay" instead of "dt_overlay". Add the missing "," in the cmdtable. Fix the exit code of the dt-overlay command, use EXIT_FAILURE instead of ERROR_FAIL. Fixes: 61765a07e3d8 ("tools/xl: Add new xl command overlay

[PATCH v2 7/8] tools: Introduce the "xl dt-overlay {attach,detach}" commands

With the XEN_DOMCTL_dt_overlay DOMCTL added, users should be able to attach/detach devices from the provided DT overlay to domains. Support this by introducing a new set of "xl dt-overlay" commands and related documentation, i.e. "xl dt-overlay {attach,detach}". Slightly rework the command option p

[PATCH v2 5/8] xen/arm/gic: Allow routing/removing interrupt to running VMs

From: Vikram Garhwal Currently, routing/removing physical interrupts are only allowed at the domain creation/destroy time. For use cases such as dynamic device tree overlay adding/removing, the routing/removing of physical IRQ to running domains should be allowed. Removing the above-mentioned do

[PATCH v2 3/8] xen/arm, doc: Add a DT property to specify IOMMU for Dom0less domUs

There are some use cases in which the dom0less domUs need to have the XEN_DOMCTL_CDF_iommu set at the domain construction time. For example, the dynamic dtbo feature allows the domain to be assigned a device that is behind the IOMMU at runtime. For these use cases, we need to have a way to specify

Re: [XEN PATCH v2 01/15] x86: introduce AMD-V and Intel VT-x Kconfig options

On 15.05.2024 10:59, Sergiy Kibrik wrote: > From: Xenia Ragiadakou > > Introduce two new Kconfig options, SVM and VMX, to allow code > specific to each virtualization technology to be separated and, when not > required, stripped. > CONFIG_SVM will be used to enable virtual machine extensions on p

[RFC QEMU PATCH v7 0/1] Support device passthrough when dom0 is PVH on Xen

Hi All, This is v7 series to support passthrough on Xen when dom0 is PVH. v6->v7 changes: * Due to changes in the implementation of obtaining gsi in the kernel and Xen. Change to use xc_physdev_gsi_from_dev, that requires passing in sbdf instead of irq. Best regards, Jiqian Chen v5->v6 chan

[REMINDER] - Submit your Design Sessions for Xen Summit!

Hello Xen Community, *Our design sessions are now open for Xen Summit! * If you've attended Xen Summit before, you might be familiar with the process. For anyone who hasn't done so before, please follow the instructions below, using the link to create an account

[RFC QEMU PATCH v7 1/1] xen/pci: get gsi for passthrough devices

In PVH dom0, it uses the linux local interrupt mechanism, when it allocs irq for a gsi, it is dynamic, and follow the principle of applying first, distributing first. And the irq number is alloced from small to large, but the applying gsi number is not, may gsi 38 comes before gsi 28, that causes t

Re: [XEN PATCH v2 02/15] x86/monitor: guard altp2m usage

On 15.05.2024 11:01, Sergiy Kibrik wrote: > --- a/xen/arch/x86/hvm/monitor.c > +++ b/xen/arch/x86/hvm/monitor.c > @@ -262,6 +262,8 @@ bool hvm_monitor_check_p2m(unsigned long gla, gfn_t gfn, > uint32_t pfec, > struct vcpu *curr = current; > vm_event_request_t req = {}; > paddr_t gpa

Re: [XEN PATCH v2 03/15] x86/p2m: guard altp2m routines

On 15.05.2024 11:03, Sergiy Kibrik wrote: > --- a/xen/arch/x86/mm/p2m-basic.c > +++ b/xen/arch/x86/mm/p2m-basic.c > @@ -126,13 +126,15 @@ int p2m_init(struct domain *d) > return rc; > } > > -rc = p2m_init_altp2m(d); > -if ( rc ) > +if ( hvm_altp2m_supported() ) > {

Re: [PATCH v9 02/15] xen: introduce generic non-atomic test_*bit()

On Thu, 2024-05-16 at 09:04 +0200, Jan Beulich wrote: > On 15.05.2024 19:03, Oleksii K. wrote: > > On Wed, 2024-05-15 at 17:41 +0200, Jan Beulich wrote: > > > On 15.05.2024 17:29, Oleksii K. wrote: > > > > On Wed, 2024-05-15 at 10:52 +0200, Jan Beulich wrote: > > > > > On 06.05.2024 12:15, Oleksii

Re: [XEN PATCH v2 04/15] x86/p2m: move altp2m-related code to separate file

On 15.05.2024 11:06, Sergiy Kibrik wrote: > --- a/xen/arch/x86/mm/p2m.c > +++ b/xen/arch/x86/mm/p2m.c > @@ -500,7 +500,7 @@ int p2m_alloc_table(struct p2m_domain *p2m) > return 0; > } > > -static int __must_check > +int __must_check > p2m_remove_entry(struct p2m_domain *p2m, gfn_t gfn, mfn

Re: [XEN PATCH v2 05/15] x86: introduce CONFIG_ALTP2M Kconfig option

On 15.05.2024 11:08, Sergiy Kibrik wrote: > --- a/xen/arch/x86/Kconfig > +++ b/xen/arch/x86/Kconfig > @@ -358,6 +358,11 @@ config REQUIRE_NX > was unavailable. However, if enabled, Xen will no longer boot on > any CPU which is lacking NX support. > > +config ALTP2M > + bool "A

Re: [PATCH v9 02/15] xen: introduce generic non-atomic test_*bit()

On 16.05.2024 12:34, Oleksii K. wrote: > On Thu, 2024-05-16 at 09:04 +0200, Jan Beulich wrote: >> (Later) Wait, maybe I've finally figured it: You use >> arch__test_and_*() >> because those underlie __test_and_*(), but arch_test_bit() because >> there's >> solely test_bit() (same for the generic_*

Re: [XEN PATCH v2 06/15] x86/p2m: guard altp2m code with CONFIG_ALTP2M option

On 16.05.2024 02:38, Stefano Stabellini wrote: > On Wed, 15 May 2024, Sergiy Kibrik wrote: >> --- a/xen/arch/x86/include/asm/p2m.h >> +++ b/xen/arch/x86/include/asm/p2m.h >> @@ -581,9 +581,9 @@ static inline gfn_t mfn_to_gfn(const struct domain *d, >> mfn_t mfn) >> return _gfn(mfn_x(mfn))

[PATCH v3 3/4] tools/hotplug/Linux: Add bridge VLAN support

Update add_to_bridge shell function to read the vlan parameter from xenstore and set the bridge VLAN configuration for the VID. Add additional helper functions to parse the vlan specification, which consists of one or more of the following: a) single VLAN (e.g. 10). b) contiguous range of VLANs (

[PATCH v3 1/4] tools/libs/light: Add vlan field to libxl_device_nic

Add `vlan' string field to libxl_device_nic, to allow a VLAN configuration to be specified for the VIF when adding it to the bridge device. Update libxl_nic.c to read and write the vlan field from the xenstore. This provides the capability for supported operating systems (e.g. Linux) to perform V

[PATCH v3 0/4] Add bridge VLAN support

Hello All, I have addressed all the feedback from Jason and merged patch 4 and 2 as requested by Andrew. Summary of changes from RFC v2 to v3: - xen-network-common.sh: use fatal() directly instead of $error variable - xen-network-common.sh: bridge command not being available is now fatal - Move

[PATCH v3 2/4] tools/xl: add vlan keyword to vif option

Update parse_nic_config() to support a new `vlan' keyword. This keyword specifies the VLAN configuration to assign to the VIF when attaching it to the bridge port, on operating systems that support the capability (e.g. Linux). The vlan keyword will allow one or more VLANs to be configured on the VI

[PATCH v3 4/4] docs/misc: Example Linux bridge VLAN config

Add a new directory linux-bridge-vlan with example files showing how to configure systemd-networkd to support a bridge VLAN configuration. Signed-off-by: Leigh Brown --- docs/misc/linux-bridge-vlan/README | 68 ++ docs/misc/linux-bridge-vlan/br0.netdev | 7 +++

Re: [XEN PATCH v2 06/15] x86/p2m: guard altp2m code with CONFIG_ALTP2M option

On 15.05.2024 11:10, Sergiy Kibrik wrote: > @@ -38,7 +38,10 @@ static inline bool altp2m_active(const struct domain *d) > } > > /* Only declaration is needed. DCE will optimise it out when linking. */ > +void altp2m_vcpu_initialise(struct vcpu *v); > +void altp2m_vcpu_destroy(struct vcpu *v); >

[PATCH] tools: Add install/uninstall targets to tests/x86_emulator

Bring test_x86_emulator in line with other tests by adding install/uninstall rules. Signed-off-by: Alejandro Vallejo --- tools/tests/x86_emulator/Makefile | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/tools/tests/x86_emulator/Makefile b/tools/tests/x86_emulator

Re: [XEN PATCH v2 07/15] x86: guard cpu_has_{svm/vmx} macros with CONFIG_{SVM/VMX}

On 15.05.2024 11:12, Sergiy Kibrik wrote: > --- a/xen/arch/x86/include/asm/cpufeature.h > +++ b/xen/arch/x86/include/asm/cpufeature.h > @@ -81,7 +81,8 @@ static inline bool boot_cpu_has(unsigned int feat) > #define cpu_has_sse3boot_cpu_has(X86_FEATURE_SSE3) > #define cpu_has_pclmulqdq

Re: [PATCH] tools: Add install/uninstall targets to tests/x86_emulator

On 16.05.2024 13:07, Alejandro Vallejo wrote: > Bring test_x86_emulator in line with other tests by adding > install/uninstall rules. > > Signed-off-by: Alejandro Vallejo I'd expect such a change to come with a word towards what use the binary has on the installed system. Imo we should not rando

Re: [XEN PATCH v2 08/15] x86/vpmu: guard vmx/svm calls with cpu_has_{vmx,svm}

On 15.05.2024 11:14, Sergiy Kibrik wrote: > --- a/xen/arch/x86/cpu/vpmu_amd.c > +++ b/xen/arch/x86/cpu/vpmu_amd.c > @@ -290,7 +290,7 @@ static int cf_check amd_vpmu_save(struct vcpu *v, bool > to_guest) > context_save(v); > > if ( !vpmu_is_set(vpmu, VPMU_RUNNING) && is_hvm_vcpu(v) &&

[PATCH for-4.19? v3 0/6] x86: Make MAX_ALTP2M configurable

From: Petr Beneš This series introduces the ability to configure the maximum number of altp2m tables during domain creation. Previously, the limits were hardcoded to a maximum of 10. This change allows for greater flexibility in environments that require more or fewer altp2m views. Adjustments i

[PATCH for-4.19? v3 3/6] docs/man: Add altp2m_count parameter to the xl.cfg manual

From: Petr Beneš Update manual pages to include detailed information about the altp2m_count configuration parameter. Signed-off-by: Petr Beneš --- docs/man/xl.cfg.5.pod.in | 14 ++ 1 file changed, 14 insertions(+) diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in in

[PATCH for-4.19? v3 5/6] tools/libxl: Activate the altp2m_count feature

From: Petr Beneš This commit activates the previously introduced altp2m_count parameter, establishing the connection between libxl and Xen. Signed-off-by: Petr Beneš --- tools/libs/light/libxl_create.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/libs/light/libxl_create.c b/tools/

[PATCH for-4.19? v3 2/6] tools/xl: Add altp2m_count parameter

From: Petr Beneš Introduce a new altp2m_count parameter to control the maximum number of altp2m views a domain can use. By default, if altp2m_count is unspecified and altp2m is enabled, the value is set to 10, reflecting the legacy behavior. This change is preparatory; it establishes the groundw

[PATCH for-4.19? v3 1/6] x86/p2m: Add braces for better code clarity

From: Petr Beneš No functional change. Signed-off-by: Petr Beneš Reviewed-by: Stefano Stabellini --- xen/arch/x86/mm/p2m.c | 4 1 file changed, 4 insertions(+) diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index ce742c12e0..eb7996170d 100644 --- a/xen/arch/x86/mm/p2m.c +++

[PATCH for-4.19? v3 6/6] tools/ocaml: Add altp2m_count parameter

From: Petr Beneš Allow developers using the OCaml bindings to set the altp2m_count parameter. Signed-off-by: Petr Beneš Acked-by: Christian Lindig --- tools/ocaml/libs/xc/xenctrl.ml | 1 + tools/ocaml/libs/xc/xenctrl.mli | 1 + tools/ocaml/libs/xc/xenctrl_stubs.c | 11 +++

[PATCH for-4.19? v3 4/6] x86: Make the maximum number of altp2m views configurable

From: Petr Beneš This commit introduces the ability to configure the maximum number of altp2m views for the domain during its creation. Previously, the limits were hardcoded to a maximum of 10. This change allows for greater flexibility in environments that require more or fewer altp2m views. Th

[PATCH] x86/ucode: Further fixes to identify "ucode already up to date"

When the revision in hardware is newer than anything Xen has to hand, 'microcode_cache' isn't set up. Then, `xen-ucode` initiates the update because it doesn't know whether the revisions across the system are symmetric or not. This involves the patch getting all the way into the apply_microcode()

Re: [PATCH] tools: Add install/uninstall targets to tests/x86_emulator

On Thu, May 16, 2024 at 12:07:10PM +0100, Alejandro Vallejo wrote: > Bring test_x86_emulator in line with other tests by adding > install/uninstall rules. > > Signed-off-by: Alejandro Vallejo > --- > tools/tests/x86_emulator/Makefile | 11 +-- > 1 file changed, 9 insertions(+), 2 deletio

Re: [PATCH] x86/ucode: Further fixes to identify "ucode already up to date"

On 16.05.2024 13:31, Andrew Cooper wrote: > When the revision in hardware is newer than anything Xen has to hand, > 'microcode_cache' isn't set up. Then, `xen-ucode` initiates the update > because it doesn't know whether the revisions across the system are symmetric > or not. This involves the pa

Re: [XEN PATCH v2 04/15] x86/p2m: move altp2m-related code to separate file

On 16.05.2024 02:35, Stefano Stabellini wrote: > On Wed, 15 May 2024, Sergiy Kibrik wrote: >> Move altp2m code from generic p2m.c file to altp2m.c, so it is kept >> separately >> and can possibly be disabled in the build. We may want to disable it when >> building for specific platform only, that

Re: [PATCH] x86/ucode: Further fixes to identify "ucode already up to date"

On Thu, May 16, 2024 at 12:31:03PM +0100, Andrew Cooper wrote: > When the revision in hardware is newer than anything Xen has to hand, > 'microcode_cache' isn't set up. Then, `xen-ucode` initiates the update > because it doesn't know whether the revisions across the system are symmetric > or not.

[xen-unstable-smoke test] 186014: tolerable all pass - PUSHED

flight 186014 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/186014/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 1

Re: [XEN PATCH v2 13/15] x86/ioreq: guard VIO_realmode_completion with CONFIG_VMX

On 15.05.2024 11:24, Sergiy Kibrik wrote: > --- a/xen/arch/x86/hvm/emulate.c > +++ b/xen/arch/x86/hvm/emulate.c > @@ -2667,7 +2667,9 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt > *hvmemul_ctxt, > break; > > case VIO_mmio_completion: > +#ifdef CONFIG_VMX > case VIO_r

Re: [XEN PATCH v2 14/15] iommu/vt-d: guard vmx_pi_hooks_* calls with cpu_has_vmx

On 15.05.2024 11:26, Sergiy Kibrik wrote: > VMX posted interrupts support can now be excluded from x86 build along with > VMX code itself, but still we may want to keep the possibility to use > VT-d IOMMU driver in non-HVM setups. > So we guard vmx_pi_hooks_{assign/deassign} with some checks for su

Re: [PATCH v5 6/8] xen: mapcache: Pass the ram_addr offset to xen_map_cache()

On Thu, May 16, 2024 at 1:08 AM Stefano Stabellini wrote: > > On Fri, 3 May 2024, Edgar E. Iglesias wrote: > > From: "Edgar E. Iglesias" > > > > Pass the ram_addr offset to xen_map_cache. > > This is in preparation for adding grant mappings that need > > to compute the address within the RAMBlock

Re: [XEN PATCH v2 15/15] x86/hvm: make AMD-V and Intel VT-x support configurable

On 16.05.2024 02:54, Stefano Stabellini wrote: > On Wed, 15 May 2024, Sergiy Kibrik wrote: >> From: Xenia Ragiadakou >> >> Provide the user with configuration control over the cpu virtualization >> support >> in Xen by making SVM and VMX options user selectable. >> >> To preserve the current defa

Re: [PATCH] tools: Add install/uninstall targets to tests/x86_emulator

On 16/05/2024 12:35, Roger Pau Monné wrote: > On Thu, May 16, 2024 at 12:07:10PM +0100, Alejandro Vallejo wrote: >> Bring test_x86_emulator in line with other tests by adding >> install/uninstall rules. >> >> Signed-off-by: Alejandro Vallejo >> --- >> tools/tests/x86_emulator/Makefile | 11 ++

Re: [PATCH] x86/ucode: Further fixes to identify "ucode already up to date"

On 16/05/2024 12:50 pm, Roger Pau Monné wrote: > On Thu, May 16, 2024 at 12:31:03PM +0100, Andrew Cooper wrote: >> When the revision in hardware is newer than anything Xen has to hand, >> 'microcode_cache' isn't set up. Then, `xen-ucode` initiates the update >> because it doesn't know whether the

Re: [PATCH v2 6/8] xen/arm: Add XEN_DOMCTL_dt_overlay DOMCTL and related operations

On 16.05.2024 12:03, Henry Wang wrote: > +static long handle_detach_overlay_nodes(struct domain *d, > +const void *overlay_fdt, > +uint32_t overlay_fdt_size) > +{ > +int rc; > +unsigned int j; > +struct over

Re: [PATCH] x86/ucode: Further fixes to identify "ucode already up to date"

On 16/05/2024 12:44 pm, Jan Beulich wrote: > On 16.05.2024 13:31, Andrew Cooper wrote: >> When the revision in hardware is newer than anything Xen has to hand, >> 'microcode_cache' isn't set up. Then, `xen-ucode` initiates the update >> because it doesn't know whether the revisions across the syst

Re: [PATCH] tools: Add install/uninstall targets to tests/x86_emulator

On 16.05.2024 14:29, Alejandro Vallejo wrote: > On 16/05/2024 12:35, Roger Pau Monné wrote: >> On Thu, May 16, 2024 at 12:07:10PM +0100, Alejandro Vallejo wrote: >>> Bring test_x86_emulator in line with other tests by adding >>> install/uninstall rules. >>> >>> Signed-off-by: Alejandro Vallejo >>>

Re: [PATCH] x86/ucode: Further fixes to identify "ucode already up to date"

On Thu, May 16, 2024 at 01:30:21PM +0100, Andrew Cooper wrote: > On 16/05/2024 12:50 pm, Roger Pau Monné wrote: > > On Thu, May 16, 2024 at 12:31:03PM +0100, Andrew Cooper wrote: > >> When the revision in hardware is newer than anything Xen has to hand, > >> 'microcode_cache' isn't set up. Then, `

Re: [PATCH v2 1/7] xen/arm: Lookup bootinfo shm bank during the mapping

Hi Luca, On 15/05/2024 16:26, Luca Fancellu wrote: > > > The current static shared memory code is using bootinfo banks when it > needs to find the number of borrowers, so every time assign_shared_memory > is called, the bank is searched in the bootinfo.shmem structure. > > There is nothing wron

Re: [XEN PATCH v8 1/5] xen/vpci: Clear all vpci status of device

On 16.05.2024 11:52, Jiqian Chen wrote: > @@ -67,6 +68,41 @@ ret_t pci_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) > arg) > break; > } > > +case PHYSDEVOP_pci_device_state_reset: { > +struct physdev_pci_device dev; > +struct pci_dev *pdev; > +pci_sb

Re: [PATCH] tools: Add install/uninstall targets to tests/x86_emulator

Hi, On 16/05/2024 12:16, Jan Beulich wrote: > On 16.05.2024 13:07, Alejandro Vallejo wrote: >> Bring test_x86_emulator in line with other tests by adding >> install/uninstall rules. >> >> Signed-off-by: Alejandro Vallejo > > I'd expect such a change to come with a word towards what use the binar

Re: [PATCH v2 2/7] xen/arm: Wrap shared memory mapping code in one function

Hi Luca, On 15/05/2024 16:26, Luca Fancellu wrote: > > > Wrap the code and logic that is calling assign_shared_memory > and map_regions_p2mt into a new function 'handle_shared_mem_bank', > it will become useful later when the code will allow the user to > don't pass the host physical address. >

[PATCH for-4.19] xen/x86: limit interrupt movement done by fixup_irqs()

The current check used in fixup_irqs() to decide whether to move around interrupts is based on the affinity mask, but such mask can have all bits set, and hence is unlikely to be a subset of the input mask. For example if an interrupt has an affinity mask of all 1s, any input to fixup_irqs() that'

Re: [PATCH v2 2/7] xen/arm: Wrap shared memory mapping code in one function

Hi Michal, >> >> -/* >> - * "role" property is optional and if it is defined explicitly, >> - * then the owner domain is not the default "dom_io" domain. >> - */ >> -if ( dt_property_read_string(shm_node, "role", &role_str) == 0 ) >> -owner_dom_

Re: [XEN PATCH v8 2/5] x86/pvh: Allow (un)map_pirq when dom0 is PVH

On 16.05.2024 11:52, Jiqian Chen wrote: > If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for > a passthrough device by using gsi, see > xen_pt_realize->xc_physdev_map_pirq and > pci_add_dm_done->xc_physdev_map_pirq. xen_pt_realize() is in qemu, which imo wants saying here (for being a

Re: [PATCH v2 3/7] xen/p2m: put reference for level 2 superpage

Hi Luca, On 15/05/2024 16:26, Luca Fancellu wrote: > > > From: Penny Zheng > > We are doing foreign memory mapping for static shared memory, and > there is a great possibility that it could be super mapped. > But today, p2m_put_l3_page could not handle superpages. s/could/can > > This commit

Re: [XEN PATCH v8 3/5] x86/pvh: Add PHYSDEVOP_setup_gsi for PVH dom0

On 16.05.2024 11:52, Jiqian Chen wrote: > --- a/xen/arch/x86/hvm/hypercall.c > +++ b/xen/arch/x86/hvm/hypercall.c > @@ -76,6 +76,11 @@ long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) > arg) > case PHYSDEVOP_unmap_pirq: > break; > > +case PHYSDEVOP_setup_gsi: > +

Re: [PATCH] hotplug: Restore block-tap phy compatibility

On 2024-05-16 03:41, Jan Beulich wrote: On 16.05.2024 04:22, Jason Andryuk wrote: From: Jason Andryuk From: Jason Andryuk Two identical From: (also in another patch of yours, while in yet another one you have two _different_ ones, when only one will survive into the eventual commit anyway)?

[PATCH 00/12] automation: Add build and test for Linux stubdomain

Initial patches can be applied independently but all are needed before the "automation: Add linux stubdom build and smoke test" patch. And later "libxl: Allow stubdomain to control interupts of PCI device" and "automation: update kernel for x86 tests" is needed before PCI passthrough test (but both

[PATCH 02/12] automation: update fedora build to F39

Fedora 29 is long EOL Signed-off-by: Marek Marczykowski-Górecki --- automation/build/fedora/29.dockerfile | 46 + automation/build/fedora/39.dockerfile | 46 - automation/gitlab-ci/build.yaml | 4 +- 3 files changed, 48 insertions(+)

[PATCH 10/12] automation: stubdom test with PCI passthrough

Based on the initial stubdomain test and existing PCI passthrough tests, add one that combines both. Schedule it on the AMD runner, as it has less tests right now. Signed-off-by: Marek Marczykowski-Górecki --- automation/gitlab-ci/test.yaml | 8 automation/scripts/qubes-x86-64.sh |

[PATCH 03/12] automation: switch to alpine:3.19

Alpine 3.19 is needed for upcoming stubdomain tests, as linux stubdomain build requires dracut-core package (dracut-install tool specifically) which isn't available in 3.18. While technically it will be needed only in the x86_64 builds, switch Alpine version everywhere for uniformity. Note this bum

[PATCH 06/12] RFC: automation: Add linux stubdom build and smoke test

Add minimal linux-stubdom smoke test. It starts a simple HVM with linux-stubdom. The actual stubdom implementation is taken from Qubes OS and then stripped off Qubes-specific code. In particular, the remaining code does _not_ support: - direct kernel boot (implemented by relaying on specific guest

[PATCH 08/12] automation: update kernel for x86 tests

Update 6.1.x kernel to the latest version in this branch. This is especially needed to include MSI-X related fixes for stubdomain ("xen-pciback: Consider INTx disabled when MSI/MSI-X is enabled"). Signed-off-by: Marek Marczykowski-Górecki --- automation/gitlab-ci/build.yaml |

[PATCH 12/12] [DO NOT MERGE] switch to my containers fork

--- automation/gitlab-ci/build.yaml | 19 --- automation/gitlab-ci/test.yaml | 9 - 2 files changed, 24 insertions(+), 4 deletions(-) diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml index f1e6a6144c90..88a59692a881 100644 --- a/automation/g

[PATCH 05/12] automation: prevent grub unpacking initramfs

It fails on larger initramfs (~250MB one), let Linux do it. Signed-off-by: Marek Marczykowski-Górecki --- automation/scripts/qubes-x86-64.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh index bd620b0d

[PATCH 01/12] automation: include domU kernel messages in the console output log

Signed-off-by: Marek Marczykowski-Górecki --- automation/scripts/qubes-x86-64.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh index d81ed7b931cf..4beeff17d31b 100755 --- a/automation/scripts/qubes-x86-64.sh +++ b/au

[PATCH 07/12] libxl: Allow stubdomain to control interupts of PCI device

Especially allow it to control MSI/MSI-X enabling bits. This part only writes a flag to a sysfs, the actual implementation is on the kernel side. This requires Linux >= 5.10 in dom0 (or relevant patch backported). Signed-off-by: Marek Marczykowski-Górecki --- tools/libs/light/libxl_pci.c | 8 ++

[PATCH 04/12] automation: increase verbosity of starting a domain

And start collecting qemu log earlier, so it isn't lost in case of a timeout during domain startup. Signed-off-by: Marek Marczykowski-Górecki --- automation/scripts/qemu-alpine-x86_64.sh| 2 +- automation/scripts/qemu-smoke-dom0-arm32.sh | 2 +- automation/scripts/qemu-smoke-dom0-arm64.sh |

  1   2   >