Re: [Xen-devel] [PATCH v4 09/10] tools/arm: tee: add "tee" option for xl.cfg

Hi Julien, On Mon, Mar 18, 2019 at 03:49:12PM +, Julien Grall wrote: > (+ Achin) > > On 07/03/2019 21:04, Volodymyr Babchuk wrote: > > From: Volodymyr Babchuk > > > > This enumeration controls TEE type for a domain. Currently there is > > two possible options: either 'none' or 'native'. > > >

Re: [Xen-devel] [PATCH v1 1/4] xen: add hypercall for getting parameters at runtime

On 18/03/2019 18:01, Jan Beulich wrote: On 18.03.19 at 16:44, wrote: >> On Mon, 2019-03-18 at 15:02 +0100, Jan Beulich wrote: > I'm also > unconvinced this is appropriate if the value is actually > a signed quantity. isn't OPT_UINT only for unsigned integers? >>> >>> You

[Xen-devel] [ovmf baseline-only test] 83748: trouble: blocked/broken

This run is configured for baseline tests only. flight 83748 ovmf real [real] http://osstest.xensource.com/osstest/logs/83748/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm

[Xen-devel] [RESEND PATCH v4 9/9] xen/privcmd-buf.c: Convert to use vm_map_pages_zero()

Convert to use vm_map_pages_zero() to map range of kernel memory to user vma. This driver has ignored vm_pgoff. We could later "fix" these drivers to behave according to the normal vm_pgoff offsetting simply by removing the _zero suffix on the function name and if that causes regressions, it gives

[Xen-devel] [RESEND PATCH v4 8/9] xen/gntdev.c: Convert to use vm_map_pages()

Convert to use vm_map_pages() to map range of kernel memory to user vma. map->count is passed to vm_map_pages() and internal API verify map->count against count ( count = vma_pages(vma)) for page array boundary overrun condition. Signed-off-by: Souptick Joarder Reviewed-by: Boris Ostrovsky ---

[Xen-devel] [RESEND PATCH v4 5/9] drm/xen/xen_drm_front_gem.c: Convert to use vm_map_pages()

Convert to use vm_map_pages() to map range of kernel memory to user vma. Signed-off-by: Souptick Joarder Reviewed-by: Oleksandr Andrushchenko --- drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 +- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/xen/x

