[Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Michael S. Tsirkin]

virtio linux headers are actually pretty portable:
all we need is implement linux/types.h in a portable
way, and we can import them and use on any platform.

These patches do exactly that, as a pre-requisite
to adding support for new virtio layout.

Note: if someone adds non-portable code in files we import from linux-headers,
we'll have to revert to copying code manually.  This didn't happen yet so
hopefully it won't.

Changes from v1:
    - add stubs for non linux platforms
    - fix mingw cross build

Michael S. Tsirkin (11):
  make: pull in linux-headers on all platforms
  scripts/update-linux-headers.sh: add virtio
  virtio-9p: switch to linux-headers
  virtio-net, eth: use linux-headers
  virtio-blk: switch to linux-headers
  virtio-balloon: switch to linux-headers
  virtio-rng: switch to linux-headers
  virtio-console: switch to linux-headers
  virtio: add virtio_ids from linux-headers
  virtio-pci: switch to linux-headers
  virtio: use ring structure from linux-headers

 Makefile.target                      |   5 +-
 configure                            |   7 +-
 hw/9pfs/virtio-9p.h                  |  13 +--
 hw/block/dataplane/virtio-blk.c      |  12 +--
 hw/block/virtio-blk.c                |  10 +-
 hw/virtio/virtio-balloon.c           |   2 +-
 hw/virtio/virtio-pci.c               |  49 +--------
 hw/virtio/virtio.c                   |  23 +---
 include/hw/virtio/virtio-balloon.h   |  37 +------
 include/hw/virtio/virtio-blk.h       |  86 +--------------
 include/hw/virtio/virtio-net.h       | 141 +-----------------------
 include/hw/virtio/virtio-rng.h       |   5 +-
 include/hw/virtio/virtio-serial.h    |  38 +------
 include/hw/virtio/virtio.h           |  45 +-------
 include/net/eth.h                    |   5 +-
 include/net/tap.h                    |  24 +----
 linux-headers/linux/if_ether.h       | 140 ++++++++++++++++++++++++
 linux-headers/linux/virtio_9p.h      |  44 ++++++++
 linux-headers/linux/virtio_balloon.h |  59 ++++++++++
 linux-headers/linux/virtio_blk.h     | 128 ++++++++++++++++++++++
 linux-headers/linux/virtio_console.h |  74 +++++++++++++
 linux-headers/linux/virtio_ids.h     |  43 ++++++++
 linux-headers/linux/virtio_net.h     | 202 +++++++++++++++++++++++++++++++++++
 linux-headers/linux/virtio_pci.h     |  97 +++++++++++++++++
 linux-headers/linux/virtio_rng.h     |   8 ++
 scripts/update-linux-headers.sh      |  17 ++-
 26 files changed, 862 insertions(+), 452 deletions(-)
 create mode 100644 linux-headers/linux/if_ether.h
 create mode 100644 linux-headers/linux/virtio_9p.h
 create mode 100644 linux-headers/linux/virtio_balloon.h
 create mode 100644 linux-headers/linux/virtio_blk.h
 create mode 100644 linux-headers/linux/virtio_console.h
 create mode 100644 linux-headers/linux/virtio_ids.h
 create mode 100644 linux-headers/linux/virtio_net.h
 create mode 100644 linux-headers/linux/virtio_pci.h
 create mode 100644 linux-headers/linux/virtio_rng.h

-- 
MST

[Qemu-devel] [PATCH v2 01/11] make: pull in linux-headers on all platforms

[Michael S. Tsirkin]

Things we pull from linux-headers are actually
quite portable. All we need is implement linux/types.h
using stdint.h and we are able to compile on any platform.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 Makefile.target | 5 +++--
 configure       | 7 ++++++-
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index ce4391f..5d69d50 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -6,9 +6,10 @@ include config-devices.mak
 include $(SRC_PATH)/rules.mak
 
 $(call set-vpath, $(SRC_PATH))
-ifdef CONFIG_LINUX
-QEMU_CFLAGS += -I../linux-headers
+ifndef CONFIG_LINUX
+QEMU_CFLAGS += -I../linux-stubs
 endif
+QEMU_CFLAGS += -I../linux-headers
 QEMU_CFLAGS += -I.. -I$(SRC_PATH)/target-$(TARGET_BASE_ARCH) -DNEED_CPU_H
 
 QEMU_CFLAGS+=-I$(SRC_PATH)/include
diff --git a/configure b/configure
index 5ae7e4a..8321f8b 100755
--- a/configure
+++ b/configure
@@ -427,6 +427,7 @@ fi
 
 # OS specific
 
+QEMU_LINUX_HEADER_INCLUDES="-I\$(SRC_PATH)/linux-stubs -I\$(SRC_PATH)/linux-headers "
 case $targetos in
 CYGWIN*)
   mingw32="yes"
@@ -547,10 +548,14 @@ Haiku)
   if [ "$cpu" = "i386" -o "$cpu" = "x86_64" ] ; then
     audio_possible_drivers="$audio_possible_drivers fmod"
   fi
-  QEMU_INCLUDES="-I\$(SRC_PATH)/linux-headers $QEMU_INCLUDES"
+  QEMU_LINUX_HEADER_INCLUDES="-I\$(SRC_PATH)/linux-headers "
 ;;
 esac
 
+#Always pull in linux-headers, we make sure they are
+#cross-platform
+QEMU_INCLUDES="$QEMU_LINUX_HEADER_INCLUDES$QEMU_INCLUDES"
+
 if [ "$bsd" = "yes" ] ; then
   if [ "$darwin" != "yes" ] ; then
     usb="bsd"
-- 
MST

[Qemu-devel] [PATCH v2 02/11] scripts/update-linux-headers.sh: add virtio

[Michael S. Tsirkin]

Add virtio headers to make it easy to keep
things in sync.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 scripts/update-linux-headers.sh | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/scripts/update-linux-headers.sh b/scripts/update-linux-headers.sh
index 120a694..334fba9 100755
--- a/scripts/update-linux-headers.sh
+++ b/scripts/update-linux-headers.sh
@@ -61,7 +61,22 @@ done
 
 rm -rf "$output/linux-headers/linux"
 mkdir -p "$output/linux-headers/linux"
-for header in kvm.h kvm_para.h vfio.h vhost.h virtio_config.h virtio_ring.h; do
+for header in \
+    kvm.h \
+    kvm_para.h \
+    vfio.h \
+    vhost.h \
+    virtio_9p.h \
+    virtio_balloon.h \
+    virtio_blk.h \
+    virtio_config.h \
+    virtio_console.h \
+    virtio_ids.h \
+    virtio_net.h \
+    virtio_pci.h \
+    virtio_ring.h \
+    virtio_rng.h \
+    ; do
     cp "$tmpdir/include/linux/$header" "$output/linux-headers/linux"
 done
 rm -rf "$output/linux-headers/asm-generic"
-- 
MST

[Qemu-devel] [PATCH v2 03/11] virtio-9p: switch to linux-headers

[Michael S. Tsirkin]

It's easier to keep everything in sync if
we just use linux headers for virtio constants.
Add virtio-9p header from linux 3.10-rc1, and
remove duplicate symbols from virtio-9p.h

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 hw/9pfs/virtio-9p.h             | 13 +-----------
 linux-headers/linux/virtio_9p.h | 44 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 45 insertions(+), 12 deletions(-)
 create mode 100644 linux-headers/linux/virtio_9p.h

diff --git a/hw/9pfs/virtio-9p.h b/hw/9pfs/virtio-9p.h
index 1d6eedb..5ba4411 100644
--- a/hw/9pfs/virtio-9p.h
+++ b/hw/9pfs/virtio-9p.h
@@ -11,10 +11,7 @@
 #include "fsdev/virtio-9p-marshal.h"
 #include "qemu/thread.h"
 #include "block/coroutine.h"
