Re: [PATCH v5 09/13] hw/cxl/events: Add qmp interfaces to add/release dynamic capacity extents

[Jonathan Cameron]

On Thu, 25 Apr 2024 10:30:51 -0700
Ira Weiny <ira.weiny@intel.com> wrote:

> Markus Armbruster wrote:
> > fan <nifan.cxl@gmail.com> writes:
> >   
> > > On Wed, Apr 24, 2024 at 03:09:52PM +0200, Markus Armbruster wrote:  
> > >> nifan.cxl@gmail.com writes:
> > >>   
> > >> > From: Fan Ni <fan.ni@samsung.com>
> > >> >
> > >> > Since fabric manager emulation is not supported yet, the change 
> > >> > implements
> > >> > the functions to add/release dynamic capacity extents as QMP 
> > >> > interfaces.  
> > >> 
> > >> Will fabric manager emulation obsolete these commands?  
> > >
> > > If in the future, fabric manager emulation supports commands for dynamic 
> > > capacity
> > > extent add/release, it is possible we do not need the commands.
> > > But it seems not to happen soon, we need the qmp commands for the
> > > end-to-end test with kernel DCD support.  
> > 
> > I asked because if the commands are temporary testing aids, they should
> > probably be declared unstable.  Even if they are permanent testing aids,
> > unstable might be the right choice.  This is for the CXL maintainers to
> > decide.
> > 
> > What does "unstable" mean?  docs/devel/qapi-code-gen.rst: "Interfaces so
> > marked may be withdrawn or changed incompatibly in future releases."
> > 
> > Management applications need stable interfaces.  Libvirt developers
> > generally refuse to touch anything in QMP that's declared unstable.
> > 
> > Human users and their ad hoc scripts appreciate stability, but they
> > don't need it nearly as much as management applications do.
> > 
> > A stability promise increases the maintenance burden.  By how much is
> > unclear.  In other words, by promising stability, the maintainers take
> > on risk.  Are the CXL maintainers happy to accept the risk here?
> >   
> 
> Ah...  All great points.
> 
> Outside of CXL development I don't think there is a strong need for them
> to be stable.  I would like to see more than ad hoc scripts use them
> though.  So I don't think they are going to be changed without some
> thought though.

These align closely with the data that comes from the fabric management
API in the CXL spec.  So I don't see a big maintenance burden problem
in having these as stable interfaces.  Whilst they aren't doing quite
the same job as the FM-API (which will be emulated such that it is
visible to the guest as that aids some other types of testing) that
interface defines the limits on what we can tell the device to do.

So yes, risk for these is minimal and I'm happy to accept that.
It'll be a while before we need libvirt to use them but I do
expect to see that happen. (subject to some guessing on a future
virtualization stack!)

Jonathan



> 
> Ira
> 
> [snip]