|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC 15/16] xen/arm: Implement Set/Way operations
On Mon, 5 Nov 2018, Julien Grall wrote:
> > > +void p2m_set_way_flush(struct vcpu *v)
> > > +{
> > > + /* This function can only work with the current vCPU. */
> > > + ASSERT(v == current);
> >
> > NIT: if it can only operate on current, it makes sense to remove the
> > struct vcpu* parameter
>
> I prefer to keep struct vcpu *v here. This makes more straightforward to know
> on what the function is working on.
>
> Furthermore, current is actually quite expensive to use in some circumstance.
>
> For instance, in nested case, TPIDR_EL2 will get trapped to the host
> hypervisor.
>
> So it would be best if we start avoid current whenever it is possible.
That's OK
> >
> >
> > > + if ( !(v->arch.hcr_el2 & HCR_TVM) )
> > > + {
> > > + p2m_flush_vm(v);
> > > + vcpu_hcr_set_flags(v, HCR_TVM);
> > > + }
> > > +}
> > > +
> > > +void p2m_toggle_cache(struct vcpu *v, bool was_enabled)
> > > +{
> > > + bool now_enabled = vcpu_has_cache_enabled(v);
> > > +
> > > + /* This function can only work with the current vCPU. */
> > > + ASSERT(v == current);
> >
> > NIT: same about struct vcpu* as parameter when only current can be used
> >
> >
> > > + /*
> > > + * If switching the MMU+caches on, need to invalidate the caches.
> > > + * If switching it off, need to clean the caches.
> > > + * Clean + invalidate does the trick always.
> > > + */
> > > + if ( was_enabled != now_enabled )
> > > + p2m_flush_vm(v);
> > > +
> > > + /* Caches are now on, stop trapping VM ops (until a S/W op) */
> > > + if ( now_enabled )
> > > + vcpu_hcr_clear_flags(v, HCR_TVM);
> > > +}
> > > +
> > > mfn_t gfn_to_mfn(struct domain *d, gfn_t gfn)
> > > {
> > > return p2m_lookup(d, gfn, NULL);
> > > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > > index 169b57cb6b..cdc10eee5a 100644
> > > --- a/xen/arch/arm/traps.c
> > > +++ b/xen/arch/arm/traps.c
> > > @@ -98,7 +98,7 @@ register_t get_default_hcr_flags(void)
> > > {
> > > return (HCR_PTW|HCR_BSU_INNER|HCR_AMO|HCR_IMO|HCR_FMO|HCR_VM|
> > > (vwfi != NATIVE ? (HCR_TWI|HCR_TWE) : 0) |
> > > - HCR_TSC|HCR_TAC|HCR_SWIO|HCR_TIDCP|HCR_FB);
> > > + HCR_TSC|HCR_TAC|HCR_SWIO|HCR_TIDCP|HCR_FB|HCR_TSW);
> > > }
> > > static enum {
> > > diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
> > > index 49529b97cd..dc46d9d0d7 100644
> > > --- a/xen/arch/arm/vcpreg.c
> > > +++ b/xen/arch/arm/vcpreg.c
> > > @@ -45,9 +45,14 @@
> > > #define TVM_REG(sz, func, reg...)
> > > \
> > > static bool func(struct cpu_user_regs *regs, uint##sz##_t *r, bool read)
> > > \
> > > {
> > > \
> > > + struct vcpu *v = current;
> > > \
> > > + bool cache_enabled = vcpu_has_cache_enabled(v);
> > > \
> > > +
> > > \
> > > GUEST_BUG_ON(read);
> > > \
> > > WRITE_SYSREG##sz(*r, reg);
> > > \
> > >
> > > \
> > > + p2m_toggle_cache(v, cache_enabled);
> > > \
> >
> > This will affect all the registers trapped with TVM. Shouldn't we only
> > call p2m_toggle_cache when relevant? i.e. when changing SCTLR?
> > I think it would be better to only modify the SCTLR emulation handler.
>
> This is made on purpose, you increase the chance to disable TVM as soon as
> possible. If you only rely on SCTLR, you may end up to trap a lot of registers
> for a long time.
>
> FWIW, as I already wrote in the commit message, this is based on what KVM
> does.
I missed that. As you explain it, it makes sense. Maybe worth adding an
explicit statement about it: "On ARM64, we call p2m_toggle_cache from on
the TVM-trapped register handlers to increase the chances of disabling
TVM as soon as possible."
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |