public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Pierre Morel <pmorel@linux.ibm.com>
To: Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: Matthew Rosato <mjrosato@linux.ibm.com>,
	linux-s390@vger.kernel.org, alex.williamson@redhat.com,
	cohuck@redhat.com, schnelle@linux.ibm.com, farman@linux.ibm.com,
	borntraeger@linux.ibm.com, hca@linux.ibm.com, gor@linux.ibm.com,
	gerald.schaefer@linux.ibm.com, agordeev@linux.ibm.com,
	frankja@linux.ibm.com, david@redhat.com, vneethv@linux.ibm.com,
	oberpar@linux.ibm.com, freude@linux.ibm.com, thuth@redhat.com,
	pasic@linux.ibm.com, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 12/30] s390/pci: get SHM information from list pci
Date: Thu, 27 Jan 2022 14:41:49 +0100	[thread overview]
Message-ID: <773d3d7c-24a4-fad3-8700-2ecd083a3bad@linux.ibm.com> (raw)
In-Reply-To: <20220126111300.1084623e@p-imbrenda>



On 1/26/22 11:13, Claudio Imbrenda wrote:
> On Tue, 18 Jan 2022 11:36:06 +0100
> Pierre Morel <pmorel@linux.ibm.com> wrote:
> 
>> On 1/14/22 21:31, 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.  Extend clp_list_pci_req to
>>> also fetch the model-dependent-data field that holds this mask.
>>>
>>> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
>>> ---
>>>    arch/s390/include/asm/pci.h     |  1 +
>>>    arch/s390/include/asm/pci_clp.h |  2 +-
>>>    arch/s390/pci/pci_clp.c         | 28 +++++++++++++++++++++++++---
>>>    3 files changed, 27 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
>>> index 00a2c24d6d2b..f3cd2da8128c 100644
>>> --- a/arch/s390/include/asm/pci.h
>>> +++ b/arch/s390/include/asm/pci.h
>>> @@ -227,6 +227,7 @@ int clp_enable_fh(struct zpci_dev *zdev, u32 *fh, u8 nr_dma_as);
>>>    int clp_disable_fh(struct zpci_dev *zdev, u32 *fh);
>>>    int clp_get_state(u32 fid, enum zpci_state *state);
>>>    int clp_refresh_fh(u32 fid, u32 *fh);
>>> +int zpci_get_mdd(u32 *mdd);
>>>    
>>>    /* UID */
>>>    void update_uid_checking(bool new);
>>> diff --git a/arch/s390/include/asm/pci_clp.h b/arch/s390/include/asm/pci_clp.h
>>> index 124fadfb74b9..d6bc324763f3 100644
>>> --- a/arch/s390/include/asm/pci_clp.h
>>> +++ b/arch/s390/include/asm/pci_clp.h
>>> @@ -76,7 +76,7 @@ struct clp_req_list_pci {
>>>    struct clp_rsp_list_pci {
>>>    	struct clp_rsp_hdr hdr;
>>>    	u64 resume_token;
>>> -	u32 reserved2;
>>> +	u32 mdd;
>>>    	u16 max_fn;
>>>    	u8			: 7;
>>>    	u8 uid_checking		: 1;
>>> diff --git a/arch/s390/pci/pci_clp.c b/arch/s390/pci/pci_clp.c
>>> index bc7446566cbc..308ffb93413f 100644
>>> --- a/arch/s390/pci/pci_clp.c
>>> +++ b/arch/s390/pci/pci_clp.c
>>> @@ -328,7 +328,7 @@ int clp_disable_fh(struct zpci_dev *zdev, u32 *fh)
>>>    }
>>>    
>>>    static int clp_list_pci_req(struct clp_req_rsp_list_pci *rrb,
>>> -			    u64 *resume_token, int *nentries)
>>> +			    u64 *resume_token, int *nentries, u32 *mdd)
>>>    {
>>>    	int rc;
>>>    
>>> @@ -354,6 +354,8 @@ static int clp_list_pci_req(struct clp_req_rsp_list_pci *rrb,
>>>    	*nentries = (rrb->response.hdr.len - LIST_PCI_HDR_LEN) /
>>>    		rrb->response.entry_size;
>>>    	*resume_token = rrb->response.resume_token;
>>> +	if (mdd)
>>> +		*mdd = rrb->response.mdd;
>>>    
>>>    	return rc;
>>>    }
>>> @@ -365,7 +367,7 @@ static int clp_list_pci(struct clp_req_rsp_list_pci *rrb, void *data,
>>>    	int nentries, i, rc;
>>>    
>>>    	do {
>>> -		rc = clp_list_pci_req(rrb, &resume_token, &nentries);
>>> +		rc = clp_list_pci_req(rrb, &resume_token, &nentries, NULL);
>>>    		if (rc)
>>>    			return rc;
>>>    		for (i = 0; i < nentries; i++)
>>> @@ -383,7 +385,7 @@ static int clp_find_pci(struct clp_req_rsp_list_pci *rrb, u32 fid,
>>>    	int nentries, i, rc;
>>>    
>>>    	do {
>>> -		rc = clp_list_pci_req(rrb, &resume_token, &nentries);
>>> +		rc = clp_list_pci_req(rrb, &resume_token, &nentries, NULL);
>>>    		if (rc)
>>>    			return rc;
>>>    		fh_list = rrb->response.fh_list;
>>> @@ -468,6 +470,26 @@ int clp_get_state(u32 fid, enum zpci_state *state)
>>>    	return rc;
>>>    }
>>>    
>>> +int zpci_get_mdd(u32 *mdd)
>>> +{
>>> +	struct clp_req_rsp_list_pci *rrb;
>>> +	u64 resume_token = 0;
>>> +	int nentries, rc;
>>> +
>>> +	if (!mdd)
>>> +		return -EINVAL;
>>
>> I think this tests is not useful.
>> The caller must take care not to call with a NULL pointer,
>> what the only caller today make sure.
> 
> what if the caller does it anyway?
> 
> I think the test is useful. if passing NULL is a bug, then maybe
> consider using BUG_ON, or WARN_ONCE

I think generally the caller is responsible for the test.
In our case for example the caller can use directly the address
of a u32 allocated on the stack or globaly and he knows if a test is 
useful or not.

Of course we can systematically check in every kernel function all 
pointer parameters against NULL.
But this is not userland, not even a inter-architecture core function 
and we can expect the kernel programmer to programm correctly.

For our special case zpci_get_mdd() nor clp_list_pci_req() do access 
*mdd if mdd is NULL so that giving a NULL mdd pointer will not trigger a 
fault.
Also, the function is named zpci_get_mdd(u32 *mdd) if the caller do not 
give a pointer to mdd which would be quite stupid to call a function 
zpci_get_mdd() in this circumstance he will just no get mdd, no side effect.
So the only purpose having this test here is to say the caller that he 
forgot to check his mdd allocation.
My opinion is that he should have check.

> 
>>
>>
>>> +
>>> +	rrb = clp_alloc_block(GFP_KERNEL);
>>> +	if (!rrb)
>>> +		return -ENOMEM;
>>> +
>>> +	rc = clp_list_pci_req(rrb, &resume_token, &nentries, mdd);
>>> +
>>> +	clp_free_block(rrb);
>>> +	return rc;
>>> +}
>>> +EXPORT_SYMBOL_GPL(zpci_get_mdd);
>>> +
>>>    static int clp_base_slpc(struct clp_req *req, struct clp_req_rsp_slpc *lpcb)
>>>    {
>>>    	unsigned long limit = PAGE_SIZE - sizeof(lpcb->request);
>>>    
>>
> 

-- 
Pierre Morel
IBM Lab Boeblingen

  reply	other threads:[~2022-01-27 13:40 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-14 20:31 [PATCH v2 00/30] KVM: s390: enable zPCI for interpretive execution Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 01/30] s390/sclp: detect the zPCI load/store interpretation facility Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 02/30] s390/sclp: detect the AISII facility Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 03/30] s390/sclp: detect the AENI facility Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 04/30] s390/sclp: detect the AISI facility Matthew Rosato
2022-01-17  7:57   ` Thomas Huth
2022-01-14 20:31 ` [PATCH v2 05/30] s390/airq: pass more TPI info to airq handlers Matthew Rosato
2022-01-17  8:27   ` Thomas Huth
2022-01-14 20:31 ` [PATCH v2 06/30] s390/airq: allow for airq structure that uses an input vector Matthew Rosato
2022-01-17 12:29   ` Claudio Imbrenda
2022-01-18 18:52     ` Matthew Rosato
2022-01-18  9:50   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 07/30] s390/pci: externalize the SIC operation controls and routine Matthew Rosato
2022-01-17 16:19   ` Niklas Schnelle
2022-01-26 10:07   ` Claudio Imbrenda
2022-01-27  9:57   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 08/30] s390/pci: stash associated GISA designation Matthew Rosato
2022-01-24 14:08   ` Pierre Morel
2022-01-24 15:12     ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 09/30] s390/pci: export some routines related to RPCIT processing Matthew Rosato
2022-01-18  9:51   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 10/30] s390/pci: stash dtsm and maxstbl Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 11/30] s390/pci: add helper function to find device by handle Matthew Rosato
2022-01-18  9:53   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 12/30] s390/pci: get SHM information from list pci Matthew Rosato
2022-01-18 10:36   ` Pierre Morel
2022-01-26 10:13     ` Claudio Imbrenda
2022-01-27 13:41       ` Pierre Morel [this message]
2022-01-27 15:14         ` Matthew Rosato
2022-01-27 10:29   ` Niklas Schnelle
2022-01-14 20:31 ` [PATCH v2 13/30] s390/pci: return status from zpci_refresh_trans Matthew Rosato
2022-01-19 18:13   ` Pierre Morel
2022-01-26 10:45   ` Claudio Imbrenda
2022-01-27 10:30   ` Niklas Schnelle
2022-01-14 20:31 ` [PATCH v2 14/30] KVM: s390: pci: add basic kvm_zdev structure Matthew Rosato
2022-01-17 16:25   ` Pierre Morel
2022-01-18 17:32     ` Pierre Morel
2022-01-18 18:39       ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 15/30] KVM: s390: pci: do initial setup for AEN interpretation Matthew Rosato
2022-01-19 18:06   ` Pierre Morel
2022-01-19 20:19     ` Matthew Rosato
2022-01-25 12:23   ` Pierre Morel
2022-01-25 14:57     ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 16/30] KVM: s390: pci: enable host forwarding of Adapter Event Notifications Matthew Rosato
2022-01-17 17:38   ` Pierre Morel
2022-01-18 17:25     ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 17/30] KVM: s390: mechanism to enable guest zPCI Interpretation Matthew Rosato
2022-01-24 14:24   ` Pierre Morel
2022-01-24 15:28     ` Matthew Rosato
2022-01-24 17:15       ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 18/30] KVM: s390: pci: provide routines for enabling/disabling interpretation Matthew Rosato
2022-01-24 14:36   ` Pierre Morel
2022-01-24 15:14     ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 19/30] KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding Matthew Rosato
2022-01-25 12:41   ` Pierre Morel
2022-01-25 15:44     ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 20/30] KVM: s390: pci: provide routines for enabling/disabling IOAT assist Matthew Rosato
2022-01-25 13:29   ` Pierre Morel
2022-01-25 14:47     ` Matthew Rosato
2022-01-26  8:30       ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 21/30] KVM: s390: pci: handle refresh of PCI translations Matthew Rosato
2022-01-19  9:29   ` Pierre Morel
2022-01-19 16:39     ` Matthew Rosato
2022-01-19 18:25       ` Pierre Morel
2022-01-19 20:02         ` Matthew Rosato
2022-01-20  9:47           ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 22/30] KVM: s390: intercept the rpcit instruction Matthew Rosato
2022-01-18 11:05   ` Pierre Morel
2022-01-18 17:27     ` Matthew Rosato
2022-01-18 17:54       ` Pierre Morel
2022-01-19 14:06   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 23/30] vfio/pci: re-introduce CONFIG_VFIO_PCI_ZDEV Matthew Rosato
2022-01-18 17:20   ` Pierre Morel
2022-01-18 17:32     ` Matthew Rosato
2022-01-18 17:45       ` Pierre Morel
2022-01-18 18:05         ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 24/30] vfio-pci/zdev: wire up group notifier Matthew Rosato
2022-01-18 17:34   ` Pierre Morel
2022-01-18 18:37     ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 25/30] vfio-pci/zdev: wire up zPCI interpretive execution support Matthew Rosato
2022-01-25 13:01   ` Pierre Morel
2022-01-25 14:21     ` Matthew Rosato
2022-01-14 20:31 ` [PATCH v2 26/30] vfio-pci/zdev: wire up zPCI adapter interrupt forwarding support Matthew Rosato
2022-01-19 17:10   ` Pierre Morel
2022-01-19 17:20     ` Matthew Rosato
2022-01-25 12:36   ` Pierre Morel
2022-01-25 14:16     ` Matthew Rosato
2022-01-26  8:24       ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 27/30] vfio-pci/zdev: wire up zPCI IOAT assist support Matthew Rosato
2022-01-19 14:03   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 28/30] vfio-pci/zdev: add DTSM to clp group capability Matthew Rosato
2022-01-19 13:48   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 29/30] KVM: s390: introduce CPU feature for zPCI Interpretation Matthew Rosato
2022-01-19 13:39   ` Pierre Morel
2022-01-14 20:31 ` [PATCH v2 30/30] MAINTAINERS: additional files related kvm s390 pci passthrough Matthew Rosato
2022-01-14 20:49 ` [PATCH v2 00/30] KVM: s390: enable zPCI for interpretive execution Matthew Rosato
2022-01-19 18:10 ` Pierre Morel

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=773d3d7c-24a4-fad3-8700-2ecd083a3bad@linux.ibm.com \
    --to=pmorel@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=alex.williamson@redhat.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=farman@linux.ibm.com \
    --cc=frankja@linux.ibm.com \
    --cc=freude@linux.ibm.com \
    --cc=gerald.schaefer@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mjrosato@linux.ibm.com \
    --cc=oberpar@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=schnelle@linux.ibm.com \
    --cc=thuth@redhat.com \
    --cc=vneethv@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