Also clean up current code by moving initialization of arch specific
fields out of common code.
Signed-off-by: Chao Gao
Reviewed-by: Jan Beulich
Reviewed-by: Roger Pau Monné
---
Changes in v5:
- rename init_arch_msix to arch_init_msix
- place arch_init_msix right after the definition of arch_
When I destroyed a guest with 'xl destroy', I found the warning
in msi_set_mask_bit() in Xen was triggered. After adding "WARN_ON(1)"
to that place, I got the call trace below:
(XEN) Xen call trace:
(XEN)[] msi.c#msi_set_mask_bit+0x1da/0x29b
(XEN)[] guest_mask_msi_irq+0x1c/0x1e
(XEN)[]
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 again is un-binding and binding it to
pciback. Someone reported this issue one year ago [1].
If the device's driver doesn't disable MSI-
On 16/01/2019 00:36, Stefano Stabellini wrote:
> On Tue, 15 Jan 2019, Jan Beulich wrote:
>>> Yes, this instance is only the tip of the
>>> iceberg, we have a long road ahead, but we shouldn't really give up
>>> because it is going to be difficult :-) Stewart's approach would
>>> actually be complia
>>> On 16.01.19 at 08:10, wrote:
> On 1/14/19 4:42 PM, Juergen Gross wrote:
>> On 14/01/2019 11:56, Razvan Cojocaru wrote:
>>> On 1/14/19 11:53 AM, Jan Beulich wrote:
>>> On 14.01.19 at 10:34, wrote:
> On 1/12/19 12:04 AM, Boris Ostrovsky wrote:
>> On 12/14/18 6:49 AM, Razvan Cojocaru
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 aware of. The two common cases are legacy USB keyboard emulation, and
the B
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.
Update the command line documentation for consistency.
Signed-off
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 second is the removal of block indentation markup fo
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 sync with the main documentation. Also drop the individual
documentation for deprecated options which refer to their newer
ve
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 behind the relevent
CONFIG_* settings, and default to PVH mode when CONFIG_PV i
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 would be completely infeasible when booting fully-fledged guests.
Howe
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
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Juergen Gross
v3:
* New
---
docs/misc/xen-command-
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 command line documentation almost from scratch, including
far more detail.
Sign
On 1/16/19 10:58 AM, Jan Beulich wrote:
On 16.01.19 at 08:10, wrote:
On 1/14/19 4:42 PM, Juergen Gross wrote:
On 14/01/2019 11:56, Razvan Cojocaru wrote:
On 1/14/19 11:53 AM, Jan Beulich wrote:
On 14.01.19 at 10:34, wrote:
On 1/12/19 12:04 AM, Boris Ostrovsky wrote:
On 12/14/18 6:49 AM, R
On Tue, Jan 15, 2019 at 04:36:31PM +0100, Marek Marczykowski-Górecki wrote:
> From: Simon Gaiser
>
> Stubdomains need to be given sufficient privilege over the guest which it
> provides emulation for in order for PCI passthrough to work correctly.
> When a HVM domain try to enable MSI, QEMU in st
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 98ab52eda9..de388d0afa 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -13,7 +13
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 6d417a618e..2ec77bf2cc 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -13,7 +13
flight 131962 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131962/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-amd64-i386-xl-pvshim12 guest-
>>> 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 variables instead of the original (perhaps
>> cast
flight 131975 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131975/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 84323dfb9daac3b47919113f881c19cffe01fc22
baseline version:
xen 93a6
>>> 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 impossible to access them from C files in the
>> first pl
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 again is un-binding and binding it to
> pciback. Someone reported this is
On 14/01/2019 15:59, Ian Jackson wrote:
> Some early kernesl are known not to reject unknown flags to
s/kernesl/kernels/
> unshare(). There may be other problems.
>
> CC: Jan Beulich
> Signed-off-by: Ian Jackson
For the series:
Release-acked-by: Juergen Gross
Juergen
___
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 sufficient privilege over the guest which it
> > provides emulation for in order for PCI passt
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 sync with the main documentation. Also drop the indi
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 command
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é
Thanks
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 behind
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 awa
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
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 f1194586..8fdb
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 overal
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
---
ts-livepatch-
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
Release
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.
>
> Other
>>> 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 | shad
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 agai
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=]
xen_device_backend_printf(xe
> -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 ; Philipp
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
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 a/hw/blo
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
I'
> -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 Pera
> -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 list:Bl
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 sufficie
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 10064
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;
>> >>
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 suc
>>> 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 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
>> W
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 h
> 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
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 Laboratorie
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 deliver
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
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!
v4.19
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
overl
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 additi
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 patch
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.
Sign
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
memblock_phys_alloc*() variant.
Signed-off-by: Mike Rapoport
---
arch/sh
These functions are not used outside memblock. Make them static.
Signed-off-by: Mike Rapoport
---
include/linux/memblock.h | 4
mm/memblock.c| 4 ++--
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index cf4cd9c
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 f
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 di
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 Rapop
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 insertions(
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 ++
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
b/drivers
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
---
kernel/dma/swiotlb.
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.
The replacement was mostly automated with semantic patches like the o
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 accommod
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 ++
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
>>> 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 pagetable
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 +++
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 acc
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
> > > wrote
>>> 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 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 cou
>>> 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=, verb
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
> +++ b/ar
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 ones
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 16/01/2019 14:44, 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.
>
> The replacement
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;
>> return;
>> }
>> -
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 a/xen/drivers/passthrough/pc
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 insertion(+)
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 6d417a618e..2ec7
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,
>
> We've
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;
>>>
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 d
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 m
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
> memblock_ph
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.
>
> Th
1 - 100 of 153 matches
Mail list logo
