[PATCH v10 00/32] arm64: Dom0 ITS emulation

[PATCH v10 00/32] arm64: Dom0 ITS emulation

[Andre Przywara]

Hi,

yet another rework, addressing comments on v9.
The same restriction as for v9 still apply: the locking is considered
somewhat insufficient and will be fixed by an upcoming rework.

Most of the fixes are smaller changes as requested by the reviewers.
Some preparatory patches have been moved earlier in the series, also there
are some new patches: 04/32 to prepare gic_remove_from_queues() to be
reused, 05/32 to add gic_remove_irq(), 09/32 as a split from the former 05/28
and finally the VGIC rank lock fix I posted earlier this week, which I put
upfront in this series (01/32). It is not necessary for the ITS, but creates
merge conflicts and I expect it to be queued earlier.
A rework removes the VCPU ID from the host LPI entry, because this information
is in the struct pending_irq already and this redundancy causes some headache.
This leads to changes in patch 11/32 in the way how we inject LPIs, also
removes some code from the command emulation where the host LPI structure
was updated.

For a detailed changelog see below.

Cheers,
Andre

----------------------------------
This series adds support for emulation of an ARM GICv3 ITS interrupt
controller. For hardware which relies on the ITS to provide interrupts for
its peripherals this code is needed to get a machine booted into Dom0 at
all. ITS emulation for DomUs is only really useful with PCI passthrough,
which is not yet available for ARM. It is expected that this feature
will be co-developed with the ITS DomU code. However this code drop here
considered DomU emulation already, to keep later architectural changes
to a minimum.

This is technical preview version to allow early testing of the feature.
Things not (properly) addressed in this release:
- There is only support for Dom0 at the moment. DomU support is only really
useful with PCI passthrough, which is not there yet for ARM.
- The MOVALL command is not emulated. In our case there is really nothing
to do here. We might need to revisit this in the future for DomU support.
- The INVALL command might need some rework to be more efficient. Currently
we iterate over all mapped LPIs, which might take a bit longer.
- Indirect tables are not supported. This affects both the host and the
virtual side.
- The ITS tables inside (Dom0) guest memory cannot easily be protected
at the moment (without restricting access to Xen as well). So for now
we trust Dom0 not to touch this memory (which the spec forbids as well).
- With malicious guests (DomUs) there is a possibility of an interrupt
storm triggered by a device. We would need to investigate what that means
for Xen and if there is a nice way to prevent this. Disabling the LPI on
the host side would require command queuing, which has its downsides to
be issued during runtime.
- Dom0 should make sure that the ITS resources (number of LPIs, devices,
events) later handed to a DomU are really limited, as a large number of
them could mean much time spend in Xen to initialize, free or handle those.
It is expected that the toolstack sets up a tailored ITS with just enough
resources to accommodate the needs of the actual passthrough-ed device(s).
- The command queue locking is currently suboptimal and should be made more
fine-grained in the future, if possible.
- Provide support for running with an IOMMU, to map the doorbell page
to all devices.


Some generic design principles:

* The current GIC code statically allocates structures for each supported
IRQ (both for the host and the guest), which due to the potentially
millions of LPI interrupts is not feasible to copy for the ITS.
So we refrain from introducing the ITS as a first class Xen interrupt
controller, also we don't hold struct irq_desc's or struct pending_irq's
for each possible LPI.
Fortunately LPIs are only interesting to guests, so we get away with
storing only the virtual IRQ number and the guest VCPU for each allocated
host LPI, which can be stashed into one uint64_t. This data is stored in
a two-level table, which is both memory efficient and quick to access.
We hook into the existing IRQ handling and VGIC code to avoid accessing
the normal structures, providing alternative methods for getting the
needed information (priority, is enabled?) for LPIs.
Whenever a guest maps a device, we allocate the maximum required number
of struct pending_irq's, so that any triggering LPI can find its data
structure. Upon the guest actually mapping the LPI, this pointer to the
corresponding pending_irq gets entered into a radix tree, so that it can
be quickly looked up.

* On the guest side we (later will) have to deal with malicious guests
trying to hog Xen with mapping requests for a lot of LPIs, for instance.
As the ITS actually uses system memory for storing status information,
we use this memory (which the guest has to provide) to naturally limit
a guest. Whenever we need information from any of the ITS tables, we
temporarily map them (which is cheap on arm64) and copy the required data.

* An obvious approach to handling some guest ITS commands would be to
propagate them to the host, for instance to map devices and LPIs and
to enable or disable LPIs.
However this (later with DomU support) will create an attack vector, as
a malicious guest could try to fill the host command queue with
propagated commands.
So we try to avoid this situation: Dom0 sending a device mapping (MAPD)
command is the only time we allow queuing commands to the host ITS command
queue, as this seems to be the only reliable way of getting the
required information at the moment. However at the same time we map all
events to LPIs already, also enable them. This avoids sending commands
later at runtime, as we can deal with mappings and LPI enabling/disabling
internally.

To accomodate the tech preview nature of this feature at the moment, there
is a Kconfig option to enable it. Also it is supported on arm64 only, which
will most likely not change in the future.
This leads to some hideous constructs like an #ifdef'ed header file with
empty function stubs to accomodate arm32 and non-ITS builds, which share
some generic code paths with the ITS emulation.
The number of supported LPIs can be limited on the command line, in case
the number reported by the hardware is too high. As Xen cannot foresee how
many interrupts the guests will need, we cater for as many as possible.
The command line parameter is called max-lpi-bits and expresses the number
of bits required to hold an interrupt ID. It defaults to 20, if that is
lower than the number supported by the hardware.

This code boots Dom0 on an ARM Fast Model with ITS support. I tried to
address the issues seen by people running the previous versions on real
hardware, though couldn't verify this here for myself.
So any testing, bug reports (and possibly even fixes) are very welcome.

The code can also be found on the its/v10 branch here:
git://linux-arm.org/xen-ap.git
http://www.linux-arm.org/git?p=xen-ap.git;a=shortlog;h=refs/heads/its/v10

Cheers,
Andre

Changelog v9 ... v10:
no changes to {06, 07, 12, 15, 20, 29, 30, 32}/32
- [01/32]: fix for rank lock deadlock as posted before
- [02/32]: replace arbitrary 16 bits for DomU interrupt IDs with 10 bits
- [03/32]: handle functions not dealing with LPIs as well
- [04/32]: new patch to rename gic_remove_from_queues and remove lock
- [05/32]: new patch to introduce helper for removing IRQs from the VGIC
- [06/32]: adapt to previous changes
- [08/32]: use memset to clear the whole structure
- [09/32]: split off from former 05/28
- [10/32]: moved up front, initialize VCPU ID
- [11/32]: remove VCPU ID from host entry, rework LPI injection, moved
           out part dealing with LPI priority caching
- [13/32]: add a hint about boolean variables
- [14/32]: fix bool_t type usage
- [16/32]: replace magic value, always use intid_bits for TYPER generation,
           add memory barrier
- [17/32]: add comments about ITS table layout, remove le64_to_cpu(),
           simplify CTLR read and remove lock, use atomic read and add comment
           in CREADR read, add TODO and ASSERT about crafting ITS tables,
           add empty lines in switch/case, move code block
- [18/32]: consistent use of data types, comments moved out to earlier patch
- [19/32]: fold in get_host_lpi(), rename veventid identifier
- [21/32]: move variable assignment
- [22/32]: add TODO locking comment, use new gic_remove_irq() function
- [23/32]: remove no longer needed VCPU ID from host LPI functions, add
           locking TODO, use goto out
- [24/32]: explain reason for LR check, make LRs unsigned, move PRISTINE
           check into one place
- [25/32]: mention MAPI, remove VCPU ID from host LPI updates, use atomic
           write for priority update, remove outdated comment, explain
           error handling path, check for valid property table
- [26/32]: remove update of VCPU ID in the host_lpi structure, add locking TODO
- [27/32]: fix error path
- [28/32]: add comment about physical LPI, use generic function to remove IRQ,
           remove redundant clear_bit
- [31/32]: make vgic_v3_its_init_virtual() static (and move it), move comment,
           remove unneeded call to vgic_v3_its_free_domain()

Changelog v8 ... v9:
- [01/28]: initialize number of interrupt IDs for DomUs also
- [02/28]: move priority reading back up front
- [03/28]: enumerate all call sites in commit message, add ASSERTs,
           add "unlikely" hints, avoid skipping ASSERTs, add comment to
           irq_to_pending() definition
- [04/28]: explain expectation of device state while destroying domain
- [05/28]: document case of invalid LPI, change dummy priority to 0xff
- [08/28]: check cross page boundary condition early in function
- [10/28]: initialize status and lr member as well
- [11/28]: check lpi_vcpu_id to cover all virtual CPUs
- [12/28]: add spin lock ASSERT
- [13/28]: introduce types for our ITS table entries, fix error messages
- [14/28]: use new ITS table entry types
- [15/28]: new patch to introduce pending_irq lookup function
- [17/28]: verify size of collection table entry
- [18/28]: use new pending_irq lookup function
- [19/28]: use new pending_irq lookup function, collection table type and
           vgic_init_pending_irq, add Dom0 ASSERT and unmap devices for DomUs
- [20/28]: document PRISTINE_LPI flag, fix typo, avoid double insertion of
           the same LPI into different LRs
- [21/28]: use new pending_irq lookup function, avoid explict LPI number
           parameter
- [22/28]: add physical affinity TODO, use new table type and pending_irq
           lookup function, fix error message
- [24/28]: use pending_irq lookup function, drop explicit LPI number parameter
- [25/28]: drop explicit LPI number parameter
- [27/28]: use new ITS table entry type

Changelog v7 ... v8:
- drop list parameter and rename to gicv3_its_make_hwdwom_dt_nodes()
- remove rebase artifacts
- add irq_enter/irq_exit() calls
- propagates number of host LPIs and number of event IDs to Dom0
- add proper coverage of all addresses in ITS MMIO handler
- avoid vcmd_lock for CBASER writes
- fix missing irqsave/irqrestore on VGIC VCPU lock
- move struct pending_irq use under the VGIC VCPU lock
- protect gic_raise_guest_irq() against NULL pending_irq
- improve device and collection table entry size documentation
- count number of ITSes to increase mmio_count
- rework MAPD, DISCARD, MAPTI and MOVI to take proper locks
- properly rollback failing MAPD and MAPTI calls
- rework functions to update property table
- return error on vgic_access_guest_memory crossing page boundary
- make sure CREADR access is atomic

Changelog v5 ... v6:
- reordered patches to allow splitting the series
- introduced functions later to avoid warnings on intermediate builds
- refactored common code changes into separate patches
- dropped GENMASK_ULL and BIT_ULL (both patches and their usage later)
- rework locking in MMIO register reads and writes
- protect new code from being executed without an ITS being configured
- fix vgic_access_guest_memory (now a separate patch)
- some more comments and TODOs

Changelog v4 ... v5:
- adding many comments
- spinlock asserts
- rename r_host_lpis to max_host_lpi_ids
- remove max_its_device_bits command line
- add warning on high number of LPIs
- avoid potential leak on host MAPD
- properly handle nr_events rounding
- remove unmap_all_devices(), replace with ASSERT
- add barriers for (lockless) host LPI lookups
- add proper locking in ITS and redist MMIO register handling
- rollback failing device mapping
- fix various printks
- add vgic_access_guest_memory() and use it
- (getting rid of page mapping functions and helpers)
- drop table mapping / unmapping on redist/ITS enable/disable
- minor reworks in functions as per review comments
- fix ITS enablement check
- move lpi_to_pending() and lpi_get_priority() to vgic_ops
- move do_LPI() to gic_hw_ops
- whitespace and hard tabs fixes
- introduce ITS domain init function (and use it for the rbtree)
- enable IRQs around do_LPI
- implement TODOs for later optimizations
- add "v" prefix to variables holding virtual properties
- provide locked and normal versions of read/write_itte
- only CLEAR LPI if not already guest visible (plus comment)
- update LPI property on MAPTI
- store vcpu_id in pending_irq for LPIs (helps INVALL)
- improve INVALL implementation to only cover LPIs on this VCPU
- improve virtual BASE register initialization
- limit number of virtual LPIs to 24 bits (Linux bug at 32??)
- only inject LPIs if redistributor is actually enabled

Changelog v3 .. v4:
- make HAS_ITS depend on EXPERT
- introduce new patch 02 to initialize host ITS early
- fix cmd_lock init position
- introduce warning on high number of LPI allocations
- various int -> unsigned fixes
- adding and improving comments
- rate limit ITS command queue full msg
- drop unneeded checks
- validate against allowed number of device IDs
- avoid memory leaks when removing devices
- improve algorithm for finding free host LPI
- convert unmap_all_devices from goto to while loop
- add message on remapping ITS device
- name virtual device / event IDs properly
- use atomic read when reading ITT entry

Changelog v2 .. v3:
- preallocate struct pending_irq's
- map ITS and redistributor tables only on demand
- store property, enable and pending bit in struct pending_irq
- improve error checking and handling
- add comments

Changelog v1 .. v2:
- clean up header file inclusion
- rework host ITS table allocation: observe attributes, many fixes
- remove patch 1 to export __flush_dcache_area, use existing function instead
- use number of LPIs internally instead of number of bits
- keep host_its_list as private as possible
- keep struct its_devices private
- rework gicv3_its_map_guest_devices
- fix rbtree issues
- more error handling and propagation
- cope with GICv4 implementations (but no virtual LPI features!)
- abstract host and guest ITSes by using doorbell addresses
- join per-redistributor variables into one per-CPU structure
- fix data types (unsigned int)
- many minor bug fixes

(Rough) changelog RFC-v2 .. v1:
- split host ITS driver into gic-v3-lpi.c and gic-v3-its.c part
- rename virtual ITS driver file to vgic-v3-its.c
- use macros and named constants for all magic numbers
- use atomic accessors for accessing the host LPI data
- remove leftovers from connecting virtual and host ITSes
- bail out if host ITS is disabled in the DT
- rework map/unmap_guest_pages():
    - split off p2m part as get/put_guest_pages (to be done on allocation)
    - get rid of vmap, using map_domain_page() instead
- delay allocation of virtual tables until actual LPI/ITS enablement
- properly size both virtual and physical tables upon allocation
- fix put_domain() locking issues in physdev_op and LPI handling code
- add and extend comments in various areas
- fix lotsa coding style and white space issues, including comment style
- add locking to data structures not yet covered
- fix various locking issues
- use an rbtree to deal with ITS devices (instead of a list)
- properly handle memory attributes for ITS tables
- handle cacheable/non-cacheable ITS table mappings
- sanitize guest provided ITS/LPI table attributes
- fix breakage on non-GICv2 compatible host GICv3 controllers
- add command line parameters on top of Kconfig options
- properly wait for an ITS to become quiescient before enabling it
- handle host ITS command queue errors
- actually wait for host ITS command completion (READR==WRITER)
- fix ARM32 compilation
- various patch splits and reorderings

Andre Przywara (31):
  ARM: vGIC: avoid rank lock when reading priority
  ARM: GICv3: setup number of LPI bits for a GICv3 guest
  ARM: vGIC: move irq_to_pending() calls under the VGIC VCPU lock
  ARM: vGIC: rework gic_remove_from_queues()
  ARM: vGIC: introduce gic_remove_irq()
  ARM: GIC: Add checks for NULL pointer pending_irq's
  ARM: GICv3: introduce separate pending_irq structs for LPIs
  ARM: GIC: export and extend vgic_init_pending_irq()
  ARM: vGIC: cache virtual LPI priority in struct pending_irq
  ARM: vGIC: add LPI VCPU ID to struct pending_irq
  ARM: GICv3: forward pending LPIs to guests
  ARM: GICv3: enable ITS and LPIs on the host
  ARM: vGICv3: handle virtual LPI pending and property tables
  ARM: vGICv3: re-use vgic_reg64_check_access
  ARM: vGIC: advertise LPI support
  ARM: vITS: add command handling stub and MMIO emulation
  ARM: vITS: introduce translation table walks
  ARM: vITS: provide access to struct pending_irq
  ARM: vITS: handle INT command
  ARM: vITS: handle MAPC command
  ARM: vITS: handle CLEAR command
  ARM: vITS: handle MAPD command
  ARM: GICv3: handle unmapped LPIs
  ARM: vITS: handle MAPTI/MAPI command
  ARM: vITS: handle MOVI command
  ARM: vITS: handle DISCARD command
  ARM: vITS: handle INV command
  ARM: vITS: handle INVALL command
  ARM: vITS: increase mmio_count for each ITS
  ARM: vITS: create and initialize virtual ITSes for Dom0
  ARM: vITS: create ITS subnodes for Dom0 DT

Vijaya Kumar K (1):
  ARM: introduce vgic_access_guest_memory()

 xen/arch/arm/gic-v2.c            |    7 +
 xen/arch/arm/gic-v3-its.c        |  180 +++++
 xen/arch/arm/gic-v3-lpi.c        |   93 ++-
 xen/arch/arm/gic-v3.c            |   29 +-
 xen/arch/arm/gic.c               |   99 ++-
 xen/arch/arm/vgic-v2.c           |   15 +
 xen/arch/arm/vgic-v3-its.c       | 1462 +++++++++++++++++++++++++++++++++++++-
 xen/arch/arm/vgic-v3.c           |  303 +++++++-
 xen/arch/arm/vgic.c              |  140 +++-
 xen/include/asm-arm/domain.h     |   16 +-
 xen/include/asm-arm/event.h      |    3 +
 xen/include/asm-arm/gic.h        |    5 +-
 xen/include/asm-arm/gic_v3_its.h |   42 ++
 xen/include/asm-arm/vgic-emul.h  |    9 +
 xen/include/asm-arm/vgic.h       |   18 +-
 15 files changed, 2353 insertions(+), 68 deletions(-)

-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 01/32] ARM: vGIC: avoid rank lock when reading priority

[Andre Przywara]

When reading the priority value of a virtual interrupt, we were taking
the respective rank lock so far.
However for forwarded interrupts (Dom0 only so far) this may lead to a
deadlock with the following call chain:
- MMIO access to change the IRQ affinity, calling the ITARGETSR handler
- this handler takes the appropriate rank lock and calls vgic_store_itargetsr()
- vgic_store_itargetsr() will eventually call vgic_migrate_irq()
- if this IRQ is already in-flight, it will remove it from the old
  VCPU and inject it into the new one, by calling vgic_vcpu_inject_irq()
- vgic_vcpu_inject_irq will call vgic_get_virq_priority()
- vgic_get_virq_priority() tries to take the rank lock - again!
It seems like this code path has never been exercised before.

Fix this by avoiding taking the lock in vgic_get_virq_priority() (like we
do in vgic_get_target_vcpu()).
Actually we are just reading one byte, and priority changes while
interrupts are handled are a benign race that can happen on real hardware
too. So it looks safe to just use read_atomic() instead.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 xen/arch/arm/vgic.c | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 83569b0..54b2aad 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -227,14 +227,8 @@ struct vcpu *vgic_get_target_vcpu(struct vcpu *v, unsigned int virq)
 static int vgic_get_virq_priority(struct vcpu *v, unsigned int virq)
 {
     struct vgic_irq_rank *rank = vgic_rank_irq(v, virq);
-    unsigned long flags;
-    int priority;
-
-    vgic_lock_rank(v, rank, flags);
-    priority = rank->priority[virq & INTERRUPT_RANK_MASK];
-    vgic_unlock_rank(v, rank, flags);
 
-    return priority;
+    return read_atomic(&rank->priority[virq & INTERRUPT_RANK_MASK]);
 }
 
 bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned int irq)
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 02/32] ARM: GICv3: setup number of LPI bits for a GICv3 guest

[Andre Przywara]

The host supports a certain number of LPI identifiers, as stored in
the GICD_TYPER register.
Store this number from the hardware register in vgic_v3_hw to allow
injecting the very same number into a guest (Dom0).
DomUs get the legacy number of 10 bits here, since for now it only sees
SPIs, so it does not need more. This should be revisited once we get
proper DomU ITS support.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 xen/arch/arm/gic-v3.c        |  6 +++++-
 xen/arch/arm/vgic-v3.c       | 10 +++++++++-
 xen/include/asm-arm/domain.h |  1 +
 xen/include/asm-arm/vgic.h   |  3 ++-
 4 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index a559e5e..29c8964 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1579,6 +1579,7 @@ static int __init gicv3_init(void)
 {
     int res, i;
     uint32_t reg;
+    unsigned int intid_bits;
 
     if ( !cpu_has_gicv3 )
     {
@@ -1622,8 +1623,11 @@ static int __init gicv3_init(void)
                i, r->base, r->base + r->size);
     }
 
+    reg = readl_relaxed(GICD + GICD_TYPER);
+    intid_bits = GICD_TYPE_ID_BITS(reg);
+
     vgic_v3_setup_hw(dbase, gicv3.rdist_count, gicv3.rdist_regions,
-                     gicv3.rdist_stride);
+                     gicv3.rdist_stride, intid_bits);
     gicv3_init_v2();
 
     spin_lock_init(&gicv3.lock);
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index d10757a..87f5fb3 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -57,18 +57,21 @@ static struct {
     unsigned int nr_rdist_regions;
     const struct rdist_region *regions;
     uint32_t rdist_stride; /* Re-distributor stride */
+    unsigned int intid_bits;  /* Number of interrupt ID bits */
 } vgic_v3_hw;
 
 void vgic_v3_setup_hw(paddr_t dbase,
                       unsigned int nr_rdist_regions,
                       const struct rdist_region *regions,
-                      uint32_t rdist_stride)
+                      uint32_t rdist_stride,
+                      unsigned int intid_bits)
 {
     vgic_v3_hw.enabled = 1;
     vgic_v3_hw.dbase = dbase;
     vgic_v3_hw.nr_rdist_regions = nr_rdist_regions;
     vgic_v3_hw.regions = regions;
     vgic_v3_hw.rdist_stride = rdist_stride;
+    vgic_v3_hw.intid_bits = intid_bits;
 }
 
 static struct vcpu *vgic_v3_irouter_to_vcpu(struct domain *d, uint64_t irouter)
@@ -1482,6 +1485,8 @@ static int vgic_v3_domain_init(struct domain *d)
 
             first_cpu += size / d->arch.vgic.rdist_stride;
         }
+
+        d->arch.vgic.intid_bits = vgic_v3_hw.intid_bits;
     }
     else
     {
@@ -1497,6 +1502,9 @@ static int vgic_v3_domain_init(struct domain *d)
         d->arch.vgic.rdist_regions[0].base = GUEST_GICV3_GICR0_BASE;
         d->arch.vgic.rdist_regions[0].size = GUEST_GICV3_GICR0_SIZE;
         d->arch.vgic.rdist_regions[0].first_cpu = 0;
+
+        /* TODO: only SPIs for now, adjust this when guests need LPIs */
+        d->arch.vgic.intid_bits = 10;
     }
 
     ret = vgic_v3_its_init_domain(d);
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 6de8082..7c3829d 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -111,6 +111,7 @@ struct arch_domain
         uint32_t rdist_stride;              /* Re-Distributor stride */
         struct rb_root its_devices;         /* Devices mapped to an ITS */
         spinlock_t its_devices_lock;        /* Protects the its_devices tree */
+        unsigned int intid_bits;
 #endif
     } vgic;
 
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 544867a..df75064 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -346,7 +346,8 @@ struct rdist_region;
 void vgic_v3_setup_hw(paddr_t dbase,
                       unsigned int nr_rdist_regions,
                       const struct rdist_region *regions,
-                      uint32_t rdist_stride);
+                      uint32_t rdist_stride,
+                      unsigned int intid_bits);
 #endif
 
 #endif /* __ASM_ARM_VGIC_H__ */
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 03/32] ARM: vGIC: move irq_to_pending() calls under the VGIC VCPU lock

[Andre Przywara]

So far irq_to_pending() is just a convenience function to lookup
statically allocated arrays. This will change with LPIs, which are
more dynamic, so the memory for their struct pending_irq might go away.
The proper answer to the issue of preventing stale pointers is
ref-counting, which requires more rework and will be introduced with
a later rework.
For now move the irq_to_pending() calls that are used with LPIs under the
VGIC VCPU lock, and only use the returned pointer while holding the lock.
This prevents the memory from being freed while we use it.
For the sake of completeness we take care about all irq_to_pending()
users, even those which later will never deal with LPIs.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 xen/arch/arm/gic.c  |  5 ++++-
 xen/arch/arm/vgic.c | 39 ++++++++++++++++++++++++++++++---------
 2 files changed, 34 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index da19130..dcb1783 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -402,10 +402,13 @@ static inline void gic_add_to_lr_pending(struct vcpu *v, struct pending_irq *n)
 
 void gic_remove_from_queues(struct vcpu *v, unsigned int virtual_irq)
 {
-    struct pending_irq *p = irq_to_pending(v, virtual_irq);
+    struct pending_irq *p;
     unsigned long flags;
 
     spin_lock_irqsave(&v->arch.vgic.lock, flags);
+
+    p = irq_to_pending(v, virtual_irq);
+
     if ( !list_empty(&p->lr_queue) )
         list_del_init(&p->lr_queue);
     spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 54b2aad..69d732b 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -234,23 +234,29 @@ static int vgic_get_virq_priority(struct vcpu *v, unsigned int virq)
 bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned int irq)
 {
     unsigned long flags;
-    struct pending_irq *p = irq_to_pending(old, irq);
+    struct pending_irq *p;
+
+    spin_lock_irqsave(&old->arch.vgic.lock, flags);
+
+    p = irq_to_pending(old, irq);
 
     /* nothing to do for virtual interrupts */
     if ( p->desc == NULL )
+    {
+        spin_unlock_irqrestore(&old->arch.vgic.lock, flags);
         return true;
+    }
 
     /* migration already in progress, no need to do anything */
     if ( test_bit(GIC_IRQ_GUEST_MIGRATING, &p->status) )
     {
         gprintk(XENLOG_WARNING, "irq %u migration failed: requested while in progress\n", irq);
+        spin_unlock_irqrestore(&old->arch.vgic.lock, flags);
         return false;
     }
 
     perfc_incr(vgic_irq_migrates);
 
-    spin_lock_irqsave(&old->arch.vgic.lock, flags);
-
     if ( list_empty(&p->inflight) )
     {
         irq_set_affinity(p->desc, cpumask_of(new->processor));
@@ -285,6 +291,13 @@ void arch_move_irqs(struct vcpu *v)
     struct vcpu *v_target;
     int i;
 
+    /*
+     * We don't migrate LPIs at the moment.
+     * If we ever do, we must make sure that the struct pending_irq does
+     * not go away, as there is no lock preventing this here.
+     */
+    ASSERT(!is_lpi(vgic_num_irqs(d) - 1));
+
     for ( i = 32; i < vgic_num_irqs(d); i++ )
     {
         v_target = vgic_get_target_vcpu(v, i);
@@ -299,6 +312,7 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
 {
     const unsigned long mask = r;
     struct pending_irq *p;
+    struct irq_desc *desc;
     unsigned int irq;
     unsigned long flags;
     int i = 0;
@@ -307,14 +321,19 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
     while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
         irq = i + (32 * n);
         v_target = vgic_get_target_vcpu(v, irq);
+
+        spin_lock_irqsave(&v_target->arch.vgic.lock, flags);
         p = irq_to_pending(v_target, irq);
         clear_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
         gic_remove_from_queues(v_target, irq);
-        if ( p->desc != NULL )
+        desc = p->desc;
+        spin_unlock_irqrestore(&v_target->arch.vgic.lock, flags);
+
+        if ( desc != NULL )
         {
-            spin_lock_irqsave(&p->desc->lock, flags);
-            p->desc->handler->disable(p->desc);
-            spin_unlock_irqrestore(&p->desc->lock, flags);
+            spin_lock_irqsave(&desc->lock, flags);
+            desc->handler->disable(desc);
+            spin_unlock_irqrestore(&desc->lock, flags);
         }
         i++;
     }
@@ -349,9 +368,9 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
     while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
         irq = i + (32 * n);
         v_target = vgic_get_target_vcpu(v, irq);
+        spin_lock_irqsave(&v_target->arch.vgic.lock, flags);
         p = irq_to_pending(v_target, irq);
         set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
-        spin_lock_irqsave(&v_target->arch.vgic.lock, flags);
         if ( !list_empty(&p->inflight) && !test_bit(GIC_IRQ_GUEST_VISIBLE, &p->status) )
             gic_raise_guest_irq(v_target, irq, p->priority);
         spin_unlock_irqrestore(&v_target->arch.vgic.lock, flags);
@@ -460,7 +479,7 @@ void vgic_clear_pending_irqs(struct vcpu *v)
 void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq)
 {
     uint8_t priority;
-    struct pending_irq *iter, *n = irq_to_pending(v, virq);
+    struct pending_irq *iter, *n;
     unsigned long flags;
     bool running;
 
@@ -468,6 +487,8 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq)
 
     spin_lock_irqsave(&v->arch.vgic.lock, flags);
 
+    n = irq_to_pending(v, virq);
+
     /* vcpu offline */
     if ( test_bit(_VPF_down, &v->pause_flags) )
     {
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 04/32] ARM: vGIC: rework gic_remove_from_queues()

[Andre Przywara]

The function name gic_remove_from_queues() was a bit of a misnomer,
since it just removes an IRQ from the pending queue, not both queues.
Rename the function to make this more clear, also give it a pointer to
a struct pending_irq directly and rely on the VGIC VCPU lock to be
already taken, so this can be used in more places.
Replace the list removal in gic_clear_pending_irqs() with a call to
this function.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 xen/arch/arm/gic.c        | 12 +++---------
 xen/arch/arm/vgic.c       |  2 +-
 xen/include/asm-arm/gic.h |  2 +-
 3 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index dcb1783..9dde146 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -400,18 +400,12 @@ static inline void gic_add_to_lr_pending(struct vcpu *v, struct pending_irq *n)
     list_add_tail(&n->lr_queue, &v->arch.vgic.lr_pending);
 }
 
-void gic_remove_from_queues(struct vcpu *v, unsigned int virtual_irq)
+void gic_remove_from_lr_pending(struct vcpu *v, struct pending_irq *p)
 {
-    struct pending_irq *p;
-    unsigned long flags;
-
-    spin_lock_irqsave(&v->arch.vgic.lock, flags);
-
-    p = irq_to_pending(v, virtual_irq);
+    ASSERT(spin_is_locked(&v->arch.vgic.lock));
 
     if ( !list_empty(&p->lr_queue) )
         list_del_init(&p->lr_queue);
-    spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
 }
 
 void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq)
@@ -612,7 +606,7 @@ void gic_clear_pending_irqs(struct vcpu *v)
 
     v->arch.lr_mask = 0;
     list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
-        list_del_init(&p->lr_queue);
+        gic_remove_from_lr_pending(v, p);
 }
 
 int gic_events_need_delivery(void)
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 69d732b..3993965 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -325,7 +325,7 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
         spin_lock_irqsave(&v_target->arch.vgic.lock, flags);
         p = irq_to_pending(v_target, irq);
         clear_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
-        gic_remove_from_queues(v_target, irq);
+        gic_remove_from_lr_pending(v_target, p);
         desc = p->desc;
         spin_unlock_irqrestore(&v_target->arch.vgic.lock, flags);
 
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 836a103..3130634 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -243,7 +243,7 @@ extern void init_maintenance_interrupt(void);
 extern void gic_raise_guest_irq(struct vcpu *v, unsigned int irq,
         unsigned int priority);
 extern void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq);
-extern void gic_remove_from_queues(struct vcpu *v, unsigned int virtual_irq);
+extern void gic_remove_from_lr_pending(struct vcpu *v, struct pending_irq *p);
 
 /* Accept an interrupt from the GIC and dispatch its handler */
 extern void gic_interrupt(struct cpu_user_regs *regs, int is_fiq);
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 05/32] ARM: vGIC: introduce gic_remove_irq()

[Andre Przywara]

To avoid code duplication in a later patch, introduce a generic function
to remove a virtual IRQ from the VGIC.
Call that function instead of the open-coded version in vgic_migrate_irq().

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 xen/arch/arm/gic.c        | 9 +++++++++
 xen/arch/arm/vgic.c       | 1 +
 xen/include/asm-arm/gic.h | 1 +
 3 files changed, 11 insertions(+)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 9dde146..3a6184a 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -408,6 +408,15 @@ void gic_remove_from_lr_pending(struct vcpu *v, struct pending_irq *p)
         list_del_init(&p->lr_queue);
 }
 
+void gic_remove_irq(struct vcpu *v, struct pending_irq *p)
+{
+    ASSERT(spin_is_locked(&v->arch.vgic.lock));
+
+    clear_bit(GIC_IRQ_GUEST_QUEUED, &p->status);
+    list_del_init(&p->inflight);
+    gic_remove_from_lr_pending(v, p);
+}
+
 void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq)
 {
     struct pending_irq *n = irq_to_pending(v, virtual_irq);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 3993965..b2acc99 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -266,6 +266,7 @@ bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned int irq)
     /* If the IRQ is still lr_pending, re-inject it to the new vcpu */
     if ( !list_empty(&p->lr_queue) )
     {
+        gic_remove_irq(old, p);
         clear_bit(GIC_IRQ_GUEST_QUEUED, &p->status);
         list_del_init(&p->lr_queue);
         list_del_init(&p->inflight);
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 3130634..5d5b4cc 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -244,6 +244,7 @@ extern void gic_raise_guest_irq(struct vcpu *v, unsigned int irq,
         unsigned int priority);
 extern void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq);
 extern void gic_remove_from_lr_pending(struct vcpu *v, struct pending_irq *p);
+extern void gic_remove_irq(struct vcpu *v, struct pending_irq *p);
 
 /* Accept an interrupt from the GIC and dispatch its handler */
 extern void gic_interrupt(struct cpu_user_regs *regs, int is_fiq);
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 06/32] ARM: GIC: Add checks for NULL pointer pending_irq's

[Andre Przywara]

For LPIs the struct pending_irq's are dynamically allocated and the
pointers will be stored in a radix tree. Since an LPI can be "unmapped"
at any time, teach the VGIC how to deal with irq_to_pending() returning
a NULL pointer.
We just do nothing in this case or clean up the LR if the virtual LPI
number was still in an LR.

Those are all call sites for irq_to_pending(), as per:
"git grep irq_to_pending", and their evaluations:
(PROTECTED means: added NULL check and bailing out)

    xen/arch/arm/gic.c:
gic_route_irq_to_guest(): only called for SPIs, added ASSERT()
gic_remove_irq_from_guest(): only called for SPIs, added ASSERT()
gic_remove_from_queues(): PROTECTED, called within VCPU VGIC lock
gic_raise_inflight_irq(): PROTECTED, called under VCPU VGIC lock
gic_raise_guest_irq(): PROTECTED, called under VCPU VGIC lock
gic_update_one_lr(): PROTECTED, called under VCPU VGIC lock

    xen/arch/arm/vgic.c:
vgic_migrate_irq(): not called for LPIs (virtual IRQs), added ASSERT()
arch_move_irqs(): not iterating over LPIs, added ASSERT()
vgic_disable_irqs(): not called for LPIs, added ASSERT()
vgic_enable_irqs(): not called for LPIs, added ASSERT()
vgic_vcpu_inject_irq(): PROTECTED, moved under VCPU VGIC lock

    xen/include/asm-arm/event.h:
local_events_need_delivery_nomask(): only called for a PPI, added ASSERT()

    xen/include/asm-arm/vgic.h:
(prototype)

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 xen/arch/arm/gic.c          | 26 ++++++++++++++++++++++++--
 xen/arch/arm/vgic.c         | 21 +++++++++++++++++++++
 xen/include/asm-arm/event.h |  3 +++
 3 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 3a6184a..957d516 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -148,6 +148,7 @@ int gic_route_irq_to_guest(struct domain *d, unsigned int virq,
     /* Caller has already checked that the IRQ is an SPI */
     ASSERT(virq >= 32);
     ASSERT(virq < vgic_num_irqs(d));
+    ASSERT(!is_lpi(virq));
 
     vgic_lock_rank(v_target, rank, flags);
 
@@ -184,6 +185,7 @@ int gic_remove_irq_from_guest(struct domain *d, unsigned int virq,
     ASSERT(spin_is_locked(&desc->lock));
     ASSERT(test_bit(_IRQ_GUEST, &desc->status));
     ASSERT(p->desc == desc);
+    ASSERT(!is_lpi(virq));
 
     vgic_lock_rank(v_target, rank, flags);
 
@@ -421,6 +423,10 @@ void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq)
 {
     struct pending_irq *n = irq_to_pending(v, virtual_irq);
 
+    /* If an LPI has been removed meanwhile, there is nothing left to raise. */
+    if ( unlikely(!n) )
+        return;
+
     ASSERT(spin_is_locked(&v->arch.vgic.lock));
 
     if ( list_empty(&n->lr_queue) )
@@ -440,20 +446,25 @@ void gic_raise_guest_irq(struct vcpu *v, unsigned int virtual_irq,
 {
     int i;
     unsigned int nr_lrs = gic_hw_ops->info->nr_lrs;
+    struct pending_irq *p = irq_to_pending(v, virtual_irq);
 
     ASSERT(spin_is_locked(&v->arch.vgic.lock));
 
+    if ( unlikely(!p) )
+        /* An unmapped LPI does not need to be raised. */
+        return;
+
     if ( v == current && list_empty(&v->arch.vgic.lr_pending) )
     {
         i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
         if (i < nr_lrs) {
             set_bit(i, &this_cpu(lr_mask));
-            gic_set_lr(i, irq_to_pending(v, virtual_irq), GICH_LR_PENDING);
+            gic_set_lr(i, p, GICH_LR_PENDING);
             return;
         }
     }
 
-    gic_add_to_lr_pending(v, irq_to_pending(v, virtual_irq));
+    gic_add_to_lr_pending(v, p);
 }
 
 static void gic_update_one_lr(struct vcpu *v, int i)
@@ -468,6 +479,17 @@ static void gic_update_one_lr(struct vcpu *v, int i)
     gic_hw_ops->read_lr(i, &lr_val);
     irq = lr_val.virq;
     p = irq_to_pending(v, irq);
+    /* An LPI might have been unmapped, in which case we just clean up here. */
+    if ( unlikely(!p) )
+    {
+        ASSERT(is_lpi(irq));
+
+        gic_hw_ops->clear_lr(i);
+        clear_bit(i, &this_cpu(lr_mask));
+
+        return;
+    }
+
     if ( lr_val.state & GICH_LR_ACTIVE )
     {
         set_bit(GIC_IRQ_GUEST_ACTIVE, &p->status);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index b2acc99..1c0da7d 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -236,6 +236,9 @@ bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned int irq)
     unsigned long flags;
     struct pending_irq *p;
 
+    /* This will never be called for an LPI, as we don't migrate them. */
+    ASSERT(!is_lpi(irq));
+
     spin_lock_irqsave(&old->arch.vgic.lock, flags);
 
     p = irq_to_pending(old, irq);
@@ -319,6 +322,9 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
     int i = 0;
     struct vcpu *v_target;
 
+    /* LPIs will never be disabled via this function. */
+    ASSERT(!is_lpi(32 * n + 31));
+
     while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
         irq = i + (32 * n);
         v_target = vgic_get_target_vcpu(v, irq);
@@ -366,6 +372,9 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
     struct vcpu *v_target;
     struct domain *d = v->domain;
 
+    /* LPIs will never be enabled via this function. */
+    ASSERT(!is_lpi(32 * n + 31));
+
     while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
         irq = i + (32 * n);
         v_target = vgic_get_target_vcpu(v, irq);
@@ -446,6 +455,12 @@ bool vgic_to_sgi(struct vcpu *v, register_t sgir, enum gic_sgi_mode irqmode,
     return true;
 }
 
+/*
+ * Returns the pointer to the struct pending_irq belonging to the given
+ * interrupt.
+ * This can return NULL if called for an LPI which has been unmapped
+ * meanwhile.
+ */
 struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
 {
     struct pending_irq *n;
@@ -489,6 +504,12 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq)
     spin_lock_irqsave(&v->arch.vgic.lock, flags);
 
     n = irq_to_pending(v, virq);
+    /* If an LPI has been removed, there is nothing to inject here. */
+    if ( unlikely(!n) )
+    {
+        spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
+        return;
+    }
 
     /* vcpu offline */
     if ( test_bit(_VPF_down, &v->pause_flags) )
diff --git a/xen/include/asm-arm/event.h b/xen/include/asm-arm/event.h
index 5330dfe..caefa50 100644
--- a/xen/include/asm-arm/event.h
+++ b/xen/include/asm-arm/event.h
@@ -19,6 +19,9 @@ static inline int local_events_need_delivery_nomask(void)
     struct pending_irq *p = irq_to_pending(current,
                                            current->domain->arch.evtchn_irq);
 
+    /* Does not work for LPIs. */
+    ASSERT(!is_lpi(current->domain->arch.evtchn_irq));
+
     /* XXX: if the first interrupt has already been delivered, we should
      * check whether any other interrupts with priority higher than the
      * one in GICV_IAR are in the lr_pending queue or in the LR
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 07/32] ARM: GICv3: introduce separate pending_irq structs for LPIs

[Andre Przywara]

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 drop the pointer to the
respective pending_irq. The index used is the virtual LPI number.
The memory for the actual structures has been allocated already per
device at device mapping time.
Teach the existing VGIC functions to find the right pointer when being
given a virtual LPI number.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
---
 xen/arch/arm/vgic-v2.c       |  8 ++++++++
 xen/arch/arm/vgic-v3.c       | 30 ++++++++++++++++++++++++++++++
 xen/arch/arm/vgic.c          |  2 ++
 xen/include/asm-arm/domain.h |  2 ++
 xen/include/asm-arm/vgic.h   |  2 ++
 5 files changed, 44 insertions(+)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index dc9f95b..0587569 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -702,10 +702,18 @@ static void vgic_v2_domain_free(struct domain *d)
     /* Nothing to be cleanup for this driver */
 }
 
+static struct pending_irq *vgic_v2_lpi_to_pending(struct domain *d,
+                                                  unsigned int vlpi)
+{
+    /* Dummy function, no LPIs on a VGICv2. */
+    BUG();
+}
+
 static const struct vgic_ops vgic_v2_ops = {
     .vcpu_init   = vgic_v2_vcpu_init,
     .domain_init = vgic_v2_domain_init,
     .domain_free = vgic_v2_domain_free,
+    .lpi_to_pending = vgic_v2_lpi_to_pending,
     .max_vcpus = 8,
 };
 
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 87f5fb3..89be7c0 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1454,6 +1454,9 @@ static int vgic_v3_domain_init(struct domain *d)
     d->arch.vgic.nr_regions = rdist_count;
     d->arch.vgic.rdist_regions = rdist_regions;
 
+    rwlock_init(&d->arch.vgic.pend_lpi_tree_lock);
+    radix_tree_init(&d->arch.vgic.pend_lpi_tree);
+
     /*
      * Domain 0 gets the hardware address.
      * Guests get the virtual platform layout.
@@ -1536,14 +1539,41 @@ static int vgic_v3_domain_init(struct domain *d)
 static void vgic_v3_domain_free(struct domain *d)
 {
     vgic_v3_its_free_domain(d);
+    /*
+     * It is expected that at this point all actual ITS devices have been
+     * cleaned up already. The struct pending_irq's, for which the pointers
+     * have been stored in the radix tree, are allocated and freed by device.
+     * On device unmapping all the entries are removed from the tree and
+     * the backing memory is freed.
+     */
+    radix_tree_destroy(&d->arch.vgic.pend_lpi_tree, NULL);
     xfree(d->arch.vgic.rdist_regions);
 }
 
+/*
+ * Looks up a virtual LPI number in our tree of mapped LPIs. This will return
+ * the corresponding struct pending_irq, which we also use to store the
+ * enabled and pending bit plus the priority.
+ * Returns NULL if an LPI cannot be found (or no LPIs are supported).
+ */
+static struct pending_irq *vgic_v3_lpi_to_pending(struct domain *d,
+                                                  unsigned int lpi)
+{
+    struct pending_irq *pirq;
+
+    read_lock(&d->arch.vgic.pend_lpi_tree_lock);
+    pirq = radix_tree_lookup(&d->arch.vgic.pend_lpi_tree, lpi);
+    read_unlock(&d->arch.vgic.pend_lpi_tree_lock);
+
+    return pirq;
+}
+
 static const struct vgic_ops v3_ops = {
     .vcpu_init   = vgic_v3_vcpu_init,
     .domain_init = vgic_v3_domain_init,
     .domain_free = vgic_v3_domain_free,
     .emulate_reg  = vgic_v3_emulate_reg,
+    .lpi_to_pending = vgic_v3_lpi_to_pending,
     /*
      * We use both AFF1 and AFF0 in (v)MPIDR. Thus, the max number of CPU
      * that can be supported is up to 4096(==256*16) in theory.
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 1c0da7d..b38c990 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -468,6 +468,8 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
      * are used for SPIs; the rests are used for per cpu irqs */
     if ( irq < 32 )
         n = &v->arch.vgic.pending_irqs[irq];
+    else if ( is_lpi(irq) )
+        n = v->domain->arch.vgic.handler->lpi_to_pending(v->domain, irq);
     else
         n = &v->domain->arch.vgic.pending_irqs[irq - 32];
     return n;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 7c3829d..3d8e84c 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -111,6 +111,8 @@ struct arch_domain
         uint32_t rdist_stride;              /* Re-Distributor stride */
         struct rb_root its_devices;         /* Devices mapped to an ITS */
         spinlock_t its_devices_lock;        /* Protects the its_devices tree */
+        struct radix_tree_root pend_lpi_tree; /* Stores struct pending_irq's */
+        rwlock_t pend_lpi_tree_lock;        /* Protects the pend_lpi_tree */
         unsigned int intid_bits;
 #endif
     } vgic;
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index df75064..c9075a9 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -134,6 +134,8 @@ struct vgic_ops {
     void (*domain_free)(struct domain *d);
     /* vGIC sysreg/cpregs emulate */
     bool (*emulate_reg)(struct cpu_user_regs *regs, union hsr hsr);
+    /* lookup the struct pending_irq for a given LPI interrupt */
+    struct pending_irq *(*lpi_to_pending)(struct domain *d, unsigned int vlpi);
     /* Maximum number of vCPU supported */
     const unsigned int max_vcpus;
 };
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 08/32] ARM: GIC: export and extend vgic_init_pending_irq()

[Andre Przywara]

For LPIs we later want to dynamically allocate struct pending_irqs.
So beside needing to initialize the struct from there we also need
to clean it up and re-initialize it later on.
Export vgic_init_pending_irq() and extend it to be reusable.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 xen/arch/arm/vgic.c        | 5 ++++-
 xen/include/asm-arm/vgic.h | 1 +
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index b38c990..6109d99 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -60,11 +60,14 @@ struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v, unsigned int irq)
     return vgic_get_rank(v, rank);
 }
 
-static void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
+void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
 {
+    memset(p, 0, sizeof(*p));
+
     INIT_LIST_HEAD(&p->inflight);
     INIT_LIST_HEAD(&p->lr_queue);
     p->irq = virq;
+    p->lr = GIC_INVALID_LR;
 }
 
 static void vgic_rank_init(struct vgic_irq_rank *rank, uint8_t index,
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index c9075a9..a59be6d 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -300,6 +300,7 @@ extern struct vcpu *vgic_get_target_vcpu(struct vcpu *v, unsigned int virq);
 extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq);
 extern void vgic_vcpu_inject_spi(struct domain *d, unsigned int virq);
 extern void vgic_clear_pending_irqs(struct vcpu *v);
+extern void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq);
 extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
 extern struct pending_irq *spi_to_pending(struct domain *d, unsigned int irq);
 extern struct vgic_irq_rank *vgic_rank_offset(struct vcpu *v, int b, int n, int s);
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 09/32] ARM: vGIC: cache virtual LPI priority in struct pending_irq

[Andre Przywara]

We enhance struct pending_irq to cache the priority information
for LPIs. Reading the information from there is faster than accessing
the property table from guest memory. Also it use some padding area in
the struct, so does not require more memory.
This introduces the function to retrieve the LPI priority as a vgic_ops.
Also this moves the vgic_get_virq_priority() call in
vgic_vcpu_inject_irq() to happen after the NULL check of the pending_irq
pointer, so we can rely on the pointer in the new function.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 xen/arch/arm/vgic-v2.c     |  7 +++++++
 xen/arch/arm/vgic-v3.c     | 11 +++++++++++
 xen/arch/arm/vgic.c        | 10 +++++++---
 xen/include/asm-arm/vgic.h |  2 ++
 4 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 0587569..df91940 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -709,11 +709,18 @@ static struct pending_irq *vgic_v2_lpi_to_pending(struct domain *d,
     BUG();
 }
 
+static int vgic_v2_lpi_get_priority(struct domain *d, unsigned int vlpi)
+{
+    /* Dummy function, no LPIs on a VGICv2. */
+    BUG();
+}
+
 static const struct vgic_ops vgic_v2_ops = {
     .vcpu_init   = vgic_v2_vcpu_init,
     .domain_init = vgic_v2_domain_init,
     .domain_free = vgic_v2_domain_free,
     .lpi_to_pending = vgic_v2_lpi_to_pending,
+    .lpi_get_priority = vgic_v2_lpi_get_priority,
     .max_vcpus = 8,
 };
 
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 89be7c0..c857550 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1568,12 +1568,23 @@ static struct pending_irq *vgic_v3_lpi_to_pending(struct domain *d,
     return pirq;
 }
 
+/* Retrieve the priority of an LPI from its struct pending_irq. */
+static int vgic_v3_lpi_get_priority(struct domain *d, uint32_t vlpi)
+{
+    struct pending_irq *p = vgic_v3_lpi_to_pending(d, vlpi);
+
+    ASSERT(p);
+
+    return p->lpi_priority;
+}
+
 static const struct vgic_ops v3_ops = {
     .vcpu_init   = vgic_v3_vcpu_init,
     .domain_init = vgic_v3_domain_init,
     .domain_free = vgic_v3_domain_free,
     .emulate_reg  = vgic_v3_emulate_reg,
     .lpi_to_pending = vgic_v3_lpi_to_pending,
+    .lpi_get_priority = vgic_v3_lpi_get_priority,
     /*
      * We use both AFF1 and AFF0 in (v)MPIDR. Thus, the max number of CPU
      * that can be supported is up to 4096(==256*16) in theory.
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 6109d99..5872152 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -229,8 +229,13 @@ struct vcpu *vgic_get_target_vcpu(struct vcpu *v, unsigned int virq)
 
 static int vgic_get_virq_priority(struct vcpu *v, unsigned int virq)
 {
-    struct vgic_irq_rank *rank = vgic_rank_irq(v, virq);
+    struct vgic_irq_rank *rank;
+
+    /* LPIs don't have a rank, also store their priority separately. */
+    if ( is_lpi(virq) )
+        return v->domain->arch.vgic.handler->lpi_get_priority(v->domain, virq);
 
+    rank = vgic_rank_irq(v, virq);
     return read_atomic(&rank->priority[virq & INTERRUPT_RANK_MASK]);
 }
 
@@ -504,8 +509,6 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq)
     unsigned long flags;
     bool running;
 
-    priority = vgic_get_virq_priority(v, virq);
-
     spin_lock_irqsave(&v->arch.vgic.lock, flags);
 
     n = irq_to_pending(v, virq);
@@ -531,6 +534,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq)
         goto out;
     }
 
+    priority = vgic_get_virq_priority(v, virq);
     n->priority = priority;
 
     /* the irq is enabled */
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index a59be6d..d51e277 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -72,6 +72,7 @@ struct pending_irq
 #define GIC_INVALID_LR         (uint8_t)~0
     uint8_t lr;
     uint8_t priority;
+    uint8_t lpi_priority;       /* Caches the priority if this is an LPI. */
     /* inflight is used to append instances of pending_irq to
      * vgic.inflight_irqs */
     struct list_head inflight;
@@ -136,6 +137,7 @@ struct vgic_ops {
     bool (*emulate_reg)(struct cpu_user_regs *regs, union hsr hsr);
     /* lookup the struct pending_irq for a given LPI interrupt */
     struct pending_irq *(*lpi_to_pending)(struct domain *d, unsigned int vlpi);
+    int (*lpi_get_priority)(struct domain *d, uint32_t vlpi);
     /* Maximum number of vCPU supported */
     const unsigned int max_vcpus;
 };
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 10/32] ARM: vGIC: add LPI VCPU ID to struct pending_irq

[Andre Przywara]

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 struct pending_irq, so that it is
easily accessible.
We use the remaining 8 bits of padding space for that to avoid enlarging
the size of struct pending_irq. The number of VCPUs is limited to 127
at the moment anyway, which we also confirm with a BUILD_BUG_ON.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 xen/arch/arm/vgic.c        | 4 ++++
 xen/include/asm-arm/vgic.h | 1 +
 2 files changed, 5 insertions(+)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 5872152..6b5c0b1 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -62,12 +62,16 @@ struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v, unsigned int irq)
 
 void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
 {
+    /* The lpi_vcpu_id field must be big enough to hold a VCPU ID. */
+    BUILD_BUG_ON(BIT(sizeof(p->lpi_vcpu_id) * 8) < MAX_VIRT_CPUS);
+
     memset(p, 0, sizeof(*p));
 
     INIT_LIST_HEAD(&p->inflight);
     INIT_LIST_HEAD(&p->lr_queue);
     p->irq = virq;
     p->lr = GIC_INVALID_LR;
+    p->lpi_vcpu_id = INVALID_VCPU_ID;
 }
 
 static void vgic_rank_init(struct vgic_irq_rank *rank, uint8_t index,
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index d51e277..07b56dc 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -73,6 +73,7 @@ struct pending_irq
     uint8_t lr;
     uint8_t priority;
     uint8_t lpi_priority;       /* Caches the priority if this is an LPI. */
+    uint8_t lpi_vcpu_id;        /* The VCPU for an LPI. */
     /* inflight is used to append instances of pending_irq to
      * vgic.inflight_irqs */
     struct list_head inflight;
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 11/32] ARM: GICv3: forward pending LPIs to guests

[Andre Przywara]

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 the domain ID and the virtual
LPI number quickly when the host takes an LPI. We then look up the
right VCPU in the struct pending_irq.
We use the existing injection function to let the GIC emulation deal
with this interrupt.
This introduces a do_LPI() as a hardware gic_ops.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 xen/arch/arm/gic-v2.c            |  7 ++++
 xen/arch/arm/gic-v3-lpi.c        | 76 ++++++++++++++++++++++++++++++++++++++--
 xen/arch/arm/gic-v3.c            |  1 +
 xen/arch/arm/gic.c               |  8 ++++-
 xen/include/asm-arm/domain.h     |  3 +-
 xen/include/asm-arm/gic.h        |  2 ++
 xen/include/asm-arm/gic_v3_its.h |  8 +++++
 7 files changed, 101 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 270a136..ffbe47c 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -1217,6 +1217,12 @@ static int __init gicv2_init(void)
     return 0;
 }
 
+static void gicv2_do_LPI(unsigned int lpi)
+{
+    /* No LPIs in a GICv2 */
+    BUG();
+}
+
 const static struct gic_hw_operations gicv2_ops = {
     .info                = &gicv2_info,
     .init                = gicv2_init,
@@ -1244,6 +1250,7 @@ const static struct gic_hw_operations gicv2_ops = {
     .make_hwdom_madt     = gicv2_make_hwdom_madt,
     .map_hwdom_extra_mappings = gicv2_map_hwdown_extra_mappings,
     .iomem_deny_access   = gicv2_iomem_deny_access,
+    .do_LPI              = gicv2_do_LPI,
 };
 
 /* Set up the GIC */
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index 292f2d0..438bbfe 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -47,7 +47,6 @@ union host_lpi {
     struct {
         uint32_t virt_lpi;
         uint16_t dom_id;
-        uint16_t vcpu_id;
     };
 };
 
@@ -136,6 +135,80 @@ uint64_t gicv3_get_redist_address(unsigned int cpu, bool use_pta)
         return per_cpu(lpi_redist, cpu).redist_id << 16;
 }
 
+static void vgic_vcpu_inject_lpi(struct domain *d, unsigned int virq)
+{
+    struct pending_irq *p = irq_to_pending(d->vcpu[0], virq);
+    struct vcpu *v = NULL;
+
+    if ( !p )
+        return;
+
+    if ( p->lpi_vcpu_id < d->max_vcpus )
+        v = d->vcpu[read_atomic(&p->lpi_vcpu_id)];
+
+    if ( v )
+        vgic_vcpu_inject_irq(v, virq);
+}
+
+/*
+ * Handle incoming LPIs, which are a bit special, because they are potentially
+ * numerous and also only get injected into guests. Treat them specially here,
+ * by just looking up their target vCPU and virtual LPI number and hand it
+ * over to the injection function.
+ * Please note that LPIs are edge-triggered only, also have no active state,
+ * so spurious interrupts on the host side are no issue (we can just ignore
+ * them).
+ * Also a guest cannot expect that firing interrupts that haven't been
+ * fully configured yet will reach the CPU, so we don't need to care about
+ * this special case.
+ */
+void gicv3_do_LPI(unsigned int lpi)
+{
+    struct domain *d;
+    union host_lpi *hlpip, hlpi;
+
+    irq_enter();
+
+    /* EOI the LPI already. */
+    WRITE_SYSREG32(lpi, ICC_EOIR1_EL1);
+
+    /* Find out if a guest mapped something to this physical LPI. */
+    hlpip = gic_get_host_lpi(lpi);
+    if ( !hlpip )
+        goto out;
+
+    hlpi.data = read_u64_atomic(&hlpip->data);
+
+    /*
+     * Unmapped events are marked with an invalid LPI ID. We can safely
+     * ignore them, as they have no further state and no-one can expect
+     * to see them if they have not been mapped.
+     */
+    if ( hlpi.virt_lpi == INVALID_LPI )
+        goto out;
+
+    d = rcu_lock_domain_by_id(hlpi.dom_id);
+    if ( !d )
+        goto out;
+
+    /*
+     * TODO: Investigate what to do here for potential interrupt storms.
+     * As we keep all host LPIs enabled, for disabling LPIs we would need
+     * to queue a ITS host command, which we avoid so far during a guest's
+     * runtime. Also re-enabling would trigger a host command upon the
+     * guest sending a command, which could be an attack vector for
+     * hogging the host command queue.
+     * See the thread around here for some background:
+     * https://lists.xen.org/archives/html/xen-devel/2016-12/msg00003.html
+     */
+    vgic_vcpu_inject_lpi(d, hlpi.virt_lpi);
+
+    rcu_unlock_domain(d);
+
+out:
+    irq_exit();
+}
+
 static int gicv3_lpi_allocate_pendtable(uint64_t *reg)
 {
     uint64_t val;
@@ -417,7 +490,6 @@ int gicv3_allocate_host_lpi_block(struct domain *d, uint32_t *first_lpi)
          */
         hlpi.virt_lpi = INVALID_LPI;
         hlpi.dom_id = d->domain_id;
-        hlpi.vcpu_id = INVALID_VCPU_ID;
         write_u64_atomic(&lpi_data.host_lpis[chunk][lpi_idx + i].data,
                          hlpi.data);
 
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 29c8964..8140c5f 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1674,6 +1674,7 @@ static const struct gic_hw_operations gicv3_ops = {
     .make_hwdom_dt_node  = gicv3_make_hwdom_dt_node,
     .make_hwdom_madt     = gicv3_make_hwdom_madt,
     .iomem_deny_access   = gicv3_iomem_deny_access,
+    .do_LPI              = gicv3_do_LPI,
 };
 
 static int __init gicv3_dt_preinit(struct dt_device_node *node, const void *data)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 957d516..9e32103 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -733,7 +733,13 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
             do_IRQ(regs, irq, is_fiq);
             local_irq_disable();
         }
-        else if (unlikely(irq < 16))
+        else if ( is_lpi(irq) )
+        {
+            local_irq_enable();
+            gic_hw_ops->do_LPI(irq);
+            local_irq_disable();
+        }
+        else if ( unlikely(irq < 16) )
         {
             do_sgi(regs, irq);
         }
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 3d8e84c..ebaea35 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -260,7 +260,8 @@ struct arch_vcpu
 
         /* GICv3: redistributor base and flags for this vCPU */
         paddr_t rdist_base;
-#define VGIC_V3_RDIST_LAST  (1 << 0)        /* last vCPU of the rdist */
+#define VGIC_V3_RDIST_LAST      (1 << 0)        /* last vCPU of the rdist */
+#define VGIC_V3_LPIS_ENABLED    (1 << 1)
         uint8_t flags;
     } vgic;
 
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 5d5b4cc..783937b 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -367,6 +367,8 @@ struct gic_hw_operations {
     int (*map_hwdom_extra_mappings)(struct domain *d);
     /* Deny access to GIC regions */
     int (*iomem_deny_access)(const struct domain *d);
+    /* Handle LPIs, which require special handling */
+    void (*do_LPI)(unsigned int lpi);
 };
 
 void register_gic_ops(const struct gic_hw_operations *ops);
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index 29559a3..7470779 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -134,6 +134,8 @@ void gicv3_its_dt_init(const struct dt_device_node *node);
 
 bool gicv3_its_host_has_its(void);
 
+void gicv3_do_LPI(unsigned int lpi);
+
 int gicv3_lpi_init_rdist(void __iomem * rdist_base);
 
 /* Initialize the host structures for LPIs and the host ITSes. */
@@ -175,6 +177,12 @@ static inline bool gicv3_its_host_has_its(void)
     return false;
 }
 
+static inline void gicv3_do_LPI(unsigned int lpi)
+{
+    /* We don't enable LPIs without an ITS. */
+    BUG();
+}
+
 static inline int gicv3_lpi_init_rdist(void __iomem * rdist_base)
 {
     return -ENODEV;
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 12/32] ARM: GICv3: enable ITS and LPIs on the host

[Andre Przywara]

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 <andre.przywara@arm.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
---
 xen/arch/arm/gic-v3-its.c |  4 ++++
 xen/arch/arm/gic-v3.c     | 18 ++++++++++++++++++
 2 files changed, 22 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 07280b3..aebc257 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -505,6 +505,10 @@ static int gicv3_its_init_single_its(struct host_its *hw_its)
         return -ENOMEM;
     writeq_relaxed(0, hw_its->its_base + GITS_CWRITER);
 
+    /* Now enable interrupt translation and command processing on that ITS. */
+    reg = readl_relaxed(hw_its->its_base + GITS_CTLR);
+    writel_relaxed(reg | GITS_CTLR_ENABLE, hw_its->its_base + GITS_CTLR);
+
     return 0;
 }
 
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 8140c5f..d539d6c 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -620,6 +620,21 @@ static int gicv3_enable_redist(void)
     return 0;
 }
 
+/* Enable LPIs on this redistributor (only useful when the host has an ITS). */
+static bool gicv3_enable_lpis(void)
+{
+    uint32_t val;
+
+    val = readl_relaxed(GICD_RDIST_BASE + GICR_TYPER);
+    if ( !(val & GICR_TYPER_PLPIS) )
+        return false;
+
+    val = readl_relaxed(GICD_RDIST_BASE + GICR_CTLR);
+    writel_relaxed(val | GICR_CTLR_ENABLE_LPIS, GICD_RDIST_BASE + GICR_CTLR);
+
+    return true;
+}
+
 static int __init gicv3_populate_rdist(void)
 {
     int i;
@@ -731,11 +746,14 @@ static int gicv3_cpu_init(void)
     if ( gicv3_enable_redist() )
         return -ENODEV;
 
+    /* If the host has any ITSes, enable LPIs now. */
     if ( gicv3_its_host_has_its() )
     {
         ret = gicv3_its_setup_collection(smp_processor_id());
         if ( ret )
             return ret;
+        if ( !gicv3_enable_lpis() )
+            return -EBUSY;
     }
 
     /* Set priority on PPI and SGI interrupts */
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 13/32] ARM: vGICv3: handle virtual LPI pending and property tables

[Andre Przywara]

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 pending table address while a redistributor
is live and also to protect the non-atomic vgic_reg64_extract() function
on the MMIO read side.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
---
 xen/arch/arm/vgic-v3.c       | 164 +++++++++++++++++++++++++++++++++++++++----
 xen/include/asm-arm/domain.h |   9 +++
 2 files changed, 161 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index c857550..b966fc9 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -233,12 +233,29 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, mmio_info_t *info,
         goto read_reserved;
 
     case VREG64(GICR_PROPBASER):
-        /* LPI's not implemented */
-        goto read_as_zero_64;
+        if ( !v->domain->arch.vgic.has_its )
+            goto read_as_zero_64;
+        if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
+
+        vgic_lock(v);
+        *r = vgic_reg64_extract(v->domain->arch.vgic.rdist_propbase, info);
+        vgic_unlock(v);
+        return 1;
 
     case VREG64(GICR_PENDBASER):
-        /* LPI's not implemented */
-        goto read_as_zero_64;
+    {
+        unsigned long flags;
+
+        if ( !v->domain->arch.vgic.has_its )
+            goto read_as_zero_64;
+        if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
+
+        spin_lock_irqsave(&v->arch.vgic.lock, flags);
+        *r = vgic_reg64_extract(v->arch.vgic.rdist_pendbase, info);
+        *r &= ~GICR_PENDBASER_PTZ;       /* WO, reads as 0 */
+        spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
+        return 1;
+    }
 
     case 0x0080:
         goto read_reserved;
@@ -335,11 +352,95 @@ read_unknown:
     return 1;
 }
 
+static uint64_t vgic_sanitise_field(uint64_t reg, uint64_t field_mask,
+                                    int field_shift,
+                                    uint64_t (*sanitise_fn)(uint64_t))
+{
+    uint64_t field = (reg & field_mask) >> field_shift;
+
+    field = sanitise_fn(field) << field_shift;
+
+    return (reg & ~field_mask) | field;
+}
+
+/* We want to avoid outer shareable. */
+static uint64_t vgic_sanitise_shareability(uint64_t field)
+{
+    switch ( field )
+    {
+    case GIC_BASER_OuterShareable:
+        return GIC_BASER_InnerShareable;
+    default:
+        return field;
+    }
+}
+
+/* Avoid any inner non-cacheable mapping. */
+static uint64_t vgic_sanitise_inner_cacheability(uint64_t field)
+{
+    switch ( field )
+    {
+    case GIC_BASER_CACHE_nCnB:
+    case GIC_BASER_CACHE_nC:
+        return GIC_BASER_CACHE_RaWb;
+    default:
+        return field;
+    }
+}
+
+/* Non-cacheable or same-as-inner are OK. */
+static uint64_t vgic_sanitise_outer_cacheability(uint64_t field)
+{
+    switch ( field )
+    {
+    case GIC_BASER_CACHE_SameAsInner:
+    case GIC_BASER_CACHE_nC:
+        return field;
+    default:
+        return GIC_BASER_CACHE_nC;
+    }
+}
+
+static uint64_t sanitize_propbaser(uint64_t reg)
+{
+    reg = vgic_sanitise_field(reg, GICR_PROPBASER_SHAREABILITY_MASK,
+                              GICR_PROPBASER_SHAREABILITY_SHIFT,
+                              vgic_sanitise_shareability);
+    reg = vgic_sanitise_field(reg, GICR_PROPBASER_INNER_CACHEABILITY_MASK,
+                              GICR_PROPBASER_INNER_CACHEABILITY_SHIFT,
+                              vgic_sanitise_inner_cacheability);
+    reg = vgic_sanitise_field(reg, GICR_PROPBASER_OUTER_CACHEABILITY_MASK,
+                              GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT,
+                              vgic_sanitise_outer_cacheability);
+
+    reg &= ~GICR_PROPBASER_RES0_MASK;
+
+    return reg;
+}
+
+static uint64_t sanitize_pendbaser(uint64_t reg)
+{
+    reg = vgic_sanitise_field(reg, GICR_PENDBASER_SHAREABILITY_MASK,
+                              GICR_PENDBASER_SHAREABILITY_SHIFT,
+                              vgic_sanitise_shareability);
+    reg = vgic_sanitise_field(reg, GICR_PENDBASER_INNER_CACHEABILITY_MASK,
+                              GICR_PENDBASER_INNER_CACHEABILITY_SHIFT,
+                              vgic_sanitise_inner_cacheability);
+    reg = vgic_sanitise_field(reg, GICR_PENDBASER_OUTER_CACHEABILITY_MASK,
+                              GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT,
+                              vgic_sanitise_outer_cacheability);
+
+    reg &= ~GICR_PENDBASER_RES0_MASK;
+
+    return reg;
+}
+
 static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, mmio_info_t *info,
                                           uint32_t gicr_reg,
                                           register_t r)
 {
     struct hsr_dabt dabt = info->dabt;
+    uint64_t reg;
 
     switch ( gicr_reg )
     {
@@ -370,36 +471,75 @@ static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, mmio_info_t *info,
         goto write_impl_defined;
 
     case VREG64(GICR_SETLPIR):
-        /* LPI is not implemented */
+        /* LPIs without an ITS are not implemented */
         goto write_ignore_64;
 
     case VREG64(GICR_CLRLPIR):
-        /* LPI is not implemented */
+        /* LPIs without an ITS are not implemented */
         goto write_ignore_64;
 
     case 0x0050:
         goto write_reserved;
 
     case VREG64(GICR_PROPBASER):
-        /* LPI is not implemented */
-        goto write_ignore_64;
+        if ( !v->domain->arch.vgic.has_its )
+            goto write_ignore_64;
+        if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
+
+        vgic_lock(v);
+
+        /*
+         * Writing PROPBASER with any redistributor having LPIs enabled
+         * is UNPREDICTABLE.
+         */
+        if ( !(v->domain->arch.vgic.rdists_enabled) )
+        {
+            reg = v->domain->arch.vgic.rdist_propbase;
+            vgic_reg64_update(&reg, r, info);
+            reg = sanitize_propbaser(reg);
+            v->domain->arch.vgic.rdist_propbase = reg;
+        }
+
+        vgic_unlock(v);
+
+        return 1;
 
     case VREG64(GICR_PENDBASER):
-        /* LPI is not implemented */
-        goto write_ignore_64;
+    {
+        unsigned long flags;
+
+        if ( !v->domain->arch.vgic.has_its )
+            goto write_ignore_64;
+        if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
+
+        spin_lock_irqsave(&v->arch.vgic.lock, flags);
+
+        /* Writing PENDBASER with LPIs enabled is UNPREDICTABLE. */
+        if ( !(v->arch.vgic.flags & VGIC_V3_LPIS_ENABLED) )
+        {
+            reg = v->arch.vgic.rdist_pendbase;
+            vgic_reg64_update(&reg, r, info);
+            reg = sanitize_pendbaser(reg);
+            v->arch.vgic.rdist_pendbase = reg;
+        }
+
+        spin_unlock_irqrestore(&v->arch.vgic.lock, false);
+
+        return 1;
+    }
 
     case 0x0080:
         goto write_reserved;
 
     case VREG64(GICR_INVLPIR):
-        /* LPI is not implemented */
+        /* LPIs without an ITS are not implemented */
         goto write_ignore_64;
 
     case 0x00A8:
         goto write_reserved;
 
     case VREG64(GICR_INVALLR):
-        /* LPI is not implemented */
+        /* LPIs without an ITS are not implemented */
         goto write_ignore_64;
 
     case 0x00B8:
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index ebaea35..b33f54a 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -109,11 +109,19 @@ struct arch_domain
         } *rdist_regions;
         int nr_regions;                     /* Number of rdist regions */
         uint32_t rdist_stride;              /* Re-Distributor stride */
+        unsigned long int nr_lpis;
+        uint64_t rdist_propbase;
         struct rb_root its_devices;         /* Devices mapped to an ITS */
         spinlock_t its_devices_lock;        /* Protects the its_devices tree */
         struct radix_tree_root pend_lpi_tree; /* Stores struct pending_irq's */
         rwlock_t pend_lpi_tree_lock;        /* Protects the pend_lpi_tree */
         unsigned int intid_bits;
+        /*
+         * TODO: if there are more bool's being added below, consider
+         * a flags variable instead.
+         */
+        bool rdists_enabled;                /* Is any redistributor enabled? */
+        bool has_its;
 #endif
     } vgic;
 
@@ -260,6 +268,7 @@ struct arch_vcpu
 
         /* GICv3: redistributor base and flags for this vCPU */
         paddr_t rdist_base;
+        uint64_t rdist_pendbase;
 #define VGIC_V3_RDIST_LAST      (1 << 0)        /* last vCPU of the rdist */
 #define VGIC_V3_LPIS_ENABLED    (1 << 1)
         uint8_t flags;
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 14/32] ARM: introduce vgic_access_guest_memory()

[Andre Przywara]

From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>

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:
https://patchwork.kernel.org/patch/8177251

Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
---
 xen/arch/arm/vgic.c        | 50 ++++++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/vgic.h |  3 +++
 2 files changed, 53 insertions(+)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 6b5c0b1..5751d79 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -20,6 +20,7 @@
 #include <xen/bitops.h>
 #include <xen/lib.h>
 #include <xen/init.h>
+#include <xen/domain_page.h>
 #include <xen/softirq.h>
 #include <xen/irq.h>
 #include <xen/sched.h>
@@ -637,6 +638,55 @@ void vgic_free_virq(struct domain *d, unsigned int virq)
 }
 
 /*
+ * Temporarily map one physical guest page and copy data to or from it.
+ * The data to be copied cannot cross a page boundary.
+ */
+int vgic_access_guest_memory(struct domain *d, paddr_t gpa, void *buf,
+                             uint32_t size, bool is_write)
+{
+    struct page_info *page;
+    uint64_t offset = gpa & ~PAGE_MASK;  /* Offset within the mapped page */
+    p2m_type_t p2mt;
+    void *p;
+
+    /* Do not cross a page boundary. */
+    if ( size > (PAGE_SIZE - offset) )
+    {
+        printk(XENLOG_G_ERR "d%d: vITS: memory access would cross page boundary\n",
+               d->domain_id);
+        return -EINVAL;
+    }
+
+    page = get_page_from_gfn(d, paddr_to_pfn(gpa), &p2mt, P2M_ALLOC);
+    if ( !page )
+    {
+        printk(XENLOG_G_ERR "d%d: vITS: Failed to get table entry\n",
+               d->domain_id);
+        return -EINVAL;
+    }
+
+    if ( !p2m_is_ram(p2mt) )
+    {
+        put_page(page);
+        printk(XENLOG_G_ERR "d%d: vITS: memory used by the ITS should be RAM.",
+               d->domain_id);
+        return -EINVAL;
+    }
+
+    p = __map_domain_page(page);
+
+    if ( is_write )
+        memcpy(p + offset, buf, size);
+    else
+        memcpy(buf, p + offset, size);
+
+    unmap_domain_page(p);
+    put_page(page);
+
+    return 0;
+}
+
+/*
  * Local variables:
  * mode: C
  * c-file-style: "BSD"
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 07b56dc..02732db 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -315,6 +315,9 @@ extern void register_vgic_ops(struct domain *d, const struct vgic_ops *ops);
 int vgic_v2_init(struct domain *d, int *mmio_count);
 int vgic_v3_init(struct domain *d, int *mmio_count);
 
+int vgic_access_guest_memory(struct domain *d, paddr_t gpa, void *buf,
+                             uint32_t size, bool_t is_write);
+
 extern int domain_vgic_register(struct domain *d, int *mmio_count);
 extern int vcpu_vgic_free(struct vcpu *v);
 extern bool vgic_to_sgi(struct vcpu *v, register_t sgir,
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 15/32] ARM: vGICv3: re-use vgic_reg64_check_access

[Andre Przywara]

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 <andre.przywara@arm.com>
Acked-by: Julien Grall <julien.grall@arm.com>
---
 xen/arch/arm/vgic-v3.c          | 9 ---------
 xen/include/asm-arm/vgic-emul.h | 9 +++++++++
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index b966fc9..e2e5bc1 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -161,15 +161,6 @@ static void vgic_store_irouter(struct domain *d, struct vgic_irq_rank *rank,
     }
 }
 
-static inline bool vgic_reg64_check_access(struct hsr_dabt dabt)
-{
-    /*
-     * 64 bits registers can be accessible using 32-bit and 64-bit unless
-     * stated otherwise (See 8.1.3 ARM IHI 0069A).
-     */
-    return ( dabt.size == DABT_DOUBLE_WORD || dabt.size == DABT_WORD );
-}
-
 static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, mmio_info_t *info,
                                          uint32_t gicr_reg,
                                          register_t *r)
diff --git a/xen/include/asm-arm/vgic-emul.h b/xen/include/asm-arm/vgic-emul.h
index 184a1f0..e52fbaa 100644
--- a/xen/include/asm-arm/vgic-emul.h
+++ b/xen/include/asm-arm/vgic-emul.h
@@ -12,6 +12,15 @@
 #define VRANGE32(start, end) start ... end + 3
 #define VRANGE64(start, end) start ... end + 7
 
+/*
+ * 64 bits registers can be accessible using 32-bit and 64-bit unless
+ * stated otherwise (See 8.1.3 ARM IHI 0069A).
+ */
+static inline bool vgic_reg64_check_access(struct hsr_dabt dabt)
+{
+    return ( dabt.size == DABT_DOUBLE_WORD || dabt.size == DABT_WORD );
+}
+
 #endif /* __ASM_ARM_VGIC_EMUL_H__ */
 
 /*
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 16/32] ARM: vGIC: advertise LPI support

[Andre Przywara]

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.
For Dom0 we report the same number of interrupts identifiers as the
host, whereas DomUs get a number fixed at 10 bits for the moments, which
covers all SPIs. Also we fix a slight inaccuracy here, since the
number of interrupt identifier specified in GICD_TYPER depends on the
stream interface and is independent from the number of actually wired
SPIs.
This also removes a "TBD" comment, as we now populate the processor
number in the GICR_TYPER register.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 xen/arch/arm/vgic-v3.c | 76 +++++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 69 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index e2e5bc1..134e1b0 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -170,8 +170,19 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, mmio_info_t *info,
     switch ( gicr_reg )
     {
     case VREG32(GICR_CTLR):
-        /* We have not implemented LPI's, read zero */
-        goto read_as_zero_32;
+    {
+        unsigned long flags;
+
+        if ( !v->domain->arch.vgic.has_its )
+            goto read_as_zero_32;
+        if ( dabt.size != DABT_WORD ) goto bad_width;
+
+        spin_lock_irqsave(&v->arch.vgic.lock, flags);
+        *r = vgic_reg32_extract(!!(v->arch.vgic.flags & VGIC_V3_LPIS_ENABLED),
+                                info);
+        spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
+        return 1;
+    }
 
     case VREG32(GICR_IIDR):
         if ( dabt.size != DABT_WORD ) goto bad_width;
@@ -183,16 +194,20 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, mmio_info_t *info,
         uint64_t typer, aff;
 
         if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
-        /* TBD: Update processor id in [23:8] when ITS support is added */
         aff = (MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 3) << 56 |
                MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 48 |
                MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 1) << 40 |
                MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 0) << 32);
         typer = aff;
+        /* We use the VCPU ID as the redistributor ID in bits[23:8] */
+        typer |= v->vcpu_id << GICR_TYPER_PROC_NUM_SHIFT;
 
         if ( v->arch.vgic.flags & VGIC_V3_RDIST_LAST )
             typer |= GICR_TYPER_LAST;
 
+        if ( v->domain->arch.vgic.has_its )
+            typer |= GICR_TYPER_PLPIS;
+
         *r = vgic_reg64_extract(typer, info);
 
         return 1;
@@ -426,6 +441,33 @@ static uint64_t sanitize_pendbaser(uint64_t reg)
     return reg;
 }
 
+static void vgic_vcpu_enable_lpis(struct vcpu *v)
+{
+    uint64_t reg = v->domain->arch.vgic.rdist_propbase;
+    unsigned int nr_lpis = BIT((reg & 0x1f) + 1);
+
+    /* rdists_enabled is protected by the domain lock. */
+    ASSERT(spin_is_locked(&v->domain->arch.vgic.lock));
+
+    if ( nr_lpis < LPI_OFFSET )
+        nr_lpis = 0;
+    else
+        nr_lpis -= LPI_OFFSET;
+
+    if ( !v->domain->arch.vgic.rdists_enabled )
+    {
+        v->domain->arch.vgic.nr_lpis = nr_lpis;
+        v->domain->arch.vgic.rdists_enabled = true;
+        /*
+         * Make sure the per-domain rdists_enabled flag has been set before
+         * enabling this particular redistributor.
+         */
+        smp_mb();
+    }
+
+    v->arch.vgic.flags |= VGIC_V3_LPIS_ENABLED;
+}
+
 static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, mmio_info_t *info,
                                           uint32_t gicr_reg,
                                           register_t r)
@@ -436,8 +478,26 @@ static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, mmio_info_t *info,
     switch ( gicr_reg )
     {
     case VREG32(GICR_CTLR):
-        /* LPI's not implemented */
-        goto write_ignore_32;
+    {
+        unsigned long flags;
+
+        if ( !v->domain->arch.vgic.has_its )
+            goto write_ignore_32;
+        if ( dabt.size != DABT_WORD ) goto bad_width;
+
+        vgic_lock(v);                   /* protects rdists_enabled */
+        spin_lock_irqsave(&v->arch.vgic.lock, flags);
+
+        /* LPIs can only be enabled once, but never disabled again. */
+        if ( (r & GICR_CTLR_ENABLE_LPIS) &&
+             !(v->arch.vgic.flags & VGIC_V3_LPIS_ENABLED) )
+            vgic_vcpu_enable_lpis(v);
+
+        spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
+        vgic_unlock(v);
+
+        return 1;
+    }
 
     case VREG32(GICR_IIDR):
         /* RO */
@@ -1045,7 +1105,6 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, mmio_info_t *info,
          * Number of interrupt identifier bits supported by the GIC
          * Stream Protocol Interface
          */
-        unsigned int irq_bits = get_count_order(vgic_num_irqs(v->domain));
         /*
          * Number of processors that may be used as interrupt targets when ARE
          * bit is zero. The maximum is 8.
@@ -1058,7 +1117,10 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, mmio_info_t *info,
         typer = ((ncpus - 1) << GICD_TYPE_CPUS_SHIFT |
                  DIV_ROUND_UP(v->domain->arch.vgic.nr_spis, 32));
 
-        typer |= (irq_bits - 1) << GICD_TYPE_ID_BITS_SHIFT;
+        if ( v->domain->arch.vgic.has_its )
+            typer |= GICD_TYPE_LPIS;
+
+        typer |= (v->domain->arch.vgic.intid_bits - 1) << GICD_TYPE_ID_BITS_SHIFT;
 
         *r = vgic_reg32_extract(typer, info);
 
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 17/32] ARM: vITS: add command handling stub and MMIO emulation

[Andre Przywara]

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).
This fixes a misnomer in our virtual ITS structure, where the spec is
confusingly using ID_bits in GITS_TYPER to denote the number of event IDs
(in contrast to GICD_TYPER, where it means number of LPIs).

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 xen/arch/arm/vgic-v3-its.c       | 578 ++++++++++++++++++++++++++++++++++++++-
 xen/include/asm-arm/gic_v3_its.h |   3 +
 2 files changed, 580 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 065ffe2..2c7f22f 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -19,6 +19,16 @@
  * along with this program; If not, see <http://www.gnu.org/licenses/>.
  */
 
+/*
+ * Locking order:
+ *
+ * its->vcmd_lock                        (protects the command queue)
+ *     its->its_lock                     (protects the translation tables)
+ *         d->its_devices_lock           (protects the device RB tree)
+ *             v->vgic.lock              (protects the struct pending_irq)
+ *                 d->pend_lpi_tree_lock (protects the radix tree)
+ */
+
 #include <xen/bitops.h>
 #include <xen/config.h>
 #include <xen/domain_page.h>
@@ -43,7 +53,7 @@
 struct virt_its {
     struct domain *d;
     unsigned int devid_bits;
-    unsigned int intid_bits;
+    unsigned int evid_bits;
     spinlock_t vcmd_lock;       /* Protects the virtual command buffer, which */
     uint64_t cwriter;           /* consists of CWRITER and CREADR and those   */
     uint64_t creadr;            /* shadow variables cwriter and creadr. */
@@ -53,6 +63,7 @@ struct virt_its {
     uint64_t baser_dev, baser_coll;     /* BASER0 and BASER1 for the guest */
     unsigned int max_collections;
     unsigned int max_devices;
+    /* changing "enabled" requires to hold *both* the vcmd_lock and its_lock */
     bool enabled;
 };
 
@@ -67,6 +78,571 @@ struct vits_itte
     uint16_t pad;
 };
 
+/*
+ * Our collection table encoding:
+ * Each entry just contains the VCPU ID of the respective vCPU.
+ */
+typedef uint16_t coll_table_entry_t;
+
+/*
+ * Our device table encodings:
+ * Contains the guest physical address of the Interrupt Translation Table in
+ * bits [51:8], and the size of it is encoded as the number of bits minus one
+ * in the lowest 5 bits of the word.
+ */
+typedef uint64_t dev_table_entry_t;
+#define DEV_TABLE_ITT_ADDR(x) ((x) & GENMASK(51, 8))
+#define DEV_TABLE_ITT_SIZE(x) (BIT(((x) & GENMASK(4, 0)) + 1))
+#define DEV_TABLE_ENTRY(addr, bits)                     \
+        (((addr) & GENMASK(51, 8)) | (((bits) - 1) & GENMASK(4, 0)))
+
+#define GITS_BASER_RO_MASK       (GITS_BASER_TYPE_MASK | \
+                                  (0x1fL << GITS_BASER_ENTRY_SIZE_SHIFT))
+
+/**************************************
+ * Functions that handle ITS commands *
+ **************************************/
+
+static uint64_t its_cmd_mask_field(uint64_t *its_cmd, unsigned int word,
+                                   unsigned int shift, unsigned int size)
+{
+    return ((its_cmd[word])) >> (shift & (BIT(size) - 1));
+}
+
+#define its_cmd_get_command(cmd)        its_cmd_mask_field(cmd, 0,  0,  8)
+#define its_cmd_get_deviceid(cmd)       its_cmd_mask_field(cmd, 0, 32, 32)
+#define its_cmd_get_size(cmd)           its_cmd_mask_field(cmd, 1,  0,  5)
+#define its_cmd_get_id(cmd)             its_cmd_mask_field(cmd, 1,  0, 32)
+#define its_cmd_get_physical_id(cmd)    its_cmd_mask_field(cmd, 1, 32, 32)
+#define its_cmd_get_collection(cmd)     its_cmd_mask_field(cmd, 2,  0, 16)
+#define its_cmd_get_target_addr(cmd)    its_cmd_mask_field(cmd, 2, 16, 32)
+#define its_cmd_get_validbit(cmd)       its_cmd_mask_field(cmd, 2, 63,  1)
+#define its_cmd_get_ittaddr(cmd)        (its_cmd_mask_field(cmd, 2, 8, 44) << 8)
+
+#define ITS_CMD_BUFFER_SIZE(baser)      ((((baser) & 0xff) + 1) << 12)
+#define ITS_CMD_OFFSET(reg)             ((reg) & GENMASK(19, 5))
+
+/*
+ * Must be called with the vcmd_lock held.
+ * TODO: Investigate whether we can be smarter here and don't need to hold
+ * the lock all of the time.
+ */
+static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its)
+{
+    paddr_t addr = its->cbaser & GENMASK(51, 12);
+    uint64_t command[4];
+
+    ASSERT(spin_is_locked(&its->vcmd_lock));
+
+    if ( its->cwriter >= ITS_CMD_BUFFER_SIZE(its->cbaser) )
+        return -1;
+
+    while ( its->creadr != its->cwriter )
+    {
+        int ret;
+
+        ret = vgic_access_guest_memory(d, addr + its->creadr,
+                                       command, sizeof(command), false);
+        if ( ret )
+            return ret;
+
+        switch ( its_cmd_get_command(command) )
+        {
+        case GITS_CMD_SYNC:
+            /* We handle ITS commands synchronously, so we ignore SYNC. */
+            break;
+        default:
+            gdprintk(XENLOG_WARNING, "vGITS: unhandled ITS command %lu\n",
+                     its_cmd_get_command(command));
+            break;
+        }
+
+        write_u64_atomic(&its->creadr, (its->creadr + ITS_CMD_SIZE) %
+                         ITS_CMD_BUFFER_SIZE(its->cbaser));
+
+        if ( ret )
+            gdprintk(XENLOG_WARNING,
+                     "vGITS: ITS command error %d while handling command %lu\n",
+                     ret, its_cmd_get_command(command));
+    }
+
+    return 0;
+}
+
+/*****************************
+ * ITS registers read access *
+ *****************************/
+
+/* Identifying as an ARM IP, using "X" as the product ID. */
+#define GITS_IIDR_VALUE                 0x5800034c
+
+static int vgic_v3_its_mmio_read(struct vcpu *v, mmio_info_t *info,
+                                 register_t *r, void *priv)
+{
+    struct virt_its *its = priv;
+    uint64_t reg;
+
+    switch ( info->gpa & 0xffff )
+    {
+    case VREG32(GITS_CTLR):
+    {
+        /*
+         * We try to avoid waiting for the command queue lock and report
+         * non-quiescent if that lock is already taken.
+         */
+        bool have_cmd_lock;
+
+        if ( info->dabt.size != DABT_WORD ) goto bad_width;
+
+        have_cmd_lock = spin_trylock(&its->vcmd_lock);
+        reg = its->enabled ? GITS_CTLR_ENABLE : 0;
+
+        if ( have_cmd_lock && its->cwriter == its->creadr )
+            reg |= GITS_CTLR_QUIESCENT;
+
+        if ( have_cmd_lock )
+            spin_unlock(&its->vcmd_lock);
+
+        *r = vgic_reg32_extract(reg, info);
+        break;
+    }
+
+    case VREG32(GITS_IIDR):
+        if ( info->dabt.size != DABT_WORD ) goto bad_width;
+        *r = vgic_reg32_extract(GITS_IIDR_VALUE, info);
+        break;
+
+    case VREG64(GITS_TYPER):
+        if ( !vgic_reg64_check_access(info->dabt) ) goto bad_width;
+
+        reg = GITS_TYPER_PHYSICAL;
+        reg |= (sizeof(struct vits_itte) - 1) << GITS_TYPER_ITT_SIZE_SHIFT;
+        reg |= (its->evid_bits - 1) << GITS_TYPER_IDBITS_SHIFT;
+        reg |= (its->devid_bits - 1) << GITS_TYPER_DEVIDS_SHIFT;
+        *r = vgic_reg64_extract(reg, info);
+        break;
+
+    case VRANGE32(0x0018, 0x001C):
+        goto read_reserved;
+    case VRANGE32(0x0020, 0x003C):
+        goto read_impl_defined;
+    case VRANGE32(0x0040, 0x007C):
+        goto read_reserved;
+
+    case VREG64(GITS_CBASER):
+        if ( !vgic_reg64_check_access(info->dabt) ) goto bad_width;
+        spin_lock(&its->its_lock);
+        *r = vgic_reg64_extract(its->cbaser, info);
+        spin_unlock(&its->its_lock);
+        break;
+
+    case VREG64(GITS_CWRITER):
+        if ( !vgic_reg64_check_access(info->dabt) ) goto bad_width;
+
+        /* CWRITER is only written by the guest, so no extra locking here. */
+        reg = its->cwriter;
+        *r = vgic_reg64_extract(reg, info);
+        break;
+
+    case VREG64(GITS_CREADR):
+        if ( !vgic_reg64_check_access(info->dabt) ) goto bad_width;
+
+        /*
+         * Lockless access, to avoid waiting for the whole command queue to be
+         * finished completely. Xen updates its->creadr atomically after each
+         * command has been handled, this allows other VCPUs to monitor the
+         * progress.
+         */
+        reg = read_u64_atomic(&its->creadr);
+        *r = vgic_reg64_extract(reg, info);
+        break;
+
+    case VRANGE64(0x0098, 0x00F8):
+        goto read_reserved;
+
+    case VREG64(GITS_BASER0):           /* device table */
+        if ( !vgic_reg64_check_access(info->dabt) ) goto bad_width;
+        spin_lock(&its->its_lock);
+        *r = vgic_reg64_extract(its->baser_dev, info);
+        spin_unlock(&its->its_lock);
+        break;
+
+    case VREG64(GITS_BASER1):           /* collection table */
+        if ( !vgic_reg64_check_access(info->dabt) ) goto bad_width;
+        spin_lock(&its->its_lock);
+        *r = vgic_reg64_extract(its->baser_coll, info);
+        spin_unlock(&its->its_lock);
+        break;
+
+    case VRANGE64(GITS_BASER2, GITS_BASER7):
+        goto read_as_zero_64;
+    case VRANGE32(0x0140, 0xBFFC):
+        goto read_reserved;
+    case VRANGE32(0xC000, 0xFFCC):
+        goto read_impl_defined;
+    case VRANGE32(0xFFD0, 0xFFE4):
+        goto read_impl_defined;
+
+    case VREG32(GITS_PIDR2):
+        if ( info->dabt.size != DABT_WORD ) goto bad_width;
+        *r = vgic_reg32_extract(GIC_PIDR2_ARCH_GICv3, info);
+        break;
+
+    case VRANGE32(0xFFEC, 0xFFFC):
+        goto read_impl_defined;
+
+    default:
+        printk(XENLOG_G_ERR
+               "%pv: vGITS: unhandled read r%d offset %#04lx\n",
+               v, info->dabt.reg, (unsigned long)info->gpa & 0xffff);
+        return 0;
+    }
+
+    return 1;
+
+read_as_zero_64:
+    if ( !vgic_reg64_check_access(info->dabt) ) goto bad_width;
+    *r = 0;
+
+    return 1;
+
+read_impl_defined:
+    printk(XENLOG_G_DEBUG
+           "%pv: vGITS: RAZ on implementation defined register offset %#04lx\n",
+           v, info->gpa & 0xffff);
+    *r = 0;
+    return 1;
+
+read_reserved:
+    printk(XENLOG_G_DEBUG
+           "%pv: vGITS: RAZ on reserved register offset %#04lx\n",
+           v, info->gpa & 0xffff);
+    *r = 0;
+    return 1;
+
+bad_width:
+    printk(XENLOG_G_ERR "vGITS: bad read width %d r%d offset %#04lx\n",
+           info->dabt.size, info->dabt.reg, (unsigned long)info->gpa & 0xffff);
+    domain_crash_synchronous();
+
+    return 0;
+}
+
+/******************************
+ * ITS registers write access *
+ ******************************/
+
+static unsigned int its_baser_table_size(uint64_t baser)
+{
+    unsigned int ret, page_size[4] = {SZ_4K, SZ_16K, SZ_64K, SZ_64K};
+
+    ret = page_size[(baser >> GITS_BASER_PAGE_SIZE_SHIFT) & 3];
+
+    return ret * ((baser & GITS_BASER_SIZE_MASK) + 1);
+}
+
+static unsigned int its_baser_nr_entries(uint64_t baser)
+{
+    unsigned int entry_size = GITS_BASER_ENTRY_SIZE(baser);
+
+    return its_baser_table_size(baser) / entry_size;
+}
+
+/* Must be called with the ITS lock held. */
+static bool vgic_v3_verify_its_status(struct virt_its *its, bool status)
+{
+    ASSERT(spin_is_locked(&its->its_lock));
+
+    if ( !status )
+        return false;
+
+    if ( !(its->cbaser & GITS_VALID_BIT) ||
+         !(its->baser_dev & GITS_VALID_BIT) ||
+         !(its->baser_coll & GITS_VALID_BIT) )
+    {
+        printk(XENLOG_G_WARNING "d%d tried to enable ITS without having the tables configured.\n",
+               its->d->domain_id);
+        return false;
+    }
+
+    /*
+     * TODO: Protect against a guest crafting ITS tables.
+     * The spec says that "at the time of the new allocation for use by the ITS"
+     * all tables must contain zeroes. We could enforce this here by clearing
+     * all the tables, but this would be moot since at the moment the guest
+     * can change the tables at any point in time anyway. Right now there are
+     * expectations about the tables being consistent (a VCPU lock protecting
+     * an LPI), which should go away with proper per-IRQ locking.
+     * So for now we ignore this issue and rely on Dom0 not doing bad things.
+     */
+    ASSERT(is_hardware_domain(its->d));
+
+    return true;
+}
+
+static void sanitize_its_base_reg(uint64_t *reg)
+{
+    uint64_t r = *reg;
+
+    /* Avoid outer shareable. */
+    switch ( (r >> GITS_BASER_SHAREABILITY_SHIFT) & 0x03 )
+    {
+    case GIC_BASER_OuterShareable:
+        r &= ~GITS_BASER_SHAREABILITY_MASK;
+        r |= GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
+        break;
+    default:
+        break;
+    }
+
+    /* Avoid any inner non-cacheable mapping. */
+    switch ( (r >> GITS_BASER_INNER_CACHEABILITY_SHIFT) & 0x07 )
+    {
+    case GIC_BASER_CACHE_nCnB:
+    case GIC_BASER_CACHE_nC:
+        r &= ~GITS_BASER_INNER_CACHEABILITY_MASK;
+        r |= GIC_BASER_CACHE_RaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
+        break;
+    default:
+        break;
+    }
+
+    /* Only allow non-cacheable or same-as-inner. */
+    switch ( (r >> GITS_BASER_OUTER_CACHEABILITY_SHIFT) & 0x07 )
+    {
+    case GIC_BASER_CACHE_SameAsInner:
+    case GIC_BASER_CACHE_nC:
+        break;
+    default:
+        r &= ~GITS_BASER_OUTER_CACHEABILITY_MASK;
+        r |= GIC_BASER_CACHE_nC << GITS_BASER_OUTER_CACHEABILITY_SHIFT;
+        break;
+    }
+
+    *reg = r;
+}
+
+static int vgic_v3_its_mmio_write(struct vcpu *v, mmio_info_t *info,
+                                  register_t r, void *priv)
+{
+    struct domain *d = v->domain;
+    struct virt_its *its = priv;
+    uint64_t reg;
+    uint32_t reg32;
+
+    switch ( info->gpa & 0xffff )
+    {
+    case VREG32(GITS_CTLR):
+    {
+        uint32_t ctlr;
+
+        if ( info->dabt.size != DABT_WORD ) goto bad_width;
+
+        /*
+         * We need to take the vcmd_lock to prevent a guest from disabling
+         * the ITS while commands are still processed.
+         */
+        spin_lock(&its->vcmd_lock);
+        spin_lock(&its->its_lock);
+        ctlr = its->enabled ? GITS_CTLR_ENABLE : 0;
+        reg32 = ctlr;
+        vgic_reg32_update(&reg32, r, info);
+
+        if ( ctlr ^ reg32 )
+            its->enabled = vgic_v3_verify_its_status(its,
+                                                     reg32 & GITS_CTLR_ENABLE);
+        spin_unlock(&its->its_lock);
+        spin_unlock(&its->vcmd_lock);
+        return 1;
+    }
+
+    case VREG32(GITS_IIDR):
+        goto write_ignore_32;
+
+    case VREG32(GITS_TYPER):
+        goto write_ignore_32;
+
+    case VRANGE32(0x0018, 0x001C):
+        goto write_reserved;
+    case VRANGE32(0x0020, 0x003C):
+        goto write_impl_defined;
+    case VRANGE32(0x0040, 0x007C):
+        goto write_reserved;
+
+    case VREG64(GITS_CBASER):
+        if ( !vgic_reg64_check_access(info->dabt) ) goto bad_width;
+
+        spin_lock(&its->its_lock);
+        /* Changing base registers with the ITS enabled is UNPREDICTABLE. */
+        if ( its->enabled )
+        {
+            spin_unlock(&its->its_lock);
+            gdprintk(XENLOG_WARNING,
+                     "vGITS: tried to change CBASER with the ITS enabled.\n");
+            return 1;
+        }
+
+        reg = its->cbaser;
+        vgic_reg64_update(&reg, r, info);
+        sanitize_its_base_reg(&reg);
+
+        its->cbaser = reg;
+        its->creadr = 0;
+        spin_unlock(&its->its_lock);
+
+        return 1;
+
+    case VREG64(GITS_CWRITER):
+        if ( !vgic_reg64_check_access(info->dabt) ) goto bad_width;
+
+        spin_lock(&its->vcmd_lock);
+        reg = ITS_CMD_OFFSET(its->cwriter);
+        vgic_reg64_update(&reg, r, info);
+        its->cwriter = ITS_CMD_OFFSET(reg);
+
+        if ( its->enabled )
+            if ( vgic_its_handle_cmds(d, its) )
+                gdprintk(XENLOG_WARNING, "error handling ITS commands\n");
+
+        spin_unlock(&its->vcmd_lock);
+
+        return 1;
+
+    case VREG64(GITS_CREADR):
+        goto write_ignore_64;
+
+    case VRANGE32(0x0098, 0x00FC):
+        goto write_reserved;
+
+    case VREG64(GITS_BASER0):           /* device table */
+        if ( !vgic_reg64_check_access(info->dabt) ) goto bad_width;
+
+        spin_lock(&its->its_lock);
+
+        /*
+         * Changing base registers with the ITS enabled is UNPREDICTABLE,
+         * we choose to ignore it, but warn.
+         */
+        if ( its->enabled )
+        {
+            spin_unlock(&its->its_lock);
+            gdprintk(XENLOG_WARNING, "vGITS: tried to change BASER with the ITS enabled.\n");
+
+            return 1;
+        }
+
+        reg = its->baser_dev;
+        vgic_reg64_update(&reg, r, info);
+
+        /* We don't support indirect tables for now. */
+        reg &= ~(GITS_BASER_RO_MASK | GITS_BASER_INDIRECT);
+        reg |= (sizeof(dev_table_entry_t) - 1) << GITS_BASER_ENTRY_SIZE_SHIFT;
+        reg |= GITS_BASER_TYPE_DEVICE << GITS_BASER_TYPE_SHIFT;
+        sanitize_its_base_reg(&reg);
+
+        if ( reg & GITS_VALID_BIT )
+        {
+            its->max_devices = its_baser_nr_entries(reg);
+            if ( its->max_devices > BIT(its->devid_bits) )
+                its->max_devices = BIT(its->devid_bits);
+        }
+        else
+            its->max_devices = 0;
+
+        its->baser_dev = reg;
+        spin_unlock(&its->its_lock);
+        return 1;
+
+    case VREG64(GITS_BASER1):           /* collection table */
+        if ( !vgic_reg64_check_access(info->dabt) ) goto bad_width;
+
+        spin_lock(&its->its_lock);
+        /*
+         * Changing base registers with the ITS enabled is UNPREDICTABLE,
+         * we choose to ignore it, but warn.
+         */
+        if ( its->enabled )
+        {
+            spin_unlock(&its->its_lock);
+            gdprintk(XENLOG_INFO, "vGITS: tried to change BASER with the ITS enabled.\n");
+            return 1;
+        }
+
+        reg = its->baser_coll;
+        vgic_reg64_update(&reg, r, info);
+        /* No indirect tables for the collection table. */
+        reg &= ~(GITS_BASER_RO_MASK | GITS_BASER_INDIRECT);
+        reg |= (sizeof(coll_table_entry_t) - 1) << GITS_BASER_ENTRY_SIZE_SHIFT;
+        reg |= GITS_BASER_TYPE_COLLECTION << GITS_BASER_TYPE_SHIFT;
+        sanitize_its_base_reg(&reg);
+
+        if ( reg & GITS_VALID_BIT )
+            its->max_collections = its_baser_nr_entries(reg);
+        else
+            its->max_collections = 0;
+        its->baser_coll = reg;
+        spin_unlock(&its->its_lock);
+        return 1;
+
+    case VRANGE64(GITS_BASER2, GITS_BASER7):
+        goto write_ignore_64;
+
+    case VRANGE32(0x0140, 0xBFFC):
+        goto write_reserved;
+    case VRANGE32(0xC000, 0xFFCC):
+        goto write_impl_defined;
+    case VRANGE32(0xFFD0, 0xFFE4):      /* IMPDEF identification registers */
+        goto write_impl_defined;
+
+    case VREG32(GITS_PIDR2):
+        goto write_ignore_32;
+
+    case VRANGE32(0xFFEC, 0xFFFC):      /* IMPDEF identification registers */
+        goto write_impl_defined;
+
+    default:
+        printk(XENLOG_G_ERR
+               "%pv: vGITS: unhandled write r%d offset %#04lx\n",
+               v, info->dabt.reg, (unsigned long)info->gpa & 0xffff);
+        return 0;
+    }
+
+    return 1;
+
+write_ignore_64:
+    if ( !vgic_reg64_check_access(info->dabt) ) goto bad_width;
+    return 1;
+
+write_ignore_32:
+    if ( info->dabt.size != DABT_WORD ) goto bad_width;
+    return 1;
+
+write_impl_defined:
+    printk(XENLOG_G_DEBUG
+           "%pv: vGITS: WI on implementation defined register offset %#04lx\n",
+           v, info->gpa & 0xffff);
+    return 1;
+
+write_reserved:
+    printk(XENLOG_G_DEBUG
+           "%pv: vGITS: WI on implementation defined register offset %#04lx\n",
+           v, info->gpa & 0xffff);
+    return 1;
+
+bad_width:
+    printk(XENLOG_G_ERR "vGITS: bad write width %d r%d offset %#08lx\n",
+           info->dabt.size, info->dabt.reg, (unsigned long)info->gpa & 0xffff);
+
+    domain_crash_synchronous();
+
+    return 0;
+}
+
+static const struct mmio_handler_ops vgic_its_mmio_handler = {
+    .read  = vgic_v3_its_mmio_read,
+    .write = vgic_v3_its_mmio_write,
+};
+
 int vgic_v3_its_init_domain(struct domain *d)
 {
     spin_lock_init(&d->arch.vgic.its_devices_lock);
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index 7470779..40f4ef5 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -35,6 +35,7 @@
 #define GITS_BASER5                     0x128
 #define GITS_BASER6                     0x130
 #define GITS_BASER7                     0x138
+#define GITS_PIDR2                      GICR_PIDR2
 
 /* Register bits */
 #define GITS_VALID_BIT                  BIT(63)
@@ -57,6 +58,7 @@
 #define GITS_TYPER_ITT_SIZE_MASK        (0xfUL << GITS_TYPER_ITT_SIZE_SHIFT)
 #define GITS_TYPER_ITT_SIZE(r)          ((((r) & GITS_TYPER_ITT_SIZE_MASK) >> \
                                                  GITS_TYPER_ITT_SIZE_SHIFT) + 1)
+#define GITS_TYPER_PHYSICAL             (1U << 0)
 
 #define GITS_BASER_INDIRECT             BIT(62)
 #define GITS_BASER_INNER_CACHEABILITY_SHIFT        59
@@ -76,6 +78,7 @@
                         (((reg >> GITS_BASER_ENTRY_SIZE_SHIFT) & 0x1f) + 1)
 #define GITS_BASER_SHAREABILITY_SHIFT   10
 #define GITS_BASER_PAGE_SIZE_SHIFT      8
+#define GITS_BASER_SIZE_MASK            0xff
 #define GITS_BASER_SHAREABILITY_MASK   (0x3ULL << GITS_BASER_SHAREABILITY_SHIFT)
 #define GITS_BASER_OUTER_CACHEABILITY_MASK   (0x7ULL << GITS_BASER_OUTER_CACHEABILITY_SHIFT)
 #define GITS_BASER_INNER_CACHEABILITY_MASK   (0x7ULL << GITS_BASER_INNER_CACHEABILITY_SHIFT)
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 18/32] ARM: vITS: introduce translation table walks

[Andre Przywara]

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 them, to avoid the guest tampering with
them meanwhile.

To allow compiling without warnings, we declare two functions as
non-static for the moment, which two later patches will fix.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 xen/arch/arm/vgic-v3-its.c | 167 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 167 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 2c7f22f..8f4a9e1 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -96,9 +96,176 @@ typedef uint64_t dev_table_entry_t;
 #define DEV_TABLE_ENTRY(addr, bits)                     \
         (((addr) & GENMASK(51, 8)) | (((bits) - 1) & GENMASK(4, 0)))
 
+#define UNMAPPED_COLLECTION      ((coll_table_entry_t)~0)
 #define GITS_BASER_RO_MASK       (GITS_BASER_TYPE_MASK | \
                                   (0x1fL << GITS_BASER_ENTRY_SIZE_SHIFT))
 
+/*
+ * The physical address is encoded slightly differently depending on
+ * the used page size: the highest four bits are stored in the lowest
+ * four bits of the field for 64K pages.
+ */
+static paddr_t get_baser_phys_addr(uint64_t reg)
+{
+    if ( reg & BIT(9) )
+        return (reg & GENMASK(47, 16)) |
+                ((reg & GENMASK(15, 12)) << 36);
+    else
+        return reg & GENMASK(47, 12);
+}
+
+/* Must be called with the ITS lock held. */
+static struct vcpu *get_vcpu_from_collection(struct virt_its *its,
+                                             uint16_t collid)
+{
+    paddr_t addr = get_baser_phys_addr(its->baser_coll);
+    coll_table_entry_t vcpu_id;
+    int ret;
+
+    ASSERT(spin_is_locked(&its->its_lock));
+
+    if ( collid >= its->max_collections )
+        return NULL;
+
+    ret = vgic_access_guest_memory(its->d,
+                                   addr + collid * sizeof(coll_table_entry_t),
+                                   &vcpu_id, sizeof(coll_table_entry_t), false);
+    if ( ret )
+        return NULL;
+
+    if ( vcpu_id == UNMAPPED_COLLECTION || vcpu_id >= its->d->max_vcpus )
+        return NULL;
+
+    return its->d->vcpu[vcpu_id];
+}
+
+/*
+ * Lookup the address of the Interrupt Translation Table associated with
+ * that device ID.
+ * TODO: add support for walking indirect tables.
+ */
+static int its_get_itt(struct virt_its *its, uint32_t devid,
+                       dev_table_entry_t *itt)
+{
+    paddr_t addr = get_baser_phys_addr(its->baser_dev);
+
+    if ( devid >= its->max_devices )
+        return -EINVAL;
+
+    return vgic_access_guest_memory(its->d,
+                                    addr + devid * sizeof(dev_table_entry_t),
+                                    itt, sizeof(*itt), false);
+}
+
+/*
+ * Lookup the address of the Interrupt Translation Table associated with
+ * a device ID and return the address of the ITTE belonging to the event ID
+ * (which is an index into that table).
+ */
+static paddr_t its_get_itte_address(struct virt_its *its,
+                                    uint32_t devid, uint32_t evid)
+{
+    dev_table_entry_t itt;
+    int ret;
+
+    ret = its_get_itt(its, devid, &itt);
+    if ( ret )
+        return INVALID_PADDR;
+
+    if ( evid >= DEV_TABLE_ITT_SIZE(itt) ||
+         DEV_TABLE_ITT_ADDR(itt) == INVALID_PADDR )
+        return INVALID_PADDR;
+
+    return DEV_TABLE_ITT_ADDR(itt) + evid * sizeof(struct vits_itte);
+}
+
+/*
+ * Queries the collection and device tables to get the vCPU and virtual
+ * LPI number for a given guest event. This first accesses the guest memory
+ * to resolve the address of the ITTE, then reads the ITTE entry at this
+ * address and puts the result in vcpu_ptr and vlpi_ptr.
+ * Must be called with the ITS lock held.
+ */
+static bool read_itte_locked(struct virt_its *its, uint32_t devid,
+                             uint32_t evid, struct vcpu **vcpu_ptr,
+                             uint32_t *vlpi_ptr)
+{
+    paddr_t addr;
+    struct vits_itte itte;
+    struct vcpu *vcpu;
+
+    ASSERT(spin_is_locked(&its->its_lock));
+
+    addr = its_get_itte_address(its, devid, evid);
+    if ( addr == INVALID_PADDR )
+        return false;
+
+    if ( vgic_access_guest_memory(its->d, addr, &itte, sizeof(itte), false) )
+        return false;
+
+    vcpu = get_vcpu_from_collection(its, itte.collection);
+    if ( !vcpu )
+        return false;
+
+    *vcpu_ptr = vcpu;
+    *vlpi_ptr = itte.vlpi;
+    return true;
+}
+
+/*
+ * This function takes care of the locking by taking the its_lock itself, so
+ * a caller shall not hold this. Before returning, the lock is dropped again.
+ */
+bool read_itte(struct virt_its *its, uint32_t devid, uint32_t evid,
+               struct vcpu **vcpu_ptr, uint32_t *vlpi_ptr)
+{
+    bool ret;
+
+    spin_lock(&its->its_lock);
+    ret = read_itte_locked(its, devid, evid, vcpu_ptr, vlpi_ptr);
+    spin_unlock(&its->its_lock);
+
+    return ret;
+}
+
+/*
+ * Queries the collection and device tables to translate the device ID and
+ * event ID and find the appropriate ITTE. The given collection ID and the
+ * virtual LPI number are then stored into that entry.
+ * If vcpu_ptr is provided, returns the VCPU belonging to that collection.
+ * Must be called with the ITS lock held.
+ */
+bool write_itte_locked(struct virt_its *its, uint32_t devid,
+                       uint32_t evid, uint32_t collid, uint32_t vlpi,
+                       struct vcpu **vcpu_ptr)
+{
+    paddr_t addr;
+    struct vits_itte itte;
+
+    ASSERT(spin_is_locked(&its->its_lock));
+
+    if ( collid >= its->max_collections )
+        return false;
+
+    if ( vlpi >= its->d->arch.vgic.nr_lpis )
+        return false;
+
+    addr = its_get_itte_address(its, devid, evid);
+    if ( addr == INVALID_PADDR )
+        return false;
+
+    itte.collection = collid;
+    itte.vlpi = vlpi;
+
+    if ( vgic_access_guest_memory(its->d, addr, &itte, sizeof(itte), true) )
+        return false;
+
+    if ( vcpu_ptr )
+        *vcpu_ptr = get_vcpu_from_collection(its, collid);
+
+    return true;
+}
+
 /**************************************
  * Functions that handle ITS commands *
  **************************************/
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 19/32] ARM: vITS: provide access to struct pending_irq

[Andre Przywara]

For each device we allocate one struct pending_irq for each virtual
event (MSI).
Provide a helper function which returns the pointer to the appropriate
struct, to be able to find the right struct when given a virtual
deviceID/eventID pair.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 xen/arch/arm/gic-v3-its.c        | 59 ++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/gic_v3_its.h |  4 +++
 2 files changed, 63 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index aebc257..38f0840 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -800,6 +800,65 @@ out:
     return ret;
 }
 
+/* Must be called with the its_device_lock held. */
+static struct its_device *get_its_device(struct domain *d, paddr_t vdoorbell,
+                                         uint32_t vdevid)
+{
+    struct rb_node *node = d->arch.vgic.its_devices.rb_node;
+    struct its_device *dev;
+
+    ASSERT(spin_is_locked(&d->arch.vgic.its_devices_lock));
+
+    while (node)
+    {
+        int cmp;
+
+        dev = rb_entry(node, struct its_device, rbnode);
+        cmp = compare_its_guest_devices(dev, vdoorbell, vdevid);
+
+        if ( !cmp )
+            return dev;
+
+        if ( cmp > 0 )
+            node = node->rb_left;
+        else
+            node = node->rb_right;
+    }
+
+    return NULL;
+}
+
+static struct pending_irq *get_event_pending_irq(struct domain *d,
+                                                 paddr_t vdoorbell_address,
+                                                 uint32_t vdevid,
+                                                 uint32_t eventid,
+                                                 uint32_t *host_lpi)
+{
+    struct its_device *dev;
+    struct pending_irq *pirq = NULL;
+
+    spin_lock(&d->arch.vgic.its_devices_lock);
+    dev = get_its_device(d, vdoorbell_address, vdevid);
+    if ( dev && eventid < dev->eventids )
+    {
+        pirq = &dev->pend_irqs[eventid];
+        if ( host_lpi )
+            *host_lpi = dev->host_lpi_blocks[eventid / LPI_BLOCK] +
+                        (eventid % LPI_BLOCK);
+    }
+    spin_unlock(&d->arch.vgic.its_devices_lock);
+
+    return pirq;
+}
+
+struct pending_irq *gicv3_its_get_event_pending_irq(struct domain *d,
+                                                    paddr_t vdoorbell_address,
+                                                    uint32_t vdevid,
+                                                    uint32_t eventid)
+{
+    return get_event_pending_irq(d, vdoorbell_address, vdevid, eventid, NULL);
+}
+
 /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
 void gicv3_its_dt_init(const struct dt_device_node *node)
 {
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index 40f4ef5..d162e89 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -169,6 +169,10 @@ int gicv3_its_map_guest_device(struct domain *d,
 int gicv3_allocate_host_lpi_block(struct domain *d, uint32_t *first_lpi);
 void gicv3_free_host_lpi_block(uint32_t first_lpi);
 
+struct pending_irq *gicv3_its_get_event_pending_irq(struct domain *d,
+                                                    paddr_t vdoorbell_address,
+                                                    uint32_t vdevid,
+                                                    uint32_t veventid);
 #else
 
 static inline void gicv3_its_dt_init(const struct dt_device_node *node)
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 20/32] ARM: vITS: handle INT command

[Andre Przywara]

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 <andre.przywara@arm.com>
---
 xen/arch/arm/vgic-v3-its.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 8f4a9e1..80a4625 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -286,6 +286,24 @@ static uint64_t its_cmd_mask_field(uint64_t *its_cmd, unsigned int word,
 #define its_cmd_get_validbit(cmd)       its_cmd_mask_field(cmd, 2, 63,  1)
 #define its_cmd_get_ittaddr(cmd)        (its_cmd_mask_field(cmd, 2, 8, 44) << 8)
 
+static int its_handle_int(struct virt_its *its, uint64_t *cmdptr)
+{
+    uint32_t devid = its_cmd_get_deviceid(cmdptr);
+    uint32_t eventid = its_cmd_get_id(cmdptr);
+    struct vcpu *vcpu;
+    uint32_t vlpi;
+
+    if ( !read_itte(its, devid, eventid, &vcpu, &vlpi) )
+        return -1;
+
+    if ( vlpi == INVALID_LPI )
+        return -1;
+
+    vgic_vcpu_inject_irq(vcpu, vlpi);
+
+    return 0;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)      ((((baser) & 0xff) + 1) << 12)
 #define ITS_CMD_OFFSET(reg)             ((reg) & GENMASK(19, 5))
 
@@ -315,6 +333,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its)
 
         switch ( its_cmd_get_command(command) )
         {
+        case GITS_CMD_INT:
+            ret = its_handle_int(its, command);
+            break;
         case GITS_CMD_SYNC:
             /* We handle ITS commands synchronously, so we ignore SYNC. */
             break;
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 21/32] ARM: vITS: handle MAPC command

[Andre Przywara]

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 <andre.przywara@arm.com>
Acked-by: Julien Grall <julien.grall@arm.com>
---
 xen/arch/arm/vgic-v3-its.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 80a4625..77205bc 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -115,6 +115,25 @@ static paddr_t get_baser_phys_addr(uint64_t reg)
 }
 
 /* Must be called with the ITS lock held. */
+static int its_set_collection(struct virt_its *its, uint16_t collid,
+                              coll_table_entry_t vcpu_id)
+{
+    paddr_t addr = get_baser_phys_addr(its->baser_coll);
+
+    /* The collection table entry must be able to store a VCPU ID. */
+    BUILD_BUG_ON(BIT(sizeof(coll_table_entry_t) * 8) < MAX_VIRT_CPUS);
+
+    ASSERT(spin_is_locked(&its->its_lock));
+
+    if ( collid >= its->max_collections )
+        return -ENOENT;
+
+    return vgic_access_guest_memory(its->d,
+                                    addr + collid * sizeof(coll_table_entry_t),
+                                    &vcpu_id, sizeof(vcpu_id), true);
+}
+
+/* Must be called with the ITS lock held. */
 static struct vcpu *get_vcpu_from_collection(struct virt_its *its,
                                              uint16_t collid)
 {
@@ -304,6 +323,29 @@ static int its_handle_int(struct virt_its *its, uint64_t *cmdptr)
     return 0;
 }
 
+static int its_handle_mapc(struct virt_its *its, uint64_t *cmdptr)
+{
+    uint32_t collid = its_cmd_get_collection(cmdptr);
+    uint64_t rdbase = its_cmd_mask_field(cmdptr, 2, 16, 44);
+
+    if ( collid >= its->max_collections )
+        return -1;
+
+    if ( rdbase >= its->d->max_vcpus )
+        return -1;
+
+    spin_lock(&its->its_lock);
+
+    if ( its_cmd_get_validbit(cmdptr) )
+        its_set_collection(its, collid, rdbase);
+    else
+        its_set_collection(its, collid, UNMAPPED_COLLECTION);
+
+    spin_unlock(&its->its_lock);
+
+    return 0;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)      ((((baser) & 0xff) + 1) << 12)
 #define ITS_CMD_OFFSET(reg)             ((reg) & GENMASK(19, 5))
 
@@ -336,6 +378,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its)
         case GITS_CMD_INT:
             ret = its_handle_int(its, command);
             break;
+        case GITS_CMD_MAPC:
+            ret = its_handle_mapc(its, command);
+            break;
         case GITS_CMD_SYNC:
             /* We handle ITS commands synchronously, so we ignore SYNC. */
             break;
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 22/32] ARM: vITS: handle CLEAR command

[Andre Przywara]

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 <andre.przywara@arm.com>
---
 xen/arch/arm/vgic-v3-its.c | 59 ++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 57 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 77205bc..3ba49db 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -52,6 +52,7 @@
  */
 struct virt_its {
     struct domain *d;
+    paddr_t doorbell_address;
     unsigned int devid_bits;
     unsigned int evid_bits;
     spinlock_t vcmd_lock;       /* Protects the virtual command buffer, which */
@@ -235,8 +236,8 @@ static bool read_itte_locked(struct virt_its *its, uint32_t devid,
  * This function takes care of the locking by taking the its_lock itself, so
  * a caller shall not hold this. Before returning, the lock is dropped again.
  */
-bool read_itte(struct virt_its *its, uint32_t devid, uint32_t evid,
-               struct vcpu **vcpu_ptr, uint32_t *vlpi_ptr)
+static bool read_itte(struct virt_its *its, uint32_t devid, uint32_t evid,
+                      struct vcpu **vcpu_ptr, uint32_t *vlpi_ptr)
 {
     bool ret;
 
@@ -346,6 +347,57 @@ static int its_handle_mapc(struct virt_its *its, uint64_t *cmdptr)
     return 0;
 }
 
+/*
+ * CLEAR removes the pending state from an LPI. */
+static int its_handle_clear(struct virt_its *its, uint64_t *cmdptr)
+{
+    uint32_t devid = its_cmd_get_deviceid(cmdptr);
+    uint32_t eventid = its_cmd_get_id(cmdptr);
+    struct pending_irq *p;
+    struct vcpu *vcpu;
+    uint32_t vlpi;
+    unsigned long flags;
+    int ret = -1;
+
+    spin_lock(&its->its_lock);
+
+    /* Translate the DevID/EvID pair into a vCPU/vLPI pair. */
+    if ( !read_itte_locked(its, devid, eventid, &vcpu, &vlpi) )
+        goto out_unlock;
+
+    p = gicv3_its_get_event_pending_irq(its->d, its->doorbell_address,
+                                        devid, eventid);
+    /* Protect against an invalid LPI number. */
+    if ( unlikely(!p) )
+        goto out_unlock;
+
+    /*
+     * TODO: This relies on the VCPU being correct in the ITS tables.
+     * This can be fixed by either using a per-IRQ lock or by using
+     * the VCPU ID from the pending_irq instead.
+     */
+    spin_lock_irqsave(&vcpu->arch.vgic.lock, flags);
+
+    /*
+     * If the LPI is already visible on the guest, it is too late to
+     * clear the pending state. However this is a benign race that can
+     * happen on real hardware, too: If the LPI has already been forwarded
+     * to a CPU interface, a CLEAR request reaching the redistributor has
+     * no effect on that LPI anymore. Since LPIs are edge triggered and
+     * have no active state, we don't need to care about this here.
+     */
+    if ( !test_bit(GIC_IRQ_GUEST_VISIBLE, &p->status) )
+        gic_remove_irq(vcpu, p);
+
+    spin_unlock_irqrestore(&vcpu->arch.vgic.lock, flags);
+    ret = 0;
+
+out_unlock:
+    spin_unlock(&its->its_lock);
+
+    return ret;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)      ((((baser) & 0xff) + 1) << 12)
 #define ITS_CMD_OFFSET(reg)             ((reg) & GENMASK(19, 5))
 
@@ -375,6 +427,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its)
 
         switch ( its_cmd_get_command(command) )
         {
+        case GITS_CMD_CLEAR:
+            ret = its_handle_clear(its, command);
+            break;
         case GITS_CMD_INT:
             ret = its_handle_int(its, command);
             break;
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 23/32] ARM: vITS: handle MAPD command

[Andre Przywara]

The MAPD command maps a device by associating a memory region for
storing ITEs with a certain device ID. Since it features a valid bit,
MAPD also covers the "unmap" functionality, which we also cover here.
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 command and create
the required tables. We take care of rolling back actions should one
step fail.
Upon unmapping a device we make sure we clean up all associated
resources and release the memory again.
We use our existing guest memory access function to find the right ITT
entry and store the mapping there (in guest memory).

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 xen/arch/arm/gic-v3-its.c        |  17 +++++
 xen/arch/arm/gic-v3-lpi.c        |  17 +++++
 xen/arch/arm/vgic-v3-its.c       | 143 +++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/gic_v3_its.h |   5 ++
 4 files changed, 182 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 38f0840..8864e0b 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -859,6 +859,23 @@ struct pending_irq *gicv3_its_get_event_pending_irq(struct domain *d,
     return get_event_pending_irq(d, vdoorbell_address, vdevid, eventid, NULL);
 }
 
+int gicv3_remove_guest_event(struct domain *d, paddr_t vdoorbell_address,
+                             uint32_t vdevid, uint32_t eventid)
+{
+    uint32_t host_lpi = INVALID_LPI;
+
+    if ( !get_event_pending_irq(d, vdoorbell_address, vdevid, eventid,
+                                &host_lpi) )
+        return -EINVAL;
+
+    if ( host_lpi == INVALID_LPI )
+        return -EINVAL;
+
+    gicv3_lpi_update_host_entry(host_lpi, d->domain_id, INVALID_LPI);
+
+    return 0;
+}
+
 /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
 void gicv3_its_dt_init(const struct dt_device_node *node)
 {
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index 438bbfe..5f6e855 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -209,6 +209,23 @@ out:
     irq_exit();
 }
 
+void gicv3_lpi_update_host_entry(uint32_t host_lpi, int domain_id,
+                                 uint32_t virt_lpi)
+{
+    union host_lpi *hlpip, hlpi;
+
+    ASSERT(host_lpi >= LPI_OFFSET);
+
+    host_lpi -= LPI_OFFSET;
+
+    hlpip = &lpi_data.host_lpis[host_lpi / HOST_LPIS_PER_PAGE][host_lpi % HOST_LPIS_PER_PAGE];
+
+    hlpi.virt_lpi = virt_lpi;
+    hlpi.dom_id = domain_id;
+
+    write_u64_atomic(&hlpip->data, hlpi.data);
+}
+
 static int gicv3_lpi_allocate_pendtable(uint64_t *reg)
 {
     uint64_t val;
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 3ba49db..e9b1cb4 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -159,6 +159,21 @@ static struct vcpu *get_vcpu_from_collection(struct virt_its *its,
     return its->d->vcpu[vcpu_id];
 }
 
+/* Set the address of an ITT for a given device ID. */
+static int its_set_itt_address(struct virt_its *its, uint32_t devid,
+                               paddr_t itt_address, uint32_t nr_bits)
+{
+    paddr_t addr = get_baser_phys_addr(its->baser_dev);
+    dev_table_entry_t itt_entry = DEV_TABLE_ENTRY(itt_address, nr_bits);
+
+    if ( devid >= its->max_devices )
+        return -ENOENT;
+
+    return vgic_access_guest_memory(its->d,
+                                    addr + devid * sizeof(dev_table_entry_t),
+                                    &itt_entry, sizeof(itt_entry), true);
+}
+
 /*
  * Lookup the address of the Interrupt Translation Table associated with
  * that device ID.
@@ -398,6 +413,131 @@ out_unlock:
     return ret;
 }
 
+/* Must be called with the ITS lock held. */
+static int its_discard_event(struct virt_its *its,
+                             uint32_t vdevid, uint32_t vevid)
+{
+    struct pending_irq *p;
+    unsigned long flags;
+    struct vcpu *vcpu;
+    uint32_t vlpi;
+
+    ASSERT(spin_is_locked(&its->its_lock));
+
+    if ( !read_itte_locked(its, vdevid, vevid, &vcpu, &vlpi) )
+        return -ENOENT;
+
+    if ( vlpi == INVALID_LPI )
+        return -ENOENT;
+
+    /*
+     * TODO: This relies on the VCPU being correct in the ITS tables.
+     * This can be fixed by either using a per-IRQ lock or by using
+     * the VCPU ID from the pending_irq instead.
+     */
+    spin_lock_irqsave(&vcpu->arch.vgic.lock, flags);
+
+    /* Remove the pending_irq from the tree. */
+    write_lock(&its->d->arch.vgic.pend_lpi_tree_lock);
+    p = radix_tree_delete(&its->d->arch.vgic.pend_lpi_tree, vlpi);
+    write_unlock(&its->d->arch.vgic.pend_lpi_tree_lock);
+
+    if ( !p )
+    {
+        spin_unlock_irqrestore(&vcpu->arch.vgic.lock, flags);
+
+        return -ENOENT;
+    }
+
+    /* Cleanup the pending_irq and disconnect it from the LPI. */
+    list_del_init(&p->inflight);
+    list_del_init(&p->lr_queue);
+    vgic_init_pending_irq(p, INVALID_LPI);
+
+    spin_unlock_irqrestore(&vcpu->arch.vgic.lock, flags);
+
+    /* Remove the corresponding host LPI entry */
+    return gicv3_remove_guest_event(its->d, its->doorbell_address,
+                                    vdevid, vevid);
+}
+
+static void its_unmap_device(struct virt_its *its, uint32_t devid)
+{
+    dev_table_entry_t itt;
+    uint64_t evid;
+
+    spin_lock(&its->its_lock);
+
+    if ( its_get_itt(its, devid, &itt) )
+        goto out;
+
+    /*
+     * For DomUs we need to check that the number of events per device
+     * is really limited, otherwise looping over all events can take too
+     * long for a guest. This ASSERT can then be removed if that is
+     * covered.
+     */
+    ASSERT(is_hardware_domain(its->d));
+
+    for ( evid = 0; evid < DEV_TABLE_ITT_SIZE(itt); evid++ )
+        /* Don't care about errors here, clean up as much as possible. */
+        its_discard_event(its, devid, evid);
+
+out:
+    spin_unlock(&its->its_lock);
+}
+
+static int its_handle_mapd(struct virt_its *its, uint64_t *cmdptr)
+{
+    /* size and devid get validated by the functions called below. */
+    uint32_t devid = its_cmd_get_deviceid(cmdptr);
+    unsigned int size = its_cmd_get_size(cmdptr) + 1;
+    bool valid = its_cmd_get_validbit(cmdptr);
+    paddr_t itt_addr = its_cmd_get_ittaddr(cmdptr);
+    int ret;
+
+    /* Sanitize the number of events. */
+    if ( valid && (size > its->evid_bits) )
+        return -1;
+
+    if ( !valid )
+        /* Discard all events and remove pending LPIs. */
+        its_unmap_device(its, devid);
+
+    /*
+     * There is no easy and clean way for Xen to know the ITS device ID of a
+     * particular (PCI) device, so we have to rely on the guest telling
+     * us about it. For *now* we are just using the device ID *Dom0* uses,
+     * because the driver there has the actual knowledge.
+     * Eventually this will be replaced with a dedicated hypercall to
+     * announce pass-through of devices.
+     */
+    if ( is_hardware_domain(its->d) )
+    {
+
+        /*
+         * Dom0's ITSes are mapped 1:1, so both addresses are the same.
+         * Also the device IDs are equal.
+         */
+        ret = gicv3_its_map_guest_device(its->d, its->doorbell_address, devid,
+                                         its->doorbell_address, devid,
+                                         BIT(size), valid);
+        if ( ret && valid )
+            return ret;
+    }
+
+    spin_lock(&its->its_lock);
+
+    if ( valid )
+        ret = its_set_itt_address(its, devid, itt_addr, size);
+    else
+        ret = its_set_itt_address(its, devid, INVALID_PADDR, 1);
+
+    spin_unlock(&its->its_lock);
+
+    return ret;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)      ((((baser) & 0xff) + 1) << 12)
 #define ITS_CMD_OFFSET(reg)             ((reg) & GENMASK(19, 5))
 
@@ -436,6 +576,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its)
         case GITS_CMD_MAPC:
             ret = its_handle_mapc(its, command);
             break;
+        case GITS_CMD_MAPD:
+            ret = its_handle_mapd(its, command);
+            break;
         case GITS_CMD_SYNC:
             /* We handle ITS commands synchronously, so we ignore SYNC. */
             break;
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index d162e89..e78dadf 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -173,6 +173,11 @@ struct pending_irq *gicv3_its_get_event_pending_irq(struct domain *d,
                                                     paddr_t vdoorbell_address,
                                                     uint32_t vdevid,
                                                     uint32_t veventid);
+int gicv3_remove_guest_event(struct domain *d, paddr_t vdoorbell_address,
+                                     uint32_t vdevid, uint32_t veventid);
+void gicv3_lpi_update_host_entry(uint32_t host_lpi, int domain_id,
+                                 uint32_t virt_lpi);
+
 #else
 
 static inline void gicv3_its_dt_init(const struct dt_device_node *node)
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 24/32] ARM: GICv3: handle unmapped LPIs

[Andre Przywara]

When LPIs get unmapped by a guest, they might still be in some LR of
some VCPU. Nevertheless we remove the corresponding pending_irq
(possibly freeing it), and detect this case (irq_to_pending() returns
NULL) when the LR gets cleaned up later.
However a *new* LPI may get mapped with the same number while the old
LPI is *still* in some LR. To avoid getting the wrong state, we mark
every newly mapped LPI as PRISTINE, which means: has never been in an
LR before. If we detect the LPI in an LR anyway, it must have been an
older one, which we can simply retire.
Before inserting such a PRISTINE LPI into an LR, we must make sure that
it's not already in another LR, as the architecture forbids two
interrupts with the same virtual IRQ number on one CPU.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 xen/arch/arm/gic.c         | 51 ++++++++++++++++++++++++++++++++++++++++++----
 xen/include/asm-arm/vgic.h |  6 ++++++
 2 files changed, 53 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 9e32103..da5ba86 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -375,6 +375,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
 {
     ASSERT(!local_irq_is_enabled());
 
+    clear_bit(GIC_IRQ_GUEST_PRISTINE_LPI, &p->status);
+
     gic_hw_ops->update_lr(lr, p, state);
 
     set_bit(GIC_IRQ_GUEST_VISIBLE, &p->status);
@@ -441,6 +443,40 @@ void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq)
 #endif
 }
 
+/*
+ * Find an unused LR to insert an IRQ into, starting with the LR given
+ * by @lr. If this new interrupt is a PRISTINE LPI, scan the other LRs to
+ * avoid inserting the same IRQ twice. This situation can occur when an
+ * event gets discarded while the LPI is in an LR, and a new LPI with the
+ * same number gets mapped quickly afterwards.
+ */
+static unsigned int gic_find_unused_lr(struct vcpu *v,
+                                       struct pending_irq *p,
+                                       unsigned int lr)
+{
+    unsigned int nr_lrs = gic_hw_ops->info->nr_lrs;
+    unsigned long *lr_mask = (unsigned long *) &this_cpu(lr_mask);
+    struct gic_lr lr_val;
+
+    ASSERT(spin_is_locked(&v->arch.vgic.lock));
+
+    if ( test_bit(GIC_IRQ_GUEST_PRISTINE_LPI, &p->status) )
+    {
+        unsigned int used_lr = 0;
+
+        while ( (used_lr = find_next_bit(lr_mask, nr_lrs, used_lr)) < nr_lrs )
+        {
+            gic_hw_ops->read_lr(used_lr, &lr_val);
+            if ( lr_val.virq == p->irq )
+                return used_lr;
+        }
+    }
+
+    lr = find_next_zero_bit(lr_mask, nr_lrs, lr);
+
+    return lr;
+}
+
 void gic_raise_guest_irq(struct vcpu *v, unsigned int virtual_irq,
         unsigned int priority)
 {
@@ -456,7 +492,8 @@ void gic_raise_guest_irq(struct vcpu *v, unsigned int virtual_irq,
 
     if ( v == current && list_empty(&v->arch.vgic.lr_pending) )
     {
-        i = find_first_zero_bit(&this_cpu(lr_mask), nr_lrs);
+        i = gic_find_unused_lr(v, p, 0);
+
         if (i < nr_lrs) {
             set_bit(i, &this_cpu(lr_mask));
             gic_set_lr(i, p, GICH_LR_PENDING);
@@ -479,8 +516,14 @@ static void gic_update_one_lr(struct vcpu *v, int i)
     gic_hw_ops->read_lr(i, &lr_val);
     irq = lr_val.virq;
     p = irq_to_pending(v, irq);
-    /* An LPI might have been unmapped, in which case we just clean up here. */
-    if ( unlikely(!p) )
+    /*
+     * An LPI might have been unmapped, in which case we just clean up here.
+     * If that LPI is marked as PRISTINE, the information in the LR is bogus,
+     * as it belongs to a previous, already unmapped LPI. So we discard it
+     * here as well.
+     */
+    if ( unlikely(!p) ||
+         test_and_clear_bit(GIC_IRQ_GUEST_PRISTINE_LPI, &p->status) )
     {
         ASSERT(is_lpi(irq));
 
@@ -590,7 +633,7 @@ static void gic_restore_pending_irqs(struct vcpu *v)
     inflight_r = &v->arch.vgic.inflight_irqs;
     list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
     {
-        lr = find_next_zero_bit(&this_cpu(lr_mask), nr_lrs, lr);
+        lr = gic_find_unused_lr(v, p, lr);
         if ( lr >= nr_lrs )
         {
             /* No more free LRs: find a lower priority irq to evict */
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 02732db..3fc4ceb 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -60,12 +60,18 @@ struct pending_irq
      * vcpu while it is still inflight and on an GICH_LR register on the
      * old vcpu.
      *
+     * GIC_IRQ_GUEST_PRISTINE_LPI: the IRQ is a newly mapped LPI, which
+     * has never been in an LR before. This means that any trace of an
+     * LPI with the same number in an LR must be from an older LPI, which
+     * has been unmapped before.
+     *
      */
 #define GIC_IRQ_GUEST_QUEUED   0
 #define GIC_IRQ_GUEST_ACTIVE   1
 #define GIC_IRQ_GUEST_VISIBLE  2
 #define GIC_IRQ_GUEST_ENABLED  3
 #define GIC_IRQ_GUEST_MIGRATING   4
+#define GIC_IRQ_GUEST_PRISTINE_LPI  5
     unsigned long status;
     struct irq_desc *desc; /* only set it the irq corresponds to a physical irq */
     unsigned int irq;
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 25/32] ARM: vITS: handle MAPTI/MAPI command

[Andre Przywara]

The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
pair and actually instantiates LPI interrupts. MAPI is just a variant
of this comment, where the LPI ID is the same as the event ID.
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 domain and the virtual LPI number in the respective
host LPI entry, we also initialize and add the already allocated
struct pending_irq to our radix tree, so that we can now easily find it
by its virtual LPI number.
We also read the property table to update the enabled bit and the
priority for our new LPI, as we might have missed this during an earlier
INVALL call (which only checks mapped LPIs). But we make sure that the
property table is actually valid, as all redistributors might still
be disabled at this point.
Since write_itte_locked() now sees its first usage, we change the
declaration to static.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 xen/arch/arm/gic-v3-its.c        |  27 ++++++++
 xen/arch/arm/vgic-v3-its.c       | 138 ++++++++++++++++++++++++++++++++++++++-
 xen/include/asm-arm/gic_v3_its.h |   3 +
 3 files changed, 165 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 8864e0b..41fff64 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -876,6 +876,33 @@ int gicv3_remove_guest_event(struct domain *d, paddr_t vdoorbell_address,
     return 0;
 }
 
+/*
+ * Connects the event ID for an already assigned device to the given VCPU/vLPI
+ * pair. The corresponding physical LPI is already mapped on the host side
+ * (when assigning the physical device to the guest), so we just connect the
+ * target VCPU/vLPI pair to that interrupt to inject it properly if it fires.
+ * Returns a pointer to the already allocated struct pending_irq that is
+ * meant to be used by that event.
+ */
+struct pending_irq *gicv3_assign_guest_event(struct domain *d,
+                                             paddr_t vdoorbell_address,
+                                             uint32_t vdevid, uint32_t eventid,
+                                             uint32_t virt_lpi)
+{
+    struct pending_irq *pirq;
+    uint32_t host_lpi = 0;
+
+    pirq = get_event_pending_irq(d, vdoorbell_address, vdevid, eventid,
+                                 &host_lpi);
+
+    if ( !pirq )
+        return NULL;
+
+    gicv3_lpi_update_host_entry(host_lpi, d->domain_id, virt_lpi);
+
+    return pirq;
+}
+
 /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
 void gicv3_its_dt_init(const struct dt_device_node *node)
 {
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index e9b1cb4..c350fa5 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -270,9 +270,9 @@ static bool read_itte(struct virt_its *its, uint32_t devid, uint32_t evid,
  * If vcpu_ptr is provided, returns the VCPU belonging to that collection.
  * Must be called with the ITS lock held.
  */
-bool write_itte_locked(struct virt_its *its, uint32_t devid,
-                       uint32_t evid, uint32_t collid, uint32_t vlpi,
-                       struct vcpu **vcpu_ptr)
+static bool write_itte_locked(struct virt_its *its, uint32_t devid,
+                              uint32_t evid, uint32_t collid, uint32_t vlpi,
+                              struct vcpu **vcpu_ptr)
 {
     paddr_t addr;
     struct vits_itte itte;
@@ -413,6 +413,42 @@ out_unlock:
     return ret;
 }
 
+/*
+ * For a given virtual LPI read the enabled bit and priority from the virtual
+ * property table and update the virtual IRQ's state in the given pending_irq.
+ * Must be called with the respective VGIC VCPU lock held.
+ */
+static int update_lpi_property(struct domain *d, struct pending_irq *p)
+{
+    paddr_t addr;
+    uint8_t property;
+    int ret;
+
+    /*
+     * If no redistributor has its LPIs enabled yet, we can't access the
+     * property table. In this case we just can't update the properties,
+     * but this should not be an error from an ITS point of view.
+     */
+    if ( !read_atomic(&d->arch.vgic.rdists_enabled) )
+        return 0;
+
+    addr = d->arch.vgic.rdist_propbase & GENMASK(51, 12);
+
+    ret = vgic_access_guest_memory(d, addr + p->irq - LPI_OFFSET,
+                                   &property, sizeof(property), false);
+    if ( ret )
+        return ret;
+
+    write_atomic(&p->lpi_priority, property & LPI_PROP_PRIO_MASK);
+
+    if ( property & LPI_PROP_ENABLED )
+        set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
+    else
+        clear_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
+
+    return 0;
+}
+
 /* Must be called with the ITS lock held. */
 static int its_discard_event(struct virt_its *its,
                              uint32_t vdevid, uint32_t vevid)
@@ -538,6 +574,98 @@ static int its_handle_mapd(struct virt_its *its, uint64_t *cmdptr)
     return ret;
 }
 
+static int its_handle_mapti(struct virt_its *its, uint64_t *cmdptr)
+{
+    uint32_t devid = its_cmd_get_deviceid(cmdptr);
+    uint32_t eventid = its_cmd_get_id(cmdptr);
+    uint32_t intid = its_cmd_get_physical_id(cmdptr), _intid;
+    uint16_t collid = its_cmd_get_collection(cmdptr);
+    struct pending_irq *pirq;
+    struct vcpu *vcpu = NULL;
+    int ret = -1;
+
+    if ( its_cmd_get_command(cmdptr) == GITS_CMD_MAPI )
+        intid = eventid;
+
+    spin_lock(&its->its_lock);
+    /*
+     * Check whether there is a valid existing mapping. If yes, behavior is
+     * unpredictable, we choose to ignore this command here.
+     * This makes sure we start with a pristine pending_irq below.
+     */
+    if ( read_itte_locked(its, devid, eventid, &vcpu, &_intid) &&
+         _intid != INVALID_LPI )
+    {
+        spin_unlock(&its->its_lock);
+        return -1;
+    }
+
+    /* Enter the mapping in our virtual ITS tables. */
+    if ( !write_itte_locked(its, devid, eventid, collid, intid, &vcpu) )
+    {
+        spin_unlock(&its->its_lock);
+        return -1;
+    }
+
+    spin_unlock(&its->its_lock);
+
+    /*
+     * Connect this virtual LPI to the corresponding host LPI, which is
+     * determined by the same device ID and event ID on the host side.
+     * This returns us the corresponding, still unused pending_irq.
+     */
+    pirq = gicv3_assign_guest_event(its->d, its->doorbell_address,
+                                    devid, eventid, intid);
+    if ( !pirq )
+        goto out_remove_mapping;
+
+    vgic_init_pending_irq(pirq, intid);
+
+    /*
+     * Now read the guest's property table to initialize our cached state.
+     * We don't need the VGIC VCPU lock here, because the pending_irq isn't
+     * in the radix tree yet.
+     */
+    ret = update_lpi_property(its->d, pirq);
+    if ( ret )
+        goto out_remove_host_entry;
+
+    pirq->lpi_vcpu_id = vcpu->vcpu_id;
+    /*
+     * Mark this LPI as new, so any older (now unmapped) LPI in any LR
+     * can be easily recognised as such.
+     */
+    set_bit(GIC_IRQ_GUEST_PRISTINE_LPI, &pirq->status);
+
+    /*
+     * Now insert the pending_irq into the domain's LPI tree, so that
+     * it becomes live.
+     */
+    write_lock(&its->d->arch.vgic.pend_lpi_tree_lock);
+    ret = radix_tree_insert(&its->d->arch.vgic.pend_lpi_tree, intid, pirq);
+    write_unlock(&its->d->arch.vgic.pend_lpi_tree_lock);
+
+    if ( !ret )
+        return 0;
+
+    /*
+     * radix_tree_insert() returns an error either due to an internal
+     * condition (like memory allocation failure) or because the LPI already
+     * existed in the tree. We don't support the latter case, so we always
+     * cleanup and return an error here in any case.
+     */
+out_remove_host_entry:
+    gicv3_remove_guest_event(its->d, its->doorbell_address, devid, eventid);
+
+out_remove_mapping:
+    spin_lock(&its->its_lock);
+    write_itte_locked(its, devid, eventid,
+                      UNMAPPED_COLLECTION, INVALID_LPI, NULL);
+    spin_unlock(&its->its_lock);
+
+    return ret;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)      ((((baser) & 0xff) + 1) << 12)
 #define ITS_CMD_OFFSET(reg)             ((reg) & GENMASK(19, 5))
 
@@ -579,6 +707,10 @@ static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its)
         case GITS_CMD_MAPD:
             ret = its_handle_mapd(its, command);
             break;
+        case GITS_CMD_MAPI:
+        case GITS_CMD_MAPTI:
+            ret = its_handle_mapti(its, command);
+            break;
         case GITS_CMD_SYNC:
             /* We handle ITS commands synchronously, so we ignore SYNC. */
             break;
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index e78dadf..c6404ea 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -175,6 +175,9 @@ struct pending_irq *gicv3_its_get_event_pending_irq(struct domain *d,
                                                     uint32_t veventid);
 int gicv3_remove_guest_event(struct domain *d, paddr_t vdoorbell_address,
                                      uint32_t vdevid, uint32_t veventid);
+struct pending_irq *gicv3_assign_guest_event(struct domain *d, paddr_t doorbell,
+                                             uint32_t devid, uint32_t eventid,
+                                             uint32_t virt_lpi);
 void gicv3_lpi_update_host_entry(uint32_t host_lpi, int domain_id,
                                  uint32_t virt_lpi);
 
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 26/32] ARM: vITS: handle MOVI command

[Andre Przywara]

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 our virtual ITTE and the pending_irq.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 xen/arch/arm/vgic-v3-its.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 66 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index c350fa5..3332c09 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -666,6 +666,66 @@ out_remove_mapping:
     return ret;
 }
 
+static int its_handle_movi(struct virt_its *its, uint64_t *cmdptr)
+{
+    uint32_t devid = its_cmd_get_deviceid(cmdptr);
+    uint32_t eventid = its_cmd_get_id(cmdptr);
+    uint16_t collid = its_cmd_get_collection(cmdptr);
+    unsigned long flags;
+    struct pending_irq *p;
+    struct vcpu *ovcpu, *nvcpu;
+    uint32_t vlpi;
+    int ret = -1;
+
+    spin_lock(&its->its_lock);
+    /* Check for a mapped LPI and get the LPI number. */
+    if ( !read_itte_locked(its, devid, eventid, &ovcpu, &vlpi) )
+        goto out_unlock;
+
+    if ( vlpi == INVALID_LPI )
+        goto out_unlock;
+
+    /* Check the new collection ID and get the new VCPU pointer */
+    nvcpu = get_vcpu_from_collection(its, collid);
+    if ( !nvcpu )
+        goto out_unlock;
+
+    p = gicv3_its_get_event_pending_irq(its->d, its->doorbell_address,
+                                        devid, eventid);
+    if ( unlikely(!p) )
+        goto out_unlock;
+
+    /*
+     * TODO: This relies on the VCPU being correct in the ITS tables.
+     * This can be fixed by either using a per-IRQ lock or by using
+     * the VCPU ID from the pending_irq instead.
+     */
+    spin_lock_irqsave(&ovcpu->arch.vgic.lock, flags);
+
+    /* Update our cached vcpu_id in the pending_irq. */
+    p->lpi_vcpu_id = nvcpu->vcpu_id;
+
+    spin_unlock_irqrestore(&ovcpu->arch.vgic.lock, flags);
+
+    /*
+     * TODO: lookup currently-in-guest virtual IRQs and migrate them,
+     * as the locking may be fragile otherwise.
+     * This is not easy to do at the moment, but should become easier
+     * with the introduction of a per-IRQ lock.
+     */
+
+    /* Now store the new collection in the translation table. */
+    if ( !write_itte_locked(its, devid, eventid, collid, vlpi, &nvcpu) )
+        goto out_unlock;
+
+    ret = 0;
+
+out_unlock:
+    spin_unlock(&its->its_lock);
+
+    return ret;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)      ((((baser) & 0xff) + 1) << 12)
 #define ITS_CMD_OFFSET(reg)             ((reg) & GENMASK(19, 5))
 
@@ -711,6 +771,12 @@ static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its)
         case GITS_CMD_MAPTI:
             ret = its_handle_mapti(its, command);
             break;
+        case GITS_CMD_MOVALL:
+            gdprintk(XENLOG_G_INFO, "vGITS: ignoring MOVALL command\n");
+            break;
+        case GITS_CMD_MOVI:
+            ret = its_handle_movi(its, command);
+            break;
         case GITS_CMD_SYNC:
             /* We handle ITS commands synchronously, so we ignore SYNC. */
             break;
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 27/32] ARM: vITS: handle DISCARD command

[Andre Przywara]

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 <andre.przywara@arm.com>
---
 xen/arch/arm/vgic-v3-its.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 3332c09..773e5fb 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -726,6 +726,30 @@ out_unlock:
     return ret;
 }
 
+static int its_handle_discard(struct virt_its *its, uint64_t *cmdptr)
+{
+    uint32_t devid = its_cmd_get_deviceid(cmdptr);
+    uint32_t eventid = its_cmd_get_id(cmdptr);
+    int ret;
+
+    spin_lock(&its->its_lock);
+
+    /* Remove from the radix tree and remove the host entry. */
+    ret = its_discard_event(its, devid, eventid);
+    if ( ret )
+        goto out_unlock;
+
+    /* Remove from the guest's ITTE. */
+    if ( !write_itte_locked(its, devid, eventid,
+                            UNMAPPED_COLLECTION, INVALID_LPI, NULL) )
+        ret = -1;
+
+out_unlock:
+    spin_unlock(&its->its_lock);
+
+    return ret;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)      ((((baser) & 0xff) + 1) << 12)
 #define ITS_CMD_OFFSET(reg)             ((reg) & GENMASK(19, 5))
 
@@ -758,6 +782,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its)
         case GITS_CMD_CLEAR:
             ret = its_handle_clear(its, command);
             break;
+        case GITS_CMD_DISCARD:
+            ret = its_handle_discard(its, command);
+            break;
         case GITS_CMD_INT:
             ret = its_handle_int(its, command);
             break;
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 28/32] ARM: vITS: handle INV command

[Andre Przywara]

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 virtual pending bit if an LPI gets enabled.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 xen/arch/arm/vgic-v3-its.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 70 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 773e5fb..14fde83 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -449,6 +449,73 @@ static int update_lpi_property(struct domain *d, struct pending_irq *p)
     return 0;
 }
 
+/*
+ * Checks whether an LPI that got enabled or disabled needs to change
+ * something in the VGIC (added or removed from the LR or queues).
+ * We don't disable the underlying physical LPI, because this requires
+ * queueing a host LPI command, which we can't afford to do on behalf
+ * of a guest.
+ * Must be called with the VCPU VGIC lock held.
+ */
+static void update_lpi_vgic_status(struct vcpu *v, struct pending_irq *p)
+{
+    ASSERT(spin_is_locked(&v->arch.vgic.lock));
+
+    if ( test_bit(GIC_IRQ_GUEST_ENABLED, &p->status) )
+    {
+        if ( !list_empty(&p->inflight) &&
+             !test_bit(GIC_IRQ_GUEST_VISIBLE, &p->status) )
+            gic_raise_guest_irq(v, p->irq, p->lpi_priority);
+    }
+    else
+        gic_remove_from_lr_pending(v, p);
+}
+
+static int its_handle_inv(struct virt_its *its, uint64_t *cmdptr)
+{
+    struct domain *d = its->d;
+    uint32_t devid = its_cmd_get_deviceid(cmdptr);
+    uint32_t eventid = its_cmd_get_id(cmdptr);
+    struct pending_irq *p;
+    unsigned long flags;
+    struct vcpu *vcpu;
+    uint32_t vlpi;
+    int ret = -1;
+
+    spin_lock(&its->its_lock);
+
+    /* Translate the event into a vCPU/vLPI pair. */
+    if ( !read_itte_locked(its, devid, eventid, &vcpu, &vlpi) )
+        goto out_unlock_its;
+
+    if ( vlpi == INVALID_LPI )
+        goto out_unlock_its;
+
+    p = gicv3_its_get_event_pending_irq(d, its->doorbell_address,
+                                        devid, eventid);
+    if ( unlikely(!p) )
+        goto out_unlock_its;
+
+    spin_lock_irqsave(&vcpu->arch.vgic.lock, flags);
+
+    /* Read the property table and update our cached status. */
+    if ( update_lpi_property(d, p) )
+        goto out_unlock;
+
+    /* Check whether the LPI needs to go on a VCPU. */
+    update_lpi_vgic_status(vcpu, p);
+
+    ret = 0;
+
+out_unlock:
+    spin_unlock_irqrestore(&vcpu->arch.vgic.lock, flags);
+
+out_unlock_its:
+    spin_unlock(&its->its_lock);
+
+    return ret;
+}
+
 /* Must be called with the ITS lock held. */
 static int its_discard_event(struct virt_its *its,
                              uint32_t vdevid, uint32_t vevid)
@@ -788,6 +855,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its)
         case GITS_CMD_INT:
             ret = its_handle_int(its, command);
             break;
+        case GITS_CMD_INV:
+            ret = its_handle_inv(its, command);
+            break;
         case GITS_CMD_MAPC:
             ret = its_handle_mapc(its, command);
             break;
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 29/32] ARM: vITS: handle INVALL command

[Andre Przywara]

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: Andre Przywara <andre.przywara@arm.com>
---
 xen/arch/arm/vgic-v3-its.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 66 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 14fde83..76e0467 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -516,6 +516,69 @@ out_unlock_its:
     return ret;
 }
 
+/*
+ * INVALL updates the per-LPI configuration status for every LPI mapped to
+ * a particular redistributor.
+ * We iterate over all mapped LPIs in our radix tree and update those.
+ */
+static int its_handle_invall(struct virt_its *its, uint64_t *cmdptr)
+{
+    uint32_t collid = its_cmd_get_collection(cmdptr);
+    struct vcpu *vcpu;
+    struct pending_irq *pirqs[16];
+    uint64_t vlpi = 0;          /* 64-bit to catch overflows */
+    unsigned int nr_lpis, i;
+    unsigned long flags;
+    int ret = 0;
+
+    /*
+     * As this implementation walks over all mapped LPIs, it might take
+     * too long for a real guest, so we might want to revisit this
+     * implementation for DomUs.
+     * However this command is very rare, also we don't expect many
+     * LPIs to be actually mapped, so it's fine for Dom0 to use.
+     */
+    ASSERT(is_hardware_domain(its->d));
+
+    spin_lock(&its->its_lock);
+    vcpu = get_vcpu_from_collection(its, collid);
+    spin_unlock(&its->its_lock);
+
+    spin_lock_irqsave(&vcpu->arch.vgic.lock, flags);
+    read_lock(&its->d->arch.vgic.pend_lpi_tree_lock);
+
+    do
+    {
+        nr_lpis = radix_tree_gang_lookup(&its->d->arch.vgic.pend_lpi_tree,
+                                         (void **)pirqs, vlpi,
+                                         ARRAY_SIZE(pirqs));
+
+        for ( i = 0; i < nr_lpis; i++ )
+        {
+            /* We only care about LPIs on our VCPU. */
+            if ( pirqs[i]->lpi_vcpu_id != vcpu->vcpu_id )
+                continue;
+
+            vlpi = pirqs[i]->irq;
+            /* If that fails for a single LPI, carry on to handle the rest. */
+            ret = update_lpi_property(its->d, pirqs[i]);
+            if ( !ret )
+                update_lpi_vgic_status(vcpu, pirqs[i]);
+        }
+    /*
+     * Loop over the next gang of pending_irqs until we reached the end of
+     * a (fully populated) tree or the lookup function returns less LPIs than
+     * it has been asked for.
+     */
+    } while ( (++vlpi < its->d->arch.vgic.nr_lpis) &&
+              (nr_lpis == ARRAY_SIZE(pirqs)) );
+
+    read_unlock(&its->d->arch.vgic.pend_lpi_tree_lock);
+    spin_unlock_irqrestore(&vcpu->arch.vgic.lock, flags);
+
+    return ret;
+}
+
 /* Must be called with the ITS lock held. */
 static int its_discard_event(struct virt_its *its,
                              uint32_t vdevid, uint32_t vevid)
@@ -858,6 +921,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its)
         case GITS_CMD_INV:
             ret = its_handle_inv(its, command);
             break;
+        case GITS_CMD_INVALL:
+            ret = its_handle_invall(its, command);
+            break;
         case GITS_CMD_MAPC:
             ret = its_handle_mapc(its, command);
             break;
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 30/32] ARM: vITS: increase mmio_count for each ITS

[Andre Przywara]

Increase the count of MMIO regions needed by one for each ITS Dom0 has
to emulate. We emulate the ITSes 1:1 from the hardware, so the number
is the number of host ITSes.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Julien Grall <julien.grall@arm.com>
---
 xen/arch/arm/vgic-v3-its.c       | 15 +++++++++++++++
 xen/arch/arm/vgic-v3.c           |  3 +++
 xen/include/asm-arm/gic_v3_its.h |  7 +++++++
 3 files changed, 25 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 76e0467..5682a38 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -1435,6 +1435,21 @@ static const struct mmio_handler_ops vgic_its_mmio_handler = {
     .write = vgic_v3_its_mmio_write,
 };
 
+unsigned int vgic_v3_its_count(const struct domain *d)
+{
+    struct host_its *hw_its;
+    unsigned int ret = 0;
+
+    /* Only Dom0 can use emulated ITSes so far. */
+    if ( !is_hardware_domain(d) )
+        return 0;
+
+    list_for_each_entry(hw_its, &host_its_list, entry)
+        ret++;
+
+    return ret;
+}
+
 int vgic_v3_its_init_domain(struct domain *d)
 {
     spin_lock_init(&d->arch.vgic.its_devices_lock);
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 134e1b0..03d9a8c 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1798,6 +1798,9 @@ int vgic_v3_init(struct domain *d, int *mmio_count)
     /* GICD region + number of Redistributors */
     *mmio_count = vgic_v3_rdist_count(d) + 1;
 
+    /* one region per ITS */
+    *mmio_count += vgic_v3_its_count(d);
+
     register_vgic_ops(d, &v3_ops);
 
     return 0;
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index c6404ea..9f70980 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -137,6 +137,8 @@ void gicv3_its_dt_init(const struct dt_device_node *node);
 
 bool gicv3_its_host_has_its(void);
 
+unsigned int vgic_v3_its_count(const struct domain *d);
+
 void gicv3_do_LPI(unsigned int lpi);
 
 int gicv3_lpi_init_rdist(void __iomem * rdist_base);
@@ -192,6 +194,11 @@ static inline bool gicv3_its_host_has_its(void)
     return false;
 }
 
+static inline unsigned int vgic_v3_its_count(const struct domain *d)
+{
+    return 0;
+}
+
 static inline void gicv3_do_LPI(unsigned int lpi)
 {
     /* We don't enable LPIs without an ITS. */
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 31/32] ARM: vITS: create and initialize virtual ITSes for Dom0

[Andre Przywara]

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 again.
We configure the virtual ITSes to match the hardware ones, that is we
keep the number of device ID bits and event ID bits the same as the host
ITS.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 xen/arch/arm/vgic-v3-its.c   | 77 ++++++++++++++++++++++++++++++++++++++++++++
 xen/include/asm-arm/domain.h |  1 +
 2 files changed, 78 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 5682a38..7567f15 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -52,6 +52,7 @@
  */
 struct virt_its {
     struct domain *d;
+    struct list_head vits_list;
     paddr_t doorbell_address;
     unsigned int devid_bits;
     unsigned int evid_bits;
@@ -1435,6 +1436,46 @@ static const struct mmio_handler_ops vgic_its_mmio_handler = {
     .write = vgic_v3_its_mmio_write,
 };
 
+static int vgic_v3_its_init_virtual(struct domain *d, paddr_t guest_addr,
+                                    unsigned int devid_bits,
+                                    unsigned int evid_bits)
+{
+    struct virt_its *its;
+    uint64_t base_attr;
+
+    its = xzalloc(struct virt_its);
+    if ( !its )
+        return -ENOMEM;
+
+    base_attr  = GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
+    base_attr |= GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILITY_SHIFT;
+    base_attr |= GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
+
+    its->cbaser  = base_attr;
+    base_attr |= 0ULL << GITS_BASER_PAGE_SIZE_SHIFT;    /* 4K pages */
+    its->baser_dev = GITS_BASER_TYPE_DEVICE << GITS_BASER_TYPE_SHIFT;
+    its->baser_dev |= (sizeof(dev_table_entry_t) - 1) <<
+                      GITS_BASER_ENTRY_SIZE_SHIFT;
+    its->baser_dev |= base_attr;
+    its->baser_coll  = GITS_BASER_TYPE_COLLECTION << GITS_BASER_TYPE_SHIFT;
+    its->baser_coll |= (sizeof(coll_table_entry_t) - 1) <<
+                       GITS_BASER_ENTRY_SIZE_SHIFT;
+    its->baser_coll |= base_attr;
+    its->d = d;
+    its->doorbell_address = guest_addr + ITS_DOORBELL_OFFSET;
+    its->devid_bits = devid_bits;
+    its->evid_bits = evid_bits;
+    spin_lock_init(&its->vcmd_lock);
+    spin_lock_init(&its->its_lock);
+
+    register_mmio_handler(d, &vgic_its_mmio_handler, guest_addr, SZ_64K, its);
+
+    /* Register the virtual ITS to be able to clean it up later. */
+    list_add_tail(&its->vits_list, &d->arch.vgic.vits_list);
+
+    return 0;
+}
+
 unsigned int vgic_v3_its_count(const struct domain *d)
 {
     struct host_its *hw_its;
@@ -1450,16 +1491,52 @@ unsigned int vgic_v3_its_count(const struct domain *d)
     return ret;
 }
 
+/*
+ * For a hardware domain, this will iterate over the host ITSes
+ * and map one virtual ITS per host ITS at the same address.
+ */
 int vgic_v3_its_init_domain(struct domain *d)
 {
+    int ret;
+
+    INIT_LIST_HEAD(&d->arch.vgic.vits_list);
     spin_lock_init(&d->arch.vgic.its_devices_lock);
     d->arch.vgic.its_devices = RB_ROOT;
 
+    if ( is_hardware_domain(d) )
+    {
+        struct host_its *hw_its;
+
+        list_for_each_entry(hw_its, &host_its_list, entry)
+        {
+            /*
+             * For each host ITS create a virtual ITS using the same
+             * base and thus doorbell address.
+             * Use the same number of device ID and event ID bits as the host.
+             */
+            ret = vgic_v3_its_init_virtual(d, hw_its->addr,
+                                           hw_its->devid_bits,
+                                           hw_its->evid_bits);
+            if ( ret )
+                return ret;
+            else
+                d->arch.vgic.has_its = true;
+        }
+    }
+
     return 0;
 }
 
 void vgic_v3_its_free_domain(struct domain *d)
 {
+    struct virt_its *pos, *temp;
+
+    list_for_each_entry_safe( pos, temp, &d->arch.vgic.vits_list, vits_list )
+    {
+        list_del(&pos->vits_list);
+        xfree(pos);
+    }
+
     ASSERT(RB_EMPTY_ROOT(&d->arch.vgic.its_devices));
 }
 
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index b33f54a..8dfc1d1 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -115,6 +115,7 @@ struct arch_domain
         spinlock_t its_devices_lock;        /* Protects the its_devices tree */
         struct radix_tree_root pend_lpi_tree; /* Stores struct pending_irq's */
         rwlock_t pend_lpi_tree_lock;        /* Protects the pend_lpi_tree */
+        struct list_head vits_list;         /* List of virtual ITSes */
         unsigned int intid_bits;
         /*
          * TODO: if there are more bool's being added below, consider
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v10 32/32] ARM: vITS: create ITS subnodes for Dom0 DT

[Andre Przywara]

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 <andre.przywara@arm.com>
---
 xen/arch/arm/gic-v3-its.c        | 73 ++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/gic-v3.c            |  4 ++-
 xen/include/asm-arm/gic_v3_its.h | 12 +++++++
 3 files changed, 88 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 41fff64..90b7462 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -20,6 +20,7 @@
 
 #include <xen/lib.h>
 #include <xen/delay.h>
+#include <xen/libfdt/libfdt.h>
 #include <xen/mm.h>
 #include <xen/rbtree.h>
 #include <xen/sched.h>
@@ -903,6 +904,78 @@ struct pending_irq *gicv3_assign_guest_event(struct domain *d,
     return pirq;
 }
 
+/*
+ * Create the respective guest DT nodes from a list of host ITSes.
+ * This copies the reg property, so the guest sees the ITS at the same address
+ * as the host.
+ */
+int gicv3_its_make_hwdom_dt_nodes(const struct domain *d,
+                                  const struct dt_device_node *gic,
+                                  void *fdt)
+{
+    uint32_t len;
+    int res;
+    const void *prop = NULL;
+    const struct dt_device_node *its = NULL;
+    const struct host_its *its_data;
+
+    if ( list_empty(&host_its_list) )
+        return 0;
+
+    /* The sub-nodes require the ranges property */
+    prop = dt_get_property(gic, "ranges", &len);
+    if ( !prop )
+    {
+        printk(XENLOG_ERR "Can't find ranges property for the gic node\n");
+        return -FDT_ERR_XEN(ENOENT);
+    }
+
+    res = fdt_property(fdt, "ranges", prop, len);
+    if ( res )
+        return res;
+
+    list_for_each_entry(its_data, &host_its_list, entry)
+    {
+        its = its_data->dt_node;
+
+        res = fdt_begin_node(fdt, its->name);
+        if ( res )
+            return res;
+
+        res = fdt_property_string(fdt, "compatible", "arm,gic-v3-its");
+        if ( res )
+            return res;
+
+        res = fdt_property(fdt, "msi-controller", NULL, 0);
+        if ( res )
+            return res;
+
+        if ( its->phandle )
+        {
+            res = fdt_property_cell(fdt, "phandle", its->phandle);
+            if ( res )
+                return res;
+        }
+
+        /* Use the same reg regions as the ITS node in host DTB. */
+        prop = dt_get_property(its, "reg", &len);
+        if ( !prop )
+        {
+            printk(XENLOG_ERR "GICv3: Can't find ITS reg property.\n");
+            res = -FDT_ERR_XEN(ENOENT);
+            return res;
+        }
+
+        res = fdt_property(fdt, "reg", prop, len);
+        if ( res )
+            return res;
+
+        fdt_end_node(fdt);
+    }
+
+    return res;
+}
+
 /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
 void gicv3_its_dt_init(const struct dt_device_node *node)
 {
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index d539d6c..c927306 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1172,8 +1172,10 @@ static int gicv3_make_hwdom_dt_node(const struct domain *d,
 
     res = fdt_property(fdt, "reg", new_cells, len);
     xfree(new_cells);
+    if ( res )
+        return res;
 
-    return res;
+    return gicv3_its_make_hwdom_dt_nodes(d, gic, fdt);
 }
 
 static const hw_irq_controller gicv3_host_irq_type = {
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index 9f70980..5fb2364 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -158,6 +158,11 @@ int gicv3_its_setup_collection(unsigned int cpu);
 int vgic_v3_its_init_domain(struct domain *d);
 void vgic_v3_its_free_domain(struct domain *d);
 
+/* Create the appropriate DT nodes for a hardware domain. */
+int gicv3_its_make_hwdom_dt_nodes(const struct domain *d,
+                                  const struct dt_device_node *gic,
+                                  void *fdt);
+
 /*
  * Map a device on the host by allocating an ITT on the host (ITS).
  * "nr_event" specifies how many events (interrupts) this device will need.
@@ -240,6 +245,13 @@ static inline void vgic_v3_its_free_domain(struct domain *d)
 {
 }
 
+static inline int gicv3_its_make_hwdom_dt_nodes(const struct domain *d,
+                                                const struct dt_device_node *gic,
+                                                void *fdt)
+{
+    return 0;
+}
+
 #endif /* CONFIG_HAS_ITS */
 
 #endif
-- 
2.9.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 01/32] ARM: vGIC: avoid rank lock when reading priority

[Julien Grall]

Hi Andre,

On 26/05/17 18:35, Andre Przywara wrote:
> When reading the priority value of a virtual interrupt, we were taking
> the respective rank lock so far.
> However for forwarded interrupts (Dom0 only so far) this may lead to a
> deadlock with the following call chain:
> - MMIO access to change the IRQ affinity, calling the ITARGETSR handler
> - this handler takes the appropriate rank lock and calls vgic_store_itargetsr()
> - vgic_store_itargetsr() will eventually call vgic_migrate_irq()
> - if this IRQ is already in-flight, it will remove it from the old
>   VCPU and inject it into the new one, by calling vgic_vcpu_inject_irq()
> - vgic_vcpu_inject_irq will call vgic_get_virq_priority()
> - vgic_get_virq_priority() tries to take the rank lock - again!
> It seems like this code path has never been exercised before.
>
> Fix this by avoiding taking the lock in vgic_get_virq_priority() (like we
> do in vgic_get_target_vcpu()).
> Actually we are just reading one byte, and priority changes while
> interrupts are handled are a benign race that can happen on real hardware
> too. So it looks safe to just use read_atomic() instead.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  xen/arch/arm/vgic.c | 8 +-------
>  1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 83569b0..54b2aad 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -227,14 +227,8 @@ struct vcpu *vgic_get_target_vcpu(struct vcpu *v, unsigned int virq)
>  static int vgic_get_virq_priority(struct vcpu *v, unsigned int virq)
>  {
>      struct vgic_irq_rank *rank = vgic_rank_irq(v, virq);
> -    unsigned long flags;
> -    int priority;
> -
> -    vgic_lock_rank(v, rank, flags);
> -    priority = rank->priority[virq & INTERRUPT_RANK_MASK];
> -    vgic_unlock_rank(v, rank, flags);
>
> -    return priority;
> +    return read_atomic(&rank->priority[virq & INTERRUPT_RANK_MASK]);

The write in rank->priority will not be atomic (see vgic_reg_update 
implementation): the register is first masked, the the priority set.

So you may end up to read 0 (which is the higher priority) by mistake.

We should probably think to make vgic_reg_* helper atomic.

>  }
>
>  bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned int irq)
>

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 02/32] ARM: GICv3: setup number of LPI bits for a GICv3 guest

[Julien Grall]

Hi Andre,

On 26/05/17 18:35, Andre Przywara wrote:
> The host supports a certain number of LPI identifiers, as stored in
> the GICD_TYPER register.
> Store this number from the hardware register in vgic_v3_hw to allow
> injecting the very same number into a guest (Dom0).
> DomUs get the legacy number of 10 bits here, since for now it only sees
> SPIs, so it does not need more. This should be revisited once we get
> proper DomU ITS support.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  xen/arch/arm/gic-v3.c        |  6 +++++-
>  xen/arch/arm/vgic-v3.c       | 10 +++++++++-
>  xen/include/asm-arm/domain.h |  1 +
>  xen/include/asm-arm/vgic.h   |  3 ++-
>  4 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index a559e5e..29c8964 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1579,6 +1579,7 @@ static int __init gicv3_init(void)
>  {
>      int res, i;
>      uint32_t reg;
> +    unsigned int intid_bits;
>
>      if ( !cpu_has_gicv3 )
>      {
> @@ -1622,8 +1623,11 @@ static int __init gicv3_init(void)
>                 i, r->base, r->base + r->size);
>      }
>
> +    reg = readl_relaxed(GICD + GICD_TYPER);
> +    intid_bits = GICD_TYPE_ID_BITS(reg);
> +
>      vgic_v3_setup_hw(dbase, gicv3.rdist_count, gicv3.rdist_regions,
> -                     gicv3.rdist_stride);
> +                     gicv3.rdist_stride, intid_bits);
>      gicv3_init_v2();
>
>      spin_lock_init(&gicv3.lock);
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index d10757a..87f5fb3 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -57,18 +57,21 @@ static struct {
>      unsigned int nr_rdist_regions;
>      const struct rdist_region *regions;
>      uint32_t rdist_stride; /* Re-distributor stride */
> +    unsigned int intid_bits;  /* Number of interrupt ID bits */
>  } vgic_v3_hw;
>
>  void vgic_v3_setup_hw(paddr_t dbase,
>                        unsigned int nr_rdist_regions,
>                        const struct rdist_region *regions,
> -                      uint32_t rdist_stride)
> +                      uint32_t rdist_stride,
> +                      unsigned int intid_bits)
>  {
>      vgic_v3_hw.enabled = 1;
>      vgic_v3_hw.dbase = dbase;
>      vgic_v3_hw.nr_rdist_regions = nr_rdist_regions;
>      vgic_v3_hw.regions = regions;
>      vgic_v3_hw.rdist_stride = rdist_stride;
> +    vgic_v3_hw.intid_bits = intid_bits;
>  }
>
>  static struct vcpu *vgic_v3_irouter_to_vcpu(struct domain *d, uint64_t irouter)
> @@ -1482,6 +1485,8 @@ static int vgic_v3_domain_init(struct domain *d)
>
>              first_cpu += size / d->arch.vgic.rdist_stride;
>          }
> +
> +        d->arch.vgic.intid_bits = vgic_v3_hw.intid_bits;
>      }
>      else
>      {
> @@ -1497,6 +1502,9 @@ static int vgic_v3_domain_init(struct domain *d)
>          d->arch.vgic.rdist_regions[0].base = GUEST_GICV3_GICR0_BASE;
>          d->arch.vgic.rdist_regions[0].size = GUEST_GICV3_GICR0_SIZE;
>          d->arch.vgic.rdist_regions[0].first_cpu = 0;
> +
> +        /* TODO: only SPIs for now, adjust this when guests need LPIs */
> +        d->arch.vgic.intid_bits = 10;

What if the guest support no SPIs? Should not you based this number of 
the number of SPIs supported by the guest?

>      }
>
>      ret = vgic_v3_its_init_domain(d);
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 6de8082..7c3829d 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -111,6 +111,7 @@ struct arch_domain
>          uint32_t rdist_stride;              /* Re-Distributor stride */
>          struct rb_root its_devices;         /* Devices mapped to an ITS */
>          spinlock_t its_devices_lock;        /* Protects the its_devices tree */
> +        unsigned int intid_bits;
>  #endif
>      } vgic;
>
> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
> index 544867a..df75064 100644
> --- a/xen/include/asm-arm/vgic.h
> +++ b/xen/include/asm-arm/vgic.h
> @@ -346,7 +346,8 @@ struct rdist_region;
>  void vgic_v3_setup_hw(paddr_t dbase,
>                        unsigned int nr_rdist_regions,
>                        const struct rdist_region *regions,
> -                      uint32_t rdist_stride);
> +                      uint32_t rdist_stride,
> +                      unsigned int intid_bits);
>  #endif
>
>  #endif /* __ASM_ARM_VGIC_H__ */
>

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 03/32] ARM: vGIC: move irq_to_pending() calls under the VGIC VCPU lock

[Julien Grall]

Hi Andre,

On 26/05/17 18:35, Andre Przywara wrote:
> So far irq_to_pending() is just a convenience function to lookup
> statically allocated arrays. This will change with LPIs, which are
> more dynamic, so the memory for their struct pending_irq might go away.
> The proper answer to the issue of preventing stale pointers is
> ref-counting, which requires more rework and will be introduced with
> a later rework.
> For now move the irq_to_pending() calls that are used with LPIs under the
> VGIC VCPU lock, and only use the returned pointer while holding the lock.
> This prevents the memory from being freed while we use it.
> For the sake of completeness we take care about all irq_to_pending()
> users, even those which later will never deal with LPIs.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  xen/arch/arm/gic.c  |  5 ++++-
>  xen/arch/arm/vgic.c | 39 ++++++++++++++++++++++++++++++---------
>  2 files changed, 34 insertions(+), 10 deletions(-)
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index da19130..dcb1783 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -402,10 +402,13 @@ static inline void gic_add_to_lr_pending(struct vcpu *v, struct pending_irq *n)
>
>  void gic_remove_from_queues(struct vcpu *v, unsigned int virtual_irq)
>  {
> -    struct pending_irq *p = irq_to_pending(v, virtual_irq);
> +    struct pending_irq *p;
>      unsigned long flags;
>
>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> +
> +    p = irq_to_pending(v, virtual_irq);
> +
>      if ( !list_empty(&p->lr_queue) )
>          list_del_init(&p->lr_queue);
>      spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 54b2aad..69d732b 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -234,23 +234,29 @@ static int vgic_get_virq_priority(struct vcpu *v, unsigned int virq)
>  bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned int irq)
>  {
>      unsigned long flags;
> -    struct pending_irq *p = irq_to_pending(old, irq);
> +    struct pending_irq *p;
> +
> +    spin_lock_irqsave(&old->arch.vgic.lock, flags);
> +
> +    p = irq_to_pending(old, irq);
>
>      /* nothing to do for virtual interrupts */
>      if ( p->desc == NULL )
> +    {
> +        spin_unlock_irqrestore(&old->arch.vgic.lock, flags);
>          return true;
> +    }
>
>      /* migration already in progress, no need to do anything */
>      if ( test_bit(GIC_IRQ_GUEST_MIGRATING, &p->status) )
>      {
>          gprintk(XENLOG_WARNING, "irq %u migration failed: requested while in progress\n", irq);
> +        spin_unlock_irqrestore(&old->arch.vgic.lock, flags);
>          return false;
>      }
>
>      perfc_incr(vgic_irq_migrates);
>
> -    spin_lock_irqsave(&old->arch.vgic.lock, flags);
> -
>      if ( list_empty(&p->inflight) )
>      {
>          irq_set_affinity(p->desc, cpumask_of(new->processor));
> @@ -285,6 +291,13 @@ void arch_move_irqs(struct vcpu *v)
>      struct vcpu *v_target;
>      int i;
>
> +    /*
> +     * We don't migrate LPIs at the moment.
> +     * If we ever do, we must make sure that the struct pending_irq does
> +     * not go away, as there is no lock preventing this here.
> +     */
> +    ASSERT(!is_lpi(vgic_num_irqs(d) - 1));

Hmmm? This raise a question of why vgic_num_irqs does not include the 
LPIs today...

> +
>      for ( i = 32; i < vgic_num_irqs(d); i++ )
>      {
>          v_target = vgic_get_target_vcpu(v, i);
> @@ -299,6 +312,7 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
>  {
>      const unsigned long mask = r;
>      struct pending_irq *p;
> +    struct irq_desc *desc;
>      unsigned int irq;
>      unsigned long flags;
>      int i = 0;
> @@ -307,14 +321,19 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
>      while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
>          irq = i + (32 * n);
>          v_target = vgic_get_target_vcpu(v, irq);
> +
> +        spin_lock_irqsave(&v_target->arch.vgic.lock, flags);
>          p = irq_to_pending(v_target, irq);
>          clear_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
>          gic_remove_from_queues(v_target, irq);

gic_remove_from_queues is taking v_target vGIC lock. So you just 
introduced a deadlock. You remove it in the next patch but still, we 
should not introduce regression even temporarily. This would make to 
difficult to bisect the series.

TBH, I am not a big fan of spreading the mess of vGIC locking when we 
are going to rework the vGIC and know that this code will not be called 
for LPIs.

BTW, this series is not bisectable because the host ITS is only enabled 
from patch #12.

> -        if ( p->desc != NULL )
> +        desc = p->desc;
> +        spin_unlock_irqrestore(&v_target->arch.vgic.lock, flags);
> +
> +        if ( desc != NULL )
>          {
> -            spin_lock_irqsave(&p->desc->lock, flags);
> -            p->desc->handler->disable(p->desc);
> -            spin_unlock_irqrestore(&p->desc->lock, flags);
> +            spin_lock_irqsave(&desc->lock, flags);
> +            desc->handler->disable(desc);
> +            spin_unlock_irqrestore(&desc->lock, flags);
>          }
>          i++;
>      }
> @@ -349,9 +368,9 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
>      while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
>          irq = i + (32 * n);
>          v_target = vgic_get_target_vcpu(v, irq);
> +        spin_lock_irqsave(&v_target->arch.vgic.lock, flags);
>          p = irq_to_pending(v_target, irq);
>          set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
> -        spin_lock_irqsave(&v_target->arch.vgic.lock, flags);
>          if ( !list_empty(&p->inflight) && !test_bit(GIC_IRQ_GUEST_VISIBLE, &p->status) )
>              gic_raise_guest_irq(v_target, irq, p->priority);
>          spin_unlock_irqrestore(&v_target->arch.vgic.lock, flags);
> @@ -460,7 +479,7 @@ void vgic_clear_pending_irqs(struct vcpu *v)
>  void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq)
>  {
>      uint8_t priority;
> -    struct pending_irq *iter, *n = irq_to_pending(v, virq);
> +    struct pending_irq *iter, *n;
>      unsigned long flags;
>      bool running;
>
> @@ -468,6 +487,8 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq)
>
>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>
> +    n = irq_to_pending(v, virq);
> +
>      /* vcpu offline */
>      if ( test_bit(_VPF_down, &v->pause_flags) )
>      {
>

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 04/32] ARM: vGIC: rework gic_remove_from_queues()

[Julien Grall]

Hi Andre,

On 26/05/17 18:35, Andre Przywara wrote:
> The function name gic_remove_from_queues() was a bit of a misnomer,
> since it just removes an IRQ from the pending queue, not both queues.
> Rename the function to make this more clear, also give it a pointer to
> a struct pending_irq directly and rely on the VGIC VCPU lock to be
> already taken, so this can be used in more places.
> Replace the list removal in gic_clear_pending_irqs() with a call to
> this function.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  xen/arch/arm/gic.c        | 12 +++---------
>  xen/arch/arm/vgic.c       |  2 +-
>  xen/include/asm-arm/gic.h |  2 +-
>  3 files changed, 5 insertions(+), 11 deletions(-)
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index dcb1783..9dde146 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -400,18 +400,12 @@ static inline void gic_add_to_lr_pending(struct vcpu *v, struct pending_irq *n)
>      list_add_tail(&n->lr_queue, &v->arch.vgic.lr_pending);
>  }
>
> -void gic_remove_from_queues(struct vcpu *v, unsigned int virtual_irq)
> +void gic_remove_from_lr_pending(struct vcpu *v, struct pending_irq *p)
>  {
> -    struct pending_irq *p;
> -    unsigned long flags;
> -
> -    spin_lock_irqsave(&v->arch.vgic.lock, flags);
> -
> -    p = irq_to_pending(v, virtual_irq);
> +    ASSERT(spin_is_locked(&v->arch.vgic.lock));

Likely something before was wrong if you replace the lock by an ASSERT 
without even adding lock in the current callers. Such as the deadlock 
introduced in the previous patch...

>
>      if ( !list_empty(&p->lr_queue) )

Whilst you rework gic_remove_from_queues, you could probably remove this 
check.

>          list_del_init(&p->lr_queue);
> -    spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
>  }
>
>  void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq)
> @@ -612,7 +606,7 @@ void gic_clear_pending_irqs(struct vcpu *v)
>
>      v->arch.lr_mask = 0;
>      list_for_each_entry_safe ( p, t, &v->arch.vgic.lr_pending, lr_queue )
> -        list_del_init(&p->lr_queue);
> +        gic_remove_from_lr_pending(v, p);
>  }
>
>  int gic_events_need_delivery(void)
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 69d732b..3993965 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -325,7 +325,7 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
>          spin_lock_irqsave(&v_target->arch.vgic.lock, flags);
>          p = irq_to_pending(v_target, irq);
>          clear_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
> -        gic_remove_from_queues(v_target, irq);
> +        gic_remove_from_lr_pending(v_target, p);
>          desc = p->desc;
>          spin_unlock_irqrestore(&v_target->arch.vgic.lock, flags);
>
> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> index 836a103..3130634 100644
> --- a/xen/include/asm-arm/gic.h
> +++ b/xen/include/asm-arm/gic.h
> @@ -243,7 +243,7 @@ extern void init_maintenance_interrupt(void);
>  extern void gic_raise_guest_irq(struct vcpu *v, unsigned int irq,
>          unsigned int priority);
>  extern void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq);
> -extern void gic_remove_from_queues(struct vcpu *v, unsigned int virtual_irq);
> +extern void gic_remove_from_lr_pending(struct vcpu *v, struct pending_irq *p);
>
>  /* Accept an interrupt from the GIC and dispatch its handler */
>  extern void gic_interrupt(struct cpu_user_regs *regs, int is_fiq);
>

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 05/32] ARM: vGIC: introduce gic_remove_irq()

[Julien Grall]

Hi Andre,

On 26/05/17 18:35, Andre Przywara wrote:
> To avoid code duplication in a later patch, introduce a generic function
> to remove a virtual IRQ from the VGIC.
> Call that function instead of the open-coded version in vgic_migrate_irq().
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  xen/arch/arm/gic.c        | 9 +++++++++
>  xen/arch/arm/vgic.c       | 1 +
>  xen/include/asm-arm/gic.h | 1 +
>  3 files changed, 11 insertions(+)
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 9dde146..3a6184a 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -408,6 +408,15 @@ void gic_remove_from_lr_pending(struct vcpu *v, struct pending_irq *p)
>          list_del_init(&p->lr_queue);
>  }
>
> +void gic_remove_irq(struct vcpu *v, struct pending_irq *p)

The name is too generic. Remove IRQ from what?

> +{
> +    ASSERT(spin_is_locked(&v->arch.vgic.lock));
> +
> +    clear_bit(GIC_IRQ_GUEST_QUEUED, &p->status);
> +    list_del_init(&p->inflight);
> +    gic_remove_from_lr_pending(v, p);
> +}
> +
>  void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq)
>  {
>      struct pending_irq *n = irq_to_pending(v, virtual_irq);
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 3993965..b2acc99 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -266,6 +266,7 @@ bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned int irq)
>      /* If the IRQ is still lr_pending, re-inject it to the new vcpu */
>      if ( !list_empty(&p->lr_queue) )
>      {
> +        gic_remove_irq(old, p);
>          clear_bit(GIC_IRQ_GUEST_QUEUED, &p->status);
>          list_del_init(&p->lr_queue);
>          list_del_init(&p->inflight);

I was expecting those 3 lines to be removed since you now call 
gic_remove_irq.

> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> index 3130634..5d5b4cc 100644
> --- a/xen/include/asm-arm/gic.h
> +++ b/xen/include/asm-arm/gic.h
> @@ -244,6 +244,7 @@ extern void gic_raise_guest_irq(struct vcpu *v, unsigned int irq,
>          unsigned int priority);
>  extern void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq);
>  extern void gic_remove_from_lr_pending(struct vcpu *v, struct pending_irq *p);
> +extern void gic_remove_irq(struct vcpu *v, struct pending_irq *p);
>
>  /* Accept an interrupt from the GIC and dispatch its handler */
>  extern void gic_interrupt(struct cpu_user_regs *regs, int is_fiq);
>

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 06/32] ARM: GIC: Add checks for NULL pointer pending_irq's

[Julien Grall]

Hi Andre,

On 26/05/17 18:35, Andre Przywara wrote:
> For LPIs the struct pending_irq's are dynamically allocated and the
> pointers will be stored in a radix tree. Since an LPI can be "unmapped"
> at any time, teach the VGIC how to deal with irq_to_pending() returning
> a NULL pointer.
> We just do nothing in this case or clean up the LR if the virtual LPI
> number was still in an LR.
>
> Those are all call sites for irq_to_pending(), as per:
> "git grep irq_to_pending", and their evaluations:
> (PROTECTED means: added NULL check and bailing out)
>
>     xen/arch/arm/gic.c:
> gic_route_irq_to_guest(): only called for SPIs, added ASSERT()
> gic_remove_irq_from_guest(): only called for SPIs, added ASSERT()
> gic_remove_from_queues(): PROTECTED, called within VCPU VGIC lock

This function has been renamed in patch #4.

> gic_raise_inflight_irq(): PROTECTED, called under VCPU VGIC lock
> gic_raise_guest_irq(): PROTECTED, called under VCPU VGIC lock
> gic_update_one_lr(): PROTECTED, called under VCPU VGIC lock
>
>     xen/arch/arm/vgic.c:
> vgic_migrate_irq(): not called for LPIs (virtual IRQs), added ASSERT()
> arch_move_irqs(): not iterating over LPIs, added ASSERT()

I don't see any ASSERT added in arch_move_irqs.

> vgic_disable_irqs(): not called for LPIs, added ASSERT()
> vgic_enable_irqs(): not called for LPIs, added ASSERT()
> vgic_vcpu_inject_irq(): PROTECTED, moved under VCPU VGIC lock
>
>     xen/include/asm-arm/event.h:
> local_events_need_delivery_nomask(): only called for a PPI, added ASSERT()
>
>     xen/include/asm-arm/vgic.h:
> (prototype)

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 11/32] ARM: GICv3: forward pending LPIs to guests

[Julien Grall]

Hi Andre,

On 26/05/17 18:35, 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 the domain ID and the virtual
> LPI number quickly when the host takes an LPI. We then look up the
> right VCPU in the struct pending_irq.
> We use the existing injection function to let the GIC emulation deal
> with this interrupt.
> This introduces a do_LPI() as a hardware gic_ops.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  xen/arch/arm/gic-v2.c            |  7 ++++
>  xen/arch/arm/gic-v3-lpi.c        | 76 ++++++++++++++++++++++++++++++++++++++--
>  xen/arch/arm/gic-v3.c            |  1 +
>  xen/arch/arm/gic.c               |  8 ++++-
>  xen/include/asm-arm/domain.h     |  3 +-
>  xen/include/asm-arm/gic.h        |  2 ++
>  xen/include/asm-arm/gic_v3_its.h |  8 +++++
>  7 files changed, 101 insertions(+), 4 deletions(-)
>
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 270a136..ffbe47c 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -1217,6 +1217,12 @@ static int __init gicv2_init(void)
>      return 0;
>  }
>
> +static void gicv2_do_LPI(unsigned int lpi)
> +{
> +    /* No LPIs in a GICv2 */
> +    BUG();
> +}
> +
>  const static struct gic_hw_operations gicv2_ops = {
>      .info                = &gicv2_info,
>      .init                = gicv2_init,
> @@ -1244,6 +1250,7 @@ const static struct gic_hw_operations gicv2_ops = {
>      .make_hwdom_madt     = gicv2_make_hwdom_madt,
>      .map_hwdom_extra_mappings = gicv2_map_hwdown_extra_mappings,
>      .iomem_deny_access   = gicv2_iomem_deny_access,
> +    .do_LPI              = gicv2_do_LPI,
>  };
>
>  /* Set up the GIC */
> diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
> index 292f2d0..438bbfe 100644
> --- a/xen/arch/arm/gic-v3-lpi.c
> +++ b/xen/arch/arm/gic-v3-lpi.c
> @@ -47,7 +47,6 @@ union host_lpi {
>      struct {
>          uint32_t virt_lpi;
>          uint16_t dom_id;
> -        uint16_t vcpu_id;

You don't explain why you remove vcpu_id from host_lpi. This likely 
require a separate patch anyway.

Also, I would prefer if you make the padding in the structure explicit 
(i.e using pad0).

>      };
>  };
>
> @@ -136,6 +135,80 @@ uint64_t gicv3_get_redist_address(unsigned int cpu, bool use_pta)
>          return per_cpu(lpi_redist, cpu).redist_id << 16;
>  }
>
> +static void vgic_vcpu_inject_lpi(struct domain *d, unsigned int virq)
> +{
> +    struct pending_irq *p = irq_to_pending(d->vcpu[0], virq);
> +    struct vcpu *v = NULL;
> +
> +    if ( !p )
> +        return;
> +
> +    if ( p->lpi_vcpu_id < d->max_vcpus )
> +        v = d->vcpu[read_atomic(&p->lpi_vcpu_id)];

Hmmm, what does prevent lpi_vcpu_id to change between the check and the 
read?

> +
> +    if ( v )

v will always be valid if you read d->vcpu[....] and the way you wrote 
the code is very confusing.

It would be clearer if you do:

if ( p->lpi_vcpu_id >= d->max_vcpus )
   return;

v = ....
vgic_vcpu_inject_irq(v, irq);

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 12/32] ARM: GICv3: enable ITS and LPIs on the host

[Julien Grall]

Hi Andre,

On 26/05/17 18:35, 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.

In that case, why don't we move this patch at the beginning of the 
series? This would make easier to bisect this series as without it the 
ITS will not process commands and therefore initialization will fail.

>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Acked-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
>  xen/arch/arm/gic-v3-its.c |  4 ++++
>  xen/arch/arm/gic-v3.c     | 18 ++++++++++++++++++
>  2 files changed, 22 insertions(+)
>
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> index 07280b3..aebc257 100644
> --- a/xen/arch/arm/gic-v3-its.c
> +++ b/xen/arch/arm/gic-v3-its.c
> @@ -505,6 +505,10 @@ static int gicv3_its_init_single_its(struct host_its *hw_its)
>          return -ENOMEM;
>      writeq_relaxed(0, hw_its->its_base + GITS_CWRITER);
>
> +    /* Now enable interrupt translation and command processing on that ITS. */
> +    reg = readl_relaxed(hw_its->its_base + GITS_CTLR);
> +    writel_relaxed(reg | GITS_CTLR_ENABLE, hw_its->its_base + GITS_CTLR);
> +
>      return 0;
>  }
>
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 8140c5f..d539d6c 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -620,6 +620,21 @@ static int gicv3_enable_redist(void)
>      return 0;
>  }
>
> +/* Enable LPIs on this redistributor (only useful when the host has an ITS). */
> +static bool gicv3_enable_lpis(void)
> +{
> +    uint32_t val;
> +
> +    val = readl_relaxed(GICD_RDIST_BASE + GICR_TYPER);
> +    if ( !(val & GICR_TYPER_PLPIS) )
> +        return false;
> +
> +    val = readl_relaxed(GICD_RDIST_BASE + GICR_CTLR);
> +    writel_relaxed(val | GICR_CTLR_ENABLE_LPIS, GICD_RDIST_BASE + GICR_CTLR);
> +
> +    return true;
> +}
> +
>  static int __init gicv3_populate_rdist(void)
>  {
>      int i;
> @@ -731,11 +746,14 @@ static int gicv3_cpu_init(void)
>      if ( gicv3_enable_redist() )
>          return -ENODEV;
>
> +    /* If the host has any ITSes, enable LPIs now. */
>      if ( gicv3_its_host_has_its() )
>      {
>          ret = gicv3_its_setup_collection(smp_processor_id());
>          if ( ret )
>              return ret;
> +        if ( !gicv3_enable_lpis() )
> +            return -EBUSY;
>      }
>
>      /* Set priority on PPI and SGI interrupts */
>

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 16/32] ARM: vGIC: advertise LPI support

[Julien Grall]

Hi Andre,

On 26/05/17 18:35, Andre Przywara wrote:
> 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.

I am not sure to understand this sentence. You report LPI capability if 
the domain has an ITS exposed. It does not matter whether the host has one.

> For Dom0 we report the same number of interrupts identifiers as the
> host, whereas DomUs get a number fixed at 10 bits for the moments, which
> covers all SPIs. Also we fix a slight inaccuracy here, since the
> number of interrupt identifier specified in GICD_TYPER depends on the
> stream interface and is independent from the number of actually wired
> SPIs.

This justification would have been useful in patch #2.

> This also removes a "TBD" comment, as we now populate the processor
> number in the GICR_TYPER register.

Again, I think it would be worth explaining that you populate
GICR_TYPER.Process_Number because the ITS will use it later on.

>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  xen/arch/arm/vgic-v3.c | 76 +++++++++++++++++++++++++++++++++++++++++++++-----
>  1 file changed, 69 insertions(+), 7 deletions(-)
>
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index e2e5bc1..134e1b0 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -170,8 +170,19 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, mmio_info_t *info,
>      switch ( gicr_reg )
>      {
>      case VREG32(GICR_CTLR):
> -        /* We have not implemented LPI's, read zero */
> -        goto read_as_zero_32;
> +    {
> +        unsigned long flags;
> +
> +        if ( !v->domain->arch.vgic.has_its )
> +            goto read_as_zero_32;
> +        if ( dabt.size != DABT_WORD ) goto bad_width;
> +
> +        spin_lock_irqsave(&v->arch.vgic.lock, flags);
> +        *r = vgic_reg32_extract(!!(v->arch.vgic.flags & VGIC_V3_LPIS_ENABLED),
> +                                info);
> +        spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
> +        return 1;
> +    }
>
>      case VREG32(GICR_IIDR):
>          if ( dabt.size != DABT_WORD ) goto bad_width;
> @@ -183,16 +194,20 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, mmio_info_t *info,
>          uint64_t typer, aff;
>
>          if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
> -        /* TBD: Update processor id in [23:8] when ITS support is added */
>          aff = (MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 3) << 56 |
>                 MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 48 |
>                 MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 1) << 40 |
>                 MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 0) << 32);
>          typer = aff;
> +        /* We use the VCPU ID as the redistributor ID in bits[23:8] */
> +        typer |= v->vcpu_id << GICR_TYPER_PROC_NUM_SHIFT;
>
>          if ( v->arch.vgic.flags & VGIC_V3_RDIST_LAST )
>              typer |= GICR_TYPER_LAST;
>
> +        if ( v->domain->arch.vgic.has_its )
> +            typer |= GICR_TYPER_PLPIS;
> +
>          *r = vgic_reg64_extract(typer, info);
>
>          return 1;
> @@ -426,6 +441,33 @@ static uint64_t sanitize_pendbaser(uint64_t reg)
>      return reg;
>  }
>
> +static void vgic_vcpu_enable_lpis(struct vcpu *v)
> +{
> +    uint64_t reg = v->domain->arch.vgic.rdist_propbase;
> +    unsigned int nr_lpis = BIT((reg & 0x1f) + 1);
> +
> +    /* rdists_enabled is protected by the domain lock. */
> +    ASSERT(spin_is_locked(&v->domain->arch.vgic.lock));
> +
> +    if ( nr_lpis < LPI_OFFSET )
> +        nr_lpis = 0;
> +    else
> +        nr_lpis -= LPI_OFFSET;
> +
> +    if ( !v->domain->arch.vgic.rdists_enabled )
> +    {
> +        v->domain->arch.vgic.nr_lpis = nr_lpis;
> +        v->domain->arch.vgic.rdists_enabled = true;
> +        /*
> +         * Make sure the per-domain rdists_enabled flag has been set before
> +         * enabling this particular redistributor.

Hmmm, you also used nr_lpis in the vITS code without any locked. So this 
barrier is not only there for rdists_enabled.

> +         */
> +        smp_mb();

I would have expected a bit more documentation based on the discussion 
we had on the previous version. For instance, why do you need this 
memory barrier?...

> +    }
> +
> +    v->arch.vgic.flags |= VGIC_V3_LPIS_ENABLED;
> +}
> +
>  static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, mmio_info_t *info,
>                                            uint32_t gicr_reg,
>                                            register_t r)
> @@ -436,8 +478,26 @@ static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, mmio_info_t *info,
>      switch ( gicr_reg )
>      {
>      case VREG32(GICR_CTLR):
> -        /* LPI's not implemented */
> -        goto write_ignore_32;
> +    {
> +        unsigned long flags;
> +
> +        if ( !v->domain->arch.vgic.has_its )
> +            goto write_ignore_32;
> +        if ( dabt.size != DABT_WORD ) goto bad_width;
> +
> +        vgic_lock(v);                   /* protects rdists_enabled */
> +        spin_lock_irqsave(&v->arch.vgic.lock, flags);
> +
> +        /* LPIs can only be enabled once, but never disabled again. */
> +        if ( (r & GICR_CTLR_ENABLE_LPIS) &&
> +             !(v->arch.vgic.flags & VGIC_V3_LPIS_ENABLED) )
> +            vgic_vcpu_enable_lpis(v);
> +
> +        spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
> +        vgic_unlock(v);
> +
> +        return 1;
> +    }
>
>      case VREG32(GICR_IIDR):
>          /* RO */
> @@ -1045,7 +1105,6 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, mmio_info_t *info,
>           * Number of interrupt identifier bits supported by the GIC
>           * Stream Protocol Interface
>           */
> -        unsigned int irq_bits = get_count_order(vgic_num_irqs(v->domain));
>          /*
>           * Number of processors that may be used as interrupt targets when ARE
>           * bit is zero. The maximum is 8.
> @@ -1058,7 +1117,10 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, mmio_info_t *info,
>          typer = ((ncpus - 1) << GICD_TYPE_CPUS_SHIFT |
>                   DIV_ROUND_UP(v->domain->arch.vgic.nr_spis, 32));
>
> -        typer |= (irq_bits - 1) << GICD_TYPE_ID_BITS_SHIFT;
> +        if ( v->domain->arch.vgic.has_its )
> +            typer |= GICD_TYPE_LPIS;
> +
> +        typer |= (v->domain->arch.vgic.intid_bits - 1) << GICD_TYPE_ID_BITS_SHIFT;
>
>          *r = vgic_reg32_extract(typer, info);
>
>

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 01/32] ARM: vGIC: avoid rank lock when reading priority

[Stefano Stabellini]

On Tue, 30 May 2017, Julien Grall wrote:
> Hi Andre,
> 
> On 26/05/17 18:35, Andre Przywara wrote:
> > When reading the priority value of a virtual interrupt, we were taking
> > the respective rank lock so far.
> > However for forwarded interrupts (Dom0 only so far) this may lead to a
> > deadlock with the following call chain:
> > - MMIO access to change the IRQ affinity, calling the ITARGETSR handler
> > - this handler takes the appropriate rank lock and calls
> > vgic_store_itargetsr()
> > - vgic_store_itargetsr() will eventually call vgic_migrate_irq()
> > - if this IRQ is already in-flight, it will remove it from the old
> >   VCPU and inject it into the new one, by calling vgic_vcpu_inject_irq()
> > - vgic_vcpu_inject_irq will call vgic_get_virq_priority()
> > - vgic_get_virq_priority() tries to take the rank lock - again!
> > It seems like this code path has never been exercised before.
> > 
> > Fix this by avoiding taking the lock in vgic_get_virq_priority() (like we
> > do in vgic_get_target_vcpu()).
> > Actually we are just reading one byte, and priority changes while
> > interrupts are handled are a benign race that can happen on real hardware
> > too. So it looks safe to just use read_atomic() instead.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> >  xen/arch/arm/vgic.c | 8 +-------
> >  1 file changed, 1 insertion(+), 7 deletions(-)
> > 
> > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> > index 83569b0..54b2aad 100644
> > --- a/xen/arch/arm/vgic.c
> > +++ b/xen/arch/arm/vgic.c
> > @@ -227,14 +227,8 @@ struct vcpu *vgic_get_target_vcpu(struct vcpu *v,
> > unsigned int virq)
> >  static int vgic_get_virq_priority(struct vcpu *v, unsigned int virq)
> >  {
> >      struct vgic_irq_rank *rank = vgic_rank_irq(v, virq);
> > -    unsigned long flags;
> > -    int priority;
> > -
> > -    vgic_lock_rank(v, rank, flags);
> > -    priority = rank->priority[virq & INTERRUPT_RANK_MASK];
> > -    vgic_unlock_rank(v, rank, flags);
> > 
> > -    return priority;
> > +    return read_atomic(&rank->priority[virq & INTERRUPT_RANK_MASK]);
> 
> The write in rank->priority will not be atomic (see vgic_reg_update
> implementation): the register is first masked, the the priority set.
> 
> So you may end up to read 0 (which is the higher priority) by mistake.
> 
> We should probably think to make vgic_reg_* helper atomic.

Right! That's why I wrote
alpine.DEB.2.10.1705231135130.18759@sstabellini-ThinkPad-X260


> >  }
> > 
> >  bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned int irq)
> > 
> 
> Cheers,
> 
> -- 
> Julien Grall
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 03/32] ARM: vGIC: move irq_to_pending() calls under the VGIC VCPU lock

[Stefano Stabellini]

On Tue, 30 May 2017, Julien Grall wrote:
> Hi Andre,
> 
> On 26/05/17 18:35, Andre Przywara wrote:
> > So far irq_to_pending() is just a convenience function to lookup
> > statically allocated arrays. This will change with LPIs, which are
> > more dynamic, so the memory for their struct pending_irq might go away.
> > The proper answer to the issue of preventing stale pointers is
> > ref-counting, which requires more rework and will be introduced with
> > a later rework.
> > For now move the irq_to_pending() calls that are used with LPIs under the
> > VGIC VCPU lock, and only use the returned pointer while holding the lock.
> > This prevents the memory from being freed while we use it.
> > For the sake of completeness we take care about all irq_to_pending()
> > users, even those which later will never deal with LPIs.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> >  xen/arch/arm/gic.c  |  5 ++++-
> >  xen/arch/arm/vgic.c | 39 ++++++++++++++++++++++++++++++---------
> >  2 files changed, 34 insertions(+), 10 deletions(-)
> > 
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> > index da19130..dcb1783 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -402,10 +402,13 @@ static inline void gic_add_to_lr_pending(struct vcpu
> > *v, struct pending_irq *n)
> > 
> >  void gic_remove_from_queues(struct vcpu *v, unsigned int virtual_irq)
> >  {
> > -    struct pending_irq *p = irq_to_pending(v, virtual_irq);
> > +    struct pending_irq *p;
> >      unsigned long flags;
> > 
> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> > +
> > +    p = irq_to_pending(v, virtual_irq);
> > +
> >      if ( !list_empty(&p->lr_queue) )
> >          list_del_init(&p->lr_queue);
> >      spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
> > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> > index 54b2aad..69d732b 100644
> > --- a/xen/arch/arm/vgic.c
> > +++ b/xen/arch/arm/vgic.c
> > @@ -234,23 +234,29 @@ static int vgic_get_virq_priority(struct vcpu *v,
> > unsigned int virq)
> >  bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned int irq)
> >  {
> >      unsigned long flags;
> > -    struct pending_irq *p = irq_to_pending(old, irq);
> > +    struct pending_irq *p;
> > +
> > +    spin_lock_irqsave(&old->arch.vgic.lock, flags);
> > +
> > +    p = irq_to_pending(old, irq);
> > 
> >      /* nothing to do for virtual interrupts */
> >      if ( p->desc == NULL )
> > +    {
> > +        spin_unlock_irqrestore(&old->arch.vgic.lock, flags);
> >          return true;
> > +    }
> > 
> >      /* migration already in progress, no need to do anything */
> >      if ( test_bit(GIC_IRQ_GUEST_MIGRATING, &p->status) )
> >      {
> >          gprintk(XENLOG_WARNING, "irq %u migration failed: requested while
> > in progress\n", irq);
> > +        spin_unlock_irqrestore(&old->arch.vgic.lock, flags);
> >          return false;
> >      }
> > 
> >      perfc_incr(vgic_irq_migrates);
> > 
> > -    spin_lock_irqsave(&old->arch.vgic.lock, flags);
> > -
> >      if ( list_empty(&p->inflight) )
> >      {
> >          irq_set_affinity(p->desc, cpumask_of(new->processor));
> > @@ -285,6 +291,13 @@ void arch_move_irqs(struct vcpu *v)
> >      struct vcpu *v_target;
> >      int i;
> > 
> > +    /*
> > +     * We don't migrate LPIs at the moment.
> > +     * If we ever do, we must make sure that the struct pending_irq does
> > +     * not go away, as there is no lock preventing this here.
> > +     */
> > +    ASSERT(!is_lpi(vgic_num_irqs(d) - 1));
> 
> Hmmm? This raise a question of why vgic_num_irqs does not include the LPIs
> today...
> 
> > +
> >      for ( i = 32; i < vgic_num_irqs(d); i++ )
> >      {
> >          v_target = vgic_get_target_vcpu(v, i);
> > @@ -299,6 +312,7 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int
> > n)
> >  {
> >      const unsigned long mask = r;
> >      struct pending_irq *p;
> > +    struct irq_desc *desc;
> >      unsigned int irq;
> >      unsigned long flags;
> >      int i = 0;
> > @@ -307,14 +321,19 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int
> > n)
> >      while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
> >          irq = i + (32 * n);
> >          v_target = vgic_get_target_vcpu(v, irq);
> > +
> > +        spin_lock_irqsave(&v_target->arch.vgic.lock, flags);
> >          p = irq_to_pending(v_target, irq);
> >          clear_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
> >          gic_remove_from_queues(v_target, irq);
> 
> gic_remove_from_queues is taking v_target vGIC lock. So you just introduced a
> deadlock. You remove it in the next patch but still, we should not introduce
> regression even temporarily. This would make to difficult to bisect the
> series.

Yeah, we cannot introduce regressions like this one.


> TBH, I am not a big fan of spreading the mess of vGIC locking when we are
> going to rework the vGIC and know that this code will not be called for LPIs.

I asked for this in
alpine.DEB.2.10.1705191729560.18759@sstabellini-ThinkPad-X260, this way
we covered all basis. The double lock is bad, but the rest of the
changes look OK to me.


> BTW, this series is not bisectable because the host ITS is only enabled from
> patch #12.
> 
> > -        if ( p->desc != NULL )
> > +        desc = p->desc;
> > +        spin_unlock_irqrestore(&v_target->arch.vgic.lock, flags);
> > +
> > +        if ( desc != NULL )
> >          {
> > -            spin_lock_irqsave(&p->desc->lock, flags);
> > -            p->desc->handler->disable(p->desc);
> > -            spin_unlock_irqrestore(&p->desc->lock, flags);
> > +            spin_lock_irqsave(&desc->lock, flags);
> > +            desc->handler->disable(desc);
> > +            spin_unlock_irqrestore(&desc->lock, flags);
> >          }
> >          i++;
> >      }
> > @@ -349,9 +368,9 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
> >      while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
> >          irq = i + (32 * n);
> >          v_target = vgic_get_target_vcpu(v, irq);
> > +        spin_lock_irqsave(&v_target->arch.vgic.lock, flags);
> >          p = irq_to_pending(v_target, irq);
> >          set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
> > -        spin_lock_irqsave(&v_target->arch.vgic.lock, flags);
> >          if ( !list_empty(&p->inflight) && !test_bit(GIC_IRQ_GUEST_VISIBLE,
> > &p->status) )
> >              gic_raise_guest_irq(v_target, irq, p->priority);
> >          spin_unlock_irqrestore(&v_target->arch.vgic.lock, flags);
> > @@ -460,7 +479,7 @@ void vgic_clear_pending_irqs(struct vcpu *v)
> >  void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq)
> >  {
> >      uint8_t priority;
> > -    struct pending_irq *iter, *n = irq_to_pending(v, virq);
> > +    struct pending_irq *iter, *n;
> >      unsigned long flags;
> >      bool running;
> > 
> > @@ -468,6 +487,8 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int
> > virq)
> > 
> >      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> > 
> > +    n = irq_to_pending(v, virq);
> > +
> >      /* vcpu offline */
> >      if ( test_bit(_VPF_down, &v->pause_flags) )
> >      {
> > 
> 
> Cheers,
> 
> -- 
> Julien Grall
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 11/32] ARM: GICv3: forward pending LPIs to guests

[Stefano Stabellini]

On Tue, 30 May 2017, Julien Grall wrote:
> Hi Andre,
> 
> On 26/05/17 18:35, 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 the domain ID and the virtual
> > LPI number quickly when the host takes an LPI. We then look up the
> > right VCPU in the struct pending_irq.
> > We use the existing injection function to let the GIC emulation deal
> > with this interrupt.
> > This introduces a do_LPI() as a hardware gic_ops.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> >  xen/arch/arm/gic-v2.c            |  7 ++++
> >  xen/arch/arm/gic-v3-lpi.c        | 76
> > ++++++++++++++++++++++++++++++++++++++--
> >  xen/arch/arm/gic-v3.c            |  1 +
> >  xen/arch/arm/gic.c               |  8 ++++-
> >  xen/include/asm-arm/domain.h     |  3 +-
> >  xen/include/asm-arm/gic.h        |  2 ++
> >  xen/include/asm-arm/gic_v3_its.h |  8 +++++
> >  7 files changed, 101 insertions(+), 4 deletions(-)
> > 
> > diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> > index 270a136..ffbe47c 100644
> > --- a/xen/arch/arm/gic-v2.c
> > +++ b/xen/arch/arm/gic-v2.c
> > @@ -1217,6 +1217,12 @@ static int __init gicv2_init(void)
> >      return 0;
> >  }
> > 
> > +static void gicv2_do_LPI(unsigned int lpi)
> > +{
> > +    /* No LPIs in a GICv2 */
> > +    BUG();
> > +}
> > +
> >  const static struct gic_hw_operations gicv2_ops = {
> >      .info                = &gicv2_info,
> >      .init                = gicv2_init,
> > @@ -1244,6 +1250,7 @@ const static struct gic_hw_operations gicv2_ops = {
> >      .make_hwdom_madt     = gicv2_make_hwdom_madt,
> >      .map_hwdom_extra_mappings = gicv2_map_hwdown_extra_mappings,
> >      .iomem_deny_access   = gicv2_iomem_deny_access,
> > +    .do_LPI              = gicv2_do_LPI,
> >  };
> > 
> >  /* Set up the GIC */
> > diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
> > index 292f2d0..438bbfe 100644
> > --- a/xen/arch/arm/gic-v3-lpi.c
> > +++ b/xen/arch/arm/gic-v3-lpi.c
> > @@ -47,7 +47,6 @@ union host_lpi {
> >      struct {
> >          uint32_t virt_lpi;
> >          uint16_t dom_id;
> > -        uint16_t vcpu_id;
> 
> You don't explain why you remove vcpu_id from host_lpi. This likely require a
> separate patch anyway.
> 
> Also, I would prefer if you make the padding in the structure explicit (i.e
> using pad0).
> 
> >      };
> >  };
> > 
> > @@ -136,6 +135,80 @@ uint64_t gicv3_get_redist_address(unsigned int cpu,
> > bool use_pta)
> >          return per_cpu(lpi_redist, cpu).redist_id << 16;
> >  }
> > 
> > +static void vgic_vcpu_inject_lpi(struct domain *d, unsigned int virq)
> > +{
> > +    struct pending_irq *p = irq_to_pending(d->vcpu[0], virq);
> > +    struct vcpu *v = NULL;
> > +
> > +    if ( !p )
> > +        return;
> > +
> > +    if ( p->lpi_vcpu_id < d->max_vcpus )
> > +        v = d->vcpu[read_atomic(&p->lpi_vcpu_id)];
> 
> Hmmm, what does prevent lpi_vcpu_id to change between the check and the read?

Supposedly we are going to set lpi_vcpu_id only to good values? Meaning
that we are going to do the lpi_vcpu_id checks at the time of setting
lpi_vcpu_id. Thus, even if lpi_vcpu_id changes, it is not a problem. In
fact, if that is true, can we even drop the if ( p->lpi_vcpu_id <
d->max_vcpus ) test here?


> > +
> > +    if ( v )
> 
> v will always be valid if you read d->vcpu[....] and the way you wrote the
> code is very confusing.
> 
> It would be clearer if you do:
> 
> if ( p->lpi_vcpu_id >= d->max_vcpus )
>   return;
> 
> v = ....
> vgic_vcpu_inject_irq(v, irq);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 28/32] ARM: vITS: handle INV command

[Stefano Stabellini]

On Fri, 26 May 2017, Andre Przywara wrote:
> 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 virtual pending bit if an LPI gets enabled.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

> ---
>  xen/arch/arm/vgic-v3-its.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 70 insertions(+)
> 
> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
> index 773e5fb..14fde83 100644
> --- a/xen/arch/arm/vgic-v3-its.c
> +++ b/xen/arch/arm/vgic-v3-its.c
> @@ -449,6 +449,73 @@ static int update_lpi_property(struct domain *d, struct pending_irq *p)
>      return 0;
>  }
>  
> +/*
> + * Checks whether an LPI that got enabled or disabled needs to change
> + * something in the VGIC (added or removed from the LR or queues).
> + * We don't disable the underlying physical LPI, because this requires
> + * queueing a host LPI command, which we can't afford to do on behalf
> + * of a guest.
> + * Must be called with the VCPU VGIC lock held.
> + */
> +static void update_lpi_vgic_status(struct vcpu *v, struct pending_irq *p)
> +{
> +    ASSERT(spin_is_locked(&v->arch.vgic.lock));
> +
> +    if ( test_bit(GIC_IRQ_GUEST_ENABLED, &p->status) )
> +    {
> +        if ( !list_empty(&p->inflight) &&
> +             !test_bit(GIC_IRQ_GUEST_VISIBLE, &p->status) )
> +            gic_raise_guest_irq(v, p->irq, p->lpi_priority);
> +    }
> +    else
> +        gic_remove_from_lr_pending(v, p);
> +}
> +
> +static int its_handle_inv(struct virt_its *its, uint64_t *cmdptr)
> +{
> +    struct domain *d = its->d;
> +    uint32_t devid = its_cmd_get_deviceid(cmdptr);
> +    uint32_t eventid = its_cmd_get_id(cmdptr);
> +    struct pending_irq *p;
> +    unsigned long flags;
> +    struct vcpu *vcpu;
> +    uint32_t vlpi;
> +    int ret = -1;
> +
> +    spin_lock(&its->its_lock);
> +
> +    /* Translate the event into a vCPU/vLPI pair. */
> +    if ( !read_itte_locked(its, devid, eventid, &vcpu, &vlpi) )
> +        goto out_unlock_its;
> +
> +    if ( vlpi == INVALID_LPI )
> +        goto out_unlock_its;
> +
> +    p = gicv3_its_get_event_pending_irq(d, its->doorbell_address,
> +                                        devid, eventid);
> +    if ( unlikely(!p) )
> +        goto out_unlock_its;
> +
> +    spin_lock_irqsave(&vcpu->arch.vgic.lock, flags);
> +
> +    /* Read the property table and update our cached status. */
> +    if ( update_lpi_property(d, p) )
> +        goto out_unlock;
> +
> +    /* Check whether the LPI needs to go on a VCPU. */
> +    update_lpi_vgic_status(vcpu, p);
> +
> +    ret = 0;
> +
> +out_unlock:
> +    spin_unlock_irqrestore(&vcpu->arch.vgic.lock, flags);
> +
> +out_unlock_its:
> +    spin_unlock(&its->its_lock);
> +
> +    return ret;
> +}
> +
>  /* Must be called with the ITS lock held. */
>  static int its_discard_event(struct virt_its *its,
>                               uint32_t vdevid, uint32_t vevid)
> @@ -788,6 +855,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its)
>          case GITS_CMD_INT:
>              ret = its_handle_int(its, command);
>              break;
> +        case GITS_CMD_INV:
> +            ret = its_handle_inv(its, command);
> +            break;
>          case GITS_CMD_MAPC:
>              ret = its_handle_mapc(its, command);
>              break;
> -- 
> 2.9.0
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 26/32] ARM: vITS: handle MOVI command

[Stefano Stabellini]

On Fri, 26 May 2017, Andre Przywara wrote:
> 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 our virtual ITTE and the pending_irq.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  xen/arch/arm/vgic-v3-its.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 66 insertions(+)
> 
> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
> index c350fa5..3332c09 100644
> --- a/xen/arch/arm/vgic-v3-its.c
> +++ b/xen/arch/arm/vgic-v3-its.c
> @@ -666,6 +666,66 @@ out_remove_mapping:
>      return ret;
>  }
>  
> +static int its_handle_movi(struct virt_its *its, uint64_t *cmdptr)
> +{
> +    uint32_t devid = its_cmd_get_deviceid(cmdptr);
> +    uint32_t eventid = its_cmd_get_id(cmdptr);
> +    uint16_t collid = its_cmd_get_collection(cmdptr);
> +    unsigned long flags;
> +    struct pending_irq *p;
> +    struct vcpu *ovcpu, *nvcpu;
> +    uint32_t vlpi;
> +    int ret = -1;
> +
> +    spin_lock(&its->its_lock);
> +    /* Check for a mapped LPI and get the LPI number. */
> +    if ( !read_itte_locked(its, devid, eventid, &ovcpu, &vlpi) )
> +        goto out_unlock;
> +
> +    if ( vlpi == INVALID_LPI )
> +        goto out_unlock;
> +
> +    /* Check the new collection ID and get the new VCPU pointer */
> +    nvcpu = get_vcpu_from_collection(its, collid);
> +    if ( !nvcpu )
> +        goto out_unlock;
> +
> +    p = gicv3_its_get_event_pending_irq(its->d, its->doorbell_address,
> +                                        devid, eventid);
> +    if ( unlikely(!p) )
> +        goto out_unlock;
> +
> +    /*
> +     * TODO: This relies on the VCPU being correct in the ITS tables.
> +     * This can be fixed by either using a per-IRQ lock or by using
> +     * the VCPU ID from the pending_irq instead.
> +     */
> +    spin_lock_irqsave(&ovcpu->arch.vgic.lock, flags);
> +
> +    /* Update our cached vcpu_id in the pending_irq. */
> +    p->lpi_vcpu_id = nvcpu->vcpu_id;
> +
> +    spin_unlock_irqrestore(&ovcpu->arch.vgic.lock, flags);
> +
> +    /*
> +     * TODO: lookup currently-in-guest virtual IRQs and migrate them,
> +     * as the locking may be fragile otherwise.
> +     * This is not easy to do at the moment, but should become easier
> +     * with the introduction of a per-IRQ lock.
> +     */

Sure but at least we can handle the inflight, but not in guest, case. It
is just a matter of adding (withing the arch.vgic.lock locked region):

    if ( !list_empty(&p->lr_queue) )
    {
        gic_remove_irq(old, p);
        clear_bit(GIC_IRQ_GUEST_QUEUED, &p->status);
        list_del_init(&p->lr_queue);
        list_del_init(&p->inflight);

        spin_unlock_irqrestore(&old->arch.vgic.lock, flags);
        vgic_vcpu_inject_irq(new, irq);
    }

That is simple and there are no problems with locking. The problem is
with the other case: !list_empty(&p->inflight) &&
list_empty(&p->lr_queue), which is the one for which you need to keep
this TODO comment.


> +    /* Now store the new collection in the translation table. */
> +    if ( !write_itte_locked(its, devid, eventid, collid, vlpi, &nvcpu) )
> +        goto out_unlock;
> +
> +    ret = 0;
> +
> +out_unlock:
> +    spin_unlock(&its->its_lock);
> +
> +    return ret;
> +}
> +
>  #define ITS_CMD_BUFFER_SIZE(baser)      ((((baser) & 0xff) + 1) << 12)
>  #define ITS_CMD_OFFSET(reg)             ((reg) & GENMASK(19, 5))
>  
> @@ -711,6 +771,12 @@ static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its)
>          case GITS_CMD_MAPTI:
>              ret = its_handle_mapti(its, command);
>              break;
> +        case GITS_CMD_MOVALL:
> +            gdprintk(XENLOG_G_INFO, "vGITS: ignoring MOVALL command\n");
> +            break;
> +        case GITS_CMD_MOVI:
> +            ret = its_handle_movi(its, command);
> +            break;
>          case GITS_CMD_SYNC:
>              /* We handle ITS commands synchronously, so we ignore SYNC. */
>              break;
> -- 
> 2.9.0
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 01/32] ARM: vGIC: avoid rank lock when reading priority

[Julien Grall]

Hi Stefano,

On 30/05/17 22:39, Stefano Stabellini wrote:
> On Tue, 30 May 2017, Julien Grall wrote:
>> Hi Andre,
>>
>> On 26/05/17 18:35, Andre Przywara wrote:
>>> When reading the priority value of a virtual interrupt, we were taking
>>> the respective rank lock so far.
>>> However for forwarded interrupts (Dom0 only so far) this may lead to a
>>> deadlock with the following call chain:
>>> - MMIO access to change the IRQ affinity, calling the ITARGETSR handler
>>> - this handler takes the appropriate rank lock and calls
>>> vgic_store_itargetsr()
>>> - vgic_store_itargetsr() will eventually call vgic_migrate_irq()
>>> - if this IRQ is already in-flight, it will remove it from the old
>>>   VCPU and inject it into the new one, by calling vgic_vcpu_inject_irq()
>>> - vgic_vcpu_inject_irq will call vgic_get_virq_priority()
>>> - vgic_get_virq_priority() tries to take the rank lock - again!
>>> It seems like this code path has never been exercised before.
>>>
>>> Fix this by avoiding taking the lock in vgic_get_virq_priority() (like we
>>> do in vgic_get_target_vcpu()).
>>> Actually we are just reading one byte, and priority changes while
>>> interrupts are handled are a benign race that can happen on real hardware
>>> too. So it looks safe to just use read_atomic() instead.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>> ---
>>>  xen/arch/arm/vgic.c | 8 +-------
>>>  1 file changed, 1 insertion(+), 7 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
>>> index 83569b0..54b2aad 100644
>>> --- a/xen/arch/arm/vgic.c
>>> +++ b/xen/arch/arm/vgic.c
>>> @@ -227,14 +227,8 @@ struct vcpu *vgic_get_target_vcpu(struct vcpu *v,
>>> unsigned int virq)
>>>  static int vgic_get_virq_priority(struct vcpu *v, unsigned int virq)
>>>  {
>>>      struct vgic_irq_rank *rank = vgic_rank_irq(v, virq);
>>> -    unsigned long flags;
>>> -    int priority;
>>> -
>>> -    vgic_lock_rank(v, rank, flags);
>>> -    priority = rank->priority[virq & INTERRUPT_RANK_MASK];
>>> -    vgic_unlock_rank(v, rank, flags);
>>>
>>> -    return priority;
>>> +    return read_atomic(&rank->priority[virq & INTERRUPT_RANK_MASK]);
>>
>> The write in rank->priority will not be atomic (see vgic_reg_update
>> implementation): the register is first masked, the the priority set.
>>
>> So you may end up to read 0 (which is the higher priority) by mistake.
>>
>> We should probably think to make vgic_reg_* helper atomic.
>
> Right! That's why I wrote
> alpine.DEB.2.10.1705231135130.18759@sstabellini-ThinkPad-X260

It was not obvious from this e-mail why you wanted this. It looked more 
a request for improvement rather than a potential bug. Hence my 
suggestion to delay it.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 03/32] ARM: vGIC: move irq_to_pending() calls under the VGIC VCPU lock

[Julien Grall]

Hi Stefano,

On 30/05/17 22:46, Stefano Stabellini wrote:
> On Tue, 30 May 2017, Julien Grall wrote
>> On 26/05/17 18:35, Andre Przywara wrote:
>> TBH, I am not a big fan of spreading the mess of vGIC locking when we are
>> going to rework the vGIC and know that this code will not be called for LPIs.
>
> I asked for this in
> alpine.DEB.2.10.1705191729560.18759@sstabellini-ThinkPad-X260, this way
> we covered all basis. The double lock is bad, but the rest of the
> changes look OK to me.

It is just adding more churn that will have to be reworked when fixing 
the vGIC. Anyway, I am not going to argue on that.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 11/32] ARM: GICv3: forward pending LPIs to guests

[Julien Grall]

Hi Stefano,

On 30/05/17 23:07, Stefano Stabellini wrote:
> On Tue, 30 May 2017, Julien Grall wrote:
>>>      };
>>>  };
>>>
>>> @@ -136,6 +135,80 @@ uint64_t gicv3_get_redist_address(unsigned int cpu,
>>> bool use_pta)
>>>          return per_cpu(lpi_redist, cpu).redist_id << 16;
>>>  }
>>>
>>> +static void vgic_vcpu_inject_lpi(struct domain *d, unsigned int virq)
>>> +{
>>> +    struct pending_irq *p = irq_to_pending(d->vcpu[0], virq);
>>> +    struct vcpu *v = NULL;
>>> +
>>> +    if ( !p )
>>> +        return;
>>> +
>>> +    if ( p->lpi_vcpu_id < d->max_vcpus )
>>> +        v = d->vcpu[read_atomic(&p->lpi_vcpu_id)];
>>
>> Hmmm, what does prevent lpi_vcpu_id to change between the check and the read?
>
> Supposedly we are going to set lpi_vcpu_id only to good values? Meaning
> that we are going to do the lpi_vcpu_id checks at the time of setting
> lpi_vcpu_id. Thus, even if lpi_vcpu_id changes, it is not a problem. In
> fact, if that is true, can we even drop the if ( p->lpi_vcpu_id <
> d->max_vcpus ) test here?

I am not too confident to say lpi_vcpu_id will always be valid with the 
current locking in the vGIC.

There is a potential race between its_discard_event and this function. 
The former may reset pending_irq whilst reading lpi_vcpu_id as we cannot 
take the vCPU lock yet.

But all of this is racy anyway because of the locking. This will get 
solved by the vGIC rework after the merge.

So For the time being I would keep the check. We can revisit it later if 
necessary.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 26/32] ARM: vITS: handle MOVI command

[Julien Grall]

Hi Stefano,

On 30/05/17 23:35, Stefano Stabellini wrote:
>> +    /*
>> +     * TODO: lookup currently-in-guest virtual IRQs and migrate them,
>> +     * as the locking may be fragile otherwise.
>> +     * This is not easy to do at the moment, but should become easier
>> +     * with the introduction of a per-IRQ lock.
>> +     */
>
> Sure but at least we can handle the inflight, but not in guest, case. It
> is just a matter of adding (withing the arch.vgic.lock locked region):
>
>     if ( !list_empty(&p->lr_queue) )
>     {
>         gic_remove_irq(old, p);
>         clear_bit(GIC_IRQ_GUEST_QUEUED, &p->status);
>         list_del_init(&p->lr_queue);
>         list_del_init(&p->inflight);
>
>         spin_unlock_irqrestore(&old->arch.vgic.lock, flags);
>         vgic_vcpu_inject_irq(new, irq);
>     }

Please no more hardcoding of migration code. If we are going to support 
migration we should rework the current function vgic_migrate_irq to 
support LPIs.

But ... I don't see any drawback to not support this today. Per the 
specification, when you migrate an interrupt the only things you have to 
ensure if the pending interrupt only fire once either on the old or new 
vCPU.

IHMO, if the interrupt has already been queued then it is too late. We 
should aim at simplifying the code if there are no drawback to do it. In 
this case, what would be the drawback to leave pending on the old vCPU?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 26/32] ARM: vITS: handle MOVI command

[Stefano Stabellini]

On Wed, 31 May 2017, Julien Grall wrote:
> Hi Stefano,
> 
> On 30/05/17 23:35, Stefano Stabellini wrote:
> > > +    /*
> > > +     * TODO: lookup currently-in-guest virtual IRQs and migrate them,
> > > +     * as the locking may be fragile otherwise.
> > > +     * This is not easy to do at the moment, but should become easier
> > > +     * with the introduction of a per-IRQ lock.
> > > +     */
> > 
> > Sure but at least we can handle the inflight, but not in guest, case. It
> > is just a matter of adding (withing the arch.vgic.lock locked region):
> > 
> >     if ( !list_empty(&p->lr_queue) )
> >     {
> >         gic_remove_irq(old, p);
> >         clear_bit(GIC_IRQ_GUEST_QUEUED, &p->status);
> >         list_del_init(&p->lr_queue);
> >         list_del_init(&p->inflight);
> > 
> >         spin_unlock_irqrestore(&old->arch.vgic.lock, flags);
> >         vgic_vcpu_inject_irq(new, irq);
> >     }
> 
> Please no more hardcoding of migration code. If we are going to support
> migration we should rework the current function vgic_migrate_irq to support
> LPIs.

I agree, it is true, in fact that is what I actually suggested last
time. My preference would be to just call vgic_migrate_irq, providing an
empty implementation of irq_set_affinity for LPIs.


> But ... I don't see any drawback to not support this today. Per the
> specification, when you migrate an interrupt the only things you have to
> ensure if the pending interrupt only fire once either on the old or new vCPU.
> 
> IHMO, if the interrupt has already been queued then it is too late. We should
> aim at simplifying the code if there are no drawback to do it. In this case,
> what would be the drawback to leave pending on the old vCPU?

It is inconsistent with what we do elsewhere (vgic_migrate_irq). It is
also inconsistent with the TODO comment (!list_empty(&p->lr_queue)
interrupts are not yet currently-in-guest).

I don't want to introduce any more hardcoding, I just would like the
existing vgic_migrate_irq to be called.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 11/32] ARM: GICv3: forward pending LPIs to guests

[Stefano Stabellini]

On Wed, 31 May 2017, Julien Grall wrote:
> Hi Stefano,
> 
> On 30/05/17 23:07, Stefano Stabellini wrote:
> > On Tue, 30 May 2017, Julien Grall wrote:
> > > >      };
> > > >  };
> > > > 
> > > > @@ -136,6 +135,80 @@ uint64_t gicv3_get_redist_address(unsigned int cpu,
> > > > bool use_pta)
> > > >          return per_cpu(lpi_redist, cpu).redist_id << 16;
> > > >  }
> > > > 
> > > > +static void vgic_vcpu_inject_lpi(struct domain *d, unsigned int virq)
> > > > +{
> > > > +    struct pending_irq *p = irq_to_pending(d->vcpu[0], virq);
> > > > +    struct vcpu *v = NULL;
> > > > +
> > > > +    if ( !p )
> > > > +        return;
> > > > +
> > > > +    if ( p->lpi_vcpu_id < d->max_vcpus )
> > > > +        v = d->vcpu[read_atomic(&p->lpi_vcpu_id)];
> > > 
> > > Hmmm, what does prevent lpi_vcpu_id to change between the check and the
> > > read?
> > 
> > Supposedly we are going to set lpi_vcpu_id only to good values? Meaning
> > that we are going to do the lpi_vcpu_id checks at the time of setting
> > lpi_vcpu_id. Thus, even if lpi_vcpu_id changes, it is not a problem. In
> > fact, if that is true, can we even drop the if ( p->lpi_vcpu_id <
> > d->max_vcpus ) test here?
> 
> I am not too confident to say lpi_vcpu_id will always be valid with the
> current locking in the vGIC.

Fair enough, but I wouldn't solve a bug with unnecessary code soon to be
removed. The problem lies elsewhere and should be fixed elsewhere. We
could even add an ASSERT(p->lpi_vcpu_id < d->max_vcpus) here, would
that work for you?


> There is a potential race between its_discard_event and this function. The
> former may reset pending_irq whilst reading lpi_vcpu_id as we cannot take the
> vCPU lock yet.
> 
> But all of this is racy anyway because of the locking. This will get solved by
> the vGIC rework after the merge.
> 
> So For the time being I would keep the check. We can revisit it later if
> necessary.

This is one of those things that are unimportant because they work
either way.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 11/32] ARM: GICv3: forward pending LPIs to guests

[Julien Grall]

Hi Stefano,

On 31/05/2017 18:56, Stefano Stabellini wrote:
> On Wed, 31 May 2017, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 30/05/17 23:07, Stefano Stabellini wrote:
>>> On Tue, 30 May 2017, Julien Grall wrote:
>>>>>      };
>>>>>  };
>>>>>
>>>>> @@ -136,6 +135,80 @@ uint64_t gicv3_get_redist_address(unsigned int cpu,
>>>>> bool use_pta)
>>>>>          return per_cpu(lpi_redist, cpu).redist_id << 16;
>>>>>  }
>>>>>
>>>>> +static void vgic_vcpu_inject_lpi(struct domain *d, unsigned int virq)
>>>>> +{
>>>>> +    struct pending_irq *p = irq_to_pending(d->vcpu[0], virq);
>>>>> +    struct vcpu *v = NULL;
>>>>> +
>>>>> +    if ( !p )
>>>>> +        return;
>>>>> +
>>>>> +    if ( p->lpi_vcpu_id < d->max_vcpus )
>>>>> +        v = d->vcpu[read_atomic(&p->lpi_vcpu_id)];
>>>>
>>>> Hmmm, what does prevent lpi_vcpu_id to change between the check and the
>>>> read?
>>>
>>> Supposedly we are going to set lpi_vcpu_id only to good values? Meaning
>>> that we are going to do the lpi_vcpu_id checks at the time of setting
>>> lpi_vcpu_id. Thus, even if lpi_vcpu_id changes, it is not a problem. In
>>> fact, if that is true, can we even drop the if ( p->lpi_vcpu_id <
>>> d->max_vcpus ) test here?
>>
>> I am not too confident to say lpi_vcpu_id will always be valid with the
>> current locking in the vGIC.
>
> Fair enough, but I wouldn't solve a bug with unnecessary code soon to be
> removed. The problem lies elsewhere and should be fixed elsewhere. We
> could even add an ASSERT(p->lpi_vcpu_id < d->max_vcpus) here, would
> that work for you?

The problem lies in this code because we don't have per-IRQ locking. The 
ASSERT is not a solution to make sure a race does not happen (it could 
easily happen if the LPI is pending whilst the guest is discarding it).

If you add an ASSERT you will potentially get your platform crashing 
time to time on discard. So I don't think the ASSERT is acceptable here.

>
>
>> There is a potential race between its_discard_event and this function. The
>> former may reset pending_irq whilst reading lpi_vcpu_id as we cannot take the
>> vCPU lock yet.
>>
>> But all of this is racy anyway because of the locking. This will get solved by
>> the vGIC rework after the merge.
>>
>> So For the time being I would keep the check. We can revisit it later if
>> necessary.
>
> This is one of those things that are unimportant because they work
> either way.

I am sorry, but it matters when you can easily prevent crash and limit 
the racy condition.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 26/32] ARM: vITS: handle MOVI command

[Julien Grall]

Hi Stefano,

On 31/05/2017 18:53, Stefano Stabellini wrote:
> On Wed, 31 May 2017, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 30/05/17 23:35, Stefano Stabellini wrote:
>>>> +    /*
>>>> +     * TODO: lookup currently-in-guest virtual IRQs and migrate them,
>>>> +     * as the locking may be fragile otherwise.
>>>> +     * This is not easy to do at the moment, but should become easier
>>>> +     * with the introduction of a per-IRQ lock.
>>>> +     */
>>>
>>> Sure but at least we can handle the inflight, but not in guest, case. It
>>> is just a matter of adding (withing the arch.vgic.lock locked region):
>>>
>>>     if ( !list_empty(&p->lr_queue) )
>>>     {
>>>         gic_remove_irq(old, p);
>>>         clear_bit(GIC_IRQ_GUEST_QUEUED, &p->status);
>>>         list_del_init(&p->lr_queue);
>>>         list_del_init(&p->inflight);
>>>
>>>         spin_unlock_irqrestore(&old->arch.vgic.lock, flags);
>>>         vgic_vcpu_inject_irq(new, irq);
>>>     }
>>
>> Please no more hardcoding of migration code. If we are going to support
>> migration we should rework the current function vgic_migrate_irq to support
>> LPIs.
>
> I agree, it is true, in fact that is what I actually suggested last
> time. My preference would be to just call vgic_migrate_irq, providing an
> empty implementation of irq_set_affinity for LPIs.
>
>
>> But ... I don't see any drawback to not support this today. Per the
>> specification, when you migrate an interrupt the only things you have to
>> ensure if the pending interrupt only fire once either on the old or new vCPU.
>>
>> IHMO, if the interrupt has already been queued then it is too late. We should
>> aim at simplifying the code if there are no drawback to do it. In this case,
>> what would be the drawback to leave pending on the old vCPU?
>
> It is inconsistent with what we do elsewhere (vgic_migrate_irq).

So? It is not because the current code does something that we should 
keep the same behavior here which BTW cannot be noticed by a guest.

> It is
> also inconsistent with the TODO comment (!list_empty(&p->lr_queue)
> interrupts are not yet currently-in-guest).

A TODO can easily be updated.

>
> I don't want to introduce any more hardcoding, I just would like the
> existing vgic_migrate_irq to be called.

It is going to need a bit of rework to get it working with LPI as the 
code is currently gated with (p->desc). For what benefits?

Not much as the current code is already working well on migration...

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 17/32] ARM: vITS: add command handling stub and MMIO emulation

[Julien Grall]

Hi Andre,

On 26/05/17 18:35, Andre Przywara wrote:
> 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).
> This fixes a misnomer in our virtual ITS structure, where the spec is
> confusingly using ID_bits in GITS_TYPER to denote the number of event IDs
> (in contrast to GICD_TYPER, where it means number of LPIs).
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Acked-by: Julien Grall <julien.grall@arm.com>

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 18/32] ARM: vITS: introduce translation table walks

[Julien Grall]

Hi Andre,

On 05/26/2017 06:35 PM, Andre Przywara wrote:
> 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 them, to avoid the guest tampering with
> them meanwhile.
> 
> To allow compiling without warnings, we declare two functions as
> non-static for the moment, which two later patches will fix.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>   xen/arch/arm/vgic-v3-its.c | 167 +++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 167 insertions(+)
> 
> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
> index 2c7f22f..8f4a9e1 100644
> --- a/xen/arch/arm/vgic-v3-its.c
> +++ b/xen/arch/arm/vgic-v3-its.c
> @@ -96,9 +96,176 @@ typedef uint64_t dev_table_entry_t;
>   #define DEV_TABLE_ENTRY(addr, bits)                     \
>           (((addr) & GENMASK(51, 8)) | (((bits) - 1) & GENMASK(4, 0)))
>   
> +#define UNMAPPED_COLLECTION      ((coll_table_entry_t)~0)

Again, this should be defined just after/before the typedef 
coll_table_entry_t.

With that fixed:

Acked-by: Julien Grall <julien.grall@arm.com>

Cheers,


>   #define GITS_BASER_RO_MASK       (GITS_BASER_TYPE_MASK | \
>                                     (0x1fL << GITS_BASER_ENTRY_SIZE_SHIFT))
>   
> +/*
> + * The physical address is encoded slightly differently depending on
> + * the used page size: the highest four bits are stored in the lowest
> + * four bits of the field for 64K pages.
> + */
> +static paddr_t get_baser_phys_addr(uint64_t reg)
> +{
> +    if ( reg & BIT(9) )
> +        return (reg & GENMASK(47, 16)) |
> +                ((reg & GENMASK(15, 12)) << 36);
> +    else
> +        return reg & GENMASK(47, 12);
> +}
> +
> +/* Must be called with the ITS lock held. */
> +static struct vcpu *get_vcpu_from_collection(struct virt_its *its,
> +                                             uint16_t collid)
> +{
> +    paddr_t addr = get_baser_phys_addr(its->baser_coll);
> +    coll_table_entry_t vcpu_id;
> +    int ret;
> +
> +    ASSERT(spin_is_locked(&its->its_lock));
> +
> +    if ( collid >= its->max_collections )
> +        return NULL;
> +
> +    ret = vgic_access_guest_memory(its->d,
> +                                   addr + collid * sizeof(coll_table_entry_t),
> +                                   &vcpu_id, sizeof(coll_table_entry_t), false);
> +    if ( ret )
> +        return NULL;
> +
> +    if ( vcpu_id == UNMAPPED_COLLECTION || vcpu_id >= its->d->max_vcpus )
> +        return NULL;
> +
> +    return its->d->vcpu[vcpu_id];
> +}
> +
> +/*
> + * Lookup the address of the Interrupt Translation Table associated with
> + * that device ID.
> + * TODO: add support for walking indirect tables.
> + */
> +static int its_get_itt(struct virt_its *its, uint32_t devid,
> +                       dev_table_entry_t *itt)
> +{
> +    paddr_t addr = get_baser_phys_addr(its->baser_dev);
> +
> +    if ( devid >= its->max_devices )
> +        return -EINVAL;
> +
> +    return vgic_access_guest_memory(its->d,
> +                                    addr + devid * sizeof(dev_table_entry_t),
> +                                    itt, sizeof(*itt), false);
> +}
> +
> +/*
> + * Lookup the address of the Interrupt Translation Table associated with
> + * a device ID and return the address of the ITTE belonging to the event ID
> + * (which is an index into that table).
> + */
> +static paddr_t its_get_itte_address(struct virt_its *its,
> +                                    uint32_t devid, uint32_t evid)
> +{
> +    dev_table_entry_t itt;
> +    int ret;
> +
> +    ret = its_get_itt(its, devid, &itt);
> +    if ( ret )
> +        return INVALID_PADDR;
> +
> +    if ( evid >= DEV_TABLE_ITT_SIZE(itt) ||
> +         DEV_TABLE_ITT_ADDR(itt) == INVALID_PADDR )
> +        return INVALID_PADDR;
> +
> +    return DEV_TABLE_ITT_ADDR(itt) + evid * sizeof(struct vits_itte);
> +}
> +
> +/*
> + * Queries the collection and device tables to get the vCPU and virtual
> + * LPI number for a given guest event. This first accesses the guest memory
> + * to resolve the address of the ITTE, then reads the ITTE entry at this
> + * address and puts the result in vcpu_ptr and vlpi_ptr.
> + * Must be called with the ITS lock held.
> + */
> +static bool read_itte_locked(struct virt_its *its, uint32_t devid,
> +                             uint32_t evid, struct vcpu **vcpu_ptr,
> +                             uint32_t *vlpi_ptr)
> +{
> +    paddr_t addr;
> +    struct vits_itte itte;
> +    struct vcpu *vcpu;
> +
> +    ASSERT(spin_is_locked(&its->its_lock));
> +
> +    addr = its_get_itte_address(its, devid, evid);
> +    if ( addr == INVALID_PADDR )
> +        return false;
> +
> +    if ( vgic_access_guest_memory(its->d, addr, &itte, sizeof(itte), false) )
> +        return false;
> +
> +    vcpu = get_vcpu_from_collection(its, itte.collection);
> +    if ( !vcpu )
> +        return false;
> +
> +    *vcpu_ptr = vcpu;
> +    *vlpi_ptr = itte.vlpi;
> +    return true;
> +}
> +
> +/*
> + * This function takes care of the locking by taking the its_lock itself, so
> + * a caller shall not hold this. Before returning, the lock is dropped again.
> + */
> +bool read_itte(struct virt_its *its, uint32_t devid, uint32_t evid,
> +               struct vcpu **vcpu_ptr, uint32_t *vlpi_ptr)
> +{
> +    bool ret;
> +
> +    spin_lock(&its->its_lock);
> +    ret = read_itte_locked(its, devid, evid, vcpu_ptr, vlpi_ptr);
> +    spin_unlock(&its->its_lock);
> +
> +    return ret;
> +}
> +
> +/*
> + * Queries the collection and device tables to translate the device ID and
> + * event ID and find the appropriate ITTE. The given collection ID and the
> + * virtual LPI number are then stored into that entry.
> + * If vcpu_ptr is provided, returns the VCPU belonging to that collection.
> + * Must be called with the ITS lock held.
> + */
> +bool write_itte_locked(struct virt_its *its, uint32_t devid,
> +                       uint32_t evid, uint32_t collid, uint32_t vlpi,
> +                       struct vcpu **vcpu_ptr)
> +{
> +    paddr_t addr;
> +    struct vits_itte itte;
> +
> +    ASSERT(spin_is_locked(&its->its_lock));
> +
> +    if ( collid >= its->max_collections )
> +        return false;
> +
> +    if ( vlpi >= its->d->arch.vgic.nr_lpis )
> +        return false;
> +
> +    addr = its_get_itte_address(its, devid, evid);
> +    if ( addr == INVALID_PADDR )
> +        return false;
> +
> +    itte.collection = collid;
> +    itte.vlpi = vlpi;
> +
> +    if ( vgic_access_guest_memory(its->d, addr, &itte, sizeof(itte), true) )
> +        return false;
> +
> +    if ( vcpu_ptr )
> +        *vcpu_ptr = get_vcpu_from_collection(its, collid);
> +
> +    return true;
> +}
> +
>   /**************************************
>    * Functions that handle ITS commands *
>    **************************************/
> 

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 19/32] ARM: vITS: provide access to struct pending_irq

[Julien Grall]

Hi Andre,

On 05/26/2017 06:35 PM, Andre Przywara wrote:
> For each device we allocate one struct pending_irq for each virtual
> event (MSI).
> Provide a helper function which returns the pointer to the appropriate
> struct, to be able to find the right struct when given a virtual
> deviceID/eventID pair.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>   xen/arch/arm/gic-v3-its.c        | 59 ++++++++++++++++++++++++++++++++++++++++
>   xen/include/asm-arm/gic_v3_its.h |  4 +++
>   2 files changed, 63 insertions(+)
> 
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> index aebc257..38f0840 100644
> --- a/xen/arch/arm/gic-v3-its.c
> +++ b/xen/arch/arm/gic-v3-its.c
> @@ -800,6 +800,65 @@ out:
>       return ret;
>   }
>   
> +/* Must be called with the its_device_lock held. */
> +static struct its_device *get_its_device(struct domain *d, paddr_t vdoorbell,
> +                                         uint32_t vdevid)
> +{
> +    struct rb_node *node = d->arch.vgic.its_devices.rb_node;
> +    struct its_device *dev;
> +
> +    ASSERT(spin_is_locked(&d->arch.vgic.its_devices_lock));
> +
> +    while (node)
> +    {
> +        int cmp;
> +
> +        dev = rb_entry(node, struct its_device, rbnode);
> +        cmp = compare_its_guest_devices(dev, vdoorbell, vdevid);
> +
> +        if ( !cmp )
> +            return dev;
> +
> +        if ( cmp > 0 )
> +            node = node->rb_left;
> +        else
> +            node = node->rb_right;
> +    }
> +
> +    return NULL;
> +}
> +
> +static struct pending_irq *get_event_pending_irq(struct domain *d,
> +                                                 paddr_t vdoorbell_address,
> +                                                 uint32_t vdevid,
> +                                                 uint32_t eventid,
> +                                                 uint32_t *host_lpi)
> +{
> +    struct its_device *dev;
> +    struct pending_irq *pirq = NULL;
> +
> +    spin_lock(&d->arch.vgic.its_devices_lock);
> +    dev = get_its_device(d, vdoorbell_address, vdevid);
> +    if ( dev && eventid < dev->eventids )
> +    {
> +        pirq = &dev->pend_irqs[eventid];
> +        if ( host_lpi )
> +            *host_lpi = dev->host_lpi_blocks[eventid / LPI_BLOCK] +
> +                        (eventid % LPI_BLOCK);
> +    }
> +    spin_unlock(&d->arch.vgic.its_devices_lock);
> +
> +    return pirq;
> +}
> +
> +struct pending_irq *gicv3_its_get_event_pending_irq(struct domain *d,
> +                                                    paddr_t vdoorbell_address,
> +                                                    uint32_t vdevid,
> +                                                    uint32_t eventid)
> +{

It is quite rude to ignore my question:

"So you never envision someone requiring the host LPI even for debug 
purpose?

AFAICT, there are no other way to get the host LPI if necessary. It 
really does not hurt to expose it and provide a wrapper.

As you may know I am all in favor of more helpers over the cost of one 
unconditional branch (see the callback example) when it results to a 
better code design.

But here it is not about code design, it is more about what kind of 
information would you need outside (see above)."


> +    return get_event_pending_irq(d, vdoorbell_address, vdevid, eventid, NULL);
> +}
> +
>   /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
>   void gicv3_its_dt_init(const struct dt_device_node *node)
>   {
> diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
> index 40f4ef5..d162e89 100644
> --- a/xen/include/asm-arm/gic_v3_its.h
> +++ b/xen/include/asm-arm/gic_v3_its.h
> @@ -169,6 +169,10 @@ int gicv3_its_map_guest_device(struct domain *d,
>   int gicv3_allocate_host_lpi_block(struct domain *d, uint32_t *first_lpi);
>   void gicv3_free_host_lpi_block(uint32_t first_lpi);
>   
> +struct pending_irq *gicv3_its_get_event_pending_irq(struct domain *d,
> +                                                    paddr_t vdoorbell_address,
> +                                                    uint32_t vdevid,
> +                                                    uint32_t veventid);
>   #else
>   
>   static inline void gicv3_its_dt_init(const struct dt_device_node *node)
> 

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 20/32] ARM: vITS: handle INT command

[Julien Grall]

Hi Andre,

On 05/26/2017 06:35 PM, Andre Przywara wrote:
> 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 <andre.przywara@arm.com > ---
>   xen/arch/arm/vgic-v3-its.c | 21 +++++++++++++++++++++
>   1 file changed, 21 insertions(+)
> 
> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
> index 8f4a9e1..80a4625 100644
> --- a/xen/arch/arm/vgic-v3-its.c
> +++ b/xen/arch/arm/vgic-v3-its.c
> @@ -286,6 +286,24 @@ static uint64_t its_cmd_mask_field(uint64_t *its_cmd, unsigned int word,
>   #define its_cmd_get_validbit(cmd)       its_cmd_mask_field(cmd, 2, 63,  1)
>   #define its_cmd_get_ittaddr(cmd)        (its_cmd_mask_field(cmd, 2, 8, 44) << 8)
>   
> +static int its_handle_int(struct virt_its *its, uint64_t *cmdptr)
> +{
> +    uint32_t devid = its_cmd_get_deviceid(cmdptr);
> +    uint32_t eventid = its_cmd_get_id(cmdptr);
> +    struct vcpu *vcpu;
> +    uint32_t vlpi;
> +
> +    if ( !read_itte(its, devid, eventid, &vcpu, &vlpi) )
> +        return -1;
> +
> +    if ( vlpi == INVALID_LPI )
> +        return -1;
> +
> +    vgic_vcpu_inject_irq(vcpu, vlpi);

Should no you call the newly introduced vgic_vcpu_inject_lpi here? This 
would avoid on relying the vcpu in the ITTE.

But I guess this is not strictly important if the table is protected. So:

Reviewed-by: Julien Grall <julien.grall@arm.com>

> +
> +    return 0;
> +}
> +
>   #define ITS_CMD_BUFFER_SIZE(baser)      ((((baser) & 0xff) + 1) << 12)
>   #define ITS_CMD_OFFSET(reg)             ((reg) & GENMASK(19, 5))
>   
> @@ -315,6 +333,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its)
>   
>           switch ( its_cmd_get_command(command) )
>           {
> +        case GITS_CMD_INT:
> +            ret = its_handle_int(its, command);
> +            break;
>           case GITS_CMD_SYNC:
>               /* We handle ITS commands synchronously, so we ignore SYNC. */
>               break;
> 

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 22/32] ARM: vITS: handle CLEAR command

[Julien Grall]

Hi Andre,

On 05/26/2017 06:35 PM, Andre Przywara wrote:
> 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 <andre.przywara@arm.com>

Acked-by: Julien Grall <julien.grall@arm.com>

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 19/32] ARM: vITS: provide access to struct pending_irq

[Julien Grall]

On 06/02/2017 05:32 PM, Julien Grall wrote:
>>   /* Scan the DT for any ITS nodes and create a list of host ITSes out 
>> of it. */
>>   void gicv3_its_dt_init(const struct dt_device_node *node)
>>   {
>> diff --git a/xen/include/asm-arm/gic_v3_its.h 
>> b/xen/include/asm-arm/gic_v3_its.h
>> index 40f4ef5..d162e89 100644
>> --- a/xen/include/asm-arm/gic_v3_its.h
>> +++ b/xen/include/asm-arm/gic_v3_its.h
>> @@ -169,6 +169,10 @@ int gicv3_its_map_guest_device(struct domain *d,
>>   int gicv3_allocate_host_lpi_block(struct domain *d, uint32_t 
>> *first_lpi);
>>   void gicv3_free_host_lpi_block(uint32_t first_lpi);
>> +struct pending_irq *gicv3_its_get_event_pending_irq(struct domain *d,
>> +                                                    paddr_t 
>> vdoorbell_address,
>> +                                                    uint32_t vdevid,
>> +                                                    uint32_t veventid);

NIT: Also, you fixed the declaration but not for the prototype:

s/veventid/eventid/

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 23/32] ARM: vITS: handle MAPD command

[Julien Grall]

Hi Andre,

On 05/26/2017 06:35 PM, Andre Przywara wrote:
> diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
> index d162e89..e78dadf 100644
> --- a/xen/include/asm-arm/gic_v3_its.h
> +++ b/xen/include/asm-arm/gic_v3_its.h
> @@ -173,6 +173,11 @@ struct pending_irq *gicv3_its_get_event_pending_irq(struct domain *d,
>                                                       paddr_t vdoorbell_address,
>                                                       uint32_t vdevid,
>                                                       uint32_t veventid);
> +int gicv3_remove_guest_event(struct domain *d, paddr_t vdoorbell_address,
> +                                     uint32_t vdevid, uint32_t veventid);

NIT: s/veventid/eventid/ as you did for the declaration.

With that fixed:

Acked-by: Julien Grall <julien.grall@arm.com>

> +void gicv3_lpi_update_host_entry(uint32_t host_lpi, int domain_id,
> +                                 uint32_t virt_lpi);
> +
>   #else
>   
>   static inline void gicv3_its_dt_init(const struct dt_device_node *node)
> 

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 24/32] ARM: GICv3: handle unmapped LPIs

[Julien Grall]

Hi Andre,

On 05/26/2017 06:35 PM, Andre Przywara wrote:
> @@ -441,6 +443,40 @@ void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq)
>   #endif
>   }
>   
> +/*
> + * Find an unused LR to insert an IRQ into, starting with the LR given
> + * by @lr. If this new interrupt is a PRISTINE LPI, scan the other LRs to
> + * avoid inserting the same IRQ twice. This situation can occur when an
> + * event gets discarded while the LPI is in an LR, and a new LPI with the
> + * same number gets mapped quickly afterwards.
> + */
> +static unsigned int gic_find_unused_lr(struct vcpu *v,
> +                                       struct pending_irq *p,
> +                                       unsigned int lr)
> +{
> +    unsigned int nr_lrs = gic_hw_ops->info->nr_lrs;
> +    unsigned long *lr_mask = (unsigned long *) &this_cpu(lr_mask);
> +    struct gic_lr lr_val;
> +
> +    ASSERT(spin_is_locked(&v->arch.vgic.lock));
> +
> +    if ( test_bit(GIC_IRQ_GUEST_PRISTINE_LPI, &p->status) )

Stefano suggested to put an unlikely and ...

> @@ -479,8 +516,14 @@ static void gic_update_one_lr(struct vcpu *v, int i)
>       gic_hw_ops->read_lr(i, &lr_val);
>       irq = lr_val.virq;
>       p = irq_to_pending(v, irq);
> -    /* An LPI might have been unmapped, in which case we just clean up here. */
> -    if ( unlikely(!p) )
> +    /*
> +     * An LPI might have been unmapped, in which case we just clean up here.
> +     * If that LPI is marked as PRISTINE, the information in the LR is bogus,
> +     * as it belongs to a previous, already unmapped LPI. So we discard it
> +     * here as well.
> +     */
> +    if ( unlikely(!p) ||
> +         test_and_clear_bit(GIC_IRQ_GUEST_PRISTINE_LPI, &p->status) )

... I think we should put one here too.

With that, I think the patch looks good. I will let Stefano confirm he 
is happy with that too.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 25/32] ARM: vITS: handle MAPTI/MAPI command

[Julien Grall]

Hi Andre,

On 05/26/2017 06:35 PM, Andre Przywara wrote:
> The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
> pair and actually instantiates LPI interrupts. MAPI is just a variant
> of this comment, where the LPI ID is the same as the event ID.
> 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 domain and the virtual LPI number in the respective
> host LPI entry, we also initialize and add the already allocated
> struct pending_irq to our radix tree, so that we can now easily find it
> by its virtual LPI number.
> We also read the property table to update the enabled bit and the
> priority for our new LPI, as we might have missed this during an earlier
> INVALL call (which only checks mapped LPIs). But we make sure that the
> property table is actually valid, as all redistributors might still
> be disabled at this point.
> Since write_itte_locked() now sees its first usage, we change the
> declaration to static.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>   xen/arch/arm/gic-v3-its.c        |  27 ++++++++
>   xen/arch/arm/vgic-v3-its.c       | 138 ++++++++++++++++++++++++++++++++++++++-
>   xen/include/asm-arm/gic_v3_its.h |   3 +
>   3 files changed, 165 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> index 8864e0b..41fff64 100644
> --- a/xen/arch/arm/gic-v3-its.c
> +++ b/xen/arch/arm/gic-v3-its.c
> @@ -876,6 +876,33 @@ int gicv3_remove_guest_event(struct domain *d, paddr_t vdoorbell_address,
>       return 0;
>   }
>   
> +/*
> + * Connects the event ID for an already assigned device to the given VCPU/vLPI
> + * pair. The corresponding physical LPI is already mapped on the host side
> + * (when assigning the physical device to the guest), so we just connect the
> + * target VCPU/vLPI pair to that interrupt to inject it properly if it fires.
> + * Returns a pointer to the already allocated struct pending_irq that is
> + * meant to be used by that event.
> + */
> +struct pending_irq *gicv3_assign_guest_event(struct domain *d,
> +                                             paddr_t vdoorbell_address,
> +                                             uint32_t vdevid, uint32_t eventid,
> +                                             uint32_t virt_lpi)
> +{
> +    struct pending_irq *pirq;
> +    uint32_t host_lpi = 0;
This should be INVALID_LPI and not 0.

[...]

> +/*
> + * For a given virtual LPI read the enabled bit and priority from the virtual
> + * property table and update the virtual IRQ's state in the given pending_irq.
> + * Must be called with the respective VGIC VCPU lock held.
> + */
> +static int update_lpi_property(struct domain *d, struct pending_irq *p)
> +{
> +    paddr_t addr;
> +    uint8_t property;
> +    int ret;
> +
> +    /*
> +     * If no redistributor has its LPIs enabled yet, we can't access the
> +     * property table. In this case we just can't update the properties,
> +     * but this should not be an error from an ITS point of view.
> +     */
> +    if ( !read_atomic(&d->arch.vgic.rdists_enabled) )
> +        return 0;

AFAICT, there are no other place where the property would be updated. 
Should we put a warning to let the user know that property will not be 
updated? More that you don't return an error so no easy way to know 
what's going on.

> +
> +    addr = d->arch.vgic.rdist_propbase & GENMASK(51, 12);
> +
> +    ret = vgic_access_guest_memory(d, addr + p->irq - LPI_OFFSET,
> +                                   &property, sizeof(property), false);
> +    if ( ret )
> +        return ret;
> +
> +    write_atomic(&p->lpi_priority, property & LPI_PROP_PRIO_MASK);
> +
> +    if ( property & LPI_PROP_ENABLED )
> +        set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
> +    else
> +        clear_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
> +
> +    return 0;
> +}
> +
>   /* Must be called with the ITS lock held. */
>   static int its_discard_event(struct virt_its *its,
>                                uint32_t vdevid, uint32_t vevid)
> @@ -538,6 +574,98 @@ static int its_handle_mapd(struct virt_its *its, uint64_t *cmdptr)
>       return ret;
>   }
>   
> +static int its_handle_mapti(struct virt_its *its, uint64_t *cmdptr)
> +{

[...]

> +    /*
> +     * radix_tree_insert() returns an error either due to an internal
> +     * condition (like memory allocation failure) or because the LPI already
> +     * existed in the tree. We don't support the latter case, so we always
> +     * cleanup and return an error here in any case.
> +     */
> +out_remove_host_entry:
> +    gicv3_remove_guest_event(its->d, its->doorbell_address, devid, eventid);

Can gicv3_remove_guest_event fail? If yes, should we check the 
return/add comment? If not, then we should have an ASSERT(....).

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 26/32] ARM: vITS: handle MOVI command

[Julien Grall]

Hi,

On 05/31/2017 07:49 PM, Julien Grall wrote:
>> I don't want to introduce any more hardcoding, I just would like the
>> existing vgic_migrate_irq to be called.
> 
> It is going to need a bit of rework to get it working with LPI as the 
> code is currently gated with (p->desc). For what benefits?
> 
> Not much as the current code is already working well on migration...

So I had a chat with Stefano about that. The consensus is , correct me 
if I misunderstood, either fully implement the migration using 
vgic_irq_migrate or not doing it.

AFAICT, the current approach is not implementing the migration but the 
comment is quite confusing. So if we don't implement it, the comment 
needs to be updated.

Cheers.

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 27/32] ARM: vITS: handle DISCARD command

[Julien Grall]

Hi Andre,

On 05/26/2017 06:35 PM, Andre Przywara wrote:
> 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 <andre.przywara@arm.com>

Acked-by: Julien Grall <julien.grall@arm.com>

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 29/32] ARM: vITS: handle INVALL command

[Julien Grall]

Hi Andre,

On 05/26/2017 06:35 PM, Andre Przywara wrote:
> +    do
> +    {
> +        nr_lpis = radix_tree_gang_lookup(&its->d->arch.vgic.pend_lpi_tree,
> +                                         (void **)pirqs, vlpi,
> +                                         ARRAY_SIZE(pirqs));
> +
> +        for ( i = 0; i < nr_lpis; i++ )
> +        {
> +            /* We only care about LPIs on our VCPU. */
> +            if ( pirqs[i]->lpi_vcpu_id != vcpu->vcpu_id )
> +                continue;
> +
> +            vlpi = pirqs[i]->irq;
> +            /* If that fails for a single LPI, carry on to handle the rest. */
> +            ret = update_lpi_property(its->d, pirqs[i]);
> +            if ( !ret )
> +                update_lpi_vgic_status(vcpu, pirqs[i]);
> +        }
> +    /*
> +     * Loop over the next gang of pending_irqs until we reached the end of
> +     * a (fully populated) tree or the lookup function returns less LPIs than
> +     * it has been asked for.
> +     */
> +    } while ( (++vlpi < its->d->arch.vgic.nr_lpis) &&
> +              (nr_lpis == ARRAY_SIZE(pirqs)) );
> +
> +    read_unlock(&its->d->arch.vgic.pend_lpi_tree_lock);
> +    spin_unlock_irqrestore(&vcpu->arch.vgic.lock, flags);
> +
> +    return ret;

The implementation looks good. However, one question. ret would be equal 
to the latest LPI updated. So even if all LPIs have failed but the 
latest, you will still return 0. Is it what you want?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 31/32] ARM: vITS: create and initialize virtual ITSes for Dom0

[Julien Grall]

Hi Andre,

On 05/26/2017 06:35 PM, Andre Przywara wrote:
> 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 again.
> We configure the virtual ITSes to match the hardware ones, that is we
> keep the number of device ID bits and event ID bits the same as the host
> ITS.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Acked-by: Julien Grall <julien.grall@arm.com>

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 32/32] ARM: vITS: create ITS subnodes for Dom0 DT

[Julien Grall]

Hi Andre,

On 05/26/2017 06:35 PM, Andre Przywara wrote:
> 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 <andre.przywara@arm.com>

Acked-by: Julien Grall <julien.grall@arm.com>

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 01/32] ARM: vGIC: avoid rank lock when reading priority

[Julien Grall]

On 05/31/2017 11:42 AM, Julien Grall wrote:
> Hi Stefano,
> 
> On 30/05/17 22:39, Stefano Stabellini wrote:
>> On Tue, 30 May 2017, Julien Grall wrote:
>>> Hi Andre,
>>>
>>> On 26/05/17 18:35, Andre Przywara wrote:
>>>> When reading the priority value of a virtual interrupt, we were taking
>>>> the respective rank lock so far.
>>>> However for forwarded interrupts (Dom0 only so far) this may lead to a
>>>> deadlock with the following call chain:
>>>> - MMIO access to change the IRQ affinity, calling the ITARGETSR handler
>>>> - this handler takes the appropriate rank lock and calls
>>>> vgic_store_itargetsr()
>>>> - vgic_store_itargetsr() will eventually call vgic_migrate_irq()
>>>> - if this IRQ is already in-flight, it will remove it from the old
>>>>   VCPU and inject it into the new one, by calling 
>>>> vgic_vcpu_inject_irq()
>>>> - vgic_vcpu_inject_irq will call vgic_get_virq_priority()
>>>> - vgic_get_virq_priority() tries to take the rank lock - again!
>>>> It seems like this code path has never been exercised before.
>>>>
>>>> Fix this by avoiding taking the lock in vgic_get_virq_priority() 
>>>> (like we
>>>> do in vgic_get_target_vcpu()).
>>>> Actually we are just reading one byte, and priority changes while
>>>> interrupts are handled are a benign race that can happen on real 
>>>> hardware
>>>> too. So it looks safe to just use read_atomic() instead.
>>>>
>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>>> ---
>>>>  xen/arch/arm/vgic.c | 8 +-------
>>>>  1 file changed, 1 insertion(+), 7 deletions(-)
>>>>
>>>> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
>>>> index 83569b0..54b2aad 100644
>>>> --- a/xen/arch/arm/vgic.c
>>>> +++ b/xen/arch/arm/vgic.c
>>>> @@ -227,14 +227,8 @@ struct vcpu *vgic_get_target_vcpu(struct vcpu *v,
>>>> unsigned int virq)
>>>>  static int vgic_get_virq_priority(struct vcpu *v, unsigned int virq)
>>>>  {
>>>>      struct vgic_irq_rank *rank = vgic_rank_irq(v, virq);
>>>> -    unsigned long flags;
>>>> -    int priority;
>>>> -
>>>> -    vgic_lock_rank(v, rank, flags);
>>>> -    priority = rank->priority[virq & INTERRUPT_RANK_MASK];
>>>> -    vgic_unlock_rank(v, rank, flags);
>>>>
>>>> -    return priority;
>>>> +    return read_atomic(&rank->priority[virq & INTERRUPT_RANK_MASK]);
>>>
>>> The write in rank->priority will not be atomic (see vgic_reg_update
>>> implementation): the register is first masked, the the priority set.
>>>
>>> So you may end up to read 0 (which is the higher priority) by mistake.
>>>
>>> We should probably think to make vgic_reg_* helper atomic.
>>
>> Right! That's why I wrote
>> alpine.DEB.2.10.1705231135130.18759@sstabellini-ThinkPad-X260
> 
> It was not obvious from this e-mail why you wanted this. It looked more 
> a request for improvement rather than a potential bug. Hence my 
> suggestion to delay it.

FIY, I wrote down a couple of patch to make vgic_reg* atomic. It is not 
too invasive and would solve write atomically in the register. However, 
it will not prevent two write racing together. So the lock would still 
be need in some places.

I am still doing some testing. I will send a version hopefully Monday.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 26/32] ARM: vITS: handle MOVI command

[Stefano Stabellini]

On Fri, 2 Jun 2017, Julien Grall wrote:
> Hi,
> 
> On 05/31/2017 07:49 PM, Julien Grall wrote:
> > > I don't want to introduce any more hardcoding, I just would like the
> > > existing vgic_migrate_irq to be called.
> > 
> > It is going to need a bit of rework to get it working with LPI as the code
> > is currently gated with (p->desc). For what benefits?
> > 
> > Not much as the current code is already working well on migration...
> 
> So I had a chat with Stefano about that. The consensus is , correct me if I
> misunderstood, either fully implement the migration using vgic_irq_migrate or
> not doing it.
> 
> AFAICT, the current approach is not implementing the migration but the comment
> is quite confusing. So if we don't implement it, the comment needs to be
> updated.

Yes

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 24/32] ARM: GICv3: handle unmapped LPIs

[Stefano Stabellini]

On Fri, 2 Jun 2017, Julien Grall wrote:
> Hi Andre,
> 
> On 05/26/2017 06:35 PM, Andre Przywara wrote:
> > @@ -441,6 +443,40 @@ void gic_raise_inflight_irq(struct vcpu *v, unsigned
> > int virtual_irq)
> >   #endif
> >   }
> >   +/*
> > + * Find an unused LR to insert an IRQ into, starting with the LR given
> > + * by @lr. If this new interrupt is a PRISTINE LPI, scan the other LRs to
> > + * avoid inserting the same IRQ twice. This situation can occur when an
> > + * event gets discarded while the LPI is in an LR, and a new LPI with the
> > + * same number gets mapped quickly afterwards.
> > + */
> > +static unsigned int gic_find_unused_lr(struct vcpu *v,
> > +                                       struct pending_irq *p,
> > +                                       unsigned int lr)
> > +{
> > +    unsigned int nr_lrs = gic_hw_ops->info->nr_lrs;
> > +    unsigned long *lr_mask = (unsigned long *) &this_cpu(lr_mask);
> > +    struct gic_lr lr_val;
> > +
> > +    ASSERT(spin_is_locked(&v->arch.vgic.lock));
> > +
> > +    if ( test_bit(GIC_IRQ_GUEST_PRISTINE_LPI, &p->status) )
> 
> Stefano suggested to put an unlikely and ...
> 
> > @@ -479,8 +516,14 @@ static void gic_update_one_lr(struct vcpu *v, int i)
> >       gic_hw_ops->read_lr(i, &lr_val);
> >       irq = lr_val.virq;
> >       p = irq_to_pending(v, irq);
> > -    /* An LPI might have been unmapped, in which case we just clean up
> > here. */
> > -    if ( unlikely(!p) )
> > +    /*
> > +     * An LPI might have been unmapped, in which case we just clean up
> > here.
> > +     * If that LPI is marked as PRISTINE, the information in the LR is
> > bogus,
> > +     * as it belongs to a previous, already unmapped LPI. So we discard it
> > +     * here as well.
> > +     */
> > +    if ( unlikely(!p) ||
> > +         test_and_clear_bit(GIC_IRQ_GUEST_PRISTINE_LPI, &p->status) )
> 
> ... I think we should put one here too.
> 
> With that, I think the patch looks good. I will let Stefano confirm he is
> happy with that too.

Yes, I think it is OK

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 02/32] ARM: GICv3: setup number of LPI bits for a GICv3 guest

[Andre Przywara]

Hi,

On 30/05/17 11:54, Julien Grall wrote:
> Hi Andre,
> 
> On 26/05/17 18:35, Andre Przywara wrote:
>> The host supports a certain number of LPI identifiers, as stored in
>> the GICD_TYPER register.
>> Store this number from the hardware register in vgic_v3_hw to allow
>> injecting the very same number into a guest (Dom0).
>> DomUs get the legacy number of 10 bits here, since for now it only sees
>> SPIs, so it does not need more. This should be revisited once we get
>> proper DomU ITS support.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>>  xen/arch/arm/gic-v3.c        |  6 +++++-
>>  xen/arch/arm/vgic-v3.c       | 10 +++++++++-
>>  xen/include/asm-arm/domain.h |  1 +
>>  xen/include/asm-arm/vgic.h   |  3 ++-
>>  4 files changed, 17 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>> index a559e5e..29c8964 100644
>> --- a/xen/arch/arm/gic-v3.c
>> +++ b/xen/arch/arm/gic-v3.c
>> @@ -1579,6 +1579,7 @@ static int __init gicv3_init(void)
>>  {
>>      int res, i;
>>      uint32_t reg;
>> +    unsigned int intid_bits;
>>
>>      if ( !cpu_has_gicv3 )
>>      {
>> @@ -1622,8 +1623,11 @@ static int __init gicv3_init(void)
>>                 i, r->base, r->base + r->size);
>>      }
>>
>> +    reg = readl_relaxed(GICD + GICD_TYPER);
>> +    intid_bits = GICD_TYPE_ID_BITS(reg);
>> +
>>      vgic_v3_setup_hw(dbase, gicv3.rdist_count, gicv3.rdist_regions,
>> -                     gicv3.rdist_stride);
>> +                     gicv3.rdist_stride, intid_bits);
>>      gicv3_init_v2();
>>
>>      spin_lock_init(&gicv3.lock);
>> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
>> index d10757a..87f5fb3 100644
>> --- a/xen/arch/arm/vgic-v3.c
>> +++ b/xen/arch/arm/vgic-v3.c
>> @@ -57,18 +57,21 @@ static struct {
>>      unsigned int nr_rdist_regions;
>>      const struct rdist_region *regions;
>>      uint32_t rdist_stride; /* Re-distributor stride */
>> +    unsigned int intid_bits;  /* Number of interrupt ID bits */
>>  } vgic_v3_hw;
>>
>>  void vgic_v3_setup_hw(paddr_t dbase,
>>                        unsigned int nr_rdist_regions,
>>                        const struct rdist_region *regions,
>> -                      uint32_t rdist_stride)
>> +                      uint32_t rdist_stride,
>> +                      unsigned int intid_bits)
>>  {
>>      vgic_v3_hw.enabled = 1;
>>      vgic_v3_hw.dbase = dbase;
>>      vgic_v3_hw.nr_rdist_regions = nr_rdist_regions;
>>      vgic_v3_hw.regions = regions;
>>      vgic_v3_hw.rdist_stride = rdist_stride;
>> +    vgic_v3_hw.intid_bits = intid_bits;
>>  }
>>
>>  static struct vcpu *vgic_v3_irouter_to_vcpu(struct domain *d,
>> uint64_t irouter)
>> @@ -1482,6 +1485,8 @@ static int vgic_v3_domain_init(struct domain *d)
>>
>>              first_cpu += size / d->arch.vgic.rdist_stride;
>>          }
>> +
>> +        d->arch.vgic.intid_bits = vgic_v3_hw.intid_bits;
>>      }
>>      else
>>      {
>> @@ -1497,6 +1502,9 @@ static int vgic_v3_domain_init(struct domain *d)
>>          d->arch.vgic.rdist_regions[0].base = GUEST_GICV3_GICR0_BASE;
>>          d->arch.vgic.rdist_regions[0].size = GUEST_GICV3_GICR0_SIZE;
>>          d->arch.vgic.rdist_regions[0].first_cpu = 0;
>> +
>> +        /* TODO: only SPIs for now, adjust this when guests need LPIs */
>> +        d->arch.vgic.intid_bits = 10;
> 
> What if the guest support no SPIs? Should not you based this number of
> the number of SPIs supported by the guest?

No, I think this is a misconception in the existing code. The number of
ID bits supported is actually related to the stream protocol, something
which we don't model here. It is independent from the number of actually
implemented SPIs, which is held in the lower 5 bits of GICD_TYPER.
See chapter 2.2 "INTIDs" in the GICv3 spec, where it says:
"If LPIs are not supported, the ID space in the Distributor is limited
to 10 bits."

Cheers,
Andre.

> 
>>      }
>>
>>      ret = vgic_v3_its_init_domain(d);
>> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
>> index 6de8082..7c3829d 100644
>> --- a/xen/include/asm-arm/domain.h
>> +++ b/xen/include/asm-arm/domain.h
>> @@ -111,6 +111,7 @@ struct arch_domain
>>          uint32_t rdist_stride;              /* Re-Distributor stride */
>>          struct rb_root its_devices;         /* Devices mapped to an
>> ITS */
>>          spinlock_t its_devices_lock;        /* Protects the
>> its_devices tree */
>> +        unsigned int intid_bits;
>>  #endif
>>      } vgic;
>>
>> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
>> index 544867a..df75064 100644
>> --- a/xen/include/asm-arm/vgic.h
>> +++ b/xen/include/asm-arm/vgic.h
>> @@ -346,7 +346,8 @@ struct rdist_region;
>>  void vgic_v3_setup_hw(paddr_t dbase,
>>                        unsigned int nr_rdist_regions,
>>                        const struct rdist_region *regions,
>> -                      uint32_t rdist_stride);
>> +                      uint32_t rdist_stride,
>> +                      unsigned int intid_bits);
>>  #endif
>>
>>  #endif /* __ASM_ARM_VGIC_H__ */
>>
> 
> Cheers,
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 05/32] ARM: vGIC: introduce gic_remove_irq()

[Andre Przywara]

Hi,

On 30/05/17 12:31, Julien Grall wrote:
> Hi Andre,
> 
> On 26/05/17 18:35, Andre Przywara wrote:
>> To avoid code duplication in a later patch, introduce a generic function
>> to remove a virtual IRQ from the VGIC.
>> Call that function instead of the open-coded version in
>> vgic_migrate_irq().
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>>  xen/arch/arm/gic.c        | 9 +++++++++
>>  xen/arch/arm/vgic.c       | 1 +
>>  xen/include/asm-arm/gic.h | 1 +
>>  3 files changed, 11 insertions(+)
>>
>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> index 9dde146..3a6184a 100644
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -408,6 +408,15 @@ void gic_remove_from_lr_pending(struct vcpu *v,
>> struct pending_irq *p)
>>          list_del_init(&p->lr_queue);
>>  }
>>
>> +void gic_remove_irq(struct vcpu *v, struct pending_irq *p)
> 
> The name is too generic. Remove IRQ from what?
> 
>> +{
>> +    ASSERT(spin_is_locked(&v->arch.vgic.lock));
>> +
>> +    clear_bit(GIC_IRQ_GUEST_QUEUED, &p->status);
>> +    list_del_init(&p->inflight);
>> +    gic_remove_from_lr_pending(v, p);
>> +}
>> +
>>  void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq)
>>  {
>>      struct pending_irq *n = irq_to_pending(v, virtual_irq);
>> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
>> index 3993965..b2acc99 100644
>> --- a/xen/arch/arm/vgic.c
>> +++ b/xen/arch/arm/vgic.c
>> @@ -266,6 +266,7 @@ bool vgic_migrate_irq(struct vcpu *old, struct
>> vcpu *new, unsigned int irq)
>>      /* If the IRQ is still lr_pending, re-inject it to the new vcpu */
>>      if ( !list_empty(&p->lr_queue) )
>>      {
>> +        gic_remove_irq(old, p);
>>          clear_bit(GIC_IRQ_GUEST_QUEUED, &p->status);
>>          list_del_init(&p->lr_queue);
>>          list_del_init(&p->inflight);
> 
> I was expecting those 3 lines to be removed since you now call
> gic_remove_irq.

Argh, of course. I actually fixed this, but somehow it sneaked in again
when I moved this patch around in the series.
Sorry for that.

Cheers,
Andre.

>> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
>> index 3130634..5d5b4cc 100644
>> --- a/xen/include/asm-arm/gic.h
>> +++ b/xen/include/asm-arm/gic.h
>> @@ -244,6 +244,7 @@ extern void gic_raise_guest_irq(struct vcpu *v,
>> unsigned int irq,
>>          unsigned int priority);
>>  extern void gic_raise_inflight_irq(struct vcpu *v, unsigned int
>> virtual_irq);
>>  extern void gic_remove_from_lr_pending(struct vcpu *v, struct
>> pending_irq *p);
>> +extern void gic_remove_irq(struct vcpu *v, struct pending_irq *p);
>>
>>  /* Accept an interrupt from the GIC and dispatch its handler */
>>  extern void gic_interrupt(struct cpu_user_regs *regs, int is_fiq);
>>
> 
> Cheers,
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 06/32] ARM: GIC: Add checks for NULL pointer pending_irq's

[Andre Przywara]

Hi,

On 30/05/17 12:38, Julien Grall wrote:
> Hi Andre,
> 
> On 26/05/17 18:35, Andre Przywara wrote:
>> For LPIs the struct pending_irq's are dynamically allocated and the
>> pointers will be stored in a radix tree. Since an LPI can be "unmapped"
>> at any time, teach the VGIC how to deal with irq_to_pending() returning
>> a NULL pointer.
>> We just do nothing in this case or clean up the LR if the virtual LPI
>> number was still in an LR.
>>
>> Those are all call sites for irq_to_pending(), as per:
>> "git grep irq_to_pending", and their evaluations:
>> (PROTECTED means: added NULL check and bailing out)
>>
>>     xen/arch/arm/gic.c:
>> gic_route_irq_to_guest(): only called for SPIs, added ASSERT()
>> gic_remove_irq_from_guest(): only called for SPIs, added ASSERT()
>> gic_remove_from_queues(): PROTECTED, called within VCPU VGIC lock
> 
> This function has been renamed in patch #4.
> 
>> gic_raise_inflight_irq(): PROTECTED, called under VCPU VGIC lock
>> gic_raise_guest_irq(): PROTECTED, called under VCPU VGIC lock
>> gic_update_one_lr(): PROTECTED, called under VCPU VGIC lock
>>
>>     xen/arch/arm/vgic.c:
>> vgic_migrate_irq(): not called for LPIs (virtual IRQs), added ASSERT()
>> arch_move_irqs(): not iterating over LPIs, added ASSERT()
> 
> I don't see any ASSERT added in arch_move_irqs.

Because this is just checking for not being called with an LPI, it was
introduced in patch 03/32 already. I can adjust the commit message.

Cheers,
Andre.

>> vgic_disable_irqs(): not called for LPIs, added ASSERT()
>> vgic_enable_irqs(): not called for LPIs, added ASSERT()
>> vgic_vcpu_inject_irq(): PROTECTED, moved under VCPU VGIC lock
>>
>>     xen/include/asm-arm/event.h:
>> local_events_need_delivery_nomask(): only called for a PPI, added
>> ASSERT()
>>
>>     xen/include/asm-arm/vgic.h:
>> (prototype)
> 
> Cheers,
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 19/32] ARM: vITS: provide access to struct pending_irq

[Andre Przywara]

Hi,

On 02/06/17 17:32, Julien Grall wrote:
> Hi Andre,
> 
> On 05/26/2017 06:35 PM, Andre Przywara wrote:
>> For each device we allocate one struct pending_irq for each virtual
>> event (MSI).
>> Provide a helper function which returns the pointer to the appropriate
>> struct, to be able to find the right struct when given a virtual
>> deviceID/eventID pair.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>>   xen/arch/arm/gic-v3-its.c        | 59
>> ++++++++++++++++++++++++++++++++++++++++
>>   xen/include/asm-arm/gic_v3_its.h |  4 +++
>>   2 files changed, 63 insertions(+)
>>
>> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
>> index aebc257..38f0840 100644
>> --- a/xen/arch/arm/gic-v3-its.c
>> +++ b/xen/arch/arm/gic-v3-its.c
>> @@ -800,6 +800,65 @@ out:
>>       return ret;
>>   }
>>   +/* Must be called with the its_device_lock held. */
>> +static struct its_device *get_its_device(struct domain *d, paddr_t
>> vdoorbell,
>> +                                         uint32_t vdevid)
>> +{
>> +    struct rb_node *node = d->arch.vgic.its_devices.rb_node;
>> +    struct its_device *dev;
>> +
>> +    ASSERT(spin_is_locked(&d->arch.vgic.its_devices_lock));
>> +
>> +    while (node)
>> +    {
>> +        int cmp;
>> +
>> +        dev = rb_entry(node, struct its_device, rbnode);
>> +        cmp = compare_its_guest_devices(dev, vdoorbell, vdevid);
>> +
>> +        if ( !cmp )
>> +            return dev;
>> +
>> +        if ( cmp > 0 )
>> +            node = node->rb_left;
>> +        else
>> +            node = node->rb_right;
>> +    }
>> +
>> +    return NULL;
>> +}
>> +
>> +static struct pending_irq *get_event_pending_irq(struct domain *d,
>> +                                                 paddr_t
>> vdoorbell_address,
>> +                                                 uint32_t vdevid,
>> +                                                 uint32_t eventid,
>> +                                                 uint32_t *host_lpi)
>> +{
>> +    struct its_device *dev;
>> +    struct pending_irq *pirq = NULL;
>> +
>> +    spin_lock(&d->arch.vgic.its_devices_lock);
>> +    dev = get_its_device(d, vdoorbell_address, vdevid);
>> +    if ( dev && eventid < dev->eventids )
>> +    {
>> +        pirq = &dev->pend_irqs[eventid];
>> +        if ( host_lpi )
>> +            *host_lpi = dev->host_lpi_blocks[eventid / LPI_BLOCK] +
>> +                        (eventid % LPI_BLOCK);
>> +    }
>> +    spin_unlock(&d->arch.vgic.its_devices_lock);
>> +
>> +    return pirq;
>> +}
>> +
>> +struct pending_irq *gicv3_its_get_event_pending_irq(struct domain *d,
>> +                                                    paddr_t
>> vdoorbell_address,
>> +                                                    uint32_t vdevid,
>> +                                                    uint32_t eventid)
>> +{
> 
> It is quite rude to ignore my question:
> 
> "So you never envision someone requiring the host LPI even for debug
> purpose?
> 
> AFAICT, there are no other way to get the host LPI if necessary. It
> really does not hurt to expose it and provide a wrapper.
> 
> As you may know I am all in favor of more helpers over the cost of one
> unconditional branch (see the callback example) when it results to a
> better code design.
> 
> But here it is not about code design, it is more about what kind of
> information would you need outside (see above)."

Sorry, I forgot to send a reply on Friday.

So I am not convinced that a *potential* debug output justifies breaking
the abstraction here. The host LPI is of no concern for the guest side
of the emulation code. If someone is in dire need for this information,
the debug output can easily be inserted into the wrapper function or
this export can be done just for this debugging session.
So I'd rather not do this - as the patch demonstrated ;-)

Cheers,
Andre.

>> +    return get_event_pending_irq(d, vdoorbell_address, vdevid,
>> eventid, NULL);
>> +}
>> +
>>   /* Scan the DT for any ITS nodes and create a list of host ITSes out
>> of it. */
>>   void gicv3_its_dt_init(const struct dt_device_node *node)
>>   {
>> diff --git a/xen/include/asm-arm/gic_v3_its.h
>> b/xen/include/asm-arm/gic_v3_its.h
>> index 40f4ef5..d162e89 100644
>> --- a/xen/include/asm-arm/gic_v3_its.h
>> +++ b/xen/include/asm-arm/gic_v3_its.h
>> @@ -169,6 +169,10 @@ int gicv3_its_map_guest_device(struct domain *d,
>>   int gicv3_allocate_host_lpi_block(struct domain *d, uint32_t
>> *first_lpi);
>>   void gicv3_free_host_lpi_block(uint32_t first_lpi);
>>   +struct pending_irq *gicv3_its_get_event_pending_irq(struct domain *d,
>> +                                                    paddr_t
>> vdoorbell_address,
>> +                                                    uint32_t vdevid,
>> +                                                    uint32_t veventid);
>>   #else
>>     static inline void gicv3_its_dt_init(const struct dt_device_node
>> *node)
>>
> 
> Cheers,
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 19/32] ARM: vITS: provide access to struct pending_irq

[Julien Grall]

Hi Andre,

On 06/06/17 11:19, Andre Przywara wrote:
> Sorry, I forgot to send a reply on Friday.
>
> So I am not convinced that a *potential* debug output justifies breaking
> the abstraction here. The host LPI is of no concern for the guest side
> of the emulation code. If someone is in dire need for this information,
> the debug output can easily be inserted into the wrapper function or
> this export can be done just for this debugging session.
> So I'd rather not do this - as the patch demonstrated ;-)

Fair enough. So:

Acked-by: Julien Grall <julien.grall@arm.com>

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 01/32] ARM: vGIC: avoid rank lock when reading priority

[Andre Przywara]

Hi,

On 30/05/17 11:47, Julien Grall wrote:
> Hi Andre,
> 
> On 26/05/17 18:35, Andre Przywara wrote:
>> When reading the priority value of a virtual interrupt, we were taking
>> the respective rank lock so far.
>> However for forwarded interrupts (Dom0 only so far) this may lead to a
>> deadlock with the following call chain:
>> - MMIO access to change the IRQ affinity, calling the ITARGETSR handler
>> - this handler takes the appropriate rank lock and calls
>> vgic_store_itargetsr()
>> - vgic_store_itargetsr() will eventually call vgic_migrate_irq()
>> - if this IRQ is already in-flight, it will remove it from the old
>>   VCPU and inject it into the new one, by calling vgic_vcpu_inject_irq()
>> - vgic_vcpu_inject_irq will call vgic_get_virq_priority()
>> - vgic_get_virq_priority() tries to take the rank lock - again!
>> It seems like this code path has never been exercised before.
>>
>> Fix this by avoiding taking the lock in vgic_get_virq_priority() (like we
>> do in vgic_get_target_vcpu()).
>> Actually we are just reading one byte, and priority changes while
>> interrupts are handled are a benign race that can happen on real hardware
>> too. So it looks safe to just use read_atomic() instead.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>>  xen/arch/arm/vgic.c | 8 +-------
>>  1 file changed, 1 insertion(+), 7 deletions(-)
>>
>> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
>> index 83569b0..54b2aad 100644
>> --- a/xen/arch/arm/vgic.c
>> +++ b/xen/arch/arm/vgic.c
>> @@ -227,14 +227,8 @@ struct vcpu *vgic_get_target_vcpu(struct vcpu *v,
>> unsigned int virq)
>>  static int vgic_get_virq_priority(struct vcpu *v, unsigned int virq)
>>  {
>>      struct vgic_irq_rank *rank = vgic_rank_irq(v, virq);
>> -    unsigned long flags;
>> -    int priority;
>> -
>> -    vgic_lock_rank(v, rank, flags);
>> -    priority = rank->priority[virq & INTERRUPT_RANK_MASK];
>> -    vgic_unlock_rank(v, rank, flags);
>>
>> -    return priority;
>> +    return read_atomic(&rank->priority[virq & INTERRUPT_RANK_MASK]);
> 
> The write in rank->priority will not be atomic (see vgic_reg_update
> implementation): the register is first masked, the the priority set.
> 
> So you may end up to read 0 (which is the higher priority) by mistake.
> 
> We should probably think to make vgic_reg_* helper atomic.

The patch you sent yesterday may be a bit over the top for this.

What about this one (in xen/arch/arm/vgic-v[23].c):

static int vgic_v2_distr_mmio_write(struct vcpu *v, ...
{
-    uint32_t *ipriorityr;
+    uint32_t *ipriorityr, priority;
....
     vgic_lock_rank(v, rank, flags);
     ipriorityr = &rank->ipriorityr[REG_RANK_INDEX(8,
                                            gicd_reg - GICD_IPRIORITYR,
                                            DABT_WORD)];
-    vgic_reg32_update(ipriorityr, r, info);
+    priority = ACCESS_ONCE(*ipriorityr);
+    vgic_reg32_update(&priority, r, info);
+    ACCESS_ONCE(*ipriorityr) = priority;
     vgic_unlock_rank(v, rank, flags);
....

Concurrent writes are protected by the rank lock, and reads are
guaranteed to be atomic due to ACCESS_ONCE and the architectural
guarantee of an aligned uint32_t access being atomic.
We can't do anything about the benign race when the priority gets
changed while we read it, but the above should make sure that we either
read the old or the new value and nothing in between.
The other read accesses (in vgic_v[23]_distr_mmio_read() and in vgic.c
here in this patch) get protected by an ACCESS_ONCE().

Does that make sense?

Cheers,
Andre.

> 
>>  }
>>
>>  bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned
>> int irq)
>>
> 
> Cheers,
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 01/32] ARM: vGIC: avoid rank lock when reading priority

[Julien Grall]

On 06/06/17 18:06, Andre Przywara wrote:
> On 30/05/17 11:47, Julien Grall wrote:
>> Hi Andre,
>>
>> On 26/05/17 18:35, Andre Przywara wrote:
>>> When reading the priority value of a virtual interrupt, we were taking
>>> the respective rank lock so far.
>>> However for forwarded interrupts (Dom0 only so far) this may lead to a
>>> deadlock with the following call chain:
>>> - MMIO access to change the IRQ affinity, calling the ITARGETSR handler
>>> - this handler takes the appropriate rank lock and calls
>>> vgic_store_itargetsr()
>>> - vgic_store_itargetsr() will eventually call vgic_migrate_irq()
>>> - if this IRQ is already in-flight, it will remove it from the old
>>>   VCPU and inject it into the new one, by calling vgic_vcpu_inject_irq()
>>> - vgic_vcpu_inject_irq will call vgic_get_virq_priority()
>>> - vgic_get_virq_priority() tries to take the rank lock - again!
>>> It seems like this code path has never been exercised before.
>>>
>>> Fix this by avoiding taking the lock in vgic_get_virq_priority() (like we
>>> do in vgic_get_target_vcpu()).
>>> Actually we are just reading one byte, and priority changes while
>>> interrupts are handled are a benign race that can happen on real hardware
>>> too. So it looks safe to just use read_atomic() instead.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>> ---
>>>  xen/arch/arm/vgic.c | 8 +-------
>>>  1 file changed, 1 insertion(+), 7 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
>>> index 83569b0..54b2aad 100644
>>> --- a/xen/arch/arm/vgic.c
>>> +++ b/xen/arch/arm/vgic.c
>>> @@ -227,14 +227,8 @@ struct vcpu *vgic_get_target_vcpu(struct vcpu *v,
>>> unsigned int virq)
>>>  static int vgic_get_virq_priority(struct vcpu *v, unsigned int virq)
>>>  {
>>>      struct vgic_irq_rank *rank = vgic_rank_irq(v, virq);
>>> -    unsigned long flags;
>>> -    int priority;
>>> -
>>> -    vgic_lock_rank(v, rank, flags);
>>> -    priority = rank->priority[virq & INTERRUPT_RANK_MASK];
>>> -    vgic_unlock_rank(v, rank, flags);
>>>
>>> -    return priority;
>>> +    return read_atomic(&rank->priority[virq & INTERRUPT_RANK_MASK]);
>>
>> The write in rank->priority will not be atomic (see vgic_reg_update
>> implementation): the register is first masked, the the priority set.
>>
>> So you may end up to read 0 (which is the higher priority) by mistake.
>>
>> We should probably think to make vgic_reg_* helper atomic.
>
> The patch you sent yesterday may be a bit over the top for this.

Patch which I only sent internally to get feedback. ;)

>
> What about this one (in xen/arch/arm/vgic-v[23].c):
>
> static int vgic_v2_distr_mmio_write(struct vcpu *v, ...
> {
> -    uint32_t *ipriorityr;
> +    uint32_t *ipriorityr, priority;
> ....
>      vgic_lock_rank(v, rank, flags);
>      ipriorityr = &rank->ipriorityr[REG_RANK_INDEX(8,
>                                             gicd_reg - GICD_IPRIORITYR,
>                                             DABT_WORD)];
> -    vgic_reg32_update(ipriorityr, r, info);
> +    priority = ACCESS_ONCE(*ipriorityr);
> +    vgic_reg32_update(&priority, r, info);
> +    ACCESS_ONCE(*ipriorityr) = priority;
>      vgic_unlock_rank(v, rank, flags);
> ....

What you do is very similar to my patch but open-code it. It might be 
possible to have other place which could take advantage of the a generic 
solution, so I am not convinced this would be the right way.

>
> Concurrent writes are protected by the rank lock, and reads are
> guaranteed to be atomic due to ACCESS_ONCE and the architectural
> guarantee of an aligned uint32_t access being atomic.
> We can't do anything about the benign race when the priority gets
> changed while we read it, but the above should make sure that we either
> read the old or the new value and nothing in between.
> The other read accesses (in vgic_v[23]_distr_mmio_read() and in vgic.c
> here in this patch) get protected by an ACCESS_ONCE().
>
> Does that make sense?

I was trying to address the suggestion of Stefano to drop the rank lock 
in some place and also make the solution generic.

I failed to address properly the lock drop. And have some idea how to do it.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 01/32] ARM: vGIC: avoid rank lock when reading priority

[Andre Przywara]

Hi,

On 06/06/17 18:11, Julien Grall wrote:
> 
> 
> On 06/06/17 18:06, Andre Przywara wrote:
>> On 30/05/17 11:47, Julien Grall wrote:
>>> Hi Andre,
>>>
>>> On 26/05/17 18:35, Andre Przywara wrote:
>>>> When reading the priority value of a virtual interrupt, we were taking
>>>> the respective rank lock so far.
>>>> However for forwarded interrupts (Dom0 only so far) this may lead to a
>>>> deadlock with the following call chain:
>>>> - MMIO access to change the IRQ affinity, calling the ITARGETSR handler
>>>> - this handler takes the appropriate rank lock and calls
>>>> vgic_store_itargetsr()
>>>> - vgic_store_itargetsr() will eventually call vgic_migrate_irq()
>>>> - if this IRQ is already in-flight, it will remove it from the old
>>>>   VCPU and inject it into the new one, by calling
>>>> vgic_vcpu_inject_irq()
>>>> - vgic_vcpu_inject_irq will call vgic_get_virq_priority()
>>>> - vgic_get_virq_priority() tries to take the rank lock - again!
>>>> It seems like this code path has never been exercised before.
>>>>
>>>> Fix this by avoiding taking the lock in vgic_get_virq_priority()
>>>> (like we
>>>> do in vgic_get_target_vcpu()).
>>>> Actually we are just reading one byte, and priority changes while
>>>> interrupts are handled are a benign race that can happen on real
>>>> hardware
>>>> too. So it looks safe to just use read_atomic() instead.
>>>>
>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>>> ---
>>>>  xen/arch/arm/vgic.c | 8 +-------
>>>>  1 file changed, 1 insertion(+), 7 deletions(-)
>>>>
>>>> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
>>>> index 83569b0..54b2aad 100644
>>>> --- a/xen/arch/arm/vgic.c
>>>> +++ b/xen/arch/arm/vgic.c
>>>> @@ -227,14 +227,8 @@ struct vcpu *vgic_get_target_vcpu(struct vcpu *v,
>>>> unsigned int virq)
>>>>  static int vgic_get_virq_priority(struct vcpu *v, unsigned int virq)
>>>>  {
>>>>      struct vgic_irq_rank *rank = vgic_rank_irq(v, virq);
>>>> -    unsigned long flags;
>>>> -    int priority;
>>>> -
>>>> -    vgic_lock_rank(v, rank, flags);
>>>> -    priority = rank->priority[virq & INTERRUPT_RANK_MASK];
>>>> -    vgic_unlock_rank(v, rank, flags);
>>>>
>>>> -    return priority;
>>>> +    return read_atomic(&rank->priority[virq & INTERRUPT_RANK_MASK]);
>>>
>>> The write in rank->priority will not be atomic (see vgic_reg_update
>>> implementation): the register is first masked, the the priority set.
>>>
>>> So you may end up to read 0 (which is the higher priority) by mistake.
>>>
>>> We should probably think to make vgic_reg_* helper atomic.
>>
>> The patch you sent yesterday may be a bit over the top for this.
> 
> Patch which I only sent internally to get feedback. ;)

Ah, indeed, sorry for dragging you into the light ;-)

For the records: I am not saying that your patch was wrong, I am just a
bit reluctant to change such a central function (vgic_reg_update) when
we only care about the priority.

>>
>> What about this one (in xen/arch/arm/vgic-v[23].c):
>>
>> static int vgic_v2_distr_mmio_write(struct vcpu *v, ...
>> {
>> -    uint32_t *ipriorityr;
>> +    uint32_t *ipriorityr, priority;
>> ....
>>      vgic_lock_rank(v, rank, flags);
>>      ipriorityr = &rank->ipriorityr[REG_RANK_INDEX(8,
>>                                             gicd_reg - GICD_IPRIORITYR,
>>                                             DABT_WORD)];
>> -    vgic_reg32_update(ipriorityr, r, info);
>> +    priority = ACCESS_ONCE(*ipriorityr);
>> +    vgic_reg32_update(&priority, r, info);
>> +    ACCESS_ONCE(*ipriorityr) = priority;
>>      vgic_unlock_rank(v, rank, flags);
>> ....
> 
> What you do is very similar to my patch but open-code it. It might be
> possible to have other place which could take advantage of the a generic
> solution, so I am not convinced this would be the right way.

My idea was to confine this fix to what we care for right now.
I guess eventually it doesn't matter as we will probably get rid of the
rank and its lock anyway.

>>
>> Concurrent writes are protected by the rank lock, and reads are
>> guaranteed to be atomic due to ACCESS_ONCE and the architectural
>> guarantee of an aligned uint32_t access being atomic.
>> We can't do anything about the benign race when the priority gets
>> changed while we read it, but the above should make sure that we either
>> read the old or the new value and nothing in between.
>> The other read accesses (in vgic_v[23]_distr_mmio_read() and in vgic.c
>> here in this patch) get protected by an ACCESS_ONCE().
>>
>> Does that make sense?
> 
> I was trying to address the suggestion of Stefano to drop the rank lock
> in some place and also make the solution generic.
> 
> I failed to address properly the lock drop. And have some idea how to do
> it.

Looking forward to it ....

Cheers,
Andre.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 01/32] ARM: vGIC: avoid rank lock when reading priority

[Julien Grall]

Hi Andre,

On 06/06/17 18:20, Andre Przywara wrote:
>>>
>>> What about this one (in xen/arch/arm/vgic-v[23].c):
>>>
>>> static int vgic_v2_distr_mmio_write(struct vcpu *v, ...
>>> {
>>> -    uint32_t *ipriorityr;
>>> +    uint32_t *ipriorityr, priority;
>>> ....
>>>      vgic_lock_rank(v, rank, flags);
>>>      ipriorityr = &rank->ipriorityr[REG_RANK_INDEX(8,
>>>                                             gicd_reg - GICD_IPRIORITYR,
>>>                                             DABT_WORD)];
>>> -    vgic_reg32_update(ipriorityr, r, info);
>>> +    priority = ACCESS_ONCE(*ipriorityr);
>>> +    vgic_reg32_update(&priority, r, info);
>>> +    ACCESS_ONCE(*ipriorityr) = priority;
>>>      vgic_unlock_rank(v, rank, flags);
>>> ....
>>
>> What you do is very similar to my patch but open-code it. It might be
>> possible to have other place which could take advantage of the a generic
>> solution, so I am not convinced this would be the right way.
>
> My idea was to confine this fix to what we care for right now.
> I guess eventually it doesn't matter as we will probably get rid of the
> rank and its lock anyway.

That's a good point. So we may want to wait until the vGIC rework to see 
what we can do here. Stefano, any opinion?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 03/32] ARM: vGIC: move irq_to_pending() calls under the VGIC VCPU lock

[Andre Przywara]

Hi,

On 30/05/17 12:08, Julien Grall wrote:
> Hi Andre,
> 
> On 26/05/17 18:35, Andre Przywara wrote:
>> So far irq_to_pending() is just a convenience function to lookup
>> statically allocated arrays. This will change with LPIs, which are
>> more dynamic, so the memory for their struct pending_irq might go away.
>> The proper answer to the issue of preventing stale pointers is
>> ref-counting, which requires more rework and will be introduced with
>> a later rework.
>> For now move the irq_to_pending() calls that are used with LPIs under the
>> VGIC VCPU lock, and only use the returned pointer while holding the lock.
>> This prevents the memory from being freed while we use it.
>> For the sake of completeness we take care about all irq_to_pending()
>> users, even those which later will never deal with LPIs.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>>  xen/arch/arm/gic.c  |  5 ++++-
>>  xen/arch/arm/vgic.c | 39 ++++++++++++++++++++++++++++++---------
>>  2 files changed, 34 insertions(+), 10 deletions(-)
>>
>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> index da19130..dcb1783 100644
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -402,10 +402,13 @@ static inline void gic_add_to_lr_pending(struct
>> vcpu *v, struct pending_irq *n)
>>
>>  void gic_remove_from_queues(struct vcpu *v, unsigned int virtual_irq)
>>  {
>> -    struct pending_irq *p = irq_to_pending(v, virtual_irq);
>> +    struct pending_irq *p;
>>      unsigned long flags;
>>
>>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>> +
>> +    p = irq_to_pending(v, virtual_irq);
>> +
>>      if ( !list_empty(&p->lr_queue) )
>>          list_del_init(&p->lr_queue);
>>      spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
>> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
>> index 54b2aad..69d732b 100644
>> --- a/xen/arch/arm/vgic.c
>> +++ b/xen/arch/arm/vgic.c
>> @@ -234,23 +234,29 @@ static int vgic_get_virq_priority(struct vcpu
>> *v, unsigned int virq)
>>  bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned
>> int irq)
>>  {
>>      unsigned long flags;
>> -    struct pending_irq *p = irq_to_pending(old, irq);
>> +    struct pending_irq *p;
>> +
>> +    spin_lock_irqsave(&old->arch.vgic.lock, flags);
>> +
>> +    p = irq_to_pending(old, irq);
>>
>>      /* nothing to do for virtual interrupts */
>>      if ( p->desc == NULL )
>> +    {
>> +        spin_unlock_irqrestore(&old->arch.vgic.lock, flags);
>>          return true;
>> +    }
>>
>>      /* migration already in progress, no need to do anything */
>>      if ( test_bit(GIC_IRQ_GUEST_MIGRATING, &p->status) )
>>      {
>>          gprintk(XENLOG_WARNING, "irq %u migration failed: requested
>> while in progress\n", irq);
>> +        spin_unlock_irqrestore(&old->arch.vgic.lock, flags);
>>          return false;
>>      }
>>
>>      perfc_incr(vgic_irq_migrates);
>>
>> -    spin_lock_irqsave(&old->arch.vgic.lock, flags);
>> -
>>      if ( list_empty(&p->inflight) )
>>      {
>>          irq_set_affinity(p->desc, cpumask_of(new->processor));
>> @@ -285,6 +291,13 @@ void arch_move_irqs(struct vcpu *v)
>>      struct vcpu *v_target;
>>      int i;
>>
>> +    /*
>> +     * We don't migrate LPIs at the moment.
>> +     * If we ever do, we must make sure that the struct pending_irq does
>> +     * not go away, as there is no lock preventing this here.
>> +     */
>> +    ASSERT(!is_lpi(vgic_num_irqs(d) - 1));
> 
> Hmmm? This raise a question of why vgic_num_irqs does not include the
> LPIs today...

I admit that this line is a bit puzzling. I guess vgic_num_irqs() should
be renamed to something like vgic_max_spis(), but this wouldn't be
exactly the right name either.
I will extend the comment to note that the current code assumes
vgic_num_irqs() only covers SPIs. Is that OK?

>> +
>>      for ( i = 32; i < vgic_num_irqs(d); i++ )
>>      {
>>          v_target = vgic_get_target_vcpu(v, i);
>> @@ -299,6 +312,7 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r,
>> int n)
>>  {
>>      const unsigned long mask = r;
>>      struct pending_irq *p;
>> +    struct irq_desc *desc;
>>      unsigned int irq;
>>      unsigned long flags;
>>      int i = 0;
>> @@ -307,14 +321,19 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t
>> r, int n)
>>      while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
>>          irq = i + (32 * n);
>>          v_target = vgic_get_target_vcpu(v, irq);
>> +
>> +        spin_lock_irqsave(&v_target->arch.vgic.lock, flags);
>>          p = irq_to_pending(v_target, irq);
>>          clear_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
>>          gic_remove_from_queues(v_target, irq);
> 
> gic_remove_from_queues is taking v_target vGIC lock. So you just
> introduced a deadlock. You remove it in the next patch but still, we
> should not introduce regression even temporarily. This would make to
> difficult to bisect the series.

Good point, thanks for spotting this. I will try to address this. I
compile-tested every single patch, but didn't try to boot every one.

> TBH, I am not a big fan of spreading the mess of vGIC locking when we
> are going to rework the vGIC and know that this code will not be called
> for LPIs.
> 
> BTW, this series is not bisectable because the host ITS is only enabled
> from patch #12.

I moved that to the front now.
TBH I spotted this issue before, and had a simpler version of patch #12
to plug this. Maybe we should consider to merge this one for 4.9 still,
as currently enabling the ITS in .config and running it on an ITS
machine will fail to boot Dom0.

Cheers,
Andre.


> 
>> -        if ( p->desc != NULL )
>> +        desc = p->desc;
>> +        spin_unlock_irqrestore(&v_target->arch.vgic.lock, flags);
>> +
>> +        if ( desc != NULL )
>>          {
>> -            spin_lock_irqsave(&p->desc->lock, flags);
>> -            p->desc->handler->disable(p->desc);
>> -            spin_unlock_irqrestore(&p->desc->lock, flags);
>> +            spin_lock_irqsave(&desc->lock, flags);
>> +            desc->handler->disable(desc);
>> +            spin_unlock_irqrestore(&desc->lock, flags);
>>          }
>>          i++;
>>      }
>> @@ -349,9 +368,9 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r,
>> int n)
>>      while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
>>          irq = i + (32 * n);
>>          v_target = vgic_get_target_vcpu(v, irq);
>> +        spin_lock_irqsave(&v_target->arch.vgic.lock, flags);
>>          p = irq_to_pending(v_target, irq);
>>          set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
>> -        spin_lock_irqsave(&v_target->arch.vgic.lock, flags);
>>          if ( !list_empty(&p->inflight) &&
>> !test_bit(GIC_IRQ_GUEST_VISIBLE, &p->status) )
>>              gic_raise_guest_irq(v_target, irq, p->priority);
>>          spin_unlock_irqrestore(&v_target->arch.vgic.lock, flags);
>> @@ -460,7 +479,7 @@ void vgic_clear_pending_irqs(struct vcpu *v)
>>  void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq)
>>  {
>>      uint8_t priority;
>> -    struct pending_irq *iter, *n = irq_to_pending(v, virq);
>> +    struct pending_irq *iter, *n;
>>      unsigned long flags;
>>      bool running;
>>
>> @@ -468,6 +487,8 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned
>> int virq)
>>
>>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>>
>> +    n = irq_to_pending(v, virq);
>> +
>>      /* vcpu offline */
>>      if ( test_bit(_VPF_down, &v->pause_flags) )
>>      {
>>
> 
> Cheers,
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 01/32] ARM: vGIC: avoid rank lock when reading priority

[Stefano Stabellini]

On Tue, 6 Jun 2017, Julien Grall wrote:
> Hi Andre,
> 
> On 06/06/17 18:20, Andre Przywara wrote:
> > > > 
> > > > What about this one (in xen/arch/arm/vgic-v[23].c):
> > > > 
> > > > static int vgic_v2_distr_mmio_write(struct vcpu *v, ...
> > > > {
> > > > -    uint32_t *ipriorityr;
> > > > +    uint32_t *ipriorityr, priority;
> > > > ....
> > > >      vgic_lock_rank(v, rank, flags);
> > > >      ipriorityr = &rank->ipriorityr[REG_RANK_INDEX(8,
> > > >                                             gicd_reg - GICD_IPRIORITYR,
> > > >                                             DABT_WORD)];
> > > > -    vgic_reg32_update(ipriorityr, r, info);
> > > > +    priority = ACCESS_ONCE(*ipriorityr);
> > > > +    vgic_reg32_update(&priority, r, info);
> > > > +    ACCESS_ONCE(*ipriorityr) = priority;
> > > >      vgic_unlock_rank(v, rank, flags);
> > > > ....
> > > 
> > > What you do is very similar to my patch but open-code it. It might be
> > > possible to have other place which could take advantage of the a generic
> > > solution, so I am not convinced this would be the right way.
> > 
> > My idea was to confine this fix to what we care for right now.
> > I guess eventually it doesn't matter as we will probably get rid of the
> > rank and its lock anyway.
> 
> That's a good point. So we may want to wait until the vGIC rework to see what
> we can do here. Stefano, any opinion?

Either would work. Since we are at it, I would have done what Julien has
done, but also doing the minimum required now is also OK. I don't think
the order of changes is important in this case given that the end result
will be the same.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 03/32] ARM: vGIC: move irq_to_pending() calls under the VGIC VCPU lock

[Stefano Stabellini]

On Tue, 6 Jun 2017, Andre Przywara wrote:
> Maybe we should consider to merge this one for 4.9 still,
> as currently enabling the ITS in .config and running it on an ITS
> machine will fail to boot Dom0.

Here, you are talking about this patch, patch #3, right?

Although it should be "safe", it touches a lot of common code. I think
it is too risky to commit it now to fix an experimental feature. I would
rather wait until it is committed to staging in the 4.10 dev window,
then backport it.

 

> >> -        if ( p->desc != NULL )
> >> +        desc = p->desc;
> >> +        spin_unlock_irqrestore(&v_target->arch.vgic.lock, flags);
> >> +
> >> +        if ( desc != NULL )
> >>          {
> >> -            spin_lock_irqsave(&p->desc->lock, flags);
> >> -            p->desc->handler->disable(p->desc);
> >> -            spin_unlock_irqrestore(&p->desc->lock, flags);
> >> +            spin_lock_irqsave(&desc->lock, flags);
> >> +            desc->handler->disable(desc);
> >> +            spin_unlock_irqrestore(&desc->lock, flags);
> >>          }
> >>          i++;
> >>      }
> >> @@ -349,9 +368,9 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r,
> >> int n)
> >>      while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
> >>          irq = i + (32 * n);
> >>          v_target = vgic_get_target_vcpu(v, irq);
> >> +        spin_lock_irqsave(&v_target->arch.vgic.lock, flags);
> >>          p = irq_to_pending(v_target, irq);
> >>          set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
> >> -        spin_lock_irqsave(&v_target->arch.vgic.lock, flags);
> >>          if ( !list_empty(&p->inflight) &&
> >> !test_bit(GIC_IRQ_GUEST_VISIBLE, &p->status) )
> >>              gic_raise_guest_irq(v_target, irq, p->priority);
> >>          spin_unlock_irqrestore(&v_target->arch.vgic.lock, flags);
> >> @@ -460,7 +479,7 @@ void vgic_clear_pending_irqs(struct vcpu *v)
> >>  void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq)
> >>  {
> >>      uint8_t priority;
> >> -    struct pending_irq *iter, *n = irq_to_pending(v, virq);
> >> +    struct pending_irq *iter, *n;
> >>      unsigned long flags;
> >>      bool running;
> >>
> >> @@ -468,6 +487,8 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned
> >> int virq)
> >>
> >>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
> >>
> >> +    n = irq_to_pending(v, virq);
> >> +
> >>      /* vcpu offline */
> >>      if ( test_bit(_VPF_down, &v->pause_flags) )
> >>      {
> >>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 03/32] ARM: vGIC: move irq_to_pending() calls under the VGIC VCPU lock

[Andre Przywara]

Hi,

On 06/06/17 19:46, Stefano Stabellini wrote:
> On Tue, 6 Jun 2017, Andre Przywara wrote:
>> Maybe we should consider to merge this one for 4.9 still,
>> as currently enabling the ITS in .config and running it on an ITS
>> machine will fail to boot Dom0.
> 
> Here, you are talking about this patch, patch #3, right?

No, sorry, I meant patch 12.

> Although it should be "safe", it touches a lot of common code. I think
> it is too risky to commit it now to fix an experimental feature. I would
> rather wait until it is committed to staging in the 4.10 dev window,
> then backport it.

Well, if you compile origin/staging with the ITS configured in and run
this on a machine with an ITS in the DT, it will not boot (regardless of
the ITS not being used anyway). This is because we try to map
collections on the host (using MAPC commands), but don't enable the host
ITS, so those commands are not executed and we time out.
I discovered this shortly after you merged the first ITS patches and
made a simple patch, but for some reasons this didn't end up on the
public list.

Let me send this out and we can decide whether we need this for 4.9 still.

Cheers,
Andre.

>>>> -        if ( p->desc != NULL )
>>>> +        desc = p->desc;
>>>> +        spin_unlock_irqrestore(&v_target->arch.vgic.lock, flags);
>>>> +
>>>> +        if ( desc != NULL )
>>>>          {
>>>> -            spin_lock_irqsave(&p->desc->lock, flags);
>>>> -            p->desc->handler->disable(p->desc);
>>>> -            spin_unlock_irqrestore(&p->desc->lock, flags);
>>>> +            spin_lock_irqsave(&desc->lock, flags);
>>>> +            desc->handler->disable(desc);
>>>> +            spin_unlock_irqrestore(&desc->lock, flags);
>>>>          }
>>>>          i++;
>>>>      }
>>>> @@ -349,9 +368,9 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r,
>>>> int n)
>>>>      while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
>>>>          irq = i + (32 * n);
>>>>          v_target = vgic_get_target_vcpu(v, irq);
>>>> +        spin_lock_irqsave(&v_target->arch.vgic.lock, flags);
>>>>          p = irq_to_pending(v_target, irq);
>>>>          set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
>>>> -        spin_lock_irqsave(&v_target->arch.vgic.lock, flags);
>>>>          if ( !list_empty(&p->inflight) &&
>>>> !test_bit(GIC_IRQ_GUEST_VISIBLE, &p->status) )
>>>>              gic_raise_guest_irq(v_target, irq, p->priority);
>>>>          spin_unlock_irqrestore(&v_target->arch.vgic.lock, flags);
>>>> @@ -460,7 +479,7 @@ void vgic_clear_pending_irqs(struct vcpu *v)
>>>>  void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq)
>>>>  {
>>>>      uint8_t priority;
>>>> -    struct pending_irq *iter, *n = irq_to_pending(v, virq);
>>>> +    struct pending_irq *iter, *n;
>>>>      unsigned long flags;
>>>>      bool running;
>>>>
>>>> @@ -468,6 +487,8 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned
>>>> int virq)
>>>>
>>>>      spin_lock_irqsave(&v->arch.vgic.lock, flags);
>>>>
>>>> +    n = irq_to_pending(v, virq);
>>>> +
>>>>      /* vcpu offline */
>>>>      if ( test_bit(_VPF_down, &v->pause_flags) )
>>>>      {
>>>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 06/32] ARM: GIC: Add checks for NULL pointer pending_irq's

[Julien Grall]

On 06/06/17 11:19, Andre Przywara wrote:
> Hi,
>
> On 30/05/17 12:38, Julien Grall wrote:
>> Hi Andre,
>>
>> On 26/05/17 18:35, Andre Przywara wrote:
>>> For LPIs the struct pending_irq's are dynamically allocated and the
>>> pointers will be stored in a radix tree. Since an LPI can be "unmapped"
>>> at any time, teach the VGIC how to deal with irq_to_pending() returning
>>> a NULL pointer.
>>> We just do nothing in this case or clean up the LR if the virtual LPI
>>> number was still in an LR.
>>>
>>> Those are all call sites for irq_to_pending(), as per:
>>> "git grep irq_to_pending", and their evaluations:
>>> (PROTECTED means: added NULL check and bailing out)
>>>
>>>     xen/arch/arm/gic.c:
>>> gic_route_irq_to_guest(): only called for SPIs, added ASSERT()
>>> gic_remove_irq_from_guest(): only called for SPIs, added ASSERT()
>>> gic_remove_from_queues(): PROTECTED, called within VCPU VGIC lock
>>
>> This function has been renamed in patch #4.
>>
>>> gic_raise_inflight_irq(): PROTECTED, called under VCPU VGIC lock
>>> gic_raise_guest_irq(): PROTECTED, called under VCPU VGIC lock
>>> gic_update_one_lr(): PROTECTED, called under VCPU VGIC lock
>>>
>>>     xen/arch/arm/vgic.c:
>>> vgic_migrate_irq(): not called for LPIs (virtual IRQs), added ASSERT()
>>> arch_move_irqs(): not iterating over LPIs, added ASSERT()
>>
>> I don't see any ASSERT added in arch_move_irqs.
>
> Because this is just checking for not being called with an LPI, it was
> introduced in patch 03/32 already. I can adjust the commit message.

Yes please.

>
> Cheers,
> Andre.
>
>>> vgic_disable_irqs(): not called for LPIs, added ASSERT()
>>> vgic_enable_irqs(): not called for LPIs, added ASSERT()
>>> vgic_vcpu_inject_irq(): PROTECTED, moved under VCPU VGIC lock
>>>
>>>     xen/include/asm-arm/event.h:
>>> local_events_need_delivery_nomask(): only called for a PPI, added
>>> ASSERT()
>>>
>>>     xen/include/asm-arm/vgic.h:
>>> (prototype)
>>
>> Cheers,
>>

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 25/32] ARM: vITS: handle MAPTI/MAPI command

[Andre Przywara]

Hi,

On 02/06/17 18:12, Julien Grall wrote:
> Hi Andre,
> 
> On 05/26/2017 06:35 PM, Andre Przywara wrote:
>> The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
>> pair and actually instantiates LPI interrupts. MAPI is just a variant
>> of this comment, where the LPI ID is the same as the event ID.
>> 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 domain and the virtual LPI number in the respective
>> host LPI entry, we also initialize and add the already allocated
>> struct pending_irq to our radix tree, so that we can now easily find it
>> by its virtual LPI number.
>> We also read the property table to update the enabled bit and the
>> priority for our new LPI, as we might have missed this during an earlier
>> INVALL call (which only checks mapped LPIs). But we make sure that the
>> property table is actually valid, as all redistributors might still
>> be disabled at this point.
>> Since write_itte_locked() now sees its first usage, we change the
>> declaration to static.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>>   xen/arch/arm/gic-v3-its.c        |  27 ++++++++
>>   xen/arch/arm/vgic-v3-its.c       | 138
>> ++++++++++++++++++++++++++++++++++++++-
>>   xen/include/asm-arm/gic_v3_its.h |   3 +
>>   3 files changed, 165 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
>> index 8864e0b..41fff64 100644
>> --- a/xen/arch/arm/gic-v3-its.c
>> +++ b/xen/arch/arm/gic-v3-its.c
>> @@ -876,6 +876,33 @@ int gicv3_remove_guest_event(struct domain *d,
>> paddr_t vdoorbell_address,
>>       return 0;
>>   }
>>   +/*
>> + * Connects the event ID for an already assigned device to the given
>> VCPU/vLPI
>> + * pair. The corresponding physical LPI is already mapped on the host
>> side
>> + * (when assigning the physical device to the guest), so we just
>> connect the
>> + * target VCPU/vLPI pair to that interrupt to inject it properly if
>> it fires.
>> + * Returns a pointer to the already allocated struct pending_irq that is
>> + * meant to be used by that event.
>> + */
>> +struct pending_irq *gicv3_assign_guest_event(struct domain *d,
>> +                                             paddr_t vdoorbell_address,
>> +                                             uint32_t vdevid,
>> uint32_t eventid,
>> +                                             uint32_t virt_lpi)
>> +{
>> +    struct pending_irq *pirq;
>> +    uint32_t host_lpi = 0;
> This should be INVALID_LPI and not 0.
> 
> [...]
> 
>> +/*
>> + * For a given virtual LPI read the enabled bit and priority from the
>> virtual
>> + * property table and update the virtual IRQ's state in the given
>> pending_irq.
>> + * Must be called with the respective VGIC VCPU lock held.
>> + */
>> +static int update_lpi_property(struct domain *d, struct pending_irq *p)
>> +{
>> +    paddr_t addr;
>> +    uint8_t property;
>> +    int ret;
>> +
>> +    /*
>> +     * If no redistributor has its LPIs enabled yet, we can't access the
>> +     * property table. In this case we just can't update the properties,
>> +     * but this should not be an error from an ITS point of view.
>> +     */
>> +    if ( !read_atomic(&d->arch.vgic.rdists_enabled) )
>> +        return 0;
> 
> AFAICT, there are no other place where the property would be updated.
> Should we put a warning to let the user know that property will not be
> updated? More that you don't return an error so no easy way to know
> what's going on.

So I thought about this again: If we handle an INV command while the
respective redistributor has LPIs off, even hardware can't do anything,
as having LPIs disabled means that there is no valid property table.
So a hardware redistributor would probably just ignore this request.

I see us only calling update_lpi_property during command handling, so I
think it is safe to just silently ignore it, as hardware would do the same?

>> +
>> +    addr = d->arch.vgic.rdist_propbase & GENMASK(51, 12);
>> +
>> +    ret = vgic_access_guest_memory(d, addr + p->irq - LPI_OFFSET,
>> +                                   &property, sizeof(property), false);
>> +    if ( ret )
>> +        return ret;
>> +
>> +    write_atomic(&p->lpi_priority, property & LPI_PROP_PRIO_MASK);
>> +
>> +    if ( property & LPI_PROP_ENABLED )
>> +        set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
>> +    else
>> +        clear_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
>> +
>> +    return 0;
>> +}
>> +
>>   /* Must be called with the ITS lock held. */
>>   static int its_discard_event(struct virt_its *its,
>>                                uint32_t vdevid, uint32_t vevid)
>> @@ -538,6 +574,98 @@ static int its_handle_mapd(struct virt_its *its,
>> uint64_t *cmdptr)
>>       return ret;
>>   }
>>   +static int its_handle_mapti(struct virt_its *its, uint64_t *cmdptr)
>> +{
> 
> [...]
> 
>> +    /*
>> +     * radix_tree_insert() returns an error either due to an internal
>> +     * condition (like memory allocation failure) or because the LPI
>> already
>> +     * existed in the tree. We don't support the latter case, so we
>> always
>> +     * cleanup and return an error here in any case.
>> +     */
>> +out_remove_host_entry:
>> +    gicv3_remove_guest_event(its->d, its->doorbell_address, devid,
>> eventid);
> 
> Can gicv3_remove_guest_event fail? If yes, should we check the
> return/add comment? If not, then we should have an ASSERT(....).

Well, as we have an "if ( !ret ) return 0;" above, we only get here with
ret being != 0, so this is in an error path already.
I am not sure how we should react here then, I think reporting the first
error is probably more meaningful.

Cheers,
Andre.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 18/32] ARM: vITS: introduce translation table walks

[Julien Grall]

Hi Andre,

On 26/05/17 18:35, Andre Przywara wrote:
> +/*
> + * Queries the collection and device tables to translate the device ID and
> + * event ID and find the appropriate ITTE. The given collection ID and the
> + * virtual LPI number are then stored into that entry.
> + * If vcpu_ptr is provided, returns the VCPU belonging to that collection.
> + * Must be called with the ITS lock held.
> + */
> +bool write_itte_locked(struct virt_its *its, uint32_t devid,
> +                       uint32_t evid, uint32_t collid, uint32_t vlpi,
> +                       struct vcpu **vcpu_ptr)
> +{
> +    paddr_t addr;
> +    struct vits_itte itte;
> +
> +    ASSERT(spin_is_locked(&its->its_lock));
> +
> +    if ( collid >= its->max_collections )
> +        return false;

This check will always fail with the command DISCARD because collid == 
UNMAPPED_COLLECTION (~0).

Looking at the code, I am not sure why you need to validate collid and 
nr_lpis in write_itte_locked. This should have been made by the caller.

> +
> +    if ( vlpi >= its->d->arch.vgic.nr_lpis )
> +        return false;
> +
> +    addr = its_get_itte_address(its, devid, evid);
> +    if ( addr == INVALID_PADDR )
> +        return false;
> +
> +    itte.collection = collid;
> +    itte.vlpi = vlpi;
> +
> +    if ( vgic_access_guest_memory(its->d, addr, &itte, sizeof(itte), true) )
> +        return false;
> +
> +    if ( vcpu_ptr )
> +        *vcpu_ptr = get_vcpu_from_collection(its, collid);

I guess this is why you check the collection in this function. However, 
I am not sure how this is related to write_itte_locked.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 24/32] ARM: GICv3: handle unmapped LPIs

[Julien Grall]

Hi Andre,

On 26/05/17 18:35, Andre Przywara wrote:
> +/*
> + * Find an unused LR to insert an IRQ into, starting with the LR given
> + * by @lr. If this new interrupt is a PRISTINE LPI, scan the other LRs to
> + * avoid inserting the same IRQ twice. This situation can occur when an
> + * event gets discarded while the LPI is in an LR, and a new LPI with the
> + * same number gets mapped quickly afterwards.
> + */
> +static unsigned int gic_find_unused_lr(struct vcpu *v,
> +                                       struct pending_irq *p,
> +                                       unsigned int lr)
> +{
> +    unsigned int nr_lrs = gic_hw_ops->info->nr_lrs;
> +    unsigned long *lr_mask = (unsigned long *) &this_cpu(lr_mask);
> +    struct gic_lr lr_val;
> +
> +    ASSERT(spin_is_locked(&v->arch.vgic.lock));
> +
> +    if ( test_bit(GIC_IRQ_GUEST_PRISTINE_LPI, &p->status) )
> +    {
> +        unsigned int used_lr = 0;
> +
> +        while ( (used_lr = find_next_bit(lr_mask, nr_lrs, used_lr)) < nr_lrs )

This loop is incorrect. find_next_bit will find the next set bit start 
at the offset used_lr. So if used_lr is set and does match the virq, 
this will turned into an infinite loop.

I would use the macro for_each_set_bit (see xen/bitops.h) here that will 
handle the problem for you:

for_each_set_bit( used_lr, lr_mask, nr_lrs )
{
  ....
}

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 18/32] ARM: vITS: introduce translation table walks

[Andre Przywara]

Hi,

On 08/06/17 10:35, Julien Grall wrote:
> Hi Andre,
> 
> On 26/05/17 18:35, Andre Przywara wrote:
>> +/*
>> + * Queries the collection and device tables to translate the device
>> ID and
>> + * event ID and find the appropriate ITTE. The given collection ID
>> and the
>> + * virtual LPI number are then stored into that entry.
>> + * If vcpu_ptr is provided, returns the VCPU belonging to that
>> collection.
>> + * Must be called with the ITS lock held.
>> + */
>> +bool write_itte_locked(struct virt_its *its, uint32_t devid,
>> +                       uint32_t evid, uint32_t collid, uint32_t vlpi,
>> +                       struct vcpu **vcpu_ptr)
>> +{
>> +    paddr_t addr;
>> +    struct vits_itte itte;
>> +
>> +    ASSERT(spin_is_locked(&its->its_lock));
>> +
>> +    if ( collid >= its->max_collections )
>> +        return false;
> 
> This check will always fail with the command DISCARD because collid ==
> UNMAPPED_COLLECTION (~0).

Good point, thanks for catching this.

> Looking at the code, I am not sure why you need to validate collid and
> nr_lpis in write_itte_locked. This should have been made by the caller.

Indeed, I just fixed that.

>> +
>> +    if ( vlpi >= its->d->arch.vgic.nr_lpis )
>> +        return false;
>> +
>> +    addr = its_get_itte_address(its, devid, evid);
>> +    if ( addr == INVALID_PADDR )
>> +        return false;
>> +
>> +    itte.collection = collid;
>> +    itte.vlpi = vlpi;
>> +
>> +    if ( vgic_access_guest_memory(its->d, addr, &itte, sizeof(itte),
>> true) )
>> +        return false;
>> +
>> +    if ( vcpu_ptr )
>> +        *vcpu_ptr = get_vcpu_from_collection(its, collid);
> 
> I guess this is why you check the collection in this function. However,
> I am not sure how this is related to write_itte_locked.

Looks like some artefact from some previous revisions of the code
(possibly due to some locking, where someone was calling write_itte(),
which would drop the lock before returning).

But indeed this is independent and actually there is only one user of
this, so I removed the vcpu_ptr parameter and do the lookup outside of
this function.

On the way I removed this whole {read,write}_itte_locked naming, just
providing functions which assume we hold the lock. There is only one
caller which didn't hold the lock, so I can just do the locking there.

Thanks for pointing this out!

Cheers,
Andre.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 17/32] ARM: vITS: add command handling stub and MMIO emulation

[Julien Grall]

Hi Andre,

On 26/05/17 18:35, Andre Przywara wrote:
> +/**************************************
> + * Functions that handle ITS commands *
> + **************************************/
> +
> +static uint64_t its_cmd_mask_field(uint64_t *its_cmd, unsigned int word,
> +                                   unsigned int shift, unsigned int size)
> +{
> +    return ((its_cmd[word])) >> (shift & (BIT(size) - 1));

This code is wrong. The mask applies to shift and not the shifted 
result. I fixed with:

return (its_cmd[word] >> shift) * (BIT(size) - 1).

Though,  BIT(size) - 1 would not work if size == 64. I would replace by 
GENMASK(0, size - 1) to be safe in all the case.

[...]

> +static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its)
> +{
> +    paddr_t addr = its->cbaser & GENMASK(51, 12);
> +    uint64_t command[4];
> +
> +    ASSERT(spin_is_locked(&its->vcmd_lock));
> +
> +    if ( its->cwriter >= ITS_CMD_BUFFER_SIZE(its->cbaser) )
> +        return -1;
> +
> +    while ( its->creadr != its->cwriter )
> +    {
> +        int ret;
> +
> +        ret = vgic_access_guest_memory(d, addr + its->creadr,
> +                                       command, sizeof(command), false);
> +        if ( ret )
> +            return ret;
> +
> +        switch ( its_cmd_get_command(command) )
> +        {
> +        case GITS_CMD_SYNC:
> +            /* We handle ITS commands synchronously, so we ignore SYNC. */
> +            break;
> +        default:
> +            gdprintk(XENLOG_WARNING, "vGITS: unhandled ITS command %lu\n",
> +                     its_cmd_get_command(command));

Would it be possible to dump the full command (i.e command[0...3]) here 
and ...

> +            break;
> +        }
> +
> +        write_u64_atomic(&its->creadr, (its->creadr + ITS_CMD_SIZE) %
> +                         ITS_CMD_BUFFER_SIZE(its->cbaser));
> +
> +        if ( ret )
> +            gdprintk(XENLOG_WARNING,
> +                     "vGITS: ITS command error %d while handling command %lu\n",
> +                     ret, its_cmd_get_command(command));

... here?

This could be helpful whilst debugging vITS command emulation.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 24/32] ARM: GICv3: handle unmapped LPIs

[Andre Przywara]

Hi,

On 08/06/17 10:45, Julien Grall wrote:
> Hi Andre,
> 
> On 26/05/17 18:35, Andre Przywara wrote:
>> +/*
>> + * Find an unused LR to insert an IRQ into, starting with the LR given
>> + * by @lr. If this new interrupt is a PRISTINE LPI, scan the other
>> LRs to
>> + * avoid inserting the same IRQ twice. This situation can occur when an
>> + * event gets discarded while the LPI is in an LR, and a new LPI with
>> the
>> + * same number gets mapped quickly afterwards.
>> + */
>> +static unsigned int gic_find_unused_lr(struct vcpu *v,
>> +                                       struct pending_irq *p,
>> +                                       unsigned int lr)
>> +{
>> +    unsigned int nr_lrs = gic_hw_ops->info->nr_lrs;
>> +    unsigned long *lr_mask = (unsigned long *) &this_cpu(lr_mask);
>> +    struct gic_lr lr_val;
>> +
>> +    ASSERT(spin_is_locked(&v->arch.vgic.lock));
>> +
>> +    if ( test_bit(GIC_IRQ_GUEST_PRISTINE_LPI, &p->status) )
>> +    {
>> +        unsigned int used_lr = 0;
>> +
>> +        while ( (used_lr = find_next_bit(lr_mask, nr_lrs, used_lr)) <
>> nr_lrs )
> 
> This loop is incorrect. find_next_bit will find the next set bit start
> at the offset used_lr. So if used_lr is set and does match the virq,
> this will turned into an infinite loop.

Thanks for catching this! Fixed as hinted below.

Cheers,
Andre.


> I would use the macro for_each_set_bit (see xen/bitops.h) here that will
> handle the problem for you:
> 
> for_each_set_bit( used_lr, lr_mask, nr_lrs )
> {
>  ....
> }
> 
> Cheers,
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 25/32] ARM: vITS: handle MAPTI/MAPI command

[Andre Przywara]

Hi,

On 02/06/17 18:12, Julien Grall wrote:
> Hi Andre,
> 
> On 05/26/2017 06:35 PM, Andre Przywara wrote:
>> The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
>> pair and actually instantiates LPI interrupts. MAPI is just a variant
>> of this comment, where the LPI ID is the same as the event ID.
>> 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 domain and the virtual LPI number in the respective
>> host LPI entry, we also initialize and add the already allocated
>> struct pending_irq to our radix tree, so that we can now easily find it
>> by its virtual LPI number.
>> We also read the property table to update the enabled bit and the
>> priority for our new LPI, as we might have missed this during an earlier
>> INVALL call (which only checks mapped LPIs). But we make sure that the
>> property table is actually valid, as all redistributors might still
>> be disabled at this point.
>> Since write_itte_locked() now sees its first usage, we change the
>> declaration to static.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>>   xen/arch/arm/gic-v3-its.c        |  27 ++++++++
>>   xen/arch/arm/vgic-v3-its.c       | 138
>> ++++++++++++++++++++++++++++++++++++++-
>>   xen/include/asm-arm/gic_v3_its.h |   3 +
>>   3 files changed, 165 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
>> index 8864e0b..41fff64 100644
>> --- a/xen/arch/arm/gic-v3-its.c
>> +++ b/xen/arch/arm/gic-v3-its.c
>> @@ -876,6 +876,33 @@ int gicv3_remove_guest_event(struct domain *d,
>> paddr_t vdoorbell_address,
>>       return 0;
>>   }
>>   +/*
>> + * Connects the event ID for an already assigned device to the given
>> VCPU/vLPI
>> + * pair. The corresponding physical LPI is already mapped on the host
>> side
>> + * (when assigning the physical device to the guest), so we just
>> connect the
>> + * target VCPU/vLPI pair to that interrupt to inject it properly if
>> it fires.
>> + * Returns a pointer to the already allocated struct pending_irq that is
>> + * meant to be used by that event.
>> + */
>> +struct pending_irq *gicv3_assign_guest_event(struct domain *d,
>> +                                             paddr_t vdoorbell_address,
>> +                                             uint32_t vdevid,
>> uint32_t eventid,
>> +                                             uint32_t virt_lpi)
>> +{
>> +    struct pending_irq *pirq;
>> +    uint32_t host_lpi = 0;
> This should be INVALID_LPI and not 0.
> 
> [...]
> 
>> +/*
>> + * For a given virtual LPI read the enabled bit and priority from the
>> virtual
>> + * property table and update the virtual IRQ's state in the given
>> pending_irq.
>> + * Must be called with the respective VGIC VCPU lock held.
>> + */
>> +static int update_lpi_property(struct domain *d, struct pending_irq *p)
>> +{
>> +    paddr_t addr;
>> +    uint8_t property;
>> +    int ret;
>> +
>> +    /*
>> +     * If no redistributor has its LPIs enabled yet, we can't access the
>> +     * property table. In this case we just can't update the properties,
>> +     * but this should not be an error from an ITS point of view.
>> +     */
>> +    if ( !read_atomic(&d->arch.vgic.rdists_enabled) )
>> +        return 0;

I was just looking at rdists_enabled, and think that using read_atomic()
is a red herring.
First rdists_enabled is a bool, so I have a hard time to imagine how it
could be read non-atomically.
I think the intention of making this read "somewhat special" was to
cater for the fact that we write it under the domain lock, but read it
here without taking it. But I think for this case we don't need any
special read version, and anyway an *atomic* read would not help here.

What we want is to make sure that rdist_propbase is valid before we see
rdists_enabled gets true, this is what this check here is for. This
should be solved by a write barrier between the two on the other side.

Looking at Linux' memory_barriers.txt my understanding is that the
matching barrier on the read side does not necessarily need to be an
explicit barrier instruction, it could be a control flow dependency as
well. And here we have that: we check rdists_enabled and bail out if
it's not set, so neither the compiler nor the CPU can reorder this (as
this would violate program semantics).

Also rdists_enabled is a bit special in that it never gets reset once it
became true, very much like the LPI enablement in the GICv3 spec.

So I think we can really go with a normal read plus a comment.

Does that make sense?

Cheers,
Andre.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 25/32] ARM: vITS: handle MAPTI/MAPI command

[Stefano Stabellini]

On Fri, 9 Jun 2017, Andre Przywara wrote:
> On 02/06/17 18:12, Julien Grall wrote:
> > Hi Andre,
> > 
> > On 05/26/2017 06:35 PM, Andre Przywara wrote:
> >> The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
> >> pair and actually instantiates LPI interrupts. MAPI is just a variant
> >> of this comment, where the LPI ID is the same as the event ID.
> >> 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 domain and the virtual LPI number in the respective
> >> host LPI entry, we also initialize and add the already allocated
> >> struct pending_irq to our radix tree, so that we can now easily find it
> >> by its virtual LPI number.
> >> We also read the property table to update the enabled bit and the
> >> priority for our new LPI, as we might have missed this during an earlier
> >> INVALL call (which only checks mapped LPIs). But we make sure that the
> >> property table is actually valid, as all redistributors might still
> >> be disabled at this point.
> >> Since write_itte_locked() now sees its first usage, we change the
> >> declaration to static.
> >>
> >> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> >> ---
> >>   xen/arch/arm/gic-v3-its.c        |  27 ++++++++
> >>   xen/arch/arm/vgic-v3-its.c       | 138
> >> ++++++++++++++++++++++++++++++++++++++-
> >>   xen/include/asm-arm/gic_v3_its.h |   3 +
> >>   3 files changed, 165 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> >> index 8864e0b..41fff64 100644
> >> --- a/xen/arch/arm/gic-v3-its.c
> >> +++ b/xen/arch/arm/gic-v3-its.c
> >> @@ -876,6 +876,33 @@ int gicv3_remove_guest_event(struct domain *d,
> >> paddr_t vdoorbell_address,
> >>       return 0;
> >>   }
> >>   +/*
> >> + * Connects the event ID for an already assigned device to the given
> >> VCPU/vLPI
> >> + * pair. The corresponding physical LPI is already mapped on the host
> >> side
> >> + * (when assigning the physical device to the guest), so we just
> >> connect the
> >> + * target VCPU/vLPI pair to that interrupt to inject it properly if
> >> it fires.
> >> + * Returns a pointer to the already allocated struct pending_irq that is
> >> + * meant to be used by that event.
> >> + */
> >> +struct pending_irq *gicv3_assign_guest_event(struct domain *d,
> >> +                                             paddr_t vdoorbell_address,
> >> +                                             uint32_t vdevid,
> >> uint32_t eventid,
> >> +                                             uint32_t virt_lpi)
> >> +{
> >> +    struct pending_irq *pirq;
> >> +    uint32_t host_lpi = 0;
> > This should be INVALID_LPI and not 0.
> > 
> > [...]
> > 
> >> +/*
> >> + * For a given virtual LPI read the enabled bit and priority from the
> >> virtual
> >> + * property table and update the virtual IRQ's state in the given
> >> pending_irq.
> >> + * Must be called with the respective VGIC VCPU lock held.
> >> + */
> >> +static int update_lpi_property(struct domain *d, struct pending_irq *p)
> >> +{
> >> +    paddr_t addr;
> >> +    uint8_t property;
> >> +    int ret;
> >> +
> >> +    /*
> >> +     * If no redistributor has its LPIs enabled yet, we can't access the
> >> +     * property table. In this case we just can't update the properties,
> >> +     * but this should not be an error from an ITS point of view.
> >> +     */
> >> +    if ( !read_atomic(&d->arch.vgic.rdists_enabled) )
> >> +        return 0;
> 
> I was just looking at rdists_enabled, and think that using read_atomic()
> is a red herring.
> First rdists_enabled is a bool, so I have a hard time to imagine how it
> could be read non-atomically.

This is not a good argument, because if we want the read to be atomic,
then we need to be using one of the _atomic functions regardless of the
type.


> I think the intention of making this read "somewhat special" was to
> cater for the fact that we write it under the domain lock, but read it
> here without taking it.

I haven't looked at the specific of rdists_enabled in this
implementaion, but be aware that in general writing a variable under a
lock, and reading it atomically is not safe. You either read and write
under a lock, or read and write atomically.


> But I think for this case we don't need any
> special read version, and anyway an *atomic* read would not help here.
> 
> What we want is to make sure that rdist_propbase is valid before we see
> rdists_enabled gets true, this is what this check here is for. This
> should be solved by a write barrier between the two on the other side.
> 
> Looking at Linux' memory_barriers.txt my understanding is that the
> matching barrier on the read side does not necessarily need to be an
> explicit barrier instruction, it could be a control flow dependency as
> well. And here we have that: we check rdists_enabled and bail out if
> it's not set, so neither the compiler nor the CPU can reorder this (as
> this would violate program semantics).

I think that this is true.


> Also rdists_enabled is a bit special in that it never gets reset once it
> became true, very much like the LPI enablement in the GICv3 spec.
> 
> So I think we can really go with a normal read plus a comment.
> 
> Does that make sense?

The first motivation isn't right, but I think that the latter
explanation makes sense.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 25/32] ARM: vITS: handle MAPTI/MAPI command

[Andre Przywara]

Hi,

On 09/06/17 20:14, Stefano Stabellini wrote:
> On Fri, 9 Jun 2017, Andre Przywara wrote:
>> On 02/06/17 18:12, Julien Grall wrote:
>>> Hi Andre,
>>>
>>> On 05/26/2017 06:35 PM, Andre Przywara wrote:
>>>> The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
>>>> pair and actually instantiates LPI interrupts. MAPI is just a variant
>>>> of this comment, where the LPI ID is the same as the event ID.
>>>> 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 domain and the virtual LPI number in the respective
>>>> host LPI entry, we also initialize and add the already allocated
>>>> struct pending_irq to our radix tree, so that we can now easily find it
>>>> by its virtual LPI number.
>>>> We also read the property table to update the enabled bit and the
>>>> priority for our new LPI, as we might have missed this during an earlier
>>>> INVALL call (which only checks mapped LPIs). But we make sure that the
>>>> property table is actually valid, as all redistributors might still
>>>> be disabled at this point.
>>>> Since write_itte_locked() now sees its first usage, we change the
>>>> declaration to static.
>>>>
>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>>> ---
>>>>   xen/arch/arm/gic-v3-its.c        |  27 ++++++++
>>>>   xen/arch/arm/vgic-v3-its.c       | 138
>>>> ++++++++++++++++++++++++++++++++++++++-
>>>>   xen/include/asm-arm/gic_v3_its.h |   3 +
>>>>   3 files changed, 165 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
>>>> index 8864e0b..41fff64 100644
>>>> --- a/xen/arch/arm/gic-v3-its.c
>>>> +++ b/xen/arch/arm/gic-v3-its.c
>>>> @@ -876,6 +876,33 @@ int gicv3_remove_guest_event(struct domain *d,
>>>> paddr_t vdoorbell_address,
>>>>       return 0;
>>>>   }
>>>>   +/*
>>>> + * Connects the event ID for an already assigned device to the given
>>>> VCPU/vLPI
>>>> + * pair. The corresponding physical LPI is already mapped on the host
>>>> side
>>>> + * (when assigning the physical device to the guest), so we just
>>>> connect the
>>>> + * target VCPU/vLPI pair to that interrupt to inject it properly if
>>>> it fires.
>>>> + * Returns a pointer to the already allocated struct pending_irq that is
>>>> + * meant to be used by that event.
>>>> + */
>>>> +struct pending_irq *gicv3_assign_guest_event(struct domain *d,
>>>> +                                             paddr_t vdoorbell_address,
>>>> +                                             uint32_t vdevid,
>>>> uint32_t eventid,
>>>> +                                             uint32_t virt_lpi)
>>>> +{
>>>> +    struct pending_irq *pirq;
>>>> +    uint32_t host_lpi = 0;
>>> This should be INVALID_LPI and not 0.
>>>
>>> [...]
>>>
>>>> +/*
>>>> + * For a given virtual LPI read the enabled bit and priority from the
>>>> virtual
>>>> + * property table and update the virtual IRQ's state in the given
>>>> pending_irq.
>>>> + * Must be called with the respective VGIC VCPU lock held.
>>>> + */
>>>> +static int update_lpi_property(struct domain *d, struct pending_irq *p)
>>>> +{
>>>> +    paddr_t addr;
>>>> +    uint8_t property;
>>>> +    int ret;
>>>> +
>>>> +    /*
>>>> +     * If no redistributor has its LPIs enabled yet, we can't access the
>>>> +     * property table. In this case we just can't update the properties,
>>>> +     * but this should not be an error from an ITS point of view.
>>>> +     */
>>>> +    if ( !read_atomic(&d->arch.vgic.rdists_enabled) )
>>>> +        return 0;
>>
>> I was just looking at rdists_enabled, and think that using read_atomic()
>> is a red herring.
>> First rdists_enabled is a bool, so I have a hard time to imagine how it
>> could be read non-atomically.
> 
> This is not a good argument, because if we want the read to be atomic,
> then we need to be using one of the _atomic functions regardless of the
> type.

OK, I see your point there. For the records (and to explain my ignorance
;-) I think it applies to a strict C standard point of view only. For
all practical means I think a read into a variable of a native data type
(especially that of a 1-byte sized bool) is always atomic on arm and
arm64 - especially with the load/store architecture of ARM. Also I have
a hard time to imagine intermediate values for a bool ;-), especially
since rdist_enabled only goes from false to true once in a domain's
lifetime.
But nevertheless I can see and agree that to be C standard compliant we
should use read_atomic().
Which makes me wonder if that would be true for other places in the code
as well ...

Another point of confusion may be that read_atomic() on its own does not
seem to be enough here, since we also need the barrier mechanism, maybe
even ACCESS_ONCE. But as I mentioned below this should be covered by the
control flow guarantee is this case.

I wonder if we should brainstorm if the usage of the atomic operations,
the barriers and ACCESS_ONCE is really correct in the current Xen code.
Comparing those to their Linux counterparts at least show some differences.

>> I think the intention of making this read "somewhat special" was to
>> cater for the fact that we write it under the domain lock, but read it
>> here without taking it.
> 
> I haven't looked at the specific of rdists_enabled in this
> implementaion, but be aware that in general writing a variable under a
> lock, and reading it atomically is not safe. You either read and write
> under a lock, or read and write atomically.

Agreed. rdists_enabled may be special here because it's a bool and only
goes from false (initialized value) to true once (there is only one
rdists_enabled assignment, which sets it to true).

>> But I think for this case we don't need any
>> special read version, and anyway an *atomic* read would not help here.
>>
>> What we want is to make sure that rdist_propbase is valid before we see
>> rdists_enabled gets true, this is what this check here is for. This
>> should be solved by a write barrier between the two on the other side.
>>
>> Looking at Linux' memory_barriers.txt my understanding is that the
>> matching barrier on the read side does not necessarily need to be an
>> explicit barrier instruction, it could be a control flow dependency as
>> well. And here we have that: we check rdists_enabled and bail out if
>> it's not set, so neither the compiler nor the CPU can reorder this (as
>> this would violate program semantics).
> 
> I think that this is true.
> 
> 
>> Also rdists_enabled is a bit special in that it never gets reset once it
>> became true, very much like the LPI enablement in the GICv3 spec.
>>
>> So I think we can really go with a normal read plus a comment.
>>
>> Does that make sense?
> 
> The first motivation isn't right, but I think that the latter
> explanation makes sense.

OK, I think I agree with that.

Cheers,
Andre.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v10 25/32] ARM: vITS: handle MAPTI/MAPI command

[Julien Grall]

Hi Andre,

On 07/06/17 18:49, Andre Przywara wrote:
> On 02/06/17 18:12, Julien Grall wrote:
>> On 05/26/2017 06:35 PM, Andre Przywara wrote:
>>> +    /*
>>> +     * radix_tree_insert() returns an error either due to an internal
>>> +     * condition (like memory allocation failure) or because the LPI
>>> already
>>> +     * existed in the tree. We don't support the latter case, so we
>>> always
>>> +     * cleanup and return an error here in any case.
>>> +     */
>>> +out_remove_host_entry:
>>> +    gicv3_remove_guest_event(its->d, its->doorbell_address, devid,
>>> eventid);
>>
>> Can gicv3_remove_guest_event fail? If yes, should we check the
>> return/add comment? If not, then we should have an ASSERT(....).
>
> Well, as we have an "if ( !ret ) return 0;" above, we only get here with
> ret being != 0, so this is in an error path already.
> I am not sure how we should react here then, I think reporting the first
> error is probably more meaningful.

Good point. I missed the if ( !ret ) return 0; in the code.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel