Re: [PATCH v2 5/8] tools/hvmloader: Retrieve (x2)APIC IDs from the APs themselves

On Wed, May 08, 2024 at 01:39:24PM +0100, Alejandro Vallejo wrote: > Make it so the APs expose their own APIC IDs in a LUT. We can use that LUT to > populate the MADT, decoupling the algorithm that relates CPU IDs and APIC IDs > from hvmloader. > > While at this also remove ap_callin, as writing t

Re: [PATCH v2 3/8] x86/vlapic: Move lapic_load_hidden migration checks to the check hook

On Thu, May 23, 2024 at 07:58:57PM +0100, Andrew Cooper wrote: > On 08/05/2024 1:39 pm, Alejandro Vallejo wrote: > > diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c > > index 8a24419c..2f06bff1b2cc 100644 > > --- a/xen/arch/x86/hvm/vlapic.c > > +++ b/xen/arch/x86/hvm/vlapic.c

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

On Fri, 2024-05-24 at 08:48 +0200, Jan Beulich wrote: > On 23.05.2024 18:40, Oleksii K. wrote: > > On Thu, 2024-05-23 at 15:33 +0100, Julien Grall wrote: > > > On 23/05/2024 15:11, Oleksii K. wrote: > > > > On Thu, 2024-05-23 at 14:00 +0100, Julien Grall wrote: > > > > > On 17/05/2024 14:54, Oleksi

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

On 24.05.2024 09:25, Oleksii K. wrote: > On Fri, 2024-05-24 at 08:48 +0200, Jan Beulich wrote: >> On 23.05.2024 18:40, Oleksii K. wrote: >>> On Thu, 2024-05-23 at 15:33 +0100, Julien Grall wrote: On 23/05/2024 15:11, Oleksii K. wrote: > On Thu, 2024-05-23 at 14:00 +0100, Julien Grall wrote

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

On Fri, 2024-05-24 at 09:35 +0200, Jan Beulich wrote: > On 24.05.2024 09:25, Oleksii K. wrote: > > On Fri, 2024-05-24 at 08:48 +0200, Jan Beulich wrote: > > > On 23.05.2024 18:40, Oleksii K. wrote: > > > > On Thu, 2024-05-23 at 15:33 +0100, Julien Grall wrote: > > > > > On 23/05/2024 15:11, Oleksii

Re: [PATCH v2 7/8] xen/x86: Derive topologically correct x2APIC IDs from the policy

On Wed, May 08, 2024 at 01:39:26PM +0100, Alejandro Vallejo wrote: > Implements the helper for mapping vcpu_id to x2apic_id given a valid > topology in a policy. The algo is written with the intention of extending > it to leaves 0x1f and e26 in the future. Using 0x1f and e26 is kind of confusing.

Re: [PATCH v2 8/8] xen/x86: Synthesise domain topologies

On Wed, May 08, 2024 at 01:39:27PM +0100, Alejandro Vallejo wrote: > Expose sensible topologies in leaf 0xb. At the moment it synthesises non-HT > systems, in line with the previous code intent. > > Signed-off-by: Alejandro Vallejo > --- > v2: > * Zap the topology leaves of (pv/hvm)_(def/max)_p

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

On Thu, 2024-05-23 at 15:33 +0100, Julien Grall wrote: > > > >     #include > > > >     > > > > +/** > > > > + * generic__test_and_set_bit - Set a bit and return its old > > > > value > > > > + * @nr: Bit to set > > > > + * @addr: Address to count from > > > > + * > > > > + * This operation is no

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

Hi Oleksii, On 24/05/2024 09:58, Oleksii K. wrote: On Thu, 2024-05-23 at 15:33 +0100, Julien Grall wrote:     #include +/** + * generic__test_and_set_bit - Set a bit and return its old value + * @nr: Bit to set + * @addr: Address to count from + * + * This operation is non-atomic and c

Re: [PATCH v5 3/7] tools/arm: Introduce the "nr_spis" xl config entry

Hi, On 24/05/2024 03:18, Stefano Stabellini wrote: From: Henry Wang 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 har

Re: [PATCH v5 5/7] xen/arm: Add XEN_DOMCTL_dt_overlay and device attachment to domains

