[libvirt test] 169386: regressions - FAIL

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

[ovmf test] 169385: regressions - FAIL

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

[ovmf test] 169384: regressions - FAIL

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

[ovmf test] 169382: regressions - FAIL

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

[ovmf test] 169381: regressions - FAIL

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

Re: [PATCH] xen/evtchn: Add design for static event channel signaling for domUs..

On Mon, 11 Apr 2022, Bertrand Marquis wrote: > What you mention here is actually combining 2 different solutions inside > Xen to build a custom communication solution. > My assumption here is that the user will actually create the device tree > nodes he wants to do that and we should not create gue

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

flight 169373 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/169373/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169348 test-armhf-armhf-libvirt 16 save

[ovmf test] 169380: regressions - FAIL

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

[ovmf test] 169379: regressions - FAIL

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

[ovmf test] 169378: regressions - FAIL

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

[ovmf test] 169377: regressions - FAIL

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

Re: [PATCH v7 03/20] reboot: Print error message if restart handler has duplicated priority

On 4/13/22 21:48, Rafael J. Wysocki wrote: > On Tue, Apr 12, 2022 at 1:39 AM Dmitry Osipenko > wrote: >> >> Add sanity check which ensures that there are no two restart handlers >> registered using the same priority. This requirement will become mandatory >> once all drivers will be converted to t

[ovmf test] 169376: regressions - FAIL

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

Re: xen-swiotlb issue when NVMe driver is enabled in Dom0 on ARM

On Wed, 13 Apr 2022, Rahul Singh wrote: > Hello All, > > We are trying to boot the Xen 4.15.1 and dom0 Linux Kernel > (5.10.27-ampere-lts-standard from [1] ) on Ampere Altra / AVA Developer > Platform > [2] with ACPI. > > NVMe storage is connected to PCIe. Native Linux kernel boot fine and also

[ovmf test] 169375: regressions - FAIL

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

[ovmf test] 169374: regressions - FAIL

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

Re: [PATCH v7 03/20] reboot: Print error message if restart handler has duplicated priority

On Tue, Apr 12, 2022 at 1:39 AM Dmitry Osipenko wrote: > > Add sanity check which ensures that there are no two restart handlers > registered using the same priority. This requirement will become mandatory > once all drivers will be converted to the new API and such errors will be > fixed. > > Sig

[ovmf test] 169372: regressions - FAIL

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

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

flight 169368 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/169368/ 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 1

[ovmf test] 169371: regressions - FAIL

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

[ovmf test] 169370: regressions - FAIL

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

Re: [xen-unstable-smoke test] 169361: regressions - FAIL

Hi, On 13/04/2022 15:48, osstest service owner wrote: flight 169361 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/169361/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xe

[ovmf test] 169366: regressions - FAIL

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

[xen-unstable-smoke test] 169361: regressions - FAIL

flight 169361 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/169361/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 169320 Tests which

Re: [PATCH 7/8] PCI: replace stray uses of PCI_{DEVFN,BDF}2()

On 13.04.2022 16:13, Bertrand Marquis wrote: >> On 13 Apr 2022, at 14:58, Roger Pau Monné wrote: >> On Wed, Apr 13, 2022 at 01:48:14PM +, Bertrand Marquis wrote: On 11 Apr 2022, at 10:40, Jan Beulich wrote: There's no good reason to use these when we already have a pci_sbdf_t >

Re: [PATCH 7/8] PCI: replace stray uses of PCI_{DEVFN,BDF}2()

Hi, > On 13 Apr 2022, at 14:58, Roger Pau Monné wrote: > > On Wed, Apr 13, 2022 at 01:48:14PM +, Bertrand Marquis wrote: >> Hi Jan, >> >>> On 11 Apr 2022, at 10:40, Jan Beulich wrote: >>> >>> There's no good reason to use these when we already have a pci_sbdf_t >>> type object available.

Re: [PATCH early-RFC 4/5] xen/arm: mm: Rework switch_ttbr()

