[libvirt test] 164789: regressions - FAIL

flight 164789 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/164789/ 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

Re: [PATCH v5 7/7] xen/arm: introduce allocate_static_memory

On 03/09/2021 01:39, Stefano Stabellini wrote: On Thu, 2 Sep 2021, Julien Grall wrote: +kinfo->mem.nr_banks = ++gbank; +kinfo->unassigned_mem -= tot_size; +if ( kinfo->unassigned_mem ) +{ +printk(XENLOG_ERR + "Size of \"memory\" property doesn't match up

Re: Enabling hypervisor agnosticism for VirtIO backends

Alex, On Wed, Sep 01, 2021 at 01:53:34PM +0100, Alex Benn??e wrote: > > Stefan Hajnoczi writes: > > > [[PGP Signed Part:Undecided]] > > On Wed, Aug 04, 2021 at 12:20:01PM -0700, Stefano Stabellini wrote: > >> > Could we consider the kernel internally converting IOREQ messages from > >> > the Xe

[ovmf test] 164790: regressions - FAIL

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

[PATCH 01/11] xen/arm: Add new device type for PCI

From: Oleksandr Andrushchenko Add new device type (DEV_PCI) to distinguish PCI devices from platform DT devices, so some drivers, like IOMMU, can handle PCI devices differently. While at it fix dev_is_dt macro. Signed-off-by: Oleksandr Andrushchenko --- xen/include/asm-arm/device.h | 6 +++---

[PATCH 02/11] xen/arm: Add dev_to_pci helper

From: Oleksandr Andrushchenko Add a helper which is when given a struct device returns the corresponding struct pci_dev which this device is a part of. Because of the header cross-dependencies, e.g. we need both struct pci_dev and struct arch_pci_dev at the same time, this cannot be done with an

[PATCH 00/11] PCI devices passthrough on Arm, part 2

From: Oleksandr Andrushchenko Hi, all! This is an assorted series of patches which aim is to make some further basis for PCI passthrough on Arm support. The series continues the work published earlier by Arm [1] and adds new helpers and clears the way for vPCI changes which will follow. Thank y

[PATCH 03/11] xen/arm: Introduce pci_find_host_bridge_node helper

From: Oleksandr Andrushchenko Get host bridge node given a PCI device attached to it. This helper will be re-used for adding PCI devices by the subsequent patches. Signed-off-by: Oleksandr Andrushchenko Signed-off-by: Oleksandr Tyshchenko --- xen/arch/arm/pci/pci-host-common.c | 17 +

[PATCH 04/11] xen/device-tree: Make dt_find_node_by_phandle global

From: Oleksandr Andrushchenko Make dt_find_node_by_phandle globally visible, so it can be re-used by other frameworks. Signed-off-by: Oleksandr Andrushchenko --- xen/common/device_tree.c | 2 +- xen/include/xen/device_tree.h | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --

[PATCH 05/11] xen/arm: Mark device as PCI while creating one

From: Oleksandr Andrushchenko While adding a PCI device mark it as such, so other frameworks can distinguish it form DT devices. Signed-off-by: Oleksandr Andrushchenko --- xen/drivers/passthrough/pci.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xen/drivers/passthrough/pci.c b/xen/d

[PATCH 06/11] xen/domain: Call pci_release_devices() when releasing domain resources

From: Oleksandr Tyshchenko This is the very same what we do for DT devices. What is more that x86 already calls pci_release_devices(). Signed-off-by: Oleksandr Tyshchenko --- xen/arch/arm/domain.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/domain.c

[PATCH 07/11] libxl: Allow removing PCI devices for all types of domains

From: Oleksandr Andrushchenko The PCI device remove path may now be used by PVH on ARM, so the assert is no longer valid. Signed-off-by: Oleksandr Andrushchenko Cc: Ian Jackson Cc: Juergen Gross --- tools/libs/light/libxl_pci.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/tools/libs/

[PATCH 08/11] libxl: Only map legacy PCI IRQs if they are supported

From: Oleksandr Andrushchenko Arm's PCI passthrough implementation doesn't support legacy interrupts, but MSI/MSI-X. This can be the case for other platforms too. For that reason introduce a new CONFIG_PCI_SUPP_LEGACY_IRQ and add it to the CFLAGS and compile the relevant code in the toolstack onl

[PATCH 09/11] xen/arm: Setup MMIO range trap handlers for hardware domain

From: Oleksandr Andrushchenko In order vPCI to work it needs all access to PCI configuration space (ECAM) to be synchronized among all entities, e.g. hardware domain and guests. For that implement PCI host bridge specific callbacks to properly setup those ranges depending on particular host bridg

[PATCH 11/11] xen/arm: Process pending vPCI map/unmap operations

From: Oleksandr Andrushchenko vPCI may map and unmap PCI device memory (BARs) being passed through which may take a lot of time. For this those operations may be deferred to be performed later, so that they can be safely preempted. Run the corresponding vPCI code while switching a vCPU. Signed-o

[PATCH 10/11] xen/arm: Do not map PCI ECAM space to Domain-0's p2m

From: Oleksandr Andrushchenko Host bridge controller's ECAM space is mapped into Domain-0's p2m, thus it is not possible to trap the same for vPCI via MMIO handlers. For this to work we need to not map those while constructing the domain. Note, that during Domain-0 creation there is no pci_dev y

[PATCH 0/2] xen: fix illegal rtc device usage of pv guests

A recent change in mc146818_get_time() resulted in WARN splats when booting a Xen PV guest. The main reason is that there is a code path resulting in accessing a RTC device which is not present, which has been made obvious by a call of WARN() in this case. This small series is fixing this issue b

[PATCH 2/2] xen: reset legacy rtc flag for PV domU

A Xen PV guest doesn't have a legacy RTC device, so reset the legacy RTC flag. Otherwise the following WARN splat will occur at boot: [1.333404] WARNING: CPU: 1 PID: 1 at /home/gross/linux/head/drivers/rtc/rtc-mc146818-lib.c:25 mc146818_get_time+0x1be/0x210 [1.333404] Modules linked in:

[PATCH 1/2] PM: base: power: don't try to use non-existing RTC for storing data

In there is no legacy RTC device, don't try to use it for storing trace data across suspend/resume. Cc: Signed-off-by: Juergen Gross --- drivers/base/power/trace.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/base/power/trace.c b/drivers/base/power/trace.c index a97f3

Re: [PATCH 1/2] PM: base: power: don't try to use non-existing RTC for storing data

On Fri, Sep 03, 2021 at 10:49:36AM +0200, Juergen Gross wrote: > In there is no legacy RTC device, don't try to use it for storing trace > data across suspend/resume. > > Cc: > Signed-off-by: Juergen Gross > --- > drivers/base/power/trace.c | 10 ++ > 1 file changed, 10 insertions(+) >

Re: [PATCH 1/2] PM: base: power: don't try to use non-existing RTC for storing data

On 03.09.21 10:56, Greg Kroah-Hartman wrote: On Fri, Sep 03, 2021 at 10:49:36AM +0200, Juergen Gross wrote: In there is no legacy RTC device, don't try to use it for storing trace data across suspend/resume. Cc: Signed-off-by: Juergen Gross --- drivers/base/power/trace.c | 10 ++ 1

Re: [PATCH 11/11] xen/arm: Process pending vPCI map/unmap operations

Hi Oleksandr, On 03/09/2021 09:33, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko vPCI may map and unmap PCI device memory (BARs) being passed through which may take a lot of time. For this those operations may be deferred to be performed later, so that they can be safely preempt

Re: [PATCH 1/2] PM: base: power: don't try to use non-existing RTC for storing data

On Fri, Sep 03, 2021 at 11:01:58AM +0200, Juergen Gross wrote: > On 03.09.21 10:56, Greg Kroah-Hartman wrote: > > On Fri, Sep 03, 2021 at 10:49:36AM +0200, Juergen Gross wrote: > > > In there is no legacy RTC device, don't try to use it for storing trace > > > data across suspend/resume. > > > > >

Re: [PATCH v2] xen/arm64: Remove vreg_emulate_sysreg32

On 02.09.2021 14:50, Julien Grall wrote: > On 01/09/2021 10:38, Michal Orzel wrote: >> Hi Julien, > > Hi Michal, > >> On 06.08.2021 13:12, Julien Grall wrote: >>> >>> >>> On 29/07/2021 12:47, Michal Orzel wrote: Hi Julien, >>> >>> Hi Michal, >>> On 29.07.2021 13:20, Julien Grall wrot

Re: Enabling hypervisor agnosticism for VirtIO backends

AKASHI Takahiro writes: > Alex, > > On Wed, Sep 01, 2021 at 01:53:34PM +0100, Alex Benn??e wrote: >> >> Stefan Hajnoczi writes: >> >> > [[PGP Signed Part:Undecided]] >> > On Wed, Aug 04, 2021 at 12:20:01PM -0700, Stefano Stabellini wrote: >> >> > Could we consider the kernel internally conve

[PATCH 1/9] vpci: Make vpci registers removal a dedicated function

From: Oleksandr Andrushchenko This is in preparation for dynamic assignment of the vpci register handlers depending on the domain: hwdom or guest. Signed-off-by: Oleksandr Andrushchenko --- xen/drivers/vpci/vpci.c | 7 ++- xen/include/xen/vpci.h | 2 ++ 2 files changed, 8 insertions(+), 1

[PATCH 0/9] PCI devices passthrough on Arm, part 3

From: Oleksandr Andrushchenko Hi, all! This patch series is focusing on vPCI and adds support for non-identity PCI BAR mappings which is required while passing through a PCI device to a guest. The highlights are: - Add relevant vpci register handlers when assigning PCI device to a domain and

[PATCH 2/9] vpci: Add hooks for PCI device assign/de-assign

From: Oleksandr Andrushchenko When a PCI device gets assigned/de-assigned some work on vPCI side needs to be done for that device. Introduce a pair of hooks so vPCI can handle that. Signed-off-by: Oleksandr Andrushchenko --- xen/drivers/passthrough/pci.c | 9 + xen/drivers/vpci/vpci.c

[PATCH 3/9] vpci/header: Move register assignments from init_bars

From: Oleksandr Andrushchenko This is in preparation for dynamic assignment of the vpci register handlers depending on the domain: hwdom or guest. Signed-off-by: Oleksandr Andrushchenko --- xen/drivers/vpci/header.c | 83 ++- 1 file changed, 56 insertions(+)

[PATCH 4/9] vpci/header: Add and remove register handlers dynamically

From: Oleksandr Andrushchenko Add relevant vpci register handlers when assigning PCI device to a domain and remove those when de-assigning. This allows having different handlers for different domains, e.g. hwdom and other guests. Use stubs for guest domains for now. Signed-off-by: Oleksandr And

[PATCH 5/9] vpci/header: Implement guest BAR register handlers

From: Oleksandr Andrushchenko Emulate guest BAR register values: this allows creating a guest view of the registers and emulates size and properties probe as it is done during PCI device enumeration by the guest. ROM BAR is only handled for the hardware domain and for guest domains there is a st

[PATCH 6/9] vpci/header: Handle p2m range sets per BAR

From: Oleksandr Andrushchenko Instead of handling a single range set, that contains all the memory regions of all the BARs and ROM, have them per BAR. This is in preparation of making non-identity mappings in p2m for the MMIOs/ROM. Signed-off-by: Oleksandr Andrushchenko --- xen/drivers/vpci/h

[PATCH 7/9] vpci/header: program p2m with guest BAR view

From: Oleksandr Andrushchenko Take into account guest's BAR view and program its p2m accordingly: gfn is guest's view of the BAR and mfn is the physical BAR value as set up by the host bridge in the hardware domain. This way hardware doamin sees physical BAR values and guest sees emulated ones.

[PATCH 8/9] vpci/header: Reset the command register when adding devices

From: Oleksandr Andrushchenko Reset the command register when passing through a PCI device: it is possible that when passing through a PCI device its memory decoding bits in the command register are already set. Thus, a guest OS may not write to the command register to update memory decoding, so

[PATCH 9/9] vpci/header: Use pdev's domain instead of vCPU

From: Rahul Singh Fixes: 9c244fdef7e7 ("vpci: add header handlers") Signed-off-by: Rahul Singh Signed-off-by: Oleksandr Andrushchenko --- xen/drivers/vpci/header.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c index d

Re: [PATCH 08/11] libxl: Only map legacy PCI IRQs if they are supported

On 03.09.21 10:33, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Arm's PCI passthrough implementation doesn't support legacy interrupts, but MSI/MSI-X. This can be the case for other platforms too. For that reason introduce a new CONFIG_PCI_SUPP_LEGACY_IRQ and add it to the CFLAG

Re: [PATCH 08/11] libxl: Only map legacy PCI IRQs if they are supported

Hello, Juergen! On 03.09.21 13:26, Juergen Gross wrote: > On 03.09.21 10:33, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko >> >> Arm's PCI passthrough implementation doesn't support legacy interrupts, >> but MSI/MSI-X. This can be the case for other platforms too. >> For that re

[xen-unstable test] 164786: tolerable FAIL

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

Re: [PATCH 05/11] xen/arm: Mark device as PCI while creating one

On 03.09.2021 10:33, Oleksandr Andrushchenko wrote: > --- a/xen/drivers/passthrough/pci.c > +++ b/xen/drivers/passthrough/pci.c > @@ -1301,6 +1301,9 @@ static int iommu_add_device(struct pci_dev *pdev) > if ( !is_iommu_enabled(pdev->domain) ) > return 0; > > +#ifdef CONFIG_ARM > +

[ovmf test] 164794: regressions - FAIL

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

Re: [PATCH 05/11] xen/arm: Mark device as PCI while creating one

On 03.09.21 15:41, Jan Beulich wrote: > On 03.09.2021 10:33, Oleksandr Andrushchenko wrote: >> --- a/xen/drivers/passthrough/pci.c >> +++ b/xen/drivers/passthrough/pci.c >> @@ -1301,6 +1301,9 @@ static int iommu_add_device(struct pci_dev *pdev) >> if ( !is_iommu_enabled(pdev->domain) ) >>

[linux-linus test] 164791: regressions - FAIL

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

Call for agenda items for September 7th Community Call @ 1500 UTC

Hi everyone, Our next meeting is this upcoming Tuesday at 1500 UTC. The proposed agenda is in https://cryptpad.fr/pad/#/2/pad/edit/PXjRK6mJfWbUxSNW0Qt8xOqT/. Please add or edit any items to this agenda. Alternatively, please feel free to email me directly with agenda items. Please put your name

[PATCH v4 00/11] xsm: refactoring xsm hooks

Based on feedback from 2021 Xen Developers Summit the xsm-roles RFC patch set is being split into two separate patch sets. This is the first patch set and is focused purely on the clean up and refactoring of the XSM hooks. This patch set refactors the xsm_ops wrapper hooks to use the alternative_c

[PATCH v4 01/11] xen: Implement xen/alternative-call.h for use in common code

From: Andrew Cooper The alternative call infrastructure is x86-only for now, but the common iommu code has a variant and more common code wants to use the infrastructure. Introduce CONFIG_ALTERNATIVE_CALL and a conditional implemetnation so common code can use the optimisation when available, wi

[PATCH v4 02/11] xsm: remove the ability to disable flask

On Linux when SELinux is put into permissive mode the descretionary access controls are still in place. Whereas for Xen when the enforcing state of flask is set to permissive, all operations for all domains would succeed, i.e. it does not fall back to the default access controls. To provide a means

[PATCH v4 03/11] xsm: drop dubious xsm_op_t type

The type xsm_op_t masks the use of void pointers. This commit drops the xsm_op_t type and replaces it and all its uses with an explicit void. Signed-off-by: Daniel P. Smith --- xen/include/xen/hypercall.h | 4 ++-- xen/include/xsm/dummy.h | 4 ++-- xen/include/xsm/xsm.h | 11 ---

[PATCH v4 04/11] xsm: apply coding style

Instead of intermixing coding style changes with code changes as they are come upon in this patch set, moving all coding style changes into a single commit. The focus of coding style changes here are, - move trailing comments to line above - ensuring line length does not exceed 80 chars - ensur

[PATCH v4 05/11] xsm: refactor xsm_ops handling

This renames the `struct xsm_operations` to the shorter `struct xsm_ops` and converts the global xsm_ops from being a pointer to an explicit instance. As part of this conversion, it reworks the XSM modules init function to return their xsm_ops struct which is copied in to the global xsm_ops instanc

[PATCH v4 06/11] xsm: convert xsm_ops hook calls to alternative call

To reduce retpolines convert all the pointer function calls of the xsm_ops hooks over to the alternative_call infrastructure. Signed-off-by: Daniel P. Smith Acked-by: Andrew Cooper --- xen/include/xsm/xsm.h | 193 +- 1 file changed, 97 insertions(+), 96 d

[PATCH v4 07/11] xsm: decouple xsm header inclusion selection

Multiple preprocessor defines were used as a mechanism to selective include parts of the xsm.h header file. This makes it difficult to know which portion is being included at any one time. This commit works to simplify this by separating the core structures and functions of XSM into xsm-core.h away

[PATCH v4 08/11] xsm: drop generic event channel labeling exclusion

The internal define flag is not used by any XSM module, removing the #ifdef leaving the generic event channel labeling as always present. Signed-off-by: Daniel P. Smith --- xen/include/xen/sched.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/xen/include/xen/sched.h b/xen/include/xen/sche

[PATCH v4 09/11] silo: remove circular xsm hook call

SILO implements a few XSM hooks to extended the decision logic beyond what is defined in the dummy/default policy. For each of the hooks, it falls back to the dummy/default policy. The fall back is done a slight round-about way. This commit makes the direct call to the default policy's logic, xsm_d

[PATCH v4 10/11] kconfig: update xsm config to reflect reality

It has been a very long time since XSM Flask was the only XSM module, yet the concenpt of turning XSM on/off continues to be synonymous with enabling and disabling XSM Flask. Even when XSM Flask was the only module, turning XSM on/off did not disable or remove the XSM hooks but simply controlled wh

[PATCH v4 11/11] xsm: remove alternate xsm hook interface

Hidden behind macro magic is an alternative xsm hook interface dedicated for use when the dummy/default policy is the only one built. This alternative interface increases code complexity and code size in the core security framework of Xen. This results in code requiring additional maintanence and

Crash when using cpupools

Hi, While doing some investigation with cpupools I encountered a crash when trying to isolate a guest to its own physical cpu. I am using current staging status. I did the following (on FVP with 8 cores): - start dom0 with dom0_max_vcpus=1 - remove core 1 from dom0 cpupool: xl cpupool-cpu-remov

Re: [PATCH] domain: try to address Coverity pointing out a missing "break" in domain_teardown()

Hi Jan, On 01/09/2021 09:45, Jan Beulich wrote: Commit 806448806264 ("xen/domain: Fix label position in domain_teardown()" has caused Coverity to report a _new_ supposedly un-annotated fall-through in a switch(). I find this (once again) puzzling; I'm having an increasingly hard time figuring wh

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

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

[PATCH v3 30/30] accel: Add missing AccelOpsClass::has_work() and drop SysemuCPUOps one

cpu_common_has_work() is the default has_work() implementation and returns 'false'. Explicit it for the QTest / HAX / HVF / NVMM / Xen accelerators and remove cpu_common_has_work(). Since there are no more implementations of SysemuCPUOps::has_work, remove it along with the assertion in cpu_has_wo

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

flight 164792 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/164792/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 164772 test-amd64-amd64-qemuu-nested-amd 2

Re: [PATCH v3 01/30] accel/tcg: Restrict cpu_handle_halt() to sysemu

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: +#ifndef CONFIG_USER_ONLY static inline bool cpu_handle_halt(CPUState *cpu) { Hmm, slightly better to move the ifdef just inside here, @@ -607,6 +608,7 @@ static inline bool cpu_handle_halt(CPUState *cpu) and here, return false

Re: [PATCH v3 02/30] hw/core: Restrict cpu_has_work() to sysemu

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: cpu_has_work() is only called from system emulation code. Signed-off-by: Philippe Mathieu-Daudé --- include/hw/core/cpu.h | 32 1 file changed, 16 insertions(+), 16 deletions(-) Reviewed-by: Richard Henderson

Re: [PATCH v3 03/30] hw/core: Un-inline cpu_has_work()

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: We want to make cpu_has_work() per-accelerator. Only declare its prototype and move its definition to softmmu/cpus.c. Signed-off-by: Philippe Mathieu-Daudé --- include/hw/core/cpu.h | 8 +--- softmmu/cpus.c| 8 2 files cha

Re: [PATCH v3 04/30] sysemu: Introduce AccelOpsClass::has_work()

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: Introduce an accelerator-specific has_work() handler. Eventually call it from cpu_has_work(). Signed-off-by: Philippe Mathieu-Daudé --- include/sysemu/accel-ops.h | 5 + softmmu/cpus.c | 3 +++ 2 files changed, 8 insertions(+)

Re: [PATCH v3 05/30] accel/kvm: Implement AccelOpsClass::has_work()

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: Implement KVM has_work() handler in AccelOpsClass and remove it from cpu_thread_is_idle() since cpu_has_work() is already called. Signed-off-by: Philippe Mathieu-Daudé --- accel/kvm/kvm-accel-ops.c | 6 ++ softmmu/cpus.c| 2 +-

Re: [PATCH v3 06/30] accel/whpx: Implement AccelOpsClass::has_work()

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: Implement WHPX has_work() handler in AccelOpsClass and remove it from cpu_thread_is_idle() since cpu_has_work() is already called. Signed-off-by: Philippe Mathieu-Daudé --- softmmu/cpus.c| 4 +--- target/i386/whpx/whpx-accel

Re: [PATCH v3 07/30] accel/tcg: Implement AccelOpsClass::has_work() as stub

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: Add TCG target-specific has_work() handler in TCGCPUOps, and add tcg_cpu_has_work() as AccelOpsClass has_work() implementation. Signed-off-by: Philippe Mathieu-Daudé --- include/hw/core/tcg-cpu-ops.h | 4 accel/tcg/tcg-accel-ops.c | 1

[ovmf test] 164795: regressions - FAIL

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

Re: [PATCH v3 08/30] target/alpha: Restrict has_work() handler to sysemu and TCG

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: Restrict has_work() to TCG sysemu. Signed-off-by: Philippe Mathieu-Daudé --- target/alpha/cpu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/target/alpha/cpu.c b/target/alpha/cpu.c index 93e16a2ffb4..32cf5a2ea9f 10064

Re: [PATCH v3 09/30] target/arm: Restrict has_work() handler to sysemu and TCG

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: Restrict has_work() to TCG sysemu. Signed-off-by: Philippe Mathieu-Daudé --- target/arm/cpu.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) Reviewed-by: Richard Henderson r~

Re: [PATCH v3 10/30] target/avr: Restrict has_work() handler to sysemu and TCG

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: Restrict has_work() to TCG sysemu. Signed-off-by: Philippe Mathieu-Daudé --- target/avr/cpu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/target/avr/cpu.c b/target/avr/cpu.c index e9fa54c9777..6267cc6d530 100644 ---

Re: [PATCH v3 11/30] target/cris: Restrict has_work() handler to sysemu and TCG

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: +#if defined(CONFIG_TCG) && !defined(CONFIG_USER_ONLY) static bool cris_cpu_has_work(CPUState *cs) No CONFIG_TCG for cris. Otherwise, Reviewed-by: Richard Henderson r~

Re: [PATCH v3 12/30] target/hexagon: Remove unused has_work() handler

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: has_work() is sysemu specific, and Hexagon target only provides a linux-user implementation. Remove the unused hexagon_cpu_has_work(). Signed-off-by: Philippe Mathieu-Daudé --- target/hexagon/cpu.c | 6 -- 1 file changed, 6 deletions(-) R

Re: [PATCH v3 13/30] target/hppa: Restrict has_work() handler to sysemu and TCG

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: Restrict has_work() to TCG sysemu. Signed-off-by: Philippe Mathieu-Daudé --- target/hppa/cpu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/target/hppa/cpu.c b/target/hppa/cpu.c index e8edd189bfc..cf1f656218f 100644 -

Re: [PATCH v3 14/30] target/i386: Restrict has_work() handler to sysemu and TCG

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: Restrict has_work() to TCG sysemu. Signed-off-by: Philippe Mathieu-Daudé --- target/i386/cpu.c | 6 -- target/i386/tcg/tcg-cpu.c | 8 +++- 2 files changed, 7 insertions(+), 7 deletions(-) Reviewed-by: Richard Henderson r~

Re: [PATCH v3 15/30] target/m68k: Restrict has_work() handler to sysemu and TCG

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: Restrict has_work() to TCG sysemu. Signed-off-by: Philippe Mathieu-Daudé --- target/m68k/cpu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/target/m68k/cpu.c b/target/m68k/cpu.c index 66d22d11895..94b35cb4a50 100644 -

Re: [PATCH v3 16/30] target/microblaze: Restrict has_work() handler to sysemu and TCG

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: Restrict has_work() to TCG sysemu. Signed-off-by: Philippe Mathieu-Daudé --- target/microblaze/cpu.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/target/microblaze/cpu.c b/target/microblaze/cpu.c index 15db277

Re: [PATCH v3 17/30] target/mips: Restrict has_work() handler to sysemu and TCG

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: Restrict has_work() to TCG sysemu. Signed-off-by: Philippe Mathieu-Daudé --- target/mips/cpu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Reviewed-by: Richard Henderson r~

Re: [PATCH v3 18/30] target/nios2: Restrict has_work() handler to sysemu and TCG

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: Restrict has_work() to TCG sysemu. Signed-off-by: Philippe Mathieu-Daudé --- target/nios2/cpu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/target/nios2/cpu.c b/target/nios2/cpu.c index 947bb09bc1e..f1f976bdad7 10064

Re: [PATCH v3 19/30] target/openrisc: Restrict has_work() handler to sysemu and TCG

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: Restrict has_work() to TCG sysemu. Signed-off-by: Philippe Mathieu-Daudé --- target/openrisc/cpu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/target/openrisc/cpu.c b/target/openrisc/cpu.c index 27cb04152f9..6544b549

Re: [PATCH v3 08/30] target/alpha: Restrict has_work() handler to sysemu and TCG

On 9/3/21 10:18 PM, Richard Henderson wrote: > On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: >> Restrict has_work() to TCG sysemu. >> >> Signed-off-by: Philippe Mathieu-Daudé >> --- >>   target/alpha/cpu.c | 4 +++- >>   1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/target/al

Re: [PATCH v3 21/30] target/ppc: Introduce PowerPCCPUClass::has_work()

On 9/3/21 2:50 AM, David Gibson wrote: > On Thu, Sep 02, 2021 at 06:15:34PM +0200, Philippe Mathieu-Daudé wrote: >> Each POWER cpu has its own has_work() implementation. Instead of >> overloading CPUClass on each PowerPCCPUClass init, register the >> generic ppc_cpu_has_work() handler, and have it

Re: [PATCH v3 08/30] target/alpha: Restrict has_work() handler to sysemu and TCG

On 9/3/21 10:34 PM, Philippe Mathieu-Daudé wrote: Drop CONFIG_TCG for alpha; it's always true. What is the rational? "Old" architectures (with no active / official hw development) are unlikely to add hardware acceleration, so TCG is the single one possible? Thus no need to clutter the code with

Re: [PATCH v3 21/30] target/ppc: Introduce PowerPCCPUClass::has_work()

On 9/3/21 2:50 AM, David Gibson wrote: On Thu, Sep 02, 2021 at 06:15:34PM +0200, Philippe Mathieu-Daudé wrote: Each POWER cpu has its own has_work() implementation. Instead of overloading CPUClass on each PowerPCCPUClass init, register the generic ppc_cpu_has_work() handler, and have it call the

Re: [PATCH v3 22/30] target/ppc: Simplify has_work() handlers

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: The common ppc_cpu_has_work() handler already checks for cs->halted, so we can simplify all callees. Signed-off-by: Philippe Mathieu-Daudé --- target/ppc/cpu_init.c | 294 -- 1 file changed, 138 insertion

Re: [PATCH v3 23/30] target/riscv: Restrict has_work() handler to sysemu and TCG

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: Restrict has_work() to TCG sysemu. Signed-off-by: Philippe Mathieu-Daudé --- target/riscv/cpu.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) Reviewed-by: Richard Henderson r~

Re: [PATCH v3 20/30] target/ppc: Restrict has_work() handler to sysemu and TCG

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: Restrict has_work() to TCG sysemu. Signed-off-by: Philippe Mathieu-Daudé --- target/ppc/cpu_init.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Reviewed-by: Richard Henderson r~

Re: [PATCH v3 24/30] target/rx: Restrict has_work() handler to sysemu and TCG

On 9/2/21 6:15 PM, Philippe Mathieu-Daudé wrote: Restrict has_work() to TCG sysemu. Signed-off-by: Philippe Mathieu-Daudé --- target/rx/cpu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/target/rx/cpu.c b/target/rx/cpu.c index 25a4aa2976d..0d0cf6f9028 100644 --- a/t

Re: [PATCH v3 30/30] accel: Add missing AccelOpsClass::has_work() and drop SysemuCPUOps one

On 9/3/21 8:19 PM, Philippe Mathieu-Daudé wrote: cpu_common_has_work() is the default has_work() implementation and returns 'false'. Explicit it for the QTest / HAX / HVF / NVMM / Xen accelerators and remove cpu_common_has_work(). Since there are no more implementations of SysemuCPUOps::has_wor

Re: [PATCH v3 21/30] target/ppc: Introduce PowerPCCPUClass::has_work()

On 9/3/21 10:42 PM, Richard Henderson wrote: > On 9/3/21 2:50 AM, David Gibson wrote: >> On Thu, Sep 02, 2021 at 06:15:34PM +0200, Philippe Mathieu-Daudé wrote: >>> Each POWER cpu has its own has_work() implementation. Instead of >>> overloading CPUClass on each PowerPCCPUClass init, register the >

[linux-5.4 test] 164793: tolerable FAIL - PUSHED

flight 164793 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/164793/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 164501 test-amd64-amd64-xl-qemuu-win7-amd64 19

Re: [PATCH v3 3/7] xen/arm: Rename cpu_boot_data to system_cpuinfo

On Wed, 25 Aug 2021, Bertrand Marquis wrote: > As we will sanitize the content of boot_cpu_data it will not really > contain the boot cpu information but the system sanitize information. > Rename the structure to system_cpuinfo so the user is informed that this > is the system wide available featur

Re: [PATCH v3 2/7] xen/arm: Import ID features sanitize from linux

On Wed, 25 Aug 2021, Bertrand Marquis wrote: > Import structures declared in Linux file arch/arm64/kernel/cpufeature.c > and the required types from arch/arm64/include/asm/cpufeature.h. > > Current code has been imported from Linux 5.13-rc5 (Commit ID > cd1245d75ce93b8fd206f4b34eb58bcfe156d5e9) an

Re: [PATCH v3 4/7] xen/arm: Sanitize cpuinfo ID registers fields

On Wed, 25 Aug 2021, Bertrand Marquis wrote: > Define a sanitize_cpu function to be called on secondary cores to > sanitize the system cpuinfo structure. > > The safest value is taken when possible and the system is marked tainted > if we encounter values which are incompatible with each other. >

Re: [PATCH v3 5/7] xen/arm: Use sanitize values for p2m

On Wed, 25 Aug 2021, Bertrand Marquis wrote: > Replace the code in p2m trying to find a sane value for the VMID size > supported and the PAR to use. We are now using the boot cpuinfo as the > values there are sanitized during boot and the value for those > parameters is now the safest possible valu

Re: [PATCH v3 6/7] xen/arm: Taint Xen on incompatible DCZID values

On Wed, 25 Aug 2021, Bertrand Marquis wrote: > Use arm64 cpu feature sanitization to TAIN Xen if different DCZID values ^ TAINT > are found (ftr_dczid is using only STRICT method). > In this case actual memory being cleaned by DC ZVA operations would be >

Re: [PATCH v3 7/7] xen/arm: Sanitize CTR_EL0 and emulate it if needed

On Tue, 31 Aug 2021, Bertrand Marquis wrote: > Hi Julien, > > > On 31 Aug 2021, at 15:47, Julien Grall wrote: > > > > > > > > On 31/08/2021 14:17, Bertrand Marquis wrote: > >> Hi Julien, > > > > Hi Bertrand, > > > >>> On 27 Aug 2021, at 16:05, Julien Grall wrote: > >>> > >>> Hi Bertrand, >

[linux-linus test] 164797: regressions - FAIL

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

[ovmf test] 164800: regressions - FAIL

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

[ovmf test] 164802: regressions - FAIL

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

  1   2   >