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

Re: [Xen-devel] [PATCH 9/9] x86: move declaration of arch_set_info_hvm_guest and provide stub



>>> On 07.08.18 at 12:00, <wei.liu2@xxxxxxxxxx> wrote:
> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -34,6 +34,7 @@
>  #include <public/hvm/save.h>
>  #include <public/hvm/hvm_op.h>
>  #include <public/hvm/dm_op.h>
> +#include <public/hvm/hvm_vcpu.h>

Why? struct vcpu_hvm_context only needs a forward declaration, just
like was the case originally. Full structure/union definitions are needed
only if you de-reference the type, instantiate it, or apply sizeof() and
alike to it.

In fact I suspect we could reduce header dependencies quite a bit if
we followed that model more widely.

> @@ -204,6 +205,22 @@ struct hvm_domain {
>  
>  #define hap_enabled(d)  ((d)->arch.hvm_domain.hap_enabled)
>  
> +#if CONFIG_HVM
> +
> +int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context 
> *ctx);
> +
> +#else
> +
> +#include <xen/errno.h>
> +
> +static inline
> +int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context 
> *ctx)
> +{
> +    return -EINVAL;
> +}
> +
> +#endif

All uses sit either in HVM-specific code or inside is_hvm_...()
conditionals: Why do we need the inline stub? If the declaration
was visible independent of CONFIG_HVM, code would compile
fine, and references to the function would be removed by the
compiler, so linking would also succeed despite there not being
any definition of the function.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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