Hi Stefano, On 24/05/2024 03:18, Stefano Stabellini wrote: From: Henry Wang 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 existi

[linux-linus test] 186127: tolerable FAIL - PUSHED

flight 186127 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/186127/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-check fail blocked in 186052 test-armhf-armhf-xl-qcow2 8 xen-b

Re: [PATCH v5 6/7] tools: Introduce the "xl dt-overlay attach" command

Hi Stefano, On 24/05/2024 03:18, Stefano Stabellini wrote: From: Henry Wang With the XEN_DOMCTL_dt_overlay DOMCTL added, users should be able to attach (in the future also detach) devices from the provided DT overlay to domains. Support this by introducing a new "xl dt-overlay" command and rel

[REMINDER] Xen Summit 2024 - Verification code for design sessions

Hello Xen Community, Day 2 design sessions will be locked end of today, so get voting! Day 3 design sessions are still open, and will be finalized 3 June 2024 after 5pm Lisbon Time. *The verification code is 'LFXEN24'. * The final schedule will be alloca

Re: [PATCH v5 7/7] docs: Add device tree overlay documentation

Hi Stefano, On 24/05/2024 03:18, Stefano Stabellini wrote: From: Vikram Garhwal Signed-off-by: Vikram Garhwal Signed-off-by: Stefano Stabellini Signed-off-by: Henry Wang --- docs/misc/arm/overlay.txt | 82 +++ 1 file changed, 82 insertions(+) create

Re: [PATCH v3 2/2] tools/xg: Clean up xend-style overrides for CPU policies

