Re: [Xen-devel] [PATCH net-next 0/7] xen-netback: guest rx side refactor

From: Paul Durrant Date: Mon, 3 Oct 2016 08:31:05 +0100 > This series refactors the guest rx side of xen-netback: > > - The code is moved into its own source module. > > - The prefix variant of GSO handling is retired (since it is no longer > in common use, and

[Xen-devel] [ovmf test] 101249: all pass - PUSHED

flight 101249 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/101249/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf c0b7e2b2bfc2748112607bfe83fc99cf48c97b48 baseline version: ovmf

[Xen-devel] [ovmf baseline-only test] 67791: regressions - FAIL

This run is configured for baseline tests only. flight 67791 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67791/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 15

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

flight 101247 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/101247/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-arndale 3 host-install(3) broken in 101246 pass in 101247 test-armhf-armhf-xl-credit2 16

[Xen-devel] [xen-unstable baseline-only test] 67790: regressions - FAIL

This run is configured for baseline tests only. flight 67790 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67790/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-qcow2 9

[Xen-devel] [ovmf test] 101248: all pass - PUSHED

flight 101248 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/101248/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 8550b5f0810f306850f9a07ee551099155d89ae0 baseline version: ovmf

[Xen-devel] [PATCH RFC] x86/Intel: virtualize support for cpuid faulting

rr (http://rr-project.org/), a Linux userspace record-and-replay reverse- execution debugger, would like to trap and emulate the CPUID instruction. This would allow us to a) mask away certain hardware features that rr does not support (e.g. RDRAND) and b) enable trace portability across machines

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

flight 101246 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/101246/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 3 host-install(3)broken REGR. vs.

[Xen-devel] [xen-unstable baseline-only test] 67784: regressions - FAIL

This run is configured for baseline tests only. flight 67784 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67784/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 6

Re: [Xen-devel] [PATCH v3 4/4] Addressed comments on quorum and security team members

Lars Kurth writes ("[PATCH v3 4/4] Addressed comments on quorum and security team members"): > Main changes > Leadership team decisions: express quorum in terms of +1 votes > Security Team Members: election > Project Wide Decision Making: minor text changes The resulting series is a little odd

Re: [Xen-devel] [PATCH v2 12/30] xen/x86: make print_e820_memory_map global

On Fri, Sep 30, 2016 at 09:04:24AM -0600, Jan Beulich wrote: > >>> On 27.09.16 at 17:57, wrote: > > So that it can be called from the Dom0 builder. > > Why would the Dom0 builder need to call it, when it doesn't so far? IMHO, I find it useful to print the domain 0 memory

Re: [Xen-devel] Livepatch for Xen 4.9

On 03/10/16 15:16, Konrad Rzeszutek Wilk wrote: > Hey! > > [CC-ing xen-devel] > > Xen 4.8-rc1 is out and means taking a break from some of the Livepatch > hypervisor > parts for me. > > My plan for 4.8 is to concentrate on any livepatch fallout and doing OSSTest > along > with Marcos (CC-ed) and

Re: [Xen-devel] [PATCH RFC] xen: make it possible to disable XEN_TMEM

Konrad Rzeszutek Wilk writes: > On Mon, Oct 03, 2016 at 04:02:48PM +0200, Vitaly Kuznetsov wrote: >> XEN_TMEM config option has no prompt and it is enabled as module by >> default if CLEANCACHE or FRONTSWAP options are set with no way to disable >> it. The only in-tree

[Xen-devel] [PATCH] libxl: fix issues in 38cd0664

A few issues were introduced in 38cd0664 ("libxl/arm: Add the size of ACPI tables to maxmem"): 1. d_config was not properly initialised and disposed of. 2. using libxl_retrieve_domain_configuration caused thread to deadlock itself. Fix those issues by: 1. properly initialise and dispose of

Re: [Xen-devel] Livepatch for Xen 4.9

>>> Konrad Rzeszutek Wilk 10/03/16 4:18 PM >>> >2) We could also do some form of restartable patching. That is seed the code >(where we are going to >put a trampoline) with 'CC'. Then do memcpy over the the 'CC' the new >instructions (jump). If the >NMI/MCE handler hits

Re: [Xen-devel] [PATCH RFC] xen: make it possible to disable XEN_TMEM

On Mon, Oct 03, 2016 at 04:02:48PM +0200, Vitaly Kuznetsov wrote: > XEN_TMEM config option has no prompt and it is enabled as module by > default if CLEANCACHE or FRONTSWAP options are set with no way to disable > it. The only in-tree user of the tmem interface is xen-selfballoon which And if

[Xen-devel] Livepatch for Xen 4.9

Hey! [CC-ing xen-devel] Xen 4.8-rc1 is out and means taking a break from some of the Livepatch hypervisor parts for me. My plan for 4.8 is to concentrate on any livepatch fallout and doing OSSTest along with Marcos (CC-ed) and see if we can wrestle it to expand on what we want to have done.

[Xen-devel] [PATCH RFC] xen: make it possible to disable XEN_TMEM

XEN_TMEM config option has no prompt and it is enabled as module by default if CLEANCACHE or FRONTSWAP options are set with no way to disable it. The only in-tree user of the tmem interface is xen-selfballoon which can itself be disabled so it makes sense to make it possible to disable XEN_TMEM

[Xen-devel] [xen-unstable-smoke test] 101245: tolerable all pass - PUSHED

flight 101245 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/101245/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl

[Xen-devel] [ANNOUNCEMENT] Xen 4.8 RC1

Hi all Xen 4.8 RC1 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.8.0-rc1 For you convenience there is also tarball at: http://bits.xensource.com/oss-xen/release/4.8.0-rc1/xen-4.8.0-rc1.tar.gz And the signature is at:

Re: [Xen-devel] [PATCH] Xen 4.8.0-rc1 preparation

On Mon, Oct 03, 2016 at 11:59:49AM +0100, Ian Jackson wrote: > * Change QEMU_UPSTREAM_REVISION MINIOS_UPSTREAM_REVISION and > QEMU_TRADITIONAL_REVISION to refer to the Xen 4.8.0-rc1 tags. > > * Change README and xen/Makefile to refer to Xen 4.8.0-rc (note, the > RC number is not included, so

Re: [Xen-devel] [PATCH v2 30/30] xen: allow setting the store pfn HVM parameter

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of > Roger Pau Monne > Sent: 27 September 2016 16:57 > To: xen-de...@lists.xenproject.org > Cc: Andrew Cooper ; > boris.ostrov...@oracle.com; Roger Pau Monne

[Xen-devel] [PATCH] Xen 4.8.0-rc1 preparation

* Change QEMU_UPSTREAM_REVISION MINIOS_UPSTREAM_REVISION and QEMU_TRADITIONAL_REVISION to refer to the Xen 4.8.0-rc1 tags. * Change README and xen/Makefile to refer to Xen 4.8.0-rc (note, the RC number is not included, so we do not have to update these again). I reran autogen.sh as per the

Re: [Xen-devel] [PATCH v2 28/30] xen/x86: add MSI-X emulation to PVHv2 Dom0

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of > Roger Pau Monne > Sent: 27 September 2016 16:57 > To: xen-de...@lists.xenproject.org > Cc: boris.ostrov...@oracle.com; Roger Pau Monne > Subject: [Xen-devel] [PATCH v2

Re: [Xen-devel] [PATCH v2 26/30] xen/x86: add PCIe emulation

> -Original Message- > From: Roger Pau Monne [mailto:roger@citrix.com] > Sent: 27 September 2016 16:57 > To: xen-de...@lists.xenproject.org > Cc: konrad.w...@oracle.com; boris.ostrov...@oracle.com; Roger Pau Monne > ; Paul Durrant ; Jan >

Re: [Xen-devel] [PATCH v2 22/30] xen/x86: support PVHv2 Dom0 BAR remapping

> -Original Message- > From: Roger Pau Monne [mailto:roger@citrix.com] > Sent: 27 September 2016 16:57 > To: xen-de...@lists.xenproject.org > Cc: konrad.w...@oracle.com; boris.ostrov...@oracle.com; Roger Pau Monne > ; Paul Durrant ; Jan >

Re: [Xen-devel] [PATCH v2 11/30] xen/x86: split Dom0 build into PV and PVHv2

On Fri, Sep 30, 2016 at 09:03:34AM -0600, Jan Beulich wrote: > >>> On 27.09.16 at 17:57, wrote: > > --- a/docs/misc/xen-command-line.markdown > > +++ b/docs/misc/xen-command-line.markdown > > @@ -663,6 +663,13 @@ Pin dom0 vcpus to their respective pcpus > > > > Flag that

[Xen-devel] [distros-debian-sid test] 67789: regressions - FAIL

flight 67789 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67789/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 5 kernel-build fail REGR. vs. 67762

Re: [Xen-devel] [PATCH v2 20/30] xen/x86: add the basic infrastructure to import QEMU passthrough code

> -Original Message- > From: Roger Pau Monne [mailto:roger@citrix.com] > Sent: 27 September 2016 16:57 > To: xen-de...@lists.xenproject.org > Cc: konrad.w...@oracle.com; boris.ostrov...@oracle.com; Roger Pau Monne > ; Jan Beulich ; Andrew Cooper

Re: [Xen-devel] [PATCH v2 19/30] xen/dcpi: add a dpci passthrough handler for hardware domain

> -Original Message- > From: Roger Pau Monne [mailto:roger@citrix.com] > Sent: 27 September 2016 16:57 > To: xen-de...@lists.xenproject.org > Cc: konrad.w...@oracle.com; boris.ostrov...@oracle.com; Roger Pau Monne > ; Paul Durrant ; Jan >

[Xen-devel] [xen-unstable test] 101244: tolerable FAIL

flight 101244 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/101244/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail in 101242 pass in 101244

Re: [Xen-devel] [PATCH] xen/x86: Initialize per_cpu(xen_vcpu, 0) a little earlier

On 2016-10-03 00:45, Boris Ostrovsky wrote: xen_cpuhp_setup() calls mutex_lock() which, when CONFIG_DEBUG_MUTEXES is defined, ends up calling xen_save_fl(). That routine expects per_cpu(xen_vcpu, 0) to be already initialized. Signed-off-by: Boris Ostrovsky

Re: [Xen-devel] [PATCH v2 13/30] xen: introduce a new format specifier to print sizes in human-readable form

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of > Roger Pau Monne > Sent: 27 September 2016 16:57 > To: xen-de...@lists.xenproject.org > Cc: Stefano Stabellini ; Wei Liu > ; George Dunlap

Re: [Xen-devel] [PATCH v2 03/30] xen/x86: fix parameters and return value of *_set_allocation functions

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of > Roger Pau Monne > Sent: 27 September 2016 16:57 > To: xen-de...@lists.xenproject.org > Cc: George Dunlap ; Andrew Cooper > ; Tim (Xen.org)

[Xen-devel] [PATCH net-next 6/7] xen-netback: batch copies for multiple to-guest rx packets

From: David Vrabel Instead of flushing the copy ops when an packet is complete, complete packets when their copy ops are done. This improves performance by reducing the number of grant copy hypercalls. Latency is still limited by the relatively small size of the copy

[Xen-devel] [PATCH net-next 7/7] xen/netback: add fraglist support for to-guest rx

From: Ross Lagerwall This allows full 64K skbuffs (with 1500 mtu ethernet, composed of 45 fragments) to be handled by netback for to-guest rx. Signed-off-by: Ross Lagerwall [re-based] Signed-off-by: Paul Durrant

[Xen-devel] [PATCH net-next 2/7] xen-netback: retire guest rx side prefix GSO feature

As far as I am aware only very old Windows network frontends make use of this style of passing GSO packets from backend to frontend. These frontends can easily be replaced by the freely available Xen Project Windows PV network frontend, which uses the 'default' mechanism for passing GSO packets,

[Xen-devel] [PATCH net-next 5/7] xen-netback: process guest rx packets in batches

From: David Vrabel Instead of only placing one skb on the guest rx ring at a time, process a batch of up-to 64. This improves performance by ~10% in some tests. Signed-off-by: David Vrabel [re-based] Signed-off-by: Paul Durrant

[Xen-devel] [PATCH net-next 4/7] xen-netback: immediately wake tx queue when guest rx queue has space

From: David Vrabel When an skb is removed from the guest rx queue, immediately wake the tx queue, instead of after processing them. Signed-off-by: David Vrabel [re-based] Signed-off-by: Paul Durrant --- Cc: Wei Liu

[Xen-devel] [PATCH net-next 0/7] xen-netback: guest rx side refactor

This series refactors the guest rx side of xen-netback: - The code is moved into its own source module. - The prefix variant of GSO handling is retired (since it is no longer in common use, and alternatives exist). - The code is then simplified and modifications made to improve performance.

[Xen-devel] [PATCH net-next 1/7] xen-netback: separate guest side rx code into separate module

The netback source module has become very large and somewhat confusing. This patch simply moves all code related to the backend to frontend (i.e guest side rx) data-path into a separate rx source module. This patch contains no functional change, it is code movement and minimal changes to avoid

[Xen-devel] [PATCH net-next 3/7] xen-netback: refactor guest rx

From: David Vrabel Refactor the to-guest (rx) path to: 1. Push responses for completed skbs earlier, reducing latency. 2. Reduce the per-queue memory overhead by greatly reducing the maximum number of grant copy ops in each hypercall (from 4352 to 64). Each