On 20.06.19 02:30, Christopher Clark wrote:
This RFC patch series adds a new hypervisor interface to support running
a set of PV front end device drivers within dom0 of a guest Xen running
on Xen.
A practical deployment scenario is a system running PV guest VMs that use
unmodified Xen PV device
flight 137986 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137986/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs.
133580
build-armhf
branch xen-4.9-testing
xenbranch xen-4.9-testing
job test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-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.
Provides proxying to the host hypervisor for the XENMEM_add_to_physmap op
only for the XENMAPSPACE_shared_info and XENMAPSPACE_grant_table spaces,
for DOMID_SELF.
Both compat and native entry points.
Signed-off-by: Christopher Clark
---
tools/flask/policy/modules/dom0.te | 1 +
xen/arch/x86/g
Provides proxying to the host hypervisor for SCHEDOP_shutdown op.
Signed-off-by: Christopher Clark
---
tools/flask/policy/modules/dom0.te | 1 +
xen/arch/x86/guest/hypercall_page.S | 1 +
xen/arch/x86/guest/xen-nested.c | 25 +
xen/arch/x86/hypercall.c|
Provides proxying to the host hypervisor for these event channel ops:
* EVTCHNOP_alloc_unbound
* EVTCHNOP_bind_vcpu
* EVTCHNOP_close
* EVTCHNOP_send
* EVTCHNOP_unmask
Introduces a new XSM access vector class for policy control applied to this
operation: nested_event.
This is required because
Provides proxying to the host hypervisor for HVMOP_get_param and
HVMOP_set_param ops.
Signed-off-by: Christopher Clark
---
tools/flask/policy/modules/dom0.te | 1 +
xen/arch/x86/guest/hypercall_page.S | 1 +
xen/arch/x86/guest/xen-nested.c | 42 +
xen/arch/x86/
Provides proxying to the host hypervisor for XENVER_version and
XENVER_get_features ops.
The nested PV interface is only enabled when Xen is not running as
either the PV shim or booted as PVH, since the initialization performed
within the hypervisor in those cases - ie. as a Xen guest - claims res
Add Kconfig option XEN_DETECT for:
"Support for Xen detecting when it is running under Xen".
If running under Xen is detected, a boot message will indicate the
hypervisor version obtained from cpuid.
Update the XEN_GUEST Kconfig option text to reflect its current
purpose:
"Common PVH_GUEST and
This RFC patch series adds a new hypervisor interface to support running
a set of PV front end device drivers within dom0 of a guest Xen running
on Xen.
A practical deployment scenario is a system running PV guest VMs that use
unmodified Xen PV device drivers, on a guest Xen hypervisor with a dom0
Expand XSM control to the full set of Xen version ops, to allow for
granular control over ops a domain is allowed to issue for the nested case.
Applies const to args of xsm_default_action.
Signed-off-by: Christopher Clark
---
tools/flask/policy/modules/dom0.te | 7 ++-
tools/flask/po
Provides proxying to the host hypervisor for the GNTTABOP_query_size op.
Signed-off-by: Christopher Clark
---
tools/flask/policy/modules/dom0.te | 1 +
xen/arch/x86/guest/hypercall_page.S | 1 +
xen/arch/x86/guest/xen-nested.c | 37 +
xen/arch/x86/hypercall.c
Move some logic from: xen/arch/x86/guest/xen.c
into a new file: xen/arch/x86/guest/xen-guest.c
xen.c then contains the functions for basic Xen detection and
xen-guest.c implements the intended behaviour changes when Xen is running
as a guest.
Since CONFIG_XEN_GUEST must currently be defined for a
flight 138054 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138054/
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 6/19/19 11:06 PM, Denis Obrezkov wrote:
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Missing kernel boot module?
(XEN)
(XEN)
(XEN) Panic on CPU 0:
(XEN) Could not set up DOM0 guest OS
(XEN)
You probably haven't set
Hi,
On 6/19/19 10:51 PM, Denis Obrezkov wrote:
Hi,
On 6/19/19 5:32 PM, Julien Grall wrote:
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 fr
Hi,
On 6/19/19 5:06 PM, Julien Grall wrote:
>
>
> 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
>>
On Wed, 19 Jun 2019, Julien Grall wrote:
> On 6/19/19 10:47 PM, Stefano Stabellini wrote:
> > On Wed, 19 Jun 2019, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > Title: You should at least mention this is for op-tee.
> > >
> > > Also, mostly likely the sha1 is too small and likely to match mul
On 6/19/19 10:47 PM, Stefano Stabellini wrote:
On Wed, 19 Jun 2019, Julien Grall wrote:
Hi Stefano,
Title: You should at least mention this is for op-tee.
Also, mostly likely the sha1 is too small and likely to match multiple commit
in the future. So you want to specify the title of the comm
Hi,
On 6/19/19 5:32 PM, Julien Grall wrote:
> 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
On Wed, 19 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> Title: You should at least mention this is for op-tee.
>
> Also, mostly likely the sha1 is too small and likely to match multiple commit
> in the future. So you want to specify the title of the commit.
>
> On 6/19/19 10:24 PM, Stefano St
On 19/06/2019 22:28, Julien Grall wrote:
> 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
flight 137943 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137943/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8a08dc5486f1a96c91b0ce86fc88a674ca0d8272
baseline version:
ovmf a860eb9668c1a2ad87587
Hi Stefano,
Title: You should at least mention this is for op-tee.
Also, mostly likely the sha1 is too small and likely to match multiple
commit in the future. So you want to specify the title of the commit.
On 6/19/19 10:24 PM, Stefano Stabellini wrote:
Optee breaks the build with:
optee.c
On 19/06/2019 22:30, Julien Grall wrote:
> 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 th
flight 137925 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137925/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
Tests which did not
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
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
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
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
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
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
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 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
* 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
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
.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
.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
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
> ---
>
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
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
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
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
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
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 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 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 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 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
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 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
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: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: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: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
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 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
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
>>> +++
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
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
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
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 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 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
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 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.
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/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 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 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 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
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 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
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
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 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
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:
> 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
>>> 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 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
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 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
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: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
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:
> 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
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 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
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: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
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 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 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: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/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/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
1 - 100 of 126 matches
Mail list logo
