Signed-off-by: Alexandru Isaila
---
Changes since v1:
- Added designated reviewer after maintainer list
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ab32e7f409..63563ce2e0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -413,6 +413,7 @@ F: un
branch xen-4.9-testing
xenbranch xen-4.9-testing
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.g
On 21.06.19 10:19, Alexandru Stefan ISAILA wrote:
Signed-off-by: Alexandru Isaila
---
Changes since v1:
- Added designated reviewer after maintainer list
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ab32e7f409..63563ce2e0 100644
--- a/MA
On 21.06.2019 11:42, Juergen Gross wrote:
> On 21.06.19 10:19, Alexandru Stefan ISAILA wrote:
>> Signed-off-by: Alexandru Isaila
>>
>> ---
>> Changes since v1:
>> - Added designated reviewer after maintainer list
>> ---
>> MAINTAINERS | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git
Signed-off-by: Alexandru Isaila
---
Changes since v2:
- Use tab instead of spaces.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ab32e7f409..a3c3ea5c97 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -413,6 +413,7 @@ F: unmodified_drivers/linu
>>> On 20.06.19 at 19:24, wrote:
> Actually I may have found the error. I feel quite ashamed I didn't spot
> this during review and when the bisector fingered it.
>
> staging-4.11 and staging.4.12 didn't have get_cycles implemented (i.e it
> returned 0). During the backport, get_cycles() got su
>>> On 19.06.19 at 22:11, wrote:
> .rodata.cst* sections are used for mergable constant data, and the clang/llvm
> 8 toolchain has been observed to create .rodata.cst8 in a default Xen build.
Neither this nor ...
> Unfortunately, this section (and its .init counterpart) aren't captured by
> Xen'
Hi Jan,
On 21/06/2019 09:58, Jan Beulich wrote:
On 20.06.19 at 19:24, wrote:
Actually I may have found the error. I feel quite ashamed I didn't spot
this during review and when the bisector fingered it.
staging-4.11 and staging.4.12 didn't have get_cycles implemented (i.e it
returned 0). Duri
>>> On 19.06.19 at 22:11, wrote:
> Neither of these should live in .data
>
> * .data.schedulers is only ever read, so is moved into .rodata
Which then would better be .rodata.schedulers, wouldn't it?
Same would apparently go for .data.param.
Jan
_
Hi,
On 20/06/2019 18:50, Andrew Cooper wrote:
On 20/06/2019 18:47, Julien Grall wrote:
Since commit ca73ac8e7d "xen/arm: Add an isb() before reading CNTPCT_EL0
to prevent re-ordering", get_cycles() is now returning the number of
cycles and used in more callers.
While the counter registers is a
>>> On 19.06.19 at 22:11, wrote:
> .data.read_mostly only needs separating from adjacent data by one cache line
> to be effective, and placing it adjacent to .data.page_aligned fulfills this
> requirement.
>
> For ARM, .ex_table appears to be a vestigial remnant. Nothing in the
> resulting build
xl(1) opens xl.conf in XEN_CONFIG_DIR.
Substitute this variable also in the man page.
Signed-off-by: Olaf Hering
---
docs/man/xl.1.pod.in | 2 +-
docs/man/xl.conf.5.pod.in | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in
inde
Now that scripts are stored in libexec, replace all hardcoded paths to
use XEN_SCRIPT_DIR to expand the actual location.
Update .gitignore.
Signed-off-by: Olaf Hering
---
.gitignore | 3 +++
docs/configure.ac
branch xen-4.8-testing
xenbranch xen-4.8-testing
job test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.
On 21/06/2019 01:28, Stefano Stabellini wrote:
On Thu, 20 Jun 2019, Volodymyr Babchuk wrote:
GCC 4.8 is unable to see that variables guest_pg, guest_data and
xen_data will be always initialized before access, so we need to
initialize them earlier.
Suggested-by: Stefano Stabellini
Signed-off-
>>> On 19.06.19 at 22:11, wrote:
> * Drop .gnu.warning. Xen, not being a library, has no need for
>__attribute__((__warning__("str"))) and isn't liable to ever gain such
>annotations for link time warnings.
> * Adjust the indentation of the start of ARM's .rodata section.
> * Discard .
This series came out of observations during the development of XSA-295.
It has been tested on x86, but only compile tested on arm. It can be obtained
in git form from:
http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/xen-grant-status
Andrew Cooper (5):
xen
_set_status_v{1,2}() and gnttab_prepare_for_transfer() read the shared header
by always casting to u32. Despite grant_entry_header_t only having an
alignment of 2, this is actually safe because of the grant table ABI itself.
Switch to using an explicit uint32_t *, which removes all subsequent cas
To allow for further improvements, it is useful to be able to clear more than
a single flag at once. Rework gnttab_clear_flag() into gnttab_clear_flags()
which takes a bitmask rather than a bit number.
No practical change yet.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: R
There is no need for 'struct { ... } shorts' to be named. Convert it to being
an anonymous struct, and rename 'word' to the more common 'raw'.
For _set_status_v1() and gnttab_prepare_for_transfer() which use a bounded
cmpxchg loop, rename {prev,new}_scombo to {prev,new} and reduce their scope to
It is inefficient to call into a different translation unit for a stub
function, when a static inline will work fine. Replace an open-coded
printk_once() while moving it.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Stefano Stabellini
CC: Julien Grall
---
xen/arch/arm/mm.c
Atomic operations are expensive to use, especially following XSA-295 for ARM.
It is wasteful to use two of them back-to-back when one will do.
Especially for a misbehaving guest on ARM, this will reduce the system
disruption required to complete the grant operations.
Signed-off-by: Andrew Cooper
>>> On 20.06.19 at 12:00, wrote:
> Hi Stefano,
>
> On 6/19/19 11:04 PM, Stefano Stabellini wrote:
>> On Wed, 19 Jun 2019, Julien Grall wrote:
>>> On 6/19/19 10:47 PM, Stefano Stabellini wrote:
On Wed, 19 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> Title: You should at least m
>>> On 20.06.19 at 14:06, wrote:
> Following on from c/s 7d161f6537 "x86/svm: Fix svm_vmcb_dump() when used in
> current context", there is now only a single user of svm_vmsave() remaining in
> the tree, with all users moved to svm_vm{load,save}_pa().
>
> nv->nv_n1vmcx has a matching nv->nv_n1vmc
flight 138127 xen-4.6-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/138127/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-amd queued
test-amd64-
flight 138023 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138023/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 137639
test-amd64-amd64-xl-qemuu-win7-amd64 17
Hi,
Changes in v3:
- two patches queued for a pull requests[1]:
xen: Drop includes of xen/hvm/params.h
xen: Avoid VLA
- the two others patchs has changed, to keep the headers identical (nearly;
at least the header guard isn't changed anymore)
Fix the build in osstest and some cleanup
F
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
On Fri, Jun 21, 2019 at 11:54:40AM +0100, Anthony PERARD wrote:
> 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
On Fri, Jun 21, 2019 at 11:54:41AM +0100, Anthony PERARD wrote:
> A Xen public header have been imported into QEMU (by
> f65eadb639 "xen: import ring.h from xen"), but there are other header
> that depends on ring.h which come from the system when building QEMU.
>
> This patch resolves the issue o
branch xen-4.10-testing
xenbranch xen-4.10-testing
job test-armhf-armhf-libvirt
testid debian-install
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xen
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
On 21/06/2019, 07:14, "Jan Beulich" wrote:
>>> On 20.06.19 at 16:18, wrote:
> On 27/05/2019, 10:41, "Jan Beulich" wrote:
>
> >>> On 24.05.19 at 19:44, wrote:
> > Following the recent discussion, we had on IRC and the action I had
in
> > the March commu
>>> On 21.06.19 at 13:46, wrote:
> 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 (
Patchew URL:
https://patchew.org/QEMU/20190621105441.3025-1-anthony.per...@citrix.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Xen-devel] [PATCH v3 0/2] Fix build of Xen support + cleanup
Type: series
Message-id: 2019062110544
> -Original Message-
> From: Anthony PERARD
> Sent: 21 June 2019 11:55
> To: qemu-de...@nongnu.org
> Cc: Stefano Stabellini ; Paul Durrant
> ; Anthony
> Perard ; xen-devel@lists.xenproject.org; Daniel P.
> Berrangé
> ; Markus Armbruster
> Subject: [PATCH v3 1/2] Revert xen/io/ring.h of
flight 138176 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138176/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 15/03/2019 11:05, Jan Beulich wrote:
> As to the feature dependency adjustment, while strictly speaking AVX is
> a sufficient prereq (to have YMM registers), 256-bit vectors of integers
> have got fully introduced with AVX2 only. Sadly gcc can't be used as a
> reference here: They don't provide
On 15/03/2019 11:06, Jan Beulich wrote:
> As to the feature dependency adjustment, just like for VPCLMULQDQ while
> strictly speaking AVX is a sufficient prereq (to have YMM registers),
> 256-bit vectors of integers have got fully introduced with AVX2 only.
>
> A new test case (also covering AESNI)
On 15/03/2019 11:06, Jan Beulich wrote:
> Note that the ISA extensions document revision 035 is ambiguous
> regarding fault suppression for VGF2P8MULB: Text says it's supported,
> while the exception specification listed is E4NF. Given the wording here
> and for the other two insns I'm inclined to
On 15/03/2019 11:07, Jan Beulich wrote:
> Incremental additions and/or mistakes have lead to some code blocks
> sitting in "unexpected" places. Re-sort the case blocks (opcode space;
> major opcode; 66/F3/F2 prefix; legacy/VEX/EVEX encoding).
>
> As an exception the opcode space 0x0f EVEX-encoded V
On 21/06/2019 14:19, Andrew Cooper wrote:
>> +}
>> +
>> +static bool simd_check_avx512bw_gf(void)
>> +{
>> +return cpu_has_gfni && cpu_has_avx512bw;
> I don't see any BW interaction anywhere (in the manual), despite the
> fact it operates on a datatype of int8.
Actually, it is an integer opera
Patchew URL:
https://patchew.org/QEMU/20190621105441.3025-1-anthony.per...@citrix.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Xen-devel] [PATCH v3 0/2] Fix build of Xen support + cleanup
Message-id: 2019062110544
On 15/03/2019 11:07, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
This feels like it should be folded with patch 45 (or perhaps easier, 45
moved later and folded into this one. The exact ordering of patches
really doesn't matter).
> @@ -91,6 +95,16 @@ static bool simd_check_xop(void)
>
On Fri, Jun 21, 2019 at 06:07:25AM -0600, Jan Beulich wrote:
> >>> On 21.06.19 at 13:46, wrote:
> > 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:
flight 138048 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138048/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 137929
test-armhf-armhf-libvirt-raw 13 saveresto
>>> On 21.06.19 at 14:52, wrote:
> On 15/03/2019 11:05, Jan Beulich wrote:
>> As to the feature dependency adjustment, while strictly speaking AVX is
>> a sufficient prereq (to have YMM registers), 256-bit vectors of integers
>> have got fully introduced with AVX2 only. Sadly gcc can't be used as
> /*
> @@ -136,7 +100,7 @@ static int64_t time_ref_count(const struct domain *d)
>* 128 bit number which is then shifted 64 times to the right to obtain
>* the high 64 bits."
>*/
Is there a good reason for using signed offset here? If so then maybe
you should change the return type
On 15/03/2019 11:08, Jan Beulich wrote:
> +/*
> + * SHA256RNDS2
> + *
> + * SRC1 = { C0, D0, G0, H0 }
> + * SRC2 = { A0, B0, E0, F0 }
> + * XMM0 = W' = { ?, ?, WK1, WK0 }
> + *
> + * (NB that the notation again is not C-like, i.e. elem
On 15/03/2019 11:08, Jan Beulich wrote:
> Also use this for AVX512_VBMI2 VPSH{L,R}D{,V}{D,Q,W} testing (only the
> quad word right shifts get actually used; the assumption is that their
> "left" counterparts as well as the double word and word forms then work
> as well).
>
> Signed-off-by: Jan Beul
> -Original Message-
> From: Alexandru Stefan ISAILA
> Sent: 21 June 2019 14:49
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Wei Liu ; Jan
> Beulich ;
> Roger Pau Monne
> Subject: Re: [Xen-devel] [PATCH v2] viridian: unify time sources
>
> > /*
> > @@ -136
>>> On 21.06.19 at 15:19, wrote:
> On 15/03/2019 11:06, Jan Beulich wrote:
>> Note that the ISA extensions document revision 035 is ambiguous
>> regarding fault suppression for VGF2P8MULB: Text says it's supported,
>> while the exception specification listed is E4NF. Given the wording here
>> and
>>> On 21.06.19 at 15:36, wrote:
> On 15/03/2019 11:07, Jan Beulich wrote:
>> Signed-off-by: Jan Beulich
>
> This feels like it should be folded with patch 45 (or perhaps easier, 45
> moved later and folded into this one. The exact ordering of patches
> really doesn't matter).
Not really imo -
>>> On 21.06.19 at 15:51, wrote:
> On 15/03/2019 11:08, Jan Beulich wrote:
>> +/*
>> + * SHA256RNDS2
>> + *
>> + * SRC1 = { C0, D0, G0, H0 }
>> + * SRC2 = { A0, B0, E0, F0 }
>> + * XMM0 = W' = { ?, ?, WK1, WK0 }
>> + *
>> + * (NB that
On 21/06/2019 15:00, Jan Beulich wrote:
>> On 15/03/2019 11:06, Jan Beulich wrote:
>> (On a tangent, AVX512_VP2INTERSECT now exists in the extensions doc.)
> And I have it implemented, but no way to test until sde supports it.
Fair enough.
>>> @@ -138,6 +141,26 @@ static bool simd_check_avx512vbm
On 21/06/2019 15:04, Jan Beulich wrote:
On 21.06.19 at 15:36, wrote:
>> On 15/03/2019 11:07, Jan Beulich wrote:
>>> Signed-off-by: Jan Beulich
>> This feels like it should be folded with patch 45 (or perhaps easier, 45
>> moved later and folded into this one. The exact ordering of patches
>
Will be useful in combination with new mode(s) of mg-repro-setup.
Signed-off-by: Ian Jackson
---
mg-transient-task | 32
1 file changed, 32 insertions(+)
create mode 100755 mg-transient-task
diff --git a/mg-transient-task b/mg-transient-task
new file mode 10075
On 21/06/2019 15:10, Jan Beulich wrote:
On 21.06.19 at 15:51, wrote:
>> On 15/03/2019 11:08, Jan Beulich wrote:
>>> +/*
>>> + * SHA256RNDS2
>>> + *
>>> + * SRC1 = { C0, D0, G0, H0 }
>>> + * SRC2 = { A0, B0, E0, F0 }
>>> + * XMM0 = W' = { ?, ?, W
This fixes bugs I found trying to use the last version of this series.
This version has been used successfully.
Ian Jackson (8):
mg-transient-task: New utility
mg-transient-task: Put the ownd fd on a high fd, say, 114
mg-repro-setup: Do all builds in their own tasks, regardless
mg-repro-se
The +TREEs and other specifications are convolved.
Signed-off-by: Ian Jackson
---
mg-repro-setup | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/mg-repro-setup b/mg-repro-setup
index 5a52e617..9a81c565 100755
--- a/mg-repro-setup
+++ b/mg-repro-setup
@@ -45,8 +45,7 @@ us
In case OSSTEST_TASK was set by the caller, unset it. Unsetting it
will cause each sg-run-job (inside mg-execute-task) to become its own
task.
Signed-off-by: Ian Jackson
---
mg-repro-setup | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mg-repro-setup b/mg-repro-setup
inde
This avoids clashes with other shell scripts' etc. fds.
Signed-off-by: Ian Jackson
---
v2: New patch
---
mg-transient-task | 5 -
tcl/JobDB-Executive.tcl | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/mg-transient-task b/mg-transient-task
index 2b3b315e..ce5180ff
We are going to make a mode where we don't set OSSTEST_TASK. The
result is that our subprocesses will do whatever they usually do.
Those are mg-allocate (which would allocate for our static task) and
mg-execute-flight which will make a dynamic task. We must therefore
prevent mg-allocate from run
This just involves turning autoalloc on and statictask off.
It is most useful with mg-transient-task, as documented.
Signed-off-by: Ian Jackson
---
mg-repro-setup | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/mg-repro-setup b/mg-repro-setup
index 45c56f6a..b
The glob syntax here was wrong, and the code cs-adjust-flight did not
handle it properly either. So --rebuild -r has not worked since it
first appeared in:
a1e0e5846f7bb7d82a5db1d7cd643b9f5ca1b9a9
mg-repro-flight: Provide --rebuild to make variant build jobs
Signed-off-by: Ian Jackson
---
--rebuild ends the current --rebuild specification.
Signed-off-by: Ian Jackson
---
v2: New patch
---
mg-repro-setup | 1 +
1 file changed, 1 insertion(+)
diff --git a/mg-repro-setup b/mg-repro-setup
index 3ceb7032..374176f0 100755
--- a/mg-repro-setup
+++ b/mg-repro-setup
@@ -189,6 +189,7 @@ wh
On Fri, Jun 21, 2019 at 12:37:47AM -0600, Jan Beulich wrote:
> >>> On 19.06.19 at 17:54, wrote:
> > On Wed, Jun 19, 2019 at 12:20:40AM -0600, Jan Beulich wrote:
> >> >>> On 18.06.19 at 19:22, wrote:
> >> > On Tue, Jun 11, 2019 at 06:42:33AM -0600, Jan Beulich wrote:
> >> >> >>> On 10.06.19 at 18:
>>> On 21.06.19 at 16:29, wrote:
> On Fri, Jun 21, 2019 at 12:37:47AM -0600, Jan Beulich wrote:
>> >>> On 19.06.19 at 17:54, wrote:
>> > On Wed, Jun 19, 2019 at 12:20:40AM -0600, Jan Beulich wrote:
>> >> >>> On 18.06.19 at 19:22, wrote:
>> >> > On Tue, Jun 11, 2019 at 06:42:33AM -0600, Jan Beuli
>>> 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:
>>> (On a tangent, AVX512_VP2INTERSECT now exists in the extensions doc.)
>> And I have it implemented, but no way to test until sde supports it.
>
> Fair enough.
>
@@ -138
>>> On 17.06.19 at 10:23, wrote:
> Currently, the time_ref_count enlightened time source maintains an offset
> such that time is frozen when the domain paused, but the reference_tsc
> enlightened time source does not. After migrate, the reference_tsc source
> may become invalidated (e.g. because o
>>> On 13.06.19 at 17:11, wrote:
> On Thu, Jun 13, 2019 at 8:01 AM Razvan Cojocaru
> wrote:
>>
>> Remove myself as vm_event maintaner, add Alexandru and Petre as
>> Bitdefender vm_event maintainers.
>>
>> Signed-off-by: Razvan Cojocaru
>
> Acked-by: Tamas K Lengyel
I'll take the liberty and a
>>> On 21.06.19 at 15:58, wrote:
>> -Original Message-
>> From: Alexandru Stefan ISAILA
>> Sent: 21 June 2019 14:49
>> To: Paul Durrant ; xen-devel@lists.xenproject.org
>> Cc: Andrew Cooper ; Wei Liu ; Jan
>> Beulich
> ;
>> Roger Pau Monne
>> Subject: Re: [Xen-devel] [PATCH v2] virid
> -Original Message-
> From: Jan Beulich
> Sent: 21 June 2019 16:21
> To: Paul Durrant
> Cc: aisa...@bitdefender.com; Andrew Cooper ; Roger
> Pau Monne
> ; xen-devel ; WeiLiu
>
> Subject: RE: [Xen-devel] [PATCH v2] viridian: unify time sources
>
> >>> On 21.06.19 at 15:58, wrote:
> >
On Fri, Jun 21, 2019 at 08:56:22AM -0600, Jan Beulich wrote:
> >>> On 21.06.19 at 16:29, wrote:
> > On Fri, Jun 21, 2019 at 12:37:47AM -0600, Jan Beulich wrote:
> >> >>> On 19.06.19 at 17:54, wrote:
> >> > On Wed, Jun 19, 2019 at 12:20:40AM -0600, Jan Beulich wrote:
> >> >> >>> On 18.06.19 at 19:
On 6/21/19 6:15 PM, Jan Beulich wrote:
On 13.06.19 at 17:11, wrote:
On Thu, Jun 13, 2019 at 8:01 AM Razvan Cojocaru
wrote:
Remove myself as vm_event maintaner, add Alexandru and Petre as
Bitdefender vm_event maintainers.
Signed-off-by: Razvan Cojocaru
Acked-by: Tamas K Lengyel
I'll ta
Hi all,
Please propose topics by either editing the running agenda document at
https://cryptpad.fr/pad/#/2/pad/edit/V-JctV2vBlEnwliVLBlFLY7n/ or by replying
to the mail.
Note that currently I have
* Nothing under:
D) New Series / Series that need attention / Series that are important
*
flight 138040 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138040/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs.
137724
Tests whic
Hello,
Following patches are the general improvements that came out of my
attempt to add LLD 8 support.
I've now put on hold the addition of LLD 8 support, since according to
LLD documentation it should mimic GNU ld behaviour, but that's clearly
not the case with orphan sections in linker scripts
if the hypervisor has been built with EFI support (ie: multiboot2).
This allows to position the .reloc section correctly in the output
binary.
Note that for the ELF output format the .reloc section is moved before
.bss for two reasons: in order for the resulting binary to not contain
any section w
After building the hypervisor binary. Note that the check is performed
by searching for the magic header value at the start of the binary.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
Changes since v1:
- Use an intermediate file to perform the header ch
Replace the two open-coded EFI related section declarations with the
usage of DECL_SECTION. This is a preparatory change for also adding a
reloc section to the ELF binary.
Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
xen/arch/x8
On 21/06/2019 17:38, Roger Pau Monne wrote:
> After building the hypervisor binary. Note that the check is performed
> by searching for the magic header value at the start of the binary.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Wei Liu
While the chan
On Fri, Jun 21, 2019 at 06:20:54PM +0100, Andrew Cooper wrote:
> On 21/06/2019 17:38, Roger Pau Monne wrote:
> > After building the hypervisor binary. Note that the check is performed
> > by searching for the magic header value at the start of the binary.
> >
> > Signed-off-by: Roger Pau Monné
> >
On 14/06/2019 16:35, Jan Beulich wrote:
> Up to now we've been assuming that all CPUs would have the same number
> of reporting banks. However, on upcoming AMD CPUs this isn't the case,
> and one can observe
>
> (XEN) mce.c:666: Different bank number on cpu
>
> indicating that Machine Check suppor
On 14/06/2019 16:37, Jan Beulich wrote:
> this_cpu() is shorter, and when there are multiple uses in a function
> per_cpu() it's also more efficient.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.
On 14/06/2019 16:37, Jan Beulich wrote:
> this_cpu() is shorter, and when there are multiple uses in a function
> per_cpu() it's also more efficient.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.
On 14/06/2019 16:38, Jan Beulich wrote:
> this_cpu{,_ptr}() are shorter, and have previously been marked as
> preferred in Xen anyway.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
Dear Community Members,
at the 2017 Developer Summit the question of a Code of Conduct (CoC) for the
Xen Project had come up and subsequently a number of individuals within the
community have looked at the question of whether we should have a CoC or not.
Note that there was a discussion at the
When binding an interdomain event channel to a vcpu via
IOCTL_EVTCHN_BIND_INTERDOMAIN not only the event channel needs to be
bound, but the affinity of the associated IRQi must be changed, too.
Otherwise the IRQ and the event channel won't be moved to another vcpu
in case the original vcpu they wer
flight 138050 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138050/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313
build-armhf-pvops
flight 138205 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138205/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
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: Denis Obrezkov
---
xen/arch/arm/arm32/head.S | 11 ++-
xen/arch/arm/platforms/omap5.c| 5 +++--
xen/include/asm-arm/platforms/o
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 possible mask and ends up causing a significant
memory waste in the
Hi all,
This is an update on "fix mask calculation in pdx_init_mask", plus a
cleanup patch.
The following changes since commit f3d8eef9091747e70c505094f63514b43329a922:
x86/linker: use DECL_SECTION uniformly (2019-06-21 17:41:05 +0100)
are available in the Git repository at:
http://xenbits
Xen is phasing out the use of u64 in favor of uint64_t. Therefore, the
instance of u64 in the pdx_init_mask() (and the callers) are now
replaced with uint64_t. Take the opportunity to also modify
srat_region_mask as this is used to store the result of pdx_init_mask().
Signed-off-by: Stefano Stabel
flight 138077 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138077/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4c12dcace99dba96a9d4f7d0e259c0231e8fe6f1
baseline version:
ovmf 8a08dc5486f1a96c91b0c
flight 138228 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138228/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Wed, 5 Jun 2019, Julien Grall wrote:
> Hi,
>
> On 20/05/2019 23:38, Julien Grall wrote:
> > On 20/05/2019 22:26, Stefano Stabellini wrote:
> > > On Sat, 11 May 2019, Julien Grall wrote:
> > > This is not about privilege over the system: whoever will make the
> > > decision to ask the hypervisor
On Wed, 1 May 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 30/04/2019 22:02, Stefano Stabellini wrote:
> > As we parse the device tree in Xen, keep track of the reserved-memory
> > regions as they need special treatment (follow-up patches will make use
> > of the stored information.)
> >
> > Re
Hi Oleksandr,
Thanks for testing! Give a look at the latest version (v3). I don't
think this error will happen there.
Cheers,
Stefano
On Thu, 16 May 2019, Oleksandr wrote:
>
> On 01.05.19 00:02, Stefano Stabellini wrote:
> > Hi all,
>
> Hi, Stefano
>
>
> >
> > This series introduces a memo
1 - 100 of 112 matches
Mail list logo
