linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Elliot Berman <quic_eberman@quicinc.com>
To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	Bjorn Andersson <quic_bjorande@quicinc.com>,
	Alex Elder <elder@linaro.org>,
	Murali Nalajala <quic_mnalajal@quicinc.com>,
	Jassi Brar <jassisinghbrar@gmail.com>
Cc: Trilok Soni <quic_tsoni@quicinc.com>,
	Srivatsa Vaddagiri <quic_svaddagi@quicinc.com>,
	Carl van Schaik <quic_cvanscha@quicinc.com>,
	Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>,
	Dmitry Baryshkov <dmitry.baryshkov@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>,
	Bagas Sanjaya <bagasdotme@gmail.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
	Sudeep Holla <sudeep.holla@arm.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 v9 08/27] mailbox: Add Gunyah message queue mailbox
Date: Wed, 8 Feb 2023 12:46:35 -0800	[thread overview]
Message-ID: <bc274d7c-4c69-25a8-7463-de3c36e36ac8@quicinc.com> (raw)
In-Reply-To: <e5acd00c-7a53-a789-8dab-a69cffda34f5@linaro.org>



On 2/2/2023 1:59 AM, Srinivas Kandagatla wrote:
> 
> 
> On 20/01/2023 22:46, Elliot Berman wrote:
>> Gunyah message queues are a unidirectional inter-VM pipe for messages up
>> to 1024 bytes. This driver supports pairing a receiver message queue and
>> a transmitter message queue to expose a single mailbox channel.
>>
>> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
>> ---

[snip]

