Re: [Xen-devel] [RFC 3/7] arm64:armds: ARM Compiler 6.6 does not accept `rx` registers naming for AArch64

Hi, Aside what Stefano and Jan already said. Please, reword the commit title. It should reflect what the commit does not describe the error (this should part of the message). On Wed, 6 Nov 2019, 18:19 Andrii Anisov, wrote: > From: Andrii Anisov > > So get the code duplication with `x`-es. >

Re: [Xen-devel] [RFC 6/7] arm: Introduce dummy empty functions for data only C files

Hi, On Wed, 6 Nov 2019, 18:20 Andrii Anisov, wrote: > From: Andrii Anisov > > ARM Compiler 6 has a proven bug: it compiles data only C files with > SoftVFP attributes. This leads to a failed linkage afterwards with > an error: > And there are no way to force disabling the softfvp attributes?

Re: [Xen-devel] [RFC 5/7] WIP:arm64:armds: Build XEN with ARM Compiler 6.6

On Tue, 12 Nov 2019, 06:27 Stefano Stabellini, wrote: > On Wed, 6 Nov 2019, Andrii Anisov wrote: > > From: Andrii Anisov > > > > Here several ARM Compiler 6.6 issues are solved or provided a > work-around: > > > > - Scatter file is pretty primitive, it has no feature to define symbols > > -

[Xen-devel] [qemu-mainline test] 144050: tolerable trouble: fail/pass/starved - PUSHED

flight 144050 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/144050/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 142915

[Xen-devel] [xen-unstable test] 144042: tolerable FAIL

flight 144042 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/144042/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 144020 test-amd64-i386-xl-qemuu-win7-amd64

Re: [Xen-devel] [PATCH] arch: arm: vgic-v3: fix GICD_ISACTIVER range

On Wed, 13 Nov 2019, 10:55 André Przywara, wrote: > On 13/11/2019 01:08, Julien Grall wrote: > > Hi, > > > On Tue, 12 Nov 2019, 04:01 Stefano Stabellini, > > wrote: > > > > On Sat, 9 Nov 2019, Julien Grall wrote: > > > On Sat, 9 Nov 2019, 04:27 Stefano

Re: [Xen-devel] [PATCH] arch: arm: vgic-v3: fix GICD_ISACTIVER range

On 13/11/2019 01:08, Julien Grall wrote: Hi, > On Tue, 12 Nov 2019, 04:01 Stefano Stabellini, > wrote: > > On Sat, 9 Nov 2019, Julien Grall wrote: > > On Sat, 9 Nov 2019, 04:27 Stefano Stabellini, > mailto:sstabell...@kernel.org>> wrote: > >       

Re: [Xen-devel] [RFC 7/7] arm/gic-v3: add GIC version suffix to iomem range variables

On Tue, 12 Nov 2019, 05:59 Stefano Stabellini, wrote: > On Wed, 6 Nov 2019, Andrii Anisov wrote: > > From: Andrii Anisov > > > > ARM Compiler 6.6 has a proven bug: static data symbols, moved to an init > > section, becomes global. Thus these symbols clash with ones defined in > > gic-v2.c. The

Re: [Xen-devel] [RFC 4/7] arm/gic: Drop pointless assertions

On Tue, 12 Nov 2019, 05:52 Stefano Stabellini, wrote: > On Wed, 6 Nov 2019, Andrii Anisov wrote: > > From: Andrii Anisov > > > > Also armclang complains about the condition always true, > > because `sgi` is of type enum with all its values under 16. > > > > Signed-off-by: Andrii Anisov > >

Re: [Xen-devel] [PATCH] arch: arm: vgic-v3: fix GICD_ISACTIVER range

On Tue, 12 Nov 2019, 04:01 Stefano Stabellini, wrote: > On Sat, 9 Nov 2019, Julien Grall wrote: > > On Sat, 9 Nov 2019, 04:27 Stefano Stabellini, > wrote: > > On Thu, 7 Nov 2019, Peng Fan wrote: > > > The end should be GICD_ISACTIVERN not GICD_ISACTIVER. > > > > > >

Re: [Xen-devel] [PATCH 3/3] xen/mcelog: also allow building for 32-bit kernels

On 11/11/19 9:46 AM, Jan Beulich wrote: > There's no apparent reason why it can be used on 64-bit only. > > Signed-off-by: Jan Beulich > > --- a/drivers/xen/Kconfig > +++ b/drivers/xen/Kconfig > @@ -285,7 +285,7 @@ config XEN_ACPI_PROCESSOR > > config XEN_MCE_LOG > bool "Xen platform

Re: [Xen-devel] [PATCH 2/3] xen/mcelog: add PPIN to record when available

On 11/11/19 9:46 AM, Jan Beulich wrote: > This is to augment commit 3f5a7896a5 ("x86/mce: Include the PPIN in MCE > records when available"). > > I'm also adding "synd" and "ipid" fields to struct xen_mce, in an > attempt to keep field offsets in sync with struct mce. These two fields > won't get

