linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Elliot Berman <quic_eberman@quicinc.com>
To: Alex Elder <elder@linaro.org>,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>
Cc: Murali Nalajala <quic_mnalajal@quicinc.com>,
	Trilok Soni <quic_tsoni@quicinc.com>,
	Srivatsa Vaddagiri <quic_svaddagi@quicinc.com>,
	Carl van Schaik <quic_cvanscha@quicinc.com>,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Bjorn Andersson <andersson@kernel.org>,
	"Konrad Dybcio" <konrad.dybcio@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Bagas Sanjaya <bagasdotme@gmail.com>,
	Will Deacon <will@kernel.org>, Andy Gross <agross@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Jassi Brar <jassisinghbrar@gmail.com>,
	<linux-arm-msm@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <linux-doc@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v13 09/24] gunyah: rsc_mgr: Add RPC for sharing memory
Date: Fri, 9 Jun 2023 15:35:31 -0700	[thread overview]
Message-ID: <d31ac48b-13d3-cb9c-7a59-220b31a89274@quicinc.com> (raw)
In-Reply-To: <9747a71d-c6d0-b67b-a3b1-c84848268f46@linaro.org>



On 6/5/2023 12:48 PM, Alex Elder wrote:
> On 5/9/23 3:47 PM, Elliot Berman wrote: >> +
>> +    req_header->mem_handle = cpu_to_le32(mem_handle);
>> +    if (end_append)
>> +        req_header->flags |= GH_MEM_APPEND_REQ_FLAGS_END;
>> +
>> +    mem_section->n_entries = cpu_to_le16(n_mem_entries);
>> +    memcpy(mem_section->entries, mem_entries, sizeof(*mem_entries) * 
>> n_mem_entries);
>> +
>> +    ret = gh_rm_call(rm, GH_RM_RPC_MEM_APPEND, msg, msg_size, NULL, 
>> NULL);
>> +    kfree(msg);
>> +
>> +    return ret;
>> +}
>> +
>> +static int gh_rm_mem_append(struct gh_rm *rm, u32 mem_handle,
>> +            struct gh_rm_mem_entry *mem_entries, size_t n_mem_entries)
>> +{
>> +    bool end_append;
>> +    int ret = 0;
>> +    size_t n;
>> +
>> +    while (n_mem_entries) {
>> +        if (n_mem_entries > GH_RM_MAX_MEM_ENTRIES) {
>> +            end_append = false;
>> +            n = GH_RM_MAX_MEM_ENTRIES;
>> +        } else {
>> +            end_append = true;
>> +            n = n_mem_entries;
>> +        }
>> +
>> +        ret = _gh_rm_mem_append(rm, mem_handle, end_append, 
>> mem_entries, n);
>> +        if (ret)
>> +            break;
>> +
>> +        mem_entries += n;
>> +        n_mem_entries -= n;
>> +    }
>> +
>> +    return ret;
>> +}
>> +
>> +static int gh_rm_mem_lend_common(struct gh_rm *rm, u32 message_id, 
>> struct gh_rm_mem_parcel *p)
>> +{
>> +    size_t msg_size = 0, initial_mem_entries = p->n_mem_entries, 
>> resp_size;
>> +    size_t acl_section_size, mem_section_size;
>> +    struct gh_rm_mem_share_req_acl_section *acl_section;
>> +    struct gh_rm_mem_share_req_mem_section *mem_section;
>> +    struct gh_rm_mem_share_req_header *req_header;
>> +    u32 *attr_section;
>> +    __le32 *resp;
>> +    void *msg;
>> +    int ret;
>> +
>> +    if (!p->acl_entries || !p->n_acl_entries || !p->mem_entries || 
>> !p->n_mem_entries ||
>> +        p->n_acl_entries > U8_MAX || p->mem_handle != 
>> GH_MEM_HANDLE_INVAL)
>> +        return -EINVAL;
>> +
>> +    if (initial_mem_entries > GH_RM_MAX_MEM_ENTRIES)
>> +        initial_mem_entries = GH_RM_MAX_MEM_ENTRIES;
> 
> Is it OK to truncate the number of entries silently?
> 

The initial share/lend accepts GH_RM_MAX_MEM_ENTRIES. I append the rest 
of the mem entries later.

>> +
>> +    acl_section_size = struct_size(acl_section, entries, 
>> p->n_acl_entries);
> 
> Is there a limit on the number of ACL entries (as there is for
> the number of mem entries).
> 

There is limit based at the transport level -- messages sent to resource 
manager can only be so long. Max # ACL entries limit is dynamic based on 
the size of the rest of the message such as how many mem entries there 
are. We could try to compute the limit and even lower max number of 
mem_entries, but max # of ACL entries in practice will single digits so 
it seemed premature optimization to be "smarter" about the limit and let 
the RPC core do the checking/complaining.

>> +    mem_section_size = struct_size(mem_section, entries, 
>> initial_mem_entries);
>> +    /* The format of the message goes:
>> +     * request header
>> +     * ACL entries (which VMs get what kind of access to this memory 
>> parcel)
>> +     * Memory entries (list of memory regions to share)
>> +     * Memory attributes (currently unused, we'll hard-code the size 
>> to 0)
>> +     */
>> +    msg_size += sizeof(struct gh_rm_mem_share_req_header);
>> +    msg_size += acl_section_size;
>> +    msg_size += mem_section_size;
>> +    msg_size += sizeof(u32); /* for memory attributes, currently 
>> unused */
>> +
>> +    msg = kzalloc(msg_size, GFP_KERNEL);
>> +    if (!msg)
>> +        return -ENOMEM;
>> +
>> +    req_header = msg;
>> +    acl_section = (void *)req_header + sizeof(*req_header);
>> +    mem_section = (void *)acl_section + acl_section_size;
>> +    attr_section = (void *)mem_section + mem_section_size;
>> +
>> +    req_header->mem_type = p->mem_type;
>> +    if (initial_mem_entries != p->n_mem_entries)
>> +        req_header->flags |= GH_MEM_SHARE_REQ_FLAGS_APPEND;
>> +    req_header->label = cpu_to_le32(p->label);
>> +
>> +    acl_section->n_entries = cpu_to_le32(p->n_acl_entries);
>> +    memcpy(acl_section->entries, p->acl_entries,
>> +        flex_array_size(acl_section, entries, p->n_acl_entries));
>> +
>> +    mem_section->n_entries = cpu_to_le16(initial_mem_entries);
>> +    memcpy(mem_section->entries, p->mem_entries,
>> +        flex_array_size(mem_section, entries, initial_mem_entries));
>> +
>> +    /* Set n_entries for memory attribute section to 0 */
>> +    *attr_section = 0;
>> +
>> +    ret = gh_rm_call(rm, message_id, msg, msg_size, (void **)&resp, 
>> &resp_size);
>> +    kfree(msg);
>> +
>> +    if (ret)
>> +        return ret;
>> +
>> +    p->mem_handle = le32_to_cpu(*resp);
>> +    kfree(resp);
>> +
>> +    if (initial_mem_entries != p->n_mem_entries) {
>> +        ret = gh_rm_mem_append(rm, p->mem_handle,
>> +                    &p->mem_entries[initial_mem_entries],
>> +                    p->n_mem_entries - initial_mem_entries);
> 
> Will there always be at most one gh_rm_mem_append() call?
> 

Yes, gh_rm_mem_append makes multiple RPC calls as necessary for all the 
remaining entries.

>> +        if (ret) {
>> +            gh_rm_mem_reclaim(rm, p);
>> +            p->mem_handle = GH_MEM_HANDLE_INVAL;
>> +        }
>> +    }
>> +
>> +    return ret;
>> +}
> 
> . . .
> 

  reply	other threads:[~2023-06-09 22:35 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-09 20:47 [PATCH v13 00/24] Drivers for Gunyah hypervisor Elliot Berman
2023-05-09 20:47 ` [PATCH v13 01/24] dt-bindings: Add binding for gunyah hypervisor Elliot Berman
2023-06-05 19:47   ` Alex Elder
2023-05-09 20:47 ` [PATCH v13 02/24] gunyah: Common types and error codes for Gunyah hypercalls Elliot Berman
2023-06-05 19:47   ` Alex Elder
2023-06-05 21:31   ` Srinivas Kandagatla
2023-05-09 20:47 ` [PATCH v13 03/24] virt: gunyah: Add hypercalls to identify Gunyah Elliot Berman
2023-06-05 19:47   ` Alex Elder
2023-05-09 20:47 ` [PATCH v13 04/24] virt: gunyah: msgq: Add hypercalls to send and receive messages Elliot Berman
2023-06-05 19:47   ` Alex Elder
2023-06-05 21:31   ` Srinivas Kandagatla
2023-05-09 20:47 ` [PATCH v13 05/24] mailbox: Add Gunyah message queue mailbox Elliot Berman
2023-05-24  6:29   ` Dmitry Baryshkov
2023-06-05 19:47   ` Alex Elder
2023-06-05 21:32   ` Srinivas Kandagatla
2023-05-09 20:47 ` [PATCH v13 06/24] gunyah: rsc_mgr: Add resource manager RPC core Elliot Berman
2023-06-05 19:47   ` Alex Elder
2023-06-06 12:45   ` Srinivas Kandagatla
2023-05-09 20:47 ` [PATCH v13 07/24] gunyah: rsc_mgr: Add VM lifecycle RPC Elliot Berman
2023-06-05 19:47   ` Alex Elder
2023-06-06 12:49   ` Srinivas Kandagatla
2023-05-09 20:47 ` [PATCH v13 08/24] gunyah: vm_mgr: Introduce basic VM Manager Elliot Berman
2023-06-05 19:47   ` Alex Elder
2023-06-06 12:51   ` Srinivas Kandagatla
2023-05-09 20:47 ` [PATCH v13 09/24] gunyah: rsc_mgr: Add RPC for sharing memory Elliot Berman
2023-06-05 19:48   ` Alex Elder
2023-06-09 22:35     ` Elliot Berman [this message]
2023-06-06 13:35   ` Srinivas Kandagatla
2023-05-09 20:47 ` [PATCH v13 10/24] gunyah: vm_mgr: Add/remove user memory regions Elliot Berman
2023-05-19 11:59   ` Will Deacon
2023-05-19 17:02     ` Elliot Berman
2023-06-05 14:18       ` Will Deacon
2023-06-07 15:54         ` Elliot Berman
2023-06-22 23:56           ` Elliot Berman
2023-07-13 20:28             ` Elliot Berman
2023-07-14 12:13               ` Will Deacon
2023-07-19  2:28                 ` Elliot Berman
2023-07-20 10:39                   ` Will Deacon
2023-06-13 17:54         ` Elliot Berman
2023-06-05 19:48   ` Alex Elder
2023-05-09 20:47 ` [PATCH v13 11/24] gunyah: vm_mgr: Add ioctls to support basic non-proxy VM boot Elliot Berman
2023-06-05 19:48   ` Alex Elder
2023-05-09 20:47 ` [PATCH v13 12/24] samples: Add sample userspace Gunyah VM Manager Elliot Berman
2023-06-05 19:48   ` Alex Elder
2023-05-09 20:47 ` [PATCH v13 13/24] gunyah: rsc_mgr: Add platform ops on mem_lend/mem_reclaim Elliot Berman
2023-06-05 19:48   ` Alex Elder
2023-05-09 20:47 ` [PATCH v13 14/24] virt: gunyah: Add Qualcomm Gunyah platform ops Elliot Berman
2023-06-05 19:48   ` Alex Elder
2023-06-07 15:55     ` Elliot Berman
2023-05-09 20:47 ` [PATCH v13 15/24] docs: gunyah: Document Gunyah VM Manager Elliot Berman
2023-06-05 19:49   ` Alex Elder
2023-05-09 20:47 ` [PATCH v13 16/24] virt: gunyah: Translate gh_rm_hyp_resource into gunyah_resource Elliot Berman
2023-06-05 19:49   ` Alex Elder
2023-06-09 20:00     ` Elliot Berman
2023-05-09 20:47 ` [PATCH v13 17/24] gunyah: vm_mgr: Add framework for VM Functions Elliot Berman
2023-06-05 19:49   ` Alex Elder
2023-06-09 19:49     ` Elliot Berman
2023-06-12 12:57       ` Alex Elder
2023-05-09 20:47 ` [PATCH v13 18/24] virt: gunyah: Add resource tickets Elliot Berman
2023-06-05 19:49   ` Alex Elder
2023-05-09 20:47 ` [PATCH v13 19/24] virt: gunyah: Add IO handlers Elliot Berman
2023-06-05 19:50   ` Alex Elder
2023-05-09 20:47 ` [PATCH v13 20/24] virt: gunyah: Add proxy-scheduled vCPUs Elliot Berman
2023-06-05 19:50   ` Alex Elder
2023-05-09 20:47 ` [PATCH v13 21/24] virt: gunyah: Add hypercalls for sending doorbell Elliot Berman
2023-06-05 19:50   ` Alex Elder
2023-05-09 20:47 ` [PATCH v13 22/24] virt: gunyah: Add irqfd interface Elliot Berman
2023-06-05 19:50   ` Alex Elder
2023-06-09 18:22     ` Elliot Berman
2023-06-09 18:28       ` Alex Elder
2023-05-09 20:48 ` [PATCH v13 23/24] virt: gunyah: Add ioeventfd Elliot Berman
2023-06-05 19:50   ` Alex Elder
2023-06-09 17:33     ` Elliot Berman
2023-06-09 17:46       ` Alex Elder
2023-05-09 20:48 ` [PATCH v13 24/24] MAINTAINERS: Add Gunyah hypervisor drivers section Elliot Berman
2023-06-05 19:50   ` Alex Elder
2023-05-24  6:47 ` [PATCH v13 00/24] Drivers for Gunyah hypervisor Dmitry Baryshkov
2023-05-24 17:13 ` Alex Bennée
2023-06-13 23:02   ` Elliot Berman
2023-06-05 19:47 ` Alex Elder

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=d31ac48b-13d3-cb9c-7a59-220b31a89274@quicinc.com \
    --to=quic_eberman@quicinc.com \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bagasdotme@gmail.com \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=elder@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jassisinghbrar@gmail.com \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_cvanscha@quicinc.com \
    --cc=quic_mnalajal@quicinc.com \
    --cc=quic_pheragu@quicinc.com \
    --cc=quic_svaddagi@quicinc.com \
    --cc=quic_tsoni@quicinc.com \
    --cc=robh+dt@kernel.org \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=will@kernel.org \
    /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).