From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xen.org, linux-kernel@vger.kernel.org,
jgross@suse.com, Stefano Stabellini <stefano@aporeto.com>
Subject: Re: [PATCH v4 04/13] xen/pvcalls: implement socket command and handle events
Date: Fri, 6 Oct 2017 16:36:24 -0400 [thread overview]
Message-ID: <f7cc2d60-5fd0-491e-7097-51b55d22500f@oracle.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1710061059410.3073@sstabellini-ThinkPad-X260>
On 10/06/2017 02:38 PM, Stefano Stabellini wrote:
> On Thu, 21 Sep 2017, Boris Ostrovsky wrote:
>>> +
>>> +static inline int get_request(struct pvcalls_bedata *bedata, int *req_id)
>>> +{
>>> + *req_id = bedata->ring.req_prod_pvt & (RING_SIZE(&bedata->ring) - 1);
>>> + if (RING_FULL(&bedata->ring) ||
>>> + READ_ONCE(bedata->rsp[*req_id].req_id) != PVCALLS_INVALID_ID)
>>> + return -EAGAIN;
>>> + return 0;
>>> +}
>>> +
>>> static irqreturn_t pvcalls_front_event_handler(int irq, void *dev_id)
>>> {
>>> + struct xenbus_device *dev = dev_id;
>>> + struct pvcalls_bedata *bedata;
>>> + struct xen_pvcalls_response *rsp;
>>> + uint8_t *src, *dst;
>>> + int req_id = 0, more = 0, done = 0;
>>> +
>>> + if (dev == NULL)
>>> + return IRQ_HANDLED;
>>> +
>>> + pvcalls_enter;
>>> + bedata = dev_get_drvdata(&dev->dev);
>>> + if (bedata == NULL) {
>>> + pvcalls_exit;
>>> + return IRQ_HANDLED;
>>> + }
>>> +
>>> +again:
>>> + while (RING_HAS_UNCONSUMED_RESPONSES(&bedata->ring)) {
>>> + rsp = RING_GET_RESPONSE(&bedata->ring, bedata->ring.rsp_cons);
>>> +
>>> + req_id = rsp->req_id;
>>> + dst = (uint8_t *)&bedata->rsp[req_id] + sizeof(rsp->req_id);
>>> + src = (uint8_t *)rsp + sizeof(rsp->req_id);
>>> + memcpy(dst, src, sizeof(*rsp) - sizeof(rsp->req_id));
>>> + /*
>>> + * First copy the rest of the data, then req_id. It is
>>> + * paired with the barrier when accessing bedata->rsp.
>>> + */
>>> + smp_wmb();
>>> + WRITE_ONCE(bedata->rsp[req_id].req_id, rsp->req_id);
>>> +
>>> + done = 1;
>>> + bedata->ring.rsp_cons++;
>>> + }
>>> +
>>> + RING_FINAL_CHECK_FOR_RESPONSES(&bedata->ring, more);
>>> + if (more)
>>> + goto again;
>>> + if (done)
>>> + wake_up(&bedata->inflight_req);
>>> + pvcalls_exit;
>>> return IRQ_HANDLED;
>>> }
>>>
>>> +
>>> + bedata = dev_get_drvdata(&pvcalls_front_dev->dev);
>>> +
>>> + map = kzalloc(sizeof(*map), GFP_KERNEL);
>>> + if (map == NULL) {
>>> + pvcalls_exit;
>>> + return -ENOMEM;
>>> + }
>>> +
>>> + spin_lock(&bedata->socket_lock);
>>> +
>>> + ret = get_request(bedata, &req_id);
>>> + if (ret < 0) {
>>> + kfree(map);
>>> + spin_unlock(&bedata->socket_lock);
>>> + pvcalls_exit;
>>> + return ret;
>>> + }
>>> +
>>> + /*
>>> + * sock->sk->sk_send_head is not used for ip sockets: reuse the
>>> + * field to store a pointer to the struct sock_mapping
>>> + * corresponding to the socket. This way, we can easily get the
>>> + * struct sock_mapping from the struct socket.
>>> + */
>>> + sock->sk->sk_send_head = (void *)map;
>>> + list_add_tail(&map->list, &bedata->socket_mappings);
>>> +
>>> + req = RING_GET_REQUEST(&bedata->ring, req_id);
>>> + req->req_id = req_id;
>>> + req->cmd = PVCALLS_SOCKET;
>>> + req->u.socket.id = (uint64_t) map;
>>> + req->u.socket.domain = AF_INET;
>>> + req->u.socket.type = SOCK_STREAM;
>>> + req->u.socket.protocol = IPPROTO_IP;
>>> +
>>> + bedata->ring.req_prod_pvt++;
>>> + RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&bedata->ring, notify);
>>> + spin_unlock(&bedata->socket_lock);
>>> + if (notify)
>>> + notify_remote_via_irq(bedata->irq);
>>> +
>>> + wait_event(bedata->inflight_req,
>>> + READ_ONCE(bedata->rsp[req_id].req_id) == req_id);
>>> +
>>> + ret = bedata->rsp[req_id].ret;
>>> + /* read ret, then set this rsp slot to be reused */
>>> + smp_mb();
>>> + WRITE_ONCE(bedata->rsp[req_id].req_id, PVCALLS_INVALID_ID);
>> Now that I looked at what *_ONCE macros do I am not sure this is needed, given
>> the smp_mb() above. In pvcalls_front_event_handler() too. And, in fact, in
>> get_request() as well.
>>
>> (Again, this will probably be also applicable to subsequent patches)
> Yes, I think you are right, although I think is much easier to use
> *_ONCE everywhere we don't want reads/writes to be mangled. Nonetheless,
> I removed WRITE_ONCE from places where the write is done immediately
> after a barrier. I kept *_ONCE elsewhere.
Adding them when not necessary makes code more difficult to read (and
possibly larger).
Juergen is out now but it would be good to hear what he thinks when he
gets back.
-boris
next prev parent reply other threads:[~2017-10-06 20:36 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-15 23:00 [PATCH v4 00/13] introduce the Xen PV Calls frontend Stefano Stabellini
2017-09-15 23:00 ` [PATCH v4 01/13] xen/pvcalls: introduce the pvcalls xenbus frontend Stefano Stabellini
2017-09-15 23:00 ` [PATCH v4 02/13] xen/pvcalls: implement frontend disconnect Stefano Stabellini
2017-09-20 20:32 ` Boris Ostrovsky
2017-10-06 17:51 ` Stefano Stabellini
2017-10-06 20:21 ` Boris Ostrovsky
2017-10-06 20:29 ` Stefano Stabellini
2017-10-06 20:31 ` Boris Ostrovsky
2017-09-20 20:59 ` Boris Ostrovsky
2017-10-07 0:08 ` Stefano Stabellini
2017-09-15 23:00 ` [PATCH v4 03/13] xen/pvcalls: connect to the backend Stefano Stabellini
2017-09-20 21:08 ` Boris Ostrovsky
2017-09-15 23:00 ` [PATCH v4 04/13] xen/pvcalls: implement socket command and handle events Stefano Stabellini
2017-09-21 17:42 ` Boris Ostrovsky
2017-10-06 18:38 ` Stefano Stabellini
2017-10-06 20:36 ` Boris Ostrovsky [this message]
2017-09-15 23:00 ` [PATCH v4 05/13] xen/pvcalls: implement connect command Stefano Stabellini
2017-09-21 18:28 ` Boris Ostrovsky
2017-10-06 17:44 ` Stefano Stabellini
2017-10-06 17:54 ` Stefano Stabellini
2017-09-15 23:00 ` [PATCH v4 06/13] xen/pvcalls: implement bind command Stefano Stabellini
2017-09-21 19:40 ` Boris Ostrovsky
2017-10-06 20:35 ` Stefano Stabellini
2017-09-15 23:00 ` [PATCH v4 07/13] xen/pvcalls: implement listen command Stefano Stabellini
2017-09-15 23:00 ` [PATCH v4 08/13] xen/pvcalls: implement accept command Stefano Stabellini
2017-09-22 0:00 ` Boris Ostrovsky
2017-10-06 22:06 ` Stefano Stabellini
2017-09-15 23:00 ` [PATCH v4 09/13] xen/pvcalls: implement sendmsg Stefano Stabellini
2017-09-22 21:57 ` Boris Ostrovsky
2017-10-06 21:43 ` Stefano Stabellini
2017-09-15 23:00 ` [PATCH v4 10/13] xen/pvcalls: implement recvmsg Stefano Stabellini
2017-09-22 22:05 ` Boris Ostrovsky
2017-10-06 20:46 ` Stefano Stabellini
2017-09-15 23:00 ` [PATCH v4 11/13] xen/pvcalls: implement poll command Stefano Stabellini
2017-09-19 15:19 ` Andrea Parri
2017-10-06 23:33 ` Stefano Stabellini
2017-09-22 22:27 ` Boris Ostrovsky
2017-10-06 23:39 ` Stefano Stabellini
2017-09-15 23:00 ` [PATCH v4 12/13] xen/pvcalls: implement release command Stefano Stabellini
2017-09-22 22:43 ` Boris Ostrovsky
2017-09-22 22:48 ` Boris Ostrovsky
2017-10-06 23:49 ` Stefano Stabellini
2017-09-15 23:00 ` [PATCH v4 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend Stefano Stabellini
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=f7cc2d60-5fd0-491e-7097-51b55d22500f@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sstabellini@kernel.org \
--cc=stefano@aporeto.com \
--cc=xen-devel@lists.xen.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
all inboxes | Powered by JetHome®