flight 134903 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134903/
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
This run is configured for baseline tests only.
flight 84003 ovmf real [real]
http://osstest.xensource.com/osstest/logs/84003/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
flight 134889 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134889/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0eccea3fbe2f6d4999d972d9310d4f2717f5100c
baseline version:
ovmf e0fd9ece26c9b84a1a756
From: "Gustavo A. R. Silva"
Date: Mon, 15 Apr 2019 16:11:41 -0500
> 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
flight 134891 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134891/
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 134745 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134745/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 6 kernel-build fail REGR. vs. 133909
build-i386
flight 134882 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134882/
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 134874 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134874/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134640
version targeted for testi
On Fri, 29 Mar 2019, Julien Grall wrote:
> On 28/03/2019 11:27, Artem Mygaiev wrote:
> > Hi Julien,
>
> Hi Artem,
>
> > On Wed, 2019-03-27 at 18:45 +, Julien Grall wrote:
> > > Hi all,
> > >
> > > This series adds support to build Xen Arm with clang. This series was
> > > tested
> > > with c
On Mon, 8 Apr 2019, Julien Grall wrote:
> Hi,
>
> On 3/15/19 11:57 PM, Feng Kan OS wrote:
> > Thanks Julien.
> >
> > On 3/15/19 4:21 AM, Julien Grall wrote:
> > > Hi,
> > >
> > > Thank you for posting the patch.
> > >
> > > Title: No need for full stop in the commit title.
> > >
> > > On 15/03
On Tue, 16 Apr 2019, Andrew Cooper wrote:
> From the log:
>
> traps: modprobe[48] trap invalid opcode ip:7f797dc7bb95 sp:7ffe3099cdb8 erro
> r:0 in ld-2.29.so[7f797dc61000+21000]
>
>
> Can you disassemble ld-2.29.so and find out what that instruction is? It is
> almost certainly a related fact
Hi Stefano,
On 4/16/19 10:51 PM, Stefano Stabellini wrote:
On Mon, 28 Jan 2019, Julien Grall wrote:
While SPIs are shared between CPU, it is not possible to receive the
same interrupts on a different CPU while the interrupt is in active
state. The deactivation of the interrupt is done at the en
flight 134749 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134749/
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. 133580
build-armhf-pvops
On Mon, 28 Jan 2019, Julien Grall wrote:
> While SPIs are shared between CPU, it is not possible to receive the
> same interrupts on a different CPU while the interrupt is in active
> state. The deactivation of the interrupt is done at the end of the
> handling.
>
> This means the _IRQ_PENDING log
On Tue, 19 Mar 2019, Julien Grall wrote:
> The format %pd will already prefix the domain ID with 'd'. So avoid to
> prefix with 'Dom'.
>
> Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
> ---
> xen/arch/arm/kernel.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -
On Tue, 19 Mar 2019, Julien Grall wrote:
> From: Julien Grall
>
> We can optimize a bit the assembly code by combining the 2 instructions
> in a single one. This likely not going to make the code faster, but
> likely make easier to read the assembly.
>
> Signed-off-by: Julien Grall
Reviewed-by
On Tue, 2 Apr 2019, Julien Grall wrote:
> 2 paths in the domU console handling are now the same. So they can be
> merged to make the code simpler.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> xen/drivers/char/console.c | 9 ++---
> 1 file changed, 2 insertions(
On Tue, 2 Apr 2019, Julien Grall wrote:
> Currently, OS developpers will have to look at Xen code in order to know
> the parameters of an hypercall and how it is meant to work.
>
> This is not a trivial task as you may need to have a deep understanding
> of Xen internal.
>
> This patch attempts t
On Tue, 2 Apr 2019, Julien Grall wrote:
> After upgrading Debian to Buster, I have began to notice console
> mangling when using zsh in Dom0. This is happenning because output sent by
> zsh to the console may contain NULs in the middle of the buffer.
>
> The actual implementation of CONSOLEIO_writ
flight 134869 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134869/
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
At 13:32 +0100 on 08 Apr (1554730320), Andrew Cooper wrote:
> On 08/04/2019 13:11, Jan Beulich wrote:
> On 08.04.19 at 13:37, wrote:
> >> On 08/04/2019 11:14, Jan Beulich wrote:
> >> On 05.04.19 at 21:09, wrote:
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/sha
On Mon, 1 Apr 2019, Julien Grall wrote:
> Hi,
>
> On 4/1/19 10:40 AM, Juergen Gross wrote:
> > On 01/04/2019 11:21, Julien Grall wrote:
> > > Hi,
> > >
> > > On 3/29/19 3:08 PM, Juergen Gross wrote:
> > > > cpu_disable_scheduler() is being called from __cpu_disable() today.
> > > > There is no ne
On Mon, 1 Apr 2019, Ian Jackson wrote:
> CC: Lars Kurth
> CC: Juergen Gross
> Signed-off-by: Ian Jackson
> ---
> SUPPORT.md | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 19fc8d7533..d4173d70ad 100644
> --- a/SUPPORT.md
> +++ b/
On 4/16/19, Roger Pau Monné wrote:
> On Mon, Apr 15, 2019 at 04:18:57PM -0700, Pry Mar wrote:
>> Hello,
>>
>> https://paste.debian.net/1077718/
>>
>> I get a kernel panic as shown in the paste above no matter how I
>> launch pvh, with bootloader (pygrub), kernel direct (4.18+), or
>> pvgrub2 (i386
flight 134743 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134743/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken in 134615
build-arm64
flight 134865 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134865/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134640
version targeted for testi
flight 134735 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134735/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 130965
build-i386-prev
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm
testid guest-saverestore
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keyco
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 CONFIG_HVM
# CONFIG_HVM is not set
zeta /usr/local/src/xen #
# tried 2 boot attempts
log at: https://p
flight 134863 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134863/
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/16/19 10:49 AM, Yue Haibing wrote:
> From: YueHaibing
>
> Fix sparse warnings:
>
> drivers/xen/swiotlb-xen.c:489:1: warning:
> symbol 'xen_swiotlb_sync_single_for_cpu' was not declared. Should it be
> static?
> drivers/xen/swiotlb-xen.c:496:1: warning:
> symbol 'xen_swiotlb_sync_single_for
On 4/16/19 3:19 PM, Tamas K Lengyel wrote:
> On Tue, Apr 16, 2019 at 8:02 AM George Dunlap
> wrote:
>>
>> On 4/16/19 2:44 PM, Tamas K Lengyel wrote:
>>> On Tue, Apr 16, 2019 at 2:45 AM Alexandru Stefan ISAILA
>>> wrote:
The code for getting the entry and then populating was repeated in
On 4/16/19 2:17 AM, Juergen Gross wrote:
> On 15/04/2019 23:11, 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
From: YueHaibing
Fix sparse warnings:
drivers/xen/swiotlb-xen.c:489:1: warning:
symbol 'xen_swiotlb_sync_single_for_cpu' was not declared. Should it be static?
drivers/xen/swiotlb-xen.c:496:1: warning:
symbol 'xen_swiotlb_sync_single_for_device' was not declared. Should it be
static?
Reporte
On Tue, Apr 16, 2019 at 7:58 AM George Dunlap wrote:
>
> On 4/16/19 2:51 PM, Andrew Cooper wrote:
> > On 16/04/2019 14:44, Tamas K Lengyel wrote:
> >>
> >>> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> >>> index 2801a8ccca..8dc4353645 100644
> >>> --- a/xen/include/asm-x86/
On Tue, Apr 16, 2019 at 8:02 AM George Dunlap wrote:
>
> On 4/16/19 2:44 PM, Tamas K Lengyel wrote:
> > On Tue, Apr 16, 2019 at 2:45 AM Alexandru Stefan ISAILA
> > wrote:
> >>
> >> The code for getting the entry and then populating was repeated in
> >> p2m_change_altp2m_gfn() and in p2m_set_altp2
On 4/16/19 2:44 PM, Tamas K Lengyel wrote:
> On Tue, Apr 16, 2019 at 2:45 AM Alexandru Stefan ISAILA
> wrote:
>>
>> The code for getting the entry and then populating was repeated in
>> p2m_change_altp2m_gfn() and in p2m_set_altp2m_mem_access().
>>
>> The code is now in one place with a bool param
On 4/16/19 2:51 PM, Andrew Cooper wrote:
> On 16/04/2019 14:44, Tamas K Lengyel wrote:
>>
>>> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
>>> index 2801a8ccca..8dc4353645 100644
>>> --- a/xen/include/asm-x86/p2m.h
>>> +++ b/xen/include/asm-x86/p2m.h
>>> @@ -514,6 +514,23 @@ s
On 16/04/2019 14:44, Tamas K Lengyel wrote:
>
>> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
>> index 2801a8ccca..8dc4353645 100644
>> --- a/xen/include/asm-x86/p2m.h
>> +++ b/xen/include/asm-x86/p2m.h
>> @@ -514,6 +514,23 @@ static inline unsigned long mfn_to_gfn(struct doma
On Tue, Apr 16, 2019 at 2:45 AM Alexandru Stefan ISAILA
wrote:
>
> The code for getting the entry and then populating was repeated in
> p2m_change_altp2m_gfn() and in p2m_set_altp2m_mem_access().
>
> The code is now in one place with a bool param that lets the caller choose
> if it populates after
> Oh wait, I don't think there is anything to fix there. Those sentences
> look repetitive but they do say different things: in tools case, it says
> "repos will be cloned"; in stubdom case, it says "external packages
> will be downloaded. So they do reflect correctly what will happen.
>
Let me na
On Mon, 15 Apr 2019 at 17:24, Wei Liu wrote:
>
> On Sat, Apr 13, 2019 at 11:17:48AM +0800, Kevin Buckley wrote:
> > On Thu, 11 Apr 2019 at 18:29, Wei Liu wrote:
> > >
> > > ...
> > > Sure. I will write a patch.
> > >
> > > Wei.
> >
> > Couple of other things I noticed after posting the original o
On 16.04.19 12:11, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 4/15/19 12:30 PM, Oleksandr wrote:
On 14.04.19 19:55, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 4/8/19 11:14 AM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Extend driver to be able to handle othe
On 16/04/2019 00:18, Pry Mar wrote:
> Hello,
>
> https://paste.debian.net/1077718/
>
> I get a kernel panic as shown in the paste above no matter how I
> launch pvh, with bootloader (pygrub), kernel direct (4.18+), or
> pvgrub2 (i386-xen_pvh support).
>From the log:
> traps: modprobe[48] trap inva
flight 134854 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134854/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134640
version targeted for testi
Extend the list of xc() object methods with additional one to display
Xen's buildid. The implementation follows the libxl implementation
(e.g. max buildid size assumption being XC_PAGE_SIZE).
Signed-off-by: Pawel Wieczorkiewicz
Reviewed-by: Martin Mazein
Reviewed-by: Andra-Irina Paraschiv
Revie
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 is essential that each and every
hotpatch is verified against the hypervisor bu
By default Livepatch enforces the following buildid-based dependency
chain between hotpatch modules:
1) first module depends on given hypervisor buildid
2) every consecutive module depends on previous module's buildid
This way proper hotpatch stack order is maintained and enforced.
While it is
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
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 functions may appear when only
hooks are specified.
Signed-off-by: Pawel Wiecz
The patched ELF object file contains all sections and symbols as
resulted from the compilation. However, certain symbols may not be
copied over to the resulting object file, due to being unchanged or
not included for other reasons.
In such situation the resulting object file has the entire sections
During verification check if all sections do not contain any entries
with undefined symbols (STN_UNDEF). This situation can happen when a
section is copied over from its original object to a patched object,
but various symbols related to the section are not copied along.
This scenario happens typic
flight 134858 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134858/
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
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-off-by: Pawel Wieczorkiewicz
Reviewed-by: Andra-I
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 considered
a special section.
Signed-off-by: Pawel Wieczo
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 follows the .altinstructions
section settings.
Allow to
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 section group sizes 170449847136a48b19fc
Xen onl
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 Paraschiv
Reviewed-by: Bjoern Doebel
Reviewed-by: No
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 sections as each and every consecutive hotpatch con
Convert to use vm_map_pages() to map range of kernel memory
to user vma.
vm_pgoff is treated in V4L2 API as a 'cookie' to select a buffer,
not as a in-buffer offset by design and it always want to mmap a
whole buffer from its beginning.
Signed-off-by: Souptick Joarder
Suggested-by: Marek Szyprow
Convert to use vm_map_pages_zero() to map range of kernel memory
to user vma.
This driver has ignored vm_pgoff and mapped the entire pages. We
could later "fix" these drivers to behave according to the normal
vm_pgoff offsetting simply by removing the _zero suffix on the
function name and if that
Convert to use vm_map_pages() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
---
drivers/iommu/dma-iommu.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index d19f3d6..bacebff 100
Convert to use vm_map_pages() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
---
arch/arm/mm/dma-mapping.c | 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index f1e2922..
Convert to use vm_map_pages() to map range of kernel
memory to user vma.
Tested on Rockchip hardware and display is working,
including talking to Lima via prime.
Signed-off-by: Souptick Joarder
Tested-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 17 ++---
1
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Andrew Cooper
> Sent: 15 April 2019 13:03
> To: Xen-devel
> Cc: Kevin Tian ; Wei Liu ; Jan
> Beulich ;
> Andrew Cooper ; Jun Nakajima
> ; Roger Pau Monne
>
> Subject: [Xen-devel] [PATC
Adding the Linux Xen maintainers, in case they can provide some insight.
On Mon, Apr 15, 2019 at 03:27:43PM -0700, PGNet Dev wrote:
> ref: from chat in #xen
>
> [08:53] pgnd: would be good to send an email so we can keep
> track of this in a more formal way.
>
> I've got Xen PV Dom0 boot
Jan Beulich writes ("Re: [PATCH 3/4] xen/public: Document
HYPERCALL_console_io()"):
> On 09.04.19 at 13:26, wrote:
> > I haven't replicated the ` because I have no idea what they are used for. I
> > would appreciate if you provide pointer how to use them.
>
> Well, I can only point you at the h
Julien Grall writes ("Re: [Xen-devel] [linux-arm-xen test] 134708: regressions
- all pass"):
> On 4/15/19 7:28 PM, osstest service owner wrote:
> > flight 134708 linux-arm-xen real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/134708/
...
> > test-arm64-arm64-examine11 examine-
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:
kpatch_regenerate_special_section: 1162: group size mismatch for section
.altinstructions
Hi Jan,
On 4/9/19 12:42 PM, Jan Beulich wrote:
On 09.04.19 at 13:26, wrote:
On 03/04/2019 14:04, Jan Beulich wrote:
Also please note the quotation used by the mentioned
existing doc comments, as well as a few other formal aspects
(like them also making clear what the return type is). I think
> -Original Message-
[snip]
> > > I wonder if the `'is_external' parameter of aio_set_fd_handler shoud be
> > > `true' here, instead. That flag seems to be used when making a snapshot
> > > of a blockdev, for example.
> > >
> > > That was introduced by:
> > > dca21ef23ba48f6f1428c59f295a857
flight 134850 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134850/
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 Oleksandr,
On 4/15/19 12:43 PM, Oleksandr wrote:
On 14.04.19 20:56, Julien Grall wrote:
On 4/8/19 11:14 AM, 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 "EAR
flight 134721 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134721/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken in 134611
build-arm64-pvops
On Mon, Apr 15, 2019 at 04:18:57PM -0700, Pry Mar wrote:
> Hello,
>
> https://paste.debian.net/1077718/
>
> I get a kernel panic as shown in the paste above no matter how I
> launch pvh, with bootloader (pygrub), kernel direct (4.18+), or
> pvgrub2 (i386-xen_pvh support).
>
> The dom0 here is ub
Hi Oleksandr,
On 4/15/19 12:30 PM, Oleksandr wrote:
On 14.04.19 19:55, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 4/8/19 11:14 AM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Extend driver to be able to handle other SCIF(X) compatible
interfaces as well. These interface
On 04/09/19 13:08, Anthony PERARD wrote:
> A Xen PVH guest doesn't have a RTC that OVMF would expect, so
> PcatRealTimeClockRuntimeDxe fails to initialize and prevent the firmware
> from finish to boot. To prevent that, we will use the
> XenRealTimeClockLib from ArmVirtPkg which simply always retur
On 04/09/19 13:08, Anthony PERARD wrote:
> So it can be used from the OvmfPkg by the following patch,
> "OvmfPkg/XenOvmf: use RealTimeClockRuntimeDxe from EmbeddedPkg"
(1) Please make the commit message self-contained.
with that,
Reviewed-by: Laszlo Ersek
Thanks
Laszlo
>
> Contributed-under:
On 04/09/19 13:08, Anthony PERARD wrote:
> This "device" use XenIoMmioLib to reserve some space to be use by the
> Grant Tables.
(1) can we replace "this device" with "XenIoPvhDxe"?
>
> The call is only done if it is necessary, we simply detect if the guest
> is probably PVH, as in this case the
The code for getting the entry and then populating was repeated in
p2m_change_altp2m_gfn() and in p2m_set_altp2m_mem_access().
The code is now in one place with a bool param that lets the caller choose
if it populates after get_entry().
If remapping is being done then both the old and new gfn's s
flight 83988 distros-debian-snapshot real [real]
http://osstest.xensource.com/osstest/logs/83988/
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
flight 134852 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134852/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 6 kernel-build fail REGR. vs. 134640
build-i386-libvirt
On Mon, 15 Apr 2019, Pry Mar wrote:
> Hello,
>
> https://paste.debian.net/1077718/
>
> I get a kernel panic as shown in the paste above no matter how I
> launch pvh, with bootloader (pygrub), kernel direct (4.18+), or
> pvgrub2 (i386-xen_pvh support).
>
> The dom0 here is ub1804, kernel-4.18, a
On 15.04.2019 18:37, Jan Beulich wrote:
Alexandru Stefan ISAILA 04/15/19 11:23 AM >>>
>> --- a/xen/include/asm-x86/p2m.h
>> +++ b/xen/include/asm-x86/p2m.h
>> @@ -514,6 +514,23 @@ static inline unsigned long mfn_to_gfn(struct domain
>> *d, mfn_t mfn)
> >return mfn_x(mfn);
>> }
>
We will soon provide this new capability to humans and automated
systems.
The default behaviour is retained: tip and base are passed by Gitlab
CI.
Signed-off-by: Wei Liu
---
automation/gitlab-ci/build-each-commit.sh | 10 +-
automation/gitlab-ci/test.yaml| 2 +-
2 files cha
On 15/04/2019 23:11, 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:
86 matches
Mail list logo
