[Xen-devel] [linux-4.4 test] 141934: regressions - FAIL

flight 141934 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/141934/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 141896 REGR. vs. 139698 Tests which

Re: [Xen-devel] [PATCH v7 4/4] xen/x86: Allow stubdom access to irq created for msi.

On Thu, Sep 26, 2019 at 09:10:17AM +0200, Roger Pau Monné wrote: > On Thu, Sep 26, 2019 at 06:16:06AM +0200, Marek Marczykowski-Górecki wrote: > > On Wed, Sep 25, 2019 at 03:26:17PM +0200, Roger Pau Monné wrote: > > > On Wed, Sep 25, 2019 at 02:29:41PM +0200, Marek Marczykowski-Górecki > > > wrote

[Xen-devel] [qemu-mainline test] 141925: regressions - FAIL

flight 141925 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/141925/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 140282 test-amd64-i386-f

[Xen-devel] [libvirt test] 141931: tolerable FAIL - PUSHED

flight 141931 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/141931/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail like 141893 test-armhf-armhf-libvirt 14 saveresto

[Xen-devel] [xen-unstable test] 141919: regressions - FAIL

flight 141919 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/141919/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 141822 test-amd64-amd64-l

[Xen-devel] [linux-4.19 test] 141913: regressions - FAIL

flight 141913 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/141913/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 6 kernel-build fail in 141813 REGR. vs. 129313 Tests which are fail

[Xen-devel] [PATCH v4 01/12] livepatch: Always check hypervisor build ID upon livepatch upload

This change is part of a independant stacked livepatch modules feature. This feature allows to bypass dependencies between modules upon loading, but still verifies Xen build ID matching. In order to prevent (up)loading any livepatches built for different hypervisor version as indicated by the Xen

[Xen-devel] [PATCH v4 10/12] livepatch: Handle arbitrary size names with the list operation

The payloads' name strings can be of arbitrary size (typically small with an upper bound of XEN_LIVEPATCH_NAME_SIZE). Current implementation of the list operation interface allows to copy names in the XEN_LIVEPATCH_NAME_SIZE chunks regardless of its actual size and enforces space allocation require

[Xen-devel] [PATCH v4 05/12] livepatch: Add support for apply|revert action replacement hooks

By default, in the quiescing zone, a livepatch payload is applied with apply_payload() and reverted with revert_payload() functions. Both of the functions receive the payload struct pointer as a parameter. The functions are also a place where standard 'load' and 'unload' module hooks are executed.

[Xen-devel] [PATCH v4 07/12] livepatch: Add per-function applied/reverted state tracking marker

Livepatch only tracks an entire payload applied/reverted state. But, with an option to supply the apply_payload() and/or revert_payload() functions as optional hooks, it becomes possible to intermix the execution of the original apply_payload()/revert_payload() functions with their dynamically supp

[Xen-devel] [PATCH v4 12/12] livepatch: Add python bindings for livepatch operations

Extend the XC python bindings library to support also all common livepatch operations and actions. Add the python bindings for the following operations: - status (pyxc_livepatch_status): Requires a payload name as an input. Returns a status dict containing a state string and a return code in

[Xen-devel] [PATCH v4 09/12] livepatch: Add support for modules .modinfo section metadata

Having detailed livepatch metadata helps to properly identify module's origin and version. It also allows to keep track of the history of livepatch loads in the system (at least within dmesg buffer size limits). The livepatch metadata are embedded in a form of .modinfo section. Each such section c

[Xen-devel] [PATCH v4 06/12] livepatch: Do not enforce ELF_LIVEPATCH_FUNC section presence

With default implementation the ELF_LIVEPATCH_FUNC section containing all functions to be replaced or added must be part of the livepatch payload, otherwise the payload is rejected (with -EINVAL). However, with the extended hooks implementation, a livepatch may be constructed of only hooks to perf

[Xen-devel] [PATCH v4 11/12] livepatch: Add metadata runtime retrieval mechanism

Extend the livepatch list operation to fetch also payloads' metadata. This is achieved by extending the sysctl list interface with 2 extra guest handles: * metadata - an array of arbitrary size strings * metadata_len - an array of metadata strings' lengths (uin32_t each) Payloads' metadata is

[Xen-devel] [PATCH v4 08/12] livepatch: Add support for inline asm livepatching expectations

This is the initial implementation of the expectations enhancement to improve inline asm livepatching. Expectations are designed as optional feature, since the main use of them is planned for inline asm livepatching. The flag enabled allows to control the expectation state. Each expectation has da

[Xen-devel] [PATCH v4 00/12] livepatch: new features and fixes

This series introduces new features to the livepatch functionality as briefly discussed during Xen Developer Summit 2019: [a] and [b]. It also provides a few fixes and some small improvements. Main changes in v4: - Fix various typos and minor issues - Simplify arch_livepatch_{apply,revert} by usin

[Xen-devel] [PATCH v4 02/12] livepatch: Allow to override inter-modules buildid dependency

By default Livepatch enforces the following buildid-based dependency chain between livepatch modules: 1) first module depends on given hypervisor buildid 2) every consecutive module depends on previous module's buildid This way proper livepatch stack order is maintained and enforced. While it i

[Xen-devel] [PATCH v4 03/12] livepatch: Export payload structure via livepatch_payload.h

