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

Re: [PATCH v5 07/11] xen/domctl: Introduce XEN_DOMCTL_CDF_vpci flag



On Wed, 13 Oct 2021, Stefano Stabellini wrote:
> On Wed, 13 Oct 2021, Roger Pau Monné wrote:
> > > I think the second solution is the right one but it cannot be done so 
> > > near from the
> > > feature freeze.
> > > 
> > > The CDF flag as introduced right now is not creating any issue and will 
> > > be used once
> > > the emulation flag will be introduce. We will be able at this stage to 
> > > set this properly
> > > also on x86 (for dom0 pvh).
> > > Moreover keeping it will allow to continue to merge the remaining part of 
> > > the PCI
> > > passthrough which are otherwise not possible to be done as they are 
> > > dependent on this flag.
> > > 
> > > Can we agree on keep the DOMCTL_CDF_vpci flag and introduce the emulation
> > > flag on Arm after 4.16 release ?
> > 
> > If vPCI for Arm on 4.16 is not going to be functional, why so much
> > pressure in pushing those patches so fast? I understand the need to
> > remove stuff from the queue, but I don't think it's worth the cost of
> > introducing a broken interface deliberately on a release.
> > 
> > I think we need to at least settle on whether we want to keep
> > CDF_vpci or use an arch specific signal mechanism in order to decide
> > what to do regarding the release.
> 
> I wrote a longer separate email to provide more context about the
> "pushing fast" comment.
> 
> I agree that we don't want to introduce a bad interface.
> 
> In regards to a way forward for 4.16, my suggestion is the following:
> 
> - revert this patch: do not change the interface in this series
>     - do not change anything related to CDF_vpci for x86
>     - for ARM, leave has_vpci(d) to { false } and do not set
>       XEN_DOMCTL_CDF_vpci
>     - we can discuss it in depth later on, no rush
> 
> - in patch #10, in libxl_arm.c:libxl__arch_domain_prepare_config
>     - do not set XEN_DOMCTL_CDF_vpci
>     - do not set b_info.arch_arm.vpci
>     - do not define LIBXL_HAVE_BUILDINFO_ARM_VPCI in libxl.h
>     - keep make_vpci_node and arch_arm.vpci
> 
> 
> The other patches (#1, #8, #10), which don't change any interfaces, can
> still make it for 4.16 if the review feedback is addressed on time, with
> one open TODO item [1].
> 
> This way, we get all the essential infrastructure we are trying to
> introduce without making any compromises on the external interfaces.
> Still it is good to have patches #1 #8 #10 so that with a trival
> oneliner patch on top of 4.16 we can enable PCI for ARM and do testing
> in the community, in gitlab-ci, and OSSTest too. (We have been
> discussing special OSSTest flights to valide PCI passthrough as we
> complete development.)

One more thing: I would really like to get at least patch #8 committed
because it would help with making progress with part 2 and part 3 of the
PCI enablement series. My preference would also be to get #1 and #10
in as well but I feel less strongly about it.

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.