flight 146062 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146062/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
> On 13. Jan 2020, at 23:12, Julien Grall wrote:
>
> pandoc is currently failing to generate the pdf with the following
> error:
> ! Undefined control sequence.
> l.1048 metadata string format is: key=value\0
>
> In this case, we want to print \0 so we need to backslash-escape the
> first ch
flight 146059 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146059/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 broken
test-amd64-amd64-xl-qemuu-ovmf-amd64 4 ho
On 1/13/20 10:12 PM, Julien Grall wrote:
> pandoc is currently failing to generate the pdf with the following
> error:
> ! Undefined control sequence.
> l.1048 metadata string format is: key=value\0
>
> In this case, we want to print \0 so we need to backslash-escape the
> first character.
>
>
On 13.01.2020 20:40, Jason Andryuk wrote:
> On Fri, Dec 27, 2019 at 11:09 AM Andrew Cooper
> wrote:
>>
>> On 20/12/2019 16:23, Jan Beulich wrote:
>>> On 16.09.2019 11:40, Jan Beulich wrote:
Using memcpy() may result in multiple individual byte accesses
(dependening how memcpy() is implem
On 13.01.2020 22:33, Julien Grall wrote:
> From: Julien Grall
>
> None of the prototypes within the header asm-x86/irq.h actually requires
> the forward declaration of "struct pirq". So remove it.
>
> No functional changes intended.
>
> Signed-off-by: Julien Grall
Acked-by: Jan Beulich
It i
On 13.01.2020 22:33, Julien Grall wrote:
> From: Julien Grall
>
> The ehci char driver is using timers but relying on the header
> xen/timer.h to be included via asm-x86/hvm/irq.h which is not even
> directly included!
>
> Future rework will reduce the number of places where asm-x86/hvm/irq.h
>
On 13.01.2020 22:33, Julien Grall wrote:
> --- a/xen/include/xen/domain.h
> +++ b/xen/include/xen/domain.h
> @@ -41,9 +41,7 @@ struct vcpu *alloc_vcpu_struct(const struct domain *d);
> void free_vcpu_struct(struct vcpu *v);
>
> /* Allocate/free a PIRQ structure. */
> -#ifndef alloc_pirq_struct
> -Original Message-
> From: Xen-devel On Behalf Of
> Julien Grall
> Sent: 13 January 2020 23:12
> To: xen-devel@lists.xenproject.org
> Cc: Ross Lagerwall ; Wieczorkiewicz, Pawel
> ; Julien Grall ; Konrad Rzeszutek
Wilk
>
> Subject: [Xen-devel] [PATCH] docs/misc: livepatch: Espace backsla
flight 146061 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146061/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs.
145969
test-armhf-armhf-li
FIFO event channels allow ports up to 2^17, so we need to use a wider
field in struct pirq. Move "masked" such that it may share the 8-byte
slot with struct arch_pirq on 64-bit arches, rather than leaving a
7-byte hole in all cases.
Take the opportunity and also add a comment regarding "arch" plac
> -Original Message-
> From: Julien Grall
> Sent: 13 January 2020 22:24
> To: Durrant, Paul ; jandr...@gmail.com
> Cc: Anthony PERARD ; xen-devel de...@lists.xenproject.org>; Ian Jackson ; Wei
> Liu
> Subject: Re: [Xen-devel] [PATCH v2 4/6] libxl: allow creation of domains
> with a speci
On Mon, Jan 13, 2020 at 02:01:47PM -0500, Jason Andryuk wrote:
> On Fri, Mar 22, 2019 at 3:43 PM Jason Andryuk wrote:
> >
> > On Thu, Mar 21, 2019 at 11:09 PM Roger Pau Monné
> > wrote:
> > >
> > > On Wed, Mar 20, 2019 at 01:28:47PM -0400, Jason Andryuk wrote:
> > > > On Fri, Mar 15, 2019 at 12:
Hi Jan,
On 14/01/2020 09:31, Jan Beulich wrote:
On 13.01.2020 22:33, Julien Grall wrote:
From: Julien Grall
None of the prototypes within the header asm-x86/irq.h actually requires
the forward declaration of "struct pirq". So remove it.
No functional changes intended.
Signed-off-by: Julien
> -Original Message-
> From: jandr...@gmail.com
> Sent: 13 January 2020 19:35
> To: Durrant, Paul
> Cc: xen-devel ; Anthony PERARD
> ; Ian Jackson ; Wei
> Liu
> Subject: Re: [Xen-devel] [PATCH v2 4/6] libxl: allow creation of domains
> with a specified or random domid
>
> On Mon, Jan 13
flight 146063 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146063/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
On 14.01.2020 11:05, Julien Grall wrote:
> On 14/01/2020 09:31, Jan Beulich wrote:
>> On 13.01.2020 22:33, Julien Grall wrote:
>>> From: Julien Grall
>>>
>>> None of the prototypes within the header asm-x86/irq.h actually requires
>>> the forward declaration of "struct pirq". So remove it.
>>>
>>>
Hi Jan,
On 14/01/2020 10:02, Jan Beulich wrote:
FIFO event channels allow ports up to 2^17, so we need to use a wider
field in struct pirq. Move "masked" such that it may share the 8-byte
slot with struct arch_pirq on 64-bit arches, rather than leaving a
7-byte hole in all cases.
Take the oppor
On 13/01/2020 14:40, Andrew Cooper wrote:
> On 13/01/2020 12:51, George Dunlap wrote:
>> So Sergey's second patch:
>> - Still denies XENVER_extraversion at the hypervisor level
>> - Leaves the value returned by the hypervisor as ""
>> - Filters the "" string at the hvmloader level, to prevent
On 14.01.2020 11:16, Julien Grall wrote:
> Hi Jan,
>
> On 14/01/2020 10:02, Jan Beulich wrote:
>> FIFO event channels allow ports up to 2^17, so we need to use a wider
>> field in struct pirq. Move "masked" such that it may share the 8-byte
>> slot with struct arch_pirq on 64-bit arches, rather th
On 14/01/2020 10:15, Jan Beulich wrote:
On 14.01.2020 11:05, Julien Grall wrote:
On 14/01/2020 09:31, Jan Beulich wrote:
On 13.01.2020 22:33, Julien Grall wrote:
From: Julien Grall
None of the prototypes within the header asm-x86/irq.h actually requires
the forward declaration of "struct pir
Hi Jan,
On 14/01/2020 10:23, Jan Beulich wrote:
On 14.01.2020 11:16, Julien Grall wrote:
Hi Jan,
On 14/01/2020 10:02, Jan Beulich wrote:
FIFO event channels allow ports up to 2^17, so we need to use a wider
field in struct pirq. Move "masked" such that it may share the 8-byte
slot with struct
On 14/01/2020 10:02, Jan Beulich wrote:
> FIFO event channels allow ports up to 2^17, so we need to use a wider
> field in struct pirq. Move "masked" such that it may share the 8-byte
> slot with struct arch_pirq on 64-bit arches, rather than leaving a
> 7-byte hole in all cases.
>
> Take the oppor
On Fri, Jan 10, 2020 at 05:51:06PM +, Ian Jackson wrote:
> Paul Durrant writes ("[PATCH] tools/Rules.mk: fix distclean"):
> > Running 'make distclean' under tools will currently result in:
> >
> > tools/Rules.mk:245: *** You have to run ./configure before building or
> > installing the tools.
On Mon, Jan 13, 2020 at 03:32:17PM +, Paul Durrant wrote:
> As agreed during the 2020-01 community call [1] this patch introduces a
> changelog, based on the principles explained at keepachangelog.com [2].
> A new MAINTAINERS entry is also added, with myself as (currently sole)
> maintainer.
>
On Fri, Jan 10, 2020 at 05:59:44PM +, Andrew Cooper wrote:
> On 10/01/2020 02:30, Tamas K Lengyel wrote:
> > The library has been largely untouched for over a decade at this point, it
> > is
> > undocumented and it's unclear what it was originally used for. Remove it
> > from
> > tree, if any
flight 146058 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146058/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-i386-xsmbroken
Tests whi
flight 146067 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146067/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
On 14/01/2020 11:48, Wei Liu wrote:
> On Fri, Jan 10, 2020 at 05:59:44PM +, Andrew Cooper wrote:
>> On 10/01/2020 02:30, Tamas K Lengyel wrote:
>>> The library has been largely untouched for over a decade at this point, it
>>> is
>>> undocumented and it's unclear what it was originally used fo
flight 146065 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146065/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
test-amd64-amd64-xl-qemuu
Hi Jan,
On 14/01/2020 09:37, Jan Beulich wrote:
On 13.01.2020 22:33, Julien Grall wrote:
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -41,9 +41,7 @@ struct vcpu *alloc_vcpu_struct(const struct domain *d);
void free_vcpu_struct(struct vcpu *v);
/* Allocate/free a PIRQ
Having Linux kernel drivers for 2.6 based kernels in the Xen tree is
not really needed any longer. So remove them from the tree.
In case anyone wants to look at them they are still available in
older branches.
Signed-off-by: Juergen Gross
---
.gitignore |
flight 146064 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146064/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 144665
test-amd64-amd64-xl-qemuu-ws16-amd64 17 g
With the 32 PAE build of Xen gone, 32bit PV guests' top level pagetables no
longer behave exactly like PAE in hardware.
They should have A/D bits set, for the same performance reasons as apply to
other levels. This brings the domain builder in line with how Xen constructs
a 32bit dom0.
As a pure
On Tue, Jan 14, 2020 at 01:34:45PM +0100, Juergen Gross wrote:
> Having Linux kernel drivers for 2.6 based kernels in the Xen tree is
> not really needed any longer. So remove them from the tree.
>
> In case anyone wants to look at them they are still available in
> older branches.
>
> Signed-off
On 14.01.2020 13:34, Juergen Gross wrote:
> Having Linux kernel drivers for 2.6 based kernels in the Xen tree is
> not really needed any longer. So remove them from the tree.
>
> In case anyone wants to look at them they are still available in
> older branches.
>
> Signed-off-by: Juergen Gross
On 14.01.2020 13:39, Andrew Cooper wrote:
> With the 32 PAE build of Xen gone, 32bit PV guests' top level pagetables no
> longer behave exactly like PAE in hardware.
>
> They should have A/D bits set, for the same performance reasons as apply to
> other levels. This brings the domain builder in l
On Tue, Jan 14, 2020 at 12:39:21PM +, Andrew Cooper wrote:
> With the 32 PAE build of Xen gone, 32bit PV guests' top level pagetables no
> longer behave exactly like PAE in hardware.
>
> They should have A/D bits set, for the same performance reasons as apply to
> other levels. This brings th
On 13/01/2020 17:50, Andrew Cooper wrote:
> It turns out that the note in c/s a8d27a54cc9cc
>
> Finally, leave a linker assert covering the fact that plenty of code blindly
> assumes that Xen is less that 16M. This wants fixing in due course.
>
> was easier to address than I had originally ant
flight 146070 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146070/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
Hi Paul,
On 14/01/2020 09:53, Durrant, Paul wrote:
-Original Message-
From: Xen-devel On Behalf Of
Julien Grall
Sent: 13 January 2020 23:12
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ; Wieczorkiewicz, Pawel
; Julien Grall ; Konrad Rzeszutek
Wilk
Subject: [Xen-devel] [PATCH
On Tue, Jan 14, 2020 at 4:28 AM Jan Beulich wrote:
>
> On 13.01.2020 20:40, Jason Andryuk wrote:
> > On Fri, Dec 27, 2019 at 11:09 AM Andrew Cooper
> > wrote:
> >>
> >> On 20/12/2019 16:23, Jan Beulich wrote:
> >>> On 16.09.2019 11:40, Jan Beulich wrote:
> Using memcpy() may result in multip
flight 146068 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146068/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 146048
build-armhf
Hi David,
On 13/01/2020 11:54, David Woodhouse wrote:
On Wed, 2020-01-08 at 17:24 +, David Woodhouse wrote:
When doing a live update, Xen needs to be very careful not to scribble
on pages which contain guest memory or state information for the
domains which are being preserved.
The informa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-312
arm: a CPU may speculate past the ERET instruction
ISSUE DESCRIPTION
=
Some CPUs can speculate past an ERET instruction and potentially perform
speculative accesses to mem
On 08.01.2020 16:23, Juergen Gross wrote:
> @@ -234,16 +233,6 @@ void domctl_lock_release(void)
> spin_unlock(¤t->domain->hypercall_deadlock_mutex);
> }
>
> -static inline
> -int vcpuaffinity_params_invalid(const struct xen_domctl_vcpuaffinity
> *vcpuaff)
> -{
> -return vcpuaff->flags
On 14.01.20 15:27, Jan Beulich wrote:
On 08.01.2020 16:23, Juergen Gross wrote:
@@ -234,16 +233,6 @@ void domctl_lock_release(void)
spin_unlock(¤t->domain->hypercall_deadlock_mutex);
}
-static inline
-int vcpuaffinity_params_invalid(const struct xen_domctl_vcpuaffinity *vcpuaff)
-{
-
"IRQ: u16 is too narrow for an event channel number" introduced a use of
evetchn_port_t, but its typedef apparently surfaces indirectly here only
on x86.
Signed-off-by: Jan Beulich
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
On 14/01/2020 14:35, Jan Beulich wrote:
> "IRQ: u16 is too narrow for an event channel number" introduced a use of
> evetchn_port_t, but its typedef apparently surfaces indirectly here only
> on x86.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 14.01.2020 15:33, Jürgen Groß wrote:
> On 14.01.20 15:27, Jan Beulich wrote:
>> On 08.01.2020 16:23, Juergen Gross wrote:
>>> +cpumask_t *cpupool_valid_cpus(struct cpupool *pool)
>>
>> const twice?
>
> See patch 9.
Well, in such a case either justify the omission in the description,
or introd
On Tue, Jan 14, 2020 at 5:04 AM Roger Pau Monné wrote:
>
> On Mon, Jan 13, 2020 at 02:01:47PM -0500, Jason Andryuk wrote:
> > On Fri, Mar 22, 2019 at 3:43 PM Jason Andryuk wrote:
> > >
> > > On Thu, Mar 21, 2019 at 11:09 PM Roger Pau Monné
> > > wrote:
> > > >
> > > > On Wed, Mar 20, 2019 at 01
On Tue, 2020-01-14 at 14:15 +, Julien Grall wrote:
> Hi David,
>
> On 13/01/2020 11:54, David Woodhouse wrote:
> > On Wed, 2020-01-08 at 17:24 +, David Woodhouse wrote:
> > > When doing a live update, Xen needs to be very careful not to scribble
> > > on pages which contain guest memory or
On 14.01.20 15:39, Jan Beulich wrote:
On 14.01.2020 15:33, Jürgen Groß wrote:
On 14.01.20 15:27, Jan Beulich wrote:
On 08.01.2020 16:23, Juergen Gross wrote:
+cpumask_t *cpupool_valid_cpus(struct cpupool *pool)
const twice?
See patch 9.
Well, in such a case either justify the omission i
On 14/01/2020 14:48, David Woodhouse wrote:
On Tue, 2020-01-14 at 14:15 +, Julien Grall wrote:
Hi David,
On 13/01/2020 11:54, David Woodhouse wrote:
On Wed, 2020-01-08 at 17:24 +, David Woodhouse wrote:
So we've settled on a simpler approach — reserve a contiguous region
of physica
On Tue, 2020-01-14 at 15:00 +, Julien Grall wrote:
>
> On 14/01/2020 14:48, David Woodhouse wrote:
> > On Tue, 2020-01-14 at 14:15 +, Julien Grall wrote:
> > > Hi David,
> > >
> > > On 13/01/2020 11:54, David Woodhouse wrote:
> > > > On Wed, 2020-01-08 at 17:24 +, David Woodhouse wrot
On 08.01.2020 16:23, Juergen Gross wrote:
> --- a/xen/common/sched/private.h
> +++ b/xen/common/sched/private.h
> @@ -533,6 +533,7 @@ static inline void sched_unit_unpause(const struct
> sched_unit *unit)
> struct cpupool
> {
> int cpupool_id;
> +#define CPUPOOLID_NONE-1
W
On 14.01.20 16:38, Jan Beulich wrote:
On 08.01.2020 16:23, Juergen Gross wrote:
--- a/xen/common/sched/private.h
+++ b/xen/common/sched/private.h
@@ -533,6 +533,7 @@ static inline void sched_unit_unpause(const struct
sched_unit *unit)
struct cpupool
{
int cpupool_id;
+#de
On 09.01.2020 14:48, Juergen Gross wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -81,6 +81,12 @@ config PERF_ARRAYS
> ---help---
> Enables software performance counter array histograms.
>
> +config DEBUG_BUGVERBOSE
> + bool "Verbose BUG_ON messages"
> + def
Andrew Cooper writes ("[PATCH 03/12] libxc/migration: Rationalise the
'checkpointed' field to 'stream_type'"):
> Originally, 'checkpointed' was a boolean signalling the difference between a
> plain and a Remus stream. COLO was added later, but several bits of code
> retained boolean-style logic.
On 14.01.20 16:47, Jan Beulich wrote:
On 09.01.2020 14:48, Juergen Gross wrote:
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -81,6 +81,12 @@ config PERF_ARRAYS
---help---
Enables software performance counter array histograms.
+config DEBUG_BUGVERBOSE
+ bool "Ver
Andrew Cooper writes ("[PATCH 04/12] libxc/migration: Adjust layout of struct
xc_sr_context"):
> We are shortly going to want to introduce some common x86 fields, so having
> x86_pv and x86_hvm as the top level objects is a problem. Insert a
> surrounding struct x86 and drop the x86 prefix from t
flight 146073 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146073/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
Andrew Cooper writes ("[PATCH 05/12] tools/migration: Drop IHDR_VERSION
constant from libxc and python"):
> Migration v3 is in the process of being introduced, meaning that the code has
> to cope with both versions. Use an explicit 2 for now.
>
> For the verify-stream-v2 and convert-legacy-strea
Andrew Cooper writes ("[PATCH 06/12] docs/migration Specify migration v3 and
STATIC_DATA_END"):
> Migration data can be split into two parts - that which is invariant of
> guest execution, and that which is not. Separate these two with the
> STATIC_DATA_END record.
>
> The short term, we want to
On 13.01.2020 22:33, Julien Grall wrote:
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -29,7 +29,8 @@
>
> bool hvm_domain_use_pirq(const struct domain *d, const struct pirq *pirq)
> {
> -return is_hvm_domain(d) && pirq && pirq->arch.hvm.emuirq != IRQ_UNBOUND;
> +ret
Andrew Cooper writes ("[PATCH 10/12] docs/migration: Specify
X86_{CPUID,MSR}_POLICY records"):
> These two records move blobs from the XEN_DOMCTL_{get,set}_cpu_policy
> hypercall.
We had an extensive IRL discussion recently about the compatibility
implications of this. Is that written down somew
On 14.01.2020 17:00, Jürgen Groß wrote:
> On 14.01.20 16:47, Jan Beulich wrote:
>> On 09.01.2020 14:48, Juergen Gross wrote:
>>> --- a/xen/Kconfig.debug
>>> +++ b/xen/Kconfig.debug
>>> @@ -81,6 +81,12 @@ config PERF_ARRAYS
>>> ---help---
>>> Enables software performance counter array hist
Andrew Cooper writes ("Re: [PATCH 10/12] docs/migration: Specify
X86_{CPUID,MSR}_POLICY records"):
> The migration stream is split into records with no playload (markers
> with external control flow meaning), and data records, which have a payload.
I remember thinking at the time you specified th
On 13.01.2020 18:50, Andrew Cooper wrote:
> Since c/s faa85d4fb3 "x86/boot: Don't map 0 during boot", l1_identmap no
> longer has an alias mapped at 0, meaning that none of the l?_identmap[]
> pagetables are actually an identity map.
>
> Rename them to l?_directmap, which avoids any kind of implic
On 13.01.2020 18:50, Andrew Cooper wrote:
> Despite being vaguely aware, the difference between PAGE_HYPERVISOR in ASM and
> C code has nevertheless caused several bugs I should have known better about,
> and contributed to review confusion.
>
> There are exactly 4 uses of these constants in asm c
Hi David,
On 14/01/2020 15:20, David Woodhouse wrote:
On Tue, 2020-01-14 at 15:00 +, Julien Grall wrote:
On 14/01/2020 14:48, David Woodhouse wrote:
On Tue, 2020-01-14 at 14:15 +, Julien Grall wrote:
Hi David,
On 13/01/2020 11:54, David Woodhouse wrote:
On Wed, 2020-01-08 at 17:24
Hi Jan,
On 14/01/2020 16:08, Jan Beulich wrote:
On 13.01.2020 22:33, Julien Grall wrote:
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -29,7 +29,8 @@
bool hvm_domain_use_pirq(const struct domain *d, const struct pirq *pirq)
{
-return is_hvm_domain(d) && pirq && pirq->
On 13.01.2020 18:50, Andrew Cooper wrote:
> The build-time construction of l2_xenmap[] imposes an arbitrary limit of 16M
> total, which is a limit looking to be lifted.
>
> Move l2_xenmap[] into the bss, and adjust both the BIOS and EFI paths to fill
> it in dynamically, based on the final linked
Andrew Cooper writes ("[PATCH 01/12] libxc/save: Shrink code volume where
possible"):
> A property of how the error handling (0 on success, nonzero otherwise)
> allows these calls to be chained together with the ternary operatior.
I'm quite surprised to find a suggestion like this coming from you
On 14.01.2020 17:26, Julien Grall wrote:
> On 14/01/2020 16:08, Jan Beulich wrote:
>> On 13.01.2020 22:33, Julien Grall wrote:
>>> --- a/xen/arch/x86/hvm/irq.c
>>> +++ b/xen/arch/x86/hvm/irq.c
>>> @@ -29,7 +29,8 @@
>>>
>>> bool hvm_domain_use_pirq(const struct domain *d, const struct pirq *pir
Andrew Cooper writes ("[PATCH 02/12] libxc/restore: Introduce functionality to
simplify blob handling"):
> During migration, we buffer several blobs of data which ultimately need
> handing back to Xen at an appropriate time.
>
> Currently, this is all handled in an ad-hoc manner, but more blobs a
Ian Jackson writes ("Re: [PATCH 01/12] libxc/save: Shrink code volume where
possible"):
> Maybe it would be better to have
> #define MUST(call) ({ rc = (call); if (rc) goto error; })
> and write
> MUST( write_one_vcpu_basic(ctx, i) );
This is not uncommon. BIND9 does something like it:
Andrew Cooper writes ("[PATCH 08/12] libxc/restore: Support v3 streams, and
cope with v2 compatibilty"):
> Introduce a static_data_complete() hook which is called when a
> STATIC_DATA_END record is found (v3) or inferred (v2).
>
> Modify handle_page_data() and handle_x86_pv_p2m_frames() to infer
On 13.01.2020 18:50, Andrew Cooper wrote:
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -687,14 +687,19 @@ trampoline_setup:
> * handling/walking), and identity map Xen into bootmap (needed for
> * the transition into long mode), using 2M superpages.
>
Hi,
On 14/01/2020 16:50, Jan Beulich wrote:
On 14.01.2020 17:26, Julien Grall wrote:
On 14/01/2020 16:08, Jan Beulich wrote:
On 13.01.2020 22:33, Julien Grall wrote:
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -29,7 +29,8 @@
bool hvm_domain_use_pirq(const struct domain
Andrew Cooper writes ("[PATCH 09/12] libxc/save: Write a v3 stream"):
> Introduce a new static_data() hook which is responsible for writing out
> any static data records. The HVM side continues to be a no-op, while
> the PV side moves write_x86_pv_info() into this earlier hook. The the
> common c
Andrew Cooper writes ("[PATCH 11/12] libxc/restore: Handle X86_{CPUID,MSR}_DATA
records"):
> For now, the data are just stashed, and discarded at the end. This will
> be addressed when the TODO in x86_static_data_complete() is addressed.
>
> No practical change to behaviour - this is all plumbin
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced:
Andrew Cooper writes ("[PATCH 12/12] libxc/save: Write X86_{CPUID,MSR}_DATA
records"):
> With all other plumbing in place, obtain the CPU Policy from Xen and
> write it into the migration stream.
This looks good to me but:
This patch may need revision to handle the results of our discussion
abou
Andrew Cooper writes ("[PATCH 16/20] tools/libxl: Simplify callback handling in
libxl-save-helper"):
> The {save,restore}_callback helpers can have their scope reduced vastly,
This part is OK with me although it would have been nicer to review if
the the move and the rename were separate patches.
On 14/01/2020 17:02, Jan Beulich wrote:
> On 13.01.2020 18:50, Andrew Cooper wrote:
>> --- a/xen/arch/x86/boot/head.S
>> +++ b/xen/arch/x86/boot/head.S
>> @@ -687,14 +687,19 @@ trampoline_setup:
>> * handling/walking), and identity map Xen into bootmap (needed for
>> * the trans
Andrew Cooper writes ("[PATCH 17/20] tools/libx[cl]: Plumb static_data_done()
up into libxl"):
> /* callbacks provided by xc_domain_restore */
> struct restore_callbacks {
> +/*
> + * Called once the STATIC_DATA_END record has been received/inferred.
> + * Passes in the blocks of sta
Andrew Cooper writes ("[PATCH 18/20] tools/libxl: Plumb domain_create_state
down into libxl__build_pre()"):
> To fix CPUID handling, libxl__build_pre() is going to have to distinguish
> between a brand new VM vs one which is being migrated-in/resumed.
Acked-by: Ian Jackson
_
Andrew Cooper writes ("[PATCH 19/20] tools/libxl: Re-position CPUID handling
during domain construction"):
> CPUID handling needs to be earlier in construction. Move it from its current
> position in libxl__build_post() to libxl__build_pre() for fresh builds, and
> libxl__srm_callout_callback_sta
Andrew Cooper writes ("[PATCH 20/20] tools/libxc: Restore CPUID/MSR data found
in the migration stream"):
> With libxl suitably adjusted, it is now safe to restore the CPUID/MSR data
> directly from the migration stream. Adjust the XGR_SDD_MISSING_* flags for
> the static_data_done() callback app
On 14/01/2020 17:33, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH 19/20] tools/libxl: Re-position CPUID handling
> during domain construction"):
>> CPUID handling needs to be earlier in construction. Move it from its current
>> position in libxl__build_post() to libxl__build_pre() for fresh
On Tue, Jan 14, 2020 at 09:41:46AM -0500, Jason Andryuk wrote:
> On Tue, Jan 14, 2020 at 5:04 AM Roger Pau Monné wrote:
> >
> > On Mon, Jan 13, 2020 at 02:01:47PM -0500, Jason Andryuk wrote:
> > > On Fri, Mar 22, 2019 at 3:43 PM Jason Andryuk wrote:
> > > >
> > > > On Thu, Mar 21, 2019 at 11:09 P
Andrew Cooper writes ("Re: [PATCH 19/20] tools/libxl: Re-position CPUID
handling during domain construction"):
> On 14/01/2020 17:33, Ian Jackson wrote:
> > Is it possible to split out the change to the sequencing, from the new
> > functionality ?
>
> Not easily, no.
Thanks for the explanation.
When placing BARs with sizes smaller than 4K multiple BARs can end
up mapped to the same guest physical address, and thus won't work
correctly.
Align all BARs placement to 4K in hvmloader to prevent such
overlapping.
Note that the guest can still move the BARs around and create this
collisions, a
On Thu, Jan 02, 2020 at 04:13:54PM -0500, Pavel Tatashin wrote:
> We currently duplicate the logic to enable/disable uaccess via TTBR0,
> with C functions and assembly macros. This is a maintenenace burden
> and is liable to lead to subtle bugs, so let's get rid of the assembly
> macros, and always
flight 146072 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146072/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
145767
Tests which did not suc
On Thu, Jan 02, 2020 at 04:13:56PM -0500, Pavel Tatashin wrote:
> The assmbly functions __asm_flush_cache_user_range and
> __asm_invalidate_icache_range have alternatives:
>
> alternative_if ARM64_HAS_CACHE_DIC
> ...
>
> alternative_if ARM64_HAS_CACHE_IDC
> ...
>
> But, the implementation of tho
flight 146081 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146081/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 146048
build-armhf
On 14/01/2020 16:45, Jan Beulich wrote:
> On 13.01.2020 18:50, Andrew Cooper wrote:
>> The build-time construction of l2_xenmap[] imposes an arbitrary limit of 16M
>> total, which is a limit looking to be lifted.
>>
>> Move l2_xenmap[] into the bss, and adjust both the BIOS and EFI paths to fill
>>
On Tue, Jan 14, 2020 at 12:30:02AM +0100, Rafael J. Wysocki wrote:
> On Mon, Jan 13, 2020 at 10:50 PM Rafael J. Wysocki wrote:
> >
> > On Mon, Jan 13, 2020 at 1:43 PM Peter Zijlstra wrote:
> > >
> > > On Mon, Jan 13, 2020 at 11:43:18AM +, Singh, Balbir wrote:
> > > > For your original comment
1 - 100 of 134 matches
Mail list logo
