flight 138257 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138257/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 138228
Tests which
flight 138099 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138099/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 13 migrate-support-checkfail never pass
test-amd64-i386-libvirt-xsm 13 migrat
flight 138157 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138157/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 137600
build-arm64-xsm
flight 138242 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138242/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 138228
Tests which
flight 138073 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138073/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 133580
test-arm64-arm64-ex
Reserved memory regions are automatically remapped to dom0. Their device
tree nodes are also added to dom0 device tree. However, the dom0 memory
node is not currently extended to cover the reserved memory regions
ranges as required by the spec. This commit fixes it.
Signed-off-by: Stefano Stabell
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.)
Reuse process_memory_node to add reserved-memory regions to the
bootinfo.reserved_mem array.
Refuse to continue once we reach t
Don't allow reserved-memory regions to be remapped into any guests,
until reserved-memory regions are properly supported in Xen. For now,
do not call iomem_permit_access for them.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- new patch
---
xen/arch/arm/domain_build.c | 23 ++
reserved-memory regions overlap with memory nodes. The overlapping
memory is reserved-memory and should be handled accordingly:
consider_modules and dt_unreserved_regions should skip these regions the
same way they are already skipping mem-reserve regions.
Signed-off-by: Stefano Stabellini
---
Ch
Add two new parameters to device_tree_for_each_node: node and depth.
Node is the parent node to start the search from and depth is the min
depth of the search (the depth of the parent node). Passing 0, 0
triggers the old behavior.
We need this change because in follow-up patches we want to be able
Change the signature of process_memory_node to match
device_tree_node_func. Thanks to this change, the next patch will be
able to use device_tree_for_each_node to call process_memory_node on all
the children of a provided node.
Signed-off-by: Stefano Stabellini
---
Changes in v3:
- improve commit
Hi all,
This patch series introduces partial reserved-memory support for dom0
only (no domU support for reserved-memory yet.)
One change is still outstanding: cleaning up process_memory_node so that
it is not completely shared between the normal memory case and the
reserved-memory case.
The fol
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
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
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
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
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
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
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
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
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
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
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
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: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 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 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
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
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
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
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
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
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
*
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
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:
> -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 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
>>> 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 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 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 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 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:
--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
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
---
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 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
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 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
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
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
>
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.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.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: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
> -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 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
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
> /*
> @@ -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 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
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 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:
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)
>
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 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
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 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: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: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
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
> -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
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
>>> 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 (
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 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
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 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
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
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
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
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
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-
>>> 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
>>> 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
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
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
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
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
>>> 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 .
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-
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.
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
1 - 100 of 112 matches
Mail list logo
