[Xen-devel] [linux-arm-xen test] 107256: trouble: broken/pass

flight 107256 linux-arm-xen real [real] http://logs.test-lab.xenproject.org/osstest/logs/107256/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 2 hosts-allocate broken REGR. vs. 1071

[Xen-devel] [xen-4.8-testing test] 107259: trouble: blocked/broken/fail/pass

flight 107259 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/107259/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 2 hosts-allocate broken REGR. vs. 10

[Xen-devel] [xen-unstable baseline-only test] 71163: regressions - trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 71163 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71163/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-build

[Xen-devel] [xen-unstable-smoke test] 107287: tolerable trouble: broken/fail/pass - PUSHED

flight 107287 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/107287/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 5 ker

[Xen-devel] [xen-unstable-smoke test] 107281: tolerable trouble: broken/fail/pass - PUSHED

flight 107281 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/107281/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 5 ker

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

flight 107253 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/107253/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 11 guest-start fail REGR. vs. 59254 test-armhf-armhf-xl

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

On Fri, 7 Apr 2017, Volodymyr Babchuk wrote: > >> Native application is an another domain type. It has own vCPU (only one at > >> this > >> moment) Native app is loaded as any other kernel, using ELF loader. > >> It looks like another stub-domain such as MiniOS, but there are two big > >> differen

Re: [Xen-devel] [PATCH v6 21/36] ARM: GICv3: prepare for virtual ITS subnodes

On 08/04/17 00:12, Julien Grall wrote: > > > On 08/04/2017 00:06, André Przywara wrote: >> On 07/04/17 23:59, Julien Grall wrote: >>> Hi Andre, >>> >>> On 07/04/2017 18:32, Andre Przywara wrote: When creating the device tree for a domain using an emulated GICv3, we will later need to ad

Re: [Xen-devel] [PATCH v4 00/19] Provide a command line option to choose how to handle SErrors

Done. I have also made the backports to the stable trees. On Fri, 7 Apr 2017, Julien Grall wrote: > Hi, > > I just noticed that commit b32d442abd "setup vwfi correctly on cpu0" has not > been revered as asked by Stefano (see [1]). > > Stefano, can you revert it? > > Cheers, > > [1] https://lis

Re: [Xen-devel] [PATCH v6 21/36] ARM: GICv3: prepare for virtual ITS subnodes

On 08/04/2017 00:06, André Przywara wrote: On 07/04/17 23:59, Julien Grall wrote: Hi Andre, On 07/04/2017 18:32, Andre Przywara wrote: When creating the device tree for a domain using an emulated GICv3, we will later need to add the respective ITS subnodes as well. Prepare a stub function to

Re: [Xen-devel] [PATCH v7 00/34] arm64: Dom0 ITS emulation

Hi, Andre mentioned this was only slightly modified. So I am going to continue to comment on v6 to keep all comments in same version making easier to track. I would encourage Stefano to do the same. Cheers, -- Julien Grall ___ Xen-devel mailing l

Re: [Xen-devel] [PATCH v6 21/36] ARM: GICv3: prepare for virtual ITS subnodes

On 07/04/17 23:59, Julien Grall wrote: > Hi Andre, > > On 07/04/2017 18:32, Andre Przywara wrote: >> When creating the device tree for a domain using an emulated GICv3, >> we will later need to add the respective ITS subnodes as well. >> Prepare a stub function to be later filled with the actual c

Re: [Xen-devel] [PATCH v6 21/36] ARM: GICv3: prepare for virtual ITS subnodes

Hi Andre, On 07/04/2017 18:32, Andre Przywara wrote: When creating the device tree for a domain using an emulated GICv3, we will later need to add the respective ITS subnodes as well. Prepare a stub function to be later filled with the actual code. make_hwdom_dt_node will only create DT node f

Re: [Xen-devel] [PATCH v6 19/36] ARM: VGIC: add vcpu_id to struct pending_irq

Hi Stefano, On 07/04/2017 23:31, Stefano Stabellini wrote: On Fri, 7 Apr 2017, Julien Grall wrote: Hi Stefano, On 04/07/2017 11:14 PM, Stefano Stabellini wrote: On Fri, 7 Apr 2017, Julien Grall wrote: Hi Andre, On 04/07/2017 06:32 PM, Andre Przywara wrote: The target CPU for an LPI is enco

Re: [Xen-devel] Outreachy project - Xen Code Review Dashboard

Hi Jesus, Thanks for your reply! So about the task, instructions say after analyzing mboxes with Perceval to "store the resulting raw index in ElasticSearch" - what does raw index mean? In terms of figuring out the elasticsearch structure, do I want an index (xen-devel mbox) with a type (message)