Hi Julien, > On 7 Apr 2022, at 16:38, Julien Grall wrote: > > Hi, > > On 25/03/2022 14:48, Bertrand Marquis wrote: >>> On 25 Mar 2022, at 15:42, Julien Grall wrote: >>> >>> Hi Bertrand, >>> >>> On 25/03/2022 14:35, Bertrand Marquis wrote: > On 25 Mar 2022, at 15:24, Julien Grall wrote:

[ovmf test] 169365: regressions - FAIL

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

Re: [PATCH 7/8] PCI: replace stray uses of PCI_{DEVFN,BDF}2()

On Wed, Apr 13, 2022 at 01:48:14PM +, Bertrand Marquis wrote: > Hi Jan, > > > On 11 Apr 2022, at 10:40, Jan Beulich wrote: > > > > There's no good reason to use these when we already have a pci_sbdf_t > > type object available. This extends to the use of PCI_BUS() in > > pci_ecam_map_bus() a

Re: [PATCH 7/8] PCI: replace stray uses of PCI_{DEVFN,BDF}2()

On 13.04.2022 15:48, Bertrand Marquis wrote: >> On 11 Apr 2022, at 10:40, Jan Beulich wrote: >> --- a/xen/arch/arm/pci/ecam.c >> +++ b/xen/arch/arm/pci/ecam.c >> @@ -28,8 +28,7 @@ void __iomem *pci_ecam_map_bus(struct pc >> container_of(bridge->ops, const struct pci_ecam_ops, pci_ops); >>

Re: [PATCH 7/8] PCI: replace stray uses of PCI_{DEVFN,BDF}2()

Hi Jan, > On 11 Apr 2022, at 10:40, Jan Beulich wrote: > > There's no good reason to use these when we already have a pci_sbdf_t > type object available. This extends to the use of PCI_BUS() in > pci_ecam_map_bus() as well. > > No change to generated code (with gcc11 at least, and I have to adm

[PATCH v4 1/2] x86/mem_sharing: make fork_reset more configurable

Allow specify distinct parts of the fork VM to be reset. This is useful when a fuzzing operation involves mapping in only a handful of pages that are known ahead of time. Throwing these pages away just to be re-copied immediately is expensive, thus allowing to specify partial resets can speed thing

[PATCH v4 2/2] x86/monitor: Add new monitor event to catch all vmexits

Add monitor event that hooks the vmexit handler allowing for both sync and async monitoring of events. With async monitoring an event is placed on the monitor ring for each exit and the rest of the vmexit handler resumes normally. If there are additional monitor events configured those will also pl

[ovmf test] 169364: regressions - FAIL

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

[PATCH v2] xen/build: Add cppcheck and cppcheck-html make rules

cppcheck can be used to check Xen code quality. To create a report do "make cppcheck" on a built tree adding any options you added during the process you used to build xen (like CROSS_COMPILE or XEN_TARGET_ARCH). This will generate an xml report xen-cppcheck.xml. To create a html report do "make

[ovmf test] 169363: regressions - FAIL

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

[ovmf test] 169362: regressions - FAIL

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

[PATCH v10 2/2] x86/xen: Allow per-domain usage of hardware virtualized APIC

Introduce a new per-domain creation x86 specific flag to select whether hardware assisted virtualization should be used for x{2}APIC. A per-domain option is added to xl in order to select the usage of x{2}APIC hardware assisted virtualization, as well as a global configuration option. Having all

[PATCH v10 1/2] xen+tools: Report Interrupt Controller Virtualization capabilities on x86

Add XEN_SYSCTL_PHYSCAP_X86_ASSISTED_XAPIC and XEN_SYSCTL_PHYSCAP_X86_ASSISTED_X2APIC to report accelerated xAPIC and x2APIC, on x86 hardware. This is so that xAPIC and x2APIC virtualization can subsequently be enabled on a per-domain basis. No such features are currently implemented on AMD hardware

[PATCH v10 0/2] xen: Report and use hardware APIC virtualization capabilities

Jane Malalane (2): xen+tools: Report Interrupt Controller Virtualization capabilities on x86 x86/xen: Allow per-domain usage of hardware virtualized APIC docs/man/xl.cfg.5.pod.in | 15 ++ docs/man/xl.conf.5.pod.in | 12 +++ tools/golang/xenligh

Re: [PATCH v9 2/2] x86/xen: Allow per-domain usage of hardware virtualized APIC

On 06/04/2022 14:44, Jan Beulich wrote: > [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments > unless you have verified the sender and know the content is safe. > > On 01.04.2022 12:47, Jane Malalane wrote: >> Introduce a new per-domain creation x86 specific flag to >> sele

[ovmf test] 169360: regressions - FAIL

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

[xen-unstable test] 169348: tolerable FAIL

flight 169348 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/169348/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169328 test-armhf-armhf-libvirt 16 save

Re: [PATCH] xen/evtchn: Add design for static event channel signaling for domUs..

Hello Julien, > On 13 Apr 2022, at 10:44 am, Julien Grall wrote: > > Hi Rahul, > > On 13/04/2022 09:25, Rahul Singh wrote: >>> On 11 Apr 2022, at 7:01 pm, Julien Grall wrote: Signed-off-by: Rahul Singh --- docs/designs/dom0less-evtchn.md | 96 + >

Re: [PATCH] x86: make "dom0_nodes=" work with credit2

On 12.04.2022 18:14, Dario Faggioli wrote: > On Tue, 2022-04-12 at 16:11 +, Dario Faggioli wrote: >> On Tue, 2022-04-12 at 15:48 +, Dario Faggioli wrote: >>> On Fri, 2022-04-08 at 14:36 +0200, Jan Beulich wrote: >>> >>> >>> And while doing that, I think we should consolidate touching the >>

[ovmf test] 169359: regressions - FAIL

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

Re: [PATCH] x86: make "dom0_nodes=" work with credit2

On 12.04.2022 18:11, Dario Faggioli wrote: > --- a/xen/common/sched/core.c > +++ b/xen/common/sched/core.c > @@ -572,11 +572,41 @@ int sched_init_vcpu(struct vcpu *v) > } > > /* > - * Initialize affinity settings. The idler, and potentially > - * domain-0 VCPUs, are pinned onto

Re: [PATCH] xen/evtchn: Add design for static event channel signaling for domUs..

Hi Stefano, On 12/04/2022 21:39, Stefano Stabellini wrote: I should mention that it would be also possible to use sub-nodes to express this information: 2) domU1: domU1 { ... /* one sub-node per local event channel */ ec1: evtchn@a {

Re: [PATCH] xen/evtchn: Add design for static event channel signaling for domUs..

Hi Rahul, On 13/04/2022 09:25, Rahul Singh wrote: On 11 Apr 2022, at 7:01 pm, Julien Grall wrote: Signed-off-by: Rahul Singh --- docs/designs/dom0less-evtchn.md | 96 + 1 file changed, 96 insertions(+) create mode 100644 docs/designs/dom0less-evtchn.md diff --gi

[ovmf test] 169358: regressions - FAIL

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

[ovmf test] 169357: regressions - FAIL

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

[ovmf test] 169352: regressions - FAIL

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

Re: [PATCH] xen/evtchn: Add design for static event channel signaling for domUs..

Hello Julien, Thanks for reviewing the design. > On 11 Apr 2022, at 7:01 pm, Julien Grall wrote: > > Hi Rahul, > > Title: s/../.../ > > On 23/03/2022 15:43, Rahul Singh wrote: >> in dom0less system. This patch introduce the new feature to support the > > s/introduce/introduces/ > s/the new/a

[libvirt test] 169351: regressions - FAIL

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

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

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

Re: [PATCH v7 4/7] xen/cpupool: Create different cpupools at boot time

On 13.04.2022 09:15, Luca Fancellu wrote: > >>> >>> No, I'm not suggesting a new menu. I was merely wondering whether the >>> Kconfig contents wouldn't location-wise better match where the >>> respective source file lives. >> >> It could be in xen/common/sched/Kconfig at the beginning of the file

Re: [PATCH v7 4/7] xen/cpupool: Create different cpupools at boot time

>> >> No, I'm not suggesting a new menu. I was merely wondering whether the >> Kconfig contents wouldn't location-wise better match where the >> respective source file lives. > > It could be in xen/common/sched/Kconfig at the beginning of the file > before creating the new "Schedulers" menu, e.