>>> On 29.04.19 at 18:47, wrote:
> On 25/04/2019 13:15, Jan Beulich wrote:
> On 22.04.19 at 18:49, wrote:
>>> The pattern _AC(1, UL{,L}) << X is commonly used in the headers to make
>>> define usuable in both assembly and C.
>>>
>>> So introduce _BITUL and _BITULL to make the code slightly mo
A new local variable is introduced for accessing p2m entry with lock protection.
Cc: Stefano Stabellini
Signed-off-by: Hillf Danton
---
--- a/arch/arm/xen/p2m.c2019-04-30 12:32:05.363768200 +0800
+++ b/arch/arm/xen/p2m.c2019-04-30 12:58:19.854334100 +0800
@@ -70,8 +70,9 @@ unsig
Release the newly allocated p2m entry if we detect a duplicate in the RB tree.
Cc: Stefano Stabellini
Signed-off-by: Hillf Danton
---
--- a/arch/arm/xen/p2m.c2019-04-30 12:32:05.363768200 +0800
+++ b/arch/arm/xen/p2m.c2019-04-30 12:41:29.774041800 +0800
@@ -156,6 +156,7 @@ bool
When testing with an UP guest with a pass-thru device with vt-d pi
enabled in host, we observed that guest couldn't receive interrupts
from that pass-thru device. Dumping IRTE, we found the corresponding
IRTE is set to posted format with "vector" field as 0.
We would fall into this issue when gues
Commit f089fddd94 "xen: report PV capability in sysctl and use it in
toolstack" changed meaning of virt_caps bit 1 - previously it was
"directio", but was changed to "pv" and "directio" was moved to bit 2.
Adjust python wrapper to use #defines for the bits values, and add
reporting of both "pv_dire
On Tue, Apr 30, 2019 at 12:08:38AM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Apr 29, 2019 at 11:16:26AM +0100, Ian Jackson wrote:
> > Marek Marczykowski-Górecki writes ("[PATCH] python: Adjust xc_physinfo
> > wrapper for updated virt_caps bits"):
> > > Commit f089fddd94 "xen: report PV ca
On Mon, Apr 29, 2019 at 11:16:26AM +0100, Ian Jackson wrote:
> Marek Marczykowski-Górecki writes ("[PATCH] python: Adjust xc_physinfo
> wrapper for updated virt_caps bits"):
> > Commit f089fddd94 "xen: report PV capability in sysctl and use it in
> > toolstack" changed meaning of virt_caps bit 1 -
On 30/04/19 2:14 AM, Ross Lagerwall wrote:
> On 4/25/19 5:53 AM, Konrad Rzeszutek Wilk wrote:
>> 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
> On 29. Apr 2019, at 17:14, Ross Lagerwall wrote:
>
> On 4/16/19 1:07 PM, Pawel Wieczorkiewicz wrote:
>> This function checks if given section has an included corresponding
>> RELA section and/or any of the symbols table symbols references the
>> section. Section associated symbols are ignored
flight 135413 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135413/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 133846
test-armhf-armhf-libvirt-raw 13 saveresto
> On 29. Apr 2019, at 15:53, Ross Lagerwall wrote:
>
> On 4/8/19 9:32 AM, Pawel Wieczorkiewicz wrote:
>> Up to now the livepatch-build ignores newly created object files.
>> When patch applies new .c file and augments its Makefile to build it
>> the resulting object file is not taken into accoun
> On 29. Apr 2019, at 16:21, Ross Lagerwall wrote:
>
> On 4/29/19 3:10 PM, Ross Lagerwall wrote:
>> On 4/16/19 1:07 PM, Pawel Wieczorkiewicz wrote:
>>> Hard-coding the special section group sizes is unreliable. Instead,
>>> determine them dynamically by finding the related struct definitions
>>>
> On 29. Apr 2019, at 14:40, Ross Lagerwall wrote:
>
> On 4/8/19 9:32 AM, Pawel Wieczorkiewicz wrote:
>> In some build systems symlinks might be used for patch file names
>> to point from target directories to actual patches. Following those
>> symlinks breaks naming convention as the resulting
> On 29. Apr 2019, at 16:37, Ross Lagerwall wrote:
>
> On 4/25/19 5:51 AM, Konrad Rzeszutek Wilk wrote:
>> 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. Hy
On Mon, 29 Apr 2019, Jan Beulich wrote:
> >>> On 29.04.19 at 17:54, wrote:
> > Anyway, I also tested the change suggested by Stefano. This will
> > substantially
> > increase the size of the frametable on platform where the RAM does not
> > start
> > at 0.
> >
> > For instance, on Foundation
Hi,
On 25/04/2019 13:15, Jan Beulich wrote:
On 22.04.19 at 18:49, wrote:
The pattern _AC(1, UL{,L}) << X is commonly used in the headers to make
define usuable in both assembly and C.
So introduce _BITUL and _BITULL to make the code slightly more readable.
I don't particularly like the name
On 4/29/19 4:18 PM, Jan Beulich wrote:
On 26.04.19 at 19:21, wrote:
>> Patch cf4b30dca0a "Add debug code to detect illegal page_lock and
>> put_page_type
>> ordering" added extra sanity checking to page_lock/page_unlock for debug
>> builds
>> with the assumption that no hypervisor path ever
On Mon, Apr 29, 2019 at 10:29 AM George Dunlap wrote:
>
> On 4/29/19 5:26 PM, Tamas K Lengyel wrote:
> > On Mon, Apr 29, 2019 at 10:14 AM Jan Beulich wrote:
> >>
> > On 29.04.19 at 18:05, wrote:
> >>> On Mon, Apr 29, 2019 at 9:52 AM George Dunlap
> >>> wrote:
> I haven't re-grokked th
On Mon, Apr 29, 2019 at 9:18 AM Jan Beulich wrote:
>
> >>> On 26.04.19 at 19:21, wrote:
> > Patch cf4b30dca0a "Add debug code to detect illegal page_lock and
> > put_page_type
> > ordering" added extra sanity checking to page_lock/page_unlock for debug
> > builds
> > with the assumption that no
Hi Jan,
On 25/04/2019 12:20, Jan Beulich wrote:
On 17.04.19 at 19:07, wrote:
Anyway, it is not the first time I see build error when trying to make the code
using
typesafe gfn/mfn. The headers dependency are quite messy in general.
Because of this, ...
Andrew, Jan do you have a suggestion
On 4/29/19 5:26 PM, Tamas K Lengyel wrote:
> On Mon, Apr 29, 2019 at 10:14 AM Jan Beulich wrote:
>>
> On 29.04.19 at 18:05, wrote:
>>> On Mon, Apr 29, 2019 at 9:52 AM George Dunlap
>>> wrote:
I haven't re-grokked the code here, but assuming I was correct 2 weeks
ago, if you have t
On Mon, Apr 29, 2019 at 10:14 AM Jan Beulich wrote:
>
> >>> On 29.04.19 at 18:05, wrote:
> > On Mon, Apr 29, 2019 at 9:52 AM George Dunlap
> > wrote:
> >> I haven't re-grokked the code here, but assuming I was correct 2 weeks
> >> ago, if you have the BUG_ON() there, you can get rid of the extr
On 4/29/19 5:14 PM, Jan Beulich wrote:
On 29.04.19 at 18:05, wrote:
>> On Mon, Apr 29, 2019 at 9:52 AM George Dunlap
>> wrote:
>>> I haven't re-grokked the code here, but assuming I was correct 2 weeks
>>> ago, if you have the BUG_ON() there, you can get rid of the extra
>>> references.
>>
The posted version of this patch depends on c/s 3c555295 "x86/vpmu: Improve
documentation and parsing for vpmu=" (Xen 4.12 and later) to prevent
`vpmu=rtm-abort` impliying `vpmu=1`, which is outside of security support.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
xen/arch/x86/cpu/vpmu.c |
These were missed as a consequence of being rebased over other cmdline
cleanup.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
xen/arch/x86/dom0_build.c | 4 ++--
xen/arch/x86/hvm/vmx/vmcs.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/dom0_build.c
Patch 1 is applicable to Xen 4.10 and 4.11
Patch 2 is applicable to just Xen 4.11
Andrew Cooper (2):
xen: Fix backport of "xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s)
construct"
xen: Fix backport of "x86/tsx: Implement controls for RTM force-aborte mode"
xen/arch/x86/cpu/vpmu.c |
>>> On 29.04.19 at 18:05, wrote:
> On Mon, Apr 29, 2019 at 9:52 AM George Dunlap
> wrote:
>> I haven't re-grokked the code here, but assuming I was correct 2 weeks
>> ago, if you have the BUG_ON() there, you can get rid of the extra
>> references.
>
> Sure, but again, the overhead of having the
On 4/16/19 1:07 PM, Pawel Wieczorkiewicz wrote:
Starting with the "2af6f1aa6233 Fix patch creation with GCC 6.1+" commit
all .rodata sections are included by default (regardless of whether they
are needed or not).
During stacked hotpatch builds it leads to unnecessary duplication of
the .rodata s
>>> On 29.04.19 at 17:54, wrote:
> Anyway, I also tested the change suggested by Stefano. This will
> substantially
> increase the size of the frametable on platform where the RAM does not start
> at 0.
>
> For instance, on Foundation Model the RAM starts at 2GB. As we don't compress
> any of
On Mon, Apr 29, 2019 at 9:52 AM George Dunlap wrote:
>
> On 4/29/19 4:41 PM, Tamas K Lengyel wrote:
> > On Mon, Apr 29, 2019 at 9:01 AM Jan Beulich wrote:
> >>
> > On 26.04.19 at 19:21, wrote:
> >>> @@ -999,6 +996,10 @@ static int share_pages(struct domain *sd, gfn_t
> >>> sgfn, shr_handle_
On Mon, Apr 29, 2019 at 9:44 AM George Dunlap wrote:
>
> On 4/26/19 6:21 PM, Tamas K Lengyel wrote:
> > Calling _put_page_type while also holding the page_lock
> > for that page can cause a deadlock.
>
> I can't immediately see what the mem_sharing_page_[un]lock() functions
> are meant to be prote
Hi,
On 29/04/2019 08:15, Jan Beulich wrote:
On 27.04.19 at 01:47, wrote:
The other change to nr_pdxs is less obvious. It is clear that nr_pdxs is
calculated wrongly in this case (memory 0-0x8000,
0x8-0x88000, ps=0, pe=0x88000): nr_pdxs=524288 which is
half the number we nee
On 4/29/19 4:41 PM, Tamas K Lengyel wrote:
> On Mon, Apr 29, 2019 at 9:01 AM Jan Beulich wrote:
>>
> On 26.04.19 at 19:21, wrote:
>>> @@ -999,6 +996,10 @@ static int share_pages(struct domain *sd, gfn_t sgfn,
>>> shr_handle_t sh,
>>> mem_sharing_page_unlock(secondpg);
>>> mem_shari
On Mon, Apr 29, 2019 at 9:32 AM Jan Beulich wrote:
>
> >>> On 26.04.19 at 19:21, wrote:
> > --- a/xen/arch/x86/Kconfig
> > +++ b/xen/arch/x86/Kconfig
> > @@ -17,7 +17,6 @@ config X86
> > select HAS_KEXEC
> > select MEM_ACCESS_ALWAYS_ON
> > select HAS_MEM_PAGING
> > - select
On 4/16/19 1:07 PM, Pawel Wieczorkiewicz wrote:
Handle .livepatch.hooks* and .altinstr_replacement sections as the
special sections with assigned group_size resolution function.
By default each .livepatch.hooks* sections' entry is 8 bytes long (a
pointer). The .altinstr_replacement section follow
On 4/26/19 6:21 PM, Tamas K Lengyel wrote:
> Calling _put_page_type while also holding the page_lock
> for that page can cause a deadlock.
I can't immediately see what the mem_sharing_page_[un]lock() functions
are meant to be protecting against. Is there a comment anywhere
describing what they're
On Mon, Apr 29, 2019 at 9:01 AM Jan Beulich wrote:
>
> >>> On 26.04.19 at 19:21, wrote:
> > @@ -999,6 +996,10 @@ static int share_pages(struct domain *sd, gfn_t sgfn,
> > shr_handle_t sh,
> > mem_sharing_page_unlock(secondpg);
> > mem_sharing_page_unlock(firstpg);
> >
> > +BUG_ON(!
The flag being set may prevent affinity changes, as these often imply
assignment of a new vector. When there's no possible destination left
for the IRQ, the clearing of the flag needs to happen right from
fixup_irqs().
Additionally _assign_irq_vector() needs to avoid setting the flag when
there's
On Mon, Apr 29, 2019 at 8:54 AM George Dunlap wrote:
>
> On 4/29/19 3:49 PM, Andrew Cooper wrote:
> > On 29/04/2019 15:46, George Dunlap wrote:
> >> On 4/29/19 3:32 PM, George Dunlap wrote:
> >>> On 4/26/19 6:21 PM, Tamas K Lengyel wrote:
> Calling _put_page_type while also holding the page_l
On Mon, Apr 29, 2019 at 08:08:33AM -0700, John L. Poole wrote:
>
> On 4/29/2019 5:02 AM, Roger Pau Monné wrote:
> > On Tue, Apr 16, 2019 at 09:23:11AM -0700, John L. Poole wrote:
> > > On 3/27/2019 7:21 AM, Jan Beulich wrote:
> > > > > > > On 27.03.19 at 14:25, wrote:
> > > > > On 3/27/2019 1:14
On Mon, Apr 29, 2019 at 8:57 AM Jan Beulich wrote:
>
> >>> On 26.04.19 at 19:21, wrote:
> > --- a/xen/include/asm-x86/mem_sharing.h
> > +++ b/xen/include/asm-x86/mem_sharing.h
> > @@ -25,7 +25,9 @@
> > #include
> >
> > /* Auditing of memory sharing code? */
> > +#ifndef NDEBUG
> > #define MEM
>>> On 26.04.19 at 19:21, wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -17,7 +17,6 @@ config X86
> select HAS_KEXEC
> select MEM_ACCESS_ALWAYS_ON
> select HAS_MEM_PAGING
> - select HAS_MEM_SHARING
> select HAS_NS16550
> select HAS_PASSTHRO
Ian Jackson writes ("[PATCH STABLE] tools/firmware: update OVMF Makefile, when
necessary"):
> On advice from Wei, I am about to push this squashed backport to the
> stable trees. We think this will help fix osstest on those branches
> following the upgrade to Debian stretch.
Now done, including
On advice from Wei, I am about to push this squashed backport to the
stable trees. We think this will help fix osstest on those branches
following the upgrade to Debian stretch.
Ian.
From e983e8ae84efd5e43045a3d20a820f13cb4a75bf Mon Sep 17 00:00:00 2001
From: Wei Liu
Date: Wed, 28 Nov 2018 17:4
On 4/16/19 1:07 PM, Pawel Wieczorkiewicz wrote:
This function determines, based on the given section name, if the
sections belongs to the special sections category.
It treats a name from the special_sections array as a prefix. Any
sections whose name starts with special section prefix is consider
>>> On 26.04.19 at 19:21, wrote:
> Patch cf4b30dca0a "Add debug code to detect illegal page_lock and
> put_page_type
> ordering" added extra sanity checking to page_lock/page_unlock for debug
> builds
> with the assumption that no hypervisor path ever locks two pages at once.
>
> This assumptio
On 4/16/19 1:07 PM, Pawel Wieczorkiewicz wrote:
This function checks if given section has an included corresponding
RELA section and/or any of the symbols table symbols references the
section. Section associated symbols are ignored here as there is
always such a symbol for every section.
Signed-
Julien Grall writes ("Re: [OSSTEST PATCH 11/15] cross builds: ts-kernel-build:
Support cross target armhf"):
> On 4/26/19 10:23 PM, Julien Grall wrote:
> > NIT: HOSTCC is not necessary. It will be default to gcc if not passed.
I will drop it.
> > Otherwise, the export looks write to me.
Thanks
On 4/29/2019 5:02 AM, Roger Pau Monné wrote:
On Tue, Apr 16, 2019 at 09:23:11AM -0700, John L. Poole wrote:
On 3/27/2019 7:21 AM, Jan Beulich wrote:
On 27.03.19 at 14:25, wrote:
On 3/27/2019 1:14 AM, Jan Beulich wrote:
On 26.03.19 at 18:21, wrote:
zeta /usr/local/src/xen # cat xen/.config
Julien Grall writes ("Re: [OSSTEST PATCH 14/15] cross builds: Build armhf
kernels on amd64 hosts"):
> On 4/26/19 5:40 PM, Ian Jackson wrote:
> > Our armhf hosts are devboards and very slow, as well as scarce. It
> > 5takes 17ks or so for a kernel build. This will go *much* faster on
>
> NIT: s/
On 4/16/19 1:07 PM, Pawel Wieczorkiewicz wrote:
Detect standard (always to be included) sections via their section
header type. The standard sections: ".shstrtab", ".symtab", ".strtab"
are either of type SHT_SYMTAB or SHT_STRTAB.
Signed-off-by: Pawel Wieczorkiewicz
Reviewed-by: Andra-Irina Para
>>> On 26.04.19 at 19:21, wrote:
> @@ -999,6 +996,10 @@ static int share_pages(struct domain *sd, gfn_t sgfn,
> shr_handle_t sh,
> mem_sharing_page_unlock(secondpg);
> mem_sharing_page_unlock(firstpg);
>
> +BUG_ON(!put_count);
> +while ( put_count-- )
> +put_page_and_t
On 29/04/2019 15:46, George Dunlap wrote:
> On 4/29/19 3:32 PM, George Dunlap wrote:
>> On 4/26/19 6:21 PM, Tamas K Lengyel wrote:
>>> Calling _put_page_type while also holding the page_lock
>>> for that page can cause a deadlock.
>>>
>>> Signed-off-by: Tamas K Lengyel
>>> Cc: Jan Beulich
>>> Cc:
>>> On 26.04.19 at 19:21, wrote:
> --- a/xen/include/asm-x86/mem_sharing.h
> +++ b/xen/include/asm-x86/mem_sharing.h
> @@ -25,7 +25,9 @@
> #include
>
> /* Auditing of memory sharing code? */
> +#ifndef NDEBUG
> #define MEM_SHARING_AUDIT 1
> +#endif
Since consumers use #if (not #ifdef), I th
On 4/29/19 3:49 PM, Andrew Cooper wrote:
> On 29/04/2019 15:46, George Dunlap wrote:
>> On 4/29/19 3:32 PM, George Dunlap wrote:
>>> On 4/26/19 6:21 PM, Tamas K Lengyel wrote:
Calling _put_page_type while also holding the page_lock
for that page can cause a deadlock.
Signed-off-
>>> On 23.04.19 at 16:30, wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -478,6 +478,43 @@ void p2m_unlock_and_tlb_flush(struct p2m_domain *p2m)
> mm_write_unlock(&p2m->lock);
> }
>
> +int altp2m_get_effective_entry(struct p2m_domain *ap2m, gfn_t gfn, mfn_t
>
On 4/29/19 3:32 PM, George Dunlap wrote:
> On 4/26/19 6:21 PM, Tamas K Lengyel wrote:
>> Calling _put_page_type while also holding the page_lock
>> for that page can cause a deadlock.
>>
>> Signed-off-by: Tamas K Lengyel
>> Cc: Jan Beulich
>> Cc: Andrew Cooper
>> Cc: George Dunlap
>> Cc: Wei Li
Julien Grall writes ("Re: [OSSTEST PATCH 00/21] Abandon jobs which are
unreasonably delaying their flight"):
> As we discussed on IRC, I understand this will have an impact on Arm32
> testing. Do you have an estimate how likely the tests will be skipped?
Many, maybe most. Very likely the smoke
On 4/25/19 5:51 AM, Konrad Rzeszutek Wilk wrote:
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 loa
On 4/26/19 6:21 PM, Tamas K Lengyel wrote:
> Calling _put_page_type while also holding the page_lock
> for that page can cause a deadlock.
>
> Signed-off-by: Tamas K Lengyel
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Wei Liu
> Cc: Roger Pau Monne
> ---
> v3: simplified p
Hi Oleksandr,
On 17/04/2019 15:59, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch makes possible to use existing early prink code
for Renesas "Stout" board based on R-Car H2 SoC (SCIFA).
The "EARLY_PRINTK_VERSION" for that board should be 'A':
CONFIG_EARLY_PRINTK=scif,0xe6c
Hi Oleksandr,
On 17/04/2019 15:59, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Extend early prink code to be able to handle other SCIF(X)
compatible interfaces as well. These interfaces have lot in common,
but mostly differ in offsets and bits for some registers.
Introduce "EARLY_P
On 4/29/19 3:10 PM, Ross Lagerwall wrote:
On 4/16/19 1:07 PM, 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 upstre
Hi Oleksandr,
On 17/04/2019 15:59, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
For the driver to be able to handle SCIFA interface as well,
this patch just adds the following:
- SCIFA related macros
- New element in "port_params" array to keep SCIFA specific things
- SCIFA compatibl
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.
In order to prevent (up)loading any hotpatches built for different
hypervisor version as indicated by the Xen Bu
On 4/25/19 5:53 AM, Konrad Rzeszutek Wilk wrote:
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 livepa
On 4/16/19 1:07 PM, 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]:
kpatch-build: detect special
>>> On 29.04.19 at 13:22, wrote:
> RFC: I've seen the new ASSERT() in irq_move_cleanup_interrupt() trigger.
> I'm pretty sure that this assertion triggering means something else
> is wrong, and has been even prior to this change (adding the
> assertion without any of the other chang
On 4/8/19 9:32 AM, Pawel Wieczorkiewicz wrote:
Up to now the livepatch-build ignores newly created object files.
When patch applies new .c file and augments its Makefile to build it
the resulting object file is not taken into account for final linking
step.
Such newly created object files can be
On 4/29/19 1:53 PM, Andrew Cooper wrote:
On 08/04/2019 09:32, Pawel Wieczorkiewicz wrote:
Up to now the livepatch-build ignores newly created object files.
When patch applies new .c file and augments its Makefile to build it
the resulting object file is not taken into account for final linking
s
flight 135407 ovmf running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135407/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt queued
test-amd64-amd64-xl-qemuu-ov
flight 135378 linux-4.9 running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135378/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm broken
build-amd64-pvops
flight 135396 linux-4.4 running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135396/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm broken
build-arm64
flight 135400 xen-4.8-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135400/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386 broken
build-i386-xsm
flight 135373 xen-4.12-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135373/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm broken
build-arm64
flight 135402 linux-next running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135402/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm broken
build-amd64-xsm
>>> On 29.04.19 at 14:55, wrote:
On 29.04.19 at 13:22, wrote:
>> RFC: I've seen the new ASSERT() in irq_move_cleanup_interrupt() trigger.
>> I'm pretty sure that this assertion triggering means something else
>> is wrong, and has been even prior to this change (adding the
>> a
flight 135374 xen-unstable running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135374/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64
Hi Oleksandr,
On 17/04/2019 15:59, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Extend driver to be able to handle other SCIF(X) compatible
interfaces as well. These interfaces have lot in common,
but mostly differ in offsets and bits for some registers.
For example, the main differ
flight 135386 linux-4.14 running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135386/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm broken
build-arm64-xsm
flight 135397 xen-4.9-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135397/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-i386-pre
On 08/04/2019 09:32, Pawel Wieczorkiewicz wrote:
> Up to now the livepatch-build ignores newly created object files.
> When patch applies new .c file and augments its Makefile to build it
> the resulting object file is not taken into account for final linking
> step.
>
> Such newly created object f
flight 135399 linux-linus running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135399/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
On 4/8/19 9:32 AM, Pawel Wieczorkiewicz wrote:
In some build systems symlinks might be used for patch file names
to point from target directories to actual patches. Following those
symlinks breaks naming convention as the resulting built modules
would be named after the actual hardlink insteads o
On 4/8/19 9:32 AM, Pawel Wieczorkiewicz wrote:
Do not copy over the built_in.o and prelink.o object files when they
get rebuilt as they are used for transient linking by Xen's build
system.
Signed-off-by: Pawel Wieczorkiewicz
Reviewed-by: Martin Pohlack
Reviewed-by: Petre Eftime
Reviewed-by
On 4/8/19 9:32 AM, Pawel Wieczorkiewicz wrote:
Xen build system may enforce particular gcc version (e.g. gcc72).
Make sure the livepatch-gcc script accepts all input toolchain gcc
commands with or without version specified.
Signed-off-by: Pawel Wieczorkiewicz
Reviewed-by: Martin Mazein
Reviewe
flight 135395 linux-4.19 running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135395/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops broken
build-amd64-pvops
flight 135383 qemu-upstream-4.10-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135383/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386 broken
bui
On Tue, Apr 16, 2019 at 09:23:11AM -0700, John L. Poole wrote:
>
> On 3/27/2019 7:21 AM, Jan Beulich wrote:
> > > > > On 27.03.19 at 14:25, wrote:
> > > On 3/27/2019 1:14 AM, Jan Beulich wrote:
> > > > > > > On 26.03.19 at 18:21, wrote:
> > > > > zeta /usr/local/src/xen # cat xen/.config |grep C
flight 135398 qemu-upstream-4.11-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135398/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
bui
flight 135377 linux-3.18 running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135377/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops broken
build-arm64-xsm
On 29/04/2019 12:25, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 29/04/2019 12:27, Jan Beulich wrote:
> Must be a left-over from earlier days.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
flight 135401 qemu-upstream-4.12-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135401/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
bui
flight 135384 libvirt running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135384/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-i386
flight 135409 qemu-mainline running [real]
http://logs.test-lab.xenproject.org/osstest/logs/135409/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 queued
test-amd64-i
Since the "Cannot set affinity ..." warning is a one time one, avoid
triggering it already at boot time when parking secondary threads and
the serial console uses a (still unconnected at that time) PCI IRQ.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -2412,8 +
Don't log a stray trailing comma. Shorten a few fields.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -2318,7 +2318,7 @@ static void dump_irqs(unsigned char key)
spin_lock_irqsave(&desc->lock, flags);
-printk(" IRQ:%4d affinity:%*pb vec:%0
All of __{assign,bind,clear}_irq_vector() manipulate struct irq_desc
fields, and hence ought to be called with the descriptor lock held in
addition to vector_lock. This is currently the case for only
set_desc_affinity() and destroy_irq(), which also clarifies what the
nesting behavior between the l
The flag being set may prevent affinity changes, as these often imply
assignment of a new vector. When there's no possible destination left
for the IRQ, the clearing of the flag needs to happen right from
fixup_irqs().
Additionally _assign_irq_vector() needs to avoid setting the flag when
there's
1 - 100 of 120 matches
Mail list logo
