[Xen-devel] FYI: GSoC 2017: Xen Project has been accepted as a mentor organization!

Hi everyone, we have been accepted into GSoC this year. This means we will likely have more interest in projects compared to the past and could do with a) more people willing to mentor b) more projects on https://wiki.xenproject.org/wiki/2017-Summer-Internships

[Xen-devel] [xen-unstable bisection] complete test-amd64-i386-freebsd10-amd64

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-freebsd10-amd64 testid xen-boot Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.

Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-freebsd10-amd64

Hello, It seems that your changes are causing issues when booting a 32bit Dom0, it seems there are several IOMMU faults that prevent Dom0 from booting at all. AFAICT this only happens when using a 32bit Dom0. The bisector has pointed several times at this change, so it looks like the culprit. See

Re: [Xen-devel] [PATCH 10/10] x86/cpuid: Always enable faulting for the control domain

>>> On 27.02.17 at 16:10, wrote: > On 22/02/17 10:10, Jan Beulich wrote: > On 22.02.17 at 11:00, wrote: >>> On 22/02/17 09:23, Jan Beulich wrote: >>> On 20.02.17 at 12:00, wrote: > The domain builder in libxc no longer depends on leaked CPUID information > to > properly cons

Re: [Xen-devel] RFC/PATCH: xen: race during domain destruction [Re: [xen-4.7-testing test] 105948: regressions - FAIL]

>>> On 27.02.17 at 16:18, wrote: > I'm therefore doing that now: I ask for backport of: > > f3d47501db2b7bb8dfd6a3c9710b7aff4b1fc55b > xen: fix a (latent) cpupool-related race during domain destroy > > to 4.7. Thanks for working this out! Applied to 4.7-staging. Jan ___

Re: [Xen-devel] [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon, Feb 27, 2017 at 04:43:04PM +0100, Michal Hocko wrote: > On Mon 27-02-17 12:25:10, Heiko Carstens wrote: > > On Mon, Feb 27, 2017 at 11:02:09AM +0100, Vitaly Kuznetsov wrote: > > > A couple of other thoughts: > > > 1) Having all newly added memory online ASAP is probably what people > > > wa

Re: [Xen-devel] [PATCH v4] xen/arm: warn if dom0_mem is not specified

On Mon, Feb 27, 2017 at 03:14:07PM -0800, Stefano Stabellini wrote: > The default dom0_mem is 128M which is not sufficient to boot a Ubuntu > based Dom0. It is not clear what a better default value could be. > > Instead, loudly warn the user when dom0_mem is unspecified and wait 3 > secs. Then use

Re: [Xen-devel] [PATCH] xl: move some helper functions to xl_utils.c

Wei Liu writes ("[PATCH] xl: move some helper functions to xl_utils.c"): > Move some commonly used functions to a new file. Acked-by: Ian Jackson ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

In stubdom environment __XEN_INTERFACE_VERSION__ is sometimes defined on the command line of the build instruction. This conflicts with xen-compat.h defining it unconditionally if __XEN__ or __XEN_TOOLS__ is set. Just use #undef in this case to avoid the resulting warning. Signed-off-by: Juergen

[Xen-devel] [PATCH 2/4] tools: add pkg-config file for libxc

When configuring the build of qemu the configure script is building various test programs to determine the exact version of libxencontrol. Instead of a try and error approach needing updates for nearly each new version of Xen just provide xencontrol.pc to be used via pkg-config. In the end we nee

[Xen-devel] [PATCH 0/4] build enhancements related to qemu

Last week I started an effort to use upstream qemu as a replacement for qemu-trad in ioemu stubdom. This small series addresses some problems I met in this effort. I believe all modifications are worth doing regardless whether qemu upstream stubdom will become a reality or not. Juergen Gross (4):

[Xen-devel] [PATCH 4/4] tools: set pkg-config path when configuring qemu

When calling configure for qemu provide the local pkg-config directory in order to let the configure process find the libxenctrl version. Signed-off-by: Juergen Gross --- tools/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/Makefile b/tools/Makefile index 99080ab..d6f8ce1 100

[Xen-devel] [PATCH 3/4] tools: use a dedicated build directory for qemu

Instead of using the downloaded git tree as target directory for the qemu build create a dedicated directory for that purpose. Signed-off-by: Juergen Gross --- .gitignore | 1 + tools/Makefile | 13 +++-- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/.gitignore b/.g

