Re: qemu-system-x86_64 appears to have sgx-epc, but not memory-backend-epc

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Oct 23, 2026 at 12:50:24PM +0100, Peter Maydell wrote:
> On Fri, 23 Oct 2026 at 12:08, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > The memory backends are all implementing the UserCreatable
> > interface, which provides a "complete" method where they
> > could gracefully report lack of the feature via 'errp'.
> 
> I didn't realize UserCreatable was a thing. It seems unfortunate
> that we have accumulated three different kinds of object
> creation/destruction life cycle:
> 
> - instance_init / instance_finalize

This is all stuff that is supposed to be basic self contanied
initialization/cleanup with no side effects or dependencies,
and impossible to fail, which is pretty clear semantics.
During init, no external properties have been set yet, and
during finalize it is already disconnected from the QOM tree.
Essentially these should be basic memory allocs/free, mutex
inits/destroys, setting default int values if non-zero, etc.

> - instance_init / realize / unrealize / instance_finalize
> - instance_init / complete / prepare_delete / instance_finalize

These two have clear overlap in that they both take place after
user specified properties have been set, and deal with types of
initialization/setup/cleanup that can fail and have external
depedencies.

UserCreatable has another aspect in that it is the witness
flag for whether a QOM type is permissible to create using
-object / object_add.

I've periodically wondered if we could make them the same, but
the realize/unrealize phases have significantly more complexity
and dependancies than the complete/prepare_delete and most
notably, 'realize' has a 'bus' parameter.

I think that an approach to unification would end up with the
'Device' class implementing UserCreatable and providing a
'complete' method which in turn called the 'realize' method.
IOW, nothing much would really change in terms of impls, as
all Device subclasses would carry on using realize/unrealize.
It would merely make Device tree available to -object/object_add.
There are probably quite a few edge case problems hiding in
there though if one were to actually try to do this, so the
pragmatic option is really to ignore this all and accept the
different APIs for Device vs non-Device QOM.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|