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
Tel
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 i
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
- Fi
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 bre
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 BOOTS
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
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, 20
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 saveresto
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 almo
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 case?
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 b
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 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 crea
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 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 alig
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 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 $"__stringify(X86_CR4_P
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
> havi
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 until
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: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)
>>>
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 CONFIG_DEBUG
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);
-s
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 to
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
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 defin
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
---
d
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 hav
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 of
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 no
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 domid
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,
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 variab
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(&desc->irq_data, IRQD_IRQ_STARTED);
>> > }
>> > +EXPORT_SYMBOL_GPL(irq_state_clr_started);
>>
>>
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 until
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 a/tools/li
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:
> >
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 git://xe
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 11
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.
>
> Signed-o
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 = domain_pause_by_syste
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 as
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
---
xen/Kconfig.d
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
pr
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 'subdi
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 1
> 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-
>>> ker.
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
> -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:
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 cpu_info
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().
>
> Signed-of
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 the
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;
> > > +
>
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 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 e
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 doma
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 ab
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 mem_sharing_fork(stru
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 wro
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 intr
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
test-amd64-i386-xl-qemu
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 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 9
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, 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
> >
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:
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: fi
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 the
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 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 1
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 succeed
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
test-amd64-i386-xl-qemu
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. I
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 wanting
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 C
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 mappings
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 )
runstate->time[runstat
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() - runstate->state_entry
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 code:
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
XEN_RUNSTATE_
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 handl
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
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 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 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(&desc->irq_data
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
+
+
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
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 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 gue
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
> -
> https://wiki.xenproject.org/wiki/Outreach_Prog
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 git:/
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.
Si
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 git://xenb
Only tools/tests/mem-sharing is maintained under the tools folder.
Signed-off-by: Tamas K Lengyel
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a42fef6ab9..21744ace6d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -504,7 +504,7
1 - 100 of 106 matches
Mail list logo
