Re: [Xen-devel] [PATCH 34/34] RFC x86: introduce directio virt cap

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.08.18 at 15:43, <wei.liu2@xxxxxxxxxx> wrote:
> On Tue, Aug 21, 2018 at 05:52:39AM -0600, Jan Beulich wrote:
>> >>> On 17.08.18 at 17:12, <wei.liu2@xxxxxxxxxx> wrote:
>> > --- a/xen/arch/x86/sysctl.c
>> > +++ b/xen/arch/x86/sysctl.c
>> > @@ -92,8 +92,10 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
>> >             min(sizeof(pi->hw_cap), sizeof(boot_cpu_data.x86_capability)));
>> >      if ( hvm_enabled )
>> >          pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
>> > -    if ( iommu_enabled )
>> > +    if ( hvm_enabled && iommu_enabled )
>> >          pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm_directio;
>> > +    else if ( iommu_enabled )
>> > +        pi->capabilities |= XEN_SYSCTL_PHYSCAP_directio;
>> >  }
>> 
>> At the sysctl layer I think you can, as suggested iirc by Roger,
>> simply replace hvm_directio with directio (or iommu). For the
>> "xl info" output, otoh, I'm afraid this doesn't hold, as people
>> may parse for the string. Depending on how this would best
>> be addressed in the tool stack, replacing the sysctl names may
>> then no longer be the most suitable solution.
> 
> In that case what do you think about the two flags this patch provides
> on the toolstack level?
> 
> Essentially we change slightly hvm_directio's meaning to mean "hvm &&
> iommu_enabled" while it previously mean "iommu_enabled", and then in the
> absence of hvm_directio, add "directio" as an indication for
> "iommu_enabled".

I think when you mean to provide two flags, retaining the meaning
of the pre-existing one might be desirable. But as said before -
much depends on what the tool stack means to present to the user.
The expectations on the current meaning on "xl info" output should
not be broken.

Jan



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