branch xen-4.10-testing
xenbranch xen-4.10-testing
job test-armhf-armhf-xl-arndale
testid debian-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemuu git://xenbit
flight 137900 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137900/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a
test-armhf-armhf-xl-credit1 1 build-check
>>> On 19.06.19 at 09:06, wrote:
> branch xen-4.10-testing
> xenbranch xen-4.10-testing
> job test-armhf-armhf-xl-arndale
> testid debian-install
>
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: ovmf git://xenbits
>>> On 19.06.19 at 01:20, wrote:
> Add a p2mt parameter to map_mmio_regions, pass p2m_mmio_direct_dev on
> ARM and p2m_mmio_direct on x86 -- no changes in behavior. On x86,
> introduce a macro to strip away the last parameter and rename the
> existing implementation of map_mmio_regions to __map_mm
>>> On 19.06.19 at 01:20, wrote:
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -2070,6 +2070,7 @@ int xc_domain_memory_mapping(
> domctl.cmd = XEN_DOMCTL_memory_mapping;
> domctl.domain = domid;
> domctl.u.memory_mapping.add_mapping = add_mapping;
> +domct
On 17/06/2019, 18:28, "Stefano Stabellini" wrote:
On Mon, 17 Jun 2019, Julien Grall wrote:
> On 17/06/2019 17:28, Stefano Stabellini wrote:
> > Looking at https://www.gnu.org/licenses/license-list.en.html and also
> > looking at the usage in the Linux kernel, I am pretty sure i
Hi,
On 6/19/19 8:28 AM, Jan Beulich wrote:
On 19.06.19 at 09:06, wrote:
branch xen-4.10-testing
xenbranch xen-4.10-testing
job test-armhf-armhf-xl-arndale
testid debian-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.g
flight 137905 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137905/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 137717
test-amd64-amd64-xl-q
flight 138013 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138013/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 260acc521db4c29df4aa9b7a67f42cf967871fd3
baseline version:
xen 1c90
Hi Lars,
On 19/06/2019 09:20, Lars Kurth wrote:
On 17/06/2019, 18:28, "Stefano Stabellini" wrote:
On Mon, 17 Jun 2019, Julien Grall wrote:
> On 17/06/2019 17:28, Stefano Stabellini wrote:
> > Looking at https://www.gnu.org/licenses/license-list.en.html and also
> > looki
Hi,
On 18/06/2019 16:23, Volodymyr Babchuk wrote:
Julien Grall writes:
On 6/18/19 3:30 PM, Volodymyr Babchuk wrote:
Julien Grall writes:
On 18/06/2019 12:19, Volodymyr Babchuk wrote:
Hi Julien,
Hi,
Julien Grall writes:
+
+=item B
+
+Allow a guest to use OP-TEE. Note that a virtua
Hi Volodymyr,
On 11/06/2019 19:46, Volodymyr Babchuk wrote:
diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig
new file mode 100644
index 00..5b829db2e9
--- /dev/null
+++ b/xen/arch/arm/tee/Kconfig
@@ -0,0 +1,4 @@
+config OPTEE
+ bool "Enable OP-TEE mediator"
+
Or else clang adds a .init.rodata.cst8 section to the resulting object
file, which is not handled by the Xen linker script and can end up
before the text section which contains the headers, thus resulting in
a not usable binary.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dun
If the hypervisor has been built with EFI support (ie: multiboot2).
This allows to position the .reloc section correctly in the output
binary, or else the linker might place .reloc before the .text
section.
Note that the .reloc section is moved before .bss for two reasons: in
order for the resulti
Hello,
Current hypervisor code/build produces an invalid binary when linked
with lld 8 (llvm linker). This is because lld 8 places orphaned sections
at the beginning of the output file, thus displacing the multiboot
headers.
In order to build a correct image with lld 8 make sure there are no
orph
On 19/06/2019 12:01, Julien Grall wrote:
Hi Volodymyr,
On 11/06/2019 19:46, Volodymyr Babchuk wrote:
diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig
new file mode 100644
index 00..5b829db2e9
--- /dev/null
+++ b/xen/arch/arm/tee/Kconfig
@@ -0,0 +1,4 @@
+config OPTEE
+
After building the hypervisor binary. Note that the check is performed
by searching for the magic header value at the start of the binary.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
xen/arch/x86/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff
Replace the two open-coded EFI related section declarations with the
usage of DECL_SECTION. This is a preparatory change for also adding a
reloc section to the ELF binary.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
xen/arch/x86/xen.lds.S | 4 ++--
1 f
Hello Volodymyr,
On 11/06/2019 19:46, Volodymyr Babchuk wrote:
Volodymyr Babchuk (10):
xen/arm: add generic TEE mediator framework
xen/arm: optee: add OP-TEE header files
xen/arm: optee: add OP-TEE mediator skeleton
xen/arm: optee: add fast calls handling
xen/arm: optee: add std c
On 19/06/2019 12:02, Roger Pau Monne wrote:
> Or else clang adds a .init.rodata.cst8 section to the resulting object
> file, which is not handled by the Xen linker script and can end up
> before the text section which contains the headers, thus resulting in
> a not usable binary.
>
> Signed-off-by:
On 19/06/2019 12:02, Roger Pau Monne wrote:
> After building the hypervisor binary. Note that the check is performed
> by searching for the magic header value at the start of the binary.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Wei Liu
> ---
> xen/ar
On 19/06/2019 12:02, Roger Pau Monne wrote:
> Replace the two open-coded EFI related section declarations with the
> usage of DECL_SECTION. This is a preparatory change for also adding a
> reloc section to the ELF binary.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
__
flight 137956 xen-4.11-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/137956/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsmqueued
test-xtf-amd64-a
flight 137937 xen-4.10-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/137937/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel queued
test-amd6
flight 137995 xen-4.7-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/137995/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 queued
build-armh
On 19/06/2019 12:02, Roger Pau Monne wrote:
> If the hypervisor has been built with EFI support (ie: multiboot2).
Seeing as this continues the sentence from the subject, it should start
without a capital. Otherwise the result is werd to read.
> This allows to position the .reloc section correctl
On Wed, Jun 19, 2019 at 12:11:43PM +0100, Andrew Cooper wrote:
> On 19/06/2019 12:02, Roger Pau Monne wrote:
> > After building the hypervisor binary. Note that the check is performed
> > by searching for the magic header value at the start of the binary.
> >
> > Signed-off-by: Roger Pau Monné
> >
On 19/06/2019 12:20, Roger Pau Monné wrote:
> On Wed, Jun 19, 2019 at 12:11:43PM +0100, Andrew Cooper wrote:
>> On 19/06/2019 12:02, Roger Pau Monne wrote:
>>> After building the hypervisor binary. Note that the check is performed
>>> by searching for the magic header value at the start of the bina
>>> On 19.06.19 at 13:09, wrote:
> On 19/06/2019 12:02, Roger Pau Monne wrote:
>> Or else clang adds a .init.rodata.cst8 section to the resulting object
>> file, which is not handled by the Xen linker script and can end up
>> before the text section which contains the headers, thus resulting in
>>
>>> On 19.06.19 at 13:02, wrote:
> Or else clang adds a .init.rodata.cst8 section to the resulting object
> file, which is not handled by the Xen linker script and can end up
> before the text section which contains the headers, thus resulting in
> a not usable binary.
To be honest I'd prefer if
>>> On 19.06.19 at 13:20, wrote:
> On 19/06/2019 12:02, Roger Pau Monne wrote:
>> Note that the .reloc section is moved before .bss for two reasons: in
>> order for the resulting binary to not contain any section with data
>> after .bss, so that the file size can be smaller than the loaded
>> memo
On 18.06.19 19:19, Julien Grall wrote:
Denis (the author of the thread) is doing a GSOC to port Xen on the BeagleBoard
X15. You ended up CCed because you can provide feedback how to proceed. Not
because we wanted you to implement it...
OK then.
Denis,
Feel free to contact me in case you n
On 15/03/2019 10:58, Jan Beulich wrote:
> This requires getting modrm_reg and sib_index set correctly in the EVEX
> case, to account for the high 16 [XYZ]MM registers. Extend the
> adjustments to modrm_rm as well, such that x86_insn_modrm() would
> correctly report register numbers (this was a late
In the near future all fresh installations will have an empty /etc.
The content of this directory will not be controlled by the package
manager anymore. One of the reasons for this move is to make snapshots
more robust.
As a first step into this direction, move the hotplug scripts to libexec
becau
On 15/03/2019 10:59, Jan Beulich wrote:
> In order to verify that in particular the index register decoding works
> correctly in the S/G emulation paths, add dedicated (64-bit only) cases
> disallowing the compiler to use the lower registers. Other than in the
> generic SIMD case, where occasional
On 15/03/2019 11:00, Jan Beulich wrote:
> Since the insns here and in particular their memory access patterns
> follow the usual scheme I didn't think it was necessary to add
> contrived tests specifically for them, beyond the Disp8 scaling ones.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Co
On 15/03/2019 11:01, Jan Beulich wrote:
> Also add testing of ones support for which was added before. Sadly gcc's
> command line option naming is not in line with Intel's naming of the
> feature, which makes it necessary to mis-name things in the test harness.
>
> Since the only new insn here and
The referenced versions can not run staging anymore since a while.
Signed-off-by: Olaf Hering
---
tools/examples/Makefile | 1 -
tools/examples/README.incompatibilities | 38 -
2 files changed, 39 deletions(-)
delete mode 100644 tools/examples/RE
On 15/03/2019 11:01, Jan Beulich wrote:
> --- a/xen/tools/gen-cpuid.py
> +++ b/xen/tools/gen-cpuid.py
> @@ -269,7 +269,7 @@ def crunch_numbers(state):
> # AVX512 extensions acting (solely) on vectors of bytes/words are
> made
> # dependents of AVX512BW (as to requiring wider than
On 15/03/2019 11:02, Jan Beulich wrote:
> Once again take the liberty and also correct the (public interface) name
> of the AVX512_IFMA feature flag to match the SDM, on the assumption that
> no external consumer has actually been using that flag so far.
>
> As in a few cases before, since the insn
On 15/03/2019 11:02, Jan Beulich wrote:
> As in a few cases before, since the insns here and in particular their
> memory access patterns follow the usual scheme, I didn't think it was
> necessary to add a contrived test specifically for them, beyond the
> Disp8 scaling one.
>
> Signed-off-by: Jan
In the near future all fresh installations will have an empty /etc.
The content of this directory will not be controlled by the package
manager anymore. One of the reasons for this move is to make snapshots
more robust.
Installing empty configuration files is not helpful for an empty /etc
director
>>> On 19.06.19 at 14:05, wrote:
> On 15/03/2019 10:58, Jan Beulich wrote:
>> This requires getting modrm_reg and sib_index set correctly in the EVEX
>> case, to account for the high 16 [XYZ]MM registers. Extend the
>> adjustments to modrm_rm as well, such that x86_insn_modrm() would
>> correctly
>>> On 19.06.19 at 14:22, wrote:
> On 15/03/2019 11:01, Jan Beulich wrote:
>> --- a/xen/tools/gen-cpuid.py
>> +++ b/xen/tools/gen-cpuid.py
>> @@ -269,7 +269,7 @@ def crunch_numbers(state):
>> # AVX512 extensions acting (solely) on vectors of bytes/words are
>> made
>> # dependen
>>> On 19.06.19 at 13:02, wrote:
> If the hypervisor has been built with EFI support (ie: multiboot2).
> This allows to position the .reloc section correctly in the output
> binary, or else the linker might place .reloc before the .text
> section.
>
> Note that the .reloc section is moved before
In the near future all fresh installations will have an empty /etc.
The content of this directory will not be controlled by the package
manager anymore. One of the reasons for this move is to make snapshots
more robust.
Installing empty configuration files is not helpful for an empty /etc
director
>>> On 19.06.19 at 13:02, wrote:
> After building the hypervisor binary. Note that the check is performed
> by searching for the magic header value at the start of the binary.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Wei Liu
> ---
> xen/arch/x86/Ma
flight 137906 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137906/
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. 137639
test-amd64-i386-xl
On Mon, Jun 17, 2019 at 09:13:16AM -0700, Stefano Stabellini wrote:
> On Mon, 17 Jun 2019, Arnd Bergmann wrote:
> > On architectures that have a larger dma_addr_t than phys_addr_t,
> > the swiotlb_tbl_map_single() function truncates its return code
> > in the failure path, making it impossible to i
On Wed, Jun 19, 2019 at 12:20:40PM +0100, Andrew Cooper wrote:
> On 19/06/2019 12:02, Roger Pau Monne wrote:
> > If the hypervisor has been built with EFI support (ie: multiboot2).
>
> Seeing as this continues the sentence from the subject, it should start
> without a capital. Otherwise the resul
Hi,
ср, 19 июн. 2019 г. в 14:01, Andrii Anisov :
>
>
>
> On 18.06.19 19:19, Julien Grall wrote:
> > Denis (the author of the thread) is doing a GSOC to port Xen on the
> > BeagleBoard X15. You ended up CCed because you can provide feedback how to
> > proceed. Not because we wanted you to implemen
>>> On 19.06.19 at 16:30, wrote:
> On Wed, Jun 19, 2019 at 12:20:40PM +0100, Andrew Cooper wrote:
>> Since the MB1/MB2 builds aren't relocatable, I think we might be able to
>> get away with simply excluding them in the non-EFI build.
>
> Hm, OK. I'm slightly loss then. I've taken a look at the h
On Wed, Jun 19, 2019 at 07:08:52AM -0600, Jan Beulich wrote:
> >>> On 19.06.19 at 13:02, wrote:
> > After building the hypervisor binary. Note that the check is performed
> > by searching for the magic header value at the start of the binary.
> >
> > Signed-off-by: Roger Pau Monné
> > ---
> > Cc
On Wed, Jun 19, 2019 at 05:50:52AM -0600, Jan Beulich wrote:
> >>> On 19.06.19 at 13:02, wrote:
> > Or else clang adds a .init.rodata.cst8 section to the resulting object
> > file, which is not handled by the Xen linker script and can end up
> > before the text section which contains the headers,
On 15/03/2019 11:04, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -1924,6 +1924,7 @@ static bool vcpu_has(
> #define vcpu_has_avx512_bitalg() vcpu_has( 7, ECX, 12, ctxt, ops)
> #define vcpu_has_avx512_vpopcntdq() vcpu_
On 15/03/2019 11:04, Jan Beulich wrote:
> As in a few cases before, since the insns here and in particular their
> memory access patterns follow the AVX512_4FMAPS scheme, I didn't think
> it was necessary to add contrived tests specifically for them, beyond
> the Disp8 scaling ones.
>
> Signed-off-
On 15/03/2019 11:04, Jan Beulich wrote:
> --- a/tools/tests/x86_emulator/x86-emulate.h
> +++ b/tools/tests/x86_emulator/x86-emulate.h
> @@ -144,6 +144,7 @@ static inline bool xcr0_mask(uint64_t ma
> #define cpu_has_avx512vl (cp.feat.avx512vl && xcr0_mask(0xe6))
> #define cpu_has_avx512_vbmi (cp.
Signed-off-by: Alexandru Isaila
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ab32e7f409..78e35012e0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -412,6 +412,7 @@ F: unmodified_drivers/linux-2.6/
VM EVENT, MEM ACCESS and MONITOR
M: R
On 6/19/19 6:02 PM, Alexandru Stefan ISAILA wrote:
Signed-off-by: Alexandru Isaila
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ab32e7f409..78e35012e0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -412,6 +412,7 @@ F: unmodified_drivers/l
On Wed, Jun 19, 2019 at 06:57:05AM -0600, Jan Beulich wrote:
> >>> On 19.06.19 at 13:02, wrote:
> > If the hypervisor has been built with EFI support (ie: multiboot2).
> > This allows to position the .reloc section correctly in the output
> > binary, or else the linker might place .reloc before th
On 19/06/2019 15:33, Denis Obrezkov wrote:
Hi,
Hi Denis,
ср, 19 июн. 2019 г. в 14:01, Andrii Anisov :
On 18.06.19 19:19, Julien Grall wrote:
Denis (the author of the thread) is doing a GSOC to port Xen on the BeagleBoard
X15. You ended up CCed because you can provide feedback how to p
On 19.06.19 18:06, Julien Grall wrote:
Lastly, please clean-up the code and send the patch on xen-devel. I will have a
closer look at that time. Feel free to ping me on IRC if you have any doubt how
to proceed.
About the code: I think omap5_init_secondary() must be moved to the platform
co
flight 138020 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138020/
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 1
Hi,
On 19/06/2019 16:27, Andrii Anisov wrote:
On 19.06.19 18:06, Julien Grall wrote:
Lastly, please clean-up the code and send the patch on xen-devel. I will have
a closer look at that time. Feel free to ping me on IRC if you have any doubt
how to proceed.
About the code: I think omap5_ini
Hi Julien,
Julien Grall writes:
> On 19/06/2019 12:01, Julien Grall wrote:
>> Hi Volodymyr,
>>
>> On 11/06/2019 19:46, Volodymyr Babchuk wrote:
>>> diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig
>>> new file mode 100644
>>> index 00..5b829db2e9
>>> --- /dev/null
>>> +++
On Wed, Jun 19, 2019 at 12:20:40AM -0600, Jan Beulich wrote:
> >>> On 18.06.19 at 19:22, wrote:
> > On Tue, Jun 11, 2019 at 06:42:33AM -0600, Jan Beulich wrote:
> >> >>> On 10.06.19 at 18:28, wrote:
> >> > On 23/05/2019 13:18, Jan Beulich wrote:
> >> >> TBD: Can we set local_apic_timer_c2_ok to t
Answering to myself.
On 19/06/2019 10:02, Julien Grall wrote:
Hi,
On 6/19/19 8:28 AM, Jan Beulich wrote:
On 19.06.19 at 09:06, wrote:
branch xen-4.10-testing
xenbranch xen-4.10-testing
job test-armhf-armhf-xl-arndale
testid debian-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tr
On Fri, Jun 07, 2019 at 11:22:26AM +0200, Roger Pau Monne wrote:
> This reduces the number of parameters of the function to two, and
> simplifies some of the calling sites.
>
> Signed-off-by: Roger Pau Monné
As far as AMD IOMMU
Acked-by: Brian Woods
> ---
> Cc: Jan Beulich
> Cc: Andrew Coope
On Fri, Jun 07, 2019 at 11:22:27AM +0200, Roger Pau Monne wrote:
> This reduces the number of parameters of the function to two, and
> simplifies some of the calling sites.
>
> Signed-off-by: Roger Pau Monné
As far as AMD IOMMU
Acked-by: Brian Woods ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
On Fri, Jun 07, 2019 at 11:22:28AM +0200, Roger Pau Monne wrote:
> This reduces the number of parameters of the function to two, and
> simplifies some of the calling sites.
>
> Signed-off-by: Roger Pau Monné
As far as AMD IOMMU
Acked-by: Brian Woods ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
On Fri, Jun 07, 2019 at 11:22:31AM +0200, Roger Pau Monne wrote:
> This reduces the number of parameters of the function to two, and
> simplifies some of the calling sites.
>
> Signed-off-by: Roger Pau Monné
As far as AMD IOMMU
Acked-by: Brian Woods ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
On Fri, Jun 07, 2019 at 11:22:32AM +0200, Roger Pau Monne wrote:
> The new format specifier is '%pp', and prints a pci_sbdf_t using the
> seg:bus:dev.func format. Replace all SBDFs printed using
> '%04x:%02x:%02x.%u' to use the new format specifier.
>
> No functional change intended.
>
> Signed-o
flight 137930 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137930/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 137600
build-i386-xsm
On 19.06.19 18:32, Julien Grall wrote:
Regarding the placement of the code, I am still split between two minds (either
head.S or a new specific .S for omap). However, this could be discussed once
the patch is submitted.
IMHO, that is a pure platform specific code. FMPOV it should be an inli
On Thu, May 23, 2019 at 11:20:15AM +0100, Andy Cooper wrote:
> [CAUTION: External Email]
>
> The various pieces of the hypercall page infrastructure have grown
> organically over time and ended up in a bit of a mess.
>
> * Rename all functions to be of the form *_init_hypercall_page(). This
>
On Mon, Jun 17, 2019 at 01:54:39PM +0100, Andy Cooper wrote:
> VMExit doesn't switch all state. The FS/GS/TS/LDTR/GSBASE segment
> information, and SYSCALL/SYSENTER MSRs may still be cached in hardware, rather
> than up-to-date in the VMCB.
>
> Export svm_sync_vmcb() via svmdebug.h so svm_vmcb_du
On Mon, Jun 03, 2019 at 07:00:25AM -0600, Jan Beulich wrote:
> [CAUTION: External Email]
>
> This reverts commit b6bd02b7a877f9fac2de69e64d8245d56f92ab25. The change
> was redundant with amd_iommu_detect_one_acpi() already calling
> pci_ro_device().
>
> Signed-off-by: Jan Beulich
Acked-by: Bria
On 19/06/2019 17:10, Andrii Anisov wrote:
On 19.06.19 18:32, Julien Grall wrote:
Regarding the placement of the code, I am still split between two minds
(either head.S or a new specific .S for omap). However, this could be
discussed once the patch is submitted.
IMHO, that is a pure platfo
On Wed, 19 Jun 2019, Julien Grall wrote:
> > On 6/19/19 8:28 AM, Jan Beulich wrote:
> > > > > > On 19.06.19 at 09:06, wrote:
> > > > branch xen-4.10-testing
> > > > xenbranch xen-4.10-testing
> > > > job test-armhf-armhf-xl-arndale
> > > > testid debian-install
> > > >
> > > > Tree: linux git://x
Hello community,
Please find new version of OP-TEE patch series. This is the kind of
follow-up for the previous version, as most of the patches of the
previous version were commited.
This series includes leftovers of the prev. version and three new patches.
One of the new patches adds a way to de
This is workaround for OP-TEE 3.5. This is the first OP-TEE release
which supports virtualization, but there is no way to tell if
OP-TEE was built with that support enabled. We can probe for it
by calling SMC that is available only when OP-TEE is built with
virtualization support.
Signed-off-by: V
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.
'optee' enables access to the OP-TEE running on a host machine. This
requires special OP-TEE build with vir
Add basic information about the OP-TEE mediator and note about
dependency on virtualization-aware OP-TEE.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/tee/Kconfig | 5 +
1 file changed, 5 insertions(+)
diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig
index 5b829db2e9..b
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
Acked-by: Ian Jackson
---
This patch depends on patches to optee
It is nicer, when options for particular TEE mediators (currently,
OP-TEE only) are following generic "Enable TEE mediators support"
option in the menuconfig:
[*] Enable TEE mediators support
[ ] Enable OP-TEE mediator
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/Kconfig | 4 ++--
1 fi
flight 137917 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137917/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm 7 xen-boot fail REGR. vs. 137724
test-amd64-i386-xl
On Tue, Jun 18, 2019 at 1:10 PM Nicholas Tsirakis
wrote:
>
> Some logging messages made more sense as argo debug
> logs rather than standard Xen logs. Use argo_dprintk
> to only print this info if argo DEBUG is enabled.
>
> Signed-off-by: Nicholas Tsirakis
Reviewed-by: Christopher Clark
> ---
>
.data.read_mostly only needs separating from adjacent data by one cache line
to be effective, and placing it adjacent to .data.page_aligned fulfills this
requirement.
For ARM, .ex_table appears to be a vestigial remnant. Nothing in the
resulting build ever inspects or acts on the contents of the
.rodata.cst* sections are used for mergable constant data, and the clang/llvm
8 toolchain has been observed to create .rodata.cst8 in a default Xen build.
Unfortunately, this section (and its .init counterpart) aren't captured by
Xen's linker globs, and end up as orphaned sections.
Generalise the
Patch 1 came from Roger's observation that a clang/llvm-8 binary doesn't
actually boot. All other patches are ancillary cleanup.
I'm afraid that I thing we still have further problems:
andrewcoop@andrewcoop:/local/xen.git/xen$ readelf -WS xen-syms
There are 23 section headers, starting at offset
Neither of these should live in .data
* .data.schedulers is only ever read, so is moved into .rodata
* CONSTRUCTORS is only ever read, and only at boot, so is moved to beside
.init.rodata
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Stefano Stabell
* Drop .gnu.warning. Xen, not being a library, has no need for
__attribute__((__warning__("str"))) and isn't liable to ever gain such
annotations for link time warnings.
* Adjust the indentation of the start of ARM's .rodata section.
* Discard .discard on ARM.
Signed-off-by: Andrew Coope
flight 137978 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137978/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 334e1935b99ca663c8808df5f545d996b19ee345
baseline version:
xtf 5264341e4fb0bd69725416
flight 137929 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137929/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 137736
test-armhf-armhf-libvirt-raw 13 saveresto
flight 138039 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138039/
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 1
Hi Andrew,
On 6/19/19 9:11 PM, Andrew Cooper wrote:
.rodata.cst* sections are used for mergable constant data, and the clang/llvm
8 toolchain has been observed to create .rodata.cst8 in a default Xen build.
Unfortunately, this section (and its .init counterpart) aren't captured by
Xen's linker
Hi Andrew,
On 6/19/19 9:11 PM, Andrew Cooper wrote:
Neither of these should live in .data
* .data.schedulers is only ever read, so is moved into .rodata
* CONSTRUCTORS is only ever read, and only at boot, so is moved to beside
.init.rodata
Signed-off-by: Andrew Cooper
---
CC: Jan Beul
Optee breaks the build with:
optee.c: In function ‘translate_noncontig.isra.4’:
optee.c:743:38: error: ‘xen_data’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
xen_data->next_page_data = page_to_maddr(xen_pgs + 1);
^
op
On 6/19/19 9:11 PM, Andrew Cooper wrote:
.data.read_mostly only needs separating from adjacent data by one cache line
to be effective, and placing it adjacent to .data.page_aligned fulfills this
requirement.
For ARM, .ex_table appears to be a vestigial remnant. Nothing in the
resulting build
Hi,
On 6/19/19 9:11 PM, Andrew Cooper wrote:
* Drop .gnu.warning. Xen, not being a library, has no need for
__attribute__((__warning__("str"))) and isn't liable to ever gain such
annotations for link time warnings.
What if this is introduced? How do we catch it?
* Adjust the ind
1 - 100 of 126 matches
Mail list logo
