[Xen-devel] [PATCH] x86/HVM: fold hypercall tables

In order to reduce the risk of unintentionally adding a function pointer to just one of the two tables, merge them into one, with each entry pair getting generated by a single macro invocation (at once dropping all explicit casting outside the macro definition). Signed-off-by: Jan Beulich

[Xen-devel] [PATCH] common: re-arrange struct kernel_param fields

Even if placed in .init.* there's no reason to needlessly bloat the binary due to padding fields the compiler needs to insert on 64-bit architectures. Signed-off-by: Jan Beulich --- a/xen/include/xen/init.h +++ b/xen/include/xen/init.h @@ -81,34 +81,35 @@ struct kernel_param

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

flight 82511 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/82511/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12

[Xen-devel] [PATCH v3 2/2] xen/vm-events: Move parts of monitor_domctl code to common-side.

This patch moves monitor_domctl to common-side. Purpose: move what's common to common, prepare for implementation of such vm-events on ARM. * move get_capabilities to arch-side => arch_monitor_get_capabilities. * add arch-side monitor op handling function => arch_monitor_domctl_op. e.g.

[Xen-devel] [PATCH v3 1/2] xen/x86: merge 2 hvm_event_... functions into 1

This patch merges almost identical functions hvm_event_int3 and hvm_event_single_step into a single function called hvm_event_breakpoint. Also fixes event.c file header comment in the process. Signed-off-by: Corneliu ZUZU --- xen/arch/x86/hvm/event.c| 108

[Xen-devel] [PATCH v3 0/2] Vm-events: move monitor vm-events code to common-side.

This patch series is an attempt to move some of the monitor vm-events code to the common-side. Done to make it easier to move additional parts that can be moved to common when ARM-side implementations are to be added. Patches summary: 1. Merge almost identical functions hvm_event_int3 +

Re: [Xen-devel] [PATCH v2 1/1] XEN/ARM: Add Odroid-XU3/XU4 support

On Thu, Feb 11, 2016 at 1:40 AM, Ian Campbell wrote: > On Wed, 2016-02-10 at 17:47 -0800, Suriyan Ramasami wrote: > > > > > > On Wed, Feb 10, 2016 at 2:03 AM, Ian Campbell > > wrote: > > > On Tue, 2016-02-09 at 10:20 -0800, Suriyan Ramasami

[Xen-devel] [qemu-upstream-4.6-testing test] 82482: tolerable FAIL - PUSHED

flight 82482 qemu-upstream-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/82482/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-qcow2 6 xen-boot fail in 82162 pass in 82482

Re: [Xen-devel] [PATCH v8 5/5] Scripts to create and delete xen-scsiback nodes in Linux target framework

On 12/02/16 19:36, Olaf Hering wrote: > On Fri, Feb 12, Wei Liu wrote: > >> On Thu, Feb 11, 2016 at 03:43:31PM +, Olaf Hering wrote: >>> Just to make them public, not meant for merging: >> >> I might be mistaken, but if you don't provide a hotplug script or some >> sort for Xen how do you

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

flight 82450 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/82450/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 65543

Re: [Xen-devel] [PATCH net-next v1 0/8] xen-netback: support toeplitz hashing

On Fri, Feb 12, 2016 at 5:59 PM, Paul Durrant wrote: >> -Original Message- >> From: David Miller [mailto:da...@davemloft.net] >> Sent: 12 February 2016 16:42 >> To: Paul Durrant >> Cc: net...@vger.kernel.org; xen-de...@lists.xenproject.org >> Subject: Re: [PATCH

Re: [Xen-devel] [PATCH net-next v1 1/8] skbuff: store hash type in socket buffer...

On Fri, Feb 12, 2016 at 11:13 AM, Paul Durrant wrote: > ...rather than a boolean merely indicating a canonical L4 hash. > > skb_set_hash() takes a hash type (from enum pkt_hash_types) as an > argument but information is lost since only a single bit in the skb > stores

Re: [Xen-devel] [PATCH net-next v1 7/8] xen-netback: pass toeplitz hash value to the frontend

On Fri, Feb 12, 2016 at 11:13 AM, Paul Durrant wrote: > My recent patch to include/xen/interface/io/netif.h defines a new extra > info type that can be used to pass toeplitz hash values between backend > and VM frontend. > > This patch adds code to xen-netback to pass

Re: [Xen-devel] [PATCH net-next v1 6/8] xen-netback: add an implementation of toeplitz hashing...

On Fri, Feb 12, 2016 at 11:13 AM, Paul Durrant wrote: > ...for receive-side packets. > > My recent patch to include/xen/interface/io/netif.h defines a set of > control messages that can be used by a VM frontend driver to configure > toeplitz hashing of receive-side

[Xen-devel] [qemu-upstream-4.5-testing test] 82431: regressions - FAIL

flight 82431 qemu-upstream-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/82431/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 77858

Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

On 02/04/16 20:24, Stefano Stabellini wrote: > On Thu, 4 Feb 2016, Haozhong Zhang wrote: > > On 02/03/16 15:22, Stefano Stabellini wrote: > > > On Wed, 3 Feb 2016, George Dunlap wrote: > > > > On 03/02/16 12:02, Stefano Stabellini wrote: > > > > > On Wed, 3 Feb 2016, Haozhong Zhang wrote: > > > >

[Xen-devel] [xen-unstable-coverity test] 82477: all pass - PUSHED

flight 82477 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/82477/ Perfect :-) All tests in this flight passed version targeted for testing: xen 483ad4439f7fc71e12d46dae516f2b9ab2b977ad baseline version: xen

