RE: [PATCH V3 11/23] xen/ioreq: Move x86's io_completion/io_req fields to struct vcpu

> -Original Message- > From: Oleksandr > Sent: 07 December 2020 21:00 > To: Jan Beulich ; Paul Durrant > Cc: Oleksandr Tyshchenko ; Andrew Cooper > ; > Roger Pau Monné ; Wei Liu ; George Dunlap > ; Ian Jackson ; Julien Grall > ; Stefano > Stabellini ; Jun Nakajima ; > Kevin Tian > ;

[PATCH] xen/arm: Add workaround for Cortex-A53 erratum #845719

When executing in aarch32 state at EL0, a load at EL0 from a virtual address that matches the bottom 32 bits of the virtual address used by a recent load at (aarch64) EL1 might return incorrect data. The workaround is to insert a write of the contextidr_el1 register on exception return to an

Re: [PATCH 2/2] xen: don't use page->lru for ZONE_DEVICE memory

On 07.12.20 21:48, Jason Andryuk wrote: On Mon, Dec 7, 2020 at 8:30 AM Juergen Gross wrote: Commit 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated memory") introduced usage of ZONE_DEVICE memory for foreign memory mappings. Unfortunately this collides with using page->lru for Xen

[linux-linus test] 157266: regressions - FAIL

flight 157266 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/157266/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332

[RFC] design: design doc for 1:1 direct-map

This is one draft design about the infrastructure for now, not ready for upstream yet (hence the RFC tag), thought it'd be useful to firstly start a discussion with the community. Create one design doc for 1:1 direct-map. It aims to describe why and how we allocate 1:1 direct-map(guest physical

Re: [SPECIFICATION RFC] The firmware and bootloader log specification

On Fri, Dec 04, 2020 at 02:23:23PM +0100, Paul Menzel wrote: > Dear Wim, dear Daniel, > > > First, thank you for including all parties in the discussion. > Am 04.12.20 um 13:52 schrieb Wim Vervoorn: > > > I agree with you. Using an existing standard is better than inventing > > a new one in

Re: (subset) [PATCH 000/141] Fix fall-through warnings for Clang

On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote: > This series aims to fix almost all remaining fall-through warnings in > order to enable -Wimplicit-fallthrough for Clang. > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly > add multiple

[xen-unstable test] 157263: regressions - FAIL

flight 157263 xen-unstable real [real] flight 157269 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/157263/ http://logs.test-lab.xenproject.org/osstest/logs/157269/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be

[qemu-mainline test] 157261: regressions - FAIL

flight 157261 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/157261/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 152631

Re: [PATCH 2/2] xen: don't use page->lru for ZONE_DEVICE memory

On 12/7/20 8:30 AM, Juergen Gross wrote: > --- a/drivers/xen/unpopulated-alloc.c > +++ b/drivers/xen/unpopulated-alloc.c > @@ -12,7 +12,7 @@ > #include > > static DEFINE_MUTEX(list_lock); > -static LIST_HEAD(page_list); > +static struct page *page_list; next_page or next_allocated_page?

Re: [PATCH 1/2] xen: add helpers for caching grant mapping pages

On 12/7/20 8:30 AM, Juergen Gross wrote: > Instead of having similar helpers in multiple backend drivers use > common helpers for caching pages allocated via gnttab_alloc_pages(). > > Make use of those helpers in blkback and scsiback. > > Signed-off-by: Juergen Gross Reviewed-by: Boris

Re: [RFC PATCH] xen/arm: domain_build: Ignore empty memory bank

On Mon, Dec 07, 2020 at 07:36:11AM -0800, Elliott Mitchell wrote: > Commit 5a37207df52066efefe419c677b089a654d37afc changed this behavior to > ignore such banks. Unfortunately this means these empty nodes are > visible to code which accesses the device trees. Have domain_build also > ignore

[linux-linus test] 157257: regressions - FAIL

flight 157257 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/157257/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332

Re: [PATCH V3 10/23] xen/mm: Make x86's XENMEM_resource_ioreq_server handling common

On 07.12.20 14:11, Jan Beulich wrote: Hi Jan On 07.12.2020 12:35, Jan Beulich wrote: On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -4699,50 +4699,6 @@ int xenmem_add_to_physmap_one( return rc; } -int

Re: [PATCH V3 00/23] IOREQ feature (+ virtio-mmio) on Arm

On 07.12.20 15:03, Wei Chen wrote: Hi Oleksandr, Hi Wei I have tested v3. It works well with the latest virtio-backend service[1]. [1] https://github.com/xen-troops/virtio-disk/commits/ioreq_ml1 Tested-by: Wei Chen Thank you very much for the testing! -- Regards, Oleksandr

Re: [PATCH V3 11/23] xen/ioreq: Move x86's io_completion/io_req fields to struct vcpu

