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
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
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. 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
Acked-by: Ro
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
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 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,
memblock_alloc() already clears the allocated memory, no point in doing it
twice.
Signed-off-by: Mike Rapoport
Acked-by: Geert Uytterhoeven # m68k
---
arch/c6x/mm/init.c | 1 -
arch/h8300/mm/init.c| 1 -
arch/ia64/kernel/mca.c | 2 --
arch/m68k/mm/mcfmmu.c | 1 -
arc
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
Acked-by: Paul Burton # MIPS part
---
arch/alpha/kernel/core_cia.c | 2 +-
arch/alpha/kernel/pci_iommu.c | 4 ++--
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
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
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
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.
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 ++
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
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
Acked-by: Greg Kroah-Hartman
---
arch/arc/kernel/unwind.c | 3 +--
arch/sh/mm/init.c | 2 +-
arch/x86/
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
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.
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
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 ++
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(
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
On 21/01/2019 02:31, no-re...@patchew.org wrote:
Patchew URL:
https://patchew.org/QEMU/1547554687-12687-1-git-send-email-liam.merw...@oracle.com/
...>
CC dma-helpers.o
CC vl.o
/tmp/qemu-test/src/block/sheepdog.c: In function 'find_vdi_name':
/tmp/qemu-test/src/block/sheepdog.c:
On Sun, Jan 20, 2019 at 05:59:36PM -0800, Christopher Clark wrote:
> On Sat, Jan 19, 2019 at 4:06 AM Roger Pau Monné wrote:
> >
> > On Fri, Jan 18, 2019 at 03:54:14PM -0800, Christopher Clark wrote:
> > > On Fri, Jan 18, 2019 at 1:44 AM Roger Pau Monné
> > > wrote:
> > > >
> > > > On Thu, Jan 17
On Mon, Jan 21, 2019 at 04:51:57AM +, Peng Fan wrote:
> on i.MX8QM, M4_1 is communicating with DomU using rpmsg with a fixed
> address as the dma mem buffer which is predefined.
>
> Without this patch, the flow is:
> vring_map_one_sg -> vring_use_dma_api
> -> dma_map_page
>
On Mon, Jan 21, 2019 at 9:06 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.
>
> The
Andrii,
I went through the instructions again and found the instructions for what
you call Yocto 3.9 here [1].
I attempted following the initial Xen ARM instructions found here [2]
The biggest difference is in the commit revisions for meta-selinux and
meta-virtualization that I didn't know if go
> -Original Message-
> From: Andrew Cooper
> Sent: 18 January 2019 17:41
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Chao Gao ; Sander Eikelenboom
> ; Jan Beulich ; Wei Liu
> ; Roger Pau Monne ; George
> Dunlap ; Ian Jackson ;
> Julien Grall ; Konrad Rzeszutek Wilk
> ; Stefano
>>> On 18.01.19 at 11:48, wrote:
> On 18/01/2019 09:54, Jan Beulich wrote:
> On 18.01.19 at 02:24, wrote:
>>> On Thu, 17 Jan 2019, Jan Beulich wrote:
>>> On 17.01.19 at 01:37, wrote:
> On Wed, 16 Jan 2019, Jan Beulich wrote:
>> Stop. No. We very much can prove they are - _end points
>>> On 18.01.19 at 16:22, wrote:
> On 18/01/2019 11:09, Jan Beulich wrote:
> On 18.01.19 at 11:48, wrote:
>>> On 18/01/2019 09:54, Jan Beulich wrote:
>>> On 18.01.19 at 02:24, wrote:
> On Thu, 17 Jan 2019, Jan Beulich wrote:
> On 17.01.19 at 01:37, wrote:
>>> On Wed, 16
>>> On 19.01.19 at 00:05, wrote:
> On Fri, 18 Jan 2019, Jan Beulich wrote:
>> >>> On 18.01.19 at 02:24, wrote:
>> > On Thu, 17 Jan 2019, Jan Beulich wrote:
>> >> >>> On 17.01.19 at 01:37, wrote:
>> >> > On Wed, 16 Jan 2019, Jan Beulich wrote:
>> >> >> In any event - since intermediate variables
Signed-off-by: Christopher Clark
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 96a0518..c4f5316 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -158,6 +158,14 @@ S: Supported
F: xen/arch/x86/hvm/svm/
F: xen/arch/x86/cpu/vpmu_a
Version five of this patch series:
* Changes are primarily addressing feedback from the v4 series reviews.
Many points noted on the invididual commit posts.
* Critical sections have been shrunk, with allocations and frees
pulled outside where possible, reordering logic within hypercall ops.
ARM port of c/s bb544585: "introduce guest_handle_for_field()"
This helper turns a field of a GUEST_HANDLE into a GUEST_HANDLE.
Signed-off-by: Christopher Clark
Reviewed-by: Paul Durrant
Reviewed-by: Stefano Stabellini
---
v3: Added Stefano's Reviewed-by
v2: Added Paul's Reviewed-by
xen/incl
Defines CONFIG_ARGO when enabled. Default: disabled.
When the Kconfig option is enabled, the Argo hypercall implementation
will be included, allowing use of the hypervisor-mediated interdomain
communication mechanism.
Argo is implemented for x86 and ARM hardware platforms.
Availability of the op
A convenience for working on development of the argo subsystem:
setting a #define variable enables additional debug messages.
Signed-off-by: Christopher Clark
Acked-by: Jan Beulich
Reviewed-by: Roger Pau Monné
---
v3 added Roger's Reviewed-by
v3 added Jan's Ack
v2 #03 feedback, Jan: fix ifdef/d
Presence is gated upon CONFIG_ARGO.
Registers the hypercall previously reserved for this.
Takes 5 arguments, does nothing and returns -ENOSYS.
Will be avoiding a compat ABI by using fixed-size types in hypercall ops so
HYPERCALL, rather than COMPAT_CALL, is the correct macro for the hypercall
tab
Initialises basic data structures and performs teardown of argo state
for domain shutdown.
Inclusion of the Argo implementation is dependent on CONFIG_ARGO.
Introduces a new Xen command line parameter 'argo': bool to enable/disable
the argo hypercall. Defaults to disabled.
New headers:
public/
Queries for data about space availability in registered rings and
causes notification to be sent when space has become available.
The hypercall op populates a supplied data structure with information about
ring state and if insufficient space is currently available in a given ring,
the hypervisor
Will inhibit initialization of the domain's argo data structure to
prevent receiving any messages or notifications and access to any of
the argo hypercall operations.
Signed-off-by: Christopher Clark
Acked-by: Daniel De Graaf
---
v3 Daniel/Jan: add to the default xsm policy for enable
v3 Add Dan
XSM controls for argo ring registration with two distinct cases, where
the ring being registered is:
1) Single source: registering a ring for communication to receive messages
from a specified single other domain.
Default policy: allow.
2) Any source: registering a ring
The register op is used by a domain to register a region of memory for
receiving messages from either a specified other domain, or, if specifying a
wildcard, any domain.
This operation creates a mapping within Xen's private address space that
will remain resident for the lifetime of the ring. In s
EMSGSIZE: Argo's sendv operation will return EMSGSIZE when an excess amount
of data, across all iovs, has been supplied, exceeding either the statically
configured maximum size of a transmittable message, or the (variable) size
of the ring registered by the destination domain.
ECONNREFUSED: Argo's
Default policy: allow.
Signed-off-by: Christopher Clark
Reviewed-by: Paul Durrant
Acked-by: Daniel De Graaf
---
v3 Daniel/Jan: add to the default xsm policy for the send op
v3 Add Daniel's Acked-by
v2: reordered commit sequence to after sendv implementation
v1 feedback Jan #16: apply const to f
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 removed from the hashtable of registered rings;
any entries for pending notifications are removed; and the ring is
unmapped from Xen's address space.
Signed-off-by: Christopher Clark
Acked-by: Daniel De Graaf
---
v3 #10 Roger: drop out label, use return -EFAULT in fill_ring_data
v3: Add Daniel's Acked-by
xen/common/argo.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/xen/common/argo.c b/xen/common/argo.c
index 4631f66..c58
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 address (domid, port) for the ring to send to.
It performs a most-specific match lookup, to allow for wildcard.
* A source address, used to inf
>>> On 21.01.19 at 06:24, wrote:
> On Friday, January 18, 2019 6:05 PM, Stefano Stabellini wrote:
>> I don't think this is the case for MISRAC. C rules apply to C. Other
>> rules apply to assembly and linker scripts. This is something that
>> should be easy to check, and I hope that Stewart should
Hi Jan,
On 21/01/2019 09:34, Jan Beulich wrote:
On 18.01.19 at 11:48, wrote:
On 18/01/2019 09:54, Jan Beulich wrote:
On 18.01.19 at 02:24, wrote:
On Thu, 17 Jan 2019, Jan Beulich wrote:
On 17.01.19 at 01:37, wrote:
On Wed, 16 Jan 2019, Jan Beulich wrote:
Stop. No. We very much can prove
Hi Dandan,
On 21/01/2019 02:23, Bi, Dandan wrote:
I have committed the fix patch.
https://github.com/tianocore/edk2/commit/eb76b76218d5bac867414e2ff6dd09c6e7c700dd
Please trying the latest EDK2 master.
I have tried EDK2 master and got a guest booting with UEFI. Thank you for
merging it!
Ch
>>> On 21.01.19 at 11:22, wrote:
> Hi Jan,
>
> On 21/01/2019 09:34, Jan Beulich wrote:
> On 18.01.19 at 11:48, wrote:
>>> On 18/01/2019 09:54, Jan Beulich wrote:
>>> On 18.01.19 at 02:24, wrote:
> On Thu, 17 Jan 2019, Jan Beulich wrote:
> On 17.01.19 at 01:37, wrote:
>>
On Mon, Jan 21, 2019 at 08:19:03AM +, Liam Merwick wrote:
> On 21/01/2019 02:31, no-re...@patchew.org wrote:
> > Patchew URL:
> > https://patchew.org/QEMU/1547554687-12687-1-git-send-email-liam.merw...@oracle.com/
> ...>
> >CC dma-helpers.o
> >CC vl.o
> > /tmp/qemu-test/src/b
On Mon, Jan 21, 2019 at 01:59:55AM -0800, Christopher Clark wrote:
> Signed-off-by: Christopher Clark
> ---
>
> MAINTAINERS | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 96a0518..c4f5316 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -15
>>> On 21.01.19 at 10:59, wrote:
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -158,6 +158,14 @@ S: Supported
> F: xen/arch/x86/hvm/svm/
> F: xen/arch/x86/cpu/vpmu_amd.c
>
> +ARGO
> +M: Christopher Clark
> +S: Maintained
> +F: xen/include/public/argo.h
> +F: xen/include/xen/argo.
>>> On 18.01.19 at 17:03, wrote:
> ...and remove alignment assertions.
>
> Testing shows that certain callers of iommu_legacy_map/unmap() specify
> order > 0 ranges that are not order aligned thus causing one of the
> IS_ALIGNED() assertions to fire.
As said before - without a much better explan
Hi Volodymyr,
On 18/12/2018 21:11, Volodymyr Babchuk wrote:
From: Volodymyr Babchuk
Shared memory is widely used by NW to communicate with
TAs in OP-TEE. NW can share part of own memory with
TA or OP-TEE core, by registering it OP-TEE, or by providing
a temporal reference. Anyways, information
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 21 January 2019 11:28
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; Roger Pau Monne ; Wei
> Liu ; Sander Eikelenboom ;
> George Dunlap ; Ian Jackson
> ; Chao Gao ; Jun Nakajima
> ; Kevin Tian ; Stefano
Hi Volodymyr,
On 18/12/2018 21:11, Volodymyr Babchuk wrote:
From: Volodymyr Babchuk
OP-TEE can issue multiple RPC requests. We are interested mostly in
request that asks NW to allocate/free shared memory for OP-TEE
needs, because mediator need to do address translation in the same
NIT: the m
>>> On 20.01.19 at 22:18, wrote:
> On Thu, Jan 17, 2019 at 3:25 AM Jan Beulich wrote:
>>
>> >>> On 17.01.19 at 08:22, wrote:
>> > Some details of the problem:
>> >
>> > Without the macro overrides in place (ie. using the existing
>> > definitions) the build fails on CHECK_argo_send_addr because
>>> On 21.01.19 at 12:56, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 21 January 2019 11:28
>> To: Paul Durrant
>> Cc: Julien Grall ; Andrew Cooper
>> ; Roger Pau Monne ; Wei
>> Liu ; Sander Eikelenboom ;
>> George Dunlap ; Ian Jackson
>> ; Chao
flight 132129 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132129/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 129313
test-amd64-amd64-xl-
Hi Volodymyr,
On 18/12/2018 21:11, Volodymyr Babchuk wrote:
From: Volodymyr Babchuk
This boolean option controls if TEE access is enabled for the domain.
If access is enabled, xl will set appropriate flag in architecture
configuration to ask hypervisor to enable TEE support.
Signed-off-by: Vo
Hi,
On 18/12/2018 21:11, Volodymyr Babchuk wrote:
From: Volodymyr Babchuk
If TEE support is enabled with "tee=1" option in xl.cfg,
then we need to inform guest about available TEE.
Currently only OP-TEE is supported, so we'll create DT
node in a way that is expected by optee driver in linux.
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
flight 132199 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132199/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR.
vs. 131437
Tests which
On 1/18/19 1:43 PM, Julien Grall wrote:
> (+ Stefano)
>
> Hi,
>
> Sorry for jumping late in the conversation.
>
> On 18/01/2019 09:40, Oleksandr Andrushchenko wrote:
>> On 1/17/19 11:18 AM, Christoph Hellwig wrote:
>>> On Wed, Jan 16, 2019 at 06:43:29AM +, Oleksandr Andrushchenko
>>> wrote:
>>
flight 132136 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132136/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-freebsd10-amd64 17 guest-localmigrate/x10 fail in 132040 pass
in 132136
test-amd64-amd64-rumprun-
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 21 January 2019 12:05
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; George Dunlap ; Ian
> Jackson ; Roger Pau Monne ;
> Wei Liu ; Sander Eikelenboom ;
> Chao Gao ; Jun Nakajima ;
> Kevin Tian ; Stefano
flight 132269 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132269/
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
When Xen is detected via pkg-config, it isn't necessary to modify
LDFLAGS as modifying libs_softmmu is enough.
Reported-by: Peter Maydell
Signed-off-by: Anthony PERARD
---
configure | 1 -
1 file changed, 1 deletion(-)
diff --git a/configure b/configure
index 12fd34f30b..98b270974d 100755
---
On 1/21/19 3:48 PM, Anthony PERARD wrote:
> When Xen is detected via pkg-config, it isn't necessary to modify
> LDFLAGS as modifying libs_softmmu is enough.
>
> Reported-by: Peter Maydell
> Signed-off-by: Anthony PERARD
> ---
> configure | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/
On Mon, 21 Jan 2019 at 14:49, Anthony PERARD wrote:
>
> When Xen is detected via pkg-config, it isn't necessary to modify
> LDFLAGS as modifying libs_softmmu is enough.
>
> Reported-by: Peter Maydell
> Signed-off-by: Anthony PERARD
> ---
> configure | 1 -
> 1 file changed, 1 deletion(-)
>
> di
The current rendering of PVH start info in unnecessarily verbose, and doesn't
clearly separate decimal and hex numbers.
All addresses are expected to be below the 4G boundary, so drop 8 redundant
zeroes on all physical addresses. Properly prefix all hex numbers, and fold
related information onto
These are all minor fixes from some recent PVH work. They are all limited to
the boot path, and low-risk nice-to-have's for 4.12.
Andrew Cooper (3):
x86/pvh-dom0: Remove unnecessary function pointer call from
modify_identity_mmio()
x86/pvh: Fixes to convert_pvh_info()
x86/pvh: Print the PV
Function pointer calls are far more expensive in a post-Spectre world, and
this one doesn't need to be.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Juergen Gross
---
xen/arch/x86/hvm/dom0_build.c | 4 ++--
1 file changed, 2 inse
panic() doesn't contain any caller information, so the sum output of:
(d1) (XEN)
(d1) (XEN)
(d1) (XEN) Panic on CPU 0:
(d1) (XEN) Magic value is wrong: 336ec568
(d1) (XEN)
(d1) (XEN)
isn't helpful at ide
On Mon, Jan 21, 2019 at 03:37:19PM +, Andrew Cooper wrote:
> Function pointer calls are far more expensive in a post-Spectre world, and
> this one doesn't need to be.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
This isn't a hot path though, so I wouldn'
On Mon, Jan 21, 2019 at 03:37:20PM +, Andrew Cooper wrote:
> panic() doesn't contain any caller information, so the sum output of:
>
> (d1) (XEN)
> (d1) (XEN)
> (d1) (XEN) Panic on CPU 0:
> (d1) (XEN) Magic value is wrong: 336ec568
> (d1) (XEN
On Mon, Jan 21, 2019 at 03:37:21PM +, Andrew Cooper wrote:
> The current rendering of PVH start info in unnecessarily verbose, and doesn't
> clearly separate decimal and hex numbers.
>
> All addresses are expected to be below the 4G boundary, so drop 8 redundant
> zeroes on all physical addres
On 21/01/2019 15:52, Wei Liu wrote:
> On Mon, Jan 21, 2019 at 03:37:20PM +, Andrew Cooper wrote:
>> panic() doesn't contain any caller information, so the sum output of:
>>
>> (d1) (XEN)
>> (d1) (XEN)
>> (d1) (XEN) Panic on CPU 0:
>> (d1) (XEN) M
From: Andrii Anisov
Wipe out excessive lines from an iommu_unmap(), and align it with an
iommu_map() code.
Signed-off-by: Andrii Anisov
---
xen/drivers/passthrough/iommu.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers
On Fri, Oct 26, 2018 at 12:10:16PM +0200, Olaf Hering wrote:
> A given Qemu version can not predict what version of Xen it will run on.
> There are some checks in configure to decide what Xen libraries and
> functions are available. How exactly these functions must be accessed
> has to be decided b
Yes! I'd love to hear more about what you did, to help me further promote
Xen as a Works on Arm supported project. Also, I'd love to hear more
details about the Gitlab integration, as I am working diligently to get
arm64 support into their mainline roadmap.
thanks
Ed
On Thu, Jan 17, 2019 at 12:4
From: Oleksandr Tyshchenko
1. Add missing return in case if IOMMU ops have been already set.
2. Add check for shared IOMMU before returning an error.
Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Julien Grall
---
xen/drivers/passthrough/arm/iommu.c | 7 +--
1 file changed, 5 insertions
From: Oleksandr Tyshchenko
We don't passthrough IOMMU device to DOM0 even if it is not used by
Xen. Therefore exposing the properties that describe relationship
between master devices and IOMMUs does not make any sense.
According to the:
1. Documentation/devicetree/bindings/iommu/iommu.txt
2. Do
From: Andrii Anisov
Dear All,
With moving our working setup to 4.12-rc2 (IPMMU series especially),I've
realized that we have a couple of patches from IPMMU series [1] which are
fixes, got RB/AB, but not reached mainline yet. I really hope those RB/AB
would not be treated as stale, and patches ar
Its last uses was removed by: 6d7c06c213ddcfabcafdc178ccef81736f85a7c2
"Remove broken Xen PV domain builder".
Signed-off-by: Anthony PERARD
---
configure | 19 ---
1 file changed, 19 deletions(-)
diff --git a/configure b/configure
index 98b270974d..8684a6e5ef 100755
--- a/config
Hello,
On 21/01/2019 12:43, Oleksandr Andrushchenko wrote:
On 1/18/19 1:43 PM, Julien Grall wrote:
On 18/01/2019 09:40, Oleksandr Andrushchenko wrote:
On 1/17/19 11:18 AM, Christoph Hellwig wrote:
On Wed, Jan 16, 2019 at 06:43:29AM +, Oleksandr Andrushchenko
wrote:
This whole issue keeps
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 21 January 2019 17:07
> To: qemu-de...@nongnu.org
> Cc: Stefano Stabellini ; Paul Durrant
> ; xen-devel@lists.xenproject.org; Anthony Perard
>
> Subject: [PATCH] configure: xen: Stop build-testing for xc
On Mon, Jan 21, 2019 at 10:04:06AM +0200, 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, 16 Jan 2019 at 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 +-
>
On Mon, Jan 21, 2019 at 04:16:35PM +, Anthony PERARD wrote:
> As for
> https://lists.xenproject.org/archives/html/xen-devel/2018-10/msg01950.html
> It appear that the same QEMU 2.9.1 is used, but QEMU isn't supposed to
> use the function xc_map_foreign_bulk when built against Xen 4.12. That
>
On 17/01/2019 12:26, Jan Beulich wrote:
On 17.01.19 at 13:15, wrote:
>> On 17/01/2019 11:20, Jan Beulich wrote:
>> On 16.01.19 at 20:51, wrote:
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/
(+ Juergen)
On 21/01/2019 17:04, Andrii Anisov wrote:
From: Andrii Anisov
Dear All,
Hello,
All patches candidate for Xen 4.12 should have the release manager CCed and
explain the pros/cons to have those patches for this release. It is also useful
if you add for-4.12 (or similar) in the [.
On 16/01/2019 11:06, Roger Pau Monné wrote:
> On Wed, Jan 16, 2019 at 09:00:45AM +, Andrew Cooper wrote:
>>
>> ->> Control the use of Snoop Control.
>> -
>> -> `sharept`
>> -
>> -> Default: `true`
>> -
>> ->> Control whether CPU and IOMMU page tables should be shared.
>> -
>> -> `dom0-passthr
Hi,
On 21/12/2018 17:41, Andrii Anisov wrote:
From: Andrii Anisov
This reduces the number of context switches in case we have coming guest
interrupts from different sources at a high rate. What is likely for
multimedia use-cases.
Having irqs unlocked here makes us go through trap path again in
Hi,
On 21/12/2018 18:54, Andrii Anisov wrote:
From: Andrii Anisov
This function is called under IRQs disabled already, so drop additional
flags save and restore.
Signed-off-by: Andrii Anisov
Reviewed-by: Julien Grall
I will queue this patch for 4.13.
Cheers,
---
This is a half of an
Hi,
On 02/01/2019 18:33, André Przywara wrote:
On 26/12/2018 11:20, Andrii Anisov wrote:
Then I looked at the IRQ handler and stumbled upon the function pointers
we are using. I was eyeing them before, because my hunch is they are
costly, especially on big cores, as it might be hard for the CPU
On Mon, Jan 21, 2019 at 01:59:44AM -0800, Christopher Clark wrote:
> Initialises basic data structures and performs teardown of argo state
> for domain shutdown.
>
> Inclusion of the Argo implementation is dependent on CONFIG_ARGO.
>
> Introduces a new Xen command line parameter 'argo': bool to e
On 17/01/2019 13:35, Jan Beulich wrote:
On 16.01.19 at 10:00, wrote:
>> @@ -709,6 +709,12 @@ Controls for the dom0 IOMMU setup.
>> This option is enabled by default on x86 systems, and invalid on ARM
>> systems.
>>
>> +* The `none` option is intended for development purposes onl
1 - 100 of 125 matches
Mail list logo