[Xen-devel] [linux-linus test] 82419: regressions - trouble: blocked/broken/fail/pass

flight 82419 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/82419/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 59254

[Xen-devel] [PATCH 4/5] drivers/xen: make sys-hypervisor.c explicitly non-modular

The Kconfig currently controlling compilation of this code is: config XEN_SYS_HYPERVISOR bool "Create xen entries under /sys/hypervisor" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading

[Xen-devel] [PATCH 2/5] drivers/xen: make [xen-]ballon explicitly non-modular

The Makefile / Kconfig currently controlling compilation here is: obj-y += grant-table.o features.o balloon.o manage.o preempt.o time.o [...] obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o ...with: drivers/xen/Kconfig:config XEN_BALLOON drivers/xen/Kconfig:bool "Xen memory

[Xen-devel] [PATCH 5/5] drivers/xen: make platform-pci.c explicitly non-modular

The Kconfig currently controlling compilation of this code is: arch/x86/xen/Kconfig:config XEN_PVHVM arch/x86/xen/Kconfig: def_bool y ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the

[Xen-devel] [PATCH 1/5] xen: audit usages of module.h ; remove unnecessary instances

Code that uses no modular facilities whatsoever should not be sourcing module.h at all, since that header drags in a bunch of other headers with it. Similarly, code that is not explicitly using modular facilities like module_init() but only is declaring module_param setup variables should be

[Xen-devel] [PATCH 0/5] xen: avoid module usage in non-modular code

This series of commits is a part of a larger project to ensure people don't reference modular support functions in non-modular code. Overall there was roughly 5k lines of dead code in the kernel due to this. So far we've fixed several areas, like tty, x86, net, ... and we continue to work on

[Xen-devel] [PATCH 3/5] drivers/xen: make xenbus_dev_[front/back]end explicitly non-modular

The Makefile / Kconfig currently controlling compilation here is: obj-y += xenbus_dev_frontend.o [...] obj-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o ...with: drivers/xen/Kconfig:config XEN_BACKEND drivers/xen/Kconfig:bool "Backend driver support" ...meaning that they currently are

[Xen-devel] [qemu-mainline test] 82388: regressions - FAIL

flight 82388 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/82388/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-build fail REGR. vs. 79947 build-amd64-xsm

[Xen-devel] [linux-mingo-tip-master test] 82303: regressions - FAIL

flight 82303 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/82303/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684

[Xen-devel] [linux-4.1 test] 82264: regressions - FAIL

flight 82264 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/82264/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399 build-i386-rumpuserxen

[Xen-devel] [xen-unstable test] 82212: tolerable FAIL - PUSHED

flight 82212 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/82212/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 11 guest-start fail REGR. vs. 81620 build-amd64-rumpuserxen

[Xen-devel] [libvirt test] 82239: regressions - FAIL

flight 82239 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/82239/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-build fail REGR. vs. 80121 Tests which did not

Re: [Xen-devel] [PATCH V3] vm_event: Remove xc_mem_access_enable_emulate() and friends

On Sun, Feb 14, 2016 at 1:38 AM, Razvan Cojocaru wrote: > xc_mem_access_enable_emulate() and xc_mem_access_disable_emulate() > are currently no-ops, that is all they do is set a flag that > nobody else checks. The user can already set the EMULATE flags in > the

[Xen-devel] [qemu-upstream-4.4-testing test] 82234: tolerable FAIL - PUSHED

flight 82234 qemu-upstream-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/82234/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 66772 Tests which did

[Xen-devel] [qemu-upstream-4.6-testing test] 82162: regressions - FAIL

flight 82162 qemu-upstream-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/82162/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-qcow2 6 xen-bootfail REGR. vs. 77722

[Xen-devel] [PATCH V3] vm_event: Remove xc_mem_access_enable_emulate() and friends

xc_mem_access_enable_emulate() and xc_mem_access_disable_emulate() are currently no-ops, that is all they do is set a flag that nobody else checks. The user can already set the EMULATE flags in the vm_event response if emulation is desired, and having an extra check above that is not inherently

Re: [Xen-devel] [PATCH V3] vm_event: Remove xc_mem_access_enable_emulate() and friends

On 02/14/2016 10:38 AM, Razvan Cojocaru wrote: > xc_mem_access_enable_emulate() and xc_mem_access_disable_emulate() > are currently no-ops, that is all they do is set a flag that > nobody else checks. The user can already set the EMULATE flags in > the vm_event response if emulation is desired,

[Xen-devel] Fixation on polarssl 1.1.4 - EOL was 2013-10-01

Hi all, Just been looking at the polarssl parts in Xen 4.6 and others - seems like we're hard coded to version 1.1.4 which was released on 31st May 2012. Branch 1.1.x has been EOL for a number of years, 1.2.x has been EOL since Jan. It's now called mbedtls and current versions are 2.2.1

[Xen-devel] [qemu-upstream-unstable test] 82198: tolerable FAIL - PUSHED

flight 82198 qemu-upstream-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/82198/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 80694