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
test-amd64-amd64-
On Fri, Jul 15, 2016 at 6:04 AM, Andrew Cooper
wrote:
> On 12/07/16 04:59, Andrey Grodzovsky wrote:
>
> Hello
>
> Some background -
>
> We are trying to run Qualcomm Atheros AR928X Wireless Network Adapter and
> have a crash right on driver load, following are our observations and
> questions.
>
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 git://xenbits.xen.org
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
test-armhf-armhf-lib
> > 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
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 doma
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 layer
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
test-amd64-amd64-li
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
test-amd64-i38
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
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 to sign up :-). (Assuming we
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
---
Resend to fix t
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 w
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 th
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 v
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 th
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
---
CC: Dario Faggioli
CC:
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.
Signed-of
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
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 other
>> than the hvmloader (wh
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 (suc
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 In-Reply-To/References header feilds.
>
> xen/
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 chang
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 dy
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:
domain_vgic_regis
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 allo
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/common/bsearch.c | 5
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 t
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
> > >
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: Andrew
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' operati
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 guest-saver
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
> repor
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
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 can
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 for
On 15/07/16 17:04, Konrad Rzeszutek Wilk wrote:
> On Fri, Jul 15, 2016 at 10:53:51AM -0400, 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 independen
On Fri, Jul 15, 2016 at 10:53:51AM -0400, 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
> maki
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 /tmp/05.schedbench-w16-cpup
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.
S
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 scrub
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:
T
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:
domain_vgic_regis
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 chang
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 allo
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 dy
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 +++
xen/inc
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
flight 97368 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/97368/
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
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 is
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:
> >> > Move sharing locks above altp2m to avoid locking order violation.
Allow
> >>
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 presentations, we will be running a half-day
> > > hackathon al
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
test-amd64-amd64-xl-qe
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
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 c
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
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
Cc: Wei Liu
Cc: Anshul Makkar
---
tools/xentrace/form
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 review.
---
xen/common/sched_credit2.c | 112 +++-
1 file chang
(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 +---
1 file changed, 54 insertions(+), 4 deletions(-)
diff --git a/xen/common
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
Reviewed-by: G
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: D
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 load_win
This really should not happen, but:
1. it does happen! Some more info here:
http://lists.xen.org/archives/html/xen-devel/2016-06/msg00922.html
2. independently from 1, it makes sense and is easy enough
to have a 'safety catch'.
The reason why this is particularly bad for Credit2 is that
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/common/sched_credit2.c | 48 ++--
1 file changed, 2
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,
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 pi
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 13/07/16
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
>
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
test-amd64-i386-
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 README.LinuxPrimitives file
* no emp
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 a specific part of OVMF where the slowdown is very
> obviou
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 t
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 Lage
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
>
> Si
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 wrote
Hi Julien,
Are you okay to insert the below two validation checks before inserting
mmio handler?
void register_mmio_handler(struct domain *d,
const struct mmio_handler_ops *ops,
paddr_t addr, paddr_t size, void *priv)
{
struct vmmio *vm
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 git://xenbits.xen.org/qemu-xen-tra
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 additions
>
> 2/7: asm-x86/at
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: xen
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 randconfig
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
---
CC: Doug Goldstein
---
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
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 betwee
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:
>>https://travis-ci.org/xen-project/xen/jobs/1449
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
Sorry for the breaka
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
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
Ac
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 Dunlap
CC: Julien Grall
---
xen/arch/x86/mm
[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 Project
> > hackathons have ev
> -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 v2]
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
On 7/12/2016 11:07 AM, Corneliu ZUZU wrote:
On 7/12/2016 10:45 AM, Tian, Kevin wrote:
From: Corneliu ZUZU [mailto:cz...@bitdefender.com]
Sent: Monday, July 11, 2016 2:19 PM
+static inline
+void monitor_ctrlreg_adjust_traps(struct domain *d, unsigned int
index)
+{
+/* For now, VMX only. */
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
> backen
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
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 the xenbits toplevel
> and g
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 imple
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 | 13 ++---
1 file changed, 10 insertions(
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
---
Changed since v4:
---
xen/include/asm-arm/atomic.h | 2 +-
xen/include/asm-x86/atomic.h | 2 +-
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.
Rem
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
Regards,
---
Changed since v4:
* remove paragraph(s) from
1 - 100 of 148 matches
Mail list logo
