similar to: [PATCH v3] arm: support fewer LR registers than virtual irqs

During context switch is_running is set for the next vcpu before the gic state is actually saved. This leads to possible nasty races when interrupts need to be injected after is_running is set to the next vcpu but before the currently running gic state has been saved from the previous vcpu. Use current instead of is_running to check which one is the currently running vcpu: set_current is called

Print some useful GIC debug information when arch_dump_domain_info is called (''q'' debug key). Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- xen/arch/arm/domain.c | 6 ++++++ xen/arch/arm/gic.c | 27 +++++++++++++++++++++++++++ xen/include/asm-arm/gic.h | 3 +++ 3 files changed, 36 insertions(+), 0 deletions(-) diff --git

We need to write the irq number to GICC_DIR on the physical cpu that previously received the interrupt, but currently we are doing it on the pcpu that received the maintenance interrupt. As a consequence if a vcpu is migrated to a different pcpu, the irq is going to be EOI''ed on the wrong pcpu. This covers the case where dom0 vcpu0 is running on pcpu1 for example (you can test this

Hi all, this small patch series implement guest SMP support for ARM, using the ARM PSCI interface for secondary cpu bringup. Stefano Stabellini (4): xen/arm: basic PSCI support, implement cpu_on xen/arm: support for guest SGI xen/arm: support vcpu_op hypercalls xen: move VCPUOP_register_vcpu_info to common code xen/arch/arm/domain.c | 66 ++++++++++++++++++++++++

Hello everyone, this is the fourth version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See

Hello everyone, this is the very first version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See

George has release acked all of these. Otherwise mostly minor updates this time around. Summary: A == acked, M == modified A xen: arm64: Add 8250 earlyprintk support A xen: arm64: Add Basic Platform support for APM X-Gene Storm. A xen: arm64: Add APM implementor id to processor implementers. M xen: arm: add a quirk to handle platforms with unusual GIC layout A xen: arm: allow platform

This patch series implements SMP boot for arch/arm, as far as getting all CPUs up and running the idle loop. Changes from v1: - moved barriers out of loop in udelay() - dropped broken GIC change in favour of explanatory comment - made the increment of ready_cpus atomic (I couldn''t move the increment to before signalling the next CPU because the PT switch has to happen between

(moving to xen-devel, xen-arm is for the older PV ARM port) On Tue, 2013-06-25 at 23:59 +0000, Eric Trudeau wrote: > Hi, I am trying to build the XEN tools for our port of XEN to our > Cortex A15-based platform. > > I am using the repo at git://xenbits.xenproject.org/xen.git to > cross-compile the tools into our rootfs. Which branch/changeset are you using? I've heard that

Check for: - uninitialized GIC interface addresses; - non-page aligned GIC interface addresses. Panic in both cases. Also remove the code from GICH and GICC to handle non-page aligned interfaces. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index 8efbeb3..2b29e7e 100644 --- a/xen/arch/arm/gic.c +++

Hello, While I was doing some tests in Arndale board, the network (iperf) throughput suddenly decreases to 5Mbps (from 100Mbps) out of nowhere. This typically happens when I generate traffic using iperf (100Mbps) while installing some packages using apt-get in dom0. Whenever this behavior happens, I can not see any distinguishable logs from any places. After some debugging, I found that

>------- Original Message ------- >Sender : Julien Grall<julien.grall@linaro.org> >Date : 2013-10-07 21:49 (GMT+09:00) >Title : Re: [Xen-devel] [PATCH v4 1/9] xen/arm: Implement hvm save and restore > >On 10/04/2013 05:43 AM, Jaeyong Yoo wrote: >> Implement save/restore of hvm context hypercall. In hvm >> context save/restore, we save gic, timer and vfp

Biggest change is to switch the new DTB node to /xen-core-devices instead of /xen at Stefano''s request. I also dropped the few patches title HACK etc which weren''t supposed to be there and fixed up some bits and pieces which folks commented on. George, WRT the freeze I think this is functionality which we cannot ship Xen 4.4 without. The impact is entirely constrained to the

> From: Jean-Philippe Brucker [mailto:jean-philippe.brucker at arm.com] > Sent: Wednesday, February 14, 2018 10:54 PM > > The virtio IOMMU is a para-virtualized device, allowing to send IOMMU > requests such as map/unmap over virtio-mmio transport without > emulating > page tables. This implementation handles ATTACH, DETACH, MAP and > UNMAP > requests. > > The

> From: Jean-Philippe Brucker [mailto:jean-philippe.brucker at arm.com] > Sent: Wednesday, February 14, 2018 10:54 PM > > The virtio IOMMU is a para-virtualized device, allowing to send IOMMU > requests such as map/unmap over virtio-mmio transport without > emulating > page tables. This implementation handles ATTACH, DETACH, MAP and > UNMAP > requests. > > The

Hi Kevin, Thanks for the comments On 19/03/18 10:03, Tian, Kevin wrote: > BYPASS feature bit is not covered in "2.3.1/2.3.2/2.3.3"". Is it > intended? In my opinion BYPASS is a bit different from the other features: while the others are needed for correctness, this one is optional and even if the guest supports BYPASS, it should be allowed not to accept it. For security

Hi Kevin, Thanks for the comments On 19/03/18 10:03, Tian, Kevin wrote: > BYPASS feature bit is not covered in "2.3.1/2.3.2/2.3.3"". Is it > intended? In my opinion BYPASS is a bit different from the other features: while the others are needed for correctness, this one is optional and even if the guest supports BYPASS, it should be allowed not to accept it. For security

Hi, This is the fifth version of this patch series. With the Versatile Express TC2, it''s possible to boot only with A7 or A15. If the user choose to boot with only A7, the CPU ID will start at 0x100. As Xen relies on it to set the logical ID and the GIC, it won''t be possible to use Xen with this use case. This patch series is divided in 3 parts: - Patch 1: prepare Xen

Trap guest WFI, block the guest VCPU unless it has pending interrupts. Awake the guest vcpu when a new interrupt for it arrrives. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- xen/arch/arm/domain_build.c | 2 +- xen/arch/arm/traps.c | 6 ++++++ xen/arch/arm/vgic.c | 4 +++- 3 files changed, 10 insertions(+), 2 deletions(-) diff --git

I''ve addressed all (I think/hope) of the review comments. The main change is to expose the guest virtual platform (e.g. memory layout and interrupt usage etc) to the toolstack via the public interface. This is then used during FDT generation. I have just codified the current defacto standard layout, it''s probably not the best layout but any change can be a separate patch/series.