Re: [PATCH v2 17/23] x86/mm: put paging_update_nestedmode under CONFIG_HVM

[Wei Liu <wei.liu2@citrix.com>]

On Thu, Aug 30, 2018 at 02:35:37AM -0600, Jan Beulich wrote:
> >>> On 30.08.18 at 09:42, <wei.liu2@citrix.com> wrote:
> > On Tue, Aug 28, 2018 at 04:50:21AM -0600, Jan Beulich wrote:
> >> >>> On 26.08.18 at 14:19, <wei.liu2@citrix.com> wrote:
> >> > --- a/xen/arch/x86/mm/paging.c
> >> > +++ b/xen/arch/x86/mm/paging.c
> >> > @@ -919,6 +919,7 @@ const struct paging_mode *paging_get_mode(struct vcpu 
> > *v)
> >> >      return paging_get_nestedmode(v);
> >> >  }
> >> >  
> >> > +#ifdef CONFIG_HVM
> >> >  void paging_update_nestedmode(struct vcpu *v)
> >> >  {
> >> >      ASSERT(nestedhvm_enabled(v->domain));
> >> > @@ -930,6 +931,7 @@ void paging_update_nestedmode(struct vcpu *v)
> >> >          v->arch.paging.nestedmode = NULL;
> >> >      hvm_asid_flush_vcpu(v);
> >> >  }
> >> > +#endif
> >> 
> >> Just a consideration (no objection): Would it be worthwhile to
> >> introduce CONFIG_NESTED_HVM at the same time (for now hard
> >> coded to Y, and of course depending on HVM) to avoid having to
> >> touch all such places a second time later on?
> > 
> > If we plan to make nested hvm configurable in the future, that would be
> > a worthwhile thing to do; otherwise it is just another concept that
> > users need to care about, which creates some mental burden.
> 
> Andrew, do you have any opinion / preference either way?

I discussed this with Andrew on IRC and came to the conclusion it is not
worth it to introduce CONFIG_NESTED_HVM, because:

1. Nested virt will become commonplace for Xen.
2. Trying to split nested parts from non-nested parts will be massively
   complicated.

Wei.

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