Re: [Xen-devel] [PATCH v9 3/6] sysctl / libxl: report whether IOMMU/HAP page table sharing is supported

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: 12 September 2019 14:28
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: JulienGrall <julien.grall@xxxxxxx>; Andrew Cooper 
> <Andrew.Cooper3@xxxxxxxxxx>; Anthony Perard
> <anthony.perard@xxxxxxxxxx>; Christian Lindig <christian.lindig@xxxxxxxxxx>; 
> George Dunlap
> <George.Dunlap@xxxxxxxxxx>; Ian Jackson <Ian.Jackson@xxxxxxxxxx>; Stefano 
> Stabellini
> <sstabellini@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx; Konrad Rzeszutek 
> Wilk
> <konrad.wilk@xxxxxxxxxx>; DavidScott <dave@xxxxxxxxxx>; Tim (Xen.org) 
> <tim@xxxxxxx>; Wei Liu
> <wl@xxxxxxx>
> Subject: Re: [PATCH v9 3/6] sysctl / libxl: report whether IOMMU/HAP page 
> table sharing is supported
> 
> On 12.09.2019 15:18, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@xxxxxxxx>
> >> Sent: 12 September 2019 14:04
> >> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> >> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Julien Grall <julien.grall@xxxxxxx>; 
> >> Andrew Cooper
> >> <Andrew.Cooper3@xxxxxxxxxx>; Anthony Perard <anthony.perard@xxxxxxxxxx>; 
> >> Christian Lindig
> >> <christian.lindig@xxxxxxxxxx>; George Dunlap <George.Dunlap@xxxxxxxxxx>; 
> >> Ian Jackson
> >> <Ian.Jackson@xxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>; 
> >> Konrad Rzeszutek Wilk
> >> <konrad.wilk@xxxxxxxxxx>; DavidScott <dave@xxxxxxxxxx>; Tim (Xen.org) 
> >> <tim@xxxxxxx>; Wei Liu
> >> <wl@xxxxxxx>
> >> Subject: Re: [PATCH v9 3/6] sysctl / libxl: report whether IOMMU/HAP page 
> >> table sharing is
> supported
> >>
> >> On 12.09.2019 13:17, Paul Durrant wrote:
> >>> --- a/xen/arch/arm/sysctl.c
> >>> +++ b/xen/arch/arm/sysctl.c
> >>> @@ -15,6 +15,9 @@
> >>>  void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
> >>>  {
> >>>      pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm | XEN_SYSCTL_PHYSCAP_hap;
> >>> +
> >>> +    if ( iommu_enabled && iommu_hap_pt_share )
> >>> +        pi->capabilities |= XEN_SYSCTL_PHYSCAP_iommu_hap_pt_share;
> >>>  }
> >>
> >> I think this should be done in common code.
> >>
> >>> --- a/xen/arch/x86/sysctl.c
> >>> +++ b/xen/arch/x86/sysctl.c
> >>> @@ -164,7 +164,12 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
> >>>      if ( IS_ENABLED(CONFIG_PV) )
> >>>          pi->capabilities |= XEN_SYSCTL_PHYSCAP_pv;
> >>>      if ( hvm_hap_supported() )
> >>> +    {
> >>>          pi->capabilities |= XEN_SYSCTL_PHYSCAP_hap;
> >>> +
> >>> +        if ( iommu_enabled && iommu_hap_pt_share )
> >>> +            pi->capabilities |= XEN_SYSCTL_PHYSCAP_iommu_hap_pt_share;
> >>> +    }
> >>>  }
> >>
> >> And if it's important to not have the bit set when !hvm_hap_supported(),
> >
> > ...and that's what it’s not in common code... there is no 
> > hvm_hap_supported() for Arm
> >
> >> then iommu_hap_pt_share should be cleared in __init code in this case.
> >
> > That would have been an alternative approach if you'd not wanted
> > it #defined in patch #5. (Yes it's a later patch in the series,
> > but this one is later chronologically and I didn't want to
> > invalidate the other patch.)
> > I could perhaps implement hvm_hap_supported() for Arm?
> 
> Well, implementing it for Arm is an option (at which point
> XEN_SYSCTL_PHYSCAP_hap could also move to common code). But
> personally I'd advise against providing more stubs than
> necessary on Arm. I may not understand your remark regarding
> patch 5: There's no problem with iommu_hap_pt_share now being
> a #define on Arm - whether the system is HVM capable is an
> x86 specific decision anyway, and hence the clearing of the
> flag could occur e.g. in hvm_enable() when it bails early.
> And btw., with !CONFIG_HVM it could be a #define on x86 as
> well, just to "false" then.

Ok, I had assumed you meant to clear it common code too. But, yes, clearing it 
in x86 code would indeed work and I'll see about the !CONFIG_HVM definition.

  Paul

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