Re: [Xen-devel] [PATCH v6 19/36] ARM: VGIC: add vcpu_id to struct pending_irq

On Fri, 7 Apr 2017, Julien Grall wrote: > Hi Stefano, > > On 04/07/2017 11:14 PM, Stefano Stabellini wrote: > > On Fri, 7 Apr 2017, Julien Grall wrote: > > > Hi Andre, > > > > > > On 04/07/2017 06:32 PM, Andre Przywara wrote: > > > > The target CPU for an LPI is encoded in the interrupt translati

Re: [Xen-devel] Code freeze exception for Xen 4.9 ARM ITS emulation?

On Fri, 7 Apr 2017, Andre Przywara wrote: > Hello! > > The development of the ARM ITS emulation support has taken more time > than anticipated and I won't be able to address and fix all outstanding > comments until the official code freeze date. > > However the first part of the series is in a go

Re: [Xen-devel] [PATCH v7 00/34] arm64: Dom0 ITS emulation

Thanks Andre, I have applied patches 1-9. On Fri, 7 Apr 2017, Andre Przywara wrote: > Hi, > > an only slightly modified repost of the last version. > I added the Reviewed-by: and Acked-by: tags from Stefano and Julien > and rebased on top of the latest staging tree: > commit 89216c7999eb5b8558bfa

Re: [Xen-devel] [PATCH v6 19/36] ARM: VGIC: add vcpu_id to struct pending_irq

Hi Stefano, On 04/07/2017 11:14 PM, Stefano Stabellini wrote: On Fri, 7 Apr 2017, Julien Grall wrote: Hi Andre, On 04/07/2017 06:32 PM, Andre Przywara wrote: The target CPU for an LPI is encoded in the interrupt translation table entry, so can't be easily derived from just an LPI number (shor

Re: [Xen-devel] [PATCH v6 19/36] ARM: VGIC: add vcpu_id to struct pending_irq

On Fri, 7 Apr 2017, Julien Grall wrote: > Hi Andre, > > On 04/07/2017 06:32 PM, Andre Przywara wrote: > > The target CPU for an LPI is encoded in the interrupt translation table > > entry, so can't be easily derived from just an LPI number (short of > > walking *all* tables and find the matching L

Re: [Xen-devel] [PATCH v6 10/36] ARM: GIC: Add checks for NULL pointer pending_irq's

On 07/04/17 23:09, Stefano Stabellini wrote: > On Fri, 7 Apr 2017, Stefano Stabellini wrote: >> On Fri, 7 Apr 2017, Julien Grall wrote: >>> Hi Andre, >>> >>> On 04/07/2017 09:46 PM, André Przywara wrote: On 07/04/17 20:07, Stefano Stabellini wrote: > On Fri, 7 Apr 2017, Andre Przywara wrot

Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

On Fri, 7 Apr 2017, Boris Ostrovsky wrote: > On 04/07/2017 01:36 PM, Stefano Stabellini wrote: > > On Fri, 7 Apr 2017, Boris Ostrovsky wrote: > >> On 04/07/2017 07:58 AM, Ian Jackson wrote: > >>> tl;dr: > >>> Please apply > >>> > >>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1 > >>> partially

Re: [Xen-devel] [PATCH v6 19/36] ARM: VGIC: add vcpu_id to struct pending_irq

Hi Andre, On 04/07/2017 06:32 PM, Andre Przywara wrote: The target CPU for an LPI is encoded in the interrupt translation table entry, so can't be easily derived from just an LPI number (short of walking *all* tables and find the matching LPI). To avoid this in case we need to know the VCPU (for

[Xen-devel] [PATCH v7 21/34] ARM: vGIC: advertise LPI support

To let a guest know about the availability of virtual LPIs, set the respective bits in the virtual GIC registers and let a guest control the LPI enable bit. Only report the LPI capability if the host has initialized at least one ITS. This removes a "TBD" comment, as we now populate the processor nu

[Xen-devel] [PATCH v7 13/34] ARM: GICv3: enable ITS and LPIs on the host

Now that the host part of the ITS code is in place, we can enable the ITS and also LPIs on each redistributor to get the show rolling. At this point there would be no LPIs mapped, as guests don't know about the ITS yet. Signed-off-by: Andre Przywara Acked-by: Stefano Stabellini --- xen/arch/arm

[Xen-devel] [PATCH v7 03/34] ARM: GICv3: allocate LPI pending and property table

The ARM GICv3 provides a new kind of interrupt called LPIs. The pending bits and the configuration data (priority, enable bits) for those LPIs are stored in tables in normal memory, which software has to provide to the hardware. Allocate the required memory, initialize it and hand it over to each r

[Xen-devel] [PATCH v7 24/34] ARM: vITS: handle CLEAR command

