[qemu-mainline test] 151065: tolerable FAIL - PUSHED

flight 151065 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/151065/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 151047 test-amd64-i386-xl-qemuu-win7-amd64

[xen-unstable-coverity test] 151106: all pass - PUSHED

flight 151106 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/151106/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen b91825f628c9a62cf2a3a0d972ea81484a8b7fce baseline version: xen 51ca

Re: [PATCH 0/8] Coverity fixes for vchan-socket-proxy

On Sat, Jun 13, 2020 at 8:40 AM Marek Marczykowski-Górecki wrote: > > On Wed, May 27, 2020 at 10:59:55PM -0400, Jason Andryuk wrote: > > On Mon, May 25, 2020 at 6:36 PM Jason Andryuk wrote: > > > > > > On Sun, May 24, 2020 at 10:50 PM Jason Andryuk wrote: > > > > > > > > This series addresses so

[xen-unstable test] 151073: regressions - FAIL

flight 151073 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151073/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 151051 Tests which did no

[PATCH 0/1] Fix broken suspend on some machines

Hi, The included patch is a small subset of a bigger patch set spanning few projects aiming to isolate the GPU in Qubes OS to a dedicated security domain. I'm doing this together with 3 colleagues as part of our Bachelors thesis. While working on the project we came across 2 machines - newer gami

[PATCH 1/1] x86/acpi: Use FADT flags to determine the PMTMR width

On some computers the bit width of the PM Timer as reported by ACPI is 32 bits when in fact the FADT flags report correctly that the timer is 24 bits wide. On affected machines such as the ASUS FX504GM and never gaming laptops this results in the inability to resume the machine from suspend. Withou

[PATCH] libxl: tooling expects wrong errno

When iommu is not enabled for a given domain then pci passthrough hypercalls such as xc_test_assign_device return EOPNOTSUPP. The code responsible for this is in "iommu_do_domctl" inside xen/drivers/passthrough/iommu.c This patch fixes the error message reported by libxl when assigning pci devices

[xen-4.12-testing test] 151082: regressions - FAIL

flight 151082 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151082/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-prev 6 xen-buildfail REGR. vs. 150176 build-amd64-pr

[libvirt test] 151091: tolerable all pass - PUSHED

flight 151091 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/151091/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151040 test-armhf-armhf-libvirt-raw 13 saveresto

[xen-4.10-testing test] 151087: regressions - trouble: blocked/fail/pass/starved

flight 151087 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151087/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 150039 test-amd64-i38

[PATCH 1/3] tools/libxl: Grant VGA IO port permission for stubdom/target domain

When qemu is running inside a linux based stubdomain, qemu does not have the necessary permissions to map the ioports to the target domain. Currently, libxl is granting permissions only for the VGA RAM memory region and not passing the required ioports. This patch grants the required permission for

[PATCH 0/3] IGD Passthrough fixes for linux based stubdomains

Hi, The included patches are a small subset of a bigger patch set spanning few projects aiming to isolate the GPU in Qubes OS to a dedicated security domain. I'm doing this together with 3 colleagues as part of our Bachelors thesis. Right now qemu assumes it runs in dom0 so it may grant access t

[PATCH 2/3] tools/libxl: Grant permission for mapping opregions to the target domain

IGD VGA devices require a special opregion MMIO region which functions as an extra BAR in the PCI configuration space. Right now qemu is assigning those permissions - this is failing inside a linux based stubdomain as the stubdomain is not privileged. This patch grants the permissions for opregions

[PATCH 3/3] tools/libxl: Directly map VBIOS to stubdomain

When passing through a IGD VGA device qemu needs to copy the host VBIOS to the target domain. Right now the current implementation on the qemu side is one big undefined behavior as described in my qemu patchset here: https://patchew.org/QEMU/20200428062847.7764-1-gorba...@gmail.com/ This patch is t

[PATCH] hw/xen_pt: Don't grant opregion permissions

With the upstreaming of linux based stubdomains to xen, qemu can't assume it runs inside dom0 - permission assignment must be moved to libxl running in dom0. This xen patch: https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00973.html implements granting the required permissions to th

[xen-4.11-testing test] 151093: regressions - FAIL

flight 151093 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151093/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev 6 xen-buildfail REGR. vs. 150040 build-i386-pre

RE: UEFI support in ARM DomUs

Hi Stefano, > -Original Message- > From: Stefano Stabellini [mailto:sstabell...@kernel.org] > Sent: 2020年6月4日 23:32 > To: Oleksandr Andrushchenko > Cc: Peng Fan ; Roman Shaposhnik > ; Xen-devel ; Stefano > Stabellini ; Julien Grall ; Nataliya > Korovkina > Subject: Re: UEFI support in AR

TEE with XEN

Hi All, While enabling trusty os with xen, I took same approach as OP-TEE, with OP-TEE running in secure world. But I am also thinking this might introduce potential issue is that secure world OS communicate with DomU. If there are some misbehavior in secure world OS, it might let XEN hypervisor

[xen-4.9-testing test] 151096: regressions - trouble: blocked/fail/pass/starved

flight 151096 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151096/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm6 xen-buildfail REGR. vs. 150120 build-amd64-pre

Re: [PATCH v10 1/9] error: auto propagated local_err

Greg Kurz writes: > On Tue, 17 Mar 2020 18:16:17 +0300 > Vladimir Sementsov-Ogievskiy wrote: > >> Introduce a new ERRP_AUTO_PROPAGATE macro, to be used at start of >> functions with an errp OUT parameter. >> >> It has three goals: >> >> 1. Fix issue with error_fatal and error_prepend/error_app

Re: [PATCH] hw/xen_pt: Don't grant opregion permissions

Hi Grzegorz, On 6/15/20 1:21 AM, Grzegorz Uriasz wrote: > With the upstreaming of linux based stubdomains to xen, qemu can't > assume it runs inside dom0 - permission assignment must be moved to > libxl running in dom0. This xen patch: > https://lists.xenproject.org/archives/html/xen-devel/2020-06

Re: [PATCH v10 1/9] error: auto propagated local_err

On Mon, 15 Jun 2020 07:21:03 +0200 Markus Armbruster wrote: > Greg Kurz writes: > > > On Tue, 17 Mar 2020 18:16:17 +0300 > > Vladimir Sementsov-Ogievskiy wrote: > > > >> Introduce a new ERRP_AUTO_PROPAGATE macro, to be used at start of > >> functions with an errp OUT parameter. > >> > >> It h