[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |