flight 136343 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136343/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 15 guest-saverestorefail REGR. vs. 136309
flight 136217 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136217/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-examine 11 examine-serial/bootloaderfail like 135997
test-amd64-i386-xl-pvshim12
Hi all
Fill buffers, load ports are shared between threads on the same physical core.
We need to run more than one vm on the same physical core.
Is there any complete mitigation for environments utilizing SMT?
___
Xen-devel mailing list
flight 136330 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136330/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 15 guest-saverestorefail REGR. vs. 136309
The pull request you sent on Wed, 15 May 2019 20:38:50 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.2b-rc1-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5fd09ba68297c967f5ba6bea9c3b444d34f80ee5
Thank you!
--
Deet-doot-dot,
flight 136213 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136213/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 132889
Signed-off-by: Alistair Francis
---
config.sub | 2522 ++--
1 file changed, 1269 insertions(+), 1253 deletions(-)
diff --git a/config.sub b/config.sub
index 6205f8423d..f53af5a2da 100755
--- a/config.sub
+++ b/config.sub
@@ -1,36 +1,31 @@
#!
Include lib.h to ensure that ASSERT() is defined.
Signed-off-by: Alistair Francis
---
xen/include/xen/rwlock.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/include/xen/rwlock.h b/xen/include/xen/rwlock.h
index 35657c56c4..131537348e 100644
--- a/xen/include/xen/rwlock.h
+++
Make the asm/vpl011.h dependent on the ARM architecture.
Signed-off-by: Alistair Francis
---
xen/drivers/char/console.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 9bbcb0f57a..f840d999bc 100644
---
flight 136327 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136327/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 15 guest-saverestorefail REGR. vs. 136309
Following the recent discussion, we had on IRC and the action I had in
the March community call, this file provides a file format that
enables writing an automated test to check whether files are out of sync.
Unlike in the IRC discussion, which suggested a single line for all
information, I
flight 136317 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136317/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 15 guest-saverestorefail REGR. vs. 136309
The condition of the BUG_ON() in advance_pc() is pretty wrong because
the bits [26:25] and [15:10] have a different meaning between AArch32
and AArch64 state.
On AArch32, they are used to store PSTATE.IT. On AArch64, they are RES0
or used for new feature (e.g ARMv8.0-SSBS, ARMv8.5-BTI).
This
On 15/05/2019 20:58, Julien Grall wrote:
> Hi all,
>
> It looks like the structures vcpu_guest_core_regs and
> vcpu_guest_context does not correctly reflect the AArch64 state. For
> instance, all Arm64 system registers (e.g sctlr, cpsr, spsr_el1)
> should be 64-bit wide not 32-bit wide.
>
> On
Hi all,
It looks like the structures vcpu_guest_core_regs and vcpu_guest_context
does not correctly reflect the AArch64 state. For instance, all Arm64
system registers (e.g sctlr, cpsr, spsr_el1) should be 64-bit wide not
32-bit wide.
On ARMv8.0, some of the registers have only the low
flight 136184 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136184/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken in 134594
build-arm64
flight 136197 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136197/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 18 leak-check/check fail REGR. vs. 136021
Tests which did not
flight 136211 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136211/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 135251
build-arm64-xsm
Hello Jan,
Jan Beulich writes:
On 14.05.19 at 20:45, wrote:
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -269,6 +269,9 @@ kconfig := silentoldconfig oldconfig config menuconfig
>> defconfig \
>> $(kconfig):
>> $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH)
On 03.05.19 20:02, Amit Singh Tomar wrote:
Hi, Amit
XEN should not forward PPIs to Dom0 as it only support SPIs.
One of solution to this problem is to skip any device that
uses PPI source completely while building domain itself.
This patch goes through all the interrupt sources of device and
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.2b-rc1-tag
xen: fixes and features for 5.2-rc1
It contains:
- some minor cleanups
- 2 small corrections for Xen on ARM
- 2 fixes for Xen PVH guest support
- a patch for a new
flight 136181 qemu-upstream-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136181/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken in
flight 136309 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136309/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 136177 qemu-upstream-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136177/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail REGR. vs. 133734
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-qemuu-nested-intel
testid xen-boot
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
A hard to trigger race with another unrelated systemd service and
xenstored.service unveiled a bug in the way how xenstored is launched
with systemd.
launch-xenstore may start either a daemon or a domain. In case a domain
is used, systemd-notify was called. If another service triggered a
restart
On 01.05.19 00:02, Stefano Stabellini wrote:
Hi, Stefano
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 140f979..9f62ead 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -928,6 +928,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
u_domctl)
>>> On 08.05.19 at 15:24, wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -427,6 +427,7 @@ static struct pci_dev *alloc_pdev(struct pci_seg *pseg,
> u8 bus, u8 devfn)
>
> check_pdev(pdev);
> apply_quirks(pdev);
> +iommu_group_assign(pdev);
branch xen-unstable
xenbranch xen-unstable
job build-i386
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem
>>> On 08.05.19 at 15:24, wrote:
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -655,6 +655,82 @@ static void iommu_dump_p2m_table(unsigned char key)
> }
> }
>
> +#ifdef CONFIG_HAS_PCI
> +
> +struct iommu_group {
> +unsigned int id;
> +
flight 136304 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136304/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Wei Liu writes ("[Xen-devel] [PATCH 0/2] Drop blktap2 from xen"):
> Wei Liu (2):
> tools: remove blktap2 related code and documentation
> Drop blktap2
Both patches:
Acked-by: Ian Jackson
Ian.
___
Xen-devel mailing list
On 01.05.19 00:02, Stefano Stabellini wrote:
Hi, Stefano
diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index efb6ca9..6adfa55 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -52,7 +52,8 @@ static int map_range(unsigned long s, unsigned long e,
flight 136172 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136172/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit1 11 debian-fixup fail REGR. vs. 135988
On Wed, 15 May 2019, Daniel Kiper wrote:
> FYI, another Xen Dom0 boot issue on Fedora...
>
> Please take a look at [1]. This will break Xen Dom0 boot due to lack of
> support for multiboot, multiboot2, module, and module2 commands. If we
> care then this has to be fixed somehow...
This bit
On Wed, May 15, 2019 at 01:07:03PM +0100, Andrew Cooper wrote:
> On 15/05/2019 12:40, Anthony PERARD wrote:
> > This was probably useful to load ELF Note, but now ELF notes
> > "should live in a PT_NOTE segment" (elfnote.h).
> >
> > With notes living in segment, there are no need for sections, so
On Wed, May 15, 2019 at 01:07:03PM +0100, Andrew Cooper wrote:
> On 15/05/2019 12:40, Anthony PERARD wrote:
> > This was probably useful to load ELF Note, but now ELF notes
> > "should live in a PT_NOTE segment" (elfnote.h).
> >
> > With notes living in segment, there are no need for sections, so
On 15/05/2019 12:40, Anthony PERARD wrote:
> This was probably useful to load ELF Note, but now ELF notes
> "should live in a PT_NOTE segment" (elfnote.h).
>
> With notes living in segment, there are no need for sections, so there
> is nothing to be stored in the shstrtab.
>
> This patch would
On Wed, May 15, 2019 at 12:40:15PM +0100, Anthony PERARD wrote:
> This was probably useful to load ELF Note, but now ELF notes
> "should live in a PT_NOTE segment" (elfnote.h).
>
> With notes living in segment, there are no need for sections, so there
> is nothing to be stored in the shstrtab.
>
>>> On 15.05.19 at 10:44, wrote:
> On 14.05.19 16:49, Jan Beulich wrote:
>> If this was a concern only for newly written code, this would be fine.
>> But you need to make sure all existing code also continues to work
>> with whatever new interface you implement.
>
> And that is one more reason
On 15/05/2019 12:50, Jan Beulich wrote:
On 15.05.19 at 12:17, wrote:
>> On 15/05/2019 09:23, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -6624,6 +6624,8 @@ x86_emulate(
>>> case X86EMUL_OPC_VEX_66(0x0f,
>>> On 15.05.19 at 12:17, wrote:
> On 15/05/2019 09:23, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -6624,6 +6624,8 @@ x86_emulate(
>> case X86EMUL_OPC_VEX_66(0x0f, 0xf3): /* vpsllq xmm/m128,{x,y}mm,{x,y}mm
>> */
This was probably useful to load ELF Note, but now ELF notes
"should live in a PT_NOTE segment" (elfnote.h).
With notes living in segment, there are no need for sections, so there
is nothing to be stored in the shstrtab.
This patch would allow to write a simpler ELF header for an OVMF blob
On 5/14/19 3:22 PM, Wei Liu wrote:
> The same sentence is repeated in the next paragraph.
>
> Signed-off-by: Wei Liu
Acked-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 5/14/19 3:22 PM, Wei Liu wrote:
> The directory is created by Visual Studio Code editor to store its
> local state.
>
> Signed-off-by: Wei Liu
Acked-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
Hey,
FYI, another Xen Dom0 boot issue on Fedora...
Please take a look at [1]. This will break Xen Dom0 boot due to lack of
support for multiboot, multiboot2, module, and module2 commands. If we
care then this has to be fixed somehow...
Again, I can coordinate work and review patches but I
On 14/05/2019 17:03, Lukas Jünger wrote:
Hello all,
Hello,
Thank you for the report.
Please try to CC the maintainers of the code (in this case Stefano and I) when
asking a question. So your e-mail don't get lost in the noise of xen-devel.
in the function advance_pc in
flight 136180 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136180/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 96ef5a8e30a8da33eaab09f13cc8d752342717a5
baseline version:
ovmf
From: Jan Beulich
... as they don't work as intended with -fPIC.
I did prefer them over *_end ones at the time because older gcc would
cause .L* symbols to be public, due to issuing .globl for all
referenced externals. And labels at the end of instructions collide
with the ones at the start of
On Wed, May 15, 2019 at 12:34:07PM +0200, Roger Pau Monné wrote:
> On Wed, May 15, 2019 at 10:24:44AM +, osstest service owner wrote:
> > flight 136291 xen-unstable-smoke real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/136291/
> >
> > Regressions :-(
> >
> > Tests which did
On Wed, May 15, 2019 at 10:24:44AM +, osstest service owner wrote:
> flight 136291 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/136291/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>
Hi Andrii,
On 15/05/2019 10:04, Andrii Anisov wrote:
On 14.05.19 16:49, Julien Grall wrote:
You have to keep in mind that existing OS have to run on newer Xen without any
modification.
As I just written to Jan, it is one more reason to keep those interfaces living
in parallel and do not
flight 136291 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136291/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 136179
Tests which
Am Mon, 13 May 2019 17:20:05 +0200
schrieb Roger Pau Monné :
> Let me know if that works for you and I will submit it formally.
Yes, it works for me. Thanks.
Olaf
pgp_Q1jrXfL2b.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailing
On 15/05/2019 09:23, Jan Beulich wrote:
> Their pre-AVX512 incarnations have clearly been overlooked during much
> earlier work. Their memory access pattern is entirely standard, so no
> specific tests get added to the harness.
>
> Reported-by: Razvan Cojocaru
> Signed-off-by: Jan Beulich
>
>
On 15/05/2019 11:09, Roger Pau Monné wrote:
> On Wed, May 15, 2019 at 10:59:20AM +0100, Andrew Cooper wrote:
>> On 15/05/2019 10:44, Roger Pau Monné wrote:
>>> On Wed, May 15, 2019 at 02:44:07AM -0600, Jan Beulich wrote:
Log information likely relevant for understanding why the BUG()s were
On Wed, May 15, 2019 at 11:07:23AM +0100, Ian Jackson wrote:
> This branch is supposed to be suitable for all versions of Xen.
> Conversely, older versions of seabios do not build on newer
> compilers (as provided, eg, in stretch).
>
> So, for "branches" other than xen-unstable and
On Wed, May 15, 2019 at 10:59:20AM +0100, Andrew Cooper wrote:
> On 15/05/2019 10:44, Roger Pau Monné wrote:
> > On Wed, May 15, 2019 at 02:44:07AM -0600, Jan Beulich wrote:
> >> Log information likely relevant for understanding why the BUG()s were
> > Why not use panic instead of printk + BUG?
>
This branch is supposed to be suitable for all versions of Xen.
Conversely, older versions of seabios do not build on newer
compilers (as provided, eg, in stretch).
So, for "branches" other than xen-unstable and xen-unstable-smoke, use
the usual "determine_version" machinery, which will select
On 15/05/2019 09:44, Jan Beulich wrote:
> Log information likely relevant for understanding why the BUG()s were
> triggering.
>
> Requested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
On 15/05/2019 10:44, Roger Pau Monné wrote:
> On Wed, May 15, 2019 at 02:44:07AM -0600, Jan Beulich wrote:
>> Log information likely relevant for understanding why the BUG()s were
> Why not use panic instead of printk + BUG?
Because the backtrace is useful a lot of the time.
~Andrew
On Wed, May 15, 2019 at 10:49:58AM +0100, Andrew Cooper wrote:
> On 15/05/2019 10:47, Wei Liu wrote:
> > On Tue, May 14, 2019 at 08:43:25AM +, Eslam Elnikety wrote:
> >> Each HVM guest currently gets a vkbd frontend/backend pair (c/s
> >> ebbd2561b4c).
> >> This consumes host resources
On 15/05/2019 10:47, Wei Liu wrote:
> On Tue, May 14, 2019 at 08:43:25AM +, Eslam Elnikety wrote:
>> Each HVM guest currently gets a vkbd frontend/backend pair (c/s ebbd2561b4c).
>> This consumes host resources unnecessarily for guests that have no use for
>> vkbd. Make this behaviour tunable
On Tue, May 14, 2019 at 08:43:25AM +, Eslam Elnikety wrote:
> Each HVM guest currently gets a vkbd frontend/backend pair (c/s ebbd2561b4c).
> This consumes host resources unnecessarily for guests that have no use for
> vkbd. Make this behaviour tunable to allow an administrator to choose. The
On Wed, May 15, 2019 at 02:44:07AM -0600, Jan Beulich wrote:
> Log information likely relevant for understanding why the BUG()s were
Why not use panic instead of printk + BUG?
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 15.05.2019 11:23, Jan Beulich wrote:
> Their pre-AVX512 incarnations have clearly been overlooked during much
> earlier work. Their memory access pattern is entirely standard, so no
> specific tests get added to the harness.
>
> Reported-by: Razvan Cojocaru
> Signed-off-by: Jan Beulich
On Wed, May 15, 2019 at 02:44:07AM -0600, Jan Beulich wrote:
> Log information likely relevant for understanding why the BUG()s were
> triggering.
>
> Requested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
>
Reviewed-by: Wei Liu
___
Xen-devel
On Wed, May 15, 2019 at 09:55:30AM +0100, George Dunlap wrote:
> On 5/15/19 7:53 AM, Wei Liu wrote:
> > On Tue, May 14, 2019 at 07:13:57PM +0300, Razvan Cojocaru wrote:
> >> All its callers live inside #ifdef CONFIG_HVM sections.
> >>
> >> Signed-off-by: Razvan Cojocaru
> >
> > Reviewed-by: Wei
Am Tue, 14 May 2019 15:32:27 +0100
schrieb Wei Liu :
> Olaf, if you can provide me with an updated version of the commit
> message I can fold that in while committing. No need to resend this
> patch.
Maybe just append this paragraph?
The upcoming change needs a full libxl_domain_config, and the
On Wed, May 08, 2019 at 02:24:03PM +0100, Paul Durrant wrote:
> ... using the new iommu_group infrastructure.
>
> Because 'sibling' devices are now members of the same iommu_group,
> implement the domctl by looking up the relevant iommu_group and walking
> the membership list.
>
> Signed-off-by:
On 14.05.19 16:49, Julien Grall wrote:
You have to keep in mind that existing OS have to run on newer Xen without any
modification.
As I just written to Jan, it is one more reason to keep those interfaces living
in parallel and do not mix their implementation.
The existing hypercall
On 5/15/19 7:53 AM, Wei Liu wrote:
> On Tue, May 14, 2019 at 07:13:57PM +0300, Razvan Cojocaru wrote:
>> All its callers live inside #ifdef CONFIG_HVM sections.
>>
>> Signed-off-by: Razvan Cojocaru
>
> Reviewed-by: Wei Liu
Acked-by: George Dunlap
On Wed, May 08, 2019 at 02:24:02PM +0100, Paul Durrant wrote:
> Some devices may share a single PCIe initiator id, e.g. if they are actually
> legacy PCI devices behind a bridge, and hence DMA from such devices will
> be subject to the same address translation in the IOMMU. Hence these devices
>
Hello Jan,
On 14.05.19 16:49, Jan Beulich wrote:
If this was a concern only for newly written code, this would be fine.
But you need to make sure all existing code also continues to work
with whatever new interface you implement.
And that is one more reason why I tend to introduce the new
Log information likely relevant for understanding why the BUG()s were
triggering.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -984,7 +984,15 @@ static struct page_info *alloc_heap_page
for ( i = 0; i < (1 << order);
Their pre-AVX512 incarnations have clearly been overlooked during much
earlier work. Their memory access pattern is entirely standard, so no
specific tests get added to the harness.
Reported-by: Razvan Cojocaru
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++
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
flight 136280 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136280/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 136179
Tests which
>>> On 14.05.19 at 20:45, wrote:
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -269,6 +269,9 @@ kconfig := silentoldconfig oldconfig config menuconfig
> defconfig \
> $(kconfig):
> $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH)
> SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)"
flight 136171 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136171/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313
build-armhf-pvops
On Tue, May 14, 2019 at 07:13:57PM +0300, Razvan Cojocaru wrote:
> All its callers live inside #ifdef CONFIG_HVM sections.
>
> Signed-off-by: Razvan Cojocaru
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
flight 136176 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136176/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 5264341e4fb0bd697254160d79b168f740557abb
baseline version:
xtf
>>> On 14.05.19 at 18:19, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 13 May 2019 09:11
>> To: Paul Durrant
>> Cc: Brian Woods ; Suravee Suthikulpanit
> ; Julien
>> Grall ; Andrew Cooper ;
>> Roger
> Pau Monne
>> ; Wei Liu ; Kevin Tian
> ;
>>> On 14.05.19 at 18:13, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 13 May 2019 08:36
>> To: Paul Durrant
>> Cc: Brian Woods ; Suravee Suthikulpanit
> ; Andrew
>> Cooper ; Roger Pau Monne ;
>> Wei
> Liu
>> ; Kevin Tian ; xen-devel
>
>>
84 matches
Mail list logo