Re: [Xen-devel] [PATCH 1/3] xen/mcelog: drop __MC_MSR_MCGCAP

On 11/11/19 9:45 AM, Jan Beulich wrote: > It has never been part of Xen's public interface, and there's therefore > no guarantee for MCG_CAP's value to always be present in array entry 0. > > Signed-off-by: Jan Beulich Reviewed-by: Boris Ostrovsky

[Xen-devel] [xen-unstable-smoke test] 144057: tolerable all pass - PUSHED

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

[Xen-devel] [ovmf test] 144046: all pass - PUSHED

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

[Xen-devel] [PATCH v3 14/14] xen/gntdev: use mmu_interval_notifier_insert

From: Jason Gunthorpe gntdev simply wants to monitor a specific VMA for any notifier events, this can be done straightforwardly using mmu_interval_notifier_insert() over the VMA's VA range. The notifier should be attached until the original VMA is destroyed. It is unclear if any of this is

[Xen-devel] [PATCH v3 05/14] RDMA/odp: Use mmu_interval_notifier_insert()

From: Jason Gunthorpe Replace the internal interval tree based mmu notifier with the new common mmu_interval_notifier_insert() API. This removes a lot of code and fixes a deadlock that can be triggered in ODP: zap_page_range() mmu_notifier_invalidate_range_start() [..]

[Xen-devel] [PATCH v3 11/14] drm/amdgpu: Use mmu_interval_insert instead of hmm_mirror

From: Jason Gunthorpe Remove the interval tree in the driver and rely on the tree maintained by the mmu_notifier for delivering mmu_notifier invalidation callbacks. For some reason amdgpu has a very complicated arrangement where it tries to prevent duplicate entries in the interval_tree, this

[Xen-devel] [PATCH v3 04/14] mm/hmm: define the pre-processor related parts of hmm.h even if disabled

From: Jason Gunthorpe Only the function calls are stubbed out with static inlines that always fail. This is the standard way to write a header for an optional component and makes it easier for drivers that only optionally need HMM_MIRROR. Reviewed-by: Jérôme Glisse Tested-by: Ralph Campbell

[Xen-devel] [PATCH v3 02/14] mm/mmu_notifier: add an interval tree notifier

From: Jason Gunthorpe Of the 13 users of mmu_notifiers, 8 of them use only invalidate_range_start/end() and immediately intersect the mmu_notifier_range with some kind of internal list of VAs. 4 use an interval tree (i915_gem, radeon_mn, umem_odp, hfi1). 4 use a linked list of some kind

[Xen-devel] [PATCH v3 12/14] drm/amdgpu: Use mmu_interval_notifier instead of hmm_mirror

From: Jason Gunthorpe Convert the collision-retry lock around hmm_range_fault to use the one now provided by the mmu_interval notifier. Although this driver does not seem to use the collision retry lock that hmm provides correctly, it can still be converted over to use the mmu_interval_notifier

[Xen-devel] [PATCH v3 09/14] nouveau: use mmu_interval_notifier instead of hmm_mirror

From: Jason Gunthorpe Remove the hmm_mirror object and use the mmu_interval_notifier API instead for the range, and use the normal mmu_notifier API for the general invalidation callback. While here re-organize the pagefault path so the locking pattern is clear. nouveau is the only driver that

[Xen-devel] [PATCH v3 13/14] mm/hmm: remove hmm_mirror and related

From: Jason Gunthorpe The only two users of this are now converted to use mmu_interval_notifier, delete all the code and update hmm.rst. Reviewed-by: Jérôme Glisse Tested-by: Ralph Campbell Signed-off-by: Jason Gunthorpe --- Documentation/vm/hmm.rst | 105 ---

[Xen-devel] [PATCH v3 10/14] drm/amdgpu: Call find_vma under mmap_sem

From: Jason Gunthorpe find_vma() must be called under the mmap_sem, reorganize this code to do the vma check after entering the lock. Further, fix the unlocked use of struct task_struct's mm, instead use the mm from hmm_mirror which has an active mm_grab. Also the mm_grab must be converted to a

[Xen-devel] [PATCH v3 06/14] RDMA/hfi1: Use mmu_interval_notifier_insert for user_exp_rcv

From: Jason Gunthorpe This converts one of the two users of mmu_notifiers to use the new API. The conversion is fairly straightforward, however the existing use of notifiers here seems to be racey. Tested-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe ---

[Xen-devel] [PATCH v3 08/14] nouveau: use mmu_notifier directly for invalidate_range_start

From: Jason Gunthorpe There is no reason to get the invalidate_range_start() callback via an indirection through hmm_mirror, just register a normal notifier directly. Tested-by: Ralph Campbell Signed-off-by: Jason Gunthorpe --- drivers/gpu/drm/nouveau/nouveau_svm.c | 95

[Xen-devel] [PATCH v3 07/14] drm/radeon: use mmu_interval_notifier_insert