This introduces the ITS command handler for the CLEAR command, which clears the pending state of an LPI. This removes a not-yet injected, but already queued IRQ from a VCPU. As read_itte() is now eventually used, we add the static keyword. Signed-off-by: Andre Przywara --- xen/arch/arm/vgic-v3-i

[Xen-devel] [PATCH v7 16/34] ARM: vGICv3: re-use vgic_reg64_check_access

vgic_reg64_check_access() checks for a valid access width of a 64-bit MMIO register, which is useful beyond the current GICv3 emulation only. Move this function to the vgic-emul.h to be easily reusable. Signed-off-by: Andre Przywara --- xen/arch/arm/vgic-v3.c | 9 - xen/include/

[Xen-devel] [PATCH v7 28/34] ARM: vITS: handle MAPTI command

The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU pair and actually instantiates LPI interrupts. We connect the already allocated host LPI to this virtual LPI, so that any triggering LPI on the host can be quickly forwarded to a guest. Beside entering the VCPU and the virtual LPI

[Xen-devel] [PATCH v7 19/34] ARM: vGICv3: add virtual ITS list head and comment about iteration

To prepare for virtual ITS support, add a list head to struct domain's vgic fields to be later able to walk over all instantiated virtual ITSes. Also add a comment explaining what to expect from vgic_v3_its_init_domain(). Signed-off-by: Andre Przywara --- xen/arch/arm/vgic-v3.c | 4 x

[Xen-devel] [PATCH v7 30/34] ARM: vITS: handle DISCARD command

The DISCARD command drops the connection between a DeviceID/EventID and an LPI/collection pair. We mark the respective structure entries as not allocated and make sure that any queued IRQs are removed. Signed-off-by: Andre Przywara --- xen/arch/arm/vgic-v3-its.c | 36

[Xen-devel] [PATCH v7 33/34] ARM: vITS: create and initialize virtual ITSes for Dom0

For each hardware ITS create and initialize a virtual ITS for Dom0. We use the same memory mapped address to keep the doorbell working. This introduces a function to initialize a virtual ITS. We maintain a list of virtual ITSes, at the moment for the only purpose of later being able to free them ag

[Xen-devel] [PATCH v7 07/34] ARM: GICv3 ITS: introduce host LPI array

The number of LPIs on a host can be potentially huge (millions), although in practise will be mostly reasonable. So prematurely allocating an array of struct irq_desc's for each LPI is not an option. However Xen itself does not care about LPIs, as every LPI will be injected into a guest (Dom0 for n

[Xen-devel] [PATCH v7 27/34] ARM: vITS: handle MAPD command

The MAPD command maps a device by associating a memory region for storing ITEs with a certain device ID. We store the given guest physical address in the device table, and, if this command comes from Dom0, tell the host ITS driver about this new mapping, so it can issue the corresponding host MAPD

[Xen-devel] [PATCH v7 25/34] ARM: vITS: handle INT command

The INT command sets a given LPI identified by a DeviceID/EventID pair as pending and thus triggers it to be injected. Signed-off-by: Andre Przywara --- xen/arch/arm/vgic-v3-its.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/a

[Xen-devel] [PATCH v7 20/34] ARM: GICv3: prepare for virtual ITS subnodes

When creating the device tree for a domain using an emulated GICv3, we will later need to add the respective ITS subnodes as well. Prepare a stub function to be later filled with the actual code. Signed-off-by: Andre Przywara --- xen/arch/arm/gic-v3.c| 4 +++- xen/include/asm-arm/gic

[Xen-devel] [PATCH v7 34/34] ARM: vITS: create ITS subnodes for Dom0 DT

Dom0 expects all ITSes in the system to be propagated to be able to use MSIs. Create Dom0 DT nodes for each hardware ITS, keeping the register frame address the same, as the doorbell address that the Dom0 drivers program into the BARs has to match the hardware. Signed-off-by: Andre Przywara ---

[Xen-devel] [PATCH v7 31/34] ARM: vITS: handle INV command

The INV command instructs the ITS to update the configuration data for a given LPI by re-reading its entry from the property table. We don't need to care so much about the priority value, but enabling or disabling an LPI has some effect: We remove or push virtual LPIs to their VCPUs, also check the

[Xen-devel] [PATCH v7 22/34] ARM: vITS: add command handling stub and MMIO emulation

Emulate the memory mapped ITS registers and provide a stub to introduce the ITS command handling framework (but without actually emulating any commands at this time). Signed-off-by: Andre Przywara --- xen/arch/arm/vgic-v3-its.c | 512 +++ xen/include/asm

[Xen-devel] [PATCH v7 15/34] ARM: introduce vgic_access_guest_memory()