Re: [Xen-devel] [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

On 28/02/17 10:34, Juergen Gross wrote: > In stubdom environment __XEN_INTERFACE_VERSION__ is sometimes defined > on the command line of the build instruction. This conflicts with > xen-compat.h defining it unconditionally if __XEN__ or __XEN_TOOLS__ > is set. > > Just use #undef in this case to av

Re: [Xen-devel] [PATCH v8 00/24] Enable L2 Cache Allocation Technology & Refactor psr.c

On Wed, Feb 15, 2017 at 04:49:15PM +0800, Yi Sun wrote: > Hi all, > > We plan to bring a new PSR (Platform Shared Resource) feature called > Intel L2 Cache Allocation Technology (L2 CAT) to Xen. > > Besides the L2 CAT implementaion, we refactor the psr.c to make it more > flexible to add new feat

[Xen-devel] [qemu-mainline baseline-only test] 68618: tolerable trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 68618 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68618/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-che

Re: [Xen-devel] [PATCH 4/4] tools: set pkg-config path when configuring qemu

Juergen Gross writes ("[PATCH 4/4] tools: set pkg-config path when configuring qemu"): > When calling configure for qemu provide the local pkg-config directory > in order to let the configure process find the libxenctrl version. Is PKG_CONFIG_PATH used _in addition to_ the built-in paths, or does

Re: [Xen-devel] [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

Juergen Gross writes ("[PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__"): > In stubdom environment __XEN_INTERFACE_VERSION__ is sometimes defined > on the command line of the build instruction. This conflicts with > xen-compat.h defining it unconditionally if __XEN__ or __XE

Re: [Xen-devel] [PATCH 4/4] tools: set pkg-config path when configuring qemu

On 28/02/17 12:08, Ian Jackson wrote: > Juergen Gross writes ("[PATCH 4/4] tools: set pkg-config path when > configuring qemu"): >> When calling configure for qemu provide the local pkg-config directory >> in order to let the configure process find the libxenctrl version. > > Is PKG_CONFIG_PATH u

Re: [Xen-devel] [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

>>> On 28.02.17 at 11:34, wrote: > In stubdom environment __XEN_INTERFACE_VERSION__ is sometimes defined > on the command line of the build instruction. This conflicts with > xen-compat.h defining it unconditionally if __XEN__ or __XEN_TOOLS__ > is set. Then that's what wants fixing. In fact it's

Re: [Xen-devel] [PATCH 2/4] tools: add pkg-config file for libxc

Juergen Gross writes ("[PATCH 2/4] tools: add pkg-config file for libxc"): > When configuring the build of qemu the configure script is building > various test programs to determine the exact version of libxencontrol. > > Instead of a try and error approach needing updates for nearly each > new ve

Re: [Xen-devel] [PATCH 3/4] tools: use a dedicated build directory for qemu

Juergen Gross writes ("[PATCH 3/4] tools: use a dedicated build directory for qemu"): > Instead of using the downloaded git tree as target directory for the > qemu build create a dedicated directory for that purpose. ... why ? Ian. ___ Xen-devel maili

Re: [Xen-devel] [PATCH 4/4] tools: set pkg-config path when configuring qemu

Juergen Gross writes ("Re: [PATCH 4/4] tools: set pkg-config path when configuring qemu"): > On 28/02/17 12:08, Ian Jackson wrote: > > Is PKG_CONFIG_PATH used _in addition to_ the built-in paths, or does > > it replace them ? > > It is in addition. Good. Thanks. Acked-by: Ian Jackson ___

[Xen-devel] [libvirt test] 106226: tolerable FAIL - PUSHED

flight 106226 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/106226/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 106101 test-armhf-armhf-libvirt-xsm 13

Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-freebsd10-amd64

>>> On 28.02.17 at 10:20, wrote: > It seems that your changes are causing issues when booting a 32bit Dom0, it > seems there are several IOMMU faults that prevent Dom0 from booting at all. > AFAICT this only happens when using a 32bit Dom0. The bisector has pointed > several times at this change,

[Xen-devel] [PATCH] efi/boot: Avoid memory corruption when freeing ebmalloc area

Don't free the final page containing a partial allocation. Signed-off-by: Andrew Cooper --- CC: Jan Beulich NB: This was from code inspection. It is not whatever is causing the bisector to finger this commit. --- xen/common/efi/boot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) dif

[Xen-devel] [PATCH v3 1/7] xen: credit2: make accessor helpers inline functions instead of macros

There isn't any particular reason for the accessor helpers to be macro, so turn them into 'static inline'-s, which are better. Note that it is necessary to move the function definitions below the structure declarations. No functional change intended. Signed-off-by: Dario Faggioli --- Cc: George

[Xen-devel] [PATCH v3 0/7] xen: credit2: improve style, and tracing; fix two bugs

Hello This is v3 of the still uncommitted patches of this series. I believe I have either responded to or addressed all the review comments. See the individual changelogs for more details. Previous versions are here: v2 https://lists.xen.org/archives/html/xen-devel/2017-02/msg01027.html v1 http

[Xen-devel] [PATCH v3 3/7] xen: credit2: group the runq manipulating functions.

So that they're all close among each other, and also near to the comment describind the runqueue organization (which is also moved). No functional change intended. Signed-off-by: Dario Faggioli --- Cc: George Dunlap Cc: Anshul Makkar --- Changes from v2: * don't move the 'credit2_runqueue' opt

[Xen-devel] [PATCH v3 2/7] xen: credit2: tidy up functions names by removing leading '__'.

There is no reason for having pretty much all of the functions whose names begin with double underscores ('__') to actually look like that. In fact, that is misleading and makes the code hard to read and understand. So, remove the '__'-s. The only two that we keep are __runq_assign() and __runq_d

[Xen-devel] [PATCH v3 4/7] xen: credit2: always mark a tickled pCPU as... tickled!

In fact, whether or not a pCPU has been tickled, and is therefore about to re-schedule, is something we look at and base decisions on in various places. So, let's make sure that we do that basing on accurate information. While there, also tweak a little bit smt_idle_mask_clear() (used for impleme

[Xen-devel] [PATCH v3 5/7] xen: credit2: don't miss accounting while doing a credit reset.

A credit reset basically means going through all the vCPUs of a runqueue and altering their credits, as a consequence of a 'scheduling epoch' having come to an end. Blocked or runnable vCPUs are fine, all the credits they've spent running so far have been accounted to them when they were scheduled

[Xen-devel] [PATCH v3 6/7] xen/tools: tracing: trace (Credit2) runq traversal.

When traversing a Credit2 runqueue to select the best candidate vCPU to be run next, show in the trace which vCPUs we consider. A bit verbose, but quite useful, considering that we may end up looking at, but then discarding, one of more vCPU. This will help understand which ones are skipped and wh

[Xen-devel] [PATCH v3 7/7] xen/tools: tracing: Report next slice time when continuing as well as switching

We record trace information about the next timeslice when switching to a different vcpu, but not when continuing to run the same cpu: csched2:schedule cpu 9, rq# 1, idle, SMT idle, tickled csched2:runq_candidate d0v3, 0 vcpus skipped, cpu 9 was tickled sched_switch prev d32767v9, run for 991.18

Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-freebsd10-amd64

On 28/02/17 11:37, Jan Beulich wrote: On 28.02.17 at 10:20, wrote: >> It seems that your changes are causing issues when booting a 32bit Dom0, it >> seems there are several IOMMU faults that prevent Dom0 from booting at all. >> AFAICT this only happens when using a 32bit Dom0. The bisector ha

Re: [Xen-devel] [PATCH v8 03/24] x86: refactor psr: implement main data structures.

On Wed, Feb 15, 2017 at 04:49:18PM +0800, Yi Sun wrote: > To construct an extendible framework, we need analyze PSR features > and abstract the common things and feature specific things. Then, > encapsulate them into different data structures. > > By analyzing PSR features, we can get below map. >

Re: [Xen-devel] [PATCH v2 08/10] x86/SVM: Add interrupt management code via AVIC

On 02/01/17 17:45, Andrew Cooper wrote: > On 31/12/2016 05:45, Suravee Suthikulpanit wrote: >> Enabling AVIC implicitly disables the V_IRQ, V_INTR_PRIO, V_IGN_TPR, >> and V_INTR_VECTOR fields in the VMCB Control Word. Therefore, this patch >> introduces new interrupt injection code via AVIC backing

Re: [Xen-devel] [PATCH] efi/boot: Avoid memory corruption when freeing ebmalloc area

>>> On 28.02.17 at 12:44, wrote: > --- a/xen/common/efi/boot.c > +++ b/xen/common/efi/boot.c > @@ -148,7 +148,7 @@ static void __init __maybe_unused > free_ebmalloc_unused_mem(void) > { > unsigned long start, end; > > -start = (unsigned long)ebmalloc_mem + PAGE_ALIGN(ebmalloc_allocate

Re: [Xen-devel] [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

On 28/02/17 12:11, Jan Beulich wrote: On 28.02.17 at 11:34, wrote: >> In stubdom environment __XEN_INTERFACE_VERSION__ is sometimes defined >> on the command line of the build instruction. This conflicts with >> xen-compat.h defining it unconditionally if __XEN__ or __XEN_TOOLS__ >> is set. >

[Xen-devel] [ovmf test] 106234: regressions - FAIL

flight 106234 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/106234/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963 test-amd64-amd64-xl-qemuu-

[Xen-devel] [distros-debian-snapshot test] 68619: regressions - trouble: blocked/broken/fail/pass

flight 68619 distros-debian-snapshot real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68619/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-i386-daily-netboot-pvgrub 9 debian-di-install fail REGR. vs. 68586

Re: [Xen-devel] [PATCH 2/4] tools: add pkg-config file for libxc

On 28/02/17 12:13, Ian Jackson wrote: > Juergen Gross writes ("[PATCH 2/4] tools: add pkg-config file for libxc"): >> When configuring the build of qemu the configure script is building >> various test programs to determine the exact version of libxencontrol. >> >> Instead of a try and error approa

Re: [Xen-devel] [PATCH v8 06/24] x86: refactor psr: implement get hw info flow.

On Wed, Feb 15, 2017 at 04:49:21PM +0800, Yi Sun wrote: > This patch implements get HW info flow including L3 CAT callback > function. > > It also changes sysctl interface to make it more general. > > With this patch, 'psr-hwinfo' can work for L3 CAT. > > Signed-off-by: Yi Sun > Reviewed-by: Ko

Re: [Xen-devel] [PATCH 3/4] tools: use a dedicated build directory for qemu

On 28/02/17 12:13, Ian Jackson wrote: > Juergen Gross writes ("[PATCH 3/4] tools: use a dedicated build directory for > qemu"): >> Instead of using the downloaded git tree as target directory for the >> qemu build create a dedicated directory for that purpose. > > ... why ? Hmm, yes, I should ha

[Xen-devel] Retrieving the precise guest start time via libxc or similar?

Hello, xc_domain_getinfo() gets us info->cpu_time, which, if I understand correctly, is the guest uptime. Is there an officially sanctioned way of retrieving the _exact_ guest start time? Obviously we can compute an approximation by doing now - info->cpu_time, but we'd like to be able to uniquely

Re: [Xen-devel] [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

On 28/02/17 12:10, Ian Jackson wrote: > Juergen Gross writes ("[PATCH 1/4] interface: avoid redefinition of > __XEN_INTERFACE_VERSION__"): >> In stubdom environment __XEN_INTERFACE_VERSION__ is sometimes defined >> on the command line of the build instruction. This conflicts with >> xen-compat.h d

[Xen-devel] [PATCH v4 00/17] x86emul: MMX/SSEn support

This includes support for AVX counterparts of them as well as a few later SSE additions (basically covering the entire 0f-prefixed opcode space, but not the 0f38 and 0f3a ones, nor 3dnow). 1: support most memory accessing MMX/SSE{,2,3} insns 2: support MMX/SSE{,2,3} moves 3: support MMX/SSE/SSE

Re: [Xen-devel] [PATCH v8 07/24] x86: refactor psr: implement get value flow.

On Wed, Feb 15, 2017 at 04:49:22PM +0800, Yi Sun wrote: > This patch implements get value flow including L3 CAT callback > function. > > It also changes domctl interface to make it more general. > > With this patch, 'psr-cat-show' can work for L3 CAT but not for > L3 code/data which is implemente

Re: [Xen-devel] [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

>>> On 28.02.17 at 13:24, wrote: > On 28/02/17 12:11, Jan Beulich wrote: > On 28.02.17 at 11:34, wrote: >>> In stubdom environment __XEN_INTERFACE_VERSION__ is sometimes defined >>> on the command line of the build instruction. This conflicts with >>> xen-compat.h defining it unconditionally

[Xen-devel] [PATCH v4 02/17] x86emul: support MMX/SSE{,2,3} moves

Previously supported insns are being converted to the new model, and several new ones are being added. To keep the stub handling reasonably simple, integrate SET_SSE_PREFIX() into copy_REX_VEX(), at once switching the stubs to use an empty REX prefix instead of a double DS: one (no byte registers

[Xen-devel] [PATCH v4 01/17] x86emul: support most memory accessing MMX/SSE{, 2, 3} insns

e 0x0f-escape space with memory operands. Not covered here are irregular moves, converts, and {,U}COMIS{S,D} (modifying EFLAGS). Note that the distinction between simd_*_fp isn't strictly needed, but I've kept them as separate entries since in an earlier version I needed them to be separate, and w

[Xen-devel] [PATCH v4 03/17] x86emul: support MMX/SSE/SSE2 converts

Note that other than most scalar instructions, vcvt{,t}s{s,d}2si do #UD when VEX.l is set on at least some Intel models. To be on the safe side, implement the most restrictive mode here for now when emulating an Intel CPU, and simply clear the bit when emulating an AMD one. Signed-off-by: Jan Beul

[Xen-devel] [PATCH v4 04/17] x86emul: support {,V}{,U}COMIS{S,D}

Signed-off-by: Jan Beulich --- v4: Add missing copy_REX_VEX(). v3: Ignore VEX.l. Add fic.exn_raised constraint to invoke_stub() use. v2: Add missing RET to stub. Generate #UD (instead of simply failing) when VEX.l is disallowed. --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/

[Xen-devel] [PATCH v4 05/17] x86emul: support MMX/SSE{, 2, 4a} insns with only register operands

This involves fixing a decode bug: VEX encoded insns aren't necessarily followed by a ModR/M byte. Signed-off-by: Jan Beulich --- v4: Add missing setting of op_bytes to insertq (register form) handling. v3: Simplify handling of extrq/insertq register forms. Use simd_0f_xmm label. v2: Corr

Re: [Xen-devel] [PATCH 2/4] tools: add pkg-config file for libxc

On Tue, Feb 28, 2017 at 01:32:06PM +0100, Juergen Gross wrote: > And I don't see why it would be wrong to use the same basic mechanism > for our internal build as for any "normal" build outside of the Xen > build environment. > +1 for this. ___ Xen-dev

[Xen-devel] [PATCH v4 06/17] x86emul: support {,V}{LD,ST}MXCSR

Signed-off-by: Jan Beulich --- v4: Drop the host_and_ part from the AVX checks. v3: Re-base. --- a/tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c +++ b/tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c @@ -660,7 +660,7 @@ int LLVMFuzzerTestOneInput(const uint8_t

[Xen-devel] [PATCH v4 07/17] x86emul: support {,V}MOVNTDQA

... as the only post-SSE2 move insn. Signed-off-by: Jan Beulich --- v3: Re-base. v2: Re-base. --- a/tools/tests/x86_emulator/test_x86_emulator.c +++ b/tools/tests/x86_emulator/test_x86_emulator.c @@ -2398,6 +2398,74 @@ int main(int argc, char **argv) else printf("skipped\n"); +

[Xen-devel] [PATCH v4 08/17] x86emul: test coverage for SSE/SSE2 insns

... and their AVX equivalents. Note that a few instructions aren't covered (yet), but those all fall into common pattern groups, so I would hope that for now we can do with what is there. MMX insns aren't being covered at all, as they're not easy to deal with: The compiler refuses to emit such for

[Xen-devel] [PATCH v4 09/17] x86emul: honor MMXEXT feature flag

This being a strict (MMX register only) subset of SSE, we can simply adjust the respective checks while making the new predicate look at both flags. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@

[Xen-devel] [PATCH v4 10/17] x86emul: add tables for 0f38 and 0f3a extension space

Convert the few existing opcodes so far supported. 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 @@ -43,6 +43,8 @@ #define SrcMask (7<<3) /* Generic ModRM decode. */ #define ModRM (1<<6) +/* vSIB add

[Xen-devel] [PATCH v4 11/17] x86emul: support SSSE3 insns

... and their AVX equivalents. 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 @@ -348,6 +348,8 @@ static const struct { uint8_t two_op:1; uint8_t vsib:1; } ext0f38_table[256] = { +[0x00 ... 0x0b] =

[Xen-devel] [PATCH v4 12/17] x86emul: support SSE4.1 insns

... and their AVX equivalents. Signed-off-by: Jan Beulich --- v4: Or in ByteOp for {,v}pinsrb instead of assigning it (in x86_decode_0f3a()). Correct case label for ptest. Add missing copy_REX_VEX() to {,v}ptest handling. Add missing immediate bytes to {,v}pextr* etc handling. dppd re

[Xen-devel] [PATCH v4 13/17] x86emul: support SSE4.2 insns

... and their AVX equivalents. Signed-off-by: Jan Beulich --- v3: New. --- a/tools/tests/x86_emulator/test_x86_emulator.c +++ b/tools/tests/x86_emulator/test_x86_emulator.c @@ -2542,6 +2542,149 @@ int main(int argc, char **argv) else printf("skipped\n"); +printf("%-40s", "Tes

[Xen-devel] [PATCH v4 14/17] x86emul: test coverage for SSE3/SSSE3/SSE4* insns

... and their AVX equivalents. Note that a few instructions aren't covered (yet), but those all fall into common pattern groups, so I would hope that for now we can do with what is there. Just like for SSE/SSE2, MMX insns aren't being covered at all, as they're not easy to deal with: The compiler

[Xen-devel] [PATCH v4 15/17] x86emul: support PCLMULQDQ

... and its AVX equivalent. 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 @@ -393,6 +393,7 @@ static const struct { [0x22] = { .simd_size = simd_none }, [0x40 ... 0x41] = { .simd_size = simd_packed_fp }

[Xen-devel] [PATCH v4 16/17] x86emul: support AESNI insns

... and their AVX equivalents. 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 @@ -368,6 +368,8 @@ static const struct { [0x37 ... 0x3f] = { .simd_size = simd_packed_int }, [0x40] = { .simd_size = simd_pa

[Xen-devel] [PATCH v4 17/17] x86emul: support SHA insns

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 @@ -368,6 +368,7 @@ static const struct { [0x37 ... 0x3f] = { .simd_size = simd_packed_int }, [0x40] = { .simd_size = simd_packed_int }, [0x41] = { .sim

Re: [Xen-devel] [PATCH 2/4] tools: add pkg-config file for libxc

Juergen Gross writes ("Re: [PATCH 2/4] tools: add pkg-config file for libxc"): > On 28/02/17 12:13, Ian Jackson wrote: > > I worry though that we're breaking new ground. Did you come up with > > this idea yourself ? > > Yes. How exciting. > > Are you aware of other projects that do something si

Re: [Xen-devel] [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

On 28/02/17 13:46, Jan Beulich wrote: On 28.02.17 at 13:24, wrote: >> On 28/02/17 12:11, Jan Beulich wrote: >> On 28.02.17 at 11:34, wrote: In stubdom environment __XEN_INTERFACE_VERSION__ is sometimes defined on the command line of the build instruction. This conflicts with >>

Re: [Xen-devel] [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

Juergen Gross writes ("Re: [Xen-devel] [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__"): > Hmm, maybe this is the problem: the value from the command line is > (textually) __XEN_LATEST_INTERFACE_VERSION__ while the value from the > #define is the _value_ of __XEN_LATEST_INT

Re: [Xen-devel] [PATCH 3/4] tools: use a dedicated build directory for qemu

Juergen Gross writes ("Re: [PATCH 3/4] tools: use a dedicated build directory for qemu"): > On 28/02/17 12:13, Ian Jackson wrote: > > ... why ? > > Hmm, yes, I should have added the reason to the commit description: > > This way I can use the same source directory of qemu for my effort to > conf

Re: [Xen-devel] [PATCH 3/4] tools: use a dedicated build directory for qemu

On 28/02/17 14:14, Ian Jackson wrote: > Juergen Gross writes ("Re: [PATCH 3/4] tools: use a dedicated build directory > for qemu"): >> On 28/02/17 12:13, Ian Jackson wrote: >>> ... why ? >> >> Hmm, yes, I should have added the reason to the commit description: >> >> This way I can use the same sou

[Xen-devel] [xen-unstable test] 106218: regressions - trouble: blocked/broken/fail/pass

flight 106218 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/106218/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64 8 leak-check/basis(8) fail REGR. vs. 105933 test-amd64-

[Xen-devel] [PATCH 0/8] x86: switch away from temporary 32-bit register names

This is only part of the necessary changes. Some needed to be dropped due to code having changed recently, and the biggest missing part is the adjustment of the insn emulator, when I'd prefer to do this work only after the non-RFC parts of https://lists.xenproject.org/archives/html/xen-devel/2017-0

Re: [Xen-devel] Next Xen ARM community call

Hi, I haven't seen any complain with the time suggested by Stefano. So the Community call will be at 5pm UTC tomorrow (Wednesday 1st March). Regarding the agenda, the topics I have so far are: - PV protocols - IRQ latency Do we have any other topics to discuss? For joining the call,

Re: [Xen-devel] [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

>>> On 28.02.17 at 14:10, wrote: > On 28/02/17 13:46, Jan Beulich wrote: > On 28.02.17 at 13:24, wrote: >>> On 28/02/17 12:11, Jan Beulich wrote: >>> On 28.02.17 at 11:34, wrote: > In stubdom environment __XEN_INTERFACE_VERSION__ is sometimes defined > on the command line of the

[Xen-devel] [PATCH 1/8] x86: re-introduce non-underscore prefixed 32-bit register names

For a transitional period (until we've managed to replace all underscore prefixed instances), allow both names to co-exist. Signed-off-by: Jan Beulich --- a/xen/include/public/arch-x86/xen-x86_64.h +++ b/xen/include/public/arch-x86/xen-x86_64.h @@ -134,7 +134,7 @@ struct iret_context { /* Anony

[Xen-devel] [PATCH 2/8] x86: switch away from temporary 32-bit register names

Signed-off-by: Jan Beulich --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -1015,11 +1015,11 @@ int arch_set_info_guest( init_int80_direct_trap(v); /* IOPL privileges are virtualised. */ -v->arch.pv_vcpu.iopl = v->arch.user_regs._eflags & X86_EFLAGS_IOPL; -v->arch.u

[Xen-devel] [PATCH 3/8] x86/HVM: switch away from temporary 32-bit register names

Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -2968,20 +2968,20 @@ void hvm_task_switch( if ( rc != HVMCOPY_okay ) goto out; -eflags = regs->_eflags; +eflags = regs->eflags; if ( taskswitch_reason == TSW_iret ) eflags

[Xen-devel] [PATCH 4/8] x86/HVMemul: switch away from temporary 32-bit register names

Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@ -442,7 +442,7 @@ static int hvmemul_linear_to_phys( } /* Reverse mode if this is a backwards multi-iteration string operation. */ -reverse = (hvmemul_ctxt->ctxt.regs->_eflags & X86_EFLA

[Xen-devel] [PATCH 5/8] x86/mm: switch away from temporary 32-bit register names

Signed-off-by: Jan Beulich --- a/xen/arch/x86/mm/guest_walk.c +++ b/xen/arch/x86/mm/guest_walk.c @@ -196,7 +196,7 @@ guest_walk_tables(struct vcpu *v, struct * - Page fault in kernel mode */ smap = hvm_smap_enabled(v) && - ((hvm_get_cpl

Re: [Xen-devel] Next Xen ARM community call

Hi Julien We would also like to discuss a topic raised recently by Volodymyr Babchuk - SMC/HVC handling in Xen. ARTEM MYGAIEV Director, Technology Solutions   Office: +380 44 390 5457 x 65570   Cell: +380 67 921 1131   Email: artem_myga...@epam.com Kyiv, Ukraine (GMT+3)   epam.com   CONFIDENTI

[Xen-devel] [PATCH 6/8] x86/SVM: switch away from temporary 32-bit register names

Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/svm/nestedsvm.c +++ b/xen/arch/x86/hvm/svm/nestedsvm.c @@ -975,7 +975,7 @@ nsvm_vmcb_guest_intercepts_exitcode(stru break; ns_vmcb = nv->nv_vvmcx; vmexits = nsvm_vmcb_guest_intercepts_msr(svm->ns_cached_msrpm, -

[Xen-devel] [PATCH 5/8] x86/Viridian: switch away from temporary 32-bit register names

Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/viridian.c +++ b/xen/arch/x86/hvm/viridian.c @@ -666,9 +666,9 @@ int viridian_hypercall(struct cpu_user_r output_params_gpa = regs->r8; break; case 4: -input.raw = (regs->rdx << 32) | regs->_eax; -input_param

[Xen-devel] [PATCH 8/8] x86/VMX: switch away from temporary 32-bit register names

Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/vmx/realmode.c +++ b/xen/arch/x86/hvm/vmx/realmode.c @@ -72,7 +72,7 @@ static void realmode_deliver_exception( /* We can't test hvmemul_ctxt->ctxt.sp_size: it may not be initialised. */ if ( hvmemul_ctxt->seg_reg[x86_seg_ss].attr.field

Re: [Xen-devel] [PATCH 4/8] x86/HVMemul: switch away from temporary 32-bit register names

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 28 February 2017 13:37 > To: xen-devel > Cc: Andrew Cooper ; Paul Durrant > ; George Dunlap > Subject: [PATCH 4/8] x86/HVMemul: switch away from temporary 32-bit > register names > > Signed-off-by: Jan Beulich >

Re: [Xen-devel] [PATCH 0/8] x86: switch away from temporary 32-bit register names

On 28/02/17 13:27, Jan Beulich wrote: > This is only part of the necessary changes. Some needed to be > dropped due to code having changed recently, and the biggest > missing part is the adjustment of the insn emulator, when I'd > prefer to do this work only after the non-RFC parts of > https://lis

Re: [Xen-devel] [PATCH 5/8] x86/Viridian: switch away from temporary 32-bit register names

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 28 February 2017 13:39 > To: xen-devel > Cc: Andrew Cooper ; Paul Durrant > ; George Dunlap > Subject: [PATCH 5/8] x86/Viridian: switch away from temporary 32-bit > register names > > Signed-off-by: Jan Beulich

Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor

On 11/02/17 00:14, Volodymyr Babchuk wrote: Hello, Hi Volodymyr, This e-mail is sort of follow-up to the two threads: [1] (my thread about TEE interaction) and [2] (Edgar's thread regarding handling SMC calls in platform_hvc). I want to discuss more broad topic there. Obviously, there are

Re: [Xen-devel] [PATCH 1/4] interface: avoid redefinition of __XEN_INTERFACE_VERSION__

On 28/02/17 14:13, Ian Jackson wrote: > Juergen Gross writes ("Re: [Xen-devel] [PATCH 1/4] interface: avoid > redefinition of __XEN_INTERFACE_VERSION__"): >> Hmm, maybe this is the problem: the value from the command line is >> (textually) __XEN_LATEST_INTERFACE_VERSION__ while the value from the

Re: [Xen-devel] [PATCH 6/8] x86/SVM: switch away from temporary 32-bit register names

On 02/28/2017 08:38 AM, Jan Beulich wrote: > Signed-off-by: Jan Beulich Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable-smoke test] 106258: tolerable trouble: broken/fail/pass - PUSHED

flight 106258 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/106258/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5 xen

Re: [Xen-devel] [PATCH v3 3/7] xen: credit2: group the runq manipulating functions.

On 28/02/17 11:52, Dario Faggioli wrote: > +static inline bool_t same_node(unsigned int cpua, unsigned int cpub) s/bool_t/bool/g > > + > +if ( unlikely(tb_init_done) ) > +{ > +struct { > +unsigned rqi:16, max_weight:16; More commonly known as uint16_t :) ~Andrew ___

Re: [Xen-devel] [PATCH v8 08/24] x86: refactor psr: set value: implement framework.

On Wed, Feb 15, 2017 at 04:49:23PM +0800, Yi Sun wrote: > As set value flow is the most complicated one in psr, it will be > divided to some patches to make things clearer. This patch > implements the set value framework to show a whole picture firstly. > > It also changes domctl interface to make

Re: [Xen-devel] [PATCH 0/8] x86: switch away from temporary 32-bit register names

>>> On 28.02.17 at 14:47, wrote: > On 28/02/17 13:27, Jan Beulich wrote: >> This is only part of the necessary changes. Some needed to be >> dropped due to code having changed recently, and the biggest >> missing part is the adjustment of the insn emulator, when I'd >> prefer to do this work only

[Xen-devel] [xen-4.4-testing test] 106220: regressions - FAIL

flight 106220 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/106220/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xend-qemut-winxpsp3 15 guest-localmigrate/x10 fail in 106051 REGR. vs. 105835

Re: [Xen-devel] [PATCH v3 3/7] xen: credit2: group the runq manipulating functions.

On Tue, 2017-02-28 at 13:55 +, Andrew Cooper wrote: > On 28/02/17 11:52, Dario Faggioli wrote: > > > > +static inline bool_t same_node(unsigned int cpua, unsigned int > > cpub) > > s/bool_t/bool/g > Oh.. Yes, you're right. Sorry! > > + > > +if ( unlikely(tb_init_done) ) > > +{ > > +

Re: [Xen-devel] [PATCH v8 13/24] x86: refactor psr: implement CPU init and free flow for CDP.

On Wed, Feb 15, 2017 at 04:49:28PM +0800, Yi Sun wrote: > This patch implements the CPU init and free flow for CDP including L3 CDP > initialization callback function. > > Signed-off-by: Yi Sun > --- > xen/arch/x86/psr.c | 104 > + > 1 file ch

Re: [Xen-devel] [PATCH v8 14/24] x86: refactor psr: implement get hw info flow for CDP.

On Wed, Feb 15, 2017 at 04:49:29PM +0800, Yi Sun wrote: > This patch implements get HW info flow for CDP including L3 CDP callback > function. > > It also changes sysctl function to make it work for CDP. > > With this patch, 'psr-hwinfo' can work for L3 CDP. > > Signed-off-by: Yi Sun > --- > x

Re: [Xen-devel] [PATCH v8 15/24] x86: refactor psr: implement get value flow for CDP.

On Wed, Feb 15, 2017 at 04:49:30PM +0800, Yi Sun wrote: > This patch implements L3 CDP get value callback function. > > With this patch, 'psr-cat-show' can work for L3 CDP. > > Signed-off-by: Yi Sun > --- > xen/arch/x86/psr.c | 16 > 1 file changed, 16 insertions(+) > > diff -

  1   2   >