From: Jason Gunthorpe The new API is an exact match for the needs of radeon. For some reason radeon tries to remove overlapping ranges from the interval tree, but interval trees (and mmu_interval_notifier_insert()) support overlapping ranges directly. Simply delete all this code. Since this

[Xen-devel] [PATCH v3 01/14] mm/mmu_notifier: define the header pre-processor parts even if disabled

From: Jason Gunthorpe Now that we have KERNEL_HEADER_TEST all headers are generally compile tested, so relying on makefile tricks to avoid compiling code that depends on CONFIG_MMU_NOTIFIER is more annoying. Instead follow the usual pattern and provide most of the header with only the functions

[Xen-devel] [PATCH v3 03/14] mm/hmm: allow hmm_range to be used with a mmu_interval_notifier or hmm_mirror

From: Jason Gunthorpe hmm_mirror's handling of ranges does not use a sequence count which results in this bug: CPU0 CPU1 hmm_range_wait_until_valid(range) valid == true

[Xen-devel] [PATCH hmm v3 00/14] Consolidate the mmu notifier interval_tree and locking

From: Jason Gunthorpe 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1, scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where they only use invalidate_range_start/end and immediately check the invalidating range against some driver data structure to tell

Re: [Xen-devel] [PATCH] Introduce a description of a new optional tag for Backports

On 12/11/2019, 11:10, "Stefano Stabellini" wrote: On Tue, 12 Nov 2019, Ian Jackson wrote: > Anthony PERARD writes ("Re: [Xen-devel] [PATCH] Introduce a description of a new optional tag for Backports"): > > Should we describe the Fixes: tag as well? These would have a similar

Re: [Xen-devel] Xen-unstable: AMD-Vi: update_paging_mode Try to access pdev_list without aquiring pcidevs_lock.

On 12/11/2019 12:05, Jan Beulich wrote: > On 11.11.2019 22:38, Sander Eikelenboom wrote: >> When supplying "pci=nomsi" to the guest kernel, the device works fine, >> and I don't get the "INVALID_DEV_REQUEST". >> >> After reverting 1b00c16bdf, the device works fine >> and I don't get the

[Xen-devel] [xen-4.12-testing test] 144035: tolerable trouble: fail/pass/starved - PUSHED

flight 144035 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/144035/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail in 144007 pass in 144035

Re: [Xen-devel] [PATCH] xen/sched: remove wrong assertions in csched2_free_pdata()

On Fri, 2019-11-08 at 08:38 +0100, Juergen Gross wrote: > The assertions in csched2_free_pdata() are wrong as in case it is > called by schedule_cpu_add() after a failure of sched_alloc_udata() > the init pdata function won't have been called. > Sorry, maybe too much time has passed since when I

[Xen-devel] Xen Security Advisory 304 v1 (CVE-2018-12207) - x86: Machine Check Error on Page Size Change DoS

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-12207 / XSA-304 x86: Machine Check Error on Page Size Change DoS ISSUE DESCRIPTION = An erratum exists across some CPUs whereby an instruction fetch may cause a machine check

[Xen-devel] [tip: x86/boot] x86/boot: Introduce kernel_info.setup_type_max

The following commit has been merged into the x86/boot branch of tip: Commit-ID: 00cd1c154d565c62ad5e065bf3530f68bdf59490 Gitweb: https://git.kernel.org/tip/00cd1c154d565c62ad5e065bf3530f68bdf59490 Author:Daniel Kiper AuthorDate:Tue, 12 Nov 2019 14:46:39 +01:00 Committer:

[Xen-devel] [tip: x86/boot] x86/boot: Introduce kernel_info

The following commit has been merged into the x86/boot branch of tip: Commit-ID: 2c33c27fd6033ced942c9a591b8ac15c07c57d70 Gitweb: https://git.kernel.org/tip/2c33c27fd6033ced942c9a591b8ac15c07c57d70 Author:Daniel Kiper AuthorDate:Tue, 12 Nov 2019 14:46:38 +01:00 Committer:

[Xen-devel] [tip: x86/boot] x86/boot: Introduce setup_indirect

The following commit has been merged into the x86/boot branch of tip: Commit-ID: b3c72fc9a78e74161f9d05ef7191706060628f8c Gitweb: https://git.kernel.org/tip/b3c72fc9a78e74161f9d05ef7191706060628f8c Author:Daniel Kiper AuthorDate:Tue, 12 Nov 2019 14:46:40 +01:00 Committer:

Re: [Xen-devel] [PATCH] arch: arm: vgic-v3: fix GICD_ISACTIVER range

On Tue, 12 Nov 2019, Peng Fan wrote: > Hi Julien, > > Inline marked with [Peng Fan] Please use plain text emails on xen-devel (and other open source development mailing lists.) > From: Julien Grall > Sent: 2019年11月9日 6:44 > To: Stefano Stabellini ; Andre Przywara > > Cc: Peng Fan ; Jürgen

