Re: [PATCH v4 5/8] mm/memory_hotplug: MEMHP_MERGE_RESOURCE to specify merging of System RAM resources

2020-09-15 Thread David Hildenbrand
On 15.09.20 04:43, Wei Yang wrote: > On Fri, Sep 11, 2020 at 12:34:56PM +0200, David Hildenbrand wrote: >> Some add_memory*() users add memory in small, contiguous memory blocks. >> Examples include virtio-mem, hyper-v balloon, and the XEN balloon. >> >> This can quickly result in a lot of memory r

Re: [PATCH v2 1/7] kernel/resource: make release_mem_region_adjustable() never fail

2020-09-15 Thread David Hildenbrand
>> static int __ref try_remove_memory(int nid, u64 start, u64 size) >> { >> int rc = 0; >> @@ -1777,7 +1757,7 @@ static int __ref try_remove_memory(int nid, u64 start, >> u64 size) >> memblock_remove(start, size); >> } >> >> -__release_memory_resource(start, size); >>

Re: [PATCH v2 2/7] kernel/resource: move and rename IORESOURCE_MEM_DRIVER_MANAGED

2020-09-15 Thread David Hildenbrand
On 15.09.20 04:20, Wei Yang wrote: > On Tue, Sep 08, 2020 at 10:10:07PM +0200, David Hildenbrand wrote: >> IORESOURCE_MEM_DRIVER_MANAGED currently uses an unused PnP bit, which is >> always set to 0 by hardware. This is far from beautiful (and confusing), >> and the bit only applies to SYSRAM. So l

Re: [RFC PATCH] efi: const correct EFI functions

2020-09-15 Thread Jan Beulich
On 14.09.2020 17:05, Trammell Hudson wrote: > On Monday, September 14, 2020 10:55 AM, Jan Beulich wrote: >> On 14.09.2020 16:46, Trammell Hudson wrote: >>> Option 3 would be to write wrappers for the few functions that are >>> used in the EFI boot path that cast-away the constness of their >>> arg

Re: libxenguest and xenguest.h

2020-09-15 Thread Jan Beulich
On 15.09.2020 07:18, Jürgen Groß wrote: > Andy has reported a libxenguest related build failure of qemu when > building qemu outside the Xen build environment. Problem is xenguest.h > now including xenctrl_dom.h, which is including xen/libelf/libelf.h. > > The underlying problem is that libxengues

Re: [PATCH 1/3] x86/shim: fix build with PV_SHIM_EXCLUSIVE and SHADOW_PAGING

2020-09-15 Thread Jan Beulich
On 14.09.2020 18:44, Roger Pau Monné wrote: > On Mon, Sep 14, 2020 at 02:38:49PM +0200, Jan Beulich wrote: >> While there's little point in enabling both, the combination ought to at >> least build correctly. Drop the direct PV_SHIM_EXCLUSIVE conditionals >> and instead zap PG_log_dirty to zero und

Re: libxenguest and xenguest.h

2020-09-15 Thread Jürgen Groß
On 15.09.20 09:55, Jan Beulich wrote: On 15.09.2020 07:18, Jürgen Groß wrote: Andy has reported a libxenguest related build failure of qemu when building qemu outside the Xen build environment. Problem is xenguest.h now including xenctrl_dom.h, which is including xen/libelf/libelf.h. The underl

[PATCH v3] EFI: free unused boot mem in at least some cases

2020-09-15 Thread Jan Beulich
Address at least the primary reason why 52bba67f8b87 ("efi/boot: Don't free ebmalloc area at all") was put in place: Make xen_in_range() aware of the freed range. This is in particular relevant for EFI-enabled builds not actually running on EFI, as the entire range will be unused in this case. Sig

Re: libxenguest and xenguest.h

2020-09-15 Thread Jan Beulich
On 15.09.2020 10:06, Jürgen Groß wrote: > On 15.09.20 09:55, Jan Beulich wrote: >> On 15.09.2020 07:18, Jürgen Groß wrote: >>> Andy has reported a libxenguest related build failure of qemu when >>> building qemu outside the Xen build environment. Problem is xenguest.h >>> now including xenctrl_dom.

Re: [PATCH v3] EFI: free unused boot mem in at least some cases

2020-09-15 Thread Jan Beulich
On 15.09.2020 10:08, Jan Beulich wrote: > Address at least the primary reason why 52bba67f8b87 ("efi/boot: Don't > free ebmalloc area at all") was put in place: Make xen_in_range() aware > of the freed range. This is in particular relevant for EFI-enabled > builds not actually running on EFI, as th

