Hi Marek,
On 21.03.22 23:26, Marek Marczykowski-Górecki wrote:
Hi,
After updating from 5.14.15 dom0 kernel to 5.16.13 I started getting
this on resume from S3:
[ 88.082751] ACPI: PM: Low-level resume complete
[ 88.087933] ACPI: EC: EC started
[ 88.091464] ACPI: PM: Restoring platform NVS
This patch series aims to do the first step towards linker scripts
synchronization. Linker scripts for arm and x86 share a lot of common
sections and in order to make the process of changing/improving/syncing
them, these sections shall be defined in just one place.
The first patch creates an empty
Both x86 and arm linker scripts share quite a lot of common content.
It is difficult to keep syncing them up, thus introduce a new header
in include/xen called xen.lds.h to store the internals mutual to all
the linker scripts.
Include this header in linker scripts for x86 and arm.
This patch serve
Populate header file xen.lds.h with the first portion of macros storing
constructs common to x86 and arm linker scripts. Replace the original
constructs with these helpers.
No functional improvements to x86 linker script.
Making use of common macros improves arm linker script with:
-explicit list
flight 168770 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168770/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi Julien,
> On 21 Mar 2022, at 18:44, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 21/03/2022 17:19, Bertrand Marquis wrote:
>>> On 21 Mar 2022, at 17:36, Julien Grall wrote:
So I don’t know why on x86 we must have cpu0 in cpupool0, maybe x86
maintainer have more knowledge about tha
Hi Julien,
> On 22 Mar 2022, at 09:35, Bertrand Marquis wrote:
>
> Hi Julien,
>
>> On 21 Mar 2022, at 18:44, Julien Grall wrote:
>>
>> Hi Bertrand,
>>
>> On 21/03/2022 17:19, Bertrand Marquis wrote:
On 21 Mar 2022, at 17:36, Julien Grall wrote:
> So I don’t know why on x86 we must
>> +- cpupool-sched (optional)
>> +
>> +Must be a string having the name of a Xen scheduler, it has no effect
>> when
>> +used in conjunction of a cpupool-id equal to zero, in that case the
>> +default Xen scheduler is selected (sched=<...> boot argument).
>> +Check the sched=<...
Hi,
On 22/03/2022 08:47, Bertrand Marquis wrote:
Hi Julien,
On 22 Mar 2022, at 09:35, Bertrand Marquis wrote:
Hi Julien,
On 21 Mar 2022, at 18:44, Julien Grall wrote:
Hi Bertrand,
On 21/03/2022 17:19, Bertrand Marquis wrote:
On 21 Mar 2022, at 17:36, Julien Grall wrote:
So I don’t kn
Hi Julien,
Il giorno mer 9 mar 2022 alle ore 20:09 Julien Grall ha
scritto:
> Hi,
>
> On 04/03/2022 17:46, Marco Solieri wrote:
> > From: Luca Miccio
> >
> > Add three new bootargs allowing configuration of cache coloring support
> > for Xen:
>
> I would prefer if documentation of each command
Hi Julien,
> On 22 Mar 2022, at 10:16, Julien Grall wrote:
>
> Hi,
>
> On 22/03/2022 08:47, Bertrand Marquis wrote:
>> Hi Julien,
>>> On 22 Mar 2022, at 09:35, Bertrand Marquis wrote:
>>>
>>> Hi Julien,
>>>
On 21 Mar 2022, at 18:44, Julien Grall wrote:
Hi Bertrand,
>>>
>>>
>>> Can you document why this is necessary on x86 but not on other
>>> architectures?
>> Hi Julien,
>> I received the warning by Juergen here:
>> https://patchwork.kernel.org/comment/24740762/ that at least on x86 there
>> could be
>> some problems if cpu0 is not in cpupool0, I tested it on
flight 168763 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168763/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168755
test-armhf-armhf-libvirt 16 save
On Tue, 15 Mar 2022 15:41:56 +0100
Markus Armbruster wrote:
> g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer,
> for two reasons. One, it catches multiplication overflowing size_t.
> Two, it returns T * rather than void *, which lets the compiler catch
> more type errors.
>
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.build-system-xen-v10
v10:
Mainly a rebase (changes needed in patches 1 and 3).
One comment change in patch 1.
v9:
One new patch (patch 3).
Otherwise, detailed change log
We need to differentiate between source files and generated/built
files. We will be replacing $(BASEDIR) by $(objtree) for files that
are generated.
Signed-off-by: Anthony PERARD
Acked-by: Jan Beulich
---
Notes:
v9:
- acked
v8:
- rebased
xen/Rules.mk| 2 +
Rather than preparing the efi source file, we will make the symbolic
link as needed from the build location.
The `ln` command is run every time to allow to update the link in case
the source tree change location.
This patch also introduce "efi-common.mk" which allow to reuse the
common make instr
Listing public headers when out-of-tree build are involved becomes
more annoying where every path to every headers needs to start with
"$(srctree)/$(src)", or $(wildcard ) will not work. This means more
repetition. ( "$(srcdir)" is a shortcut for "$(srctree)/$(src)" )
This patch attempt to reduce
$(srctree) is a better description for the source directory than
$(BASEDIR) that has been used for both source and build directory
(which where the same).
This adds $(srctree) to a few path where make's VPATH=$(srctree) won't
apply. And replace $(BASEDIR) by $(srctree).
Introduce "$(srcdir)" as a
When doing an out-of-tree build, and thus setting VPATH,
GNU Make 3.81 on Ubuntu Trusty complains about Circular dependency of
include/Makefile and include/xlat.lst and drop them. The build fails
later due to headers malformed.
This might be due to bug #13529
"Incorrect circular dependancy"
Reorganize a bit the Makefile ahead of patch
"build: adding out-of-tree support to the xen build"
We are going to want to calculate all the $(*srctree) and $(*objtree)
once, when we can calculate them. This can happen within the
"$(root-make-done)" guard, in an out-of-tree build scenario, so move
This implement out-of-tree support, there's two ways to create an
out-of-tree build tree (after that, `make` in that new directory
works):
make O=build
mkdir build; cd build; make -f ../Makefile
also works with an absolute path for both.
This implementation only works if the source tree is
On 18/03/2022 18:26, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 17/03/2022 14:00, Ayan Kumar Halder wrote:
diff --git a/xen/arch/arm/include/asm/mmio.h
b/xen/arch/arm/include/asm/mmio.h
index ca259a79c2..79e64d9af8 100644
--- a/xen/arch/arm/include/asm/mmio.h
+++ b/xen/arch/arm/include/asm
flight 168774 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168774/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 22/03/2022 12:06, Ayan Kumar Halder wrote:
On 18/03/2022 18:26, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 17/03/2022 14:00, Ayan Kumar Halder wrote:
diff --git a/xen/arch/arm/include/asm/mmio.h
b/xen/arch/arm/include/asm/mmio.h
index ca259a79c2..79e64d9af8 100644
--- a/xen/arch/arm/i
flight 168769 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168769/
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
flight 168777 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168777/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi Ayan,
On 22/03/2022 12:38, Ayan Kumar Halder wrote:
On 22/03/2022 12:06, Ayan Kumar Halder wrote:
On 18/03/2022 18:26, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 17/03/2022 14:00, Ayan Kumar Halder wrote:
diff --git a/xen/arch/arm/include/asm/mmio.h
b/xen/arch/arm/include/asm/mmio.h
On Tue, Mar 15, 2022 at 03:41:53PM +0100, Markus Armbruster wrote:
> g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer,
> for two reasons. One, it catches multiplication overflowing size_t.
> Two, it returns T * rather than void *, which lets the compiler catch
> more type error
flight 168779 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168779/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi,
On 21/03/2022 22:07, Stefano Stabellini wrote:
On Mon, 21 Mar 2022, Julien Grall wrote:
This is the list of kernels that I tried and failed:
- Debian Buster
- Debian Bullseye
- vanilla 4.9
- vanilla 4.10
Does this mean you where using v4.{9,10}.0 rather than the stable branch?
Note that
Hi,
On 22/03/2022 09:52, Luca Fancellu wrote:
Can you document why this is necessary on x86 but not on other architectures?
Hi Julien,
I received the warning by Juergen here:
https://patchwork.kernel.org/comment/24740762/ that at least on x86 there could
be
some problems if cpu0 is not in cp
flight 168780 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168780/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Tue, Mar 22, 2022 at 08:12:53AM +0100, Juergen Gross wrote:
> Hi Marek,
>
> On 21.03.22 23:26, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > After updating from 5.14.15 dom0 kernel to 5.16.13 I started getting
> > this on resume from S3:
> >
> > [ 88.082751] ACPI: PM: Low-level resume c
Hello,
On 3/10/22 02:34, Juergen Gross wrote:
Now that the hypercall handlers are all being called directly instead
through a function vector, the "cf_check" attribute can be removed.
Signed-off-by: Juergen Gross
Tested-by: Téo Couprie Diaz
I tested the latest patch series on Armv8 on the
On 21/03/2022 21:12, Tamas K Lengyel wrote:
> During VM forking and resetting a failed vmentry has been observed due
> to the guest non-register state going out-of-sync with the guest register
> state. For example, a VM fork reset right after a STI instruction can trigger
> the failed entry. This i
flight 168765 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168765/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 8 xen-boot fail REGR. vs. 168712
Tests which did not succee
Now that x86'es check-endbr.sh script uses it, also make it available
consistently with other tool chain components.
Signed-off-by: Jan Beulich
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -10,6 +10,7 @@ endif
LD_LTO = $(CROSS_COMPILE)ld
endif
CPP= $(CC) -E
+ADDR2LINE = $(CRO
On Tue, Mar 22, 2022 at 11:11 AM Andrew Cooper
wrote:
>
> On 21/03/2022 21:12, Tamas K Lengyel wrote:
> > During VM forking and resetting a failed vmentry has been observed due
> > to the guest non-register state going out-of-sync with the guest register
> > state. For example, a VM fork reset rig
On Thu, Mar 10, 2022 at 08:34:16AM +0100, Juergen Gross wrote:
> diff --git a/xen/include/Makefile b/xen/include/Makefile
> index a3c2511f5f..b52a2da40c 100644
> --- a/xen/include/Makefile
> +++ b/xen/include/Makefile
> @@ -77,6 +77,18 @@ $(obj)/compat/xlat.h: $(addprefix
> $(obj)/compat/.xlat/,$(
flight 168783 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168783/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
is_xen_pmu() is taking the cpu number as parameter, but it is not using
it. Instead it just tests whether the Xen PMU initialization on the
current cpu did succeed. As this test is done by checking a percpu
pointer, preemption needs to be disabled in order to avoid switching
the cpu while doing the
On 22.03.22 16:31, Anthony PERARD wrote:
On Thu, Mar 10, 2022 at 08:34:16AM +0100, Juergen Gross wrote:
diff --git a/xen/include/Makefile b/xen/include/Makefile
index a3c2511f5f..b52a2da40c 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -77,6 +77,18 @@ $(obj)/compat/xlat.h: $(ad
flight 168778 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168778/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hi Julien,
On 22/03/2022 13:22, Julien Grall wrote:
Hi Ayan,
On 22/03/2022 12:38, Ayan Kumar Halder wrote:
On 22/03/2022 12:06, Ayan Kumar Halder wrote:
On 18/03/2022 18:26, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 17/03/2022 14:00, Ayan Kumar Halder wrote:
diff --git a/xen/arch/arm/i
flight 168768 linux-linus real [real]
flight 168782 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168768/
http://logs.test-lab.xenproject.org/osstest/logs/168782/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
Hi,
On 22/03/2022 16:16, Ayan Kumar Halder wrote:
On 22/03/2022 13:22, Julien Grall wrote:
Furthermore, I think try_fwd_ioserv() need to be adapted because the
function will use the fields SAS and SRT. From the Arm Arm they are
RES0, so while they are 0 today, we should not rely on this.
The
flight 168785 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168785/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
+ maintainer golang, libs, ocaml, python bindings
> On 18 Mar 2022, at 16:18, Julien Grall wrote:
>
> Hi,
>
> On 18/03/2022 15:25, Luca Fancellu wrote:
>> Introduce domain-cpupool property of a xen,domain device tree node,
>> that specifies the cpupool device tree handle of a xen,cpupool node
On Tue, 22 Mar 2022, Luca Fancellu wrote:
> >> +- cpupool-sched (optional)
> >> +
> >> +Must be a string having the name of a Xen scheduler, it has no effect
> >> when
> >> +used in conjunction of a cpupool-id equal to zero, in that case the
> >> +default Xen scheduler is selected (sch
Add option to the fork memop to skip populating the fork with special pages.
These special pages are only necessary when setting up forks to be fully
functional with a toolstack. For short-lived forks where no toolstack is active
these pages are uneccesary.
Signed-off-by: Tamas K Lengyel
---
xen
Allow specify distinct parts of the fork VM to be reset. This is useful when a
fuzzing operation involves mapping in only a handful of pages that are known
ahead of time. Throwing these pages away just to be re-copied immediately is
expensive, thus allowing to specify partial resets can speed thing
For the duration of the fork memop set dom_cow as a placeholder parent. This
gets updated to the real parent when the fork operation completes, or to NULL
in case the fork failed. Doing this allows us to skip populating the physmap
with any entries until the fork operation successfully completes. C
flight 168788 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168788/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 3/22/22 11:50 AM, Juergen Gross wrote:
is_xen_pmu() is taking the cpu number as parameter, but it is not using
it. Instead it just tests whether the Xen PMU initialization on the
current cpu did succeed. As this test is done by checking a percpu
pointer, preemption needs to be disabled in or
Hi Juergen,
On 10/03/2022 07:34, Juergen Gross wrote:
do_physdev_op() prototypes on Arm and x86 differ in their return type,
so rename the Arm one in order to prepare using a common generated
header file.
Signed-off-by: Juergen Gross
Acked-by: Julien Grall
Cheers,
--
Julien Grall
Hi Juergen,
On 10/03/2022 07:34, Juergen Gross wrote:
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 351029f8b2..f9de1be43c 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1570,15 +1570,11 @@ int default_initialise_vcpu(struct vcpu *v,
XEN_GUEST_HANDLE_PARAM(void) a
Hi Juergen,
On 10/03/2022 07:34, Juergen Gross wrote:
Instead of including asm/hypercall.h always use xen/hypercall.h.
Additionally include xen/hypercall.h from all sources containing a
hypercall handler.
This prepares for generating the handlers' prototypes at build time.
Add a guard in asm/h
Hi Juergen,
On 10/03/2022 07:34, Juergen Gross wrote:
+table: pv32 pv64 hvm32hvm64arm
+set_trap_table compat do ---
+mmu_update do:1 do:1 ---
+set_gdt
Hi Juergen,
On 10/03/2022 07:34, Juergen Gross wrote:
Remove the hypercall handler's prototypes in the related header files
and use the generated ones instead.
Some handlers having been static before need to be made globally
visible.
Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
---
x
From: Stefano Stabellini
The first 32 bytes of zImage are NOPs. When CONFIG_EFI is enabled in the
kernel, certain versions of Linux will use an UNPREDICATABLE NOP
encoding, sometimes resulting in an unbootable kernel. Whether the
resulting kernel is bootable or not depends on the processor. See c
Hi all,
This small series adds a simple Xen + Dom0 boot arm32 test to gitlab-ci
using QEMU, similar to the existing tests for arm64 and x86.
Cheers,
Stefano
Stefano Stabellini (2):
gitlab-ci: add qemu-system-arm to the existing tests-artifacts container
gitlab-ci: add an ARM32 qemu-
From: Stefano Stabellini
Add qemu-system-arm to the existing test-artifacts qemu container (which
doesn't get build for every iteration but only updated once in a while.)
With qemu-system-arm available, we'll be able to run ARM32 tests.
This patch also bumps the QEMU version to v6.0.0 for both
Add a minimal ARM32 smoke test based on qemu-system-arm, as provided by
the test-artifacts qemu container. The minimal test simply boots Xen
(built from previous build stages) and Dom0.
The test needs a working kernel and minimal initrd for dom0. Instead of
building our own kernel and initrd, whic
On Mon, Jan 24, 2022 at 10:10:49AM +0100, Christoph Hellwig wrote:
> open code mpage_alloc in it's two callers and simplify the results
> because of the context:
>
> - __mpage_writepage always passes GFP_NOFS and can thus always sleep and
> will never get a NULL return from bio_alloc at all.
On Wed, Mar 23, 2022 at 6:19 AM Guenter Roeck wrote:
>
> On Mon, Jan 24, 2022 at 10:10:49AM +0100, Christoph Hellwig wrote:
> > open code mpage_alloc in it's two callers and simplify the results
> > because of the context:
> >
> > - __mpage_writepage always passes GFP_NOFS and can thus always sle
flight 168789 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168789/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 168784 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168784/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 19 guest-saverestore.2 fail REGR. vs. 168765
Tests which did not succee
On Sat, 29 Jan 2022, Julien Grall wrote:
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 6931c022a2..9144d6c0b6 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -2963,6 +2963,7 @@ static int __init construct_domU(struct d
On Tue, 15 Mar 2022, Daniel P. Smith wrote:
> On 1/28/22 16:33, Stefano Stabellini wrote:
> > From: Luca Miccio
> >
> > The xenstore event channel will be allocated for dom0less domains. It is
> > necessary to have access to the evtchn_alloc_unbound function to do
> > that, so make evtchn_alloc_u
On Sat, 29 Jan 2022, Julien Grall wrote:
> On 28/01/2022 21:33, Stefano Stabellini wrote:
> > From: Luca Miccio
> >
> > If "xen,enhanced" is enabled, then add to dom0less domains:
> >
> > - the hypervisor node in device tree
> > - the xenstore event channel
> >
> > The xenstore event channel is
On Sat, 29 Jan 2022, Julien Grall wrote:
> On 28/01/2022 21:33, Stefano Stabellini wrote:
> > From: Luca Miccio
> >
> > Add an example application that can be run in dom0 to complete the
> > dom0less domains initialization so that they can get access to xenstore
> > and use PV drivers.
> >
> > S
flight 168790 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168790/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 168786 xen-unstable real [real]
flight 168792 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168786/
http://logs.test-lab.xenproject.org/osstest/logs/168792/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
flight 168787 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168787/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl 22 guest-start/debian.repeat fail in 168768 pass in 168787
test-armhf-armhf-xl-vhd 12 de
If a xen domain with at least two VCPUs has a PCI device attached which
enters the D3hot state during suspend, the kernel may hang while
resuming, depending on the core on which an async resume task gets
scheduled.
The bug occurs because xen's do_suspend calls dpm_resume_start while
only the timer
On Mar 15 15:41, Markus Armbruster wrote:
> g_new(T, n) is neater than g_malloc(sizeof(T) * n). It's also safer,
> for two reasons. One, it catches multiplication overflowing size_t.
> Two, it returns T * rather than void *, which lets the compiler catch
> more type errors.
>
> This commit only
On Wed, Mar 23, 2022 at 06:38:22AM +0900, Ryusuke Konishi wrote:
> This looks because the mask of GFP_KERNEL is removed along with
> the removal of mpage_alloc().
>
> The default value of the gfp flag is set to GFP_HIGHUSER_MOVABLE by
> inode_init_always().
> So, __GFP_HIGHMEM hits the gfp warnin
On 23.03.2022 01:22, Stefano Stabellini wrote:
> On Tue, 15 Mar 2022, Daniel P. Smith wrote:
>> On 1/28/22 16:33, Stefano Stabellini wrote:
>>> From: Luca Miccio
>>>
>>> The xenstore event channel will be allocated for dom0less domains. It is
>>> necessary to have access to the evtchn_alloc_unboun
flight 168793 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168793/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
80 matches
Mail list logo
