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

flight 97375 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/97375/ 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. 94748

[Xen-devel] [linux-4.1 bisection] complete test-amd64-i386-xl-qemut-debianhvm-amd64

branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemut-debianhvm-amd64 testid debian-hvm-install Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu

[Xen-devel] [xen-unstable test] 97355: regressions - FAIL

flight 97355 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/97355/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-pair 15 debian-install/dst_host fail REGR. vs. 97275

Re: [Xen-devel] [PATCH 2/3] Update to use a .config file

> > OK, I'll split it into two. Feel free to create a stable-47 branch in > > livepatch-build-tools.git with only the .config patch. Personally, I'd > > rather not spend much time backporting stuff to support a tech preview > > feature on an older branch. > > We will need to update the Wiki a bit

[Xen-devel] [PATCH v3] libxl: trigger attach events for devices attached before xl devd startup

When this daemon is started after creating backend device, that device will not be configured. Racy situation: 1. driver domain is started 2. frontend domain is started (just after kicking driver domain off) 3. device in frontend domain is connected to the backend (as specified in frontend

[Xen-devel] [PATCH v2 05/19] block: Convert BB interface to byte-based discards

Change sector-based blk_discard(), blk_co_discard(), and blk_aio_discard() to instead be byte-based blk_pdiscard(), blk_co_pdiscard(), and blk_aio_pdiscard(). NBD gets a lot simpler now that ignoring the unaligned portion of a byte-based discard request is handled under the hood by the block

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

flight 97338 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/97338/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-xsm 11 guest-start fail REGR. vs. 96791

[Xen-devel] [linux-4.1 test] 97334: regressions - trouble: blocked/broken/fail/pass

flight 97334 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/97334/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 96211

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

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

Re: [Xen-devel] [PATCH RFC] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1

On 07/15/2016 01:48 PM, Lars Kurth wrote: > > On 15/07/2016 18:43, "Ian Jackson" wrote: > > >> This should be >> >> Respectfully, >> >> Lars Kurth (Xen Project Community Manager) >> Boris Ostrovsky (Oracle) >> Ian Jackson (Citrix) >> >> and anyone else you can get

Re: [Xen-devel] [PATCH RESEND 2/4] xen: Add generic implementation of binary search

Hi Andrew, On 07/15/2016 12:42 PM, Andrew Cooper wrote: On 15/07/16 18:35, Shanker Donthineni wrote: This patch adds the generic implementation of binary search algorithm whcih is copied from Linux kernel v4.7-rc7. No functional changes. Signed-off-by: Shanker Donthineni

Re: [Xen-devel] [PATCH RFC] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1

Boris Ostrovsky writes ("Re: [PATCH RFC] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1"): > On 07/15/2016 01:43 PM, Ian Jackson wrote: > > Boris Ostrovsky writes ("[PATCH RFC] acpi: Re-license ACPI builder files > > from GPLv2 to LGPLv2.1"): > > > >> I added the notice to mk_dsdt.c

Re: [Xen-devel] [PATCH 3/3] xen: Remove buggy initial placement algorithm

On 15/07/16 19:02, George Dunlap wrote: > The initial placement algorithm sometimes picks cpus outside of the > mask it's given, does a lot of unnecessary bitmasking, does its own > separate load calculation, and completely ignores vcpu hard and soft > affinities. Just get rid of it and rely on

Re: [Xen-devel] [PATCH 2/3] xen: Have schedulers revise initial placement

On 15/07/16 19:02, George Dunlap wrote: > diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c > index 3b9aa27..5a04985 100644 > --- a/xen/common/sched_credit2.c > +++ b/xen/common/sched_credit2.c > @@ -1620,15 +1620,23 @@ csched2_vcpu_insert(const struct scheduler *ops, > struct

[Xen-devel] [PATCH 2/3] xen: Have schedulers revise initial placement

The generic domain creation logic in xen/common/domctl.c:default_vcpu0_location() attempts to try to do initial placement load-balancing by placing vcpu 0 on the least-busy non-primary hyperthread available. Unfortunately, the logic can end up picking a pcpu that's not in the online mask. When

[Xen-devel] [PATCH 1/3] xen: Some code motion to avoid having to do forward-declaration

For sched_credit2, move the vcpu insert / remove / free functions near the domain insert / remove / alloc / free functions (and after cpu_pick). For sched_rt, move rt_cpu_pick() further up. This is pure code motion; no functional change. Signed-off-by: George Dunlap

[Xen-devel] [PATCH 3/3] xen: Remove buggy initial placement algorithm

The initial placement algorithm sometimes picks cpus outside of the mask it's given, does a lot of unnecessary bitmasking, does its own separate load calculation, and completely ignores vcpu hard and soft affinities. Just get rid of it and rely on the schedulers to do initial placement.

Re: [Xen-devel] [PATCH RFC] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1

On 07/15/2016 01:43 PM, Ian Jackson wrote: > Boris Ostrovsky writes ("[PATCH RFC] acpi: Re-license ACPI builder files from > GPLv2 to LGPLv2.1"): > >> I added the notice to mk_dsdt.c which didn't have any. The notice >> may not be required since mk_dsdt is Xen build tool and is >> not shipped but

Re: [Xen-devel] [PATCH RFC] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1

On 15/07/2016 18:43, "Ian Jackson" wrote: >Boris Ostrovsky writes ("[PATCH RFC] acpi: Re-license ACPI builder files >from GPLv2 to LGPLv2.1"): >> ACPI builder is currently distributed under GPLv2 license. >> >> We plan to make the builder available to components

Re: [Xen-devel] [PATCH RFC] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1

Boris Ostrovsky writes ("[PATCH RFC] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1"): > ACPI builder is currently distributed under GPLv2 license. > > We plan to make the builder available to components other > than the hvmloader (which is also GPLv2). Some of these > components

Re: [Xen-devel] [PATCH RESEND 2/4] xen: Add generic implementation of binary search

On 15/07/16 18:35, Shanker Donthineni wrote: > This patch adds the generic implementation of binary search algorithm > whcih is copied from Linux kernel v4.7-rc7. No functional changes. > > Signed-off-by: Shanker Donthineni > --- > Resend to fix the

[Xen-devel] [PATCH RESEND 3/4] xen/arm: io: Use binary search for mmio handler lookup

As the number of I/O handlers increase, the overhead associated with linear lookup also increases. The system might have maximum of 144 (assuming CONFIG_NR_CPUS=128) mmio handlers. In worst case scenario, it would require 144 iterations for finding a matching handler. Now it is time for us to

[Xen-devel] [PATCH RESEND 1/4] arm/io: Use separate memory allocation for mmio handlers

The number of mmio handlers are limited to a compile time macro MAX_IO_HANDLER which is 16. This number is not at all sufficient to support per CPU distributor regions. Either it needs to be increased to a bigger number, at least CONFIG_NR_CPUS+16, or allocate a separate memory for mmio handlers

[Xen-devel] [PATCH RESEND 4/4] arm/vgic: Change fixed number of mmio handlers to variable number

Compute the number of mmio handlers that are required for vGICv3 and vGICv2 emulation drivers in vgic_v3_init()/vgic_v2_init(). Augment this variable number of mmio handers to a fixed number MAX_IO_HANDLER and pass it to domain_io_init() to allocate enough memory. New code path:

[Xen-devel] [PATCH RESEND 2/4] xen: Add generic implementation of binary search

This patch adds the generic implementation of binary search algorithm whcih is copied from Linux kernel v4.7-rc7. No functional changes. Signed-off-by: Shanker Donthineni --- Resend to fix the In-Reply-To/References header feilds. xen/common/Makefile | 1 +

[Xen-devel] [PATCH RESEND 0/4] Change fixed mmio handlers to a variable number

The maximum number of mmio handlers that are allowed is limited to a macro MAX_IO_HANDLER(16), which is not enough for supporting per CPU Redistributor regions. We need at least MAX_IO_HANDLER+CONFIG_NR_CPUS mmio handlers in order to support ACPI based XEN boot. This patchset uses the dynamic

[Xen-devel] [PATCH RFC] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1

ACPI builder is currently distributed under GPLv2 license. We plan to make the builder available to components other than the hvmloader (which is also GPLv2). Some of these components (such as libxl) may distributed under non-GPLv2 licenses and thus we may not be able to link the builder against

Re: [Xen-devel] [PATCH v3 2/2] qdisk - hw/block/xen_disk: grant copy implementation

On Fri, Jul 15, 2016 at 12:15:45PM +0100, Wei Liu wrote: > On Fri, Jul 15, 2016 at 12:28:48PM +0200, Paulina Szubarczyk wrote: > > > > > > On 07/14/2016 12:37 PM, Wei Liu wrote: > > >On Wed, Jun 22, 2016 at 10:38:53AM +0200, Paulina Szubarczyk wrote: > > >>diff --git a/configure b/configure > >

[Xen-devel] [PATCH] xen/domctl: Add DOMINFO_hap to xen_domctl_getdomaininfo

This allows a toolstack to identify whether a running domain is using hardware assisted paging or not. The appropriate tests differ by architecture, so introduce arch_get_domain_info(). ARM unconditionally sets the new flag, while x86 checks with the paging subsystem first. Signed-off-by:

Re: [Xen-devel] [PATCH v3 2/2] qdisk - hw/block/xen_disk: grant copy implementation

On Wed, Jun 22, 2016 at 10:38:53AM +0200, Paulina Szubarczyk wrote: > Copy data operated on during request from/to local buffers to/from > the grant references. > > Before grant copy operation local buffers must be allocated what is > done by calling ioreq_init_copy_buffers. For the 'read'

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

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

[Xen-devel] [PATCH] xenstore: add memory allocation debugging capability

Juergen Gross writes ("[PATCH] xenstore: add memory allocation debugging capability"): > Add support for debugging memory allocation statistics to xenstored. > Specifying "-M " on the command line will enable the feature. > Whenever xenstored receives SIGUSR1 it will dump out a full talloc >

[Xen-devel] [PATCH 2/2] xenstore: use temporary memory context for firing watches

Juergen Gross writes ("[PATCH 2/2] xenstore: use temporary memory context for firing watches"): > Use a temporary memory context for memory allocations when firing > watches. This will avoid leaking memory in case of long living > connections and/or xenstore entries. Can you please split out the

[Xen-devel] [PATCH 1/2] xenstore: call each xenstored command function with temporary context

Juergen Gross writes ("[PATCH 1/2] xenstore: call each xenstored command function with temporary context"): > In order to be able to avoid leaving temporary memory allocated after > processing of a command in xenstored call all command functions with > the temporary "in" context. Each function

[Xen-devel] for-4.8/drivers and Linus' tree + staging conflicts?

Hey Jens, I have some patches for Xen block driver that are based on Linus's tree which has: 7b427a5 xen-blkfront: save uncompleted reqs in blkfront_resume() That particular patch conflicts with your for-4.8/driver branch. What I was wondering is if: 1) Do you want me to create a branh

Re: [Xen-devel] credit2 / cpupool crash in xen-unstable

On Fri, Jul 15, 2016 at 3:48 PM, George Dunlap wrote: > Hey Dario, > > Working on my scheduler benchmarking, and managing occasionally to > crash Xen running the following command: > > xl cpupool-create cpupool.cfg && ./schedbench plan && (xentrace -S 32 > -e 0x21000 -D

Re: [Xen-devel] [PATCH 0/4] Change fixed mmio handlers to a variable number

Hi Julien, On 07/15/2016 10:32 AM, Julien Grall wrote: Hi Shanker, It looks like this series is not threaded. I looked to the headers, and some patch miss the In-Reply-To/References header or they are wrong. Please try to thread the series, it is much easier to find the associated patch.

Re: [Xen-devel] Converting heap page_infos to contiguous virtual

On 07/15/2016 11:19 AM, Andrew Cooper wrote: > On 15/07/16 15:53, Boris Ostrovsky wrote: >> On 07/14/2016 09:29 AM, Andrew Cooper wrote: >>> However, I would recommend getting something functioning first, before >>> trying to optimise it. >> There are two fairly independent parts to improving

Re: [Xen-devel] [PATCH 0/4] Change fixed mmio handlers to a variable number

Hi Shanker, It looks like this series is not threaded. I looked to the headers, and some patch miss the In-Reply-To/References header or they are wrong. Please try to thread the series, it is much easier to find the associated patch. Regards, On 15/07/16 16:25, Shanker Donthineni wrote:

[Xen-devel] [PATCH 4/4] arm/vgic: Change fixed number of mmio handlers to variable number

Compute the number of mmio handlers that are required for vGICv3 and vGICv2 emulation drivers in vgic_v3_init()/vgic_v2_init(). Augment this variable number of mmio handers to a fixed number MAX_IO_HANDLER and pass it to domain_io_init() to allocate enough memory. New code path:

[Xen-devel] [PATCH 3/4] xen/arm: io: Use binary search for mmio handler lookup

As the number of I/O handlers increase, the overhead associated with linear lookup also increases. The system might have maximum of 144 (assuming CONFIG_NR_CPUS=128) mmio handlers. In worst case scenario, it would require 144 iterations for finding a matching handler. Now it is time for us to

[Xen-devel] [PATCH 0/4] Change fixed mmio handlers to a variable number

The maximum number of mmio handlers that are allowed is limited to a macro MAX_IO_HANDLER(16), which is not enough for supporting per CPU Redistributor regions. We need at least MAX_IO_HANDLER+CONFIG_NR_CPUS mmio handlers in order to support ACPI based XEN boot. This patchset uses the dynamic

[Xen-devel] [PATCH 1/4] arm/io: Use separate memory allocation for mmio handlers

The number of mmio handlers are limited to a compile time macro MAX_IO_HANDLER which is 16. This number is not at all sufficient to support per CPU distributor regions. Either it needs to be increased to a bigger number, at least CONFIG_NR_CPUS+16, or allocate a separate memory for mmio handlers

[Xen-devel] [PATCH 2/4] xen: Add generic implementation of binary search

This patch adds the generic implementation of binary search algorithm whcih is copied from Linux kernel v4.7-rc7. No functional changes. Signed-off-by: Shanker Donthineni --- xen/common/Makefile | 1 + xen/common/bsearch.c | 51

Re: [Xen-devel] OVMF very slow on AMD

On 07/15/2016 09:48 AM, Konrad Rzeszutek Wilk wrote: > On Thu, Jul 14, 2016 at 04:53:07PM +0100, Anthony PERARD wrote: >> Hi, >> >> I've been investigating why OVMF is very slow in a Xen guest on an AMD >> host. This, I think, is the current failure that osstest is having. >> >> I've only look at

Re: [Xen-devel] Converting heap page_infos to contiguous virtual

On 15/07/16 15:53, Boris Ostrovsky wrote: > On 07/14/2016 09:29 AM, Andrew Cooper wrote: >> However, I would recommend getting something functioning first, before >> trying to optimise it. > There are two fairly independent parts to improving scrubbing: one is > making it asynchronous and second

Re: [Xen-devel] [PATCH v4] altp2m: Allow the hostp2m entries to be of type p2m_ram_shared

On Jul 15, 2016 02:57, "George Dunlap" wrote: > > On Thu, May 26, 2016 at 5:17 PM, Tamas K Lengyel wrote: > > > > On May 26, 2016 04:40, "George Dunlap" wrote: > >> > >> On 26/05/16 04:55, Tamas K Lengyel wrote: > >> >

Re: [Xen-devel] [Embedded-pv-devel] Xen Project Developer Summit : program Published

On Fri, Jul 15, 2016 at 8:01 AM, Dario Faggioli wrote: > [Reducing the rate of cross-posting a bit] > > On Wed, 2016-06-08 at 11:43 -0400, Meng Xu wrote: > > On Wed, Jun 8, 2016 at 9:02 AM, Lars Kurth > > wrote: > > > In addition to

[Xen-devel] [linux-3.18 test] 97319: regressions - FAIL

flight 97319 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/97319/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 6 xen-boot fail REGR. vs. 96188

Re: [Xen-devel] Converting heap page_infos to contiguous virtual

On 07/14/2016 09:29 AM, Andrew Cooper wrote: > > However, I would recommend getting something functioning first, before > trying to optimise it. There are two fairly independent parts to improving scrubbing: one is making it asynchronous and second is improving clear_page() performance. Whole-RAM

[Xen-devel] [PATCH v2 11/11] xen: credit2: implement true SMT support

In fact, right now, we recommend keepeing runqueues arranged per-core, so that it is the inter-runqueue load balancing code that automatically spreads the work in an SMT friendly way. This means that any other runq arrangement one may want to use falls short of SMT scheduling optimizations. This

[Xen-devel] [PATCH v2 10/11] xen: credit2: the private scheduler lock can be an rwlock.

In fact, the data it protects only change either at init-time, during cpupools manipulation, or when changing domains' weights. In all other cases (namely, load balancing, reading weights and status dumping), information is only read. Therefore, let the lock be an read/write one. This means there

[Xen-devel] [PATCH v2 09/11] tools: tracing: deal with new Credit2 events

more specifically, with: TICKLE_NEW, RUNQ_MAX_WEIGHT, MIGRATE, LOAD_CHECK, LOAD_BALANCE and PICKED_CPU, and in both both xenalyze and formats (for xentrace_format). Signed-off-by: Dario Faggioli Acked-by: George Dunlap --- Cc: Ian Jackson

[Xen-devel] [PATCH v2 08/11] xen: credit2: only marshall trace point arguments if tracing enabled

Signed-off-by: Dario Faggioli --- Cc: George Dunlap Cc: Anshul Makkar Cc: David Vrabel --- Changes from v1: * avoid stray code removal in balance_load(), as pointed out by George during

[Xen-devel] [PATCH v2 07/11] xen: credit2: add yet some more tracing

(and fix the style of two labels as well.) Signed-off-by: Dario Faggioli Acked-by: George Dunlap --- Cc: Anshul Makkar Cc: David Vrabel --- xen/common/sched_credit2.c | 58

[Xen-devel] [PATCH v2 04/11] xen/tools: improve tracing of Credit2 load tracking events

Add the shift used for the precision of the integer arithmetic to the trace records, and update both xenalyze and xentrace_format to make use of/print it. In particular, in xenalyze, we are can now show the load as a (easier to interpreet) percentage. Signed-off-by: Dario Faggioli

[Xen-devel] [PATCH v2 06/11] xen: credit2: make the code less experimental

Mainly, almost all of the BUG_ON-s can be converted into ASSERTS, and almost all the debug printk can either be removed or turned into tracing. The 'TODO' list, in a comment at the beginning of the file, was also stale, so remove items that were still there but are actually done. Signed-off-by:

[Xen-devel] [PATCH v2 03/11] xen: credit2: rework load tracking logic

The existing load tracking code was hard to understad and maintain, and not entirely consistent. This is due to a number of reasons: - code and comments were not in perfect sync, making it difficult to figure out what the intent of a particular choice was (e.g., the choice of 18 for

[Xen-devel] [PATCH v2 05/11] xen: credit2: use non-atomic cpumask and bit operations

as all the accesses to both the masks and the flags are serialized by the runqueues locks already. Signed-off-by: Dario Faggioli Acked-by: George Dunlap --- Cc: Anshul Makkar Cc: David Vrabel

[Xen-devel] [PATCH v2 00/11] xen: sched: assorted fixes and improvements to Credit2

Hi, Version 2 of the patch series. Not much to say apart from the fact that (I think) I've addressed all the review comments v1 received (thanks everyone!). Details are in the individual changelogs. It's smaller because George commited some of the patches already. As mentioned in the v1 thread,

[Xen-devel] [PATCH v2 01/11] xen: sched: leave CPUs doing tasklet work alone.

In both Credit1 and Credit2, stop considering a pCPU idle, if the reason why the idle vCPU is being selected, is to do tasklet work. Not doing so means that the tickling and load balancing logic, seeing the pCPU as idle, considers it a candidate for picking up vCPUs. But the pCPU won't actually

Re: [Xen-devel] Converting heap page_infos to contiguous virtual

On 07/14/2016 06:34 AM, Andrew Cooper wrote: > On 14/07/16 11:25, George Dunlap wrote: >> On 13/07/16 21:57, Boris Ostrovsky wrote: >>> On 07/13/2016 04:34 PM, Andrew Cooper wrote: On 13/07/2016 21:17, Boris Ostrovsky wrote: > On 07/13/2016 04:02 PM, Andrew Cooper wrote: >> On

Re: [Xen-devel] [PATCH v2 1/2] xen: fix a (latent) cpupool-related race during domain destroy

On Fri, 2016-07-15 at 14:52 +0200, Juergen Gross wrote: > On 15/07/16 13:52, Dario Faggioli wrote: > > > > On Fri, 2016-07-15 at 12:36 +0200, Juergen Gross wrote: > > > > > > On 15/07/16 12:14, Dario Faggioli wrote: > > > > > > > > In particular, I'm probably not fully understanding, from that

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

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

Re: [Xen-devel] [PATCH v5 0/7] adjustments

On 7/15/2016 4:05 PM, Andrew Cooper wrote: On 15/07/16 11:41, Corneliu ZUZU wrote: Corneliu ZUZU (7): 1/7: asm-arm/atomic.h: fix arm32|arm64 macros duplication Reviewed-by: Stefano Stabellini Changed: * remove paragraph(s) from

Re: [Xen-devel] [PATCH 12/18] arm/altp2m: Cosmetic fixes - function prototypes.

Hi Sergej, On 04/07/16 12:45, Sergej Proskurin wrote: This commit changes the prototype of the following functions: - apply_p2m_changes - apply_one_level - p2m_shatter_page - p2m_create_table - __p2m_lookup - __p2m_get_mem_access These changes are required as our implementation reuses most of

Re: [Xen-devel] [PATCH 2/3] Update to use a .config file

On Thu, Jul 14, 2016 at 09:05:36AM +0100, Ross Lagerwall wrote: > On 06/15/2016 03:00 PM, Konrad Rzeszutek Wilk wrote: > >On Wed, Jun 15, 2016 at 09:08:46AM +0100, Ross Lagerwall wrote: > >>On 06/14/2016 04:35 PM, Konrad Rzeszutek Wilk wrote: > >>>On Fri, Jun 10, 2016 at 12:02:44PM +0100, Ross

Re: [Xen-devel] [PATCH] travis: Add checkpolicy to the list of packages

On 7/15/16 7:54 AM, Andrew Cooper wrote: > Since c/s 41b61be1c "xsm: add a default policy to .init.data", checkpackage is > required for the hypervisor build if randconfig decides to enable XSM. > > Identified by a Travis randconfig run: > https://travis-ci.org/andyhhp/xen/jobs/144989065 > >

Re: [Xen-devel] Regression with commit 095497ffc66b7f031

On 15/07/16 14:42, Paolo Bonzini wrote: > > > On 15/07/2016 12:41, Juergen Gross wrote: >> On 15/07/16 12:35, Paolo Bonzini wrote: >>> >>> >>> On 15/07/2016 12:12, Gerd Hoffmann wrote: On Fr, 2016-07-15 at 12:02 +0200, Paolo Bonzini wrote: > > On 15/07/2016 10:47, Juergen Gross

Re: [Xen-devel] [libvirt bisection] complete build-i386-libvirt

On 07/15/2016 02:02 PM, osstest service owner wrote: > branch xen-unstable > xenbranch xen-unstable > job build-i386-libvirt > testid libvirt-build > > Tree: libvirt git://libvirt.org/libvirt.git > Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git > Tree: qemu

Re: [Xen-devel] [PATCH v5 0/7] adjustments

On 15/07/16 11:41, Corneliu ZUZU wrote: > Corneliu ZUZU (7): > 1/7: asm-arm/atomic.h: fix arm32|arm64 macros duplication > Reviewed-by: Stefano Stabellini > Changed: > * remove paragraph(s) from README.LinuxPrimitives file > * no empty line

[Xen-devel] [libvirt bisection] complete build-i386-libvirt

branch xen-unstable xenbranch xen-unstable job build-i386-libvirt testid libvirt-build Tree: libvirt git://libvirt.org/libvirt.git Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree:

Re: [Xen-devel] [PATCH] travis: Add checkpolicy to the list of packages

On 15/07/16 13:54, Andrew Cooper wrote: > Since c/s 41b61be1c "xsm: add a default policy to .init.data", checkpackage is s/checkpackage/checkpolicy/ Not sure what came over me. ~Andrew > required for the hypervisor build if randconfig decides to enable XSM. > > Identified by a Travis

[Xen-devel] [PATCH] travis: Add checkpolicy to the list of packages

Since c/s 41b61be1c "xsm: add a default policy to .init.data", checkpackage is required for the hypervisor build if randconfig decides to enable XSM. Identified by a Travis randconfig run: https://travis-ci.org/andyhhp/xen/jobs/144989065 Signed-off-by: Andrew Cooper

Re: [Xen-devel] [PATCH v2 1/2] xen: fix a (latent) cpupool-related race during domain destroy

On 15/07/16 13:52, Dario Faggioli wrote: > On Fri, 2016-07-15 at 12:36 +0200, Juergen Gross wrote: >> On 15/07/16 12:14, Dario Faggioli wrote: >>> In particular, I'm probably not fully understanding, from that >>> commit >>> changelog, what is the set of operations/command that I should run >>> to

Re: [Xen-devel] Regression with commit 095497ffc66b7f031

On 15/07/2016 12:41, Juergen Gross wrote: > On 15/07/16 12:35, Paolo Bonzini wrote: >> >> >> On 15/07/2016 12:12, Gerd Hoffmann wrote: >>> On Fr, 2016-07-15 at 12:02 +0200, Paolo Bonzini wrote: On 15/07/2016 10:47, Juergen Gross wrote: > Nothing scaring and no real difference

Re: [Xen-devel] [PATCH] x86/shadow: Fix build with CONFIG_SHADOW_PAGING=n following c/s 2fc002b

On 15/07/16 13:33, Julien Grall wrote: > Hi Andrew, > > On 15/07/16 13:07, Andrew Cooper wrote: >> c/s 2fc002b "xen: Use a typesafe to define INVALID_GFN" changed >> INVALID_GFN to >> be a boxed type. >> >> Identified by a Travis randconfig run: >>

Re: [Xen-devel] [PATCH] x86/shadow: Fix build with CONFIG_SHADOW_PAGING=n following c/s 2fc002b

Hi Andrew, On 15/07/16 13:07, Andrew Cooper wrote: c/s 2fc002b "xen: Use a typesafe to define INVALID_GFN" changed INVALID_GFN to be a boxed type. Identified by a Travis randconfig run: https://travis-ci.org/xen-project/xen/jobs/144980445 Signed-off-by: Andrew Cooper

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

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

Re: [Xen-devel] [PATCH] x86/shadow: Fix build with CONFIG_SHADOW_PAGING=n following c/s 2fc002b

At 13:07 +0100 on 15 Jul (1468588072), Andrew Cooper wrote: > c/s 2fc002b "xen: Use a typesafe to define INVALID_GFN" changed INVALID_GFN to > be a boxed type. > > Identified by a Travis randconfig run: > https://travis-ci.org/xen-project/xen/jobs/144980445 > > Signed-off-by: Andrew Cooper

[Xen-devel] [PATCH] x86/shadow: Fix build with CONFIG_SHADOW_PAGING=n following c/s 2fc002b

c/s 2fc002b "xen: Use a typesafe to define INVALID_GFN" changed INVALID_GFN to be a boxed type. Identified by a Travis randconfig run: https://travis-ci.org/xen-project/xen/jobs/144980445 Signed-off-by: Andrew Cooper --- CC: Tim Deegan CC: George

Re: [Xen-devel] [Embedded-pv-devel] Xen Project Developer Summit : program Published

[Reducing the rate of cross-posting a bit] On Wed, 2016-06-08 at 11:43 -0400, Meng Xu wrote: > On Wed, Jun 8, 2016 at 9:02 AM, Lars Kurth > wrote: > > In addition to presentations, we will be running a half-day > > hackathon alongside the Summit on the last day. Xen

Re: [Xen-devel] [DRAFT v2] XenSock protocol design document

> -Original Message- > From: Juergen Gross [mailto:jgr...@suse.com] > Sent: 15 July 2016 12:37 > To: Stefano Stabellini; xen-de...@lists.xenproject.org > Cc: joao.m.mart...@oracle.com; Wei Liu; Roger Pau Monne; Lars Kurth; > boris.ostrov...@oracle.com; Paul Durrant > Subject: Re: [DRAFT

Re: [Xen-devel] [PATCH v2 1/2] xen: fix a (latent) cpupool-related race during domain destroy

On Fri, 2016-07-15 at 12:36 +0200, Juergen Gross wrote: > On 15/07/16 12:14, Dario Faggioli wrote: > > In particular, I'm probably not fully understanding, from that > > commit > > changelog, what is the set of operations/command that I should run > > to > > check whether or not I reintroduced the

Re: [Xen-devel] [DRAFT v2] XenSock protocol design document

On 13/07/16 17:47, Stefano Stabellini wrote: > Hi all, > > This is the design document of the XenSock protocol. You can find > prototypes of the Linux frontend and backend drivers here: ... > ### Commands Ring > > The shared ring is used by the frontend to forward socket API calls to the >

Re: [Xen-devel] [PATCH v3 2/2] qdisk - hw/block/xen_disk: grant copy implementation

On Fri, Jul 15, 2016 at 12:28:48PM +0200, Paulina Szubarczyk wrote: > > > On 07/14/2016 12:37 PM, Wei Liu wrote: > >On Wed, Jun 22, 2016 at 10:38:53AM +0200, Paulina Szubarczyk wrote: > >>diff --git a/configure b/configure > >>index e41876a..355d3fa 100755 > >>--- a/configure > >>+++ b/configure

Re: [Xen-devel] xenbits "official" repo for XTF (was Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)

On 15/07/2016 11:21, "Ian Jackson" wrote: >Lars Kurth writes ("Re: [Xen-devel] xenbits "official" repo for XTF (was >Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)"): >> Alright, [stuff] > >With my xenbits admin hat on I therefore intend to: > > * Create xtf.git in

[Xen-devel] [PATCH v5 7/7] asm/atomic.h: implement missing and add common prototypes

ARM (): * add atomic_add_unless() wrapper over __atomic_add_unless() (for common-code interface, i.e. ) X86 (): * implement missing functions atomic_{sub,inc,dec}_return(), atomic_add_unless() * implement missing macro atomic_xchg() COMMON (): * add prototypes for the aforementioned newly

[Xen-devel] [PATCH v5 6/7] asm-arm/atomic.h: atomic_{inc, dec}_return: macros to inline functions

Turn atomic_inc_return and atomic_dec_return atomic.h macros to inline functions. Signed-off-by: Corneliu ZUZU Reviewed-by: Stefano Stabellini --- Changed since v4: * README.LinuxPrimitives not updated anymore --- xen/include/asm-arm/atomic.h |

[Xen-devel] [PATCH v5 5/7] xen/atomic.h: fix: make atomic_read() param const

This wouldn't let me make a param of a function that used atomic_read() const. Signed-off-by: Corneliu ZUZU Reviewed-by: Andrew Cooper Reviewed-by: Stefano Stabellini Reviewed-by: Julien Grall ---

[Xen-devel] [PATCH v5 4/7] asm/atomic.h: common prototyping (add xen/atomic.h)

Create a common-side to establish, among others, prototypes of atomic functions called from common-code. Done to avoid introducing inconsistencies between arch-side headers when we make subtle changes to one of them. Some arm-side macros had to be turned into inline functions in the process.

Re: [Xen-devel] [PATCH v5 1/7] asm-arm/atomic.h: fix arm32|arm64 macros duplication

On 15/07/16 11:41, Corneliu ZUZU wrote: Move duplicate macros between asm-arm/arm32/atomic.h and asm-arm/arm64/atomic.h to asm-arm/atomic.h. Signed-off-by: Corneliu ZUZU Reviewed-by: Stefano Stabellini Acked-by: Julien Grall

[Xen-devel] [PATCH v5 2/7] asm-x86/atomic.h: minor: proper atomic_inc_and_test() placement

Place atomic_inc_and_test() implementation after atomic_inc(). Also empty line fix. Signed-off-by: Corneliu ZUZU Reviewed-by: Andrew Cooper --- Changed since v4: --- xen/include/asm-x86/atomic.h | 39 +++ 1

[Xen-devel] [PATCH v5 1/7] asm-arm/atomic.h: fix arm32|arm64 macros duplication

Move duplicate macros between asm-arm/arm32/atomic.h and asm-arm/arm64/atomic.h to asm-arm/atomic.h. Signed-off-by: Corneliu ZUZU Reviewed-by: Stefano Stabellini --- Changed since v4: * remove paragraph(s) from README.LinuxPrimitives file * no

Re: [Xen-devel] Regression with commit 095497ffc66b7f031

On 15/07/16 12:35, Paolo Bonzini wrote: > > > On 15/07/2016 12:12, Gerd Hoffmann wrote: >> On Fr, 2016-07-15 at 12:02 +0200, Paolo Bonzini wrote: >>> >>> On 15/07/2016 10:47, Juergen Gross wrote: Nothing scaring and no real difference between working and not working variant.

[Xen-devel] [PATCH v5 0/7] adjustments

Corneliu ZUZU (7): 1/7: asm-arm/atomic.h: fix arm32|arm64 macros duplication Reviewed-by: Stefano Stabellini Changed: * remove paragraph(s) from README.LinuxPrimitives file * no empty line additions 2/7: asm-x86/atomic.h: minor: proper

Re: [Xen-devel] [PATCH v2 1/2] xen: fix a (latent) cpupool-related race during domain destroy

On 15/07/16 12:14, Dario Faggioli wrote: > On Fri, 2016-07-15 at 11:38 +0200, Juergen Gross wrote: >> Hmm, are you aware of commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a >> which explicitly moved cpupool_rm_domain() at the place where you are >> removing it again? Please verify that the scenario

Re: [Xen-devel] Regression with commit 095497ffc66b7f031

On 15/07/2016 12:12, Gerd Hoffmann wrote: > On Fr, 2016-07-15 at 12:02 +0200, Paolo Bonzini wrote: >> >> On 15/07/2016 10:47, Juergen Gross wrote: >>> Nothing scaring and no real difference between working and not working >>> variant. >>> >>> Meanwhile I've been digging a little bit deeper and

Re: [Xen-devel] [PATCH v3 2/2] qdisk - hw/block/xen_disk: grant copy implementation

On 07/14/2016 12:37 PM, Wei Liu wrote: On Wed, Jun 22, 2016 at 10:38:53AM +0200, Paulina Szubarczyk wrote: diff --git a/configure b/configure index e41876a..355d3fa 100755 --- a/configure +++ b/configure @@ -1843,7 +1843,7 @@ fi # xen probe if test "$xen" != "no" ; then -

Re: [Xen-devel] xenbits "official" repo for XTF (was Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)

Lars Kurth writes ("Re: [Xen-devel] xenbits "official" repo for XTF (was Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)"): > Alright, [stuff] With my xenbits admin hat on I therefore intend to: * Create xtf.git in the xenbits toplevel and give it the appropriate permissions * Create

  1   2   >