Re: libxenguest and xenguest.h

2020-09-15 Thread Jürgen Groß
On 15.09.20 10:11, Jan Beulich wrote: On 15.09.2020 10:06, Jürgen Groß wrote: On 15.09.20 09:55, Jan Beulich wrote: On 15.09.2020 07:18, Jürgen Groß wrote: Andy has reported a libxenguest related build failure of qemu when building qemu outside the Xen build environment. Problem is xenguest.h

Re: [PATCH v3] x86/HVM: more consistently set I/O completion

2020-09-15 Thread Jan Beulich
On 27.08.2020 09:09, Jan Beulich wrote: > Doing this just in hvm_emulate_one_insn() is not enough. > hvm_ud_intercept() and hvm_emulate_one_vm_event() can get invoked for > insns requiring one or more continuations, and at least in principle > hvm_emulate_one_mmio() could, too. Without proper setti

[PATCH v9 2/8] iommu: remove unused iommu_ops method and tasklet

2020-09-15 Thread Paul Durrant
From: Paul Durrant The VT-d and AMD IOMMU implementations both use the general x86 IOMMU page table allocator and ARM always shares page tables with CPU. Hence there is no need to retain the free_page_table() method or the tasklet which invokes it. Signed-off-by: Paul Durrant Reviewed-by: Jan B

[PATCH v9 0/8] IOMMU cleanup

2020-09-15 Thread Paul Durrant
From: Paul Durrant Paul Durrant (8): x86/iommu: convert VT-d code to use new page table allocator iommu: remove unused iommu_ops method and tasklet iommu: flush I/O TLB if iommu_map() or iommu_unmap() fail iommu: make map and unmap take a page count, similar to flush remove remaining us

[PATCH v9 3/8] iommu: flush I/O TLB if iommu_map() or iommu_unmap() fail

2020-09-15 Thread Paul Durrant
From: Paul Durrant This patch adds a full I/O TLB flush to the error paths of iommu_map() and iommu_unmap(). Without this change callers need constructs such as: rc = iommu_map/unmap(...) err = iommu_flush(...) if ( !rc ) rc = err; With this change, it can be simplified to: rc = iommu_map/u

[PATCH v9 4/8] iommu: make map and unmap take a page count, similar to flush

2020-09-15 Thread Paul Durrant
From: Paul Durrant At the moment iommu_map() and iommu_unmap() take a page order rather than a count, whereas iommu_iotlb_flush() takes a page count rather than an order. This patch makes them consistent with each other, opting for a page count since CPU page orders are not necessarily the same a

[PATCH v9 5/8] remove remaining uses of iommu_legacy_map/unmap

2020-09-15 Thread Paul Durrant
From: Paul Durrant The 'legacy' functions do implicit flushing so amend the callers to do the appropriate flushing. Unfortunately, because of the structure of the P2M code, we cannot remove the per-CPU 'iommu_dont_flush_iotlb' global and the optimization it facilitates. Checking of this flag is

[PATCH v9 1/8] x86/iommu: convert VT-d code to use new page table allocator

2020-09-15 Thread Paul Durrant
From: Paul Durrant This patch converts the VT-d code to use the new IOMMU page table allocator function. This allows all the free-ing code to be removed (since it is now handled by the general x86 code) which reduces TLB and cache thrashing as well as shortening the code. The scope of the mappin

[PATCH v9 8/8] iommu: stop calling IOMMU page tables 'p2m tables'

2020-09-15 Thread Paul Durrant
From: Paul Durrant It's confusing and not consistent with the terminology introduced with 'dfn_t'. Just call them IOMMU page tables. Also remove a pointless check of the 'acpi_drhd_units' list in vtd_dump_page_table_level(). If the list is empty then IOMMU mappings would not have been enabled fo

[PATCH v9 6/8] common/grant_table: batch flush I/O TLB

2020-09-15 Thread Paul Durrant
From: Paul Durrant This patch avoids calling iommu_iotlb_flush() for each individual GNTTABOP and instead calls iommu_iotlb_flush_all() at the end of a batch. This should mean non-singleton map/unmap operations perform better. NOTE: A batch is the number of operations done before a pre-emption c

[PATCH v9 7/8] iommu: remove the share_p2m operation

2020-09-15 Thread Paul Durrant
From: Paul Durrant Sharing of HAP tables is now VT-d specific so the operation is never defined for AMD IOMMU any more. There's also no need to pro-actively set vtd.pgd_maddr when using shared EPT as it is straightforward to simply define a helper function to return the appropriate value in the s