[Xen-devel] [RESEND PATCH v4 1/9] mm: Introduce new vm_map_pages() and vm_map_pages_zero() API

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 by creating new functions and use it across the drivers. vm_map_pages(

[Xen-devel] [RESEND PATCH v4 0/9] mm: Use vm_map_pages() and vm_map_pages_zero() API

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 by creating new functions and use it across the drivers. vm_map_pages(

[Xen-devel] [freebsd-master test] 133898: all pass - PUSHED

flight 133898 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/133898/ Perfect :-) All tests in this flight passed as required version targeted for testing: freebsd b24a98cb7ea88b59c90e29449588acb7839a747a baseline version: freebsd 4545fe820a8

[Xen-devel] [xen-4.9-testing test] 133881: regressions - FAIL

flight 133881 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/133881/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs. 132889 test-am

[Xen-devel] [xen-4.8-testing test] 133879: regressions - FAIL

flight 133879 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/133879/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs. 130965 Tests

[Xen-devel] [qemu-mainline baseline-only test] 83747: trouble: blocked/broken

This run is configured for baseline tests only. flight 83747 qemu-mainline real [real] http://osstest.xensource.com/osstest/logs/83747/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64

Re: [Xen-devel] [PATCH v3] xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored

On Mon, Mar 18, 2019 at 06:37:31PM +0100, Roger Pau Monne wrote: > Or if it's not possible to honor the hinted address an error is returned > instead. Just to be sure: MAP_FIXED will cause to map at specified address, even if something is mapped there already. From mmap(2): If the memory reg

Re: [Xen-devel] [PATCH RFC 05/55] x86/mm: introduce l{1, 2}t local variables to modify_xen_mappings

On Thu, 2019-02-07 at 16:44 +, Wei Liu wrote: > The pl2e and pl1e variables are heavily (ab)used in that > function.  It > is fine at the moment because all page tables are always mapped so > there is no need to track the life time of each variable. > > We will soon have the requirement to map

Re: [Xen-devel] [PATCH RFC 23/55] x86_64/mm: drop l4e_to_l3e invocation from paging_init

On Thu, 2019-02-07 at 16:44 +, Wei Liu wrote: > Signed-off-by: Wei Liu Any reason why this isn't squashed with the previous patch? - Stefan > --- >  xen/arch/x86/x86_64/mm.c | 7 +-- >  1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/

Re: [Xen-devel] [PATCH RFC 07/55] x86/mm: add an end_of_loop label in map_pages_to_xen

On Thu, 2019-02-07 at 16:44 +, Wei Liu wrote: > We will soon need to clean up mappings whenever the out most loop is > ended. Add a new label and turn relevant continue's into goto's. > > No functional change. > > Signed-off-by: Wei Liu > --- I'm not as opposed to this use of goto as Jan, b

Re: [Xen-devel] [PATCH RFC 27/55] x86_64/mm: drop lXe_to_lYe invocations from setup_m2p_table

On Thu, 2019-02-07 at 16:44 +, Wei Liu wrote: > Signed-off-by: Wei Liu > --- >  xen/arch/x86/x86_64/mm.c | 16 >  1 file changed, 12 insertions(+), 4 deletions(-) > > diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c > index 0b85961105..216f97c95f 100644 > --- a

Re: [Xen-devel] [PATCH RFC 25/55] x86_64/mm: introduce pl2e in setup_m2p_table

On Thu, 2019-02-07 at 16:44 +, Wei Liu wrote: > Signed-off-by: Wei Liu > --- >  xen/arch/x86/x86_64/mm.c | 9 + >  1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c > index 55fa338d71..d3e2398b6c 100644 > --- a/xen/arch

Re: [Xen-devel] [PATCH RFC 00/55] x86: use domheap page for xen page tables

On Thu, 2019-02-07 at 16:44 +, Wei Liu wrote: > This series switches xen page tables from xenheap page to domheap > page. > > This is required so that when we implement xenheap on top of vmap > there won't > be a loop. > > It is done in roughly three steps: > > 1. Introduce a new set of APIs

Re: [Xen-devel] [PATCH RFC 21/55] x86_64/mm: introduce pl2e in paging_init

On Thu, 2019-02-07 at 16:44 +, Wei Liu wrote: > Introduce pl2e so that we can use l2_ro_mpt to point to the page > table > itself. > > No functional change. > > Signed-off-by: Wei Liu > --- >  xen/arch/x86/x86_64/mm.c | 18 ++ >  1 file changed, 10 insertions(+), 8 deletions(-

Re: [Xen-devel] [PATCH RFC 31/55] efi: add emacs block to boot.c

On Thu, 2019-02-07 at 16:44 +, Wei Liu wrote: > Signed-off-by: Wei Liu > --- >  xen/common/efi/boot.c | 10 ++ >  1 file changed, 10 insertions(+) > > diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c > index 1d1420f02c..3868293d06 100644 > --- a/xen/common/efi/boot.c > +++ b/

Re: [Xen-devel] [PATCH RFC 32/55] efi: switch EFI L4 table to use new APIs

On Thu, 2019-02-07 at 16:44 +, Wei Liu wrote: > This requires storing the MFN instead of linear address of the L4 > table. Adjust code accordingly. > > Signed-off-by: Wei Liu > --- >  xen/arch/x86/efi/runtime.h | 12 +--- >  xen/common/efi/boot.c  |  8 ++-- >  xen/common/efi/ef

Re: [Xen-devel] [PATCH RFC 17/55] x86/mm: drop lXe_to_lYe invocations in map_pages_to_xen

On Thu, 2019-02-07 at 16:44 +, Wei Liu wrote: > Map and unmap page tables where necessary. > > Signed-off-by: Wei Liu > --- >  xen/arch/x86/mm.c | 40 +--- >  1 file changed, 29 insertions(+), 11 deletions(-) > > diff --git a/xen/arch/x86/mm.c b/xen/arch/x8

Re: [Xen-devel] [PATCH RFC 06/55] x86/mm: map_pages_to_xen should have one exit path

On Thu, 2019-02-07 at 16:44 +, Wei Liu wrote: > We will soon rewrite the function to handle dynamically mapping and > unmapping of page tables. > > No functional change. > > Signed-off-by: Wei Liu > --- >  xen/arch/x86/mm.c | 34 +++--- >  1 file changed, 27 insert

Re: [Xen-devel] [PATCH RFC 14/55] x86/mm: rewrite xen_to_virt_l2e

On Thu, 2019-02-07 at 16:44 +, Wei Liu wrote: > Rewrite that function to use the new APIs. Modify its callers to > unmap > the pointer returned. > > Signed-off-by: Wei Liu > --- nit: the commit title should be 'virt_to_xen_l2e' not 'xen_to_virt...' Amazon Development Center Germany GmbH

[Xen-devel] [xen-unstable-smoke test] 133911: tolerable all pass - PUSHED

flight 133911 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/133911/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 1

Re: [Xen-devel] [PATCH RFC 16/55] x86/mm: switch to new APIs in map_pages_to_xen

On Fri, 2019-02-08 at 17:58 +, Wei Liu wrote: > On Thu, Feb 07, 2019 at 04:44:17PM +, Wei Liu wrote: > > > > Page tables allocated in that function should be mapped and > > unmapped > > now. > > > > Signed-off-by: Wei Liu > > --- > >  xen/arch/x86/mm.c | 31 ++

Re: [Xen-devel] [PATCH RFC 18/55] x86/mm: switch to new APIs in modify_xen_mappings

On Thu, 2019-02-07 at 16:44 +, Wei Liu wrote: > Page tables allocated in that function should be mapped and unmapped > now. > > Signed-off-by: Wei Liu > --- >  xen/arch/x86/mm.c | 31 ++- >  1 file changed, 22 insertions(+), 9 deletions(-) > > diff --git a/xen/arch

[Xen-devel] Xen Project Automotive Workshop (March 25/26, Cambridge, UK, Citrix) - last chance to register for & logistics

Hi all, this is a quick reminder that https://wiki.xenproject.org/wiki/Developer_Meeting/March2019_-_Safety_Certification takes place Monday and Tuesday next week Attending in person If you are planning to a

[Xen-devel] [xen-unstable baseline-only test] 83745: trouble: blocked/broken

This run is configured for baseline tests only. flight 83745 xen-unstable real [real] http://osstest.xensource.com/osstest/logs/83745/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64

[Xen-devel] [xen-unstable-smoke test] 133907: tolerable all pass - PUSHED

flight 133907 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/133907/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 1

[Xen-devel] [ovmf test] 133887: all pass - PUSHED

flight 133887 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/133887/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 34b162d078aa59d55059f08a0f15dd114e7b7db4 baseline version: ovmf c49f298d28cb90c332f8d

Re: [Xen-devel] [PATCH v3] xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored

On 18/03/2019 17:37, Roger Pau Monne wrote: > Or if it's not possible to honor the hinted address an error is returned > instead. This makes it easier to spot the actual failure, instead of > failing later on when the caller of xen_remap_bucket realizes the > mapping has not been created at the req

[Xen-devel] [PATCH v3] xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored

Or if it's not possible to honor the hinted address an error is returned instead. This makes it easier to spot the actual failure, instead of failing later on when the caller of xen_remap_bucket realizes the mapping has not been created at the requested address. Also note that at least on FreeBSD

[Xen-devel] [qemu-mainline test] 133872: tolerable FAIL - PUSHED

flight 133872 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/133872/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 guest-saverestore fail in 133844 pass in 133872 test-amd

Re: [Xen-devel] [PATCH v8 10/11] viridian: add implementation of synthetic timers

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 18 March 2019 16:56 > To: Paul Durrant > Cc: Julien Grall ; Andrew Cooper > ; George Dunlap > ; Ian Jackson ; Roger Pau > Monne > ; Wei Liu ; Stefano Stabellini > ; > xen-devel ; Konrad Rzeszutek Wilk > ; Tim >

Re: [Xen-devel] [PATCH v1 1/4] xen: add hypercall for getting parameters at runtime

>>> On 18.03.19 at 16:44, wrote: > On Mon, 2019-03-18 at 15:02 +0100, Jan Beulich wrote: >> > > I'm also >> > > unconvinced this is appropriate if the value is actually >> > > a signed quantity. >> > >> > isn't OPT_UINT only for unsigned integers? >> >> You'll notice that there's no OPT_INT or O

Re: [Xen-devel] [PATCH v8 10/11] viridian: add implementation of synthetic timers

>>> On 18.03.19 at 17:26, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 18 March 2019 16:23 >> >> >>> On 18.03.19 at 16:46, wrote: >> >> > > +{ >> >> > > +expiration = vs->count; >> >> > > +if ( expiration - now <= 0 ) >> >> > > +{ >> >> > > +

Re: [Xen-devel] [PATCH v2 02/14] x86/cpu/mtrr: Add Hygon Dhyana support to get TOP_MEM2

>>> On 18.03.19 at 16:51, wrote: > On 2019/3/18 16:57, Jan Beulich wrote: > On 16.03.19 at 11:06, wrote: >>> On 2019/3/15 20:40, Jan Beulich wrote: >>> On 21.02.19 at 10:48, wrote: > The Hygon Dhyana CPU supports the MSR way to get TOP_MEM2. So add Hygon > Dhyana support to print

Re: [Xen-devel] [PATCH v2] xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored

> -Original Message- > From: Anthony PERARD [mailto:anthony.per...@citrix.com] > Sent: 18 March 2019 16:35 > To: Igor Druzhinin > Cc: Roger Pau Monne ; qemu-de...@nongnu.org; Stefano > Stabellini > ; Paul Durrant ; Paolo > Bonzini ; > Richard Henderson ; Eduardo Habkost ; > Michael S. T

Re: [Xen-devel] [PATCH v2] xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored

On Mon, Mar 18, 2019 at 03:48:59PM +, Igor Druzhinin wrote: > On 18/03/2019 15:45, Roger Pau Monne wrote: > > diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c > > index 349f72d00c..23de5517db 100644 > > --- a/hw/i386/xen/xen-mapcache.c > > +++ b/hw/i386/xen/xen-mapcache.c >

Re: [Xen-devel] [PATCH v8 10/11] viridian: add implementation of synthetic timers

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 18 March 2019 16:23 > To: Paul Durrant > Cc: Julien Grall ; Andrew Cooper > ; George Dunlap > ; Ian Jackson ; Roger Pau > Monne > ; Wei Liu ; Stefano Stabellini > ; > xen-devel ; Konrad Rzeszutek Wilk > ; Tim >

Re: [Xen-devel] [PATCH v8 10/11] viridian: add implementation of synthetic timers

>>> On 18.03.19 at 16:46, wrote: >> > > +{ >> > > +expiration = vs->count; >> > > +if ( expiration - now <= 0 ) >> > > +{ >> > > +vs->expiration = expiration; >> > > +stimer_expire(vs); >> > >> > Aren't you introducing a risk for races by calling

Re: [Xen-devel] [PATCH v8 10/11] viridian: add implementation of synthetic timers

>>> On 18.03.19 at 16:36, wrote: >> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of >> Jan Beulich >> Sent: 18 March 2019 15:21 >> >> >>> On 18.03.19 at 15:37, wrote: >> >> From: Jan Beulich [mailto:jbeul...@suse.com] >> >> Sent: 18 March 2019 14:24 >> >> >> >> >>>

[Xen-devel] preparations for 4.11.2

All, the release is due by the end of the month, but will likely don't make it before early April. Please point out backports you find missing from the respective staging branch, but which you consider relevant. The one commit I've queued already on top of what was just pushed is 22e2f8dddf

Re: [Xen-devel] [PATCH v2] xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored

On Mon, Mar 18, 2019 at 03:48:59PM +, Igor Druzhinin wrote: > On 18/03/2019 15:45, Roger Pau Monne wrote: > > Or if it's not possible to honor the hinted address an error is returned > > instead. This makes it easier to spot the actual failure, instead of > > failing later on when the caller of

Re: [Xen-devel] [PATCH v2 02/14] x86/cpu/mtrr: Add Hygon Dhyana support to get TOP_MEM2

On 2019/3/18 16:57, Jan Beulich wrote: On 16.03.19 at 11:06, wrote: >> On 2019/3/15 20:40, Jan Beulich wrote: >> On 21.02.19 at 10:48, wrote: The Hygon Dhyana CPU supports the MSR way to get TOP_MEM2. So add Hygon Dhyana support to print the value of TOP_MEM2. Signed-

Re: [Xen-devel] [PATCH v4 10/10] tools/arm: optee: create optee firmware node in DT if tee=native

Hi, On 07/03/2019 21:04, Volodymyr Babchuk wrote: static int make_memory_nodes(libxl__gc *gc, void *fdt, const struct xc_dom_image *dom) { @@ -933,6 +959,9 @@ next_resize: if (info->arch_arm.vuart == LIBXL_VUART_TYPE_SBSA_UART) FDT( make

Re: [Xen-devel] [PATCH v2] xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored

> -Original Message- > From: Roger Pau Monne [mailto:roger@citrix.com] > Sent: 18 March 2019 15:46 > To: qemu-de...@nongnu.org > Cc: Roger Pau Monne ; Stefano Stabellini > ; Anthony > Perard ; Paul Durrant ; > Igor Druzhinin > ; Paolo Bonzini ; Richard > Henderson ; > Eduardo Habkost

Re: [Xen-devel] [PATCH v8 10/11] viridian: add implementation of synthetic timers

> -Original Message- [snip] > > > +{ > > > +expiration = vs->count; > > > +if ( expiration - now <= 0 ) > > > +{ > > > +vs->expiration = expiration; > > > +stimer_expire(vs); > > > > Aren't you introducing a risk for races by calling the t

Re: [Xen-devel] [PATCH v4 09/10] tools/arm: tee: add "tee" option for xl.cfg

(+ Achin) On 07/03/2019 21:04, Volodymyr Babchuk wrote: From: Volodymyr Babchuk This enumeration controls TEE type for a domain. Currently there is two possible options: either 'none' or 'native'. 'none' is the default value and it basically disables TEE support at all. 'native' enables acce

Re: [Xen-devel] [PATCH v2] xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored

On 18/03/2019 15:45, Roger Pau Monne wrote: > Or if it's not possible to honor the hinted address an error is returned > instead. This makes it easier to spot the actual failure, instead of > failing later on when the caller of xen_remap_bucket realizes the > mapping has not been created at the req

[Xen-devel] [PATCH v2] xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored

Or if it's not possible to honor the hinted address an error is returned instead. This makes it easier to spot the actual failure, instead of failing later on when the caller of xen_remap_bucket realizes the mapping has not been created at the requested address. Also note that at least on FreeBSD

Re: [Xen-devel] [PATCH v1 1/4] xen: add hypercall for getting parameters at runtime

On Mon, 2019-03-18 at 15:02 +0100, Jan Beulich wrote: > > > > From the return value of strcmp()? I don't think so, because > > > > you > may have run past all table entries. Instead it's that property > that you can use, i.e. checking whether ... > > > > > +for ( param = start; param < end

Re: [Xen-devel] [PATCH v8 10/11] viridian: add implementation of synthetic timers

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of > Jan Beulich > Sent: 18 March 2019 15:21 > To: Paul Durrant > Cc: Stefano Stabellini ; Wei Liu > ; Konrad Rzeszutek Wilk > ; Andrew Cooper ; Tim > (Xen.org) ; > George Dunlap ; Julien Gr

Re: [Xen-devel] [PATCH v4 08/10] xen/arm: optee: add support for RPC commands

Hi Volodymyr, On 07/03/2019 21:04, Volodymyr Babchuk wrote: @@ -376,8 +391,11 @@ static struct shm_rpc *allocate_and_pin_shm_rpc(struct optee_domain *ctx, return shm_rpc; err: +free_domheap_page(shm_rpc->xen_arg_pg); + if ( shm_rpc->guest_page ) put_page(shm_rpc-

[Xen-devel] [libvirt test] 133876: regressions - FAIL

flight 133876 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/133876/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 133846 test-amd64-amd64-libvir

Re: [Xen-devel] [PATCH v4 07/10] xen/arm: optee: add support for arbitrary shared memory

On 07/03/2019 21:04, Volodymyr Babchuk wrote: From: Volodymyr Babchuk Some of the patches are using your EPAM e-mail addresss. Other are using your gmail address. Could you confirm this is expected? Shared memory is widely used by NW (Normal World) to communicate with TAs (Trusted Appli

Re: [Xen-devel] [PATCH v8 10/11] viridian: add implementation of synthetic timers

>>> On 18.03.19 at 15:37, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 18 March 2019 14:24 >> >> >>> On 18.03.19 at 12:20, wrote: >> > @@ -72,11 +77,14 @@ static void update_reference_tsc(struct domain *d, >> > bool initialize) >> > * ticks per 100ns shifted left by 64.

Re: [Xen-devel] Running XEN on imx8mq

Hello, > It will be difficult to help without any log. You probably want to try with > Stefano series instead. However ... If we comment out GPU node(gpu@3800) , we don't see this issue and Dom0 kernel is loaded into memory but we following crash: Starting kernel ... - UART enabled - - CPU

Re: [Xen-devel] [PATCH v2] x86/atomic: Improvements and simplifications to assembly constraints

>>> On 18.03.19 at 15:49, wrote: > On 18/03/2019 14:11, Andrew Cooper wrote: >> @@ -63,36 +65,38 @@ static always_inline __uint128_t cmpxchg16b_local_( * If no fault occurs then _o is updated to the value we saw at _p. If this * is the same as the initial value of _o then

[Xen-devel] Xen 4.12 RC6

Hi all, Xen 4.12 rc6 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.12.0-rc6 For your convenience there is also a tarball at: https://downloads.xenproject.org/release/xen/4.12.0-rc6/xen-4.12.0-rc6.tar.gz And the signature is at: https://downloads.xenproject.org/

Re: [Xen-devel] [PATCH v2] x86/atomic: Improvements and simplifications to assembly constraints

>>> On 18.03.19 at 15:11, wrote: > On 18/03/2019 13:20, Jan Beulich wrote: >> >>> On 18.03.19 at 12:27, wrote: >>> * Some of the single-byte versions specify "=q" as the output. This is a >>>remnent of the 32bit build and can be relaxed to "=r" in 64bit builds. >> I have to admit that I don

[Xen-devel] [PATCH 1/2] x86: decouple xen alignment setting from EFI/non-EFI build

Introduce a new Kconfig option to pick the alignment for xen binary. To retain original behaviour, the default pick for EFI build is 2M and non-EFI build 4K. Signed-off-by: Wei Liu --- xen/arch/x86/Kconfig | 26 ++ xen/arch/x86/xen.lds.S | 16 ++-- 2 files c

[Xen-devel] [PATCH 0/2] x86: more flexible alignment handling for xen binary

Wei Liu (2): x86: decouple xen alignment setting from EFI/non-EFI build x86/pvshim: use 2M alignment xen/arch/x86/Kconfig | 26 ++ xen/arch/x86/configs/pvshim_defconfig | 1 + xen/arch/x86/xen.lds.S| 16 ++-- 3 files change

[Xen-devel] [PATCH 2/2] x86/pvshim: use 2M alignment

The pvshim is loaded directly by toolstack. Use 2M alignment for potential better performance. Signed-off-by: Wei Liu --- xen/arch/x86/configs/pvshim_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/x86/configs/pvshim_defconfig b/xen/arch/x86/configs/pvshim_defconfig index

Re: [Xen-devel] [PATCH v2] x86/atomic: Improvements and simplifications to assembly constraints

On 18/03/2019 14:11, Andrew Cooper wrote: > >>> @@ -63,36 +65,38 @@ static always_inline __uint128_t cmpxchg16b_local_( >>> * If no fault occurs then _o is updated to the value we saw at _p. If this >>> * is the same as the initial value of _o then _n is written to location >>> _p. >>> */ >>

[Xen-devel] 回复：Re: Xen ARM Fault recovery for automotive use case

> On 18/03/2019 06:50, rambl...@sina.com wrote: > > Hello, > Hello, > > I'm researching xen for automotive use case and I see a presentation called: > > "Design and Implementation of Automotive Virtualization Based on Xen - > > Sung-Min > > Lee, Samsung Electronics" > > on Xen Developer and Design

Re: [Xen-devel] [PATCH v8 10/11] viridian: add implementation of synthetic timers

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 18 March 2019 14:24 > To: Paul Durrant > Cc: Julien Grall ; Andrew Cooper > ; Roger Pau Monne > ; Wei Liu ; George Dunlap > ; Ian > Jackson ; Stefano Stabellini > ; xen-devel de...@lists.xenproject.org>; Konrad

[Xen-devel] [linux-linus test] 133863: regressions - FAIL

flight 133863 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/133863/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-credit1 12 guest-start fail REGR. vs. 133580 test-arm64-arm64-xl

Re: [Xen-devel] [PATCH v8 10/11] viridian: add implementation of synthetic timers

>>> On 18.03.19 at 12:20, wrote: > @@ -72,11 +77,14 @@ static void update_reference_tsc(struct domain *d, bool > initialize) > * ticks per 100ns shifted left by 64. > */ > p->TscScale = ((1ul << 32) / d->arch.tsc_khz) << 32; > +smp_wmb(); > + > +seq = p->TscSequence +

Re: [Xen-devel] [PATCH v4 06/10] xen/arm: optee: add support for RPC SHM buffers

Hi Volodymyr, On 07/03/2019 21:04, Volodymyr Babchuk wrote: From: Volodymyr Babchuk OP-TEE usually uses the same idea with command buffers (see previous commit) to issue RPC requests. Problem is that initially it has no buffer, where it can write request. So the first RPC request it makes is s

Re: [Xen-devel] [PATCH v2] x86/atomic: Improvements and simplifications to assembly constraints

On 18/03/2019 13:20, Jan Beulich wrote: > >>> On 18.03.19 at 12:27, wrote: >> * Some of the single-byte versions specify "=q" as the output. This is a >>remnent of the 32bit build and can be relaxed to "=r" in 64bit builds. > I have to admit that I don't understand the "relaxed" part of this

Re: [Xen-devel] [PATCH v1 1/4] xen: add hypercall for getting parameters at runtime

>>> On 18.03.19 at 14:34, wrote: > On Wed, 2019-03-13 at 17:35 +0100, Jan Beulich wrote: >> > > > On 06.03.19 at 13:58, wrote: >> > +found = false; >> >> I don't think you need this variable here, or if so, it shouldn't >> be boolean: Either you mean to support returning data for >> mult

[Xen-devel] saucy doesn't exist

Hi, I closely followed https://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/CrossCompiling to cross compile xen tool, but "saucy" is a wrong option now. Which discts/folder would you recommend now? sbuild-createchroot --components=main,universe saucy /srv/chroots/saucy-armhf-cross

Re: [Xen-devel] [PATCH v4 05/10] xen/arm: optee: add std call handling

Hi Volodymyr, Only few NITs in this patch. See below: On 07/03/2019 21:04, Volodymyr Babchuk wrote: +/* + * Default maximal number concurrent threads that OP-TEE supports. + * This limits number of standard calls that guest can have. + */ +#define DEF_MAX_OPTEE_THREADS 16 + #define OPTEE_KNOW

Re: [Xen-devel] [PATCH 0/2 for-4.12] Introduce runstate area registration with phys address

On 18.03.19 14:25, Julien Grall wrote: As I already said multiple times before, please try to explain everything in your first e-mail... I know. I'm trying to provide enough info in the cover letter. But it seems I do not succeed. Putting all the thoughts might lead into overburdened text. B

Re: [Xen-devel] [PATCH v1 1/4] xen: add hypercall for getting parameters at runtime

thanks for the review. On Wed, 2019-03-13 at 17:35 +0100, Jan Beulich wrote: > > > > On 06.03.19 at 13:58, wrote: > > +static int get_params(const char *cmdline, char *values, > > + const struct kernel_param *start, > > + const struct kernel_param *end) >

Re: [Xen-devel] [PATCH] x86/spec_ctrl: Extend repoline safey calcuations for eIBRS and Atom parts

>>> On 18.03.19 at 14:04, wrote: > On 18/03/2019 11:58, Jan Beulich wrote: > On 18.03.19 at 12:27, wrote: >>> However, an additional meaning of Enhanced IRBS is that the processor may >>> not >>> be retpoline-safe. The Gemini Lake platform, based on the Goldmont+ >>> microarchitecture is th

Re: [Xen-devel] [PATCH v2] x86/atomic: Improvements and simplifications to assembly constraints

>>> On 18.03.19 at 12:27, wrote: > * Some of the single-byte versions specify "=q" as the output. This is a >remnent of the 32bit build and can be relaxed to "=r" in 64bit builds. I have to admit that I don't understand the "relaxed" part of this: "q" and "r" represent the exact same set of

Re: [Xen-devel] Xen ARM Fault recovery for automotive use case

On 18/03/2019 06:50, rambl...@sina.com wrote: Hello, Hello, I'm researching xen for automotive use case and I see a presentation called: "Design and Implementation of Automotive Virtualization Based on Xen - Sung-Min Lee, Samsung Electronics" on Xen Developer and Design Summit 2018. I'm in

[Xen-devel] [PATCH 4/6] xen: don't free percpu areas during suspend

Instead of freeing percpu areas during suspend and allocating them again when resuming keep them. Only free an area in case a cpu didn't come up again when resuming. Signed-off-by: Juergen Gross --- xen/arch/x86/percpu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xen/a

[Xen-devel] [PATCH 2/6] xen: add helper for calling notifier_call_chain() to common/cpu.c

Add a helper cpu_notifier_call_chain() to call notifier_call_chain() for a cpu with a specified action, returning an errno value. This avoids coding the same pattern multiple times. Signed-off-by: Juergen Gross --- xen/common/cpu.c | 50 +- 1 file

[Xen-devel] [PATCH 0/6] xen: simplify suspend/resume handling

Especially in the scheduler area (schedule.c, cpupool.c) there is a rather complex handling involved when doing suspend and resume. This can be simplified a lot by not performing a complete cpu down and up cycle for the non-boot cpus, but keeping the pure software related state and freeing it only

[Xen-devel] [PATCH 1/6] xen/sched: call cpu_disable_scheduler() via cpu notifier

cpu_disable_scheduler() is being called from __cpu_disable() today. There is no need to call it on the cpu just being disabled, so use the CPU_DEAD case of the cpu notifier chain. Signed-off-by: Juergen Gross --- xen/arch/x86/smpboot.c | 3 --- xen/common/schedule.c | 12 +--- 2 files

[Xen-devel] [PATCH 6/6] xen/sched: don't disable scheduler on cpus during suspend

Today there is special handling in cpu_disable_scheduler() for suspend by forcing all vcpus to the boot cpu. In fact there is no need for that as during resume the vcpus are put on the correct cpus again. So we can just omit the call of cpu_disable_scheduler() when offlining a cpu due to suspend a

[Xen-devel] [PATCH 3/6] xen: add new cpu notifier action CPU_RESUME_FAILED

Add a new cpu notifier action CPU_RESUME_FAILED which is called for all cpus which failed to come up at resume. The calls will be done after all other cpus are already up. Signed-off-by: Juergen Gross --- xen/common/cpu.c | 5 + xen/include/xen/cpu.h | 20 +++- 2 files

[Xen-devel] [PATCH 5/6] xen/cpupool: simplify suspend/resume handling

Instead of removing cpus temporarily from cpupools during suspend/resume only remove cpus finally which didn't come up when resuming. Signed-off-by: Juergen Gross --- xen/common/cpupool.c | 130 ++--- xen/include/xen/sched-if.h | 1 - 2 files chang

Re: [Xen-devel] [PATCH] x86/spec_ctrl: Extend repoline safey calcuations for eIBRS and Atom parts

On 18/03/2019 11:58, Jan Beulich wrote: On 18.03.19 at 12:27, wrote: >> However, an additional meaning of Enhanced IRBS is that the processor may not >> be retpoline-safe. The Gemini Lake platform, based on the Goldmont+ >> microarchitecture is the first Atom processor to support eIBRS, even

[Xen-devel] [xen-unstable-smoke test] 133900: tolerable all pass - PUSHED

flight 133900 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/133900/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 1

Re: [Xen-devel] Running XEN on imx8mq

> It will be difficult to help without any log. You probably want to try with > Stefano series instead. However ... Yeah, tried Stefano series as well but show same message: Starting kernel ... - UART enabled - - CPU booting - - Current EL 0008 - - Xen starting at EL2 - - Zero BSS

Re: [Xen-devel] [PATCH] x86/msr: Shorten ARCH_CAPABILITIES_* constants

>>> On 18.03.19 at 12:45, wrote: > They are unnecesserily verbose, and ARCH_CAPS_* is already the more common > version. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists

Re: [Xen-devel] [PATCH 0/2 for-4.12] Introduce runstate area registration with phys address

On 18/03/2019 11:31, Andrii Anisov wrote: Hello Julien, Guys, Hi, Sorry for a delayed answer. I caught a pretty nasty flu after last long weekend, it made me completely unavailable last week :( Sorry to hear that. On 07.03.19 17:17, Julien Grall wrote: Why? Arm32 is as equally supported

Re: [Xen-devel] [PATCH] x86/spec_ctrl: Extend repoline safey calcuations for eIBRS and Atom parts

>>> On 18.03.19 at 12:27, wrote: > However, an additional meaning of Enhanced IRBS is that the processor may not > be retpoline-safe. The Gemini Lake platform, based on the Goldmont+ > microarchitecture is the first Atom processor to support eIBRS, even though it > is in practice safe. But afaic

[Xen-devel] [PATCH] x86/msr: Shorten ARCH_CAPABILITIES_* constants

They are unnecesserily verbose, and ARCH_CAPS_* is already the more common version. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné --- xen/arch/x86/spec_ctrl.c| 10 +- xen/include/asm-x86/msr-index.h | 4 ++-- 2 files changed, 7 insertions(+)

[Xen-devel] [distros-debian-sid test] 83744: trouble: blocked/broken

flight 83744 distros-debian-sid real [real] http://osstest.xensource.com/osstest/logs/83744/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvopsbroken build-i386

Re: [Xen-devel] [PATCH 0/2 for-4.12] Introduce runstate area registration with phys address

Hello Julien, Guys, Sorry for a delayed answer. I caught a pretty nasty flu after last long weekend, it made me completely unavailable last week :( On 07.03.19 17:17, Julien Grall wrote: Why? Arm32 is as equally supported as Arm64. Yep, I believe that. But I do not expect one would build arm3

[Xen-devel] [PATCH] x86/spec_ctrl: Extend repoline safey calcuations for eIBRS and Atom parts

All currently-released Atom processors are in practice retpoline-safe, because they don't fall back to a BTB prediction on RSB underflow. However, an additional meaning of Enhanced IRBS is that the processor may not be retpoline-safe. The Gemini Lake platform, based on the Goldmont+ microarchitec

[Xen-devel] [PATCH v2] x86/atomic: Improvements and simplifications to assembly constraints

* Some of the single-byte versions specify "=q" as the output. This is a remnent of the 32bit build and can be relaxed to "=r" in 64bit builds. * Constraints in the form "=r" (x) : "0" (x) can be folded to just "+r" (x) * Switch to using named parameters (mostly for legibility) which in p

[Xen-devel] [PATCH v8 10/11] viridian: add implementation of synthetic timers

This patch introduces an implementation of the STIMER0-15_CONFIG/COUNT MSRs and hence a the first SynIC message source. The new (and documented) 'stimer' viridian enlightenment group may be specified to enable this feature. While in the neighbourhood, this patch adds a missing check for an attemp

  1   2   >