flight 158989 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158989/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-seattle broken
test-arm64-arm64-xl-credit1 8 xen-boot
On Wed, Feb 03, 2021 at 03:37:05PM -0800, Dongli Zhang wrote:
> This patch converts several swiotlb related variables to arrays, in
> order to maintain stat/status for different swiotlb buffers. Here are
> variables involved:
>
> - io_tlb_start and io_tlb_end
> - io_tlb_nslabs and io_tlb_used
> -
On 1.2.2021 21.25, Stefano Stabellini wrote:
On Sat, 30 Jan 2021, Julien Grall wrote:
On 27/01/2021 11:47, Jukka Kaartinen wrote:
On Tue, Jan 26, 2021 at 10:22 PM Stefano Stabellini
mailto:sstabell...@kernel.org>> wrote:
On Tue, 26 Jan 2021, Jukka Kaartinen wrote:
> On Tue, Jan
On 4.2.2021 0.12, Elliott Mitchell wrote:
On Wed, Feb 03, 2021 at 12:55:40PM -0800, Stefano Stabellini wrote:
On Wed, 3 Feb 2021, Jukka Kaartinen wrote:
On 3.2.2021 2.18, Stefano Stabellini wrote:
How are you configuring and installing the kernel?
make bcm2711_defconfig
make Image.gz
make
On 3.2.2021 22.55, Stefano Stabellini wrote:
On Wed, 3 Feb 2021, Jukka Kaartinen wrote:
On 3.2.2021 2.18, Stefano Stabellini wrote:
On Tue, 2 Feb 2021, Jukka Kaartinen wrote:
Good catch.
GPU works now and I can start X! Thanks! I was also able to create
domU
that runs Raspian OS.
This is
On 04.02.21 00:48, Jakub Kicinski wrote:
On Tue, 2 Feb 2021 08:09:38 +0100 Juergen Gross wrote:
Since commit 23025393dbeb3b8b3 ("xen/netback: use lateeoi irq binding")
xenvif_rx_ring_slots_available() is no longer called only from the rx
queue kernel thread, so it needs to access the rx queue w
flight 158987 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158987/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xsm 4 host-insta
On Wed, 3 Feb 2021, Julien Grall wrote:
> On Wed, 3 Feb 2021 at 22:18, Stefano Stabellini
> wrote:
> > > > But aside from PCIe, let's say that we know of a few nodes for which
> > > > "reg" needs a special treatment. I am not sure it makes sense to proceed
> > > > with parsing those nodes without
flight 158981 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158981/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 broken
test-arm64-arm64-xl-seattle
flight 158985 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158985/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e806bb29cfde1b242bb37e72e77364dd812830e0
baseline version:
ovmf 618e6a1f21a11eaee0a92
On Tue, 2 Feb 2021 08:09:38 +0100 Juergen Gross wrote:
> Since commit 23025393dbeb3b8b3 ("xen/netback: use lateeoi irq binding")
> xenvif_rx_ring_slots_available() is no longer called only from the rx
> queue kernel thread, so it needs to access the rx queue with the
> associated queue held.
>
>
This patch is to enable the 64-bit xen-swiotlb buffer.
For Xen PVM DMA address, the 64-bit device will be able to allocate from
64-bit swiotlb buffer.
Cc: Joe Jin
Signed-off-by: Dongli Zhang
---
drivers/xen/swiotlb-xen.c | 117 --
1 file changed, 74 insertio
This patch converts several xen-swiotlb related variables to arrays, in
order to maintain stat/status for different swiotlb buffers. Here are
variables involved:
- xen_io_tlb_start and xen_io_tlb_end
- xen_io_tlb_nslabs
- MAX_DMA_BITS
There is no functional change and this is to prepare to enable
This patch is to enable the 64-bit swiotlb buffer.
The state of the art swiotlb pre-allocates <=32-bit memory in order to meet
the DMA mask requirement for some 32-bit legacy device. Considering most
devices nowadays support 64-bit DMA and IOMMU is available, the swiotlb is
not used for most of th
This patch converts several swiotlb related variables to arrays, in
order to maintain stat/status for different swiotlb buffers. Here are
variables involved:
- io_tlb_start and io_tlb_end
- io_tlb_nslabs and io_tlb_used
- io_tlb_list
- io_tlb_index
- max_segment
- io_tlb_orig_addr
- no_iotlb_memor
This patch introduces swiotlb_get_type() in order to calculate which
swiotlb buffer the given DMA address is belong to.
This is to prepare to enable 64-bit swiotlb.
Cc: Joe Jin
Signed-off-by: Dongli Zhang
---
include/linux/swiotlb.h | 14 ++
kernel/dma/swiotlb.c| 2 ++
2 files
This RFC is to introduce the 2nd swiotlb buffer for 64-bit DMA access. The
prototype is based on v5.11-rc6.
The state of the art swiotlb pre-allocates <=32-bit memory in order to meet
the DMA mask requirement for some 32-bit legacy device. Considering most
devices nowadays support 64-bit DMA and
This is just to define new enumerated type without functional change.
The 'SWIOTLB_LO' is to index legacy 32-bit swiotlb buffer, while the
'SWIOTLB_HI' is to index the 64-bit buffer.
This is to prepare to enable 64-bit swiotlb.
Cc: Joe Jin
Signed-off-by: Dongli Zhang
---
include/linux/swiotlb
flight 158993 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158993/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Wed, 3 Feb 2021 at 22:18, Stefano Stabellini wrote:
> > > But aside from PCIe, let's say that we know of a few nodes for which
> > > "reg" needs a special treatment. I am not sure it makes sense to proceed
> > > with parsing those nodes without knowing how to deal with that.
> >
> > I believe t
On Wed, 3 Feb 2021, Julien Grall wrote:
> On 03/02/2021 00:18, Stefano Stabellini wrote:
> > On Tue, 2 Feb 2021, Julien Grall wrote:
> > > On 02/02/2021 18:12, Julien Grall wrote:
> > > > On 02/02/2021 17:47, Elliott Mitchell wrote:
> > > > > The handle_device() function has been returning failure
On Wed, Feb 03, 2021 at 12:55:40PM -0800, Stefano Stabellini wrote:
> On Wed, 3 Feb 2021, Jukka Kaartinen wrote:
> > On 3.2.2021 2.18, Stefano Stabellini wrote:
> > > How are you configuring and installing the kernel?
> > >
> > > make bcm2711_defconfig
> > > make Image.gz
> > > make modules_instal
On 2/3/21 1:06 PM, Linus Torvalds wrote:
On Wed, Feb 3, 2021 at 11:58 AM Shuah Khan wrote:
ld: arch/x86/built-in.a: member arch/x86/kernel/pci-swiotlb.o in archive
is not an object
make: *** [Makefile:1170: vmlinux] Error 1
That honestly sounds like something went wrong earlier - things like
flight 158977 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158977/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 broken
test-arm64-arm64-xl-
On 2/3/21 11:58 AM, Shuah Khan wrote:
> I am seeing the following compile error on Linux 5.11-rc6.
> No issues on 5.11.0-rc5 with the same config.
>
> ld: arch/x86/built-in.a: member arch/x86/kernel/pci-swiotlb.o in archive is
> not an object
> make: *** [Makefile:1170: vmlinux] Error 1
>
> CONF
On Wed, 3 Feb 2021, Jukka Kaartinen wrote:
> On 3.2.2021 2.18, Stefano Stabellini wrote:
> > On Tue, 2 Feb 2021, Jukka Kaartinen wrote:
> > > > > Good catch.
> > > > > GPU works now and I can start X! Thanks! I was also able to create
> > > > > domU
> > > > > that runs Raspian OS.
> > > >
> > > >
On 26/01/2021 15:04, Samuel Verschelde wrote:
> Le 18/01/2021 à 11:03, Roger Pau Monné a écrit :
>> On Fri, Jan 15, 2021 at 03:03:26PM +, Samuel Verschelde wrote:
>>> Hi list,
>>>
>>> Another "popular" thread on XCP-ng forum [1], started in october 2020,
>>> allowed us to detect that patch 12 f
I am seeing the following compile error on Linux 5.11-rc6.
No issues on 5.11.0-rc5 with the same config.
ld: arch/x86/built-in.a: member arch/x86/kernel/pci-swiotlb.o in archive
is not an object
make: *** [Makefile:1170: vmlinux] Error 1
CONFIG_SWIOTLB_XEN=y
CONFIG_SWIOTLB=y
I can debug furth
Domains migrating or restoring should have viridian HVM param key in
the migration stream already and setting that twice results in Xen
returing -EEXIST on the second attempt later (during migration stream parsing)
in case the values don't match. That causes migration/restore operation
to fail at d
No functional change.
Signed-off-by: Igor Druzhinin
---
New patch in v2 as requested.
---
tools/libs/light/libxl_arch.h | 6 --
tools/libs/light/libxl_arm.c | 4 +++-
tools/libs/light/libxl_dom.c | 2 +-
tools/libs/light/libxl_x86.c | 6 --
4 files changed, 12 insertions(+), 6 deletio
On Wed, Feb 3, 2021 at 11:58 AM Shuah Khan wrote:
>
> ld: arch/x86/built-in.a: member arch/x86/kernel/pci-swiotlb.o in archive
> is not an object
> make: *** [Makefile:1170: vmlinux] Error 1
That honestly sounds like something went wrong earlier - things like
doing a system upgrade in the middle
On 03/02/2021 17:58, Roger Pau Monne wrote:
> Or else the EFI service calls will use the wrong calling convention.
>
> The __ms_abi__ attribute is available on all supported versions of
> clang.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
> ---
> Cc: Ian Jackson
>
> Without this
flight 158969 qemu-mainline real [real]
flight 158986 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158969/
http://logs.test-lab.xenproject.org/osstest/logs/158986/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Wed, Feb 03, 2021 at 05:26:44PM +, Ian Jackson wrote:
> Manuel Bouyer writes ("[PATCH v3] NetBSD: use system-provided headers"):
> > +#ifdef __NetBSD__
> > +#include
> > +#else
> > #include
> > +#endif
> > #include
> > #include
> Maneul, thanks. I think this is a bugfix and ought in
flight 158971 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158971/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
Or else the EFI service calls will use the wrong calling convention.
The __ms_abi__ attribute is available on all supported versions of
clang.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Without this a Xen built with clang won't be able to correctly use the
EFI services, leading to weir
On 03/02/2021 17:51, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH for-4.15 2/2] libs/foreignmem: Fix/simplify
> errno handling for map_resource"):
>> Simplify the FreeBSD logic, and duplicate it for NetBSD as the userpace ABI
>> appears to be to consistently provide EOPNOTSUPP for missing Xe
Andrew Cooper writes ("[PATCH for-4.15 2/2] libs/foreignmem: Fix/simplify errno
handling for map_resource"):
> Simplify the FreeBSD logic, and duplicate it for NetBSD as the userpace ABI
> appears to be to consistently provide EOPNOTSUPP for missing Xen/Kernel
> support.
>
> The Linux logic was c
On Wed, Feb 03, 2021 at 05:38:59PM +, Ian Jackson wrote:
> > [...]
> > broken on Linux too ?
>
> Andy pointed me to the recent thread "xenstored file descriptor leak"
> which answers all these questions. I think it would have been nice if
> some tools maintainer(s) had been CC'd on that :-).
On 03/02/2021 00:18, Stefano Stabellini wrote:
On Tue, 2 Feb 2021, Julien Grall wrote:
On 02/02/2021 18:12, Julien Grall wrote:
On 02/02/2021 17:47, Elliott Mitchell wrote:
The handle_device() function has been returning failure upon
encountering a device address which was invalid. A devic
Andrew Cooper writes ("[PATCH for-4.15 0/3] tools/oxenstored bugfixes"):
> All of these been posted before, but were tangled in other content which is
> not appropriate for 4.15 any more. As a consequence, I didn't get around to
> committing them before the code freeze.
>
> They were all found wi
Andrew Cooper writes ("[PATCH 1/3] tools/oxenstored: Fix quota calculation for
mkdir EEXIST"):
> From: Edwin Török
>
> We increment the domain's quota on mkdir even when the node already exists.
> This results in a quota inconsistency after live update, where reconstructing
> the tree from scrat
Ian Jackson writes ("Re: [PATCH] xenstored: close socket connections on error"):
> Manuel Bouyer writes ("[PATCH] xenstored: close socket connections on error"):
> > On error, don't keep socket connection in ignored state but close them.
> > When the remote end of a socket is closed, xenstored will
All of these been posted before, but were tangled in other content which is
not appropriate for 4.15 any more. As a consequence, I didn't get around to
committing them before the code freeze.
They were all found with unit testing, specifically fuzzing the
serialising/deserialising logic introduce
From: Edwin Török
Watches on invalid paths were accepted, but they would never trigger. The
client also got no notification that its watch is bad and would never trigger.
Found again by the structured fuzzer, due to an error on live update reload:
the invalid watch paths would get rejected duri
From: Edwin Török
We increment the domain's quota on mkdir even when the node already exists.
This results in a quota inconsistency after live update, where reconstructing
the tree from scratch results in a different quota.
Not a security issue because the domain uses up quota faster, so it will
From: Edwin Török
Due to how set_write_lowpath was used here it didn't detect create/delete
conflicts. When we create an entry we must mark our parent as modified
(this is what creating a new node via write does).
Otherwise we can have 2 transactions one creating, and another deleting a node
bo
On 03/02/2021 17:18, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH for-4.15 2/2] libs/foreignmem: Fix/simplify
> errno handling for map_resource"):
>> Simplify the FreeBSD logic, and duplicate it for NetBSD as the userpace ABI
>> appears to be to consistently provide EOPNOTSUPP for missing Xe
Manuel Bouyer writes ("[PATCH v3] NetBSD: use system-provided headers"):
> +#ifdef __NetBSD__
> +#include
> +#else
> #include
> +#endif
> #include
> #include
Maneul, thanks. I think this is a bugfix and ought in principle to go
in but I think we probably want to do this with configure rathe
On 03/02/2021 17:16, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH for-4.15 1/2] libs/foreignmem: Drop useless
> and/or misleading logging"):
>> These log lines are all in response to single system calls, and do not
>> provide
>> any information which the immediate caller can't determine the
Manuel Bouyer writes ("[PATCH] xenstored: close socket connections on error"):
> On error, don't keep socket connection in ignored state but close them.
> When the remote end of a socket is closed, xenstored will flag it as an
> error and switch the connection to ignored. But on some OSes (e.g.
> N
Manuel Bouyer writes ("[PATCH] add a qemu-ifup script on NetBSD"):
> On NetBSD, qemu-xen will use a qemu-ifup script to setup the tap interfaces
> (as qemu-xen-traditional used to). Copy the script from qemu-xen-traditional,
> and install it on NetBSD. While there document parameters and environnem
Andrew Cooper writes ("[PATCH for-4.15 2/2] libs/foreignmem: Fix/simplify errno
handling for map_resource"):
> Simplify the FreeBSD logic, and duplicate it for NetBSD as the userpace ABI
> appears to be to consistently provide EOPNOTSUPP for missing Xen/Kernel
> support.
>
> The Linux logic was c
Andrew Cooper writes ("[PATCH for-4.15 1/2] libs/foreignmem: Drop useless
and/or misleading logging"):
> These log lines are all in response to single system calls, and do not provide
> any information which the immediate caller can't determine themselves. It is
> however exceedinly rude to put j
Hello Stefano,
> On 2 Feb 2021, at 5:44 pm, Stefano Stabellini wrote:
>
> On Tue, 2 Feb 2021, Rahul Singh wrote:
>> Hello Stefano,
>>
>>> On 26 Jan 2021, at 10:58 pm, Stefano Stabellini
>>> wrote:
>>>
>>> Hi all,
>>>
>>> This series introduces support for the generic SMMU bindings to
>>> xe
On NetBSD use the system-provided headers for ioctl and related definitions,
they are up to date and have more chances to match the kernel's idea of
the ioctls and structures.
Remove now-unused NetBSD/evtchn.h and NetBSD/privcmd.h.
Don't fail install if xen/sys/*.h are not present.
Signed-off-by:
Document that on NetBSD, the tap interface will be configured by the
qemu-ifup script.
Signed-off-by: Manuel Bouyer
Release-Acked-by: Ian Jackson
---
docs/man/xl-network-configuration.5.pod | 3 +++
1 file changed, 3 insertions(+)
diff --git a/docs/man/xl-network-configuration.5.pod
b/docs/ma
On NetBSD, qemu-xen will use a qemu-ifup script to setup the tap interfaces
(as qemu-xen-traditional used to). Copy the script from qemu-xen-traditional,
and install it on NetBSD. While there document parameters and environnement
variables.
Signed-off-by: Manuel Bouyer
---
tools/hotplug/NetBSD/M
On error, don't keep socket connection in ignored state but close them.
When the remote end of a socket is closed, xenstored will flag it as an
error and switch the connection to ignored. But on some OSes (e.g.
NetBSD), poll(2) will return only POLLIN in this case, so sockets in ignored
state will
These log lines are all in response to single system calls, and do not provide
any information which the immediate caller can't determine themselves. It is
however exceedinly rude to put junk like this onto stderr, especially as
system call failures are not even error conditions in certain circums
Simplify the FreeBSD logic, and duplicate it for NetBSD as the userpace ABI
appears to be to consistently provide EOPNOTSUPP for missing Xen/Kernel
support.
The Linux logic was contorted in what appears to be a deliberate attempt to
skip the now-deleted logic for the EOPNOTSUPP case. Simplify it.
On 02/02/2021 09:04, Jan Beulich wrote:
> On 02.02.2021 00:26, Andrew Cooper wrote:
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -132,6 +132,56 @@ static void vcpu_info_reset(struct vcpu *v)
>> v->vcpu_info_mfn = INVALID_MFN;
>> }
>>
>> +static void vmtrace_free_buffer(st
> -Original Message-
> From: Jan Beulich
> Sent: 03 February 2021 15:43
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; 'James Dingwall'
>
> Subject: Re: VIRIDIAN CRASH: 3b c096 75b12c5 9e7f1580 0
>
> On 03.02.2021 16:04, Paul Durrant wrote:
> >> From: Xen-devel On Behalf
On 03.02.2021 16:04, Paul Durrant wrote:
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 03 February 2021 14:55
>>
>> On 01.02.2021 16:26, James Dingwall wrote:
>>> 21244@1612191983.282480:xen_platform_log xen platform: XEN|BUGCHECK:
>>> EXCEPTION (A824848948C2):
>>> 21244@1612191983
On 03/02/2021 15:31, Jan Beulich wrote:
> On 03.02.2021 16:01, Andrew Cooper wrote:
>> On 03/02/2021 14:22, Jan Beulich wrote:
>>> With memcpy() expanding to the compiler builtin, we may not hand it
>>> overlapping source and destination. We strictly mean to forward to our
>>> own implementation (a
On 03.02.2021 16:01, Andrew Cooper wrote:
> On 03/02/2021 14:22, Jan Beulich wrote:
>> With memcpy() expanding to the compiler builtin, we may not hand it
>> overlapping source and destination. We strictly mean to forward to our
>> own implementation (a few lines up in the same source file).
>>
>>
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 03 February 2021 14:55
> To: James Dingwall
> Cc: xen-devel@lists.xenproject.org
> Subject: Re: VIRIDIAN CRASH: 3b c096 75b12c5 9e7f1580 0
>
> On 01.02.2021 16:26, James Dingwall wrote:
> > I am building the x
On 03/02/2021 14:22, Jan Beulich wrote:
> With memcpy() expanding to the compiler builtin, we may not hand it
> overlapping source and destination. We strictly mean to forward to our
> own implementation (a few lines up in the same source file).
>
> Fixes: 78825e1c60fa ("x86/string: Clean up x86/st
On 01.02.2021 16:26, James Dingwall wrote:
> I am building the xen 4.11 branch at
> 310ab79875cb705cc2c7daddff412b5a4899f8c9 which includes commit
> 3b5de119f0399cbe745502cb6ebd5e6633cc139c "86/msr: fix handling of
> MSR_IA32_PERF_{STATUS/CTL}". I think this should address this error
> recorde
Igor Druzhinin writes ("[PATCH] tools/libxl: only set viridian flags on new
domains"):
> Domains migrating or restoring should have viridian HVM param key in
> the migration stream already and setting that twice results in Xen
> returing -EEXIST on the second attempt later (during migration stream
With memcpy() expanding to the compiler builtin, we may not hand it
overlapping source and destination. We strictly mean to forward to our
own implementation (a few lines up in the same source file).
Fixes: 78825e1c60fa ("x86/string: Clean up x86/string.h")
Signed-off-by: Jan Beulich
---
An alter
On 03/02/2021 04:01, Igor Druzhinin wrote:
> Domains migrating or restoring should have viridian HVM param key in
> the migration stream already and setting that twice results in Xen
> returing -EEXIST on the second attempt later (during migration stream parsing)
> in case the values don't match. T
On Wed, Feb 03, 2021 at 02:11:43PM +0100, Jürgen Groß wrote:
> Not using git on a daily basis I really suggest to use stgit as an
> add.on:
>
> https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_StGit
>
> It makes handling multiple iterations of a patch rather easy.
thanks. When I starte
On 03.02.21 14:03, Manuel Bouyer wrote:
On Wed, Feb 03, 2021 at 01:58:19PM +0100, Jürgen Groß wrote:
On 03.02.21 13:47, Manuel Bouyer wrote:
On Wed, Feb 03, 2021 at 01:42:12PM +0100, Jürgen Groß wrote:
Uh, this is no regular patch.
I though by regular patch, you meants a plain diff -u
You'
On Wed, Feb 03, 2021 at 01:58:19PM +0100, Jürgen Groß wrote:
> On 03.02.21 13:47, Manuel Bouyer wrote:
> > On Wed, Feb 03, 2021 at 01:42:12PM +0100, Jürgen Groß wrote:
> > > Uh, this is no regular patch.
> >
> > I though by regular patch, you meants a plain diff -u
> >
> > > You've sent correct p
On 03.02.21 13:47, Manuel Bouyer wrote:
On Wed, Feb 03, 2021 at 01:42:12PM +0100, Jürgen Groß wrote:
Uh, this is no regular patch.
I though by regular patch, you meants a plain diff -u
You've sent correct patches before,
Yes, and it's very time-consuming. This is why I want to have it righ
flight 158975 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158975/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 618e6a1f21a11eaee0a92e19c753969eb4a1b198
baseline version:
ovmf 3f90ac3ec03512e2374cd
On Wed, Feb 03, 2021 at 01:42:12PM +0100, Jürgen Groß wrote:
> Uh, this is no regular patch.
I though by regular patch, you meants a plain diff -u
> You've sent correct patches before,
Yes, and it's very time-consuming. This is why I want to have it right the
first time and not go through sevrer
On 03.02.21 13:33, Manuel Bouyer wrote:
On Wed, Feb 03, 2021 at 01:21:59PM +0100, Jürgen Groß wrote:
Will do
In the patch I'm going to submit, may I add
Reviewed-by: Jürgen Groß
?
Let me see the patch (including commit message) first, please.
So just send out as a regular patch, and I'll
On Wed, Feb 03, 2021 at 01:21:59PM +0100, Jürgen Groß wrote:
> > Will do
> >
> > In the patch I'm going to submit, may I add
> >
> > Reviewed-by: Jürgen Groß
> > ?
> >
>
> Let me see the patch (including commit message) first, please.
>
> So just send out as a regular patch, and I'll respond
On 03.02.21 13:17, Manuel Bouyer wrote:
On Wed, Feb 03, 2021 at 01:13:53PM +0100, Jürgen Groß wrote:
On 03.02.21 13:03, Manuel Bouyer wrote:
On Wed, Feb 03, 2021 at 12:54:23PM +0100, Jürgen Groß wrote:
On 03.02.21 12:48, Manuel Bouyer wrote:
On Wed, Feb 03, 2021 at 09:21:32AM +0100, Jürgen Gr
On Wed, Feb 03, 2021 at 01:13:53PM +0100, Jürgen Groß wrote:
> On 03.02.21 13:03, Manuel Bouyer wrote:
> > On Wed, Feb 03, 2021 at 12:54:23PM +0100, Jürgen Groß wrote:
> > > On 03.02.21 12:48, Manuel Bouyer wrote:
> > > > On Wed, Feb 03, 2021 at 09:21:32AM +0100, Jürgen Groß wrote:
> > > > > [...]
On 03.02.21 13:03, Manuel Bouyer wrote:
On Wed, Feb 03, 2021 at 12:54:23PM +0100, Jürgen Groß wrote:
On 03.02.21 12:48, Manuel Bouyer wrote:
On Wed, Feb 03, 2021 at 09:21:32AM +0100, Jürgen Groß wrote:
[...]
This shouldn't happen in case we are closing the socket actively.
In the end we shoul
On Wed, Feb 03, 2021 at 12:54:23PM +0100, Jürgen Groß wrote:
> On 03.02.21 12:48, Manuel Bouyer wrote:
> > On Wed, Feb 03, 2021 at 09:21:32AM +0100, Jürgen Groß wrote:
> > > [...]
> > > This shouldn't happen in case we are closing the socket actively.
> > >
> > > In the end we should just do a tal
On 03.02.21 12:20, Julien Grall wrote:
Hi Juergen,
On 03/02/2021 11:00, Jürgen Groß wrote:
On 03.02.21 10:19, Julien Grall wrote:
Hi,
On 03/02/2021 07:31, Dario Faggioli wrote:
On Tue, 2021-02-02 at 15:23 +, Julien Grall wrote:
In reality, it is probably still too early as a pCPU can be
On 03.02.21 12:48, Manuel Bouyer wrote:
On Wed, Feb 03, 2021 at 09:21:32AM +0100, Jürgen Groß wrote:
[...]
This shouldn't happen in case we are closing the socket actively.
In the end we should just do a talloc_free(conn) in
ignore_connection() if it is a socket based one. This should revert
th
branch xen-unstable
xenbranch xen-unstable
job test-arm64-arm64-xl
testid guest-start
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu
On Wed, Feb 03, 2021 at 09:21:32AM +0100, Jürgen Groß wrote:
> [...]
> This shouldn't happen in case we are closing the socket actively.
>
> In the end we should just do a talloc_free(conn) in
> ignore_connection() if it is a socket based one. This should revert
> the critical modification of the
Hi Juergen,
On 03/02/2021 11:00, Jürgen Groß wrote:
On 03.02.21 10:19, Julien Grall wrote:
Hi,
On 03/02/2021 07:31, Dario Faggioli wrote:
On Tue, 2021-02-02 at 15:23 +, Julien Grall wrote:
In reality, it is probably still too early as a pCPU can be
considered
quiesced until a call to rcu
On 03.02.21 10:19, Julien Grall wrote:
Hi,
On 03/02/2021 07:31, Dario Faggioli wrote:
On Tue, 2021-02-02 at 15:23 +, Julien Grall wrote:
In reality, it is probably still too early as a pCPU can be
considered
quiesced until a call to rcu_lock*() (such rcu_lock_domain()).
Well, yes, in the
flight 158962 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158962/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel 14 guest-start fail REGR. vs. 158387
test-amd64-amd64-dom0
flight 158979 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158979/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 5e7aa904405fa2f268c3af213516bae271de3265
baseline version:
xen 9dc6
Hi,
On 03/02/2021 07:31, Dario Faggioli wrote:
On Tue, 2021-02-02 at 15:23 +, Julien Grall wrote:
In reality, it is probably still too early as a pCPU can be
considered
quiesced until a call to rcu_lock*() (such rcu_lock_domain()).
Well, yes, in theory, we could track down which is the fi
On 03.02.21 09:16, Manuel Bouyer wrote:
On Wed, Feb 03, 2021 at 09:05:27AM +0100, Jürgen Groß wrote:
[...]
Yes, I think this is a good idea.
Well, after some sleep I don't think it is. We should always keep at last
POLLIN or we will never notice a socket close otherwise.
Adding the fd of an
On Wed, Feb 03, 2021 at 09:05:27AM +0100, Jürgen Groß wrote:
> > > [...]
> > > Yes, I think this is a good idea.
> >
> > Well, after some sleep I don't think it is. We should always keep at last
> > POLLIN or we will never notice a socket close otherwise.
>
> Adding the fd of an ignored socket co
flight 158957 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158957/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 158922
Tests which did not succeed
On 03.02.21 08:57, Manuel Bouyer wrote:
On Wed, Feb 03, 2021 at 07:18:51AM +0100, Jürgen Groß wrote:
On 02.02.21 19:37, Manuel Bouyer wrote:
Hello,
on NetBSD I'm tracking down an issue where xenstored never closes its
file descriptor to /var/run/xenstored/socket and instead loops at 100%
CPU on
97 matches
Mail list logo
