flight 132257 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132257/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 10 debian-di-installfail REGR. vs. 132086
On Fri, Jan 11, 2019 at 8:33 PM Souptick Joarder wrote:
>
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
>
> As this pattern is common across different drivers, it can
> be generalized
On 22/01/2019 00:41, Stefano Stabellini wrote:
> On Mon, 21 Jan 2019, Jan Beulich wrote:
> 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, 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
21.01.2019 18:17, Peter Maydell wrote:
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
flight 132250 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132250/
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 Mon, Jan 21, 2019 at 12:28:30AM -0800, h...@infradead.org wrote:
> 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:
On i.MX8, we implemented partition reboot which means Cortex-A reboot
will not impact M4 cores and System control Unit core. However GICv3
is not reset because hardware design.
The gic-v3 controller is configured with EOImode to 1, so during xen
reboot, GIC_SGI_CALL_FUNCTION interrupt from CPU0
Hi
> -Original Message-
> From: h...@infradead.org [mailto:h...@infradead.org]
> Sent: 2019年1月21日 16:29
> To: Peng Fan
> Cc: m...@redhat.com; jasow...@redhat.com; sstabell...@kernel.org;
> h...@infradead.org; virtualizat...@lists.linux-foundation.org;
> xen-devel@lists.xenproject.org;
flight 132258 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132258/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 839c0f8b261a9f1502e1a65517826340c263022f
baseline version:
freebsd
On Sat, 19 Jan 2019, Christoph Hellwig wrote:
> [full quote deleted, please take a little more care when quoting]
>
> On Fri, Jan 18, 2019 at 04:44:23PM -0800, Stefano Stabellini wrote:
> > > #ifdef CONFIG_XEN
> > > - if (xen_initial_domain()) {
> > > - dev->archdata.dev_dma_ops =
On Mon, 21 Jan 2019, Jan Beulich wrote:
> >>> 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:
On Mon, 21 Jan 2019, Jan Beulich wrote:
> >>> 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
flight 132252 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132252/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
129475
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-pair
testid xen-boot/dst_host
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
flight 132287 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132287/
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 132179 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132179/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 128858
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. "no-attr=uc" is ambiguous and
shouldn't be accepted, but accept "attr=no" as an acceptable alternative.
Update the command line documentation for
See individual patches for the delta from v3.
Andrew Cooper (3):
docs: Improve documentation and parsing for efi=
xen/dom0: Deprecate iommu_hwdom_inclusive and leave it disabled by default
xen/dom0: Add a dom0-iommu=none option
docs/misc/xen-command-line.pandoc | 41
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.
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
Hi,
I've been trying to use the pkg-config files generated in
tools/pkg-config/ when building QEMU, but those files only contains
"-Wl,-rpath-link" and "-l" options. At link times, the linker just
doesn't find the *.so.
Are those *.pc actually used anywhere, and working for someone? QEMU
Hi,
Ping?
Cheers,
On 30/11/2018 17:25, Julien Grall wrote:
Hi,
Below a list of backport candidate for Arm.
For Xen 4.10+ to handle correctly SMC call parameters and result
35fc608612 xen/arm: smccc-1.1: Make return values unsigned long
fa7974f743 xen/arm: smccc-1.1: Handle
Hi Andrii,
Thank you for the numbers.
On 26/12/2018 11:20, Andrii Anisov wrote:
From: Andrii Anisov
This patch series is an attempt to reduce IRQ latency with the
old GIC implementation (gic-vgic). These patches originally based
on XEN 4.10 release. The motivation was to improve benchmark
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
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
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
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
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
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.
>> -
>> ->
(+ 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 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
>> +++
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 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 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
> -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
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
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
---
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
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
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.
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
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
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
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)
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
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
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)
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
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
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
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(-)
>
>
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
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
---
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
> -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 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
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 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
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
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.
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:
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
>>> 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
>>> 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
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
> -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
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,
>>> 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
>>> 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:
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
> @@
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
> >
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!
>>> 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:
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
>>> 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
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
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
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
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:
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
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
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
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
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
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:
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
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
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
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
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:
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.
>>> 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
>>> 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 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
> -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
> ;
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
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
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
>
1 - 100 of 124 matches
Mail list logo
