flight 136566 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136566/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 130965
flight 136564 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136564/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl 7 xen-boot fail REGR. vs. 136233
Tests which
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-credit2
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 git://xenbits.xen.org/osstest/ovmf.git
Hi George,
Did you have time to look at this patch?
Regards,
Alex
On 03.05.2019 11:04, Jan Beulich wrote:
On 03.05.19 at 09:53, wrote:
>> On 25.04.2019 15:54, Jan Beulich wrote:
>>> It is an issue anyway that a change is
>>> made without saying why the new behavior preferable over
>>> the
>>> On 20.05.19 at 20:12, wrote:
> As this is now Xen and tools only, I am wondering whether the check on
> GNU_C is still necessary. I am happy to send a follow-up patch (or fold
> in this one) if it can be removed.
I think this should be dropped if it can be without breaking any
Hi,
On 5/20/19 11:56 PM, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
The current value of HSCTLR_BASE for Arm64 is pretty wrong. It would
actually turn on SCTLR_EL2.nAA (bit 6) on hardware implementing
ARMv8.4-LSE.
Furthermore, the documentation of what is cleared/set
On Mon, May 20, 2019 at 7:45 PM Lars Kurth wrote:
> @Adam and Fedora Testing & QA:
> any views on my proposal?
> Regards
> Lars
>
Hi Lars,
thanks for your reply. Adam was on a long vacation and he's probably the
most qualified person to reply to you, sorry for not telling you sooner.
Adam is
flight 136516 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136516/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail blocked in 135683
On 14.05.19 15:24, Julien Grall wrote:
The function create_xen_entries() may be called concurrently. For
instance, while the vmap allocation is protected by a spinlock, the
mapping is not.
The implementation create_xen_entries() contains quite a few TOCTOU
races such as when allocating the
Guests can issue grant table operations and provide guest controlled
data to them. This data is used for memory loads in helper functions
and macros. To avoid speculative out-of-bound accesses, we use the
array_index_nospec macro where applicable, or the block_speculation
macro.
This is part of
Dear all,
This patch series attempts to mitigate the issue that have been raised in the
XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html). To block speculative
execution on Intel hardware, an lfence instruction is required to make sure
that selected checks are not bypassed. Speculative
On 14.05.19 15:24, Julien Grall wrote:
The parameter cpuid is not used by start_xen. So remove it.
Signed-off-by: Julien Grall
---
- Re-order the patch with "xen/arm: Rework secondary_start
prototype"
---
Reviewed-by: Andrii Anisov
--
Sincerely,
Andrii Anisov.
On 21.05.19 00:43, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
Arm currently provides two macro BIT and BIT_ULL that are only usable
in C and return respectively unsigned long and unsigned long long.
Extending the macros to deal with assembly would be a nice benefits
On 14.05.19 15:24, Julien Grall wrote:
Use the pattern BIT(..., UL) to make the code more readable. Note that
unsigned long is used instead of unsigned because SCTLR is technically
32-bit on Arm32 and 64-bit on Arm64.
Signed-off-by: Julien Grall
Reviewed-by: Andrii Anisov
--
Sincerely,
Hi Stefano,
On 5/20/19 10:04 PM, Stefano Stabellini wrote:
On Mon, 20 May 2019, Julien Grall wrote:
On 17/04/2019 18:27, Stefano Stabellini wrote:
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
Guests can issue grant table operations and provide guest controlled
data to them. This data is used as index for memory loads after bound
checks have been done. Depending on the grant table version, the
size of elements in containers differ. As the base data structure is
a page, the number of
Guests can issue grant table operations and provide guest controlled
data to them. This data is used as index for memory loads after bound
checks have been done. To avoid speculative out-of-bound accesses, we
use the array_index_nospec macro where applicable, or the macro
block_speculation. Note,
flight 136652 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136652/
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
>>> On 20.05.19 at 16:27, wrote:
> On 3/29/19 18:11, Jan Beulich wrote:
> On 14.03.19 at 13:50, wrote:
>>> @@ -2410,9 +2448,11 @@ acquire_grant_for_copy(
>>> PIN_FAIL(gt_unlock_out, GNTST_bad_gntref,
>>> "Bad grant reference %#x\n", gref);
>>>
>>> -act =
>>> On 21.05.19 at 11:35, wrote:
> On 5/21/19 10:26 AM, Jan Beulich wrote:
> On 20.05.19 at 20:12, wrote:
>>> As this is now Xen and tools only, I am wondering whether the check on
>>> GNU_C is still necessary. I am happy to send a follow-up patch (or fold
>>> in this one) if
Hi Jan,
On 5/21/19 10:43 AM, Jan Beulich wrote:
On 21.05.19 at 11:35, wrote:
On 5/21/19 10:26 AM, Jan Beulich wrote:
On 20.05.19 at 20:12, wrote:
As this is now Xen and tools only, I am wondering whether the check on
GNU_C is still necessary. I am happy to send a follow-up
On 14.05.19 15:24, Julien Grall wrote:
The boot code is using r2 and r3 to hold the page-table entry value.
While r2 is always updated before storing the value, this is not always
the case for r3.
Thankfully today, r3 will always be zero when we care. But this is
difficult to track and
>>> On 20.05.19 at 19:20, wrote:
>> --- a/xen/drivers/char/console.c
>> +++ b/xen/drivers/char/console.c
>> @@ -36,7 +36,7 @@
>> #ifdef CONFIG_X86
>> #include
>> #include
>> -#else
>> +#elif CONFIG_SBSA_VUART_CONSOLE
>> #include
>> #endif
>
> This is a bit odds to require
Hi Jan,
On 5/21/19 10:26 AM, Jan Beulich wrote:
On 20.05.19 at 20:12, wrote:
As this is now Xen and tools only, I am wondering whether the check on
GNU_C is still necessary. I am happy to send a follow-up patch (or fold
in this one) if it can be removed.
I think this should
On 21/05/2019 15:29, Julien Grall wrote:
> Commit 03957f58db "xen/const: Extend the existing macro BIT to take a
> suffix in parameter" didn't convert all the callers of the macro BIT.
>
> This will result to a build breakage when enabling Livepatch on arm64.
>
> Reported-by: Andrew Cooper
>
On Tue, May 21, 2019 at 04:58:18PM +0200, Olaf Hering wrote:
> Am Tue, 21 May 2019 15:43:15 +0100
> schrieb Wei Liu :
>
> > Yeah, that's indeed strange. Thanks for having a look.
>
> Is the used domU.cfg available? I think In my testing disk=[] had
> backend=qdisk.
See
Commit 03957f58db "xen/const: Extend the existing macro BIT to take a
suffix in parameter" didn't convert all the callers of the macro BIT.
This will result to a build breakage when enabling Livepatch on arm64.
Reported-by: Andrew Cooper
Signed-off-by: Julien Grall
---
Hi Olaf
It appears there is at least one instance that's not properly handled.
See
http://logs.test-lab.xenproject.org/osstest/logs/136440/test-amd64-amd64-xl-qcow2/10.ts-debian-di-install.log
bxl: debug: libxl_device.c:380:libxl__device_disk_set_backend: Disk vdev=xvda
spec.backend=qdisk
On Tue, May 21, 2019 at 04:41:22PM +0200, Olaf Hering wrote:
> Am Tue, 21 May 2019 15:37:02 +0100
> schrieb Wei Liu :
>
> > bxl: debug: libxl_device.c:380:libxl__device_disk_set_backend: Disk
> > vdev=xvda spec.backend=qdisk
> > libxl: debug: libxl_linux.c:235:libxl__get_hotplug_script_info:
On Tue, May 21, Wei Liu wrote:
> bxl: debug: libxl_device.c:380:libxl__device_disk_set_backend: Disk vdev=xvda
> spec.backend=qdisk
> libxl: debug: libxl_linux.c:235:libxl__get_hotplug_script_info: Domain
> 1:backend_kind 3, no need to execute scripts
The backtrace looks like that:
(gdb) bt
#0
flight 136687 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136687/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 136665
Tests which
>>> On 21.05.19 at 15:56, wrote:
> flight 136552 xen-4.10-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/136552/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-xl-pvhv2-intel 23
Am Tue, 21 May 2019 15:43:15 +0100
schrieb Wei Liu :
> Yeah, that's indeed strange. Thanks for having a look.
Is the used domU.cfg available? I think In my testing disk=[] had backend=qdisk.
Olaf
pgpR3Q_4Qz3p3.pgp
Description: Digitale Signatur von OpenPGP
On Tue, 21 May 2019, Julien Grall wrote:
> Commit 03957f58db "xen/const: Extend the existing macro BIT to take a
> suffix in parameter" didn't convert all the callers of the macro BIT.
>
> This will result to a build breakage when enabling Livepatch on arm64.
>
> Reported-by: Andrew Cooper
>
Am Tue, 21 May 2019 15:37:02 +0100
schrieb Wei Liu :
> bxl: debug: libxl_device.c:380:libxl__device_disk_set_backend: Disk vdev=xvda
> spec.backend=qdisk
> libxl: debug: libxl_linux.c:235:libxl__get_hotplug_script_info: Domain
> 1:backend_kind 3, no need to execute scripts
I will check why
On 5/21/19 4:36 PM, Stefano Stabellini wrote:
On Tue, 21 May 2019, Julien Grall wrote:
Commit 03957f58db "xen/const: Extend the existing macro BIT to take a
suffix in parameter" didn't convert all the callers of the macro BIT.
This will result to a build breakage when enabling Livepatch on
On 15/03/2019 10:44, Jan Beulich wrote:
> No explicit test harness additions other than the overrides, as the
> compiler already makes use of the insns.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
On Mon, May 20, 2019 at 06:12:49PM +0100, Ian Jackson wrote:
> Alistair Francis writes ("[PATCH v2 1/2] autotools: Updage config.guess and
> config.sub"):
> > The autoconf manual [1] specifies that as we define AC_CANONICAL_HOST we
> > must supply config.guess and config.sub. In which case let's
flight 136665 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136665/
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
On 15/03/2019 10:54, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -435,7 +435,10 @@ static const struct ext0f38_table {
> disp8scale_t d8s:4;
> } ext0f38_table[256] = {
> [0x00] = { .simd_size = simd_packed_int,
flight 136552 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136552/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-intel 23 leak-check/check fail REGR. vs. 135813
On 15/03/2019 10:45, Jan Beulich wrote:
> Judging from insn prefixes, these are scalar insns, but their (memory)
> operands are vector ones (with the exception of 128-bit VMOVDDUP). For
> this some adjustments to disp8scale calculation code are needed.
>
> No explicit test harness additions other
>>> On 21.05.19 at 15:08, wrote:
> On 15/03/2019 10:54, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -435,7 +435,10 @@ static const struct ext0f38_table {
>> disp8scale_t d8s:4;
>> } ext0f38_table[256] = {
>>
On Fri, May 17, 2019 at 03:31:51PM -0700, Alistair Francis wrote:
> The autoconf manual [1] specifies that as we define AC_CANONICAL_HOST we
> must supply config.guess and config.sub. In which case let's update them
> from [2] commit: b98424c24 "config.guess: Remove space after "#endif", as
>
On 15/03/2019 10:46, Jan Beulich wrote:
> No further test harness additions - what is there is good enough for
> these rather "regular" insns.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
On 15/03/2019 10:47, Jan Beulich wrote:
> @@ -9312,7 +9386,8 @@ x86_emulate(
>
> if ( ea.type == OP_MEM )
> {
> -rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp, 8 << vex.l,
> ctxt);
> +rc = ops->write(ea.mem.seg, truncate_ea(ea.mem.off + first_byte),
>
On 15/03/2019 10:53, Jan Beulich wrote:
> Some "manual" overrides of disp8scale are needed here again. In
> particular code ends up simpler when using d8s_dq64 in the
> twobyte_table[] entry.
>
> Test harness additions will be done once the reverse conversions are
> also available.
>
>
On 15/03/2019 10:54, Jan Beulich wrote:
> Plus their AVX512BW counterparts.
>
> Take the opportunity and also eliminate a pair of open coded instances
> of scalar_1op().
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing
On 15/03/2019 10:46, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 15/03/2019 10:47, Jan Beulich wrote:
> ... including the two AVX512DQ forms which shared encodings, just with
> EVEX.W set there.
>
> VCVTDQ2PD, sharing its main opcode with others, needs a "manual"
> override of disp8scale.
>
> The simd_size changes for the twobyte_table[] entries are benign
On 15/03/2019 10:52, Jan Beulich wrote:
> VCVT{,T}S{S,D}2SI use EVEX.W for their destination (register) rather
> than their (possibly memory) source operand size and hence need a
> "manual" override of disp8scale.
>
> While the SDM claims that EVEX.L'L needs to be zero for the 32-bit forms
> of
On 15/03/2019 10:52, Jan Beulich wrote:
> VCVT{,T}PS2QQ, sharing their main opcodes with others, once again need
> "manual" overrides of disp8scale.
>
> While not directly related here, also add a scalar variant of to_wint()
> to the test harness.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew
On 15/03/2019 10:54, Jan Beulich wrote:
> Along the lines of prior patches, VCVT{,T}PS2UQQ as well as
> VCVT{,T}S{S,D}2USI need "manual" overrides of disp8scale.
>
> The twobyte_table[] entries get altered, with their prior values
> now put in place in x86_decode_twobyte().
>
> Signed-off-by: Jan
>>> On 21.05.19 at 13:33, wrote:
> On 15/03/2019 10:47, Jan Beulich wrote:
>> @@ -9312,7 +9386,8 @@ x86_emulate(
>>
>> if ( ea.type == OP_MEM )
>> {
>> -rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp, 8 << vex.l,
>> ctxt);
>> +rc =
Hi,
Answering to myself.
On 5/17/19 8:00 PM, Julien Grall wrote:
Hi,
On 5/17/19 6:23 PM, Anthony PERARD wrote:
On Thu, May 16, 2019 at 10:38:54PM +0100, Julien Grall wrote:
Hi Anthony,
Thank you for CCing me.
On 5/16/19 11:37 AM, Anthony PERARD wrote:
On Wed, May 15, 2019 at 07:48:17PM
Hi Ian,
On 5/20/19 5:04 PM, Ian Jackson wrote:
Julien Grall writes ("Re: [xen-4.11-testing test] 136385: regressions - FAIL"):
Before the last 2 flights, the kernel was compiled natively. Now it is
cross-compiled on x86 machine. So there are a difference in the way the kernel
is built.
That
From: Oleksandr Tyshchenko
Port Linux helper of_count_phandle_with_args for counting
number of phandles in a property.
Please note, this helper is ported from Linux v4.6.
Signed-off-by: Oleksandr Tyshchenko
---
Changes RFC -> V1:
- Add Linux version which is used as the base.
---
From: Oleksandr Tyshchenko
Hello, all.
The purpose of this small series is to add minimal required support for Xen to
be able
to handle device-tree nodes with "interrupts-extended" property [1].
The "interrupts-extended" property is a special form for use when a node needs
to reference
From: Oleksandr Tyshchenko
The "interrupts-extended" property is a special form for use when
a node needs to reference multiple interrupt parents.
According to the:
Linux/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
But, there are cases when "interrupts-extended"
flight 136699 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136699/
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
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug
On Mon, 2019-05-13 at 16:29 -0600, Lars Kurth wrote:
> Hi all,
>
> I am going to step in here with my hat as Xen Project community
> manager. We had a discussion about this issue as part of last week's
> community call. I CC'ed a number of stake-holders, which probably
> should have been on the
This header files describes protocol between OP-TEE and OP-TEE client
driver in Linux. They are needed for upcoming OP-TEE mediator, which
is added in the next patch.
Reason to add those headers in separate patch is to ease up review.
Those files were taken from linux tree (drivers/tee/optee/) and
Shared memory is widely used by NW (Normal World) to communicate with
TAs (Trusted Applications) in OP-TEE. NW can share part of own memory
with TA or with OP-TEE core, by registering it in OP-TEE, or by
providing a temporal reference. Anyways, information about such memory
buffers are sent to
This patch adds handling for the fast SMCs. As name suggests, those
calls can't be preempted and are used for auxiliary tasks such as
information retrieval. Most handlers are quite trivial, with exception
for capabilities information.
Capabilities exchange should be filtered out, so only caps
OP-TEE usually uses the same idea with command buffers (see
previous commit) to issue RPC requests. Problem is that initially
it has no buffer, where it can write request. So the first RPC
request it makes is special: it requests NW to allocate shared
buffer for other RPC requests. Usually this
OP-TEE can issue multiple RPC requests. We are interested mostly in
request that asks NW to allocate/free shared memory for OP-TEE
needs, because mediator needs to do address translation in the same
way as it was done for shared buffers registered by NW.
OP-TEE can ask NW to allocate multiple
If TEE support is enabled with "tee=optee" option in xl.cfg,
then we need to inform guest about available TEE, by creating
corresponding node in the guest's device tree.
Signed-off-by: Volodymyr Babchuk
Reviewed-by: Julien Grall
---
This patch depends on patches to optee.c.
Changes from v4:
Add very basic OP-TEE mediator. It can probe for OP-TEE presence,
tell it about domain creation/destruction and then return an error
to all calls to the guest.
This code issues two non-preemptible calls to OP-TEE: to create and
to destroy client context. They can't block in OP-TEE, as they are
Hello community,
This is the fifth version of OP-TEE mediator in XEN.
OP-TEE 3.5.0 was released when I worked on this version of the
pathes. This is the first release where virtualization support is
available. This release includes both original virtualization patches
and new SMC that retrevies
The main way to communicate with OP-TEE is to issue standard SMCCC
call. "Standard" is a SMCCC term and it means that call can be
interrupted and OP-TEE can return control to NW before completing
the call.
In contrast with fast calls, where arguments and return values
are passed in registers,
This patch adds basic framework for TEE mediators. Guests can't talk
to TEE directly, we need some entity that will intercept request
and decide what to do with them. "TEE mediator" is a such entity.
This is how it works: user can build XEN with multiple TEE mediators
(see the next patches, where
This enumeration controls TEE type for a domain. Currently there is
two possible options: either 'none' or 'optee'.
'none' is the default value and it basically disables TEE support at
all.
'native' enables access to a "real" OP-TEE installed on a platform.
It is possible to add another types
On Tue, 21 May 2019, Julien Grall wrote:
> Hi Jan,
>
> On 5/21/19 10:43 AM, Jan Beulich wrote:
> > > > > On 21.05.19 at 11:35, wrote:
> > > On 5/21/19 10:26 AM, Jan Beulich wrote:
> > > > > > > On 20.05.19 at 20:12, wrote:
> > > > > As this is now Xen and tools only, I am wondering
The only use of asm/vpl011.h is protected by the CONFIG_SBSA_VUART_CONSOLE
define so lets protect the include as well.
Signed-off-by: Alistair Francis
---
v3:
- Rework commit title and message
- Split it into a seperate ifdef
xen/drivers/char/console.c | 3 ++-
1 file changed, 2
flight 136559 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136559/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 7 xen-boot fail REGR. vs. 128858
76 matches
Mail list logo
