flight 161302 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161302/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 0395a690c921cb195619b689ba0c0b687531c64c
baseline version:
xtf
flight 161301 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161301/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 64138c95db5a7a3e4768d8a01ba71dc3475e6524
baseline version:
ovmf
Patchew URL:
https://patchew.org/QEMU/1618889702-13104-1-git-send-email-igor.druzhi...@citrix.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 1618889702-13104-1-git-send-email-igor.druzhi...@citrix.com
Subject:
When we're replacing the existing mapping there is possibility of a race
on memory map with other threads doing mmap operations - the address being
unmapped/re-mapped could be occupied by another thread in between.
Linux mmap man page recommends keeping the existing mappings in place to
reserve
flight 161290 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161290/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
flight 161286 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161286/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 159418
flight 161291 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161291/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8c75a0720800e934c29aae75e3fb1cb42c0d0728
baseline version:
ovmf
From: Michael Brown
[ Upstream commit 2afeec08ab5c86ae21952151f726bfe184f6b23d ]
The logic in connect() is currently written with the assumption that
xenbus_watch_pathfmt() will return an error for a node that does not
exist. This assumption is incorrect: xenstore does allow a watch to
be
From: Michael Brown
[ Upstream commit 2afeec08ab5c86ae21952151f726bfe184f6b23d ]
The logic in connect() is currently written with the assumption that
xenbus_watch_pathfmt() will return an error for a node that does not
exist. This assumption is incorrect: xenstore does allow a watch to
be
From: Michael Brown
[ Upstream commit 2afeec08ab5c86ae21952151f726bfe184f6b23d ]
The logic in connect() is currently written with the assumption that
xenbus_watch_pathfmt() will return an error for a node that does not
exist. This assumption is incorrect: xenstore does allow a watch to
be
From: Michael Brown
[ Upstream commit 2afeec08ab5c86ae21952151f726bfe184f6b23d ]
The logic in connect() is currently written with the assumption that
xenbus_watch_pathfmt() will return an error for a node that does not
exist. This assumption is incorrect: xenstore does allow a watch to
be
From: Michael Brown
[ Upstream commit 2afeec08ab5c86ae21952151f726bfe184f6b23d ]
The logic in connect() is currently written with the assumption that
xenbus_watch_pathfmt() will return an error for a node that does not
exist. This assumption is incorrect: xenstore does allow a watch to
be
From: Michael Brown
[ Upstream commit 2afeec08ab5c86ae21952151f726bfe184f6b23d ]
The logic in connect() is currently written with the assumption that
xenbus_watch_pathfmt() will return an error for a node that does not
exist. This assumption is incorrect: xenstore does allow a watch to
be
From: Michael Brown
[ Upstream commit 2afeec08ab5c86ae21952151f726bfe184f6b23d ]
The logic in connect() is currently written with the assumption that
xenbus_watch_pathfmt() will return an error for a node that does not
exist. This assumption is incorrect: xenstore does allow a watch to
be
flight 161294 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161294/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf b0bc49846c154b79243f39d461a4515804bcaf53
baseline version:
xtf
flight 161284 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161284/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
On Mon, 19 Apr 2021, Bertrand Marquis wrote:
> Hi Julien,
>
> > On 18 Apr 2021, at 19:03, Julien Grall wrote:
> >
> > From: Julien Grall
> >
> > Some CPUs can speculate past a RET instruction and potentially perform
> > speculative accesses to memory before processing the return.
> >
> >
flight 161293 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161293/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 161281 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161281/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail like
161222
On Mon, 19 Apr 2021, Rahul Singh wrote:
> Hi Julien,
>
> > On 18 Apr 2021, at 6:48 pm, Julien Grall wrote:
> >
> >
> >
> > On 16/04/2021 17:41, Rahul Singh wrote:
> >> Hi Julien
> >
> > Hi Rahul,
> >
> >>> On 16 Apr 2021, at 5:08 pm, Julien Grall wrote:
> >>>
> >>>
> >>>
> >>> On
On 19.04.2021 17:57, Andrew Cooper wrote:
> On 19/04/2021 16:55, Jan Beulich wrote:
>> On 19.04.2021 16:45, Andrew Cooper wrote:
>>> Factor out a compat boolean to remove the lfence overhead from multiple
>>> is_pv_32bit_domain() calls.
>>>
>>> For a compat guest, the upper 32 bits of rdx are
On 19.04.2021 16:45, Andrew Cooper wrote:
> This removes a visually-werid layout of conditionals.
>
> Signed-off-by: Andrew Cooper
I don't mind the rearrangement, so
Acked-by: Jan Beulich
but I think it was done for a reason - to keep separate steps
separate.
Jan
On 19/04/2021 16:55, Jan Beulich wrote:
> On 19.04.2021 16:45, Andrew Cooper wrote:
>> Factor out a compat boolean to remove the lfence overhead from multiple
>> is_pv_32bit_domain() calls.
>>
>> For a compat guest, the upper 32 bits of rdx are zero, so there is no need to
>> have any conditional
On 19.04.2021 16:45, Andrew Cooper wrote:
> Factor out a compat boolean to remove the lfence overhead from multiple
> is_pv_32bit_domain() calls.
>
> For a compat guest, the upper 32 bits of rdx are zero, so there is no need to
> have any conditional logic at all when mapping the start info page.
On 19.04.2021 17:41, Andrew Cooper wrote:
> On 19/04/2021 16:30, Jan Beulich wrote:
>> All of the sudden, besides .text and .rodata and alike, an always
>> present .note.gnu.property section has appeared. This section, when
>> converting to binary format output, gets placed according to its
>>
On 19.04.2021 16:01, Andrew Cooper wrote:
> As with the toolstack side, we ought to use -Og for debug builds.
>
> All fixes are trivial. The first 3 are understandable, given reduced
> optimisations. The next 3 are, AFAICT, bogus diagnostics.
>
> Andrew Cooper (7):
> xen/arm: Make
On 19/04/2021 16:30, Jan Beulich wrote:
> All of the sudden, besides .text and .rodata and alike, an always
> present .note.gnu.property section has appeared. This section, when
> converting to binary format output, gets placed according to its
> linked address, causing the resulting blobs to be
All of the sudden, besides .text and .rodata and alike, an always
present .note.gnu.property section has appeared. This section, when
converting to binary format output, gets placed according to its
linked address, causing the resulting blobs to be about 128Mb in size.
The resulting headers with a
Factor out a compat boolean to remove the lfence overhead from multiple
is_pv_32bit_domain() calls.
For a compat guest, the upper 32 bits of rdx are zero, so there is no need to
have any conditional logic at all when mapping the start info page.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
This removes a visually-werid layout of conditionals.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/pv/dom0_build.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/pv/dom0_build.c
Hi Julien,
> On 18 Apr 2021, at 19:03, Julien Grall wrote:
>
> From: Julien Grall
>
> Some CPUs can speculate past a RET instruction and potentially perform
> speculative accesses to memory before processing the return.
>
> There is no known gadget available after the RET instruction today.
When compiling at -Og:
boot.c: In function 'efi_start':
boot.c:1339:9: error: 'argc' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
1339 | efi_arch_handle_cmdline(argc ? *argv : NULL, options, name.s);
|
The recommended optimisation level for debugging is -Og, and is what tools
such as gdb prefer. In practice, it equates to -01 with a few specific
optimisations turned off.
While the use of gdb isn't necessarily very helpful for Xen, the disassembly
will have fewer structural transformations vs
When compiling at -Og:
sysctl.c: In function ‘arch_do_sysctl’:
sysctl.c:197:19: error: ‘hcpu’ may be used uninitialized in this
function[-Werror=maybe-uninitialized]
ret = continue_hypercall_on_cpu(0, fn, hcpu);
^~
As with the toolstack side, we ought to use -Og for debug builds.
All fixes are trivial. The first 3 are understandable, given reduced
optimisations. The next 3 are, AFAICT, bogus diagnostics.
Andrew Cooper (7):
xen/arm: Make make_cpus_node() compile at -Og
x86/shim: Fix compilation at -Og
When compiling at -Og:
irq.c: In function ‘create_irq’:
irq.c:310:38: error: ‘desc’ may be used uninitialized in this
function[-Werror=maybe-uninitialized]
desc->arch.creator_domid = currd->domain_id;
~^~
This diagnostic
When compiling at -Og:
In file included from
/builds/xen-project/people/andyhhp/xen/xen/include/asm/domain.h:4:0,
from
/builds/xen-project/people/andyhhp/xen/xen/include/xen/domain.h:8,
from
When compiling at -Og:
domain_build.c: In function 'make_cpus_node':
domain_build.c:926:12: error: 'clock_valid' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
926 | if ( clock_valid )
|^
The compiler hasn't spotted that clock_valid
When compiling at -Og:
shim.c: In function ‘write_start_info’:
shim.c:288:22: error: ‘param’ may be used uninitialized in this
function[-Werror=maybe-uninitialized]
si->store_evtchn = param;
~^~~
and a slew of knock-on failures. All are caused by
flight 161288 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161288/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
The removed lines were initially added by commit 314e64084d31, but the
subsequent code which was using the nb_vm variable was later removed by
commit 2ba368d13893, which makes these lines of code an overlooked
reminiscence. Moreover, the call becomes very expensive when there is a
considerable
On 19.04.2021 13:54, Julien Grall wrote:
> For the time being, I think move this code in x86 is a lot better than
> #ifdef or keep the code in common code.
Well, I would perhaps agree if it ended up being #ifdef CONFIG_X86.
I would perhaps not agree if there was a new CONFIG_* which other
On 19.04.2021 14:09, Roger Pau Monné wrote:
> On Mon, Apr 19, 2021 at 01:46:02PM +0200, Jan Beulich wrote:
>> On 19.04.2021 11:16, Roger Pau Monné wrote:
>>> Adding Paul also for the Viridian part.
>>>
>>> On Fri, Apr 16, 2021 at 03:16:41PM +0200, Jan Beulich wrote:
Zapping leaf data for out
On Mon, Apr 19, 2021 at 01:46:02PM +0200, Jan Beulich wrote:
> On 19.04.2021 11:16, Roger Pau Monné wrote:
> > Adding Paul also for the Viridian part.
> >
> > On Fri, Apr 16, 2021 at 03:16:41PM +0200, Jan Beulich wrote:
> >> Zapping leaf data for out of range leaves is just one half of it: To
>
On 19/04/2021 12:16, Jan Beulich wrote:
On 19.04.2021 10:40, Roger Pau Monné wrote:
On Mon, Apr 19, 2021 at 07:16:52AM +, Rahul Singh wrote:
Thanks you everyone for reviewing the code. I will summarise what I have
understood from all the comments
and what I will be doing for the next
On 19.04.2021 11:16, Roger Pau Monné wrote:
> Adding Paul also for the Viridian part.
>
> On Fri, Apr 16, 2021 at 03:16:41PM +0200, Jan Beulich wrote:
>> Zapping leaf data for out of range leaves is just one half of it: To
>> avoid guests (bogusly or worse) inferring information from mere leaf
>>
flight 161276 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161276/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
On 17.04.2021 21:24, Tim Deegan wrote:
> At 12:40 +0200 on 12 Apr (1618231248), Jan Beulich wrote:
>> The address of this page is used by the CPU only to recognize when to
>> access the virtual APIC page instead. No accesses would ever go to this
>> page. It only needs to be present in the (CPU)
On 19.04.2021 10:40, Roger Pau Monné wrote:
> On Mon, Apr 19, 2021 at 07:16:52AM +, Rahul Singh wrote:
>> Thanks you everyone for reviewing the code. I will summarise what I have
>> understood from all the comments
>> and what I will be doing for the next version of the patch. Please let me
On 19.04.2021 11:12, Luca Fancellu wrote:
> Modification to include/public/grant_table.h:
>
> 1) Add doxygen tags to:
> - Create Grant tables section
> - include variables in the generated documentation
> 2) Add .rst file for grant table for Arm64
I'm missing some reasoning about at least some
Hi Julien,
> On 18 Apr 2021, at 6:48 pm, Julien Grall wrote:
>
>
>
> On 16/04/2021 17:41, Rahul Singh wrote:
>> Hi Julien
>
> Hi Rahul,
>
>>> On 16 Apr 2021, at 5:08 pm, Julien Grall wrote:
>>>
>>>
>>>
>>> On 16/04/2021 17:05, Rahul Singh wrote:
> On 16 Apr 2021, at 4:23 pm, Julien
On 18.04.21 16:44, Marek Marczykowski-Górecki wrote:
Hi,
I've recently got the crash like below. I'm not sure what exactly
triggers it (besides grant table mapping as seen in the call trace), and
also I don't have reliable reproducer. It happened once for about ~30
startups.
Previous version
I follow the bleeding edge on Dom0 kernels and Xen pretty closely, and
for the past 6 months I have been encountering increasingly frequent
hangs in the most heavily used domUs. I have tried downgrading
both dom0 kernel and xen, but can't seem to find any where the bug does
not materialize.
Adding Paul also for the Viridian part.
On Fri, Apr 16, 2021 at 03:16:41PM +0200, Jan Beulich wrote:
> Zapping leaf data for out of range leaves is just one half of it: To
> avoid guests (bogusly or worse) inferring information from mere leaf
> presence, also shrink maximum indicators such that
Modification to include/public/grant_table.h:
1) Add doxygen tags to:
- Create Grant tables section
- include variables in the generated documentation
2) Add .rst file for grant table for Arm64
Signed-off-by: Luca Fancellu
---
v2 changes:
- Revert back to anonymous union/struct
- add doxygen
Create a skeleton for the documentation about hypercalls
Signed-off-by: Luca Fancellu
---
.gitignore | 1 +
docs/Makefile | 4
docs/hypercall-interfaces/arm32.rst| 4
docs/hypercall-interfaces/arm64.rst| 32
This serie introduce doxygen in the sphinx html docs generation.
One benefit is to keep most of the documentation in the source
files of xen so that it's more maintainable, on the other hand
there are some limitation of doxygen that should be addressed
modifying the current codebase (for example
flight 161279 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161279/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 159418
Tests which
On Mon, Apr 19, 2021 at 07:16:52AM +, Rahul Singh wrote:
> Thanks you everyone for reviewing the code. I will summarise what I have
> understood from all the comments
> and what I will be doing for the next version of the patch. Please let me
> know your view on this.
>
> 1. Create a
On Fri, Apr 16, 2021 at 09:29:26AM +0200, Jan Beulich wrote:
> On 15.04.2021 18:04, Roger Pau Monné wrote:
> > On Wed, Apr 07, 2021 at 07:08:06PM +0200, Roger Pau Monné wrote:
> >> On Wed, Apr 07, 2021 at 05:51:14PM +0200, Jan Beulich wrote:
> >>> On 31.03.2021 12:32, Roger Pau Monne wrote:
>
On Sun, 11 Apr 2021 11:17:38 +0200
Juergen Gross wrote:
> On 11.04.21 09:17, Henrik Riomar wrote:
> > On Sun, 11 Apr 2021 07:34:16 +0200
> > Juergen Gross wrote:
> >
> >> On 11.04.21 00:02, Henrik Riomar wrote:
> >>> Hi,
> >>>
> >>> In Alpine and Debian (probably elsewhere as well), the -s
flight 161282 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161282/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
Hi Julien,
> On 18 Apr 2021, at 19:16, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 16/04/2021 17:04, Bertrand Marquis wrote:
>>> On 5 Apr 2021, at 17:20, Julien Grall wrote:
>>>
>>> From: Julien Grall
>>>
>>> At the moment, we are computing offsets/masks for each level and
>>> granularity.
Hi All,
> On 15 Apr 2021, at 2:31 pm, Julien Grall wrote:
>
> Hi Roger,
>
> On 15/04/2021 14:26, Roger Pau Monné wrote:
>> On Wed, Apr 14, 2021 at 09:49:37AM +0100, Julien Grall wrote:
>>> Hi Roger,
>>>
>>> On 14/04/2021 09:05, Roger Pau Monné wrote:
On Tue, Apr 13, 2021 at 06:12:10PM
flight 161270 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161270/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
65 matches
Mail list logo