On 07.12.20 14:32, Jan Beulich wrote: Hi Jan, Paul. On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@ -142,8 +142,8 @@ void hvmemul_cancel(struct vcpu *v) { struct hvm_vcpu_io *vio = >arch.hvm.hvm_io; -

Re: [PATCH 2/2] xen: don't use page->lru for ZONE_DEVICE memory

On Mon, Dec 7, 2020 at 8:30 AM Juergen Gross wrote: > > Commit 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated > memory") introduced usage of ZONE_DEVICE memory for foreign memory > mappings. > > Unfortunately this collides with using page->lru for Xen backend > private page caches. > >

[xen-unstable-smoke test] 157262: tolerable all pass - PUSHED

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

Re: [PATCH V3 12/23] xen/ioreq: Remove "hvm" prefixes from involved function names

On 07.12.20 14:45, Jan Beulich wrote: Hi Jan On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: @@ -301,8 +301,8 @@ bool is_ioreq_server_page(struct domain *d, const struct page_info *page) return found; } -static void hvm_update_ioreq_evtchn(struct ioreq_server *s, -

Re: [PATCH V3 09/23] xen/dm: Make x86's DM feature common

On 07.12.20 14:08, Jan Beulich wrote: Hi Jan. On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: From: Julien Grall As a lot of x86 code can be re-used on Arm later on, this patch splits devicemodel support into common and arch specific parts. The common DM feature is supposed to be built

Re: [PATCH V3 08/23] xen/ioreq: Move x86's ioreq_server to struct domain

On 07.12.20 14:04, Jan Beulich wrote: Hi Jan On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko The IOREQ is a common feature now and this struct will be used on Arm as is. Move it to common struct domain. This also significantly reduces the layering violation in

Re: [PATCH V3 04/23] xen/ioreq: Make x86's IOREQ feature common

On 07.12.20 13:41, Jan Beulich wrote: Hi Jan On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: --- a/xen/include/asm-x86/hvm/ioreq.h +++ b/xen/include/asm-x86/hvm/ioreq.h @@ -19,8 +19,7 @@ #ifndef __ASM_X86_HVM_IOREQ_H__ #define __ASM_X86_HVM_IOREQ_H__ -#define HANDLE_BUFIOREQ(s) \ -

RE: [PATCH v5 18/23] libxlu: introduce xlu_pci_parse_spec_string()

> -Original Message- > From: Wei Liu > Sent: 04 December 2020 11:34 > To: Paul Durrant > Cc: xen-devel@lists.xenproject.org; Paul Durrant ; Ian > Jackson > ; Wei Liu ; Anthony PERARD > > Subject: Re: [PATCH v5 18/23] libxlu: introduce xlu_pci_parse_spec_string() > > On Thu, Dec 03,

[RFC PATCH] tools/python: Correct extension filenames for Python 3

Python distutils really looks like between 2 and 3, it took two steps forward and then two steps backward. First, it broke the linking step off of the compile step. Thus CC and LDSHARED were separated, thus CFLAGS and LDFLAGS were separated. A substantial step forwards. Yet then CFLAGS was

Re: [PATCH v2 8/8] xen/arm: Add support for SMMUv3 driver

Hello Julien, > On 7 Dec 2020, at 5:39 pm, Julien Grall wrote: > > > > On 07/12/2020 12:12, Rahul Singh wrote: +typedef paddr_t dma_addr_t; +typedef unsigned int gfp_t; + +#define platform_device device + +#define GFP_KERNEL 0 + +/* Alias to Xen device

[RFC PATCH] xen/arm: domain_build: Ignore empty memory bank

Previously Xen had stopped processing Device Trees if an empty (size == 0) memory bank was found. Commit 5a37207df52066efefe419c677b089a654d37afc changed this behavior to ignore such banks. Unfortunately this means these empty nodes are visible to code which accesses the device trees. Have

Re: [PATCH v2 8/8] xen/arm: Add support for SMMUv3 driver

On 07/12/2020 12:12, Rahul Singh wrote: +typedef paddr_t dma_addr_t; +typedef unsigned int gfp_t; + +#define platform_device device + +#define GFP_KERNEL 0 + +/* Alias to Xen device tree helpers */ +#define device_node dt_device_node +#define of_phandle_args dt_phandle_args +#define

Re: [PATCH v3 5/5] evtchn: don't call Xen consumer callback with per-channel lock held

On Mon, Dec 7, 2020 at 12:30 PM Julien Grall wrote: > > Hi Jan, > > On 07/12/2020 15:28, Jan Beulich wrote: > > On 04.12.2020 20:15, Tamas K Lengyel wrote: > >> On Fri, Dec 4, 2020 at 10:29 AM Julien Grall wrote: > >>> On 04/12/2020 15:21, Tamas K Lengyel wrote: > On Fri, Dec 4, 2020 at

Re: [PATCH v2 1/7] xen/arm: Add ID registers and complete cpufinfo

Hi Stefano, > On 4 Dec 2020, at 23:52, Stefano Stabellini wrote: > > There is a typo in the subject line I will fix that in the v3. > > > On Mon, 30 Nov 2020, Bertrand Marquis wrote: >> Add definition and entries in cpuinfo for ID registers introduced in >> newer Arm Architecture reference

Re: [PATCH v3 5/5] evtchn: don't call Xen consumer callback with per-channel lock held

Hi Jan, On 07/12/2020 15:28, Jan Beulich wrote: On 04.12.2020 20:15, Tamas K Lengyel wrote: On Fri, Dec 4, 2020 at 10:29 AM Julien Grall wrote: On 04/12/2020 15:21, Tamas K Lengyel wrote: On Fri, Dec 4, 2020 at 6:29 AM Julien Grall wrote: On 03/12/2020 10:09, Jan Beulich wrote: On

Re: [PATCH v2 3/7] xen/arm: create a cpuinfo structure for guest

Hi Stefano, > On 4 Dec 2020, at 23:57, Stefano Stabellini wrote: > > On Mon, 30 Nov 2020, Bertrand Marquis wrote: >> Create a cpuinfo structure for guest and mask into it the features that >> we do not support in Xen or that we do not want to publish to guests. >> >> Modify some values in the

Re: [PATCH v3 5/5] evtchn: don't call Xen consumer callback with per-channel lock held

On 07/12/2020 08:02, Jan Beulich wrote: On 04.12.2020 16:09, Julien Grall wrote: On 04/12/2020 12:01, Jan Beulich wrote: On 04.12.2020 12:51, Julien Grall wrote: On 04/12/2020 11:48, Jan Beulich wrote: On 04.12.2020 12:28, Julien Grall wrote: On 03/12/2020 10:09, Jan Beulich wrote: On

Re: [PATCH V3 01/23] x86/ioreq: Prepare IOREQ feature for making it common

Hi Jan @@ -1080,6 +1105,24 @@ int hvm_unmap_io_range_from_ioreq_server(struct domain *d, ioservid_t id, return rc; } +/* Called with ioreq_server lock held */ +int arch_ioreq_server_map_mem_type(struct domain *d, + struct hvm_ioreq_server *s,

[xen-unstable-smoke test] 157259: tolerable all pass - PUSHED

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

Re: [PATCH V3 01/23] x86/ioreq: Prepare IOREQ feature for making it common

On 07.12.2020 16:27, Oleksandr wrote: > On 07.12.20 13:13, Jan Beulich wrote: >> On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: >>> @@ -601,7 +610,7 @@ static int hvm_ioreq_server_map_pages(struct >>> hvm_ioreq_server *s) >>> return rc; >>> } >>> >>> -static void

RE: [PATCH v5 01/23] xl / libxl: s/pcidev/pci and remove DEFINE_DEVICE_TYPE_STRUCT_X

> -Original Message- > From: Paul Durrant > Sent: 07 December 2020 16:18 > To: p...@xen.org; 'Wei Liu' > Cc: xen-devel@lists.xenproject.org; Durrant, Paul ; > 'Oleksandr Andrushchenko' > ; 'Ian Jackson' ; > 'Anthony PERARD' > > Subject: RE: [EXTERNAL] [PATCH v5 01/23] xl / libxl:

RE: [PATCH v5 01/23] xl / libxl: s/pcidev/pci and remove DEFINE_DEVICE_TYPE_STRUCT_X

> -Original Message- [snip] > > > > > > > > This is going to break libxl callers because the name "pcidev" is > > > > visible from the public header. > > > > > > > > I agree this is confusing and inconsistent, but we didn't go extra > > > > length to maintain the inconsistency for no

[qemu-mainline test] 157253: regressions - FAIL

flight 157253 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/157253/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 152631

Re: [PATCH v1] docs: remove stale README.incompatibilities

On Wed, Sep 09, 2020 at 12:52:13PM +0200, Olaf Hering wrote: > It mentions just stale and obsolete distributions. > They are not suitable to build current Xen, since a couple of years. > > Signed-off-by: Olaf Hering Acked + applied. Wei.

Re: [PATCH 0/2] ns16550: #ifdef-ary

On Thu, Nov 19, 2020 at 09:54:58AM +0100, Jan Beulich wrote: > 1: "com=" command line options are x86-specific > 2: drop stray "#ifdef CONFIG_HAS_PCI" > Acked-by: Wei Liu

Re: [PATCH v1 3/4] Makefile: add build-tools-oxenstored

On Tue, Nov 17, 2020 at 06:24:11PM +, Edwin Török wrote: > As a convenience so that oxenstored patches can be compile-tested > using upstream's build-system before submitting upstream. > > Signed-off-by: Edwin Török Acked-by: Wei Liu Seeing that there is still pending comments from Andrew

Re: [PATCH v3] docs: fix documentation about default scheduler

On Tue, Nov 17, 2020 at 10:32:58AM +0100, Roger Pau Monne wrote: > Fix the command line document to account for the default scheduler in > Kconfig being credit2 now, and the fact that it's selectable at build > time and thus different builds could end up with different default > schedulers. > >

Re: [PATCH V3 03/23] x86/ioreq: Provide out-of-line wrapper for the handle_mmio()

On 07.12.20 13:27, Jan Beulich wrote: Hi Jan On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: --- a/xen/arch/x86/hvm/ioreq.c +++ b/xen/arch/x86/hvm/ioreq.c @@ -36,6 +36,11 @@ #include #include +bool ioreq_complete_mmio(void) +{ +return handle_mmio(); +} As indicated before I

Re: [PATCH V3 02/23] x86/ioreq: Add IOREQ_STATUS_* #define-s and update code for moving

On 07.12.20 13:19, Jan Beulich wrote: Hi Jan On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: --- a/xen/include/asm-x86/hvm/ioreq.h +++ b/xen/include/asm-x86/hvm/ioreq.h @@ -74,6 +74,10 @@ unsigned int hvm_broadcast_ioreq(ioreq_t *p, bool buffered); void hvm_ioreq_init(struct domain

Re: [PATCH v2 0/2] automation: arm64 dom0less smoke test

On Mon, Nov 16, 2020 at 08:21:18PM -0800, Stefano Stabellini wrote: > Hi all, > > This short series introduces a very simple Xen Dom0less smoke test based > on qemu-system-aarch64 to be run as part of the gitlab CI-loop. It > currently passes on staging. > > Cheers, > > Stefano > > > Changes

Re: Ping: [PATCH] libxenstat: avoid build race

On Mon, Dec 07, 2020 at 04:25:41PM +0100, Jan Beulich wrote: > On 18.11.2020 15:27, Bertrand Marquis wrote: > >> On 17 Nov 2020, at 09:42, Jan Beulich wrote: > >> > >> Olaf reported observing > >> > >> xenstat_qmp.c:26:10: fatal error: _paths.h: No such file or directory > >>

Re: [PATCH v8 03/15] x86/mm: rewrite virt_to_xen_l*e

On Mon, 2020-07-27 at 15:21 +0100, Hongyan Xia wrote: > From: Wei Liu > > Rewrite those functions to use the new APIs. Modify its callers to > unmap > the pointer returned. Since alloc_xen_pagetable_new() is almost never > useful unless accompanied by page clearing and a mapping, introduce a >

Re: [PATCH v3 5/5] evtchn: don't call Xen consumer callback with per-channel lock held

On 04.12.2020 20:15, Tamas K Lengyel wrote: > On Fri, Dec 4, 2020 at 10:29 AM Julien Grall wrote: >> On 04/12/2020 15:21, Tamas K Lengyel wrote: >>> On Fri, Dec 4, 2020 at 6:29 AM Julien Grall wrote: On 03/12/2020 10:09, Jan Beulich wrote: > On 02.12.2020 22:10, Julien Grall wrote:

Re: [PATCH V3 01/23] x86/ioreq: Prepare IOREQ feature for making it common

On 07.12.20 13:13, Jan Beulich wrote: Hi Jan On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: --- a/xen/arch/x86/hvm/ioreq.c +++ b/xen/arch/x86/hvm/ioreq.c @@ -17,15 +17,15 @@ */ #include +#include +#include #include +#include #include -#include +#include #include

Ping: [PATCH] libxenstat: avoid build race

On 18.11.2020 15:27, Bertrand Marquis wrote: >> On 17 Nov 2020, at 09:42, Jan Beulich wrote: >> >> Olaf reported observing >> >> xenstat_qmp.c:26:10: fatal error: _paths.h: No such file or directory >> .../tools/libs/stat/../../../tools/Rules.mk:153: xenstat_qmp.opic] Error 1 >> >> Obviously

Re: [PATCH v2 04/17] xen/cpupool: switch cpupool id to unsigned

On 04.12.2020 16:52, Dario Faggioli wrote: > On Tue, 2020-12-01 at 09:21 +0100, Juergen Gross wrote: >> The cpupool id is an unsigned value in the public interface header, >> so >> there is no reason why it is a signed value in struct cpupool. >> >> Switch it to unsigned int. >> > I think we can

Re: [PATCH v2 04/17] xen/cpupool: switch cpupool id to unsigned

On 07.12.2020 15:48, Jürgen Groß wrote: > On 07.12.20 10:59, Jan Beulich wrote: >> On 01.12.2020 10:01, Jürgen Groß wrote: >>> On 01.12.20 09:55, Jan Beulich wrote: On 01.12.2020 09:21, Juergen Gross wrote: > --- a/xen/common/sched/private.h > +++ b/xen/common/sched/private.h > @@

Re: [PATCH v2 04/17] xen/cpupool: switch cpupool id to unsigned

On 07.12.20 10:59, Jan Beulich wrote: On 01.12.2020 10:01, Jürgen Groß wrote: On 01.12.20 09:55, Jan Beulich wrote: On 01.12.2020 09:21, Juergen Gross wrote: --- a/xen/common/sched/private.h +++ b/xen/common/sched/private.h @@ -505,8 +505,8 @@ static inline void sched_unit_unpause(const

Re: [PATCH v3 5/5] gitlab-ci: Add Xen cross-build jobs

On 07/12/2020 14.15, Philippe Mathieu-Daudé wrote: > Cross-build ARM and X86 targets with only Xen accelerator enabled. > > Signed-off-by: Philippe Mathieu-Daudé > --- > .gitlab-ci.d/crossbuilds.yml | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git

Re: [Help Wanted] New toolstack Rust PoC

Same mail as plain text, sorry for the incovenience and the none readability of my previous one. Hi all, As you may know: we are working on a rust PoC (https://github.com/xcp-ng/xenopsd-ng/rust/ ) for the new Xen Toolstack. We have partial

[Help Wanted] New toolstack Rust PoC

Hi all, As you may know: we are working on a rust PoC (https://github.com/xcp-ng/xenopsd-ng/rust/ ) for the new Xen Toolstack. We have partial bindings for Xenctrl and Xenstore and with that we're able to pause/unpause/shutdown a guest and we're

[PATCH 1/2] xen: add helpers for caching grant mapping pages

Instead of having similar helpers in multiple backend drivers use common helpers for caching pages allocated via gnttab_alloc_pages(). Make use of those helpers in blkback and scsiback. Signed-off-by: Juergen Gross --- drivers/block/xen-blkback/blkback.c | 89 ++---

[PATCH 0/2] xen: fix using ZONE_DEVICE memory for foreign mappings

Fix an issue found in dom0 when running on a host with NVMe. Juergen Gross (2): xen: add helpers for caching grant mapping pages xen: don't use page->lru for ZONE_DEVICE memory drivers/block/xen-blkback/blkback.c | 89 drivers/block/xen-blkback/common.h | 4 +-

[PATCH 2/2] xen: don't use page->lru for ZONE_DEVICE memory

Commit 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated memory") introduced usage of ZONE_DEVICE memory for foreign memory mappings. Unfortunately this collides with using page->lru for Xen backend private page caches. Fix that by using page->zone_device_data instead. Fixes:

[PATCH v3 5/5] gitlab-ci: Add Xen cross-build jobs

Cross-build ARM and X86 targets with only Xen accelerator enabled. Signed-off-by: Philippe Mathieu-Daudé --- .gitlab-ci.d/crossbuilds.yml | 14 ++ 1 file changed, 14 insertions(+) diff --git a/.gitlab-ci.d/crossbuilds.yml b/.gitlab-ci.d/crossbuilds.yml index

[PATCH v3 4/5] gitlab-ci: Add KVM s390x cross-build jobs

Cross-build s390x target with only KVM accelerator enabled. Reviewed-by: Thomas Huth Signed-off-by: Philippe Mathieu-Daudé --- .gitlab-ci.d/crossbuilds.yml | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/.gitlab-ci.d/crossbuilds.yml b/.gitlab-ci.d/crossbuilds.yml

[PATCH v3 3/5] gitlab-ci: Introduce 'cross_accel_build_job' template

Introduce a job template to cross-build accelerator specific jobs (enable a specific accelerator, disabling the others). The specific accelerator is selected by the $ACCEL environment variable (default to KVM). Extra options such disabling other accelerators are passed via the

[PATCH v3 2/5] gitlab-ci: Replace YAML anchors by extends (cross_system_build_job)

'extends' is an alternative to using YAML anchors and is a little more flexible and readable. See: https://docs.gitlab.com/ee/ci/yaml/#extends More importantly it allows exploding YAML jobs. Reviewed-by: Wainer dos Santos Moschetta Reviewed-by: Thomas Huth Signed-off-by: Philippe Mathieu-Daudé

[PATCH v3 1/5] gitlab-ci: Document 'build-tcg-disabled' is a KVM X86 job

Document what this job cover (build X86 targets with KVM being the single accelerator available). Reviewed-by: Thomas Huth Signed-off-by: Philippe Mathieu-Daudé --- .gitlab-ci.yml | 5 + 1 file changed, 5 insertions(+) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index

[PATCH v3 0/5] gitlab-ci: Add accelerator-specific Linux jobs

Since v2: - Fixed ARM Xen job - Renamed jobs with -$accel trailer (Thomas) Since v1: - Documented cross_accel_build_job template (Claudio) - Only add new job for s390x (Thomas) - Do not add entry to MAINTAINERS (Daniel) - Document 'build-tcg-disabled' job is X86 + KVM - Drop the patches with

Re: [PATCH v3] x86/vmap: handle superpages in vmap_to_mfn()

On 07.12.2020 13:49, Hongyan Xia wrote: > --- a/xen/include/xen/mm.h > +++ b/xen/include/xen/mm.h > @@ -175,6 +175,7 @@ bool scrub_free_pages(void); > } while ( false ) > #define FREE_XENHEAP_PAGE(p) FREE_XENHEAP_PAGES(p, 0) > > +mfn_t xen_map_to_mfn(unsigned long va); > /* Map machine page

[xen-unstable test] 157249: tolerable FAIL

flight 157249 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/157249/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 157233 Tests which did not

RE: [PATCH V3 00/23] IOREQ feature (+ virtio-mmio) on Arm

Hi Oleksandr, I have tested v3. It works well with the latest virtio-backend service[1]. [1] https://github.com/xen-troops/virtio-disk/commits/ioreq_ml1 Tested-by: Wei Chen Regards, Wei Chen > -Original Message- > From: Oleksandr > Sent: 2020年11月30日 19:23 > To:

Re: GPF on 0xdead000000000100 in nvme_map_data - Linux 5.9.9

On Mon, Dec 07, 2020 at 01:00:14PM +0100, Jürgen Groß wrote: > On 07.12.20 12:48, Marek Marczykowski-Górecki wrote: > > On Mon, Dec 07, 2020 at 11:55:01AM +0100, Jürgen Groß wrote: > > > Marek, > > > > > > On 06.12.20 17:47, Jason Andryuk wrote: > > > > On Sat, Dec 5, 2020 at 3:29 AM Roger Pau

Re: [PATCH v2 3/5] gitlab-ci: Introduce 'cross_accel_build_job' template

On 12/7/20 12:37 PM, Thomas Huth wrote: > On 07/12/2020 12.23, Philippe Mathieu-Daudé wrote: >> Introduce a job template to cross-build accelerator specific >> jobs (enable a specific accelerator, disabling the others). >> >> The specific accelerator is selected by the $ACCEL environment >>

[PATCH v3] x86/vmap: handle superpages in vmap_to_mfn()

From: Hongyan Xia There is simply no guarantee that vmap won't return superpages to the caller. It can happen if the list of MFNs are contiguous, or we simply have a large granularity. Although rare, if such things do happen, we will simply hit BUG_ON() and crash. Introduce xen_map_to_mfn() to

[ovmf test] 157255: all pass - PUSHED

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

Re: [PATCH v2 5/5] gitlab-ci: Add Xen cross-build jobs

On 12/7/20 12:51 PM, Thomas Huth wrote: > On 07/12/2020 12.23, Philippe Mathieu-Daudé wrote: >> Cross-build ARM and X86 targets with only Xen accelerator enabled. >> >> Signed-off-by: Philippe Mathieu-Daudé >> --- >> .gitlab-ci.d/crossbuilds.yml | 15 +++ >> 1 file changed, 15

Re: [PATCH V3 12/23] xen/ioreq: Remove "hvm" prefixes from involved function names

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: > @@ -301,8 +301,8 @@ bool is_ioreq_server_page(struct domain *d, const struct > page_info *page) > return found; > } > > -static void hvm_update_ioreq_evtchn(struct ioreq_server *s, > -struct ioreq_vcpu

Re: [PATCH V3 11/23] xen/ioreq: Move x86's io_completion/io_req fields to struct vcpu

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: > --- a/xen/arch/x86/hvm/emulate.c > +++ b/xen/arch/x86/hvm/emulate.c > @@ -142,8 +142,8 @@ void hvmemul_cancel(struct vcpu *v) > { > struct hvm_vcpu_io *vio = >arch.hvm.hvm_io; > > -vio->io_req.state = STATE_IOREQ_NONE; > -

Re: [PATCH v2 8/8] xen/arm: Add support for SMMUv3 driver

Hello Julien, > On 2 Dec 2020, at 4:22 pm, Julien Grall wrote: > > Hi Rahul, > > On 26/11/2020 17:02, Rahul Singh wrote: >> Add support for ARM architected SMMUv3 implementation. It is based on >> the Linux SMMUv3 driver. >> Major differences with regard to Linux driver are as follows: >> 1.

RE: [PATCH V3 08/23] xen/ioreq: Move x86's ioreq_server to struct domain

> -Original Message- > From: Jan Beulich > Sent: 07 December 2020 12:05 > To: Oleksandr Tyshchenko ; Paul Durrant > Cc: Oleksandr Tyshchenko ; Andrew Cooper > ; > George Dunlap ; Ian Jackson ; > Julien Grall > ; Stefano Stabellini ; Wei Liu > ; Roger Pau Monné > ; Julien Grall ; >

Re: [PATCH V3 10/23] xen/mm: Make x86's XENMEM_resource_ioreq_server handling common

On 07.12.2020 12:35, Jan Beulich wrote: > On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: >> --- a/xen/arch/x86/mm.c >> +++ b/xen/arch/x86/mm.c >> @@ -4699,50 +4699,6 @@ int xenmem_add_to_physmap_one( >> return rc; >> } >> >> -int arch_acquire_resource(struct domain *d, unsigned int type,

Re: [PATCH V3 09/23] xen/dm: Make x86's DM feature common

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: > From: Julien Grall > > As a lot of x86 code can be re-used on Arm later on, this patch > splits devicemodel support into common and arch specific parts. > > The common DM feature is supposed to be built with IOREQ_SERVER > option enabled (as

Re: [PATCH V3 08/23] xen/ioreq: Move x86's ioreq_server to struct domain

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: > From: Oleksandr Tyshchenko > > The IOREQ is a common feature now and this struct will be used > on Arm as is. Move it to common struct domain. This also > significantly reduces the layering violation in the common code > (*arch.hvm* usage). > >

Re: GPF on 0xdead000000000100 in nvme_map_data - Linux 5.9.9

On 07.12.20 12:48, Marek Marczykowski-Górecki wrote: On Mon, Dec 07, 2020 at 11:55:01AM +0100, Jürgen Groß wrote: Marek, On 06.12.20 17:47, Jason Andryuk wrote: On Sat, Dec 5, 2020 at 3:29 AM Roger Pau Monné wrote: On Fri, Dec 04, 2020 at 01:20:54PM +0100, Marek Marczykowski-Górecki wrote:

Re: [PATCH v2] x86/vmap: handle superpages in vmap_to_mfn()

On 07.12.2020 12:54, Hongyan Xia wrote: > On Mon, 2020-12-07 at 11:11 +0100, Jan Beulich wrote: >> On 03.12.2020 12:21, Hongyan Xia wrote: >>> --- a/xen/arch/x86/mm.c >>> +++ b/xen/arch/x86/mm.c >>> @@ -5194,6 +5194,60 @@ l1_pgentry_t *virt_to_xen_l1e(unsigned long >>> v) >>> }

Re: [PATCH V3 07/23] xen/ioreq: Make x86's hvm_ioreq_(page/vcpu/server) structs common

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: > From: Oleksandr Tyshchenko > > The IOREQ is a common feature now and these structs will be used > on Arm as is. Move them to xen/ioreq.h and remove "hvm" prefixes. > > Signed-off-by: Oleksandr Tyshchenko Applicable parts Acked-by: Jan Beulich

Re: [PATCH v2] x86/vmap: handle superpages in vmap_to_mfn()

On Mon, 2020-12-07 at 11:11 +0100, Jan Beulich wrote: > On 03.12.2020 12:21, Hongyan Xia wrote: > > --- a/xen/arch/x86/mm.c > > +++ b/xen/arch/x86/mm.c > > @@ -5194,6 +5194,60 @@ l1_pgentry_t *virt_to_xen_l1e(unsigned long > > v) > > } \ > > }

Re: [PATCH v2 5/5] gitlab-ci: Add Xen cross-build jobs

On 07/12/2020 12.23, Philippe Mathieu-Daudé wrote: > Cross-build ARM and X86 targets with only Xen accelerator enabled. > > Signed-off-by: Philippe Mathieu-Daudé > --- > .gitlab-ci.d/crossbuilds.yml | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git

Re: GPF on 0xdead000000000100 in nvme_map_data - Linux 5.9.9

On Mon, Dec 07, 2020 at 11:55:01AM +0100, Jürgen Groß wrote: > Marek, > > On 06.12.20 17:47, Jason Andryuk wrote: > > On Sat, Dec 5, 2020 at 3:29 AM Roger Pau Monné wrote: > > > > > > On Fri, Dec 04, 2020 at 01:20:54PM +0100, Marek Marczykowski-Górecki > > > wrote: > > > > On Fri, Dec 04, 2020

Re: [PATCH V3 06/23] xen/ioreq: Make x86's hvm_mmio_first(last)_byte() common

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: > From: Oleksandr Tyshchenko > > The IOREQ is a common feature now and these helpers will be used > on Arm as is. Move them to xen/ioreq.h and replace "hvm" prefixes > with "ioreq". > > Signed-off-by: Oleksandr Tyshchenko > Reviewed-by: Paul

Re: [PATCH V3 05/23] xen/ioreq: Make x86's hvm_ioreq_needs_completion() common

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: > --- a/xen/include/xen/ioreq.h > +++ b/xen/include/xen/ioreq.h > @@ -21,6 +21,13 @@ > > #include > > +static inline bool ioreq_needs_completion(const ioreq_t *ioreq) > +{ > +return ioreq->state == STATE_IOREQ_READY && > +

Re: [PATCH v3 1/2] x86/IRQ: make max number of guests for a shared IRQ configurable

On 07.12.2020 12:28, Igor Druzhinin wrote: > On 07/12/2020 09:43, Jan Beulich wrote: >> On 06.12.2020 18:43, Igor Druzhinin wrote: >>> @@ -1633,11 +1640,12 @@ int pirq_guest_bind(struct vcpu *v, struct pirq >>> *pirq, int will_share) >>> goto retry; >>> } >>> >>> -if (

Re: [PATCH v2 4/5] gitlab-ci: Add KVM s390x cross-build jobs

On 07/12/2020 12.23, Philippe Mathieu-Daudé wrote: > Cross-build s390x target with only KVM accelerator enabled. > > Signed-off-by: Philippe Mathieu-Daudé > --- > .gitlab-ci.d/crossbuilds.yml | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git

Re: [PATCH V3 04/23] xen/ioreq: Make x86's IOREQ feature common

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: > --- a/xen/include/asm-x86/hvm/ioreq.h > +++ b/xen/include/asm-x86/hvm/ioreq.h > @@ -19,8 +19,7 @@ > #ifndef __ASM_X86_HVM_IOREQ_H__ > #define __ASM_X86_HVM_IOREQ_H__ > > -#define HANDLE_BUFIOREQ(s) \ > -((s)->bufioreq_handling !=

Re: [PATCH v2 3/5] gitlab-ci: Introduce 'cross_accel_build_job' template

On 07/12/2020 12.23, Philippe Mathieu-Daudé wrote: > Introduce a job template to cross-build accelerator specific > jobs (enable a specific accelerator, disabling the others). > > The specific accelerator is selected by the $ACCEL environment > variable (default to KVM). > > Extra options such

Re: [PATCH V3 10/23] xen/mm: Make x86's XENMEM_resource_ioreq_server handling common

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -4699,50 +4699,6 @@ int xenmem_add_to_physmap_one( > return rc; > } > > -int arch_acquire_resource(struct domain *d, unsigned int type, > - unsigned int id,

Re: [PATCH v2 1/5] gitlab-ci: Document 'build-tcg-disabled' is a KVM X86 job

On 07/12/2020 12.23, Philippe Mathieu-Daudé wrote: > Document what this job cover (build X86 targets with > KVM being the single accelerator available). > > Signed-off-by: Philippe Mathieu-Daudé > --- > .gitlab-ci.yml | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/.gitlab-ci.yml

Re: [PATCH v3 1/2] x86/IRQ: make max number of guests for a shared IRQ configurable

On 07/12/2020 09:43, Jan Beulich wrote: > On 06.12.2020 18:43, Igor Druzhinin wrote: >> @@ -1633,11 +1640,12 @@ int pirq_guest_bind(struct vcpu *v, struct pirq >> *pirq, int will_share) >> goto retry; >> } >> >> -if ( action->nr_guests == IRQ_MAX_GUESTS ) >> +if (

Re: [PATCH V3 03/23] x86/ioreq: Provide out-of-line wrapper for the handle_mmio()

On 30.11.2020 11:31, Oleksandr Tyshchenko wrote: > --- a/xen/arch/x86/hvm/ioreq.c > +++ b/xen/arch/x86/hvm/ioreq.c > @@ -36,6 +36,11 @@ > #include > #include > > +bool ioreq_complete_mmio(void) > +{ > +return handle_mmio(); > +} As indicated before I don't like out-of-line functions

Re: [PATCH 5/8] gitlab-ci: Add KVM s390x cross-build jobs

On 12/7/20 12:14 PM, Philippe Mathieu-Daudé wrote: > On 12/7/20 11:34 AM, Daniel P. Berrangé wrote: >> On Mon, Dec 07, 2020 at 11:26:58AM +0100, Philippe Mathieu-Daudé wrote: >>> On 12/7/20 11:25 AM, Daniel P. Berrangé wrote: On Mon, Dec 07, 2020 at 06:46:01AM +0100, Thomas Huth wrote: >

[PATCH v2 5/5] gitlab-ci: Add Xen cross-build jobs

Cross-build ARM and X86 targets with only Xen accelerator enabled. Signed-off-by: Philippe Mathieu-Daudé --- .gitlab-ci.d/crossbuilds.yml | 15 +++ 1 file changed, 15 insertions(+) diff --git a/.gitlab-ci.d/crossbuilds.yml b/.gitlab-ci.d/crossbuilds.yml index

[PATCH v2 4/5] gitlab-ci: Add KVM s390x cross-build jobs

Cross-build s390x target with only KVM accelerator enabled. Signed-off-by: Philippe Mathieu-Daudé --- .gitlab-ci.d/crossbuilds.yml | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/.gitlab-ci.d/crossbuilds.yml b/.gitlab-ci.d/crossbuilds.yml index

[PATCH v2 3/5] gitlab-ci: Introduce 'cross_accel_build_job' template

Introduce a job template to cross-build accelerator specific jobs (enable a specific accelerator, disabling the others). The specific accelerator is selected by the $ACCEL environment variable (default to KVM). Extra options such disabling other accelerators are passed via the

  1   2   >