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