[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 04/29] tools/xenlogd: add transport layer


  • To: Jason Andryuk <jandryuk@xxxxxxxxx>
  • From: Juergen Gross <jgross@xxxxxxxx>
  • Date: Fri, 3 Nov 2023 08:50:12 +0100
  • Autocrypt: addr=jgross@xxxxxxxx; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>
  • Delivery-date: Fri, 03 Nov 2023 07:50:24 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 02.11.23 19:30, Jason Andryuk wrote:
On Wed, Nov 1, 2023 at 5:34 AM Juergen Gross <jgross@xxxxxxxx> wrote:

Add the transport layer of 9pfs. This is basically the infrastructure
to receive requests from the frontend and to send the related answers
via the rings.

In order to avoid unaligned accesses e.g. on Arm, add the definition of
__packed to the common-macros.h header.

Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
---

diff --git a/tools/xenlogd/io.c b/tools/xenlogd/io.c
index ef0954d69d..590d06e906 100644
--- a/tools/xenlogd/io.c
+++ b/tools/xenlogd/io.c

+static unsigned int get_request_bytes(device *device, unsigned int off,
+                                      unsigned int len)
+{
+    unsigned int size;
+    unsigned int out_data = ring_out_data(device);
+    RING_IDX prod, cons;
+
+    size = min(len - off, out_data);
+    prod = xen_9pfs_mask(device->intf->out_prod, device->ring_size);
+    cons = xen_9pfs_mask(device->cons_pvt_out, device->ring_size);
+    xen_9pfs_read_packet(device->buffer + off, device->data.out, size,
+                         prod, &cons, device->ring_size);
+
+    xen_rmb();           /* Read data out before setting visible consumer. */
+    device->cons_pvt_out += size;
+    device->intf->out_cons = device->cons_pvt_out;
+
+    /* Signal that more space is available now. */
+    xenevtchn_notify(xe, device->evtchn);
+
+    return size;
+}
+
+static unsigned int put_request_bytes(device *device, unsigned int off,
+                                      unsigned int len)

Should this be named put_response_bytes?

Yes.


+{
+    unsigned int size;
+    unsigned int in_data = ring_in_free(device);
+    RING_IDX prod, cons;
+
+    size = min(len - off, in_data);

IIUC, len is the total length of the outgoing data.  Maybe total_len
would be a better name?  I at least read len as just a length for a
particular call.  Same comment applies to get_request_bytes() if you
want to follow it.

Fine with me.


+    prod = xen_9pfs_mask(device->prod_pvt_in, device->ring_size);
+    cons = xen_9pfs_mask(device->intf->in_cons, device->ring_size);
+    xen_9pfs_write_packet(device->data.in, device->buffer + off, size,
+                          &prod, cons, device->ring_size);
+
+    xen_wmb();           /* Write data out before setting visible producer. */
+    device->prod_pvt_in += size;
+    device->intf->in_prod = device->prod_pvt_in;
+
+    return size;
+}
+
  static bool io_work_pending(device *device)
  {
      if ( device->stop_thread )
          return true;
-    return false;
+    if ( device->error )
+        return false;
+    return device->handle_response ? ring_in_free(device)
+                                   : ring_out_data(device);
  }

  void *io_thread(void *arg)
  {
      device *device = arg;
+    unsigned int count = 0;
+    struct p9_header hdr;
+    bool in_hdr = true;
+
+    device->max_size = device->ring_size;
+    device->buffer = malloc(device->max_size);
+    if ( !device->buffer )
+    {
+        syslog(LOG_CRIT, "memory allocation failure!");
+        return NULL;
+    }

      while ( !device->stop_thread )
      {
@@ -36,9 +127,56 @@ void *io_thread(void *arg)
          }
          pthread_mutex_unlock(&device->mutex);

-        /* TODO: I/O handling. */
+        if ( device->stop_thread || device->error )
+            continue;
+
+        if ( !device->handle_response )
+        {
+            if ( in_hdr )
+            {
+                count += get_request_bytes(device, count, sizeof(hdr));
+                if ( count != sizeof(hdr) )
+                    continue;
+                hdr = *(struct p9_header *)device->buffer;
+                if ( hdr.size > device->max_size || hdr.size < sizeof(hdr) )
+                {
+                    syslog(LOG_ERR, "%u.%u specified illegal request length 
%u",
+                           device->domid, device->devid, hdr.size);
+                    device->error = true;

When device->error is set, io_thread stops processing requests, but do
we want to also tear down this backend?  The event channel at least is
left in place and unmasked.

I think tearing down the backend shouldn't be done, but you are right that
the event channel should be kept masked.


+                    continue;
+                }
+                in_hdr = false;
+            }
+
+            count += get_request_bytes(device, count, hdr.size);
+            if ( count < hdr.size )
+                continue;
+
+            /* TODO: handle request. */
+
+            device->handle_response = true;
+            hdr.size = ((struct p9_header *)device->buffer)->size;

hdr.size is set during the struct copy above, so this isn't needed?

It will be needed later when the "TODO" is filled in, as it will then be the
response size.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.