On 14.10.2020 18:27, Jason Andryuk wrote:
> On Wed, Oct 14, 2020 at 12:02 PM Jan Beulich wrote:
>>
>> On 14.10.2020 17:31, Jason Andryuk wrote:
>>> Linux kernels only have an ENTRY elfnote when built with CONFIG_PV. A
>>> kernel build CONFIG_PVH=y CONFIG_PV=n lacks the note. In this case,
>>> vi
On 14.10.2020 18:42, Igor Druzhinin wrote:
> On 14/10/2020 16:47, Jan Beulich wrote:
>> On 13.10.2020 05:02, Igor Druzhinin wrote:
>>> LBR, C-state MSRs and if_pschange_mc erratum applicability should correspond
>>> to Ice Lake desktop according to External Design Specification vol.2.
>>
>> Could y
flight 155825 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155825/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b9b7406c43e9d29bde3e9679c1b039cb91109097
baseline version:
ovmf 5d0a827122cccd1f884fa
On 14.10.2020 20:00, Andrew Cooper wrote:
> On 13/10/2020 16:51, Jan Beulich wrote:
>> On 12.10.2020 15:49, Andrew Cooper wrote:
>>> All interrupts and exceptions pass a struct cpu_user_regs up into C. This
>>> contains the legacy vm86 fields from 32bit days, which are beyond the
>>> hardware-push
After a short discussion on IRC yesterday I promised to send a mail
how I think we could get rid of creating dynamic links especially
for header files in the Xen build process.
This will require some restructuring, the amount will depend on the
selected way to proceed:
- avoid links completely,
On 14.10.2020 15:57, Andrew Cooper wrote:
> On 13/10/2020 16:58, Jan Beulich wrote:
>> On 09.10.2020 17:09, Andrew Cooper wrote:
>>> At the time of XSA-170, the x86 instruction emulator really was broken, and
>>> would allow arbitrary non-canonical values to be loaded into %rip. This was
>>> fixed
On 14.10.2020 19:53, Jason Andryuk wrote:
> @@ -76,7 +80,9 @@ config XEN_DEBUG_FS
> Enabling this option may incur a significant performance overhead.
>
> config XEN_PVH
> - bool "Support for running as a Xen PVH guest"
> + bool "Xen PVH guest support"
Tangential question: Is "g
On 15.10.2020 02:38, Dylanger Daly wrote:
> I'm currently using Xen 4.14 (Qubes 4.1 OS) on a Ryzen 7 4750U PRO, by
> default I'll experience softlocks where the mouse for example will jolt from
> time to time, in this state it's not usable.
>From what you say below I imply this is in Dom0?
> Ad
On 14.10.2020 22:41, osstest service owner wrote:
> flight 155811 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/155811/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64
On 14.10.2020 18:14, Bertrand Marquis wrote:
> Add a check for snprintf return code and ignore the entry if we get an
> error. This should in fact never happen and is more a trick to make gcc
> happy and prevent compilation errors.
>
> This is solving the following gcc warning when compiling for a
Doing so isn't appropriate here - this gets done very early in the build
process. If the directory is mean to to be buildable on its own,
different arrangements would be needed.
The issue has become more pronounced by 47654a0d7320 ("tools/include:
fix (drop) dependencies of when to populate xen/")
On 14.10.2020 20:47, Andrew Cooper wrote:
> cpu_smpboot_alloc() is designed to be idempotent with respect to partially
> initialised state. This occurs for S3 and CPU parking, where enough state to
> handle NMIs/#MCs needs to remain valid for the entire lifetime of Xen, even
> when we otherwise wa
Hi Jan, thank you for responding.
Indeed this is for dom0, I only recently tried limiting a domU to 1 core and
observed absolutely no softlocks, UI animations are smooth as butter with 1
core only.
Indeed I believe this is a CPU Scheduling issue, I've tried both the older
credit and RTDS howev
Hi,
> On 15 Oct 2020, at 09:33, Jan Beulich wrote:
>
> On 14.10.2020 18:14, Bertrand Marquis wrote:
>> Add a check for snprintf return code and ignore the entry if we get an
>> error. This should in fact never happen and is more a trick to make gcc
>> happy and prevent compilation errors.
>>
>>
Add a check for snprintf return code and ignore the entry if we get an
error. This should in fact never happen and is more a trick to make gcc
happy and prevent compilation errors.
This is solving the following gcc warning when compiling for arm32 host
platforms with optimization activated:
xenpmd
On 15.10.2020 11:14, Dylanger Daly wrote:
> Indeed this is for dom0, I only recently tried limiting a domU to 1 core and
> observed absolutely no softlocks, UI animations are smooth as butter with 1
> core only.
>
> Indeed I believe this is a CPU Scheduling issue, I've tried both the older
> cr
On 14.10.20 19:53, Jason Andryuk wrote:
Moving XEN_512GB allows it to nest under XEN_PV. That also allows
XEN_PVH to nest under XEN as a sibling to XEN_PV and XEN_PVHVM giving:
[*] Xen guest support
[*] Xen PV guest support
[*] Limit Xen pv-domain memory to 512GB
[*] Xen PV Do
On 15.10.2020 09:58, Jürgen Groß wrote:
> After a short discussion on IRC yesterday I promised to send a mail
> how I think we could get rid of creating dynamic links especially
> for header files in the Xen build process.
>
> This will require some restructuring, the amount will depend on the
> s
Hi,
> On 14 Oct 2020, at 22:15, Stefano Stabellini wrote:
>
> On Wed, 14 Oct 2020, Julien Grall wrote:
>> On 14/10/2020 17:03, Bertrand Marquis wrote:
On 14 Oct 2020, at 12:35, Andrew Cooper wrote:
On 14/10/2020 11:41, Bertrand Marquis wrote:
> When a Cortex A57 processor is
flight 155819 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155819/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 13 guest-startfail REGR. vs. 152631
test-amd64-amd64-
On 15.10.20 12:09, Jan Beulich wrote:
On 15.10.2020 09:58, Jürgen Groß wrote:
After a short discussion on IRC yesterday I promised to send a mail
how I think we could get rid of creating dynamic links especially
for header files in the Xen build process.
This will require some restructuring, th
On Wed, Oct 07, 2020 at 03:30:09PM +0200, Juergen Gross wrote:
> Move sending of a virq event for oprofile to the local vcpu from NMI
> to softirq context.
>
> This has been tested with a small test patch using the continuation
> framework of patch 1 for all NMIs and doing a print to console in
>
On 15.10.20 12:09, Jan Beulich wrote:
On 15.10.2020 09:58, Jürgen Groß wrote:
After a short discussion on IRC yesterday I promised to send a mail
how I think we could get rid of creating dynamic links especially
for header files in the Xen build process.
This will require some restructuring, th
On 15.10.20 12:49, Roger Pau Monné wrote:
On Wed, Oct 07, 2020 at 03:30:09PM +0200, Juergen Gross wrote:
Move sending of a virq event for oprofile to the local vcpu from NMI
to softirq context.
This has been tested with a small test patch using the continuation
framework of patch 1 for all NMIs
On Tue, Oct 13, 2020 at 07:26:47AM +0200, J. Roeleveld wrote:
> Hi All,
>
> I am seeing the following message in the "dmesg" output of a driver domain.
>
> [Thu Oct 8 20:57:04 2020] xen-blkback: Scheduled work from previous purge is
> still busy, cannot purge list
> [Thu Oct 8 20:57:11 2020] x
On Wed, Oct 14, 2020 at 02:17:15PM +0200, Jan Beulich wrote:
> On 07.10.2020 12:20, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/msr.c
> > +++ b/xen/arch/x86/msr.c
> > @@ -253,6 +253,12 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t
> > *val)
> > break;
> > goto g
On Wed, Oct 14, 2020 at 08:37:06PM +0100, Andrew Cooper wrote:
> On 14/10/2020 20:28, Jason Andryuk wrote:
> > Hi,
> >
> > Bug opened at https://gitlab.freedesktop.org/drm/intel/-/issues/2576
> >
> > I'm seeing DMA faults for the i915 graphics hardware on a Dell
> > Latitude 5500. These were captur
On 15/10/2020 01:38, Dylanger Daly wrote:
> Hi All,
>
> I'm currently using Xen 4.14 (Qubes 4.1 OS) on a Ryzen 7 4750U PRO, by
> default I'll experience softlocks where the mouse for example will
> jolt from time to time, in this state it's not usable.
>
> Adding `dom0_max_vcpus=1 dom0_vcpus_pin` t
Please don't drop xen-devel mailing list when replying.
On Thu, Oct 15, 2020 at 01:28:49PM +0200, J. Roeleveld wrote:
> On Thursday, October 15, 2020 12:57:35 PM CEST you wrote:
> > On Tue, Oct 13, 2020 at 07:26:47AM +0200, J. Roeleveld wrote:
> > > Hi All,
> > >
> > > I am seeing the following m
On 14.10.2020 13:40, Julien Grall wrote:
> Hi Jan,
>
> On 13/10/2020 15:26, Jan Beulich wrote:
>> On 13.10.2020 16:20, Jürgen Groß wrote:
>>> On 13.10.20 15:58, Jan Beulich wrote:
On 12.10.2020 11:27, Juergen Gross wrote:
> The queue for a fifo event is depending on the vcpu_id and the
>>
The parameters map and is_iomem are always of the same value. Removed them
to prepares the function for conversion to struct dma_buf_map.
v4:
* don't check for !kmap->virtual; will always be false
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem_v
The functions exynos_drm_gem_prime_{vmap,vunmap}() are empty. Remove
them before changing the interface to use struct drm_buf_map. As a side
effect of removing drm_gem_prime_vmap(), the error code changes from
ENOMEM to EOPNOTSUPP.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/exynos/exyn
DRM's fbdev console uses regular load and store operations to update
framebuffer memory. The bochs driver on sparc64 requires the use of
I/O-specific load and store operations. We have a workaround, but need
a long-term solution to the problem.
This patchset changes GEM's vmap/vunmap interfaces to
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
address space. The mapping's address is returned as struct dma_buf_map.
Each function is a simplified version of TTM's existing kmap code. Both
functions respect the memory's location ani/or writecombine flags.
On top TTM's
At least sparc64 requires I/O-specific access to framebuffers. This
patch updates the fbdev console accordingly.
For drivers with direct access to the framebuffer memory, the callback
functions in struct fb_ops test for the type of memory and call the rsp
fb_sys_ of fb_cfb_ functions.
For drivers
This patch replaces the vmap/vunmap's use of raw pointers in GEM object
functions with instances of struct dma_buf_map. GEM backends are
converted as well. For most of them, this simply changes the returned type.
TTM-based drivers now return information about the location of the memory,
either sys
The function drm_gem_cma_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_cma_helper.c | 17 -
drivers/gpu/drm/vc4/vc4_bo.c | 1 -
include/drm/drm_gem_cma_helper.h
GEM's vmap and vunmap interfaces now wrap memory pointers in struct
dma_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_client.c | 18 +++---
drivers/gpu/drm/drm_gem.c | 26 +-
drivers/gpu/drm/drm_internal.h
Kernel DRM clients now store their framebuffer address in an instance
of struct dma_buf_map. Depending on the buffer's location, the address
refers to system or I/O memory.
Callers of drm_client_buffer_vmap() receive a copy of the value in
the call's supplied arguments. It can be accessed and modi
To do framebuffer updates, one needs memcpy from system memory and a
pointer-increment function. Add both interfaces with documentation.
Signed-off-by: Thomas Zimmermann
---
include/linux/dma-buf-map.h | 72 +++--
1 file changed, 62 insertions(+), 10 deletions(-)
On 10/14/20 1:53 PM, Jason Andryuk wrote:
> +config XEN_512GB
> + bool "Limit Xen pv-domain memory to 512GB"
> + depends on XEN_PV && X86_64
Why is X86_64 needed here?
-boris
The function etnaviv_gem_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem_prim
On Thursday, October 15, 2020 2:00:46 PM CEST Roger Pau Monné wrote:
> Please don't drop xen-devel mailing list when replying.
My apologies, most mailing lists I am active on have a working "reply" button.
Here I need to use "reply-all".
> On Thu, Oct 15, 2020 at 01:28:49PM +0200, J. Roeleveld
flight 155831 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155831/
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 Thu, Oct 15, 2020 at 02:53:34PM +0200, J. Roeleveld wrote:
> On Thursday, October 15, 2020 2:00:46 PM CEST Roger Pau Monné wrote:
> > Please don't drop xen-devel mailing list when replying.
>
> My apologies, most mailing lists I am active on have a working "reply"
> button.
> Here I need to u
On 15/10/2020 13:37, boris.ostrov...@oracle.com wrote:
> On 10/14/20 1:53 PM, Jason Andryuk wrote:
>> +config XEN_512GB
>> +bool "Limit Xen pv-domain memory to 512GB"
>> +depends on XEN_PV && X86_64
>
> Why is X86_64 needed here?
>512G support was implemented using a direct-mapped P2M, and
Jan Beulich writes ("[PATCH] tools/gdbsx: drop stray recursion into
tools/include/"):
> Doing so isn't appropriate here - this gets done very early in the build
> process. If the directory is mean to to be buildable on its own,
> different arrangements would be needed.
>
> The issue has become mo
On 10/15/20 9:10 AM, Andrew Cooper wrote:
> On 15/10/2020 13:37, boris.ostrov...@oracle.com wrote:
>> On 10/14/20 1:53 PM, Jason Andryuk wrote:
>>> +config XEN_512GB
>>> + bool "Limit Xen pv-domain memory to 512GB"
>>> + depends on XEN_PV && X86_64
>> Why is X86_64 needed here?
>> 512G suppor
On Wed, Oct 07, 2020 at 06:41:17PM +0200, Roger Pau Monné wrote:
> On Wed, Oct 07, 2020 at 01:06:08PM +0100, Andrew Cooper wrote:
> > On 06/10/2020 17:23, Roger Pau Monne wrote:
> > > Currently a PV hardware domain can also be given control over the CPU
> > > frequency, and such guest is allowed to
flight 155842 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155842/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 155828
Tests which
Am 15.10.20 um 14:37 schrieb Thomas Zimmermann:
The parameters map and is_iomem are always of the same value. Removed them
to prepares the function for conversion to struct dma_buf_map.
v4:
* don't check for !kmap->virtual; will always be false
Signed-off-by: Thomas Zimmermann
Reviewed
Am 15.10.20 um 14:37 schrieb Thomas Zimmermann:
The function drm_gem_cma_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
---
drivers/gpu/drm/drm_gem_cma_helper.c | 17 ---
Am 15.10.20 um 14:37 schrieb Thomas Zimmermann:
The function etnaviv_gem_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
drivers/
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
The functions exynos_drm_gem_prime_{vmap,vunmap}() are empty. Remove
them before changing the interface to use struct drm_buf_map. As a side
effect of removing drm_gem_prime_vmap(), the error code changes from
ENOMEM to EOPNOTSUPP.
Signed-off-by: T
On 15/10/2020 09:50, Jan Beulich wrote:
> On 14.10.2020 20:47, Andrew Cooper wrote:
>> cpu_smpboot_alloc() is designed to be idempotent with respect to partially
>> initialised state. This occurs for S3 and CPU parking, where enough state to
>> handle NMIs/#MCs needs to remain valid for the entire
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
address space. The mapping's address is returned as struct dma_buf_map.
Each function is a simplified version of TTM's existing kmap code. Both
functions respect the memory's
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
This patch replaces the vmap/vunmap's use of raw pointers in GEM object
functions with instances of struct dma_buf_map. GEM backends are
converted as well. For most of them, this simply changes the returned type.
TTM-based drivers now return inform
Assume that reads and writes to the variable will be atomic. The worse
that could happen is that one of the purges removes a partially
written percentage of grants, but the cache itself will recover.
Signed-off-by: Roger Pau Monné
---
Cc: Konrad Rzeszutek Wilk
Cc: Jens Axboe
Cc: Boris Ostrovsky
Add the LRU parameters as tunables.
Roger Pau Monne (2):
xen/blkback: turn the cache purge LRU interval into a parameter
xen/blkback: turn the cache purge percent into a parameter
.../ABI/testing/sysfs-driver-xen-blkback | 19 +++
drivers/block/xen-blkback/blkback.c
Assume that reads and writes to the variable will be atomic. The worse
that could happen is that one of the LRU intervals is not calculated
properly if a partially written value is read, but that would only be
a transient issue.
Signed-off-by: Roger Pau Monné
---
Cc: Konrad Rzeszutek Wilk
Cc: Je
On 15.10.20 16:24, Roger Pau Monne wrote:
Assume that reads and writes to the variable will be atomic. The worse
that could happen is that one of the LRU intervals is not calculated
properly if a partially written value is read, but that would only be
a transient issue.
Signed-off-by: Roger Pau
flight 155837 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155837/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 19c87b7d446c3273e84b238cb02cd1c0ae69c43e
baseline version:
ovmf b9b7406c43e9d29bde3e9
On 15.10.20 16:24, Roger Pau Monne wrote:
Assume that reads and writes to the variable will be atomic. The worse
that could happen is that one of the purges removes a partially
written percentage of grants, but the cache itself will recover.
Signed-off-by: Roger Pau Monné
---
Cc: Konrad Rzeszut
On Thu, Oct 15, 2020 at 04:37:52PM +0200, Jürgen Groß wrote:
> On 15.10.20 16:24, Roger Pau Monne wrote:
> > Assume that reads and writes to the variable will be atomic. The worse
> > that could happen is that one of the purges removes a partially
> > written percentage of grants, but the cache its
On Thu, Oct 15, 2020 at 3:00 AM Jan Beulich wrote:
>
> On 14.10.2020 18:27, Jason Andryuk wrote:
> > On Wed, Oct 14, 2020 at 12:02 PM Jan Beulich wrote:
> >>
> >> On 14.10.2020 17:31, Jason Andryuk wrote:
> >>> Linux kernels only have an ENTRY elfnote when built with CONFIG_PV. A
> >>> kernel bu
On Thu, Oct 15, 2020 at 9:17 AM wrote:
>
>
> On 10/15/20 9:10 AM, Andrew Cooper wrote:
> > On 15/10/2020 13:37, boris.ostrov...@oracle.com wrote:
> >> On 10/14/20 1:53 PM, Jason Andryuk wrote:
> >>> +config XEN_512GB
> >>> + bool "Limit Xen pv-domain memory to 512GB"
> >>> + depends on XEN_PV
On Thu, Oct 15, 2020 at 5:42 AM Jürgen Groß wrote:
>
> On 14.10.20 19:53, Jason Andryuk wrote:
> > Moving XEN_512GB allows it to nest under XEN_PV. That also allows
> > XEN_PVH to nest under XEN as a sibling to XEN_PV and XEN_PVHVM giving:
> >
> > [*] Xen guest support
> > [*] Xen PV guest
On Thu, Oct 15, 2020 at 4:10 AM Jan Beulich wrote:
>
> On 14.10.2020 19:53, Jason Andryuk wrote:
> > @@ -76,7 +80,9 @@ config XEN_DEBUG_FS
> > Enabling this option may incur a significant performance overhead.
> >
> > config XEN_PVH
> > - bool "Support for running as a Xen PVH guest"
flight 155839 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155839/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 155770
test-amd64-amd64-xl-qemuu-ws16-amd64 19 g
On 15.10.2020 16:59, Jason Andryuk wrote:
> On Thu, Oct 15, 2020 at 4:10 AM Jan Beulich wrote:
>>
>> On 14.10.2020 19:53, Jason Andryuk wrote:
>>> @@ -76,7 +80,9 @@ config XEN_DEBUG_FS
>>> Enabling this option may incur a significant performance overhead.
>>>
>>> config XEN_PVH
>>> -
On Thu, Oct 15, 2020 at 09:00:09AM +0200, Jan Beulich wrote:
> On 14.10.2020 18:27, Jason Andryuk wrote:
> > On Wed, Oct 14, 2020 at 12:02 PM Jan Beulich wrote:
> >>
> >> On 14.10.2020 17:31, Jason Andryuk wrote:
> >>> Linux kernels only have an ENTRY elfnote when built with CONFIG_PV. A
> >>> ke
On Thu, Oct 15, 2020 at 05:02:21PM +0200, Jan Beulich wrote:
> On 15.10.2020 16:59, Jason Andryuk wrote:
> > On Thu, Oct 15, 2020 at 4:10 AM Jan Beulich wrote:
> >>
> >> On 14.10.2020 19:53, Jason Andryuk wrote:
> >>> @@ -76,7 +80,9 @@ config XEN_DEBUG_FS
> >>> Enabling this option may inc
On Thu, 15 Oct 2020 16:24:15 +0200 Roger Pau Monne wrote:
> Assume that reads and writes to the variable will be atomic. The worse
> that could happen is that one of the LRU intervals is not calculated
> properly if a partially written value is read, but that would only be
> a transient issue.
>
On 15.10.2020 16:50, Jason Andryuk wrote:
> On Thu, Oct 15, 2020 at 3:00 AM Jan Beulich wrote:
>> And why is there no bounds check of ->phys_entry paralleling the
>> ->virt_entry one?
>
> What is the purpose of this checking? It's sanity checking which is
> generally good, but what is the harm f
On 15.10.2020 16:02, Andrew Cooper wrote:
> On 15/10/2020 09:50, Jan Beulich wrote:
>> On 14.10.2020 20:47, Andrew Cooper wrote:
>>> cpu_smpboot_alloc() is designed to be idempotent with respect to partially
>>> initialised state. This occurs for S3 and CPU parking, where enough state
>>> to
>>>
On Thu, Oct 15, 2020 at 7:31 AM Roger Pau Monné wrote:
>
> On Wed, Oct 14, 2020 at 08:37:06PM +0100, Andrew Cooper wrote:
> > On 14/10/2020 20:28, Jason Andryuk wrote:
> > > Hi,
> > >
> > > Bug opened at https://gitlab.freedesktop.org/drm/intel/-/issues/2576
> > >
> > > I'm seeing DMA faults for t
flight 155829 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155829/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-qem
flight 155832 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155832/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 12 debian-install fail REGR. vs. 155788
build-amd64-xsm
On Thu, Oct 15, 2020 at 03:24:34PM +, osstest service owner wrote:
> flight 155829 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/155829/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i
From: Ian Jackson
NFC.
Signed-off-by: Ian Jackson
---
cri-args-hostlists | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/cri-args-hostlists b/cri-args-hostlists
index 7019c0c7..52e39f33 100644
--- a/cri-args-hostlists
+++ b/cri-args-hostlists
@@ -128,
These are large and not very useful. A copy is in the tree if needed.
Signed-off-by: Ian Jackson
---
mg-execute-flight | 3 ---
1 file changed, 3 deletions(-)
diff --git a/mg-execute-flight b/mg-execute-flight
index 391f4810..bef8dab6 100755
--- a/mg-execute-flight
+++ b/mg-execute-flight
@@ -
We discussed this at the Xen Summit. What I do here is immediate
retry the jobs with regressions, and then reanalyse the original full
flight. If the retries showed the failures were heisenbugs, this will
let them though.
This should reduce the negative impact on development, of heisenbugs,
but
From: Ian Jackson
No effect if this is empty.
Signed-off-by: Ian Jackson
---
cri-args-hostlists | 1 +
1 file changed, 1 insertion(+)
diff --git a/cri-args-hostlists b/cri-args-hostlists
index 6cdff53f..7019c0c7 100644
--- a/cri-args-hostlists
+++ b/cri-args-hostlists
@@ -121,6 +121,7 @@ star
This is a Tcl list of globs for ., and allows for
simulating particular test failures.
Signed-off-by: Ian Jackson
---
sg-run-job | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/sg-run-job b/sg-run-job
index dd76d4f2..c64ae026 100755
--- a/sg-run-job
+++ b/sg-run-job
@
$anypassq is used for the "never pass" check; the distinction between
this and simply "fail" is cosmetic (although it can be informative).
On non-"real" flights, it can easily happen that the flight never
passed *on this branch with this blessing* but has passed on real. So
the steps subquery doe
From: Ian Jackson
Put the call to this debugging/testing variable inside an eval. This
allows a wider variety of stunts. The one in-tree reference is
already compatible with this new semantics.
Signed-off-by: Ian Jackson
---
cr-daily-branch | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
From: Ian Jackson
No functional change.
Signed-off-by: Ian Jackson
---
sg-report-flight | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/sg-report-flight b/sg-report-flight
index 15631001..2ab1637f 100755
--- a/sg-report-flight
+++ b/sg-report-flight
@@ -783
Signed-off-by: Ian Jackson
---
cri-args-hostlists | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cri-args-hostlists b/cri-args-hostlists
index 994e00c0..6cdff53f 100644
--- a/cri-args-hostlists
+++ b/cri-args-hostlists
@@ -68,8 +68,8 @@ fi
execute_flight () {
From: Ian Jackson
This just generates an extra heading and URL at the top of the output.
In particular, it doesn't affect the algorithms which calculate
regressions.
Signed-off-by: Ian Jackson
---
sg-report-flight | 18 ++
1 file changed, 18 insertions(+)
diff --git a/sg-repor
From: Ian Jackson
Nothing produces this yet. (There's play-retry as well of course but
we don't need to document that really.)
Signed-off-by: Ian Jackson
---
README.dev | 9 +
cr-daily-branch | 3 ++-
cr-disk-report | 2 +-
cr-try-bisect | 4 ++--
cr-try-bisect
Sort the flight summary lines together, before the URLs. This makes
it considerably easier to read.
Signed-off-by: Ian Jackson
---
sg-report-flight | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/sg-report-flight b/sg-report-flight
index bcd896a8..cbd39599
This is only used in report_flight. We are going to want to call
report_flight from outside start_email, without having to set that
variable ourselves.
The variable isn't actually used in start_email.
Signed-off-by: Ian Jackson
---
cri-args-hostlists | 2 +-
1 file changed, 1 insertion(+), 1 d
This is primarily useful for debugging the immediate-retry logic, but
it seems churlish to delete it again.
Signed-off-by: Ian Jackson
---
cr-daily-branch | 4
1 file changed, 4 insertions(+)
diff --git a/cr-daily-branch b/cr-daily-branch
index bea8734e..3e58d465 100755
--- a/cr-daily-bran
Do not do a retest if it would involve retesting more than 10% of the
original flight, or if it wouldn't get a push even if the retests
pass.
Signed-off-by: Ian Jackson
---
cr-daily-branch | 15 +++
1 file changed, 15 insertions(+)
diff --git a/cr-daily-branch b/cr-daily-branch
inde
From: Ian Jackson
We exclude the self-tests because we don't want to miss breakage, and
the Xen smoke tests because they will be run again RSN anyway.
Signed-off-by: Ian Jackson
---
cr-daily-branch | 48 +++-
1 file changed, 47 insertions(+), 1 delet
The mro will now contain exactly one of "blockers" or "tolerable".
Nothing uses this yet.
Signed-off-by: Ian Jackson
---
sg-report-flight | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/sg-report-flight b/sg-report-flight
index 51a409ed..fd266586 100755
--- a/sg-report-f
CC: Andrew Cooper
Signed-off-by: Ian Jackson
---
cr-daily-branch | 1 +
1 file changed, 1 insertion(+)
diff --git a/cr-daily-branch b/cr-daily-branch
index 3e58d465..9b1961bd 100755
--- a/cr-daily-branch
+++ b/cr-daily-branch
@@ -484,6 +484,7 @@ default_immediate_retry=$wantpush
case "$branch"
On 15/10/2020 16:16, Jan Beulich wrote:
> On 15.10.2020 16:02, Andrew Cooper wrote:
>> On 15/10/2020 09:50, Jan Beulich wrote:
>>> On 14.10.2020 20:47, Andrew Cooper wrote:
cpu_smpboot_alloc() is designed to be idempotent with respect to partially
initialised state. This occurs for S3 an
> > Can you paste the memory map as printed by Xen when booting, and what
> > command line are you using to boot Xen.
>
> So this is OpenXT, and it's booting EFI -> xen -> tboot -> xen
Unrelated comment: since tboot now has a PE build
(http://hg.code.sf.net/p/tboot/code/rev/5c68f0963a78) I think i
From: Oleksandr Tyshchenko
As a lot of x86 code can be re-used on Arm later on, this
patch makes some preparation to x86/hvm/ioreq.c before moving
to the common code. This way we will get a verbatim copy for
a code movement in subsequent patch (arch/x86/hvm/ioreq.c
will be *just* renamed to commo
1 - 100 of 145 matches
Mail list logo