Re: [PATCH v3 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends

2020-09-15 Thread kernel test robot
Hi David, I love your patch! Perhaps something to improve: [auto build test WARNING on next-20200909] [cannot apply to mmotm/master hnaz-linux-mm/master xen-tip/linux-next powerpc/next linus/master v5.9-rc4 v5.9-rc3 v5.9-rc2 v5.9-rc4] [If your patch is applied to the wrong git tree, kindly drop

Re: [PATCH 18/20] drm/xen: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
Hi Am 13.08.20 um 13:19 schrieb Oleksandr Andrushchenko: > Hi, > > On 8/13/20 11:36 AM, Thomas Zimmermann wrote: >> GEM object functions deprecate several similar callback interfaces in >> struct drm_driver. This patch replaces the per-driver callbacks with >> per-instance callbacks in xen. The o

Re: [PATCH v2 1/7] kernel/resource: make release_mem_region_adjustable() never fail

2020-09-15 Thread Wei Yang
On Tue, Sep 15, 2020 at 09:35:30AM +0200, David Hildenbrand wrote: > >>> static int __ref try_remove_memory(int nid, u64 start, u64 size) >>> { >>> int rc = 0; >>> @@ -1777,7 +1757,7 @@ static int __ref try_remove_memory(int nid, u64 >>> start, u64 size) >>> memblock_remove(start,

[libvirt test] 154353: regressions - FAIL

2020-09-15 Thread osstest service owner
flight 154353 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/154353/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777 build-amd64-libvirt

RE: [PATCH v3] x86/HVM: more consistently set I/O completion

2020-09-15 Thread Paul Durrant
> -Original Message- > From: Jan Beulich > Sent: 15 September 2020 09:26 > To: Andrew Cooper ; Paul Durrant > Cc: xen-devel@lists.xenproject.org; Wei Liu ; Roger Pau Monné > ; Jun > Nakajima ; Kevin Tian ; George > Dunlap > > Subject: Re: [PATCH v3] x86/HVM: more consistently set I/O c

Re: [PATCH v2 1/7] kernel/resource: make release_mem_region_adjustable() never fail

2020-09-15 Thread David Hildenbrand
On 15.09.20 11:06, Wei Yang wrote: > On Tue, Sep 15, 2020 at 09:35:30AM +0200, David Hildenbrand wrote: >> static int __ref try_remove_memory(int nid, u64 start, u64 size) { int rc = 0; @@ -1777,7 +1757,7 @@ static int __ref try_remove_memory(int nid, u64 start, u64 siz

[xen-4.14-testing test] 154350: tolerable FAIL - PUSHED

2020-09-15 Thread osstest service owner
flight 154350 xen-4.14-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/154350/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13

Re: [PATCH v2 1/7] kernel/resource: make release_mem_region_adjustable() never fail

2020-09-15 Thread Wei Yang
On Tue, Sep 15, 2020 at 11:15:53AM +0200, David Hildenbrand wrote: >On 15.09.20 11:06, Wei Yang wrote: >> On Tue, Sep 15, 2020 at 09:35:30AM +0200, David Hildenbrand wrote: >>> > static int __ref try_remove_memory(int nid, u64 start, u64 size) > { > int rc = 0; > @@ -1777,7 +1757,

[xen-4.13-testing test] 154122: trouble: fail/pass/preparing

2020-09-15 Thread osstest service owner
flight 154122 xen-4.13-testing running [real] http://logs.test-lab.xenproject.org/osstest/logs/154122/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 2 hosts-allocate running

Re: [RFC PATCH] efi: const correct EFI functions

2020-09-15 Thread Trammell Hudson
On Tuesday, September 15, 2020 9:41 AM, Jan Beulich wrote: > On 14.09.2020 17:05, Trammell Hudson wrote: > > [...] I checked to see > > which functions would need to be wrapped. It is a surprisingly > > small number: > > #define PrintStr(s) StdOut->OutputString(StdOut, (CHAR16 *)(s)) > > #define P

[RFC PATCH v2] efi: const correct EFI functions

2020-09-15 Thread Trammell Hudson
By wrapping the few EFI handler functions used by the Xen boot process and casting away constness where safe, it is possible to allow most of the rest of the EFI boot code to use constant strings and GUIDs. There are a few places in the code that casts away the const that should be reconsidered. F

Re: [RFC PATCH v2] efi: const correct EFI functions

2020-09-15 Thread Jan Beulich
On 15.09.2020 12:02, Trammell Hudson wrote: > @@ -149,10 +150,23 @@ static struct file __initdata cfg; > static struct file __initdata kernel; > static struct file __initdata ramdisk; > static struct file __initdata xsm; > -static CHAR16 __initdata newline[] = L"\r\n"; > - > -#define PrintStr(s)

Re: [RFC PATCH v2] efi: const correct EFI functions

2020-09-15 Thread Trammell Hudson
On Tuesday, September 15, 2020 12:36 PM, Jan Beulich wrote: > In order for these casts to be halfway safe, they need to happen in > inline functions, not macros. That way it'll be sufficiently clear > and certain that it's really only the const which gets changed, > but not e.g. also the pointed-t

Re: [PATCH 2/3] x86/shim: adjust Kconfig defaults

2020-09-15 Thread Jan Beulich
On 15.09.2020 12:49, Roger Pau Monné wrote: > On Mon, Sep 14, 2020 at 02:39:08PM +0200, Jan Beulich wrote: >> Just like HVM, defaulting SHADOW_PAGING and TBOOT to Yes in shim- >> exclusive mode makes no sense, as the respective code is dead there. >> >> Also adjust the shim default config file: It

Re: [PATCH 3/3] x86/shim: don't permit HVM and PV_SHIM_EXCLUSIVE at the same time

2020-09-15 Thread Jan Beulich
On 15.09.2020 13:02, Roger Pau Monné wrote: > On Mon, Sep 14, 2020 at 02:39:33PM +0200, Jan Beulich wrote: >> This combination doesn't really make sense (and there likely are more). >> The alternative here would be some presumably intrusive #ifdef-ary to >> get this combination to actually build ag

Re: [PATCH 1/9] build: use if_changed more consistently (and correctly) for prelink*.o

2020-09-15 Thread Jan Beulich
On 15.09.2020 13:56, Roger Pau Monné wrote: > On Mon, Sep 14, 2020 at 12:15:39PM +0200, Jan Beulich wrote: >> Switch to $(call if_changed,ld) where possible; presumably not doing so >> in e321576f4047 ("xen/build: start using if_changed") right away was an >> oversight, as it did for Arm in (just)

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

2020-09-15 Thread osstest service owner
flight 154357 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/154357/ 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 1

[PATCH v2 0/2] fix 'xl block-detach'

2020-09-15 Thread Paul Durrant
From: Paul Durrant This series makes it behave as the documentation states it should Paul Durrant (2): libxl: provide a mechanism to define a device 'safe remove' function... xl: implement documented '--force' option for block-detach docs/man/xl.1.pod.in | 4 ++-- tools/libxl/

[PATCH v2 1/2] libxl: provide a mechanism to define a device 'safe remove' function...

2020-09-15 Thread Paul Durrant
From: Paul Durrant ... and use it to define libxl_device_disk_safe_remove(). This patch builds on the existent macro magic by using a new value of the 'force' field in in libxl__ao_device. It is currently defined as an int but is used in a boolean manner where 1 means the operation is forced and

[PATCH v2 2/2] xl: implement documented '--force' option for block-detach

2020-09-15 Thread Paul Durrant
From: Paul Durrant The manpage for 'xl' documents an option to force a block device to be released even if the domain to which it is attached does not co-operate. The documentation also states that, if the force flag is not specified, the block-detach operation should fail. Currently the force o

RE: [PATCH v7 7/9] common/domain: add a domain context record for shared_info...

2020-09-15 Thread Durrant, Paul
> -Original Message- > From: Paul Durrant > Sent: 04 September 2020 18:30 > To: 'Jan Beulich' > Cc: xen-devel@lists.xenproject.org; Durrant, Paul ; > 'Ian Jackson' > ; 'Wei Liu' ; 'Andrew Cooper' > ; > 'George Dunlap' ; 'Julien Grall' ; > 'Stefano Stabellini' > > Subject: RE: [EXTERNA

RE: [PATCH v2 1/2] libxl: provide a mechanism to define a device 'safe remove' function...

2020-09-15 Thread Durrant, Paul
> -Original Message- > From: Roger Pau Monné > Sent: 15 September 2020 15:32 > To: Paul Durrant > Cc: xen-devel@lists.xenproject.org; Durrant, Paul ; > Ian Jackson > ; Wei Liu ; Anthony PERARD > > Subject: RE: [EXTERNAL] [PATCH v2 1/2] libxl: provide a mechanism to define a > device '

Re: [PATCH 2/3] x86/shim: adjust Kconfig defaults

2020-09-15 Thread Roger Pau Monné
On Mon, Sep 14, 2020 at 02:39:08PM +0200, Jan Beulich wrote: > Just like HVM, defaulting SHADOW_PAGING and TBOOT to Yes in shim- > exclusive mode makes no sense, as the respective code is dead there. > > Also adjust the shim default config file: It needs to specifiy values > only for settings wher

[PATCH v2 05/21] drm/gma500: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in gma500. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/gma500/framebuffer.c | 2 ++ drivers/gpu/drm/gma500/gem.c | 1

[PATCH v2 00/21] Convert all remaining drivers to GEM object functions

2020-09-15 Thread Thomas Zimmermann
The GEM and PRIME related callbacks in struct drm_driver are deprecated in favor of GEM object functions in struct drm_gem_object_funcs. This patchset converts the remaining drivers to object functions and removes most of the obsolete interfaces. Patches #1 to #16 and #18 to #19 convert DRM driver

[PATCH v2 08/21] drm/msm: Introduce GEM object funcs

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in msm. The only exception is gem_prime_mmap, which is non-trivial to convert. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/ms

[PATCH v2 04/21] drm/exynos: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in exynos. The only exception is gem_prime_mmap, which is non-trivial to convert. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm

[PATCH v2 03/21] drm/etnaviv: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in etnaviv. The only exception is gem_prime_mmap, which is non-trivial to convert. Signed-off-by: Thomas Zimmermann --- drivers/gpu/dr

[PATCH v2 17/21] drm/virtgpu: Set PRIME export function in struct drm_gem_object_funcs

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces virtgpu's per-driver PRIME export function with a per-object function. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/virtio/virtgpu_drv.c| 1 - drivers/gpu/drm/virtio/virtgpu_o

[PATCH v2 01/21] drm/amdgpu: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in amdgpu. The only exception is gem_prime_mmap, which is non-trivial to convert. v2: * move object-function instance to amdgpu_

[PATCH v2 18/21] drm/vkms: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in vkms. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/vkms/vkms_drv.c | 8 drivers/gpu/drm/vkms/vkms_gem.c | 13

[PATCH v2 09/21] drm/nouveau: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in nouveau. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/nouveau/nouveau_drm.c | 9 - drivers/gpu/drm/nouveau/nouve

[PATCH v2 02/21] drm/armada: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in armada. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/armada/armada_drv.c | 3 --- drivers/gpu/drm/armada/armada_gem.c | 12

[PATCH v2 13/21] drm/rockchip: Convert to drm_gem_object_funcs

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in rockchip. The only exception is gem_prime_mmap, which is non-trivial to convert. Signed-off-by: Thomas Zimmermann --- drivers/gpu/d

[PATCH v2 06/21] drm/i915: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in i915. v2: * move object-function instance to i915_gem_object.c (Jani) Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm

[PATCH v2 07/21] drm/mediatek: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in mediatek. The only exception is gem_prime_mmap, which is non-trivial to convert. Signed-off-by: Thomas Zimmermann --- drivers/gpu/d

[PATCH v2 14/21] drm/tegra: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in tegra. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/tegra/drm.c | 4 drivers/gpu/drm/tegra/gem.c | 8 2 files

[PATCH v2 15/21] drm/vc4: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in vc4. The only exception is gem_prime_mmap, which is non-trivial to convert. Signed-off-by: Thomas Zimmermann Reviewed-by: Eric Anhol

[PATCH v2 16/21] drm/vgem: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in vgem. The only exception is gem_prime_mmap, which is non-trivial to convert. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/v

[PATCH v2 11/21] drm/pl111: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in pl111. The only exception is gem_prime_mmap, which is non-trivial to convert. v2: * use drm_gem_cma_create_object_default_fun

[PATCH v2 12/21] drm/radeon: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in radeon. v2: * move object-function instance to radeon_gem.c (Christian) * set callbacks in radeon_gem_object_create()

[PATCH v2 19/21] drm/xen: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in xen. The only exception is gem_prime_mmap, which is non-trivial to convert. v2: * convert xen_drm_drv_free_object_unlocked()

[PATCH v2 21/21] drm: Remove obsolete GEM and PRIME callbacks from struct drm_driver

2020-09-15 Thread Thomas Zimmermann
Several GEM and PRIME callbacks have been deprecated in favor of per-instance GEM object functions. Remove the callbacks as they are now unused. The only exception is .gem_prime_mmap, which is still in use by several drivers. What is also gone is gem_vm_ops in struct drm_driver. All drivers now us

[PATCH v2 10/21] drm/omapdrm: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in omapdrm. v2: * make omap_gem_free_object() static (Tomi) Signed-off-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart Re

[PATCH v2 20/21] drm/xlnx: Initialize DRM driver instance with CMA helper macro

2020-09-15 Thread Thomas Zimmermann
The xlnx driver uses CMA helpers with default callback functions. Initialize the driver structure with the rsp CMA helper macro. The driver is being converted to use GEM object functions as part of this change. Two callbacks, .dumb_destroy and .gem_prime_import, were initialized to their default i

Re: [PATCH 3/3] x86/shim: don't permit HVM and PV_SHIM_EXCLUSIVE at the same time

2020-09-15 Thread Roger Pau Monné
On Mon, Sep 14, 2020 at 02:39:33PM +0200, Jan Beulich wrote: > This combination doesn't really make sense (and there likely are more). > The alternative here would be some presumably intrusive #ifdef-ary to > get this combination to actually build again. > > Signed-off-by: Jan Beulich I'm not su

Re: [PATCH v2 01/21] drm/amdgpu: Introduce GEM object functions

2020-09-15 Thread Christian König
Am 15.09.20 um 16:59 schrieb Thomas Zimmermann: GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in amdgpu. The only exception is gem_prime_mmap, which is non-trivial to convert. v2:

Re: [PATCH v2 02/21] drm/armada: Introduce GEM object functions

2020-09-15 Thread Russell King - ARM Linux admin
On Tue, Sep 15, 2020 at 04:59:39PM +0200, Thomas Zimmermann wrote: > GEM object functions deprecate several similar callback interfaces in > struct drm_driver. This patch replaces the per-driver callbacks with > per-instance callbacks in armada. > > Signed-off-by: Thomas Zimmermann Acked-by: Rus

Re: [PATCH v2 12/21] drm/radeon: Introduce GEM object functions

2020-09-15 Thread Christian König
Am 15.09.20 um 16:59 schrieb Thomas Zimmermann: GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in radeon. v2: * move object-function instance to radeon_gem.c (Christian)

Re: [PATCH v2 1/2] libxl: provide a mechanism to define a device 'safe remove' function...

2020-09-15 Thread Wei Liu
On Tue, Sep 15, 2020 at 04:48:14PM +0200, Roger Pau Monné wrote: > On Tue, Sep 15, 2020 at 02:40:09PM +, Durrant, Paul wrote: > > > -Original Message- > > > From: Roger Pau Monné > > > Sent: 15 September 2020 15:32 > > > To: Paul Durrant > > > Cc: xen-devel@lists.xenproject.org; Durra

Re: [PATCH 1/9] build: use if_changed more consistently (and correctly) for prelink*.o

2020-09-15 Thread Jan Beulich
On 15.09.2020 15:46, Roger Pau Monné wrote: > On Tue, Sep 15, 2020 at 02:26:34PM +0200, Jan Beulich wrote: >> On 15.09.2020 13:56, Roger Pau Monné wrote: >>> On Mon, Sep 14, 2020 at 12:15:39PM +0200, Jan Beulich wrote: Switch to $(call if_changed,ld) where possible; presumably not doing so >>>

Re: [PATCH v2 00/21] Convert all remaining drivers to GEM object functions

2020-09-15 Thread Christian König
Added my rb to the amdgpu and radeon patches. Should we pick those up through the amd branches or do you want to push everything to drm-misc-next? I think the later since this should result in much merge clash. Christian. Am 15.09.20 um 16:59 schrieb Thomas Zimmermann: The GEM and PRIME rel

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

2020-09-15 Thread osstest service owner
flight 154361 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/154361/ 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 1

Re: [PATCH v2 20/21] drm/xlnx: Initialize DRM driver instance with CMA helper macro

2020-09-15 Thread Laurent Pinchart
Hi Thomas, Thank you for the patch. On Tue, Sep 15, 2020 at 04:59:57PM +0200, Thomas Zimmermann wrote: > The xlnx driver uses CMA helpers with default callback functions. > Initialize the driver structure with the rsp CMA helper macro. The > driver is being converted to use GEM object functions a

Re: [PATCH 1/9] build: use if_changed more consistently (and correctly) for prelink*.o

2020-09-15 Thread Roger Pau Monné
On Mon, Sep 14, 2020 at 12:15:39PM +0200, Jan Beulich wrote: > Switch to $(call if_changed,ld) where possible; presumably not doing so > in e321576f4047 ("xen/build: start using if_changed") right away was an > oversight, as it did for Arm in (just) one case. It failed to add > prelink.o to $(targe

Re: [PATCH v2 06/21] drm/i915: Introduce GEM object functions

2020-09-15 Thread Tvrtko Ursulin
On 15/09/2020 15:59, Thomas Zimmermann wrote: GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in i915. v2: * move object-function instance to i915_gem_object.c (Jani) Sign

[PATCH v8 5/8] docs / tools: specific migration v4 to include DOMAIN_CONTEXT

2020-09-15 Thread Paul Durrant
From: Paul Durrant A new 'domain context' framework was recently introduced to facilitate transfer of state for both PV and HVM guests. Hence this patch mandates the presence of a new DOMAIN_CONTEXT record in version 4 of the libxc migration stream. This record will incorprate the content of the

[PATCH v8 6/8] common/domain: add a domain context record for shared_info...

2020-09-15 Thread Paul Durrant
From: Paul Durrant ... and update xen-domctx to dump some information describing the record. NOTE: Processing of the content during restore is currently limited to PV domains, and matches processing of the PV-only SHARED_INFO record done by libxc. All content is, however, saved such

[PATCH v8 7/8] x86/time: add a domain context record for tsc_info...

2020-09-15 Thread Paul Durrant
From: Paul Durrant ... and update xen-domctx to dump some information describing the record. NOTE: Whilst the record definition is x86 specific, it is visible directly in the common header as context record numbers should be unique across all architectures. Signed-off-by: Paul Durra

[PATCH v8 0/8] domain context infrastructure

2020-09-15 Thread Paul Durrant
From: Paul Durrant Paul Durrant (8): xen/common: introduce a new framework for save/restore of 'domain' context xen/common/domctl: introduce XEN_DOMCTL_get/setdomaincontext tools/misc: add xen-domctx to present domain context docs/specs: add missing definitions to libxc-migration-stre

[PATCH v8 4/8] docs/specs: add missing definitions to libxc-migration-stream

2020-09-15 Thread Paul Durrant
From: Paul Durrant The STATIC_DATA_END, X86_CPUID_POLICY and X86_MSR_POLICY record types have sections explaining what they are but their values are not defined. Indeed their values are defined as "Reserved for future mandatory records." Also, the spec revision is adjusted to match the migration

[PATCH v8 1/8] xen/common: introduce a new framework for save/restore of 'domain' context

2020-09-15 Thread Paul Durrant
To allow enlightened HVM guests (i.e. those that have PV drivers) to be migrated without their co-operation it will be necessary to transfer 'PV' state such as event channel state, grant entry state, etc. Currently there is a framework (entered via the hvm_save/load() functions) that allows a doma

[PATCH v8 8/8] tools/libxc: add DOMAIN_CONTEXT records to the migration stream...

2020-09-15 Thread Paul Durrant
From: Paul Durrant ... and bump the version. This patch implements version 4 of the migration stream by adding the code necessary to save and restore DOMAIN_CONTEXT records, and removing the code to save the SHARED_INFO and TSC_INFO records (as these are deprecated in version 4). Signed-off-by:

[PATCH v8 3/8] tools/misc: add xen-domctx to present domain context

2020-09-15 Thread Paul Durrant
This tool is analogous to 'xen-hvmctx' which presents HVM context. Subsequent patches will add 'dump' functions when new records are introduced. Signed-off-by: Paul Durrant Acked-by: Ian Jackson --- Cc: Andrew Cooper Cc: Wei Liu NOTE: Ian requested ack from Andrew v3: - Re-worked to avoid c

[PATCH v8 2/8] xen/common/domctl: introduce XEN_DOMCTL_get/setdomaincontext

2020-09-15 Thread Paul Durrant
These domctls provide a mechanism to get and set domain context from the toolstack. Signed-off-by: Paul Durrant Reviewed-by: Julien Grall --- Cc: Daniel De Graaf Cc: Ian Jackson Cc: Wei Liu Cc: Andrew Cooper Cc: George Dunlap Cc: Jan Beulich Cc: Stefano Stabellini v4: - Add missing zero

Re: [PATCH v2 1/2] libxl: provide a mechanism to define a device 'safe remove' function...

2020-09-15 Thread Wei Liu
On Tue, Sep 15, 2020 at 03:10:06PM +0100, Paul Durrant wrote: > From: Paul Durrant > > ... and use it to define libxl_device_disk_safe_remove(). > > This patch builds on the existent macro magic by using a new value of the > 'force' field in in libxl__ao_device. > It is currently defined as an i

Re: [PATCH 1/9] build: use if_changed more consistently (and correctly) for prelink*.o

2020-09-15 Thread Roger Pau Monné
On Tue, Sep 15, 2020 at 02:26:34PM +0200, Jan Beulich wrote: > On 15.09.2020 13:56, Roger Pau Monné wrote: > > On Mon, Sep 14, 2020 at 12:15:39PM +0200, Jan Beulich wrote: > >> Switch to $(call if_changed,ld) where possible; presumably not doing so > >> in e321576f4047 ("xen/build: start using if_c

[linux-linus test] 154356: regressions - FAIL

2020-09-15 Thread osstest service owner
flight 154356 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/154356/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 152332 test-amd64-i386-xl-

Re: [PATCH v2 1/2] libxl: provide a mechanism to define a device 'safe remove' function...

2020-09-15 Thread Roger Pau Monné
On Tue, Sep 15, 2020 at 03:10:06PM +0100, Paul Durrant wrote: > From: Paul Durrant > > ... and use it to define libxl_device_disk_safe_remove(). > > This patch builds on the existent macro magic by using a new value of the > 'force' field in in libxl__ao_device. > It is currently defined as an i

Re: [PATCH v2 1/2] libxl: provide a mechanism to define a device 'safe remove' function...

2020-09-15 Thread Roger Pau Monné
On Tue, Sep 15, 2020 at 02:40:09PM +, Durrant, Paul wrote: > > -Original Message- > > From: Roger Pau Monné > > Sent: 15 September 2020 15:32 > > To: Paul Durrant > > Cc: xen-devel@lists.xenproject.org; Durrant, Paul ; > > Ian Jackson > > ; Wei Liu ; Anthony PERARD > > > > Subject:

Re: [PATCH v3 01/11] xen/manage: keep track of the on-going suspend mode

2020-09-15 Thread boris . ostrovsky
>> >> > + > +static int xen_setup_pm_notifier(void) > +{ > + if (!xen_hvm_domain() || xen_initial_domain()) > + return -ENODEV; I don't think this works anymore. >>> What do you mean? >>> The first check is for xen domain types and other is for archi

Re: [PATCH v3 02/11] xenbus: add freeze/thaw/restore callbacks support

2020-09-15 Thread Anchal Agarwal
On Sun, Sep 13, 2020 at 12:11:47PM -0400, boris.ostrov...@oracle.com wrote: > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you can confirm the sender and know the > content is safe. > > > > On 8/21/20 6:26 PM, Anchal Agarwal w

Compiling Xen from source

2020-09-15 Thread David I
Hello, I am unable to mcompile xen-tools from source. here is the "stacktrace": ln -f xenstore xenstore-watch gcc xenstore_control.o -Wl,-rpath-link=/home/david/xen/xen/tools/xenstore/../../tools/libs/toolcore /home/david/xen/xen/tools/xenstore/../../tools/xenstore/libxenstore.so -ldl /home/da

[xen-4.13-testing test] 154358: tolerable FAIL - PUSHED

2020-09-15 Thread osstest service owner
flight 154358 xen-4.13-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/154358/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13

[PATCH] x86/mm: Simplify expression in set_gpfn_from_mfn()

2020-09-15 Thread Andrew Cooper
Coverity points out that the "d &&" is redundant. Fixes: c9476c4ad72 ("x86: don't override INVALID_M2P_ENTRY with SHARED_M2P_ENTRY") Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné CC: Wei Liu --- xen/arch/x86/x86_64/mm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletio

Re: Compiling Xen from source

2020-09-15 Thread Hans van Kranenburg
Hi, On 9/16/20 12:00 AM, Andrew Cooper wrote: > On 15/09/2020 21:16, David I wrote: >> Hello, >> >> I am unable to mcompile xen-tools from source. >> >> here is the "stacktrace": >> >> ln -f xenstore xenstore-watch >> gcc xenstore_control.o     >>  -Wl,-rpath-link=/home/david/xen/xen/tools/xenstor

Re: Compiling Xen from source

2020-09-15 Thread Andrew Cooper
On 15/09/2020 21:16, David I wrote: > Hello, > > I am unable to mcompile xen-tools from source. > > here is the "stacktrace": > > ln -f xenstore xenstore-watch > gcc xenstore_control.o     >  -Wl,-rpath-link=/home/david/xen/xen/tools/xenstore/../../tools/libs/toolcore > /home/david/xen/xen/tools/xe

[linux-linus test] 154364: regressions - FAIL

2020-09-15 Thread osstest service owner
flight 154364 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/154364/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 152332 test-amd64-i386-xl-

[ovmf test] 154370: all pass - PUSHED

2020-09-15 Thread osstest service owner
flight 154370 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/154370/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf a62fb4229d149560cac2bf56011fba49a281ed2b baseline version: ovmf 1b461403ee723dab01d58

  1   2   >