[Xen-devel] [xen-unstable-smoke test] 144053: tolerable all pass - PUSHED

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

Re: [Xen-devel] [PATCH 1/3] x86/boot: Remove cached CPUID data from the trampoline

On 12.11.2019 17:09, Andrew Cooper wrote: > On 04/11/2019 15:31, Jan Beulich wrote: >> On 04.11.2019 16:22, Andrew Cooper wrote: >>> On 04/11/2019 15:03, Jan Beulich wrote: On 04.11.2019 15:59, Andrew Cooper wrote: > On 04/11/2019 13:25, Jan Beulich wrote: >> On 01.11.2019 21:25,

Re: [Xen-devel] [PATCH] Introduce a description of a new optional tag for Backports

On Tue, 12 Nov 2019, Ian Jackson wrote: > Anthony PERARD writes ("Re: [Xen-devel] [PATCH] Introduce a description of a > new optional tag for Backports"): > > Should we describe the Fixes: tag as well? These would have a similar > > purpose to the backport tag, I mean it could help figure out

Re: [Xen-devel] [BUGFIX PATCH for-4.13] sched: fix dom0less boot with the null scheduler

> On Nov 6, 2019, at 3:58 PM, Dario Faggioli wrote: > > In a dom0less configuration, if the null scheduler is used, the system > may fail to boot, because the loop in null_unit_wake() never exits. > > Bisection showed that this behavior occurs since commit d545f1d6 ("xen: > sched: deal with

Re: [Xen-devel] [PATCH v2 6/6] xen: add runtime parameter reading support to hypfs

On 12.11.19 15:28, Jan Beulich wrote: On 02.10.2019 13:20, Juergen Gross wrote: Add support to read values of hypervisor runtime parameters via the hypervisor file system for all unsigned integer type runtime parameters. What about string ones (which you seem to handle in the code, but see

Re: [Xen-devel] [PATCH v2 5/6] xen: add /buildinfo/config entry to hypervisor filesystem

On 12.11.19 15:22, Jan Beulich wrote: On 02.10.2019 13:20, Juergen Gross wrote: Add the /buildinfo/config entry to the hypervisor filesystem. This entry contains the .config file used to build the hypervisor. I think this is the 2nd step ahead of the 1st: Much of the stuff exposed as XENVER_*

Re: [Xen-devel] [OSSTEST PATCH 2/2] ts-libvirt-build: Do an out-of-tree build

On 11/12/19 9:10 AM, Ian Jackson wrote: > Hi. Thanks for the information. > > Jim Fehlig writes ("Re: [OSSTEST PATCH 2/2] ts-libvirt-build: Do an > out-of-tree build"): >> I assumed libvirt's gradual move from autotools to meson would >> affect OSSTEST, but later rather than sooner. Sorry for

[Xen-devel] [libvirt test] 144038: regressions - FAIL

flight 144038 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/144038/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 143023 build-amd64-libvirt

Re: [Xen-devel] [PATCH] xen/sched: remove wrong assertions in csched2_free_pdata()

On 12.11.19 16:52, George Dunlap wrote: On Nov 8, 2019, at 7:38 AM, Juergen Gross wrote: The assertions in csched2_free_pdata() are wrong as in case it is called by schedule_cpu_add() after a failure of sched_alloc_udata() the init pdata function won't have been called. I’m a bit confused

Re: [Xen-devel] [OSSTEST PATCH 2/2] ts-libvirt-build: Do an out-of-tree build

Hi. Thanks for the information. Jim Fehlig writes ("Re: [OSSTEST PATCH 2/2] ts-libvirt-build: Do an out-of-tree build"): > I assumed libvirt's gradual move from autotools to meson would > affect OSSTEST, but later rather than sooner. Sorry for not > mentioning it earlier, but now you have been

Re: [Xen-devel] [PATCH 1/3] x86/boot: Remove cached CPUID data from the trampoline

On 04/11/2019 15:31, Jan Beulich wrote: > On 04.11.2019 16:22, Andrew Cooper wrote: >> On 04/11/2019 15:03, Jan Beulich wrote: >>> On 04.11.2019 15:59, Andrew Cooper wrote: On 04/11/2019 13:25, Jan Beulich wrote: > On 01.11.2019 21:25, Andrew Cooper wrote: >> ---

Re: [Xen-devel] [PATCH v2 2/6] xen: add basic hypervisor filesystem support

On 12.11.19 14:48, Jan Beulich wrote: On 02.10.2019 13:20, Juergen Gross wrote: --- /dev/null +++ b/xen/common/hypfs.c @@ -0,0 +1,318 @@ +/** + * + * hypfs.c + * + * Simple sysfs-like file system for the hypervisor. +

Re: [Xen-devel] [OSSTEST PATCH 2/2] ts-libvirt-build: Do an out-of-tree build

On 11/12/19 5:09 AM, Ian Jackson wrote: > Recent versions of libvirt do not support in-tree builds (!) I assumed libvirt's gradual move from autotools to meson would affect OSSTEST, but later rather than sooner. Sorry for not mentioning it earlier, but now you have been warned that libvirt is

Re: [Xen-devel] [PATCH] xen/sched: remove wrong assertions in csched2_free_pdata()

> On Nov 8, 2019, at 7:38 AM, Juergen Gross wrote: > > The assertions in csched2_free_pdata() are wrong as in case it is > called by schedule_cpu_add() after a failure of sched_alloc_udata() > the init pdata function won't have been called. I’m a bit confused by this, as the comment says that

Re: [Xen-devel] [OSSTEST PATCH 1/2] ts-libvirt-build: Provide PKG_CONFIG_PATH

Jim Fehlig writes ("Re: [OSSTEST PATCH 1/2] ts-libvirt-build: Provide PKG_CONFIG_PATH"): > On 11/12/19 5:09 AM, Ian Jackson wrote: > > +PKG_CONFIG_PATH="$xenprefix/lib/pkgconfig/" \\ > > GNULIB_SRCDIR=$builddir/libvirt/$gnulib->{Path} \\ > > ./autogen.sh --no-git

Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err

12.11.2019 16:46, Cornelia Huck wrote: > On Fri, 8 Nov 2019 22:57:25 +0400 > Marc-André Lureau wrote: > >> Hi >> >> On Fri, Nov 8, 2019 at 7:31 PM Vladimir Sementsov-Ogievskiy >> wrote: >>> >>> Finally, what is the plan? >>> >>> Markus what do you think? >>> >>> Now a lot of patches are

Re: [Xen-devel] [OSSTEST PATCH 1/2] ts-libvirt-build: Provide PKG_CONFIG_PATH

On 11/12/19 5:09 AM, Ian Jackson wrote: > In osstest we do not install the xen tree in /usr/local because the > build environment is shared with many different build jobs which might > be using different versions of Xen. We put it in a job-specific > directory in ~osstest on the build host, and

Re: [Xen-devel] [XEN PATCH for-4.13] libxl: Fix libxl_retrieve_domain_configuration error path

On 12.11.19 15:19, Anthony PERARD wrote: From: Anthony PERARD If an error were to happen before the last step, for example the domain_configuration is missing, the error wouldn't be check by the _end callback. Fix that, also initialise `lock' to NULL because the exit path checks it. The

Re: [Xen-devel] [XEN PATCH for-4.13] libxl: Fix libxl_retrieve_domain_configuration error path

On Tue, Nov 12, 2019 at 02:19:43PM +, Anthony PERARD wrote: > From: Anthony PERARD > > If an error were to happen before the last step, for example the > domain_configuration is missing, the error wouldn't be check by the check -> checked > _end callback. > > Fix that, also initialise

Re: [Xen-devel] [XEN PATCH for-4.13] libxl: Fix libxl_retrieve_domain_configuration error path

On Tue, Nov 12, 2019 at 02:19:43PM +, Anthony PERARD wrote: > From: Anthony PERARD > > If an error were to happen before the last step, for example the > domain_configuration is missing, the error wouldn't be check by the > _end callback. > > Fix that, also initialise `lock' to NULL because

Re: [Xen-devel] [PATCH V2 1/2] x86/altp2m: Add hypercall to set a range of sve bits

On 12.11.2019 15:05, Tamas K Lengyel wrote: > On Tue, Nov 12, 2019 at 4:54 AM Jan Beulich wrote: >> On 06.11.2019 16:35, Alexandru Stefan ISAILA wrote: >>> +else >>> +{ >>> +rc = p2m_set_suppress_ve_multi(d, _ve); >>> + >>> +if ( rc == -ERESTART ) >>> +

Re: [Xen-devel] [PATCH v2 6/6] xen: add runtime parameter reading support to hypfs

On 02.10.2019 13:20, Juergen Gross wrote: > Add support to read values of hypervisor runtime parameters via the > hypervisor file system for all unsigned integer type runtime parameters. What about string ones (which you seem to handle in the code, but see also there)? > @@ -320,6 +321,44 @@ int

Re: [Xen-devel] [PATCH v2 5/6] xen: add /buildinfo/config entry to hypervisor filesystem

On 02.10.2019 13:20, Juergen Gross wrote: > Add the /buildinfo/config entry to the hypervisor filesystem. This > entry contains the .config file used to build the hypervisor. I think this is the 2nd step ahead of the 1st: Much of the stuff exposed as XENVER_* sub-ops should manifest itself here

[Xen-devel] [XEN PATCH for-4.13] libxl: Fix libxl_retrieve_domain_configuration error path

From: Anthony PERARD If an error were to happen before the last step, for example the domain_configuration is missing, the error wouldn't be check by the _end callback. Fix that, also initialise `lock' to NULL because the exit path checks it. The issue shows up when there's a stubdom, and

[Xen-devel] [xen-unstable-smoke test] 144044: tolerable all pass - PUSHED

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

Re: [Xen-devel] [PATCH V2 1/2] x86/altp2m: Add hypercall to set a range of sve bits

On Tue, Nov 12, 2019 at 4:54 AM Jan Beulich wrote: > > On 06.11.2019 16:35, Alexandru Stefan ISAILA wrote: > > @@ -4681,7 +4682,7 @@ static int do_altp2m_op( > > break; > > > > case HVMOP_altp2m_set_suppress_ve: > > -if ( a.u.suppress_ve.pad1 || a.u.suppress_ve.pad2 ) > > +

Re: [Xen-devel] [RFC v5 026/126] python: add commit-per-subsystem.py

On Fri, 11 Oct 2019 19:04:12 +0300 Vladimir Sementsov-Ogievskiy wrote: > Add script to automatically commit tree-wide changes per-subsystem. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- I think this still needs some notes as to the supposed usage.

Re: [Xen-devel] [RFC v5 000/126] error: auto propagated local_err

On Fri, 8 Nov 2019 22:57:25 +0400 Marc-André Lureau wrote: > Hi > > On Fri, Nov 8, 2019 at 7:31 PM Vladimir Sementsov-Ogievskiy > wrote: > > > > Finally, what is the plan? > > > > Markus what do you think? > > > > Now a lot of patches are reviewed, but a lot of are not. > > > > Is there any

Re: [Xen-devel] [PATCH for-4.13] xen: Drop bogus BOOLEAN definitions, TRUE and FALSE

On 12.11.2019 14:39, Andrew Cooper wrote: > On 12/11/2019 08:35, Jan Beulich wrote: >> On 11.11.2019 21:24, Andrew Cooper wrote: >>> --- a/xen/arch/x86/x86_64/mm.c >>> +++ b/xen/arch/x86/x86_64/mm.c >>> @@ -1077,7 +1077,7 @@ long do_set_segment_base(unsigned int which, unsigned >>> long base) >>>

[Xen-devel] [PATCH v6 1/3] x86/boot: Introduce the kernel_info

The relationships between the headers are analogous to the various data sections: setup_header = .data boot_params/setup_data = .bss What is missing from the above list? That's right: kernel_info = .rodata We have been (ab)using .data for things that could go into .rodata or .bss for a

[Xen-devel] [PATCH v6 2/3] x86/boot: Introduce the kernel_info.setup_type_max

This field contains maximal allowed type for setup_data. Do not bump setup_header version in arch/x86/boot/header.S because it will be followed by additional changes coming into the Linux/x86 boot protocol. Suggested-by: H. Peter Anvin (Intel) Signed-off-by: Daniel Kiper Reviewed-by: Konrad

Re: [Xen-devel] [PATCH v2 2/6] xen: add basic hypervisor filesystem support

On 02.10.2019 13:20, Juergen Gross wrote: > --- /dev/null > +++ b/xen/common/hypfs.c > @@ -0,0 +1,318 @@ > +/** > + * > + * hypfs.c > + * > + * Simple sysfs-like file system for the hypervisor. > + */ > + > +#include >

[Xen-devel] [PATCH v6 0/3] x86/boot: Introduce the kernel_info et consortes

Hi, Due to very limited space in the setup_header this patch series introduces new kernel_info struct which will be used to convey information from the kernel to the bootloader. This way the boot protocol can be extended regardless of the setup_header limitations. Additionally, the patch series

[Xen-devel] [PATCH v6 3/3] x86/boot: Introduce the setup_indirect

The setup_data is a bit awkward to use for extremely large data objects, both because the setup_data header has to be adjacent to the data object and because it has a 32-bit length field. However, it is important that intermediate stages of the boot process have a way to identify which chunks of

Re: [Xen-devel] [PATCH for-4.13] xen: Drop bogus BOOLEAN definitions, TRUE and FALSE

On 12/11/2019 08:35, Jan Beulich wrote: > On 11.11.2019 21:24, Andrew Cooper wrote: >> --- a/xen/arch/x86/x86_64/mm.c >> +++ b/xen/arch/x86/x86_64/mm.c >> @@ -1077,7 +1077,7 @@ long do_set_segment_base(unsigned int which, unsigned >> long base) >> } >> >> >> -/* Returns TRUE if given

Re: [Xen-devel] [PATCH] arch: arm: vgic-v3: fix GICD_ISACTIVER range

On Mon, 11 Nov 2019 11:01:07 -0800 (PST) Stefano Stabellini wrote: Hi, > On Sat, 9 Nov 2019, Julien Grall wrote: > > On Sat, 9 Nov 2019, 04:27 Stefano Stabellini, > > wrote: > > On Thu, 7 Nov 2019, Peng Fan wrote: > > > The end should be GICD_ISACTIVERN not GICD_ISACTIVER. > >

Re: [Xen-devel] [xen-4.13.0-rc] kexec/kdump failure with cpu Intel(R) Xeon(R) Gold 6242 CPU

On 12/11/2019 11:38, Dietmar Hahn wrote: > Hi, > > on a new machine with cpu Intel(R) Xeon(R) Gold 6242 CPU the kexec/kdump > doesn't work with current xen-4.13.0-rc. > The last output of the xen console is: > > (XEN) Hardware Dom0 crashed: Executing kexec image on cpu5 > (XEN) Shot down all CPUs

[Xen-devel] [ovmf test] 144034: all pass - PUSHED

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

[Xen-devel] [OSSTEST PATCH 1/2] ts-libvirt-build: Provide PKG_CONFIG_PATH

In osstest we do not install the xen tree in /usr/local because the build environment is shared with many different build jobs which might be using different versions of Xen. We put it in a job-specific directory in ~osstest on the build host, and set environment variables to ensure that it all

[Xen-devel] [OSSTEST PATCH 2/2] ts-libvirt-build: Do an out-of-tree build

Recent versions of libvirt do not support in-tree builds (!) Cope with this by always building in a subdirectory `build' (a subdirectory of the source tree); this is the arrangement which the libvirt upstream messages and documentation now seem to recommend (at least where things have been

[Xen-devel] Xen 4.13 RC2

Hi all, Xen 4.13 rc2 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.13.0-rc2 For your convenience there is also a tarball at: https://downloads.xenproject.org/release/xen/4.13.0-rc2/xen-4.13.0-rc2.tar.gz And the signature is at:

Re: [Xen-devel] [PATCH V2 2/2] x86/mm: Make use of the default access param from xc_altp2m_create_view

On 06.11.2019 16:35, Alexandru Stefan ISAILA wrote: > --- a/xen/arch/x86/mm/p2m-ept.c > +++ b/xen/arch/x86/mm/p2m-ept.c > @@ -1345,13 +1345,14 @@ void setup_ept_dump(void) > register_keyhandler('D', ept_dump_p2m_table, "dump VT-x EPT tables", 0); > } > > -void p2m_init_altp2m_ept(struct

Re: [Xen-devel] [XEN PATCH for-4.13] tools/configure: Honour XEN_COMPILE_ARCH and _TARGET_ for shim

Ian Jackson writes ("Re: [Xen-devel] [XEN PATCH for-4.13] tools/configure: Honour XEN_COMPILE_ARCH and _TARGET_ for shim"): > Andrew Cooper writes ("Re: [Xen-devel] [XEN PATCH for-4.13] tools/configure: > Honour XEN_COMPILE_ARCH and _TARGET_ for shim"): > > On 29/10/2019 17:57, Ian Jackson

Re: [Xen-devel] [PATCH V2 1/2] x86/altp2m: Add hypercall to set a range of sve bits

On 06.11.2019 16:35, Alexandru Stefan ISAILA wrote: > @@ -4681,7 +4682,7 @@ static int do_altp2m_op( > break; > > case HVMOP_altp2m_set_suppress_ve: > -if ( a.u.suppress_ve.pad1 || a.u.suppress_ve.pad2 ) > +if ( a.u.suppress_ve.pad1 ) Just because the field changes

[Xen-devel] [xen-4.13.0-rc] kexec/kdump failure with cpu Intel(R) Xeon(R) Gold 6242 CPU

Hi, on a new machine with cpu Intel(R) Xeon(R) Gold 6242 CPU the kexec/kdump doesn't work with current xen-4.13.0-rc. The last output of the xen console is: (XEN) Hardware Dom0 crashed: Executing kexec image on cpu5 (XEN) Shot down all CPUs After short delay the system reboots. It seems the

Re: [Xen-devel] [PATCH] Introduce a description of a new optional tag for Backports

Anthony PERARD writes ("Re: [Xen-devel] [PATCH] Introduce a description of a new optional tag for Backports"): > Should we describe the Fixes: tag as well? These would have a similar > purpose to the backport tag, I mean it could help figure out which > commit to backport to which tree. Good

Re: [Xen-devel] [PATCH] Introduce a description of a new optional tag for Backports

On Fri, Nov 08, 2019 at 11:09:52AM -0800, Stefano Stabellini wrote: > +Backport Tag > + > + > +A backport tag is an optional tag in the commit message to request a > +given commit to be backported to the stable trees: > + > +Backport: all [...] Should we describe the Fixes: tag as

Re: [Xen-devel] Xen-unstable: AMD-Vi: update_paging_mode Try to access pdev_list without aquiring pcidevs_lock.

On 11.11.2019 22:38, Sander Eikelenboom wrote: > When supplying "pci=nomsi" to the guest kernel, the device works fine, > and I don't get the "INVALID_DEV_REQUEST". > > After reverting 1b00c16bdf, the device works fine > and I don't get the INVALID_DEV_REQUEST, Could you give the patch below a

[Xen-devel] [xen-4.11-testing test] 144025: tolerable FAIL - PUSHED

flight 144025 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/144025/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass

Re: [Xen-devel] [PATCH for-4.13] xen: Drop bogus BOOLEAN definitions, TRUE and FALSE

On Mon, Nov 11, 2019 at 08:24:43PM +, Andrew Cooper wrote: > actypes.h and efidef.h both define BOOLEAN as unsigned char, which is buggy in > combination with logic such as "BOOLEAN b = (a & 0x100);" Redefine BOOLEAN as > bool instead, which doesn't truncate. > > Both also define TRUE and

Re: [Xen-devel] [PATCH v3] tools/hotpug: only attempt to call 'ip route' if there is valid command

On Tue, Nov 12, 2019 at 11:01:26AM +0100, Jürgen Groß wrote: > On 08.11.19 11:31, Wei Liu wrote: > > On Fri, Nov 08, 2019 at 09:42:33AM +, p...@xen.org wrote: > > > From: Paul Durrant > > > > > > The vif-route script should only call 'ip route' when 'ipcmd' has been > > > set, otherwise it

Re: [Xen-devel] [PATCH v3] tools/hotpug: only attempt to call 'ip route' if there is valid command

On 08.11.19 11:31, Wei Liu wrote: On Fri, Nov 08, 2019 at 09:42:33AM +, p...@xen.org wrote: From: Paul Durrant The vif-route script should only call 'ip route' when 'ipcmd' has been set, otherwise it will fail due to an incorrect command string. This patch also adds routes for 'tap'

Re: [Xen-devel] [PATCH 1/3] AMD/IOMMU: don't needlessly trigger errors/crashes when unmapping a page

On 06.11.19 16:18, Jan Beulich wrote: Unmapping a page which has never been mapped should be a no-op (note how it already is in case there was no root page table allocated). There's in particular no need to grow the number of page table levels in use, and there's also no need to allocate

Re: [Xen-devel] [PATCH for-4.13 v2 2/2] x86/ioapic: fix clear_IO_APIC_pin write of raw entries

On Mon, Nov 11, 2019 at 10:56:21AM +0100, Jan Beulich wrote: > On 10.11.2019 10:25, Roger Pau Monne wrote: > > clear_IO_APIC_pin can be called after the iommu has been enabled, and > > using raw reads and writes to modify IO-APIC entries that have been > > setup to use interrupt remapping can lead

Re: [Xen-devel] [PATCH] xen/sched: fix a potential issue with core scheduling

On 12.11.19 10:14, Dario Faggioli wrote: On Fri, 2019-11-08 at 07:57 +0100, Juergen Gross wrote: cpupool_online_cpumask() is used by credit and rt scheduler. It returns all the cpus of a cpupool or all online cpus in case no cpupool is specified. The "no cpupool" case can be dropped, as no

[Xen-devel] Lifting commit moratorium

Committers, The commit moratorium has been lifted, as we've got the desired push. You can now commit the release-acked patches again. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH] xen/sched: fix a potential issue with core scheduling

On Fri, 2019-11-08 at 07:57 +0100, Juergen Gross wrote: > cpupool_online_cpumask() is used by credit and rt scheduler. It > returns > all the cpus of a cpupool or all online cpus in case no cpupool is > specified. > > The "no cpupool" case can be dropped, as no scheduler other than the > init

[Xen-devel] [xen-unstable test] 144020: tolerable FAIL - PUSHED

flight 144020 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/144020/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-migrupgrade 11 xen-boot/dst_host fail in 144001 pass in 144020 test-amd64-amd64-xl-qcow2 19

Re: [Xen-devel] [PATCH] AMD/IOMMU: Fix passthrough following c/s d7cfeb7c13e

On 11.11.19 21:55, Andrew Cooper wrote: "AMD/IOMMU: don't blindly allocate interrupt remapping tables" introduces a call at runtime from amd_iommu_add_device() to amd_iommu_set_intremap_table() which is still marked as __init. On one AMD Rome machine we have, this results in a crash the moment

Re: [Xen-devel] [PATCH] AMD/IOMMU: Fix passthrough following c/s d7cfeb7c13e

On 11.11.2019 21:55, Andrew Cooper wrote: > "AMD/IOMMU: don't blindly allocate interrupt remapping tables" introduces a > call at runtime from amd_iommu_add_device() to amd_iommu_set_intremap_table() > which is still marked as __init. > > On one AMD Rome machine we have, this results in a crash

Re: [Xen-devel] [PATCH for-4.13] xen: Drop bogus BOOLEAN definitions, TRUE and FALSE

On 11.11.2019 21:24, Andrew Cooper wrote: > --- a/xen/arch/x86/x86_64/mm.c > +++ b/xen/arch/x86/x86_64/mm.c > @@ -1077,7 +1077,7 @@ long do_set_segment_base(unsigned int which, unsigned > long base) > } > > > -/* Returns TRUE if given descriptor is valid for GDT or LDT. */ > +/* Returns true

  1   2   >