[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v8 14/27] ARM: vITS: introduce translation table walks



On 12/04/17 14:36, Andre Przywara wrote:
Hi,

On 12/04/17 14:22, Julien Grall wrote:


On 12/04/17 01:44, 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@xxxxxxx>
---
 xen/arch/arm/vgic-v3-its.c | 183
+++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 183 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index a60f9b2..632ab84 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -78,6 +78,7 @@ struct vits_itte
     uint16_t pad;
 };

+#define UNMAPPED_COLLECTION      ((uint16_t)~0)

On v5 (patch #28), I asked to minimize the use of uint16_t (resp.
uint64_t) when it refers to collection (resp. ITTE). But it sounds like
you missed again that point.

Well, I introduced that below, just failed to use it *everywhere*.

...


 #define GITS_BASER_RO_MASK       (GITS_BASER_TYPE_MASK | \
                                   (31UL << GITS_BASER_ENTRY_SIZE_SHIFT))

@@ -94,6 +95,188 @@ void vgic_v3_its_free_domain(struct domain *d)
     ASSERT(RB_EMPTY_ROOT(&d->arch.vgic.its_devices));
 }

+/*
+ * 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);
+}
+
+/*
+ * Our collection table encoding:
+ * Just contains the 16-bit VCPU ID of the respective vCPU.
+ */
+#define COLL_TABLE_ENTRY_SIZE 2UL

...             (here)

+
+/* 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);
+    uint16_t vcpu_id;

I don't see any BUILD_BUG_ON making sure you can store a vCPU ID in
uint16_t.

+    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(uint16_t),
+                                   &vcpu_id, sizeof(vcpu_id), false);

Minimizing the use of uint16_t will likely make this code less confusing
to read as it mixes sizeof(vcpu_id) and sizeof(uint16_t).

The idea here is to use the actual type of the variable used instead of
putting an explicit type in here, since this can get out of sync.

So would a typedef meet your expectations?

        typedef uint16_t coll_table_entry_t;
        typedef uint64_t dev_table_entry_t;

And then use that throughout the code?

Yes please.

Cheers,

--
Julien Grall

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.