>>> On 19.12.18 at 19:20, wrote:
> On 19/12/2018 14:36, Jan Beulich wrote:
>> @@ -280,6 +285,12 @@ static const struct test avx512bw_all[]
>> INSN(ptestnm, f3, 0f38, 26,vl, bw, vl),
>> };
>>
>> +static const struct test avx512bw_128[] = {
>> +INSN(pextrb, 66, 0f3a, 14, el,
On Thu, Dec 20, 2018 at 12:36:35AM -0700, Jan Beulich wrote:
> >>> On 19.12.18 at 13:54, wrote:
> On 19.12.18 at 12:55, wrote:
> >> On Wed, Dec 19, 2018 at 04:05:57AM -0700, Jan Beulich wrote:
> >>> In any event, both Andrew and I must have overlooked the one
> >>> crucial place due to
>>> On 19.12.18 at 13:54, wrote:
On 19.12.18 at 12:55, wrote:
>> On Wed, Dec 19, 2018 at 04:05:57AM -0700, Jan Beulich wrote:
>>> In any event, both Andrew and I must have overlooked the one
>>> crucial place due to which the assertion is indeed wrong from
>>> put_page_from_l2e():
>>>
>>>
Argo doesn't use compat hypercall or argument translation but can use some
of the infrastructure for validating the hypercall argument structures to
ensure that the struct sizes, offsets and compositions don't vary between 32
and 64bit, so add that here in a new dedicated source file for this
Will inhibit initialization of the domain's argo data structure to
prevent receiving any messages or notifications and access to any of
the argo hypercall operations.
Signed-off-by: Christopher Clark
---
Changes since v1:
v1 #5 (#17) feedback Paul: XSM control for any access: use currd
v1 #16
flight 131437 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131437/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 131081
test-amd64-amd64-xl-qemuu-ws16-amd64 17
Queries for data about space availability in registered rings and
causes notification to be sent when space has become available.
The hypercall op populates a supplied data structure with information about
ring state, and if insufficent space is currently available in a given ring,
the hypervisor
Takes a single argument: a handle to the registered ring.
The ring's entry is removed from the hashtable of registered rings;
any entries for pending notifications are removed; and the ring is
unmapped from Xen's address space.
Signed-off-by: Christopher Clark
---
Changes since v1:
v1 #5 (#14)
This is the second version of the patch series that implements the Argo
hypervisor-mediated interdomain communication mechanism as an experimental
feature for incorporation into the Xen hypervisor.
Feedback from version one has been incorporated, with notable changes:
* VIRQs are used
Initialises basic data structures and performs teardown of argo state
for domain shutdown.
Adds a Xen command line parameter 'argo': bool to enable/disable.
=> defaults to disabled.
Introduces headers:
with definions of addresses and ring structure, including
indexes for atomic update for
The hypervisor data structures for the argo rings are populated with mfns
which cannot be assumed to map to the same guest frame numbers across entry
to and exit from host power state S4 (hibernate to disk).
Tear down all the rings during suspend to stop argo operations from
performing any
Signed-off-by: Christopher Clark
---
Changes since v1:
Change the default to disabled.
Make the prompt depend on EXPERT.
Fix tab-based indentation.
xen/common/Kconfig | 20
1 file changed, 20 insertions(+)
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index
Default policy: allow.
Signed-off-by: Christopher Clark
---
v1 version was:
Reviewed-by: Paul Durrant
but this has been modified since v1 based on Jan's feedback to apply const
to function signatures.
=> Paul, does the Reviewed-by still stand?
xen/include/xsm/dummy.h | 6 ++
Signed-off-by: Christopher Clark
---
xen/common/argo.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/xen/common/argo.c b/xen/common/argo.c
index 1f16872..921aaf3 100644
--- a/xen/common/argo.c
+++ b/xen/common/argo.c
@@ -1115,6 +1115,17 @@ argo_fill_ring_data(const struct
XSM hooks implement distinct permissions for these two distinct cases of
Argo ring registration:
* Single source: registering a ring for communication to receive messages
from a specified single other domain.
Default policy: allow.
* Any source: registering a ring for
A convenience for working on development of the argo subsystem:
toggling a local #define variable turns on just the debug messages
in this subsystem.
Signed-off-by: Christopher Clark
---
Changes since v1:
v1 #04 feedback, Jan:
remove do-while from definition
fully parenthesize the macro
ARM port of c/s bb544585: "introduce guest_handle_for_field()"
This helper turns a field of a GUEST_HANDLE into a GUEST_HANDLE.
Signed-off-by: Christopher Clark
Reviewed-by: Paul Durrant
---
v1 10 feedback Paul: improve commit message, add R-by
xen/include/asm-arm/guest_access.h | 3 +++
1
sendv operation is invoked to perform a synchronous send of buffers
contained in iovs to a remote domain's registered ring.
It takes:
* A destination address (domid, port) for the ring to send to.
It performs a most-specific match lookup, to allow for wildcard.
* A source address, used to
This is to assist code clarity and abstraction conformance, enabling:
var = XEN_GUEST_HANDLE_NULL(type);
instead of an abstraction violation, where structure is assumed:
var = ((XEN_GUEST_HANDLE(type)){(void *)0});
or:
var.p = NULL;
and for convenience for supplying a suitably
Used by a domain to register a region of memory for receiving messages from
either a specified other domain, or, if specifying a wildcard, any domain.
This operation creates a mapping within Xen's private address space that
will remain resident for the lifetime of the ring. In subsequent commits,
EMSGSIZE: Argo's sendv operation will return EMSGSIZE when an excess amount
of data, across all iovs, has been supplied, exceeding either the statically
configured maximum size of a transmittable message, or the (variable) size
of the ring registered by the destination domain.
ECONNREFUSED:
Presence is gated upon CONFIG_ARGO.
Registers the hypercall previously reserved for this.
Takes 5 arguments, does nothing and returns -ENOSYS.
Will be avoiding a compat ABI by using fixed-size types in hypercall ops so
HYPERCALL, rather than COMPAT_CALL, is the correct macro for the hypercall
Adds: copy_from_guest_errno(ptr, hnd, nr)
and: copy_from_guest_offset_errno(ptr, hnd, off, nr)
Inputs are identical to copy_from_guest and copy_from_guest_offset:
- ptr: pointer to local memory to write into
- hnd: guest handle to read from
- nr: number of records to copy
-
On Thu, Dec 13, 2018 at 6:26 AM Jan Beulich wrote:
>
> >>> On 01.12.18 at 02:33, wrote:
> > so that the guest may re-register the rings on resume with current mappings.
>
> Is this something guests really need help with, rather than managing
> it on their own? What does "current mappings" here
On Thu, Dec 13, 2018 at 6:16 AM Jan Beulich wrote:
>
> >>> On 01.12.18 at 02:33, wrote:
> > * x86 PV domains are notified via event channel.
> >
> > PV guests are known to have the event channel software present in the guest
> > kernel, so it is fine to depend on and use it.
> >
> > * x86 HVM
On Thu, Dec 13, 2018 at 6:06 AM Jan Beulich wrote:
>
> >>> On 01.12.18 at 02:32, wrote:
> > +static uint32_t
> > +argo_ringbuf_payload_space(struct domain *d, struct argo_ring_info
> > *ring_info)
> > +{
> > +argo_ring_t ring;
> > +int32_t ret;
> > +
> > +
On Wed, Dec 12, 2018 at 3:53 AM Jan Beulich wrote:
>
> >>> On 01.12.18 at 02:32, wrote:
> > +static void
> > +argo_signal_domain(struct domain *d)
> > +{
> > +argo_dprintk("signalling domid:%d\n", d->domain_id);
> > +
> > +if ( !d->argo ) /* This can happen if the domain is being
On Wed, Dec 12, 2018 at 8:48 AM Roger Pau Monné wrote:
>
> On Fri, Nov 30, 2018 at 05:32:52PM -0800, Christopher Clark wrote:
> > +static inline uint16_t
> > +argo_hash_fn(const struct argo_ring_id *id)
>
> No need for the argo_ prefix for static functions, this is already an
> argo specific
On Wed, Dec 12, 2018 at 1:48 AM Jan Beulich wrote:
>
> > +static int
> > +argo_find_ring_mfns(struct domain *d, struct argo_ring_info *ring_info,
> > +uint32_t npage, XEN_GUEST_HANDLE_PARAM(argo_pfn_t)
> > pfn_hnd,
> > +uint32_t len)
> > +{
> > +int i;
On Tue, Dec 4, 2018 at 1:52 AM Paul Durrant wrote:
>
> > -Original Message-
> > From: Christopher Clark [mailto:christopher.w.cl...@gmail.com]
> > Sent: 01 December 2018 01:33
> > To: xen-devel@lists.xenproject.org
> > Cc: Andrew Cooper ; George Dunlap
> > ; Ian Jackson ; Jan
> > Beulich
flight 131435 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131435/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 131399
test-armhf-armhf-libvirt 14
On Wed, Dec 12, 2018 at 8:03 AM Roger Pau Monné wrote:
>
> On Fri, Nov 30, 2018 at 05:32:46PM -0800, Christopher Clark wrote:
> > Applied to both x86 and ARM headers.
> >
> > Signed-off-by: Christopher Clark
> > ---
> > xen/include/asm-arm/guest_access.h | 25 +
> >
On Tue, Dec 4, 2018 at 1:44 AM Paul Durrant wrote:
>
> > -Original Message-
> > From: Christopher Clark [mailto:christopher.w.cl...@gmail.com]
> > Sent: 01 December 2018 01:33
> > To: xen-devel@lists.xenproject.org
> > Subject: [PATCH 03/25] argo: introduce the argo_message_op hypercall
>
flight 131429 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131429/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail
in 131386 pass in 131429
On Wed, Dec 19, 2018 at 09:57:51AM +0100, Roger Pau Monné wrote:
>On Tue, Dec 18, 2018 at 10:43:37PM +0800, Chao Gao wrote:
>> I find some pass-thru devices don't work any more across guest
>> reboot. Assigning it to another domain also meets the same issue. And
>> the only way to make it work
On Wed, Dec 19, 2018 at 10:00:49AM +0100, Roger Pau Monné wrote:
>On Tue, Dec 18, 2018 at 10:43:38PM +0800, Chao Gao wrote:
>> When I destroyed a guest with 'xl destroy', I found the warning
>> in msi_set_mask_bit() in Xen was triggered. After adding "WARN_ON(1)"
>> to that place, I got the call
flight 131433 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131433/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 131392
test-armhf-armhf-libvirt-raw 13
On Wed, 19 Dec 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 18/12/2018 22:36, Stefano Stabellini wrote:
> > On Tue, 18 Dec 2018, Julien Grall wrote:
> > > Hi,
> > >
> > > On 12/17/18 10:10 PM, Stefano Stabellini wrote:
> > > > +/* These calls are safe and always allowed. */
> > > > +
On Wed, 19 Dec 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 18/12/2018 23:32, Stefano Stabellini wrote:
> > +/* These calls are safe and always allowed. */
> > +case EEMI_FID(PM_GET_TRUSTZONE_VERSION):
> > +case EEMI_FID(PM_GET_API_VERSION):
>
> Regardless the discussion about
On 19/12/2018 22:33, Tamas K Lengyel wrote:
> On Wed, Dec 19, 2018 at 11:52 AM Petre Pircalabu
> wrote:
>> This patchset is a rework of the "multi-page ring buffer" for vm_events
>> patch based on Andrew Cooper's comments.
>> For synchronous vm_events the ring waitqueue logic was unnecessary as
On Wed, Dec 19, 2018 at 11:52 AM Petre Pircalabu
wrote:
>
> This patchset is a rework of the "multi-page ring buffer" for vm_events
> patch based on Andrew Cooper's comments.
> For synchronous vm_events the ring waitqueue logic was unnecessary as the
> vcpu sending the request was blocked until a
On Wed, Dec 19, 2018 at 11:52 AM Petre Pircalabu
wrote:
>
> Decouple the VM Event interface from the ring implementation.
This will need a much better description. There is also a lot of churn
that is mostly just mechanical in this patch but makes reviewing it
hard. Perhaps functional changes
flight 131427 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131427/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-pvshim12 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 13
On Wed, Dec 19, 2018 at 11:52 AM Petre Pircalabu
wrote:
>
> Define the type for each of the supported vm_event rings (paging,
> monitor and sharing) and replace the ring param field with this type.
>
> Replace XEN_DOMCTL_VM_EVENT_OP_ occurrences with their corresponding
> XEN_VM_EVENT_TYPE_
flight 131432 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131432/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 129475
build-i386-xsm
flight 131426 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131426/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 131384
Tests which did not
Decouple the VM Event interface from the ring implementation.
---
xen/arch/arm/mem_access.c | 2 +-
xen/arch/x86/mm/mem_access.c | 4 +-
xen/arch/x86/mm/mem_paging.c | 2 +-
xen/arch/x86/mm/mem_sharing.c | 5 +-
xen/arch/x86/mm/p2m.c | 10 +-
xen/common/mem_access.c |
Signed-off-by: Petre Pircalabu
---
tools/libxc/xc_private.c | 3 +++
xen/common/kernel.c | 3 +++
xen/include/public/version.h | 3 +++
3 files changed, 9 insertions(+)
diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
index 90974d5..9b983e0 100644
---
In high throughput introspection scenarios where lots of monitor
vm_events are generated, the ring buffer can fill up before the monitor
application gets a chance to handle all the requests thus blocking
other vcpus which will have to wait for a slot to become available.
This patch adds support
Define the type for each of the supported vm_event rings (paging,
monitor and sharing) and replace the ring param field with this type.
Replace XEN_DOMCTL_VM_EVENT_OP_ occurrences with their corresponding
XEN_VM_EVENT_TYPE_ counterpart.
Signed-off-by: Petre Pircalabu
---
This patchset is a rework of the "multi-page ring buffer" for vm_events
patch based on Andrew Cooper's comments.
For synchronous vm_events the ring waitqueue logic was unnecessary as the
vcpu sending the request was blocked until a response was received.
To simplify the request/response mechanism,
Signed-off-by: Petre Pircalabu
---
tools/tests/xen-access/xen-access.c | 545 +---
1 file changed, 441 insertions(+), 104 deletions(-)
diff --git a/tools/tests/xen-access/xen-access.c
b/tools/tests/xen-access/xen-access.c
index 6aaee16..b09be6c 100644
---
Modified xc_mem_paging_enable to use directly xc_vm_event_enable and
moved the ring_page handling from client to libxc (xenpaging).
Restricted vm_event_control usage only to simplest domctls which do
not expect any return values and change xc_vm_event_enable to call do_domctl
directly.
Removed
On 19/12/2018 14:36, Jan Beulich wrote:
> @@ -280,6 +285,12 @@ static const struct test avx512bw_all[]
> INSN(ptestnm, f3, 0f38, 26,vl, bw, vl),
> };
>
> +static const struct test avx512bw_128[] = {
> +INSN(pextrb, 66, 0f3a, 14, el, b, el),
> +// pextrw, 66, 0f, c5,
flight 131425 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131425/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 129313
On Wed, Dec 19, 2018 at 04:49:43PM +, Alexandru Stefan ISAILA wrote:
> On 27.11.2018 13:32, Roger Pau Monné wrote:
> > Would it be possible to add some kind of flag to the emulator to
> > signal whether p2m restrictions should be enforced/ignored?
> > hvmemul_acquire_page seems like a suitable
On 12/13/18 10:43 AM, Jan Beulich wrote:
On 13.12.18 at 11:22, wrote:
>> For my own part, I see no reason why not clipping end should not work
>> when updating the ranges only (as long as start continues to be <=
>> unclipped_end).
>>
>> Would that modification + testing of it help this
On 27.11.2018 13:32, Roger Pau Monné wrote:
> Would it be possible to add some kind of flag to the emulator to
> signal whether p2m restrictions should be enforced/ignored?
> hvmemul_acquire_page seems like a suitable place, but I'm not that
> familiar with the emulator.
>
> Then you could
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 19 December 2018 16:24
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; George Dunlap ; Ian
> Jackson ; Roger Pau Monne ;
> Wei Liu ; Jun Nakajima ;
> Kevin Tian ; Stefano Stabellini
> ; xen-devel ;
>
>>> On 19.12.18 at 10:05, wrote:
> Julien, ping?
Seeing Julien's reply, did you perhaps mean to ping George instead
(the minimal change to p2m-ept.c probably doesn't need a
separate EPT maintainer ack)?
Jan
>> -Original Message-
>> From: Paul Durrant [mailto:paul.durr...@citrix.com]
>>
flight 131445 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131445/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
Den 19.12.2018 09.18, skrev Oleksandr Andrushchenko:
On 12/18/18 9:20 PM, Noralf Trønnes wrote:
Den 27.11.2018 11.32, skrev Oleksandr Andrushchenko:
From: Oleksandr Andrushchenko
When GEM backing storage is allocated with drm_gem_get_pages
the backing pages may be cached, thus making it
On 19/12/2018 14:36, Jan Beulich wrote:
> 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
Hi Paul,
On 17/12/2018 09:22, Paul Durrant wrote:
This patch removes any implicit flushing that occurs in the implementation
of map and unmap operations and adds new iommu_map/unmap() wrapper
functions. To maintain semantics of the iommu_legacy_map/unmap() wrapper
functions, these are modified
Hi,
On 19/12/2018 09:05, Paul Durrant wrote:
Julien, ping?
My ack should not be necessary for this one :). Anyway:
Acked-by: Julien Grall
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
Hi,
On 17/12/2018 09:08, Paul Durrant wrote:
@@ -345,7 +352,26 @@ int iommu_legacy_map(struct domain *d, dfn_t dfn,
mfn_t mfn,
return rc;
}
-int iommu_legacy_unmap(struct domain *d, dfn_t dfn, unsigned int
page_order)
+int iommu_legacy_map(struct domain *d, dfn_t dfn, mfn_t mfn,
On Wed, Dec 19, 2018 at 03:02:36PM +, Ian Jackson wrote:
> Anthony PERARD writes ("Re: [PATCH] libxl: Documentation about the domain
> configuration on disk"):
> > I think there is already a race, and `xl destroy` can leak QEMU. I've
> > called `xl create` with a sleep before spawn_local_dm,
On 19/12/2018 14:35, Jan Beulich wrote:
> This is to better reflect that it's an abbreviation for "broadcast,
> rounding, or SAE" rather than just "broadcast".
>
> Take the opportunity and also add SDM naming comments to both union vex
> and union evex.
>
> Requested-by: Andrew Cooper
>
Bring libxl's in line with the public header, and update xen-cpuid's to
the latest information available in Intel's documentation (SDM ver 068
and ISA extensions ver 035), with (as before) the exception on MAWAU.
Some pre-existing strings get changed to match SDM naming. This should
be benign in
Incremental additions and/or mistakes have lead to some code blocks
sitting in "unexpected" places. Re-sort the case blocks (opcode space;
major opcode; 66/F3/F2 prefix; legacy/VEX/EVEX encoding).
As an exception the opcode space 0x0f EVEX-encoded VPEXTRW is left at
its current place, to keep it
As to the feature dependency adjustment, just like for VPCLMULQDQ while
strictly speaking AVX is a sufficient prereq (to have YMM registers),
256-bit vectors of integers have got fully introduced with AVX2 only.
Along the lines of AESNI, since the insns here and in particular their
memory access
Note that the ISA extensions document revision 035 is ambiguous
regarding fault suppression for VGF2P8MULB: Text says it's supported,
while the exception specification listed is E4NF. Given the wording here
and for the other two insns I'm inclined to trust the text more than the
exception
As to the feature dependency adjustment, while strictly speaking AVX is
a sufficient prereq (to have YMM registers), 256-bit vectors of integers
have got fully introduced with AVX2 only. Sadly gcc can't be used as a
reference here: They don't provide any AVX512-independent built-in at
all.
Along
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 Beulich
---
v7: New.
---
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-by: Jan Beulich
---
v7: Re-base.
v6: New.
---
Anthony PERARD writes ("Re: [PATCH] libxl: Documentation about the domain
configuration on disk"):
> I think there is already a race, and `xl destroy` can leak QEMU. I've
> called `xl create` with a sleep before spawn_local_dm, and during the
> sleep, I call `xl destroy` with a sleep after it had
Signed-off-by: Jan Beulich
---
v7: Re-base.
v6: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -538,6 +538,13 @@ static const struct test avx512pf_512[]
INSNX(scatterpf1q, 66, 0f38, c7, 6, vl, sd, el),
};
+static const struct test
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 Beulich
---
v7: Re-base over change earlier in
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 insns here and in particular their
memory access
Plus the only other AVX512_BITALG one.
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 Beulich
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 in particular its memory access pattern
follows
On Wed, Dec 19, 2018 at 02:46:55PM +, George Dunlap wrote:
> On 12/19/18 2:40 PM, Roger Pau Monné wrote:
> > On Wed, Dec 19, 2018 at 12:38:50PM +, George Dunlap wrote:
> >> On 12/19/18 12:10 PM, Roger Pau Monné wrote:
> >>> On Wed, Dec 19, 2018 at 11:40:14AM +, George Dunlap 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
---
v6: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++
Some adjustments are necessary to the EVEX Disp8 scaling test code to
account for the zero byte reads/writes. I have to admit though that I'm
not fully convinced the SDM describes the faulting behavior correctly:
Other prefetch insns, including the Xeon Phi Coprocessor S/G ones, don't
produce
This completes support of AVX512F in the insn emulator.
Note that in the test harness there's a little bit of trickery needed to
get around the not fully consistent naming of AVX512VL gather and
scatter built-ins. To suppress expansion of the "di" and "si" tokens
they get constructed by token
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 uses of %xmm or %ymm registers in
generated
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 latent issue only as we
don't currently have
This completes support of AVX512BW in the insn emulator, and leaves just
the scatter/gather ones open in the AVX512F set.
Signed-off-by: Jan Beulich
---
v5: New.
---
TBD: The *blendm* inline functions don't reliably produce the intended
insns, as the respective moves are about as good a fit
Signed-off-by: Jan Beulich
---
v7: Re-base.
v6: Re-base. Add tests for the byte/word forms.
v5: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -109,6 +109,7 @@ static const struct test avx512f_all[] =
INSN_FP(cmp, 0f, c2),
This completes support of AVX512DQ in the insn emulator.
Signed-off-by: Jan Beulich
---
v7: Fix vector length check for scalar insns. Re-base.
v5: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -457,11 +457,17 @@ static const struct test
Signed-off-by: Jan Beulich
---
v7: Fix vector length check for scalar insns. ea.type == OP_* ->
ea.type != OP_*. Re-base.
v5: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -140,6 +140,8 @@ static const struct test avx512f_all[] =
Also include the only other AVX512ER insn pair, VEXP2P{D,S}.
Note that despite the replacement of the SHA insns' table slots there's
no need to special case their decoding: Their insn-specific code already
sets op_bytes (as was required due to simd_other), and TwoOp is of no
relevance for legacy
Signed-off-by: Jan Beulich
---
v5: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -354,6 +354,7 @@ static const struct test avx512bw_all[]
INSN(paddusb, 66, 0f, dc,vl,b, vl),
INSN(paddusw, 66, 0f, dd,vl,w,
Plus their AVX512BW counterparts.
Take the opportunity and also eliminate a pair of open coded instances
of scalar_1op().
Signed-off-by: Jan Beulich
---
v7: Re-base.
v6: Re-base over changes earlier in the series.
v5: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++
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
---
v7: Re-base.
v6: Workaround for gcc 7 quirk.
v5: Re-base over
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
---
v7: Re-base.
v4: New.
---
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
---
v7: Re-base.
v4: New.
---
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.
While the SDM claims that EVEX.L'L needs to be zero for the 32-bit forms
of VCVT{,U}SI2SD (exception type E10NF), observations on
... 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
1 - 100 of 168 matches
Mail list logo
