flight 128087 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128087/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 127928
Tests which
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-qemut-rhel6hvm-intel
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
Hi Boris,
On 09/26/2018 04:19 AM, Boris Ostrovsky wrote:
> On 9/25/18 1:14 AM, Dongli Zhang wrote:
>>
>> So far we have: (1) domain hash table, (2) domain list (where duplicate
>> entries
>> may exist) and (3) purge list.
>>
>> Can I assume you would like to discard the domain list and only keep
flight 128080 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128080/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 127928
Tests which
flight 128082 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128082/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e5cd809087e5710e019d2766fab13c59a2e2ac28
baseline version:
ovmf
This run is configured for baseline tests only.
flight 75290 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75290/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Tuesday, September 25, 2018 7:03 PM
>
> Move p2m_{get/set}_suppress_ve() to p2m.c, replace incorrect
> ASSERT() in p2m-pt.c (since a guest can run in shadow mode even on
> a system with virt exceptions, which would trigger the
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Friday, September 21, 2018 11:21 PM
>
> And just rely on arch_iommu_hwdom_init to setup the correct inclusive
> mappings as it's done for Intel.
>
> AMD has code in amd_iommu_hwdom_init to setup inclusive mappings up
> to
> max_pdx,
On Tue, 25 Sep 2018, Julien Grall wrote:
> call_smc is a subset of arm_smccc_smc. Rather than having 2 methods to
> do SMCCC call, replace all call to the former by the later.
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/Makefile| 1 -
> xen/arch/arm/platforms/exynos5.c |
On Tue, 25 Sep 2018, Julien Grall wrote:
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> Changes in v2:
> - Invert the condition
> - Add missing includes
> ---
> xen/arch/arm/psci.c | 4
> xen/include/asm-arm/cpufeature.h | 3 ++-
>
On Tue, 25 Sep 2018, Julien Grall wrote:
> From: Volodymyr Babchuk
>
> Existing SMC wrapper call_smc() allows only 4 parameters and
> returns only one value. This is enough for existing
> use in PSCI code, but TEE mediator will need a call that is
> fully compatible with ARM SMCCC v1.0.
>
>
flight 128075 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128075/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 127928
Tests which
On Tue, 25 Sep 2018, Julien Grall wrote:
> From: Marc Zyngier
>
> If someone has the silly idea to write something along those lines:
>
> extern u64 foo(void);
>
> void bar(struct arm_smccc_res *res)
> {
> arm_smccc_1_1_smc(0xbad, foo(), res);
> }
>
>
On Tue, 25 Sep 2018, Julien Grall wrote:
> From: Marc Zyngier
>
> An unfortunate consequence of having a strong typing for the input
> values to the SMC call is that it also affects the type of the
> return values, limiting r0 to 32 bits and r{1,2,3} to whatever
> was passed as an input.
>
>
Hi Paul,
I am looking at porting the IOREQ server infrastructure on Arm. I didn't
need much modification to make it run for Arm. Although, the
implementation could be simplified over the x86 implementation.
I noticed some issue while trying to implement the hypercall
On Tue, Sep 25, 2018 at 03:19:31PM +0100, Wei Liu wrote:
> Sometimes it is handy to create a container and play with its setup
> manually as root.
>
> Signed-off-by: Wei Liu
Acked-by: Doug Goldstein
Thanks for the improvement!
___
Xen-devel mailing
flight 128033 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128033/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 127997
test-armhf-armhf-libvirt 14
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
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
This run is configured for baseline tests only.
flight 75286 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75286/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
On 9/25/18 7:36 AM, Jason Andryuk wrote:
> XEN_BACKEND doesn't actually depend on XEN_DOM0. DomUs can serve
> backends to other DomUs. One example is a service VM providing network
> backends.
>
> The original Kconfig defaulted Dom0 to y and it could be disabled. DomU
> could not select the
On Tue, 4 Sep 2018, Andrew Cooper wrote:
> On 04/09/18 20:35, Julien Grall wrote:
> > Hi,
> >
> > On 09/04/2018 08:21 PM, Julien Grall wrote:
> >> A follow-up patch will require to know the number of vCPUs when
> >> initializating the vGICv3 domain structure. However this information is
> >> not
On Tue, 4 Sep 2018, Julien Grall wrote:
> At the moment, Xen is assuming the hardware domain will have the same
> number of re-distributor regions as the host. However, as the
> number of CPUs or the stride (e.g on GICv4) may be different we end up
> exposing regions which does not contain any
Nothing Xen specific in these headers, which get included from a lot
of code in the kernel. So prune the includes and move them to the
Xen-specific files that actually use them instead.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/io.h | 1 -
arch/arm64/include/asm/io.h
Take the Xen check into the core code instead of delegating it to
the architectures.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/io.h | 3 ---
arch/arm64/include/asm/io.h | 3 ---
arch/x86/include/asm/io.h | 3 ---
block/blk.h | 7 ++-
Having multiple externs in arch headers is not a good way to provide
a common interface.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/io.h | 3 ---
arch/arm64/include/asm/io.h | 3 ---
arch/x86/include/asm/io.h | 4
include/xen/xen.h | 4
4 files changed, 4
BIOVEC_PHYS_MERGEABLE is only called from core block code.
Signed-off-by: Christoph Hellwig
---
drivers/xen/biomerge.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/xen/biomerge.c b/drivers/xen/biomerge.c
index 55ed80c3a17c..399c4e30f723 100644
--- a/drivers/xen/biomerge.c
+++
Hi Jens,
this series moves Xen special handling of block merges from arch hooks
into common code. A previous version has been reviewed by Boris.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/io.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 3c835d6263fa..e58ca25eddb7 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -459,13 +459,6
On Mon, Sep 24, 2018 at 10:25:45AM -0400, Boris Ostrovsky wrote:
> Konrad is out this (and last) week, this looks good to me. Including
> patch 13, although it's hard to say whether it may break some builds.
I fixed up everything the buildbot reported (which was quite a bit
as you can see in the
On 9/25/18 1:14 AM, Dongli Zhang wrote:
>
> So far we have: (1) domain hash table, (2) domain list (where duplicate
> entries
> may exist) and (3) purge list.
>
> Can I assume you would like to discard the domain list and only keep domain
> hash
> table and purge list?
Yes, that's what I was
flight 128062 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128062/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 127928
Tests which
flight 75288 examine real [real]
http://osstest.xensource.com/osstest/logs/75288/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
flight 128058 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128058/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3cb0a311cb7e747d7be5c5076d0fff76ad256d2b
baseline version:
ovmf
Hi Roger,
Sorry for the late reply.
On 09/03/2018 03:40 PM, Roger Pau Monné wrote:
On Mon, Sep 03, 2018 at 12:15:16PM +0100, Julien Grall wrote:
On 03/09/18 12:09, Julien Grall wrote:
On 23/08/18 08:58, Roger Pau Monné wrote:
On Wed, Aug 22, 2018 at 06:48:05PM +0100, Julien Grall wrote:
On Tue 25-09-18 11:59:09, Vlastimil Babka wrote:
[...]
> This seems like almost complete copy of __free_pages_boot_core(), could
> you do some code reuse instead? I think Michal Hocko also suggested that.
Yes, please try to reuse as much code as possible
--
Michal Hocko
SUSE Labs
flight 128057 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128057/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 127928
build-amd64
[Adding a few people to the Cc-list. See below...]
On Tue, 2018-09-25 at 12:15 +0100, Julien Grall wrote:
> Hi Dario,
>
Hi,
> On 09/25/2018 10:02 AM, Dario Faggioli wrote:
> > On Mon, 2018-09-24 at 22:46 +0100, Julien Grall wrote:
> > >
> > > Per my understanding of call_rcu, the calls will be
From: "Jan Beulich"
Date: Tue, 25 Sep 2018 02:11:33 -0600
> First and foremost the fix for XSA-270. On top of that further changes
> which looked desirable to me while investigating that XSA.
>
> 1: fix input validation in xenvif_set_hash_mapping()
> 2: validate queue numbers in
On 10/09/18 11:00, Jan Beulich wrote:
>
> + ASM_OUTPUT2([ma] "=" (ma), [off] "+r" (va)),
> + [mask] "m" (ma_real_mask),
> + [shift] "m" (pfn_pdx_hole_shift),
> + [bmask] "m" (ma_va_bottom_mask),
> +
From: Volodymyr Babchuk
Existing SMC wrapper call_smc() allows only 4 parameters and
returns only one value. This is enough for existing
use in PSCI code, but TEE mediator will need a call that is
fully compatible with ARM SMCCC v1.0.
This patch adds a wrapper for both arm32 and arm64. In the
From: Marc Zyngier
An unfortunate consequence of having a strong typing for the input
values to the SMC call is that it also affects the type of the
return values, limiting r0 to 32 bits and r{1,2,3} to whatever
was passed as an input.
Let's turn everything into "unsigned long", which satisfies
Some capababilities are set right during boot and will never change
afterwards. At the moment, the function cpu_have_caps will check whether
the cap is enabled from the memory.
It is possible to avoid the load from the memory by using an
ALTERNATIVE. With that the check is just reduced to 1
Hi all,
This patch series contains fixup and improvement for the SMCCC subsystem.
Patch #1 - #2 are candidates for backporting.
Cheers,
Julien Grall (3):
xen/arm: cpufeature: Add helper to check constant caps
xen/arm: smccc: Add wrapper to automatically select the calling
convention
call_smc is a subset of arm_smccc_smc. Rather than having 2 methods to
do SMCCC call, replace all call to the former by the later.
Signed-off-by: Julien Grall
---
xen/arch/arm/Makefile| 1 -
xen/arch/arm/platforms/exynos5.c | 3 ++-
xen/arch/arm/platforms/seattle.c | 4 ++--
Signed-off-by: Julien Grall
---
Changes in v2:
- Invert the condition
- Add missing includes
---
xen/arch/arm/psci.c | 4
xen/include/asm-arm/cpufeature.h | 3 ++-
xen/include/asm-arm/smccc.h | 11 +++
3 files changed, 17 insertions(+), 1
From: Marc Zyngier
If someone has the silly idea to write something along those lines:
extern u64 foo(void);
void bar(struct arm_smccc_res *res)
{
arm_smccc_1_1_smc(0xbad, foo(), res);
}
they are in for a surprise, as this gets compiled as:
On 29/08/18 17:03, Jan Beulich wrote:
> Eliminates a couple of branches in particular from the context switch
> path.
>
> Signed-off-by: Jan Beulich
I've already expressed a dis-inclination to this patch, because it looks
like a micro-optimisation which won't actually affect measureable
On 18/09/18 13:41, Jan Beulich wrote:
> Ping?
You're very unlikely to get any reply when I'm
>
On 11.09.18 at 10:20, wrote:
> On 29.08.18 at 14:36, wrote:
>>> On 21/08/18 11:44, Jan Beulich wrote:
While commit 2a3b34ec47 ("x86/spec-ctrl: Yet more fixes for xpti=
parsing")
On 18/09/18 13:44, Jan Beulich wrote:
On 10.09.18 at 16:02, wrote:
>> Rather than unconditionally using vCPU 0, use the current vCPU if the
>> subject domain is the current one.
>>
>> Signed-off-by: Jan Beulich
What improvement is this intended to bring?
Shadows are per-domain, and the
On 18/09/18 13:28, Jan Beulich wrote:
> Besides the mentioned oddity with measured performance, I've also
> noticed a significant difference (of at least 150 clocks) between
> measuring immediately around the calls to svm_load_segs() and measuring
> immediately inside the function.
This is a
On 30/08/18 18:43, Volodymyr Babchuk wrote:
Hi Julien,
Hi,
On 24.08.18 19:58, Julien Grall wrote:
Some capababilities are set right during boot and will never change
afterwards. At the moment, the function cpu_have_caps will check whether
the cap is enabled from the memory.
It is
On Tue, Sep 25, 2018 at 9:04 AM Razvan Cojocaru
wrote:
>
> On 9/19/18 6:29 PM, Tamas K Lengyel wrote:
> > On Mon, Sep 3, 2018 at 9:47 AM Adrian Pop wrote:
> >> diff --git a/xen/include/public/hvm/hvm_op.h
> >> b/xen/include/public/hvm/hvm_op.h
> >> index bbba99e5f5..bbb0aa984a 100644
> >> ---
All,
I am pleased to announce the release of Xen 4.9.3. This is
available immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.9
(tag RELEASE-4.9.3) or from the XenProject download page
flight 128022 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128022/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR.
vs. 125898
All,
I am pleased to announce the release of Xen 4.10.2. This is
available immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.10
(tag RELEASE-4.10.2) or from the XenProject download page
Hi,
On 25/09/18 14:02, Andrew Cooper wrote:
On 25/09/18 13:56, Jan Beulich wrote:
The removal of the VLA there has changed sizeof() for the array.
Signed-off-by: Jan Beulich
---
Untested; purely based on looking at the code.
I have tested it, it resolved the boot.
Oops. Yes - that will
On 25/09/18 13:41, Jan Beulich wrote:
On 20.09.18 at 14:41, wrote:
>> On 13/09/18 11:12, Jan Beulich wrote:
>>> The function does two translations in one go for a single guest access.
>>> Any failure of the first translation step (guest linear -> guest
>>> physical), resulting in #PF, ought
flight 128041 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128041/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 123814
build-amd64-libvirt
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 25 September 2018 15:27
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
> ; George Dunlap
> Subject: [PATCH v3 4/4] x86/HVM: prefill cache with PDPTEs when possible
>
> Since strictly speaking it is incorrect
This run is configured for baseline tests only.
flight 75285 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/75285/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
On 9/19/18 6:29 PM, Tamas K Lengyel wrote:
> On Mon, Sep 3, 2018 at 9:47 AM Adrian Pop wrote:
>> diff --git a/xen/include/public/hvm/hvm_op.h
>> b/xen/include/public/hvm/hvm_op.h
>> index bbba99e5f5..bbb0aa984a 100644
>> --- a/xen/include/public/hvm/hvm_op.h
>> +++
On 09/25/2018 12:02 PM, Razvan Cojocaru wrote:
> Move p2m_{get/set}_suppress_ve() to p2m.c, replace incorrect
> ASSERT() in p2m-pt.c (since a guest can run in shadow mode even on
> a system with virt exceptions, which would trigger the ASSERT()),
> move the VMX-isms (cpu_has_vmx_virt_exceptions
On 09/25/2018 12:02 PM, Ian Jackson wrote:
> George Dunlap writes ("Re: [PATCH v2 6/6] RFC: tools/dm_restrict: Enable QEMU
> sandboxing"):
>> On 09/24/2018 12:21 PM, Ian Jackson wrote:
>>> Just noticed this, but: OMG no `set -e'.
>>> You probably want `set -o pipefail' too.
>>
>> `set -e` never
Since strictly speaking it is incorrect for guest_walk_tables() to read
L3 entries during PAE page walks (they get loaded from memory only upon
CR3 loads and certain TLB flushes), try to overcome this where possible
by pre-loading the values from hardware into the cache. Sadly the
information is
Emulation requiring device model assistance uses a form of instruction
re-execution, assuming that the second (and any further) pass takes
exactly the same path. This is a valid assumption as far use of CPU
registers goes (as those can't change without any other instruction
executing in between),
The caching isn't actually implemented here, this is just setting the
stage.
Touching these anyway also
- make their return values gfn_t
- gva -> gla in their names
- name their input arguments gla
At the use sites do the conversion to gfn_t as suitable.
Signed-off-by: Jan Beulich
Reviewed-by:
The caching isn't actually implemented here, this is just setting the
stage.
Signed-off-by: Jan Beulich
Reviewed-by: Paul Durrant
Reviewed-by: Wei Liu
---
v2: Don't wrongly use top_gfn for non-root gpa calculation. Re-write
cache entries after setting A/D bits (an alternative would be to
On Mon, Sep 24, 2018 at 01:41:12PM -0500, Doug Goldstein wrote:
> On Mon, Sep 24, 2018 at 05:18:29PM +0100, Wei Liu wrote:
> > Sometimes it is handy to create a container and play as root with its
> > setup manually.
> >
> > Signed-off-by: Wei Liu
> > ---
> > automation/scripts/containerize | 8
flight 128052 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128052/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 127928
Tests which
Emulation requiring device model assistance uses a form of instruction
re-execution, assuming that the second (and any further) pass takes
exactly the same path. This is a valid assumption as far as use of CPU
registers goes (as those can't change without any other instruction
executing in
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 Beulich
---
v4: New.
---
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.
Signed-off-by: Jan Beulich
---
v4: New.
---
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
---
v4: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++
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.
Slightly adjust the scalar to_int() in the test harness, to increase the
chances of the operand ending up in memory.
... 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 to
pre-existing code, but allow decode_disp8scale()
VCVTPS2PD, sharing its main opcode with others, needs a "manual"
override of disp8scale.
The simd_size change for twobyte_table[0x5a] is benign to pre-existing
code, but allows decode_disp8scale() to work as is here.
Also correct the comment on an AVX counterpart.
Signed-off-by: Jan Beulich
No further test harness additions - what is there is good enough for
these rather "regular" insns.
Signed-off-by: Jan Beulich
---
v4: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -296,6 +296,10 @@ static const struct test avx512bw_all[]
Signed-off-by: Jan Beulich
---
v4: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -166,6 +166,10 @@ static const struct test avx512f_all[] =
INSN(pcmpu,66, 0f3a, 1e,vl, dq, vl),
INSN(permi2, 66, 0f38, 76,vl,
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 than the overrides, as the
compiler already makes
No explicit test harness additions other than the overrides, as the
compiler already makes use of the insns.
Signed-off-by: Jan Beulich
---
v4: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -242,6 +242,16 @@ static const struct test
Test various of the insns which have been implemented already.
Signed-off-by: Jan Beulich
---
v4: Wrap OVR(pmullq) in __AVX512VL__ conditional.
v3: New.
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -13,7 +13,7 @@ all: $(TARGET)
run: $(TARGET)
Test various of the insns which have been implemented already.
Signed-off-by: Jan Beulich
---
v4: Add __AVX512VL__ conditional around majority of OVR() additions.
Correct eq() for 1- and 2-byte cases.
v3: New.
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
Also include shuff{32x4,64x2} as being very similar to shufi{32x4,64x2}.
Signed-off-by: Jan Beulich
---
v4: Move OVR() addition into __AVX512VL__ conditional. Correct comments.
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -203,6 +203,7 @@
Entries to the tables in evex-disp8.c are added despite these insns not
allowing for memory operands, with the goal of the tables giving a
complete picture of the supported EVEX-encoded insns in the end.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++
Take the liberty and also correct the (public interface) name of the
AVX512_VBMI feature flag, on the assumption that no external consumer
has actually been using that flag so far. Furthermore make it have
AVX512BW instead of AVX512F as a prerequisite, for requiring full
64-bit mask registers (the
There's once again one extra twobyte_table[] entry which gets its Disp8
shift value set right away without getting support implemented just yet,
again to avoid needlessly splitting groups of entries.
Signed-off-by: Jan Beulich
---
v4: Move OVR() additions into __AVX512VL__ conditional.
v3: New.
Note that the vpmov{,s,us}{d,q}w table entries in evex-disp8.c are
slightly different from what one would expect, due to them requiring
EVEX.W to be zero.
Signed-off-by: Jan Beulich
---
v4: Also #UD when evex.z is set with a memory operand.
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
Note that the testing in simd.c doesn't really follow the ISA extension
pattern - to fit the scheme, extensions from byte and word granular
vectors can (currently) sensibly only happen in the AVX512BW case (and
hence respective abstraction macros will be added there rather than
here).
Test the 128- and 256-bit variants of the insns which have been
implemented already.
Signed-off-by: Jan Beulich
---
v4: Move OVR() additions into __AVX512VL__ conditional.
v3: New.
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -60,7 +60,7 @@ avx2-sg-flts :=
Note that the pbroadcastw table entry in evex-disp8.c is slightly
different from what one would expect, due to it requiring EVEX.W to be
zero.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -153,6 +153,9 @@
Test various of the insns which have been implemented already.
Signed-off-by: Jan Beulich
---
v4: Make eq() also work for 4- and 8-byte integer element sizes.
v3: New.
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -13,7 +13,7 @@ all: $(TARGET)
run:
Signed-off-by: Jan Beulich
---
v4: Make use of d8s_dq64.
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -201,6 +201,7 @@ static const struct test avx512f_all[] =
};
static const struct test avx512f_128[] = {
+INSN(extractps, 66, 0f3a,
Note that simd_packed_fp for the opcode space 0f38 major opcodes 14 and
15 is not really correct, but sufficient for the purposes here. Further
adjustments may later be needed for the down conversion unsigned
saturating VPMOV* insns, first and foremost for the different Disp8
scaling those ones
This eliminates a separate case block here, and allows to get away with
fewer new ones when adding AVX512 vector shifts.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -366,19 +366,19 @@ static const struct
Note: vpadd* / vpsub* et al are put at seemingly the wrong slot of the
big switch(). This is in anticipation of adding e.g. vpunpck* to those
groups (see the legacy/VEX encoded case labels nearby to support this).
Signed-off-by: Jan Beulich
---
v4: Move a case block further down.
v3: New.
---
Include VPTEST{,N}M{B,D,Q,W} as once again possibly used by the compiler
for comparison against all-zero vectors.
Also table entries for a few more insns get their .d8s field set right
away, again in order to not split and later re-combine the groups.
Signed-off-by: Jan Beulich
---
v3: New.
In preparation for sensible to-boolean conversion on AVX512, wrap
another abstraction function around the present to_bool( == ), to
get rid of the open-coded == (which will get in the way of using
built-in functions instead). For the future AVX512 use scalar operands
can't be used then anymore:
Signed-off-by: Jan Beulich
---
v4: Add missing avx512_vlen_check().
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -96,6 +96,8 @@ static const struct test avx512f_all[] =
INSN_FP(add, 0f, 58),
INSN(broadcastss, 66, 0f38,
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -94,6 +94,7 @@ enum esz {
static const struct test avx512f_all[] = {
INSN_FP(add, 0f, 58),
+INSN(broadcastss, 66, 0f38, 18,el, d,
Plus vpternlog{d,q} as being extensively used by the compiler, in order
to facilitate test enabling in the harness as soon as possible. Also the
twobyte_table[] entries for a few more insns get their .d8s field set
right away, in order to not split and later re-combine the groups.
Signed-off-by:
1 - 100 of 171 matches
Mail list logo
