qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Rosato <mjrosato@linux.ibm.com>
To: Thomas Huth <thuth@redhat.com>, cohuck@redhat.com
Cc: walling@linux.ibm.com, pmorel@linux.ibm.com, mst@redhat.com,
	qemu-s390x@nongnu.org, david@redhat.com, qemu-devel@nongnu.org,
	pasic@linux.ibm.com, borntraeger@de.ibm.com,
	alex.williamson@redhat.com, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Qemu-devel] [qemu-s390x] [PATCH v3 3/5] s390: vfio_pci: Use a PCI Group structure
Date: Mon, 9 Sep 2019 12:21:15 -0400	[thread overview]
Message-ID: <8fec5bce-7408-05e4-9726-9e2fd531cccb@linux.ibm.com> (raw)
In-Reply-To: <0c29ba98-d404-d570-d1c0-5d1a3750f6ad@redhat.com>

On 9/9/19 1:18 AM, Thomas Huth wrote:
> On 07/09/2019 02.16, Matthew Rosato wrote:
>> From: Pierre Morel <pmorel@linux.ibm.com>
>>
>> We use a S390PCIGroup structure to hold the information
>> related to zPCI Function group.
>>
>> This allows us to be ready to support multiple groups and to retrieve
>> the group information from the host.
>>
>> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
>> ---
>>  hw/s390x/s390-pci-bus.c  | 42 ++++++++++++++++++++++++++++++++++++++++++
>>  hw/s390x/s390-pci-bus.h  | 11 ++++++++++-
>>  hw/s390x/s390-pci-inst.c | 22 +++++++++++++---------
>>  3 files changed, 65 insertions(+), 10 deletions(-)
>>
>> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
>> index 963a41c..e625217 100644
>> --- a/hw/s390x/s390-pci-bus.c
>> +++ b/hw/s390x/s390-pci-bus.c
>> @@ -730,6 +730,46 @@ static void s390_pci_iommu_free(S390pciState *s, PCIBus *bus, int32_t devfn)
>>      object_unref(OBJECT(iommu));
>>  }
>>  
>> +static S390PCIGroup *s390_grp_create(int ug)
>> +{
>> +    S390PCIGroup *grp;
>> +    S390pciState *s = s390_get_phb();
>> +
>> +    grp = g_new0(S390PCIGroup, 1);
>> +    grp->ug = ug;
>> +    QTAILQ_INSERT_TAIL(&s->zpci_grps, grp, link);
>> +    return grp;
>> +}
> 
> Maybe an ignorant question, but shouldn't there also be some kind of
> clean up function that also frees the memory again, e.g. during a
> machine reset? Or are these groups supposed to survive a machine reset?

Hmm..  Well, I think it is in line with the way the devices themselves
are handled during reset (they are not removed during a reset unless
there was a pending unplug and their info persists).  But you have a
point in that it seems sketchy to leave the group information around,
particularly in cases where the last device associated with the group
has been unplugged.

So yes, I think there is some work to be done here.  I need to
investigate whether a precautionary wiping of the list (minus the
default group) at machine reset is really good enough or whether we need
to remove group info sooner (device unplug).

Thanks,
Matt


  reply	other threads:[~2019-09-09 16:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-07  0:16 [Qemu-devel] [PATCH v3 0/5] Retrieving zPCI specific info from QEMU Matthew Rosato
2019-09-07  0:16 ` [Qemu-devel] [PATCH v3 1/5] vfio: vfio_iommu_type1: linux header place holder Matthew Rosato
2019-09-08 13:08   ` Michael S. Tsirkin
2019-09-07  0:16 ` [Qemu-devel] [PATCH v3 2/5] s390: PCI: Creation a header dedicated to PCI CLP Matthew Rosato
2019-09-07  0:16 ` [Qemu-devel] [PATCH v3 3/5] s390: vfio_pci: Use a PCI Group structure Matthew Rosato
2019-09-09  5:18   ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2019-09-09 16:21     ` Matthew Rosato [this message]
2019-09-07  0:16 ` [Qemu-devel] [PATCH v3 4/5] s390: vfio_pci: Use a PCI Function structure Matthew Rosato
2019-09-07  0:16 ` [Qemu-devel] [PATCH v3 5/5] s390: vfio_pci: Get zPCI function info from host Matthew Rosato

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8fec5bce-7408-05e4-9726-9e2fd531cccb@linux.ibm.com \
    --to=mjrosato@linux.ibm.com \
    --cc=alex.williamson@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=mst@redhat.com \
    --cc=pasic@linux.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=pmorel@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=thuth@redhat.com \
    --cc=walling@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).