From: Vijaya Kumar K This function allows to copy a chunk of data from and to guest physical memory. It looks up the associated page from the guest's p2m tree and maps this page temporarily for the time of the access. This function was originally written by Vijaya as part of an earlier series: ht

[Xen-devel] [PATCH v7 26/34] ARM: vITS: handle MAPC command

The MAPC command associates a given collection ID with a given redistributor, thus mapping collections to VCPUs. We just store the vcpu_id in the collection table for that. Signed-off-by: Andre Przywara --- xen/arch/arm/vgic-v3-its.c | 41 + 1 file changed

[Xen-devel] [PATCH v7 18/34] ARM: VGIC: add vcpu_id to struct pending_irq

The target CPU for an LPI is encoded in the interrupt translation table entry, so can't be easily derived from just an LPI number (short of walking *all* tables and find the matching LPI). To avoid this in case we need to know the VCPU (for the INVALL command, for instance), put the VCPU ID in the

[Xen-devel] [PATCH v7 29/34] ARM: vITS: handle MOVI command

The MOVI command moves the interrupt affinity from one redistributor (read: VCPU) to another. For now migration of "live" LPIs is not yet implemented, but we store the changed affinity in the host LPI structure and in our virtual ITTE. Signed-off-by: Andre Przywara --- xen/arch/arm/gic-v3-its.c

[Xen-devel] [PATCH v7 23/34] ARM: vITS: introduce translation table walks

The ITS stores the target (v)CPU and the (virtual) LPI number in tables. Introduce functions to walk those tables and translate an device ID - event ID pair into a pair of virtual LPI and vCPU. We map those tables on demand - which is cheap on arm64 - and copy the respective entries before using th

[Xen-devel] [PATCH v7 32/34] ARM: vITS: handle INVALL command

The INVALL command instructs an ITS to invalidate the configuration data for all LPIs associated with a given redistributor (read: VCPU). This is nasty to emulate exactly with our architecture, so we just iterate over all mapped LPIs and filter for those from that particular VCPU. Signed-off-by: A

[Xen-devel] [PATCH v7 17/34] ARM: GIC: export vgic_init_pending_irq()

For LPIs we later want to dynamically allocate struct pending_irqs. Let's export the vgic_init_pending_irq() to be able to reuse it. Signed-off-by: Andre Przywara --- xen/arch/arm/vgic.c| 2 +- xen/include/asm-arm/vgic.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git

[Xen-devel] [PATCH v7 00/34] arm64: Dom0 ITS emulation

Hi, an only slightly modified repost of the last version. I added the Reviewed-by: and Acked-by: tags from Stefano and Julien and rebased on top of the latest staging tree: commit 89216c7999eb5b8558bfac7d61ae0d5ab844ce3f Author: Dario Faggioli Date: Fri Apr 7 18:57:14 2017 +0200 xen: credi

[Xen-devel] [PATCH v7 09/34] ARM: GICv3 ITS: introduce device mapping

The ITS uses device IDs to map LPIs to a device. Dom0 will later use those IDs, which we directly pass on to the host. For this we have to map each device that Dom0 may request to a host ITS device with the same identifier. Allocate the respective memory and enter each device into an rbtree to late

[Xen-devel] [PATCH v7 05/34] ARM: GICv3 ITS: map ITS command buffer

Instead of directly manipulating the tables in memory, an ITS driver sends commands via a ring buffer in normal system memory to the ITS h/w to create or alter the LPI mappings. Allocate memory for that buffer and tell the ITS about it to be able to send ITS commands. Signed-off-by: Andre Przywara

Re: [Xen-devel] [PATCH v6 10/36] ARM: GIC: Add checks for NULL pointer pending_irq's

On Fri, 7 Apr 2017, Stefano Stabellini wrote: > On Fri, 7 Apr 2017, Julien Grall wrote: > > Hi Andre, > > > > On 04/07/2017 09:46 PM, André Przywara wrote: > > > On 07/04/17 20:07, Stefano Stabellini wrote: > > > > On Fri, 7 Apr 2017, Andre Przywara wrote: > > > > > For LPIs the struct pending_irq

[Xen-devel] [PATCH v7 14/34] ARM: vGICv3: handle virtual LPI pending and property tables

Allow a guest to provide the address and size for the memory regions it has reserved for the GICv3 pending and property tables. We sanitise the various fields of the respective redistributor registers. The MMIO read and write accesses are protected by locks, to avoid any changing of the property or

[Xen-devel] [PATCH v7 04/34] ARM: GICv3 ITS: allocate device and collection table

Each ITS maps a pair of a DeviceID (for instance derived from a PCI b/d/f triplet) and an EventID (the MSI payload or interrupt ID) to a pair of LPI number and collection ID, which points to the target CPU. This mapping is stored in the device and collection tables, which software has to provide fo