The payload structure will be used by the new hooks implementation and therefore its definition has to be exported via the livepatch_payload header. The new hooks will make use of the payload structure fields and the hooks' pointers will also be defined in the payload structure, so the structure al

[Xen-devel] [PATCH v4 04/12] livepatch: Implement pre-|post- apply|revert hooks

This is an implementation of 4 new livepatch module vetoing hooks, that can be optionally supplied along with modules. Hooks that currently exists in the livepatch mechanism aren't agile enough and have various limitations: * run only from within a quiescing zone * cannot conditionally prevent appl

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

flight 141911 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/141911/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i38

[Xen-devel] [PATCH v8 1/4] libxl: fix cold plugged PCI device with stubdomain

When libxl__device_pci_add() is called, stubdomain is already running, even when still constructing the target domain. Previously, do_pci_add() was called with 'starting' hardcoded to false, but now do_pci_add() shares 'starting' flag in pci_add_state for both target domain and stubdomain. Fix thi

[Xen-devel] [PATCH v8 0/4] Fix PCI passthrough for HVM with stubdomain

This version is rebase libxl patches on staging. Changes to "libxl: attach PCI device to qemu only after setting pciback/pcifront" are significant enough that I've dropped Wei's ack. Also, there is a new patch to fix regression introduced during async conversion. Changes in v2: - new "xen/x86: Al

[Xen-devel] [PATCH v8 2/4] libxl: do not attach xen-pciback to HVM domain, if stubdomain is in use

HVM domains use IOMMU and device model assistance for communicating with PCI devices, xen-pcifront/pciback isn't directly needed by HVM domain. But pciback serve also second function - it reset the device when it is deassigned from the guest and for this reason pciback needs to be used with HVM dom

[Xen-devel] [PATCH v8 3/4] libxl: attach PCI device to qemu only after setting pciback/pcifront

When qemu is running in stubdomain, handling "pci-ins" command will fail if pcifront is not initialized already. Fix this by sending such command only after confirming that pciback/front is running. Signed-off-by: Marek Marczykowski-Górecki --- Changes in v2: - Fixed code style since previous ver

[Xen-devel] [PATCH v8 4/4] libxl: don't try to manipulate json config for stubdomain

Stubdomain do not have it's own config file - its configuration is derived from target domains. Do not try to manipulate it when attaching PCI device. This bug prevented starting HVM with stubdomain and PCI passthrough device attached. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu

Re: [Xen-devel] [PATCH v7 0/4] Fix PCI passthrough for HVM with stubdomain

On Fri, Sep 27, 2019 at 03:36:08PM +0100, Wei Liu wrote: > On Fri, Sep 27, 2019 at 04:21:55PM +0200, Jan Beulich wrote: > > > > > > Marek Marczykowski-Górecki (4): > > > libxl: do not attach xen-pciback to HVM domain, if stubdomain is in use > > > libxl: attach PCI device to qemu only after se

Re: [Xen-devel] [ANNOUNCE] Xen 4.13 Development Update

At the risk of sounding like a broken record, is there an progress with investigations on the AMD Ryzen 3xxx series and Windows HVM systems? Steven Haigh 📧 net...@crc.id.au 💻 https://www.crc.id.au 📞 +613 9001 6090 📱 +614 1293 5897 On Sat, Sep 28, 2019 at 07:09, Juergen Gross wrote:

Re: [Xen-devel] [PATCH V6 0/8] iommu/arm: Add Renesas IPMMU-VMSA support + Linux's iommu_fwspec

On 28/09/2019 00:52, Oleksandr Tyshchenko wrote: > сб, 28 сент. 2019 г., 01:50 Stefano Stabellini >: > > On Thu, 26 Sep 2019, Oleksandr wrote: > > On 26.09.19 17:56, Julien Grall wrote: > > > Hi, > > > > Hi Julien > > > > > >

Re: [Xen-devel] [PATCH v1] xen/balloon: Set pages PageOffline() in balloon_add_region()

On 27.09.19 20:08, Boris Ostrovsky wrote: > On 9/27/19 11:46 AM, David Hildenbrand wrote: >> We are missing a __SetPageOffline(), which is why we can get >> !PageOffline() pages onto the balloon list, where >> alloc_xenballooned_pages() will complain: >> >> page:ea0003e7ffc0 refcount:1 mapcount

[Xen-devel] [PATCH] x86/iommu: fix hwdom iommu requirements check

Both a shadow and a HAP hwdom require an iommu and must be run in strict mode. Change the HAP check into a hvm domain check. Signed-off-by: Roger Pau Monné --- xen/drivers/passthrough/iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/drivers/passthrough/iommu.c b/xe

[Xen-devel] [qemu-upstream-unstable test] 141899: tolerable FAIL - PUSHED

flight 141899 qemu-upstream-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/141899/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 140767 test-amd64-i386-xl-qemuu-w

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

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

Re: [Xen-devel] [PATCH v2 00/21] Refine memblock API

On Thu, Sep 26, 2019 at 02:35:53PM -0500, Adam Ford wrote: > On Thu, Sep 26, 2019 at 11:04 AM Mike Rapoport wrote: > > > > Hi, > > > > On Thu, Sep 26, 2019 at 08:09:52AM -0500, Adam Ford wrote: > > > On Wed, Sep 25, 2019 at 10:17 AM Fabio Estevam wrote: > > > > > > > > On Wed, Sep 25, 2019 at 9:1