On 23/05/2024 11:47, Roger Pau Monné wrote: >> -static xen_cpuid_leaf_t *find_leaf( >> -xen_cpuid_leaf_t *leaves, unsigned int nr_leaves, >> -const struct xc_xend_cpuid *xend) >> +static xen_cpuid_leaf_t *find_leaf(xc_cpu_policy_t *p, >> + const struct xc_x

Re: [PATCH v3 1/2] tools/xg: Streamline cpu policy serialise/deserialise calls

On 23/05/2024 11:21, Roger Pau Monné wrote: > On Thu, May 23, 2024 at 10:41:29AM +0100, Alejandro Vallejo wrote: >> The idea is to use xc_cpu_policy_t as a single object containing both the >> serialised and deserialised forms of the policy. Note that we need lengths >> for the arrays, as the seria

[PATCH v7 1/8] xen: mapcache: Make MCACHE_BUCKET_SHIFT runtime configurable

From: "Edgar E. Iglesias" Make MCACHE_BUCKET_SHIFT runtime configurable per cache instance. Signed-off-by: Edgar E. Iglesias Reviewed-by: Stefano Stabellini --- hw/xen/xen-mapcache.c | 54 ++- 1 file changed, 33 insertions(+), 21 deletions(-) diff --gi

[PATCH v7 3/8] xen: Add xen_mr_is_memory()

From: "Edgar E. Iglesias" Add xen_mr_is_memory() to abstract away tests for the xen_memory MR. No functional changes. Signed-off-by: Edgar E. Iglesias Reviewed-by: Stefano Stabellini Acked-by: David Hildenbrand --- hw/xen/xen-hvm-common.c | 10 -- include/sysemu/xen.h| 8 ++

[PATCH v7 7/8] xen: mapcache: Add support for grant mappings

From: "Edgar E. Iglesias" Add a second mapcache for grant mappings. The mapcache for grants needs to work with XC_PAGE_SIZE granularity since we can't map larger ranges than what has been granted to us. Like with foreign mappings (xen_memory), machines using grants are expected to initialize the

[PATCH v7 2/8] xen: mapcache: Unmap first entries in buckets

From: "Edgar E. Iglesias" When invalidating memory ranges, if we happen to hit the first entry in a bucket we were never unmapping it. This was harmless for foreign mappings but now that we're looking to reuse the mapcache for transient grant mappings, we must unmap entries when invalidated. Sig

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

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. No functional changes. Signed-off-by: Edgar E. Iglesias Reviewed-by: David Hildenbrand Reviewed-by: Stefano Stabellini -

Re: [PATCH v2 1/8] xen/x86: Add initial x2APIC ID to the per-vLAPIC save area

On 23/05/2024 15:32, Roger Pau Monné wrote: >> case 0xb: >> -/* >> - * In principle, this leaf is Intel-only. In practice, it is >> tightly >> - * coupled with x2apic, and we offer an x2apic-capable APIC >> emulation >> - * to guests on AMD hardware as well.

Re: [PATCH v3 1/2] tools/xg: Streamline cpu policy serialise/deserialise calls

On Fri, May 24, 2024 at 11:32:50AM +0100, Alejandro Vallejo wrote: > On 23/05/2024 11:21, Roger Pau Monné wrote: > > On Thu, May 23, 2024 at 10:41:29AM +0100, Alejandro Vallejo wrote: > >> -int xc_cpu_policy_serialise(xc_interface *xch, const xc_cpu_policy_t *p, > >> -xe

[PATCH v11 4/9] xen/riscv: introduce bitops.h

Taken from Linux-6.4.0-rc1 Xen's bitops.h consists of several Linux's headers: * linux/arch/include/asm/bitops.h: * The following function were removed as they aren't used in Xen: * test_and_set_bit_lock * clear_bit_unlock * __clear_bit_unlock * The following functions

[PATCH v11 9/9] xen/README: add compiler and binutils versions for RISC-V64

This patch doesn't represent a strict lower bound for GCC and GNU Binutils; rather, these versions are specifically employed by the Xen RISC-V container and are anticipated to undergo continuous testing. Older GCC and GNU Binutils would work, but this is not a guarantee. While it is feasible to ut

[PATCH v11 1/9] xen/riscv: disable unnecessary configs

Disables unnecessary configs for two cases: 1. By utilizing EXTRA_FIXED_RANDCONFIG for randconfig builds (GitLab CI jobs). 2. By using tiny64_defconfig for non-randconfig builds. Only configs which lead to compilation issues were disabled. Remove lines related to disablement of configs which aren

[PATCH v11 8/9] xen/riscv: enable full Xen build

Signed-off-by: Oleksii Kurochko Reviewed-by: Jan Beulich --- At least this patch cann't be merged w/o Andrew's patch series is merged as ffs related functions are used from that patch series: https://lore.kernel.org/xen-devel/20240313172716.2325427-1-andrew.coop...@citrix.com/T/#t --- Chang

[PATCH v11 5/9] xen/riscv: add definition of __read_mostly

The definition of __read_mostly should be removed in: https://lore.kernel.org/xen-devel/f25eb5c9-7c14-6e23-8535-2c66772b3...@suse.com/ The patch introduces it in arch-specific header to not block enabling of full Xen build for RISC-V. Signed-off-by: Oleksii Kurochko --- - [PATCH] move __read_mos

[PATCH v11 0/9] Enable build of full Xen for RISC-V

This patch series performs all of the additions necessary to drop the build overrides for RISCV and enable the full Xen build. Except in cases where compatibile implementations already exist (e.g. atomic.h and bitops.h), the newly added definitions are simple. The patch series is based on the foll

[PATCH v11 3/9] xen/bitops: implement fls{l}() in common logic

To avoid the compilation error below, it is needed to update to places in common/page_alloc.c where flsl() is used as now flsl() returns unsigned int: ./include/xen/kernel.h:18:21: error: comparison of distinct pointer types lacks a cast [-Werror] 18 | (void) (&_x == &_y);

[PATCH v11 2/9] xen: introduce generic non-atomic test_*bit()

The following generic functions were introduced: * test_bit * generic__test_and_set_bit * generic__test_and_clear_bit * generic__test_and_change_bit These functions and macros can be useful for architectures that don't have corresponding arch-specific instructions. Also, the patch introduces the

[PATCH v11 7/9] xen/riscv: add minimal amount of stubs to build full Xen

Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in V7-V11: - Only rebase was done. --- Changes in V6: - update the commit in stubs.c around /* ... common/irq.c ... */ - add Acked-by: Jan Beulich --- Changes in V5: - drop unrelated changes - assert_failed("unimplmented...")

[PATCH v11 6/9] xen/riscv: add minimal stuff to mm.h to build full Xen

Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in V8-V11: - Nothing changed only rebase. --- Changes in V7: - update argument type of maddr_to_virt() function: unsigned long -> paddr_t - rename argument of PFN_ORDER(): pfn -> pg. - add Acked-by: Jan Beulich --- Changes in

Re: [PATCH v2 1/8] xen/x86: Add initial x2APIC ID to the per-vLAPIC save area

On Fri, May 24, 2024 at 11:58:44AM +0100, Alejandro Vallejo wrote: > On 23/05/2024 15:32, Roger Pau Monné wrote: > >> case 0xb: > >> -/* > >> - * In principle, this leaf is Intel-only. In practice, it is > >> tightly > >> - * coupled with x2apic, and we offer an x2api

Re: [PATCH v2 3/8] x86/vlapic: Move lapic_load_hidden migration checks to the check hook

On 23/05/2024 15:50, Roger Pau Monné wrote: > On Wed, May 08, 2024 at 01:39:22PM +0100, Alejandro Vallejo wrote: >> While at it, add a check for the reserved field in the hidden save area. >> >> Signed-off-by: Alejandro Vallejo >> --- >> v2: >> * New patch. Addresses the missing check for rsvd_z

[RFC for-4.20 v1 1/1] x86/hvm: Introduce Xen-wide ASID Allocator

Currently ASID generation and management is done per-PCPU. This scheme is incompatible with SEV technologies as SEV VMs need to have a fixed ASID associated with all vcpus of the VM throughout it's lifetime. This commit introduces a Xen-wide allocator which initializes the asids at the start of xe

[RFC for-4.20 v1 0/1] x86/hvm: Introduce Xen-wide ASID allocator

Motivation: --- This is part of the effort to enable AMD SEV technologies in Xen. For AMD SEV support, we need a fixed ASID associated with all vcpus of the same domain throughout the domain's lifetime. This is because for SEV/ SEV-{ES,SNP} VM, the ASID is the index which is associated with

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

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. This commits implements a new function p2m_put_l2_superpage to handle 2MB superpages, specifical

[PATCH v4 5/7] xen/arm: Rework heap page allocation outside allocate_bank_memory

The function allocate_bank_memory allocates pages from the heap and maps them to the guest using guest_physmap_add_page. As a preparation work to support static shared memory bank when the host physical address is not provided, Xen needs to allocate memory from the heap, so rework allocate_bank_me

[PATCH v4 7/7] xen/docs: Describe static shared memory when host address is not provided

From: Penny Zheng This commit describe the new scenario where host address is not provided in "xen,shared-mem" property and a new example is added to the page to explain in details. Take the occasion to fix some typos in the page. Signed-off-by: Penny Zheng Signed-off-by: Luca Fancellu Review

[PATCH v4 4/7] xen/arm: Parse xen,shared-mem when host phys address is not provided

Handle the parsing of the 'xen,shared-mem' property when the host physical address is not provided, this commit is introducing the logic to parse it, but the functionality is still not implemented and will be part of future commits. Rework the logic inside process_shm_node to check the shm_id befo

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

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 wrong with it, however the bank can be used also to retrieve the start a

[PATCH v4 0/7] Static shared memory followup v2 - pt2

This serie is a partial rework of this other serie: https://patchwork.kernel.org/project/xen-devel/cover/20231206090623.1932275-1-penny.zh...@arm.com/ The original serie is addressing an issue of the static shared memory feature that impacts the memory footprint of other component when the feature

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

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. Signed-off-by: Luca Fancellu Reviewed-by: Michal Orzel --- v3 cha

[PATCH v4 6/7] xen/arm: Implement the logic for static shared memory from Xen heap

This commit implements the logic to have the static shared memory banks from the Xen heap instead of having the host physical address passed from the user. When the host physical address is not supplied, the physical memory is taken from the Xen heap using allocate_domheap_memory, the allocation n

Re: [PATCH v2 3/8] x86/vlapic: Move lapic_load_hidden migration checks to the check hook

On Fri, May 24, 2024 at 12:16:00PM +0100, Alejandro Vallejo wrote: > On 23/05/2024 15:50, Roger Pau Monné wrote: > > On Wed, May 08, 2024 at 01:39:22PM +0100, Alejandro Vallejo wrote: > >> While at it, add a check for the reserved field in the hidden save area. > >> > >> Signed-off-by: Alejandro Va

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

Hi Luca, On 24/05/2024 13:40, 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. This commits implements a new function p2m

[xen-4.17-testing test] 186129: regressions - FAIL

flight 186129 xen-4.17-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/186129/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 6 kernel-build fail in 186109 REGR. vs. 185864 Tests which ar

Re: [PATCH v15 4/5] xen/arm: translate virtual PCI bus topology for guests

Hi Stewart, On 17/05/2024 18:06, Stewart Hildebrand wrote: From: Oleksandr Andrushchenko There are three originators for the PCI configuration space access: 1. The domain that owns physical host bridge: MMIO handlers are there so we can update vPCI register handlers with the values written by

Re: [PATCH v16 4/5] xen/arm: translate virtual PCI bus topology for guests

Hi, Sorry I didn't notice there was a v16 and posted comments on the v15. The only one is about the size of the list we iterate. On 23/05/2024 08:48, Roger Pau Monné wrote: On Wed, May 22, 2024 at 06:59:23PM -0400, Stewart Hildebrand wrote: From: Oleksandr Andrushchenko There are three or

Re: [PATCH v3] xen/arm: Set correct per-cpu cpu_core_mask

Hi, On 21/05/2024 08:57, Michal Orzel wrote: On 21/05/2024 09:51, Henry Wang wrote: Hi Michal, On 5/21/2024 3:47 PM, Michal Orzel wrote: Hi Henry. On 3/21/2024 11:57 AM, Henry Wang wrote: In the common sysctl command XEN_SYSCTL_physinfo, the value of cores_per_socket is calculated based o

Re: [PATCH for-4.19 v3 2/3] xen: enable altp2m at create domain domctl

On 17.05.24 15:33, Roger Pau Monne wrote: Enabling it using an HVM param is fragile, and complicates the logic when deciding whether options that interact with altp2m can also be enabled. Leave the HVM param value for consumption by the guest, but prevent it from being set. Enabling is now done

[GIT PULL] xen: branch for v6.10-rc1

Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.10a-rc1-tag xen: branch for v6.10-rc1 It contains the following patches: - a small cleanup in the drivers/xen/xenbus Makefile - a fix of the Xen xenstore driver to improve connecti

Re: [PATCH v3 2/4] xen/arm: Alloc XenStore page for Dom0less DomUs from hypervisor

Hi Henry, + Juergen as the Xenstore maintainers. I'd like his opinion on the approach. The documentation of the new logic is in: https://lore.kernel.org/xen-devel/20240517032156.1490515-5-xin.wa...@amd.com/ FWIW I am happy in principle with the logic (this is what we discussed on the call la

Re: [PATCH v3 2/4] xen/arm: Alloc XenStore page for Dom0less DomUs from hypervisor

On 24.05.24 15:58, Julien Grall wrote: Hi Henry, + Juergen as the Xenstore maintainers. I'd like his opinion on the approach. The documentation of the new logic is in: https://lore.kernel.org/xen-devel/20240517032156.1490515-5-xin.wa...@amd.com/ FWIW I am happy in principle with the logic (t

Re: [PATCH v3 2/4] xen/arm: Alloc XenStore page for Dom0less DomUs from hypervisor

On 24.05.24 16:30, Jürgen Groß wrote: On 24.05.24 15:58, Julien Grall wrote: Hi Henry, + Juergen as the Xenstore maintainers. I'd like his opinion on the approach. The documentation of the new logic is in: https://lore.kernel.org/xen-devel/20240517032156.1490515-5-xin.wa...@amd.com/ FWIW I

Re: [PATCH v2 5/8] tools/hvmloader: Retrieve (x2)APIC IDs from the APs themselves

On 24/05/2024 08:21, Roger Pau Monné wrote: > On Wed, May 08, 2024 at 01:39:24PM +0100, Alejandro Vallejo wrote: >> Make it so the APs expose their own APIC IDs in a LUT. We can use that LUT to >> populate the MADT, decoupling the algorithm that relates CPU IDs and APIC IDs >> from hvmloader. >> >>

Re: [PATCH v2 5/8] tools/hvmloader: Retrieve (x2)APIC IDs from the APs themselves

On 23/05/2024 17:13, Roger Pau Monné wrote: > On Wed, May 08, 2024 at 01:39:24PM +0100, Alejandro Vallejo wrote: >> Make it so the APs expose their own APIC IDs in a LUT. We can use that LUT to >> populate the MADT, decoupling the algorithm that relates CPU IDs and APIC IDs >> from hvmloader. >> >>

[xen-unstable-smoke test] 186136: regressions - FAIL

flight 186136 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/186136/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 6 xen-buildfail REGR. vs. 186117 Tests which

Re: [PATCH v2 7/8] xen/x86: Derive topologically correct x2APIC IDs from the policy

On 24/05/2024 09:39, Roger Pau Monné wrote: > On Wed, May 08, 2024 at 01:39:26PM +0100, Alejandro Vallejo wrote: >> Implements the helper for mapping vcpu_id to x2apic_id given a valid >> topology in a policy. The algo is written with the intention of extending >> it to leaves 0x1f and e26 in the f

Re: [PATCH v2 8/8] xen/x86: Synthesise domain topologies

On 24/05/2024 09:58, Roger Pau Monné wrote: > On Wed, May 08, 2024 at 01:39:27PM +0100, Alejandro Vallejo wrote: >> Expose sensible topologies in leaf 0xb. At the moment it synthesises non-HT >> systems, in line with the previous code intent. >> >> Signed-off-by: Alejandro Vallejo >> --- >> v2: >>

Re: [GIT PULL] xen: branch for v6.10-rc1

The pull request you sent on Fri, 24 May 2024 15:37:33 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git > for-linus-6.10a-rc1-tag has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/9351f138d1dcbe504cd829abe590ba7f3387f09c Thank you! -- Deet-doot-dot,

[ovmf test] 186137: all pass - PUSHED

flight 186137 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/186137/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 3e722403cd16388a0e4044e705a2b34c841d76ca baseline version: ovmf 7142e648416ff5d3eac6c

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

flight 186139 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/186139/ 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

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

flight 186132 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/186132/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186078 test-amd64-amd64-xl-qemut-win7-amd64

[PATCH v2 04/13] xen/page_alloc: Coerce min(flsl(), foo) expressions to being unsigned

This is in order to maintain bisectability through the subsequent changes, where flsl() changes sign-ness non-atomically by architecture. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu CC: Stefano Stabellini CC: Julien Grall CC: Volodymyr Babchuk CC: Bertra

[PATCH v2 01/13] ppc/boot: Run constructors on boot

PPC collects constructors, but doesn't run them yet. Do so. They'll shortly be used to confirm correct behaviour of the bitops primitives. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu CC: Stefano Stabellini CC: Julien Grall CC: Volodymyr Babchuk CC: Ber

[PATCH v2 03/13] ARM/bitops: Change find_first_set_bit() to be a define

This is in order to maintain bisectability through the subsequent changes, as the order of definitions is altered. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu CC: Stefano Stabellini CC: Julien Grall CC: Volodymyr Babchuk CC: Bertrand Marquis CC: Michal

[PATCH v2 07/13] x86/bitops: Improve arch_ffs() in the general case

The asm in arch_ffs() is safe but inefficient. CMOV would be an improvement over a conditional branch, but for 64bit CPUs both Intel and AMD have provided enough details about the behaviour for a zero input. It is safe to pre-load the destination register with -1 and drop the conditional logic.

[PATCH v2 10/13] xen/bitops: Delete find_first_set_bit()

No more users. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu CC: Stefano Stabellini CC: Julien Grall CC: Volodymyr Babchuk CC: Bertrand Marquis CC: Michal Orzel CC: Oleksii Kurochko CC: Shawn Anastasio CC: consult...@bugseng.com CC: Simone Ballarin C

[PATCH v2 08/13] xen/bitops: Implement ffsl() in common logic

Just like ffs() in the previous changes. Express the upper bound of the testing in terms of BITS_PER_LONG as it varies between architectures. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu CC: Stefano Stabellini CC: Julien Grall CC: Volodymyr Babchuk CC: B

[PATCH v2 12/13] xen/bitops: Clean up ffs64()/fls64() definitions

Implement ffs64() and fls64() as plain static inlines, dropping the ifdefary and intermediate generic_f?s64() forms. Add tests for all interesting bit positions at 32bit boundaries. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu CC: Ste

[PATCH v2 05/13] xen/bitops: Implement generic_f?sl() in lib/

generic_f?s() being static inline is the cause of lots of the complexity between the common and arch-specific bitops.h They appear to be static inline for constant-folding reasons (ARM uses them for this), but there are better ways to achieve the same effect. It is presumptuous that an unrolled b

[PATCH v2 for-4.19 00/13] xen/bitops: Untangle ffs()/fls() infrastructure

bitops.h is a mess. It has grown organtically over many years, and forces unreasonable repsonsibilities out into the per-arch stubs. Start cleaning it up with ffs() and friends. Across the board, this adds: * Functioning bitops without arch-specific asm * An option for arches to provide more

[PATCH v2 02/13] xen/bitops: Cleanup ahead of rearrangements

* Rename __attribute_pure__ to just __pure before it gains users. * Introduce __constructor which is going to be used in lib/, and is unconditionally cf_check. * Identify the areas of xen/bitops.h which are a mess. * Introduce xen/boot-check.h as helpers for compile and boot time testing.

[PATCH v2 11/13] xen/bitops: Implement fls()/flsl() in common logic

From: Oleksii Kurochko This is most easily done together because of how arm32 is currently structured, but it does just mirror the existing ffs()/ffsl() work. Introduce compile and boot time testing. Signed-off-by: Oleksii Kurochko Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger P

[PATCH v2 06/13] xen/bitops: Implement ffs() in common logic

Perform constant-folding unconditionally, rather than having it implemented inconsistency between architectures. Confirm the expected behaviour with compile time and boot time tests. For non-constant inputs, use arch_ffs() if provided but fall back to generic_ffsl() if not. In particular, RISC-V

[PATCH v2 09/13] xen/bitops: Replace find_first_set_bit() with ffsl() - 1

find_first_set_bit() is a Xen-ism which has undefined behaviour with a 0 input. The latter is well defined with an input of 0, and is a found outside of Xen too. _init_heap_pages() is the one special case here, comparing the LSB of two different addresses. The -1 cancels off both sides of the ex

[PATCH v2 13/13] xen/bitops: Rearrange the top of xen/bitops.h

The #include can move to the top of the file now now that generic_f?s() have been untangled. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu CC: Stefano Stabellini CC: Julien Grall CC: Volodymyr Babchuk CC: Bertrand Marquis CC: Michal Orzel CC: Oleksii Ku

Re: [PATCH v5 3/7] tools/arm: Introduce the "nr_spis" xl config entry

On Fri, 23 May 2024, Julien Grall wrote: > Hi, > > On 24/05/2024 03:18, Stefano Stabellini wrote: > > From: Henry Wang > > > > 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 th

[libvirt test] 186133: tolerable all pass - PUSHED

flight 186133 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/186133/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186070 test-amd64-amd64-libvirt 15 migrate-s

Re: [PATCH v5 5/7] xen/arm: Add XEN_DOMCTL_dt_overlay and device attachment to domains

On Fri, 24 May 2024, Julien Grall wrote: > Hi Stefano, > > On 24/05/2024 03:18, Stefano Stabellini wrote: > > From: Henry Wang > > > > 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

Re: [PATCH v5 6/7] tools: Introduce the "xl dt-overlay attach" command

On Fri, 24 May 2024, Julien Grall wrote: > Hi Stefano, > > On 24/05/2024 03:18, Stefano Stabellini wrote: > > From: Henry Wang > > > > With the XEN_DOMCTL_dt_overlay DOMCTL added, users should be able to > > attach (in the future also detach) devices from the provided DT overlay > > to domains.

Re: [PATCH v5 7/7] docs: Add device tree overlay documentation

On Fri, 24 May 2024, Julien Grall wrote: > Hi Stefano, > > On 24/05/2024 03:18, Stefano Stabellini wrote: > > From: Vikram Garhwal > > > > Signed-off-by: Vikram Garhwal > > Signed-off-by: Stefano Stabellini > > Signed-off-by: Henry Wang > > --- > > docs/misc/arm/overlay.txt | 82 +++

[PATCH v6 0/7] 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 v6 3/7] tools/arm: Introduce the "nr_spis" xl config entry

From: Henry Wang 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 pro

[PATCH v6 4/7] xen/arm/gic: Allow adding interrupt to running VMs

From: Henry Wang Currently, adding physical interrupts are only allowed at the domain creation time. For use cases such as dynamic device tree overlay addition, the adding of physical IRQ to running domains should be allowed. Drop the above-mentioned domain creation check. Since this will introd

[PATCH v6 2/7] xen/arm, doc: Add a DT property to specify IOMMU for Dom0less domUs

From: Henry Wang 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 hav

[PATCH v6 6/7] tools: Introduce the "xl dt-overlay attach" command

From: Henry Wang With the XEN_DOMCTL_dt_overlay DOMCTL added, users should be able to attach (in the future also detach) devices from the provided DT overlay to domains. Support this by introducing a new "xl dt-overlay" command and related documentation, i.e. "xl dt-overlay attach. Slightly rewor

[PATCH v6 1/7] tools/xl: Correct the help information and exit code of the dt-overlay command

From: Henry Wang 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

[PATCH v6 5/7] xen/arm: Add XEN_DOMCTL_dt_overlay and device attachment to domains

From: Henry Wang 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 dev

[PATCH v6 7/7] docs: Add device tree overlay documentation

From: Vikram Garhwal Signed-off-by: Vikram Garhwal Signed-off-by: Stefano Stabellini Signed-off-by: Henry Wang --- docs/misc/arm/overlay.txt | 82 +++ 1 file changed, 82 insertions(+) create mode 100644 docs/misc/arm/overlay.txt diff --git a/docs/misc/arm

Re: [PATCH v3 1/4] xen/arm/static-shmem: Static-shmem should be direct-mapped for direct-mapped domains

On Tue, 21 May 2024, Henry Wang wrote: > Hi Michal, > > On 5/21/2024 12:09 AM, Michal Orzel wrote: > > > > > Thanks. I will take the tag if you are ok with above diff (for the > > > > > case > > > > > if this series goes in later than Luca's). > > > > I would move this check to process_shm() right

Re: [PATCH v3 2/4] xen/arm: Alloc XenStore page for Dom0less DomUs from hypervisor

On Fri, 24 May 2024, Julien Grall wrote: > Hi Henry, > > + Juergen as the Xenstore maintainers. I'd like his opinion on the approach. > The documentation of the new logic is in: > > https://lore.kernel.org/xen-devel/20240517032156.1490515-5-xin.wa...@amd.com/ > > FWIW I am happy in principle wit

Re: [PATCH v3 4/4] docs/features/dom0less: Update the late XenStore init protocol

On Fri, 17 May 2024, Henry Wang wrote: > With the new allocation strategy of Dom0less DomUs XenStore page, > update the doc of the late XenStore init protocol accordingly. > > Signed-off-by: Henry Wang Reviewed-by: Stefano Stabellini > --- > v3: > - Wording change. > v2: > - New patch. > ---

Re: [PATCH v3 3/4] tools/init-dom0less: Avoid hardcoding GUEST_MAGIC_BASE

On Mon, 20 May 2024, Jason Andryuk wrote: > On 2024-05-16 23:21, Henry Wang wrote: > > Currently the GUEST_MAGIC_BASE in the init-dom0less application is > > hardcoded, which will lead to failures for 1:1 direct-mapped Dom0less > > DomUs. > > > > Since the guest magic region allocation from init-d

[PATCH v4 1/4] xen/arm/static-shmem: Static-shmem should be direct-mapped for direct-mapped domains

From: Henry Wang Currently, users are allowed to map static shared memory in a non-direct-mapped way for direct-mapped domains. This can lead to clashing of guest memory spaces. Also, the current extended region finding logic only removes the host physical addresses of the static shared memory ar

[PATCH v4 4/4] docs/features/dom0less: Update the late XenStore init protocol

From: Henry Wang With the new allocation strategy of Dom0less DomUs XenStore page, update the doc of the late XenStore init protocol accordingly. Signed-off-by: Henry Wang --- docs/features/dom0less.pandoc | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/docs/fe

[PATCH v4 0/4] Guest XenStore page allocation for 11 Dom0less domUs

Hi all, This series is trying to fix the reported guest magic region alloc issue for 11 Dom0less domUs, an error message can seen from the init-dom0less application on 1:1 direct-mapped Dom0less DomUs: ``` Allocating magic pages memory.c:238:d0v0 mfn 0x39000 doesn't belong to d1 Error on alloc mag

  1   2   >