flight 134935 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134935/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 21 leak-check/check fail REGR. vs. 134889
test-amd64-i386-xl-qemuu-o
flight 134791 qemu-upstream-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134791/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken in 134580
build-arm64
flight 134936 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134936/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
On 4/17/19 8:30 PM, PGNet Dev wrote:
> Thx.
>
> not ignoring you -- opensuse kernel build system is having a hissy-fit
> atm; builds are failing. :-/
>
> if I can't get it to behave a build a nice pkg for me, I'll work on a
> manual spin.
With a pkg instance of your-patched kernel 5.0.8,
Thx.
not ignoring you -- opensuse kernel build system is having a hissy-fit
atm; builds are failing. :-/
if I can't get it to behave a build a nice pkg for me, I'll work on a
manual spin.
On 4/17/19 5:05 AM, Roger Pau Monné wrote:
On Tue, Apr 16, 2019 at 12:50:43PM +0200, Roger Pau Monn
On 2019/4/17 23:04, Wei Liu wrote:
On Sat, Apr 13, 2019 at 12:14:14AM +0800, Pu Wen wrote:
On 2019/4/5 15:50, Jan Beulich wrote:
On 04.04.19 at 18:39, wrote:
On 2019/4/4 22:07, Andrew Cooper wrote:
This needs the following hunk folding in
which can be done on commit to avoid sending yet anot
This deals with two casting issues for compiling under go 1.11:
- explicitly cast to *C.xentoollog_logger for Ctx.logger pointer
- add cast to unsafe.Pointer for the C string cpath
Signed-off-by: Daniel P. Smith
---
tools/golang/xenlight/xenlight.go | 8
1 file changed, 4 insertions(+),
flight 134933 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134933/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
flight 134928 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134928/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
On Wed, 17 Apr 2019, Julien Grall wrote:
> Hi,
>
> On 4/17/19 10:12 PM, Stefano Stabellini wrote:
> > On Wed, 27 Feb 2019, Jan Beulich wrote:
> > > > > > On 27.02.19 at 00:07, wrote:
> > > > --- a/xen/include/public/domctl.h
> > > > +++ b/xen/include/public/domctl.h
> > > > @@ -571,12 +571,14 @@
flight 134780 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134780/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken in 134507
build-arm64-xsm
Hi,
On 4/17/19 10:12 PM, Stefano Stabellini wrote:
On Wed, 27 Feb 2019, Jan Beulich wrote:
On 27.02.19 at 00:07, wrote:
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -571,12 +571,14 @@ struct xen_domctl_bind_pt_irq {
*/
#define DPCI_ADD_MAPPING 1
#define
Hi,
On 4/17/19 9:52 PM, Stefano Stabellini wrote:
Gentle ping.
As I said in [1], I don't plan to review v2 because I answered to some
of the issues in v1. You have enough to respin this.
Cheers,
[1] https://lists.xen.org/archives/html/xen-devel/2019-01/msg01133.html
--
Julien Grall
_
On 4/17/19 9:29 PM, Stefano Stabellini wrote:
On Wed, 27 Mar 2019, Julien Grall wrote:
Clang is pickier than GCC for the register size in asm statement. It
expects the register size to match the value size.
The asm statement expects a 32-bit (resp. 64-bit) value on Arm32
(resp. Arm64) whereas
Hi,
On 4/17/19 9:28 PM, Stefano Stabellini wrote:
On Wed, 27 Mar 2019, Julien Grall wrote:
Clang is pickier than GCC for the register size in asm statement. It
expects the register size to match the value size.
The asm statement expects a 32-bit (resp. 64-bit) value on Arm32
(resp. Arm64) wher
On Wed, 27 Feb 2019, Jan Beulich wrote:
> >>> On 27.02.19 at 00:07, wrote:
> > --- a/xen/include/public/domctl.h
> > +++ b/xen/include/public/domctl.h
> > @@ -571,12 +571,14 @@ struct xen_domctl_bind_pt_irq {
> > */
> > #define DPCI_ADD_MAPPING 1
> > #define DPCI_REMOVE_MAPPING 0
>
Hi,
On 4/17/19 9:24 PM, Stefano Stabellini wrote:
On Wed, 27 Mar 2019, Julien Grall wrote:
Hi,
On 27/03/2019 19:03, Andrew Cooper wrote:
On 27/03/2019 18:45, Julien Grall wrote:
Clang is pickier than GCC for the register size in asm statement. It expects
the register size to match the value
Hi,
On 4/17/19 9:45 PM, Stefano Stabellini wrote:
On Wed, 27 Mar 2019, Julien Grall wrote:
Clang understands the GCCism in use here, but still complains that sp is
unitialised. In such cases, resort to the older versions of this code,
which directly read sp into the temporary variable.
Note th
Gentle ping.
On Thu, 3 Jan 2019, Stefano Stabellini wrote:
> Hi all,
>
> This small patch series adds device assignment support to Dom0less.
> The last patch is the documentation.
>
> Cheers,
>
> Stefano
>
>
> Main changes in v2:
> - add a note about the code coming from libxl in the commit m
On Wed, 27 Mar 2019, Julien Grall wrote:
> Clang understands the GCCism in use here, but still complains that sp is
> unitialised. In such cases, resort to the older versions of this code,
> which directly read sp into the temporary variable.
>
> Note that we still keep the GCCism in the default c
On Wed, 27 Mar 2019, Julien Grall wrote:
> Currently __cmpxchg_mb and __cmpxchg are only marked inline. The
> compiler is free to decide to not honor the inline. This will result to
> generate code use __bad_cmpxchg and lead a link failure.
>
> This was caught by Clang 8.0.
>
> Signed-off-by: Jul
On Wed, 27 Mar 2019, Julien Grall wrote:
> Clang 8.0 throws an error in the get_top_bit function:
>
> guest_walk.c:328:15: error: variable 'topbit' is used uninitialized
> whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
> else if ( is_64bit_domain(d) )
> ^~~~
On Wed, 27 Mar 2019, Julien Grall wrote:
> Clang is pickier than GCC for the register size in asm statement. It
> expects the register size to match the value size.
>
> The asm statement expects a 32-bit (resp. 64-bit) value on Arm32
> (resp. Arm64) whereas the value is a boolean (Clang consider t
On Wed, 27 Mar 2019, Julien Grall wrote:
> Clang is pickier than GCC for the register size in asm statement. It
> expects the register size to match the value size.
>
> The asm statement expects a 32-bit (resp. 64-bit) value on Arm32
> (resp. Arm64) whereas the value is a boolean (Clang consider t
On Wed, 27 Mar 2019, Julien Grall wrote:
> Clang is pickier than GCC for the register size in asm statement. It
> expects the register size to match the value size.
>
> The instructions msr/mrs are expecting a 64-bit register. This means the
> implementation of the 32-bit helpers is not correct. T
On Wed, 27 Mar 2019, Julien Grall wrote:
> Hi,
>
> On 27/03/2019 19:03, Andrew Cooper wrote:
> > On 27/03/2019 18:45, Julien Grall wrote:
> >> Clang is pickier than GCC for the register size in asm statement. It
> >> expects
> >> the register size to match the value size.
> >>
> >> The instructio
On Wed, 27 Mar 2019, Julien Grall wrote:
> The header guard for xilinx-zynqmp-eemi.h is not followed by a #define
> of the macro used in the guard.
>
> Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
> ---
> xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h | 2 +-
> 1 file changed
flight 134768 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134768/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken in 134568
build-arm64-pvops
On Wed, Apr 17, 2019 at 1:15 AM Alexandru Stefan ISAILA
wrote:
>
>
>
> On 16.04.2019 18:07, George Dunlap wrote:
> > On 4/16/19 3:19 PM, Tamas K Lengyel wrote:
> >> On Tue, Apr 16, 2019 at 8:02 AM George Dunlap
> >> wrote:
> >>>
> >>> On 4/16/19 2:44 PM, Tamas K Lengyel wrote:
> On Tue, Apr
flight 134924 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134924/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
At the moment, create_xen_entries will only flush the TLBs if the full
range has successfully been updated. This may lead to leave unwanted
entries in the TLBs if we fail to update some entries.
Signed-off-by: Julien Grall
---
xen/arch/arm/mm.c | 20 +---
1 file changed, 13 inser
At the moment, TLB helpers are scattered in 2 headers: page.h (for
Xen TLB helpers) and tlbflush.h (for guest TLB helpers).
This patch is gathering all of them in tlbflush. This will help to
uniformize and update the logic of the helpers in follow-up patches.
Signed-off-by: Julien Grall
---
xen
All the TLBs helpers invalidate all the TLB entries are using the same
pattern:
DSB SY
TLBI ...
DSB SY
ISB
This pattern is following pattern recommended by the Arm Arm to ensure
visibility of updates to translation tables (see K10-5610 in ARM DDI
0487.A.k).
We have been a bit too
Hi all,
I spent the last few months looking at Xen boot and memory management to make
it simpler, more efficient and also more compliant in respect of the Arm Arm.
The full rework is quite consequence (already 150 patches and I haven't yet
finished!), so I am planning to send in smaller part over
The function flush_xen_text_tlb_local() has been misused and will result
to invalidate the instruction cache more than necessary.
For instance, there are no need to invalidate the instruction cache if
we are setting SCTLR_EL2.WXN.
There are effectively only one caller (i.e free_init_memory() woul
Now that we dropped flush_xen_text_tlb_local(), we have only one set of
helpers acting on Xen TLBs. There naming are quite confusing because the
TLB instructions used will act on both Data and Instruction TLBs.
Take the opportunity to rework the documentation that can be confusing
to read as they
The logic to set SCTLR_EL2.WXN is the same for the boot CPU and
non-boot CPU. So introduce a function to set the bit and clear TBLs.
This new function will help us to document and update the logic in a
single place.
Signed-off-by: Julien Grall
---
xen/arch/arm/mm.c | 22 +++---
TLB helpers in the headers tlbflush.h are currently quite confusing to
use the name may lead to think they are dealing with hypervisors TLBs
while they actually deal with guest TLBs.
Rename them to make it clearer that we are dealing with guest TLBs.
Signed-off-by: Julien Grall
---
xen/arch/arm
> On Apr 10, 2019, at 20:02, Chris Patterson wrote:
>
> For anyone looking at this... while I have tested and verified that
> both virtio-gpu and VirGL work, it's not without some hiccup.
>
> I have been running Ubuntu 19.04 with this config for a few days and I
> have had a couple VM freezes. '
Hi,
@Wei, @Ian: Do you have any input?
On 14/03/2019 07:55, Jan Beulich wrote:
On 13.03.19 at 18:30, wrote:
On 13/03/2019 15:20, Jan Beulich wrote:
On 18.02.19 at 12:35, wrote:
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -205,7 +205,7 @@ void getdomaininfo(struct domain *d, stru
On Wed, 17 Apr 2019, Julien Grall wrote:
> Hi,
>
> On 17/04/2019 18:12, Stefano Stabellini wrote:
> > On Tue, 16 Apr 2019, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 4/16/19 10:51 PM, Stefano Stabellini wrote:
> > > > On Mon, 28 Jan 2019, Julien Grall wrote:
> > > > > While SPIs are sha
Hi,
On 17/04/2019 18:12, Stefano Stabellini wrote:
On Tue, 16 Apr 2019, Julien Grall wrote:
Hi Stefano,
On 4/16/19 10:51 PM, Stefano Stabellini wrote:
On Mon, 28 Jan 2019, Julien Grall wrote:
While SPIs are shared between CPU, it is not possible to receive the
same interrupts on a different
On Tue, 16 Apr 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 4/16/19 10:51 PM, Stefano Stabellini wrote:
> > On Mon, 28 Jan 2019, Julien Grall wrote:
> > > While SPIs are shared between CPU, it is not possible to receive the
> > > same interrupts on a different CPU while the interrupt is in activ
(+ Andrew and Jan)
On 15/04/2019 23:42, Julien Grall wrote:
> Hi,
>
> On 4/15/19 11:25 PM, Stefano Stabellini wrote:
>> On Mon, 15 Apr 2019, Julien Grall wrote:
>>> Hi,
>>>
>>> On 4/15/19 10:55 PM, Stefano Stabellini wrote:
On Mon, 18 Feb 2019, Julien Grall wrote:
> mfn_to_pdx adds more
This avoids any possible problems with shells misinterpreting ! and is
consistent with the other recent changes replacing ! for negation
with ^.
Signed-off-by: Ian Jackson
---
mg-repro-setup | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/mg-repro-setup b/mg-repro-set
In October 2014, debian-installer was updated to honour `---' in the
way it previously honoured `--': #762007. If we use that instead,
we don't need to duplicate $gconsole any more.
This, effectively, reverts
db26f5825a21269d9218417a9ca40bc5d47755d2
ts-host-install: include console before *an
Firstly, change the smoke flight to use amd64, not i386.
Secondly, make the other flights have a mixture of i386 and amd64, not
just amd64.
It was always wrong to test only one guest architecture in the main
flights.
The context for changing the smoke flight is that there seems to be a
problem af
The Debian HVM tests are broken with 32-bit guests, due to bugs and
infelicities in stretch. This is blocking things. Fix it. I will
push this series to osstest pretest right away.
Ian Jackson (5):
debianhvm tests: Re-permute guest architecture
mg-repro-setup: Allow, and advertise, ^ for un
Signed-off-by: Ian Jackson
---
ts-debian-hvm-install | 8
1 file changed, 8 insertions(+)
diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index a01cfb2b..4deb443e 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -135,6 +135,14 @@ sub gcmdline (;$) {
pu
The Debian stretch i386 installer does not have Xen PV-on-HVM drivers.
When we run the HVM guest installer, it therefore sees /dev/sda (the
emulated IDE). But the booted system *has* the drivers and sees
/dev/xvda.
The Debian installer is supposed to put UUID= in the bootloader config
and so on i
Hi,
On 14/04/2019 18:50, Amit Singh Tomar wrote:
This patch adds earlyprintk support for Amlogic Meson SoC based
boards.
ATF[1] and U-boot[2] already initialize the UART for us. So no need to do it
again.
Tested With:
http://wiki.friendlyarm.com/wiki/index.php/NanoPi_K2
[1]:
https://githu
Hi,
On 16/04/2019 22:07, Stefano Stabellini wrote:
On Tue, 19 Mar 2019, Julien Grall wrote:
From: Julien Grall
We can optimize a bit the assembly code by combining the 2 instructions
in a single one. This likely not going to make the code faster, but
likely make easier to read the assembly.
Hi,
On 17/04/2019 15:59, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Current sentence is not entirely correct. Since SCIF0 interface is
applicable for Lager board, but is not applicable for all R-Car H2
based boards. For example, Stout board uses SCIFA0 interface.
Signed-off-by: Ol
Hi,
On 16/04/2019 22:09, Stefano Stabellini wrote:
On Tue, 19 Mar 2019, Julien Grall wrote:
The format %pd will already prefix the domain ID with 'd'. So avoid to
prefix with 'Dom'.
Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
Thank you! I have pushed to my branch next-4.13 f
On Sat, Apr 13, 2019 at 12:14:14AM +0800, Pu Wen wrote:
> On 2019/4/5 15:50, Jan Beulich wrote:
> > On 04.04.19 at 18:39, wrote:
> > > On 2019/4/4 22:07, Andrew Cooper wrote:
> > > > This needs the following hunk folding in
> > > > which can be done on commit to avoid sending yet another version.
From: Oleksandr Tyshchenko
Extend early prink code to be able to handle other SCIF(X)
compatible interfaces as well. These interfaces have lot in common,
but mostly differ in offsets and bits for some registers.
Introduce "EARLY_PRINTK_VERSION" config option to choose which
interface version sho
From: Oleksandr Tyshchenko
Hi, all.
The purpose of this patch series is to add required support to be able to run
Xen on Renesas Stout board [1] which uses SCIFA compatible UART as a console
interface.
Actually Xen already has support for SCIF compatible UARTs which are used on
Renesas Lager (R
From: Oleksandr Tyshchenko
This patch makes possible to use existing early prink code
for Renesas "Stout" board based on R-Car H2 SoC (SCIFA).
The "EARLY_PRINTK_VERSION" for that board should be 'A':
CONFIG_EARLY_PRINTK=scif,0xe6c4,A
Signed-off-by: Oleksandr Tyshchenko
CC: Julien Grall
-
From: Oleksandr Tyshchenko
For the driver to be able to handle SCIFA interface as well,
this patch just adds the following:
- SCIFA related macros
- New element in "port_params" array to keep SCIFA specific things
- SCIFA compatible string
This patch makes possible to use existing driver for Ren
From: Oleksandr Tyshchenko
Current sentence is not entirely correct. Since SCIF0 interface is
applicable for Lager board, but is not applicable for all R-Car H2
based boards. For example, Stout board uses SCIFA0 interface.
Signed-off-by: Oleksandr Tyshchenko
Acked-by: Julien Grall
---
docs/mi
From: Oleksandr Tyshchenko
Extend driver to be able to handle other SCIF(X) compatible
interfaces as well. These interfaces have lot in common,
but mostly differ in offsets and bits for some registers.
For example, the main difference between SCIF and SCIFA interfaces
from "scif-uart" driver's p
On Wed, Apr 17, 2019 at 02:44:21PM +0200, Juergen Gross wrote:
> On 17/04/2019 13:53, Andrew Cooper wrote:
> > On 17/04/2019 12:43, Juergen Gross wrote:
> >> On 17/04/2019 13:26, Wei Liu wrote:
> >>> On Wed, Apr 17, 2019 at 12:23:29PM +0100, Andrew Cooper wrote:
> On 17/04/2019 12:16, Wei Liu
flight 134763 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134763/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken in 134642
build-arm
flight 134914 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134914/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xen-freebsd 5 host-install(5) fail REGR. vs. 134811
build-amd64-free
i...@xenbits.xen.org writes ("[adhoc test] 134864: trouble:
blocked/broken/pass"):
> [adhoc commission-arndale] <2testing.git (HEAD detached at origin/pretest)
> /dev/pts/41>
> harness 689d27f: ts-host-install: Do not force MAC address of Xen vifs
> 134864: trouble: blocked/broken/pass
>
> fligh
flight 134916 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134916/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
On 17/04/2019 13:53, Andrew Cooper wrote:
> On 17/04/2019 12:43, Juergen Gross wrote:
>> On 17/04/2019 13:26, Wei Liu wrote:
>>> On Wed, Apr 17, 2019 at 12:23:29PM +0100, Andrew Cooper wrote:
On 17/04/2019 12:16, Wei Liu wrote:
> On Wed, Apr 17, 2019 at 12:15:04PM +0100, Andrew Cooper wrot
On Wed, Apr 17, 2019 at 11:08:40AM +0100, Ian Jackson wrote:
> Firstly, change the smoke flight to use amd64, not i386.
> Secondly, make the other flights have a mixture of i386 and amd64, not
> just amd64.
>
> It was always wrong to test only one guest architecture in the main
> flights.
>
> The
On Tue, Apr 16, 2019 at 12:50:43PM +0200, Roger Pau Monné wrote:
> Adding the Linux Xen maintainers, in case they can provide some insight.
>
> On Mon, Apr 15, 2019 at 03:27:43PM -0700, PGNet Dev wrote:
> > ref: from chat in #xen
> >
> > [08:53] pgnd: would be good to send an email so we can
On 17/04/2019 12:43, Juergen Gross wrote:
> On 17/04/2019 13:26, Wei Liu wrote:
>> On Wed, Apr 17, 2019 at 12:23:29PM +0100, Andrew Cooper wrote:
>>> On 17/04/2019 12:16, Wei Liu wrote:
On Wed, Apr 17, 2019 at 12:15:04PM +0100, Andrew Cooper wrote:
> On 17/04/2019 12:03, Wei Liu wrote:
>>>
On 17/04/2019 13:26, Wei Liu wrote:
> On Wed, Apr 17, 2019 at 12:23:29PM +0100, Andrew Cooper wrote:
>> On 17/04/2019 12:16, Wei Liu wrote:
>>> On Wed, Apr 17, 2019 at 12:15:04PM +0100, Andrew Cooper wrote:
On 17/04/2019 12:03, Wei Liu wrote:
> On Wed, Apr 17, 2019 at 11:58:49AM +0100, And
On Mon, Apr 15, 2019 at 05:28:08PM +0100, Ian Jackson wrote:
> In d290e325179ccee966cd679d0fed48be6f4cc1b7
> "build system: don't let install-stubdom depend on install-tools"
> the dependency of install-stubdom on install-tools was removed.
>
> However, this was not correct. stubdom/Makefile c
On Wed, Apr 17, 2019 at 12:23:29PM +0100, Andrew Cooper wrote:
> On 17/04/2019 12:16, Wei Liu wrote:
> > On Wed, Apr 17, 2019 at 12:15:04PM +0100, Andrew Cooper wrote:
> >> On 17/04/2019 12:03, Wei Liu wrote:
> >>> On Wed, Apr 17, 2019 at 11:58:49AM +0100, Andrew Cooper wrote:
> On 17/04/2019
On 17/04/2019 12:16, Wei Liu wrote:
> On Wed, Apr 17, 2019 at 12:15:04PM +0100, Andrew Cooper wrote:
>> On 17/04/2019 12:03, Wei Liu wrote:
>>> On Wed, Apr 17, 2019 at 11:58:49AM +0100, Andrew Cooper wrote:
On 17/04/2019 11:57, Wei Liu wrote:
> On Wed, Apr 17, 2019 at 11:44:36AM +0100, And
On Wed, Apr 17, 2019 at 12:15:04PM +0100, Andrew Cooper wrote:
> On 17/04/2019 12:03, Wei Liu wrote:
> > On Wed, Apr 17, 2019 at 11:58:49AM +0100, Andrew Cooper wrote:
> >> On 17/04/2019 11:57, Wei Liu wrote:
> >>> On Wed, Apr 17, 2019 at 11:44:36AM +0100, Andrew Cooper wrote:
> On 17/04/2019
On 17/04/2019 12:03, Wei Liu wrote:
> On Wed, Apr 17, 2019 at 11:58:49AM +0100, Andrew Cooper wrote:
>> On 17/04/2019 11:57, Wei Liu wrote:
>>> On Wed, Apr 17, 2019 at 11:44:36AM +0100, Andrew Cooper wrote:
On 17/04/2019 11:41, Wei Liu wrote:
> On Wed, Apr 17, 2019 at 10:56:57AM +0100, Wei
On Wed, Apr 17, 2019 at 11:58:49AM +0100, Andrew Cooper wrote:
> On 17/04/2019 11:57, Wei Liu wrote:
> > On Wed, Apr 17, 2019 at 11:44:36AM +0100, Andrew Cooper wrote:
> >> On 17/04/2019 11:41, Wei Liu wrote:
> >>> On Wed, Apr 17, 2019 at 10:56:57AM +0100, Wei Liu wrote:
> > Here's what i did h
On 17/04/2019 12:58, Andrew Cooper wrote:
> On 17/04/2019 11:57, Wei Liu wrote:
>> On Wed, Apr 17, 2019 at 11:44:36AM +0100, Andrew Cooper wrote:
>>> On 17/04/2019 11:41, Wei Liu wrote:
On Wed, Apr 17, 2019 at 10:56:57AM +0100, Wei Liu wrote:
>> Here's what i did having pulled the master a
On 17/04/2019 12:08, Ian Jackson wrote:
> Firstly, change the smoke flight to use amd64, not i386.
> Secondly, make the other flights have a mixture of i386 and amd64, not
> just amd64.
>
> It was always wrong to test only one guest architecture in the main
> flights.
>
> The context for changing
On 17/04/2019 11:57, Wei Liu wrote:
> On Wed, Apr 17, 2019 at 11:44:36AM +0100, Andrew Cooper wrote:
>> On 17/04/2019 11:41, Wei Liu wrote:
>>> On Wed, Apr 17, 2019 at 10:56:57AM +0100, Wei Liu wrote:
> Here's what i did having pulled the master at commit cb70a26
>
> tar xf /path/to/xen
On Wed, Apr 17, 2019 at 11:44:36AM +0100, Andrew Cooper wrote:
> On 17/04/2019 11:41, Wei Liu wrote:
> > On Wed, Apr 17, 2019 at 10:56:57AM +0100, Wei Liu wrote:
> >>> Here's what i did having pulled the master at commit cb70a26
> >>>
> >>> tar xf /path/to/xen-cb70a26.tar.gz
> >>>
> >>> cd xen-mast
On 17/04/2019 11:41, Wei Liu wrote:
> On Wed, Apr 17, 2019 at 10:56:57AM +0100, Wei Liu wrote:
>>> Here's what i did having pulled the master at commit cb70a26
>>>
>>> tar xf /path/to/xen-cb70a26.tar.gz
>>>
>>> cd xen-master/
>>>
>>> PYTHON=/usr/bin/python3 ./configure --prefix=/usr \
>>>--di
On Wed, Apr 17, 2019 at 10:56:57AM +0100, Wei Liu wrote:
> >
> > Here's what i did having pulled the master at commit cb70a26
> >
> > tar xf /path/to/xen-cb70a26.tar.gz
> >
> > cd xen-master/
> >
> > PYTHON=/usr/bin/python3 ./configure --prefix=/usr \
> >--disable-seabios \
> >--dis
flight 134758 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134758/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken in 134634
build-arm64
Firstly, change the smoke flight to use amd64, not i386.
Secondly, make the other flights have a mixture of i386 and amd64, not
just amd64.
It was always wrong to test only one guest architecture in the main
flights.
The context for changing the smoke flight is that there seems to be a
problem af
On Tue, Apr 16, 2019 at 09:28:01PM +0800, Kevin Buckley wrote:
> On Mon, 15 Apr 2019 at 17:24, Wei Liu wrote:
> >
> > On Sat, Apr 13, 2019 at 11:17:48AM +0800, Kevin Buckley wrote:
> > > On Thu, 11 Apr 2019 at 18:29, Wei Liu wrote:
> > > >
> > > > ...
> > > > Sure. I will write a patch.
> > > >
>
flight 134913 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134913/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
coverity-amd647 coverity-upload fail REGR. vs. 133615
version t
flight 134910 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134910/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
Hi,
On 16/04/2019 23:43, Stefano Stabellini wrote:
On Fri, 29 Mar 2019, Julien Grall wrote:
On 28/03/2019 11:27, Artem Mygaiev wrote:
Hi Julien,
Hi Artem,
On Wed, 2019-03-27 at 18:45 +, Julien Grall wrote:
Hi all,
This series adds support to build Xen Arm with clang. This series was
On 17/04/2019 09:02, Amit Tomer wrote:
Hello,
Hi,
On Fri, Mar 22, 2019 at 5:05 PM Amit Tomer wrote:
Hi,
I am wondering if you had time to bisect the issue?
We are releasing Xen 4.12 soon so we need to make the decision whether this
should be fixed after (and backport it) or before.
D
flight 84005 distros-debian-squeeze real [real]
http://osstest.xensource.com/osstest/logs/84005/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
Hello,
On Fri, Mar 22, 2019 at 5:05 PM Amit Tomer wrote:
>
> Hi,
>
>
> > I am wondering if you had time to bisect the issue?
> >
> > We are releasing Xen 4.12 soon so we need to make the decision whether this
> > should be fixed after (and backport it) or before.
Don't see this crash if I chose
On 16.04.2019 18:07, George Dunlap wrote:
> On 4/16/19 3:19 PM, Tamas K Lengyel wrote:
>> On Tue, Apr 16, 2019 at 8:02 AM George Dunlap
>> wrote:
>>>
>>> On 4/16/19 2:44 PM, Tamas K Lengyel wrote:
On Tue, Apr 16, 2019 at 2:45 AM Alexandru Stefan ISAILA
wrote:
>
> The code for
93 matches
Mail list logo
