flight 154374 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154374/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
Hi Tomas,
Thanks for the patch.
On Tue, Sep 15, 2020 at 08:53:46AM -0700, Laurent Pinchart wrote:
> 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
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
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-
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
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
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
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
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
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
>>
>>
> +
> +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
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:
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
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-
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
>>>
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
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)
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
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:
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
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
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
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()
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
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()
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
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
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
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
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
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
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
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
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
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_
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
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
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
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
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
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
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
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
> -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 '
> -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
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
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/
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
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
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)
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
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
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
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)
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
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
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
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,
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
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
> -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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
1 - 100 of 102 matches
Mail list logo
