Hi Oleksandr,
On 19/09/2020 18:21, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Mark Renesas IPMMU-VMSA as "Supported, not security supported"
and remove dependencies on CONFIG_EXPERT.
We can't treat the IOMMU driver as "Supported" since the device
passthrough feature is not securit
From: Julien Grall
SMMUv{1, 2} are both marked as security supported, so we would
technically have to issue an XSA for any IOMMU security bug.
However, at the moment, device passthrough is not security supported
on Arm and there is no plan to change that in the next few months.
Therefore, mark
flight 154614 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154614/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 6 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
Hi Jan,
On 17/09/2020 12:27, Jan Beulich wrote:
Inspired by some of Trammell's suggestions, this harvests some low
hanging fruit, without needing to be concerned about the definitions of
the EFI interfaces themselves.
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Cheers,
--- a/xen/a
On 29/08/2020 11:38, Simon Leiner wrote:
Hi Julien,
Hi Simon,
Apologies for the late answer.
On 25.08.20 15:02, Julien Grall wrote:
May I ask why did you create a new transport rather than using the
existing one?
We wanted a mechanism for dynamically creating virtio devices at
runtime. I
On Tue, Sep 22, 2020 at 09:18:49AM +0100, Daniel P. Berrangé wrote:
> On Tue, Sep 22, 2020 at 08:56:06AM +0200, Paolo Bonzini wrote:
> > On 22/09/20 08:45, David Hildenbrand wrote:
> > >> It's certainly a good idea but it's quite verbose.
> > >>
> > >> What about using atomic__* as the prefix? It
On Tue, Sep 22, 2020 at 01:35:37PM +0200, Paolo Bonzini wrote:
> On 22/09/20 10:58, Stefan Hajnoczi wrote:
> I think the reviews crossed, are you going to respin using a qatomic_
> prefix?
Yes, let's do qatomic_. I'll send a v3.
Stefan
signature.asc
Description: PGP signature
flight 154628 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154628/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-prev
On 18/09/2020 17:37, Christoph Hellwig wrote:
i915_gem_object_map implements fairly low-level vmap functionality in
a driver. Split it into two helpers, one for remapping kernel memory
which can use vmap, and one for I/O memory that uses vmap_pfn.
The only practical difference is that alloc_v
> -Original Message-
> From: Xen-devel On Behalf Of Julien
> Grall
> Sent: 23 September 2020 10:04
> To: Simon Leiner
> Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> ; Bertrand Marquis
> ; Oleksandr Tyshchenko
> Subject: Re: Virtio Xen (WAS: Re: [Linux] [ARM] Granting memory
flight 154638 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154638/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 2785b2a9e04abc148e1c5259f4faee708ea356f4
baseline version:
xen baa4
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.
v3:
* remove amdgpu_object.c from patch (Chris
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
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/gma500/framebuffer.c | 2 ++
drivers/gpu/
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 i915.
v2:
* move object-function instance to i915_gem_object.c (Jani)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Tvrtko
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
Reviewed-by: Daniel
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
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.
Version 3 of this patchset mostly fixes drm_gem_pri
The i.MX DCSS 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, .gem_prime_export and .gem_prime_import, were initialized
to their
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 armada.
Signed-off-by: Thomas Zimmermann
Acked-by: Russell King
---
drivers/gpu/drm/armada/armada_drv.c | 3 ---
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 msm. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vet
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
Reviewed-by: Daniel
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
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_drv.c| 1 -
driv
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
Acked-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 4
drivers/gpu/drm/tegra/g
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 mediatek. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Danie
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.
v3:
* update documentation
Signed-off-by: T
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
Reviewed-by: Melissa Wen
---
drivers/gpu/drm/vkms/vkms_drv.c | 8
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 vgem. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Melissa W
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
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 9 -
d
flight 154617 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154617/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-1 68 xtf/test-hvm64-xsa-221 fail REGR. vs. 154350
test-xtf-amd64
On 23/09/2020 11:09, Paul Durrant wrote:
-Original Message-
From: Xen-devel On Behalf Of Julien
Grall
Sent: 23 September 2020 10:04
To: Simon Leiner
Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
; Bertrand Marquis
; Oleksandr Tyshchenko
Subject: Re: Virtio Xen (WAS: 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()
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
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
Hi,
> On 23 Sep 2020, at 09:28, Julien Grall wrote:
>
> From: Julien Grall
>
> SMMUv{1, 2} are both marked as security supported, so we would
> technically have to issue an XSA for any IOMMU security bug.
>
> However, at the moment, device passthrough is not security supported
> on Arm and th
Hi Julien,
> On 22 Sep 2020, at 20:31, Julien Grall wrote:
>
> From: Julien Grall
>
> Some callers of vcpu_pause() will expect to access the latest vcpu
> context when the function returns (see XENDOMCTL_{set,get}vcpucontext}.
>
> However, the latest vCPU context can only be observed after
>
On 23/09/2020 11:50, Bertrand Marquis wrote:
Hi,
On 23 Sep 2020, at 09:28, Julien Grall wrote:
From: Julien Grall
SMMUv{1, 2} are both marked as security supported, so we would
technically have to issue an XSA for any IOMMU security bug.
However, at the moment, device passthrough is not
Hi Thomas,
On Wed, Sep 23, 2020 at 12:21:44PM +0200, Thomas Zimmermann wrote:
> The i.MX DCSS 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 chan
On 23/09/2020 12:08, Bertrand Marquis wrote:
Hi Julien,
On 22 Sep 2020, at 20:31, Julien Grall wrote:
From: Julien Grall
Some callers of vcpu_pause() will expect to access the latest vcpu
context when the function returns (see XENDOMCTL_{set,get}vcpucontext}.
However, the latest vCPU co
flight 154637 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154637/
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 22.09.20 18:52, Jan Beulich wrote:
Hi Jan
On 22.09.2020 17:05, Oleksandr wrote:
2. *arch.hvm.params*: Two functions that use it
(hvm_alloc_legacy_ioreq_gfn/hvm_free_legacy_ioreq_gfn) either go into
arch code completely or
specific macro is used in common code:
#define ioreq_ge
On Mi, 2020-09-23 at 12:21 +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 etnaviv. The only exception is gem_prime_mmap,
> which is non-trivial
On 9/23/20 12:56 PM, Stefan Hajnoczi wrote:
> clang's C11 atomic_fetch_*() functions only take a C11 atomic type
> pointer argument. QEMU uses direct types (int, etc) and this causes a
> compiler error when a QEMU code calls these functions in a source file
> that also included via a system header
> -Original Message-
> From: Anthony PERARD
> Sent: 23 September 2020 12:03
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Anthony PERARD ;
> Ian Jackson
> ; Wei Liu
> Subject: [XEN PATCH] tools: Fix configure of upstream QEMU
>
> QEMU as recently switch its build system to u
On Wed, Sep 23, 2020 at 10:52:33AM +0100, Tvrtko Ursulin wrote:
>
> On 18/09/2020 17:37, Christoph Hellwig wrote:
>> i915_gem_object_map implements fairly low-level vmap functionality in
>> a driver. Split it into two helpers, one for remapping kernel memory
>> which can use vmap, and one for I/O
> On 23 Sep 2020, at 12:27, Julien Grall wrote:
>
>
>
> On 23/09/2020 12:08, Bertrand Marquis wrote:
>> Hi Julien,
>>> On 22 Sep 2020, at 20:31, Julien Grall wrote:
>>>
>>> From: Julien Grall
>>>
>>> Some callers of vcpu_pause() will expect to access the latest vcpu
>>> context when the f
Hi,
> On 22 Sep 2020, at 20:31, Julien Grall wrote:
>
> From: Julien Grall
>
> Some callers of vcpu_pause() will expect to access the latest vcpu
> context when the function returns (see XENDOMCTL_{set,get}vcpucontext}.
>
> However, the latest vCPU context can only be observed after
> v->is_r
> On 23 Sep 2020, at 12:17, Julien Grall wrote:
>
>
>
> On 23/09/2020 11:50, Bertrand Marquis wrote:
>> Hi,
>>> On 23 Sep 2020, at 09:28, Julien Grall wrote:
>>>
>>> From: Julien Grall
>>>
>>> SMMUv{1, 2} are both marked as security supported, so we would
>>> technically have to issue an
On 23/09/2020 14:41, Christoph Hellwig wrote:
On Wed, Sep 23, 2020 at 10:52:33AM +0100, Tvrtko Ursulin wrote:
On 18/09/2020 17:37, Christoph Hellwig wrote:
i915_gem_object_map implements fairly low-level vmap functionality in
a driver. Split it into two helpers, one for remapping kernel mem
On 23/09/2020 14:55, Bertrand Marquis wrote:
On 23 Sep 2020, at 12:17, Julien Grall wrote:
More that it make more sense in general to have SMMUv3 with 2 level of page
table supporting this then old SMMU versions.
Both driver are equally important. I wouldn't discard SMMUv2 just
because t
Hi,
I'm facing an issue with libvirt and the LIBXL driver, failing when searching
for DMI data in /sys.
info : libvirt version: 5.0.0, package: 4+deb10u1 (Guido Günther
Thu, 05 Dec 2019 00:22:14 +0100)
error : udevGetDMIData:1719 : internal error: Failed to get udev device for
syspath '/sys/d
Despite appearing to be a deliberate design choice of early PV64, the
resulting behaviour for unregistered SYSCALL callbacks creates an untenable
testability problem for Xen. Furthermore, the behaviour is undocumented,
bizarre, and inconsistent with related behaviour in Xen, and very liable
introd
A 64bit IRET can restore NT - the faulting case is when NT is set in the live
flags. This change had an unintended consequence of causing the NT flag to
spontaneously disappear from guest context whenever a interrupt/exception
occurred.
In combination with a SYSENTER which sets both TF and NT, Xe
Patches 1 and 2 are a consequence of trying to get the Linux x86 selftests to
pass even when running under Xen.
Patches 3 and XSA-339 were further fallout from trying to put in place testing
to cover all aspects of the PV fast system call entrypoints.
Patch 3 was almost an XSA itself, but was ult
It is a matter of guest kernel policy what to do with offending userspace, and
terminating said userspace may not be the action chosen.
Linux explicitly tolerates this case.
Reported-by: Andy Lutomirski
Fixes: fdac951560 ("x86: clear EFLAGS.NT in SYSENTER entry path")
Signed-off-by: Andrew Coope
flight 154619 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154619/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-1 68 xtf/test-hvm64-xsa-221 fail REGR. vs. 151714
test-xtf-amd64
On 9/16/20 9:31 PM, David Hildenbrand wrote:
>
>
>> Am 16.09.2020 um 20:50 schrieb osalva...@suse.de:
>>
>> On 2020-09-16 20:34, David Hildenbrand wrote:
>>> When adding separate memory blocks via add_memory*() and onlining them
>>> immediately, the metadata (especially the memmap) of the next
Feel free to add an Acked-by: Christian König
to all patches which I haven't explicitly reviewed.
I would say we should just push this to drm-misc-next now.
Thanks for the nice cleanup,
Christian.
Am 23.09.20 um 12:21 schrieb Thomas Zimmermann:
The GEM and PRIME related callbacks in struct d
On Wed, Sep 23, 2020 at 02:58:43PM +0100, Tvrtko Ursulin wrote:
>>> Series did not get a CI run from our side because of a different base so I
>>> don't know if you would like to have a run there? If so you would need to
>>> rebase against git://anongit.freedesktop.org/drm-tip drm-tip and you could
QEMU as recently switch its build system to use meson and the
./configure step with meson is more restrictive that the step used to
be, most installation path wants to be within prefix, otherwise we
have this error message:
ERROR: The value of the 'datadir' option is '/usr/share/qemu-xen' whic
On Wed, Sep 23, 2020 at 11:56:46AM +0100, Stefan Hajnoczi wrote:
> clang's C11 atomic_fetch_*() functions only take a C11 atomic type
> pointer argument. QEMU uses direct types (int, etc) and this causes a
> compiler error when a QEMU code calls these functions in a source file
> that also included
On 23.09.20 16:31, Vlastimil Babka wrote:
> On 9/16/20 9:31 PM, David Hildenbrand wrote:
>>
>>
>>> Am 16.09.2020 um 20:50 schrieb osalva...@suse.de:
>>>
>>> On 2020-09-16 20:34, David Hildenbrand wrote:
When adding separate memory blocks via add_memory*() and onlining them
immediately, t
From: Paul Durrant
Currently a single watch on /local/domain/X/backend is registered by each
QEMU process running in service domain X (where X is usually 0). The purpose
of this watch is to ensure that QEMU is notified when the Xen toolstack
creates a new device backend area.
Such a backend area
Hi,
On 10/09/2020 21:21, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
As a lot of x86 code can be re-used on Arm later on, this patch
prepares IOREQ support before moving to the common code. This way
we will get almost a verbatim copy for a code movement.
FWIW, I agree with Jan tha
Hi,
On 14/09/2020 15:59, Jan Beulich wrote:
On 10.09.2020 22:21, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/ioreq.h
+++ b/xen/include/xen/ioreq.h
@@ -35,6 +35,13 @@ static inline struct hvm_ioreq_server
*get_ioreq_server(const struct domain *d,
return GET_IOREQ_SERVER(d, id);
}
Hi Oleksandr,
On 10/09/2020 21:21, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and Arm will have its own
implementation.
But the name of the function is pretty generic and can be confusing
on Arm (we already have a try_handle_mmio()).
In order not
On 10/09/2020 21:22, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
I believe I am the original author of this code. So this needs to be
fixed accordingly.
As a lot of x86 code can be re-used on Arm later on, this patch
splits devicemodel support into common and arch specific p
On Wed, 23 Sep 2020, Bertrand Marquis wrote:
> > On 23 Sep 2020, at 12:17, Julien Grall wrote:
> > On 23/09/2020 11:50, Bertrand Marquis wrote:
> >> Hi,
> >>> On 23 Sep 2020, at 09:28, Julien Grall wrote:
> >>>
> >>> From: Julien Grall
> >>>
> >>> SMMUv{1, 2} are both marked as security suppor
On Wed, 23 Sep 2020, Julien Grall wrote:
> From: Julien Grall
>
> SMMUv{1, 2} are both marked as security supported, so we would
> technically have to issue an XSA for any IOMMU security bug.
>
> However, at the moment, device passthrough is not security supported
> on Arm and there is no plan t
On Wed, 23 Sep 2020, Bertrand Marquis wrote:
> Hi,
>
> > On 22 Sep 2020, at 20:31, Julien Grall wrote:
> >
> > From: Julien Grall
> >
> > Some callers of vcpu_pause() will expect to access the latest vcpu
> > context when the function returns (see XENDOMCTL_{set,get}vcpucontext}.
> >
> > Howe
Hi,
On 10/09/2020 21:22, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
I believe I am the originally author of this code...
This patch adds basic IOREQ/DM support on Arm. The subsequent
patches will improve functionality, add remaining bits as well as
address several TODOs.
Find a
Hi Oleksandr,
On 10/09/2020 21:22, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The cmpxchg() in hvm_send_buffered_ioreq() operates on memory shared
with the emulator. In order to be on the safe side we need to switch
to guest_cmpxchg64() to prevent a domain to DoS Xen on Arm.
CC: J
On 23.09.20 20:22, Julien Grall wrote:
Hi,
Hi Julien
On 10/09/2020 21:21, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
As a lot of x86 code can be re-used on Arm later on, this patch
prepares IOREQ support before moving to the common code. This way
we will get almost a verbat
On 22/09/2020 21:05, Oleksandr wrote:
On 16.09.20 12:12, Julien Grall wrote:
Hi all.
On 16/09/2020 10:09, Paul Durrant wrote:
-Original Message-
From: Julien Grall
Sent: 16 September 2020 10:07
To: Jan Beulich ; Oleksandr Tyshchenko
Cc: xen-devel@lists.xenproject.org; Oleksan
On 23.09.20 20:28, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 10/09/2020 21:21, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and Arm will have its own
implementation.
But the name of the function is pretty generic and can be confusing
on
On 23.09.20 20:35, Julien Grall wrote:
Hi Julien
On 10/09/2020 21:22, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
I believe I am the original author of this code. So this needs to be
fixed accordingly.
Sorry, will fix.
--
Regards,
Oleksandr Tyshchenko
flight 154639 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154639/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-prev
On Tue, Sep 22, 2020 at 09:01:25AM +0200, SeongJae Park wrote:
> From: SeongJae Park
>
> Persistent grants feature provides high scalability. On some small
> systems, however, it could incur data copy overhead[1] and thus it is
> required to be disabled. But, there is no option to disable it.
On 23.09.20 21:03, Julien Grall wrote:
Hi,
Hi Julien
On 10/09/2020 21:22, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
I believe I am the originally author of this code...
Sorry, will fix
This patch adds basic IOREQ/DM support on Arm. The subsequent
patches will impro
On 23.09.20 21:12, Julien Grall wrote:
Hi Julien
On 16/09/2020 10:04, Jan Beulich wrote:
On 10.09.2020 22:22, Oleksandr Tyshchenko wrote:
@@ -1325,7 +1327,7 @@ static int hvm_send_buffered_ioreq(struct
hvm_ioreq_server *s, ioreq_t *p)
new.read_pointer = old.read_pointer - n
flight 154622 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154622/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4 68 xtf/test-hvm64-xsa-221 fail REGR. vs. 154601
test-xtf-amd64
flight 154650 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154650/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
examine-italia0 5 host-installbroken like 152701
examine-albana1 2 hosts-all
On Mon, 21 Sep 2020, Andrew Cooper wrote:
> On 21/09/2020 19:02, Julien Grall wrote:
> > From: Julien Grall
> >
> > On x86, mfn_to_gmfn can be replaced with mfn_to_gfn. On Arm, there are
> > no more call to mfn_to_gmfn, so the helper can be dropped.
>
> The previous patch dropped the mfn_to_gmfn(
On Mon, 21 Sep 2020, Julien Grall wrote:
> On 21/09/2020 13:55, Durrant, Paul wrote:
> > > (+ Xen-devel)
> > >
> > > Sorry I forgot to CC xen-devel.
> > >
> > > On 21/09/2020 12:38, Julien Grall wrote:
> > > > Hi all,
> > > >
> > > > I have started to look at the deferral code (see
> > > > vcpu_
flight 154625 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154625/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4 68 xtf/test-hvm64-xsa-221 fail REGR. vs. 154358
test-xtf-amd64
flight 154632 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154632/
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
On Wed, Sep 23, 2020 at 04:31:25PM +0200, Vlastimil Babka wrote:
>On 9/16/20 9:31 PM, David Hildenbrand wrote:
>>
>>
>>> Am 16.09.2020 um 20:50 schrieb osalva...@suse.de:
>>>
>>> On 2020-09-16 20:34, David Hildenbrand wrote:
When adding separate memory blocks via add_memory*() and onlining
flight 154629 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154629/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 152631
test-amd64-i386-x
flight 154659 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154659/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-prev
flight 154633 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154633/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf dd5c7e3c5282b084daa5bbf0ec229cec699b2c17
baseline version:
ovmf fb97626fe04747ec89599
On Wed, 23 Sep 2020 16:09:30 -0400 Konrad Rzeszutek Wilk
wrote:
> On Tue, Sep 22, 2020 at 09:01:25AM +0200, SeongJae Park wrote:
> > From: SeongJae Park
> >
> > Persistent grants feature provides high scalability. On some small
> > systems, however, it could incur data copy overhead[1] and th
93 matches
Mail list logo
