flight 135050 qemu-upstream-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135050/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow216 guest-saverestore.2 fail REGR. vs. 133734
buil
flight 135215 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135215/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
To the Makefile that generates the cpuid policy. Without this fix if
the tools python interpreter is different than the default 'python' it
won't be correctly propagated.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/include/Makefile | 2 +-
1 file changed, 1 inserti
flight 84118 distros-debian-squeeze real [real]
http://osstest.xensource.com/osstest/logs/84118/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
Hi,
On 22/04/2019 22:59, Stefano Stabellini wrote:
On Sun, 21 Apr 2019, Julien Grall wrote:
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 30cfb01..5b8fcc5 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1068,9 +1068,24 @@ int unmap_regions_p2mt(struct domain *d,
in
Hi,
On 24/04/2019 01:20, Stefano Stabellini wrote:
On Mon, 22 Apr 2019, Julien Grall wrote:
CONFIG_EARLY_PRINTK can only be set when CONFIG_DEBUG is enabled. It can
be quite convenient to only modify the target.
However, the target clean will not include the .config.
This means CONFIG_DEBUG i
flight 135232 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135232/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
coverity-amd647 coverity-upload fail REGR. vs. 133615
version t
On Thu, Apr 18, 2019 at 07:33:05PM +0100, Julien Grall wrote:
> (+ Roger)
>
> On 18/04/2019 12:15, Artem Mygaiev wrote:
> > Hi Julien
> >
> > On Thu, 2019-04-18 at 11:43 +0100, Julien Grall wrote:
> > > On 18/04/2019 10:15, Artem Mygaiev wrote:
> > > > Hello Julien, Stefano
> > >
> > > Hi Artem,
On Wed, Apr 24, 2019 at 11:20:37AM +0200, Roger Pau Monne wrote:
> To the Makefile that generates the cpuid policy. Without this fix if
> the tools python interpreter is different than the default 'python' it
> won't be correctly propagated.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Wei Liu
flight 135228 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135228/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
Hi Jan,
On 11/04/2019 13:45, Jan Beulich wrote:
--- a/xen/common/core_parking.c
+++ b/xen/common/core_parking.c
[...]
+bool core_parking_remove(unsigned int cpu)
Something looks wrong. This function is implemented in common code but...
+{
+unsigned int i;
+bool found = false;
+
On 23/04/2019 22:59, Mathieu Tarral wrote:
>>> The funny thing is that it's always at the same instruction that it fails,
>>> the 106th singlestep,
>>> at 0x806d32dc:
>>> [0x7c90e514]> s 0x806d32dc
>>> [0x806d32dc]> pd 10
>>> 0x806d32dc 890d8000feff mov dword [0xfffe0080], ecx
>> This is a read of
Hi,
I haven't seen any answer from Gang Wei. I assume this is fine.
I will queue this patch in my branch next-4.13.
Cheers,
On 22/03/2019 10:46, Julien Grall wrote:
Hi,
Adding Gang Wei so he can ack the patch.
Cheers,
On 12/03/2019 09:39, Hawrylko, Lukasz wrote:
Signed-off-by: Lukasz Hawr
flight 135219 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135219/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134977
version targeted for testi
At this moment change_type_range() prints a warning in case end >
host_max_pfn. While this is unlikely to happen the function should
return a error and propagate it to the caller, hap_track_dirty_vram()
This patch makes change_type_range() return -EINVAL or 0 if all is ok.
Signed-off-by: Alexandr
On Sun, 2019-04-21 at 22:26 +, Mathieu Tarral wrote:
> Hi,
>
> I'm having an issue with Xen's VMI subsystem.
>
> My goal is to build a small debugger that can break at an
> application's entrypoint
> on Windows XP, when a new process is being created.
>
There was an announcement a while bac
flight 135077 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135077/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 133909
Tests which did n
flight 135233 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135233/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd b58321507702a1125aed58ddc320b560b1bffc71
baseline version:
freebsd 8752233742e
On Wed, Apr 24, 2019 at 02:27:32PM +, Alexandru Stefan ISAILA wrote:
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 9e81a30cc4..27697d5a77 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1028,7 +1028,7 @@ int p2m_change_type_one(struct domain *d, u
flight 135245 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135245/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
On 4/24/19 5:46 PM, Roger Pau Monné wrote:
On Wed, Apr 24, 2019 at 02:27:32PM +, Alexandru Stefan ISAILA wrote:
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 9e81a30cc4..27697d5a77 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1028,7 +1028,7 @@ int p2m
Hi,
On 15/04/2019 09:41, Andre Przywara wrote:
On Mon, 15 Apr 2019 13:41:41 +0530
Amit Tomer wrote:
Hello,
After talking via IRC, the problem is PPIs, that this platform uses for
PMU interrupts. When Xen tries to setup the IRQ forwarding for Dom0 for
this device, it fails because it only su
Hi,
Please ignore this patch. This was already sent separately.
Cheers,
On 22/04/2019 17:49, Julien Grall wrote:
CONFIG_EARLY_PRINTK can only be set when CONFIG_DEBUG is enabled. It can
be quite convenient to only modify the target.
However, the target clean will not include the .config. This
On Mon, Apr 22, 2019 at 6:00 PM Mathieu Tarral
wrote:
>
> On Monday 22 April 2019 11:22, Razvan Cojocaru
> wrote:
>
> > On 4/22/19 1:26 AM, Mathieu Tarral wrote:
> >
> > > The problem is that RtlUserThreadStart is paged-out, so i'm trying to
> > > reach it via singlestepping as a backup solutio
Hi,
@Ian, @Wei: Gentle ping.
On 18/04/2019 16:09, Julien Grall wrote:
Hi,
On 18/04/2019 12:46, Wei Liu wrote:
On Wed, Apr 17, 2019 at 06:42:47PM +0100, Julien Grall wrote:
Hi,
@Wei, @Ian: Do you have any input?
Sorry I haven't been following this closely, but shouldn't we fix the
interfac
flight 135082 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135082/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail in 134997 pass in
135082
test-amd64-amd64-libvirt
On 4/24/19 6:25 PM, Tamas K Lengyel wrote:
On Mon, Apr 22, 2019 at 6:00 PM Mathieu Tarral
wrote:
On Monday 22 April 2019 11:22, Razvan Cojocaru
wrote:
On 4/22/19 1:26 AM, Mathieu Tarral wrote:
The problem is that RtlUserThreadStart is paged-out, so i'm trying to reach it
via singleste
On Sun, Apr 21, 2019 at 4:27 PM Mathieu Tarral
wrote:
>
> Hi,
>
> I'm having an issue with Xen's VMI subsystem.
>
> My goal is to build a small debugger that can break at an application's
> entrypoint
> on Windows XP, when a new process is being created.
>
> To accomplish this, I first set a soft
On 4/23/19 9:04 AM, Roger Pau Monne wrote:
> This involves initializing the boot params EFI related fields and the
> efi global variable.
>
> Without this fix a PVH dom0 doesn't detect when booted from EFI, and
> thus doesn't support accessing any of the EFI related data.
>
> Reported-by: PGNet Dev
On Wed, Apr 24, 2019 at 9:34 AM Razvan Cojocaru
wrote:
>
>
>
> On 4/24/19 6:25 PM, Tamas K Lengyel wrote:
> > On Mon, Apr 22, 2019 at 6:00 PM Mathieu Tarral
> > wrote:
> >>
> >> On Monday 22 April 2019 11:22, Razvan Cojocaru
> >> wrote:
> >>
> >>> On 4/22/19 1:26 AM, Mathieu Tarral wrote:
> >>>
On Wed, Apr 24, 2019 at 11:36:41AM -0400, Boris Ostrovsky wrote:
> On 4/23/19 9:04 AM, Roger Pau Monne wrote:
> > This involves initializing the boot params EFI related fields and the
> > efi global variable.
> >
> > Without this fix a PVH dom0 doesn't detect when booted from EFI, and
> > thus does
On 4/24/19 11:45 AM, Roger Pau Monné wrote:
> On Wed, Apr 24, 2019 at 11:36:41AM -0400, Boris Ostrovsky wrote:
>> On 4/23/19 9:04 AM, Roger Pau Monne wrote:
>>> This involves initializing the boot params EFI related fields and the
>>> efi global variable.
>>>
>>> Without this fix a PVH dom0 doesn't
Currently, the virtual address of the 3rd level page-tables is obtained
using mfn_to_virt().
On Arm32, mfn_to_virt can only work on xenheap page. While in practice
all the page-tables updated will reside in xenheap, in practive the
page-tables covering Xen memory (e.g xen_mapping) is part of Xen b
{set, clear}_fixmap() are currently open-coding update to the Xen
page-tables. This can be avoided by using the generic helpers
map_pages_to_xen() and destroy_xen_mappings().
Both function are not meant to fail for fixmap, hence the BUG_ON()
checking the return.
Signed-off-by: Julien Grall
---
The enum xenmap_operation is not used anymore. So remove it.
Signed-off-by: Julien Grall
---
xen/arch/arm/mm.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 611ea53992..97e876d866 100644
--- a/xen/arch/ar
At the moment, the flags are not enough to describe what kind of update
will done on the VA range. They need to be used in conjunction with the
enum xenmap_operation.
It would be more convenient to have all the information for the update
in a single place.
Two new flags are added to remove the re
Currently, xen_pt_update_entry() is only able to update the region covered
by xen_second (i.e 0 to 0x7fff).
Because of the restriction we end to have multiple functions in mm.c
modifying the page-tables differently.
Furthermore, we never walked the page-tables fully. This means that any
chang
create_xen_entries() is doing more than creating entries. It can also
modify and remove entries.
Rename the function to make clear what the function is actually doing.
Signed-off-by: Julien Grall
---
xen/arch/arm/mm.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
d
Hi all,
This is the third part of the boot/memory rework for Xen on Arm. At the
moment, the update to Xen PT is scattered all around mm.c. This makes
difficult to rework Xen memory layout or even ensuring we are following the
Arm Arm properly (and we are not so far!).
This part contains code to p
set_pte_flags_on_range() is yet another function that will open-code
update to a specific range in the Xen page-tables. It can be completely
dropped by using either modify_xen_mappings() or destroy_xen_mappings().
Signed-off-by: Julien Grall
---
xen/arch/arm/mm.c | 58 ++-
In preparation of rework of the Xen PT, the logic to update an entry
in moved out in a separate function.
Signed-off-by: Julien Grall
---
xen/arch/arm/mm.c | 140 +-
1 file changed, 74 insertions(+), 66 deletions(-)
diff --git a/xen/arch/arm/m
Currently, the MFN will be incremented even if it is invalid. This will
result to have a valid MFN after the first iteration.
While this is not a major problem today, this will be in the future if
the code expect an invalid MFN at every iteration.
Such behavior is prevented by avoiding to increme
With the newly introduced flags, it is now possible to know how the page
will be updated through the flags.
All the use of xenmap_operation are not replaced with the flags. At the
same time, validity check are now removed as they are gathered in
xen_pt_check_entry().
Signed-off-by: Julien Grall
The code handling Xen PT update has quite a few restrictions on what it
can do. This is not a bad thing as it keeps the code simple.
There are already a few checks scattered in current page table handling.
However they are not sufficient as they could still allow to
modify/remove entry with contig
There are few places requiring to generate offsets from an address.
Rather than open-coding everywhere, we can introduce a macro to do the
job for us.
Signed-off-by: Julien Grall
---
xen/arch/arm/p2m.c | 23 +++
xen/include/asm-arm/lpae.h | 9 +
2 files chang
flight 135248 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135248/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134977
version targeted for testi
flight 135252 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135252/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
Andrew Cooper (2):
xen/domain: Block more speculative out-of-bound accesses
xen/arm: Misc improvements to do_common_cpu_on()
xen/arch/arm/vpsci.c | 8 +++-
xen/common/compat/domain.c | 2 +-
2 files changed, 4 insertions(+), 6 deletions(-)
--
2.1.4
__
c/s f8303458 restricted speculative access for do_vcpu_op(), but neglected its
compat counterpart, which is reachable by guests using the 32bit ABI.
Make an identical adjustment.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julie
* Use domain_vcpu() rather than opencoding the lookup. Amongst other things,
domain_vcpu() is spectre-v1-safe.
* Unlock the domain immediately after arch_set_info_guest() completes. There
is no need for free_vcpu_guest_context() to be within the critical region,
and moving the call sim
On 3/22/19 2:29 PM, thibo...@gmail.com wrote:
> From: Ryan Thibodeaux
>
> Add a new command-line option "xen_timer_slop=" that sets the
> minimum delta of virtual Xen timers. This commit does not change the
> default timer slop value for virtual Xen timers.
>
> Lowering the timer slop value should
On 4/6/19 8:29 AM, Hariprasad Kelam wrote:
> Changes passing function argument 0 to NULL to avoid below sparse
> warning
>
> CHECK drivers/xen/xen-pciback/xenbus.c
> drivers/xen/xen-pciback/xenbus.c:700:51: warning: Using plain integer as
> NULL pointer
>
> Signed-off-by: Hariprasad Kelam
Appl
On 4/15/19 5:11 PM, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> This patch fixes the following warning:
>
> drivers/net/xen-netfront.c: In function ‘netback_changed’:
> drivers/net/xen-netfront.c:203
On 4/16/19 12:06 AM, Mao Wenan wrote:
> Drop LIST_HEAD where the variable it declares is never used.
>
> The declarations were introduced with the file, but the declared
> variables were not used.
>
> Fixes: 1107ba885e469("xen: add xenfs to allow usermode <-> Xen interaction")
> Signed-off-by: Mao
On Wednesday 24 April 2019 16:27, Nuernberger, Stefan wrote:
> On Sun, 2019-04-21 at 22:26 +, Mathieu Tarral wrote:
>
> > Hi,
> > I'm having an issue with Xen's VMI subsystem.
> > My goal is to build a small debugger that can break at an
> > application's entrypoint
> > on Windows XP, when a
On Wednesday 24 April 2019 17:38, Tamas K Lengyel
wrote:
> On Wed, Apr 24, 2019 at 9:34 AM Razvan Cojocaru
> rcojoc...@bitdefender.com wrote:
>
> > On 4/24/19 6:25 PM, Tamas K Lengyel wrote:
> >
> > > On Mon, Apr 22, 2019 at 6:00 PM Mathieu Tarral
> > > mathieu.tar...@protonmail.com wrote:
> > >
On 24/04/2019 20:11, Mathieu Tarral wrote:
> On Wednesday 24 April 2019 16:27, Nuernberger, Stefan wrote:
>
>> On Sun, 2019-04-21 at 22:26 +, Mathieu Tarral wrote:
>>
>>> Hi,
>>> I'm having an issue with Xen's VMI subsystem.
>>> My goal is to build a small debugger that can break at an
>>> app
On Wednesday 24 April 2019 17:35, Tamas K Lengyel
wrote:
> On Sun, Apr 21, 2019 at 4:27 PM Mathieu Tarral
> mathieu.tar...@protonmail.com wrote:
>
> > Hi,
> > I'm having an issue with Xen's VMI subsystem.
> > My goal is to build a small debugger that can break at an application's
> > entrypoint
flight 135265 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135265/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134977
version targeted for testi
flight 135267 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135267/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
Hi,
On 4/19/19 7:47 PM, Stefano Stabellini wrote:
On Fri, 29 Mar 2019, Jan Beulich wrote:
On 29.03.19 at 10:41, wrote:
On 28/03/2019 09:55, Jan Beulich wrote:
On 27.03.19 at 19:45, wrote:
Clang uses "-target" option for cross-compilation.
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@
flight 135268 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135268/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 55b53286e669cc27119f5b4323a7e4db2aeae91f
baseline version:
xtf 2dc1902e6756163ceb1f07
> Anyway, i would need to intercept a MOV-TO-DRx to prevent Windows from
> disabling my hardware breakpoints :)
>
> As I understood, this was not exposed by the Xen VMI API yet:
> https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/vm_event.h;h=b2bafc0d77f9758e42b0d53c05a7e6bb86c
> > I'm not entirely sure what you mean here (and perhaps that's a
> > discussion to be moved to the LibVMI issues page). If you already have
> > an event registered for singlestepping why would you want to disable
> > it just to re-enable it? If it's because you just have the handler
> > registere
Hi Artem,
On 4/23/19 2:39 PM, Artem Mygaiev wrote:
Hello Julien, Roger
On Thu, 2019-04-18 at 19:33 +0100, Julien Grall wrote:
(+ Roger)
On 18/04/2019 12:15, Artem Mygaiev wrote:
Hi Julien
On Thu, 2019-04-18 at 11:43 +0100, Julien Grall wrote:
On 18/04/2019 10:15, Artem Mygaiev wrote:
Hell
flight 135106 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135106/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134763
build-i386-pvops
flight 135110 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135110/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 12 guest-start fail REGR. vs. 134885
test-amd64-amd64-lib
flight 135269 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135269/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134977
version targeted for testi
This run is configured for baseline tests only.
flight 84123 xen-4.10-testing real [real]
http://osstest.xensource.com/osstest/logs/84123/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
Hi all,
we are planning to launch the program for the Xen Project Developer Summit the
week of May 6th. In the interest of attracting more attendees it is important
that we have a good program when we launch. The talk submissions have been good
this year, but as 50% of our content are design se
flight 135272 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135272/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
flight 135277 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135277/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
flight 135276 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135276/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134977
version targeted for testi
Hello Julien
On Wed, 2019-04-24 at 22:07 +0100, Julien Grall wrote:
> Hi Artem,
>
> On 4/23/19 2:39 PM, Artem Mygaiev wrote:
> > Hello Julien, Roger
> >
> > On Thu, 2019-04-18 at 19:33 +0100, Julien Grall wrote:
> > > (+ Roger)
> > >
> > > On 18/04/2019 12:15, Artem Mygaiev wrote:
> > > > Hi Ju
flight 135280 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135280/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
flight 135113 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135113/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken in 134634
build-arm64
On Tue, Apr 16, 2019 at 11:05:49AM +0100, Ross Lagerwall wrote:
> On 4/12/19 5:50 AM, Glenn Enright wrote:
> > A recent xsa livepatch failed to generate due to the following
> > message in create-diff-object.log ...
> >
> > /livepatch-build-tools/create-diff-object: ERROR: grant_table.o:
> > kpatc
On Tue, Apr 16, 2019 at 12:57:14PM +, Pawel Wieczorkiewicz wrote:
> This change is part of a independant stacked hotpatch modules
> feature. This feature allows to bypass dependencies between modules
> upon loading, but still verifies Xen build ID matching.
>
> With stacked hotpatch modules it
On Tue, Apr 16, 2019 at 12:22:39PM +, Pawel Wieczorkiewicz wrote:
> When there is no changed function in the generated payload, do not
> create an empty .livepatch.funcs section. Hypervisor code considers
> such payloads as broken and rejects to load them.
>
> Such payloads without any changed
On Tue, Apr 16, 2019 at 12:07:14PM +, Pawel Wieczorkiewicz wrote:
> Hard-coding the special section group sizes is unreliable. Instead,
> determine them dynamically by finding the related struct definitions
> in the DWARF metadata.
>
> This is a livepatch backport of kpatch upstream commit [1]
flight 135135 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135135/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail REGR. vs. 133989
build-i386-lib
flight 135282 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135282/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134977
build-i386-pvops
82 matches
Mail list logo
