Re: [PATCH v4 4/4] hw/i386/sgx: Attach SGX-EPC objects to machine

[Igor Mammedov]

On Mon, 14 Feb 2022 14:58:57 +0800
Yang Zhong <yang.zhong@intel.com> wrote:

> On Mon, Feb 07, 2022 at 09:37:52AM +0100, Igor Mammedov wrote:
> > On Sat,  5 Feb 2022 13:45:26 +0100
> > Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> >   
> > > Previously SGX-EPC objects were exposed in the QOM tree at a path
> > > 
> > >   /machine/unattached/device[nn]
> > > 
> > > where the 'nn' varies depending on what devices were already created.
> > > 
> > > With this change the SGX-EPC objects are now at
> > > 
> > >   /machine/sgx-epc[nn]
> > > 
> > > where the 'nn' of the first SGX-EPC object is always zero.  
> > 
> > yet again, why it's necessary?  
> 
> 
>   Igor, Sorry for delay feedback because of Chinese New Year holiday.
> 
>   This series patches are to fix below issues I reported before,
>   https://lists.nongnu.org/archive/html/qemu-devel/2021-11/msg05670.html
> 
>   Since the /machine/unattached/device[0] is used by vcpu and Libvirt
>   use this interface to get unavailable-features list. But in the SGX
>   VM, the device[0] will be occupied by virtual sgx epc device, Libvirt
>   can't get unavailable-features from this device[0].
> 
>   Although patch 2 in this series already fixed "unavailable-features" issue,

I've seen patches on libvirt fixing "unavailable-features" in another way
without dependence on  /machine/unattached/device[0].
see:
 https://www.mail-archive.com/libvir-list@redhat.com/msg226244.html

>   this patch can move sgx virtual device from /machine/unattached/device[nn]
>   to /machine/sgx-epc[nn], which seems more clear. Thanks!

with those patches device[0] becomes non issue, and this patch also becomes
unnecessary.
I don't mind putting sgx-epc under machine, but that shall be justified
somehow. A drawback I noticed in this case is an extra manual
plumbing/wiring without apparent need for it.

PS:
general note on submitting patches.
Commit message shall
 1 describe problem (+error message/way to reproduce the issue)
 2 what patch does
 3 and why patch fixes the issue in a certain way

commit message in this patch only does #2,  without any clue
to what the problem was nor why it tries to fix it this way.

> 
>   Yang
>   
> 
> >   
> > > 
> > > Reported-by: Yang Zhong <yang.zhong@intel.com>
> > > Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
> > > Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> > > Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> > > ---
> > >  hw/i386/sgx.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/hw/i386/sgx.c b/hw/i386/sgx.c
> > > index a2b318dd938..3ab2217ca43 100644
> > > --- a/hw/i386/sgx.c
> > > +++ b/hw/i386/sgx.c
> > > @@ -304,6 +304,8 @@ void pc_machine_init_sgx_epc(PCMachineState *pcms)
> > >      for (list = x86ms->sgx_epc_list; list; list = list->next) {
> > >          obj = object_new("sgx-epc");
> > >  
> > > +        object_property_add_child(OBJECT(pcms), "sgx-epc[*]", 
> > > OBJECT(obj));
> > > +
> > >          /* set the memdev link with memory backend */
> > >          object_property_parse(obj, SGX_EPC_MEMDEV_PROP, 
> > > list->value->memdev,
> > >                                &error_fatal);  
>