flight 109545 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109545/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358
test-amd64-i386-xl-qe
This run is configured for baseline tests only.
flight 71338 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71338/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfai
Currently, Hot unplug a physical CPU with vpmu enabled may cause
system hang due to send a remote call to an offlined pCPU. This
patch add a cpu hot unplug notifer to save vpmu context before
cpu offline.
Consider one scenario, hot unplug pCPU N with vpmu enabled.
The vcpu which running on this pC
On 5/16/2017 12:13 PM, Boris Ostrovsky wrote:
On 05/16/2017 11:52 AM, Gary R Hook wrote:
A PVH guest's config looks something like
kernel="/root/64/vmlinux"
May I ask from whence this kernel came?
One of 4.11's rcs. Make sure you set CONFIG_XEN_PVH in your .config file.
Please excuse my
On Wed, May 17, 2017 at 7:44 AM, George Dunlap wrote:
>
> Antony,
>
> Attached is a patch to add the -w option if it's available. I've
> smoke-tested that it works under normal conditions; but my simplistic
> attempts to get the bug to trigger have failed. Can you give it a try
> and see if it w
flight 109549 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109549/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 5 xen-buildfail REGR. vs. 107636
build-arm64
> or something ?
I ended up doing two patches - one to create an enable_livepatch
(in mfi-common) to seed the jobs.
And then another to piggyback on that.
I am attaching them here (as attachment), and I think it makes
it simpler?
>From 1a303fe8acb3949eb556673744bc5bc89a842b54 Mon Sep 17 00:00:00
flight 109548 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109548/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 11a6cc5bda811513d2fbe47d8cb1a70b48077800
baseline version:
ovmf a8321feebb6af978478e0
flight 109528 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109528/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 14 guest-saverestore.2 fail REGR. vs.
109469
test-amd64-a
On 2017-05-16 16:23, Juergen Gross wrote:
Destroying a Xen guest domain while it was doing I/Os via xen-blkback
leaked several resources, including references of the guest's memory
pages.
This patch series addresses those leaks by correcting usage of
reference counts and the sequence when to fre
flight 109527 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109527/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 9 redhat-install fail REGR. vs. 109486
test-amd64-amd64-x
Wei Liu, on mer. 17 mai 2017 15:26:08 +0100, wrote:
> Build can fail if stubdom build is run before tools build because:
>
> 1. tools/include build uses relative path and depends on XEN_OS
> 2. stubdom needs tools/include to be built, at which time XEN_OS is
>mini-os and corresponding symlinks
Hi,
On 05/17/2017 07:26 PM, osstest service owner wrote:
> flight 109515 xen-4.8-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/109515/
>
> Failures :-/ but no regressions.
>
> Tests which are failing intermittently (not blocking):
> test-xtf-amd64-amd64-5 45 xtf/test-hv
Hi,
On 05/17/2017 08:32 PM, osstest service owner wrote:
flight 109547 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109547/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1)
On Wed, May 17, 2017 at 08:07:58PM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 13, 2016 at 04:49:25PM +, Ian Jackson wrote:
> > Konrad Rzeszutek Wilk writes ("[PATCH v2 6/9] ts-xen-build: Build the
> > livepatch test-cases"):
> > > +buildcmd_stamped_logged(600, 'xen', 'xenlpt-build',
On 05/17/2017 07:51 PM, Oleksandr Tyshchenko wrote:
Hi, all.
Hi Oleksandr,
On Wed, May 17, 2017 at 7:01 PM, Jan Beulich wrote:
On 17.05.17 at 17:45, wrote:
On Mon, May 15, 2017 at 3:43 PM, Jan Beulich wrote:
On 15.05.17 at 13:45, wrote:
On 05/15/2017 09:19 AM, Jan Beulich wrote:
On
So that you can do:
DESTDIR=`pwd`/dist/xenlptinstall/usr/lib/debug
mkdir -p $DESTDIR
BASEDIR=`pwd`/xen XEN_ROOT=`pwd` make -C xen/test -f `pwd`/xen/Rules.mk install
or such.
Signed-off-by: Konrad Rzeszutek Wilk
---
xen/test/Makefile | 4
1 file changed, 4 insertions(+)
diff --git a/xen/t
On Tue, Dec 13, 2016 at 04:49:25PM +, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("[PATCH v2 6/9] ts-xen-build: Build the
> livepatch test-cases"):
> > +buildcmd_stamped_logged(600, 'xen', 'xenlpt-build', '',< > $dokconfig;
> > +if test -d xen/test; then
> > +$ma
Hi Jan,
On 05/12/2017 03:31 PM, Jan Beulich wrote:
On 10.05.17 at 16:03, wrote:
From: Oleksandr Tyshchenko
The presence of this flag lets us know that the guest
has devices which will most likely be used for passthrough
and as the result the use of IOMMU is expected for this domain.
In that
flight 109523 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109523/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 5 xen-buildfail REGR. vs. 107636
build-arm64
flight 109547 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109547/
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
test-amd64-amd64-libvirt 12 mig
Hi Andrew,
On 16/05/17 18:12, Andrew Cooper wrote:
On 16/05/17 18:06, Tim Deegan wrote:
At 17:51 +0100 on 16 May (1494957116), Andrew Cooper wrote:
c/s 4c5d78a10 was accidentally buggy when handling Protection Keys.
Protection keys applies to all user translations, not just accesses which
orig
Hi, all.
On Wed, May 17, 2017 at 7:01 PM, Jan Beulich wrote:
On 17.05.17 at 17:45, wrote:
>> On Mon, May 15, 2017 at 3:43 PM, Jan Beulich wrote:
>> On 15.05.17 at 13:45, wrote:
On 05/15/2017 09:19 AM, Jan Beulich wrote:
On 15.05.17 at 09:42, wrote:
>> On 15/05/2017
Hi, all.
On Wed, May 17, 2017 at 6:39 PM, Jan Beulich wrote:
On 17.05.17 at 17:28, wrote:
>> Hi, Jan.
>>
>> On Tue, May 16, 2017 at 4:11 PM, Jan Beulich wrote:
>> On 16.05.17 at 14:48, wrote:
On Mon, May 15, 2017 at 3:33 PM, Jan Beulich wrote:
On 15.05.17 at 12:43, wro
flight 109516 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109516/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 109375
test-armhf-armhf-libvirt 13 saveresto
On 16/05/17 14:28, Ian Jackson wrote:
George Dunlap writes ("Re: [PATCH RFC 0/6] qemu-xen-trad: sasl: add SASL support to
VNC"):
On 16/05/17 14:16, Ian Jackson wrote:
Simon: What is stopping you moving to a modern version of qemu ?
I think from his previous query, it was the fact that there
Hi Wei,
On 17/05/17 15:26, Wei Liu wrote:
Build can fail if stubdom build is run before tools build because:
1. tools/include build uses relative path and depends on XEN_OS
2. stubdom needs tools/include to be built, at which time XEN_OS is
mini-os and corresponding symlinks are created
3. l
flight 109524 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109524/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a8321feebb6af978478e0da559806602bd2dcc7d
baseline version:
ovmf 760759962786c3c554c20
Hi Andre,
On 11/05/17 18:53, Andre Przywara wrote:
When LPIs get unmapped by a guest, they might still be in some LR of
some VCPU. Nevertheless we remove the corresponding pending_irq
(possibly freeing it), and detect this case (irq_to_pending() returns
NULL) when the LR gets cleaned up later.
H
flight 109515 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109515/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-xtf-amd64-amd64-5 45 xtf/test-hvm64-lbr-tsx-vmentry fail in 109489 pass
in 109515
test-amd64-i386-xl-q
Hi Andre,
On 11/05/17 18:53, Andre Przywara wrote:
The MAPD command maps a device by associating a memory region for
storing ITEs with a certain device ID. Since it features a valid bit,
MAPD also covers the "unmap" functionality, which we also cover here.
We store the given guest physical addre
Hi Andre,
On 11/05/17 18:53, Andre Przywara wrote:
This introduces the ITS command handler for the CLEAR command, which
clears the pending state of an LPI.
This removes a not-yet injected, but already queued IRQ from a VCPU.
As read_itte() is now eventually used, we add the static keyword.
Sign
flight 109543 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109543/
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
test-amd64-amd64-libvirt 12 mig
Hi Andre,
On 11/05/17 18:53, Andre Przywara wrote:
The MAPC command associates a given collection ID with a given
redistributor, thus mapping collections to VCPUs.
We just store the vcpu_id in the collection table for that.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3-its.c | 47 +++
flight 109511 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109511/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358
test-amd64-i386-xl-qe
On Tue, Dec 13, 2016 at 04:24:56PM +, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("[PATCH v2 3/9] OssTest: Add
> target_dir_exists"):
> > We have target_file_exists but not an equivalant one for directories.
> > This adds it in and is used in the "ts-xen-build: Make {xen|}dist.tar.gz
>
>>> "selected_cpu" needs to be protected, but I would like to avoid taking
>>> a lock. One way to avoid taking lock (before
>>> xen_rebind_evtchn_to_cpu()) would be to use
>>> "local_port%num_present_cpus()" or " smp_processor_id()" as index into
>>> cpumask_next.
>> The latter sounds better to me
On 05/15/2017 02:52 PM, Julien Grall wrote:
Hi Andrew,
On 08/05/17 17:29, Andrew Cooper wrote:
On 08/05/17 17:17, Ross Lagerwall wrote:
Some EFI firmware implementations may place the EFI properties table in
RAM marked as BootServicesData, which Xen does not consider as reserved.
When dom0 tri
Hi Andre,
On 11/05/17 18:53, Andre Przywara wrote:
The INT command sets a given LPI identified by a DeviceID/EventID pair
as pending and thus triggers it to be injected.
Signed-off-by: Andre Przywara
---
xen/arch/arm/vgic-v3-its.c | 21 +
1 file changed, 21 insertions(+)
Hi,
On 11/05/17 18:53, Andre Przywara wrote:
+/* Must be called with the ITS lock held. */
+static bool vgic_v3_verify_its_status(struct virt_its *its, bool status)
+{
+ASSERT(spin_is_locked(&its->its_lock));
+
+if ( !status )
+return false;
+
+if ( !(its->cbaser & GITS_VALID
Jan Beulich writes:
On 15.05.17 at 16:10, wrote:
>> --- a/xen/include/asm-x86/page.h
>> +++ b/xen/include/asm-x86/page.h
>> @@ -375,6 +375,10 @@ perms_strictly_increased(uint32_t old_flags, uint32_t
>> new_flags)
>>
>> #define PAGE_ALIGN(x) (((x) + PAGE_SIZE - 1) & PAGE_MASK)
>>
>> +s
On 17/05/2017 16:56, Jan Beulich wrote:
On 17.05.17 at 16:57, wrote:
The condition to check for if there is space in the ring buffer
also becomes true if the buffer is full, thus consumer waits for
the producer to fill the buffer eventhough it is already full.
To resolve the situat
>>> On 17.05.17 at 17:45, wrote:
> On Mon, May 15, 2017 at 3:43 PM, Jan Beulich wrote:
> On 15.05.17 at 13:45, wrote:
>>> On 05/15/2017 09:19 AM, Jan Beulich wrote:
>>> On 15.05.17 at 09:42, wrote:
> On 15/05/2017 08:20, Jan Beulich wrote:
>> With this I think there's quite a bi
>>> On 17.05.17 at 16:57, wrote:
> The condition to check for if there is space in the ring buffer
> also becomes true if the buffer is full, thus consumer waits for
> the producer to fill the buffer eventhough it is already full.
>
> To resolve the situation, check if the buffer is f
>>> On 15.05.17 at 16:10, wrote:
> --- a/xen/include/asm-x86/page.h
> +++ b/xen/include/asm-x86/page.h
> @@ -375,6 +375,10 @@ perms_strictly_increased(uint32_t old_flags, uint32_t
> new_flags)
>
> #define PAGE_ALIGN(x) (((x) + PAGE_SIZE - 1) & PAGE_MASK)
>
> +static inline void invalidate_ic
>>> On 15.05.17 at 16:10, wrote:
> flush_page_to_ram() unconditionally drops the icache. In certain
> situations this leads to execessive icache flushes when
> flush_page_to_ram() ends up being repeatedly called in a loop.
>
> Introduce a parameter to allow callers of flush_page_to_ram() to take
Hi, Jan.
On Mon, May 15, 2017 at 3:43 PM, Jan Beulich wrote:
On 15.05.17 at 13:45, wrote:
>> On 05/15/2017 09:19 AM, Jan Beulich wrote:
>> On 15.05.17 at 09:42, wrote:
On 15/05/2017 08:20, Jan Beulich wrote:
> With this I think there's quite a bit of justification needed to ke
>>> On 17.05.17 at 17:28, wrote:
> Hi, Jan.
>
> On Tue, May 16, 2017 at 4:11 PM, Jan Beulich wrote:
> On 16.05.17 at 14:48, wrote:
>>> On Mon, May 15, 2017 at 3:33 PM, Jan Beulich wrote:
>>> On 15.05.17 at 12:43, wrote:
> Indeed, there was some misunderstanding from my side on thi
This run is configured for baseline tests only.
flight 71333 xen-4.7-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71333/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-56 xen-boot
Hi Andre,
On 11/05/17 18:53, Andre Przywara wrote:
For each device we allocate one struct pending_irq for each virtual
event (MSI).
Provide a helper function which returns the pointer to the appropriate
struct, to be able to find the right struct when given a virtual
deviceID/eventID pair.
Sign
On 16/05/17 20:02, Boris Ostrovsky wrote:
On 05/16/2017 01:15 PM, Anoob Soman wrote:
Hi,
In our Xenserver testing, I have seen cases when we boot 50 windows
VMs together, dom0 kernel softlocks up.
The following is a brief description of the problem of what caused
soflockup detection code to ki
Hi, Jan.
On Tue, May 16, 2017 at 4:11 PM, Jan Beulich wrote:
On 16.05.17 at 14:48, wrote:
>> On Mon, May 15, 2017 at 3:33 PM, Jan Beulich wrote:
>> On 15.05.17 at 12:43, wrote:
Indeed, there was some misunderstanding from my side on this.
Let me elaborate a bit more on this:
Wei Liu writes ("[PATCH for-4.9 v2] build: stubdom and tools should depend on
public header target"):
> Build can fail if stubdom build is run before tools build because:
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https:/
On Wed, May 17, 2017 at 09:14:17AM -0600, Jan Beulich wrote:
> >>> On 17.05.17 at 17:05, wrote:
> > On Wed, May 17, 2017 at 03:51:11PM +0100, Wei Liu wrote:
> >> On Wed, May 17, 2017 at 08:28:40AM -0600, Jan Beulich wrote:
> >> > >>> On 17.05.17 at 16:20, wrote:
> >> > > Wei Liu writes ("Re: [PAT
Can confirm this fixes the problems I was seeing. Tested with multiple
builds on both RHEL6 and RHEL7. No further issues found.
Tested-by: Steven Haigh
On 18/05/17 00:26, Wei Liu wrote:
> Build can fail if stubdom build is run before tools build because:
>
> 1. tools/include build uses relative
Achieve this by expanding pt_irq_create_bind in order to support mapping
interrupts of type PT_IRQ_TYPE_PCI to a PVH Dom0. GSIs bound to Dom0 are always
identity bound, which means the all the fields inside of the u.pci sub-struct
are ignored, and only the machine_irq is actually used in order to d
Hello,
The following patches allow binding bare-metal GSIs into a PVHv2 Dom0, by
snooping on the vIO APICs writes made by Dom0.
First two patches introduce the necessary code to bind GSIs into a PVH Dom0,
and patch 3 snoops on vIO APIC writes for unmask and binds the GSI to Dom0.
The series has
Add the glue in order to bind the PVH Dom0 GSI from bare metal. This is done
when Dom0 unmasks the vIO APIC pins, by fetching the current pin settings and
setting up the PIRQ, which will then be bound to Dom0.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes sinc
Move the code to allocate and map a domain pirq (either GSI or MSI) into the
x86 irq code base, so that it can be used outside of the physdev ops.
This change shouldn't affect the functionality of the already existing physdev
ops.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Co
>>> On 17.05.17 at 17:05, wrote:
> On Wed, May 17, 2017 at 03:51:11PM +0100, Wei Liu wrote:
>> On Wed, May 17, 2017 at 08:28:40AM -0600, Jan Beulich wrote:
>> > >>> On 17.05.17 at 16:20, wrote:
>> > > Wei Liu writes ("Re: [PATCH for-4.9] build: stubdom and tools should
>> > > depend
>
>> > > o
>>> On 17.05.17 at 16:51, wrote:
> On Wed, May 17, 2017 at 08:28:40AM -0600, Jan Beulich wrote:
>> >>> On 17.05.17 at 16:20, wrote:
>> > Wei Liu writes ("Re: [PATCH for-4.9] build: stubdom and tools should
>> > depend
>> > on public header target"):
>> >> On Wed, May 17, 2017 at 02:16:39PM +010
On Wed, May 17, 2017 at 03:51:11PM +0100, Wei Liu wrote:
> On Wed, May 17, 2017 at 08:28:40AM -0600, Jan Beulich wrote:
> > >>> On 17.05.17 at 16:20, wrote:
> > > Wei Liu writes ("Re: [PATCH for-4.9] build: stubdom and tools should
> > > depend
> > > on public header target"):
> > >> On Wed, May
On 05/16/2017 06:43 PM, osstest service owner wrote:
> flight 109469 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/109469/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-libvirt 6
The condition to check for if there is space in the ring buffer
also becomes true if the buffer is full, thus consumer waits for
the producer to fill the buffer eventhough it is already full.
To resolve the situation, check if the buffer is full and then
break from the loop.
On Wed, May 17, 2017 at 08:28:40AM -0600, Jan Beulich wrote:
> >>> On 17.05.17 at 16:20, wrote:
> > Wei Liu writes ("Re: [PATCH for-4.9] build: stubdom and tools should depend
> > on public header target"):
> >> On Wed, May 17, 2017 at 02:16:39PM +0100, Ian Jackson wrote:
> >> > The new code in t
On 17/05/17 15:44, Wei Liu wrote:
On Wed, May 17, 2017 at 03:35:42PM +0100, Julien Grall wrote:
Hi Wei,
On 16/05/17 11:47, Wei Liu wrote:
Wei Liu (2):
tools/Rules.mk: honour CPPFLAGS in header check
Assuming this patch got ack...
build: fix tools/include and stubdom build
...
Rele
>>> On 17.05.17 at 16:32, wrote:
> On 05/17/2017 10:09 AM, Jan Beulich wrote:
> On 17.05.17 at 15:58, wrote:
>>> On 05/17/2017 08:54 AM, Jan Beulich wrote:
>>> On 17.05.17 at 14:40, wrote:
> On 16.05.17 at 19:29, wrote:
>>> Currently, hot unplug a cpu with vpmu enabled may c
On Wed, May 17, 2017 at 03:35:42PM +0100, Julien Grall wrote:
> Hi Wei,
>
> On 16/05/17 11:47, Wei Liu wrote:
> > Wei Liu (2):
> > tools/Rules.mk: honour CPPFLAGS in header check
>
> Assuming this patch got ack...
>
> > build: fix tools/include and stubdom build
>
> ...
>
> Release-acked-b
Hi,
On 16/05/17 17:02, Wei Liu wrote:
On Tue, May 16, 2017 at 06:57:53PM +0300, Andrii Anisov wrote:
From: Andrii Anisov
Initialise *size in default branch to prevent certain compilers (i.e.
Linaro GCC 5.2-2015.11-2) from reporting "variable may be used uninitialized"
errors in caller functio
Hi Wei,
On 16/05/17 11:47, Wei Liu wrote:
Wei Liu (2):
tools/Rules.mk: honour CPPFLAGS in header check
Assuming this patch got ack...
build: fix tools/include and stubdom build
...
Release-acked-by: Julien Grall
Cheers,
--
Julien Grall
_
On 05/17/2017 10:09 AM, Jan Beulich wrote:
On 17.05.17 at 15:58, wrote:
>> On 05/17/2017 08:54 AM, Jan Beulich wrote:
>> On 17.05.17 at 14:40, wrote:
On 16.05.17 at 19:29, wrote:
>> Currently, hot unplug a cpu with vpmu enabled may cause system hang
>> due to send IPI t
>>> On 17.05.17 at 16:20, wrote:
> Wei Liu writes ("Re: [PATCH for-4.9] build: stubdom and tools should depend
> on public header target"):
>> On Wed, May 17, 2017 at 02:16:39PM +0100, Ian Jackson wrote:
>> > The new code in the Makefiles LGTM. I have only one nit, which is
>> > that style for M
Build can fail if stubdom build is run before tools build because:
1. tools/include build uses relative path and depends on XEN_OS
2. stubdom needs tools/include to be built, at which time XEN_OS is
mini-os and corresponding symlinks are created
3. libraries inside tools needs tools/include to
Hello,
Sorry I missed that patch. In the future, please CC me if you want a
patch to go in Xen 4.9.
On 10/05/17 12:13, Igor Druzhinin wrote:
The same set of functions is used to set as well as to clean
P2M entries, except that for clean operations INVALID_MFN (~0UL)
is passed as a parameter.
On Wed, May 17, 2017 at 03:20:08PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH for-4.9] build: stubdom and tools should depend
> on public header target"):
> > On Wed, May 17, 2017 at 02:16:39PM +0100, Ian Jackson wrote:
> > > The new code in the Makefiles LGTM. I have only one nit, w
Wei Liu writes ("Re: [PATCH for-4.9] build: stubdom and tools should depend on
public header target"):
> On Wed, May 17, 2017 at 02:16:39PM +0100, Ian Jackson wrote:
> > The new code in the Makefiles LGTM. I have only one nit, which is
> > that style for Makefile targets seems to be to use `-' ra
flight 71334 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71334/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-i386-squeeze-netboot-pygrub 9 debian-di-install fail like
71276
test-amd64-i
>>> On 17.05.17 at 15:58, wrote:
> On 05/17/2017 08:54 AM, Jan Beulich wrote:
> On 17.05.17 at 14:40, wrote:
>>> On 16.05.17 at 19:29, wrote:
> Currently, hot unplug a cpu with vpmu enabled may cause system hang
> due to send IPI to a die physical cpu. This patch add a cpu hot un
On 16/05/17 14:58, Ian Jackson wrote:
Andrew Cooper writes ("[PATCH for-4.9] tools/xenconsoled: Preserve errno while
rotating logfile handles"):
The logic to optionally exit after a poll() error relies on errno, but
handle_log_reload() does not preserve it.
Signed-off-by: Andrew Cooper
Ac
flight 109537 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109537/
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
test-amd64-amd64-libvirt 12 mig
On 16/05/17 08:59, Roger Pau Monne wrote:
Hello,
Hi Roger,
The first two patches in the series fix a race with concurrent device
addition/removal and two bugs related to manipulation of the list of active
domains in the devd subcommand. The last patch is not a bugfix itself, but
it makes the
On 05/17/2017 08:54 AM, Jan Beulich wrote:
On 17.05.17 at 14:40, wrote:
>> On 16.05.17 at 19:29, wrote:
Currently, hot unplug a cpu with vpmu enabled may cause system hang
due to send IPI to a die physical cpu. This patch add a cpu hot unplug
notifer to save vpmu context b
Hi,
On 15/05/17 14:47, George Dunlap wrote:
On Sat, May 13, 2017 at 1:34 AM, Xiong Zhang wrote:
Commit 6d774a951696 ("x86/ioreq server: synchronously reset outstanding
p2m_ioreq_server entries when an ioreq server unmaps") introduced
p2m_finish_type_change(), which was meant to synchronously f
On Wed, May 17, 2017 at 02:16:39PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH for-4.9] build: stubdom and tools should depend on
> public header target"):
> > Build can fail if stubdom build is run before tools build because:
> >
> > 1. tools/include build uses relative path and depends
flight 109505 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109505/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail like 109428
test-amd64-i386-xl-qemut-win7-amd64
On Wed, May 17, 2017 at 1:46 PM, George Dunlap wrote:
> On 17/05/17 13:43, Ian Jackson wrote:
>> George Dunlap writes ("Re: [Xen-devel] [Xen-users] vif-bridge errors when
>> creating and destroying dozens of VMs simultaneously"):
>>> So we have three options:
>> ...
>>> 3. Try to check to see if
flight 109509 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109509/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-rtds 5 xen-install fail in 109488 pass in 109509
test-amd64-i386-xl-qemut-debi
On 05/13/2017, 12:15 AM, Josh Poimboeuf wrote:
>> Similarly, I have OBJTOOL(START_FUNC) and OBJTOOL(END_FUNC) emitted with
>> each FUNC_START/FUNC_END. So far, when manually expanded for simplicity,
>> it looks like this:
>
> I like the idea of making objtool smart enough to read the entry code,
>
Wei Liu writes ("[PATCH for-4.9] build: stubdom and tools should depend on
public header target"):
> Build can fail if stubdom build is run before tools build because:
>
> 1. tools/include build uses relative path and depends on XEN_OS
> 2. stubdom needs tools/include to be built, at which time X
Build can fail if stubdom build is run before tools build because:
1. tools/include build uses relative path and depends on XEN_OS
2. stubdom needs tools/include to be built, at which time XEN_OS is
mini-os and corresponding symlinks are created
3. libraries inside tools needs tools/include to
On Tue, May 16, 2017 at 12:19:26PM -0700, Stefano Stabellini wrote:
> The following changes since commit cdece0467c7cf8e3f4b3c3f0b13bf2c4fea9:
>
> block/win32: fix 'ret not initialized' warning (2017-05-16 15:34:18 +0100)
>
> are available in the git repository at:
>
> git://xenbits.xen.
>>> On 17.05.17 at 14:40, wrote:
>> >>> On 16.05.17 at 19:29, wrote:
>> > Currently, hot unplug a cpu with vpmu enabled may cause system hang
>> > due to send IPI to a die physical cpu. This patch add a cpu hot unplug
>> > notifer to save vpmu context before cpu offline.
>> >
>> > Consider one sc
On 17/05/17 13:43, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] [Xen-users] vif-bridge errors when
> creating and destroying dozens of VMs simultaneously"):
>> So we have three options:
> ...
>> 3. Try to check to see if the version of iptables we have supports -w,
>> and use it if
George Dunlap writes ("Re: [Xen-devel] [Xen-users] vif-bridge errors when
creating and destroying dozens of VMs simultaneously"):
> So we have three options:
...
> 3. Try to check to see if the version of iptables we have supports -w,
> and use it if available. This should also work on all system
> >>> On 16.05.17 at 19:29, wrote:
> > Currently, hot unplug a cpu with vpmu enabled may cause system hang
> > due to send IPI to a die physical cpu. This patch add a cpu hot unplug
> > notifer to save vpmu context before cpu offline.
> >
> > Consider one scene, hotplug physical cpu N with vpmu is
On Wed, May 17, 2017 at 11:10 AM, George Dunlap
wrote:
> On 17/05/17 10:45, Roger Pau Monné wrote:
>> On Wed, May 17, 2017 at 10:04:40AM +0100, George Dunlap wrote:
>>> cc'ing xen-devel & some relevant people
>>
>> Please bear with me, my knowledge of iptables is 0.
>>
>>> On Tue, May 16, 2017 at
Hi Andrew,
On 05/15/2017 04:40 PM, Andrew Cooper wrote:
On 15/05/17 16:31, Jan Beulich wrote:
On 15.05.17 at 14:50, wrote:
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -633,9 +633,12 @@ void pv_inject_event(const struct x86_event *event)
const struct trap_info *ti;
const
flight 109529 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109529/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen b231884da805d21156163d3ea2ef4de2e9f65fb0
baseline version:
xen 1788
On Wed, May 17, 2017 at 03:51:43AM -0600, Jan Beulich wrote:
> >>> On 17.05.17 at 11:34, wrote:
> > On Wed, May 17, 2017 at 03:02:26AM -0600, Jan Beulich wrote:
> >> >>> On 17.05.17 at 10:26, wrote:
> >> > On Tue, May 16, 2017 at 10:23:48AM -0600, Jan Beulich wrote:
> >> >> >>> On 16.05.17 at 17:
On 17/05/17 10:45, Roger Pau Monné wrote:
> On Wed, May 17, 2017 at 10:04:40AM +0100, George Dunlap wrote:
>> cc'ing xen-devel & some relevant people
>
> Please bear with me, my knowledge of iptables is 0.
>
>> On Tue, May 16, 2017 at 4:21 PM, Antony Saba wrote:
>>> Hello xen-users,
>>>
>>> We a
1 - 100 of 115 matches
Mail list logo
