Map 'xen_nopv' to 'nopv' and mark 'xen_nopv' obsolete in
kernel-parameters.txt
Signed-off-by: Zhenzhong Duan
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
---
Documentation/admin-guide/kernel-parameters.txt | 6 ++
.. as they are only called at early bootup stage. In fact, other
functions in x86_hyper_xen_hvm.init.* are all marked as __init.
Unexport xen_hvm_need_lapic as it's never used outside.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Juergen Gross
Cc: Boris Ostrovsky
Cc: Stefano Stabellini
Cc:
PVH guest needs PV extentions to work, so 'nopv' parameter should be
ignored for PVH but not for HVM guest.
If PVH guest boots up via the Xen-PVH boot entry, xen_pvh is set early,
we know it's PVH guest and ignore 'nopv' parameter directly.
If PVH guest boots up via the normal boot entry same as
In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.
However, in some cases (kexec not fully working, benchmarking)
we want to disable PV extensions. As such introduce the
'nopv' parameter that will do
This reverts commit 8d693b911bb9c57009c24cb1772d205b84c7985c.
Instead we use an unified parameter 'nopv' for all the hypervisor
platforms.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Juergen Gross
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo
Hi,
In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.
However, in some cases (kexec not fully working, benchmarking, etc)
we want to disable PV extensions. We have xen_nopv for that purpose
but only
flight 138670 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138670/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 138584
On 2019/7/2 11:48, Boris Ostrovsky wrote:
On Mon, Jul 01, 2019 at 10:20:27AM +0800, Zhenzhong Duan wrote:
This reverts commit 8d693b911bb9c57009c24cb1772d205b84c7985c.
Instead we use an unified parameter 'nopv' for all the hypervisor
platforms.
Signed-off-by: Zhenzhong Duan
Reviewed-by:
flight 138673 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138673/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-thunderx broken
build-i386-prev 6
On Mon, Jul 01, 2019 at 10:20:27AM +0800, Zhenzhong Duan wrote:
> This reverts commit 8d693b911bb9c57009c24cb1772d205b84c7985c.
>
> Instead we use an unified parameter 'nopv' for all the hypervisor
> platforms.
>
> Signed-off-by: Zhenzhong Duan
> Reviewed-by: Juergen Gross
> Cc: Boris
flight 138674 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138674/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2603fce126507568f3ce3a4bd67ed51139e3b332
baseline version:
ovmf
.. as they are only called at early bootup stage. In fact, other
functions in x86_hyper_xen_hvm.init.* are all marked as __init.
Unexport xen_hvm_need_lapic as it's never used outside.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Juergen Gross
Cc: Boris Ostrovsky
Cc: Stefano Stabellini
Cc:
PVH guest needs PV extentions to work, so 'nopv' parameter should be
ignored for PVH but not for HVM guest.
If PVH guest boots up via the Xen-PVH boot entry, xen_pvh is set early,
we know it's PVH guest and ignore 'nopv' parameter directly.
If PVH guest boots up via the normal boot entry same as
This reverts commit 8d693b911bb9c57009c24cb1772d205b84c7985c.
Instead we use an unified parameter 'nopv' for all the hypervisor
platforms.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Juergen Gross
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo
Hi,
In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.
However, in some cases (kexec not fully working, benchmarking, etc)
we want to disable PV extensions. We have xen_nopv for that purpose
but only
Ping~ Anyone have comments?
Thanks
Zhang Chen
> -Original Message-
> From: Zhang, Chen
> Sent: Friday, June 21, 2019 2:00 PM
> To: Ian Jackson ; Wei Liu ; xen-
> de...@lists.xenproject.org
> Cc: Zhang Chen
> Subject: RE: [PATCH] tools/libxl: Add iothread support for COLO
>
> Hi All,
>
In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.
However, in some cases (kexec not fully working, benchmarking)
we want to disable PV extensions. As such introduce the
'nopv' parameter that will do
On Fri, Jun 21, 2019 at 08:47:03PM +0200, Juergen Gross wrote:
> When binding an interdomain event channel to a vcpu via
> IOCTL_EVTCHN_BIND_INTERDOMAIN not only the event channel needs to be
> bound, but the affinity of the associated IRQi must be changed, too.
> Otherwise the IRQ and the event
flight 138668 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138668/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
Tests which are
On Mon, 1 Jul 2019 at 16:22, Jan Beulich wrote:
>
> On 01.07.2019 17:04, Anthony PERARD wrote:
> > On Mon, Jun 17, 2019 at 05:10:50PM +0100, Anthony PERARD wrote:
> >> Update to the latest stable tag.
> >>
> >> Signed-off-by: Anthony PERARD
> >
> > Could one of you commit this patch?
>
> I was
flight 138675 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138675/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 137600
build-arm64-xsm
flight 138666 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138666/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-freebsd10-amd64 7 xen-boot fail in 138645 pass in 138666
test-arm64-arm64-examine 11
flight 138671 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138671/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xen-freebsd 7 xen-build-freebsdfail REGR. vs. 138540
version
Hi Juergen,
Juergen Gross writes:
> This email only tracks big items for xen.git tree. Please reply for items you
> would like to see in 4.13 so that people have an idea what is going on and
> prioritise accordingly.
>
[...]
>
> == Completed ==
>
> * Drop tmem
> - Wei Liu
>
> * Add support
On Thu, Jun 27, 2019 at 09:19:06AM -0600, Jan Beulich wrote:
> The common case is all IOMMUs having the same features. Log them only
> for the first IOMMU, or for any that have a differing feature set.
>
> Requested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
Acked-by: Brian Woods
> ---
>
On Mon, Jul 01, 2019 at 03:19:29PM +, Jan Beulich wrote:
> On 01.07.2019 17:04, Anthony PERARD wrote:
> > On Mon, Jun 17, 2019 at 05:10:50PM +0100, Anthony PERARD wrote:
> >> Update to the latest stable tag.
> >>
> >> Signed-off-by: Anthony PERARD
> >
> > Could one of you commit this patch?
On 01.07.2019 17:36, Alexandru Stefan ISAILA wrote:
> On 01.07.2019 17:55, Jan Beulich wrote:
>> On 01.07.2019 16:45, Alexandru Stefan ISAILA wrote:
>>> On 01.07.2019 16:13, Jan Beulich wrote:
>>> On 04.06.19 at 13:49, wrote:
> +if ( !req.u.mem_access.flags )
> +return
On 01.07.2019 17:10, Juergen Gross wrote:
> On 01.07.19 16:08, Jan Beulich wrote:
> On 28.05.19 at 12:32, wrote:
>>> @@ -155,8 +156,8 @@ static void nmi_mce_softirq(void)
>>> * Set the tmp value unconditionally, so that the check in the iret
>>> * hypercall works.
>>> */
On 01.07.2019 17:13, Razvan Cojocaru wrote:
> On 7/1/19 5:45 PM, Alexandru Stefan ISAILA wrote:
>>
>>
>> On 01.07.2019 16:13, Jan Beulich wrote:
>> On 04.06.19 at 13:49, wrote:
This patch aims to have mem access vm events sent from the emulator.
This is useful where we want to only
On 27/06/2019 16:19, Jan Beulich wrote:
> The common case is all IOMMUs having the same features. Log them only
> for the first IOMMU, or for any that have a differing feature set.
>
> Requested-by: Andrew Cooper
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On 01.07.2019 17:55, Jan Beulich wrote:
> On 01.07.2019 16:45, Alexandru Stefan ISAILA wrote:
>> On 01.07.2019 16:13, Jan Beulich wrote:
>> On 04.06.19 at 13:49, wrote:
+if ( !send_event || !pfec )
+return false;
>>>
>>> I think I've said before that the !pfec part
On 01.07.2019 17:16, Roger Pau Monné wrote:
> On Mon, Jul 01, 2019 at 02:20:52PM +, Jan Beulich wrote:
>> On 01.07.2019 16:01, Roger Pau Monné wrote:
>>> On Mon, Jul 01, 2019 at 11:39:16AM +, Jan Beulich wrote:
On 01.07.2019 12:49, Roger Pau Monne wrote:
> ---
On 01.07.2019 17:04, Anthony PERARD wrote:
> On Mon, Jun 17, 2019 at 05:10:50PM +0100, Anthony PERARD wrote:
>> Update to the latest stable tag.
>>
>> Signed-off-by: Anthony PERARD
>
> Could one of you commit this patch?
I was wondering what the policy here is - do such updates go in
without
On Mon, Jul 01, 2019 at 02:20:52PM +, Jan Beulich wrote:
> On 01.07.2019 16:01, Roger Pau Monné wrote:
> > On Mon, Jul 01, 2019 at 11:39:16AM +, Jan Beulich wrote:
> >> On 01.07.2019 12:49, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/xstate.c
> >>> +++ b/xen/arch/x86/xstate.c
> >>> @@
All,
I am pleased to announce the release of Xen 4.11.2. This is available
immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.11
(tag RELEASE-4.11.2) or from the XenProject download page
On 7/1/19 5:45 PM, Alexandru Stefan ISAILA wrote:
On 01.07.2019 16:13, Jan Beulich wrote:
On 04.06.19 at 13:49, wrote:
This patch aims to have mem access vm events sent from the emulator.
This is useful where we want to only emulate a page walk without
checking the EPT, but we still want to
On 01.07.19 16:08, Jan Beulich wrote:
On 28.05.19 at 12:32, wrote:
@@ -155,8 +156,8 @@ static void nmi_mce_softirq(void)
* Set the tmp value unconditionally, so that the check in the iret
* hypercall works.
*/
-cpumask_copy(st->vcpu->cpu_hard_affinity_tmp,
-
On Mon, Jun 17, 2019 at 05:10:50PM +0100, Anthony PERARD wrote:
> Update to the latest stable tag.
>
> Signed-off-by: Anthony PERARD
Hi,
Could one of you commit this patch?
Thanks,
--
Anthony PERARD
___
Xen-devel mailing list
On 01.07.2019 16:45, Alexandru Stefan ISAILA wrote:
> On 01.07.2019 16:13, Jan Beulich wrote:
> On 04.06.19 at 13:49, wrote:
>>> +if ( !send_event || !pfec )
>>> +return false;
>>
>> I think I've said before that the !pfec part need an explanation (in
>> a comment). Without such
On 01.07.2019 16:13, Jan Beulich wrote:
On 04.06.19 at 13:49, wrote:
>> This patch aims to have mem access vm events sent from the emulator.
>> This is useful where we want to only emulate a page walk without
>> checking the EPT, but we still want to check the EPT when emulating
>> the
On 01.07.2019 16:01, Roger Pau Monné wrote:
> On Mon, Jul 01, 2019 at 11:39:16AM +, Jan Beulich wrote:
>> On 01.07.2019 12:49, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/xstate.c
>>> +++ b/xen/arch/x86/xstate.c
>>> @@ -577,7 +577,7 @@ unsigned int xstate_ctxt_size(u64 xcr0)
>>>/*
>>> On 28.05.19 at 12:32, wrote:
> @@ -155,8 +156,8 @@ static void nmi_mce_softirq(void)
> * Set the tmp value unconditionally, so that the check in the iret
> * hypercall works.
> */
> -cpumask_copy(st->vcpu->cpu_hard_affinity_tmp,
> -
On Mon, Jul 01, 2019 at 11:39:16AM +, Jan Beulich wrote:
> On 01.07.2019 12:49, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/xstate.c
> > +++ b/xen/arch/x86/xstate.c
> > @@ -577,7 +577,7 @@ unsigned int xstate_ctxt_size(u64 xcr0)
> > /* Collect the information of processor's extended state
flight 138661 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138661/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 133580
build-armhf-pvops
>>> On 18.06.19 at 13:54, wrote:
> At the moment the IOMMU flags are not used in p2m-pt and could be used
> on other application.
I don't understand the second half of this sentence. I guess anyway
that you want to at least mention the fact that CPU and IOMMU page
tables can't be shared anymore,
>>> On 04.06.19 at 13:49, wrote:
> This patch aims to have mem access vm events sent from the emulator.
> This is useful where we want to only emulate a page walk without
> checking the EPT, but we still want to check the EPT when emulating
> the instruction that caused the page walk. In this
...in assign_device().
The check of arch.hvm.mem_sharing_enabled flag at the top of
drivers/passthrough/pci.c:assign_device() does not make sure that the
domain is actually an HVM domain.
This patch fixes the issue by moving the definition of the
mem_sharing_enabled() macro from mem_sharing.c
This patch aims to have mem access vm events sent from the emulator.
This is useful where we want to only emulate a page walk without
checking the EPT, but we still want to check the EPT when emulating
the instruction that caused the page walk. In this case, the original
EPT fault is caused by the
Jan Beulich writes ("Re: [xen-4.7-testing test] 138307: regressions - FAIL"):
> On 01.07.2019 12:00, Ian Jackson wrote:
> > osstest service owner writes ("[xen-4.7-testing test] 138307: regressions -
> > FAIL"):
> >> flight 138307 xen-4.7-testing real [real]
> >>
Useful patch, glad to have it on the table.
On 01.07.2019 14:59, Jan Beulich wrote:
> A majority of callers wants just a single iteration handled. Allow to
> express this by passing in a NULL pointer, instead of setting up a local
> variable just to hold the "1" to pass in here.
>
>
On Mon, 24 Jun 2019 at 16:33, Anthony PERARD wrote:
>
> The following changes since commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde:
>
> Merge remote-tracking branch
> 'remotes/amarkovic/tags/mips-queue-jun-21-2019' into staging (2019-06-21
> 15:40:50 +0100)
>
> are available in the Git
On 01.07.19 13:42, Jan Beulich wrote:
On 01.07.2019 13:35, Juergen Gross wrote:
=== x86 ===
* PV-IOMMU (v7)
- Paul Durrant
* HVM guest CPU topology support (RFC)
- Chao Gao
* Intel Processor Trace virtualization enabling (v1)
- Luwei Kang
* Linux stub domains (RFC v2)
Note that the ISA extensions document revision 035 doesn't specify
exception behavior for ModRM.mod != 0b11; assuming #UD here.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -548,6 +548,8 @@ static const struct
The hook is already in use for other purposes, and emulating e.g.
CLFLUSH by issuing WBINVD is, well, not very nice. Rename the hook and
add parameters. Use lighter weight flushing insns when possible in
hvmemul_cache_op().
hvmemul_cache_op() treating x86emul_invd the same as x86emul_wbinvd is
to
A majority of callers wants just a single iteration handled. Allow to
express this by passing in a NULL pointer, instead of setting up a local
variable just to hold the "1" to pass in here.
Signed-off-by: Jan Beulich
---
Note that this conflicts with additions/changes made by "x86emul:
further
Just like for INVLPGA the HVM hook only supports PCID 0 for the time
being for individual address invalidation. It also translates the other
types to a full flush, which is architecturally permitted and
performance-wise presumably not much worse because emulation is slow
anyway.
Signed-off-by:
The hook is already in use for INVLPGA as well. Rename the hook and add
parameters. For the moment INVLPGA with a non-zero ASID remains
unsupported, but the TODO item gets pushed into the actual hook handler.
Signed-off-by: Jan Beulich
---
v2: New.
---
This way the insn emulator can then too use the #define-s.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/include/asm-x86/invpcid.h
+++ b/xen/include/asm-x86/invpcid.h
@@ -5,11 +5,6 @@
extern bool use_invpcid;
-#define INVPCID_TYPE_INDIV_ADDR 0
-#define INVPCID_TYPE_SINGLE_CTXT
Rev 035 of Intel's ISA extensions document does not state intercept
behavior for the insn (I've been in-officially told that the distinction
is going to be by exit qualification, as I would have assumed
considering that this way it's sufficiently transparent to unaware
software, and using WBINVD
On top of the AVX512 series I'd like to put out for review/discussion
1: generalize wbinvd() hook
2: support WBNOINVD
3: generalize invlpg() hook
4: move INVPCID_TYPE_* to x86-defns.h
5: support INVPCID
6: support MOVDIR{I,64B} insns
Jan
___
Xen-devel
On 01.07.2019 13:35, Juergen Gross wrote:
> === x86 ===
>
> * PV-IOMMU (v7)
>- Paul Durrant
>
> * HVM guest CPU topology support (RFC)
>- Chao Gao
>
> * Intel Processor Trace virtualization enabling (v1)
>- Luwei Kang
>
> * Linux stub domains (RFC v2)
>- Marek
On 01.07.2019 12:49, Roger Pau Monne wrote:
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -577,7 +577,7 @@ unsigned int xstate_ctxt_size(u64 xcr0)
> /* Collect the information of processor's extended state */
> void xstate_init(struct cpuinfo_x86 *c)
> {
> -static bool
This email only tracks big items for xen.git tree. Please reply for items you
would like to see in 4.13 so that people have an idea what is going on and
prioritise accordingly.
You're welcome to provide description and use cases of the feature you're
working on.
= Timeline =
We now adopt a
As to the feature dependency adjustment, while strictly speaking SSE is
a sufficient prereq (to have XMM registers), vectors of bytes and qwords
have got introduced only with SSE2. gcc, for example, uses a similar
connection in its respective intrinsics header.
Signed-off-by: Jan Beulich
---
v9:
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
Also use this for AVX512VL VPRO{L,R}{,V}D as well as some further shifts
testing.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v8: New.
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -20,8 +20,9 @@ SIMD := 3dnow sse sse2 sse4 avx avx2 xop
FMA :=
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 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
Acked-by: Andrew Cooper
---
v9:
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
---
v8: New.
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -19,8 +19,9 @@ CFLAGS += $(CFLAGS_xeninclude)
SIMD := 3dnow sse sse2 sse4 avx avx2 xop avx512f avx512bw avx512dq avx512er
avx512vbmi
FMA :=
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.
A new test case (also covering AESNI) will be added to the harness by a
subsequent
A decoder adjustment is needed here because of the current sharing of
table entries between different (implied) opcode prefixes: The same
major opcodes are used for vfmsub{132,213}{p,s}{s,d}, which have a
different memory operand size and different Disp8 scaling.
Signed-off-by: Jan Beulich
---
Along the lines of the 4FMAPS case, convert the 4VNNIW-based table
entries to a decoder adjustment. Because of the current sharing of table
entries between different (implied) opcode prefixes and with the same
major opcodes being used for vp4dpwssd{,s}, which have a different
memory operand size
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
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
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
Acked-by: Andrew Cooper
---
v7: Re-base
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
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
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
Acked-by: Andrew Cooper
---
v9: Re-base.
v6: New.
---
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 compiler built-ins. To suppress expansion of the "di" and "si"
tokens they get constructed by
Some adjustments are necessary to the EVEX Disp8 scaling test code to
account for the zero byte reads/writes, which get issued for the test
harness only.
Signed-off-by: Jan Beulich
---
v9: Suppress general register update upon failures. Re-base.
v8: #GP/#SS don't arise here. Add previously
Signed-off-by: Jan Beulich
---
v9: Suppress general register update upon failures. Split out ModR/M
handling changes as well as independent test harness ones into
prereq patches. Re-base.
v8: Re-base.
v7: Fix ByteOp register decode. Re-base.
v6: New.
---
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
There was an encoding mistake in the EVEX Disp8 test code, which was
benign (due to %rdx getting set to zero) to all non-vSIB tests as it
mistakenly encoded (%rdx,%rdx) instead of (%rdx,%riz). In
the vSIB case this meant (%rdx,%zmm2) instead of the intended
(%rdx,%zmm4).
Likewise the access count
They require getting modrm_reg and sib_index set correctly in the EVEX
case, to account for the high 16 [XYZ]MM registers when used as
addressing index register. Extend the adjustments to modrm_rm as well,
such that x86_insn_modrm() would correctly report register numbers (this
was a latent issue
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
Acked-by: Andrew Cooper
---
v5: New.
---
TBD: The *blendm* built-in functions don't reliably produce the intended
insns, as the respective
Signed-off-by: Jan Beulich
---
v9: Re-base. Drop "(solely)" from a comment.
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[] =
This goes on top of "x86emul: avoid speculative out of bounds
accesses", or else there's a conflict in at least the "gather" patch
here.
01: support AVX512{F,_VBMI2} compress/expand insns
02: support remaining misc AVX512{F,BW} insns
03: prepare for AVX512F S/G insns
04: test harness adjustments
flight 138664 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138664/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf adec1f5deb89c68d8259807456bd575e8f58
baseline version:
ovmf
On 01.07.2019 10:56, Andrew Cooper wrote:
> On 01/07/2019 09:45, Petre Ovidiu PIRCALABU wrote:
>> The problem lies with vfree because it creates a new list with the
>> pages, unmaps the va pointer and then frees the pages. If I do these
>> steps manually (without adding them to a new list) it
LLVM code generation can attempt to load from a variable in the next
condition of an expression under certain circumstances, thus
attempting to load use_xsave regardless of the value of the bsp
variable, which leads to a page fault when the init section has
already been unmapped.
Fix this by
flight 138665 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138665/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 137600
build-arm64-xsm
Hi Andrew,
Andrew Cooper writes:
> A Travis randconfig build notices:
>
> optee.c: In function ‘allocate_and_pin_shm_rpc’:
> optee.c:383:13: error: format ‘%lx’ expects argument of type
>‘long unsigned int’, but argument 5 has type ‘uint64_t’ [-Werror=format=]
> gdprintk(XENLOG_WARNING,
On 01.07.2019 12:00, Ian Jackson wrote:
> osstest service owner writes ("[xen-4.7-testing test] 138307: regressions -
> FAIL"):
>> flight 138307 xen-4.7-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/138307/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are
osstest service owner writes ("[xen-4.7-testing test] 138307: regressions -
FAIL"):
> flight 138307 xen-4.7-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/138307/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be
flight 138659 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138659/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-thunderx broken
build-i386-prev 6
> -Original Message-
> From: Petre Ovidiu PIRCALABU
> Sent: 01 July 2019 10:27
> To: Paul Durrant ; xen-devel@lists.xenproject.org;
> Andrew Cooper
>
> Cc: Alexandru Stefan ISAILA ;
> rcojoc...@bitdefender.com
> Subject: Re: vfree crash
>
> On Mon, 2019-07-01 at 08:55 +, Paul
On Mon, 2019-07-01 at 08:55 +, Paul Durrant wrote:
> > -Original Message-
> > From: Petre Ovidiu PIRCALABU
> > Sent: 01 July 2019 09:46
> > To: Paul Durrant ;
> > xen-devel@lists.xenproject.org; Andrew Cooper
> >
> > Cc: Alexandru Stefan ISAILA ;
> > rcojoc...@bitdefender.com
> >
On 01/07/2019 09:45, Petre Ovidiu PIRCALABU wrote:
> On Mon, 2019-07-01 at 08:29 +, Paul Durrant wrote:
>>> -Original Message-
>>> From: Xen-devel On Behalf
>>> Of Petre Ovidiu PIRCALABU
>>> Sent: 28 June 2019 19:00
>>> To: xen-devel@lists.xenproject.org; Andrew Cooper <
>>>
> -Original Message-
> From: Petre Ovidiu PIRCALABU
> Sent: 01 July 2019 09:46
> To: Paul Durrant ; xen-devel@lists.xenproject.org;
> Andrew Cooper
>
> Cc: Alexandru Stefan ISAILA ;
> rcojoc...@bitdefender.com
> Subject: Re: vfree crash
>
> On Mon, 2019-07-01 at 08:29 +, Paul
On Mon, 2019-07-01 at 08:29 +, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel On Behalf
> > Of Petre Ovidiu PIRCALABU
> > Sent: 28 June 2019 19:00
> > To: xen-devel@lists.xenproject.org; Andrew Cooper <
> > andrew.coop...@citrix.com>
> > Cc: Alexandru Stefan ISAILA ;
1 - 100 of 103 matches
Mail list logo
