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

Re: [Xen-devel] [PATCH for-next RFC 6/8] x86: make probe_xen return boolean value



On Mon, Sep 23, 2019 at 11:09:29AM +0100, Wei Liu wrote:
> We need indication whether it has succeeded or not.
> 
> Signed-off-by: Wei Liu <liuwe@xxxxxxxxxxxxx>

The code LGTM, I have just a suggestion on the approach.

> ---
>  xen/arch/x86/guest/hypervisor.c | 5 ++++-
>  xen/arch/x86/guest/xen/xen.c    | 7 ++++---
>  xen/include/asm-x86/guest/xen.h | 4 ++--
>  3 files changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/x86/guest/hypervisor.c b/xen/arch/x86/guest/hypervisor.c
> index b0a724bf13..fb572b0402 100644
> --- a/xen/arch/x86/guest/hypervisor.c
> +++ b/xen/arch/x86/guest/hypervisor.c
> @@ -34,7 +34,10 @@ void __init probe_hypervisor(void)
>      if ( !(cpuid_ecx(1) & cpufeat_mask(X86_FEATURE_HYPERVISOR)) )
>          return;
>  
> -    probe_xen();
> +    if ( probe_xen() )
> +        return;
> +
> +    /* Hyper-V probing to follow. */

Instead of having to append a new probe_foo here every time support for
running on a new hypervisor is added, you could do something similar
to what's done in REGISTER_VPCI_INIT, where each hypervisor would
register it's own set of helpers and probe function in a specific
section, and then you would just iterate over all the guest support
that's compiled in Xen.

That would also prevent you from having to export a dummy probe_xen
helper if CONFIG_XEN_GUEST is not defined.

Anyway, maybe that's overkill...

Thanks, Roger.

_______________________________________________
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®.