-
-/* The feature bitmap for virtio 9P */
-/* The mount point is specified in a config variable */
-#define VIRTIO_9P_MOUNT_TAG 0
+#include "linux/virtio_9p.h"
 
 enum {
     P9_TLERROR = 6,
@@ -277,14 +274,6 @@ typedef struct V9fsWriteState {
     int cnt;
 } V9fsWriteState;
 
-struct virtio_9p_config
-{
-    /* number of characters in tag */
-    uint16_t tag_len;
-    /* Variable size tag name */
-    uint8_t tag[0];
-} QEMU_PACKED;
-
 typedef struct V9fsMkState {
     V9fsPDU *pdu;
     size_t offset;
diff --git a/linux-headers/linux/virtio_9p.h b/linux-headers/linux/virtio_9p.h
new file mode 100644
index 0000000..277c4ad
--- /dev/null
+++ b/linux-headers/linux/virtio_9p.h
@@ -0,0 +1,44 @@
+#ifndef _LINUX_VIRTIO_9P_H
+#define _LINUX_VIRTIO_9P_H
+/* This header is BSD licensed so anyone can use the definitions to implement
+ * compatible drivers/servers.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of IBM nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL IBM OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE. */
+#include <linux/types.h>
+#include <linux/virtio_ids.h>
+#include <linux/virtio_config.h>
+
+/* The feature bitmap for virtio 9P */
+
+/* The mount point is specified in a config variable */
+#define VIRTIO_9P_MOUNT_TAG 0
+
+struct virtio_9p_config {
+	/* length of the tag name */
+	__u16 tag_len;
+	/* non-NULL terminated tag name */
+	__u8 tag[0];
+} __attribute__((packed));
+
+#endif /* _LINUX_VIRTIO_9P_H */
-- 
MST

[Qemu-devel] [PATCH v2 04/11] virtio-net, eth: use linux-headers

[Michael S. Tsirkin]

It's easier to keep everything virtio in sync if
we just use headers exported from linux kernel.
Import linux/virtio_net.h and linux/if_ether.h
that it depends on. Switch to symbols from
that header for stuff that was
duplicated in tap.h and eth.h

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 include/hw/virtio/virtio-net.h   | 141 +--------------------------
 include/net/eth.h                |   5 +-
 include/net/tap.h                |  24 +----
 linux-headers/linux/if_ether.h   | 140 +++++++++++++++++++++++++++
 linux-headers/linux/virtio_net.h | 202 +++++++++++++++++++++++++++++++++++++++
 5 files changed, 347 insertions(+), 165 deletions(-)
 create mode 100644 linux-headers/linux/if_ether.h
 create mode 100644 linux-headers/linux/virtio_net.h

diff --git a/include/hw/virtio/virtio-net.h b/include/hw/virtio/virtio-net.h
index b315ac9..65616c0 100644
--- a/include/hw/virtio/virtio-net.h
+++ b/include/hw/virtio/virtio-net.h
@@ -16,46 +16,13 @@
 
 #include "hw/virtio/virtio.h"
 #include "hw/pci/pci.h"
+#include "linux/virtio_net.h"
+#include "linux/virtio_ids.h"
 
 #define TYPE_VIRTIO_NET "virtio-net-device"
 #define VIRTIO_NET(obj) \
         OBJECT_CHECK(VirtIONet, (obj), TYPE_VIRTIO_NET)
 
-#define ETH_ALEN    6
-
-/* from Linux's virtio_net.h */
-
-/* The ID for virtio_net */
-#define VIRTIO_ID_NET   1
-
-/* The feature bitmap for virtio net */
-#define VIRTIO_NET_F_CSUM       0       /* Host handles pkts w/ partial csum */
-#define VIRTIO_NET_F_GUEST_CSUM 1       /* Guest handles pkts w/ partial csum */
-#define VIRTIO_NET_F_CTRL_GUEST_OFFLOADS 2 /* Control channel offload
-                                         * configuration support */
-#define VIRTIO_NET_F_MAC        5       /* Host has given MAC address. */
-#define VIRTIO_NET_F_GSO        6       /* Host handles pkts w/ any GSO type */
-#define VIRTIO_NET_F_GUEST_TSO4 7       /* Guest can handle TSOv4 in. */
-#define VIRTIO_NET_F_GUEST_TSO6 8       /* Guest can handle TSOv6 in. */
-#define VIRTIO_NET_F_GUEST_ECN  9       /* Guest can handle TSO[6] w/ ECN in. */
-#define VIRTIO_NET_F_GUEST_UFO  10      /* Guest can handle UFO in. */
-#define VIRTIO_NET_F_HOST_TSO4  11      /* Host can handle TSOv4 in. */
-#define VIRTIO_NET_F_HOST_TSO6  12      /* Host can handle TSOv6 in. */
-#define VIRTIO_NET_F_HOST_ECN   13      /* Host can handle TSO[6] w/ ECN in. */
-#define VIRTIO_NET_F_HOST_UFO   14      /* Host can handle UFO in. */
-#define VIRTIO_NET_F_MRG_RXBUF  15      /* Host can merge receive buffers. */
-#define VIRTIO_NET_F_STATUS     16      /* virtio_net_config.status available */
-#define VIRTIO_NET_F_CTRL_VQ    17      /* Control channel available */
-#define VIRTIO_NET_F_CTRL_RX    18      /* Control channel RX mode support */
-#define VIRTIO_NET_F_CTRL_VLAN  19      /* Control channel VLAN filtering */
-#define VIRTIO_NET_F_CTRL_RX_EXTRA 20   /* Extra RX mode control support */
-#define VIRTIO_NET_F_MQ         22      /* Device supports Receive Flow
-                                         * Steering */
-
-#define VIRTIO_NET_F_CTRL_MAC_ADDR   23 /* Set MAC address */
-
-#define VIRTIO_NET_S_LINK_UP    1       /* Link is up */
-
 #define TX_TIMER_INTERVAL 150000 /* 150 us */
 
 /* Limit the number of packets that can be sent via a single flush
@@ -75,72 +42,6 @@ typedef struct virtio_net_conf
 /* Maximum packet size we can receive from tap device: header + 64k */
 #define VIRTIO_NET_MAX_BUFSIZE (sizeof(struct virtio_net_hdr) + (64 << 10))
 
-struct virtio_net_config
-{
-    /* The config defining mac address ($ETH_ALEN bytes) */
-    uint8_t mac[ETH_ALEN];
-    /* See VIRTIO_NET_F_STATUS and VIRTIO_NET_S_* above */
-    uint16_t status;
-    /* Max virtqueue pairs supported by the device */
-    uint16_t max_virtqueue_pairs;
-} QEMU_PACKED;
-
-/*
- * Control virtqueue data structures
- *
- * The control virtqueue expects a header in the first sg entry
- * and an ack/status response in the last entry.  Data for the
- * command goes in between.
- */
-struct virtio_net_ctrl_hdr {
-    uint8_t class;
-    uint8_t cmd;
-};
-
-typedef uint8_t virtio_net_ctrl_ack;
-
-#define VIRTIO_NET_OK     0
-#define VIRTIO_NET_ERR    1
-
-/*
- * Control the RX mode, ie. promisucous, allmulti, etc...
- * All commands require an "out" sg entry containing a 1 byte
- * state value, zero = disable, non-zero = enable.  Commands
- * 0 and 1 are supported with the VIRTIO_NET_F_CTRL_RX feature.
- * Commands 2-5 are added with VIRTIO_NET_F_CTRL_RX_EXTRA.
- */
-#define VIRTIO_NET_CTRL_RX    0
- #define VIRTIO_NET_CTRL_RX_PROMISC      0
- #define VIRTIO_NET_CTRL_RX_ALLMULTI     1
- #define VIRTIO_NET_CTRL_RX_ALLUNI       2
- #define VIRTIO_NET_CTRL_RX_NOMULTI      3
- #define VIRTIO_NET_CTRL_RX_NOUNI        4
- #define VIRTIO_NET_CTRL_RX_NOBCAST      5
-
-/*
- * Control the MAC
- *
- * The MAC filter table is managed by the hypervisor, the guest should
- * assume the size is infinite.  Filtering should be considered
- * non-perfect, ie. based on hypervisor resources, the guest may
- * received packets from sources not specified in the filter list.
- *
- * In addition to the class/cmd header, the TABLE_SET command requires
- * two out scatterlists.  Each contains a 4 byte count of entries followed
- * by a concatenated byte stream of the ETH_ALEN MAC addresses.  The
- * first sg list contains unicast addresses, the second is for multicast.
- * This functionality is present if the VIRTIO_NET_F_CTRL_RX feature
- * is available.
- *
- * The ADDR_SET command requests one out scatterlist, it contains a
- * 6 bytes MAC address. This functionality is present if the
- * VIRTIO_NET_F_CTRL_MAC_ADDR feature is available.
- */
-struct virtio_net_ctrl_mac {
-    uint32_t entries;
-    uint8_t macs[][ETH_ALEN];
-};
-
 typedef struct VirtIONetQueue {
     VirtQueue *rx_vq;
     VirtQueue *tx_vq;
@@ -195,43 +96,7 @@ typedef struct VirtIONet {
     uint64_t curr_guest_offloads;
 } VirtIONet;
 
-#define VIRTIO_NET_CTRL_MAC    1
- #define VIRTIO_NET_CTRL_MAC_TABLE_SET        0
- #define VIRTIO_NET_CTRL_MAC_ADDR_SET         1
-
-/*
- * Control VLAN filtering
- *
- * The VLAN filter table is controlled via a simple ADD/DEL interface.
- * VLAN IDs not added may be filterd by the hypervisor.  Del is the
- * opposite of add.  Both commands expect an out entry containing a 2
- * byte VLAN ID.  VLAN filterting is available with the
- * VIRTIO_NET_F_CTRL_VLAN feature bit.
- */
-#define VIRTIO_NET_CTRL_VLAN       2
- #define VIRTIO_NET_CTRL_VLAN_ADD             0
- #define VIRTIO_NET_CTRL_VLAN_DEL             1
-
-/*
- * Control Multiqueue
- *
- * The command VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET
- * enables multiqueue, specifying the number of the transmit and
- * receive queues that will be used. After the command is consumed and acked by
- * the device, the device will not steer new packets on receive virtqueues
- * other than specified nor read from transmit virtqueues other than specified.
- * Accordingly, driver should not transmit new packets  on virtqueues other than
- * specified.
- */
-struct virtio_net_ctrl_mq {
-    uint16_t virtqueue_pairs;
-};
-
-#define VIRTIO_NET_CTRL_MQ   4
- #define VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET        0
- #define VIRTIO_NET_CTRL_MQ_VQ_PAIRS_MIN        1
- #define VIRTIO_NET_CTRL_MQ_VQ_PAIRS_MAX        0x8000
-
+#define VIRTIO_NET_F_CTRL_GUEST_OFFLOADS 2 /* Guest offload control */
 /*
  * Control network offloads
  *
diff --git a/include/net/eth.h b/include/net/eth.h
index 1d48e06..6102394 100644
--- a/include/net/eth.h
+++ b/include/net/eth.h
@@ -26,13 +26,12 @@
 #ifndef QEMU_ETH_H
 #define QEMU_ETH_H
 
+#include <linux/if_ether.h>
 #include <sys/types.h>
 #include <string.h>
 #include "qemu/bswap.h"
 #include "qemu/iov.h"
 
-#define ETH_ALEN 6
-
 struct eth_header {
     uint8_t  h_dest[ETH_ALEN];   /* destination eth addr */
     uint8_t  h_source[ETH_ALEN]; /* source ether addr    */
@@ -170,8 +169,6 @@ struct tcp_hdr {
 #define IP_HEADER_VERSION(ip)     \
     ((ip->ip_ver_len >> 4)&0xf)
 
-#define ETH_P_IP                  (0x0800)
-#define ETH_P_IPV6                (0x86dd)
 #define ETH_P_VLAN                (0x8100)
 #define ETH_P_DVLAN               (0x88a8)
 #define VLAN_VID_MASK             0x0fff
diff --git a/include/net/tap.h b/include/net/tap.h
index a994f20..2eff653 100644
--- a/include/net/tap.h
+++ b/include/net/tap.h
@@ -28,6 +28,7 @@
 
 #include "qemu-common.h"
 #include "qapi-types.h"
+#include "linux/virtio_net.h"
 
 bool tap_has_ufo(NetClientState *nc);
 int tap_has_vnet_hdr(NetClientState *nc);
@@ -43,27 +44,4 @@ int tap_get_fd(NetClientState *nc);
 struct vhost_net;
 struct vhost_net *tap_get_vhost_net(NetClientState *nc);
 
-struct virtio_net_hdr
-{
-#define VIRTIO_NET_HDR_F_NEEDS_CSUM     1       // Use csum_start, csum_offset
-#define VIRTIO_NET_HDR_F_DATA_VALID    2       // Csum is valid
-    uint8_t flags;
-#define VIRTIO_NET_HDR_GSO_NONE         0       // Not a GSO frame
-#define VIRTIO_NET_HDR_GSO_TCPV4        1       // GSO frame, IPv4 TCP (TSO)
-#define VIRTIO_NET_HDR_GSO_UDP          3       // GSO frame, IPv4 UDP (UFO)
-#define VIRTIO_NET_HDR_GSO_TCPV6        4       // GSO frame, IPv6 TCP
-#define VIRTIO_NET_HDR_GSO_ECN          0x80    // TCP has ECN set
-    uint8_t gso_type;
-    uint16_t hdr_len;
-    uint16_t gso_size;
-    uint16_t csum_start;
-    uint16_t csum_offset;
-};
-
-struct virtio_net_hdr_mrg_rxbuf
-{
-    struct virtio_net_hdr hdr;
-    uint16_t num_buffers;   /* Number of merged rx buffers */
-};
-
 #endif /* QEMU_NET_TAP_H */
diff --git a/linux-headers/linux/if_ether.h b/linux-headers/linux/if_ether.h
new file mode 100644
index 0000000..2fc760a
--- /dev/null
+++ b/linux-headers/linux/if_ether.h
@@ -0,0 +1,140 @@
+/*
+ * INET		An implementation of the TCP/IP protocol suite for the LINUX
+ *		operating system.  INET is implemented using the  BSD Socket
+ *		interface as the means of communication with the user level.
+ *
+ *		Global definitions for the Ethernet IEEE 802.3 interface.
+ *
+ * Version:	@(#)if_ether.h	1.0.1a	02/08/94
+ *
+ * Author:	Fred N. van Kempen, <waltje@uWalt.NL.Mugnet.ORG>
+ *		Donald Becker, <becker@super.org>
+ *		Alan Cox, <alan@lxorguk.ukuu.org.uk>
+ *		Steve Whitehouse, <gw7rrm@eeshack3.swan.ac.uk>
+ *
+ *		This program is free software; you can redistribute it and/or
+ *		modify it under the terms of the GNU General Public License
+ *		as published by the Free Software Foundation; either version
+ *		2 of the License, or (at your option) any later version.
+ */
+
+#ifndef _LINUX_IF_ETHER_H
+#define _LINUX_IF_ETHER_H
+
+#include <linux/types.h>
+
+/*
+ *	IEEE 802.3 Ethernet magic constants.  The frame sizes omit the preamble
+ *	and FCS/CRC (frame check sequence).
+ */
+
+#define ETH_ALEN	6		/* Octets in one ethernet addr	 */
+#define ETH_HLEN	14		/* Total octets in header.	 */
+#define ETH_ZLEN	60		/* Min. octets in frame sans FCS */
+#define ETH_DATA_LEN	1500		/* Max. octets in payload	 */
+#define ETH_FRAME_LEN	1514		/* Max. octets in frame sans FCS */
+#define ETH_FCS_LEN	4		/* Octets in the FCS		 */
+
+/*
+ *	These are the defined Ethernet Protocol ID's.
+ */
+
+#define ETH_P_LOOP	0x0060		/* Ethernet Loopback packet	*/
+#define ETH_P_PUP	0x0200		/* Xerox PUP packet		*/
+#define ETH_P_PUPAT	0x0201		/* Xerox PUP Addr Trans packet	*/
+#define ETH_P_IP	0x0800		/* Internet Protocol packet	*/
+#define ETH_P_X25	0x0805		/* CCITT X.25			*/
+#define ETH_P_ARP	0x0806		/* Address Resolution packet	*/
+#define	ETH_P_BPQ	0x08FF		/* G8BPQ AX.25 Ethernet Packet	[ NOT AN OFFICIALLY REGISTERED ID ] */
+#define ETH_P_IEEEPUP	0x0a00		/* Xerox IEEE802.3 PUP packet */
+#define ETH_P_IEEEPUPAT	0x0a01		/* Xerox IEEE802.3 PUP Addr Trans packet */
+#define ETH_P_BATMAN	0x4305		/* B.A.T.M.A.N.-Advanced packet [ NOT AN OFFICIALLY REGISTERED ID ] */
+#define ETH_P_DEC       0x6000          /* DEC Assigned proto           */
+#define ETH_P_DNA_DL    0x6001          /* DEC DNA Dump/Load            */
+#define ETH_P_DNA_RC    0x6002          /* DEC DNA Remote Console       */
+#define ETH_P_DNA_RT    0x6003          /* DEC DNA Routing              */
+#define ETH_P_LAT       0x6004          /* DEC LAT                      */
+#define ETH_P_DIAG      0x6005          /* DEC Diagnostics              */
+#define ETH_P_CUST      0x6006          /* DEC Customer use             */
+#define ETH_P_SCA       0x6007          /* DEC Systems Comms Arch       */
+#define ETH_P_TEB	0x6558		/* Trans Ether Bridging		*/
+#define ETH_P_RARP      0x8035		/* Reverse Addr Res packet	*/
+#define ETH_P_ATALK	0x809B		/* Appletalk DDP		*/
+#define ETH_P_AARP	0x80F3		/* Appletalk AARP		*/
+#define ETH_P_8021Q	0x8100          /* 802.1Q VLAN Extended Header  */
+#define ETH_P_IPX	0x8137		/* IPX over DIX			*/
+#define ETH_P_IPV6	0x86DD		/* IPv6 over bluebook		*/
+#define ETH_P_PAUSE	0x8808		/* IEEE Pause frames. See 802.3 31B */
+#define ETH_P_SLOW	0x8809		/* Slow Protocol. See 802.3ad 43B */
+#define ETH_P_WCCP	0x883E		/* Web-cache coordination protocol
+					 * defined in draft-wilson-wrec-wccp-v2-00.txt */
+#define ETH_P_PPP_DISC	0x8863		/* PPPoE discovery messages     */
+#define ETH_P_PPP_SES	0x8864		/* PPPoE session messages	*/
+#define ETH_P_MPLS_UC	0x8847		/* MPLS Unicast traffic		*/
+#define ETH_P_MPLS_MC	0x8848		/* MPLS Multicast traffic	*/
+#define ETH_P_ATMMPOA	0x884c		/* MultiProtocol Over ATM	*/
+#define ETH_P_LINK_CTL	0x886c		/* HPNA, wlan link local tunnel */
+#define ETH_P_ATMFATE	0x8884		/* Frame-based ATM Transport
+					 * over Ethernet
+					 */
+#define ETH_P_PAE	0x888E		/* Port Access Entity (IEEE 802.1X) */
+#define ETH_P_AOE	0x88A2		/* ATA over Ethernet		*/
+#define ETH_P_8021AD	0x88A8          /* 802.1ad Service VLAN		*/
+#define ETH_P_802_EX1	0x88B5		/* 802.1 Local Experimental 1.  */
+#define ETH_P_TIPC	0x88CA		/* TIPC 			*/
+#define ETH_P_8021AH	0x88E7          /* 802.1ah Backbone Service Tag */
+#define ETH_P_MVRP	0x88F5          /* 802.1Q MVRP                  */
+#define ETH_P_1588	0x88F7		/* IEEE 1588 Timesync */
+#define ETH_P_FCOE	0x8906		/* Fibre Channel over Ethernet  */
+#define ETH_P_TDLS	0x890D          /* TDLS */
+#define ETH_P_FIP	0x8914		/* FCoE Initialization Protocol */
+#define ETH_P_QINQ1	0x9100		/* deprecated QinQ VLAN [ NOT AN OFFICIALLY REGISTERED ID ] */
+#define ETH_P_QINQ2	0x9200		/* deprecated QinQ VLAN [ NOT AN OFFICIALLY REGISTERED ID ] */
+#define ETH_P_QINQ3	0x9300		/* deprecated QinQ VLAN [ NOT AN OFFICIALLY REGISTERED ID ] */
+#define ETH_P_EDSA	0xDADA		/* Ethertype DSA [ NOT AN OFFICIALLY REGISTERED ID ] */
+#define ETH_P_AF_IUCV   0xFBFB		/* IBM af_iucv [ NOT AN OFFICIALLY REGISTERED ID ] */
+
+#define ETH_P_802_3_MIN	0x0600		/* If the value in the ethernet type is less than this value
+					 * then the frame is Ethernet II. Else it is 802.3 */
+
+/*
+ *	Non DIX types. Won't clash for 1500 types.
+ */
+
+#define ETH_P_802_3	0x0001		/* Dummy type for 802.3 frames  */
+#define ETH_P_AX25	0x0002		/* Dummy protocol id for AX.25  */
+#define ETH_P_ALL	0x0003		/* Every packet (be careful!!!) */
+#define ETH_P_802_2	0x0004		/* 802.2 frames 		*/
+#define ETH_P_SNAP	0x0005		/* Internal only		*/
+#define ETH_P_DDCMP     0x0006          /* DEC DDCMP: Internal only     */
+#define ETH_P_WAN_PPP   0x0007          /* Dummy type for WAN PPP frames*/
+#define ETH_P_PPP_MP    0x0008          /* Dummy type for PPP MP frames */
+#define ETH_P_LOCALTALK 0x0009		/* Localtalk pseudo type 	*/
+#define ETH_P_CAN	0x000C		/* CAN: Controller Area Network */
+#define ETH_P_CANFD	0x000D		/* CANFD: CAN flexible data rate*/
+#define ETH_P_PPPTALK	0x0010		/* Dummy type for Atalk over PPP*/
+#define ETH_P_TR_802_2	0x0011		/* 802.2 frames 		*/
+#define ETH_P_MOBITEX	0x0015		/* Mobitex (kaz@cafe.net)	*/
+#define ETH_P_CONTROL	0x0016		/* Card specific control frames */
+#define ETH_P_IRDA	0x0017		/* Linux-IrDA			*/
+#define ETH_P_ECONET	0x0018		/* Acorn Econet			*/
+#define ETH_P_HDLC	0x0019		/* HDLC frames			*/
+#define ETH_P_ARCNET	0x001A		/* 1A for ArcNet :-)            */
+#define ETH_P_DSA	0x001B		/* Distributed Switch Arch.	*/
+#define ETH_P_TRAILER	0x001C		/* Trailer switch tagging	*/
+#define ETH_P_PHONET	0x00F5		/* Nokia Phonet frames          */
+#define ETH_P_IEEE802154 0x00F6		/* IEEE802.15.4 frame		*/
+#define ETH_P_CAIF	0x00F7		/* ST-Ericsson CAIF protocol	*/
+
+/*
+ *	This is an Ethernet frame header.
+ */
+
+struct ethhdr {
+	unsigned char	h_dest[ETH_ALEN];	/* destination eth addr	*/
+	unsigned char	h_source[ETH_ALEN];	/* source ether addr	*/
+	__be16		h_proto;		/* packet type ID field	*/
+} __attribute__((packed));
+
+
+#endif /* _LINUX_IF_ETHER_H */
diff --git a/linux-headers/linux/virtio_net.h b/linux-headers/linux/virtio_net.h
new file mode 100644
index 0000000..c520203
--- /dev/null
+++ b/linux-headers/linux/virtio_net.h
@@ -0,0 +1,202 @@
+#ifndef _LINUX_VIRTIO_NET_H
+#define _LINUX_VIRTIO_NET_H
+/* This header is BSD licensed so anyone can use the definitions to implement
+ * compatible drivers/servers.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of IBM nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL IBM OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE. */
+#include <linux/types.h>
+#include <linux/virtio_ids.h>
+#include <linux/virtio_config.h>
+#include <linux/if_ether.h>
+
+/* The feature bitmap for virtio net */
+#define VIRTIO_NET_F_CSUM	0	/* Host handles pkts w/ partial csum */
+#define VIRTIO_NET_F_GUEST_CSUM	1	/* Guest handles pkts w/ partial csum */
+#define VIRTIO_NET_F_MAC	5	/* Host has given MAC address. */
+#define VIRTIO_NET_F_GSO	6	/* Host handles pkts w/ any GSO type */
+#define VIRTIO_NET_F_GUEST_TSO4	7	/* Guest can handle TSOv4 in. */
+#define VIRTIO_NET_F_GUEST_TSO6	8	/* Guest can handle TSOv6 in. */
+#define VIRTIO_NET_F_GUEST_ECN	9	/* Guest can handle TSO[6] w/ ECN in. */
+#define VIRTIO_NET_F_GUEST_UFO	10	/* Guest can handle UFO in. */
+#define VIRTIO_NET_F_HOST_TSO4	11	/* Host can handle TSOv4 in. */
+#define VIRTIO_NET_F_HOST_TSO6	12	/* Host can handle TSOv6 in. */
+#define VIRTIO_NET_F_HOST_ECN	13	/* Host can handle TSO[6] w/ ECN in. */
+#define VIRTIO_NET_F_HOST_UFO	14	/* Host can handle UFO in. */
+#define VIRTIO_NET_F_MRG_RXBUF	15	/* Host can merge receive buffers. */
+#define VIRTIO_NET_F_STATUS	16	/* virtio_net_config.status available */
+#define VIRTIO_NET_F_CTRL_VQ	17	/* Control channel available */
+#define VIRTIO_NET_F_CTRL_RX	18	/* Control channel RX mode support */
+#define VIRTIO_NET_F_CTRL_VLAN	19	/* Control channel VLAN filtering */
+#define VIRTIO_NET_F_CTRL_RX_EXTRA 20	/* Extra RX mode control support */
+#define VIRTIO_NET_F_GUEST_ANNOUNCE 21	/* Guest can announce device on the
+					 * network */
+#define VIRTIO_NET_F_MQ	22	/* Device supports Receive Flow
+					 * Steering */
+#define VIRTIO_NET_F_CTRL_MAC_ADDR 23	/* Set MAC address */
+
+#define VIRTIO_NET_S_LINK_UP	1	/* Link is up */
+#define VIRTIO_NET_S_ANNOUNCE	2	/* Announcement is needed */
+
+struct virtio_net_config {
+	/* The config defining mac address (if VIRTIO_NET_F_MAC) */
+	__u8 mac[6];
+	/* See VIRTIO_NET_F_STATUS and VIRTIO_NET_S_* above */
+	__u16 status;
+	/* Maximum number of each of transmit and receive queues;
+	 * see VIRTIO_NET_F_MQ and VIRTIO_NET_CTRL_MQ.
+	 * Legal values are between 1 and 0x8000
+	 */
+	__u16 max_virtqueue_pairs;
+} __attribute__((packed));
+
+/* This is the first element of the scatter-gather list.  If you don't
+ * specify GSO or CSUM features, you can simply ignore the header. */
+struct virtio_net_hdr {
+#define VIRTIO_NET_HDR_F_NEEDS_CSUM	1	// Use csum_start, csum_offset
+#define VIRTIO_NET_HDR_F_DATA_VALID	2	// Csum is valid
+	__u8 flags;
+#define VIRTIO_NET_HDR_GSO_NONE		0	// Not a GSO frame
+#define VIRTIO_NET_HDR_GSO_TCPV4	1	// GSO frame, IPv4 TCP (TSO)
+#define VIRTIO_NET_HDR_GSO_UDP		3	// GSO frame, IPv4 UDP (UFO)
+#define VIRTIO_NET_HDR_GSO_TCPV6	4	// GSO frame, IPv6 TCP
+#define VIRTIO_NET_HDR_GSO_ECN		0x80	// TCP has ECN set
+	__u8 gso_type;
+	__u16 hdr_len;		/* Ethernet + IP + tcp/udp hdrs */
+	__u16 gso_size;		/* Bytes to append to hdr_len per frame */
+	__u16 csum_start;	/* Position to start checksumming from */
+	__u16 csum_offset;	/* Offset after that to place checksum */
+};
+
+/* This is the version of the header to use when the MRG_RXBUF
+ * feature has been negotiated. */
+struct virtio_net_hdr_mrg_rxbuf {
+	struct virtio_net_hdr hdr;
+	__u16 num_buffers;	/* Number of merged rx buffers */
+};
+
+/*
+ * Control virtqueue data structures
+ *
+ * The control virtqueue expects a header in the first sg entry
+ * and an ack/status response in the last entry.  Data for the
+ * command goes in between.
+ */
+struct virtio_net_ctrl_hdr {
+	__u8 class;
+	__u8 cmd;
+} __attribute__((packed));
+
+typedef __u8 virtio_net_ctrl_ack;
+
+#define VIRTIO_NET_OK     0
+#define VIRTIO_NET_ERR    1
+
+/*
+ * Control the RX mode, ie. promisucous, allmulti, etc...
+ * All commands require an "out" sg entry containing a 1 byte
+ * state value, zero = disable, non-zero = enable.  Commands
+ * 0 and 1 are supported with the VIRTIO_NET_F_CTRL_RX feature.
+ * Commands 2-5 are added with VIRTIO_NET_F_CTRL_RX_EXTRA.
+ */
+#define VIRTIO_NET_CTRL_RX    0
+ #define VIRTIO_NET_CTRL_RX_PROMISC      0
+ #define VIRTIO_NET_CTRL_RX_ALLMULTI     1
+ #define VIRTIO_NET_CTRL_RX_ALLUNI       2
+ #define VIRTIO_NET_CTRL_RX_NOMULTI      3
+ #define VIRTIO_NET_CTRL_RX_NOUNI        4
+ #define VIRTIO_NET_CTRL_RX_NOBCAST      5
+
+/*
+ * Control the MAC
+ *
+ * The MAC filter table is managed by the hypervisor, the guest should
+ * assume the size is infinite.  Filtering should be considered
+ * non-perfect, ie. based on hypervisor resources, the guest may
+ * received packets from sources not specified in the filter list.
+ *
+ * In addition to the class/cmd header, the TABLE_SET command requires
+ * two out scatterlists.  Each contains a 4 byte count of entries followed
+ * by a concatenated byte stream of the ETH_ALEN MAC addresses.  The
+ * first sg list contains unicast addresses, the second is for multicast.
+ * This functionality is present if the VIRTIO_NET_F_CTRL_RX feature
+ * is available.
+ *
+ * The ADDR_SET command requests one out scatterlist, it contains a
+ * 6 bytes MAC address. This functionality is present if the
+ * VIRTIO_NET_F_CTRL_MAC_ADDR feature is available.
+ */
+struct virtio_net_ctrl_mac {
+	__u32 entries;
+	__u8 macs[][ETH_ALEN];
+} __attribute__((packed));
+
+#define VIRTIO_NET_CTRL_MAC    1
+ #define VIRTIO_NET_CTRL_MAC_TABLE_SET        0
+ #define VIRTIO_NET_CTRL_MAC_ADDR_SET         1
+
+/*
+ * Control VLAN filtering
+ *
+ * The VLAN filter table is controlled via a simple ADD/DEL interface.
+ * VLAN IDs not added may be filterd by the hypervisor.  Del is the
+ * opposite of add.  Both commands expect an out entry containing a 2
+ * byte VLAN ID.  VLAN filterting is available with the
+ * VIRTIO_NET_F_CTRL_VLAN feature bit.
+ */
+#define VIRTIO_NET_CTRL_VLAN       2
+ #define VIRTIO_NET_CTRL_VLAN_ADD             0
+ #define VIRTIO_NET_CTRL_VLAN_DEL             1
+
+/*
+ * Control link announce acknowledgement
+ *
+ * The command VIRTIO_NET_CTRL_ANNOUNCE_ACK is used to indicate that
+ * driver has recevied the notification; device would clear the
+ * VIRTIO_NET_S_ANNOUNCE bit in the status field after it receives
+ * this command.
+ */
+#define VIRTIO_NET_CTRL_ANNOUNCE       3
+ #define VIRTIO_NET_CTRL_ANNOUNCE_ACK         0
+
+/*
+ * Control Receive Flow Steering
+ *
+ * The command VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET
+ * enables Receive Flow Steering, specifying the number of the transmit and
+ * receive queues that will be used. After the command is consumed and acked by
+ * the device, the device will not steer new packets on receive virtqueues
+ * other than specified nor read from transmit virtqueues other than specified.
+ * Accordingly, driver should not transmit new packets  on virtqueues other than
+ * specified.
+ */
+struct virtio_net_ctrl_mq {
+	__u16 virtqueue_pairs;
+};
+
+#define VIRTIO_NET_CTRL_MQ   4
+ #define VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET        0
+ #define VIRTIO_NET_CTRL_MQ_VQ_PAIRS_MIN        1
+ #define VIRTIO_NET_CTRL_MQ_VQ_PAIRS_MAX        0x8000
+
+#endif /* _LINUX_VIRTIO_NET_H */
-- 
MST

[Qemu-devel] [PATCH v2 05/11] virtio-blk: switch to linux-headers

[Michael S. Tsirkin]

It's easier to keep everything in sync if
we just use linux headers for virtio constants.
Add virtio_blk.h header from linux 3.10-rc1, and
remove duplicate symbols from virtio-blk.h

In particular, it turns out that linux does
not have struct virtio_blk_inhdr for the status
field, so make this struct match the qemu coding style.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 hw/block/dataplane/virtio-blk.c  |  12 ++--
 hw/block/virtio-blk.c            |  10 +--
 include/hw/virtio/virtio-blk.h   |  86 ++------------------------
 linux-headers/linux/virtio_blk.h | 128 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 144 insertions(+), 92 deletions(-)
 create mode 100644 linux-headers/linux/virtio_blk.h

diff --git a/hw/block/dataplane/virtio-blk.c b/hw/block/dataplane/virtio-blk.c
index 0356665..e582ff3 100644
--- a/hw/block/dataplane/virtio-blk.c
+++ b/hw/block/dataplane/virtio-blk.c
@@ -87,7 +87,7 @@ static void complete_request(struct iocb *iocb, ssize_t ret, void *opaque)
 {
     VirtIOBlockDataPlane *s = opaque;
     VirtIOBlockRequest *req = container_of(iocb, VirtIOBlockRequest, iocb);
-    struct virtio_blk_inhdr hdr;
+    VirtIOBlockInHdr hdr;
     int len;
 
     if (likely(ret >= 0)) {
@@ -128,7 +128,7 @@ static void complete_request(struct iocb *iocb, ssize_t ret, void *opaque)
 static void complete_request_early(VirtIOBlockDataPlane *s, unsigned int head,
                                    QEMUIOVector *inhdr, unsigned char status)
 {
-    struct virtio_blk_inhdr hdr = {
+    VirtIOBlockInHdr hdr = {
         .status = status,
     };
 
@@ -215,16 +215,16 @@ static int process_request(IOQueue *ioq, struct iovec iov[],
 
     /* Grab inhdr for later */
     in_size = iov_size(in_iov, in_num);
-    if (in_size < sizeof(struct virtio_blk_inhdr)) {
+    if (in_size < sizeof(VirtIOBlockInHdr)) {
         error_report("virtio_blk request inhdr too short");
         return -EFAULT;
     }
     inhdr = g_slice_new(QEMUIOVector);
     qemu_iovec_init(inhdr, 1);
     qemu_iovec_concat_iov(inhdr, in_iov, in_num,
-            in_size - sizeof(struct virtio_blk_inhdr),
-            sizeof(struct virtio_blk_inhdr));
-    iov_discard_back(in_iov, &in_num, sizeof(struct virtio_blk_inhdr));
+            in_size - sizeof(VirtIOBlockInHdr),
+            sizeof(VirtIOBlockInHdr));
+    iov_discard_back(in_iov, &in_num, sizeof(VirtIOBlockInHdr));
 
     /* TODO Linux sets the barrier bit even when not advertised! */
     outhdr.type &= ~VIRTIO_BLK_T_BARRIER;
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index cf12469..d8131f7 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -30,7 +30,7 @@ typedef struct VirtIOBlockReq
 {
     VirtIOBlock *dev;
     VirtQueueElement elem;
-    struct virtio_blk_inhdr *in;
+    VirtIOBlockInHdr *in;
     struct virtio_blk_outhdr *out;
     struct virtio_scsi_inhdr *scsi;
     QEMUIOVector qiov;
@@ -487,11 +487,11 @@ static void virtio_blk_update_config(VirtIODevice *vdev, uint8_t *config)
     memset(&blkcfg, 0, sizeof(blkcfg));
     stq_raw(&blkcfg.capacity, capacity);
     stl_raw(&blkcfg.seg_max, 128 - 2);
-    stw_raw(&blkcfg.cylinders, s->conf->cyls);
+    stw_raw(&blkcfg.geometry.cylinders, s->conf->cyls);
     stl_raw(&blkcfg.blk_size, blk_size);
     stw_raw(&blkcfg.min_io_size, s->conf->min_io_size / blk_size);
     stw_raw(&blkcfg.opt_io_size, s->conf->opt_io_size / blk_size);
-    blkcfg.heads = s->conf->heads;
+    blkcfg.geometry.heads = s->conf->heads;
     /*
      * We must ensure that the block device capacity is a multiple of
      * the logical block size. If that is not the case, let's use
@@ -504,9 +504,9 @@ static void virtio_blk_update_config(VirtIODevice *vdev, uint8_t *config)
      * per track (cylinder).
      */
     if (bdrv_getlength(s->bs) /  s->conf->heads / s->conf->secs % blk_size) {
-        blkcfg.sectors = s->conf->secs & ~s->sector_mask;
+        blkcfg.geometry.sectors = s->conf->secs & ~s->sector_mask;
     } else {
-        blkcfg.sectors = s->conf->secs;
+        blkcfg.geometry.sectors = s->conf->secs;
     }
     blkcfg.size_max = 0;
     blkcfg.physical_block_exp = get_physical_block_exp(s->conf);
diff --git a/include/hw/virtio/virtio-blk.h b/include/hw/virtio/virtio-blk.h
index fc71853..911df23 100644
--- a/include/hw/virtio/virtio-blk.h
+++ b/include/hw/virtio/virtio-blk.h
@@ -16,95 +16,19 @@
 
 #include "hw/virtio/virtio.h"
 #include "hw/block/block.h"
+#include "linux/virtio_blk.h"
+#include "linux/virtio_ids.h"
 
 #define TYPE_VIRTIO_BLK "virtio-blk-device"
 #define VIRTIO_BLK(obj) \
         OBJECT_CHECK(VirtIOBlock, (obj), TYPE_VIRTIO_BLK)
 
-/* from Linux's linux/virtio_blk.h */
-
-/* The ID for virtio_block */
-#define VIRTIO_ID_BLOCK 2
-
-/* Feature bits */
-#define VIRTIO_BLK_F_BARRIER    0       /* Does host support barriers? */
-#define VIRTIO_BLK_F_SIZE_MAX   1       /* Indicates maximum segment size */
-#define VIRTIO_BLK_F_SEG_MAX    2       /* Indicates maximum # of segments */
-#define VIRTIO_BLK_F_GEOMETRY   4       /* Indicates support of legacy geometry */
-#define VIRTIO_BLK_F_RO         5       /* Disk is read-only */
-#define VIRTIO_BLK_F_BLK_SIZE   6       /* Block size of disk is available*/
-#define VIRTIO_BLK_F_SCSI       7       /* Supports scsi command passthru */
-/* #define VIRTIO_BLK_F_IDENTIFY   8       ATA IDENTIFY supported, DEPRECATED */
-#define VIRTIO_BLK_F_WCE        9       /* write cache enabled */
-#define VIRTIO_BLK_F_TOPOLOGY   10      /* Topology information is available */
-#define VIRTIO_BLK_F_CONFIG_WCE 11      /* write cache configurable */
-
-#define VIRTIO_BLK_ID_BYTES     20      /* ID string length */
-
-struct virtio_blk_config
-{
-    uint64_t capacity;
-    uint32_t size_max;
-    uint32_t seg_max;
-    uint16_t cylinders;
-    uint8_t heads;
-    uint8_t sectors;
-    uint32_t blk_size;
-    uint8_t physical_block_exp;
-    uint8_t alignment_offset;
-    uint16_t min_io_size;
-    uint32_t opt_io_size;
-    uint8_t wce;
-} QEMU_PACKED;
-
-/* These two define direction. */
-#define VIRTIO_BLK_T_IN         0
-#define VIRTIO_BLK_T_OUT        1
-
-/* This bit says it's a scsi command, not an actual read or write. */
-#define VIRTIO_BLK_T_SCSI_CMD   2
-
-/* Flush the volatile write cache */
-#define VIRTIO_BLK_T_FLUSH      4
-
-/* return the device ID string */
-#define VIRTIO_BLK_T_GET_ID     8
-
-/* Barrier before this op. */
-#define VIRTIO_BLK_T_BARRIER    0x80000000
-
-/* This is the first element of the read scatter-gather list. */
-struct virtio_blk_outhdr
-{
-    /* VIRTIO_BLK_T* */
-    uint32_t type;
-    /* io priority. */
-    uint32_t ioprio;
-    /* Sector (ie. 512 byte offset) */
-    uint64_t sector;
-};
-
-#define VIRTIO_BLK_S_OK         0
-#define VIRTIO_BLK_S_IOERR      1
-#define VIRTIO_BLK_S_UNSUPP     2
-
 /* This is the last element of the write scatter-gather list */
-struct virtio_blk_inhdr
-{
+typedef struct VirtIOBlockInHdr {
     unsigned char status;
-};
-
-/* SCSI pass-through header */
-struct virtio_scsi_inhdr
-{
-    uint32_t errors;
-    uint32_t data_len;
-    uint32_t sense_len;
-    uint32_t residual;
-};
+} VirtIOBlockInHdr;
 
-struct VirtIOBlkConf
-{
+struct VirtIOBlkConf {
     BlockConf conf;
     char *serial;
     uint32_t scsi;
diff --git a/linux-headers/linux/virtio_blk.h b/linux-headers/linux/virtio_blk.h
new file mode 100644
index 0000000..8270c14
--- /dev/null
+++ b/linux-headers/linux/virtio_blk.h
@@ -0,0 +1,128 @@
+#ifndef _LINUX_VIRTIO_BLK_H
+#define _LINUX_VIRTIO_BLK_H
+/* This header is BSD licensed so anyone can use the definitions to implement
+ * compatible drivers/servers.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of IBM nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL IBM OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE. */
+#include <linux/types.h>
+#include <linux/virtio_ids.h>
+#include <linux/virtio_config.h>
+
+/* Feature bits */
+#define VIRTIO_BLK_F_BARRIER	0	/* Does host support barriers? */
+#define VIRTIO_BLK_F_SIZE_MAX	1	/* Indicates maximum segment size */
+#define VIRTIO_BLK_F_SEG_MAX	2	/* Indicates maximum # of segments */
+#define VIRTIO_BLK_F_GEOMETRY	4	/* Legacy geometry available  */
+#define VIRTIO_BLK_F_RO		5	/* Disk is read-only */
+#define VIRTIO_BLK_F_BLK_SIZE	6	/* Block size of disk is available*/
+#define VIRTIO_BLK_F_SCSI	7	/* Supports scsi command passthru */
+#define VIRTIO_BLK_F_WCE	9	/* Writeback mode enabled after reset */
+#define VIRTIO_BLK_F_TOPOLOGY	10	/* Topology information is available */
+#define VIRTIO_BLK_F_CONFIG_WCE	11	/* Writeback mode available in config */
+
+/* Old (deprecated) name for VIRTIO_BLK_F_WCE. */
+#define VIRTIO_BLK_F_FLUSH VIRTIO_BLK_F_WCE
+
+#define VIRTIO_BLK_ID_BYTES	20	/* ID string length */
+
+struct virtio_blk_config {
+	/* The capacity (in 512-byte sectors). */
+	__u64 capacity;
+	/* The maximum segment size (if VIRTIO_BLK_F_SIZE_MAX) */
+	__u32 size_max;
+	/* The maximum number of segments (if VIRTIO_BLK_F_SEG_MAX) */
+	__u32 seg_max;
+	/* geometry the device (if VIRTIO_BLK_F_GEOMETRY) */
+	struct virtio_blk_geometry {
+		__u16 cylinders;
+		__u8 heads;
+		__u8 sectors;
+	} geometry;
+
+	/* block size of device (if VIRTIO_BLK_F_BLK_SIZE) */
+	__u32 blk_size;
+
+	/* the next 4 entries are guarded by VIRTIO_BLK_F_TOPOLOGY  */
+	/* exponent for physical block per logical block. */
+	__u8 physical_block_exp;
+	/* alignment offset in logical blocks. */
+	__u8 alignment_offset;
+	/* minimum I/O size without performance penalty in logical blocks. */
+	__u16 min_io_size;
+	/* optimal sustained I/O size in logical blocks. */
+	__u32 opt_io_size;
+
+	/* writeback mode (if VIRTIO_BLK_F_CONFIG_WCE) */
+	__u8 wce;
+} __attribute__((packed));
+
+/*
+ * Command types
+ *
+ * Usage is a bit tricky as some bits are used as flags and some are not.
+ *
+ * Rules:
+ *   VIRTIO_BLK_T_OUT may be combined with VIRTIO_BLK_T_SCSI_CMD or
+ *   VIRTIO_BLK_T_BARRIER.  VIRTIO_BLK_T_FLUSH is a command of its own
+ *   and may not be combined with any of the other flags.
+ */
+
+/* These two define direction. */
+#define VIRTIO_BLK_T_IN		0
+#define VIRTIO_BLK_T_OUT	1
+
+/* This bit says it's a scsi command, not an actual read or write. */
+#define VIRTIO_BLK_T_SCSI_CMD	2
+
+/* Cache flush command */
+#define VIRTIO_BLK_T_FLUSH	4
+
+/* Get device ID command */
+#define VIRTIO_BLK_T_GET_ID    8
+
+/* Barrier before this op. */
+#define VIRTIO_BLK_T_BARRIER	0x80000000
+
+/* This is the first element of the read scatter-gather list. */
+struct virtio_blk_outhdr {
+	/* VIRTIO_BLK_T* */
+	__u32 type;
+	/* io priority. */
+	__u32 ioprio;
+	/* Sector (ie. 512 byte offset) */
+	__u64 sector;
+};
+
+struct virtio_scsi_inhdr {
+	__u32 errors;
+	__u32 data_len;
+	__u32 sense_len;
+	__u32 residual;
+};
+
+/* And this is the final byte of the write scatter-gather list. */
+#define VIRTIO_BLK_S_OK		0
+#define VIRTIO_BLK_S_IOERR	1
+#define VIRTIO_BLK_S_UNSUPP	2
+#endif /* _LINUX_VIRTIO_BLK_H */
-- 
MST

[Qemu-devel] [PATCH v2 06/11] virtio-balloon: switch to linux-headers

[Michael S. Tsirkin]

It's easier to keep everything in sync if
we just use linux headers for virtio constants.
Add virtio_balloon.h header from linux 3.10-rc1, and
remove duplicate symbols from virtio-balloon.h

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 hw/virtio/virtio-balloon.c           |  2 +-
 include/hw/virtio/virtio-balloon.h   | 37 ++--------------------
 linux-headers/linux/virtio_balloon.h | 59 ++++++++++++++++++++++++++++++++++++
 3 files changed, 63 insertions(+), 35 deletions(-)
 create mode 100644 linux-headers/linux/virtio_balloon.h

diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index d669756..548508b 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -216,7 +216,7 @@ static void virtio_balloon_receive_stats(VirtIODevice *vdev, VirtQueue *vq)
 {
     VirtIOBalloon *s = VIRTIO_BALLOON(vdev);
     VirtQueueElement *elem = &s->stats_vq_elem;
-    VirtIOBalloonStat stat;
+    struct virtio_balloon_stat stat;
     size_t offset = 0;
     qemu_timeval tv;
 
diff --git a/include/hw/virtio/virtio-balloon.h b/include/hw/virtio/virtio-balloon.h
index f863bfe..dc0702d 100644
--- a/include/hw/virtio/virtio-balloon.h
+++ b/include/hw/virtio/virtio-balloon.h
@@ -17,45 +17,14 @@
 
 #include "hw/virtio/virtio.h"
 #include "hw/pci/pci.h"
+#include "linux/virtio_balloon.h"
+#include "linux/virtio_ids.h"
+
 
 #define TYPE_VIRTIO_BALLOON "virtio-balloon-device"
 #define VIRTIO_BALLOON(obj) \
         OBJECT_CHECK(VirtIOBalloon, (obj), TYPE_VIRTIO_BALLOON)
 
-/* from Linux's linux/virtio_balloon.h */
-
-/* The ID for virtio_balloon */
-#define VIRTIO_ID_BALLOON 5
-
-/* The feature bitmap for virtio balloon */
-#define VIRTIO_BALLOON_F_MUST_TELL_HOST 0 /* Tell before reclaiming pages */
-#define VIRTIO_BALLOON_F_STATS_VQ 1       /* Memory stats virtqueue */
-
-/* Size of a PFN in the balloon interface. */
-#define VIRTIO_BALLOON_PFN_SHIFT 12
-
-struct virtio_balloon_config
-{
-    /* Number of pages host wants Guest to give up. */
-    uint32_t num_pages;
-    /* Number of pages we've actually got in balloon. */
-    uint32_t actual;
-};
-
-/* Memory Statistics */
-#define VIRTIO_BALLOON_S_SWAP_IN  0   /* Amount of memory swapped in */
-#define VIRTIO_BALLOON_S_SWAP_OUT 1   /* Amount of memory swapped out */
-#define VIRTIO_BALLOON_S_MAJFLT   2   /* Number of major faults */
-#define VIRTIO_BALLOON_S_MINFLT   3   /* Number of minor faults */
-#define VIRTIO_BALLOON_S_MEMFREE  4   /* Total amount of free memory */
-#define VIRTIO_BALLOON_S_MEMTOT   5   /* Total amount of memory */
-#define VIRTIO_BALLOON_S_NR       6
-
-typedef struct VirtIOBalloonStat {
-    uint16_t tag;
-    uint64_t val;
-} QEMU_PACKED VirtIOBalloonStat;
-
 typedef struct VirtIOBalloon {
     VirtIODevice parent_obj;
     VirtQueue *ivq, *dvq, *svq;
diff --git a/linux-headers/linux/virtio_balloon.h b/linux-headers/linux/virtio_balloon.h
new file mode 100644
index 0000000..5e26f61
--- /dev/null
+++ b/linux-headers/linux/virtio_balloon.h
@@ -0,0 +1,59 @@
+#ifndef _LINUX_VIRTIO_BALLOON_H
+#define _LINUX_VIRTIO_BALLOON_H
+/* This header is BSD licensed so anyone can use the definitions to implement
+ * compatible drivers/servers.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of IBM nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL IBM OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE. */
+#include <linux/virtio_ids.h>
+#include <linux/virtio_config.h>
+
+/* The feature bitmap for virtio balloon */
+#define VIRTIO_BALLOON_F_MUST_TELL_HOST	0 /* Tell before reclaiming pages */
+#define VIRTIO_BALLOON_F_STATS_VQ	1 /* Memory Stats virtqueue */
+
+/* Size of a PFN in the balloon interface. */
+#define VIRTIO_BALLOON_PFN_SHIFT 12
+
+struct virtio_balloon_config
+{
+	/* Number of pages host wants Guest to give up. */
+	__le32 num_pages;
+	/* Number of pages we've actually got in balloon. */
+	__le32 actual;
+};
+
+#define VIRTIO_BALLOON_S_SWAP_IN  0   /* Amount of memory swapped in */
+#define VIRTIO_BALLOON_S_SWAP_OUT 1   /* Amount of memory swapped out */
+#define VIRTIO_BALLOON_S_MAJFLT   2   /* Number of major faults */
+#define VIRTIO_BALLOON_S_MINFLT   3   /* Number of minor faults */
+#define VIRTIO_BALLOON_S_MEMFREE  4   /* Total amount of free memory */
+#define VIRTIO_BALLOON_S_MEMTOT   5   /* Total amount of memory */
+#define VIRTIO_BALLOON_S_NR       6
+
+struct virtio_balloon_stat {
+	__u16 tag;
+	__u64 val;
+} __attribute__((packed));
+
+#endif /* _LINUX_VIRTIO_BALLOON_H */
-- 
MST

[Qemu-devel] [PATCH v2 07/11] virtio-rng: switch to linux-headers

[Michael S. Tsirkin]

It's easier to keep everything in sync if
we just use linux headers for virtio constants.
Add virtio_rng.h header from linux 3.10-rc1, and
remove duplicate symbols from virtio-rng.h

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 include/hw/virtio/virtio-rng.h   | 5 ++---
 linux-headers/linux/virtio_rng.h | 8 ++++++++
 2 files changed, 10 insertions(+), 3 deletions(-)
 create mode 100644 linux-headers/linux/virtio_rng.h

diff --git a/include/hw/virtio/virtio-rng.h b/include/hw/virtio/virtio-rng.h
index debaa15..a0cc62e 100644
--- a/include/hw/virtio/virtio-rng.h
+++ b/include/hw/virtio/virtio-rng.h
@@ -14,14 +14,13 @@
 
 #include "sysemu/rng.h"
 #include "sysemu/rng-random.h"
+#include "linux/virtio_rng.h"
+#include "linux/virtio_ids.h"
 
 #define TYPE_VIRTIO_RNG "virtio-rng-device"
 #define VIRTIO_RNG(obj) \
         OBJECT_CHECK(VirtIORNG, (obj), TYPE_VIRTIO_RNG)
 
-/* The Virtio ID for the virtio rng device */
-#define VIRTIO_ID_RNG    4
-
 struct VirtIORNGConf {
     RngBackend *rng;
     uint64_t max_bytes;
diff --git a/linux-headers/linux/virtio_rng.h b/linux-headers/linux/virtio_rng.h
new file mode 100644
index 0000000..c4d5de8
--- /dev/null
+++ b/linux-headers/linux/virtio_rng.h
@@ -0,0 +1,8 @@
+#ifndef _LINUX_VIRTIO_RNG_H
+#define _LINUX_VIRTIO_RNG_H
+/* This header is BSD licensed so anyone can use the definitions to implement
+ * compatible drivers/servers. */
+#include <linux/virtio_ids.h>
+#include <linux/virtio_config.h>
+
+#endif /* _LINUX_VIRTIO_RNG_H */
-- 
MST

[Qemu-devel] [PATCH v2 08/11] virtio-console: switch to linux-headers

[Michael S. Tsirkin]

It's easier to keep everything in sync if
we just use linux headers for virtio constants.
Add virtio_console.h header from linux 3.10-rc1, and
remove duplicate symbols from virtio-serial.h

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 include/hw/virtio/virtio-serial.h    | 38 +-----------------
 linux-headers/linux/virtio_console.h | 74 ++++++++++++++++++++++++++++++++++++
 2 files changed, 75 insertions(+), 37 deletions(-)
 create mode 100644 linux-headers/linux/virtio_console.h

diff --git a/include/hw/virtio/virtio-serial.h b/include/hw/virtio/virtio-serial.h
index 1d2040b..7dd76ab 100644
--- a/include/hw/virtio/virtio-serial.h
+++ b/include/hw/virtio/virtio-serial.h
@@ -17,49 +17,13 @@
 
 #include "hw/qdev.h"
 #include "hw/virtio/virtio.h"
-
-/* == Interface shared between the guest kernel and qemu == */
-
-/* The Virtio ID for virtio console / serial ports */
-#define VIRTIO_ID_CONSOLE		3
-
-/* Features supported */
-#define VIRTIO_CONSOLE_F_MULTIPORT	1
-
-#define VIRTIO_CONSOLE_BAD_ID           (~(uint32_t)0)
-
-struct virtio_console_config {
-    /*
-     * These two fields are used by VIRTIO_CONSOLE_F_SIZE which
-     * isn't implemented here yet
-     */
-    uint16_t cols;
-    uint16_t rows;
-
-    uint32_t max_nr_ports;
-} QEMU_PACKED;
-
-struct virtio_console_control {
-    uint32_t id;		/* Port number */
-    uint16_t event;		/* The kind of control event (see below) */
-    uint16_t value;		/* Extra information for the key */
-};
+#include "linux/virtio_console.h"
 
 struct virtio_serial_conf {
     /* Max. number of ports we can have for a virtio-serial device */
     uint32_t max_virtserial_ports;
 };
 
-/* Some events for the internal messages (control packets) */
-#define VIRTIO_CONSOLE_DEVICE_READY	0
-#define VIRTIO_CONSOLE_PORT_ADD		1
-#define VIRTIO_CONSOLE_PORT_REMOVE	2
-#define VIRTIO_CONSOLE_PORT_READY	3
-#define VIRTIO_CONSOLE_CONSOLE_PORT	4
-#define VIRTIO_CONSOLE_RESIZE		5
-#define VIRTIO_CONSOLE_PORT_OPEN	6
-#define VIRTIO_CONSOLE_PORT_NAME	7
-
 /* == In-qemu interface == */
 
 #define TYPE_VIRTIO_SERIAL_PORT "virtio-serial-port"
diff --git a/linux-headers/linux/virtio_console.h b/linux-headers/linux/virtio_console.h
new file mode 100644
index 0000000..5403535
--- /dev/null
+++ b/linux-headers/linux/virtio_console.h
@@ -0,0 +1,74 @@
+/*
+ * This header, excluding the #ifdef __KERNEL__ part, is BSD licensed so
+ * anyone can use the definitions to implement compatible drivers/servers:
+ *
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of IBM nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL IBM OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * Copyright (C) Red Hat, Inc., 2009, 2010, 2011
+ * Copyright (C) Amit Shah <amit.shah@redhat.com>, 2009, 2010, 2011
+ */
+#ifndef _LINUX_VIRTIO_CONSOLE_H
+#define _LINUX_VIRTIO_CONSOLE_H
+#include <linux/types.h>
+#include <linux/virtio_ids.h>
+#include <linux/virtio_config.h>
+
+/* Feature bits */
+#define VIRTIO_CONSOLE_F_SIZE	0	/* Does host provide console size? */
+#define VIRTIO_CONSOLE_F_MULTIPORT 1	/* Does host provide multiple ports? */
+
+#define VIRTIO_CONSOLE_BAD_ID		(~(__u32)0)
+
+struct virtio_console_config {
+	/* colums of the screens */
+	__u16 cols;
+	/* rows of the screens */
+	__u16 rows;
+	/* max. number of ports this device can hold */
+	__u32 max_nr_ports;
+} __attribute__((packed));
+
+/*
+ * A message that's passed between the Host and the Guest for a
+ * particular port.
+ */
+struct virtio_console_control {
+	__u32 id;		/* Port number */
+	__u16 event;		/* The kind of control event (see below) */
+	__u16 value;		/* Extra information for the key */
+};
+
+/* Some events for control messages */
+#define VIRTIO_CONSOLE_DEVICE_READY	0
+#define VIRTIO_CONSOLE_PORT_ADD		1
+#define VIRTIO_CONSOLE_PORT_REMOVE	2
+#define VIRTIO_CONSOLE_PORT_READY	3
+#define VIRTIO_CONSOLE_CONSOLE_PORT	4
+#define VIRTIO_CONSOLE_RESIZE		5
+#define VIRTIO_CONSOLE_PORT_OPEN	6
+#define VIRTIO_CONSOLE_PORT_NAME	7
+
+
+#endif /* _LINUX_VIRTIO_CONSOLE_H */
-- 
MST

[Qemu-devel] [PATCH v2 09/11] virtio: add virtio_ids from linux-headers

[Michael S. Tsirkin]

All imported headers will use it.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 linux-headers/linux/virtio_ids.h | 43 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 linux-headers/linux/virtio_ids.h

diff --git a/linux-headers/linux/virtio_ids.h b/linux-headers/linux/virtio_ids.h
new file mode 100644
index 0000000..284fc3a
--- /dev/null
+++ b/linux-headers/linux/virtio_ids.h
@@ -0,0 +1,43 @@
+#ifndef _LINUX_VIRTIO_IDS_H
+#define _LINUX_VIRTIO_IDS_H
+/*
+ * Virtio IDs
+ *
+ * This header is BSD licensed so anyone can use the definitions to implement
+ * compatible drivers/servers.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of IBM nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL IBM OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE. */
+
+#define VIRTIO_ID_NET		1 /* virtio net */
+#define VIRTIO_ID_BLOCK		2 /* virtio block */
+#define VIRTIO_ID_CONSOLE	3 /* virtio console */
+#define VIRTIO_ID_RNG		4 /* virtio rng */
+#define VIRTIO_ID_BALLOON	5 /* virtio balloon */
+#define VIRTIO_ID_RPMSG		7 /* virtio remote processor messaging */
+#define VIRTIO_ID_SCSI		8 /* virtio scsi */
+#define VIRTIO_ID_9P		9 /* 9p virtio console */
+#define VIRTIO_ID_RPROC_SERIAL 11 /* virtio remoteproc serial link */
+#define VIRTIO_ID_CAIF	       12 /* Virtio caif */
+
+#endif /* _LINUX_VIRTIO_IDS_H */
-- 
MST

[Qemu-devel] [PATCH v2 10/11] virtio-pci: switch to linux-headers

[Michael S. Tsirkin]

It's easier to keep everything in sync if
we just use linux headers for virtio constants.
Add virtio_pci.h header from linux 3.10-rc1, and
remove duplicate symbols from virtio-pci.h

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 hw/virtio/virtio-pci.c           | 49 +++-----------------
 linux-headers/linux/virtio_pci.h | 97 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 102 insertions(+), 44 deletions(-)
 create mode 100644 linux-headers/linux/virtio_pci.h

diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 70d2c6b..8707463 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -34,53 +34,14 @@
 #include "qemu/range.h"
 #include "hw/virtio/virtio-bus.h"
 #include "qapi/visitor.h"
-
-/* from Linux's linux/virtio_pci.h */
-
-/* A 32-bit r/o bitmask of the features supported by the host */
-#define VIRTIO_PCI_HOST_FEATURES        0
-
-/* A 32-bit r/w bitmask of features activated by the guest */
-#define VIRTIO_PCI_GUEST_FEATURES       4
-
-/* A 32-bit r/w PFN for the currently selected queue */
-#define VIRTIO_PCI_QUEUE_PFN            8
-
-/* A 16-bit r/o queue size for the currently selected queue */
-#define VIRTIO_PCI_QUEUE_NUM            12
-
-/* A 16-bit r/w queue selector */
-#define VIRTIO_PCI_QUEUE_SEL            14
-
-/* A 16-bit r/w queue notifier */
-#define VIRTIO_PCI_QUEUE_NOTIFY         16
-
-/* An 8-bit device status register.  */
-#define VIRTIO_PCI_STATUS               18
-
-/* An 8-bit r/o interrupt status register.  Reading the value will return the
- * current contents of the ISR and will also clear it.  This is effectively
- * a read-and-acknowledge. */
-#define VIRTIO_PCI_ISR                  19
-
-/* MSI-X registers: only enabled if MSI-X is enabled. */
-/* A 16-bit vector for configuration changes. */
-#define VIRTIO_MSI_CONFIG_VECTOR        20
-/* A 16-bit vector for selected queue notifications. */
-#define VIRTIO_MSI_QUEUE_VECTOR         22
+#include "linux/virtio_pci.h"
 
 /* Config space size */
-#define VIRTIO_PCI_CONFIG_NOMSI         20
-#define VIRTIO_PCI_CONFIG_MSI           24
-#define VIRTIO_PCI_REGION_SIZE(dev)     (msix_present(dev) ? \
-                                         VIRTIO_PCI_CONFIG_MSI : \
-                                         VIRTIO_PCI_CONFIG_NOMSI)
+#define VIRTIO_PCI_REGION_SIZE(dev)     VIRTIO_PCI_CONFIG_OFF(msix_present(dev))
 
 /* The remaining space is defined by each driver as the per-driver
  * configuration space */
-#define VIRTIO_PCI_CONFIG(dev)          (msix_enabled(dev) ? \
-                                         VIRTIO_PCI_CONFIG_MSI : \
-                                         VIRTIO_PCI_CONFIG_NOMSI)
+#define VIRTIO_PCI_CONFIG_SIZE(dev)     VIRTIO_PCI_CONFIG_OFF(msix_enabled(dev))
 
 /* How many bits to shift physical queue address written to QUEUE_PFN.
  * 12 is historical, and due to x86 page size. */
@@ -386,7 +347,7 @@ static uint64_t virtio_pci_config_read(void *opaque, hwaddr addr,
                                        unsigned size)
 {
     VirtIOPCIProxy *proxy = opaque;
-    uint32_t config = VIRTIO_PCI_CONFIG(&proxy->pci_dev);
+    uint32_t config = VIRTIO_PCI_CONFIG_SIZE(&proxy->pci_dev);
     uint64_t val = 0;
     if (addr < config) {
         return virtio_ioport_read(proxy, addr);
@@ -417,7 +378,7 @@ static void virtio_pci_config_write(void *opaque, hwaddr addr,
                                     uint64_t val, unsigned size)
 {
     VirtIOPCIProxy *proxy = opaque;
-    uint32_t config = VIRTIO_PCI_CONFIG(&proxy->pci_dev);
+    uint32_t config = VIRTIO_PCI_CONFIG_SIZE(&proxy->pci_dev);
     if (addr < config) {
         virtio_ioport_write(proxy, addr, val);
         return;
diff --git a/linux-headers/linux/virtio_pci.h b/linux-headers/linux/virtio_pci.h
new file mode 100644
index 0000000..e5ec1ca
--- /dev/null
+++ b/linux-headers/linux/virtio_pci.h
@@ -0,0 +1,97 @@
+/*
+ * Virtio PCI driver
+ *
+ * This module allows virtio devices to be used over a virtual PCI device.
+ * This can be used with QEMU based VMMs like KVM or Xen.
+ *
+ * Copyright IBM Corp. 2007
+ *
+ * Authors:
+ *  Anthony Liguori  <aliguori@us.ibm.com>
+ *
+ * This header is BSD licensed so anyone can use the definitions to implement
+ * compatible drivers/servers.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of IBM nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL IBM OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#ifndef _LINUX_VIRTIO_PCI_H
+#define _LINUX_VIRTIO_PCI_H
+
+#include <linux/virtio_config.h>
+
+/* A 32-bit r/o bitmask of the features supported by the host */
+#define VIRTIO_PCI_HOST_FEATURES	0
+
+/* A 32-bit r/w bitmask of features activated by the guest */
+#define VIRTIO_PCI_GUEST_FEATURES	4
+
+/* A 32-bit r/w PFN for the currently selected queue */
+#define VIRTIO_PCI_QUEUE_PFN		8
+
+/* A 16-bit r/o queue size for the currently selected queue */
+#define VIRTIO_PCI_QUEUE_NUM		12
+
+/* A 16-bit r/w queue selector */
+#define VIRTIO_PCI_QUEUE_SEL		14
+
+/* A 16-bit r/w queue notifier */
+#define VIRTIO_PCI_QUEUE_NOTIFY		16
+
+/* An 8-bit device status register.  */
+#define VIRTIO_PCI_STATUS		18
+
+/* An 8-bit r/o interrupt status register.  Reading the value will return the
+ * current contents of the ISR and will also clear it.  This is effectively
+ * a read-and-acknowledge. */
+#define VIRTIO_PCI_ISR			19
+
+/* The bit of the ISR which indicates a device configuration change. */
+#define VIRTIO_PCI_ISR_CONFIG		0x2
+
+/* MSI-X registers: only enabled if MSI-X is enabled. */
+/* A 16-bit vector for configuration changes. */
+#define VIRTIO_MSI_CONFIG_VECTOR        20
+/* A 16-bit vector for selected queue notifications. */
+#define VIRTIO_MSI_QUEUE_VECTOR         22
+/* Vector value used to disable MSI for queue */
+#define VIRTIO_MSI_NO_VECTOR            0xffff
+
+/* The remaining space is defined by each driver as the per-driver
+ * configuration space */
+#define VIRTIO_PCI_CONFIG_OFF(msix_enabled)	((msix_enabled) ? 24 : 20)
+/* Deprecated: please use VIRTIO_PCI_CONFIG_OFF instead */
+#define VIRTIO_PCI_CONFIG(dev)	VIRTIO_PCI_CONFIG_OFF((dev)->msix_enabled)
+
+/* Virtio ABI version, this must match exactly */
+#define VIRTIO_PCI_ABI_VERSION		0
+
+/* How many bits to shift physical queue address written to QUEUE_PFN.
+ * 12 is historical, and due to x86 page size. */
+#define VIRTIO_PCI_QUEUE_ADDR_SHIFT	12
+
+/* The alignment to use between consumer and producer parts of vring.
+ * x86 pagesize again. */
+#define VIRTIO_PCI_VRING_ALIGN		4096
+#endif
-- 
MST

[Qemu-devel] [PATCH v2 11/11] virtio: use ring structure from linux-headers

[Michael S. Tsirkin]

We already have ring structure in virtio-ring.h for use by dataplane.
Use it in virtio.h as well, renaming some conflicting functions.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 hw/virtio/virtio.c         | 23 +++++------------------
 include/hw/virtio/virtio.h | 45 +++------------------------------------------
 2 files changed, 8 insertions(+), 60 deletions(-)

diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 8176c14..20bb6c2 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -145,7 +145,7 @@ static inline uint16_t vring_avail_ring(VirtQueue *vq, int i)
     return lduw_phys(pa);
 }
 
-static inline uint16_t vring_used_event(VirtQueue *vq)
+static inline uint16_t vring_used_event_idx(VirtQueue *vq)
 {
     return vring_avail_ring(vq, vq->vring.num);
 }
@@ -192,7 +192,7 @@ static inline void vring_used_flags_unset_bit(VirtQueue *vq, int mask)
     stw_phys(pa, lduw_phys(pa) & ~mask);
 }
 
-static inline void vring_avail_event(VirtQueue *vq, uint16_t val)
+static inline void vring_avail_event_idx(VirtQueue *vq, uint16_t val)
 {
     hwaddr pa;
     if (!vq->notification) {
@@ -206,7 +206,7 @@ void virtio_queue_set_notification(VirtQueue *vq, int enable)
 {
     vq->notification = enable;
     if (vq->vdev->guest_features & (1 << VIRTIO_RING_F_EVENT_IDX)) {
-        vring_avail_event(vq, vring_avail_idx(vq));
+        vring_avail_event_idx(vq, vring_avail_idx(vq));
     } else if (enable) {
         vring_used_flags_unset_bit(vq, VRING_USED_F_NO_NOTIFY);
     } else {
@@ -448,7 +448,7 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
 
     i = head = virtqueue_get_head(vq, vq->last_avail_idx++);
     if (vq->vdev->guest_features & (1 << VIRTIO_RING_F_EVENT_IDX)) {
-        vring_avail_event(vq, vring_avail_idx(vq));
+        vring_avail_event_idx(vq, vring_avail_idx(vq));
     }
 
     if (vring_desc_flags(desc_pa, i) & VRING_DESC_F_INDIRECT) {
@@ -740,19 +740,6 @@ void virtio_irq(VirtQueue *vq)
     virtio_notify_vector(vq->vdev, vq->vector);
 }
 
-/* Assuming a given event_idx value from the other size, if
- * we have just incremented index from old to new_idx,
- * should we trigger an event? */
-static inline int vring_need_event(uint16_t event, uint16_t new, uint16_t old)
-{
-	/* Note: Xen has similar logic for notification hold-off
-	 * in include/xen/interface/io/ring.h with req_event and req_prod
-	 * corresponding to event_idx + 1 and new respectively.
-	 * Note also that req_event and req_prod in Xen start at 1,
-	 * event indexes in virtio start at 0. */
-	return (uint16_t)(new - event - 1) < (uint16_t)(new - old);
-}
-
 static bool vring_notify(VirtIODevice *vdev, VirtQueue *vq)
 {
     uint16_t old, new;
@@ -773,7 +760,7 @@ static bool vring_notify(VirtIODevice *vdev, VirtQueue *vq)
     vq->signalled_used_valid = true;
     old = vq->signalled_used;
     new = vq->signalled_used = vring_used_idx(vq);
-    return !v || vring_need_event(vring_used_event(vq), new, old);
+    return !v || vring_need_event(vring_used_event_idx(vq), new, old);
 }
 
 void virtio_notify(VirtIODevice *vdev, VirtQueue *vq)
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index a6c5c53..3ea634d 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -22,50 +22,11 @@
 #ifdef CONFIG_VIRTFS
 #include "hw/virtio/virtio-9p.h"
 #endif
+#include "linux/virtio_config.h"
+#include "linux/virtio_ring.h"
 
-/* from Linux's linux/virtio_config.h */
-
-/* Status byte for guest to report progress, and synchronize features. */
-/* We have seen device and processed generic fields (VIRTIO_CONFIG_F_VIRTIO) */
-#define VIRTIO_CONFIG_S_ACKNOWLEDGE     1
-/* We have found a driver for the device. */
-#define VIRTIO_CONFIG_S_DRIVER          2
-/* Driver has used its parts of the config, and is happy */
-#define VIRTIO_CONFIG_S_DRIVER_OK       4
-/* We've given up on this device. */
-#define VIRTIO_CONFIG_S_FAILED          0x80
-
-/* Some virtio feature bits (currently bits 28 through 31) are reserved for the
- * transport being used (eg. virtio_ring), the rest are per-device feature bits. */
-#define VIRTIO_TRANSPORT_F_START        28
-#define VIRTIO_TRANSPORT_F_END          32
-
-/* We notify when the ring is completely used, even if the guest is suppressing
- * callbacks */
-#define VIRTIO_F_NOTIFY_ON_EMPTY        24
-/* We support indirect buffer descriptors */
-#define VIRTIO_RING_F_INDIRECT_DESC     28
-/* The Guest publishes the used index for which it expects an interrupt
- * at the end of the avail ring. Host should ignore the avail->flags field. */
-/* The Host publishes the avail index for which it expects a kick
- * at the end of the used ring. Guest should ignore the used->flags field. */
-#define VIRTIO_RING_F_EVENT_IDX         29
 /* A guest should never accept this.  It implies negotiation is broken. */
-#define VIRTIO_F_BAD_FEATURE		30
-
-/* from Linux's linux/virtio_ring.h */
-
-/* This marks a buffer as continuing via the next field. */
-#define VRING_DESC_F_NEXT       1
-/* This marks a buffer as write-only (otherwise read-only). */
-#define VRING_DESC_F_WRITE      2
-/* This means the buffer contains a list of buffer descriptors. */
-#define VRING_DESC_F_INDIRECT  4
-
-/* This means don't notify other side when buffer added. */
-#define VRING_USED_F_NO_NOTIFY  1
-/* This means don't interrupt guest when buffer consumed. */
-#define VRING_AVAIL_F_NO_INTERRUPT      1
+#define VIRTIO_F_BAD_FEATURE           30
 
 struct VirtQueue;
 
-- 
MST

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Peter Maydell]

On 26 May 2013 16:22, Michael S. Tsirkin <mst@redhat.com> wrote:
> virtio linux headers are actually pretty portable:
> all we need is implement linux/types.h in a portable
> way, and we can import them and use on any platform.
>
> These patches do exactly that, as a pre-requisite
> to adding support for new virtio layout.
>
> Note: if someone adds non-portable code in files we import from linux-headers,
> we'll have to revert to copying code manually.  This didn't happen yet so
> hopefully it won't.

This series breaks compilation on MacOSX:

  CC    net/eth.o
In file included from net/eth.c:18:
In file included from /Users/pm215/src/qemu/include/net/eth.h:29:
/Users/pm215/src/qemu/linux-headers/linux/if_ether.h:24:10: fatal
error: 'linux/types.h' file not found
#include <linux/types.h>
         ^
1 error generated.
make: *** [net/eth.o] Error 1

thanks
-- PMM

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Michael S. Tsirkin]

On Sun, May 26, 2013 at 04:43:57PM +0100, Peter Maydell wrote:
> On 26 May 2013 16:22, Michael S. Tsirkin <mst@redhat.com> wrote:
> > virtio linux headers are actually pretty portable:
> > all we need is implement linux/types.h in a portable
> > way, and we can import them and use on any platform.
> >
> > These patches do exactly that, as a pre-requisite
> > to adding support for new virtio layout.
> >
> > Note: if someone adds non-portable code in files we import from linux-headers,
> > we'll have to revert to copying code manually.  This didn't happen yet so
> > hopefully it won't.
> 
> This series breaks compilation on MacOSX:
> 
>   CC    net/eth.o
> In file included from net/eth.c:18:
> In file included from /Users/pm215/src/qemu/include/net/eth.h:29:
> /Users/pm215/src/qemu/linux-headers/linux/if_ether.h:24:10: fatal
> error: 'linux/types.h' file not found
> #include <linux/types.h>
>          ^
> 1 error generated.
> make: *** [net/eth.o] Error 1
> 
> thanks
> -- PMM

Could be a stale file in your tree ...
Did configure get re-run?
Could you post the config-host.mak file please?

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Peter Maydell]

[-- Attachment #1: Type: text/plain, Size: 908 bytes --]

On 26 May 2013 18:51, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Sun, May 26, 2013 at 04:43:57PM +0100, Peter Maydell wrote:
>> This series breaks compilation on MacOSX:
>>
>>   CC    net/eth.o
>> In file included from net/eth.c:18:
>> In file included from /Users/pm215/src/qemu/include/net/eth.h:29:
>> /Users/pm215/src/qemu/linux-headers/linux/if_ether.h:24:10: fatal
>> error: 'linux/types.h' file not found
>> #include <linux/types.h>
>>          ^
>> 1 error generated.
>> make: *** [net/eth.o] Error 1

> Could be a stale file in your tree ...
> Did configure get re-run?
> Could you post the config-host.mak file please?

Configure did get rerun, but where are you expecting the header
to pull linux/types.h from?  Your patchset adds files which include
it but doesn't add any copy itself, so if you're not on a Linux
host then it just doesn't exist...

config-host.mak attached.

thanks
-- PMM

[-- Attachment #2: config-host.mak --]
[-- Type: application/octet-stream, Size: 3147 bytes --]

# Automatically generated by configure - do not modify
# Configured with: './configure' '--target-list=arm-softmmu' '--enable-debug'
all:
prefix=/usr/local
bindir=${prefix}/bin
libdir=${prefix}/lib
libexecdir=${prefix}/libexec
includedir=${prefix}/include
mandir=${prefix}/share/man
sysconfdir=${prefix}/etc
qemu_confdir=${prefix}/etc/qemu
qemu_datadir=${prefix}/share/qemu
qemu_docdir=${prefix}/share/doc/qemu
qemu_localstatedir=${prefix}/var
qemu_helperdir=${prefix}/libexec
extra_cflags=-m64 
extra_ldflags=
qemu_localedir=${prefix}/share/locale
libs_softmmu=-L/sw/lib -lssh2 -L/sw/lib -lcurl -lncurses -framework CoreAudio -L/sw/lib -lpng15 -lsasl2 -L/sw/lib/gnutls28 -lgnutls -F/System/Library/Frameworks -framework Cocoa -framework IOKit  -lz -L$(BUILD_DIR)/dtc/libfdt -lfdt -L/opt/X11/lib -lpixman-1
ARCH=x86_64
CONFIG_QEMU_LDST_OPTIMIZATION=y
CONFIG_DEBUG_TCG=y
CONFIG_POSIX=y
CONFIG_DARWIN=y
CONFIG_SLIRP=y
CONFIG_SMBD_COMMAND="/usr/sbin/smbd"
CONFIG_AUDIO_DRIVERS=coreaudio
CONFIG_COREAUDIO=y
CONFIG_BDRV_WHITELIST=
CONFIG_VNC=y
CONFIG_VNC_TLS=y
CONFIG_VNC_SASL=y
CONFIG_VNC_PNG=y
CONFIG_VNC_WS=y
VNC_WS_CFLAGS=
CONFIG_FNMATCH=y
CONFIG_UUID=y
VERSION=1.5.50
PKGVERSION=
SRC_PATH=/Users/pm215/src/qemu
TARGET_DIRS=arm-softmmu
BUILD_DOCS=yes
CONFIG_COCOA=y
CONFIG_CURSES=y
CONFIG_CURL=y
CURL_CFLAGS=-I/sw/include  
GLIB_CFLAGS=-I/sw/include/glib-2.0 -I/sw/lib/glib-2.0/include
INSTALL_BLOBS=yes
CONFIG_IOVEC=y
CONFIG_FDT=y
CONFIG_MADVISE=y
CONFIG_POSIX_MADVISE=y
CONFIG_BSD=y
CONFIG_UNAME_RELEASE=""
CONFIG_QOM_CAST_DEBUG=y
CONFIG_COROUTINE_BACKEND=sigaltstack
CONFIG_CPUID_H=y
CONFIG_INT128=y
CONFIG_LIBSSH2=y
HOST_USB=stub
TRACE_BACKEND=nop
CONFIG_TRACE_NOP=y
CONFIG_TRACE_FILE=trace
CONFIG_TRACE_DEFAULT=y
TOOLS=qemu-ga$(EXESUF) qemu-nbd$(EXESUF) qemu-img$(EXESUF) qemu-io$(EXESUF) 
ROMS=
MAKE=make
INSTALL=install
INSTALL_DIR=install -d -m 0755
INSTALL_DATA=install -c -m 0644
INSTALL_PROG=install -c -m 0755
INSTALL_LIB=install -c -m 0644
PYTHON=python
CC=cc
CC_I386=$(CC) -m32
HOST_CC=cc
OBJCC=clang
AR=ar
AS=as
CPP=cc -E
OBJCOPY=objcopy
LD=ld
WINDRES=windres
LIBTOOL=
CFLAGS=-g 
QEMU_CFLAGS=-m64 -DOS_OBJECT_USE_OBJC=0 -arch x86_64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing  -Wno-initializer-overrides -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-definition -Wtype-limits -fstack-protector-all -I/sw/include    -I/sw/include/libpng15   -I/sw/include   -I/opt/X11/include/pixman-1   -I$(SRC_PATH)/dtc/libfdt
QEMU_INCLUDES=-I$(SRC_PATH)/tcg -I$(SRC_PATH)/tcg/i386 -I$(SRC_PATH)/linux-stubs -I$(SRC_PATH)/linux-headers -I. -I$(SRC_PATH) -I$(SRC_PATH)/include
AUTOCONF_HOST := 
LDFLAGS=-m64 -framework CoreFoundation -framework IOKit -arch x86_64 -g 
LIBTOOLFLAGS= -Wc,-fstack-protector-all
LIBS+=-L/sw/lib -lgthread-2.0 -lglib-2.0 -lintl 
LIBS_TOOLS+=-L/sw/lib -lssh2 -L/sw/lib -lcurl 
EXESUF=
LIBS_QGA+=-L/sw/lib -lgthread-2.0 -lglib-2.0 -lintl 
POD2MAN=pod2man
TRANSLATE_OPT_CFLAGS=
config-host.h: subdir-dtc

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Michael S. Tsirkin]

On Sun, May 26, 2013 at 07:00:58PM +0100, Peter Maydell wrote:
> On 26 May 2013 18:51, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Sun, May 26, 2013 at 04:43:57PM +0100, Peter Maydell wrote:
> >> This series breaks compilation on MacOSX:
> >>
> >>   CC    net/eth.o
> >> In file included from net/eth.c:18:
> >> In file included from /Users/pm215/src/qemu/include/net/eth.h:29:
> >> /Users/pm215/src/qemu/linux-headers/linux/if_ether.h:24:10: fatal
> >> error: 'linux/types.h' file not found
> >> #include <linux/types.h>
> >>          ^
> >> 1 error generated.
> >> make: *** [net/eth.o] Error 1
> 
> > Could be a stale file in your tree ...
> > Did configure get re-run?
> > Could you post the config-host.mak file please?
> 
> Configure did get rerun, but where are you expecting the header
> to pull linux/types.h from?  Your patchset adds files which include
> it but doesn't add any copy itself, so if you're not on a Linux
> host then it just doesn't exist...
> 
> config-host.mak attached.
> 
> thanks
> -- PMM


Ouch. Forgot to git-add them. Thanks.

I'll send a fixed version -
could you please try this patch on top?


    linux-stubs: linux/types.h
    
    This adds a directory with minimal stubs that
    make it possible to use some linux headers
    in qemu in a portable environment.
    
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

---

diff --git a/linux-stubs/linux/types.h b/linux-stubs/linux/types.h
new file mode 100644
index 0000000..8642cbb
--- /dev/null
+++ b/linux-stubs/linux/types.h
@@ -0,0 +1,37 @@
+#ifndef STUBS_LINUX_TYPES_H
+#define STUBS_LINUX_TYPES_H
+
+#include <stdint.h>
+
+/*
+ * Below are Linux-specific types that should never collide with
+ * any application/library that wants linux/types.h.
+ */
+
+typedef uint8_t __u8;
+typedef uint16_t __u16;
+typedef uint32_t __u32;
+typedef uint64_t __u64;
+
+#ifdef __CHECKER__
+#define __bitwise__ __attribute__((bitwise))
+#else
+#define __bitwise__
+#endif
+#ifdef __CHECK_ENDIAN__
+#define __bitwise __bitwise__
+#else
+#define __bitwise
+#endif
+
+typedef __u16 __bitwise __le16;
+typedef __u16 __bitwise __be16;
+typedef __u32 __bitwise __le32;
+typedef __u32 __bitwise __be32;
+typedef __u64 __bitwise __le64;
+typedef __u64 __bitwise __be64;
+
+typedef __u16 __bitwise __sum16;
+typedef __u32 __bitwise __wsum;
+
+#endif



-- 
MST

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Paolo Bonzini]

Il 26/05/2013 20:10, Michael S. Tsirkin ha scritto:
> On Sun, May 26, 2013 at 07:00:58PM +0100, Peter Maydell wrote:
>> On 26 May 2013 18:51, Michael S. Tsirkin <mst@redhat.com> wrote:
>>> On Sun, May 26, 2013 at 04:43:57PM +0100, Peter Maydell wrote:
>>>> This series breaks compilation on MacOSX:
>>>>
>>>>   CC    net/eth.o
>>>> In file included from net/eth.c:18:
>>>> In file included from /Users/pm215/src/qemu/include/net/eth.h:29:
>>>> /Users/pm215/src/qemu/linux-headers/linux/if_ether.h:24:10: fatal
>>>> error: 'linux/types.h' file not found
>>>> #include <linux/types.h>
>>>>          ^
>>>> 1 error generated.
>>>> make: *** [net/eth.o] Error 1
>>
>>> Could be a stale file in your tree ...
>>> Did configure get re-run?
>>> Could you post the config-host.mak file please?
>>
>> Configure did get rerun, but where are you expecting the header
>> to pull linux/types.h from?  Your patchset adds files which include
>> it but doesn't add any copy itself, so if you're not on a Linux
>> host then it just doesn't exist...
>>
>> config-host.mak attached.
>>
>> thanks
>> -- PMM
> 
> 
> Ouch. Forgot to git-add them. Thanks.
> 
> I'll send a fixed version -
> could you please try this patch on top?
> 
> 
>     linux-stubs: linux/types.h
>     
>     This adds a directory with minimal stubs that
>     make it possible to use some linux headers
>     in qemu in a portable environment.
>     
>     Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> 
> ---
> 
> diff --git a/linux-stubs/linux/types.h b/linux-stubs/linux/types.h
> new file mode 100644
> index 0000000..8642cbb
> --- /dev/null
> +++ b/linux-stubs/linux/types.h
> @@ -0,0 +1,37 @@
> +#ifndef STUBS_LINUX_TYPES_H
> +#define STUBS_LINUX_TYPES_H
> +
> +#include <stdint.h>
> +
> +/*
> + * Below are Linux-specific types that should never collide with
> + * any application/library that wants linux/types.h.
> + */
> +
> +typedef uint8_t __u8;
> +typedef uint16_t __u16;
> +typedef uint32_t __u32;
> +typedef uint64_t __u64;
> +
> +#ifdef __CHECKER__
> +#define __bitwise__ __attribute__((bitwise))
> +#else
> +#define __bitwise__
> +#endif
> +#ifdef __CHECK_ENDIAN__
> +#define __bitwise __bitwise__
> +#else
> +#define __bitwise
> +#endif
> +
> +typedef __u16 __bitwise __le16;
> +typedef __u16 __bitwise __be16;
> +typedef __u32 __bitwise __le32;
> +typedef __u32 __bitwise __be32;
> +typedef __u64 __bitwise __le64;
> +typedef __u64 __bitwise __be64;
> +
> +typedef __u16 __bitwise __sum16;
> +typedef __u32 __bitwise __wsum;
> +

I don't like defining __-prefixed types.  Can we preprocess
linux-headers to avoid usage of __u8/16/32/64, and to
s,linux/types.h,stdint.h, ?

Paolo

> +#endif
> 
> 
> 

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Michael S. Tsirkin]

On Sun, May 26, 2013 at 08:26:14PM +0200, Paolo Bonzini wrote:
> Il 26/05/2013 20:10, Michael S. Tsirkin ha scritto:
> > On Sun, May 26, 2013 at 07:00:58PM +0100, Peter Maydell wrote:
> >> On 26 May 2013 18:51, Michael S. Tsirkin <mst@redhat.com> wrote:
> >>> On Sun, May 26, 2013 at 04:43:57PM +0100, Peter Maydell wrote:
> >>>> This series breaks compilation on MacOSX:
> >>>>
> >>>>   CC    net/eth.o
> >>>> In file included from net/eth.c:18:
> >>>> In file included from /Users/pm215/src/qemu/include/net/eth.h:29:
> >>>> /Users/pm215/src/qemu/linux-headers/linux/if_ether.h:24:10: fatal
> >>>> error: 'linux/types.h' file not found
> >>>> #include <linux/types.h>
> >>>>          ^
> >>>> 1 error generated.
> >>>> make: *** [net/eth.o] Error 1
> >>
> >>> Could be a stale file in your tree ...
> >>> Did configure get re-run?
> >>> Could you post the config-host.mak file please?
> >>
> >> Configure did get rerun, but where are you expecting the header
> >> to pull linux/types.h from?  Your patchset adds files which include
> >> it but doesn't add any copy itself, so if you're not on a Linux
> >> host then it just doesn't exist...
> >>
> >> config-host.mak attached.
> >>
> >> thanks
> >> -- PMM
> > 
> > 
> > Ouch. Forgot to git-add them. Thanks.
> > 
> > I'll send a fixed version -
> > could you please try this patch on top?
> > 
> > 
> >     linux-stubs: linux/types.h
> >     
> >     This adds a directory with minimal stubs that
> >     make it possible to use some linux headers
> >     in qemu in a portable environment.
> >     
> >     Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > 
> > ---
> > 
> > diff --git a/linux-stubs/linux/types.h b/linux-stubs/linux/types.h
> > new file mode 100644
> > index 0000000..8642cbb
> > --- /dev/null
> > +++ b/linux-stubs/linux/types.h
> > @@ -0,0 +1,37 @@
> > +#ifndef STUBS_LINUX_TYPES_H
> > +#define STUBS_LINUX_TYPES_H
> > +
> > +#include <stdint.h>
> > +
> > +/*
> > + * Below are Linux-specific types that should never collide with
> > + * any application/library that wants linux/types.h.
> > + */
> > +
> > +typedef uint8_t __u8;
> > +typedef uint16_t __u16;
> > +typedef uint32_t __u32;
> > +typedef uint64_t __u64;
> > +
> > +#ifdef __CHECKER__
> > +#define __bitwise__ __attribute__((bitwise))
> > +#else
> > +#define __bitwise__
> > +#endif
> > +#ifdef __CHECK_ENDIAN__
> > +#define __bitwise __bitwise__
> > +#else
> > +#define __bitwise
> > +#endif
> > +
> > +typedef __u16 __bitwise __le16;
> > +typedef __u16 __bitwise __be16;
> > +typedef __u32 __bitwise __le32;
> > +typedef __u32 __bitwise __be32;
> > +typedef __u64 __bitwise __le64;
> > +typedef __u64 __bitwise __be64;
> > +
> > +typedef __u16 __bitwise __sum16;
> > +typedef __u32 __bitwise __wsum;
> > +
> 
> I don't like defining __-prefixed types.  Can we preprocess
> linux-headers to avoid usage of __u8/16/32/64, and to
> s,linux/types.h,stdint.h, ?
> 
> Paolo

Let's not be purists, and do the practical thing.

When I suggested this you didn't like it:
>> I can think of two ways:
>>     - strip linux/types.h in update_headers
>>     - add a stub linux/types.h for non linux platforms
>
>The latter, using stdint.h types, would be fine.

And now, I think it's cleaner to keep it as is.
Most likely, these specific __ types work fine, *if* we
see a problem we can think what's to be done.
In particular, there are __le/__be tags there which can
be useful to do static code analysis.

What's the worst case failure scanario?
Conflict with some system standard header on some
strange target OS, this results in a failed build,
and we go and try to fix it, almost surely with
ifndef around some of the stubs. Why worry now?

> > +#endif
> > 
> > 
> > 

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Paolo Bonzini]

Il 26/05/2013 20:37, Michael S. Tsirkin ha scritto:
>> > I don't like defining __-prefixed types.  Can we preprocess
>> > linux-headers to avoid usage of __u8/16/32/64, and to
>> > s,linux/types.h,stdint.h, ?
>> > 
>> > Paolo
> Let's not be purists, and do the practical thing.
> 
> When I suggested this you didn't like it:
>>> >> I can think of two ways:
>>> >>     - strip linux/types.h in update_headers
>>> >>     - add a stub linux/types.h for non linux platforms
>> >
>> >The latter, using stdint.h types, would be fine.

My fault.  I should have looked at linux/types.h (actually asm-generic/).

Paolo

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Michael S. Tsirkin]

On Sun, May 26, 2013 at 08:53:33PM +0200, Paolo Bonzini wrote:
> Il 26/05/2013 20:37, Michael S. Tsirkin ha scritto:
> >> > I don't like defining __-prefixed types.  Can we preprocess
> >> > linux-headers to avoid usage of __u8/16/32/64, and to
> >> > s,linux/types.h,stdint.h, ?
> >> > 
> >> > Paolo
> > Let's not be purists, and do the practical thing.
> > 
> > When I suggested this you didn't like it:
> >>> >> I can think of two ways:
> >>> >>     - strip linux/types.h in update_headers
> >>> >>     - add a stub linux/types.h for non linux platforms
> >> >
> >> >The latter, using stdint.h types, would be fine.
> 
> My fault.  I should have looked at linux/types.h (actually asm-generic/).
> 
> Paolo

Not really, __uX appear in the headers that were posted.
What I'm saying is - a chance of a conflict is very remote,
if it happens it's a build failure so easy to debug.

-- 
MST

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Paolo Bonzini]

Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
> > My fault.  I should have looked at linux/types.h (actually asm-generic/).
> 
> Not really, __uX appear in the headers that were posted.
> What I'm saying is - a chance of a conflict is very remote,
> if it happens it's a build failure so easy to debug.

I'm sure that others will complain, :) but you can go ahead.

Paolo

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Anthony Liguori]

Paolo Bonzini <pbonzini@redhat.com> writes:

> Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
>> > My fault.  I should have looked at linux/types.h (actually asm-generic/).
>> 
>> Not really, __uX appear in the headers that were posted.

Which is a problem because this is a reserved namespace in C99.

>> What I'm saying is - a chance of a conflict is very remote,
>> if it happens it's a build failure so easy to debug.
>
> I'm sure that others will complain, :) but you can go ahead.

I think we should clean up the virtio headers in the kernel first.
Seems like a good thing to do given the standardization effort too.

There are lots of headers in uapi that use the C99 int types so there
doesn't seem to be a reason they couldn't be used in virtio.  fuse.h
even has a:

    #ifdef __KERNEL__
    #include <linux/types.h>
    #else
    #include <stdint.h>
    #endif

Which seems like a reasonable thing to do.

The only other kernel dependency is linux/if_ether.h to define
ETH_ALEN.  But it seems completely reasonable to define a
VIRTIO_NET_MAC_ALEN or something like that.

This would make the virtio headers completely stand alone and includable
in userspace (without violating C99).

Perhaps it's even worth moving the headers from uapi/linux to
uapi/virtio.  Rusty, what do you think?

Regards,

Anhtony Liguori

>
> Paolo

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Anthony Liguori]

Paolo Bonzini <pbonzini@redhat.com> writes:

> Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
>> > My fault.  I should have looked at linux/types.h (actually asm-generic/).
>> 
>> Not really, __uX appear in the headers that were posted.

Which is a problem because this is a reserved namespace in C99.

>> What I'm saying is - a chance of a conflict is very remote,
>> if it happens it's a build failure so easy to debug.
>
> I'm sure that others will complain, :) but you can go ahead.

I think we should clean up the virtio headers in the kernel first.
Seems like a good thing to do given the standardization effort too.

There are lots of headers in uapi that use the C99 int types so there
doesn't seem to be a reason they couldn't be used in virtio.  fuse.h
even has a:

    #ifdef __KERNEL__
    #include <linux/types.h>
    #else
    #include <stdint.h>
    #endif

Which seems like a reasonable thing to do.

The only other kernel dependency is linux/if_ether.h to define
ETH_ALEN.  But it seems completely reasonable to define a
VIRTIO_NET_MAC_ALEN or something like that.

This would make the virtio headers completely stand alone and includable
in userspace (without violating C99).

Perhaps it's even worth moving the headers from uapi/linux to
uapi/virtio.  Rusty, what do you think?

Regards,

Anhtony Liguori

>
> Paolo

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Michael S. Tsirkin]

On Sun, May 26, 2013 at 03:49:53PM -0500, Anthony Liguori wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
> > Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
> >> > My fault.  I should have looked at linux/types.h (actually asm-generic/).
> >> 
> >> Not really, __uX appear in the headers that were posted.
> 
> Which is a problem because this is a reserved namespace in C99.
> 
> >> What I'm saying is - a chance of a conflict is very remote,
> >> if it happens it's a build failure so easy to debug.
> >
> > I'm sure that others will complain, :) but you can go ahead.
> 
> I think we should clean up the virtio headers in the kernel first.
> Seems like a good thing to do given the standardization effort too.
> There are lots of headers in uapi that use the C99 int types

I found 4:
$ grep -l uint include/uapi/linux/*h
include/uapi/linux/dm-log-userspace.h
include/uapi/linux/fuse.h
include/uapi/linux/jffs2.h
include/uapi/linux/pps.h
include/uapi/linux/rds.h
include/uapi/linux/sctp.h

That's not really lots.

> so there
> doesn't seem to be a reason they couldn't be used in virtio.  fuse.h
> even has a:
> 
>     #ifdef __KERNEL__
>     #include <linux/types.h>
>     #else
>     #include <stdint.h>
>     #endif
> 
> Which seems like a reasonable thing to do.

In kernel, we really want to use things like endian-ness
checks (and, we really should have them in userspace too!).
So we want __le32 and other kernel goodies
like that. stdint.h won't cut it.

> The only other kernel dependency is linux/if_ether.h to define
> ETH_ALEN.  But it seems completely reasonable to define a
> VIRTIO_NET_MAC_ALEN or something like that.

Ugh. Not really reasonable IMO. We also use ETH_P_IP in code,
would like to get rid of redefining that too.
But we can have our own linux/if_ether.h for non-linux hosts,
just with a
couple of macros like that, it's not a big deal.

> This would make the virtio headers completely stand alone and includable
> in userspace (without violating C99).
> 
> Perhaps it's even worth moving the headers from uapi/linux to
> uapi/virtio.  Rusty, what do you think?
> 
> Regards,
> 
> Anhtony Liguori
> 
> >
> > Paolo

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Michael S. Tsirkin]

On Sun, May 26, 2013 at 03:49:53PM -0500, Anthony Liguori wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
> > Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
> >> > My fault.  I should have looked at linux/types.h (actually asm-generic/).
> >> 
> >> Not really, __uX appear in the headers that were posted.
> 
> Which is a problem because this is a reserved namespace in C99.
> 
> >> What I'm saying is - a chance of a conflict is very remote,
> >> if it happens it's a build failure so easy to debug.
> >
> > I'm sure that others will complain, :) but you can go ahead.
> 
> I think we should clean up the virtio headers in the kernel first.
> Seems like a good thing to do given the standardization effort too.
> There are lots of headers in uapi that use the C99 int types

I found 4:
$ grep -l uint include/uapi/linux/*h
include/uapi/linux/dm-log-userspace.h
include/uapi/linux/fuse.h
include/uapi/linux/jffs2.h
include/uapi/linux/pps.h
include/uapi/linux/rds.h
include/uapi/linux/sctp.h

That's not really lots.

> so there
> doesn't seem to be a reason they couldn't be used in virtio.  fuse.h
> even has a:
> 
>     #ifdef __KERNEL__
>     #include <linux/types.h>
>     #else
>     #include <stdint.h>
>     #endif
> 
> Which seems like a reasonable thing to do.

In kernel, we really want to use things like endian-ness
checks (and, we really should have them in userspace too!).
So we want __le32 and other kernel goodies
like that. stdint.h won't cut it.

> The only other kernel dependency is linux/if_ether.h to define
> ETH_ALEN.  But it seems completely reasonable to define a
> VIRTIO_NET_MAC_ALEN or something like that.

Ugh. Not really reasonable IMO. We also use ETH_P_IP in code,
would like to get rid of redefining that too.
But we can have our own linux/if_ether.h for non-linux hosts,
just with a
couple of macros like that, it's not a big deal.

> This would make the virtio headers completely stand alone and includable
> in userspace (without violating C99).
> 
> Perhaps it's even worth moving the headers from uapi/linux to
> uapi/virtio.  Rusty, what do you think?
> 
> Regards,
> 
> Anhtony Liguori
> 
> >
> > Paolo

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Anthony Liguori]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Sun, May 26, 2013 at 03:49:53PM -0500, Anthony Liguori wrote:
>> Paolo Bonzini <pbonzini@redhat.com> writes:
>> 
>> > Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
>> >> > My fault.  I should have looked at linux/types.h (actually asm-generic/).
>> >> 
>> >> Not really, __uX appear in the headers that were posted.
>> 
>> Which is a problem because this is a reserved namespace in C99.
>> 
>> >> What I'm saying is - a chance of a conflict is very remote,
>> >> if it happens it's a build failure so easy to debug.
>> >
>> > I'm sure that others will complain, :) but you can go ahead.
>> 
>> I think we should clean up the virtio headers in the kernel first.
>> Seems like a good thing to do given the standardization effort too.
>> There are lots of headers in uapi that use the C99 int types
>
> I found 4:
> $ grep -l uint include/uapi/linux/*h
> include/uapi/linux/dm-log-userspace.h
> include/uapi/linux/fuse.h
> include/uapi/linux/jffs2.h
> include/uapi/linux/pps.h
> include/uapi/linux/rds.h
> include/uapi/linux/sctp.h
>
> That's not really lots.
>
>> so there
>> doesn't seem to be a reason they couldn't be used in virtio.  fuse.h
>> even has a:
>> 
>>     #ifdef __KERNEL__
>>     #include <linux/types.h>
>>     #else
>>     #include <stdint.h>
>>     #endif
>> 
>> Which seems like a reasonable thing to do.
>
> In kernel, we really want to use things like endian-ness
> checks (and, we really should have them in userspace too!).
> So we want __le32 and other kernel goodies
> like that. stdint.h won't cut it.

With the spec being standardized, I think having a stand alone set of
headers is a good thing.  Licensing is problematic here too.

If virtio headers depend on other Linux headers, then it really doesn't
matter if they are BSD licensed if you need a GPL header (like
linux/if_ether.h).

Now, we can certainly debate the copyrightability of these defines and
what have you but if the headers are meant to be 1) consumed outside the
kernel 2) licensed under a different license than the general kernel
then depending on kernel goodies is the wrong strategy.

>> The only other kernel dependency is linux/if_ether.h to define
>> ETH_ALEN.  But it seems completely reasonable to define a
>> VIRTIO_NET_MAC_ALEN or something like that.
>
> Ugh. Not really reasonable IMO. We also use ETH_P_IP in code,
> would like to get rid of redefining that too.
> But we can have our own linux/if_ether.h for non-linux hosts,
> just with a
> couple of macros like that, it's not a big deal.

See above.

Regards,

Anthony Liguori

>
>> This would make the virtio headers completely stand alone and includable
>> in userspace (without violating C99).
>> 
>> Perhaps it's even worth moving the headers from uapi/linux to
>> uapi/virtio.  Rusty, what do you think?
>> 
>> Regards,
>> 
>> Anhtony Liguori
>> 
>> >
>> > Paolo

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Anthony Liguori]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Sun, May 26, 2013 at 03:49:53PM -0500, Anthony Liguori wrote:
>> Paolo Bonzini <pbonzini@redhat.com> writes:
>> 
>> > Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
>> >> > My fault.  I should have looked at linux/types.h (actually asm-generic/).
>> >> 
>> >> Not really, __uX appear in the headers that were posted.
>> 
>> Which is a problem because this is a reserved namespace in C99.
>> 
>> >> What I'm saying is - a chance of a conflict is very remote,
>> >> if it happens it's a build failure so easy to debug.
>> >
>> > I'm sure that others will complain, :) but you can go ahead.
>> 
>> I think we should clean up the virtio headers in the kernel first.
>> Seems like a good thing to do given the standardization effort too.
>> There are lots of headers in uapi that use the C99 int types
>
> I found 4:
> $ grep -l uint include/uapi/linux/*h
> include/uapi/linux/dm-log-userspace.h
> include/uapi/linux/fuse.h
> include/uapi/linux/jffs2.h
> include/uapi/linux/pps.h
> include/uapi/linux/rds.h
> include/uapi/linux/sctp.h
>
> That's not really lots.
>
>> so there
>> doesn't seem to be a reason they couldn't be used in virtio.  fuse.h
>> even has a:
>> 
>>     #ifdef __KERNEL__
>>     #include <linux/types.h>
>>     #else
>>     #include <stdint.h>
>>     #endif
>> 
>> Which seems like a reasonable thing to do.
>
> In kernel, we really want to use things like endian-ness
> checks (and, we really should have them in userspace too!).
> So we want __le32 and other kernel goodies
> like that. stdint.h won't cut it.

With the spec being standardized, I think having a stand alone set of
headers is a good thing.  Licensing is problematic here too.

If virtio headers depend on other Linux headers, then it really doesn't
matter if they are BSD licensed if you need a GPL header (like
linux/if_ether.h).

Now, we can certainly debate the copyrightability of these defines and
what have you but if the headers are meant to be 1) consumed outside the
kernel 2) licensed under a different license than the general kernel
then depending on kernel goodies is the wrong strategy.

>> The only other kernel dependency is linux/if_ether.h to define
>> ETH_ALEN.  But it seems completely reasonable to define a
>> VIRTIO_NET_MAC_ALEN or something like that.
>
> Ugh. Not really reasonable IMO. We also use ETH_P_IP in code,
> would like to get rid of redefining that too.
> But we can have our own linux/if_ether.h for non-linux hosts,
> just with a
> couple of macros like that, it's not a big deal.

See above.

Regards,

Anthony Liguori

>
>> This would make the virtio headers completely stand alone and includable
>> in userspace (without violating C99).
>> 
>> Perhaps it's even worth moving the headers from uapi/linux to
>> uapi/virtio.  Rusty, what do you think?
>> 
>> Regards,
>> 
>> Anhtony Liguori
>> 
>> >
>> > Paolo

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Peter Maydell]

On 26 May 2013 19:10, Michael S. Tsirkin <mst@redhat.com> wrote:
> Ouch. Forgot to git-add them. Thanks.
>
> I'll send a fixed version -
> could you please try this patch on top?

With this extra patch MacOSX compiles.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Rusty Russell]

Anthony Liguori <anthony@codemonkey.ws> writes:
> Paolo Bonzini <pbonzini@redhat.com> writes:
>
>> Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
>>> > My fault.  I should have looked at linux/types.h (actually asm-generic/).
>>> 
>>> Not really, __uX appear in the headers that were posted.
>
> Which is a problem because this is a reserved namespace in C99.

Personally, I find it hard to care.  What matters is not what the
standard has carved out, but whether we have clashes, reserved namespace
or no.  And that won't happen for these.

If someone wants to convert all the kernel headers, I won't NAK it
though.

> Perhaps it's even worth moving the headers from uapi/linux to
> uapi/virtio.  Rusty, what do you think?

Hmm, #include <virtio/virtio_net.h> etc would be worthwhile if that also
worked on FreeBSD.  Bryan CC'd...

Cheers,
Rusty.

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Michael S. Tsirkin]

On Sun, May 26, 2013 at 07:55:25PM -0500, Anthony Liguori wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > On Sun, May 26, 2013 at 03:49:53PM -0500, Anthony Liguori wrote:
> >> Paolo Bonzini <pbonzini@redhat.com> writes:
> >> 
> >> > Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
> >> >> > My fault.  I should have looked at linux/types.h (actually asm-generic/).
> >> >> 
> >> >> Not really, __uX appear in the headers that were posted.
> >> 
> >> Which is a problem because this is a reserved namespace in C99.
> >> 
> >> >> What I'm saying is - a chance of a conflict is very remote,
> >> >> if it happens it's a build failure so easy to debug.
> >> >
> >> > I'm sure that others will complain, :) but you can go ahead.
> >> 
> >> I think we should clean up the virtio headers in the kernel first.
> >> Seems like a good thing to do given the standardization effort too.
> >> There are lots of headers in uapi that use the C99 int types
> >
> > I found 4:
> > $ grep -l uint include/uapi/linux/*h
> > include/uapi/linux/dm-log-userspace.h
> > include/uapi/linux/fuse.h
> > include/uapi/linux/jffs2.h
> > include/uapi/linux/pps.h
> > include/uapi/linux/rds.h
> > include/uapi/linux/sctp.h
> >
> > That's not really lots.
> >
> >> so there
> >> doesn't seem to be a reason they couldn't be used in virtio.  fuse.h
> >> even has a:
> >> 
> >>     #ifdef __KERNEL__
> >>     #include <linux/types.h>
> >>     #else
> >>     #include <stdint.h>
> >>     #endif
> >> 
> >> Which seems like a reasonable thing to do.
> >
> > In kernel, we really want to use things like endian-ness
> > checks (and, we really should have them in userspace too!).
> > So we want __le32 and other kernel goodies
> > like that. stdint.h won't cut it.
> 
> With the spec being standardized, I think having a stand alone set of
> headers is a good thing.

Sure, that's possible. We'll have to find some way to
preserve the endian-ness annotations, I think.
And then import them into kernel/qemu with some script, converting
to kernel/qemu style and annotations?

>  Licensing is problematic here too.
> 
> If virtio headers depend on other Linux headers, then it really doesn't
> matter if they are BSD licensed if you need a GPL header (like
> linux/if_ether.h).
> 
> Now, we can certainly debate the copyrightability of these defines and
> what have you but if the headers are meant to be 1) consumed outside the
> kernel 2) licensed under a different license than the general kernel
> then depending on kernel goodies is the wrong strategy.

Well specifically if_ether.h says GPLv2+ so it's OK for QEMU.
Do you mean for some other non GPL app?

> >> The only other kernel dependency is linux/if_ether.h to define
> >> ETH_ALEN.  But it seems completely reasonable to define a
> >> VIRTIO_NET_MAC_ALEN or something like that.
> >
> > Ugh. Not really reasonable IMO. We also use ETH_P_IP in code,
> > would like to get rid of redefining that too.
> > But we can have our own linux/if_ether.h for non-linux hosts,
> > just with a
> > couple of macros like that, it's not a big deal.
> 
> See above.
> 
> Regards,
> 
> Anthony Liguori
> 
> >
> >> This would make the virtio headers completely stand alone and includable
> >> in userspace (without violating C99).
> >> 
> >> Perhaps it's even worth moving the headers from uapi/linux to
> >> uapi/virtio.  Rusty, what do you think?
> >> 
> >> Regards,
> >> 
> >> Anhtony Liguori
> >> 
> >> >
> >> > Paolo

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Michael S. Tsirkin]

On Sun, May 26, 2013 at 07:55:25PM -0500, Anthony Liguori wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > On Sun, May 26, 2013 at 03:49:53PM -0500, Anthony Liguori wrote:
> >> Paolo Bonzini <pbonzini@redhat.com> writes:
> >> 
> >> > Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
> >> >> > My fault.  I should have looked at linux/types.h (actually asm-generic/).
> >> >> 
> >> >> Not really, __uX appear in the headers that were posted.
> >> 
> >> Which is a problem because this is a reserved namespace in C99.
> >> 
> >> >> What I'm saying is - a chance of a conflict is very remote,
> >> >> if it happens it's a build failure so easy to debug.
> >> >
> >> > I'm sure that others will complain, :) but you can go ahead.
> >> 
> >> I think we should clean up the virtio headers in the kernel first.
> >> Seems like a good thing to do given the standardization effort too.
> >> There are lots of headers in uapi that use the C99 int types
> >
> > I found 4:
> > $ grep -l uint include/uapi/linux/*h
> > include/uapi/linux/dm-log-userspace.h
> > include/uapi/linux/fuse.h
> > include/uapi/linux/jffs2.h
> > include/uapi/linux/pps.h
> > include/uapi/linux/rds.h
> > include/uapi/linux/sctp.h
> >
> > That's not really lots.
> >
> >> so there
> >> doesn't seem to be a reason they couldn't be used in virtio.  fuse.h
> >> even has a:
> >> 
> >>     #ifdef __KERNEL__
> >>     #include <linux/types.h>
> >>     #else
> >>     #include <stdint.h>
> >>     #endif
> >> 
> >> Which seems like a reasonable thing to do.
> >
> > In kernel, we really want to use things like endian-ness
> > checks (and, we really should have them in userspace too!).
> > So we want __le32 and other kernel goodies
> > like that. stdint.h won't cut it.
> 
> With the spec being standardized, I think having a stand alone set of
> headers is a good thing.

Sure, that's possible. We'll have to find some way to
preserve the endian-ness annotations, I think.
And then import them into kernel/qemu with some script, converting
to kernel/qemu style and annotations?

>  Licensing is problematic here too.
> 
> If virtio headers depend on other Linux headers, then it really doesn't
> matter if they are BSD licensed if you need a GPL header (like
> linux/if_ether.h).
> 
> Now, we can certainly debate the copyrightability of these defines and
> what have you but if the headers are meant to be 1) consumed outside the
> kernel 2) licensed under a different license than the general kernel
> then depending on kernel goodies is the wrong strategy.

Well specifically if_ether.h says GPLv2+ so it's OK for QEMU.
Do you mean for some other non GPL app?

> >> The only other kernel dependency is linux/if_ether.h to define
> >> ETH_ALEN.  But it seems completely reasonable to define a
> >> VIRTIO_NET_MAC_ALEN or something like that.
> >
> > Ugh. Not really reasonable IMO. We also use ETH_P_IP in code,
> > would like to get rid of redefining that too.
> > But we can have our own linux/if_ether.h for non-linux hosts,
> > just with a
> > couple of macros like that, it's not a big deal.
> 
> See above.
> 
> Regards,
> 
> Anthony Liguori
> 
> >
> >> This would make the virtio headers completely stand alone and includable
> >> in userspace (without violating C99).
> >> 
> >> Perhaps it's even worth moving the headers from uapi/linux to
> >> uapi/virtio.  Rusty, what do you think?
> >> 
> >> Regards,
> >> 
> >> Anhtony Liguori
> >> 
> >> >
> >> > Paolo

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Anthony Liguori]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Sun, May 26, 2013 at 07:55:25PM -0500, Anthony Liguori wrote:
>> "Michael S. Tsirkin" <mst@redhat.com> writes:
>> 
>> > On Sun, May 26, 2013 at 03:49:53PM -0500, Anthony Liguori wrote:
>> >> Paolo Bonzini <pbonzini@redhat.com> writes:
>> >> 
>> >> > Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
>> >> >> > My fault.  I should have looked at linux/types.h (actually asm-generic/).
>> >> >> 
>> >> >> Not really, __uX appear in the headers that were posted.
>> >> 
>> >> Which is a problem because this is a reserved namespace in C99.
>> >> 
>> >> >> What I'm saying is - a chance of a conflict is very remote,
>> >> >> if it happens it's a build failure so easy to debug.
>> >> >
>> >> > I'm sure that others will complain, :) but you can go ahead.
>> >> 
>> >> I think we should clean up the virtio headers in the kernel first.
>> >> Seems like a good thing to do given the standardization effort too.
>> >> There are lots of headers in uapi that use the C99 int types
>> >
>> > I found 4:
>> > $ grep -l uint include/uapi/linux/*h
>> > include/uapi/linux/dm-log-userspace.h
>> > include/uapi/linux/fuse.h
>> > include/uapi/linux/jffs2.h
>> > include/uapi/linux/pps.h
>> > include/uapi/linux/rds.h
>> > include/uapi/linux/sctp.h
>> >
>> > That's not really lots.
>> >
>> >> so there
>> >> doesn't seem to be a reason they couldn't be used in virtio.  fuse.h
>> >> even has a:
>> >> 
>> >>     #ifdef __KERNEL__
>> >>     #include <linux/types.h>
>> >>     #else
>> >>     #include <stdint.h>
>> >>     #endif
>> >> 
>> >> Which seems like a reasonable thing to do.
>> >
>> > In kernel, we really want to use things like endian-ness
>> > checks (and, we really should have them in userspace too!).
>> > So we want __le32 and other kernel goodies
>> > like that. stdint.h won't cut it.
>> 
>> With the spec being standardized, I think having a stand alone set of
>> headers is a good thing.
>
> Sure, that's possible. We'll have to find some way to
> preserve the endian-ness annotations, I think.
> And then import them into kernel/qemu with some script, converting
> to kernel/qemu style and annotations?

See below.

>>  Licensing is problematic here too.
>> 
>> If virtio headers depend on other Linux headers, then it really doesn't
>> matter if they are BSD licensed if you need a GPL header (like
>> linux/if_ether.h).
>> 
>> Now, we can certainly debate the copyrightability of these defines and
>> what have you but if the headers are meant to be 1) consumed outside the
>> kernel 2) licensed under a different license than the general kernel
>> then depending on kernel goodies is the wrong strategy.
>
> Well specifically if_ether.h says GPLv2+ so it's OK for QEMU.
> Do you mean for some other non GPL app?

Ignore QEMU for the moment.

The headers say they are BSD licensed... but they include a GPLv2+
header.  Doesn't make a lot of sense, does it?

Again, I think it's something pretty basic here.  Either (1) these are
kernel/userspace headers that are meant to be consumed through libc or
whatever (2) these are kernel-private headers not to be consumed outside
of the kernel (3) these are headers meant to be copied widely and used
as a reference implementation of virtio.

If (1) or (2), copying them into QEMU via a magic sanitizing script is
wrong.  We should just keep doing what we're doing.

If (3), then we should clean up the virtio headers to be license clean
and usable outside of the kernel.  We shouldn't try to solve this
problem in QEMU (via scripts) if we can just solve it in the kernel.

Regards,

Anthony Liguori

>
>> >> The only other kernel dependency is linux/if_ether.h to define
>> >> ETH_ALEN.  But it seems completely reasonable to define a
>> >> VIRTIO_NET_MAC_ALEN or something like that.
>> >
>> > Ugh. Not really reasonable IMO. We also use ETH_P_IP in code,
>> > would like to get rid of redefining that too.
>> > But we can have our own linux/if_ether.h for non-linux hosts,
>> > just with a
>> > couple of macros like that, it's not a big deal.
>> 
>> See above.
>> 
>> Regards,
>> 
>> Anthony Liguori
>> 
>> >
>> >> This would make the virtio headers completely stand alone and includable
>> >> in userspace (without violating C99).
>> >> 
>> >> Perhaps it's even worth moving the headers from uapi/linux to
>> >> uapi/virtio.  Rusty, what do you think?
>> >> 
>> >> Regards,
>> >> 
>> >> Anhtony Liguori
>> >> 
>> >> >
>> >> > Paolo

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Anthony Liguori]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Sun, May 26, 2013 at 07:55:25PM -0500, Anthony Liguori wrote:
>> "Michael S. Tsirkin" <mst@redhat.com> writes:
>> 
>> > On Sun, May 26, 2013 at 03:49:53PM -0500, Anthony Liguori wrote:
>> >> Paolo Bonzini <pbonzini@redhat.com> writes:
>> >> 
>> >> > Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
>> >> >> > My fault.  I should have looked at linux/types.h (actually asm-generic/).
>> >> >> 
>> >> >> Not really, __uX appear in the headers that were posted.
>> >> 
>> >> Which is a problem because this is a reserved namespace in C99.
>> >> 
>> >> >> What I'm saying is - a chance of a conflict is very remote,
>> >> >> if it happens it's a build failure so easy to debug.
>> >> >
>> >> > I'm sure that others will complain, :) but you can go ahead.
>> >> 
>> >> I think we should clean up the virtio headers in the kernel first.
>> >> Seems like a good thing to do given the standardization effort too.
>> >> There are lots of headers in uapi that use the C99 int types
>> >
>> > I found 4:
>> > $ grep -l uint include/uapi/linux/*h
>> > include/uapi/linux/dm-log-userspace.h
>> > include/uapi/linux/fuse.h
>> > include/uapi/linux/jffs2.h
>> > include/uapi/linux/pps.h
>> > include/uapi/linux/rds.h
>> > include/uapi/linux/sctp.h
>> >
>> > That's not really lots.
>> >
>> >> so there
>> >> doesn't seem to be a reason they couldn't be used in virtio.  fuse.h
>> >> even has a:
>> >> 
>> >>     #ifdef __KERNEL__
>> >>     #include <linux/types.h>
>> >>     #else
>> >>     #include <stdint.h>
>> >>     #endif
>> >> 
>> >> Which seems like a reasonable thing to do.
>> >
>> > In kernel, we really want to use things like endian-ness
>> > checks (and, we really should have them in userspace too!).
>> > So we want __le32 and other kernel goodies
>> > like that. stdint.h won't cut it.
>> 
>> With the spec being standardized, I think having a stand alone set of
>> headers is a good thing.
>
> Sure, that's possible. We'll have to find some way to
> preserve the endian-ness annotations, I think.
> And then import them into kernel/qemu with some script, converting
> to kernel/qemu style and annotations?

See below.

>>  Licensing is problematic here too.
>> 
>> If virtio headers depend on other Linux headers, then it really doesn't
>> matter if they are BSD licensed if you need a GPL header (like
>> linux/if_ether.h).
>> 
>> Now, we can certainly debate the copyrightability of these defines and
>> what have you but if the headers are meant to be 1) consumed outside the
>> kernel 2) licensed under a different license than the general kernel
>> then depending on kernel goodies is the wrong strategy.
>
> Well specifically if_ether.h says GPLv2+ so it's OK for QEMU.
> Do you mean for some other non GPL app?

Ignore QEMU for the moment.

The headers say they are BSD licensed... but they include a GPLv2+
header.  Doesn't make a lot of sense, does it?

Again, I think it's something pretty basic here.  Either (1) these are
kernel/userspace headers that are meant to be consumed through libc or
whatever (2) these are kernel-private headers not to be consumed outside
of the kernel (3) these are headers meant to be copied widely and used
as a reference implementation of virtio.

If (1) or (2), copying them into QEMU via a magic sanitizing script is
wrong.  We should just keep doing what we're doing.

If (3), then we should clean up the virtio headers to be license clean
and usable outside of the kernel.  We shouldn't try to solve this
problem in QEMU (via scripts) if we can just solve it in the kernel.

Regards,

Anthony Liguori

>
>> >> The only other kernel dependency is linux/if_ether.h to define
>> >> ETH_ALEN.  But it seems completely reasonable to define a
>> >> VIRTIO_NET_MAC_ALEN or something like that.
>> >
>> > Ugh. Not really reasonable IMO. We also use ETH_P_IP in code,
>> > would like to get rid of redefining that too.
>> > But we can have our own linux/if_ether.h for non-linux hosts,
>> > just with a
>> > couple of macros like that, it's not a big deal.
>> 
>> See above.
>> 
>> Regards,
>> 
>> Anthony Liguori
>> 
>> >
>> >> This would make the virtio headers completely stand alone and includable
>> >> in userspace (without violating C99).
>> >> 
>> >> Perhaps it's even worth moving the headers from uapi/linux to
>> >> uapi/virtio.  Rusty, what do you think?
>> >> 
>> >> Regards,
>> >> 
>> >> Anhtony Liguori
>> >> 
>> >> >
>> >> > Paolo

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Anthony Liguori]

Rusty Russell <rusty@rustcorp.com.au> writes:

> Anthony Liguori <anthony@codemonkey.ws> writes:
>> Paolo Bonzini <pbonzini@redhat.com> writes:
>>
>>> Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
>>>> > My fault.  I should have looked at linux/types.h (actually asm-generic/).
>>>> 
>>>> Not really, __uX appear in the headers that were posted.
>>
>> Which is a problem because this is a reserved namespace in C99.
>
> Personally, I find it hard to care.  What matters is not what the
> standard has carved out, but whether we have clashes, reserved namespace
> or no.  And that won't happen for these.
>
> If someone wants to convert all the kernel headers, I won't NAK it
> though.

virtio headers are special.  Linux headers are normally only consumed in
the kernel or in a userspace application running on Linux.

virtio headers may be used either in a userspace application running on
!Linux (we need to support QEMU on Windows) or even in a foreign kernel.

linux/types.h is unusable outside of Linux because it pulls in a bunch
of other headers.  If you look at Michael's patch, he adds his own
version of types.h.  It's unfortunate for every user of the headers to
do this.

Regards,

Anthony Liguori

>> Perhaps it's even worth moving the headers from uapi/linux to
>> uapi/virtio.  Rusty, what do you think?
>
> Hmm, #include <virtio/virtio_net.h> etc would be worthwhile if that also
> worked on FreeBSD.  Bryan CC'd...
>
> Cheers,
> Rusty.

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Michael S. Tsirkin]

On Mon, May 27, 2013 at 11:14:47AM -0500, Anthony Liguori wrote:
> > Well specifically if_ether.h says GPLv2+ so it's OK for QEMU.
> > Do you mean for some other non GPL app?
> 
> Ignore QEMU for the moment.
> 
> The headers say they are BSD licensed... but they include a GPLv2+
> header.

Above is a bit misleading.  To be precise, they don't include a GPLv2+
header. One header merely includes this line:
#include <linux/if_ether.h>

-- 
MST

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Michael S. Tsirkin]

On Mon, May 27, 2013 at 11:14:47AM -0500, Anthony Liguori wrote:
> > Well specifically if_ether.h says GPLv2+ so it's OK for QEMU.
> > Do you mean for some other non GPL app?
> 
> Ignore QEMU for the moment.
> 
> The headers say they are BSD licensed... but they include a GPLv2+
> header.

Above is a bit misleading.  To be precise, they don't include a GPLv2+
header. One header merely includes this line:
#include <linux/if_ether.h>

-- 
MST

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Rusty Russell]

Anthony Liguori <anthony@codemonkey.ws> writes:
> The headers say they are BSD licensed... but they include a GPLv2+
> header.  Doesn't make a lot of sense, does it?

It makes perfect sense: you're overthinking it.  It just means that
copying the BSD headers outside Linux is encouraged.

And it's clearly nonsensical to claim the GPL on kernel headers means
that userspace needs to be GPL.  So please ignore this licensing
red-herring.

And we'll bikeshed the headers in the standard when we have to :)  They
certainly don't need to be cut&paste into the kernel sources.

Cheers,
Rusty.

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Rusty Russell]

Anthony Liguori <anthony@codemonkey.ws> writes:
> Rusty Russell <rusty@rustcorp.com.au> writes:
>
>> Anthony Liguori <anthony@codemonkey.ws> writes:
>>> Paolo Bonzini <pbonzini@redhat.com> writes:
>>>
>>>> Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
>>>>> > My fault.  I should have looked at linux/types.h (actually asm-generic/).
>>>>> 
>>>>> Not really, __uX appear in the headers that were posted.
>>>
>>> Which is a problem because this is a reserved namespace in C99.
>>
>> Personally, I find it hard to care.  What matters is not what the
>> standard has carved out, but whether we have clashes, reserved namespace
>> or no.  And that won't happen for these.
>>
>> If someone wants to convert all the kernel headers, I won't NAK it
>> though.
>
> virtio headers are special.  Linux headers are normally only consumed in
> the kernel or in a userspace application running on Linux.
>
> virtio headers may be used either in a userspace application running on
> !Linux (we need to support QEMU on Windows) or even in a foreign kernel.

No.

s/virtio/SCSI/.  s/virtio/if_eth/.  s/virtio/TCPIP/.

Cheers,
Rusty.

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Rusty Russell]

Anthony Liguori <anthony@codemonkey.ws> writes:
> Rusty Russell <rusty@rustcorp.com.au> writes:
>
>> Anthony Liguori <anthony@codemonkey.ws> writes:
>>> Paolo Bonzini <pbonzini@redhat.com> writes:
>>>
>>>> Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
>>>>> > My fault.  I should have looked at linux/types.h (actually asm-generic/).
>>>>> 
>>>>> Not really, __uX appear in the headers that were posted.
>>>
>>> Which is a problem because this is a reserved namespace in C99.
>>
>> Personally, I find it hard to care.  What matters is not what the
>> standard has carved out, but whether we have clashes, reserved namespace
>> or no.  And that won't happen for these.
>>
>> If someone wants to convert all the kernel headers, I won't NAK it
>> though.
>
> virtio headers are special.  Linux headers are normally only consumed in
> the kernel or in a userspace application running on Linux.
>
> virtio headers may be used either in a userspace application running on
> !Linux (we need to support QEMU on Windows) or even in a foreign kernel.

No.

s/virtio/SCSI/.  s/virtio/if_eth/.  s/virtio/TCPIP/.

Cheers,
Rusty.

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Bryan Venteicher]

[-- Attachment #1: Type: text/plain, Size: 1994 bytes --]

On Mon, May 27, 2013 at 6:15 AM, Rusty Russell <rusty@rustcorp.com.au>wrote:

> Anthony Liguori <anthony@codemonkey.ws> writes:
> > Paolo Bonzini <pbonzini@redhat.com> writes:
> >
> >> Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
> >>> > My fault.  I should have looked at linux/types.h (actually
> asm-generic/).
> >>>
> >>> Not really, __uX appear in the headers that were posted.
> >
> > Which is a problem because this is a reserved namespace in C99.
>
> Personally, I find it hard to care.  What matters is not what the
> standard has carved out, but whether we have clashes, reserved namespace
> or no.  And that won't happen for these.
>
> If someone wants to convert all the kernel headers, I won't NAK it
> though.
>
> > Perhaps it's even worth moving the headers from uapi/linux to
> > uapi/virtio.  Rusty, what do you think?
>
> Hmm, #include <virtio/virtio_net.h> etc would be worthwhile if that also
> worked on FreeBSD.  Bryan CC'd...
>
>
I've only done minor work on the VirtIO headers when importing them to
FreeBSD - mostly converting the _XX types to the preferred C99 variants,
along with some misc nits. I'm not too concerned with keeping the
headers identical to what is in Linux; I manually merge in required changes
when supporting a new feature and this hasn't been an issue. I'm content as
long as they remain BSD licensed. Growing GPL'ed #includes is a bit
worrisome, but I have a hard time foreseeing what the VirtIO files
could possibly depend on that isn't trivial.

I don't think I have enough context to understand the  ' #include
<virtio/virtio_net.h> etc' suggestion ... In FreeBSD, the VirtIO headers
files exist only in the source tree along side the corresponding device,
ie. sys/dev/virtio/network/virtio_net.h, sys/dev/virtio/pci/virtio_pci.h,
etc. The FreeBSD hypervisor (bhyve) just duplicates the
needed definitions/defines. This will be fixed at some point, but bhyve's
VirtIO is so barebones there is bigger fish to fry.


> Cheers,
> Rusty.
>

[-- Attachment #2: Type: text/html, Size: 2937 bytes --]

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Bryan Venteicher]

[-- Attachment #1.1: Type: text/plain, Size: 1994 bytes --]

On Mon, May 27, 2013 at 6:15 AM, Rusty Russell <rusty@rustcorp.com.au>wrote:

> Anthony Liguori <anthony@codemonkey.ws> writes:
> > Paolo Bonzini <pbonzini@redhat.com> writes:
> >
> >> Il 26/05/2013 22:02, Michael S. Tsirkin ha scritto:
> >>> > My fault.  I should have looked at linux/types.h (actually
> asm-generic/).
> >>>
> >>> Not really, __uX appear in the headers that were posted.
> >
> > Which is a problem because this is a reserved namespace in C99.
>
> Personally, I find it hard to care.  What matters is not what the
> standard has carved out, but whether we have clashes, reserved namespace
> or no.  And that won't happen for these.
>
> If someone wants to convert all the kernel headers, I won't NAK it
> though.
>
> > Perhaps it's even worth moving the headers from uapi/linux to
> > uapi/virtio.  Rusty, what do you think?
>
> Hmm, #include <virtio/virtio_net.h> etc would be worthwhile if that also
> worked on FreeBSD.  Bryan CC'd...
>
>
I've only done minor work on the VirtIO headers when importing them to
FreeBSD - mostly converting the _XX types to the preferred C99 variants,
along with some misc nits. I'm not too concerned with keeping the
headers identical to what is in Linux; I manually merge in required changes
when supporting a new feature and this hasn't been an issue. I'm content as
long as they remain BSD licensed. Growing GPL'ed #includes is a bit
worrisome, but I have a hard time foreseeing what the VirtIO files
could possibly depend on that isn't trivial.

I don't think I have enough context to understand the  ' #include
<virtio/virtio_net.h> etc' suggestion ... In FreeBSD, the VirtIO headers
files exist only in the source tree along side the corresponding device,
ie. sys/dev/virtio/network/virtio_net.h, sys/dev/virtio/pci/virtio_pci.h,
etc. The FreeBSD hypervisor (bhyve) just duplicates the
needed definitions/defines. This will be fixed at some point, but bhyve's
VirtIO is so barebones there is bigger fish to fry.


> Cheers,
> Rusty.
>

[-- Attachment #1.2: Type: text/html, Size: 2937 bytes --]

[-- Attachment #2: Type: text/plain, Size: 183 bytes --]

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Anthony Liguori]

Rusty Russell <rusty@rustcorp.com.au> writes:

> Anthony Liguori <anthony@codemonkey.ws> writes:
>> The headers say they are BSD licensed... but they include a GPLv2+
>> header.  Doesn't make a lot of sense, does it?
>
> It makes perfect sense: you're overthinking it.  It just means that
> copying the BSD headers outside Linux is encouraged.

Copying by hand and modifying.  This patch series attempts to do it
automatically within QEMU.

> And it's clearly nonsensical to claim the GPL on kernel headers means
> that userspace needs to be GPL.  So please ignore this licensing
> red-herring.

You're missing context, I suspect.  This series is trying to
automatically copy the headers from Linux.  We currently have a manually
copied version.

The headers are not currently well suited for automatic copying because
(1) they use kernel types (2) they pull in dependencies from throughout
the kernel.

This discussion comes down to whether we want to make it easier to
automatically copy the headers or do we maintain the status quo and
require manual munging to pull in the headers.

Regards,

Anthony Liguori

>
> And we'll bikeshed the headers in the standard when we have to :)  They
> certainly don't need to be cut&paste into the kernel sources.
>
> Cheers,
> Rusty.

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Michael S. Tsirkin]

On Wed, May 29, 2013 at 08:05:29AM -0500, Anthony Liguori wrote:
> Rusty Russell <rusty@rustcorp.com.au> writes:
> 
> > Anthony Liguori <anthony@codemonkey.ws> writes:
> >> The headers say they are BSD licensed... but they include a GPLv2+
> >> header.  Doesn't make a lot of sense, does it?
> >
> > It makes perfect sense: you're overthinking it.  It just means that
> > copying the BSD headers outside Linux is encouraged.
> 
> Copying by hand and modifying.  This patch series attempts to do it
> automatically within QEMU.
> 
> > And it's clearly nonsensical to claim the GPL on kernel headers means
> > that userspace needs to be GPL.  So please ignore this licensing
> > red-herring.
> 
> You're missing context, I suspect.  This series is trying to
> automatically copy the headers from Linux.  We currently have a manually
> copied version.
> 
> The headers are not currently well suited for automatic copying because
> (1) they use kernel types (2) they pull in dependencies from throughout
> the kernel.
> 
> This discussion comes down to whether we want to make it easier to
> automatically copy the headers or do we maintain the status quo and
> require manual munging to pull in the headers.
> 
> Regards,
> 
> Anthony Liguori

Okay, what if I

1. add a stub if_ether.h with a couple of macros we want
2. replace the types during copying

Would this address all concerns?

> >
> > And we'll bikeshed the headers in the standard when we have to :)  They
> > certainly don't need to be cut&paste into the kernel sources.
> >
> > Cheers,
> > Rusty.

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Michael S. Tsirkin]

On Wed, May 29, 2013 at 08:05:29AM -0500, Anthony Liguori wrote:
> Rusty Russell <rusty@rustcorp.com.au> writes:
> 
> > Anthony Liguori <anthony@codemonkey.ws> writes:
> >> The headers say they are BSD licensed... but they include a GPLv2+
> >> header.  Doesn't make a lot of sense, does it?
> >
> > It makes perfect sense: you're overthinking it.  It just means that
> > copying the BSD headers outside Linux is encouraged.
> 
> Copying by hand and modifying.  This patch series attempts to do it
> automatically within QEMU.
> 
> > And it's clearly nonsensical to claim the GPL on kernel headers means
> > that userspace needs to be GPL.  So please ignore this licensing
> > red-herring.
> 
> You're missing context, I suspect.  This series is trying to
> automatically copy the headers from Linux.  We currently have a manually
> copied version.
> 
> The headers are not currently well suited for automatic copying because
> (1) they use kernel types (2) they pull in dependencies from throughout
> the kernel.
> 
> This discussion comes down to whether we want to make it easier to
> automatically copy the headers or do we maintain the status quo and
> require manual munging to pull in the headers.
> 
> Regards,
> 
> Anthony Liguori

Okay, what if I

1. add a stub if_ether.h with a couple of macros we want
2. replace the types during copying

Would this address all concerns?

> >
> > And we'll bikeshed the headers in the standard when we have to :)  They
> > certainly don't need to be cut&paste into the kernel sources.
> >
> > Cheers,
> > Rusty.

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Anthony Liguori]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Wed, May 29, 2013 at 08:05:29AM -0500, Anthony Liguori wrote:
>> Rusty Russell <rusty@rustcorp.com.au> writes:
>> 
>> > Anthony Liguori <anthony@codemonkey.ws> writes:
>> >> The headers say they are BSD licensed... but they include a GPLv2+
>> >> header.  Doesn't make a lot of sense, does it?
>> >
>> > It makes perfect sense: you're overthinking it.  It just means that
>> > copying the BSD headers outside Linux is encouraged.
>> 
>> Copying by hand and modifying.  This patch series attempts to do it
>> automatically within QEMU.
>> 
>> > And it's clearly nonsensical to claim the GPL on kernel headers means
>> > that userspace needs to be GPL.  So please ignore this licensing
>> > red-herring.
>> 
>> You're missing context, I suspect.  This series is trying to
>> automatically copy the headers from Linux.  We currently have a manually
>> copied version.
>> 
>> The headers are not currently well suited for automatic copying because
>> (1) they use kernel types (2) they pull in dependencies from throughout
>> the kernel.
>> 
>> This discussion comes down to whether we want to make it easier to
>> automatically copy the headers or do we maintain the status quo and
>> require manual munging to pull in the headers.
>> 
>> Regards,
>> 
>> Anthony Liguori
>
> Okay, what if I
>
> 1. add a stub if_ether.h with a couple of macros we want
> 2. replace the types during copying
>
> Would this address all concerns?

If Rusty doesn't like the idea of making the headers usable directly,
then I don't object to having stubs/scripts to sanitize them in QEMU.

Regards,

Anthony Liguori

>
>> >
>> > And we'll bikeshed the headers in the standard when we have to :)  They
>> > certainly don't need to be cut&paste into the kernel sources.
>> >
>> > Cheers,
>> > Rusty.

Re: [Qemu-devel] [PATCH v2 00/11] qemu: use virtio linux headers in portable code

[Anthony Liguori]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Wed, May 29, 2013 at 08:05:29AM -0500, Anthony Liguori wrote:
>> Rusty Russell <rusty@rustcorp.com.au> writes:
>> 
>> > Anthony Liguori <anthony@codemonkey.ws> writes:
>> >> The headers say they are BSD licensed... but they include a GPLv2+
>> >> header.  Doesn't make a lot of sense, does it?
>> >
>> > It makes perfect sense: you're overthinking it.  It just means that
>> > copying the BSD headers outside Linux is encouraged.
>> 
>> Copying by hand and modifying.  This patch series attempts to do it
>> automatically within QEMU.
>> 
>> > And it's clearly nonsensical to claim the GPL on kernel headers means
>> > that userspace needs to be GPL.  So please ignore this licensing
>> > red-herring.
>> 
>> You're missing context, I suspect.  This series is trying to
>> automatically copy the headers from Linux.  We currently have a manually
>> copied version.
>> 
>> The headers are not currently well suited for automatic copying because
>> (1) they use kernel types (2) they pull in dependencies from throughout
>> the kernel.
>> 
>> This discussion comes down to whether we want to make it easier to
>> automatically copy the headers or do we maintain the status quo and
>> require manual munging to pull in the headers.
>> 
>> Regards,
>> 
>> Anthony Liguori
>
> Okay, what if I
>
> 1. add a stub if_ether.h with a couple of macros we want
> 2. replace the types during copying
>
> Would this address all concerns?

If Rusty doesn't like the idea of making the headers usable directly,
then I don't object to having stubs/scripts to sanitize them in QEMU.

Regards,

Anthony Liguori

>
>> >
>> > And we'll bikeshed the headers in the standard when we have to :)  They
>> > certainly don't need to be cut&paste into the kernel sources.
>> >
>> > Cheers,
>> > Rusty.