On Mon, Jan 14, 2019 at 4:57 AM Jan Beulich wrote:
>
> >>> On 07.01.19 at 08:42, wrote:
> > Argo doesn't use compat hypercall or argument translation but can use some
> > of the infrastructure for validating the hypercall argument structures to
> > ensure that the struct sizes, offsets and
On Wed, Jan 16, 2019 at 03:44:19PM +0200, Mike Rapoport wrote:
> arch/csky/mm/highmem.c| 5 +
...
> diff --git a/arch/csky/mm/highmem.c b/arch/csky/mm/highmem.c
> index 53b1bfa..3317b774 100644
> --- a/arch/csky/mm/highmem.c
> +++ b/arch/csky/mm/highmem.c
> @@ -141,6
On Tue, Jan 15, 2019 at 8:19 AM Roger Pau Monné wrote:
>
> On Tue, Jan 15, 2019 at 01:27:42AM -0800, Christopher Clark wrote:
> > Queries for data about space availability in registered rings and
> > causes notification to be sent when space has become available.
> >
> > The hypercall op
On Tue, Jan 15, 2019 at 7:49 AM Roger Pau Monné wrote:
>
> On Tue, Jan 15, 2019 at 01:27:41AM -0800, Christopher Clark wrote:
> > sendv operation is invoked to perform a synchronous send of buffers
> > contained in iovs to a remote domain's registered ring.
> >
> > It takes:
> > * A destination
On Tue, Jan 15, 2019 at 7:07 AM Roger Pau Monné wrote:
>
> On Tue, Jan 15, 2019 at 01:27:40AM -0800, Christopher Clark wrote:
> > Takes a single argument: a handle to the ring unregistration struct,
> > which specifies the port and partner domain id or wildcard.
> >
> > The ring's entry is
flight 131971 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131971/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 131645
test-amd64-i386-xl-qemut-win7-amd64 17
flight 131969 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131969/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2broken in 131942
test-amd64-i386-xl-xsm
Andrii,
2019年1月16日(水) 16:40、Andrii Anisov さん（andrii.ani...@gmail.com）のメッセージ:
> Hello Jairo,
>
> On 08.01.19 19:04, LOPEZ, FUENTES NACARINO Jairo Eduardo wrote:
>
> > I have noticed that the uboot date has not changed from 2015.04
> It is not a u-boot date, but upstream version. Renesas derived
Hi Roger,
On 2019/1/16 下午10:52, Roger Pau Monné wrote:
> 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
>> ---
>>
On Wed, 16 Jan 2019, Jan Beulich wrote:
> >>> On 16.01.19 at 00:36, wrote:
> > On Tue, 15 Jan 2019, Jan Beulich wrote:
> >> First of all we should explore whether the variables could also be
> >> linker generated, in particular to avoid the current symbols to be
> >> global (thus making it
On Wed, 16 Jan 2019, Jan Beulich wrote:
> >>> On 15.01.19 at 21:03, wrote:
> > On Tuesday, January 15, 2019 3:21 AM, Jan Beulich wrote:
> >> The thing that I don't understand though is how the undefined
> >> behavior (if there really is any) goes away: Even if you compare
> >> the contents of the
On Tue, Jan 15, 2019 at 8:58 AM 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
On 2019/1/17 上午12:32, Konrad Rzeszutek Wilk wrote:
> 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
Hi Julien,
On Wed, Jan 16, 2019 at 08:13:29PM +, Julien Grall wrote:
[...]
> > So xen_get_dma_ops() will try to retrieve pointer from
> > 'dev->archdata.dev_dma_ops' but because it's NULL so at the end
> > introduces kernel panic will NULL pointer.
> >
> > Seems to me, we should check two
On Mon, Jan 07, 2019 at 01:43:11PM +0100, Juergen Gross wrote:
> On 07/01/2019 12:41, Colin Watson wrote:
> > Hi,
> >
> > I'm working on integrating the recently-merged PVH support for GRUB into
> > the Debian packages. As a result I find myself thinking about how to
> > handle the two-stage boot
Kudos to Oleksandr Tyshchenko, he stepped into the same, and found the
rootcause.
The problem is in a patch https://patchwork.kernel.org/patch/10084561/ .
I guess you can workaround it with adding interrupts and interrupt-parent
properties to timer node through your dtb. Something like
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
On Tue, Jan 15, 2019 at 10:07 AM Leo Yan wrote:
>
> Hi all,
Hi Leo,
Thank you for the report.
> On Tue, Jan 15, 2019 at 10:49:58AM +0800, Leo Yan wrote:
>
> [...]
>
> > [1.807591] Modules linked in:
> > [1.810717] CPU: 4 PID: 1 Comm: swapper/0 Not tainted
> >
On 16/01/2019 14:08, Jan Beulich wrote:
>
>> -and the hardware must have VT-x/SVM extensions available.
>> +* For a PVH dom0, the hardware must have VT-x/SVM extensions
>> available.
>>
>> * The `shadow` boolean is only applicable when dom0 is constructed as a
>> PVH
>>
On 16/01/2019 10:53, Roger Pau Monné wrote:
> On Wed, Jan 16, 2019 at 09:00:44AM +, Andrew Cooper wrote:
>> Update to the latest metadata style, and discuss the options more
>> completely where appropriate.
>>
>> Drop the redundant comment beside parse_dom0_param() - it is already out
>> of
On 16/01/2019 11:52, Jan Beulich wrote:
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.
>>
Hi Volodymyr,
On 18/12/2018 21:11, Volodymyr Babchuk wrote:
From: Volodymyr Babchuk
The main way to communicate with OP-TEE is to issue standard SMCCC
call. "Standard" is a SMCCC term and it means that call can be
interrupted and OP-TEE can return control to NW before completing
the call.
In
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
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 @@
+/*
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 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
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
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
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 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,
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 =
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
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
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
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
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 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.
>
>
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?
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
+: >>>
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
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.
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 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
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
>>> 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 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)
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
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 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.
>
>
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 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
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
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;
>>>
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: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: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
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
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
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 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
> +++
>>> 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=,
>>> 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 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
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
> > >
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
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
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
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
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.
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
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 ++
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
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
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
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
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 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 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
> 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 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
>>
>>> 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).
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 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;
>>
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 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
1 - 100 of 146 matches
Mail list logo
