Il mer 2 lug 2025, 09:25 Xiaoyao Li <xiaoyao...@intel.com> ha scritto:
> IIRC that's on rhel QEMU which ports the TDX code before it's merged > upstream. Now TDX is upstreamed, it works with upstream compat property > and I think future new compat property won't affect TDX or anything, > since it's compat property and it's to guarantee the existing behavior > when introducing new behavior? > It's a compat property that is only added by RHEL-specific machine types. But the bug is not specific to RHEL, it just happens that no upstream machine type has compat properties that overlap with TDX adjustments of CPUID. > In general I don't see how the reverse order makes sense: the subclass > > knows what the superclass does, so it can do the right thing if it runs > > last; but the superclass cannot know what all of its subclasses do in > > post_init, so it makes less sense to run it last. > > I agree in general the parent to child order makes more sense, > especially when we treat .instance_init() as the phase 1 init and > .post_instance_init() as the phase 2 init. > > But the original purpose of introducing .post_instance_init() was to > ensure qdev_prop_set_globals() is called at last for Device. Reverse the > order breaks this purpose. > Not "last", but "after instance_init". Anything that happens in the child class's instance_post_init can be moved at the end of instance_init, just like the refactoring that I did for risc-v. Paolo It seems not good option like the reversed order from child to parent > that can achieve it by just putting the last step in top parent's. > > I'm looking forward to seeing a better solution. > > > Paolo > > > > > >> So I think we might revert this patch, and document clearly the reverse > >> order of .post_instance_init() callback. > >> > >>> X86 CPUs have the issue (e.g., "vendor" doesn't work) now because > >>> they - as leaf class, don't care about the property values of > >>> superclass - the DeviceState. If a property is just for initialization, > >>> like "vendor", it should be placed in the instance_init() instead of > >>> instance_post_init(). > >>> > >>> In addition, if other places handle it similarly, the device's > >>> post_init seems pointless. :-( > >>> > >>> Thanks, > >>> Zhao > >>> > >> > >> > > > >
