On 27.01.2021 22:23, Andrew Cooper wrote:
> On 27/01/2021 21:16, Stefano Stabellini wrote:
>> Hi all,
>>
>> These are two recent randconfig build failures reported by gitlab (the
>> two patches that triggered the CI-loop are two patches to the
>> MAINTAINERS file -- certainly not the cause of the b
flight 158717 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158717/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 27.01.2021 21:14, Oleksandr wrote:
> On 27.01.21 18:58, Jan Beulich wrote:
>> On 25.01.2021 20:08, Oleksandr Tyshchenko wrote:
>>> --- a/xen/arch/x86/Kconfig
>>> +++ b/xen/arch/x86/Kconfig
>>> @@ -92,6 +92,7 @@ config PV_LINEAR_PT
>>>
>>> config HVM
>>> def_bool !PV_SHIM_EXCLUSIVE
>>> +
> -Original Message-
> From: Xen-devel On Behalf Of Dongli
> Zhang
> Sent: 27 January 2021 19:57
> To: Paul Durrant ; xen-devel@lists.xenproject.org;
> linux-bl...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: Paul Durrant ; Konrad Rzeszutek Wilk
> ; Roger Pau
> Monné ; Jens Ax
On 1/27/21 11:21 PM, Damien Le Moal wrote:
On 2021/01/28 16:12, Chaitanya Kulkarni wrote:
Introduce bio_new() helper and use it in blk-lib.c to allocate and
initialize various non-optional or semi-optional members of the bio
along with bio allocation done with bio_alloc(). Here we also calmp the
On 1/27/21 11:27 PM, Damien Le Moal wrote:
+
+ bio_set_dev(bio, bdev);
+ bio->bi_iter.bi_sector = sector;
+ bio_set_op_attrs(bio, op, op_flags);
This function is obsolete. Open code this.
And that also mean that you could remove one argument to bio_new(): combine op
and op_fl
flight 158711 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158711/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 158699
test-amd64-amd64-xl-qemuu-win7-amd64
Hi Oleksandr,
On 27/01/2021 19:20, Oleksandr wrote:
> >>> So I think we may be able to drop the include from
asm/hvm/domain.h
(this would avoid to include it everywhere...).
I have tried that, but other CUs use definitions from
public/hvm/dm_op.h, for example:
p2m-pt.c: In function 'p2m_t
On 26.01.2021 14:03, Claudemir Todo Bom wrote:
> If this information is good for more tests, please send the patch and
> I will test it!
Here you go. For simplifying analysis it may be helpful if you
could limit the number of CPUs in use, e.g. by "maxcpus=4" or
at least "smt=0". Provided the probl
On 28.01.2021 10:47, Jan Beulich wrote:
> On 26.01.2021 14:03, Claudemir Todo Bom wrote:
>> If this information is good for more tests, please send the patch and
>> I will test it!
>
> Here you go. For simplifying analysis it may be helpful if you
> could limit the number of CPUs in use, e.g. by "
Hi Oleksandr,
On 25/01/2021 19:08, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
We need to send mapcache invalidation request to qemu/demu everytime
the page gets removed from a guest.
At the moment, the Arm code doesn't explicitely remove the existing
mapping before inserting the n
On 28.01.2021 06:38, Jürgen Groß wrote:
> On 28.01.21 04:16, Marek Marczykowski-Górecki wrote:
>> Using RING_GET_RESPONSE() on a shared ring is easy to use incorrectly
>> (i.e., by not considering that the other end may alter the data in the
>> shared ring while it is being inspected). Safe usage o
On 27.01.2021 20:49, Andrew Cooper wrote:
> In practice, there is no such thing as a real 64bit system without
> APICs. (PVH style virtual environments, sure, but they don't end up here).
>
> The suggestion to try and use noapic only makes a bad situation worse.
>
> Signed-off-by: Andrew Cooper
On 27.01.2021 23:28, Elliott Mitchell wrote:
> On Wed, Jan 27, 2021 at 09:03:32PM +, Andrew Cooper wrote:
>> So.?? What *should* happen is that if QEMU/OVMF dirties more memory than
>> exists in the PoD cache, the domain gets terminated.
>>
>> Irrespective, Xen/dom0 dying isn't an expected cons
Hi all,
PLEASE NOTE NEW CALLIN DETAILS BELOW.
The proposed agenda is in
https://cryptpad.fr/pad/#/2/pad/edit/e2cGWQMdvrXt86dvezuzJ9S2/ and you can edit
to add items. Alternatively, you can reply to this mail directly.
Agenda items appreciated a few days before the call: please put your name
On Thu, Jan 28, 2021 at 8:21 AM Chaitanya Kulkarni
wrote:
>
Please explain in the changelog why making this change is a good idea.
> Signed-off-by: Chaitanya Kulkarni
> ---
> kernel/power/swap.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/power/swap.c
flight 158712 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158712/
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-xl-
On Tue, Jan 26, 2021 at 11:48:00PM +0100, Manuel Bouyer wrote:
> On NetBSD, d_name is larger than 256, so file_name[284] may not be large
> enough (and gcc emits a format-truncation error).
> Use asprintf() instead of snprintf() on a static on-stack buffer.
>
> Signed-off-by: Manuel Bouyer
Revie
Scrubbing can significantly delay the offlining (parking) of a CPU (e.g.
because of booting into in smt=0 mode), to a degree that the "CPU
still not dead..." messages logged on x86 in 1s intervals can be seen
multiple times. There are no softirqs involved in this process, so
extend the existing pr
On 28/01/2021 10:35, Jan Beulich wrote:
> Scrubbing can significantly delay the offlining (parking) of a CPU (e.g.
> because of booting into in smt=0 mode), to a degree that the "CPU
> still not dead..." messages logged on x86 in 1s intervals can be seen
> multiple times. There are no softirqs inv
On Tue, Jan 26, 2021 at 11:47:52PM +0100, Manuel Bouyer wrote:
> Implement foreignmemory interface on NetBSD. The compat interface is now used
> only on __sun__
>
> Signed-off-by: Manuel Bouyer
> ---
> tools/libs/foreignmemory/Makefile | 2 +-
> tools/libs/foreignmemory/netbsd.c | 66
On 25.01.2021 20:08, Oleksandr Tyshchenko wrote:
> --- /dev/null
> +++ b/xen/include/xen/dm.h
> @@ -0,0 +1,41 @@
> +/*
> + * Copyright (c) 2016 Citrix Systems Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU Gen
On 26/01/2021 22:47, Manuel Bouyer wrote:
> diff --git a/tools/libs/foreignmemory/netbsd.c
> b/tools/libs/foreignmemory/netbsd.c
> index 54a418ebd6..a7e1d72ffc 100644
> --- a/tools/libs/foreignmemory/netbsd.c
> +++ b/tools/libs/foreignmemory/netbsd.c
> @@ -97,7 +102,48 @@ void *osdep_map_foreign_b
On Tue, Jan 26, 2021 at 11:47:59PM +0100, Manuel Bouyer wrote:
> On NetBSD, PTHREAD_STACK_MIN is not available.
> If PTHREAD_STACK_MIN is not defined, define it to 0 so that we fallback to
> DEFAULT_THREAD_STACKSIZE
>
I would add:
Suggested-by: Andrew Cooper
> Signed-off-by: Manuel Bouyer
Re
On 27.01.21 22:46, Stefano Stabellini wrote:
Hi Stefano, all
On Wed, 27 Jan 2021, Oleksandr wrote:
On Mon, 25 Jan 2021 at 19:09, Oleksandr Tyshchenko
wrote:
***
Please note, this patch depends on the following which is
on review:
https://patchwork.kernel.org/patch/11816689/
The effort (to
Manuel Bouyer writes ("[PATCH v2] libs/light: make it build without
setresuid()"):
> NetBSD doesn't have setresuid(). introcuce libxl__setresuid(),
> which on NetBSD assert() that it's never called (it should not be called when
> dm restriction is off, and NetBSD doesn't support dm restriction at
On Tue, Jan 26, 2021 at 11:47:58PM +0100, Manuel Bouyer wrote:
> Pass bridge name to qemu as command line option
> When starting qemu, set an environnement variable XEN_DOMAIN_ID,
> to be used by qemu helper scripts
> The only functional difference of using the br parameter is that the
> bridge nam
On 28/01/2021 10:57, Roger Pau Monné wrote:
> On Tue, Jan 26, 2021 at 11:47:59PM +0100, Manuel Bouyer wrote:
>> On NetBSD, PTHREAD_STACK_MIN is not available.
>> If PTHREAD_STACK_MIN is not defined, define it to 0 so that we fallback to
>> DEFAULT_THREAD_STACKSIZE
>>
> I would add:
>
> Suggested-by
On Tue, Jan 26, 2021 at 11:47:53PM +0100, Manuel Bouyer wrote:
> +int osdep_gntshr_unshare(xengntshr_handle *xgs,
> + void *start_address, uint32_t count)
> +{
> +return munmap(start_address, count * PAGE_SIZE);
> +}
> +
> +/*
> + * The functions below are Linux-isms tha
On 28.01.21 10:06, Jan Beulich wrote:
Hi Jan
On 27.01.2021 21:14, Oleksandr wrote:
On 27.01.21 18:58, Jan Beulich wrote:
On 25.01.2021 20:08, Oleksandr Tyshchenko wrote:
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -92,6 +92,7 @@ config PV_LINEAR_PT
config HVM
d
On Tue, Jan 26, 2021 at 11:47:50PM +0100, Manuel Bouyer wrote:
> 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
On 28.01.2021 12:01, Oleksandr wrote:
> On 27.01.21 22:46, Stefano Stabellini wrote:
>> On Wed, 27 Jan 2021, Oleksandr wrote:
>>> Thank you. I got a request to make a possibility for user to select IOREQ
>>> via
>>> the menuconfig on Arm. Saying tech preview do you mean that I also need to
>>> pu
On 28.01.2021 12:16, Oleksandr wrote:
> On 28.01.21 10:06, Jan Beulich wrote:
>> On 27.01.2021 21:14, Oleksandr wrote:
>>> On 27.01.21 18:58, Jan Beulich wrote:
On 25.01.2021 20:08, Oleksandr Tyshchenko wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -92,6 +92
On 28.01.21 11:40, Julien Grall wrote:
Hi Julien
Hi Oleksandr,
On 27/01/2021 19:20, Oleksandr wrote:
> >>> So I think we may be able to drop the include from
asm/hvm/domain.h
(this would avoid to include it everywhere...).
I have tried that, but other CUs use definitions from
public/hv
Manuel Bouyer writes ("Re: [PATCH] libs/light: make it build without
setresuid()"):
> On Wed, Jan 27, 2021 at 04:03:04PM +, Ian Jackson wrote:
> > How about I write a patch splitting the relevant part up into a
> > version for systems with setresuid and systems without ? Then you
> > could fi
On 28/01/2021 10:52, Andrew Cooper wrote:
> On 26/01/2021 22:47, Manuel Bouyer wrote:
>> diff --git a/tools/libs/foreignmemory/netbsd.c
>> b/tools/libs/foreignmemory/netbsd.c
>> index 54a418ebd6..a7e1d72ffc 100644
>> --- a/tools/libs/foreignmemory/netbsd.c
>> +++ b/tools/libs/foreignmemory/netbsd.
On Tue, Jan 26, 2021 at 11:47:49PM +0100, Manuel Bouyer wrote:
> When a domain is destroyed, xparams may not be available any more when
> the block script is called to unconfigure the vnd.
> Check xparam only at configure time, and just unconfigure any vnd present
> in the xenstore.
Can you paste
With the Xen side of this interface (soon to be) fixed to return real sizes,
userspace needs to be able to make the query.
Introduce xenforeignmemory_resource_size() for the purpose, bumping the
library minor version.
Update both all osdep_xenforeignmemory_map_resource() implementations to
unders
On 28.01.21 12:52, Jan Beulich wrote:
Hi Jan
On 25.01.2021 20:08, Oleksandr Tyshchenko wrote:
--- /dev/null
+++ b/xen/include/xen/dm.h
@@ -0,0 +1,41 @@
+/*
+ * Copyright (c) 2016 Citrix Systems Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the
I think you send a wrong subject by mistake.
Thanks,
Joseph
On 1/28/21 3:11 PM, Chaitanya Kulkarni wrote:
> Signed-off-by: Chaitanya Kulkarni
> ---
> fs/ocfs2/cluster/heartbeat.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/fs/ocfs2/cluster/heartbeat.c b/fs/oc
> -Original Message-
> From: Andrew Cooper
> Sent: 28 January 2021 12:02
> To: Xen-devel
> Cc: Andrew Cooper ; Wei Liu ; Paul
> Durrant ;
> Roger Pau Monné ; Juergen Gross ; Ian
> Jackson
> ; Michał Leszczyński ;
> Hubert Jasudowicz
> ; Tamas K Lengyel ; Manuel
> Bouyer
> Subject: [P
You probably don't need 4 patches to fs/jfs/. These can be combined into
a single patch.
Dave
On 1/28/21 1:11 AM, Chaitanya Kulkarni wrote:
Signed-off-by: Chaitanya Kulkarni
---
fs/jfs/jfs_logmgr.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/fs/jfs/jfs_logmgr
On 28.01.21 13:21, Jan Beulich wrote:
Hi Jan
On 28.01.2021 12:01, Oleksandr wrote:
On 27.01.21 22:46, Stefano Stabellini wrote:
On Wed, 27 Jan 2021, Oleksandr wrote:
Thank you. I got a request to make a possibility for user to select IOREQ via
the menuconfig on Arm. Saying tech preview do
From: Paul Durrant
Prior to commit 4a8c31a1c6f5 ("xen/blkback: rework connect_ring() to avoid
inconsistent xenstore 'ring-page-order' set by malicious blkfront"), the
behaviour of xen-blkback when connecting to a frontend was:
- read 'ring-page-order'
- if not present then expect a single page r
On Thu, Jan 28, 2021 at 12:01:52PM +, Andrew Cooper wrote:
> With the Xen side of this interface (soon to be) fixed to return real sizes,
> userspace needs to be able to make the query.
>
> Introduce xenforeignmemory_resource_size() for the purpose, bumping the
> library minor version.
>
> Up
Apologies; I missed the v2 from the subject line. I'll re-send.
Paul
> -Original Message-
> From: Xen-devel On Behalf Of Paul
> Durrant
> Sent: 28 January 2021 12:55
> To: xen-devel@lists.xenproject.org; linux-bl...@vger.kernel.org;
> linux-ker...@vger.kernel.org
> Cc: Paul Durrant ;
From: Paul Durrant
Prior to commit 4a8c31a1c6f5 ("xen/blkback: rework connect_ring() to avoid
inconsistent xenstore 'ring-page-order' set by malicious blkfront"), the
behaviour of xen-blkback when connecting to a frontend was:
- read 'ring-page-order'
- if not present then expect a single page r
On 28.01.21 11:55, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 25/01/2021 19:08, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
We need to send mapcache invalidation request to qemu/demu everytime
the page gets removed from a guest.
At the moment, the Arm code doesn't exp
On 28.01.2021 13:06, Oleksandr wrote:
>
> On 28.01.21 12:52, Jan Beulich wrote:
>
> Hi Jan
>
>> On 25.01.2021 20:08, Oleksandr Tyshchenko wrote:
>>> --- /dev/null
>>> +++ b/xen/include/xen/dm.h
>>> @@ -0,0 +1,41 @@
>>> +/*
>>> + * Copyright (c) 2016 Citrix Systems Inc.
>>> + *
>>> + * This progr
On 28.01.21 13:33, Oleksandr wrote:
Hi Julien
On 28.01.21 11:40, Julien Grall wrote:
Hi Julien
Hi Oleksandr,
On 27/01/2021 19:20, Oleksandr wrote:
> >>> So I think we may be able to drop the include from
asm/hvm/domain.h
(this would avoid to include it everywhere...).
I have tried t
Hi Oleksandr,
On 25/01/2021 19:08, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and these fields will be used
on Arm as is. Move them to common struct vcpu as a part of new
struct vcpu_io and drop duplicating "io" prefixes. Also move
enum hvm_io_comp
On 28.01.2021 14:41, Julien Grall wrote:
> Hi Oleksandr,
>
> On 25/01/2021 19:08, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko
>>
>> The IOREQ is a common feature now and these fields will be used
>> on Arm as is. Move them to common struct vcpu as a part of new
>> struct vcpu_io and
Manuel Bouyer writes ("Re: [PATCH] NetBSD hotplug: Introduce locking
functions"):
> thanks, but I submitted a v2 patch which uses a locking.sh derived
> from the linux one, based on your feedback.
> Should I add your Reviewed-by to the v2 ?
Sorry, yes, please.
Ian.
On 28.01.21 15:41, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 25/01/2021 19:08, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and these fields will be used
on Arm as is. Move them to common struct vcpu as a part of new
struct vcpu_io and
Hi Jan,
On 28/01/2021 13:53, Jan Beulich wrote:
On 28.01.2021 14:41, Julien Grall wrote:
Hi Oleksandr,
On 25/01/2021 19:08, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and these fields will be used
on Arm as is. Move them to common struct vcpu as
Andrew Cooper writes ("Re: [OSSTEST PATCH 7/7] make-flight: Stripy xenstored
[and 2 more messages]"):
> Well - I ask specifically because there is a thread on xen-devel about
> upping the minimum supported version of Ocaml, in order to simplify a
> couple of aspects.
>
> This would manifest as ox
Hi Julien
On 28.01.21 15:39, Oleksandr wrote:
On 28.01.21 13:33, Oleksandr wrote:
Hi Julien
On 28.01.21 11:40, Julien Grall wrote:
Hi Julien
Hi Oleksandr,
On 27/01/2021 19:20, Oleksandr wrote:
> >>> So I think we may be able to drop the include from
asm/hvm/domain.h
(this would a
On 28.01.2021 15:21, Julien Grall wrote:
> On 28/01/2021 13:53, Jan Beulich wrote:
>> On 28.01.2021 14:41, Julien Grall wrote:
>>> On 25/01/2021 19:08, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and these fields will be used
on Arm
Hi Julien, all
On 27.01.21 19:45, Oleksandr wrote:
On 27.01.21 19:42, Julien Grall wrote:
Hi
On 27/01/2021 17:37, Oleksandr wrote:
On 27.01.21 19:33, Julien Grall wrote:
Hi Julien
On 27/01/2021 16:50, Oleksandr wrote:
On 27.01.21 18:43, Julien Grall wrote:
Hi Oleksandr,
Hi J
hvm_destroy_all_ioreq_servers(), called from
hvm_domain_relinquish_resources(), invokes relocate_portio_handler(),
which uses d->arch.hvm.io_handler. Defer freeing of this array
accordingly on the error path of hvm_domain_initialise().
Similarly rtc_deinit() requires d->arch.hvm.pl_time to still b
On 28/01/2021 14:29, Oleksandr wrote:
Hi Julien
On 28.01.21 15:39, Oleksandr wrote:
On 28.01.21 13:33, Oleksandr wrote:
Hi Julien
On 28.01.21 11:40, Julien Grall wrote:
Hi Julien
Hi Oleksandr,
On 27/01/2021 19:20, Oleksandr wrote:
> >>> So I think we may be able to drop the incl
On 25.01.2021 18:59, Andrew Cooper wrote:
> I am literally not changing the current behaviour. Xen *will* hit a
> BUG() if any of these domain_crash() paths are taken.
>
> If you do not believe me, then please go and actually check what happens
> when simulating a ref-acquisition failure.
Okay,
On 28/01/2021 14:36, Jan Beulich wrote:
> On 28.01.2021 15:21, Julien Grall wrote:
>> I was going to reply back on my e-mail with more debugging information.
>> It seems that this is a build issue as if I clean the repo the error
>> disappear.
>>
>> The error happens when I move from staging to a
flight 158724 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158724/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 158713
Tests which
Jan Beulich writes ("Re: [PATCH V5 10/22] xen/ioreq: Move x86's
io_completion/io_req fields to struct vcpu"):
> On 28.01.2021 15:21, Julien Grall wrote:
> > It seems that this is a build issue as if I clean the repo the error
> > disappear.
> >
> > The error happens when I move from staging to a
On 28.01.21 16:41, Julien Grall wrote:
Hi Julien
On 28/01/2021 14:29, Oleksandr wrote:
Hi Julien
On 28.01.21 15:39, Oleksandr wrote:
On 28.01.21 13:33, Oleksandr wrote:
Hi Julien
On 28.01.21 11:40, Julien Grall wrote:
Hi Julien
Hi Oleksandr,
On 27/01/2021 19:20, Oleksandr wrot
On 28.01.2021 15:51, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH V5 10/22] xen/ioreq: Move x86's
> io_completion/io_req fields to struct vcpu"):
>> On 28.01.2021 15:21, Julien Grall wrote:
>>> It seems that this is a build issue as if I clean the repo the error
>>> disappear.
>>>
>>> The
Jan Beulich writes ("Re: [PATCH for-4.15] x86/boot: Drop 'noapic' suggestion
from check_timer()"):
> On 27.01.2021 20:49, Andrew Cooper wrote:
> > In practice, there is no such thing as a real 64bit system without
> > APICs. (PVH style virtual environments, sure, but they don't end up here).
> >
Hi Jan,
On 28/01/2021 14:36, Jan Beulich wrote:
On 28.01.2021 15:21, Julien Grall wrote:
On 28/01/2021 13:53, Jan Beulich wrote:
On 28.01.2021 14:41, Julien Grall wrote:
On 25/01/2021 19:08, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and these
On 28/01/2021 14:52, Oleksandr wrote:
On 28.01.21 16:41, Julien Grall wrote:
On 28/01/2021 14:29, Oleksandr wrote:
On 28.01.21 15:39, Oleksandr wrote:
On 28.01.21 13:33, Oleksandr wrote:
Hi Julien
On 28.01.21 11:40, Julien Grall wrote:
Hi Julien
Hi Oleksandr,
On 27/01/2021 19:20,
Hi,
On 28/01/2021 14:37, Oleksandr wrote:
On 27.01.21 19:45, Oleksandr wrote:
On 27.01.21 19:42, Julien Grall wrote:
Hi
On 27/01/2021 17:37, Oleksandr wrote:
On 27.01.21 19:33, Julien Grall wrote:
Hi Julien
On 27/01/2021 16:50, Oleksandr wrote:
On 27.01.21 18:43, Julien Grall wro
On 28/01/2021 14:57, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH for-4.15] x86/boot: Drop 'noapic' suggestion
> from check_timer()"):
>> On 27.01.2021 20:49, Andrew Cooper wrote:
>>> In practice, there is no such thing as a real 64bit system without
>>> APICs. (PVH style virtual environm
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.11-rc6-tag
xen: branch for v5.11-rc6
It contains the following fixes:
- A fix for a regression introduced in 5.11 resulting in Xen dom0 having
problems to correctly initialize Xe
Using RING_GET_RESPONSE() on a shared ring is easy to use incorrectly
(i.e., by not considering that the other end may alter the data in the
shared ring while it is being inspected). Safe usage of a response
generally requires taking a local copy.
Provide a RING_COPY_RESPONSE() macro to use instea
The ABI is unfortunate, and frame being 64 bits leads to all kinds of problems
performing correct overflow checks.
Furthermore, the mixed use of unsigned int and unsigned long in the call tree
is buggy on arm32 where the two are the same size, and certain out-of-range
combinations will truncated a
Hi,
On 25/01/2021 19:08, Oleksandr Tyshchenko wrote:
> Patch series [8] was rebased on recent "staging branch"
(5e31789 tools/ocaml/libs/xb: Do not crash after xenbus is unmapped) and tested
on
Renesas Salvator-X board + H3 ES3.0 SoC (Arm64) with virtio-mmio disk backend
[9]
running in driver
On 28/01/2021 14:54, Jan Beulich wrote:
> On 28.01.2021 15:51, Ian Jackson wrote:
>> Jan Beulich writes ("Re: [PATCH V5 10/22] xen/ioreq: Move x86's
>> io_completion/io_req fields to struct vcpu"):
Removing entry.o or asm-offsets.h before building doesn't help. Any
other idea?
>>> No, I
On 27/01/2021 23:11, Rahul Singh wrote:
Hello Julien,
Hi Rahul,
On 27 Jan 2021, at 9:25 pm, Julien Grall wrote:
Hi,
On Wed, 27 Jan 2021 at 21:16, Stefano Stabellini wrote:
Hi all,
These are two recent randconfig build failures reported by gitlab (the
two patches that triggered the CI-l
This documents our practice, established in 2018
https://lists.xen.org/archives/html/xen-devel/2018-07/msg02240.html
et seq
CC: Jürgen Groß
CC: Paul Durrant
CC: Wei Liu
Signed-off-by: Ian Jackson
---
docs/process/xen-release-management.pandoc | 12 ++--
1 file changed, 10 insertions
On 28.01.2021 17:34, Julien Grall wrote:
> On 27/01/2021 23:11, Rahul Singh wrote:
>> Hello Julien,
>
> Hi Rahul,
>
>>> On 27 Jan 2021, at 9:25 pm, Julien Grall wrote:
>>>
>>> Hi,
>>>
>>> On Wed, 27 Jan 2021 at 21:16, Stefano Stabellini
>>> wrote:
Hi all,
These are two rece
FYI your email is completely unreadable to those not using html.
I can't tell what you wrote and what Damien wrote.
On Thu, Jan 28, 2021 at 08:33:10AM +, Chaitanya Kulkarni wrote:
> On 1/27/21 11:21 PM, Damien Le Moal wrote:
>
> On 2021/01/28 16:12, Chaitanya Kulkarni wrote:
>
>
> Introdu
On 28.01.2021 17:35, Ian Jackson wrote:
> This documents our practice, established in 2018
> https://lists.xen.org/archives/html/xen-devel/2018-07/msg02240.html
> et seq
>
> CC: Jürgen Groß
> CC: Paul Durrant
> CC: Wei Liu
> Signed-off-by: Ian Jackson
> ---
> docs/process/xen-release-manage
On 28/01/2021 14:40, Jan Beulich wrote:
> hvm_destroy_all_ioreq_servers(), called from
> hvm_domain_relinquish_resources(), invokes relocate_portio_handler(),
> which uses d->arch.hvm.io_handler. Defer freeing of this array
> accordingly on the error path of hvm_domain_initialise().
>
> Similarly r
Jan Beulich writes ("Re: [PATCH] xen-release-management doc: More info on
schedule"):
> On 28.01.2021 17:35, Ian Jackson wrote:
> > -The Xen hypervisor project now releases every 8 months. The actual release
> > date
> > -depends on a lot of factors.
> > +The Xen hypervisor project now releases e
On 28.01.2021 17:51, Andrew Cooper wrote:
> On 28/01/2021 14:40, Jan Beulich wrote:
>> hvm_destroy_all_ioreq_servers(), called from
>> hvm_domain_relinquish_resources(), invokes relocate_portio_handler(),
>> which uses d->arch.hvm.io_handler. Defer freeing of this array
>> accordingly on the error
On Wed, Jan 27, 2021 at 11:11:16PM -0800, Chaitanya Kulkarni wrote:
> Signed-off-by: Chaitanya Kulkarni
Looks ok to me,
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/iomap/direct-io.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/fs/iomap/direct-io.c b/fs/iomap
> -Original Message-
> From: Andrew Cooper
> Sent: 28 January 2021 16:06
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Roger Pau Monné
> ; Wei Liu ; Stefano Stabellini
> ; Julien
> Grall ; Volodymyr Babchuk ; Paul
> Durrant ;
> Oleksandr Tyshchenko
> Subject: [PATCH] xen/memor
On Thu, 28 Jan 2021, Oleksandr wrote:
> On 28.01.21 13:21, Jan Beulich wrote:
> > On 28.01.2021 12:01, Oleksandr wrote:
> > > On 27.01.21 22:46, Stefano Stabellini wrote:
> > > > On Wed, 27 Jan 2021, Oleksandr wrote:
> > > > > Thank you. I got a request to make a possibility for user to select
> >
flight 158714 qemu-mainline real [real]
flight 158734 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158714/
http://logs.test-lab.xenproject.org/osstest/logs/158734/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Hello Julien,
> On 28 Jan 2021, at 4:34 pm, Julien Grall wrote:
>
> On 27/01/2021 23:11, Rahul Singh wrote:
>> Hello Julien,
>
> Hi Rahul,
>
>>> On 27 Jan 2021, at 9:25 pm, Julien Grall wrote:
>>>
>>> Hi,
>>>
>>> On Wed, 27 Jan 2021 at 21:16, Stefano Stabellini
>>> wrote:
Hi al
On Wed, Jan 27, 2021 at 11:11:25PM -0800, Chaitanya Kulkarni wrote:
> Signed-off-by: Chaitanya Kulkarni
Seems fine to me...
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/xfs/xfs_bio_io.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/fs/xfs/xfs_bio_io.c b/fs/xf
On Wed, Jan 27, 2021 at 11:11:26PM -0800, Chaitanya Kulkarni wrote:
> Signed-off-by: Chaitanya Kulkarni
Reviewed-by: Darrick J. Wong
--D
> ---
> fs/xfs/xfs_buf.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
> index f8400bb
On Wed, Jan 27, 2021 at 11:11:17PM -0800, Chaitanya Kulkarni wrote:
> Signed-off-by: Chaitanya Kulkarni
> ---
> fs/iomap/direct-io.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
> index f6c557a1bd25..0737192f7e5c 100644
On Thu, 28 Jan 2021, Julien Grall wrote:
> On 25/01/2021 19:08, Oleksandr Tyshchenko wrote:
> > Patch series [8] was rebased on recent "staging branch"
> > (5e31789 tools/ocaml/libs/xb: Do not crash after xenbus is unmapped) and
> > tested on
> > Renesas Salvator-X board + H3 ES3.0 SoC (Arm64) wit
On 28/01/2021 17:24, Stefano Stabellini wrote:
On Thu, 28 Jan 2021, Julien Grall wrote:
On 25/01/2021 19:08, Oleksandr Tyshchenko wrote:
> Patch series [8] was rebased on recent "staging branch"
(5e31789 tools/ocaml/libs/xb: Do not crash after xenbus is unmapped) and
tested on
Renesas Salv
On 28/01/2021 16:46, Jan Beulich wrote:
On 28.01.2021 17:34, Julien Grall wrote:
On 27/01/2021 23:11, Rahul Singh wrote:
Hello Julien,
Hi Rahul,
On 27 Jan 2021, at 9:25 pm, Julien Grall wrote:
Hi,
On Wed, 27 Jan 2021 at 21:16, Stefano Stabellini wrote:
Hi all,
These are two recent
On 28.01.21 17:08, Julien Grall wrote:
Hi Julien
On 28/01/2021 14:52, Oleksandr wrote:
On 28.01.21 16:41, Julien Grall wrote:
On 28/01/2021 14:29, Oleksandr wrote:
On 28.01.21 15:39, Oleksandr wrote:
On 28.01.21 13:33, Oleksandr wrote:
Hi Julien
On 28.01.21 11:40, Julien Grall wro
flight 158728 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158728/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 158713
Tests which
On 28.01.21 17:14, Julien Grall wrote:
Hi Julien
Hi,
On 28/01/2021 14:37, Oleksandr wrote:
On 27.01.21 19:45, Oleksandr wrote:
On 27.01.21 19:42, Julien Grall wrote:
Hi
On 27/01/2021 17:37, Oleksandr wrote:
On 27.01.21 19:33, Julien Grall wrote:
Hi Julien
On 27/01/2021 16:50,
On 28/01/2021 17:44, Julien Grall wrote:
>
>
> On 28/01/2021 17:24, Stefano Stabellini wrote:
>> On Thu, 28 Jan 2021, Julien Grall wrote:
>>> On 25/01/2021 19:08, Oleksandr Tyshchenko wrote:
>>> > Patch series [8] was rebased on recent "staging branch"
(5e31789 tools/ocaml/libs/xb: Do not cr
1 - 100 of 161 matches
Mail list logo
