|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 05/13] x86/altp2m: basic data structures and support routines.
>>> On 01.07.15 at 20:09, <edmund.h.white@xxxxxxxxx> wrote:
> ---
> xen/arch/x86/hvm/Makefile | 1 +
> xen/arch/x86/hvm/altp2m.c | 92 +++++++++++++++++++++++++++++++++++++
Wouldn't this better go into xen/arch/x86/mm/?
> +int
> +altp2m_vcpu_initialise(struct vcpu *v)
> +{
> + int rc = -EOPNOTSUPP;
> +
> + if ( v != current )
> + vcpu_pause(v);
> +
> + if ( !hvm_funcs.ap2m_vcpu_initialise ||
> + (hvm_funcs.ap2m_vcpu_initialise(v) == 0) )
> + {
> + rc = 0;
I think you would better honor the error code returned by
hvm_funcs.ap2m_vcpu_initialise() and enter this block only if it
was zero.
> + altp2m_vcpu_reset(v);
> + vcpu_altp2m(v).p2midx = 0;
> + atomic_inc(&p2m_get_altp2m(v)->active_vcpus);
> +
> + ap2m_vcpu_update_eptp(v);
We're in vendor independent code here - either the function is
misnamed, or it shouldn't be called directly from here.
> +void
> +altp2m_vcpu_destroy(struct vcpu *v)
> +{
> + struct p2m_domain *p2m;
> +
> + if ( v != current )
> + vcpu_pause(v);
> +
> + if ( hvm_funcs.ap2m_vcpu_destroy )
> + hvm_funcs.ap2m_vcpu_destroy(v);
> +
> + if ( (p2m = p2m_get_altp2m(v)) )
> + atomic_dec(&p2m->active_vcpus);
The ordering looks odd - from an abstract perspective I'd expect
p2m_get_altp2m() to not return the p2m anymore that was just
destroyed via hvm_funcs.ap2m_vcpu_destroy().
> +void ap2m_vcpu_update_eptp(struct vcpu *v)
> +{
As I think I said before, I consider these ap2m_ prefixes ambiguous -
the 'a' could also stand for accelerated, advanced, ... Consistently
staying with altp2m_ would seem better.
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -459,7 +459,7 @@ void hap_domain_init(struct domain *d)
> int hap_enable(struct domain *d, u32 mode)
> {
> unsigned int old_pages;
> - uint8_t i;
> + uint16_t i;
unsigned int (also elsewhere, including uint8_t-s)
> @@ -498,6 +498,24 @@ int hap_enable(struct domain *d, u32 mode)
> goto out;
> }
>
> + /* Init alternate p2m data */
> + if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
> + {
> + rv = -ENOMEM;
> + goto out;
> + }
> +
> + for (i = 0; i < MAX_EPTP; i++)
> + d->arch.altp2m_eptp[i] = INVALID_MFN;
The above again seems EPT-specific in a vendor independent file.
> @@ -196,7 +234,14 @@ int p2m_init(struct domain *d)
> * (p2m_init runs too early for HVM_PARAM_* options) */
> rc = p2m_init_nestedp2m(d);
> if ( rc )
> + {
> p2m_teardown_hostp2m(d);
> + return rc;
> + }
> +
> + rc = p2m_init_altp2m(d);
> + if ( rc )
> + p2m_teardown_altp2m(d);
>
> return rc;
> }
And why not also p2m_teardown_hostp2m() in this last error case?
And doesn't p2m_init_nestedp2m() need undoing too? (Overall this
suggests the error cleanup structuring here should be changed.)
> @@ -294,6 +298,12 @@ struct arch_domain
> struct p2m_domain *nested_p2m[MAX_NESTEDP2M];
> mm_lock_t nested_p2m_lock;
>
> + /* altp2m: allow multiple copies of host p2m */
> + bool_t altp2m_active;
> + struct p2m_domain *altp2m_p2m[MAX_ALTP2M];
> + mm_lock_t altp2m_lock;
> + uint64_t *altp2m_eptp;
This is a non-insignificant increase of the structure size - perhaps all
of these should hang off of struct arch_domain via a single,
separately allocated pointer?
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -210,6 +210,14 @@ struct hvm_function_table {
> uint32_t *ecx, uint32_t *edx);
>
> void (*enable_msr_exit_interception)(struct domain *d);
> +
> + /* Alternate p2m */
> + int (*ap2m_vcpu_initialise)(struct vcpu *v);
> + void (*ap2m_vcpu_destroy)(struct vcpu *v);
> + int (*ap2m_vcpu_reset)(struct vcpu *v);
Why is this returning int when altp2m_vcpu_reset() returns void?
> +static inline struct p2m_domain *p2m_get_altp2m(struct vcpu *v)
> +{
> + struct domain *d = v->domain;
> + uint16_t index = vcpu_altp2m(v).p2midx;
> +
> + return (index == INVALID_ALTP2M) ? NULL : d->arch.altp2m_p2m[index];
It would feel better if you checked against MAX_ALTP2M here.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |