[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9787a083-1271-85e5-b356-a35a549abfca@linux.ibm.com>
Date: Thu, 9 Dec 2021 13:25:18 -0500
From: Matthew Rosato <mjrosato@...ux.ibm.com>
To: Niklas Schnelle <schnelle@...ux.ibm.com>,
linux-s390@...r.kernel.org
Cc: alex.williamson@...hat.com, cohuck@...hat.com,
farman@...ux.ibm.com, pmorel@...ux.ibm.com,
borntraeger@...ux.ibm.com, hca@...ux.ibm.com, gor@...ux.ibm.com,
gerald.schaefer@...ux.ibm.com, agordeev@...ux.ibm.com,
frankja@...ux.ibm.com, david@...hat.com, imbrenda@...ux.ibm.com,
vneethv@...ux.ibm.com, oberpar@...ux.ibm.com, freude@...ux.ibm.com,
thuth@...hat.com, pasic@...ux.ibm.com, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 12/32] s390/pci: get SHM information from list pci
On 12/8/21 7:21 AM, Niklas Schnelle wrote:
> On Tue, 2021-12-07 at 15:57 -0500, Matthew Rosato wrote:
>> KVM will need information on the special handle mask used to indicate
>> emulated devices. In order to obtain this, a new type of list pci call
>> must be made to gather the information. Remove the unused data pointer
>> from clp_list_pci and __clp_add and instead optionally pass a pointer to
>> a model-dependent-data field. Additionally, allow for clp_list_pci calls
>> that don't specify a callback - in this case, just do the first pass of
>> list pci and exit.
>>
>> Signed-off-by: Matthew Rosato <mjrosato@...ux.ibm.com>
>> ---
>> arch/s390/include/asm/pci.h | 6 ++++++
>> arch/s390/include/asm/pci_clp.h | 2 +-
>> arch/s390/pci/pci.c | 19 +++++++++++++++++++
>> arch/s390/pci/pci_clp.c | 16 ++++++++++------
>> 4 files changed, 36 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
>> index 00a2c24d6d2b..86f43644756d 100644
>> --- a/arch/s390/include/asm/pci.h
>> +++ b/arch/s390/include/asm/pci.h
>> @@ -219,12 +219,18 @@ int zpci_unregister_ioat(struct zpci_dev *, u8);
>> void zpci_remove_reserved_devices(void);
>> void zpci_update_fh(struct zpci_dev *zdev, u32 fh);
>>
> ---8<---
>> -static int clp_list_pci(struct clp_req_rsp_list_pci *rrb, void *data,
>> - void (*cb)(struct clp_fh_list_entry *, void *))
>> +int clp_list_pci(struct clp_req_rsp_list_pci *rrb, u32 *mdd,
>> + void (*cb)(struct clp_fh_list_entry *))
>> {
>> u64 resume_token = 0;
>> int nentries, i, rc;
>> @@ -368,8 +368,12 @@ static int clp_list_pci(struct clp_req_rsp_list_pci *rrb, void *data,
>> rc = clp_list_pci_req(rrb, &resume_token, &nentries);
>> if (rc)
>> return rc;
>> + if (mdd)
>> + *mdd = rrb->response.mdd;
>> + if (!cb)
>> + return 0;
>
> I think it would be slightly cleaner to instead de-static
> clp_list_pci_req() and call that directly. Just because that makes the
> clp_list_pci() still list all PCI functions and allows us to get rid of
> the data parameter completely.
>
Oops, I must have missed this comment before. Sure, makes sense.
> Also, I've been thinking about moving clp_scan_devices(),
> clp_get_state(), and clp_refresh_fh() out of pci_clp.c because they are
> higher level. I think that would nicely fit your zpci_get_mdd() in
> pci.c with or without the above suggestion. Then we could do the
> removal of the unused data parameter in that series as a cleanup. What
> do you think?
Sure, that would be fine. So then this patch instead just exports
alloc/free/clp_list_pci_req and the new zpci_get_mdd calls
clp_list_pci_req directly. I'll drop the changes to clp_list_pci() and
__clp_add (and re-word the commit message)
>
>> for (i = 0; i < nentries; i++)
>> - cb(&rrb->response.fh_list[i], data);
>> + cb(&rrb->response.fh_list[i]);
>> } while (resume_token);
>>
>> return rc;
>> @@ -398,7 +402,7 @@ static int clp_find_pci(struct clp_req_rsp_list_pci *rrb, u32 fid,
>> return -ENODEV;
>> }
>>
>> -static void __clp_add(struct clp_fh_list_entry *entry, void *data)
>> +static void __clp_add(struct clp_fh_list_entry *entry)
>> {
>> struct zpci_dev *zdev;
>>
>
Powered by blists - more mailing lists