* preparations for 4.15.1 and 4.13.4 @ 2021-07-15 7:58 Jan Beulich 2021-07-02 14:29 ` [PATCH-4.15] tools/libs/ctrl: fix xc_core_arch_map_p2m() to support linear p2m table Juergen Gross ` (7 more replies) 0 siblings, 8 replies; 28+ messages in thread From: Jan Beulich @ 2021-07-15 7:58 UTC (permalink / raw) To: xen-devel, Ian Jackson Cc: George Dunlap, Stefano Stabellini, Wei Liu, Anthony Perard, Julien Grall All, the releases are due in a couple of weeks time (and 4.14.3 is supposed to follow another few weeks later). Please point out backports you find missing from the respective staging branches, but which you consider relevant. Please note that 4.13.4 is going to be the last Xen Project coordinated release from the 4.13 branch; the branch will go into security-only maintenance mode after this release. Ian: I did take the liberty to backport Anthony's 5d3e4ebb5c71 libs/foreignmemory: Fix osdep_xenforeignmemory_map prototype Beyond this I'd like the following to be considered: 6409210a5f51 libxencall: osdep_hypercall() should return long bef64f2c0019 libxencall: introduce variant of xencall2() returning long 01a2d001dea2 libxencall: Bump SONAME following new functionality 6f02d1ea4a10 libxc: use multicall for memory-op on Linux (and Solaris) If those are to be taken (which means in particular if the question of the .so versioning can be properly sorted), 198a2bc6f149 x86/HVM: wire up multicalls is going to be required as a prereq. I have backports of all of the above ready (so I could put them in if you tell me to), but for 01a2d001dea2 only in its straightforward but simplistic form, which I'm not sure is the right thing to do. Jan ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH-4.15] tools/libs/ctrl: fix xc_core_arch_map_p2m() to support linear p2m table @ 2021-07-02 14:29 ` Juergen Gross 2021-07-16 6:47 ` Juergen Gross 0 siblings, 1 reply; 28+ messages in thread From: Juergen Gross @ 2021-07-02 14:29 UTC (permalink / raw) To: xen-devel; +Cc: Juergen Gross, Ian Jackson, Wei Liu The core of a pv linux guest produced via "xl dump-core" is not usable as since kernel 4.14 only the linear p2m table is kept if Xen indicates it is supporting that. Unfortunately xc_core_arch_map_p2m() is still supporting the 3-level p2m tree only. Fix that by copying the functionality of map_p2m() from libxenguest to libxenctrl. Additionally the mapped p2m isn't of a fixed length now, so the interface to the mapping functions needs to be adapted. In order not to add even more parameters, expand struct domain_info_context and use a pointer to that as a parameter. This is a backport of upstream commit bd7a29c3d0b937ab542a. As the original patch includes a modification of a data structure passed via pointer to a library function, the related function in the library is renamed in order to be able to spot any external users of that function. Note that it is extremely unlikely any such users outside the Xen git tree are existing, so the risk to break any existing programs is very unlikely. In case such a user is existing, changing the name of xc_map_domain_meminfo() will at least avoid silent breakage. Fixes: dc6d60937121 ("libxc: set flag for support of linear p2m list in domain builder") Signed-off-by: Juergen Gross <jgross@suse.com> --- tools/include/xenguest.h | 2 + tools/libs/ctrl/xc_core.c | 5 +- tools/libs/ctrl/xc_core.h | 8 +- tools/libs/ctrl/xc_core_arm.c | 23 +-- tools/libs/ctrl/xc_core_x86.c | 256 ++++++++++++++++++++++++++++------ tools/libs/ctrl/xc_private.h | 1 + tools/libs/guest/xg_domain.c | 17 +-- 7 files changed, 234 insertions(+), 78 deletions(-) diff --git a/tools/include/xenguest.h b/tools/include/xenguest.h index 217022b6e7..36a26deba4 100644 --- a/tools/include/xenguest.h +++ b/tools/include/xenguest.h @@ -700,8 +700,10 @@ struct xc_domain_meminfo { xen_pfn_t *pfn_type; xen_pfn_t *p2m_table; unsigned long p2m_size; + unsigned int p2m_frames; }; +#define xc_map_domain_meminfo xc_map_domain_meminfo_mod int xc_map_domain_meminfo(xc_interface *xch, uint32_t domid, struct xc_domain_meminfo *minfo); diff --git a/tools/libs/ctrl/xc_core.c b/tools/libs/ctrl/xc_core.c index b47ab2f6d8..9576bec5a3 100644 --- a/tools/libs/ctrl/xc_core.c +++ b/tools/libs/ctrl/xc_core.c @@ -574,8 +574,7 @@ xc_domain_dumpcore_via_callback(xc_interface *xch, goto out; } - sts = xc_core_arch_map_p2m(xch, dinfo->guest_width, &info, live_shinfo, - &p2m, &dinfo->p2m_size); + sts = xc_core_arch_map_p2m(xch, dinfo, &info, live_shinfo, &p2m); if ( sts != 0 ) goto out; @@ -945,7 +944,7 @@ out: if ( memory_map != NULL ) free(memory_map); if ( p2m != NULL ) - munmap(p2m, PAGE_SIZE * P2M_FL_ENTRIES); + munmap(p2m, PAGE_SIZE * dinfo->p2m_frames); if ( p2m_array != NULL ) free(p2m_array); if ( pfn_array != NULL ) diff --git a/tools/libs/ctrl/xc_core.h b/tools/libs/ctrl/xc_core.h index 36fb755da2..8ea1f93a10 100644 --- a/tools/libs/ctrl/xc_core.h +++ b/tools/libs/ctrl/xc_core.h @@ -138,14 +138,14 @@ int xc_core_arch_memory_map_get(xc_interface *xch, xc_dominfo_t *info, shared_info_any_t *live_shinfo, xc_core_memory_map_t **mapp, unsigned int *nr_entries); -int xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, +int xc_core_arch_map_p2m(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info, shared_info_any_t *live_shinfo, - xen_pfn_t **live_p2m, unsigned long *pfnp); + xen_pfn_t **live_p2m); -int xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width, +int xc_core_arch_map_p2m_writable(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info, shared_info_any_t *live_shinfo, - xen_pfn_t **live_p2m, unsigned long *pfnp); + xen_pfn_t **live_p2m); int xc_core_arch_get_scratch_gpfn(xc_interface *xch, uint32_t domid, xen_pfn_t *gpfn); diff --git a/tools/libs/ctrl/xc_core_arm.c b/tools/libs/ctrl/xc_core_arm.c index 7b587b4cc5..93765a565f 100644 --- a/tools/libs/ctrl/xc_core_arm.c +++ b/tools/libs/ctrl/xc_core_arm.c @@ -66,33 +66,24 @@ xc_core_arch_memory_map_get(xc_interface *xch, struct xc_core_arch_context *unus static int xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info, - shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m, - unsigned long *pfnp, int rw) + shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m, int rw) { errno = ENOSYS; return -1; } int -xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info, - shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m, - unsigned long *pfnp) +xc_core_arch_map_p2m(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info, + shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m) { - struct domain_info_context _dinfo = { .guest_width = guest_width }; - struct domain_info_context *dinfo = &_dinfo; - return xc_core_arch_map_p2m_rw(xch, dinfo, info, - live_shinfo, live_p2m, pfnp, 0); + return xc_core_arch_map_p2m_rw(xch, dinfo, info, live_shinfo, live_p2m, 0); } int -xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info, - shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m, - unsigned long *pfnp) +xc_core_arch_map_p2m_writable(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info, + shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m) { - struct domain_info_context _dinfo = { .guest_width = guest_width }; - struct domain_info_context *dinfo = &_dinfo; - return xc_core_arch_map_p2m_rw(xch, dinfo, info, - live_shinfo, live_p2m, pfnp, 1); + return xc_core_arch_map_p2m_rw(xch, dinfo, info, live_shinfo, live_p2m, 1); } int diff --git a/tools/libs/ctrl/xc_core_x86.c b/tools/libs/ctrl/xc_core_x86.c index cb76e6207b..c8f71d4b75 100644 --- a/tools/libs/ctrl/xc_core_x86.c +++ b/tools/libs/ctrl/xc_core_x86.c @@ -17,6 +17,7 @@ * */ +#include <inttypes.h> #include "xc_private.h" #include "xc_core.h" #include <xen/hvm/e820.h> @@ -65,34 +66,169 @@ xc_core_arch_memory_map_get(xc_interface *xch, struct xc_core_arch_context *unus return 0; } -static int -xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info, - shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m, - unsigned long *pfnp, int rw) +static inline bool is_canonical_address(uint64_t vaddr) { - /* Double and single indirect references to the live P2M table */ - xen_pfn_t *live_p2m_frame_list_list = NULL; - xen_pfn_t *live_p2m_frame_list = NULL; - /* Copies of the above. */ - xen_pfn_t *p2m_frame_list_list = NULL; - xen_pfn_t *p2m_frame_list = NULL; + return ((int64_t)vaddr >> 47) == ((int64_t)vaddr >> 63); +} - uint32_t dom = info->domid; - int ret = -1; - int err; - int i; +/* Virtual address ranges reserved for hypervisor. */ +#define HYPERVISOR_VIRT_START_X86_64 0xFFFF800000000000ULL +#define HYPERVISOR_VIRT_END_X86_64 0xFFFF87FFFFFFFFFFULL - if ( xc_domain_nr_gpfns(xch, info->domid, &dinfo->p2m_size) < 0 ) +#define HYPERVISOR_VIRT_START_X86_32 0x00000000F5800000ULL +#define HYPERVISOR_VIRT_END_X86_32 0x00000000FFFFFFFFULL + +static xen_pfn_t * +xc_core_arch_map_p2m_list_rw(xc_interface *xch, struct domain_info_context *dinfo, + uint32_t dom, shared_info_any_t *live_shinfo, + uint64_t p2m_cr3) +{ + uint64_t p2m_vaddr, p2m_end, mask, off; + xen_pfn_t p2m_mfn, mfn, saved_mfn, max_pfn; + uint64_t *ptes = NULL; + xen_pfn_t *mfns = NULL; + unsigned int fpp, n_pages, level, n_levels, shift, + idx_start, idx_end, idx, saved_idx; + + p2m_vaddr = GET_FIELD(live_shinfo, arch.p2m_vaddr, dinfo->guest_width); + fpp = PAGE_SIZE / dinfo->guest_width; + dinfo->p2m_frames = (dinfo->p2m_size - 1) / fpp + 1; + p2m_end = p2m_vaddr + dinfo->p2m_frames * PAGE_SIZE - 1; + + if ( dinfo->guest_width == 8 ) { - ERROR("Could not get maximum GPFN!"); - goto out; + mask = 0x0000ffffffffffffULL; + n_levels = 4; + p2m_mfn = p2m_cr3 >> 12; + if ( !is_canonical_address(p2m_vaddr) || + !is_canonical_address(p2m_end) || + p2m_end < p2m_vaddr || + (p2m_vaddr <= HYPERVISOR_VIRT_END_X86_64 && + p2m_end > HYPERVISOR_VIRT_START_X86_64) ) + { + ERROR("Bad virtual p2m address range %#" PRIx64 "-%#" PRIx64, + p2m_vaddr, p2m_end); + errno = ERANGE; + goto out; + } + } + else + { + mask = 0x00000000ffffffffULL; + n_levels = 3; + if ( p2m_cr3 & ~mask ) + p2m_mfn = ~0UL; + else + p2m_mfn = (uint32_t)((p2m_cr3 >> 12) | (p2m_cr3 << 20)); + if ( p2m_vaddr > mask || p2m_end > mask || p2m_end < p2m_vaddr || + (p2m_vaddr <= HYPERVISOR_VIRT_END_X86_32 && + p2m_end > HYPERVISOR_VIRT_START_X86_32) ) + { + ERROR("Bad virtual p2m address range %#" PRIx64 "-%#" PRIx64, + p2m_vaddr, p2m_end); + errno = ERANGE; + goto out; + } } - if ( dinfo->p2m_size < info->nr_pages ) + mfns = malloc(sizeof(*mfns)); + if ( !mfns ) { - ERROR("p2m_size < nr_pages -1 (%lx < %lx", dinfo->p2m_size, info->nr_pages - 1); + ERROR("Cannot allocate memory for array of %u mfns", 1); goto out; } + mfns[0] = p2m_mfn; + off = 0; + saved_mfn = 0; + idx_start = idx_end = saved_idx = 0; + + for ( level = n_levels; level > 0; level-- ) + { + n_pages = idx_end - idx_start + 1; + ptes = xc_map_foreign_pages(xch, dom, PROT_READ, mfns, n_pages); + if ( !ptes ) + { + PERROR("Failed to map %u page table pages for p2m list", n_pages); + goto out; + } + free(mfns); + + shift = level * 9 + 3; + idx_start = ((p2m_vaddr - off) & mask) >> shift; + idx_end = ((p2m_end - off) & mask) >> shift; + idx = idx_end - idx_start + 1; + mfns = malloc(sizeof(*mfns) * idx); + if ( !mfns ) + { + ERROR("Cannot allocate memory for array of %u mfns", idx); + goto out; + } + + for ( idx = idx_start; idx <= idx_end; idx++ ) + { + mfn = (ptes[idx] & 0x000ffffffffff000ULL) >> PAGE_SHIFT; + if ( mfn == 0 ) + { + ERROR("Bad mfn %#lx during page table walk for vaddr %#" PRIx64 " at level %d of p2m list", + mfn, off + ((uint64_t)idx << shift), level); + errno = ERANGE; + goto out; + } + mfns[idx - idx_start] = mfn; + + /* Maximum pfn check at level 2. Same reasoning as for p2m tree. */ + if ( level == 2 ) + { + if ( mfn != saved_mfn ) + { + saved_mfn = mfn; + saved_idx = idx - idx_start; + } + } + } + + if ( level == 2 ) + { + if ( saved_idx == idx_end ) + saved_idx++; + max_pfn = ((xen_pfn_t)saved_idx << 9) * fpp; + if ( max_pfn < dinfo->p2m_size ) + { + dinfo->p2m_size = max_pfn; + dinfo->p2m_frames = (dinfo->p2m_size + fpp - 1) / fpp; + p2m_end = p2m_vaddr + dinfo->p2m_frames * PAGE_SIZE - 1; + idx_end = idx_start + saved_idx; + } + } + + munmap(ptes, n_pages * PAGE_SIZE); + ptes = NULL; + off = p2m_vaddr & ((mask >> shift) << shift); + } + + return mfns; + + out: + free(mfns); + if ( ptes ) + munmap(ptes, n_pages * PAGE_SIZE); + + return NULL; +} + +static xen_pfn_t * +xc_core_arch_map_p2m_tree_rw(xc_interface *xch, struct domain_info_context *dinfo, + uint32_t dom, shared_info_any_t *live_shinfo) +{ + /* Double and single indirect references to the live P2M table */ + xen_pfn_t *live_p2m_frame_list_list; + xen_pfn_t *live_p2m_frame_list = NULL; + /* Copies of the above. */ + xen_pfn_t *p2m_frame_list_list = NULL; + xen_pfn_t *p2m_frame_list; + + int err; + int i; live_p2m_frame_list_list = xc_map_foreign_range(xch, dom, PAGE_SIZE, PROT_READ, @@ -151,10 +287,60 @@ xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context *dinfo, xc for ( i = P2M_FL_ENTRIES - 1; i >= 0; i-- ) p2m_frame_list[i] = ((uint32_t *)p2m_frame_list)[i]; + dinfo->p2m_frames = P2M_FL_ENTRIES; + + return p2m_frame_list; + + out: + err = errno; + + if ( live_p2m_frame_list_list ) + munmap(live_p2m_frame_list_list, PAGE_SIZE); + + if ( live_p2m_frame_list ) + munmap(live_p2m_frame_list, P2M_FLL_ENTRIES * PAGE_SIZE); + + free(p2m_frame_list_list); + + errno = err; + + return NULL; +} + +static int +xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info, + shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m, int rw) +{ + xen_pfn_t *p2m_frame_list = NULL; + uint64_t p2m_cr3; + uint32_t dom = info->domid; + int ret = -1; + int err; + + if ( xc_domain_nr_gpfns(xch, info->domid, &dinfo->p2m_size) < 0 ) + { + ERROR("Could not get maximum GPFN!"); + goto out; + } + + if ( dinfo->p2m_size < info->nr_pages ) + { + ERROR("p2m_size < nr_pages -1 (%lx < %lx", dinfo->p2m_size, info->nr_pages - 1); + goto out; + } + + p2m_cr3 = GET_FIELD(live_shinfo, arch.p2m_cr3, dinfo->guest_width); + + p2m_frame_list = p2m_cr3 ? xc_core_arch_map_p2m_list_rw(xch, dinfo, dom, live_shinfo, p2m_cr3) + : xc_core_arch_map_p2m_tree_rw(xch, dinfo, dom, live_shinfo); + + if ( !p2m_frame_list ) + goto out; + *live_p2m = xc_map_foreign_pages(xch, dom, rw ? (PROT_READ | PROT_WRITE) : PROT_READ, p2m_frame_list, - P2M_FL_ENTRIES); + dinfo->p2m_frames); if ( !*live_p2m ) { @@ -162,21 +348,11 @@ xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context *dinfo, xc goto out; } - *pfnp = dinfo->p2m_size; - ret = 0; out: err = errno; - if ( live_p2m_frame_list_list ) - munmap(live_p2m_frame_list_list, PAGE_SIZE); - - if ( live_p2m_frame_list ) - munmap(live_p2m_frame_list, P2M_FLL_ENTRIES * PAGE_SIZE); - - free(p2m_frame_list_list); - free(p2m_frame_list); errno = err; @@ -184,25 +360,17 @@ out: } int -xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info, - shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m, - unsigned long *pfnp) +xc_core_arch_map_p2m(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info, + shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m) { - struct domain_info_context _dinfo = { .guest_width = guest_width }; - struct domain_info_context *dinfo = &_dinfo; - return xc_core_arch_map_p2m_rw(xch, dinfo, info, - live_shinfo, live_p2m, pfnp, 0); + return xc_core_arch_map_p2m_rw(xch, dinfo, info, live_shinfo, live_p2m, 0); } int -xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info, - shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m, - unsigned long *pfnp) +xc_core_arch_map_p2m_writable(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info, + shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m) { - struct domain_info_context _dinfo = { .guest_width = guest_width }; - struct domain_info_context *dinfo = &_dinfo; - return xc_core_arch_map_p2m_rw(xch, dinfo, info, - live_shinfo, live_p2m, pfnp, 1); + return xc_core_arch_map_p2m_rw(xch, dinfo, info, live_shinfo, live_p2m, 1); } int diff --git a/tools/libs/ctrl/xc_private.h b/tools/libs/ctrl/xc_private.h index f0b5f83ac8..8ebc0b59da 100644 --- a/tools/libs/ctrl/xc_private.h +++ b/tools/libs/ctrl/xc_private.h @@ -79,6 +79,7 @@ struct iovec { struct domain_info_context { unsigned int guest_width; + unsigned int p2m_frames; unsigned long p2m_size; }; diff --git a/tools/libs/guest/xg_domain.c b/tools/libs/guest/xg_domain.c index 5019c84e0e..dd7db2cbd8 100644 --- a/tools/libs/guest/xg_domain.c +++ b/tools/libs/guest/xg_domain.c @@ -24,13 +24,9 @@ int xc_unmap_domain_meminfo(xc_interface *xch, struct xc_domain_meminfo *minfo) { - struct domain_info_context _di = { .guest_width = minfo->guest_width, - .p2m_size = minfo->p2m_size}; - struct domain_info_context *dinfo = &_di; - free(minfo->pfn_type); if ( minfo->p2m_table ) - munmap(minfo->p2m_table, P2M_FL_ENTRIES * PAGE_SIZE); + munmap(minfo->p2m_table, minfo->p2m_frames * PAGE_SIZE); minfo->p2m_table = NULL; return 0; @@ -40,7 +36,6 @@ int xc_map_domain_meminfo(xc_interface *xch, uint32_t domid, struct xc_domain_meminfo *minfo) { struct domain_info_context _di; - struct domain_info_context *dinfo = &_di; xc_dominfo_t info; shared_info_any_t *live_shinfo; @@ -96,16 +91,16 @@ int xc_map_domain_meminfo(xc_interface *xch, uint32_t domid, return -1; } - if ( xc_core_arch_map_p2m_writable(xch, minfo->guest_width, &info, - live_shinfo, &minfo->p2m_table, - &minfo->p2m_size) ) + if ( xc_core_arch_map_p2m_writable(xch, &_di, &info, + live_shinfo, &minfo->p2m_table) ) { PERROR("Could not map the P2M table"); munmap(live_shinfo, PAGE_SIZE); return -1; } munmap(live_shinfo, PAGE_SIZE); - _di.p2m_size = minfo->p2m_size; + minfo->p2m_size = _di.p2m_size; + minfo->p2m_frames = _di.p2m_frames; /* Make space and prepare for getting the PFN types */ minfo->pfn_type = calloc(sizeof(*minfo->pfn_type), minfo->p2m_size); @@ -141,7 +136,7 @@ failed: } if ( minfo->p2m_table ) { - munmap(minfo->p2m_table, P2M_FL_ENTRIES * PAGE_SIZE); + munmap(minfo->p2m_table, minfo->p2m_frames * PAGE_SIZE); minfo->p2m_table = NULL; } -- 2.26.2 ^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: [PATCH-4.15] tools/libs/ctrl: fix xc_core_arch_map_p2m() to support linear p2m table 2021-07-02 14:29 ` [PATCH-4.15] tools/libs/ctrl: fix xc_core_arch_map_p2m() to support linear p2m table Juergen Gross @ 2021-07-16 6:47 ` Juergen Gross 2021-08-19 7:45 ` Juergen Gross 2021-08-19 15:44 ` preparations for 4.15.1 and 4.13.4 support linear p2m table [and 1 more messages] Ian Jackson 0 siblings, 2 replies; 28+ messages in thread From: Juergen Gross @ 2021-07-16 6:47 UTC (permalink / raw) To: xen-devel, Ian Jackson; +Cc: Wei Liu, Jan Beulich [-- Attachment #1.1.1: Type: text/plain, Size: 21366 bytes --] Ping? On 02.07.21 16:29, Juergen Gross wrote: > The core of a pv linux guest produced via "xl dump-core" is not usable > as since kernel 4.14 only the linear p2m table is kept if Xen indicates > it is supporting that. Unfortunately xc_core_arch_map_p2m() is still > supporting the 3-level p2m tree only. > > Fix that by copying the functionality of map_p2m() from libxenguest to > libxenctrl. > > Additionally the mapped p2m isn't of a fixed length now, so the > interface to the mapping functions needs to be adapted. In order not to > add even more parameters, expand struct domain_info_context and use a > pointer to that as a parameter. > > This is a backport of upstream commit bd7a29c3d0b937ab542a. > > As the original patch includes a modification of a data structure > passed via pointer to a library function, the related function in the > library is renamed in order to be able to spot any external users of > that function. Note that it is extremely unlikely any such users > outside the Xen git tree are existing, so the risk to break any > existing programs is very unlikely. In case such a user is existing, > changing the name of xc_map_domain_meminfo() will at least avoid > silent breakage. > > Fixes: dc6d60937121 ("libxc: set flag for support of linear p2m list in domain builder") > Signed-off-by: Juergen Gross <jgross@suse.com> > --- > tools/include/xenguest.h | 2 + > tools/libs/ctrl/xc_core.c | 5 +- > tools/libs/ctrl/xc_core.h | 8 +- > tools/libs/ctrl/xc_core_arm.c | 23 +-- > tools/libs/ctrl/xc_core_x86.c | 256 ++++++++++++++++++++++++++++------ > tools/libs/ctrl/xc_private.h | 1 + > tools/libs/guest/xg_domain.c | 17 +-- > 7 files changed, 234 insertions(+), 78 deletions(-) > > diff --git a/tools/include/xenguest.h b/tools/include/xenguest.h > index 217022b6e7..36a26deba4 100644 > --- a/tools/include/xenguest.h > +++ b/tools/include/xenguest.h > @@ -700,8 +700,10 @@ struct xc_domain_meminfo { > xen_pfn_t *pfn_type; > xen_pfn_t *p2m_table; > unsigned long p2m_size; > + unsigned int p2m_frames; > }; > > +#define xc_map_domain_meminfo xc_map_domain_meminfo_mod > int xc_map_domain_meminfo(xc_interface *xch, uint32_t domid, > struct xc_domain_meminfo *minfo); > > diff --git a/tools/libs/ctrl/xc_core.c b/tools/libs/ctrl/xc_core.c > index b47ab2f6d8..9576bec5a3 100644 > --- a/tools/libs/ctrl/xc_core.c > +++ b/tools/libs/ctrl/xc_core.c > @@ -574,8 +574,7 @@ xc_domain_dumpcore_via_callback(xc_interface *xch, > goto out; > } > > - sts = xc_core_arch_map_p2m(xch, dinfo->guest_width, &info, live_shinfo, > - &p2m, &dinfo->p2m_size); > + sts = xc_core_arch_map_p2m(xch, dinfo, &info, live_shinfo, &p2m); > if ( sts != 0 ) > goto out; > > @@ -945,7 +944,7 @@ out: > if ( memory_map != NULL ) > free(memory_map); > if ( p2m != NULL ) > - munmap(p2m, PAGE_SIZE * P2M_FL_ENTRIES); > + munmap(p2m, PAGE_SIZE * dinfo->p2m_frames); > if ( p2m_array != NULL ) > free(p2m_array); > if ( pfn_array != NULL ) > diff --git a/tools/libs/ctrl/xc_core.h b/tools/libs/ctrl/xc_core.h > index 36fb755da2..8ea1f93a10 100644 > --- a/tools/libs/ctrl/xc_core.h > +++ b/tools/libs/ctrl/xc_core.h > @@ -138,14 +138,14 @@ int xc_core_arch_memory_map_get(xc_interface *xch, > xc_dominfo_t *info, shared_info_any_t *live_shinfo, > xc_core_memory_map_t **mapp, > unsigned int *nr_entries); > -int xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, > +int xc_core_arch_map_p2m(xc_interface *xch, struct domain_info_context *dinfo, > xc_dominfo_t *info, shared_info_any_t *live_shinfo, > - xen_pfn_t **live_p2m, unsigned long *pfnp); > + xen_pfn_t **live_p2m); > > -int xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width, > +int xc_core_arch_map_p2m_writable(xc_interface *xch, struct domain_info_context *dinfo, > xc_dominfo_t *info, > shared_info_any_t *live_shinfo, > - xen_pfn_t **live_p2m, unsigned long *pfnp); > + xen_pfn_t **live_p2m); > > int xc_core_arch_get_scratch_gpfn(xc_interface *xch, uint32_t domid, > xen_pfn_t *gpfn); > diff --git a/tools/libs/ctrl/xc_core_arm.c b/tools/libs/ctrl/xc_core_arm.c > index 7b587b4cc5..93765a565f 100644 > --- a/tools/libs/ctrl/xc_core_arm.c > +++ b/tools/libs/ctrl/xc_core_arm.c > @@ -66,33 +66,24 @@ xc_core_arch_memory_map_get(xc_interface *xch, struct xc_core_arch_context *unus > > static int > xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info, > - shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m, > - unsigned long *pfnp, int rw) > + shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m, int rw) > { > errno = ENOSYS; > return -1; > } > > int > -xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info, > - shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m, > - unsigned long *pfnp) > +xc_core_arch_map_p2m(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info, > + shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m) > { > - struct domain_info_context _dinfo = { .guest_width = guest_width }; > - struct domain_info_context *dinfo = &_dinfo; > - return xc_core_arch_map_p2m_rw(xch, dinfo, info, > - live_shinfo, live_p2m, pfnp, 0); > + return xc_core_arch_map_p2m_rw(xch, dinfo, info, live_shinfo, live_p2m, 0); > } > > int > -xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info, > - shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m, > - unsigned long *pfnp) > +xc_core_arch_map_p2m_writable(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info, > + shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m) > { > - struct domain_info_context _dinfo = { .guest_width = guest_width }; > - struct domain_info_context *dinfo = &_dinfo; > - return xc_core_arch_map_p2m_rw(xch, dinfo, info, > - live_shinfo, live_p2m, pfnp, 1); > + return xc_core_arch_map_p2m_rw(xch, dinfo, info, live_shinfo, live_p2m, 1); > } > > int > diff --git a/tools/libs/ctrl/xc_core_x86.c b/tools/libs/ctrl/xc_core_x86.c > index cb76e6207b..c8f71d4b75 100644 > --- a/tools/libs/ctrl/xc_core_x86.c > +++ b/tools/libs/ctrl/xc_core_x86.c > @@ -17,6 +17,7 @@ > * > */ > > +#include <inttypes.h> > #include "xc_private.h" > #include "xc_core.h" > #include <xen/hvm/e820.h> > @@ -65,34 +66,169 @@ xc_core_arch_memory_map_get(xc_interface *xch, struct xc_core_arch_context *unus > return 0; > } > > -static int > -xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info, > - shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m, > - unsigned long *pfnp, int rw) > +static inline bool is_canonical_address(uint64_t vaddr) > { > - /* Double and single indirect references to the live P2M table */ > - xen_pfn_t *live_p2m_frame_list_list = NULL; > - xen_pfn_t *live_p2m_frame_list = NULL; > - /* Copies of the above. */ > - xen_pfn_t *p2m_frame_list_list = NULL; > - xen_pfn_t *p2m_frame_list = NULL; > + return ((int64_t)vaddr >> 47) == ((int64_t)vaddr >> 63); > +} > > - uint32_t dom = info->domid; > - int ret = -1; > - int err; > - int i; > +/* Virtual address ranges reserved for hypervisor. */ > +#define HYPERVISOR_VIRT_START_X86_64 0xFFFF800000000000ULL > +#define HYPERVISOR_VIRT_END_X86_64 0xFFFF87FFFFFFFFFFULL > > - if ( xc_domain_nr_gpfns(xch, info->domid, &dinfo->p2m_size) < 0 ) > +#define HYPERVISOR_VIRT_START_X86_32 0x00000000F5800000ULL > +#define HYPERVISOR_VIRT_END_X86_32 0x00000000FFFFFFFFULL > + > +static xen_pfn_t * > +xc_core_arch_map_p2m_list_rw(xc_interface *xch, struct domain_info_context *dinfo, > + uint32_t dom, shared_info_any_t *live_shinfo, > + uint64_t p2m_cr3) > +{ > + uint64_t p2m_vaddr, p2m_end, mask, off; > + xen_pfn_t p2m_mfn, mfn, saved_mfn, max_pfn; > + uint64_t *ptes = NULL; > + xen_pfn_t *mfns = NULL; > + unsigned int fpp, n_pages, level, n_levels, shift, > + idx_start, idx_end, idx, saved_idx; > + > + p2m_vaddr = GET_FIELD(live_shinfo, arch.p2m_vaddr, dinfo->guest_width); > + fpp = PAGE_SIZE / dinfo->guest_width; > + dinfo->p2m_frames = (dinfo->p2m_size - 1) / fpp + 1; > + p2m_end = p2m_vaddr + dinfo->p2m_frames * PAGE_SIZE - 1; > + > + if ( dinfo->guest_width == 8 ) > { > - ERROR("Could not get maximum GPFN!"); > - goto out; > + mask = 0x0000ffffffffffffULL; > + n_levels = 4; > + p2m_mfn = p2m_cr3 >> 12; > + if ( !is_canonical_address(p2m_vaddr) || > + !is_canonical_address(p2m_end) || > + p2m_end < p2m_vaddr || > + (p2m_vaddr <= HYPERVISOR_VIRT_END_X86_64 && > + p2m_end > HYPERVISOR_VIRT_START_X86_64) ) > + { > + ERROR("Bad virtual p2m address range %#" PRIx64 "-%#" PRIx64, > + p2m_vaddr, p2m_end); > + errno = ERANGE; > + goto out; > + } > + } > + else > + { > + mask = 0x00000000ffffffffULL; > + n_levels = 3; > + if ( p2m_cr3 & ~mask ) > + p2m_mfn = ~0UL; > + else > + p2m_mfn = (uint32_t)((p2m_cr3 >> 12) | (p2m_cr3 << 20)); > + if ( p2m_vaddr > mask || p2m_end > mask || p2m_end < p2m_vaddr || > + (p2m_vaddr <= HYPERVISOR_VIRT_END_X86_32 && > + p2m_end > HYPERVISOR_VIRT_START_X86_32) ) > + { > + ERROR("Bad virtual p2m address range %#" PRIx64 "-%#" PRIx64, > + p2m_vaddr, p2m_end); > + errno = ERANGE; > + goto out; > + } > } > > - if ( dinfo->p2m_size < info->nr_pages ) > + mfns = malloc(sizeof(*mfns)); > + if ( !mfns ) > { > - ERROR("p2m_size < nr_pages -1 (%lx < %lx", dinfo->p2m_size, info->nr_pages - 1); > + ERROR("Cannot allocate memory for array of %u mfns", 1); > goto out; > } > + mfns[0] = p2m_mfn; > + off = 0; > + saved_mfn = 0; > + idx_start = idx_end = saved_idx = 0; > + > + for ( level = n_levels; level > 0; level-- ) > + { > + n_pages = idx_end - idx_start + 1; > + ptes = xc_map_foreign_pages(xch, dom, PROT_READ, mfns, n_pages); > + if ( !ptes ) > + { > + PERROR("Failed to map %u page table pages for p2m list", n_pages); > + goto out; > + } > + free(mfns); > + > + shift = level * 9 + 3; > + idx_start = ((p2m_vaddr - off) & mask) >> shift; > + idx_end = ((p2m_end - off) & mask) >> shift; > + idx = idx_end - idx_start + 1; > + mfns = malloc(sizeof(*mfns) * idx); > + if ( !mfns ) > + { > + ERROR("Cannot allocate memory for array of %u mfns", idx); > + goto out; > + } > + > + for ( idx = idx_start; idx <= idx_end; idx++ ) > + { > + mfn = (ptes[idx] & 0x000ffffffffff000ULL) >> PAGE_SHIFT; > + if ( mfn == 0 ) > + { > + ERROR("Bad mfn %#lx during page table walk for vaddr %#" PRIx64 " at level %d of p2m list", > + mfn, off + ((uint64_t)idx << shift), level); > + errno = ERANGE; > + goto out; > + } > + mfns[idx - idx_start] = mfn; > + > + /* Maximum pfn check at level 2. Same reasoning as for p2m tree. */ > + if ( level == 2 ) > + { > + if ( mfn != saved_mfn ) > + { > + saved_mfn = mfn; > + saved_idx = idx - idx_start; > + } > + } > + } > + > + if ( level == 2 ) > + { > + if ( saved_idx == idx_end ) > + saved_idx++; > + max_pfn = ((xen_pfn_t)saved_idx << 9) * fpp; > + if ( max_pfn < dinfo->p2m_size ) > + { > + dinfo->p2m_size = max_pfn; > + dinfo->p2m_frames = (dinfo->p2m_size + fpp - 1) / fpp; > + p2m_end = p2m_vaddr + dinfo->p2m_frames * PAGE_SIZE - 1; > + idx_end = idx_start + saved_idx; > + } > + } > + > + munmap(ptes, n_pages * PAGE_SIZE); > + ptes = NULL; > + off = p2m_vaddr & ((mask >> shift) << shift); > + } > + > + return mfns; > + > + out: > + free(mfns); > + if ( ptes ) > + munmap(ptes, n_pages * PAGE_SIZE); > + > + return NULL; > +} > + > +static xen_pfn_t * > +xc_core_arch_map_p2m_tree_rw(xc_interface *xch, struct domain_info_context *dinfo, > + uint32_t dom, shared_info_any_t *live_shinfo) > +{ > + /* Double and single indirect references to the live P2M table */ > + xen_pfn_t *live_p2m_frame_list_list; > + xen_pfn_t *live_p2m_frame_list = NULL; > + /* Copies of the above. */ > + xen_pfn_t *p2m_frame_list_list = NULL; > + xen_pfn_t *p2m_frame_list; > + > + int err; > + int i; > > live_p2m_frame_list_list = > xc_map_foreign_range(xch, dom, PAGE_SIZE, PROT_READ, > @@ -151,10 +287,60 @@ xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context *dinfo, xc > for ( i = P2M_FL_ENTRIES - 1; i >= 0; i-- ) > p2m_frame_list[i] = ((uint32_t *)p2m_frame_list)[i]; > > + dinfo->p2m_frames = P2M_FL_ENTRIES; > + > + return p2m_frame_list; > + > + out: > + err = errno; > + > + if ( live_p2m_frame_list_list ) > + munmap(live_p2m_frame_list_list, PAGE_SIZE); > + > + if ( live_p2m_frame_list ) > + munmap(live_p2m_frame_list, P2M_FLL_ENTRIES * PAGE_SIZE); > + > + free(p2m_frame_list_list); > + > + errno = err; > + > + return NULL; > +} > + > +static int > +xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info, > + shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m, int rw) > +{ > + xen_pfn_t *p2m_frame_list = NULL; > + uint64_t p2m_cr3; > + uint32_t dom = info->domid; > + int ret = -1; > + int err; > + > + if ( xc_domain_nr_gpfns(xch, info->domid, &dinfo->p2m_size) < 0 ) > + { > + ERROR("Could not get maximum GPFN!"); > + goto out; > + } > + > + if ( dinfo->p2m_size < info->nr_pages ) > + { > + ERROR("p2m_size < nr_pages -1 (%lx < %lx", dinfo->p2m_size, info->nr_pages - 1); > + goto out; > + } > + > + p2m_cr3 = GET_FIELD(live_shinfo, arch.p2m_cr3, dinfo->guest_width); > + > + p2m_frame_list = p2m_cr3 ? xc_core_arch_map_p2m_list_rw(xch, dinfo, dom, live_shinfo, p2m_cr3) > + : xc_core_arch_map_p2m_tree_rw(xch, dinfo, dom, live_shinfo); > + > + if ( !p2m_frame_list ) > + goto out; > + > *live_p2m = xc_map_foreign_pages(xch, dom, > rw ? (PROT_READ | PROT_WRITE) : PROT_READ, > p2m_frame_list, > - P2M_FL_ENTRIES); > + dinfo->p2m_frames); > > if ( !*live_p2m ) > { > @@ -162,21 +348,11 @@ xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context *dinfo, xc > goto out; > } > > - *pfnp = dinfo->p2m_size; > - > ret = 0; > > out: > err = errno; > > - if ( live_p2m_frame_list_list ) > - munmap(live_p2m_frame_list_list, PAGE_SIZE); > - > - if ( live_p2m_frame_list ) > - munmap(live_p2m_frame_list, P2M_FLL_ENTRIES * PAGE_SIZE); > - > - free(p2m_frame_list_list); > - > free(p2m_frame_list); > > errno = err; > @@ -184,25 +360,17 @@ out: > } > > int > -xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info, > - shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m, > - unsigned long *pfnp) > +xc_core_arch_map_p2m(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info, > + shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m) > { > - struct domain_info_context _dinfo = { .guest_width = guest_width }; > - struct domain_info_context *dinfo = &_dinfo; > - return xc_core_arch_map_p2m_rw(xch, dinfo, info, > - live_shinfo, live_p2m, pfnp, 0); > + return xc_core_arch_map_p2m_rw(xch, dinfo, info, live_shinfo, live_p2m, 0); > } > > int > -xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info, > - shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m, > - unsigned long *pfnp) > +xc_core_arch_map_p2m_writable(xc_interface *xch, struct domain_info_context *dinfo, xc_dominfo_t *info, > + shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m) > { > - struct domain_info_context _dinfo = { .guest_width = guest_width }; > - struct domain_info_context *dinfo = &_dinfo; > - return xc_core_arch_map_p2m_rw(xch, dinfo, info, > - live_shinfo, live_p2m, pfnp, 1); > + return xc_core_arch_map_p2m_rw(xch, dinfo, info, live_shinfo, live_p2m, 1); > } > > int > diff --git a/tools/libs/ctrl/xc_private.h b/tools/libs/ctrl/xc_private.h > index f0b5f83ac8..8ebc0b59da 100644 > --- a/tools/libs/ctrl/xc_private.h > +++ b/tools/libs/ctrl/xc_private.h > @@ -79,6 +79,7 @@ struct iovec { > > struct domain_info_context { > unsigned int guest_width; > + unsigned int p2m_frames; > unsigned long p2m_size; > }; > > diff --git a/tools/libs/guest/xg_domain.c b/tools/libs/guest/xg_domain.c > index 5019c84e0e..dd7db2cbd8 100644 > --- a/tools/libs/guest/xg_domain.c > +++ b/tools/libs/guest/xg_domain.c > @@ -24,13 +24,9 @@ > > int xc_unmap_domain_meminfo(xc_interface *xch, struct xc_domain_meminfo *minfo) > { > - struct domain_info_context _di = { .guest_width = minfo->guest_width, > - .p2m_size = minfo->p2m_size}; > - struct domain_info_context *dinfo = &_di; > - > free(minfo->pfn_type); > if ( minfo->p2m_table ) > - munmap(minfo->p2m_table, P2M_FL_ENTRIES * PAGE_SIZE); > + munmap(minfo->p2m_table, minfo->p2m_frames * PAGE_SIZE); > minfo->p2m_table = NULL; > > return 0; > @@ -40,7 +36,6 @@ int xc_map_domain_meminfo(xc_interface *xch, uint32_t domid, > struct xc_domain_meminfo *minfo) > { > struct domain_info_context _di; > - struct domain_info_context *dinfo = &_di; > > xc_dominfo_t info; > shared_info_any_t *live_shinfo; > @@ -96,16 +91,16 @@ int xc_map_domain_meminfo(xc_interface *xch, uint32_t domid, > return -1; > } > > - if ( xc_core_arch_map_p2m_writable(xch, minfo->guest_width, &info, > - live_shinfo, &minfo->p2m_table, > - &minfo->p2m_size) ) > + if ( xc_core_arch_map_p2m_writable(xch, &_di, &info, > + live_shinfo, &minfo->p2m_table) ) > { > PERROR("Could not map the P2M table"); > munmap(live_shinfo, PAGE_SIZE); > return -1; > } > munmap(live_shinfo, PAGE_SIZE); > - _di.p2m_size = minfo->p2m_size; > + minfo->p2m_size = _di.p2m_size; > + minfo->p2m_frames = _di.p2m_frames; > > /* Make space and prepare for getting the PFN types */ > minfo->pfn_type = calloc(sizeof(*minfo->pfn_type), minfo->p2m_size); > @@ -141,7 +136,7 @@ failed: > } > if ( minfo->p2m_table ) > { > - munmap(minfo->p2m_table, P2M_FL_ENTRIES * PAGE_SIZE); > + munmap(minfo->p2m_table, minfo->p2m_frames * PAGE_SIZE); > minfo->p2m_table = NULL; > } > > [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 3135 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 495 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH-4.15] tools/libs/ctrl: fix xc_core_arch_map_p2m() to support linear p2m table 2021-07-16 6:47 ` Juergen Gross @ 2021-08-19 7:45 ` Juergen Gross 2021-08-19 16:11 ` Ian Jackson 2021-08-19 15:44 ` preparations for 4.15.1 and 4.13.4 support linear p2m table [and 1 more messages] Ian Jackson 1 sibling, 1 reply; 28+ messages in thread From: Juergen Gross @ 2021-08-19 7:45 UTC (permalink / raw) To: xen-devel, Ian Jackson, Wei Liu; +Cc: Jan Beulich [-- Attachment #1.1.1: Type: text/plain, Size: 25239 bytes --] PING!!! On 16.07.21 08:47, Juergen Gross wrote: > Ping? > > On 02.07.21 16:29, Juergen Gross wrote: >> The core of a pv linux guest produced via "xl dump-core" is not usable >> as since kernel 4.14 only the linear p2m table is kept if Xen indicates >> it is supporting that. Unfortunately xc_core_arch_map_p2m() is still >> supporting the 3-level p2m tree only. >> >> Fix that by copying the functionality of map_p2m() from libxenguest to >> libxenctrl. >> >> Additionally the mapped p2m isn't of a fixed length now, so the >> interface to the mapping functions needs to be adapted. In order not to >> add even more parameters, expand struct domain_info_context and use a >> pointer to that as a parameter. >> >> This is a backport of upstream commit bd7a29c3d0b937ab542a. >> >> As the original patch includes a modification of a data structure >> passed via pointer to a library function, the related function in the >> library is renamed in order to be able to spot any external users of >> that function. Note that it is extremely unlikely any such users >> outside the Xen git tree are existing, so the risk to break any >> existing programs is very unlikely. In case such a user is existing, >> changing the name of xc_map_domain_meminfo() will at least avoid >> silent breakage. >> >> Fixes: dc6d60937121 ("libxc: set flag for support of linear p2m list >> in domain builder") >> Signed-off-by: Juergen Gross <jgross@suse.com> >> --- >> tools/include/xenguest.h | 2 + >> tools/libs/ctrl/xc_core.c | 5 +- >> tools/libs/ctrl/xc_core.h | 8 +- >> tools/libs/ctrl/xc_core_arm.c | 23 +-- >> tools/libs/ctrl/xc_core_x86.c | 256 ++++++++++++++++++++++++++++------ >> tools/libs/ctrl/xc_private.h | 1 + >> tools/libs/guest/xg_domain.c | 17 +-- >> 7 files changed, 234 insertions(+), 78 deletions(-) >> >> diff --git a/tools/include/xenguest.h b/tools/include/xenguest.h >> index 217022b6e7..36a26deba4 100644 >> --- a/tools/include/xenguest.h >> +++ b/tools/include/xenguest.h >> @@ -700,8 +700,10 @@ struct xc_domain_meminfo { >> xen_pfn_t *pfn_type; >> xen_pfn_t *p2m_table; >> unsigned long p2m_size; >> + unsigned int p2m_frames; >> }; >> +#define xc_map_domain_meminfo xc_map_domain_meminfo_mod >> int xc_map_domain_meminfo(xc_interface *xch, uint32_t domid, >> struct xc_domain_meminfo *minfo); >> diff --git a/tools/libs/ctrl/xc_core.c b/tools/libs/ctrl/xc_core.c >> index b47ab2f6d8..9576bec5a3 100644 >> --- a/tools/libs/ctrl/xc_core.c >> +++ b/tools/libs/ctrl/xc_core.c >> @@ -574,8 +574,7 @@ xc_domain_dumpcore_via_callback(xc_interface *xch, >> goto out; >> } >> - sts = xc_core_arch_map_p2m(xch, dinfo->guest_width, &info, >> live_shinfo, >> - &p2m, &dinfo->p2m_size); >> + sts = xc_core_arch_map_p2m(xch, dinfo, &info, live_shinfo, >> &p2m); >> if ( sts != 0 ) >> goto out; >> @@ -945,7 +944,7 @@ out: >> if ( memory_map != NULL ) >> free(memory_map); >> if ( p2m != NULL ) >> - munmap(p2m, PAGE_SIZE * P2M_FL_ENTRIES); >> + munmap(p2m, PAGE_SIZE * dinfo->p2m_frames); >> if ( p2m_array != NULL ) >> free(p2m_array); >> if ( pfn_array != NULL ) >> diff --git a/tools/libs/ctrl/xc_core.h b/tools/libs/ctrl/xc_core.h >> index 36fb755da2..8ea1f93a10 100644 >> --- a/tools/libs/ctrl/xc_core.h >> +++ b/tools/libs/ctrl/xc_core.h >> @@ -138,14 +138,14 @@ int xc_core_arch_memory_map_get(xc_interface *xch, >> xc_dominfo_t *info, >> shared_info_any_t *live_shinfo, >> xc_core_memory_map_t **mapp, >> unsigned int *nr_entries); >> -int xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, >> +int xc_core_arch_map_p2m(xc_interface *xch, struct >> domain_info_context *dinfo, >> xc_dominfo_t *info, shared_info_any_t >> *live_shinfo, >> - xen_pfn_t **live_p2m, unsigned long *pfnp); >> + xen_pfn_t **live_p2m); >> -int xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int >> guest_width, >> +int xc_core_arch_map_p2m_writable(xc_interface *xch, struct >> domain_info_context *dinfo, >> xc_dominfo_t *info, >> shared_info_any_t *live_shinfo, >> - xen_pfn_t **live_p2m, unsigned long >> *pfnp); >> + xen_pfn_t **live_p2m); >> int xc_core_arch_get_scratch_gpfn(xc_interface *xch, uint32_t domid, >> xen_pfn_t *gpfn); >> diff --git a/tools/libs/ctrl/xc_core_arm.c >> b/tools/libs/ctrl/xc_core_arm.c >> index 7b587b4cc5..93765a565f 100644 >> --- a/tools/libs/ctrl/xc_core_arm.c >> +++ b/tools/libs/ctrl/xc_core_arm.c >> @@ -66,33 +66,24 @@ xc_core_arch_memory_map_get(xc_interface *xch, >> struct xc_core_arch_context *unus >> static int >> xc_core_arch_map_p2m_rw(xc_interface *xch, struct >> domain_info_context *dinfo, xc_dominfo_t *info, >> - shared_info_any_t *live_shinfo, xen_pfn_t >> **live_p2m, >> - unsigned long *pfnp, int rw) >> + shared_info_any_t *live_shinfo, xen_pfn_t >> **live_p2m, int rw) >> { >> errno = ENOSYS; >> return -1; >> } >> int >> -xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, >> xc_dominfo_t *info, >> - shared_info_any_t *live_shinfo, xen_pfn_t >> **live_p2m, >> - unsigned long *pfnp) >> +xc_core_arch_map_p2m(xc_interface *xch, struct domain_info_context >> *dinfo, xc_dominfo_t *info, >> + shared_info_any_t *live_shinfo, xen_pfn_t >> **live_p2m) >> { >> - struct domain_info_context _dinfo = { .guest_width = guest_width }; >> - struct domain_info_context *dinfo = &_dinfo; >> - return xc_core_arch_map_p2m_rw(xch, dinfo, info, >> - live_shinfo, live_p2m, pfnp, 0); >> + return xc_core_arch_map_p2m_rw(xch, dinfo, info, live_shinfo, >> live_p2m, 0); >> } >> int >> -xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int >> guest_width, xc_dominfo_t *info, >> - shared_info_any_t *live_shinfo, >> xen_pfn_t **live_p2m, >> - unsigned long *pfnp) >> +xc_core_arch_map_p2m_writable(xc_interface *xch, struct >> domain_info_context *dinfo, xc_dominfo_t *info, >> + shared_info_any_t *live_shinfo, >> xen_pfn_t **live_p2m) >> { >> - struct domain_info_context _dinfo = { .guest_width = guest_width }; >> - struct domain_info_context *dinfo = &_dinfo; >> - return xc_core_arch_map_p2m_rw(xch, dinfo, info, >> - live_shinfo, live_p2m, pfnp, 1); >> + return xc_core_arch_map_p2m_rw(xch, dinfo, info, live_shinfo, >> live_p2m, 1); >> } >> int >> diff --git a/tools/libs/ctrl/xc_core_x86.c >> b/tools/libs/ctrl/xc_core_x86.c >> index cb76e6207b..c8f71d4b75 100644 >> --- a/tools/libs/ctrl/xc_core_x86.c >> +++ b/tools/libs/ctrl/xc_core_x86.c >> @@ -17,6 +17,7 @@ >> * >> */ >> +#include <inttypes.h> >> #include "xc_private.h" >> #include "xc_core.h" >> #include <xen/hvm/e820.h> >> @@ -65,34 +66,169 @@ xc_core_arch_memory_map_get(xc_interface *xch, >> struct xc_core_arch_context *unus >> return 0; >> } >> -static int >> -xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context >> *dinfo, xc_dominfo_t *info, >> - shared_info_any_t *live_shinfo, xen_pfn_t >> **live_p2m, >> - unsigned long *pfnp, int rw) >> +static inline bool is_canonical_address(uint64_t vaddr) >> { >> - /* Double and single indirect references to the live P2M table */ >> - xen_pfn_t *live_p2m_frame_list_list = NULL; >> - xen_pfn_t *live_p2m_frame_list = NULL; >> - /* Copies of the above. */ >> - xen_pfn_t *p2m_frame_list_list = NULL; >> - xen_pfn_t *p2m_frame_list = NULL; >> + return ((int64_t)vaddr >> 47) == ((int64_t)vaddr >> 63); >> +} >> - uint32_t dom = info->domid; >> - int ret = -1; >> - int err; >> - int i; >> +/* Virtual address ranges reserved for hypervisor. */ >> +#define HYPERVISOR_VIRT_START_X86_64 0xFFFF800000000000ULL >> +#define HYPERVISOR_VIRT_END_X86_64 0xFFFF87FFFFFFFFFFULL >> - if ( xc_domain_nr_gpfns(xch, info->domid, &dinfo->p2m_size) < 0 ) >> +#define HYPERVISOR_VIRT_START_X86_32 0x00000000F5800000ULL >> +#define HYPERVISOR_VIRT_END_X86_32 0x00000000FFFFFFFFULL >> + >> +static xen_pfn_t * >> +xc_core_arch_map_p2m_list_rw(xc_interface *xch, struct >> domain_info_context *dinfo, >> + uint32_t dom, shared_info_any_t >> *live_shinfo, >> + uint64_t p2m_cr3) >> +{ >> + uint64_t p2m_vaddr, p2m_end, mask, off; >> + xen_pfn_t p2m_mfn, mfn, saved_mfn, max_pfn; >> + uint64_t *ptes = NULL; >> + xen_pfn_t *mfns = NULL; >> + unsigned int fpp, n_pages, level, n_levels, shift, >> + idx_start, idx_end, idx, saved_idx; >> + >> + p2m_vaddr = GET_FIELD(live_shinfo, arch.p2m_vaddr, >> dinfo->guest_width); >> + fpp = PAGE_SIZE / dinfo->guest_width; >> + dinfo->p2m_frames = (dinfo->p2m_size - 1) / fpp + 1; >> + p2m_end = p2m_vaddr + dinfo->p2m_frames * PAGE_SIZE - 1; >> + >> + if ( dinfo->guest_width == 8 ) >> { >> - ERROR("Could not get maximum GPFN!"); >> - goto out; >> + mask = 0x0000ffffffffffffULL; >> + n_levels = 4; >> + p2m_mfn = p2m_cr3 >> 12; >> + if ( !is_canonical_address(p2m_vaddr) || >> + !is_canonical_address(p2m_end) || >> + p2m_end < p2m_vaddr || >> + (p2m_vaddr <= HYPERVISOR_VIRT_END_X86_64 && >> + p2m_end > HYPERVISOR_VIRT_START_X86_64) ) >> + { >> + ERROR("Bad virtual p2m address range %#" PRIx64 "-%#" >> PRIx64, >> + p2m_vaddr, p2m_end); >> + errno = ERANGE; >> + goto out; >> + } >> + } >> + else >> + { >> + mask = 0x00000000ffffffffULL; >> + n_levels = 3; >> + if ( p2m_cr3 & ~mask ) >> + p2m_mfn = ~0UL; >> + else >> + p2m_mfn = (uint32_t)((p2m_cr3 >> 12) | (p2m_cr3 << 20)); >> + if ( p2m_vaddr > mask || p2m_end > mask || p2m_end < >> p2m_vaddr || >> + (p2m_vaddr <= HYPERVISOR_VIRT_END_X86_32 && >> + p2m_end > HYPERVISOR_VIRT_START_X86_32) ) >> + { >> + ERROR("Bad virtual p2m address range %#" PRIx64 "-%#" >> PRIx64, >> + p2m_vaddr, p2m_end); >> + errno = ERANGE; >> + goto out; >> + } >> } >> - if ( dinfo->p2m_size < info->nr_pages ) >> + mfns = malloc(sizeof(*mfns)); >> + if ( !mfns ) >> { >> - ERROR("p2m_size < nr_pages -1 (%lx < %lx", dinfo->p2m_size, >> info->nr_pages - 1); >> + ERROR("Cannot allocate memory for array of %u mfns", 1); >> goto out; >> } >> + mfns[0] = p2m_mfn; >> + off = 0; >> + saved_mfn = 0; >> + idx_start = idx_end = saved_idx = 0; >> + >> + for ( level = n_levels; level > 0; level-- ) >> + { >> + n_pages = idx_end - idx_start + 1; >> + ptes = xc_map_foreign_pages(xch, dom, PROT_READ, mfns, n_pages); >> + if ( !ptes ) >> + { >> + PERROR("Failed to map %u page table pages for p2m list", >> n_pages); >> + goto out; >> + } >> + free(mfns); >> + >> + shift = level * 9 + 3; >> + idx_start = ((p2m_vaddr - off) & mask) >> shift; >> + idx_end = ((p2m_end - off) & mask) >> shift; >> + idx = idx_end - idx_start + 1; >> + mfns = malloc(sizeof(*mfns) * idx); >> + if ( !mfns ) >> + { >> + ERROR("Cannot allocate memory for array of %u mfns", idx); >> + goto out; >> + } >> + >> + for ( idx = idx_start; idx <= idx_end; idx++ ) >> + { >> + mfn = (ptes[idx] & 0x000ffffffffff000ULL) >> PAGE_SHIFT; >> + if ( mfn == 0 ) >> + { >> + ERROR("Bad mfn %#lx during page table walk for vaddr >> %#" PRIx64 " at level %d of p2m list", >> + mfn, off + ((uint64_t)idx << shift), level); >> + errno = ERANGE; >> + goto out; >> + } >> + mfns[idx - idx_start] = mfn; >> + >> + /* Maximum pfn check at level 2. Same reasoning as for >> p2m tree. */ >> + if ( level == 2 ) >> + { >> + if ( mfn != saved_mfn ) >> + { >> + saved_mfn = mfn; >> + saved_idx = idx - idx_start; >> + } >> + } >> + } >> + >> + if ( level == 2 ) >> + { >> + if ( saved_idx == idx_end ) >> + saved_idx++; >> + max_pfn = ((xen_pfn_t)saved_idx << 9) * fpp; >> + if ( max_pfn < dinfo->p2m_size ) >> + { >> + dinfo->p2m_size = max_pfn; >> + dinfo->p2m_frames = (dinfo->p2m_size + fpp - 1) / fpp; >> + p2m_end = p2m_vaddr + dinfo->p2m_frames * PAGE_SIZE - 1; >> + idx_end = idx_start + saved_idx; >> + } >> + } >> + >> + munmap(ptes, n_pages * PAGE_SIZE); >> + ptes = NULL; >> + off = p2m_vaddr & ((mask >> shift) << shift); >> + } >> + >> + return mfns; >> + >> + out: >> + free(mfns); >> + if ( ptes ) >> + munmap(ptes, n_pages * PAGE_SIZE); >> + >> + return NULL; >> +} >> + >> +static xen_pfn_t * >> +xc_core_arch_map_p2m_tree_rw(xc_interface *xch, struct >> domain_info_context *dinfo, >> + uint32_t dom, shared_info_any_t >> *live_shinfo) >> +{ >> + /* Double and single indirect references to the live P2M table */ >> + xen_pfn_t *live_p2m_frame_list_list; >> + xen_pfn_t *live_p2m_frame_list = NULL; >> + /* Copies of the above. */ >> + xen_pfn_t *p2m_frame_list_list = NULL; >> + xen_pfn_t *p2m_frame_list; >> + >> + int err; >> + int i; >> live_p2m_frame_list_list = >> xc_map_foreign_range(xch, dom, PAGE_SIZE, PROT_READ, >> @@ -151,10 +287,60 @@ xc_core_arch_map_p2m_rw(xc_interface *xch, >> struct domain_info_context *dinfo, xc >> for ( i = P2M_FL_ENTRIES - 1; i >= 0; i-- ) >> p2m_frame_list[i] = ((uint32_t *)p2m_frame_list)[i]; >> + dinfo->p2m_frames = P2M_FL_ENTRIES; >> + >> + return p2m_frame_list; >> + >> + out: >> + err = errno; >> + >> + if ( live_p2m_frame_list_list ) >> + munmap(live_p2m_frame_list_list, PAGE_SIZE); >> + >> + if ( live_p2m_frame_list ) >> + munmap(live_p2m_frame_list, P2M_FLL_ENTRIES * PAGE_SIZE); >> + >> + free(p2m_frame_list_list); >> + >> + errno = err; >> + >> + return NULL; >> +} >> + >> +static int >> +xc_core_arch_map_p2m_rw(xc_interface *xch, struct domain_info_context >> *dinfo, xc_dominfo_t *info, >> + shared_info_any_t *live_shinfo, xen_pfn_t >> **live_p2m, int rw) >> +{ >> + xen_pfn_t *p2m_frame_list = NULL; >> + uint64_t p2m_cr3; >> + uint32_t dom = info->domid; >> + int ret = -1; >> + int err; >> + >> + if ( xc_domain_nr_gpfns(xch, info->domid, &dinfo->p2m_size) < 0 ) >> + { >> + ERROR("Could not get maximum GPFN!"); >> + goto out; >> + } >> + >> + if ( dinfo->p2m_size < info->nr_pages ) >> + { >> + ERROR("p2m_size < nr_pages -1 (%lx < %lx", dinfo->p2m_size, >> info->nr_pages - 1); >> + goto out; >> + } >> + >> + p2m_cr3 = GET_FIELD(live_shinfo, arch.p2m_cr3, dinfo->guest_width); >> + >> + p2m_frame_list = p2m_cr3 ? xc_core_arch_map_p2m_list_rw(xch, >> dinfo, dom, live_shinfo, p2m_cr3) >> + : xc_core_arch_map_p2m_tree_rw(xch, >> dinfo, dom, live_shinfo); >> + >> + if ( !p2m_frame_list ) >> + goto out; >> + >> *live_p2m = xc_map_foreign_pages(xch, dom, >> rw ? (PROT_READ | PROT_WRITE) : >> PROT_READ, >> p2m_frame_list, >> - P2M_FL_ENTRIES); >> + dinfo->p2m_frames); >> if ( !*live_p2m ) >> { >> @@ -162,21 +348,11 @@ xc_core_arch_map_p2m_rw(xc_interface *xch, >> struct domain_info_context *dinfo, xc >> goto out; >> } >> - *pfnp = dinfo->p2m_size; >> - >> ret = 0; >> out: >> err = errno; >> - if ( live_p2m_frame_list_list ) >> - munmap(live_p2m_frame_list_list, PAGE_SIZE); >> - >> - if ( live_p2m_frame_list ) >> - munmap(live_p2m_frame_list, P2M_FLL_ENTRIES * PAGE_SIZE); >> - >> - free(p2m_frame_list_list); >> - >> free(p2m_frame_list); >> errno = err; >> @@ -184,25 +360,17 @@ out: >> } >> int >> -xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, >> xc_dominfo_t *info, >> - shared_info_any_t *live_shinfo, xen_pfn_t >> **live_p2m, >> - unsigned long *pfnp) >> +xc_core_arch_map_p2m(xc_interface *xch, struct domain_info_context >> *dinfo, xc_dominfo_t *info, >> + shared_info_any_t *live_shinfo, xen_pfn_t >> **live_p2m) >> { >> - struct domain_info_context _dinfo = { .guest_width = guest_width }; >> - struct domain_info_context *dinfo = &_dinfo; >> - return xc_core_arch_map_p2m_rw(xch, dinfo, info, >> - live_shinfo, live_p2m, pfnp, 0); >> + return xc_core_arch_map_p2m_rw(xch, dinfo, info, live_shinfo, >> live_p2m, 0); >> } >> int >> -xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int >> guest_width, xc_dominfo_t *info, >> - shared_info_any_t *live_shinfo, >> xen_pfn_t **live_p2m, >> - unsigned long *pfnp) >> +xc_core_arch_map_p2m_writable(xc_interface *xch, struct >> domain_info_context *dinfo, xc_dominfo_t *info, >> + shared_info_any_t *live_shinfo, >> xen_pfn_t **live_p2m) >> { >> - struct domain_info_context _dinfo = { .guest_width = guest_width }; >> - struct domain_info_context *dinfo = &_dinfo; >> - return xc_core_arch_map_p2m_rw(xch, dinfo, info, >> - live_shinfo, live_p2m, pfnp, 1); >> + return xc_core_arch_map_p2m_rw(xch, dinfo, info, live_shinfo, >> live_p2m, 1); >> } >> int >> diff --git a/tools/libs/ctrl/xc_private.h b/tools/libs/ctrl/xc_private.h >> index f0b5f83ac8..8ebc0b59da 100644 >> --- a/tools/libs/ctrl/xc_private.h >> +++ b/tools/libs/ctrl/xc_private.h >> @@ -79,6 +79,7 @@ struct iovec { >> struct domain_info_context { >> unsigned int guest_width; >> + unsigned int p2m_frames; >> unsigned long p2m_size; >> }; >> diff --git a/tools/libs/guest/xg_domain.c b/tools/libs/guest/xg_domain.c >> index 5019c84e0e..dd7db2cbd8 100644 >> --- a/tools/libs/guest/xg_domain.c >> +++ b/tools/libs/guest/xg_domain.c >> @@ -24,13 +24,9 @@ >> int xc_unmap_domain_meminfo(xc_interface *xch, struct >> xc_domain_meminfo *minfo) >> { >> - struct domain_info_context _di = { .guest_width = >> minfo->guest_width, >> - .p2m_size = minfo->p2m_size}; >> - struct domain_info_context *dinfo = &_di; >> - >> free(minfo->pfn_type); >> if ( minfo->p2m_table ) >> - munmap(minfo->p2m_table, P2M_FL_ENTRIES * PAGE_SIZE); >> + munmap(minfo->p2m_table, minfo->p2m_frames * PAGE_SIZE); >> minfo->p2m_table = NULL; >> return 0; >> @@ -40,7 +36,6 @@ int xc_map_domain_meminfo(xc_interface *xch, >> uint32_t domid, >> struct xc_domain_meminfo *minfo) >> { >> struct domain_info_context _di; >> - struct domain_info_context *dinfo = &_di; >> xc_dominfo_t info; >> shared_info_any_t *live_shinfo; >> @@ -96,16 +91,16 @@ int xc_map_domain_meminfo(xc_interface *xch, >> uint32_t domid, >> return -1; >> } >> - if ( xc_core_arch_map_p2m_writable(xch, minfo->guest_width, &info, >> - live_shinfo, &minfo->p2m_table, >> - &minfo->p2m_size) ) >> + if ( xc_core_arch_map_p2m_writable(xch, &_di, &info, >> + live_shinfo, &minfo->p2m_table) ) >> { >> PERROR("Could not map the P2M table"); >> munmap(live_shinfo, PAGE_SIZE); >> return -1; >> } >> munmap(live_shinfo, PAGE_SIZE); >> - _di.p2m_size = minfo->p2m_size; >> + minfo->p2m_size = _di.p2m_size; >> + minfo->p2m_frames = _di.p2m_frames; >> /* Make space and prepare for getting the PFN types */ >> minfo->pfn_type = calloc(sizeof(*minfo->pfn_type), >> minfo->p2m_size); >> @@ -141,7 +136,7 @@ failed: >> } >> if ( minfo->p2m_table ) >> { >> - munmap(minfo->p2m_table, P2M_FL_ENTRIES * PAGE_SIZE); >> + munmap(minfo->p2m_table, minfo->p2m_frames * PAGE_SIZE); >> minfo->p2m_table = NULL; >> } >> > [-- Attachment #1.1.2: OpenPGP public key --] [-- Type: application/pgp-keys, Size: 3135 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 495 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH-4.15] tools/libs/ctrl: fix xc_core_arch_map_p2m() to support linear p2m table 2021-08-19 7:45 ` Juergen Gross @ 2021-08-19 16:11 ` Ian Jackson 0 siblings, 0 replies; 28+ messages in thread From: Ian Jackson @ 2021-08-19 16:11 UTC (permalink / raw) To: Juergen Gross; +Cc: xen-devel, Ian Jackson, Wei Liu, Jan Beulich Juergen Gross writes ("Re: [PATCH-4.15] tools/libs/ctrl: fix xc_core_arch_map_p2m() to support linear p2m table"): > PING!!! Sorry. I have reviewed this and I think it is good to backport, so Reviewed-by: Ian Jackson <iwj@xenproject.org> and queued. I'll push it to staging-4.15 later today. Ian. ^ permalink raw reply [flat|nested] 28+ messages in thread
* preparations for 4.15.1 and 4.13.4 support linear p2m table [and 1 more messages] 2021-07-16 6:47 ` Juergen Gross 2021-08-19 7:45 ` Juergen Gross @ 2021-08-19 15:44 ` Ian Jackson 1 sibling, 0 replies; 28+ messages in thread From: Ian Jackson @ 2021-08-19 15:44 UTC (permalink / raw) To: Jan Beulich, Juergen Gross Cc: xen-devel, Wei Liu, Ian Jackson, George Dunlap, Stefano Stabellini, Anthony Perard, Julien Grall Juergen Gross writes ("Re: [PATCH-4.15] tools/libs/ctrl: fix xc_core_arch_map_p2m() to support linear p2m table"): > Ping? Jan Beulich writes ("preparations for 4.15.1 and 4.13.4"): > the releases are due in a couple of weeks time (and 4.14.3 is > supposed to follow another few weeks later). Please point out backports > you find missing from the respective staging branches, but which you > consider relevant. Hi. I'm sorry I am behind on this. I am going to look at some of these backports now but I may not get through all of them... Ian. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: preparations for 4.15.1 and 4.13.4 2021-07-15 7:58 preparations for 4.15.1 and 4.13.4 Jan Beulich 2021-07-02 14:29 ` [PATCH-4.15] tools/libs/ctrl: fix xc_core_arch_map_p2m() to support linear p2m table Juergen Gross @ 2021-07-15 8:02 ` Jan Beulich 2021-07-15 9:02 ` Anthony PERARD ` (5 subsequent siblings) 7 siblings, 0 replies; 28+ messages in thread From: Jan Beulich @ 2021-07-15 8:02 UTC (permalink / raw) To: Andrew Cooper Cc: George Dunlap, Stefano Stabellini, Wei Liu, Anthony Perard, Julien Grall, Ian Jackson, xen-devel Andrew, On 15.07.2021 09:58, Jan Beulich wrote: > the releases are due in a couple of weeks time (and 4.14.3 is > supposed to follow another few weeks later). Please point out backports > you find missing from the respective staging branches, but which you > consider relevant. > > Please note that 4.13.4 is going to be the last Xen Project > coordinated release from the 4.13 branch; the branch will go into > security-only maintenance mode after this release. as I don't suppose "x86/cpuid: Fix HLE and RTM handling (again)" is what you were meaning to be all that's needed to fix my backport of "x86/cpuid: Rework HLE and RTM handling" on the 4.13 branch, would you please either submit whatever further fix you deem necessary, or share enough information for someone else (perhaps me) to create such a fix? Thanks, Jan ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: preparations for 4.15.1 and 4.13.4 2021-07-15 7:58 preparations for 4.15.1 and 4.13.4 Jan Beulich 2021-07-02 14:29 ` [PATCH-4.15] tools/libs/ctrl: fix xc_core_arch_map_p2m() to support linear p2m table Juergen Gross 2021-07-15 8:02 ` preparations for 4.15.1 and 4.13.4 Jan Beulich @ 2021-07-15 9:02 ` Anthony PERARD 2021-08-19 16:23 ` QEMU 6.0+ in 4.15 and 4.14 (Re: preparations for 4.15.1 and 4.13.4) Ian Jackson 2021-07-15 10:58 ` preparations for 4.15.1 and 4.13.4 Andrew Cooper ` (4 subsequent siblings) 7 siblings, 1 reply; 28+ messages in thread From: Anthony PERARD @ 2021-07-15 9:02 UTC (permalink / raw) To: Jan Beulich, Ian Jackson Cc: xen-devel, Ian Jackson, George Dunlap, Stefano Stabellini, Wei Liu, Julien Grall Can we backport support of QEMU 6.0 to Xen 4.15? I'm pretty sure distributions are going to want to use the latest QEMU and latest Xen, without needed to build two different QEMU binaries. [XEN PATCH v2 0/8] Fix libxl with QEMU 6.0 + remove some more deprecated usages. <20210511092810.13759-1-anthony.perard@citrix.com> Commits: d5f54009db^..fe6630ddc4 Some more QEMU 6.0 fixes <20210628100157.5010-1-anthony.perard@citrix.com> Commits: 217eef30f7 3bc3be978f Also, Olaf want them to be backported to 4.14, see <20210629095952.7b0b94c1.olaf@aepfle.de> Thanks, -- Anthony PERARD ^ permalink raw reply [flat|nested] 28+ messages in thread
* QEMU 6.0+ in 4.15 and 4.14 (Re: preparations for 4.15.1 and 4.13.4) 2021-07-15 9:02 ` Anthony PERARD @ 2021-08-19 16:23 ` Ian Jackson 2021-08-23 9:48 ` Olaf Hering 2021-08-27 12:39 ` Anthony PERARD 0 siblings, 2 replies; 28+ messages in thread From: Ian Jackson @ 2021-08-19 16:23 UTC (permalink / raw) To: Anthony PERARD Cc: Jan Beulich, Olaf Hering, xen-devel, George Dunlap, Stefano Stabellini, Wei Liu, Julien Grall Anthony PERARD writes ("Re: preparations for 4.15.1 and 4.13.4"): > Can we backport support of QEMU 6.0 to Xen 4.15? I'm pretty sure > distributions are going to want to use the latest QEMU and latest Xen, > without needed to build two different QEMU binaries. I think this is appropriate. Xen 4.15 is still now, and there was an unfortunate interaction between release dates. Your argument makes sense. > [XEN PATCH v2 0/8] Fix libxl with QEMU 6.0 + remove some more deprecated usages. > <20210511092810.13759-1-anthony.perard@citrix.com> > Commits: d5f54009db^..fe6630ddc4 > > Some more QEMU 6.0 fixes > <20210628100157.5010-1-anthony.perard@citrix.com> > Commits: 217eef30f7 3bc3be978f So I have queued all these. > Also, Olaf want them to be backported to 4.14, see > <20210629095952.7b0b94c1.olaf@aepfle.de> I'm unsure about this. The diff seems moderately large. Also, are we sure that it wouldn't break anything other than very old qemu ? OTOH compat problems with newer qemu are indeed a problem especially for distros. I'm currently leaning towards "no" but I am very open to being convinced this is a good idea. Ian. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: QEMU 6.0+ in 4.15 and 4.14 (Re: preparations for 4.15.1 and 4.13.4) 2021-08-19 16:23 ` QEMU 6.0+ in 4.15 and 4.14 (Re: preparations for 4.15.1 and 4.13.4) Ian Jackson @ 2021-08-23 9:48 ` Olaf Hering 2021-08-27 12:39 ` Anthony PERARD 1 sibling, 0 replies; 28+ messages in thread From: Olaf Hering @ 2021-08-23 9:48 UTC (permalink / raw) To: Ian Jackson Cc: Anthony PERARD, Jan Beulich, xen-devel, George Dunlap, Stefano Stabellini, Wei Liu, Julien Grall [-- Attachment #1: Type: text/plain, Size: 782 bytes --] Am Thu, 19 Aug 2021 17:23:26 +0100 schrieb Ian Jackson <iwj@xenproject.org>: > Anthony PERARD writes ("Re: preparations for 4.15.1 and 4.13.4"): > > Also, Olaf want them to be backported to 4.14, see > > <20210629095952.7b0b94c1.olaf@aepfle.de> > I'm unsure about this. The diff seems moderately large. Also, are we > sure that it wouldn't break anything other than very old qemu ? OTOH > compat problems with newer qemu are indeed a problem especially for > distros. libxl in 4.14 and 4.15 is nearly identical. It would reduce the amount of changes for Xen in Leap 15.3. SUSE uses a separate qemu binary since a few years, in case of 15.3 it happens to be qemu-5.2. This variant of qemu removed "cpu-add", as a result cpu hotplug with HVM fails. Olaf [-- Attachment #2: Digitale Signatur von OpenPGP --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: QEMU 6.0+ in 4.15 and 4.14 (Re: preparations for 4.15.1 and 4.13.4) 2021-08-19 16:23 ` QEMU 6.0+ in 4.15 and 4.14 (Re: preparations for 4.15.1 and 4.13.4) Ian Jackson 2021-08-23 9:48 ` Olaf Hering @ 2021-08-27 12:39 ` Anthony PERARD 1 sibling, 0 replies; 28+ messages in thread From: Anthony PERARD @ 2021-08-27 12:39 UTC (permalink / raw) To: Ian Jackson Cc: Jan Beulich, Olaf Hering, xen-devel, George Dunlap, Stefano Stabellini, Wei Liu, Julien Grall On Thu, Aug 19, 2021 at 05:23:26PM +0100, Ian Jackson wrote: > Anthony PERARD writes ("Re: preparations for 4.15.1 and 4.13.4"): > > Can we backport support of QEMU 6.0 to Xen 4.15? I'm pretty sure > > distributions are going to want to use the latest QEMU and latest Xen, > > without needed to build two different QEMU binaries. > > I think this is appropriate. Xen 4.15 is still now, and there was an > unfortunate interaction between release dates. Your argument makes > sense. > > > [XEN PATCH v2 0/8] Fix libxl with QEMU 6.0 + remove some more deprecated usages. > > <20210511092810.13759-1-anthony.perard@citrix.com> > > Commits: d5f54009db^..fe6630ddc4 > > > > Some more QEMU 6.0 fixes > > <20210628100157.5010-1-anthony.perard@citrix.com> > > Commits: 217eef30f7 3bc3be978f > > So I have queued all these. > > > Also, Olaf want them to be backported to 4.14, see > > <20210629095952.7b0b94c1.olaf@aepfle.de> > > I'm unsure about this. The diff seems moderately large. Also, are we > sure that it wouldn't break anything other than very old qemu ? OTOH > compat problems with newer qemu are indeed a problem especially for > distros. I've check all commits, beside two commits they all have a fallback mechanism so we still are compatible with old qemus. There is these two commits libxl: Fix QEMU cmdline for scsi device libxl: Use -device for cd-rom drives which replace command line arguments, but it is to use something that has been available since QEMU 0.15, so before the first version that libxl as evert supported. So overall, I don't think we break compatibility with very old qemus. It would take a couple more QMP command to run some feature as libxl would try the new command first before falling back to previous ones. > I'm currently leaning towards "no" but I am very open to being > convinced this is a good idea. I don't know if it is a good idea, but at least it doesn't seems to be a bad one. -- Anthony PERARD ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: preparations for 4.15.1 and 4.13.4 2021-07-15 7:58 preparations for 4.15.1 and 4.13.4 Jan Beulich ` (2 preceding siblings ...) 2021-07-15 9:02 ` Anthony PERARD @ 2021-07-15 10:58 ` Andrew Cooper 2021-07-15 11:12 ` Jan Beulich 2021-07-15 14:11 ` Olaf Hering ` (3 subsequent siblings) 7 siblings, 1 reply; 28+ messages in thread From: Andrew Cooper @ 2021-07-15 10:58 UTC (permalink / raw) To: Jan Beulich, xen-devel, Ian Jackson Cc: George Dunlap, Stefano Stabellini, Wei Liu, Anthony Perard, Julien Grall On 15/07/2021 08:58, Jan Beulich wrote: > All, > > the releases are due in a couple of weeks time (and 4.14.3 is > supposed to follow another few weeks later). Please point out backports > you find missing from the respective staging branches, but which you > consider relevant. I've got a queue of: * 429b0a5c62b9 - (HEAD -> staging-4.15) tools/libxenstat: fix populating vbd.rd_sect <Richard Kojedzinszky> * 41f0903e1632 - tools/python: fix Python3.4 TypeError in format string <Olaf Hering> * 67f798942caf - tools/python: handle libxl__physmap_info.name properly in convert-legacy-stream (74 seconds ago) <Olaf Hering> * e9709a83490f - tools: use integer division in convert-legacy-stream<Olaf Hering> * 1a6824957d05 - (upstream/staging-4.15, origin/staging-4.15) build: clean "lib.a" <Anthony PERARD> which I'd already ok'd with Ian as ok for backport. I'll sort those out on all applicable branches right now. ~Andrew ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: preparations for 4.15.1 and 4.13.4 2021-07-15 10:58 ` preparations for 4.15.1 and 4.13.4 Andrew Cooper @ 2021-07-15 11:12 ` Jan Beulich 0 siblings, 0 replies; 28+ messages in thread From: Jan Beulich @ 2021-07-15 11:12 UTC (permalink / raw) To: Andrew Cooper Cc: George Dunlap, Stefano Stabellini, Wei Liu, Anthony Perard, Julien Grall, xen-devel, Ian Jackson On 15.07.2021 12:58, Andrew Cooper wrote: > On 15/07/2021 08:58, Jan Beulich wrote: >> All, >> >> the releases are due in a couple of weeks time (and 4.14.3 is >> supposed to follow another few weeks later). Please point out backports >> you find missing from the respective staging branches, but which you >> consider relevant. > > I've got a queue of: > > * 429b0a5c62b9 - (HEAD -> staging-4.15) tools/libxenstat: fix populating > vbd.rd_sect <Richard Kojedzinszky> > * 41f0903e1632 - tools/python: fix Python3.4 TypeError in format string > <Olaf Hering> > * 67f798942caf - tools/python: handle libxl__physmap_info.name properly > in convert-legacy-stream (74 seconds ago) <Olaf Hering> > * e9709a83490f - tools: use integer division in > convert-legacy-stream<Olaf Hering> > * 1a6824957d05 - (upstream/staging-4.15, origin/staging-4.15) build: > clean "lib.a" <Anthony PERARD> You'll notice that this last one is already there. Jan ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: preparations for 4.15.1 and 4.13.4 2021-07-15 7:58 preparations for 4.15.1 and 4.13.4 Jan Beulich ` (3 preceding siblings ...) 2021-07-15 10:58 ` preparations for 4.15.1 and 4.13.4 Andrew Cooper @ 2021-07-15 14:11 ` Olaf Hering 2021-07-15 14:21 ` Jan Beulich 2021-08-19 16:46 ` Ian Jackson 2021-07-15 17:16 ` Andrew Cooper ` (2 subsequent siblings) 7 siblings, 2 replies; 28+ messages in thread From: Olaf Hering @ 2021-07-15 14:11 UTC (permalink / raw) To: Jan Beulich Cc: xen-devel, Ian Jackson, George Dunlap, Stefano Stabellini, Wei Liu, Anthony Perard, Julien Grall [-- Attachment #1: Type: text/plain, Size: 477 bytes --] Am Thu, 15 Jul 2021 09:58:24 +0200 schrieb Jan Beulich <jbeulich@suse.com>: > Please point out backports you find missing from the respective staging branches, but which you consider relevant. Depending on how green the CI is supposed to be: 76416c459c libfsimage: fix parentheses in macro parameters e54c433adf libfsimage: fix clang 10 build This will likely turn the Leap clang builds at https://gitlab.com/xen-project/xen/-/pipelines/337629824 green. Olaf [-- Attachment #2: Digitale Signatur von OpenPGP --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: preparations for 4.15.1 and 4.13.4 2021-07-15 14:11 ` Olaf Hering @ 2021-07-15 14:21 ` Jan Beulich 2021-08-19 16:46 ` Ian Jackson 1 sibling, 0 replies; 28+ messages in thread From: Jan Beulich @ 2021-07-15 14:21 UTC (permalink / raw) To: Olaf Hering, Ian Jackson Cc: xen-devel, George Dunlap, Stefano Stabellini, Wei Liu, Anthony Perard, Julien Grall On 15.07.2021 16:11, Olaf Hering wrote: > Am Thu, 15 Jul 2021 09:58:24 +0200 > schrieb Jan Beulich <jbeulich@suse.com>: > >> Please point out backports you find missing from the respective staging branches, but which you consider relevant. > > Depending on how green the CI is supposed to be: > > 76416c459c libfsimage: fix parentheses in macro parameters > e54c433adf libfsimage: fix clang 10 build Ian, that's again something for you to consider. Thanks, Jan > This will likely turn the Leap clang builds at https://gitlab.com/xen-project/xen/-/pipelines/337629824 green. > > Olaf > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: preparations for 4.15.1 and 4.13.4 2021-07-15 14:11 ` Olaf Hering 2021-07-15 14:21 ` Jan Beulich @ 2021-08-19 16:46 ` Ian Jackson 2021-08-23 8:42 ` Olaf Hering 1 sibling, 1 reply; 28+ messages in thread From: Ian Jackson @ 2021-08-19 16:46 UTC (permalink / raw) To: Olaf Hering Cc: Jan Beulich, xen-devel, George Dunlap, Stefano Stabellini, Wei Liu, Anthony Perard, Julien Grall Olaf Hering writes ("Re: preparations for 4.15.1 and 4.13.4"): > Am Thu, 15 Jul 2021 09:58:24 +0200 > schrieb Jan Beulich <jbeulich@suse.com>: > > > Please point out backports you find missing from the respective staging branches, but which you consider relevant. > > Depending on how green the CI is supposed to be: > > 76416c459c libfsimage: fix parentheses in macro parameters > e54c433adf libfsimage: fix clang 10 build > > This will likely turn the Leap clang builds at https://gitlab.com/xen-project/xen/-/pipelines/337629824 green. I would be happy to take fixes like these for stable branches. I tried a git cherry-pick but it didn't apply. Would you like to supply backports ? Thanks, Ian. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: preparations for 4.15.1 and 4.13.4 2021-08-19 16:46 ` Ian Jackson @ 2021-08-23 8:42 ` Olaf Hering 0 siblings, 0 replies; 28+ messages in thread From: Olaf Hering @ 2021-08-23 8:42 UTC (permalink / raw) To: Ian Jackson Cc: Jan Beulich, xen-devel, George Dunlap, Stefano Stabellini, Wei Liu, Anthony Perard, Julien Grall [-- Attachment #1: Type: text/plain, Size: 400 bytes --] Am Thu, 19 Aug 2021 17:46:28 +0100 schrieb Ian Jackson <iwj@xenproject.org>: > I would be happy to take fixes like these for stable branches. I > tried a git cherry-pick but it didn't apply. Would you like to supply > backports ? This script worked for me in staging-4.13: set -ex git cherry-pick -ex e54c433adf01a242bf6e9fe9378a2c83d3f8b419 git cherry-pick -ex 76416c459c Olaf [-- Attachment #2: Digitale Signatur von OpenPGP --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: preparations for 4.15.1 and 4.13.4 2021-07-15 7:58 preparations for 4.15.1 and 4.13.4 Jan Beulich ` (4 preceding siblings ...) 2021-07-15 14:11 ` Olaf Hering @ 2021-07-15 17:16 ` Andrew Cooper 2021-07-16 6:16 ` Jan Beulich 2021-08-19 16:43 ` preparations for 4.15.1 and 4.13.4 [and 1 more messages] Ian Jackson 2021-07-16 7:41 ` preparations for 4.15.1 and 4.13.4 Julien Grall 2021-07-19 10:32 ` Jan Beulich 7 siblings, 2 replies; 28+ messages in thread From: Andrew Cooper @ 2021-07-15 17:16 UTC (permalink / raw) To: Jan Beulich, xen-devel, Ian Jackson Cc: George Dunlap, Stefano Stabellini, Wei Liu, Anthony Perard, Julien Grall On 15/07/2021 08:58, Jan Beulich wrote: > Beyond this I'd like the following to be considered: > > 6409210a5f51 libxencall: osdep_hypercall() should return long > bef64f2c0019 libxencall: introduce variant of xencall2() returning long > 01a2d001dea2 libxencall: Bump SONAME following new functionality > 6f02d1ea4a10 libxc: use multicall for memory-op on Linux (and Solaris) > > If those are to be taken (which means in particular if the question of > the .so versioning can be properly sorted), > > 198a2bc6f149 x86/HVM: wire up multicalls We can backport changes in SONAME safely so long as: 1) We declare VERS_1.2 to be fixed and released. This means that we bump to 1.3 for the next change, even if it is ahead of Xen 4.16 being release, and 2) *All* ABI changes up to VERS_1.2 are backported. The ABI called VERS_1.2 must be identical on all older branches to avoid binary problems when rebuilding a package against old-xen+updates, and then updating to a newer Xen. ~Andrew ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: preparations for 4.15.1 and 4.13.4 2021-07-15 17:16 ` Andrew Cooper @ 2021-07-16 6:16 ` Jan Beulich 2021-08-19 16:43 ` preparations for 4.15.1 and 4.13.4 [and 1 more messages] Ian Jackson 1 sibling, 0 replies; 28+ messages in thread From: Jan Beulich @ 2021-07-16 6:16 UTC (permalink / raw) To: Andrew Cooper Cc: George Dunlap, Stefano Stabellini, Wei Liu, Anthony Perard, Julien Grall, xen-devel, Ian Jackson On 15.07.2021 19:16, Andrew Cooper wrote: > On 15/07/2021 08:58, Jan Beulich wrote: >> Beyond this I'd like the following to be considered: >> >> 6409210a5f51 libxencall: osdep_hypercall() should return long >> bef64f2c0019 libxencall: introduce variant of xencall2() returning long >> 01a2d001dea2 libxencall: Bump SONAME following new functionality >> 6f02d1ea4a10 libxc: use multicall for memory-op on Linux (and Solaris) >> >> If those are to be taken (which means in particular if the question of >> the .so versioning can be properly sorted), >> >> 198a2bc6f149 x86/HVM: wire up multicalls > > We can backport changes in SONAME safely so long as: > > 1) We declare VERS_1.2 to be fixed and released. This means that we > bump to 1.3 for the next change, even if it is ahead of Xen 4.16 being > release, and Right. A matter of remembering at the right point (if need be). That's where I think the risk is. (And of course I understand you meaning VERS_1.3 and VERS_1.4 respectively for "fixed and released" and "bump to".) If we did so, what I can't tell offhand is whether any ABI-checker data would need updating then. > 2) *All* ABI changes up to VERS_1.2 are backported. > > > The ABI called VERS_1.2 must be identical on all older branches to avoid > binary problems when rebuilding a package against old-xen+updates, and > then updating to a newer Xen. I'm afraid I'm less clear about this part: There shouldn't be any ABI differences in VERS_1.2 in the first place, should there? Or, if the number is again off by one, the sole new function would be identical (ABI-wise) everywhere. Jan ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: preparations for 4.15.1 and 4.13.4 [and 1 more messages] 2021-07-15 17:16 ` Andrew Cooper 2021-07-16 6:16 ` Jan Beulich @ 2021-08-19 16:43 ` Ian Jackson 2021-08-19 16:55 ` Ian Jackson ` (2 more replies) 1 sibling, 3 replies; 28+ messages in thread From: Ian Jackson @ 2021-08-19 16:43 UTC (permalink / raw) To: Andrew Cooper, Jan Beulich Cc: xen-devel, Ian Jackson, George Dunlap, Stefano Stabellini, Wei Liu, Anthony Perard, Julien Grall Jan Beulich writes ("preparations for 4.15.1 and 4.13.4"): > Ian: I did take the liberty to backport Anthony's > > 5d3e4ebb5c71 libs/foreignmemory: Fix osdep_xenforeignmemory_map prototype Thanks. > Beyond this I'd like the following to be considered: > > 6409210a5f51 libxencall: osdep_hypercall() should return long > bef64f2c0019 libxencall: introduce variant of xencall2() returning long > 01a2d001dea2 libxencall: Bump SONAME following new functionality > 6f02d1ea4a10 libxc: use multicall for memory-op on Linux (and Solaris) I agree these are needed. Don't we need these, or something like them in 4.14 and earlier too ? > If those are to be taken (which means in particular if the question of > the .so versioning can be properly sorted), > > 198a2bc6f149 x86/HVM: wire up multicalls > > is going to be required as a prereq. I have backports of all of the > above ready (so I could put them in if you tell me to), but for > 01a2d001dea2 only in its straightforward but simplistic form, which I'm > not sure is the right thing to do. So, I have queued 198a2bc6f149 too. As for the ABI: 01a2d001dea2 introduces VERS_1.3 with xencall2L. I think backporting it to 4.15 means declaring that that is precisely what VERS_1.3 is, and that any future changes must be in VERS_1.4. I checked that after the backport of 198a2bc6f149, the two files defining VERS_1.3 are the same. Well, they are different because of 7ffbed8681a0 libxencall: drop bogus mentioning of xencall6() which is fine, since that symbol didn't exist in any version. So I propose to bump xencall to 1.4 in staging, to make sure we don't break the ABI for 1.3 by mistake. Andrew Cooper writes ("Re: preparations for 4.15.1 and 4.13.4"): > We can backport changes in SONAME safely so long as: > > 1) We declare VERS_1.2 to be fixed and released. This means that we > bump to 1.3 for the next change, even if it is ahead of Xen 4.16 being > release, and > > 2) *All* ABI changes up to VERS_1.2 are backported. I think this is what I am doing, except that I think Andy wrote "1.2" instead of "1.3". "1.2" is currently in staging-4.15, without my queued series. > The ABI called VERS_1.2 must be identical on all older branches to avoid > binary problems when rebuilding a package against old-xen+updates, and > then updating to a newer Xen. Indeed. But that is less relevant than the fact that this must also be true for VERS_1.3 which is what we are introducing to 4.15 here :-). Andy, I usually agree with you on ABI matters. I think I am doing what you mean. Please correct me if I have misunderstood you. If what I hnve done is wrong, we should revert and/or fix it quickly on staging-4.15. (I'll ping you in IRC when I have pushed my queue to staging-4.15.) Ian. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: preparations for 4.15.1 and 4.13.4 [and 1 more messages] 2021-08-19 16:43 ` preparations for 4.15.1 and 4.13.4 [and 1 more messages] Ian Jackson @ 2021-08-19 16:55 ` Ian Jackson 2021-08-19 17:04 ` Ian Jackson 2021-08-19 16:56 ` Andrew Cooper 2021-08-20 6:10 ` Jan Beulich 2 siblings, 1 reply; 28+ messages in thread From: Ian Jackson @ 2021-08-19 16:55 UTC (permalink / raw) To: Andrew Cooper Cc: Jan Beulich, xen-devel, Ian Jackson, George Dunlap, Stefano Stabellini, Wei Liu, Anthony Perard, Julien Grall Ian Jackson writes ("Re: preparations for 4.15.1 and 4.13.4 [and 1 more messages]"): > Jan Beulich writes ("preparations for 4.15.1 and 4.13.4"): > > The ABI called VERS_1.2 must be identical on all older branches to avoid > > binary problems when rebuilding a package against old-xen+updates, and > > then updating to a newer Xen. > > Indeed. But that is less relevant than the fact that this must also > be true for VERS_1.3 which is what we are introducing to 4.15 here :-). > > Andy, I usually agree with you on ABI matters. I think I am doing > what you mean. Please correct me if I have misunderstood you. If > what I hnve done is wrong, we should revert and/or fix it quickly on > staging-4.15. > > (I'll ping you in IRC when I have pushed my queue to staging-4.15.) I thought of a better way to do this. See below for proposed patch to xen.git#staging. Ian. From 239847451fbef4194e757ce090b6f96c4852af46 Mon Sep 17 00:00:00 2001 From: Ian Jackson <iwj@xenproject.org> Date: Thu, 19 Aug 2021 17:53:19 +0100 Subject: [PATCH] libxencall: Put a reminder that ABI VERS_1.3 is now frozen CC: Andrew Cooper <andrew.cooper3@citrix.com> CC: Jan Beulich <jbeulich@suse.com> CC: Wei Liu <wl@xen.org> Signed-off-by: Ian Jackson <iwj@xenproject.org> --- tools/libs/call/libxencall.map | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/libs/call/libxencall.map b/tools/libs/call/libxencall.map index d18a3174e9..c99630a44b 100644 --- a/tools/libs/call/libxencall.map +++ b/tools/libs/call/libxencall.map @@ -30,4 +30,5 @@ VERS_1.2 { VERS_1.3 { global: xencall2L; + /* NB VERS_1.3 is frozen since it has been exposed in Xen 4.15 */ } VERS_1.2; -- 2.20.1 ^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: preparations for 4.15.1 and 4.13.4 [and 1 more messages] 2021-08-19 16:55 ` Ian Jackson @ 2021-08-19 17:04 ` Ian Jackson 0 siblings, 0 replies; 28+ messages in thread From: Ian Jackson @ 2021-08-19 17:04 UTC (permalink / raw) To: Andrew Cooper, Jan Beulich, xen-devel, Ian Jackson, George Dunlap, Stefano Stabellini, Wei Liu, Anthony Perard, Julien Grall Ian Jackson writes ("Re: preparations for 4.15.1 and 4.13.4 [and 1 more messages]"): > I thought of a better way to do this. See below for proposed patch to > xen.git#staging. We discussed this on IRC, and I'm going to drop this patch. Ian. 18:00 <@andyhhp> I'm debating what to say there 18:01 <@Diziet> I thought of this since otherwise we're just setting ourselves up to make a mistake. 18:01 <@andyhhp> I'm tempted to just leave it all alone. That comment will go stale very quickly, and the general rule is applicable to other libs 18:01 <@Diziet> True 18:01 <@andyhhp> evidence suggests that almost all edits to the soname require a fixup... 18:01 <@Diziet> haha 18:01 <@Diziet> FE 18:01 <@andyhhp> it would be nice to do something better 18:02 <@andyhhp> and the "bump the soname proactively" is almost very nice for that. My first thought was to suggest that we change to that as a default way of working 18:01 <@Diziet> haha 18:01 <@Diziet> FE 18:01 <@andyhhp> it would be nice to do something better 18:02 <@andyhhp> and the "bump the soname proactively" is almost very nice for that. My first thought was to suggest that we change to that as a default way of working 18:02 <@andyhhp> but it gets you into a position where you're off-by-one when it comes to the release 18:02 <@Diziet> Mmmm 18:03 <@Diziet> OK, well, I'll drop my patch for now then if you don't feel it's worth it. 18:03 <@Diziet> Thanks for the reviews, anyway. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: preparations for 4.15.1 and 4.13.4 [and 1 more messages] 2021-08-19 16:43 ` preparations for 4.15.1 and 4.13.4 [and 1 more messages] Ian Jackson 2021-08-19 16:55 ` Ian Jackson @ 2021-08-19 16:56 ` Andrew Cooper 2021-08-20 6:10 ` Jan Beulich 2 siblings, 0 replies; 28+ messages in thread From: Andrew Cooper @ 2021-08-19 16:56 UTC (permalink / raw) To: Ian Jackson, Jan Beulich Cc: xen-devel, Ian Jackson, George Dunlap, Stefano Stabellini, Wei Liu, Anthony Perard, Julien Grall On 19/08/2021 17:43, Ian Jackson wrote: > Jan Beulich writes ("preparations for 4.15.1 and 4.13.4"): >> Ian: I did take the liberty to backport Anthony's >> >> 5d3e4ebb5c71 libs/foreignmemory: Fix osdep_xenforeignmemory_map prototype > Thanks. > >> Beyond this I'd like the following to be considered: >> >> 6409210a5f51 libxencall: osdep_hypercall() should return long >> bef64f2c0019 libxencall: introduce variant of xencall2() returning long >> 01a2d001dea2 libxencall: Bump SONAME following new functionality >> 6f02d1ea4a10 libxc: use multicall for memory-op on Linux (and Solaris) > I agree these are needed. > > Don't we need these, or something like them in 4.14 and earlier too ? > >> If those are to be taken (which means in particular if the question of >> the .so versioning can be properly sorted), >> >> 198a2bc6f149 x86/HVM: wire up multicalls >> >> is going to be required as a prereq. I have backports of all of the >> above ready (so I could put them in if you tell me to), but for >> 01a2d001dea2 only in its straightforward but simplistic form, which I'm >> not sure is the right thing to do. > So, I have queued 198a2bc6f149 too. > > As for the ABI: 01a2d001dea2 introduces VERS_1.3 with xencall2L. > I think backporting it to 4.15 means declaring that that is precisely > what VERS_1.3 is, and that any future changes must be in VERS_1.4. Yes > > I checked that after the backport of 198a2bc6f149, the two files > defining VERS_1.3 are the same. Well, they are different because of > 7ffbed8681a0 > libxencall: drop bogus mentioning of xencall6() > which is fine, since that symbol didn't exist in any version. That's probably ok, but I'd be tempted to backport that fix too. > So I propose to bump xencall to 1.4 in staging, to make sure we don't > break the ABI for 1.3 by mistake. We don't proactively bump the stable libs sonames - they get bumped on first new addition. Otherwise, if there is no addition between now and the 4.16 release, then the 4.16 build will produce a libfoo.so.1.4 with 1.3's effective ABI. The same would be true in general for every stable library we didn't modify in a specific release cycle. > > Andrew Cooper writes ("Re: preparations for 4.15.1 and 4.13.4"): >> We can backport changes in SONAME safely so long as: >> >> 1) We declare VERS_1.2 to be fixed and released. This means that we >> bump to 1.3 for the next change, even if it is ahead of Xen 4.16 being >> release, and >> >> 2) *All* ABI changes up to VERS_1.2 are backported. > I think this is what I am doing, except that I think Andy wrote "1.2" > instead of "1.3". "1.2" is currently in staging-4.15, without my > queued series. Oops - my mistake. > >> The ABI called VERS_1.2 must be identical on all older branches to avoid >> binary problems when rebuilding a package against old-xen+updates, and >> then updating to a newer Xen. > Indeed. But that is less relevant than the fact that this must also > be true for VERS_1.3 which is what we are introducing to 4.15 here :-). > > Andy, I usually agree with you on ABI matters. I think I am doing > what you mean. Please correct me if I have misunderstood you. If > what I hnve done is wrong, we should revert and/or fix it quickly on > staging-4.15. Looks good to me. ~Andrew ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: preparations for 4.15.1 and 4.13.4 [and 1 more messages] 2021-08-19 16:43 ` preparations for 4.15.1 and 4.13.4 [and 1 more messages] Ian Jackson 2021-08-19 16:55 ` Ian Jackson 2021-08-19 16:56 ` Andrew Cooper @ 2021-08-20 6:10 ` Jan Beulich 2 siblings, 0 replies; 28+ messages in thread From: Jan Beulich @ 2021-08-20 6:10 UTC (permalink / raw) To: Ian Jackson, Andrew Cooper Cc: xen-devel, Ian Jackson, George Dunlap, Stefano Stabellini, Wei Liu, Anthony Perard, Julien Grall On 19.08.2021 18:43, Ian Jackson wrote: > Jan Beulich writes ("preparations for 4.15.1 and 4.13.4"): >> Ian: I did take the liberty to backport Anthony's >> >> 5d3e4ebb5c71 libs/foreignmemory: Fix osdep_xenforeignmemory_map prototype > > Thanks. > >> Beyond this I'd like the following to be considered: >> >> 6409210a5f51 libxencall: osdep_hypercall() should return long >> bef64f2c0019 libxencall: introduce variant of xencall2() returning long >> 01a2d001dea2 libxencall: Bump SONAME following new functionality >> 6f02d1ea4a10 libxc: use multicall for memory-op on Linux (and Solaris) > > I agree these are needed. > > Don't we need these, or something like them in 4.14 and earlier too ? Well, yes, I think so. Did I give the wrong impression of asking for 4.15 only? Jan ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: preparations for 4.15.1 and 4.13.4 2021-07-15 7:58 preparations for 4.15.1 and 4.13.4 Jan Beulich ` (5 preceding siblings ...) 2021-07-15 17:16 ` Andrew Cooper @ 2021-07-16 7:41 ` Julien Grall 2021-07-16 20:16 ` Stefano Stabellini 2021-07-19 10:32 ` Jan Beulich 7 siblings, 1 reply; 28+ messages in thread From: Julien Grall @ 2021-07-16 7:41 UTC (permalink / raw) To: Jan Beulich, xen-devel, Stefano Stabellini Cc: George Dunlap, Stefano Stabellini, Wei Liu, Anthony Perard, Ian Jackson On 15/07/2021 08:58, Jan Beulich wrote: > All, Hi Jan & Stefano, > the releases are due in a couple of weeks time (and 4.14.3 is > supposed to follow another few weeks later). Please point out backports > you find missing from the respective staging branches, but which you > consider relevant. > > Please note that 4.13.4 is going to be the last Xen Project > coordinated release from the 4.13 branch; the branch will go into > security-only maintenance mode after this release. I would like to request the backports of the following commits: 4473f3601098 xen/arm: bootfdt: Always sort memory banks b80470c84553 arm: Modify type of actlr to register_t dfcffb128be4 xen/arm32: SPSR_hyp/SPSR 93031fbe9f4c Arm32: MSR to SPSR needs qualification Cheers, -- Julien Grall ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: preparations for 4.15.1 and 4.13.4 2021-07-16 7:41 ` preparations for 4.15.1 and 4.13.4 Julien Grall @ 2021-07-16 20:16 ` Stefano Stabellini 0 siblings, 0 replies; 28+ messages in thread From: Stefano Stabellini @ 2021-07-16 20:16 UTC (permalink / raw) To: Julien Grall Cc: Jan Beulich, xen-devel, Stefano Stabellini, George Dunlap, Wei Liu, Anthony Perard, Ian Jackson On Fri, 16 Jul 2021, Julien Grall wrote: > On 15/07/2021 08:58, Jan Beulich wrote: > > All, > > Hi Jan & Stefano, > > > > the releases are due in a couple of weeks time (and 4.14.3 is > > supposed to follow another few weeks later). Please point out backports > > you find missing from the respective staging branches, but which you > > consider relevant. > > > > Please note that 4.13.4 is going to be the last Xen Project > > coordinated release from the 4.13 branch; the branch will go into > > security-only maintenance mode after this release. > > I would like to request the backports of the following commits: > > 4473f3601098 xen/arm: bootfdt: Always sort memory banks > b80470c84553 arm: Modify type of actlr to register_t > dfcffb128be4 xen/arm32: SPSR_hyp/SPSR > 93031fbe9f4c Arm32: MSR to SPSR needs qualification Done ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: preparations for 4.15.1 and 4.13.4 2021-07-15 7:58 preparations for 4.15.1 and 4.13.4 Jan Beulich ` (6 preceding siblings ...) 2021-07-16 7:41 ` preparations for 4.15.1 and 4.13.4 Julien Grall @ 2021-07-19 10:32 ` Jan Beulich 2021-08-19 16:49 ` Ian Jackson 7 siblings, 1 reply; 28+ messages in thread From: Jan Beulich @ 2021-07-19 10:32 UTC (permalink / raw) To: Ian Jackson Cc: George Dunlap, Stefano Stabellini, Wei Liu, Anthony Perard, Julien Grall, xen-devel Ian, On 15.07.2021 09:58, Jan Beulich wrote: > Beyond this I'd like the following to be considered: > > 6409210a5f51 libxencall: osdep_hypercall() should return long > bef64f2c0019 libxencall: introduce variant of xencall2() returning long > 01a2d001dea2 libxencall: Bump SONAME following new functionality > 6f02d1ea4a10 libxc: use multicall for memory-op on Linux (and Solaris) in addition I'd like to ask you to consider 0be5a00af590 libxl/x86: check return value of SHADOW_OP_SET_ALLOCATION domctl as well, now that it has gone in. Thanks, Jan ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: preparations for 4.15.1 and 4.13.4 2021-07-19 10:32 ` Jan Beulich @ 2021-08-19 16:49 ` Ian Jackson 0 siblings, 0 replies; 28+ messages in thread From: Ian Jackson @ 2021-08-19 16:49 UTC (permalink / raw) To: Jan Beulich Cc: George Dunlap, Stefano Stabellini, Wei Liu, Anthony Perard, Julien Grall, xen-devel Jan Beulich writes ("Re: preparations for 4.15.1 and 4.13.4"): > On 15.07.2021 09:58, Jan Beulich wrote: > > Beyond this I'd like the following to be considered: > > > > 6409210a5f51 libxencall: osdep_hypercall() should return long > > bef64f2c0019 libxencall: introduce variant of xencall2() returning long > > 01a2d001dea2 libxencall: Bump SONAME following new functionality > > 6f02d1ea4a10 libxc: use multicall for memory-op on Linux (and Solaris) > > in addition I'd like to ask you to consider > > 0be5a00af590 libxl/x86: check return value of SHADOW_OP_SET_ALLOCATION domctl > > as well, now that it has gone in. I have queued that all the way back to 4.12, since it seems security-adjacent at the very least. Thanks, Ian. ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2021-08-27 12:39 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-07-15 7:58 preparations for 4.15.1 and 4.13.4 Jan Beulich 2021-07-02 14:29 ` [PATCH-4.15] tools/libs/ctrl: fix xc_core_arch_map_p2m() to support linear p2m table Juergen Gross 2021-07-16 6:47 ` Juergen Gross 2021-08-19 7:45 ` Juergen Gross 2021-08-19 16:11 ` Ian Jackson 2021-08-19 15:44 ` preparations for 4.15.1 and 4.13.4 support linear p2m table [and 1 more messages] Ian Jackson 2021-07-15 8:02 ` preparations for 4.15.1 and 4.13.4 Jan Beulich 2021-07-15 9:02 ` Anthony PERARD 2021-08-19 16:23 ` QEMU 6.0+ in 4.15 and 4.14 (Re: preparations for 4.15.1 and 4.13.4) Ian Jackson 2021-08-23 9:48 ` Olaf Hering 2021-08-27 12:39 ` Anthony PERARD 2021-07-15 10:58 ` preparations for 4.15.1 and 4.13.4 Andrew Cooper 2021-07-15 11:12 ` Jan Beulich 2021-07-15 14:11 ` Olaf Hering 2021-07-15 14:21 ` Jan Beulich 2021-08-19 16:46 ` Ian Jackson 2021-08-23 8:42 ` Olaf Hering 2021-07-15 17:16 ` Andrew Cooper 2021-07-16 6:16 ` Jan Beulich 2021-08-19 16:43 ` preparations for 4.15.1 and 4.13.4 [and 1 more messages] Ian Jackson 2021-08-19 16:55 ` Ian Jackson 2021-08-19 17:04 ` Ian Jackson 2021-08-19 16:56 ` Andrew Cooper 2021-08-20 6:10 ` Jan Beulich 2021-07-16 7:41 ` preparations for 4.15.1 and 4.13.4 Julien Grall 2021-07-16 20:16 ` Stefano Stabellini 2021-07-19 10:32 ` Jan Beulich 2021-08-19 16:49 ` Ian Jackson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).