On 29.01.21 07:20, Dongli Zhang wrote:
On 1/28/21 5:04 AM, Paul Durrant wrote:
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
flight 158759 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158759/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 158713
build-arm64-
On 1/28/21 5:04 AM, Paul Durrant wrote:
> 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
flight 158748 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158748/
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 158740 qemu-mainline real [real]
flight 158762 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158740/
http://logs.test-lab.xenproject.org/osstest/logs/158762/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 29.01.21 01:51, Marek Marczykowski-Górecki wrote:
On Thu, Jan 28, 2021 at 07:03:00PM -0500, Boris Ostrovsky wrote:
On 1/28/21 6:52 PM, Michael D Labriola wrote:
Hey, everyone. I've run into problems starting up my Xen domUs as of
the latest batch of stable updates. Whenever I try to creat
Greetings,
I try to run Xen on low energy platforms. I've previously been here
about an Intal Atom which died
just after the 3 year warranty expired. So I'm trying AMD's laptop
Ryzen. I think I've been using Xen
for 8 years.
I have Debian (Linux snuc 4.19.0-13-amd64 #1 SMP Debian 4.19.160-
flight 158752 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158752/
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
From: Oleksandr Tyshchenko
In the ideal world we would never get an undefined behavior when
propagating the sign bit since that bit can only be set for access
size smaller than the register size (i.e byte/half-word for aarch32,
byte/half-word/word for aarch64).
In the real world we need to care
From: Oleksandr Tyshchenko
As the IOREQ is a common feature now and we also need to
invalidate qemu/demu mapcache on Arm when the required condition
occurs this patch moves this function to the common code
(and remames it to ioreq_signal_mapcache_invalidate).
This patch also moves per-domain qemu
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 new mapping. Instead, this is done
implicitely by __p2m_set_entry()
From: Oleksandr Tyshchenko
This patch prevents the device model running on other than x86
systems to use buffered I/O feature for now.
Please note, there is no caller which requires to send buffered
I/O request on Arm currently and the purpose of this check is
to catch any future user of bufiore
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_completion to xen/sched.h and remove "hvm" prefixes.
This patch compl
From: Oleksandr Tyshchenko
This patch adds ability to the device emulator to notify otherend
(some entity running in the guest) using a SPI and implements Arm
specific bits for it. Proposed interface allows emulator to set
the logical level of a one of a domain's IRQ lines.
We can't reuse the ex
From: Oleksandr Tyshchenko
This patch introduces a helper the main purpose of which is to check
if a domain is using IOREQ server(s).
On Arm the current benefit is to avoid calling vcpu_ioreq_handle_completion()
(which implies iterating over all possible IOREQ servers anyway)
on every return in
From: Oleksandr Tyshchenko
In order to avoid code duplication (both handle_read() and
handle_ioserv() contain the same code for the sign-extension)
put this code to a common helper to be used for both.
Signed-off-by: Oleksandr Tyshchenko
CC: Julien Grall
Reviewed-by: Stefano Stabellini
[On Ar
From: Julien Grall
This patch adds basic IOREQ/DM support on Arm. The subsequent
patches will improve functionality and add remaining bits.
The IOREQ/DM features are supposed to be built with IOREQ_SERVER
option enabled, which is disabled by default on Arm for now.
Please note, the "PIO handlin
From: Julien Grall
As x86 implementation of XENMEM_resource_ioreq_server can be
re-used on Arm later on, this patch makes it common and removes
arch_acquire_resource (and the corresponding option) as unneeded.
Also re-order #include-s alphabetically.
This support is going to be used on Arm to b
From: Oleksandr Tyshchenko
This patch adds remaining bits needed for the IOREQ support on Arm.
Besides just calling vcpu_ioreq_handle_completion() we need to handle
it's return value to make sure that all the vCPU works are done before
we return to the guest (the vcpu_ioreq_handle_completion() ma
From: Oleksandr Tyshchenko
The cmpxchg() in ioreq_send_buffered() operates on memory shared
with the emulator domain (and the target domain if the legacy
interface is used).
In order to be on the safe side we need to switch
to guest_cmpxchg64() to prevent a domain to DoS Xen on Arm.
The point to
From: Oleksandr Tyshchenko
This patch implements reference counting of foreign entries in
in set_foreign_p2m_entry() on Arm. This is a mandatory action if
we want to run emulator (IOREQ server) in other than dom0 domain,
as we can't trust it to do the right thing if it is not running
in dom0. So
From: Oleksandr Tyshchenko
This patch removes "hvm" prefixes and infixes from IOREQ related
function names in the common code and performs a renaming where
appropriate according to the more consistent new naming scheme:
- IOREQ server functions should start with "ioreq_server_"
- IOREQ functions
From: Oleksandr Tyshchenko
The purpose of this patch is to add a possibility for user
to be able to select IOREQ support on Arm (which is disabled
by default) with retaining the current behaviour on x86
(is selected by HVM and it's prompt is not visible).
Also make the IOREQ be depended on CONFI
From: Julien Grall
As a lot of x86 code can be re-used on Arm later on, this patch
moves the IOREQ related dm-op handling to the common code.
The idea is to have the top level dm-op handling arch-specific
and call into ioreq_server_dm_op() for otherwise unhandled ops.
Pros:
- More natural than d
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and this struct will be used
on Arm as is. Move it to common struct domain. This also
significantly reduces the layering violation in the common code
(*arch.hvm* usage).
We don't move ioreq_gfn since it is not used in the common code
(
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and these structs will be used
on Arm as is. Move them to xen/ioreq.h and remove "hvm" prefixes.
Also there is no need to include public/hvm/dm_op.h by
asm-x86/hvm/domain.h anymore since #define NR_IO_RANGE_TYPES
(which uses XEN_DMOP_I
From: Oleksandr Tyshchenko
As a lot of x86 code can be re-used on Arm later on, this patch
moves previously prepared IOREQ support to the common code
(the code movement is verbatim copy).
The "legacy" mechanism of mapping magic pages for the IOREQ servers
remains x86 specific and not exposed to
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and these helpers will be used
on Arm as is. Move them to xen/ioreq.h and replace "hvm" prefixes
with "ioreq".
Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Paul Durrant
Acked-by: Jan Beulich
Reviewed-by: Julien Grall
Reviewed-b
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and this helper will be used
on Arm as is. Move it to xen/ioreq.h and remove "hvm" prefix.
Although PIO handling on Arm is not introduced with the current series
(it will be implemented when we add support for vPCI), technically
the PI
From: Oleksandr Tyshchenko
The IOREQ is about to be common feature 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 to rename the function (which is used for a varying
set of
From: Oleksandr Tyshchenko
This patch continues to make some preparation to x86/hvm/ioreq.c
before moving to the common code.
Add IOREQ_STATUS_* #define-s and update candidates for moving
since X86EMUL_* shouldn't be exposed to the common code in
that form.
This support is going to be used on A
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.
This patch mostly introduces specific hooks to abst
From: Oleksandr Tyshchenko
Hello all.
The purpose of this patch series is to add IOREQ/DM support to Xen on Arm.
You can find an initial discussion at [1] and RFC-V5 series at [2]-[7].
Xen on Arm requires some implementation to forward guest MMIO access to a device
model in order to implement vi
On 28.01.21 21:44, Oleksandr wrote:
Hi Andrew, Julien
On 28.01.21 20:10, Andrew Cooper wrote:
Hi Andrew
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:
flight 158722 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158722/
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 Thu, Jan 28, 2021 at 07:03:00PM -0500, Boris Ostrovsky wrote:
>
> On 1/28/21 6:52 PM, Michael D Labriola wrote:
> > Hey, everyone. I've run into problems starting up my Xen domUs as of
> > the latest batch of stable updates. Whenever I try to create one, I
> > get a bunch of block device erro
On Thu, Jan 28, 2021 at 7:03 PM Boris Ostrovsky
wrote:
>
>
> On 1/28/21 6:52 PM, Michael D Labriola wrote:
> > Hey, everyone. I've run into problems starting up my Xen domUs as of
> > the latest batch of stable updates. Whenever I try to create one, I
> > get a bunch of block device errors like
flight 158719 xen-unstable real [real]
flight 158751 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158719/
http://logs.test-lab.xenproject.org/osstest/logs/158751/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On 1/28/21 6:52 PM, Michael D Labriola wrote:
> Hey, everyone. I've run into problems starting up my Xen domUs as of
> the latest batch of stable updates. Whenever I try to create one, I
> get a bunch of block device errors like this:
>
> libxl: error: libxl_device.c:1105:device_backend_callbac
flight 158750 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158750/
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
Hey, everyone. I've run into problems starting up my Xen domUs as of
the latest batch of stable updates. Whenever I try to create one, I
get a bunch of block device errors like this:
libxl: error: libxl_device.c:1105:device_backend_callback: Domain 4:unable to
add device with path /local/domain
On 15/01/2021 16:12, Jan Beulich wrote:
> On 12.01.2021 20:48, Andrew Cooper wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -4628,7 +4628,6 @@ int arch_acquire_resource(struct domain *d, unsigned
>> int type,
>> if ( id != (unsigned int)ioservid )
>> break
On 15/01/2021 15:37, Jan Beulich wrote:
> On 12.01.2021 20:48, Andrew Cooper wrote:
>> @@ -446,6 +430,31 @@ int compat_memory_op(unsigned int cmd,
>> XEN_GUEST_HANDLE_PARAM(void) compat)
>>
>> #undef XLAT_mem_acquire_resource_HNDL_frame_list
>>
>> +if ( xen_frame_list && cmp.mar.n
On 18/01/2021 08:23, Jan Beulich wrote:
> On 15.01.2021 17:57, Andrew Cooper wrote:
>> On 15/01/2021 11:56, Jan Beulich wrote:
+/* Grow table if necessary. */
+grant_write_lock(gt);
+rc = -EINVAL;
+switch ( id )
+{
+case XENMEM_resource_grant_ta
> On Jan 28, 2021, at 10:42 PM, George Dunlap wrote:
>
>
>
>> On Jan 28, 2021, at 6:26 PM, Elliott Mitchell wrote:
>>
>> On Thu, Jan 28, 2021 at 11:19:41AM +0100, Jan Beulich wrote:
>>> On 27.01.2021 23:28, Elliott Mitchell wrote:
On Wed, Jan 27, 2021 at 09:03:32PM +, Andrew Cooper
On Fri, 2021-01-15 at 15:14 +, Lengyel, Tamas wrote:
>
> > 2) "scheduler broken" bugs. We've had 4 or 5 reports of Xen not
> > working,
> > and very little investigation on whats going on. Suspicion is that
> > there
> > might be two bugs, one with smt=0 on recent AMD hardware, and one
> > m
> On Jan 28, 2021, at 6:26 PM, Elliott Mitchell wrote:
>
> On Thu, Jan 28, 2021 at 11:19:41AM +0100, Jan Beulich wrote:
>> 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 dirtie
On Thu, 2021-01-28 at 19:26 +0100, Dario Faggioli wrote:
>
> [...]
>
> 2) Then there has been his one:
>
>
> https://lists.xenproject.org/archives/html/xen-devel/2020-10/msg01005.html
>
> Here, the where reporter said that "[credit1] results is an
> observable
> delay, unusable performance; cr
On Thu, 28 Jan 2021 at 20:10, Andrew Cooper wrote:
>
> On 28/01/2021 18:16, Julien Grall wrote:
> > Hi Andrew,
> >
> > On 28/01/2021 18:10, Andrew Cooper wrote:
> >> On 28/01/2021 17:44, Julien Grall wrote:
> >>>
> >>>
> >>> On 28/01/2021 17:24, Stefano Stabellini wrote:
> On Thu, 28 Jan 2021
flight 158743 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158743/
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 20/01/2021 09:19, Jan Beulich wrote:
> On 16.01.2021 00:10, Andrew Cooper wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -834,6 +834,29 @@ void load_system_tables(void)
>> BUG_ON(system_state != SYS_STATE_early_boot && (stack_bottom & 0xf));
>> }
>>
>>
On 28/01/2021 18:16, Julien Grall wrote:
> Hi Andrew,
>
> On 28/01/2021 18:10, Andrew Cooper wrote:
>> 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 wr
On 28.01.21 15:18, Jan Beulich wrote:
Hi Jan
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.
+ *
+
On 28.01.21 20:10, Andrew Cooper wrote:
Hi Andrew
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"
flight 158716 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158716/
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
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree
On Thu, Jan 28, 2021 at 11:19:41AM +0100, Jan Beulich wrote:
> 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
On Thu, 2021-01-14 at 19:02 +, Andrew Cooper wrote:
> On 14/01/2021 16:06, Ian Jackson wrote:
> > The last posting date for new feature patches for Xen 4.15 is
> > tomorrow. [1] We seem to be getting a reasonable good flood of
> > stuff
> > trying to meet this deadline :-).
> >
> > Patches fo
On 28/01/2021 18:16, Julien Grall wrote:
Hi Andrew,
On 28/01/2021 18:10, Andrew Cooper wrote:
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 seri
The pull request you sent on Thu, 28 Jan 2021 16:33:56 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.11-rc6-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e5ff2cb9cf67a542f2ec7fb87e24934c88b32678
Thank you!
--
Deet-doot-dot, I
Hi Andrew,
On 28/01/2021 18:10, Andrew Cooper wrote:
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"
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
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,
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: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
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/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 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 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 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: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
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
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
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
> >
> -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 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
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
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 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
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
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: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
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 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
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
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
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
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
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
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
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: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 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
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).
> >
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
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
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
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
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
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,
1 - 100 of 161 matches
Mail list logo
