On Mon, 14 Feb 2022 14:58:57 +0800 Yang Zhong <yang.zh...@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é <f4...@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.zh...@intel.com> > > > Suggested-by: Paolo Bonzini <pbonz...@redhat.com> > > > Reviewed-by: Daniel P. Berrangé <berra...@redhat.com> > > > Signed-off-by: Philippe Mathieu-Daudé <f4...@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); >