[Xen-devel] [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

Recently a new dm_op[1] hypercall was added to Xen to provide a mechanism for restricting device emulators (such as QEMU) to a limited set of hypervisor operations, and being able to audit those operations in the kernel of the domain in which they run. This patch adds IOCTL_PRIVCMD_DM_OP as

Re: [Xen-devel] [PATCH v2 04/10] xen: credit2: make accessor helpers inline functions instead of macros

On 09/02/17 13:58, Dario Faggioli wrote: > @@ -441,6 +429,40 @@ struct csched2_dom { > }; > > /* > + * Accessor helpers functions. > + */ > +static always_inline The always_inline isn't necessary. For one, the compiler is always going to inline these, and IMO should be reserved for when you

[Xen-devel] [PATCH v2 06/10] 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

Re: [Xen-devel] [PATCH RESEND v17] xen/sndif: Add sound-device ABI

On February 9, 2017 3:46:10 AM EST, Oleksandr Andrushchenko wrote: > > >On 02/08/2017 05:29 PM, Konrad Rzeszutek Wilk wrote: >> . snip.. Reviewed-by: Konrad Rzeszutek Wilk >>> >Couple of issues I found in sndif while preparing displif for review:

[Xen-devel] [PATCH v2 10/10] xen/tools: tracing: always report how long next slice will be.

In fact, it is quite useful a pice of information, to know how long it is the "next time slice" a vCPU has been granted. It allows one to assume (and then check) when the scheduler is supposed to run next, and other things. While this information is indeed reported when a context switch happens,

[Xen-devel] [PATCH v2 09/10] 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

[Xen-devel] [PATCH v2 08/10] 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

[Xen-devel] [PATCH v2 07/10] 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

[Xen-devel] [PATCH v2 03/10] xen: credit2: improve comments' style and definition of CSFLAG-s

Most of the comments describing the meaning of the vCPU flags used by the scheduler miss the 'wings' (or have other minor style issues). Also, use 1U (instead of 1) as the base of shiftings. No functional change intended. Signed-off-by: Dario Faggioli --- Cc: George

[Xen-devel] [PATCH v2 01/10] xen: sched: harmonize debug dump output among schedulers.

Information we currently print for idle pCPUs is rather useless. Credit2 already stopped showing that, do the same for Credit and RTDS. Also, define a new CPU status dump hook, which is not defined by those schedulers which already dump such info in other ways (e.g., Credit2, which does that

[Xen-devel] [PATCH v2 04/10] 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

[Xen-devel] [PATCH v2 00/10] xen: credit2: improve style, and tracing; fix two bugs

Hello, This series contains mostly style or cosmetic fixes for Credit2, with the following two exceptions: - 2 actual fixes for (not so severe) behavioral bugs (patches 5 and 6); - some tracing improvements (last 3 patches). More info on the specific changelogs. This is basically a

[Xen-devel] [PATCH v2 05/10] 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

[Xen-devel] [PATCH v2 02/10] xen: credit2: clear bit instead of skip step in runq_tickle()

Since we are doing cpumask manipulation already, clear a bit in the mask at once. Doing that will save us an if, later in the code. No functional change intended. Signed-off-by: Dario Faggioli --- Cc: George Dunlap --- Changes from v1: *

Re: [Xen-devel] [PATCH v3] xen, input: try to read screen resolution for xen-kbdfront

On 30/01/17 16:10, Juergen Gross wrote: > Instead of using the default resolution of 800*600 for the pointing > device of xen-kbdfront try to read the resolution of the (virtual) > framebuffer device. Use the default as fallback only. > > Signed-off-by: Juergen Gross Ping? >

Re: [Xen-devel] [PATCH] x86/vmx: fix build with clang 3.8.0

On Thu, Feb 09, 2017 at 06:14:54AM -0700, Jan Beulich wrote: > >>> On 09.02.17 at 14:05, wrote: > > On 09/02/17 13:01, Jan Beulich wrote: > > On 09.02.17 at 13:49, wrote: > >>> On 09/02/17 11:33, Roger Pau Monne wrote: > ---

Re: [Xen-devel] [PATCH] xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()

On 02/03/2017 04:38 AM, Juergen Gross wrote: On 30/01/17 18:45, Boris Ostrovsky wrote: rx_refill_timer should be deleted as soon as we disconnect from the backend since otherwise it is possible for the timer to go off before we get to xennet_destroy_queues(). If this happens we may

Re: [Xen-devel] [PATCH] x86/vmx: fix build with clang 3.8.0

On 09/02/17 13:14, Jan Beulich wrote: On 09.02.17 at 14:05, wrote: >> On 09/02/17 13:01, Jan Beulich wrote: >> On 09.02.17 at 13:49, wrote: On 09/02/17 11:33, Roger Pau Monne wrote: > --- a/xen/include/asm-x86/hvm/vmx/vmx.h

[Xen-devel] [PATCH v4 0/3] xen: optimize xenbus performance

The xenbus driver used for communication with Xenstore (all kernel accesses to Xenstore and in case of Xenstore living in another domain all accesses of the local domain to Xenstore) is rather simple especially regarding multiple concurrent accesses: they are just being serialized in spite of

[Xen-devel] [PATCH v4 1/3] xen: clean up xenbus internal headers

The xenbus driver has an awful mixture of internally and globally visible headers: some of the internally used only stuff is defined in the global header include/xen/xenbus.h while some stuff defined in internal headers is used by other drivers, too. Clean this up by moving the externally used

[Xen-devel] [PATCH v4 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses

Handling of multiple concurrent Xenstore accesses through xenbus driver either from the kernel or user land is rather lame today: xenbus is capable to have one access active only at one point of time. Rewrite xenbus to handle multiple requests concurrently by making use of the request id of the

[Xen-devel] [PATCH v4 2/3] xen: modify xenstore watch event interface

Today a Xenstore watch event is delivered via a callback function declared as: void (*callback)(struct xenbus_watch *, const char **vec, unsigned int len); As all watch events only ever come with two parameters (path and token) changing the prototype to: void (*callback)(struct

Re: [Xen-devel] [linux-linus test] 105655: regressions - FAIL

On 02/09/2017 05:44 AM, Dario Faggioli wrote: On Thu, 2017-02-09 at 10:00 +, osstest service owner wrote: flight 105655 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/105655/ Regressions :-( Tests which did not succeed and are blocking, including tests which

Re: [Xen-devel] [PATCH] x86/vmx: fix build with clang 3.8.0

>>> On 09.02.17 at 14:05, wrote: > On 09/02/17 13:01, Jan Beulich wrote: > On 09.02.17 at 13:49, wrote: >>> On 09/02/17 11:33, Roger Pau Monne wrote: --- a/xen/include/asm-x86/hvm/vmx/vmx.h +++

Re: [Xen-devel] [PATCH] x86/vmx: fix build with clang 3.8.0

On 09/02/17 13:01, Jan Beulich wrote: On 09.02.17 at 13:49, wrote: >> On 09/02/17 11:33, Roger Pau Monne wrote: >>> --- a/xen/include/asm-x86/hvm/vmx/vmx.h >>> +++ b/xen/include/asm-x86/hvm/vmx/vmx.h >>> @@ -602,15 +602,16 @@ void vmx_pi_hooks_assign(struct domain

Re: [Xen-devel] [PATCH] x86/vmx: fix build with clang 3.8.0

>>> On 09.02.17 at 13:49, wrote: > On 09/02/17 11:33, Roger Pau Monne wrote: >> --- a/xen/include/asm-x86/hvm/vmx/vmx.h >> +++ b/xen/include/asm-x86/hvm/vmx/vmx.h >> @@ -602,15 +602,16 @@ void vmx_pi_hooks_assign(struct domain *d); >> void vmx_pi_hooks_deassign(struct

Re: [Xen-devel] [PATCH] x86/vmx: fix build with clang 3.8.0

On 09/02/17 11:33, Roger Pau Monne wrote: > The usage of the __transparent__ attribute in 991033fa introduces some issues > when compiled with clang 3.8.0: > > xen/include/asm/hvm/vmx/vmx.h:605:15: error: transparent_union attribute can > only be > applied to a union definition; attribute

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

flight 105666 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/105666/ 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

Re: [Xen-devel] kernel BUG at block/bio.c:1786 -- (xen_blkif_schedule on the stack)

CC Roger and Konrad On Mon, Feb 06, 2017 at 12:31:20AM +0100, Håkon Alstadheim wrote: > I get the BUG below in dom0 when trying to start a windows 10 domu (hvm, > with some pv-drivers installed ) . Below is "xl info", then comes dmesg > output, and finally domu config attached at end. > > This

Re: [Xen-devel] [PATCH v2 02/12] libxl: make some functions global to prepare splitting up libxl.c

On 09/02/17 12:36, Ian Jackson wrote: > Juergen Gross writes ("[PATCH v2 02/12] libxl: make some functions global to > prepare splitting up libxl.c"): >> Splitting up libxl.c will require two functions to be globally visible. >> Add their prototypes to libxl_internal.h. > > Thanks. However, >

Re: [Xen-devel] [PATCH v2 12/12] libxl: make one function static

Juergen Gross writes ("[PATCH v2 12/12] libxl: make one function static"): > libxl__device_frontend_path() is used in libxl_device.c only. Make it > static. Acked-by: Ian Jackson ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH v2 00/12] libxl: split up libxl.c

Juergen Gross writes ("[PATCH v2 00/12] libxl: split up libxl.c"): > libxl: carve out cpupool specific functions from libxl.c > libxl: carve out scheduler specific functions from libxl.c > libxl: carve out disk specific functions from libxl.c > libxl: carve out console specific functions

Re: [Xen-devel] [PATCH v2 03/12] libxl: white space cleanup

Juergen Gross writes ("[PATCH v2 03/12] libxl: white space cleanup"): > Before moving code to new sources clean up some white space issues in > libxl.c. Acked-by: Ian Jackson ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH v2 01/12] libxl: adjust copyright comment of libxl.c

Juergen Gross writes ("[PATCH v2 01/12] libxl: adjust copyright comment of libxl.c"): > The copyright of libxl.c is a little bit outdated. Acked-by: Ian Jackson If you felt like doing a similar thing to the other files that would be nice (but of course not required

Re: [Xen-devel] [PATCH v2 02/12] libxl: make some functions global to prepare splitting up libxl.c

Juergen Gross writes ("[PATCH v2 02/12] libxl: make some functions global to prepare splitting up libxl.c"): > Splitting up libxl.c will require two functions to be globally visible. > Add their prototypes to libxl_internal.h. Thanks. However, > -static void xcinfo2xlinfo(libxl_ctx *ctx, > -

Re: [Xen-devel] [PATCH 2/2] tools/libxl: Introduce LIBXL_CPUPOOL_POOLID_ANY

On 09/02/17 11:24, Wei Liu wrote: > On Thu, Feb 09, 2017 at 11:17:46AM +, George Dunlap wrote: >> On 09/02/17 10:35, Wei Liu wrote: >>> On Wed, Feb 08, 2017 at 04:17:58PM +, George Dunlap wrote: On 08/02/17 16:11, Dario Faggioli wrote: > On Wed, 2017-02-08 at 14:51 +, George

[Xen-devel] [PATCH] x86/vmx: fix build with clang 3.8.0

The usage of the __transparent__ attribute in 991033fa introduces some issues when compiled with clang 3.8.0: xen/include/asm/hvm/vmx/vmx.h:605:15: error: transparent_union attribute can only be applied to a union definition; attribute ignored [-Werror,-Wignored-attributes] typedef union

Re: [Xen-devel] [PATCH 2/2] tools/libxl: Introduce LIBXL_CPUPOOL_POOLID_ANY

On Thu, Feb 09, 2017 at 11:17:46AM +, George Dunlap wrote: > On 09/02/17 10:35, Wei Liu wrote: > > On Wed, Feb 08, 2017 at 04:17:58PM +, George Dunlap wrote: > >> On 08/02/17 16:11, Dario Faggioli wrote: > >>> On Wed, 2017-02-08 at 14:51 +, George Dunlap wrote: > Callers to

Re: [Xen-devel] [PATCH 2/2] tools/libxl: Introduce LIBXL_CPUPOOL_POOLID_ANY

On 09/02/17 10:35, Wei Liu wrote: > On Wed, Feb 08, 2017 at 04:17:58PM +, George Dunlap wrote: >> On 08/02/17 16:11, Dario Faggioli wrote: >>> On Wed, 2017-02-08 at 14:51 +, George Dunlap wrote: Callers to libxl_cpupool_create() can either request a specific pool id, or request

Re: [Xen-devel] [PATCH] xen/mm: Alter is_iomem_page() to use mfn_t

On Thu, 2017-02-09 at 11:54 +0800, Chao Gao wrote: > > Jan is right. When the assertion fails, the value of gfn is 0xfee00. > > Do you mean that is_iomem_page() is equal to direct_mmio except some > corner cases such as APIC access MFN and INVALID_MFN( any others? ) ? That was the hypothesis,

Re: [Xen-devel] [PATCH v6 04/24] x86: refactor psr: implement CPU init and free flow.

On 17-02-08 14:03:15, Konrad Rzeszutek Wilk wrote: > > > +static void cpu_fini_work(unsigned int cpu) > > > +{ > > > +unsigned int socket = cpu_to_socket(cpu); > > > + > > > +if ( !socket_cpumask[socket] || > > > cpumask_empty(socket_cpumask[socket]) ) > > > > I fear I don't understand

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

On Wed, Feb 08, 2017 at 04:15:59PM +0800, Yi Sun wrote: > static void __init parse_psr_bool(char *s, char *value, char *feature, > @@ -479,12 +495,14 @@ static struct psr_socket_info *get_socket_info(unsigned > int socket) > return socket_info + socket; > } > > -int psr_get_info(unsigned

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

On Wed, Feb 08, 2017 at 04:15:55PM +0800, Yi Sun wrote: > diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c > index 96a8589..4656936 100644 > --- a/xen/arch/x86/psr.c > +++ b/xen/arch/x86/psr.c > @@ -17,12 +17,118 @@ > #include > #include > #include > +#include Please move the inclusion

Re: [Xen-devel] [PATCH v6 04/24] x86: refactor psr: implement CPU init and free flow.

On 17-02-08 11:34:16, Konrad Rzeszutek Wilk wrote: > > +/* No valid value so do not enable feature. */ > > +if ( !regs.a || !regs.b ) > > You use regs.d below. Would it make sense to check for that value as > well? > > Or is a value of 0 for cox_max OK? I would think so, but not exactly

Re: [Xen-devel] [PATCH] xen/mm: Alter is_iomem_page() to use mfn_t

On Thu, Feb 09, 2017 at 01:56:14AM -0700, Jan Beulich wrote: On 09.02.17 at 09:27, wrote: >> On Wed, Feb 08, 2017 at 10:05:38AM -0700, Jan Beulich wrote: >> On 08.02.17 at 08:31, wrote: > From: Jan Beulich [mailto:jbeul...@suse.com] >

Re: [Xen-devel] [PATCH] x86/acpi: fix unmapping of low 1MB memory in acpi_os_unmap_memory

>>> On 09.02.17 at 11:37, wrote: > Current code in acpi_os_map_memory uses the direct map in order to map memory > in the low 1MB, but acpi_os_unmap_memory doesn't takes that into account, > and > always tries to perform a vunmap, which results in the following WARN: > >

Re: [Xen-devel] [linux-linus test] 105655: regressions - FAIL

On Thu, 2017-02-09 at 10:00 +, osstest service owner wrote: > flight 105655 linux-linus real [real] > http://logs.test-lab.xenproject.org/osstest/logs/105655/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >  

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

On Thu, Feb 09, 2017 at 08:51:46AM +, Xuquan (Quan Xu) wrote: >On February 08, 2017 4:22 PM, Chao Gao wrote: >>On Wed, Feb 08, 2017 at 10:15:28AM +, Xuquan (Quan Xu) wrote: >>>On February 08, 2017 4:52 PM, Jan Beulich wrote: >>> On 08.02.17 at 09:27, wrote: >

[Xen-devel] [PATCH] x86/acpi: fix unmapping of low 1MB memory in acpi_os_unmap_memory

Current code in acpi_os_map_memory uses the direct map in order to map memory in the low 1MB, but acpi_os_unmap_memory doesn't takes that into account, and always tries to perform a vunmap, which results in the following WARN: (XEN) Xen WARN at vmap.c:185 (XEN) [ Xen-4.9-unstable x86_64

Re: [Xen-devel] [PATCH 1/2] tools/libxc: Introduce XC_CPUPOOL_POOLID_ANY

On Wed, Feb 08, 2017 at 02:51:45PM +, George Dunlap wrote: > Callers to xc_cpupool_create() can either request a specific pool id, > or request that Xen do it for them. But at the moment, the > "automatic" selection is indicated by using a magic value, 0. This is > undesirable both because

Re: [Xen-devel] [PATCH 2/2] tools/libxl: Introduce LIBXL_CPUPOOL_POOLID_ANY

On Wed, Feb 08, 2017 at 04:17:58PM +, George Dunlap wrote: > On 08/02/17 16:11, Dario Faggioli wrote: > > On Wed, 2017-02-08 at 14:51 +, George Dunlap wrote: > >> Callers to libxl_cpupool_create() can either request a specific pool > >> id, or request that Xen do it for them. But at the

Re: [Xen-devel] [PATCH 2/5] xen: credit2: never consider CPUs outside of our cpupool.

On Thu, 2017-02-09 at 02:17 -0700, Jan Beulich wrote: > > > > On 08.02.17 at 19:55, wrote: > I'm going to commit what I have later today, and > I'll pull in the one extra backport next time round. > Ok, patch attached. I've tested it on top of current tip of

Re: [Xen-devel] [PATCH v6] x86/hvm: add vcpu parameter to guest memory copy function

On Thu, Feb 09, 2017 at 03:10:10AM -0700, Jan Beulich wrote: > >>> On 07.02.17 at 18:35, wrote: > > @@ -3178,9 +3179,9 @@ static enum hvm_copy_result __hvm_copy( > > { > > static unsigned long lastpage; > > if ( xchg(, gfn) !=

Re: [Xen-devel] 4.7.2 / 4.6.5 preparations

On 09/02/17 09:52, Jan Beulich wrote: > All, > > these stable releases are due in about 3 weeks time. Please indicate > backports you consider necessary but find still missing. Commits > already marked for backporting: > > e719192026 xen: credit2: never consider CPUs outside of our cpupool. > (for

Re: [Xen-devel] [PATCH v2 00/12] libxl: split up libxl.c

On Thu, Feb 09, 2017 at 10:30:13AM +0100, Juergen Gross wrote: > libxl.c has become rather large. Split it up into multiple files. > > Changes are: > - modification of Copyright comment (patch 1) > - made two functions non-static: libxl__get_memory_target(), > xcinfo2xlinfo() (patch 2) > -

Re: [Xen-devel] [PATCH v2 01/12] libxl: adjust copyright comment of libxl.c

On Thu, Feb 09, 2017 at 10:30:14AM +0100, Juergen Gross wrote: > The copyright of libxl.c is a little bit outdated. > > Adjust it to reality. > > Signed-off-by: Juergen Gross Reviewed-by: Wei Liu ___ Xen-devel

Re: [Xen-devel] [RFC XEN PATCH 15/16] tools/libxl: handle return code of libxl__qmp_initializations()

Hmm... not sure why my reply didn't have you in the To: field. On Thu, Feb 09, 2017 at 10:13:13AM +, Wei Liu wrote: > On Thu, Feb 09, 2017 at 10:47:01AM +0800, Haozhong Zhang wrote: > > On 02/08/17 10:31 +, Wei Liu wrote: > > > On Wed, Feb 08, 2017 at 02:07:26PM +0800, Haozhong Zhang

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

flight 105660 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/105660/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-buildfail REGR. vs. 105279 build-amd64

Re: [Xen-devel] [RFC XEN PATCH 15/16] tools/libxl: handle return code of libxl__qmp_initializations()

On Thu, Feb 09, 2017 at 10:47:01AM +0800, Haozhong Zhang wrote: > On 02/08/17 10:31 +, Wei Liu wrote: > > On Wed, Feb 08, 2017 at 02:07:26PM +0800, Haozhong Zhang wrote: > > > On 01/27/17 17:11 -0500, Konrad Rzeszutek Wilk wrote: > > > > On Mon, Oct 10, 2016 at 08:32:34AM +0800, Haozhong Zhang

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

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

Re: [Xen-devel] [PATCH v6] x86/hvm: add vcpu parameter to guest memory copy function

>>> On 07.02.17 at 18:35, wrote: > @@ -3178,9 +3179,9 @@ static enum hvm_copy_result __hvm_copy( > { > static unsigned long lastpage; > if ( xchg(, gfn) != gfn ) > -gdprintk(XENLOG_DEBUG, "guest attempted

[Xen-devel] [linux-linus test] 105655: regressions - FAIL

flight 105655 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/105655/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 14 guest-saverestore fail REGR. vs. 59254

Re: [Xen-devel] 4.7.2 / 4.6.5 preparations

On Thu, Feb 09, 2017 at 02:52:49AM -0700, Jan Beulich wrote: > All, > > these stable releases are due in about 3 weeks time. Please indicate > backports you consider necessary but find still missing. Commits > already marked for backporting: > > e719192026 xen: credit2: never consider CPUs

[Xen-devel] 4.7.2 / 4.6.5 preparations

All, these stable releases are due in about 3 weeks time. Please indicate backports you consider necessary but find still missing. Commits already marked for backporting: e719192026 xen: credit2: never consider CPUs outside of our cpupool. (for 4.7.5 only, unless anyone cares to also provide 4.6

[Xen-devel] [distros-debian-wheezy test] 68541: tolerable trouble: broken/pass

flight 68541 distros-debian-wheezy real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68541/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: build-arm64 2 hosts-allocate broken never pass build-arm64-pvops

Re: [Xen-devel] [PATCH 0/9] libxl: spolit up libxl.c

On Thu, Feb 09, 2017 at 09:51:48AM +0800, Zhang Chen wrote: > > > On 02/09/2017 12:54 AM, Wei Liu wrote: > > And CC Zhangchen > > Thanks, I will apply this patch set before test my patch. > This is not yet the final form. Please need to wait until this work gets applied. Wei.

[Xen-devel] [PATCH v2 08/12] libxl: carve out memory specific functions from libxl.c

libxl.c has grown to an uncomfortable size. Carve out the memory related functions to libxl_mem.c. Signed-off-by: Juergen Gross --- tools/libxl/Makefile| 2 +- tools/libxl/libxl.c | 577 -- tools/libxl/libxl_mem.c | 601

[Xen-devel] [PATCH v2 07/12] libxl: carve out console specific functions from libxl.c

libxl.c has grown to an uncomfortable size. Carve out the console related functions (including channels, keyboard and frame buffer) to libxl_console.c. Signed-off-by: Juergen Gross --- tools/libxl/Makefile| 2 +- tools/libxl/libxl.c | 846

[Xen-devel] [PATCH v2 06/12] libxl: carve out disk specific functions from libxl.c

libxl.c has grown to an uncomfortable size. Carve out the disk related functions to libxl_disk.c. Signed-off-by: Juergen Gross --- tools/libxl/Makefile |2 +- tools/libxl/libxl.c | 1233 - tools/libxl/libxl_disk.c | 1258

[Xen-devel] [PATCH v2 00/12] libxl: split up libxl.c

libxl.c has become rather large. Split it up into multiple files. Changes are: - modification of Copyright comment (patch 1) - made two functions non-static: libxl__get_memory_target(), xcinfo2xlinfo() (patch 2) - white space cleanup of libxl.c (patch 3) - moving functions into new or existing

[Xen-devel] [PATCH v2 10/12] libxl: carve out tmem specific functions from libxl.c

libxl.c has grown to an uncomfortable size. Carve out the tmem related functions to libxl_tmem.c. Signed-off-by: Juergen Gross --- tools/libxl/Makefile | 2 +- tools/libxl/libxl.c | 142 tools/libxl/libxl_tmem.c | 167

[Xen-devel] [PATCH v2 04/12] libxl: carve out cpupool specific functions from libxl.c

libxl.c has grown to an uncomfortable size. Carve out the cpupool related functions to libxl_cpupool.c. Signed-off-by: Juergen Gross --- tools/libxl/Makefile| 1 + tools/libxl/libxl.c | 418 - tools/libxl/libxl_cpupool.c

[Xen-devel] [PATCH v2 02/12] libxl: make some functions global to prepare splitting up libxl.c

Splitting up libxl.c will require two functions to be globally visible. Add their prototypes to libxl_internal.h. Signed-off-by: Juergen Gross --- tools/libxl/libxl.c | 12 ++-- tools/libxl/libxl_internal.h | 7 +++ 2 files changed, 13 insertions(+), 6

[Xen-devel] [PATCH v2 01/12] libxl: adjust copyright comment of libxl.c

The copyright of libxl.c is a little bit outdated. Adjust it to reality. Signed-off-by: Juergen Gross --- tools/libxl/libxl.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index d400fa2..0641a8a 100644 ---

[Xen-devel] [PATCH v2 03/12] libxl: white space cleanup

Before moving code to new sources clean up some white space issues in libxl.c. Signed-off-by: Juergen Gross --- tools/libxl/libxl.c | 23 ++- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index

[Xen-devel] [PATCH v2 05/12] libxl: carve out scheduler specific functions from libxl.c

libxl.c has grown to an uncomfortable size. Carve out the scheduler related functions to libxl_sched.c. Signed-off-by: Juergen Gross --- tools/libxl/Makefile | 2 +- tools/libxl/libxl.c | 891 tools/libxl/libxl_sched.c |

[Xen-devel] [PATCH v2 09/12] libxl: move device specific functions out of libxl.c

Move the few generic device specific functions left in libxl.c to libxl_device.c. Signed-off-by: Juergen Gross --- tools/libxl/libxl.c| 416 - tools/libxl/libxl_device.c | 414 2

[Xen-devel] [PATCH v2 11/12] libxl: carve out domain specific functions from libxl.c

libxl.c has grown to an uncomfortable size. Carve out the domain related functions to libxl_domain.c. Signed-off-by: Juergen Gross --- tools/libxl/Makefile |1 + tools/libxl/libxl.c| 1722 --- tools/libxl/libxl_domain.c

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

On Thu, Feb 09, 2017 at 10:12:41AM +0100, Edgar E. Iglesias wrote: > On Wed, Feb 08, 2017 at 05:20:44PM -0800, Stefano Stabellini wrote: > > On Thu, 9 Feb 2017, Julien Grall wrote: > > > On 08/02/2017 23:28, Tamas K Lengyel wrote: > > > > On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall

Re: [Xen-devel] [PATCH 2/5] xen: credit2: never consider CPUs outside of our cpupool.

On Thu, 2017-02-09 at 02:17 -0700, Jan Beulich wrote: > > > > On 08.02.17 at 19:55, wrote: > > I've only quickly tested it so far, and I have to leave now. I'll > > play > > with it a bit more tomorrow morning and let you know how it goes. > > Well, looking at the

Re: [Xen-devel] [PATCH 2/5] xen: credit2: never consider CPUs outside of our cpupool.

>>> On 08.02.17 at 19:55, wrote: > As per 4.7, I've prepared a branch for you: Thanks. > git://xenbits.xen.org/people/dariof/xen.git > for-jan/staging-4.7/credit2-cpupool-fixes > > http://xenbits.xen.org/gitweb/?p=people/dariof/xen.git;a=shortlog;h=refs/head >

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

On Wed, Feb 08, 2017 at 05:20:44PM -0800, Stefano Stabellini wrote: > On Thu, 9 Feb 2017, Julien Grall wrote: > > On 08/02/2017 23:28, Tamas K Lengyel wrote: > > > On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall wrote: > > > > Hi Tamas, > > > > > > > > Can you please try to

Re: [Xen-devel] [PATCH] xen/mm: Alter is_iomem_page() to use mfn_t

On Thu, 2017-02-09 at 01:56 -0700, Jan Beulich wrote: > > > diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c > > index 86c71be..3d9386a 100644 > > --- a/xen/arch/x86/hvm/mtrr.c > > +++ b/xen/arch/x86/hvm/mtrr.c > > @@ -784,6 +784,8 @@ int epte_get_entry_emt(struct domain *d,

Re: [Xen-devel] [PATCH] xen/mm: Alter is_iomem_page() to use mfn_t

>>> On 09.02.17 at 09:27, wrote: > On Wed, Feb 08, 2017 at 10:05:38AM -0700, Jan Beulich wrote: > On 08.02.17 at 08:31, wrote: From: Jan Beulich [mailto:jbeul...@suse.com] Sent: Monday, February 06, 2017 11:38 PM >>> On 06.02.17

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

On February 08, 2017 4:22 PM, Chao Gao wrote: >On Wed, Feb 08, 2017 at 10:15:28AM +, Xuquan (Quan Xu) wrote: >>On February 08, 2017 4:52 PM, Jan Beulich wrote: >> On 08.02.17 at 09:27, wrote: Assumed vCPU is in guest_mode.. When apicv is enabled, hypervisor

Re: [Xen-devel] [PATCH RESEND v17] xen/sndif: Add sound-device ABI

On 02/08/2017 05:29 PM, Konrad Rzeszutek Wilk wrote: . snip.. Reviewed-by: Konrad Rzeszutek Wilk Couple of issues I found in sndif while preparing displif for review: 1. missing string constants +#define XENSND_FIELD_BE_VERSIONS"versions" +#define

Re: [Xen-devel] [PATCH] xen/mm: Alter is_iomem_page() to use mfn_t

On Wed, Feb 08, 2017 at 10:05:38AM -0700, Jan Beulich wrote: On 08.02.17 at 08:31, wrote: >>> From: Jan Beulich [mailto:jbeul...@suse.com] >>> Sent: Monday, February 06, 2017 11:38 PM >>> >>> >>> On 06.02.17 at 15:48, wrote: >>> > On Mon,

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

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

<    1   2