flight 128086 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128086/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2939283f2df3b8a0871e9bc7b2dd3718146318f4
baseline version:
ovmf e5cd809087e5710e019d2
>>> On 25.09.18 at 18:52, wrote:
> 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 whi
>>> On 25.09.18 at 18:14, wrote:
> On 18/09/18 13:28, Jan Beulich wrote:
>> @@ -1281,11 +1282,35 @@ static void load_segments(struct vcpu *n
>> struct cpu_user_regs *uregs = &n->arch.user_regs;
>> int all_segs_okay = 1;
>> unsigned int dirty_segment_mask, cpu = smp_processor_id();
>
flight 128049 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128049/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 128010
test-amd64-amd64-xl-qemuu-win7-amd6
>>> On 25.09.18 at 15:25, wrote:
> These are all VEX encoded, so the EVEX decoding logic continues to
> remain unused at this point.
>
> The new testcase is deliberately coded in assembly, as a C one would
> have become almost unreadable due to the overwhelming amount of
> __builtin_...() that wo
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 git://xenbits.xen.org/qemu-xen-tradit
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 3cb0a311cb7e747d7be5c
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 ASSE
> 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, re
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 | 3
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.
>
> This
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);
> }
>
> they
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.
>
> Let
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
XENMEM_acquire_resource.
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 save
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 tree
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 opti
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 av
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 re-d
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 ++-
drivers/xen/biomerge.c
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 i
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
+++ b/dri
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
https://lists.xenproject.org/mailman/listinfo/xen
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 p
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 thi
On Tue, 4 Sep 2018, Julien Grall wrote:
> vgic_v3_its_free_domain may be called before vgic_v3_its_init_domain if
> the vGIC was failing to initalize itself. This means the list would be
> unitialized and result in a crash.
>
> Thankfully, we only allow ITS for the hardware domain. So the crash is
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 17634d026f968c404b039
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 xenvif_set_hash_
On 10/09/18 11:00, Jan Beulich wrote:
>
> + ASM_OUTPUT2([ma] "=&r" (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 ca
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 instru
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
x
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 ++--
xen/a
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 dele
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
performan
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") ind
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 gmf
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 littl
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 possible
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
> >> --- a/
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
http://www.xenproject.org/downloads/xen-archives/xen-pr
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
test-amd
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
http://www.xenproject.org/downloads/xen-archives/xen
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 t
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
>> +++ b/xen/include/public/hvm/hvm_op
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 che
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 ma
Sometimes it is handy to create a container and play with its setup
manually as root.
Signed-off-by: Wei Liu
---
automation/build/README.md | 2 ++
automation/scripts/containerize | 8 +++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/automation/build/README.md b/automa
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 av
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), b
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 between)
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.
--- a/tools/tests/x86_emulator
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.
--- a/tools/tests/x86_em
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
+++ b/tools/t
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.
Signed-off-b
... 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() to
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[]
INS
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 avx512f_128[]
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)
./$(TA
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 @@ st
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
+++ b/to
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).
Signed-off-b
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 := 4
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 @@ stati
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: $(TARGET)
Also correct the comment of the AVX form of VINSERTPS.
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
@@ -202,6 +202,7 @@ static const struct test avx512f_all[] =
static const struct tes
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, 1
1 - 100 of 178 matches
Mail list logo
