On Tue, Dec 18, 2018 at 11:19:04PM +0100, Manuel Bouyer wrote:
> Hello,
> I tried updating my NetBSD dom0 to 4.11.1 (from 4.11.0 with security patches),
> and on a 32bits PV domU shutdown I get (100% reproductible):
I get the same panic on 4.8.5. Also, I didn't mention it but there's
no problems w
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 possible that
the backend sees only partial content of the
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 again is un-binding and binding it to
> pciback. Someone reported this is
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 trace below:
>
> (XEN) Xen call trace:
> (XEN)[] msi.c#msi_set_mas
Julien, ping?
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 17 December 2018 09:23
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Stefano Stabellini
> ; Julien Grall ; Andrew
> Cooper ; George Dunlap
> ; Ian Jackson ; Konrad
> Rzeszutek Wilk
Julien, ping?
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 17 December 2018 09:23
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Andrew Cooper
> ; Wei Liu ; Roger Pau
> Monne ; George Dunlap ;
> Ian Jackson ; Julien Grall ;
> Konrad Rzeszute
On Tue, Dec 18, 2018 at 11:29:16PM +0800, Dongli Zhang wrote:
>
>
> On 12/18/2018 11:13 PM, Roger Pau Monné wrote:
> > On Tue, Dec 18, 2018 at 07:31:59PM +0800, Dongli Zhang wrote:
> >> Hi Roger,
> >>
> >> On 12/18/2018 05:33 PM, Roger Pau Monné wrote:
> >>> On Tue, Dec 18, 2018 at 08:55:38AM +08
flight 131416 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131416/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 125898
test-amd64-amd64-pa
flight 131438 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131438/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen f60658c6ae47e74792e6cc48ea2effac8bb52826
baseline version:
xen a9c9
Andre,
Could you please comment on the patch and below.
On 20.11.18 13:09, Andrii Anisov wrote:
Hello Andre,
I'm going to change "gic_raise_guest_irq()" function interface.
Could you please comment my understanding of vgic-v3-its.c code below? So that
I could fix it alongside the function i
On 12/18/18 4:05 PM, Roger Pau Monne wrote:
> No functional change.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 12/18/18 4:05 PM, Roger Pau Monne wrote:
> And rename to have only one prefix underscore where applicable.
>
> No functional change.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproje
>>> On 18.12.18 at 23:19, wrote:
> I tried updating my NetBSD dom0 to 4.11.1 (from 4.11.0 with security patches),
Hmm, the issue stems from the XSA-273 changes, so did you perhaps
mean "with some security patches", and you didn't have those ones
applied?
> and on a 32bits PV domU shutdown I get
Sorry for top-posting.
Well, from the logs I see that those failures come before PV DRM
even creates any shared buffers which could be the problem:
when you see
(XEN) p2m.c:1456: d2v1: gvirt_to_maddr failed va=0x80001df5205f
flags=0x1 par=0x809
(XEN) p2m.c:1456: d2v3: gvirt_to_maddr faile
flight 131420 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131420/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 128858
test-amd64-i386-xl-r
On 12/18/18 4:05 PM, Roger Pau Monne wrote:
> paging_log_dirty_op function takes mm locks from a subject domain and
> then attempts to perform copy to operations against the caller
> domain in order to copy the result of the hypercall into the caller
> provided buffer.
>
> This works fine when the
On Wed, Dec 19, 2018 at 04:05:57AM -0700, Jan Beulich wrote:
> >>> On 18.12.18 at 23:19, wrote:
> > I tried updating my NetBSD dom0 to 4.11.1 (from 4.11.0 with security
> > patches),
>
> Hmm, the issue stems from the XSA-273 changes, so did you perhaps
> mean "with some security patches", and yo
On 18/12/2018 15:22, Jan Beulich wrote:
On 18.12.18 at 15:28, wrote:
>> On 10/12/2018 13:56, Jan Beulich wrote:
>> On 10.12.18 at 14:20, wrote:
On 10/12/2018 11:32, Jan Beulich wrote:
> The avx512_vlen_check() invocation needs to be conditional.
>
> Signed-off-by: Jan Be
On 2018-12-18 19:33, Markus Armbruster wrote:
> Thomas Huth writes:
>
>> The last user of blk_attach_dev_legacy() is the code in xen_disk.c.
>> It passes a pointer to a XenBlkDev as second parameter. XenBlkDev
>> is derived from XenDevice which in turn is derived from DeviceState
>> since commit
On Wed, Dec 19, 2018 at 11:40:14AM +, George Dunlap wrote:
> On 12/18/18 4:05 PM, Roger Pau Monne wrote:
> > paging_log_dirty_op function takes mm locks from a subject domain and
> > then attempts to perform copy to operations against the caller
> > domain in order to copy the result of the hyp
On 19/12/2018 12:10, Roger Pau Monné wrote:
> Hypercalls AFAIK have a single target (or subject) domain, so even if
> there's a stubdomain relation I'm not sure I see why that would
> require this kind of locking, any domain can perform hypercalls
> against a single subject domain, and the hypervis
On 12/19/18 12:10 PM, Roger Pau Monné wrote:
> On Wed, Dec 19, 2018 at 11:40:14AM +, George Dunlap wrote:
>> On 12/18/18 4:05 PM, Roger Pau Monne wrote:
>>> paging_log_dirty_op function takes mm locks from a subject domain and
>>> then attempts to perform copy to operations against the caller
>
On Mon, Dec 17, 2018 at 01:30:09PM +, Paul Durrant wrote:
> +static char *xen_block_blockdev_add(const char *id, QDict *qdict,
> +Error **errp)
> +{
> +const char *driver = qdict_get_try_str(qdict, "driver");
> +BlockdevOptions *options = NULL;
> +
On Mon, Dec 17, 2018 at 01:30:08PM +, Paul Durrant wrote:
> ...that maintains compatibility with existing Xen toolstacks.
>
> Xen toolstacks instantiate PV backends by simply writing information into
> xenstore and expecting a backend implementation to be watching for this.
>
> This patch add
On 19/12/2018 12:38, 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:
>>> On 12/18/18 4:05 PM, Roger Pau Monne wrote:
paging_log_dirty_op function takes mm locks from a subject domain and
then attempts to
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 19 December 2018 12:39
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; qemu-bl...@nongnu.org; xen-
> de...@lists.xenproject.org; Kevin Wolf ; Max Reitz
> ; Stefano Stabellini
> Subject: Re: [PATCH v6 16
>>> 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():
>>
>> int rc = _put_page_type(pg, false,
>>> On 19.12.18 at 13:02, wrote:
> On 18/12/2018 15:22, Jan Beulich wrote:
> On 18.12.18 at 15:28, wrote:
>>> On 10/12/2018 13:56, Jan Beulich wrote:
>>> On 10.12.18 at 14:20, wrote:
> On 10/12/2018 11:32, Jan Beulich wrote:
>> The avx512_vlen_check() invocation needs to be condi
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. */
+case EEMI_FID(ZYNQMP_SIP_SVC_CALL_COUNT):
+case EEMI_FID(ZYNQMP_SIP_SVC_UID):
+
Hi,
> > > + mapping = xen_obj->base.filp->f_mapping;
> > > + mapping_set_gfp_mask(mapping, GFP_USER | __GFP_DMA32);
> > Let's see if I understand what you're doing:
> >
> > Here you say that the pages should be DMA accessible for devices that can
> > only see 4GB.
>
> Yes, your understa
The xenstore 'ring-page-order' is used globally for each blkback queue and
therefore should be read from xenstore only once. However, it is obtained
in read_per_ring_refs() which might be called multiple times during the
initialization of each blkback queue.
If the blkfront is malicious and the 'r
On 12/19/18 3:14 PM, Gerd Hoffmann wrote:
Hi,
+ mapping = xen_obj->base.filp->f_mapping;
+ mapping_set_gfp_mask(mapping, GFP_USER | __GFP_DMA32);
Let's see if I understand what you're doing:
Here you say that the pages should be DMA accessible for devices that can
only see 4GB.
Yes,
(+Juergen)
On 18/12/2018 21:11, Volodymyr Babchuk wrote:
From: Volodymyr Babchuk
Hello all,
Hi Volodymyr,
Sorry for late submussion. I was busy with other projects.
Thank you for posting a new version of the series. I am afraid neither Stefano
nor I will have time to review the series by
On Wed, Dec 19, 2018 at 05:54:42AM -0700, Jan Beulich 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
> >>
Hi Stefano,
On 18/12/2018 23:32, Stefano Stabellini wrote:
From: "Edgar E. Iglesias"
Introduce zynqmp specific defines for the firmware calls.
See EEMI:
https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf
The error codes are described, under XIlPM Error Codes:
https:/
flight 131423 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131423/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 131282
test-armhf-armhf-libvirt 14 save
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 PM_GET_API_VERSION behavior:
Acked-by: Julien Grall
I am stil
On 12/19/18 12:42 PM, Andrew Cooper wrote:
> On 19/12/2018 12:38, 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:
On 12/18/18 4:05 PM, Roger Pau Monne wrote:
> paging_log_dirty_op function takes mm lock
On Wed, Dec 19, 2018 at 12:43:24PM +, Paul Durrant wrote:
> > Kevin seems to say that this could be done without the _flat_confused
> > version. The flat_confused version seems to be useful just because
> > the key "cache.direct" is used earlier, and because everything in qdict
> > is a string.
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 19 December 2018 14:01
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; qemu-bl...@nongnu.org; xen-
> de...@lists.xenproject.org; Kevin Wolf ; Max Reitz
> ; Stefano Stabellini
> Subject: Re: [PATCH v6 16
On 19/12/2018 13:55, George Dunlap wrote:
> On 12/19/18 12:42 PM, Andrew Cooper wrote:
>> On 19/12/2018 12:38, 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:
> On 12/18/18 4:05 PM, Roger Pau Monne wrote:
Hi,
> > Sure this actually helps? It's below 4G in guest physical address
> > space, so it can be backed by pages which are actually above 4G in host
> > physical address space ...
>
> Yes, you are right here. This is why I wrote about the IOMMU
> and other conditions. E.g. you can have a devi
01: rename evex.br to evex.brs
02: support AVX512{F,BW} shift/rotate insns
03: support AVX512{F,BW,DQ} extract insns
04: support AVX512{F,BW,DQ} insert insns
05: basic AVX512F testing
06: support AVX512{F,BW,DQ} integer broadcast insns
07: basic AVX512VL testing
08: support AVX512{F,BW} zero- and s
>>> On 19.12.18 at 13:38, wrote:
> On 12/19/18 12:10 PM, Roger Pau Monné wrote:
>> On Wed, Dec 19, 2018 at 11:40:14AM +, George Dunlap wrote:
>>> On 12/18/18 4:05 PM, Roger Pau Monne wrote:
paging_log_dirty_op function takes mm locks from a subject domain and
then attempts to perform
>>> On 19.12.18 at 15:07, wrote:
> On 19/12/2018 13:55, George Dunlap wrote:
>> Yes, if someone uses XSM to bypass the IS_PRIV() functionality to give
>> one domain access over another, then the lock checking will trigger.
>
> Noone should be able to trigger assertions in the hypervisor by simply
>>> On 19.12.18 at 15:17, wrote:
> 01: rename evex.br to evex.brs
> 02: support AVX512{F,BW} shift/rotate insns
> 03: support AVX512{F,BW,DQ} extract insns
> 04: support AVX512{F,BW,DQ} insert insns
> 05: basic AVX512F testing
> 06: support AVX512{F,BW,DQ} integer broadcast insns
> 07: basic AVX51
On Wed, Dec 19, 2018 at 12:17:51PM +, Andrew Cooper wrote:
> On 19/12/2018 12:10, Roger Pau Monné wrote:
> > Hypercalls AFAIK have a single target (or subject) domain, so even if
> > there's a stubdomain relation I'm not sure I see why that would
> > require this kind of locking, any domain can
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
Signed-off-by: Jan Beulich
---
v7: New.
--- a/xen/arch/x86/x86
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
---
v7: Re-base.
v4: Make use of d8s_dq64.
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -212,6 +212,7 @@ static const struct test avx512f_all[] =
};
static const struct test avx512f_128[] = {
+INSN(extractps
Also correct the comment of the AVX form of VINSERTPS.
Signed-off-by: Jan Beulich
---
v7: Re-base.
v6: Don't refuse to emulate VINSERTPS without AVX512VL.
v4: Make use of d8s_dq64.
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -213,6 +213,7 @
On 12/19/18 2:30 PM, Jan Beulich wrote:
On 19.12.18 at 13:38, wrote:
>> On 12/19/18 12:10 PM, Roger Pau Monné wrote:
>>> On Wed, Dec 19, 2018 at 11:40:14AM +, George Dunlap wrote:
On 12/18/18 4:05 PM, Roger Pau Monne wrote:
> paging_log_dirty_op function takes mm locks from a sub
Test various of the insns which have been implemented already.
Signed-off-by: Jan Beulich
---
v6: Fix formatting in simd.h.
v5: Add VSQRT* tests.
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/Makef
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
---
v7: Use dummy output in invoke_stub(). Re-base.
v3: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86
Test the 128- and 256-bit variants of the insns which have been
implemented already.
Signed-off-by: Jan Beulich
---
v6: Don't enable AVX512VL for scalar tests, nor for S/G ones with index
wider than data. Re-base over changes earlier in the series.
v4: Move OVR() additions into __AVX512VL__ c
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:
> >> On 12/18/18 4:05 PM, Roger Pau Monne wrote:
> >>> paging_log_dirty_op function takes mm locks from a subject domain a
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
---
v7: ea.type == OP_* -> ea.type != OP_*. Re-base over change in previous
patch. Re-base.
v5: Also adjust x86
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
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
---
v6: Re-base over changes earlier in the series.
v4: Move OVR() add
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
Also include vshuff{32x4,64x2} as being very similar to vshufi{32x4,64x2}.
Signed-off-by: Jan Beulich
---
v7: Disable fault suppression for VPSHUF{D,{H,L}W}. Re-base.
v6: Re-base over changes earlier in the series.
v5: Re-base over changes earlier in the series.
v4: Move OVR() addition into __AVX
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
Test various of the insns which have been implemented already.
Signed-off-by: Jan Beulich
---
v6: Re-base over changes earlier in the series.
v4: Add __AVX512VL__ conditional around majority of OVR() additions.
Correct eq() for 1- and 2-byte cases.
v3: New.
--- a/tools/tests/x86_emulator/Mak
Test various of the insns which have been implemented already.
Signed-off-by: Jan Beulich
---
v6: Re-base.
v5: Re-base over changes earlier in the series.
v4: Wrap OVR(pmullq) in __AVX512VL__ conditional.
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
---
v7: Re-base.
v4: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -253,6 +253,16 @@ static const struct test
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:
On 12/18/18 4:05 PM, Roger Pau Monne wrote:
> paging_log_dirty_op
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
---
v7: Re-base.
v5: Re-base over changes earlier in the series.
v4: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -178,6 +178,10 @@ static const struct test avx512f_all[] =
INSN(pcmpu,66, 0f3a, 1e,vl,
No further test harness additions - what is there is good enough for
these rather "regular" insns.
Signed-off-by: Jan Beulich
---
v7: Re-base.
v4: New.
--- a/tools/tests/x86_emulator/evex-disp8.c
+++ b/tools/tests/x86_emulator/evex-disp8.c
@@ -306,6 +306,10 @@ static const struct test avx512bw_a
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.
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
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.
--- a/tools
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.
--- a/tools/tests
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 chang
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
+++ b/tools/tests/x86_emulat
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, vl),
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 e
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[] =
INSN(cvt
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 avx512dq_
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),
INS
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
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 callers
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 code
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 conc
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 #GP/#
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
+++ b/tools
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:
> >>
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 t
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
--
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 patt
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 the
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 avx512_4f
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
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.
--- a/tools/tests/x86_emulat
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.
--- a/t
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 t
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 reference
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 p
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 c
1 - 100 of 170 matches
Mail list logo