>> +static irqreturn_t gh_msgq_rx_irq_handler(int irq, void *data)
>> +{
>> +    struct gh_msgq *msgq = data;
>> +    struct gh_msgq_rx_data rx_data;
>> +    unsigned long gh_err;
>> +    bool ready = true;
>> +
>> +    while (ready) {
>> +        gh_err = gh_hypercall_msgq_recv(msgq->rx_ghrsc->capid,
>> +                (uintptr_t)&rx_data.data, sizeof(rx_data.data),
> you should proabably use  GH_MSGQ_MAX_MSG_SIZE instead of calling sizeof 
> for every loop.
> 
>> +                &rx_data.length, &ready);
>> +        if (gh_err == GH_ERROR_OK) {
>> +            mbox_chan_received_data(gh_msgq_chan(msgq), &rx_data);
>> +        } else if (gh_err == GH_ERROR_MSGQUEUE_EMPTY) {
>> +            break;
>> +        } else {
>> +            pr_warn("Failed to receive data from msgq for %s: %zd\n",
>> +                msgq->mbox.dev ? dev_name(msgq->mbox.dev) : "", gh_err);
>> +            break;
>> +        }
>> +    }
>> +
>> +    return IRQ_HANDLED;
>> +}
> How about making this more readable.
> also use of gh_ in local variables is not really adding any value.
> > while (ready) {
>      err = gh_hypercall_msgq_recv(...);
>      if (err) {
>          if (err != GH_ERROR_MSGQUEUE_EMPTY)
>                      dev_warn(msgq->mbox.dev, "Failedto receive data 
> %zd\n", err);
>                  break;
> 
>                 }
>      mbox_chan_received_data(gh_msgq_chan(msgq), &rx_data);
> }
> 
> 

Done

>> +
>> +static irqreturn_t gh_msgq_tx_irq_handler(int irq, void *data)
>> +{
>> +    struct gh_msgq *msgq = data;
>> +
>> +    mbox_chan_txdone(gh_msgq_chan(msgq), 0);
> What is this irq for? Is it for tx done ack?
> 

This IRQ is asserted when the message queue transitions from "full" to 
"space available". For mailbox framework, it is tx done ack.

>> +
>> +    return IRQ_HANDLED;
>> +}
>> +
>> +static void gh_msgq_txdone_tasklet(struct tasklet_struct *tasklet)
>> +{
>> +    struct gh_msgq *msgq = container_of(tasklet, struct gh_msgq, 
>> txdone_tasklet);
>> +
>> +    mbox_chan_txdone(gh_msgq_chan(msgq), msgq->last_ret);
>> +}
>> +
>> +static int gh_msgq_send_data(struct mbox_chan *chan, void *data)
>> +{
>> +    struct gh_msgq *msgq = mbox_chan_to_msgq(chan);
>> +    struct gh_msgq_tx_data *msgq_data = data;
>> +    u64 tx_flags = 0;
>> +    unsigned long ret;
>> +    bool ready;
>> +
>> +    if (msgq_data->push)
>> +        tx_flags |= GH_HYPERCALL_MSGQ_TX_FLAGS_PUSH;
>> +
>> +    ret = gh_hypercall_msgq_send(msgq->tx_ghrsc->capid, 
>> msgq_data->length,
>> +                    (uintptr_t)msgq_data->data, tx_flags, &ready);
>> +
>> +    /**
>> +     * unlikely because Linux tracks state of msgq and should not try to
>> +     * send message when msgq is full.
>> +     */
>> +    if (unlikely(ret == GH_ERROR_MSGQUEUE_FULL))
>> +        return -EAGAIN;
>> +
>> +    /**
>> +     * Propagate all other errors to client. If we return error to 
>> mailbox
>> +     * framework, then no other messages can be sent and nobody will 
>> know
>> +     * to retry this message.
>> +     */
>> +    msgq->last_ret = gh_remap_error(ret);
>> +
>> +    /**
>> +     * This message was successfully sent, but message queue isn't 
>> ready to
>> +     * receive more messages because it's now full.Mailbox framework
>> +     * requires that we only report that message was transmitted when
>> +     * we're ready to transmit another message. We'll get that in the 
>> form
>> +     * of tx IRQ once the other side starts to drain the msgq.
>> +     */
>> +    if (ret == GH_ERROR_OK && !ready)
>> +        return 0;
>> +
>> +    /**
>> +     * We can send more messages. Mailbox frameworkrequires that tx 
>> done
>> +     * happens asynchronously to sending the message. Gunyah message 
>> queues
>> +     * tell us right away on the hypercall return whether we can send 
>> more
>> +     * messages. To work around this, defer the txdone to a tasklet.
>> +     */
>> +    tasklet_schedule(&msgq->txdone_tasklet);
>> +
>> +    return 0;
>> +}
>> +
>> +static struct mbox_chan_ops gh_msgq_ops = {
>> +    .send_data = gh_msgq_send_data,
>> +};
>> +
>> +/**
>> + * gh_msgq_init() - Initialize a Gunyah message queue with an 
>> mbox_client
>> + * @parent: optional, device parent used for the mailbox controller
>> + * @msgq: Pointer to the gh_msgq to initialize
>> + * @cl: A mailbox client to bind to the mailbox channel that the 
>> message queue creates
>> + * @tx_ghrsc: optional, the transmission side of the message queue
>> + * @rx_ghrsc: optional, the receiving side of the message queue
>> + *
>> + * At least one of tx_ghrsc and rx_ghrsc should be not NULL. Most 
>> message queue use cases come with
>> + * a pair of message queues to facilitate bidirectional 
>> communication. When tx_ghrsc is set,
>> + * the client can send messages with 
>> mbox_send_message(gh_msgq_chan(msgq), msg). When rx_ghrsc
>> + * is set, the mbox_client should register an .rx_callback() and the 
>> message queue driver will
>> + * push all available messages upon receiving the RX ready interrupt. 
>> The messages should be
>> + * consumed or copied by the client right away as the gh_msgq_rx_data 
>> will be replaced/destroyed
>> + * after the callback.
>> + *
>> + * Returns - 0 on success, negative otherwise
>> + */
>> +int gh_msgq_init(struct device *parent, struct gh_msgq *msgq, struct 
>> mbox_client *cl,
>> +             struct gunyah_resource *tx_ghrsc, struct gunyah_resource 
>> *rx_ghrsc)
>> +{
>> +    int ret;
>> +
>> +    /* Must have at least a tx_ghrsc or rx_ghrsc and that they are 
>> the right device types */
>> +    if ((!tx_ghrsc && !rx_ghrsc) ||
>> +        (tx_ghrsc && tx_ghrsc->type != GUNYAH_RESOURCE_TYPE_MSGQ_TX) ||
>> +        (rx_ghrsc && rx_ghrsc->type != GUNYAH_RESOURCE_TYPE_MSGQ_RX))
>> +        return -EINVAL;
>> +
>> +    if (gh_api_version() != GUNYAH_API_V1) {
>> +        pr_warn("Unrecognized gunyahversion: %u. Currently 
>> supported: %d\n",
>> +            gh_api_version(), GUNYAH_API_V1);
> how about using dev_err here?
> 
>> +        return -ENODEV;
> 
> -EOPNOTSUPP?
> 

Done.

>> +    }
>> +
>> +    if (!gh_api_has_feature(GH_API_FEATURE_MSGQUEUE))
>> +        return -EOPNOTSUPP;
>> +
>> +    msgq->tx_ghrsc = tx_ghrsc;
>> +    msgq->rx_ghrsc = rx_ghrsc;
>> +
>> +    msgq->mbox.dev = parent;
>> +    msgq->mbox.ops = &gh_msgq_ops;
>> +    msgq->mbox.num_chans = 1;
>> +    msgq->mbox.chans = kcalloc(msgq->mbox.num_chans, 
>> sizeof(*msgq->mbox.chans), GFP_KERNEL);
>> +    if (!msgq->mbox.chans)
>> +        return -ENOMEM;
> 
> new line here would be nice.
>> +    msgq->mbox.txdone_irq = true;
>> +
>> +    if (msgq->tx_ghrsc) {
>> +        ret = request_irq(msgq->tx_ghrsc->irq, 
>> gh_msgq_tx_irq_handler, 0, "gh_msgq_tx",
>> +                msgq);
>> +        if (ret)
>> +            gotoerr_chans;
>> +    }
>> +
>> +    if (msgq->rx_ghrsc) {
>> +        ret = request_threaded_irq(msgq->rx_ghrsc->irq, NULL, 
>> gh_msgq_rx_irq_handler,
>> +                        IRQF_ONESHOT, "gh_msgq_rx", msgq);
>> +        if (ret)
>> +            gotoerr_tx_irq;
>> +    }
>> +
>> +    tasklet_setup(&msgq->txdone_tasklet, gh_msgq_txdone_tasklet);
> 
> AFAIU, this looks like duplicating what core already has with 
> TXDONE_BY_POLL.
> 
> can we not use
> txdone_poll = true
> and implement last_tx_done callback to use hrtimer from the core to tick 
> tx.
> 

The TXDONE_BY_POLL suits when message queue is immediately ready to 
receive more data. In the other case, we have an interrupt to indicate 
when it can receive more data and the poll doesn't make sense. IMO, the 
IRQ handler should immediately tick the mailbox controller and I don't 
know a way to do that if using TXDONE_BY_POLL -- there isn't an 
interface to reset the timer and mbox_chan_done() only works with 
TXDONE_BY_IRQ.

Thanks,
Elliot

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2023-02-08 20:47 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-20 22:45 [PATCH v9 00/27] Drivers for gunyah hypervisor Elliot Berman
2023-01-20 22:46 ` [PATCH v9 01/27] docs: gunyah: Introduce Gunyah Hypervisor Elliot Berman
2023-01-20 22:46 ` [PATCH v9 02/27] dt-bindings: Add binding for gunyah hypervisor Elliot Berman
2023-01-20 22:46 ` [PATCH v9 03/27] gunyah: Common types and error codes for Gunyah hypercalls Elliot Berman
2023-01-30  9:58   ` Greg Kroah-Hartman
2023-01-20 22:46 ` [PATCH v9 04/27] virt: gunyah: Add hypercalls to identify Gunyah Elliot Berman
2023-01-30 10:01   ` Greg Kroah-Hartman
2023-01-30 19:05     ` Elliot Berman
2023-01-20 22:46 ` [PATCH v9 05/27] virt: gunyah: Identify hypervisor version Elliot Berman
2023-01-20 22:46 ` [PATCH v9 06/27] mailbox: Allow direct registration to a channel Elliot Berman
2023-01-20 22:46 ` [PATCH v9 07/27] virt: gunyah: msgq: Add hypercalls to send and receive messages Elliot Berman
2023-01-31 16:16   ` Srinivas Kandagatla
2023-01-20 22:46 ` [PATCH v9 08/27] mailbox: Add Gunyah message queue mailbox Elliot Berman
2023-02-02  9:59   ` Srinivas Kandagatla
2023-02-06 14:00     ` Alex Elder
2023-02-08 20:46     ` Elliot Berman [this message]
2023-01-20 22:46 ` [PATCH v9 09/27] gunyah: rsc_mgr: Add resource manager RPC core Elliot Berman
2023-02-02 11:53   ` Srinivas Kandagatla
2023-02-06 14:14     ` Alex Elder
2023-01-20 22:46 ` [PATCH v9 10/27] gunyah: rsc_mgr: Add VM lifecycle RPC Elliot Berman
2023-01-25  6:12   ` Srivatsa Vaddagiri
2023-01-30 21:43     ` Elliot Berman
2023-02-02 12:46   ` Srinivas Kandagatla
2023-02-06 15:41     ` Alex Elder
2023-02-06 17:38       ` Elliot Berman
2023-01-20 22:46 ` [PATCH v9 11/27] gunyah: vm_mgr: Introduce basic VM Manager Elliot Berman
2023-02-02 12:54   ` Srinivas Kandagatla
2023-02-07  0:36     ` Elliot Berman
2023-01-20 22:46 ` [PATCH v9 12/27] gunyah: rsc_mgr: Add RPC for sharing memory Elliot Berman
2023-01-30 10:14   ` Srivatsa Vaddagiri
2023-01-30 21:45     ` Elliot Berman
2023-01-20 22:46 ` [PATCH v9 13/27] gunyah: vm_mgr: Add/remove user memory regions Elliot Berman
2023-01-25 13:34   ` Srivatsa Vaddagiri
2023-01-30 21:46     ` Elliot Berman
2023-02-06 16:12   ` Srinivas Kandagatla
2023-02-06 23:23     ` Elliot Berman
2023-01-20 22:46 ` [PATCH v9 14/27] gunyah: vm_mgr: Add ioctls to support basic non-proxy VM boot Elliot Berman
2023-01-30  8:53   ` Srivatsa Vaddagiri
2023-01-30 21:44     ` Elliot Berman
2023-01-30 21:45       ` Elliot Berman
2023-02-07 11:36   ` Srinivas Kandagatla
2023-02-08 21:04     ` Elliot Berman
2023-01-20 22:46 ` [PATCH v9 15/27] samples: Add sample userspace Gunyah VM Manager Elliot Berman
2023-01-20 22:46 ` [PATCH v9 16/27] gunyah: rsc_mgr: Add platform ops on mem_lend/mem_reclaim Elliot Berman
2023-01-20 22:46 ` [PATCH v9 17/27] firmware: qcom_scm: Use fixed width src vm bitmap Elliot Berman
2023-03-16  3:21   ` (subset) " Bjorn Andersson
2023-01-20 22:46 ` [PATCH v9 18/27] firmware: qcom_scm: Register Gunyah platform ops Elliot Berman
2023-01-31 15:18   ` Srivatsa Vaddagiri
2023-02-07 11:52   ` Srinivas Kandagatla
2023-02-08  1:06     ` Elliot Berman
2023-01-20 22:46 ` [PATCH v9 19/27] docs: gunyah: Document Gunyah VM Manager Elliot Berman
2023-01-20 22:46 ` [PATCH v9 20/27] virt: gunyah: Translate gh_rm_hyp_resource into gunyah_resource Elliot Berman
2023-01-20 22:46 ` [PATCH v9 21/27] gunyah: vm_mgr: Add framework to add VM Functions Elliot Berman
2023-02-03  9:37   ` Srivatsa Vaddagiri
2023-02-03 17:56     ` Srivatsa Vaddagiri
2023-02-07 13:15   ` Srinivas Kandagatla
2023-02-08 19:34     ` Elliot Berman
2023-01-20 22:46 ` [PATCH v9 22/27] virt: gunyah: Add resource tickets Elliot Berman
2023-02-06  9:50   ` Srivatsa Vaddagiri
2023-02-06 21:30     ` Elliot Berman
2023-01-20 22:46 ` [PATCH v9 23/27] virt: gunyah: Add IO handlers Elliot Berman
2023-02-06 10:46   ` Srivatsa Vaddagiri
2023-02-07  3:59     ` Elliot Berman
2023-02-07 12:19       ` Srivatsa Vaddagiri
2023-01-20 22:46 ` [PATCH v9 24/27] virt: gunyah: Add proxy-scheduled vCPUs Elliot Berman
2023-02-07 14:43   ` Srinivas Kandagatla
2023-02-08 18:36     ` Elliot Berman
2023-02-09 10:39   ` Srivatsa Vaddagiri
2023-02-10  6:54     ` Srivatsa Vaddagiri
2023-02-10 17:09       ` Elliot Berman
2023-01-20 22:46 ` [PATCH v9 25/27] virt: gunyah: Add hypercalls for sending doorbell Elliot Berman
2023-01-20 22:46 ` [PATCH v9 26/27] virt: gunyah: Add irqfd interface Elliot Berman
2023-02-07 14:30   ` Srinivas Kandagatla
2023-02-13  8:11   ` Srivatsa Vaddagiri
2023-01-20 22:46 ` [PATCH v9 27/27] virt: gunyah: Add ioeventfd Elliot Berman
2023-02-07 14:19   ` Srinivas Kandagatla

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=bc274d7c-4c69-25a8-7463-de3c36e36ac8@quicinc.com \
    --to=quic_eberman@quicinc.com \
    --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=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=maz@kernel.org \
    --cc=quic_bjorande@quicinc.com \
    --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=sudeep.holla@arm.com \
    --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).