[Xen-devel] [PATCH v7 12/34] ARM: GICv3: forward pending LPIs to guests

Upon receiving an LPI on the host, we need to find the right VCPU and virtual IRQ number to get this IRQ injected. Iterate our two-level LPI table to find this information quickly when the host takes an LPI. Call the existing injection function to let the GIC emulation deal with this interrupt. Als

[Xen-devel] [PATCH v7 06/34] ARM: GICv3 ITS: introduce ITS command handling

To be able to easily send commands to the ITS, create the respective wrapper functions, which take care of the ring buffer. The first two commands we implement provide methods to map a collection to a redistributor (aka host core) and to flush the command queue (SYNC). Start using these commands fo

[Xen-devel] [PATCH v7 11/34] ARM: GICv3: introduce separate pending_irq structs for LPIs

For the same reason that allocating a struct irq_desc for each possible LPI is not an option, having a struct pending_irq for each LPI is also not feasible. We only care about mapped LPIs, so we can get away with having struct pending_irq's only for them. Maintain a radix tree per domain where we d

[Xen-devel] [PATCH v7 02/34] ARM: GICv3 ITS: initialize host ITS

Map the registers frame for each host ITS and populate the host ITS structure with some parameters describing the size of certain properties like the number of bits for device IDs. Signed-off-by: Andre Przywara Reviewed-by: Julien Grall Reviewed-by: Stefano Stabellini --- xen/arch/arm/gic-v3-i

[Xen-devel] [PATCH v7 10/34] ARM: GIC: Add checks for NULL pointer pending_irq's

For LPIs the struct pending_irq's are somewhat dynamically allocated and the pointers are stored in a radix tree. While I convinced myself that an invalid LPI number can't make it into the core code, people might be concerned about NULL pointer dereferences. So add checks in some places just to be

[Xen-devel] [PATCH v7 08/34] ARM: vGICv3: introduce ITS emulation stub

Create a new file to hold the emulation code for the ITS widget. This just holds the data structure and a init and free function for now. Signed-off-by: Andre Przywara Acked-by: Julien Grall Acked-by: Stefano Stabellini --- xen/arch/arm/Makefile| 1 + xen/arch/arm/vgic-v3-its.c

[Xen-devel] [PATCH v7 01/34] ARM: GICv3 ITS: parse and store ITS subnodes from hardware DT

Parse the GIC subnodes in the device tree to find every ITS MSI controller the hardware offers. Store that information in a list to both propagate all of them later to Dom0, but also to be able to iterate over all ITSes. This introduces an ITS Kconfig option (as an EXPERT option), use XEN_CONFIG_EX

Re: [Xen-devel] [PATCH v6 10/36] ARM: GIC: Add checks for NULL pointer pending_irq's

On Fri, 7 Apr 2017, Julien Grall wrote: > Hi Andre, > > On 04/07/2017 09:46 PM, André Przywara wrote: > > On 07/04/17 20:07, Stefano Stabellini wrote: > > > On Fri, 7 Apr 2017, Andre Przywara wrote: > > > > For LPIs the struct pending_irq's are somewhat dynamically allocated and > > > > the pointe

Re: [Xen-devel] [PATCH v6 15/36] ARM: introduce vgic_access_guest_memory()

Hi Andre, On 04/07/2017 06:32 PM, Andre Przywara wrote: This function allows to copy a chunk of data from and to guest physical memory. It looks up the associated page from the guest's p2m tree and maps this page temporarily for the time of the access. This function was originally written by Vij

Re: [Xen-devel] [PATCH v6 14/36] ARM: vGICv3: handle virtual LPI pending and property tables

Hi Andre, On 04/07/2017 06:32 PM, Andre Przywara wrote: diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h index 583d491..365a4ef 100644 --- a/xen/include/asm-arm/domain.h +++ b/xen/include/asm-arm/domain.h @@ -109,10 +109,14 @@ struct arch_domain } *rdist_regions;

Re: [Xen-devel] [PATCH v6 12/36] ARM: GICv3: forward pending LPIs to guests

