On 15/01/2019 17:58, Jan Beulich wrote:
> While in the native case entry into the kernel happens on the trampoline
> stack, PV Xen kernels get entered with the current thread stack right
> away. Hence source and destination stacks are identical in that case,
> and special care is needed.
>
>
>>> On 16.01.19 at 10:00, wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -636,61 +636,83 @@ trace feature is only enabled in debugging builds of
> Xen.
>
> Specify the bit width of the DMA heap.
>
> -### dom0 (x86)
> -> `= List of [ pvh |
> -Original Message-
> From: Alex Bennée [mailto:alex.ben...@linaro.org]
> Sent: 16 January 2019 12:14
> To: peter.mayd...@linaro.org
> Cc: qemu-de...@nongnu.org; Alex Bennée ; Stefano
> Stabellini ; Anthony Perard
> ; Paul Durrant ; Kevin
> Wolf ; Max Reitz ; open list:X86
> ; open
>>> On 16.01.19 at 13:20, wrote:
> Do you think it makes sense to add a domctl to enable/disable MSI(X)?
A domctl looks odd for an operation like this; I'd rather consider
adding a physdevop if a new (sub)hypercall is needed here (of
which I'm not yet convinced; I have yet to look at the patch).
On Wed, Jan 16, 2019 at 08:50:13AM +0100, Juergen Gross wrote:
> @@ -1650,13 +1650,14 @@ void xen_callback_vector(void)
> xen_have_vector_callback = 0;
> return;
> }
> - pr_info("Xen HVM callback vector for event
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: f94c8d116997 sched/clock, x86/tsc: Rework the x86 'unstable'
sched_clock() interface.
The bot has tested the following trees: v4.20.2, v4.19.15, v4.14.93.
v4.20.2: Build OK!
flight 131963 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131963/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 131842
build-i386
>>> On 16.01.19 at 10:00, wrote:
> Update parse_efi_param() to use parse_boolean() for "rs", so it behaves
> like other Xen booleans.
>
> However, change "attr=uc" to not be a boolean. This is a functional
> change, but "no-attr=uc" is ambiguous and shouldn't be accepted.
"no-attr=uc" is of
On Wed, Jan 16, 2019 at 09:47:41PM +0800, Dongli Zhang wrote:
> There is no need to wake up xen_blkif_schedule() as kthread_stop() is able
> to already wake up the kernel thread.
>
> Signed-off-by: Dongli Zhang
Reviewed-by: Roger Pau Monné
kthread_stop waits for the thread to exit, so it must
On 1/16/19 9:46 AM, Juergen Gross wrote:
> The syntax for the release note link in SUPPORT.md is wrong. Correct
> that.
>
> Signed-off-by: Juergen Gross > ---
> SUPPORT.md | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/SUPPORT.md b/SUPPORT.md
> index
On Wed, Jan 16, 2019 at 09:00:45AM +, Andrew Cooper wrote:
> Update parse_iommu_param() to uniformly use parse_boolean(), so the sub
> booleans behave like other Xen boolean options. Reposition the
> custom_param() to avoid a forward declaration of parse_iommu_param().
>
> Rewrite the
On 16/01/2019 10:00, Andrew Cooper wrote:
> This is logically two series, but they were co-developed and tightly coupled.
>
> The first 4 patches are improvements to our documentation and command line
> parsing. It fixes two key issues - first that sub-booleans now all behave
> consistently, and
On 14/01/2019 12:40, Jan Beulich wrote:
> For VPSADBW this likely was a result of bad copy-and-paste.
>
> For VPS{L,R}LDQ comment and code were not in line, but then again the
> comment also wasn't fully updated from the AVX2 original it got cloned
> from.
>
> Signed-off-by: Jan Beulich
On Wed, Jan 16, 2019 at 09:00:49AM +, Andrew Cooper wrote:
> This option is unique to x86 PV dom0's, but it is not sensible to have a
> catch-all which blindly maps all non-RAM regions into the IOMMU.
>
> The map-reserved option remains, and covers all the buggy firmware issues that
> I am
target_cmd_output_root_status prints the command exit status. If that
was a failure and the failure was as expected, this can be confusing
to readers who do not know that this is a possibility. So print a
message about it.
Signed-off-by: Ian Jackson
CC: Konrad Rzeszutek Wilk
---
As all the memblock allocation functions return NULL in case of error
rather than panic(), the duplicates with _nopanic suffix can be removed.
Signed-off-by: Mike Rapoport
---
arch/arc/kernel/unwind.c | 3 +--
arch/sh/mm/init.c | 2 +-
arch/x86/kernel/setup_percpu.c | 10
>>> On 16.01.19 at 10:00, wrote:
>[...]
> +The functionality in an IOMMU commonly falls into two orthogonal categories:
>
> -> Default: `false`
> -
> ->> Don't continue booting unless IOMMU support is found and can be
> initialized
> ->> successfully.
> +1. DMA remapping which uses a
On Wed, Jan 16, 2019 at 09:47:41PM +0800, Dongli Zhang wrote:
> There is no need to wake up xen_blkif_schedule() as kthread_stop() is able
> to already wake up the kernel thread.
>
> Signed-off-by: Dongli Zhang
> ---
> drivers/block/xen-blkback/xenbus.c | 4 +---
> 1 file changed, 1
Trivial format string fix to solve:
hw/block/xen-block.c: In function 'xen_block_realize':
hw/block/xen-block.c:218:53: error: format '%lu' expects argument of type
'long unsigned int', but argument 4 has type 'int64_t {aka long long int}'
[-Werror=format=]
On Tue, Jan 8, 2019 at 8:32 AM Jan Beulich wrote:
>
> >>> On 07.01.19 at 18:28, wrote:
> > On 07/01/2019 08:59, Jan Beulich wrote:
> >>> @@ -271,6 +297,27 @@ int parse_boolean(const char *name, const char *s,
> > const char *e)
> >>> return -1;
> >>> }
> >>>
> >>> +int cmdline_strcmp(const
flight 131961 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131961/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm broken in 131948
build-amd64-pvops
>>> On 16.01.19 at 13:08, wrote:
> On Tue, Jan 8, 2019 at 8:32 AM Jan Beulich wrote:
>>
>> >>> On 07.01.19 at 18:28, wrote:
>> > On 07/01/2019 08:59, Jan Beulich wrote:
>> >>> @@ -271,6 +297,27 @@ int parse_boolean(const char *name, const char *s,
>> > const char *e)
>> >>> return -1;
>>
>>> On 16.01.19 at 10:00, wrote:
> Alter parse_pci_param() to use parse_boolean(), so the sub options
> behave like other Xen booleans.
>
> Update the command line documentation for consistency.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
The memblock_alloc_base_nid() is a oneliner wrapper for
memblock_alloc_range_nid() without any side effect.
Replace it's usage by the direct calls to memblock_alloc_range_nid().
Signed-off-by: Mike Rapoport
---
include/linux/memblock.h | 3 ---
mm/memblock.c| 15 ---
2
Make the memblock_phys_alloc() function an inline wrapper for
memblock_phys_alloc_range() and update the memblock_phys_alloc() callers to
check the returned value and panic in case of error.
Signed-off-by: Mike Rapoport
---
arch/arm/mm/init.c | 4
arch/arm64/mm/mmu.c
Currently, memblock has several internal functions with overlapping
functionality. They all call memblock_find_in_range_node() to find free
memory and then reserve the allocated range and mark it with kmemleak.
However, there is difference in the allocation constraints and in fallback
strategies.
The memblock_phys_alloc_try_nid() function tries to allocate memory from
the requested node and then falls back to allocation from any node in the
system. The memblock_alloc_base() fallback used by this function panics if
the allocation fails.
Replace the memblock_alloc_base() fallback with the
As all the memblock_alloc*() users are now checking the return value and
panic() in case of error, the panic() call can be removed from the core
memblock allocator, namely memblock_alloc_try_nid().
Signed-off-by: Mike Rapoport
---
mm/memblock.c | 15 +--
1 file changed, 5
memblock_alloc() already clears the allocated memory, no point in doing it
twice.
Signed-off-by: Mike Rapoport
---
arch/c6x/mm/init.c | 1 -
arch/h8300/mm/init.c| 1 -
arch/ia64/kernel/mca.c | 2 --
arch/m68k/mm/mcfmmu.c | 1 -
arch/microblaze/mm/init.c | 6 ++
Add panic() calls if memblock_alloc() returns NULL.
The panic() format duplicates the one used by memblock itself and in order
to avoid explosion with long parameters list replace open coded allocation
size calculations with a local variable.
Signed-off-by: Mike Rapoport
---
mm/percpu.c | 73
The memblock_alloc_base() function tries to allocate a memory up to the
limit specified by its max_addr parameter and panics if the allocation
fails. Replace its usage with memblock_phys_alloc_range() and make the
callers check the return value and panic in case of error.
Signed-off-by: Mike
On Wed, Jan 16, 2019 at 09:00:50AM +, Andrew Cooper wrote:
> For development purposes, it is very convenient to boot Xen as a PVH guest,
> with an XTF PV or PVH "dom0". The edit-compile-go cycle is a matter of
> seconds, and you can reasonably insert printk() debugging in places which
> which
On Wed, Jan 16, 2019 at 11:52:18AM +0100, Marek Marczykowski-Górecki wrote:
> On Wed, Jan 16, 2019 at 10:21:29AM +0100, Roger Pau Monné wrote:
> > On Tue, Jan 15, 2019 at 04:36:31PM +0100, Marek Marczykowski-Górecki wrote:
> > > From: Simon Gaiser
> > >
> > > Stubdomains need to be given
>>> On 16.01.19 at 10:00, wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -637,21 +637,23 @@ trace feature is only enabled in debugging builds of
> Xen.
> Specify the bit width of the DMA heap.
>
> ### dom0
> -= List of [ pvh=, shadow=,
Hi Mike,
On Wed, Jan 16, 2019 at 2:46 PM Mike Rapoport wrote:
> Add check for the return value of memblock_alloc*() functions and call
> panic() in case of error.
> The panic message repeats the one used by panicing memblock allocators with
> adjustment of parameters to include only relevant
On Wed, Jan 16, 2019 at 09:00:48AM +, Andrew Cooper wrote:
> Having a pvh boolean isn't ideal. If we gain a 3rd virtulsation mode,
> what does `dom0=no-pvh` mean?
>
> Change the syntax to be "dom0 = pv | pvh" which offers an option to more
> obviously select PV mode. Hide both options
This is more idiomatic. All existing OutputChecks return booleans, so
no functional change.
Signed-off-by: Ian Jackson
CC: Konrad Rzeszutek Wilk
---
ts-livepatch-run | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ts-livepatch-run b/ts-livepatch-run
index
The doubled $s here are simply a mistake. The result is to make this
test ineffective, since `$$file' means `the value of the variable
whose name is in the variable $file', which here will never exist.
This produces a `Use of uninitialized value' warning and substitutes
the empty string, so
Rename memblock_alloc_range() to memblock_phys_alloc_range() to emphasize
that it returns a physical address.
While on it, remove the 'enum memblock_flags' parameter from this function
as its only user anyway sets it to MEMBLOCK_NONE, which is the default for
the most of memblock allocations.
From: Christophe Leroy
Since only the virtual address of allocated blocks is used,
lets use functions returning directly virtual address.
Those functions have the advantage of also zeroing the block.
[ MR:
- updated error message in alloc_stack() to be more verbose
- convereted several
The allocation of the page tables memory in openrics uses
memblock_phys_alloc() and then converts the returned physical address to
virtual one. Use memblock_alloc_raw() and add a panic() if the allocation
fails.
Signed-off-by: Mike Rapoport
---
arch/openrisc/mm/init.c | 5 -
1 file changed,
The calls to memblock_alloc_base(size, align, MEMBLOCK_ALLOC_ANYWHERE) and
memblock_phys_alloc(size, align) are equivalent as both try to allocate
'size' bytes with 'align' alignment anywhere in the memory and panic if hte
allocation fails.
The conversion is done using the following semantic
Hi,
Current memblock API is quite extensive and, which is more annoying,
duplicated. Except the low-level functions that allow searching for a free
memory region and marking it as reserved, memblock provides three (well,
two and a half) sets of functions to allocate memory. There are several
flight 131964 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131964/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 131857
Tests which did not
On 1/16/19 1:19 PM, Paul Durrant wrote:
>> -Original Message-
>> From: Alex Bennée [mailto:alex.ben...@linaro.org]
>> Sent: 16 January 2019 12:14
>> To: peter.mayd...@linaro.org
>> Cc: qemu-de...@nongnu.org; Alex Bennée ; Stefano
>> Stabellini ; Anthony Perard
>> ; Paul Durrant ; Kevin
>>
There is no need to wake up xen_blkif_schedule() as kthread_stop() is able
to already wake up the kernel thread.
Signed-off-by: Dongli Zhang
---
drivers/block/xen-blkback/xenbus.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/block/xen-blkback/xenbus.c
Add panic() calls if memblock_alloc() returns NULL.
The panic() format duplicates the one used by memblock itself and in order
to avoid explosion with long parameters list replace open coded allocation
size calculations with a local variable.
Signed-off-by: Mike Rapoport
---
Add panic() calls if memblock_alloc*() returns NULL.
Most of the changes are simply addition of
if(!ptr)
panic();
statements after the calls to memblock_alloc*() variants.
Exceptions are pcpu_populate_pte() and kernel_map_range() that were
slightly refactored to
The last parameter of memblock_alloc_from() is the lower limit for the
memory allocation. When it is 0, the call is equivalent to
memblock_alloc().
Signed-off-by: Mike Rapoport
---
arch/alpha/kernel/core_cia.c | 2 +-
arch/alpha/kernel/pci_iommu.c | 4 ++--
arch/alpha/kernel/setup.c | 2
Add panic() calls if memblock_alloc() returns NULL.
The panic() format duplicates the one used by memblock itself and in order
to avoid explosion with long parameters list replace open coded allocation
size calculations with a local variable.
Signed-off-by: Mike Rapoport
---
init/main.c | 26
On Wed, Jan 16, 2019 at 01:34:28PM +0100, Roger Pau Monné wrote:
>On Wed, Jan 16, 2019 at 07:59:44PM +0800, Chao Gao wrote:
>> On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote:
>> >On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote:
>> >> diff --git
> -Original Message-
> From: Philippe Mathieu-Daudé [mailto:phi...@redhat.com]
> Sent: 16 January 2019 12:01
> To: qemu-de...@nongnu.org
> Cc: Paul Durrant ; Anthony Perard
> ; Max Reitz ; qemu-
> bl...@nongnu.org; Stefano Stabellini ; xen-
> de...@lists.xenproject.org; Kevin Wolf ;
The %lu format string is different depending on the host architecture
which causes builds like the debian-armhf-cross build to fail. Use the
correct PRi64 format string.
Signed-off-by: Alex Bennée
---
hw/block/xen-block.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 1/8/19 5:59 PM, Lars Kurth wrote:
> What I need is
> - Raise your hands if you are interested
> - Let me know of date / location restrictions
> - We could try and so some of this via video conference: would you be able to
> attend if we did open the meeting up to some remote participation
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 16 January 2019 12:04
> To: 'Philippe Mathieu-Daudé' ; qemu-de...@nongnu.org
> Cc: Kevin Wolf ; Stefano Stabellini
> ; qemu-bl...@nongnu.org; Max Reitz
> ; Anthony
On Wed, Jan 16, 2019 at 07:59:44PM +0800, Chao Gao wrote:
> On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote:
> >On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote:
> >> diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
> >> index 93c20b9..4f2be02
> On 16 Jan 2019, at 12:16, George Dunlap wrote:
>
> On 1/8/19 5:59 PM, Lars Kurth wrote:
>> What I need is
>> - Raise your hands if you are interested
>> - Let me know of date / location restrictions
>> - We could try and so some of this via video conference: would you be able
>> to attend
On Wed, Jan 16, 2019 at 05:57:04AM -0700, Jan Beulich wrote:
> >>> On 16.01.19 at 13:20, wrote:
> > Do you think it makes sense to add a domctl to enable/disable MSI(X)?
>
> A domctl looks odd for an operation like this; I'd rather consider
> adding a physdevop if a new (sub)hypercall is needed
On Wed, Jan 16, 2019 at 01:20:04PM +0100, Roger Pau Monné wrote:
> On Wed, Jan 16, 2019 at 11:52:18AM +0100, Marek Marczykowski-Górecki wrote:
> > On Wed, Jan 16, 2019 at 10:21:29AM +0100, Roger Pau Monné wrote:
> > > On Tue, Jan 15, 2019 at 04:36:31PM +0100, Marek Marczykowski-Górecki
> > >
On Wed, Jan 16, 2019 at 09:00:46AM +, Andrew Cooper wrote:
> Alter parse_pci_param() to use parse_boolean(), so the sub options
> behave like other Xen booleans.
>
> Update the command line documentation for consistency.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote:
>On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote:
>> I find some pass-thru devices don't work any more across guest
>> reboot. Assigning it to another domain also meets the same issue. And
>> the only way to make it work
Hi Lars,
We've updated the description of the projects related to Unikraft, please let
us know if you need anything else from us.
Thanks,
-- Felipe
Dr. Felipe Huici
Chief Researcher, Systems and Machine Learning Group
NEC
Add panic() calls if memblock_alloc*() returns NULL.
Most of the changes are simply addition of
if(!ptr)
panic();
statements after the calls to memblock_alloc*() variants.
Exceptions are create_mem_map_page_table() and ia64_log_init() that were
slightly refactored to
On Wed, Jan 16, 2019 at 2:45 PM Mike Rapoport wrote:
> memblock_alloc() already clears the allocated memory, no point in doing it
> twice.
>
> Signed-off-by: Mike Rapoport
> arch/m68k/mm/mcfmmu.c | 1 -
For m68k part:
Acked-by: Geert Uytterhoeven
> --- a/arch/m68k/mm/mcfmmu.c
> +++
Changed the return value of 1 to 0 so now p2m_finish_type_change returns
0 for success or <0 for error.
Signed-off-by: Alexandru Isaila
---
xen/arch/x86/mm/p2m.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index
Juergen Gross writes ("Re: [PATCH-for-4.10] correct release note link in
SUPPORT.md"):
> On 16/01/2019 15:57, George Dunlap wrote:
> > On 1/16/19 9:46 AM, Juergen Gross wrote:
> >> +Release-Notes
> >> +: >> href="https://wiki.xenproject.org/wiki/Xen_Project_4.10_Release_Notes;>RN
> >
> > This
Second try, this time also works for all links to xen-vbd-interface(7).
We don't try anymore to have pod2html generate relative links, instead
we do it ourself.
First, we modify all links to man pages to have what looks like an
absolute URL and pod2html will just write it in the html output.
Provide a better way to see the link to a different manpage, with simple
words.
Suggested-by: Ian Jackson
Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
---
docs/man/xl-disk-configuration.5.pod | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 16/01/2019 16:45, Ian Jackson wrote:
> Juergen Gross writes ("Re: [PATCH-for-4.10] correct release note link in
> SUPPORT.md"):
>> On 16/01/2019 15:57, George Dunlap wrote:
>>> On 1/16/19 9:46 AM, Juergen Gross wrote:
+Release-Notes
+: >>>
From: Mike Rapoport
Date: Wed, 16 Jan 2019 15:44:15 +0200
> Add panic() calls if memblock_alloc*() returns NULL.
>
> Most of the changes are simply addition of
>
> if(!ptr)
> panic();
>
> statements after the calls to memblock_alloc*() variants.
>
> Exceptions are
Hello Julien,
Julien Grall writes:
> Hi,
>
> On 12/18/18 9:11 PM, Volodymyr Babchuk wrote:
>> From: Volodymyr Babchuk
>>
>> This flag enables TEE support for a domain.
>>
>> Signed-off-by: Volodymyr Babchuk
>> ---
>> xen/arch/arm/domain.c | 4
>> xen/arch/arm/domctl.c
Hi Volodymyr,
On 18/12/2018 21:11, Volodymyr Babchuk wrote:
+static void optee_domain_destroy(struct domain *d)
+{
+struct arm_smccc_res resp;
+
+/* At this time all domain VCPUs should be stopped */
This function is called unconditionally, i.e this can be called even if the call
of
On 16/01/2019 12:13, Alex Bennée wrote:
> The %lu format string is different depending on the host architecture
> which causes builds like the debian-armhf-cross build to fail. Use the
> correct PRi64 format string.
>
> Signed-off-by: Alex Bennée
> ---
> hw/block/xen-block.c | 2 +-
> 1 file
On 1/16/19 10:29 AM, Juergen Gross wrote:
> On 16/01/2019 16:07, Boris Ostrovsky wrote:
>> On 1/16/19 9:33 AM, Juergen Gross wrote:
>>> On 16/01/2019 14:17, Boris Ostrovsky wrote:
On Wed, Jan 16, 2019 at 08:50:13AM +0100, Juergen Gross wrote:
> @@ -1650,13 +1650,14 @@ void
On Wed, Jan 16, 2019 at 03:27:35PM +0100, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Wed, Jan 16, 2019 at 2:46 PM Mike Rapoport wrote:
> > Add check for the return value of memblock_alloc*() functions and call
> > panic() in case of error.
> > The panic message repeats the one used by panicing
>>> On 16.01.19 at 16:13, wrote:
> Changed the return value of 1 to 0 so now p2m_finish_type_change returns
> 0 for success or <0 for error.
This is a valid alternative return value model. Both have their merits.
Hence if you want to change from one to the other, you should give
a reason.
> ---
On Wed, Jan 16, 2019 at 11:36:37AM +, Ian Jackson wrote:
> The doubled $s here are simply a mistake. The result is to make this
> test ineffective, since `$$file' means `the value of the variable
> whose name is in the variable $file', which here will never exist.
> This produces a `Use of
On Wed, Jan 16, 2019 at 11:36:35AM +, Ian Jackson wrote:
> This is more idiomatic. All existing OutputChecks return booleans, so
> no functional change.
>
> Signed-off-by: Ian Jackson
> CC: Konrad Rzeszutek Wilk
Reviewed-by: Konrad Rzeszutek Wilk
Thank you!
> ---
> ts-livepatch-run | 4
On Wed, Jan 16, 2019 at 11:36:36AM +, Ian Jackson wrote:
> target_cmd_output_root_status prints the command exit status. If that
> was a failure and the failure was as expected, this can be confusing
> to readers who do not know that this is a possibility. So print a
> message about it.
>
>
Does this fix your problem?
diff --git a/arch/arm/include/asm/xen/page-coherent.h
b/arch/arm/include/asm/xen/page-coherent.h
index b3ef061d8b74..2c403e7c782d 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -1 +1,95 @@
+/*
On 16.01.2019 17:39, Jan Beulich wrote:
On 16.01.19 at 16:13, wrote:
>> Changed the return value of 1 to 0 so now p2m_finish_type_change returns
>> 0 for success or <0 for error.
>
> This is a valid alternative return value model. Both have their merits.
> Hence if you want to change from
Thank you Felipe
I went through and updated the Verified dates and also changed the date of
insert for "New Platform Support" and "Go Language Support" as these were
different enough from what was there before
Regards
Lars
> On 16 Jan 2019, at 13:10, Felipe Huici wrote:
>
> Hi Lars,
>
>
On 1/16/19 9:33 AM, Juergen Gross wrote:
> On 16/01/2019 14:17, Boris Ostrovsky wrote:
>> On Wed, Jan 16, 2019 at 08:50:13AM +0100, Juergen Gross wrote:
>>
>>> @@ -1650,13 +1650,14 @@ void xen_callback_vector(void)
>>> xen_have_vector_callback = 0;
>>>
On Wed, Jan 16, 2019 at 7:46 AM Mike Rapoport wrote:
>
> Add check for the return value of memblock_alloc*() functions and call
> panic() in case of error.
> The panic message repeats the one used by panicing memblock allocators with
> adjustment of parameters to include only relevant ones.
>
>
Hi all,
Xen 4.12 rc1 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.12.0-rc1
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.12.0-rc1/xen-4.12.0-rc1.tar.gz
And the signature is at:
On Wed, Jan 16, 2019 at 05:47:19PM +0100, Roger Pau Monné wrote:
> On Tue, Jan 15, 2019 at 04:36:28PM +0100, Marek Marczykowski-Górecki wrote:
> > HVM domains use IOMMU and device model assistance for communicating with
> > PCI devices, xen-pcifront/pciback is used only in PV domains.
>
> You
Hi,
I made an attempt to boot Linux 5.0-rc2 as Dom0 on Xen
Arm64 and got the following splat:
[4.074264] Unable to handle kernel NULL pointer dereference at virtual
address
[4.083074] Mem abort info:
[4.085870] ESR = 0x9604
[4.089050] Exception class =
On 16/01/2019 17:22, Volodymyr Babchuk wrote:
Hello Julien,
Julien Grall writes:
Hi,
On 12/18/18 9:11 PM, Volodymyr Babchuk wrote:
From: Volodymyr Babchuk
This flag enables TEE support for a domain.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/domain.c | 4
Hi Daniel.
> v5: Actually try to sort them, and while at it, sort all the ones I
> touch.
Applied this variant on top of drm-misc and did a build test.
Looked good for ia64, x86 and alpha.
Took a closer look at the changes to atmel_hlcd - and they looked OK.
But I noticed that atmel_hlcdc uses
On 16/01/2019 16:07, Boris Ostrovsky wrote:
> On 1/16/19 9:33 AM, Juergen Gross wrote:
>> On 16/01/2019 14:17, Boris Ostrovsky wrote:
>>> On Wed, Jan 16, 2019 at 08:50:13AM +0100, Juergen Gross wrote:
>>>
@@ -1650,13 +1650,14 @@ void xen_callback_vector(void)
flight 131982 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131982/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
flight 131967 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131967/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 129475
build-i386-xsm
On Tue, Jan 15, 2019 at 04:36:28PM +0100, Marek Marczykowski-Górecki wrote:
> HVM domains use IOMMU and device model assistance for communicating with
> PCI devices, xen-pcifront/pciback is used only in PV domains.
You still need pciback in order to reset the device when it's
deassigned from the
Hi Julien,
Julien Grall writes:
> Hi Volodymyr,
>
> On 12/18/18 9:11 PM, Volodymyr Babchuk wrote:
>> From: Volodymyr Babchuk
>>
>> Add very basic OP-TEE mediator. It can probe for OP-TEE presence,
>> tell it about domain creation/destruction and forward all known
>> calls.
>>
>> This is all
On Wed, Jan 16, 2019 at 7:45 AM Mike Rapoport wrote:
>
> The __memblock_alloc_base() function tries to allocate a memory up to the
> limit specified by its max_addr parameter. Depending on the value of this
> parameter, the __memblock_alloc_base() can is replaced with the appropriate
>
On 16/01/2019 15:57, George Dunlap wrote:
> On 1/16/19 9:46 AM, Juergen Gross wrote:
>> The syntax for the release note link in SUPPORT.md is wrong. Correct
>> that.
>>
>> Signed-off-by: Juergen Gross > ---
>> SUPPORT.md | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git
On Tue, Jan 15, 2019 at 07:16:21PM +, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [PATCH 1/2] docs: Fix all links to Xen
> man pages in html"):
> > On 15/01/2019 18:21, Anthony PERARD wrote:
> > > diff --git a/docs/Makefile b/docs/Makefile
> > > index cbc61e3f1d..974d9089ed
On Tue, Jan 08, 2019 at 04:24:32PM +0800, Dongli Zhang wrote:
> oops. Please ignore this v5 patch.
>
> I just realized Linus suggested in an old email not use BUG()/BUG_ON() in the
> code.
>
> I will switch to the WARN() solution and resend again.
OK. Did I miss it?
Hello Andre,
On 02.01.19 20:33, André Przywara wrote:
Many thanks for generating these numbers, this is very useful.
But: could you make any sense out them? I plotted them, but they don't
seem to be very conclusive.
Those numbers are mostly intended to show per patch effects. But I kept them
flight 131985 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131985/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
1 - 100 of 146 matches
Mail list logo
