flight 145842 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145842/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 145779
test-armhf-armhf-libvirt-raw 13
On 09.01.2020 11:07, George Dunlap wrote:
> On 1/9/20 5:40 AM, Juergen Gross wrote:
>> In expert mode it is possible to enable CONFIG_DEBUG_LOCKS without
>> having enabled CONFIG_DEBUG. The coding is depending on CONFIG_DEBUG
>> as it is using ASSERT(), however.
>
> Any reason not to use BUG_ON()
On 09.01.20 11:07, George Dunlap wrote:
On 1/9/20 5:40 AM, Juergen Gross wrote:
In expert mode it is possible to enable CONFIG_DEBUG_LOCKS without
having enabled CONFIG_DEBUG. The coding is depending on CONFIG_DEBUG
as it is using ASSERT(), however.
Any reason not to use BUG_ON() in that
On 1/9/20 10:30 AM, Jan Beulich wrote:
> On 09.01.2020 11:15, Jürgen Groß wrote:
>> On 09.01.20 11:07, George Dunlap wrote:
>>> On 1/9/20 5:40 AM, Juergen Gross wrote:
In expert mode it is possible to enable CONFIG_DEBUG_LOCKS without
having enabled CONFIG_DEBUG. The coding is depending
On Tue, Dec 24, 2019 at 07:17:52PM +0100, Roger Pau Monné wrote:
> On Tue, Dec 24, 2019 at 04:00:27PM +, Andrew Cooper wrote:
> > On 24/12/2019 12:42, Roger Pau Monné wrote:
> > > On Tue, Dec 24, 2019 at 12:23:12PM +, Andrew Cooper wrote:
> > >> On 24/12/2019 10:18, Roger Pau Monne wrote:
flight 145852 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145852/
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 09.01.2020 11:39, George Dunlap wrote:
> On 1/9/20 10:30 AM, Jan Beulich wrote:
>> On 09.01.2020 11:15, Jürgen Groß wrote:
>>> On 09.01.20 11:07, George Dunlap wrote:
On 1/9/20 5:40 AM, Juergen Gross wrote:
> In expert mode it is possible to enable CONFIG_DEBUG_LOCKS without
>
On 08.01.20 16:20, Sergey Dyasli wrote:
This enables to use Outline instrumentation for Xen PV kernels.
KASAN_INLINE and KASAN_VMALLOC options currently lead to boot crashes
and hence disabled.
Signed-off-by: Sergey Dyasli
---
RFC --> v1:
- New functions with declarations in xen/xen-ops.h
-
On Wed, Jan 08, 2020 at 12:51:35PM -0700, Tamas K Lengyel wrote:
> On Wed, Jan 8, 2020 at 11:37 AM Roger Pau Monné wrote:
> >
> > On Wed, Jan 08, 2020 at 11:14:46AM -0700, Tamas K Lengyel wrote:
> > > On Wed, Jan 8, 2020 at 11:01 AM Roger Pau Monné
> > > wrote:
> > > >
> > > > On Wed, Jan 08,
On 1/8/20 4:21 PM, Sergey Dyasli wrote:
> From: Ross Lagerwall
>
> When KASAN (or SLUB_DEBUG) is turned on, the normal expectation that
> allocations are aligned to the next power of 2 of the size does not
> hold.
Hmm, really? They should after 59bb47985c1d ("mm, sl[aou]b: guarantee
natural
libxl needs to be able to know when processes it forks have completed.
At the moment, libxl has two basic mode (with some variations). In
one mode -- libxl_sigchld_owner_libxl* -- libxl sets up its own
SIGCHLD signal handler, and also handles the event loop that allows
libxl to safely block
On 08/01/2020 17:14, Tamas K Lengyel wrote:
Implement hypercall that allows a fork to shed all memory that got allocated
for it during its execution and re-load its vCPU context from the parent VM.
This allows the forked VM to reset into the same state the parent VM is in a
faster way then
On 09.01.2020 11:15, Jürgen Groß wrote:
> On 09.01.20 11:07, George Dunlap wrote:
>> On 1/9/20 5:40 AM, Juergen Gross wrote:
>>> In expert mode it is possible to enable CONFIG_DEBUG_LOCKS without
>>> having enabled CONFIG_DEBUG. The coding is depending on CONFIG_DEBUG
>>> as it is using ASSERT(),
On 08.01.2020 18:00, Andrew Cooper wrote:
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -249,23 +249,24 @@ static void __init noreturn
> efi_arch_post_exit_boot(void)
> "or $"__stringify(X86_CR4_PGE)", %[cr4]\n\t"
> "mov
On 09/01/2020 10:52, Jan Beulich wrote:
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -554,7 +554,7 @@ static int do_boot_cpu(int apicid, int cpu)
printk("Booting processor %d/%d eip %lx\n",
cpu, apicid, start_eip);
-
branch xen-unstable
xenbranch xen-unstable
job build-amd64
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen
flight 145846 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145846/
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
Tests which are failing
On 08.01.2020 20:41, Andrew Cooper wrote:
> On 08/01/2020 11:23, Jan Beulich wrote:
This would then also ease shrinking the build
time mappings further, e.g. to the low 1Mb (instead of touching
several of the places you touch now, it would again mainly be an
adjustment to
On 1/9/20 5:40 AM, Juergen Gross wrote:
> In expert mode it is possible to enable CONFIG_DEBUG_LOCKS without
> having enabled CONFIG_DEBUG. The coding is depending on CONFIG_DEBUG
> as it is using ASSERT(), however.
Any reason not to use BUG_ON() in that case?
Having two different asserts is
On 09.01.20 11:45, Jan Beulich wrote:
On 09.01.2020 11:39, George Dunlap wrote:
On 1/9/20 10:30 AM, Jan Beulich wrote:
On 09.01.2020 11:15, Jürgen Groß wrote:
On 09.01.20 11:07, George Dunlap wrote:
On 1/9/20 5:40 AM, Juergen Gross wrote:
In expert mode it is possible to enable
On 09.01.2020 11:43, Andrew Cooper wrote:
> On 09/01/2020 10:28, Jan Beulich wrote:
>> On 08.01.2020 18:00, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/efi/efi-boot.h
>>> +++ b/xen/arch/x86/efi/efi-boot.h
>>> @@ -249,23 +249,24 @@ static void __init noreturn
>>> efi_arch_post_exit_boot(void)
>>>
The top (numerically higher addresses) of cpu0_stack[] contains the BSP's
cpu_info block. Logic in Xen expects this to be initialised to 0, but this
area of stack is also used during early boot.
Update the head.S code to avoid using the cpu_info block. Additionally,
update the stack_start
Hi Tamas,
On 08/01/2020 17:14, Tamas K Lengyel wrote:
+static int mem_sharing_fork(struct domain *d, struct domain *cd)
+{
+int rc;
+
+if ( !d->controller_pause_count &&
+ (rc = domain_pause_by_systemcontroller(d)) )
AFAIU, the parent domain will be paused if it wasn't paused
On 09/01/2020 10:28, Jan Beulich wrote:
> On 08.01.2020 18:00, Andrew Cooper wrote:
>> --- a/xen/arch/x86/efi/efi-boot.h
>> +++ b/xen/arch/x86/efi/efi-boot.h
>> @@ -249,23 +249,24 @@ static void __init noreturn
>> efi_arch_post_exit_boot(void)
>> "or
On Thu, Jan 09, 2020 at 10:43:01AM +0100, Jan Beulich wrote:
> On 08.01.2020 19:14, Roger Pau Monné wrote:
> > On Wed, Jan 08, 2020 at 02:54:57PM +0100, Jan Beulich wrote:
> >> On 08.01.2020 14:30, Roger Pau Monné wrote:
> >>> On Fri, Jan 03, 2020 at 01:55:51PM +0100, Jan Beulich wrote:
> On
A domid is considered retired if the domain it represents was destroyed
less than a specified number of seconds ago. The number can be set using
the environment variable LIBXL_DOMID_MAX_RETIREMENT. If the variable does
not exist then a default value of 60s is used.
Whenever a domain is destroyed,
Anchal Agarwal writes:
> On Wed, Jan 08, 2020 at 04:23:25PM +0100, Thomas Gleixner wrote:
>> Anchal Agarwal writes:
>> > +void irq_state_clr_started(struct irq_desc *desc)
>> > {
>> >irqd_clear(>irq_data, IRQD_IRQ_STARTED);
>> > }
>> > +EXPORT_SYMBOL_GPL(irq_state_clr_started);
>>
>> This
On Thu, Jan 09, 2020 at 12:24:05PM +0100, Roger Pau Monné wrote:
> On Thu, Jan 09, 2020 at 10:43:01AM +0100, Jan Beulich wrote:
> > On 08.01.2020 19:14, Roger Pau Monné wrote:
> > > On Wed, Jan 08, 2020 at 02:54:57PM +0100, Jan Beulich wrote:
> > >> On 08.01.2020 14:30, Roger Pau Monné wrote:
> >
Hi Lars, I've just updated the list, please let me know if you have any
comments.
-- Felipe
Dr. Felipe Huici
Chief Researcher, Systems and Machine Learning Group
NEC Laboratories Europe GmbH
Kurfuerstenanlage 36, D-69115 Heidelberg
On 08.01.2020 18:09, Andrew Cooper wrote:
> On 08/01/2020 16:55, Jan Beulich wrote:
>> On 08.01.2020 17:15, Andrew Cooper wrote:
>>> On 08/01/2020 11:38, Jan Beulich wrote:
As said - I'm going to try to not stand in the way of you re-
arranging this, but
- the new code should not
On 08.01.2020 19:14, Roger Pau Monné wrote:
> On Wed, Jan 08, 2020 at 02:54:57PM +0100, Jan Beulich wrote:
>> On 08.01.2020 14:30, Roger Pau Monné wrote:
>>> On Fri, Jan 03, 2020 at 01:55:51PM +0100, Jan Beulich wrote:
On 03.01.2020 13:34, Roger Pau Monné wrote:
> On Fri, Jan 03, 2020 at
Running 'make distclean' under tools will currently result in:
tools/Rules.mk:245: *** You have to run ./configure before building or
installing the tools. Stop.
This patch adds 'distclean', 'subdir-distclean%' and 'subdir-clean%' to
no-configure-targets, which allows 'make distclean' to run
Currently both xl and libxl have internal definitions of INVALID_DOMID
which happen to be identical. However, for the purposes of describing the
behaviour of libxl_domain_create_new/restore() it is useful to have a
specified invalid value for a domain id.
This patch therefore moves the libxl
This patch adds a '-D' command line option to save and migrate to allow
the domain id to be incorporated into the saved domain configuration and
hence be preserved.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
v2:
- Heavily re-worked based on new libxl_domain_create_info
---
This patch adds a new global 'domid_policy' configuration option to decide
how domain id values are allocated for new domains. It may be set to one of
two values:
"xen", the default value, will cause an invalid domid value to be passed
to do_domain_create() preserving the existing behaviour of
This series was previously named "xl/libxl: allow creation of domains with
a specified domid".
Paul Durrant (6):
libxl: add definition of INVALID_DOMID to the API
libxl_create: make 'soft reset' explicit
libxl: add infrastructure to track and query 'retired' domids
libxl: allow creation
The 'soft reset' code path in libxl__domain_make() is currently taken if a
valid domid is passed into the function. A subsequent patch will enable
higher levels of the toolstack to determine the domid of newly created or
restored domains and therefore this criteria for choosing 'soft reset'
will
This patch adds a 'domid' field to libxl_domain_create_info and then
modifies do_domain_create() to use that value if it is valid. Any valid
domid will be checked against the retired domid list before being passed
to libxl__domain_make().
If the domid value is invalid then Xen will choose the
libxl needs to be able to know when processes it forks have completed.
At the moment, libxl has two basic mode (with some variations). In
one mode -- libxl_sigchld_owner_libxl* -- libxl sets up its own
SIGCHLD signal handler, and also handles the event loop that allows
libxl to safely block
No functional changes.
Signed-off-by: George Dunlap
---
CC: Ian Jackson
CC: Wei Liu
CC: Anthony Perard
---
tools/libxl/libxl_event.h| 2 +-
tools/libxl/libxl_fork.c | 4 ++--
tools/libxl/libxl_internal.h | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git
On Thu, Jan 9, 2020 at 3:29 AM Julien Grall wrote:
>
> Hi Tamas,
>
> On 08/01/2020 17:14, Tamas K Lengyel wrote:
> > +static int mem_sharing_fork(struct domain *d, struct domain *cd)
> > +{
> > +int rc;
> > +
> > +if ( !d->controller_pause_count &&
> > + (rc =
flight 145858 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145858/
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
> -Original Message-
> From: Wei Liu
> Sent: 09 January 2020 13:52
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Ian Jackson
> ; Wei Liu ; Anthony PERARD
>
> Subject: Re: [PATCH] tools/Rules.mk: fix distclean
>
> On Thu, Jan 09, 2020 at 11:15:05AM +, Paul Durrant wrote:
flight 145866 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145866/
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 Thu, Jan 9, 2020 at 8:34 AM Jan Beulich wrote:
>
> On 09.01.2020 16:10, Roger Pau Monné wrote:
> > On Thu, Jan 09, 2020 at 06:41:12AM -0700, Tamas K Lengyel wrote:
> >> On Thu, Jan 9, 2020 at 3:29 AM Julien Grall wrote:
> >>>
> >>> Hi Tamas,
> >>>
> >>> On 08/01/2020 17:14, Tamas K Lengyel
On Wed, Jan 08, 2020 at 03:55:52PM +, Will Deacon wrote:
> On Thu, Dec 19, 2019 at 01:07:50PM -0800, Stefano Stabellini wrote:
> > On Thu, 19 Dec 2019, Mark Brown wrote:
> > > In an effort to clarify and simplify the annotation of assembly functions
> > > in the kernel new macros have been
On Thu, Jan 9, 2020 at 9:03 AM Jan Beulich wrote:
>
> On 09.01.2020 16:57, Tamas K Lengyel wrote:
> > On Thu, Jan 9, 2020 at 8:34 AM Jan Beulich wrote:
> >>
> >> On 09.01.2020 16:10, Roger Pau Monné wrote:
> >>> On Thu, Jan 09, 2020 at 06:41:12AM -0700, Tamas K Lengyel wrote:
> On Thu, Jan
On Wed, 8 Jan 2020 at 15:21, Sergey Dyasli wrote:
>
> From: Ross Lagerwall
>
> When KASAN (or SLUB_DEBUG) is turned on, the normal expectation that
> allocations are aligned to the next power of 2 of the size does not
> hold. Therefore, handle grant copies that cross page boundaries.
>
>
flight 145859 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145859/
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 03/01/2020 14:44, Jan Beulich wrote:
> On 24.12.2019 16:19, Andrew Cooper wrote:
>> 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 move
Today a triggering BUG_ON() will only print source file and line
information. Add the possibility to print the triggering condition like
ASSERT().
Do that by introducing BUG_ON_VERBOSE() and add a Kconfig option to
make BUG_ON use BUG_ON_VERBOSE().
Signed-off-by: Juergen Gross
---
On Wed, Jan 08, 2020 at 05:53:36PM +, Andrew Cooper wrote:
> On 08/01/2020 17:43, Wei Liu wrote:
> > On Tue, Jan 07, 2020 at 03:42:14PM +, Wei Liu wrote:
> >> On Sun, Jan 05, 2020 at 09:57:56PM +, Andrew Cooper wrote:
> >> [...]
> > The locked bit is probably a good idea, but one
In expert mode it is possible to enable CONFIG_DEBUG_LOCKS without
having enabled CONFIG_DEBUG. The coding is depending on CONFIG_DEBUG
as it is using ASSERT(), however.
Fix that by using BUG_ON() instead of ASSERT() in rel_lock().
Signed-off-by: Juergen Gross
---
xen/common/spinlock.c | 2 +-
CONFIG_DEBUG_LOCKS is using ASSERT() for catching issues making it
depend on CONFIG_DEBUG.
This series fixes that by using BUG_ON() instead. In order not to lose
the rather nice debugging information which condition was hit add a
config option to include a message similar to the one ASSERT() is
On Mon, 2019-12-02 at 19:51 +, Andrew Cooper wrote:
> ...
>
> Other areas in need of work is the boot time directmap at 0 (which
> hides
> NULL pointer deferences during boot), and the correct handling of
> %dr6
> for all kinds of guests.
>
Sorry for the late reply to this thread. Talking
On Thu, Jan 9, 2020 at 8:10 AM Roger Pau Monné wrote:
>
> On Thu, Jan 09, 2020 at 06:41:12AM -0700, Tamas K Lengyel wrote:
> > On Thu, Jan 9, 2020 at 3:29 AM Julien Grall wrote:
> > >
> > > Hi Tamas,
> > >
> > > On 08/01/2020 17:14, Tamas K Lengyel wrote:
> > > > +static int
flight 145854 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145854/
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
On 09.01.2020 16:57, Tamas K Lengyel wrote:
> On Thu, Jan 9, 2020 at 8:34 AM Jan Beulich wrote:
>>
>> On 09.01.2020 16:10, Roger Pau Monné wrote:
>>> On Thu, Jan 09, 2020 at 06:41:12AM -0700, Tamas K Lengyel wrote:
On Thu, Jan 9, 2020 at 3:29 AM Julien Grall wrote:
>
> Hi Tamas,
On Thu, Jan 9, 2020 at 2:48 AM Roger Pau Monné wrote:
>
> On Wed, Jan 08, 2020 at 12:51:35PM -0700, Tamas K Lengyel wrote:
> > On Wed, Jan 8, 2020 at 11:37 AM Roger Pau Monné
> > wrote:
> > >
> > > On Wed, Jan 08, 2020 at 11:14:46AM -0700, Tamas K Lengyel wrote:
> > > > On Wed, Jan 8, 2020 at
On Thu, Jan 09, 2020 at 11:15:05AM +, Paul Durrant wrote:
> Running 'make distclean' under tools will currently result in:
>
> tools/Rules.mk:245: *** You have to run ./configure before building or
> installing the tools. Stop.
>
> This patch adds 'distclean', 'subdir-distclean%' and
> On Dec 16, 2019, at 03:31, Jürgen Groß wrote:
>
> On 16.12.19 09:18, Durrant, Paul wrote:
>>> -Original Message-
>>> From: Jürgen Groß
>>> Sent: 16 December 2019 08:10
>>> To: Durrant, Paul ; David Miller
>>>
>>> Cc: xen-devel@lists.xenproject.org; wei@kernel.org; linux-
>>>
On 09.01.2020 12:51, Andrew Cooper wrote:
> The top (numerically higher addresses) of cpu0_stack[] contains the BSP's
> cpu_info block. Logic in Xen expects this to be initialised to 0, but this
> area of stack is also used during early boot.
>
> Update the head.S code to avoid using the
On 09.01.2020 14:48, Juergen Gross wrote:
> In expert mode it is possible to enable CONFIG_DEBUG_LOCKS without
> having enabled CONFIG_DEBUG. The coding is depending on CONFIG_DEBUG
> as it is using ASSERT(), however.
>
> Fix that by using BUG_ON() instead of ASSERT() in rel_lock().
>
>
On 09.01.2020 16:10, Roger Pau Monné wrote:
> On Thu, Jan 09, 2020 at 06:41:12AM -0700, Tamas K Lengyel wrote:
>> On Thu, Jan 9, 2020 at 3:29 AM Julien Grall wrote:
>>>
>>> Hi Tamas,
>>>
>>> On 08/01/2020 17:14, Tamas K Lengyel wrote:
+static int mem_sharing_fork(struct domain *d, struct
If the IPI destination mask matches the mask of online CPUs use the
APIC ALLBUT destination shorthand in order to send an IPI to all CPUs
on the system except the current one. This can only be safely used
when no CPU hotplug or unplug operations are taking place, no offline
CPUs or those have been
On Thu, Jan 09, 2020 at 08:33:37AM -0800, Stefano Stabellini wrote:
> On Thu, 9 Jan 2020, Catalin Marinas wrote:
> > On Wed, Jan 08, 2020 at 03:55:52PM +, Will Deacon wrote:
> > > On Thu, Dec 19, 2019 at 01:07:50PM -0800, Stefano Stabellini wrote:
> > > > On Thu, 19 Dec 2019, Mark Brown wrote:
flight 145867 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145867/
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
On Thu, Jan 09, 2020 at 02:02:55PM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Wei Liu
> > Sent: 09 January 2020 13:52
> > To: Durrant, Paul
> > Cc: xen-devel@lists.xenproject.org; Ian Jackson
> > ; Wei Liu ; Anthony PERARD
> >
> > Subject: Re: [PATCH] tools/Rules.mk:
On 1/9/20 12:12 PM, George Dunlap wrote:
> libxl needs to be able to know when processes it forks have completed.
>
> At the moment, libxl has two basic mode (with some variations). In
> one mode -- libxl_sigchld_owner_libxl* -- libxl sets up its own
> SIGCHLD signal handler, and also handles
On Thu, 9 Jan 2020, Catalin Marinas wrote:
> On Wed, Jan 08, 2020 at 03:55:52PM +, Will Deacon wrote:
> > On Thu, Dec 19, 2019 at 01:07:50PM -0800, Stefano Stabellini wrote:
> > > On Thu, 19 Dec 2019, Mark Brown wrote:
> > > > In an effort to clarify and simplify the annotation of assembly
>
flight 145873 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145873/
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
flight 145871 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145871/
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
flight 145851 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145851/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 145826
Tests which did not
On Thu, Jan 09, 2020 at 06:41:12AM -0700, Tamas K Lengyel wrote:
> On Thu, Jan 9, 2020 at 3:29 AM Julien Grall wrote:
> >
> > Hi Tamas,
> >
> > On 08/01/2020 17:14, Tamas K Lengyel wrote:
> > > +static int mem_sharing_fork(struct domain *d, struct domain *cd)
> > > +{
> > > +int rc;
> > > +
>
On 03/01/2020 15:30, Jan Beulich wrote:
> On 03.01.2020 15:55, Andrew Cooper wrote:
>> On 03/01/2020 14:49, Jan Beulich wrote:
>>> On 24.12.2019 16:19, Andrew Cooper wrote:
@@ -439,6 +449,34 @@ def verify_record_static_data_end(self, content):
raise RecordError("Static data
These are left over from c/s b2804422 "x86: make Xen early boot code
relocatable", which made it possible for Xen not to be in the bottom 16M.
Nothing using the mappings any more. Build them in the directmap when walking
the E820 table along with everything else.
Furthermore, it is undefined to
The need for Xen to be identity mapped into the bootmap is not obvious, and
differs between the MB and EFI boot paths.
The EFI side is further complicated by an attempt to cope with with l2_bootmap
only being 4k long. This is undocumented, confusing, only works if Xen is the
single object
This is the (long overdue) series which finally removes the mapping at 0
during early boot, which has bitten us in the past. It also removes an RWX
gadget which persists past boot in the idle pagetables.
Most of the complexity was down to the differing (and hard-to-follow) uses of
the bootmap.
flight 145877 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145877/
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
Now that NULL will fault at boot, there is no need for a special constant to
signify "current not set up yet".
Since c/s fae249d23413 "x86/boot: Rationalise stack handling during early
boot", the BSP cpu_info block is now consistently zero, so drop the adjacent
re-zeroing.
Signed-off-by: Andrew
In particular, it causes accidental NULL pointer dereferences to go unnoticed.
The majority of the early operation takes place either in Real mode, or
Protected Unpaged mode. The only bit which requires pagetable mappings is the
trampoline transition into Long mode and jump to the higher
Dear Xen Devs,
commit 2529c850ea48f036727ca2f148caed89391311b8 introduces the
XEN_RUNSTATE_UPDATE marker bit, which is not handled in
vcpu_runstate_get() in xen/common/schedule.c. Relevant code:
delta = NOW() - runstate->state_entry_time;
if ( delta > 0 )
2020-01-09 20:50 időpontban Andrew Cooper ezt írta:
On 09/01/2020 19:40, Richard Kojedzinszky wrote:
Dear Xen Devs,
commit 2529c850ea48f036727ca2f148caed89391311b8 introduces the
XEN_RUNSTATE_UPDATE marker bit, which is not handled in
vcpu_runstate_get() in xen/common/schedule.c. Relevant
2020-01-09 21:10 időpontban Andrew Cooper ezt írta:
On 09/01/2020 20:09, Richard Kojedzinszky wrote:
2020-01-09 20:50 időpontban Andrew Cooper ezt írta:
On 09/01/2020 19:40, Richard Kojedzinszky wrote:
Dear Xen Devs,
commit 2529c850ea48f036727ca2f148caed89391311b8 introduces the
On 09/01/2020 20:09, Richard Kojedzinszky wrote:
> 2020-01-09 20:50 időpontban Andrew Cooper ezt írta:
>> On 09/01/2020 19:40, Richard Kojedzinszky wrote:
>>> Dear Xen Devs,
>>>
>>> commit 2529c850ea48f036727ca2f148caed89391311b8 introduces the
>>> XEN_RUNSTATE_UPDATE marker bit, which is not
flight 145884 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145884/
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 Thu, Jan 09, 2020 at 01:07:27PM +0100, Thomas Gleixner wrote:
> Anchal Agarwal writes:
> > On Wed, Jan 08, 2020 at 04:23:25PM +0100, Thomas Gleixner wrote:
> >> Anchal Agarwal writes:
> >> > +void irq_state_clr_started(struct irq_desc *desc)
> >> > {
> >> > irqd_clear(>irq_data,
On 1/9/20 6:46 PM, Boris Ostrovsky wrote:
On 1/7/20 6:37 PM, Anchal Agarwal wrote:
+
+static int xen_setup_pm_notifier(void)
+{
+ if (!xen_hvm_domain())
+ return -ENODEV;
ARM guests are also HVM domains. Is it OK for them to register the
notifier? The diffstat suggests that you
On Wed, 8 Jan 2020, Lars Kurth wrote:
> @Stefano, @Julien: the 5 projects below are against you - are these still
> valid?
> @Julien: these are against your Arm address
> https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Xen_Hypervisor
> -
>
On Thu, Jan 09, 2020 at 06:49:07PM -0500, Boris Ostrovsky wrote:
>
>
> On 1/9/20 6:46 PM, Boris Ostrovsky wrote:
> >
> >
> >On 1/7/20 6:37 PM, Anchal Agarwal wrote:
> >>+
> >>+static int xen_setup_pm_notifier(void)
> >>+{
> >>+ if (!xen_hvm_domain())
> >>+ return -ENODEV;
> >
> >ARM
I'd like some feedback on these patches. Parts I particularly want
feedback on are listed below and each patch will have a copy of the
relevant parts requesting feedback. Any feedback is welcomed though.
Also, the commit messages are a little rough.
Patch 1:
- Check in device_tree.c. This is
Modify the smmu driver so that it uses the iommu_fwspec helper
functions. This means both ARM IOMMU drivers will both use the
iommu_fwspec helper functions, making enabling generic device tree
bindings in the SMMU driver much cleaner.
Signed-off-by: Brian Woods
---
RFC especially wanted on:
-
Restructure some of the code and add supporting functions for adding
generic device tree (DT) binding support. The normal add_device and
dt_xlate functions are wrappers of the legacy functions due to legacy
calls needing more arguments because the find_smmu can't a smmu that
isn't initialized.
flight 145888 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145888/
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 1/8/20 10:20 AM, Sergey Dyasli wrote:
@@ -1943,6 +1973,15 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd,
unsigned long max_pfn)
if (i && i < pgd_index(__START_KERNEL_map))
init_top_pgt[i] = ((pgd_t *)xen_start_info->pt_base)[i];
+#ifdef CONFIG_KASAN
+
On 1/7/20 6:37 PM, Anchal Agarwal wrote:
+
+static int xen_setup_pm_notifier(void)
+{
+ if (!xen_hvm_domain())
+ return -ENODEV;
ARM guests are also HVM domains. Is it OK for them to register the
notifier? The diffstat suggests that you are supporting ARM.
-boris
+
+
branch xen-unstable
xenbranch xen-unstable
job build-i386-xsm
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen
On 09/01/2020 19:40, Richard Kojedzinszky wrote:
> Dear Xen Devs,
>
> commit 2529c850ea48f036727ca2f148caed89391311b8 introduces the
> XEN_RUNSTATE_UPDATE marker bit, which is not handled in
> vcpu_runstate_get() in xen/common/schedule.c. Relevant code:
>
> delta = NOW() -
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-ovmf-amd64
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 https://github.com/tianocore/edk2.git
Tree: qemu
flight 145902 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/145902/
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
1 - 100 of 106 matches
Mail list logo
