This run is configured for baseline tests only.
flight 75282 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75282/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
>>> On 25.09.18 at 01:17, wrote:
> On Mon, Sep 24, 2018 at 5:06 AM Jan Beulich wrote:
>>
>> >>> On 21.09.18 at 21:25, wrote:
>> >
>> > Adds necessary (previously missing) #include to x86-emulate.h
>>
>> Why "necessary (previously missing)"? I can't seem to be able to
>> spot anything in that he
(re-send just to satisfy the apparent need for "net" inside the square brackets)
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 xenv
Both len and off are frontend specified values, so we need to make
sure there's no overflow when adding the two for the bounds check. We
also want to avoid undefined behavior and hence use off to index into
->hash.mapping[] only after bounds checking. This at the same time
allows to take care of no
Checking them before the grant copy means nothing as to the validity of
the incoming request. As we shouldn't make the new data live before
having validated it, introduce a second instance of the mapping array.
Signed-off-by: Jan Beulich
Reviewed-by: Paul Durrant
---
drivers/net/xen-netback/com
There's no guarantee that the mapping array doesn't cross a page
boundary. Use a second grant copy operation if necessary.
Signed-off-by: Jan Beulich
Acked-by: Wei Liu
Reviewed-by: Paul Durrant
---
drivers/net/xen-netback/hash.c | 25 ++---
1 file changed, 18 insertions(+
>>> On 24.09.18 at 18:49, wrote:
> From: "Jan Beulich"
> Date: Mon, 24 Sep 2018 01:43:50 -0600
>
>> Dave? I notice none of the patches is in 4.19-rc5, not even the security
>> fix, the advisory for which had gone public over a month ago.
>
> If it's not in my patchwork queue, you have to resend
flight 128045 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128045/
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
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 checks) to
p2m_ept_{get/set}_entry(), and fix locking code
flight 128010 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128010/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 126861
test-amd64-amd64-xl-qemuu-win7-amd6
On Mon, 2018-09-24 at 22:46 +0100, Julien Grall wrote:
> On 09/21/2018 05:20 PM, Dario Faggioli wrote:
> >
> > What I'm after, is how log, after domain_destroy(),
> > complete_domain_destroy() is called, and whether/how it relates the
> > the
> > grace period idle timer we've added in the RCU code
This is useful so HVMOP_altp2m_vcpu_enable_notify will fail and not
silently succeed. It save a call to HVMOP_altp2m_set_suppress_ve.
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/hvm/hvm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm
Reading through the code and studying how mem_hotplug_lock is to be used,
I noticed that there are two places where we can end up calling
device_online()/device_offline() - online_pages()/offline_pages() without
the mem_hotplug_lock. And there are other places where we call
device_online()/device_o
remove_memory() is exported right now but requires the
device_hotplug_lock, which is not exported. So let's provide a variant
that takes the lock and only export that one.
The lock is already held in
arch/powerpc/platforms/pseries/hotplug-memory.c
drivers/acpi/acpi_memhotplug.c
device_online() should be called with device_hotplug_lock() held.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Rashmica Gupta
Cc: Balbir Singh
Cc: Michael Neuling
Reviewed-by: Pavel Tatashin
Reviewed-by: Rashmica Gupta
Signed-off-by: David Hildenbrand
---
arch/p
add_memory() currently does not take the device_hotplug_lock, however
is aleady called under the lock from
arch/powerpc/platforms/pseries/hotplug-memory.c
drivers/acpi/acpi_memhotplug.c
to synchronize against CPU hot-remove and similar.
In general, we should hold the device_hotplug
There seem to be some problems as result of 30467e0b3be ("mm, hotplug:
fix concurrent memory hot-add deadlock"), which tried to fix a possible
lock inversion reported and discussed in [1] due to the two locks
a) device_lock()
b) mem_hotplug_lock
While add_memory() first takes b), f
Let's document the magic a bit, especially why device_hotplug_lock is
required when adding/removing memory and how it all play together with
requests to online/offline memory from user space.
Cc: Jonathan Corbet
Cc: Michal Hocko
Cc: Andrew Morton
Reviewed-by: Pavel Tatashin
Reviewed-by: Rashmi
Let's perform all checking + offlining + removing under
device_hotplug_lock, so nobody can mess with these devices via
sysfs concurrently.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Rashmica Gupta
Cc: Balbir Singh
Cc: Michael Neuling
Reviewed-by: Pavel Tatashin
R
On 25/09/18 10:10, Alexandru Isaila wrote:
> This is useful so HVMOP_altp2m_vcpu_enable_notify will fail and not
> silently succeed. It save a call to HVMOP_altp2m_set_suppress_ve.
>
> Signed-off-by: Alexandru Isaila
In principle we could emulate this by having .sve becoming an
EPT_MISCONFIG, but
>>> On 24.09.18 at 19:27, wrote:
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 25.09.18 at 01:22, wrote:
> --- a/tools/tests/x86_emulator/wrappers.c
> +++ b/tools/tests/x86_emulator/wrappers.c
> @@ -1,5 +1,4 @@
> #include
> -#include
>
> #define WRAP(x) typeof(x) emul_##x
> #include "x86-emulate.h"
Ah, I see now why you can't take care of the inclusion here.
>>> On 21.09.18 at 17:20, wrote:
> 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, remove this since it's now a duplication of
> arch_iommu_hwdom_init. No
On 9/25/18 7:42 AM, Arun KS wrote:
> When free pages are done with higher order, time spend on
> coalescing pages by buddy allocator can be reduced. With
> section size of 256MB, hot add latency of a single section
> shows improvement from 50-60 ms to less than 1 ms, hence
> improving the hot add l
On Tue, Sep 25, 2018 at 9:37 AM 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_exc
On 09/25/2018 09:36 AM, 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
Hello guys,
mapping on my system is:
dom0 have one vCPU and it is pinned on pCPU0
domU also have one vCPU and it's pinned for pCPU2
I removed only vwfi=native and everything works fine. I can destroy
and create a guest as many times as I want with out any error (still
using sched=null).
These are
On 09/24/2018 01:59 PM, Andrew Cooper wrote:
> There is no need to duplicate the contents of the skip block.
>
> While cleaning up this function, change 4 ints to be unsigned.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: George Dunlap
___
Xen-devel
On 09/24/2018 02:00 PM, Andrew Cooper wrote:
> Callers of p2m_pod_zero_check() pass a count of up to POD_SWEEP_STRIDE.
> Move the definition of POD_SWEEP_STRIDE and give the arrays a fixed
> bound.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: George Dunlap
On 24/09/18 15:16, Jan Beulich wrote:
On 24.09.18 at 15:00, wrote:
>> For at least "gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609", the
>> typecast of buf triggers a Variable Length Array warning.
>>
>> Alter the asm expression to avoid the typecast, which necessitates the
>> introducti
>>> On 21.09.18 at 12:56, wrote:
> --- a/xen/arch/x86/hvm/mtrr.c
> +++ b/xen/arch/x86/hvm/mtrr.c
> @@ -783,7 +783,8 @@ HVM_REGISTER_SAVE_RESTORE(MTRR, hvm_save_mtrr_msr,
> hvm_load_mtrr_msr, 1,
>
> void memory_type_changed(struct domain *d)
> {
> -if ( need_iommu(d) && d->vcpu && d->vcpu[
On 03/06/2018 07:05 PM, Wei Liu wrote:
> On Tue, Mar 06, 2018 at 06:18:12PM +, George Dunlap wrote:
>> On 03/06/2018 06:08 PM, Wei Liu wrote:
>>> On Tue, Mar 06, 2018 at 05:08:43PM +, George Dunlap wrote:
We don't promise to protect you against rogue stub domain binaries;
only fro
On 9/25/18 1:09 PM, George Dunlap wrote:
> On 09/25/2018 09:36 AM, 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()),
>> mov
>>> On 25.09.18 at 12:31, wrote:
> On 24/09/18 15:16, Jan Beulich wrote:
> On 24.09.18 at 15:00, wrote:
>>> For at least "gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609", the
>>> typecast of buf triggers a Variable Length Array warning.
>>>
>>> Alter the asm expression to avoid the typec
George Dunlap writes ("Re: [PATCH v2 1/6] docs/qemu-deprivilege: Revise and
update with status and future plans"):
> On 09/24/2018 11:23 AM, Ian Jackson wrote:
> > You also need the tool `fishdescriptor' from src:chiark-utils to get
> > the descriptors out of qemu. It is in chiark-utils-bin in De
George Dunlap writes ("Re: [PATCH v2 6/6] RFC: tools/dm_restrict: Enable QEMU
sandboxing"):
> On 09/24/2018 02:04 PM, Ian Jackson wrote:
> > What about capabilities not known to the qemu source code ?
>
> Hrm -- it looks like the sandboxing stuff is based on a blacklist,
> rather than a whitelist
George Dunlap writes ("Re: [PATCH v2 4/6] tools/dm_restrict: Unshare mount and
IPC namespaces on Linux"):
> On 09/24/2018 11:40 AM, Ian Jackson wrote:
> > I think that this means we should explicitly write down that the qemu
> > depriv implementation is incomplete on FreeBSD.
>
> I think theoreti
On 09/25/2018 11:12 AM, Milan Boberic wrote:
Hello guys,
Hi Milan,
mapping on my system is:
dom0 have one vCPU and it is pinned on pCPU0
domU also have one vCPU and it's pinned for pCPU2
Your platform has 4 CPUs, right? What does the other do? Just sitting in
the idle loop?
I removed
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 checks) to
p2m_ept_{get/set}_entry(), and fix locking code
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 made any sense to me -- that's not the way I code i
George Dunlap writes ("Re: [PATCH v2 5/6] tools/dm_depriv: Add first cut
RLIMITs"):
> Does osstest need to actually parse the output at all? Couldn't it just
> capture the output verbatim in a log file, and use the exit code as a
> pass/fail (or grep for FAILED)?
Yes. Each of these tests should
Hi Dario,
On 09/25/2018 10:02 AM, Dario Faggioli wrote:
On Mon, 2018-09-24 at 22:46 +0100, Julien Grall wrote:
On 09/21/2018 05:20 PM, Dario Faggioli wrote:
What I'm after, is how log, after domain_destroy(),
complete_domain_destroy() is called, and whether/how it relates the
the
grace period
George Dunlap writes ("Re: [PATCH] SUPPORT.md: Clarify stubdomain support"):
> I think my answer before contains the answer to your question. Yes, a
> stubdomain *image* has access to code and interfaces that a *running
> stubdomain* does not -- it interacts with the setup code. Its image is
> pa
On Fri, Sep 21, 2018 at 06:04:23PM +0100, George Dunlap wrote:
> +## Migration
> +
> +When calling xen-save-devices-state, since QEMU is running in a chroot
> +it is not useful to pass a filename (it doesn't even have write access
> +inside the chroot). Instead, give it an open fd using the add-fd
flight 128048 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128048/
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
flight 128037 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128037/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 17634d026f968c404b039a8d8431b6389dd396ea
baseline version:
ovmf a364928195e911c2650fc
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 option. With the new Kconfig, we default y for
Dom0 and
flight 75284 distros-debian-snapshot real [real]
http://osstest.xensource.com/osstest/logs/75284/
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
Reply for Julien,
yes, my platform have 4 CPUs it's UltraZed-EG board with carrier card.
I use only 2 CPUs, one for dom0 which is PetaLinux and one for domU
which is bare-metal application that blinks LED on the board (I use it
to measure jitter with oscilloscope), other two CPUs are unused (in
idl
On Tue, Sep 25, 2018 at 11:14:56AM +0200, David Hildenbrand wrote:
> Let's perform all checking + offlining + removing under
> device_hotplug_lock, so nobody can mess with these devices via
> sysfs concurrently.
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: Ra
On 25/09/18 07:45, osstest service owner wrote:
> branch xen-unstable-smoke
> xenbranch xen-unstable-smoke
> job test-arm64-arm64-xl-xsm
> testid xen-boot
>
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemuu git:/
>>> 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 to take precedence over any failure
>> of th
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.
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -568,7 +568,7 @@ static int __init make_memory_node(const struct domain *d,
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.
Oops. Yes - that will cause things to go wrong.
Reviewed-by: Andrew Cooper
___
On 07/09/18 16:14, Jan Beulich wrote:
>> Irrespective of whether you think it is ambiguous or not, I don't view
>> this as a good enough (potential) issue to diverge.
>>
>> Furthermore, (and more likely to sway your opinion), N1570 indicates
>> that the 'l' length modifier is only applicable for th
01: support AVX512 opmask insns
02: x86/HVM: grow MMIO cache data size to 64 bytes
03: correct EVEX decoding
04: generalize vector length handling for AVX512/EVEX
05: support basic AVX512 moves
06: test for correct EVEX Disp8 scaling
07: also allow running the 32-bit harness on a 64-bit distro
08:
>>> On 25.09.18 at 15:06, wrote:
> On 07/09/18 16:14, Jan Beulich wrote:
>>> Irrespective of whether you think it is ambiguous or not, I don't view
>>> this as a good enough (potential) issue to diverge.
>>>
>>> Furthermore, (and more likely to sway your opinion), N1570 indicates
>>> that the 'l'
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 would need to be used. After all the compiler ha
Fix an inverted pair of checks, drop an incorrect instance of #UD
raising for non-64-bit mode, and add further generic checks.
Note: Other than SDM Vol 2 rev 067 states, EVEX.V' is _not_ ignored
outside of 64-bit mode when the field does not encode a register.
Just like EVEX. is re
This is needed before enabling any AVX512 insns in the emulator. Change
the way alignment is enforced at the same time.
Add a check that the buffer won't actually overflow, and while at it
also convert the check for accesses to not cross page boundaries.
Signed-off-by: Jan Beulich
Reviewed-by: P
To allow for some code sharing where possible, copy VEX.L into EVEX.LR
even for VEX (or XOP) encoded insns. Make operand size determination
use this right away, at the same time adding consistency checks for the
EVEX scalar insn cases (the non-scalar ones aren't uniform enough for
the checking to b
Note: SDM Vol 2 rev 067 is not really consistent about EVEX.L'L for LIG
insns - the only place where this is made explicit is a table in
the section titled "Vector Length Orthogonality": While they
tolerate 0, 1, and 2, a value of 3 uniformly leads to #UD.
Signed-off-by: Jan Beul
Besides the already existing tests (which are going to be extended once
respective ISA extension support is complete), let's also ensure for
every individual insn that their Disp8 scaling (and memory access width)
are correct.
Signed-off-by: Jan Beulich
---
v4: Introduce ESZ_d_WIG.
v3: New.
---
In order to be able to verify the 32-bit variant builds and runs,
introduce a respective target (and the necessary other adjustments).
Signed-off-by: Jan Beulich
---
v4: Moved ahead in series.
v3: New.
--- a/.gitignore
+++ b/.gitignore
@@ -240,6 +240,7 @@ tools/security/xensec_tool
tools/tests/
The more generic AVX512 implementation allows quite a bit of insn-
specific code to be dropped/shared.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -439,8 +439,8 @@ static const struct ext0f38_table {
[0x28 ... 0x29]
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -93,6 +93,10 @@ enum esz {
INSN_SFP(m, sp, o)
static const struct test avx512f_all[] = {
+INSN_FP(add, 0f, 58),
+INSN_FP(div,
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -133,6 +133,13 @@ static const struct test avx512bw_all[]
INSN(movdqu16,f2, 0f, 7f,vl,w, vl),
};
+static const struct test avx512dq_all[] = {
+
Also correct the AVX counterpart's comment.
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_
Also correct an AVX counterpart's comment.
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -116,8 +116,11 @@ static const struct test avx512f_all[] =
INSN_PFP_NB(movu,0f, 10),
INSN_PFP_NB(movu,
Signed-off-by: Jan Beulich
---
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -96,6 +96,36 @@ static const struct test avx512f_all[] =
INSN_FP(add, 0f, 58),
INSN_FP(cmp, 0f, c2),
INSN_FP(div, 0
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: J
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, el
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,
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: Use
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.
---
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.
--- a/
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 two
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 use
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
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
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)
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 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 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
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
++
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.
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
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
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
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
@@
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[]
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
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,
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
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
---
... 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
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
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
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
1 - 100 of 178 matches
Mail list logo
