flight 138327 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138327/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 138190
test-armhf-armhf-libvirt-raw 13 saveresto
flight 138307 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138307/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 133596
build-amd64-pre
>>> On 21.06.19 at 18:38, wrote:
> if the hypervisor has been built with EFI support (ie: multiboot2).
> This allows to position the .reloc section correctly in the output
> binary.
The title still says "add ... to ELF binary", when really such a section
is already there (and in fact that's the p
Hello,
I'm facing a problem with `xl list` output - as I'm fetching the output
of this command once in a minute, gathering the sum of the last column
to calculate CPUs/s usage I'm having a `data jumps` from 352242.2 to
9445321553.2 and then goes back to the previous value. This `blurs` the
a
This series fixes building with GCC 8 and later, and fixes booting native with
GCC 5 and later.
Andrew Cooper (2):
xen/ubsan: Don't perform alignment checking on supporting compilers
xen/ubsan: Support for -fsanitise=builtin
xen/Rules.mk | 4 +++-
xen/common/ubsan/ubsan.c | 21 +
This fixes the UBSAN build for GCC 8 and later. The sanitiser checks for
passing 0 to the ctz()/clz() builtins.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
---
xen/common/ubsan/ubsan.c | 21 +
GCC 5 introduced -fsanitize=alignment which is enabled by default by
CONFIG_UBSAN. This trips a load of wont-fix cases in the ACPI tables and the
hypercall page and stubs writing logic.
It also causes the native Xen boot to crash before the console is set up, for
an as-yet unidentified reason (mo
Hi Stefano,
On 6/21/19 9:24 PM, Stefano Stabellini wrote:
The mask calculation in pdx_init_mask is wrong when the first bank
starts at address 0x0. The reason is that pdx_init_mask will do '0 - 1'
causing an underflow. As a result, the mask becomes 0x
which is the biggest possibl
Hi Andrew,
On 6/24/19 11:17 AM, Andrew Cooper wrote:
GCC 5 introduced -fsanitize=alignment which is enabled by default by
CONFIG_UBSAN. This trips a load of wont-fix cases in the ACPI tables and the
hypercall page and stubs writing logic.
It also causes the native Xen boot to crash before the
On 24/06/2019 11:33, Julien Grall wrote:
> Hi Andrew,
>
> On 6/24/19 11:17 AM, Andrew Cooper wrote:
>> GCC 5 introduced -fsanitize=alignment which is enabled by default by
>> CONFIG_UBSAN. This trips a load of wont-fix cases in the ACPI tables
>> and the
>> hypercall page and stubs writing logic.
(+ GSOC mentors and Andre)
Hi Denis,
Thank you for the patch.
First of all, may I ask to CC the other mentors?
On 6/21/19 9:02 PM, Denis Obrezkov wrote:
This function allows xen to bring secondary CPU cores into non-secure
HYP mode. This is done by using a Secure Monitor call.
Signed-off-by:
On Fri, Jun 21, 2019 at 12:34:13AM -0600, Jan Beulich wrote:
> >>> On 19.06.19 at 17:06, wrote:
> > On Wed, Jun 19, 2019 at 06:57:05AM -0600, Jan Beulich wrote:
> >> >>> On 19.06.19 at 13:02, wrote:
> >> > If the hypervisor has been built with EFI support (ie: multiboot2).
> >> > This allows to p
flight 138333 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138333/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs.
127792
test-xt
On 24/06/2019 12:09, Julien Grall wrote:
> (+ GSOC mentors and Andre)
>
> Hi Denis,
>
> Thank you for the patch.
>
> First of all, may I ask to CC the other mentors?
>
> On 6/21/19 9:02 PM, Denis Obrezkov wrote:
>> This function allows xen to bring secondary CPU cores into non-secure
>> HYP mode. T
Hi all,
since Andy created https://xenbits.xen.org/docs/sphinx-unstable/ and
https://xenbits.xen.org/docs/sphinx-unstable-staging/ (sources in
docs/hypervisor-guide, docs/guest-guide, docs/admin-guide) I was wondering
whether it would not make sense to migrate some key documents in the wiki (an
In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.
However, in some cases (kexec not fully working, benchmarking)
we want to disable PV extensions. As such introduce the
'nopv' parameter that will do it
This reverts commit 8d693b911bb9c57009c24cb1772d205b84c7985c.
Instead we use an unified parameter 'nopv' for all the hypervisor
platforms.
Signed-off-by: Zhenzhong Duan
Cc: xen-devel@lists.xenproject.org
---
Documentation/admin-guide/kernel-parameters.txt | 4
arch/x86/xen/enlighten_hvm.c
On 23.06.19 15:01, Zhenzhong Duan wrote:
In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.
However, in some cases (kexec not fully working, benchmarking)
we want to disable PV extensions. As such int
On 23.06.19 15:01, Zhenzhong Duan wrote:
In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.
However, in some cases (kexec not fully working, benchmarking)
we want to disable PV extensions. As such int
flight 138424 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138424/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 2019/6/24 21:18, Juergen Gross wrote:
On 23.06.19 15:01, Zhenzhong Duan wrote:
In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.
However, in some cases (kexec not fully working, benchmarking)
we
osstest service owner writes ("[xen-4.6-testing test] 138333: regressions -
FAIL"):
> flight 138333 xen-4.6-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/138333/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be ru
Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions - FAIL"):
> These all have `qemut' in common.
I still think this is true (largely at least).
> The corresponding tests in Xen 4.7
> are all completey broken regardless of the qemu version...
But this is wrong.
Ian.
__
Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions - FAIL"):
> Ian Jackson writes ("Re: [xen-4.6-testing test] 138333: regressions - FAIL"):
> > These all have `qemut' in common.
>
> I still think this is true (largely at least).
>
> > The corresponding tests in Xen 4.7
> > are
erard/qemu-dm.git
tags/pull-xen-20190624
for you to fetch changes up to a3434a2d56aee3018f4a0f55c7e0f0cda11f3d9e:
xen: Import other xen/io/*.h (2019-06-24 10:42:30 +0100)
Xen queue
* Fix build
* xen-block: support feature-large-s
xen-mapcache.c doesn't needs params.h.
xen-hvm.c uses defines available in params.h but so is xen_common.h
which is included before. HVM_PARAM_* flags are only needed to make
xc_hvm_param_{get,set} calls so including only xenctrl.h, which is
where the definition the function is, should be enough.
From: Paul Durrant
This patch adds an AioContext parameter to xen_device_bind_event_channel()
and then uses aio_set_fd_handler() to set the callback rather than
qemu_set_fd_handler().
Signed-off-by: Paul Durrant
Reviewed-by: Anthony PERARD
Message-Id: <20190408151617.13025-3-paul.durr...@citri
From: Paul Durrant
To better support use of IOThread-s it will be necessary to be able to set
the AioContext for each XenEventChannel and hence it is necessary to open a
separate handle to libxenevtchan for each channel.
This patch stops using NotifierList for event channel callbacks, replacing
From: Paul Durrant
This patch introduces a poll callback for event channel fd-s and uses
this to invoke the channel callback function.
To properly support polling, it is necessary for the event channel callback
function to return a boolean saying whether it has done any useful work or
not. Thus
From: Paul Durrant
A recent Xen commit [1] clarified the semantics of sector based quantities
used in the blkif protocol such that it is now safe to create a xen-block
device with a logical_block_size != 512, as long as the device only
connects to a frontend advertizing 'feature-large-block-size'
This reverts changes to include/hw/xen/io/ring.h from commit
37677d7db39a3c250ad661d00fb7c3b59d047b1f.
Following 37677d7db3 "Clean up a few header guard symbols", QEMU start
to fail to build:
In file included from ~/xen/tools/../tools/include/xen/io/blkif.h:31:0,
from ~/xen/tools
Avoid using a variable length array.
We allocate the `dirty_bitmap' buffer only once when we start tracking
for dirty bits.
Signed-off-by: Anthony PERARD
Reviewed-by: Paul Durrant
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20190618112341.513-5-anthony.per...@citrix.com>
---
hw/i386/xen/
Patchew URL:
https://patchew.org/QEMU/20190624153257.20163-1-anthony.per...@citrix.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190624153257.20163-1-anthony.per...@citrix.com
Type: series
Subject: [Xen-devel] [PULL 0/8] xe
Hello,
One UBSAN report on x86 is:
(XEN)
(XEN) UBSAN: Undefined behaviour in
/local/xen.git/xen/include/xen/nodemask.h:220:9
(XEN) shift exponent 64 is too large for 64-bit type 'long unsigned int'
(XEN) [ Xen-4.
Patchew URL:
https://patchew.org/QEMU/20190624153257.20163-1-anthony.per...@citrix.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Xen-devel] [PULL 0/8] xen queue 2019-06-24
Type: series
Message-id: 20190624153257.20163-1-anthony
Patchew URL:
https://patchew.org/QEMU/20190624153257.20163-1-anthony.per...@citrix.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190624153257.20163-1-anthony.per...@citrix.com
Subject: [Xen-devel] [PULL 0/8] xen queue 2019-
Patchew URL:
https://patchew.org/QEMU/20190624153257.20163-1-anthony.per...@citrix.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190624153257.20163-1-anthony.per...@citrix.com
Type: series
Subject: [Xen-devel] [PULL 0/8] xe
Patchew URL:
https://patchew.org/QEMU/20190624153257.20163-1-anthony.per...@citrix.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190624153257.20163-1-anthony.per...@citrix.com
Subject: [Xen-devel] [PULL 0/8] xen queue 2019-
Signed-off-by: Stefano Stabellini
diff --git a/MAINTAINERS b/MAINTAINERS
index 313df52494..882e4efa22 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -175,6 +175,7 @@ F: tools/libxc/xc_arinc653.c
ARM (W/ VIRTUALISATION EXTENSIONS) ARCHITECTURE
M: Stefano Stabellini
M: Julien Grall
+R
Hi Stefano,
Stefano Stabellini writes:
> Signed-off-by: Stefano Stabellini
Acked-by: Volodymyr Babchuk
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 313df52494..882e4efa22 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -175,6 +175,7 @@ F:tools/libxc/xc_arinc653.c
> ARM (W/ V
d->node_affinity defaults to NODE_MASK_ALL which has bits set outside of
node_online_map. This in turn causes the loop in get_free_buddy() to waste
effort iterating over offline nodes.
Always clamp d->node_affinity to node_online_map when in use.
This in turn involves implementing nodes_copy() w
On Mon, 24 Jun 2019, Lars Kurth wrote:
> Hi all,
>
> since Andy created https://xenbits.xen.org/docs/sphinx-unstable/ and
> https://xenbits.xen.org/docs/sphinx-unstable-staging/ (sources in
> docs/hypervisor-guide, docs/guest-guide, docs/admin-guide) I was wondering
> whether it would not make
On Thu, 13 Jun 2019, chenbaodong wrote:
> > > But currently i don't understand xen well, only a few weeks experience.
> >
> > We do have small task for newcomers that would improve Xen code base and
> > also allow your to understand more some part of the code.
> >
> > If you have a specific area
GCC 5 introduced -fsanitize=alignment which is enabled by default by
CONFIG_UBSAN. This trips a load of wont-fix cases in the ACPI tables and the
hypercall page and stubs writing logic.
It also causes the native Xen boot to crash before the console is set up, for
an as-yet unidentified reason (mo
On Mon, 24 Jun 2019, Stefano Stabellini wrote:
> On Thu, 13 Jun 2019, chenbaodong wrote:
> > > > But currently i don't understand xen well, only a few weeks experience.
> > >
> > > We do have small task for newcomers that would improve Xen code base and
> > > also allow your to understand more som
+ xen-devel
On Mon, 24 Jun 2019, Stefano Stabellini wrote:
> Hi all,
>
> I might have found a bug with PCI passthrough to a Linux HVM guest on
> x86 with Xen 4.12. It is not easy for me to get access, and especially
> change components, on this particular system, and I don't have access to
> othe
Hi,
On 24/06/2019 19:03, Stefano Stabellini wrote:
> On Mon, 24 Jun 2019, Lars Kurth wrote:
> I think we all agree by now that maintaining up-to-date docs on the wiki
> and keeping them in sync with code changes is hard. I see moving things
> from the wiki to xen.git as a great improvement. We hav
Hi Stefano,
On 24/06/2019 19:27, Stefano Stabellini wrote:
> On Mon, 24 Jun 2019, Stefano Stabellini wrote:
>> On Thu, 13 Jun 2019, chenbaodong wrote:
> Let me add that if you prefer to document one of the other interfaces
> listed above in my email, you are welcome to pick another one. For
> exam
flight 138348 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138348/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 138207
test-amd64-amd64-xl-qemuu-win7-amd64
On Mon, 24 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 24/06/2019 19:27, Stefano Stabellini wrote:
> > On Mon, 24 Jun 2019, Stefano Stabellini wrote:
> >> On Thu, 13 Jun 2019, chenbaodong wrote:
> > Let me add that if you prefer to document one of the other interfaces
> > listed above in my
On Mon, 24 Jun 2019, Julien Grall wrote:
> Hi,
>
> On 24/06/2019 19:03, Stefano Stabellini wrote:
> > On Mon, 24 Jun 2019, Lars Kurth wrote:
> > I think we all agree by now that maintaining up-to-date docs on the wiki
> > and keeping them in sync with code changes is hard. I see moving things
> >
Hi Stefano,
On 6/24/19 9:23 PM, Stefano Stabellini wrote:
On Mon, 24 Jun 2019, Julien Grall wrote:
Hi,
On 24/06/2019 19:03, Stefano Stabellini wrote:
On Mon, 24 Jun 2019, Lars Kurth wrote:
I think we all agree by now that maintaining up-to-date docs on the wiki
and keeping them in sync with c
Hi,
On 6/24/19 9:17 PM, Stefano Stabellini wrote:
On Mon, 24 Jun 2019, Julien Grall wrote:
Hi Stefano,
On 24/06/2019 19:27, Stefano Stabellini wrote:
On Mon, 24 Jun 2019, Stefano Stabellini wrote:
On Thu, 13 Jun 2019, chenbaodong wrote:
Let me add that if you prefer to document one of the o
On Mon, 24 Jun 2019, Julien Grall wrote:
> Hi,
>
> On 6/24/19 9:17 PM, Stefano Stabellini wrote:
> > On Mon, 24 Jun 2019, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 24/06/2019 19:27, Stefano Stabellini wrote:
> > > > On Mon, 24 Jun 2019, Stefano Stabellini wrote:
> > > > > On Thu, 13 Ju
On Mon, 24 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 6/24/19 9:23 PM, Stefano Stabellini wrote:
> > On Mon, 24 Jun 2019, Julien Grall wrote:
> > > Hi,
> > >
> > > On 24/06/2019 19:03, Stefano Stabellini wrote:
> > > > On Mon, 24 Jun 2019, Lars Kurth wrote:
> > > > I think we all agree by
flight 138353 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138353/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
test-arm64-arm64-xl-
On 6/20/19 7:01 PM, Andrew Cooper wrote:
> Xen itself doesn't use autoconf, and needs a bit of extra help getting
> its options in order. There is an extra clang=y variable which you need
> to pass.
>
> xen.git$ make -C xen/ CC=clang-7 clang=y
Thanks! That seems to have worked.
Now I've got a ne
flight 138372 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138372/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 137600
build-amd64-xsm
flight 138364 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138364/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 130965
build-i386-prev
>>> On 21.06.19 at 16:20, wrote:
> On 21/06/2019 15:00, Jan Beulich wrote:
>>> On 15/03/2019 11:06, Jan Beulich wrote:
@@ -138,6 +141,26 @@ static bool simd_check_avx512vbmi_vl(voi
return cpu_has_avx512_vbmi && cpu_has_avx512vl;
}
+static bool simd_check_sse2_gf(vo
flight 138368 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138368/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 132889
build-amd64-pre
61 matches
Mail list logo
