| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 5 Mar 2013 10:41:41 +0000
From: David Vrabel <david.vrabel@...rix.com>
To: Wei Liu <wei.liu2@...rix.com>
CC: <xen-devel@...ts.xen.org>, <netdev@...r.kernel.org>,
<ian.campbell@...rix.com>, <konrad.wilk@...cle.com>,
<annie.li@...cle.com>
Subject: Re: [Xen-devel] [PATCH 5/8] netback: multi-page ring support
On 15/02/13 16:00, Wei Liu wrote:
> [nothing]
You need to describe the protocol used to negotiate this. What happens
when a frontend without such support connects to a backend with support?
And vice-versa?
> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -45,6 +45,12 @@
> #include <xen/grant_table.h>
> #include <xen/xenbus.h>
>
> +#define NETBK_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
> +#define NETBK_MAX_RING_PAGES (1U << NETBK_MAX_RING_PAGE_ORDER)
> +
> +#define NETBK_MAX_TX_RING_SIZE XEN_NETIF_TX_RING_SIZE(NETBK_MAX_RING_PAGES)
> +#define NETBK_MAX_RX_RING_SIZE XEN_NETIF_RX_RING_SIZE(NETBK_MAX_RING_PAGES)
See comment below.
> @@ -105,15 +113,19 @@ static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
> return to_xenbus_device(vif->dev->dev.parent);
> }
>
> -#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
> -#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
> +#define XEN_NETIF_TX_RING_SIZE(_nr_pages) \
> + __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
Ring size is no longer const.
Would these be better as inline functions with a struct xenvif parameter?
Would need to fixup the MAX_XX_RING_SIZE macros above.
> index db638e1..fa4d46d 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -305,10 +305,16 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
> return vif;
> }
>
> -int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
> - unsigned long rx_ring_ref, unsigned int evtchn)
> +int xenvif_connect(struct xenvif *vif,
> + unsigned long *tx_ring_ref, unsigned int tx_ring_ref_count,
> + unsigned long *rx_ring_ref, unsigned int rx_ring_ref_count,
> + unsigned int evtchn)
> {
> int err = -ENOMEM;
> + void *addr;
> + struct xen_netif_tx_sring *txs;
> + struct xen_netif_rx_sring *rxs;
> + int tmp[NETBK_MAX_RING_PAGES], i;
grant_ref_t, and elsewhere probably -- I didn't check.
> @@ -382,7 +413,8 @@ void xenvif_disconnect(struct xenvif *vif)
>
> unregister_netdev(vif->dev);
>
> - xen_netbk_unmap_frontend_rings(vif);
> + xen_netbk_unmap_frontend_rings(vif, (void *)vif->tx.sring);
> + xen_netbk_unmap_frontend_rings(vif, (void *)vif->rx.sring);
Don't need the casts here.
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -47,6 +47,19 @@
> #include <asm/xen/hypercall.h>
> #include <asm/xen/page.h>
>
> +unsigned int MODPARM_netback_max_rx_ring_page_order = NETBK_MAX_RING_PAGE_ORDER;
> +module_param_named(netback_max_rx_ring_page_order,
> + MODPARM_netback_max_rx_ring_page_order, uint, 0);
Please don't prefix new module parameters with "netback",
"max_rx_ring_page_order" is fine.
> +MODULE_PARM_DESC(netback_max_rx_ring_page_order,
> + "Maximum supported receiver ring page order");
> +
> +unsigned int MODPARM_netback_max_tx_ring_page_order = NETBK_MAX_RING_PAGE_ORDER;
> +module_param_named(netback_max_tx_ring_page_order,
> + MODPARM_netback_max_tx_ring_page_order, uint, 0);
Ditto.
> +MODULE_PARM_DESC(netback_max_tx_ring_page_order,
> + "Maximum supported transmitter ring page order");
> +
> +
[...]
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
[...]
> + err = xenbus_scanf(XBT_NIL, dev->otherend, "tx-ring-order", "%u",
> + &tx_ring_order);
> + if (err < 0) {
> + tx_ring_order = 0;
> +
> + err = xenbus_scanf(XBT_NIL, dev->otherend, "tx-ring-ref", "%lu",
> + &tx_ring_ref[0]);
> + if (err < 0) {
> + xenbus_dev_fatal(dev, err, "reading %s/tx-ring-ref",
> + dev->otherend);
> + return err;
> + }
> + } else {
> + unsigned int i;
> +
> + if (tx_ring_order > MODPARM_netback_max_tx_ring_page_order) {
> + err = -EINVAL;
> + xenbus_dev_fatal(dev, err,
> + "%s/tx-ring-page-order too big",
> + dev->otherend);
> + return err;
> + }
> +
> + for (i = 0; i < (1U << tx_ring_order); i++) {
> + char ring_ref_name[sizeof("tx-ring-ref") + 2];
> +
> + snprintf(ring_ref_name, sizeof(ring_ref_name),
> + "tx-ring-ref%u", i);
> +
> + err = xenbus_scanf(XBT_NIL, dev->otherend,
> + ring_ref_name, "%lu",
> + &tx_ring_ref[i]);
> + if (err < 0) {
> + xenbus_dev_fatal(dev, err,
> + "reading %s/%s",
> + dev->otherend,
> + ring_ref_name);
> + return err;
> + }
> + }
Refactor this whole if/else block and the similar code below for rx into
a common library function?
It will be useful for blkback etc. as well.
> @@ -454,11 +566,28 @@ static int connect_rings(struct backend_info *be)
> vif->csum = !val;
>
> /* Map the shared frame, irq etc. */
> - err = xenvif_connect(vif, tx_ring_ref, rx_ring_ref, evtchn);
> + err = xenvif_connect(vif, tx_ring_ref, (1U << tx_ring_order),
> + rx_ring_ref, (1U << rx_ring_order),
> + evtchn);
> if (err) {
> + /* construct 1 2 3 / 4 5 6 */
This comment doesn't make sense to me.
David
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists