On 10.03.2021 18:22, Andrew Cooper wrote:
> On 10/03/2021 17:12, Jan Beulich wrote:
>> On 10.03.2021 16:07, Andrew Cooper wrote:
>>> --- a/docs/designs/dmop.pandoc
>>> +++ b/docs/designs/dmop.pandoc
>>> @@ -4,9 +4,13 @@ DMOP
>>> Introduction
>>>
>>>
>>> -The aim of DMOP is to
On 10.03.2021 20:09, Ian Jackson wrote:
> (I bounced Roger's original mail to xen-devel. I hope it made it...)
>
> Roger Pau Monné writes ("Remaining MSR wrinkles"):
>> 1. MSR behavior for PV guests without a #GP handler set: PV Linux versions <
>>4.14 will use rdmsr_safe (and likely
flight 159928 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159928/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 3/10/2021 1:40 PM, Rob Herring wrote:
> On Wed, Mar 10, 2021 at 9:08 AM Will Deacon wrote:
>>
>> Hi Claire,
>>
>> On Tue, Feb 09, 2021 at 02:21:30PM +0800, Claire Chang wrote:
>>> Introduce the new compatible string, restricted-dma-pool, for restricted
>>> DMA. One can specify the address
flight 159911 qemu-mainline real [real]
flight 159923 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159911/
http://logs.test-lab.xenproject.org/osstest/logs/159923/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
> From: Igor Druzhinin
> Sent: Monday, March 8, 2021 3:00 PM
>
> BIOS might pass control to Xen leaving QI and/or IR in enabled and/or
> partially configured state. In case of x2APIC code path where EIM is
> enabled early in boot - those are correctly disabled by Xen before any
> attempt to
On Wed, 10 Mar 2021 at 21:15, Roman Shaposhnik wrote:
>
> Hi!
Hi,
>
> just came across this failure on aarch64:
>
> ld: prelink.o: in function `_spin_lock_cb':
> 19187(.text+0x1f26c): undefined reference to `__aarch64_ldadd4_acq_rel'
> 19188ld: prelink.o: in function `_spin_lock':
>
Hello,
There are a couple of remaining wrinkles related to MSR that I think we need to
solve before the release, or agree that it's fine to leave them as-is and
document in the release notes. I've tried to summarize the different views
below, sorry if I haven't done this properly or missed some
On Wed, Mar 10, 2021 at 9:08 AM Will Deacon wrote:
>
> Hi Claire,
>
> On Tue, Feb 09, 2021 at 02:21:30PM +0800, Claire Chang wrote:
> > Introduce the new compatible string, restricted-dma-pool, for restricted
> > DMA. One can specify the address and length of the restricted DMA memory
> > region
Hi!
just came across this failure on aarch64:
ld: prelink.o: in function `_spin_lock_cb':
19187(.text+0x1f26c): undefined reference to `__aarch64_ldadd4_acq_rel'
19188ld: prelink.o: in function `_spin_lock':
19189(.text+0x1f2ec): undefined reference to `__aarch64_ldadd4_acq_rel'
19190ld:
On Sat, 6 Mar 2021, Julien Grall wrote:
> From: Julien Grall
>
> Compilers older than 4.8 have known codegen issues which can lead to
> silent miscompilation:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145
>
> Furthermore, pre-4.9 GCC have known bugs (including things like
> internal
flight 159906 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159906/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 159893
Tests which did not
> On 30.01.21 19:53, Roman Shaposhnik wrote:
> > On Fri, Jan 29, 2021 at 11:28 PM Jürgen Groß wrote:
> >>
> >> On 29.01.21 21:12, Roman Shaposhnik wrote:
> >>> Hi!
> >>>
> >>> I'm trying to see how much mileage I can get out of
> >>> crash(1) 7.2.8 (based on gdb 7.6) when it comes to analyzing
flight 159917 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159917/
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
On 3/10/21 1:29 AM, Gurrieri Stefano wrote:
> Hello,
>
> I'm working on the platform STM32MP1 based on cortex-A7 dual core. This is an
> armv7-A that has the "Hardware virtualization support".
> My current Linux BSP is built using Yocto Project... but now, I'm asking how
> to enable XEN on my
Hi Jan,
On 09/03/2021 11:20, Jan Beulich wrote:
On 08.03.2021 21:22, Julien Grall wrote:
On 08/03/2021 11:20, Jan Beulich wrote:
On 08.03.2021 11:51, Julien Grall wrote:
On 08/03/2021 08:09, Jan Beulich wrote:
Additionally - partly related to your own reply regarding the CI
failures - imo
Hi Jan,
On 10/03/2021 16:21, Jan Beulich wrote:
On 10.03.2021 15:58, Julien Grall wrote:
On 10/03/2021 10:13, Jan Beulich wrote:
Sadly I was wrong to suggest dropping vaddrs' initializer during review
of v2 of the patch introducing this code. gcc 4.3 can't cope.
What's the error?
The one
On 10/03/2021 17:12, Jan Beulich wrote:
> On 10.03.2021 16:07, Andrew Cooper wrote:
>> --- a/docs/designs/dmop.pandoc
>> +++ b/docs/designs/dmop.pandoc
>> @@ -4,9 +4,13 @@ DMOP
>> Introduction
>>
>>
>> -The aim of DMOP is to prevent a compromised device model from compromising
>>
On 10.03.2021 16:07, Andrew Cooper wrote:
> --- a/docs/designs/dmop.pandoc
> +++ b/docs/designs/dmop.pandoc
> @@ -4,9 +4,13 @@ DMOP
> Introduction
>
>
> -The aim of DMOP is to prevent a compromised device model from compromising
> -domains other than the one it is providing
flight 159913 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159913/
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
On 10.03.2021 15:58, Julien Grall wrote:
> On 10/03/2021 10:13, Jan Beulich wrote:
>> Sadly I was wrong to suggest dropping vaddrs' initializer during review
>> of v2 of the patch introducing this code. gcc 4.3 can't cope.
>
> What's the error?
The one quoted in the title.
> Are you sure this
And update the release technician checklist to mention to edit it.
Signed-off-by: Ian Jackson
Release-Acked-by: Ian Jackson
---
CHANGELOG.md | 4 +++-
docs/process/release-technician-checklist.txt | 2 ++
2 files changed, 5 insertions(+), 1 deletion(-)
diff
The administriva parts of this (1/, 2/) are a little belated.
For for the substance 3/ I have information from SUPPORT.md. There is
much other information to put here but right now there are several
blockers in tree and I don't want to distract from fixing them.
I had a look through the git logs
Signed-off-by: Ian Jackson
Release-Acked-by: Ian Jackson
---
CHANGELOG.md | 11 +++
1 file changed, 11 insertions(+)
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 6805f9b7d4..c407f6bb2f 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -6,6 +6,17 @@ The format is based on [Keep a
Signed-off-by: Ian Jackson
Acked-by: Jan Beulich
Release-Acked-by: Ian Jackson
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3a5c481543..6a7fa8717e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -256,7 +256,7 @@ S: Supported
flight 159902 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159902/
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
2021年3月10日(水) 22:29 Gerd Hoffmann :
>
> Hi,
>
> > -static void xenfb_update_interval(void *opaque, uint64_t interval)
> > +static void xenfb_ui_info(void *opaque, uint32_t idx, QemuUIInfo *info)
>
> > -.update_interval = xenfb_update_interval,
> > +.ui_info = xenfb_ui_info,
>
> Hmm,
Hi Claire,
On Tue, Feb 09, 2021 at 02:21:30PM +0800, Claire Chang wrote:
> Introduce the new compatible string, restricted-dma-pool, for restricted
> DMA. One can specify the address and length of the restricted DMA memory
> region by restricted-dma-pool in the reserved-memory node.
>
>
Andrew Cooper writes ("Re: [PATCH for-4.15 v2] xen/dmop: Strip __XEN_TOOLS__
header guard from public API"):
> Thanks, but you already release acked it. This is the requested update
> including the documentation change.
Oh yes so I did.
Ian.
On 10/03/2021 15:14, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH for-4.15 v2] xen/dmop: Strip __XEN_TOOLS__
> header guard from public API"):
>> Exactly as with c/s f40e1c52e4, this is inappropriate for a stable library.
>>
>> That change actually broke the build with:
>>
>>
Andrew Cooper writes ("[PATCH for-4.15 v2] xen/dmop: Strip __XEN_TOOLS__ header
guard from public API"):
> Exactly as with c/s f40e1c52e4, this is inappropriate for a stable library.
>
> That change actually broke the build with:
>
> include/xendevicemodel.h:52:5: error: unknown type name
Exactly as with c/s f40e1c52e4, this is inappropriate for a stable library.
That change actually broke the build with:
include/xendevicemodel.h:52:5: error: unknown type name 'ioservid_t'
ioservid_t *id);
^
as libxendevicemodel.h now uses a type it can't see a typedef for.
Roger Pau Monne writes ("[PATCH v3 for-4.15] x86/msr: introduce an option for
compatible MSR behavior selection"):
> Introduce an option to allow selecting a behavior similar to the pre
> Xen 4.15 one for accesses to MSRs not explicitly handled. Since commit
> 84e848fd7a162f669 and
Hi,
I was running a loop of `xl block-attach ; xl block-detach` and I
triggered a BUG in xen-blkfront, drivers/block/xen-blkfront.c:1917
This is BUG_ON(info->nr_rings) in negotiate_mq called by blkback_changed.
I'm using Linux 5.4.103 and blktap3 on Xen 4.12 (OpenXT), though I
don't think that
Hi Jan,
On 10/03/2021 10:13, Jan Beulich wrote:
Sadly I was wrong to suggest dropping vaddrs' initializer during review
of v2 of the patch introducing this code. gcc 4.3 can't cope.
What's the error? Are you sure this is not going to hiding a potential
miscompilation of the function?
Introduce an option to allow selecting a behavior similar to the pre
Xen 4.15 one for accesses to MSRs not explicitly handled. Since commit
84e848fd7a162f669 and 322ec7c89f6640e accesses to MSRs not explicitly
handled by Xen result in the injection of a #GP to the guest. This
is a behavior change
On 10.03.21 15:27, Borislav Petkov wrote:
On Tue, Mar 09, 2021 at 02:48:06PM +0100, Juergen Gross wrote:
diff --git a/arch/x86/include/asm/alternative.h
b/arch/x86/include/asm/alternative.h
index 89889618ae01..4fb844e29d26 100644
--- a/arch/x86/include/asm/alternative.h
+++
On 10.03.21 15:15, Borislav Petkov wrote:
On Wed, Mar 10, 2021 at 08:52:40AM +0100, Jürgen Groß wrote:
Did you look at patch 13? :-)
Well, I usually review in increasing patch order. :-P
But make that change here pls because otherwise unnecessary churn.
Okay.
Juergen
On Tue, Mar 09, 2021 at 02:48:06PM +0100, Juergen Gross wrote:
> diff --git a/arch/x86/include/asm/alternative.h
> b/arch/x86/include/asm/alternative.h
> index 89889618ae01..4fb844e29d26 100644
> --- a/arch/x86/include/asm/alternative.h
> +++ b/arch/x86/include/asm/alternative.h
> @@ -178,6
On Wed, Mar 10, 2021 at 08:52:40AM +0100, Jürgen Groß wrote:
> Did you look at patch 13? :-)
Well, I usually review in increasing patch order. :-P
But make that change here pls because otherwise unnecessary churn.
Thx.
--
Regards/Gruss,
Boris.
On Wed, Mar 10, 2021 at 08:51:22AM +0100, Jürgen Groß wrote:
> It is combining the two needed actions: update the static call and
> set the paravirt_using_native_sched_clock boolean.
I actually meant what the point of using_native_sched_clock() is but put
this comment at the wrong place, sorry.
Xen 4.15 RC2 is now available.
It is available from git:
git clone https://xenbits.xenproject.org/git-http/xen.git -b 4.15.0-rc2
For your convenience a tarball is available:
https://downloads.xenproject.org/release/xen/4.15.0-rc2/xen-4.15.0-rc2.tar.gz
On 09.03.2021 20:57, Andrew Cooper wrote:
> On 09/03/2021 11:36, Jan Beulich wrote:
>> On 09.03.2021 11:56, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/hvm/svm/svm.c
>>> +++ b/xen/arch/x86/hvm/svm/svm.c
>>> @@ -1795,6 +1795,7 @@ static int svm_msr_read_intercept(unsigned int msr,
>>> uint64_t
Julien Grall writes ("Re: [PATCH v4] arm: Add Kconfig entry to select
CONFIG_DTB_FILE"):
> I was under the impression that this patch would not target 4.15. At
> least I didn't see any request for it.
OK, good :-).
Thanks,
Ian.
Hi,
> -static void xenfb_update_interval(void *opaque, uint64_t interval)
> +static void xenfb_ui_info(void *opaque, uint32_t idx, QemuUIInfo *info)
> -.update_interval = xenfb_update_interval,
> +.ui_info = xenfb_ui_info,
Hmm, I suspect xenfb really wants the actual refresh rate,
On 10.03.21 11:46, Jan Beulich wrote:
Requesting zeroed memory when all of it will be overwritten subsequently
by all ones is a waste of processing bandwidth. In fact, rather than
recording zeroed ->grants[], fill that array too with more appropriate
"invalid" indicators.
Signed-off-by: Jan
flight 159898 qemu-mainline real [real]
flight 159908 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159898/
http://logs.test-lab.xenproject.org/osstest/logs/159908/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
On 10.03.2021 12:13, Roger Pau Monné wrote:
> On Tue, Mar 09, 2021 at 07:57:42PM +, Andrew Cooper wrote:
>> On 09/03/2021 11:36, Jan Beulich wrote:
>>> So what are your thoughts wrt my change to this file? Drop it
>>> altogether and require people to use this new option? Or do you
>>> see both
Hi Ian,
On 10/03/2021 11:33, Ian Jackson wrote:
Jan Beulich writes ("Re: [PATCH v4] arm: Add Kconfig entry to select
CONFIG_DTB_FILE"):
Nit: Linux, iirc, has dropped support for ---help--- (allowing
only help now). To limit churn whenever we're going to re-sync
our kconfig again, I'd like to
Jan Beulich writes ("Re: [PATCH v4] arm: Add Kconfig entry to select
CONFIG_DTB_FILE"):
> Nit: Linux, iirc, has dropped support for ---help--- (allowing
> only help now). To limit churn whenever we're going to re-sync
> our kconfig again, I'd like to avoid introduction of new uses
> of the old
On 10.03.2021 12:24, Jan Beulich wrote:
> On 10.03.2021 12:13, Dario Faggioli wrote:
>> So, in my mind, now `mask` is empty. Therefore, I'm currently clueless
>> about why we enter this loop...
>>
>>> for_each_cpu(i, )
>>> {
>>> s_time_t score;
>>>
>>> /* Already looked at
Jan Beulich writes ("Re: [PATCH for-4.15] arm: replace typeof() with
__typeof__()"):
> On 09.03.2021 22:27, Andrew Cooper wrote:
> > This wants backporting as a build fix, so should be considered for 4.15
> > at this point.
Release-Acked-by: Ian Jackson
Ian.
On 10.03.2021 12:13, Dario Faggioli wrote:
> On Tue, 2021-03-09 at 17:24 +0100, Roger Pau Monné wrote:
>> Hello,
>>
> Hey,
>
>> While looking at the NR_CPUS == 1 build I realized I could reliable
>> trigger the following ASSERT by creating a guest (note that dom0
>> seems
>> to be fine):
>>
>
On Tue, Mar 09, 2021 at 07:57:42PM +, Andrew Cooper wrote:
> On 09/03/2021 11:36, Jan Beulich wrote:
> > On 09.03.2021 11:56, Roger Pau Monne wrote:
> >> --- a/xen/arch/x86/pv/emul-priv-op.c
> >> +++ b/xen/arch/x86/pv/emul-priv-op.c
> >> @@ -875,6 +875,7 @@ static int read_msr(unsigned int
On Tue, 2021-03-09 at 17:24 +0100, Roger Pau Monné wrote:
> Hello,
>
Hey,
> While looking at the NR_CPUS == 1 build I realized I could reliable
> trigger the following ASSERT by creating a guest (note that dom0
> seems
> to be fine):
>
Yes, I'm (somewhat, not sure if exactly though) able to
On 10.03.21 11:45, Jan Beulich wrote:
It's not helpful if every driver has to cook its own. Generalize
xenbus'es INVALID_GRANT_HANDLE and pcifront's INVALID_GRANT_REF (which
shouldn't have expanded to zero to begin with). Use the constants in
p2m.c and gntdev.c right away, and update field types
On 10.03.21 11:45, Jan Beulich wrote:
They're needed only in the not-auto-translate (i.e. PV) case; there's no
point in allocating memory that's never going to get accessed.
Signed-off-by: Jan Beulich
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description:
Requesting zeroed memory when all of it will be overwritten subsequently
by all ones is a waste of processing bandwidth. In fact, rather than
recording zeroed ->grants[], fill that array too with more appropriate
"invalid" indicators.
Signed-off-by: Jan Beulich
---
v2: Use (now generalized)
It's not helpful if every driver has to cook its own. Generalize
xenbus'es INVALID_GRANT_HANDLE and pcifront's INVALID_GRANT_REF (which
shouldn't have expanded to zero to begin with). Use the constants in
p2m.c and gntdev.c right away, and update field types where necessary so
they would match
They're needed only in the not-auto-translate (i.e. PV) case; there's no
point in allocating memory that's never going to get accessed.
Signed-off-by: Jan Beulich
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -136,17 +136,20 @@ struct gntdev_grant_map *gntdev_alloc_ma
While addressing the XSAs a number of further oddities were noticed.
Try to take care of them.
1: gntdev: don't needlessly allocate k{,un}map_ops[]
2: gnttab: introduce common INVALID_GRANT_{HANDLE,REF}
3: gntdev: don't needlessly use kvcalloc()
Jan
Add support for arm64/arm32 in the build
system, modify the common headers to be
aware of the new architectures and update
the documentation.
Architecture can be set using ARCH=arm64
or ARCH=arm32.
arm64: Currently only one test: tests/example
is supported allowing the startup code head.S
to be
Currently XTF build system is strictly made up for x86.
Modify the build system so that it will be easier
to add other platforms to XTF in the future.
This is done by generalizing the common makefiles to be
architecture independent and creating architecture
specific makefiles.
Signed-off-by:
The goal of this patch series is to make the first step in porting
XTF to arm64 and arm32, whereby the emphasis is on arm64.
The attempt to port XTF to arm64 was originally started by Julien Grall.
The series contains:
Patch 1 performs miscellaneous code cleanup related to headers
that should be
Add initial support to XTF for arm64/arm32 without
modifying existing XTF architecture.
Most of the files are just dummy files waiting to be properly
implemented step by step later on.
The purpose of this change is to add the initial code and minimal
set of files to support arm64 without
-define macro ALIGN to set alignment:
Header file asm_macros.h should not contain
architecture specific code. Replace hardcoded
alignment value with a call to macro ALIGN.
-move declaration of shared_info into xtf/traps.h:
Declaration of shared_info structure should be
placed in xtf/traps.h as it
On Wed, 2021-03-10 at 08:52 +0100, Roger Pau Monné wrote:
> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you can confirm the sender
> and know the content is safe.
>
>
>
> On Tue, Mar 09, 2021 at 02:24:05PM -0800, Stefano
On 10.03.2021 10:33, Roger Pau Monné wrote:
> On Tue, Mar 09, 2021 at 07:13:26PM +, Andrew Cooper wrote:
>> On 09/03/2021 10:56, Roger Pau Monne wrote:
>>> --- a/xen/include/public/arch-x86/xen.h
>>> +++ b/xen/include/public/arch-x86/xen.h
>>> @@ -304,6 +304,14 @@ struct xen_arch_domainconfig
Sadly I was wrong to suggest dropping vaddrs' initializer during review
of v2 of the patch introducing this code. gcc 4.3 can't cope.
Fixes: 52531c734ea1 ("xen/gnttab: Rework resource acquisition")
Signed-off-by: Jan Beulich
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@
On 08.03.21 14:36, Elliott Mitchell wrote:
typeof() is available in Xen's build environment, which uses Xen's
compiler. As these headers are public, they need strict standards
conformance. Only __typeof__() is officially standardized.
A compiler in standards conformance mode should report:
flight 159903 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159903/
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 159907 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159907/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 1b47cc852fd130ed9ce274a0f1600a4a62949a2c
baseline version:
xen
On Tue, Mar 09, 2021 at 07:13:26PM +, Andrew Cooper wrote:
> On 09/03/2021 10:56, Roger Pau Monne wrote:
> > Introduce an option to allow selecting a behavior similar to the pre
> > Xen 4.15 one for accesses to MSRs not explicitly handled. Since commit
> > 84e848fd7a162f669 and 322ec7c89f6640e
Hello,
I'm working on the platform STM32MP1 based on cortex-A7 dual core. This is an
armv7-A that has the "Hardware virtualization support".
My current Linux BSP is built using Yocto Project... but now, I'm asking how to
enable XEN on my platform? Is there a procedure to follow to try to
On 2021-03-09 08:57, Ross Lagerwall wrote:
> On 2021-03-09 05:14, Jürgen Groß wrote:
>> On 08.03.21 21:33, Boris Ostrovsky wrote:
>>>
>>> On 3/6/21 11:18 AM, Juergen Gross wrote:
An event channel should be kept masked when an eoi is pending for it.
When being migrated to another cpu it
On 10.03.2021 07:58, Michal Orzel wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -400,6 +400,14 @@ config DOM0_MEM
>
> Leave empty if you are not sure what to specify.
>
> +config DTB_FILE
> + string "Absolute path to device tree blob"
> + depends on
On 09.03.2021 22:27, Andrew Cooper wrote:
> On 08/03/2021 13:36, Elliott Mitchell wrote:
>> typeof() is available in Xen's build environment, which uses Xen's
>> compiler. As these headers are public, they need strict standards
>> conformance. Only __typeof__() is officially standardized.
>>
>>
flight 159893 xen-unstable real [real]
flight 159904 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159893/
http://logs.test-lab.xenproject.org/osstest/logs/159904/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi,
> On 10 Mar 2021, at 07:58, Michal Orzel wrote:
>
> Currently in order to link existing DTB into Xen image
> we need to either specify option CONFIG_DTB_FILE on the
> command line or manually add it into .config.
> Add Kconfig entry: CONFIG_DTB_FILE to be able to
> provide the path to DTB
79 matches
Mail list logo
