[linux-linus test] 167380: tolerable FAIL - PUSHED

flight 167380 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/167380/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 18 guest-localmigrate fail REGR. vs. 167378 Tests which did not succeed,

[PATCH] xen/pciback: fix typo in a comment

The double `the' in the comment in line 163 is repeated. Remove it from the comment. Signed-off-by: Jason Wang --- drivers/xen/xen-pciback/pciback_ops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/xen/xen-pciback/pciback_ops.c b/drivers/xen/xen-pciback/pciback_op

Re: [PATCH 10/10] mini-os: modify grant mappings to work in PVH mode

Juergen Gross, le lun. 06 déc. 2021 08:23:37 +0100, a ecrit: > For being able to use the grant mapping interface in PVH mode some > changes are required, as the guest needs to specify a physical address > in the hypercall interface. > > Signed-off-by: Juergen Gross Reviewed-by: Samuel Thibault

Re: [PATCH 09/10] mini-os: prepare grantmap entry interface for use by PVH mode

Juergen Gross, le lun. 06 déc. 2021 08:23:36 +0100, a ecrit: > Instead of passing the pointer of a grantmap entry to the > _gntmap_[un]map_grant_ref() sub-functions use the map pointer and the > entry index instead. This will be needed for PVH mode usage. > > Signed-off-by: Juergen Gross Reviewe

Re: [PATCH 08/10] mini-os: add proper pvh grant table handling

Juergen Gross, le lun. 06 déc. 2021 08:23:35 +0100, a ecrit: > Grant table initialization for PVH requires some additional actions > compared to PV mode. Add those. > > Signed-off-by: Juergen Gross Reviewed-by: Samuel Thibault > --- > arch/x86/gnttab.c | 31 +++ >

Re: [PATCH 07/10] mini-os: move x86 specific gnttab coding into arch/x86/gnttab.c

Juergen Gross, le lun. 06 déc. 2021 08:23:34 +0100, a ecrit: > Having grant table code in arch/x86/mm.c seems wrong. Move it to the > new file arch/x86/gnttab.c, especially as the amount of code is > expected to grow further. > > No functional change. There is the __pte fix that you'd probably wa

Re: [PATCH 06/10] mini-os: add memory map service functions

Juergen Gross, le lun. 06 déc. 2021 08:23:33 +0100, a ecrit: > +void e820_put_reserved_pfns(unsigned long start_pfn, int pages) > +{ > +int i; > +unsigned long addr = start_pfn << PAGE_SHIFT; > +unsigned long size = (long)pages << PAGE_SHIFT; > + > +for ( i = 0; i < e820_entries &&

Re: [PATCH 05/10] mini-os: don't repeat definition available via header file

Juergen Gross, le lun. 06 déc. 2021 08:23:32 +0100, a ecrit: > arch/x86/setup.c is repeating the definition of __pte() instead using > the appropriate header. Fix that. > > Signed-off-by: Juergen Gross Reviewed-by: Samuel Thibault > --- > arch/x86/setup.c | 8 +--- > 1 file changed, 1 ins

Re: [PATCH 04/10] mini-os: respect memory map when ballooning up

Juergen Gross, le lun. 06 déc. 2021 08:23:31 +0100, a ecrit: > @@ -81,8 +93,11 @@ int balloon_up(unsigned long n_pages) > if ( n_pages > N_BALLOON_FRAMES ) > n_pages = N_BALLOON_FRAMES; > > +start_pfn = e820_get_maxpfn(nr_mem_pages + 1) - 1; > +n_pages = e820_get_max_pages(s

Re: [PATCH 03/10] mini-os: don't assume contiguous RAM when initializing in PVH mode

Juergen Gross, le lun. 06 déc. 2021 08:23:30 +0100, a ecrit: > -unsigned long pfn, max = 0; > +unsigned long pfns, max = 0; I'd say rather rename max to start. > e820_get_memmap(); > > @@ -166,9 +166,12 @@ unsigned long e820_get_maxpfn(void) > { > if ( e820_map[i].typ

Re: [PATCH 02/10] mini-os: sort and sanitize e820 memory map

Hello, Juergen Gross, le lun. 06 déc. 2021 08:23:29 +0100, a ecrit: > - align the entries to page boundaries > +/* Adjust map entries to page boundaries. */ > +for ( i = 0; i < e820_entries; i++ ) > +{ > +end = (e820_map[i].addr + e820_map[i].size + PAGE_SIZE - 1) & > PAGE_MA

Re: [PATCH 01/10] mini-os: split e820 map handling into new source file

Juergen Gross, le lun. 06 déc. 2021 08:23:28 +0100, a ecrit: > Introduce e820.c containing all the E820 memory map handling. > > No functional change. > > Signed-off-by: Juergen Gross Reviewed-by: Samuel Thibault > --- > Makefile | 1 + > arch/arm/mm.c | 8 > arch/x86/mm.c |

Re: [XEN PATCH 57/57] stubdom: xenlibs linkfarm, ignore non-regular files

Anthony PERARD, le lun. 06 déc. 2021 17:02:40 +, a ecrit: > When we will convert tools/ build system, their will be a need to > replace some use of "vpath". This will done making symbolic links. > Those symlinks are not wanted by stubdom build system when making a > linkfarm for the Xen librari

Re: [XEN PATCH 56/57] stubdom: build xenstore*-stubdom using new Makefile.common

Anthony PERARD, le lun. 06 déc. 2021 17:02:39 +, a ecrit: > Makefile.common have everything needed by stubdom, when used with > xenlibs.mk, so we don't need "Makefile" anymore. > > Also, remove DESTDIR for "xenstore" related targets, "xenlibs.mk" > doesn't use DESTDIR so its value doesn't matt

Re: [XEN PATCH 53/57] stubdom: introduce xenlibs.mk

Anthony PERARD, le lun. 06 déc. 2021 17:02:36 +, a ecrit: > This new makefile will be used to build libraries that provides > "Makefile.common". > > At some point, we will be converting Makefile in tools/ to "subdirmk" > and stubdom build will not be able to use those new makefiles, so we > wi

Re: [XEN PATCH 52/57] stubdom: only build libxen*.a from tools/libs/

Anthony PERARD, le lun. 06 déc. 2021 17:02:35 +, a ecrit: > Avoid generating *.map files or running headers.chk when all we need > is the libxen*.a. > > Also, allow force make to check again if libxen*.a needs rebuilt by > adding a '.PHONY' prerequisite. > > Also, remove DESTDIR= as we don't

[linux-linus test] 167378: tolerable FAIL - PUSHED

flight 167378 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/167378/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 167362 Tests which did not succeed,

[ovmf test] 167379: all pass - PUSHED

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

Re: [patch V3 12/35] soc: ti: ti_sci_inta_msi: Allocate MSI device data on first use

On Fri, Dec 10, 2021 at 11:19 PM Thomas Gleixner wrote: > > From: Thomas Gleixner > > Allocate the MSI device data on first invocation of the allocation function. > > Signed-off-by: Thomas Gleixner > Reviewed-by: Greg Kroah-Hartman > Reviewed-by: Jason Gunthorpe > Cc: Nishanth Menon > Cc: Ter

[ovmf test] 167377: all pass - PUSHED

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

Re: [patch V3 34/35] soc: ti: ti_sci_inta_msi: Get rid of ti_sci_inta_msi_get_virq()

On Fri, Dec 10, 2021 at 11:19 PM Thomas Gleixner wrote: > > From: Thomas Gleixner > > Just use the core function msi_get_virq(). > > Signed-off-by: Thomas Gleixner > Reviewed-by: Greg Kroah-Hartman > Reviewed-by: Jason Gunthorpe > Cc: Peter Ujfalusi > Cc: Vinod Koul > Cc: dmaeng...@vger.kern

[ovmf test] 167376: regressions - FAIL

flight 167376 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/167376/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 167239 build-i386-xsm

[ovmf test] 167375: regressions - FAIL

flight 167375 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/167375/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 167239 build-i386-xsm

Re: [patch V3 07/35] device: Move MSI related data into a struct

On Fri, Dec 10, 2021 at 11:18 PM Thomas Gleixner wrote: > > From: Thomas Gleixner > > The only unconditional part of MSI data in struct device is the irqdomain > pointer. Everything else can be allocated on demand. Create a data > structure and move the irqdomain pointer into it. The other MSI sp

Re: [patch V3 05/35] powerpc/cell/axon_msi: Use PCI device property

On Fri, Dec 10, 2021 at 11:18 PM Thomas Gleixner wrote: > > From: Thomas Gleixner > > instead of fiddling with MSI descriptors. > > Signed-off-by: Thomas Gleixner > Cc: Arnd Bergmann > Cc: Michael Ellerman > Cc: Benjamin Herrenschmidt > Cc: linuxppc-...@lists.ozlabs.org > --- Acked-by: Arnd

[ovmf test] 167374: regressions - FAIL

flight 167374 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/167374/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 167239 build-i386-xsm

[linux-linus test] 167362: tolerable FAIL - PUSHED

flight 167362 linux-linus real [real] flight 167372 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/167362/ http://logs.test-lab.xenproject.org/osstest/logs/167372/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-

[ovmf test] 167373: regressions - FAIL

flight 167373 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/167373/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 167239 build-i386-xsm

[ovmf test] 167371: regressions - FAIL

flight 167371 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/167371/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 167239 build-i386-xsm

[ovmf test] 167370: regressions - FAIL

flight 167370 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/167370/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 167239 build-i386-xsm

[ovmf test] 167369: regressions - FAIL

flight 167369 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/167369/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 167239 build-i386-xsm

[ovmf test] 167368: regressions - FAIL

flight 167368 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/167368/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 167239 build-i386-xsm

Re: [patch V3 03/35] x86/apic/msi: Use PCI device MSI property

On Fri, Dec 10, 2021 at 11:18:47PM +0100, Thomas Gleixner wrote: > From: Thomas Gleixner > > instead of fiddling with MSI descriptors. > > Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman

[ovmf test] 167367: regressions - FAIL

flight 167367 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/167367/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 167239 build-i386-xsm

[xen-unstable test] 167357: tolerable FAIL - PUSHED

flight 167357 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/167357/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail like 167348 test-amd64-amd64-xl-qemut-win7-amd64

[ovmf test] 167366: regressions - FAIL

flight 167366 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/167366/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 167239 build-i386-xsm

[ovmf test] 167365: regressions - FAIL

flight 167365 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/167365/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 167239 build-i386-xsm

Re: [PATCH v5 02/14] vpci: fix function attributes for vpci_process_pending

Hi, Roger! On 11.12.21 10:20, Roger Pau Monné wrote: > On Fri, Dec 10, 2021 at 05:55:03PM +, Julien Grall wrote: >> Hi Oleksandr, >> >> On 25/11/2021 11:02, Oleksandr Andrushchenko wrote: >>> From: Oleksandr Andrushchenko >>> >>> vpci_process_pending is defined with different attributes, e.g.

Re: [PATCH v5 02/14] vpci: fix function attributes for vpci_process_pending

On Fri, Dec 10, 2021 at 05:55:03PM +, Julien Grall wrote: > Hi Oleksandr, > > On 25/11/2021 11:02, Oleksandr Andrushchenko wrote: > > From: Oleksandr Andrushchenko > > > > vpci_process_pending is defined with different attributes, e.g. > > with __must_check if CONFIG_HAS_VPCI enabled and not

[libvirt test] 167361: regressions - FAIL

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

[ovmf test] 167364: regressions - FAIL

flight 167364 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/167364/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 167239 build-i386-xsm