Hi Andre, On 04/07/2017 06:32 PM, Andre Przywara wrote: diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c index 292f2d0..5f3fe2c 100644 --- a/xen/arch/arm/gic-v3-lpi.c +++ b/xen/arch/arm/gic-v3-lpi.c @@ -136,6 +136,62 @@ uint64_t gicv3_get_redist_address(unsigned int cpu, bool

Re: [Xen-devel] [PATCH v6 11/36] ARM: GICv3: introduce separate pending_irq structs for LPIs

Hi Stefano, On 04/07/2017 07:49 PM, Stefano Stabellini wrote: On Fri, 7 Apr 2017, Andre Przywara wrote: For the same reason that allocating a struct irq_desc for each possible LPI is not an option, having a struct pending_irq for each LPI is also not feasible. We only care about mapped LPIs, so

Re: [Xen-devel] [PATCH v6 10/36] ARM: GIC: Add checks for NULL pointer pending_irq's

Hi Andre, On 04/07/2017 09:46 PM, André Przywara wrote: On 07/04/17 20:07, Stefano Stabellini wrote: On Fri, 7 Apr 2017, Andre Przywara wrote: For LPIs the struct pending_irq's are somewhat dynamically allocated and the pointers are stored in a radix tree. While I convinced myself that an inva

Re: [Xen-devel] [PATCH v6 10/36] ARM: GIC: Add checks for NULL pointer pending_irq's

On 07/04/17 20:07, Stefano Stabellini wrote: > On Fri, 7 Apr 2017, Andre Przywara wrote: >> For LPIs the struct pending_irq's are somewhat dynamically allocated and >> the pointers are stored in a radix tree. While I convinced myself that >> an invalid LPI number can't make it into the core code, p

[Xen-devel] [xen-unstable-smoke test] 107276: tolerable trouble: broken/fail/pass - PUSHED

flight 107276 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/107276/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 5 ker

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

flight 107250 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/107250/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 107219 test-amd64-i386-x

[Xen-devel] [PATCH v5 for-4.9 4/4] dmop: Add xendevicemodel_modified_memory_bulk()

From: Jennifer Herbert This new lib devicemodel call allows multiple extents of pages to be marked as modified in a single call. This is something needed for a usecase I'm working on. The xen side of the modified_memory call has been modified to accept an array of extents. The devicemodle libr

[Xen-devel] [PATCH v5 for-4.9 2/4] hvm/dmop: Implement copy_{to, from}_guest_buf() in terms of raw accessors

This allows the usual cases to be simplified, by omitting an unnecessary buf parameters, and because the macros can appropriately size the object. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Paul Durrant CC: Julien Grall --- xen/arch/x86/hvm/dm.c | 47 +---

[Xen-devel] [PATCH v5 for-4.9 3/4] hvm/dmop: Implement copy_{to, from}_guest_buf_offset() helpers

copy_{to,from}_guest_buf() are now implemented using an offset of 0. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Paul Durrant CC: Julien Grall --- xen/arch/x86/hvm/dm.c | 34 -- 1 file changed, 24 insertions(+), 10 deletions(-) diff --git a/xen/arch/x

[Xen-devel] [PATCH v5 for-4.9 1/4] hvm/dmop: Box dmop_bufs rather than passing two parameters around

From: Jennifer Herbert No functional change. Signed-off-by: Jennifer Herbert Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Paul Durrant CC: Julien Grall --- xen/arch/x86/hvm/dm.c | 49 +++-- 1 file changed, 31 insertions(+), 18 deletions(-

Re: [Xen-devel] [PATCH v6 09/36] ARM: GICv3 ITS: introduce device mapping

Hi, On 07/04/17 19:21, Stefano Stabellini wrote: >> +/* >> + * Allocate the pending_irqs for each virtual LPI. They will be put >> + * into the domain's radix tree upon the guest's MAPTI command. >> + * Pre-allocating memory for each *possible* LPI would be using way >> + * too

Re: [Xen-devel] [PATCH v6 13/36] ARM: GICv3: enable ITS and LPIs on the host

On Fri, 7 Apr 2017, Andre Przywara wrote: > Now that the host part of the ITS code is in place, we can enable the > ITS and also LPIs on each redistributor to get the show rolling. > At this point there would be no LPIs mapped, as guests don't know about > the ITS yet. > > Signed-off-by: Andre Prz

Re: [Xen-devel] [PATCH v6 10/36] ARM: GIC: Add checks for NULL pointer pending_irq's

On Fri, 7 Apr 2017, Andre Przywara wrote: > For LPIs the struct pending_irq's are somewhat dynamically allocated and > the pointers are stored in a radix tree. While I convinced myself that > an invalid LPI number can't make it into the core code, people might be > concerned about NULL pointer dere

Re: [Xen-devel] [PATCH v6 12/36] ARM: GICv3: forward pending LPIs to guests

On Fri, 7 Apr 2017, Andre Przywara wrote: > Upon receiving an LPI on the host, we need to find the right VCPU and > virtual IRQ number to get this IRQ injected. > Iterate our two-level LPI table to find this information quickly when > the host takes an LPI. Call the existing injection function to l

Re: [Xen-devel] raisin and minios stubdom

On 01/04/17 08:19, Géza Gémes wrote: > > > 2017. márc. 31. 16:15 ezt írta ("Juergen Gross" >): > > On 31/03/17 16:05, Konrad Rzeszutek Wilk wrote: > > On Thu, Mar 30, 2017 at 07:42:48PM +0200, Gémes Géza wrote: > >> > >>> On Mon, Mar 27, 2017 at 09:28:14PM +

Re: [Xen-devel] [PATCH v6 11/36] ARM: GICv3: introduce separate pending_irq structs for LPIs

On Fri, 7 Apr 2017, Andre Przywara wrote: > For the same reason that allocating a struct irq_desc for each > possible LPI is not an option, having a struct pending_irq for each LPI > is also not feasible. We only care about mapped LPIs, so we can get away > with having struct pending_irq's only for

Re: [Xen-devel] [PATCH v6 10/36] ARM: GIC: Add checks for NULL pointer pending_irq's

Hi Andre, On 07/04/17 18:32, Andre Przywara wrote: For LPIs the struct pending_irq's are somewhat dynamically allocated and When I read "dynamically", I directly ask myself. What is protecting the pending_irq structure to be freed whilst in-use in the vgic code? In the current design, this

Re: [Xen-devel] raisin and minios stubdom

2017-04-03 14:01 keltezéssel, Wei Liu írta: On Mon, Apr 03, 2017 at 12:17:08PM +0100, George Dunlap wrote: On Mon, Mar 27, 2017 at 8:28 PM, Gémes Géza wrote: Hi, Currently the xen build system has optional support for building a minios (+needed libraries and tools) based stubdom. What is you

Re: [Xen-devel] [PATCH v6 09/36] ARM: GICv3 ITS: introduce device mapping

On Fri, 7 Apr 2017, Andre Przywara wrote: > The ITS uses device IDs to map LPIs to a device. Dom0 will later use > those IDs, which we directly pass on to the host. > For this we have to map each device that Dom0 may request to a host > ITS device with the same identifier. > Allocate the respective

Re: [Xen-devel] [PATCH v6 09/36] ARM: GICv3 ITS: introduce device mapping

Hi Andre, On 07/04/17 18:32, Andre Przywara wrote: /* Set up the (1:1) collection mapping for the given host CPU. */ int gicv3_its_setup_collection(unsigned int cpu) { @@ -450,6 +523,278 @@ int gicv3_its_init(void) return 0; } +/* + * TODO: Investiage the interaction when a guest remov

Re: [Xen-devel] [PATCH v6 08/36] ARM: vGICv3: introduce ITS emulation stub

Hi Andre, On 07/04/17 18:32, Andre Przywara wrote: Create a new file to hold the emulation code for the ITS widget. This just holds the data structure and a init and free function for now. Signed-off-by: Andre Przywara Acked-by: Julien Grall Cheers, --- xen/arch/arm/Makefile

Re: [Xen-devel] [PATCH v6 07/36] ARM: GICv3 ITS: introduce host LPI array

Hi Andre, On 07/04/17 18:32, Andre Przywara wrote: The number of LPIs on a host can be potentially huge (millions), although in practise will be mostly reasonable. So prematurely allocating an array of struct irq_desc's for each LPI is not an option. However Xen itself does not care about LPIs,

Re: [Xen-devel] [PATCH v6 03/36] ARM: GICv3: allocate LPI pending and property table

Hi Andre, On 07/04/17 18:32, Andre Przywara wrote: The ARM GICv3 provides a new kind of interrupt called LPIs. The pending bits and the configuration data (priority, enable bits) for those LPIs are stored in tables in normal memory, which software has to provide to the hardware. Allocate the req

Re: [Xen-devel] [PATCH v6 01/36] ARM: GICv3 ITS: parse and store ITS subnodes from hardware DT

Hi Andre, On 07/04/17 18:32, Andre Przywara wrote: Parse the GIC subnodes in the device tree to find every ITS MSI controller the hardware offers. Store that information in a list to both propagate all of them later to Dom0, but also to be able to iterate over all ITSes. This introduces an ITS K

Re: [Xen-devel] [PATCH v6 08/36] ARM: vGICv3: introduce ITS emulation stub

On Fri, 7 Apr 2017, Andre Przywara wrote: > Create a new file to hold the emulation code for the ITS widget. > This just holds the data structure and a init and free function for now. > > Signed-off-by: Andre Przywara Acked-by: Stefano Stabellini > --- > xen/arch/arm/Makefile| 1

Re: [Xen-devel] [PATCH v6 07/36] ARM: GICv3 ITS: introduce host LPI array

On Fri, 7 Apr 2017, Andre Przywara wrote: > The number of LPIs on a host can be potentially huge (millions), > although in practise will be mostly reasonable. So prematurely allocating > an array of struct irq_desc's for each LPI is not an option. > However Xen itself does not care about LPIs, as e

[Xen-devel] [xen-unstable test] 107247: tolerable FAIL - PUSHED

flight 107247 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/107247/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 107160 test-armhf-armhf-libvirt-xs

Re: [Xen-devel] [PATCH v6 01/36] ARM: GICv3 ITS: parse and store ITS subnodes from hardware DT

On Fri, 7 Apr 2017, Andre Przywara wrote: > Parse the GIC subnodes in the device tree to find every ITS MSI controller > the hardware offers. Store that information in a list to both propagate > all of them later to Dom0, but also to be able to iterate over all ITSes. > This introduces an ITS Kconf

Re: [Xen-devel] [For Linux 4/4] xen/displif: add ABI for para-virtual display

On 04/07/2017 08:50 PM, Stefano Stabellini wrote: On Fri, 7 Apr 2017, Oleksandr Andrushchenko wrote: On 04/07/2017 07:36 PM, Stefano Stabellini wrote: On Fri, 7 Apr 2017, Oleksandr Andrushchenko wrote: Hi, Julien! On 04/07/2017 04:50 PM, Julien Grall wrote: Hi Oleksandr, On 07/04/17 09:30,

Re: [Xen-devel] [For Linux 4/4] xen/displif: add ABI for para-virtual display

On Fri, 7 Apr 2017, Oleksandr Andrushchenko wrote: > On 04/07/2017 07:36 PM, Stefano Stabellini wrote: > > On Fri, 7 Apr 2017, Oleksandr Andrushchenko wrote: > > > Hi, Julien! > > > > > > On 04/07/2017 04:50 PM, Julien Grall wrote: > > > > Hi Oleksandr, > > > > > > > > On 07/04/17 09:30, Oleksand

Re: [Xen-devel] [For Linux 4/4] xen/displif: add ABI for para-virtual display

On 04/07/2017 07:36 PM, Stefano Stabellini wrote: On Fri, 7 Apr 2017, Oleksandr Andrushchenko wrote: Hi, Julien! On 04/07/2017 04:50 PM, Julien Grall wrote: Hi Oleksandr, On 07/04/17 09:30, Oleksandr Andrushchenko wrote: +/* + *

Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

On 04/07/2017 01:36 PM, Stefano Stabellini wrote: > On Fri, 7 Apr 2017, Boris Ostrovsky wrote: >> On 04/07/2017 07:58 AM, Ian Jackson wrote: >>> tl;dr: >>> Please apply >>> >>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1 >>> partially revert "xen: Remove event channel notification through >>>

Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

On Fri, 7 Apr 2017, Boris Ostrovsky wrote: > On 04/07/2017 07:58 AM, Ian Jackson wrote: > > tl;dr: > > Please apply > > > > da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1 > > partially revert "xen: Remove event channel notification through > > Xen PCI platform device" > > > > to all stabl

[Xen-devel] [PATCH v6 33/36] ARM: vITS: handle INV command

The INV command instructs the ITS to update the configuration data for a given LPI by re-reading its entry from the property table. We don't need to care so much about the priority value, but enabling or disabling an LPI has some effect: We remove or push virtual LPIs to their VCPUs, also check the

[Xen-devel] [PATCH v6 31/36] ARM: vITS: handle MOVI command

The MOVI command moves the interrupt affinity from one redistributor (read: VCPU) to another. For now migration of "live" LPIs is not yet implemented, but we store the changed affinity in the host LPI structure and in our virtual ITTE. Signed-off-by: Andre Przywara --- xen/arch/arm/gic-v3-its.c

[Xen-devel] Code freeze exception for Xen 4.9 ARM ITS emulation?

Hello! The development of the ARM ITS emulation support has taken more time than anticipated and I won't be able to address and fix all outstanding comments until the official code freeze date. However the first part of the series is in a good shape and should be ready to be merged in time. I wa

[Xen-devel] [PATCH v6 25/36] ARM: vITS: introduce translation table walks

The ITS stores the target (v)CPU and the (virtual) LPI number in tables. Introduce functions to walk those tables and translate an device ID - event ID pair into a pair of virtual LPI and vCPU. We map those tables on demand - which is cheap on arm64 - and copy the respective entries before using th

[Xen-devel] [PATCH v6 28/36] ARM: vITS: handle MAPC command

The MAPC command associates a given collection ID with a given redistributor, thus mapping collections to VCPUs. We just store the vcpu_id in the collection table for that. Signed-off-by: Andre Przywara --- xen/arch/arm/vgic-v3-its.c | 41 + 1 file changed

  1   2   3   4   >