[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH v8 01/27] ARM: GICv3: propagate number of host LPIs to GICv3 guest
Hi Andre,
On 12/04/17 01:44, 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).
DOM0 number should be derived from the limitation provided by the user
(i.e lpi_data.max_host_lpi_ids) and not directly from the hardware.
Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx>
---
xen/arch/arm/gic-v3.c | 6 +++++-
xen/arch/arm/vgic-v3.c | 7 ++++++-
xen/include/asm-arm/domain.h | 1 +
xen/include/asm-arm/vgic.h | 3 ++-
4 files changed, 14 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);
This only works for DOM0, I would expect the number of the guest to come
up from the toolstack. You may want to have a look to
xen_arch_domain_config. This is not necessary for this version (*hint*
this should be listed in the list of TODO in the cover letter *hint*).
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..ebcca22 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;
So intid_bits is based on what the hardware report, however Xen may not
use ITS. So I would have expected this number to be derived from what is
actually exposed to the domain. For DOM0 it would be the number of LPIs
supported in Xen (e.g lpi_data.max_host_lpi_ids) if ITS is enabled.
Looking at the code (patch #12), you are only using intid_bits when ITS
is enabled which is really surprising as this value should be correct
even though LPIs are not used by DOM0.
}
else
{
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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|