All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3 7/7] net/virtio_user: enable multiqueue with vhost kernel
From: Jianfeng Tan @ 2017-01-04  3:59 UTC (permalink / raw)
  To: dev; +Cc: yuanhan.liu, ferruh.yigit, cunming.liang, Jianfeng Tan
In-Reply-To: <1483502366-140154-1-git-send-email-jianfeng.tan@intel.com>

With vhost kernel, to enable multiqueue, we need backend device
in kernel support multiqueue feature. Specifically, with tap
as the backend, as linux/Documentation/networking/tuntap.txt shows,
we check if tap supports IFF_MULTI_QUEUE feature.

And for vhost kernel, each queue pair has a vhost fd, and with a tap
fd binding this vhost fd. All tap fds are set with the same tap
interface name.

Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
---
 drivers/net/virtio/virtio_user/vhost_kernel.c    | 69 +++++++++++++++++++++---
 drivers/net/virtio/virtio_user/virtio_user_dev.c |  1 +
 2 files changed, 64 insertions(+), 6 deletions(-)

diff --git a/drivers/net/virtio/virtio_user/vhost_kernel.c b/drivers/net/virtio/virtio_user/vhost_kernel.c
index bdb4af2..023bdf8 100644
--- a/drivers/net/virtio/virtio_user/vhost_kernel.c
+++ b/drivers/net/virtio/virtio_user/vhost_kernel.c
@@ -206,6 +206,29 @@ prepare_vhost_memory_kernel(void)
 	 (1ULL << VIRTIO_NET_F_CSUM))
 
 static int
+tap_supporte_mq(void)
+{
+	int tapfd;
+	unsigned int tap_features;
+
+	tapfd = open(PATH_NET_TUN, O_RDWR);
+	if (tapfd < 0) {
+		PMD_DRV_LOG(ERR, "fail to open %s: %s",
+			    PATH_NET_TUN, strerror(errno));
+		return -1;
+	}
+
+	if (ioctl(tapfd, TUNGETFEATURES, &tap_features) == -1) {
+		PMD_DRV_LOG(ERR, "TUNGETFEATURES failed: %s", strerror(errno));
+		close(tapfd);
+		return -1;
+	}
+
+	close(tapfd);
+	return tap_features & IFF_MULTI_QUEUE;
+}
+
+static int
 vhost_kernel_ioctl(struct virtio_user_dev *dev,
 		   enum vhost_user_request req,
 		   void *arg)
@@ -213,6 +236,8 @@ vhost_kernel_ioctl(struct virtio_user_dev *dev,
 	int i, ret = -1;
 	uint64_t req_kernel;
 	struct vhost_memory_kernel *vm = NULL;
+	int vhostfd;
+	unsigned int queue_sel;
 
 	PMD_DRV_LOG(INFO, "%s", vhost_msg_strings[req]);
 
@@ -232,15 +257,37 @@ vhost_kernel_ioctl(struct virtio_user_dev *dev,
 		/* VHOST kernel does not know about below flags */
 		*(uint64_t *)arg &= ~VHOST_KERNEL_GUEST_OFFLOADS_MASK;
 		*(uint64_t *)arg &= ~VHOST_KERNEL_HOST_OFFLOADS_MASK;
+
+		*(uint64_t *)arg &= ~(1ULL << VIRTIO_NET_F_MQ);
 	}
 
-	for (i = 0; i < VHOST_KERNEL_MAX_QUEUES; ++i) {
-		if (dev->vhostfds[i] < 0)
-			continue;
+	switch (req_kernel) {
+	case VHOST_SET_VRING_NUM:
+	case VHOST_SET_VRING_ADDR:
+	case VHOST_SET_VRING_BASE:
+	case VHOST_GET_VRING_BASE:
+	case VHOST_SET_VRING_KICK:
+	case VHOST_SET_VRING_CALL:
+		queue_sel = *(unsigned int *)arg;
+		vhostfd = dev->vhostfds[queue_sel / 2];
+		*(unsigned int *)arg = queue_sel % 2;
+		PMD_DRV_LOG(DEBUG, "vhostfd=%d, index=%u",
+			    vhostfd, *(unsigned int *)arg);
+		break;
+	default:
+		vhostfd = -1;
+	}
+	if (vhostfd == -1) {
+		for (i = 0; i < VHOST_KERNEL_MAX_QUEUES; ++i) {
+			if (dev->vhostfds[i] < 0)
+				continue;
 
-		ret = ioctl(dev->vhostfds[i], req_kernel, arg);
-		if (ret < 0)
-			break;
+			ret = ioctl(dev->vhostfds[i], req_kernel, arg);
+			if (ret < 0)
+				break;
+		}
+	} else {
+		ret = ioctl(vhostfd, req_kernel, arg);
 	}
 
 	if (!ret && req_kernel == VHOST_GET_FEATURES) {
@@ -250,6 +297,12 @@ vhost_kernel_ioctl(struct virtio_user_dev *dev,
 		 */
 		*((uint64_t *)arg) |= VHOST_KERNEL_GUEST_OFFLOADS_MASK;
 		*((uint64_t *)arg) |= VHOST_KERNEL_HOST_OFFLOADS_MASK;
+
+		/* vhost_kernel will not declare this feature, but it does
+		 * support multi-queue.
+		 */
+		if (tap_supporte_mq())
+			*(uint64_t *)arg |= (1ull << VIRTIO_NET_F_MQ);
 	}
 
 	if (vm)
@@ -329,6 +382,7 @@ vhost_kernel_enable_queue_pair(struct virtio_user_dev *dev,
 			TUN_F_TSO6 |
 			TUN_F_TSO_ECN |
 			TUN_F_UFO;
+	int req_mq = (dev->max_queue_pairs > 1);
 
 	vhostfd = dev->vhostfds[pair_idx];
 
@@ -382,6 +436,9 @@ vhost_kernel_enable_queue_pair(struct virtio_user_dev *dev,
 		goto error;
 	}
 
+	if (req_mq)
+		ifr.ifr_flags |= IFF_MULTI_QUEUE;
+
 	if (dev->ifname)
 		strncpy(ifr.ifr_name, dev->ifname, IFNAMSIZ);
 	else
diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c b/drivers/net/virtio/virtio_user/virtio_user_dev.c
index c40b77e..2d9d989 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.c
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c
@@ -93,6 +93,7 @@ virtio_user_kick_queue(struct virtio_user_dev *dev, uint32_t queue_sel)
 	state.num = vring->num;
 	dev->ops->send_request(dev, VHOST_USER_SET_VRING_NUM, &state);
 
+	state.index = queue_sel;
 	state.num = 0; /* no reservation */
 	dev->ops->send_request(dev, VHOST_USER_SET_VRING_BASE, &state);
 
-- 
2.7.4

^ permalink raw reply related

* [PATCH v3 1/7] net/virtio_user: fix wrongly set features
From: Jianfeng Tan @ 2017-01-04  3:59 UTC (permalink / raw)
  To: dev; +Cc: yuanhan.liu, ferruh.yigit, cunming.liang, Jianfeng Tan, stable
In-Reply-To: <1483502366-140154-1-git-send-email-jianfeng.tan@intel.com>

Before the commit 86d59b21468a ("net/virtio: support LRO"), features
in virtio PMD, is decided and properly set at device initialization
and will not be changed. But afterward, features could be changed in
virtio_dev_configure(), and will be re-negotiated if it's changed.

In virtio_user, device features is obtained at driver probe phase
only once, but we did not store it. So the added feature bits in
re-negotiation will fail.

To fix it, we store it down, and will be used to feature negotiation
either at device initialization phase or device configure phase.

Fixes: e9efa4d93821 ("net/virtio-user: add new virtual PCI driver")

CC: stable@dpdk.org

Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
---
 drivers/net/virtio/virtio_user/virtio_user_dev.c | 34 +++++++++++-------------
 drivers/net/virtio/virtio_user/virtio_user_dev.h |  5 +++-
 drivers/net/virtio/virtio_user_ethdev.c          |  4 +--
 3 files changed, 22 insertions(+), 21 deletions(-)

diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c b/drivers/net/virtio/virtio_user/virtio_user_dev.c
index e239e0e..0d7e17b 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.c
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c
@@ -148,12 +148,13 @@ virtio_user_start_device(struct virtio_user_dev *dev)
 
 	/* Step 1: set features
 	 * Make sure VHOST_USER_F_PROTOCOL_FEATURES is added if mq is enabled,
-	 * and VIRTIO_NET_F_MAC is stripped.
+	 * VIRTIO_NET_F_MAC and VIRTIO_NET_F_CTRL_VQ is stripped.
 	 */
 	features = dev->features;
 	if (dev->max_queue_pairs > 1)
 		features |= VHOST_USER_MQ;
 	features &= ~(1ull << VIRTIO_NET_F_MAC);
+	features &= ~(1ull << VIRTIO_NET_F_CTRL_VQ);
 	ret = vhost_user_sock(dev->vhostfd, VHOST_USER_SET_FEATURES, &features);
 	if (ret < 0)
 		goto error;
@@ -228,29 +229,26 @@ virtio_user_dev_init(struct virtio_user_dev *dev, char *path, int queues,
 	}
 
 	if (vhost_user_sock(dev->vhostfd, VHOST_USER_GET_FEATURES,
-			    &dev->features) < 0) {
+			    &dev->device_features) < 0) {
 		PMD_INIT_LOG(ERR, "get_features failed: %s", strerror(errno));
 		return -1;
 	}
 	if (dev->mac_specified)
-		dev->features |= (1ull << VIRTIO_NET_F_MAC);
+		dev->device_features |= (1ull << VIRTIO_NET_F_MAC);
 
-	if (!cq) {
-		dev->features &= ~(1ull << VIRTIO_NET_F_CTRL_VQ);
-		/* Also disable features depends on VIRTIO_NET_F_CTRL_VQ */
-		dev->features &= ~(1ull << VIRTIO_NET_F_CTRL_RX);
-		dev->features &= ~(1ull << VIRTIO_NET_F_CTRL_VLAN);
-		dev->features &= ~(1ull << VIRTIO_NET_F_GUEST_ANNOUNCE);
-		dev->features &= ~(1ull << VIRTIO_NET_F_MQ);
-		dev->features &= ~(1ull << VIRTIO_NET_F_CTRL_MAC_ADDR);
-	} else {
-		/* vhost user backend does not need to know ctrl-q, so
-		 * actually we need add this bit into features. However,
-		 * DPDK vhost-user does send features with this bit, so we
-		 * check it instead of OR it for now.
+	if (cq) {
+		/* device does not really need to know anything about CQ,
+		 * so if necessary, we just claim to support CQ
 		 */
-		if (!(dev->features & (1ull << VIRTIO_NET_F_CTRL_VQ)))
-			PMD_INIT_LOG(INFO, "vhost does not support ctrl-q");
+		dev->device_features |= (1ull << VIRTIO_NET_F_CTRL_VQ);
+	} else {
+		dev->device_features &= ~(1ull << VIRTIO_NET_F_CTRL_VQ);
+		/* Also disable features depends on VIRTIO_NET_F_CTRL_VQ */
+		dev->device_features &= ~(1ull << VIRTIO_NET_F_CTRL_RX);
+		dev->device_features &= ~(1ull << VIRTIO_NET_F_CTRL_VLAN);
+		dev->device_features &= ~(1ull << VIRTIO_NET_F_GUEST_ANNOUNCE);
+		dev->device_features &= ~(1ull << VIRTIO_NET_F_MQ);
+		dev->device_features &= ~(1ull << VIRTIO_NET_F_CTRL_MAC_ADDR);
 	}
 
 	if (dev->max_queue_pairs > 1) {
diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.h b/drivers/net/virtio/virtio_user/virtio_user_dev.h
index 33690b5..28fc788 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.h
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.h
@@ -46,7 +46,10 @@ struct virtio_user_dev {
 	uint32_t	max_queue_pairs;
 	uint32_t	queue_pairs;
 	uint32_t	queue_size;
-	uint64_t	features;
+	uint64_t	features; /* the negotiated features with driver,
+				   * and will be sync with device
+				   */
+	uint64_t	device_features; /* supported features by device */
 	uint8_t		status;
 	uint8_t		mac_addr[ETHER_ADDR_LEN];
 	char		path[PATH_MAX];
diff --git a/drivers/net/virtio/virtio_user_ethdev.c b/drivers/net/virtio/virtio_user_ethdev.c
index 8cb983c..4a5a227 100644
--- a/drivers/net/virtio/virtio_user_ethdev.c
+++ b/drivers/net/virtio/virtio_user_ethdev.c
@@ -117,7 +117,7 @@ virtio_user_get_features(struct virtio_hw *hw)
 {
 	struct virtio_user_dev *dev = virtio_user_get_dev(hw);
 
-	return dev->features;
+	return dev->device_features;
 }
 
 static void
@@ -125,7 +125,7 @@ virtio_user_set_features(struct virtio_hw *hw, uint64_t features)
 {
 	struct virtio_user_dev *dev = virtio_user_get_dev(hw);
 
-	dev->features = features;
+	dev->features = features & dev->device_features;
 }
 
 static uint8_t
-- 
2.7.4

^ permalink raw reply related

* [PATCH v3 2/7] net/virtio_user: fix not properly reset device
From: Jianfeng Tan @ 2017-01-04  3:59 UTC (permalink / raw)
  To: dev; +Cc: yuanhan.liu, ferruh.yigit, cunming.liang, Jianfeng Tan, stable
In-Reply-To: <1483502366-140154-1-git-send-email-jianfeng.tan@intel.com>

virtio_user is not properly reset when users call vtpci_reset(),
as it ignores VIRTIO_CONFIG_STATUS_RESET status in
virtio_user_set_status().

This might lead to initialization failure as it starts to re-init
the device before sending RESET messege to backend. Besides, previous
callfds and kickfds are not closed.

To fix it, we add support to disable virtqueues when it's set to
DRIVER OK status, and re-init fields in struct virtio_user_dev.

Fixes: e9efa4d93821 ("net/virtio-user: add new virtual PCI driver")
Fixes: 37a7eb2ae816 ("net/virtio-user: add device emulation layer")

CC: stable@dpdk.org

Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
---
 drivers/net/virtio/virtio_user/virtio_user_dev.c | 26 ++++++++++++++++--------
 drivers/net/virtio/virtio_user_ethdev.c          | 15 ++++++++------
 2 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c b/drivers/net/virtio/virtio_user/virtio_user_dev.c
index 0d7e17b..a38398b 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.c
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c
@@ -182,7 +182,17 @@ virtio_user_start_device(struct virtio_user_dev *dev)
 
 int virtio_user_stop_device(struct virtio_user_dev *dev)
 {
-	return vhost_user_sock(dev->vhostfd, VHOST_USER_RESET_OWNER, NULL);
+	uint32_t i;
+
+	for (i = 0; i < dev->max_queue_pairs * 2; ++i) {
+		close(dev->callfds[i]);
+		close(dev->kickfds[i]);
+	}
+
+	for (i = 0; i < dev->max_queue_pairs; ++i)
+		vhost_user_enable_queue_pair(dev->vhostfd, i, 0);
+
+	return 0;
 }
 
 static inline void
@@ -210,6 +220,8 @@ int
 virtio_user_dev_init(struct virtio_user_dev *dev, char *path, int queues,
 		     int cq, int queue_size, const char *mac)
 {
+	uint32_t i;
+
 	snprintf(dev->path, PATH_MAX, "%s", path);
 	dev->max_queue_pairs = queues;
 	dev->queue_pairs = 1; /* mq disabled by default */
@@ -218,6 +230,11 @@ virtio_user_dev_init(struct virtio_user_dev *dev, char *path, int queues,
 	parse_mac(dev, mac);
 	dev->vhostfd = -1;
 
+	for (i = 0; i < VIRTIO_MAX_VIRTQUEUES * 2 + 1; ++i) {
+		dev->kickfds[i] = -1;
+		dev->callfds[i] = -1;
+	}
+
 	dev->vhostfd = vhost_user_setup(dev->path);
 	if (dev->vhostfd < 0) {
 		PMD_INIT_LOG(ERR, "backend set up fails");
@@ -264,13 +281,6 @@ virtio_user_dev_init(struct virtio_user_dev *dev, char *path, int queues,
 void
 virtio_user_dev_uninit(struct virtio_user_dev *dev)
 {
-	uint32_t i;
-
-	for (i = 0; i < dev->max_queue_pairs * 2; ++i) {
-		close(dev->callfds[i]);
-		close(dev->kickfds[i]);
-	}
-
 	close(dev->vhostfd);
 }
 
diff --git a/drivers/net/virtio/virtio_user_ethdev.c b/drivers/net/virtio/virtio_user_ethdev.c
index 4a5a227..93f5b01 100644
--- a/drivers/net/virtio/virtio_user_ethdev.c
+++ b/drivers/net/virtio/virtio_user_ethdev.c
@@ -87,21 +87,24 @@ virtio_user_write_dev_config(struct virtio_hw *hw, size_t offset,
 }
 
 static void
-virtio_user_set_status(struct virtio_hw *hw, uint8_t status)
+virtio_user_reset(struct virtio_hw *hw)
 {
 	struct virtio_user_dev *dev = virtio_user_get_dev(hw);
 
-	if (status & VIRTIO_CONFIG_STATUS_DRIVER_OK)
-		virtio_user_start_device(dev);
-	dev->status = status;
+	if (dev->status & VIRTIO_CONFIG_STATUS_DRIVER_OK)
+		virtio_user_stop_device(dev);
 }
 
 static void
-virtio_user_reset(struct virtio_hw *hw)
+virtio_user_set_status(struct virtio_hw *hw, uint8_t status)
 {
 	struct virtio_user_dev *dev = virtio_user_get_dev(hw);
 
-	virtio_user_stop_device(dev);
+	if (status & VIRTIO_CONFIG_STATUS_DRIVER_OK)
+		virtio_user_start_device(dev);
+	else if (status == VIRTIO_CONFIG_STATUS_RESET)
+		virtio_user_reset(hw);
+	dev->status = status;
 }
 
 static uint8_t
-- 
2.7.4

^ permalink raw reply related

* Re: [PATCH] f2fs: fix small discards when se->valid_blocks is zero
From: Yunlong Song @ 2017-01-04  3:59 UTC (permalink / raw)
  To: Jaegeuk Kim
  Cc: cm224.lee, yuchao0, chao, sylinux, bintian.wang, linux-fsdevel,
	linux-f2fs-devel, linux-kernel
In-Reply-To: <20170104015510.GB16504@jaegeuk.local>

Hi Kim,
    Although the blocks of that file will finally be discarded when it is not current segment any more and almost fully invalidate,
but the point is that the blocks of that file can only be discarded along with the whole segment now, which violates the meaning
of small discard. Look at the case I said in last mail, if the segment which owns the deleted file has no more changing after the file
deleting, and its validate blocks are perhaps over 95%, and it may not be easy to be selected as a gc victim. In this case, FTL can
not know the "file delete" on time, and the invalidate blocks of that file can not be discarded in FTL layer on time.

On 2017/1/4 9:55, Jaegeuk Kim wrote:
> Hi Yunlong,
>
> On 01/03, Yunlong Song wrote:
>> In the small discard case, when se->valid_blocks is zero, the add_discard_addrs
>> will directly return without __add_discard_entry. This will cause the file
>> delete have no small discard. The case is like this:
>>
>> 1. Allocate free 2M segment
>> 2. Write a file (size n blocks < 512) in that 2M segment, se->valid_blocks = n
>> 3. Delete that file, se->valid_blocks = 0, add_discard_addrs will return without
>> sending any discard of that file, and forever due to cur_map[i] ^ ckpt_map[i] =
>> 0 after that checkpoint
> During this checkpoint, that'll be discarded as a prefree segment, no?
> Note that, if this is a current segment, f2fs won't discard it until it is
> fully allocated.
>
> Thanks,
>
>> Signed-off-by: Yunlong Song <yunlong.song@huawei.com>
>> ---
>>  fs/f2fs/segment.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
>> index 0738f48..8610f14 100644
>> --- a/fs/f2fs/segment.c
>> +++ b/fs/f2fs/segment.c
>> @@ -838,7 +838,7 @@ static void add_discard_addrs(struct f2fs_sb_info *sbi, struct cp_control *cpc)
>>  		return;
>>  
>>  	if (!force) {
>> -		if (!test_opt(sbi, DISCARD) || !se->valid_blocks ||
>> +		if (!test_opt(sbi, DISCARD) ||
>>  		    SM_I(sbi)->nr_discards >= SM_I(sbi)->max_discards)
>>  			return;
>>  	}
>> -- 
>> 1.8.5.2
> .
>


-- 
Thanks,
Yunlong Song

^ permalink raw reply

* Re: [PATCH] f2fs: fix small discards when se->valid_blocks is zero
From: Yunlong Song @ 2017-01-04  3:59 UTC (permalink / raw)
  To: Jaegeuk Kim
  Cc: cm224.lee, yuchao0, chao, sylinux, bintian.wang, linux-fsdevel,
	linux-f2fs-devel, linux-kernel
In-Reply-To: <20170104015510.GB16504@jaegeuk.local>

Hi Kim,
    Although the blocks of that file will finally be discarded when it is not current segment any more and almost fully invalidate,
but the point is that the blocks of that file can only be discarded along with the whole segment now, which violates the meaning
of small discard. Look at the case I said in last mail, if the segment which owns the deleted file has no more changing after the file
deleting, and its validate blocks are perhaps over 95%, and it may not be easy to be selected as a gc victim. In this case, FTL can
not know the "file delete" on time, and the invalidate blocks of that file can not be discarded in FTL layer on time.

On 2017/1/4 9:55, Jaegeuk Kim wrote:
> Hi Yunlong,
>
> On 01/03, Yunlong Song wrote:
>> In the small discard case, when se->valid_blocks is zero, the add_discard_addrs
>> will directly return without __add_discard_entry. This will cause the file
>> delete have no small discard. The case is like this:
>>
>> 1. Allocate free 2M segment
>> 2. Write a file (size n blocks < 512) in that 2M segment, se->valid_blocks = n
>> 3. Delete that file, se->valid_blocks = 0, add_discard_addrs will return without
>> sending any discard of that file, and forever due to cur_map[i] ^ ckpt_map[i] =
>> 0 after that checkpoint
> During this checkpoint, that'll be discarded as a prefree segment, no?
> Note that, if this is a current segment, f2fs won't discard it until it is
> fully allocated.
>
> Thanks,
>
>> Signed-off-by: Yunlong Song <yunlong.song@huawei.com>
>> ---
>>  fs/f2fs/segment.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
>> index 0738f48..8610f14 100644
>> --- a/fs/f2fs/segment.c
>> +++ b/fs/f2fs/segment.c
>> @@ -838,7 +838,7 @@ static void add_discard_addrs(struct f2fs_sb_info *sbi, struct cp_control *cpc)
>>  		return;
>>  
>>  	if (!force) {
>> -		if (!test_opt(sbi, DISCARD) || !se->valid_blocks ||
>> +		if (!test_opt(sbi, DISCARD) ||
>>  		    SM_I(sbi)->nr_discards >= SM_I(sbi)->max_discards)
>>  			return;
>>  	}
>> -- 
>> 1.8.5.2
> .
>


-- 
Thanks,
Yunlong Song



^ permalink raw reply

* Re: [PATCH] lib/librte_vhost: fix memory leak
From: Yuanhan Liu @ 2017-01-04  4:02 UTC (permalink / raw)
  To: Yong Wang; +Cc: dev
In-Reply-To: <1483502275-18482-1-git-send-email-wang.yong19@zte.com.cn>

On Tue, Jan 03, 2017 at 10:57:55PM -0500, Yong Wang wrote:
> In function vhost_new_device(), current code dose not free 'dev'
> in "i == MAX_VHOST_DEVICE" condition statements. It will lead to a
> memory leak.

Nice catch!

Here are few minor stuff you might need pay attention to for future
contribution:

- a fix patch needs a fixline, like following

  Fixes: 45ca9c6f7bc6 ("vhost: get rid of linked list for devices")

- the prefix for vhost lib is "vhost: ". And FYI, for PMD drivers, it's
  'net/PMD_NAME', say 'net/virtio'.


For you convenience, I have fixed the two while applying. And thanks
for the fix.

Applied to dpdk-next-virtio.

	--yliu

^ permalink raw reply

* Re: [PATCH] ASoC: intel: rt5640: add support for sound card found on HP Pavilion x2 10-p000
From: Vinod Koul @ 2017-01-04  4:02 UTC (permalink / raw)
  To: Alexandrov Stanislav; +Cc: Alsa Devel, Pierre-Louis Bossart
In-Reply-To: <505f46a71aa53080da43f9c8abeb3b5d@nya.ai>

On Tue, Jan 03, 2017 at 11:40:04PM +0300, Alexandrov Stanislav wrote:
> Add support for rt5640 sound card found on HP Pavilion x2 10-p000
> tablet.
> 
> Inside DSDT table there is record for this soundcard:
> 
>             Device (RTKC)
>             {
>                 Name (_ADR, Zero)  // _ADR: Address
>                 Name (_HID, "10EC3276")  // _HID: Hardware ID
>                 Name (_CID, "10EC3276")  // _CID: Compatible ID
>                 Name (_DDN, "ALC3276")  // _DDN: DOS Device Name
>                 Name (_SUB, "103C827C")  // _SUB: Subsystem ID
>                 Name (_PR0, Package (0x01)  // _PR0: Power Resources
> for D0
> 
> original bugreport: https://bugzilla.kernel.org/show_bug.cgi?id=187621

Hi,

Thanks for the patch, changes look okay, but they need to be split per
driver and you need to sign-off these changes.
See Documentation/process/submitting-patches.rst esp Section 11.

> 
> ---
> 
> diff --git a/sound/soc/codecs/rt5640.c b/sound/soc/codecs/rt5640.c
> index e29a6de..c5234b9 100644
> --- a/sound/soc/codecs/rt5640.c
> +++ b/sound/soc/codecs/rt5640.c
> @@ -2315,6 +2315,7 @@ static const struct acpi_device_id
> rt5640_acpi_match[] = {
>         { "INT33CA", 0 },
>         { "10EC5640", 0 },
>         { "10EC5642", 0 },
> +       { "10EC3276", 0 },
>         { "INTCCFFD", 0 },
>         { },
>  };
> diff --git a/sound/soc/intel/atom/sst/sst_acpi.c
> b/sound/soc/intel/atom/sst/sst_acpi.c
> index f4d92bb..896ced2 100644
> --- a/sound/soc/intel/atom/sst/sst_acpi.c
> +++ b/sound/soc/intel/atom/sst/sst_acpi.c
> @@ -463,6 +463,8 @@ static struct sst_acpi_mach sst_acpi_chv[] = {
>         /* some CHT-T platforms rely on RT5640, use Baytrail machine
> driver */
>         {"10EC5640", "bytcr_rt5640", "intel/fw_sst_22a8.bin",
> "bytcr_rt5640", cht_quirk,
>                                                 &chv_platform_data },
> +       {"10EC3276", "bytcr_rt5640", "intel/fw_sst_22a8.bin",
> "bytcr_rt5640", NULL,
> +                                               &chv_platform_data },
> 
>         {},
>  };

-- 
~Vinod

^ permalink raw reply

* [U-Boot] [PATCH RESEND v2 1/2] spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible
From: Vignesh R @ 2017-01-04  4:02 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <CAD6G_RQaOJzkskQnd-AXhYZV34iSpHRejOTZ4QwpN28dVDA=rA@mail.gmail.com>



On Tuesday 03 January 2017 07:40 PM, Jagan Teki wrote:
> On Tue, Jan 3, 2017 at 2:35 PM, R, Vignesh <vigneshr@ti.com> wrote:
>>
>>
>> On 12/21/2016 10:42 AM, Vignesh R wrote:
>>> According to Section 11.15.4.9.2 Indirect Write Controller of K2G SoC
>>> TRM SPRUHY8D[1], the external master is only permitted to issue 32-bit
>>> data interface writes until the last word of an indirect transfer
>>> otherwise indirect writes is known to fails sometimes. So, make sure
>>> that QSPI indirect writes are 32 bit sized except for the last write. If
>>> the txbuf is unaligned then use bounce buffer to avoid data aborts.
>>>
>>> So, now that the driver uses bounce_buffer, enable CONFIG_BOUNCE_BUFFER
>>> for all boards that use Cadence QSPI driver.
>>>
>>> [1]www.ti.com/lit/ug/spruhy8d/spruhy8d.pdf
>>>
>>> Signed-off-by: Vignesh R <vigneshr@ti.com>
>>> Reviewed-by: Marek Vasut <marex@denx.de>
>>
>> Gentle ping on the series...
> 
> Please link to other one, I couldn't find it on patchwork.
> 

Here are the two patches of the series:
https://patchwork.ozlabs.org/patch/707648/
https://patchwork.ozlabs.org/patch/707647/

-- 
Regards
Vignesh

^ permalink raw reply

* Re: [PATCH 2/2] md/r5cache: enable chunk_aligned_read with write back cache
From: NeilBrown @ 2017-01-04  4:02 UTC (permalink / raw)
  To: linux-raid
  Cc: shli, kernel-team, dan.j.williams, hch, liuzhengyuan, liuyun01,
	Song Liu, Jes.Sorensen
In-Reply-To: <20161229011802.692478-2-songliubraving@fb.com>

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

On Thu, Dec 29 2016, Song Liu wrote:

> Chunk aligned read significantly reduces CPU usage of raid456.
> However, it is not safe to fully bypass the write back cache.
> This patch enables chunk aligned read with write back cache.
>
> For chunk aligned read, we track stripes in write back cache at
> a bigger granularity, "big_stripe". Each chunk may contain more
> than one stripe (for example, a 256kB chunk contains 64 4kB-page,
> so this chunk contain 64 stripes). For chunk_aligned_read, these
> stripes are grouped into one big_stripe, so we only need one lookup
> for the whole chunk.
>
> For each big_stripe, struct big_stripe_info tracks how many stripes of
> this big_stripe are in the write back cache. These data are tracked
> in a radix tree (big_stripe_tree). big_stripe_index() is used to
> calculate keys for the radix tree.
>
> chunk_aligned_read() calls r5c_big_stripe_cached() to look up
> big_stripe of each chunk in the tree. If this big_stripe is in the
> tree, chunk_aligned_read() aborts. This look up is protected by
> rcu_read_lock().
>
> It is necessary to remember whether a stripe is counted in
> big_stripe_tree. Instead of adding new flag, we reuses existing flags:
> STRIPE_R5C_PARTIAL_STRIPE and STRIPE_R5C_FULL_STRIPE. If either of these
> two flags are set, the stripe is counted in big_stripe_tree. This
> requires moving set_bit(STRIPE_R5C_PARTIAL_STRIPE) to
> r5c_try_caching_write().
>
> Signed-off-by: Song Liu <songliubraving@fb.com>
> ---
>  drivers/md/raid5-cache.c | 146 ++++++++++++++++++++++++++++++++++++++++++++---
>  drivers/md/raid5.c       |  19 +++---
>  drivers/md/raid5.h       |   1 +
>  3 files changed, 152 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
> index 817b294..268dcd2 100644
> --- a/drivers/md/raid5-cache.c
> +++ b/drivers/md/raid5-cache.c
> @@ -162,9 +162,60 @@ struct r5l_log {
>  
>  	/* to submit async io_units, to fulfill ordering of flush */
>  	struct work_struct deferred_io_work;
> +
> +	/* to for chunk_aligned_read in writeback mode, details below */
> +	spinlock_t tree_lock;
> +	struct radix_tree_root big_stripe_tree;
> +	struct kmem_cache *bsi_kc;	/* kmem_cache for big_stripe_info */

Why use a kmem_cache.  The structure you are allocating is an atomic_t,
which is 4 or 8 bytes, so kmalloc can allocate it efficiently.  You only
need a kmem_cache for objects that are not a nice even size.

> +	mempool_t *big_stripe_info_pool;

And why a mempool? Mempool are used when the allocation mustn't fail and
you can wait for some other users of the memory to free it.  That is not
at all the case here.

As you are using a radix tree, it would probably make sense to not store
a pointer, but to store an integer directly.  Use radix_tree_replace to
update.


>  };
>  
>  /*
> + * Enable chunk_aligned_read() with write back cache.
> + *
> + * Each chunk may contain more than one stripe (for example, a 256kB
> + * chunk contains 64 4kB-page, so this chunk contain 64 stripes). For
> + * chunk_aligned_read, these stripes are grouped into one "big_stripe".
> + * For each big_stripe, struct big_stripe_info tracks how many stripes of
> + * this big_stripe are in the write back cache. These data are tracked
> + * in a radix tree (big_stripe_tree). big_stripe_index() is used to
> + * calculate keys for the radix tree.
> + *
> + * chunk_aligned_read() calls r5c_big_stripe_cached() to look up
> + * big_stripe of each chunk in the tree. If this big_stripe is in the
> + * tree, chunk_aligned_read() aborts. This look up is protected by
> + * rcu_read_lock().
> + *
> + * It is necessary to remember whether a stripe is counted in
> + * big_stripe_tree. Instead of adding new flag, we reuses existing flags:
> + * STRIPE_R5C_PARTIAL_STRIPE and STRIPE_R5C_FULL_STRIPE. If either of these
> + * two flags are set, the stripe is counted in big_stripe_tree. This
> + * requires moving set_bit(STRIPE_R5C_PARTIAL_STRIPE) to
> + * r5c_try_caching_write().
> + */
> +struct big_stripe_info {
> +	atomic_t count;
> +#ifdef CONFIG_DEBUG_VM
> +	void *pad;  /* suppress size check error in kmem_cache_sanity_check */

There is a probably a reason for this error .....

> +#endif
> +};
> +
> +/*
> + * calculate key for big_stripe_tree
> + *
> + * sect: align_bi->bi_iter.bi_sector or sh->sector
> + */
> +static inline sector_t big_stripe_index(struct r5conf *conf,
> +					sector_t sect)
> +{
> +	sector_t offset;
> +
> +	offset = sector_div(sect, conf->chunk_sectors *
> +			    (conf->raid_disks - conf->max_degraded));

This code implies that 'sect' is a sector address in the array.
However you call this function as 
> +		bs_index = big_stripe_index(conf, sh->sector);

and sh->sector is a sector address in each underlying device.
So something is definitely wrong.


> +	return sect;
> +}
> +
> +/*
>   * an IO range starts from a meta data block and end at the next meta data
>   * block. The io unit's the meta data block tracks data/parity followed it. io
>   * unit is written to log disk with normal write, as we always flush log disk
> @@ -2293,6 +2344,8 @@ int r5c_try_caching_write(struct r5conf *conf,
>  	int i;
>  	struct r5dev *dev;
>  	int to_cache = 0;
> +	struct big_stripe_info *bsinfo;
> +	sector_t bs_index;
>  
>  	BUG_ON(!r5c_is_writeback(log));
>  
> @@ -2327,6 +2380,37 @@ int r5c_try_caching_write(struct r5conf *conf,
>  		}
>  	}
>  
> +	/* if the stripe is not counted in big_stripe_tree, add it now */
> +	if (!test_bit(STRIPE_R5C_PARTIAL_STRIPE, &sh->state) &&
> +	    !test_bit(STRIPE_R5C_FULL_STRIPE, &sh->state)) {
> +		bs_index = big_stripe_index(conf, sh->sector);
> +		spin_lock(&log->tree_lock);
> +		bsinfo = radix_tree_lookup(&log->big_stripe_tree, bs_index);
> +		if (bsinfo)
> +			atomic_inc(&bsinfo->count);
> +		else {
> +			bsinfo = mempool_alloc(log->big_stripe_info_pool, GFP_ATOMIC);
> +			if (bsinfo) {
> +				atomic_set(&bsinfo->count, 1);
> +				radix_tree_insert(&log->big_stripe_tree, bs_index, bsinfo);

You've declared this radix_tree as
> +	INIT_RADIX_TREE(&log->big_stripe_tree, GFP_ATOMIC);

so it can be using in spinlock context, but that is only reliable if you
first call radix_tree_preload() before taking the lock.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply

* adding 32 bit compatibility layer in custom kernel module
From: Pradeepa Kumar @ 2017-01-04  4:04 UTC (permalink / raw)
  To: kernelnewbies

Hi experts

down votefavorite
<http://stackoverflow.com/questions/41455943/adding-32-bit-compatibility-layer-in-custom-kernel-module#>

in my 64 bit kernel, I have a custom kernel module providing new protocol
and providing socket system calls.

it works fine when 64 bit app runs.

i am seeing issues when 32 bit app runs (for exp recvmsg() call does not
work if msg has cmsghdrs as struct size of cmsghdr is different in 32 bit
and 64 bit).

This is because my custom kernel module does not have 32 bit compatibility
layer ( but linux kernel has this in compat.c etc).

   -

   is it simple to add compatibility layer to my custom kernel module
   -

   how do i do this (any links ?)

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170104/6f56f08e/attachment-0001.html 

^ permalink raw reply

* Re: [Qemu-devel] [PATCH for-2.9 v3 0/5] Sheepdog cleanups
From: Jeff Cody @ 2017-01-04  4:07 UTC (permalink / raw)
  To: Paolo Bonzini; +Cc: qemu-devel, Hitoshi Mitake, Liu Yuan, qemu-block
In-Reply-To: <3f948687-3169-c304-3ef8-31347f08857f@redhat.com>

On Wed, Dec 21, 2016 at 03:07:07PM +0100, Paolo Bonzini wrote:
> 
> 
> On 29/11/2016 12:32, Paolo Bonzini wrote:
> > Cleaning up the code and removing duplication makes it simpler to
> > later adapt it for the multiqueue work.
> > 
> > Tested against sheepdog 1.0.  I also tested taking snapshots and reverting
> > to older snapshots, but the latter only worked with "dog vdi rollback".
> > Neither loadvm nor qemu-img worked for me.
> > 
> > Paolo
> > 
> >         v1->v2: placate patchew
> >         v2->v3: rebase
> > 
> > Paolo Bonzini (5):
> >   sheepdog: remove unused cancellation support
> >   sheepdog: reorganize coroutine flow
> >   sheepdog: do not use BlockAIOCB
> >   sheepdog: simplify inflight_aio_head management
> >   sheepdog: reorganize check for overlapping requests
> > 
> >  block/sheepdog.c | 289 ++++++++++++++++---------------------------------------
> >  1 file changed, 83 insertions(+), 206 deletions(-)
> > 
> 
> 2.8 is now out, so ping.
>

I don't have a functional sheepdog setup at the moment; have you tested
these patches, or should I set up a test rig for them? (I am guessing I
should do the latter; either way, I'll pull the patches in once I or someone
else has tested them).

^ permalink raw reply

* Re: [Qemu-devel] [PATCH 0/4] QOM'ify work for ppc
From: David Gibson @ 2017-01-04  3:28 UTC (permalink / raw)
  To: 赵小强; +Cc: peter.maydell, qemu-ppc, qemu-devel, agraf
In-Reply-To: <A1654386-0C53-4C64-BE97-A6804E1AA4F3@163.com>

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

On Tue, Jan 03, 2017 at 10:02:21PM +0800, 赵小强 wrote:
> Hi,david:
> 
>    To my understanding,what must be put in the realize function  is
>    code which depends on property values. What's the benefit of
>    moving memory region initialization into realize function?  I can
>    not figure out, can you make some explanations?

If nothing else it's better in realize() for consistency with other
devices.

I'm not familiar enough with the details to be sure, but I also think
it's not safe in instance_init.  Once memory regions are registered,
the device can potentially interact with other devices in the virtual
machine.  realize() is sequenced to expect that, instance_init is not.

>     Thanks for your review.
> 
> Best wishes !
> 
> > 在 2017年1月3日,06:28,David Gibson <david@gibson.dropbear.id.au> 写道:
> > 
> >> On Sat, Dec 31, 2016 at 09:18:27AM +0800, xiaoqiang zhao wrote:
> >> This is some QOM'ify work relate with ppc.
> >> See each commit message for details.
> >> 
> >> xiaoqiang zhao (4):
> >>  hw/gpio: QOM'ify mpc8xxx.c
> >>  hw/ppc: QOM'ify e500.c
> >>  hw/ppc: QOM'ify ppce500_spin.c
> >>  hw/ppc: QOM'ify spapr_vio.c
> >> 
> >> hw/gpio/mpc8xxx.c     | 20 +++++++++++---------
> >> hw/ppc/e500.c         | 17 ++++-------------
> >> hw/ppc/ppce500_spin.c | 18 ++++++++----------
> >> hw/ppc/spapr_vio.c    |  2 --
> >> 4 files changed, 23 insertions(+), 34 deletions(-)
> > 
> > Patches 1-3 all have the same problem - they move memory region
> > initialization and similar to an instance_init function.  This is not
> > how things are generally done in the qdev model.  Instead that phase
> > of initialization should be done from a dc->realize() function.
> > 
> 
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply

* [radeon-alex:amd-staging-drm-next 149/158] drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1740:2: warning: ISO C90 forbids mixed declarations and code
From: kbuild test robot @ 2017-01-04  4:12 UTC (permalink / raw)
  To: Andrew Wong; +Cc: Alex Deucher, kbuild-all, dri-devel

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

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   5d8e75c019bf76889bd606a67afabf7d0b32d3fa
commit: 23ffa1200a5abc5b724fe87bb4a7291fce85bba2 [149/158] drm/amd/display: DAL3: HDR10 Infoframe encoding
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        git checkout 23ffa1200a5abc5b724fe87bb4a7291fce85bba2
        # save the attached .config to linux build tree
        make.cross ARCH=alpha 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c: In function 'set_hdr_static_info_packet':
>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1740:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
     struct dc_hdr_static_metadata hdr_metadata =
     ^~~~~~
   drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1760:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
     uint32_t data;
     ^~~~~~~~
   drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c: In function 'set_avi_info_frame':
>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1495:38: warning: iteration 28 invokes undefined behavior [-Waggressive-loop-optimizations]
      info_packet->sb[byte_index] = info_frame.avi_info_packet.
                                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~
      info_packet_hdmi.packet_raw_data.sb[byte_index];
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~
   drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1493:2: note: within this loop
     for (byte_index = 0; byte_index < sizeof(info_packet->sb); byte_index++)
     ^~~
   drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c: In function 'set_hdr_static_info_packet.isra.7':
>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1734:11: warning: 'i' may be used uninitialized in this function [-Wmaybe-uninitialized]
     uint16_t i;
              ^

vim +1740 drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c

  1728	
  1729	static void set_hdr_static_info_packet(
  1730			struct core_surface *surface,
  1731			struct core_stream *stream,
  1732			struct hw_info_packet *info_packet)
  1733	{
> 1734		uint16_t i;
  1735		enum signal_type signal = stream->signal;
  1736	
  1737		if (!surface)
  1738			return;
  1739	
> 1740		struct dc_hdr_static_metadata hdr_metadata =
  1741				surface->public.hdr_static_ctx;
  1742	
  1743		if (dc_is_hdmi_signal(signal)) {

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 47963 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* Re: mount_pseudo(), sget() and MS_KERNMOUNT
From: Eric W. Biederman @ 2017-01-04  4:20 UTC (permalink / raw)
  To: Luis Ressel; +Cc: Alexander Viro, linux-fsdevel, linux-kernel
In-Reply-To: <20161227112037.015dc5ac@gentp.lnet>

Luis Ressel <aranea@aixah.de> writes:

> Hello,
>
> With Linux 4.8, the sget() function in fs/super.c got a new permission
> check: It now returns -EPERM if
> (!(flags & MS_KERNMOUNT) && !ns_capable(user_ns, CAP_SYS_ADMIN)) .
>
> I presume the first half is intented to detect in-kernel mounts? If so,
> why doesn't mount_pseudo() (in fs/libfs.c) pass the MS_KERNMOUNT flag
> to sget()?

It looks like an oversight that has simply not mattered.

> This behaviour has caused a problem for me: During graphics driver
> initalization, drm_fs_inode_new() (in drivers/gpu/drm/drm_drv.c) calls
> simple_pin_fs(). The MS_KERNMOUNT flag is indeed passed down the
> call chain from there, but it is lost when mount_pseudo() is called, as
> that function doesn't take a 'flags' argument.
>
> Hence, the first part of the above permission check fails. (The second
> part also fails under some cicumstances due to a SELinux quirk, and
> therefore the initalization of my graphics driver doesn't succeed.)

I am concerned that perhaps there is some wrong context in here that is
causing SELinux to have problems.

Does this correct your symptoms?

Eric

diff --git a/fs/libfs.c b/fs/libfs.c
index e973cd51f126..28d6f35feed6 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -245,7 +245,8 @@ struct dentry *mount_pseudo_xattr(struct file_system_type *fs_type, char *name,
 	struct inode *root;
 	struct qstr d_name = QSTR_INIT(name, strlen(name));
 
-	s = sget(fs_type, NULL, set_anon_super, MS_NOUSER, NULL);
+	s = sget_userns(fs_type, NULL, set_anon_super, MS_KERNMOUNT|MS_NOUSER,
+			&init_user_ns, NULL);
 	if (IS_ERR(s))
 		return ERR_CAST(s);
 




^ permalink raw reply related

* [PATCH perf/core 2/3] perf-probe: Fix to probe on gcc generated symbols for offline kernel
From: Masami Hiramatsu @ 2017-01-04  3:30 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo
  Cc: Masami Hiramatsu, linux-kernel, Jiri Olsa, Peter Zijlstra,
	Ingo Molnar, Namhyung Kim
In-Reply-To: <148350046263.19001.16486219029429895749.stgit@devbox>

Fix perf-probe to show probe definition on gcc generated symbols
for offline kernel (including cross-arch kernel image).

Gcc sometimes optimizes functions and generate new symbols with
suffixes such as ".constprop.N" or ".isra.N" etc. Since those
symbol names are not recorded in DWARF, we have to find correct
generated symbols from offline ELF binary to probe on it (kallsyms
doesn't correct it).
For online kernel or uprobes we don't need it because those are
rebased on _text, or a section relative address.

E.g. Without this;
  -----
  $ perf probe -k build-arm/vmlinux -F __slab_alloc*
  __slab_alloc.constprop.9
  $ perf probe -k build-arm/vmlinux -D __slab_alloc
  p:probe/__slab_alloc __slab_alloc+0
  -----
If you put above definition on target machine, it should fail
because there is no __slab_alloc in kallsyms.

With this fix, perf probe shows correct probe definition on
__slab_alloc.constprop.9.
  -----
  $ perf probe -k build-arm/vmlinux -D __slab_alloc
  p:probe/__slab_alloc __slab_alloc.constprop.9+0
  -----

Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
---
 tools/perf/util/probe-event.c |   48 ++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 47 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 542e647..4a57c8a 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -610,6 +610,51 @@ static int find_perf_probe_point_from_dwarf(struct probe_trace_point *tp,
 	return ret ? : -ENOENT;
 }
 
+/*
+ * Rename DWARF symbols to ELF symbols -- gcc sometimes optimizes functions
+ * and generate new symbols with suffixes such as .constprop.N or .isra.N
+ * etc. Since those symbols are not recorded in DWARF, we have to find
+ * correct generated symbols from offline ELF binary.
+ * For online kernel or uprobes we don't need this because those are
+ * rebased on _text, or already a section relative address.
+ */
+static int
+post_process_offline_probe_trace_events(struct probe_trace_event *tevs,
+					int ntevs, const char *pathname)
+{
+	struct symbol *sym;
+	struct map *map;
+	unsigned long stext = 0;
+	u64 addr;
+	int i;
+
+	/* Prepare a map for offline binary */
+	map = dso__new_map(pathname);
+	if (!map || get_text_start_address(pathname, &stext) < 0) {
+		pr_warning("Failed to get ELF symbols for %s\n", pathname);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < ntevs; i++) {
+		addr = tevs[i].point.address + tevs[i].point.offset - stext;
+		sym = map__find_symbol(map, addr);
+		if (!sym)
+			continue;
+		if (!strcmp(sym->name, tevs[i].point.symbol))
+			continue;
+		/* If we have no realname, use symbol for it */
+		if (!tevs[i].point.realname)
+			tevs[i].point.realname = tevs[i].point.symbol;
+		else
+			free(tevs[i].point.symbol);
+		tevs[i].point.symbol = strdup(sym->name);
+		tevs[i].point.offset = addr - sym->start;
+	}
+	map__put(map);
+
+	return 0;
+}
+
 static int add_exec_to_probe_trace_events(struct probe_trace_event *tevs,
 					  int ntevs, const char *exec)
 {
@@ -671,7 +716,8 @@ post_process_kernel_probe_trace_events(struct probe_trace_event *tevs,
 
 	/* Skip post process if the target is an offline kernel */
 	if (symbol_conf.ignore_vmlinux_buildid)
-		return 0;
+		return post_process_offline_probe_trace_events(tevs, ntevs,
+						symbol_conf.vmlinux_name);
 
 	reloc_sym = kernel_get_ref_reloc_sym();
 	if (!reloc_sym) {

^ permalink raw reply related

* cron job: media_tree daily build: ERRORS
From: Hans Verkuil @ 2017-01-04  4:25 UTC (permalink / raw)
  To: linux-media

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:			Wed Jan  4 05:00:10 CET 2017
media-tree git hash:	40eca140c404505c09773d1c6685d818cb55ab1a
media_build git hash:	1606032398b1d79149c1507be2029e1a00d8dff0
v4l-utils git hash:	951c4878a93f4722146f8bc6515a47fba6470bb3
gcc version:		i686-linux-gcc (GCC) 6.2.0
sparse version:		v0.5.0-3553-g78b2ea6
smatch version:		v0.5.0-3553-g78b2ea6
host hardware:		x86_64
host os:		4.8.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.1.33-i686: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.4.22-i686: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.7.5-i686: ERRORS
linux-4.8-i686: ERRORS
linux-4.9-i686: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.33-x86_64: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.22-x86_64: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.5-x86_64: ERRORS
linux-4.8-x86_64: ERRORS
linux-4.9-x86_64: ERRORS
apps: WARNINGS
spec-git: ERRORS
sparse: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html

^ permalink raw reply

* [Qemu-devel] [Bug 1639225] Re: qcow2 - filesize 8.1Petabyte
From: Launchpad Bug Tracker @ 2017-01-04  4:18 UTC (permalink / raw)
  To: qemu-devel
In-Reply-To: <20161104124922.14508.87645.malonedeb@chaenomeles.canonical.com>

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1639225

Title:
  qcow2 - filesize 8.1Petabyte

Status in QEMU:
  Expired

Bug description:
  
  problem :

  Filesystem                                     Size  Used Avail Use%
  Mounted on

  /dev/sdd1                                      120G   63G   57G  53%
  /storage/kvmstorage4ssd

  # pwd
  /storage/kvmstorage4ssd/images

  # qemu-img info vsys19_ssd1.qcow2 
  image: vsys19_ssd1.qcow2
  file format: qcow2
  virtual size: 20G (21474836480 bytes)
  disk size: 11G
  cluster_size: 65536
  Format specific information:
      compat: 1.1
      lazy refcounts: true
      refcount bits: 16
      corrupt: true
  # ls -lah vsys19_*
  -rw------- 1 root root 8.1P Nov  4 13:16 vsys19_ssd1.qcow2

  # ls -la vsys19_*
  -rw------- 1 root root 9007203702079488 Nov  4 13:16 vsys19_ssd1.qcow2

  # qemu-img check vsys19_ssd1.qcow2 
  qemu-img: Check failed: File too large

  # xfs_repair /dev/sdd1
  Phase 1 - find and verify superblock...
  Phase 2 - using internal log
          - zero log...
          - scan filesystem freespace and inode maps...
          - found root inode chunk
  Phase 3 - for each AG...
          - scan and clear agi unlinked lists...
          - process known inodes and perform inode discovery...
          - agno = 0
          - agno = 1
          - agno = 2
          - agno = 3
          - process newly discovered inodes...
  Phase 4 - check for duplicate blocks...
          - setting up duplicate extent list...
          - check for inodes claiming duplicate blocks...
          - agno = 0
          - agno = 1
          - agno = 2
          - agno = 3
  Phase 5 - rebuild AG headers and trees...
          - reset superblock...
  Phase 6 - check inode connectivity...
          - resetting contents of realtime bitmap and summary inodes
          - traversing filesystem ...
          - traversal finished ...
          - moving disconnected inodes to lost+found ...
  Phase 7 - verify and correct link counts...
  done

  
  # pwd
  /storage/kvmstorage4ssd/images

      <disk type='file' device='disk'>
        <driver name='qemu' type='qcow2'/>
        <source file='/storage/kvmstorage4ssd/images/vsys19_ssd1.qcow2'/>
        <target dev='vdn' bus='virtio'/>
        <address type='pci' domain='0x0000' bus='0x00' slot='0x0f' function='0x0'/>
      </disk>

  
  guest OS:

  
  # uname -a
  Linux vsys19 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux
  cat /etc/debian_version 
  stretch/sid

  Nov  4 01:23:26 vsys19 kernel: [7654313.024844] end_request: I/O error, dev vdk, sector 8691272
  Nov  4 01:23:26 vsys19 kernel: [7654313.025328] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 s
  tarting block 1085897)
  Nov  4 01:23:26 vsys19 kernel: [7654313.025334] Buffer I/O error on device dm-1, logical block 1085897
  Nov  4 01:23:26 vsys19 kernel: [7654313.025488] Buffer I/O error on device dm-1, logical block 1085898
  Nov  4 01:23:26 vsys19 kernel: [7654313.025632] Buffer I/O error on device dm-1, logical block 1085899
  Nov  4 01:23:26 vsys19 kernel: [7654313.025776] Buffer I/O error on device dm-1, logical block 1085900
  Nov  4 01:23:26 vsys19 kernel: [7654313.025920] Buffer I/O error on device dm-1, logical block 1085901
  Nov  4 01:23:26 vsys19 kernel: [7654313.026064] Buffer I/O error on device dm-1, logical block 1085902
  Nov  4 01:23:26 vsys19 kernel: [7654313.026207] Buffer I/O error on device dm-1, logical block 1085903
  Nov  4 01:23:26 vsys19 kernel: [7654313.026350] Buffer I/O error on device dm-1, logical block 1085904
  Nov  4 01:23:26 vsys19 kernel: [7654313.026500] Buffer I/O error on device dm-1, logical block 1085905
  Nov  4 01:23:26 vsys19 kernel: [7654313.028837] Buffer I/O error on device dm-1, logical block 1085906
  Nov  4 01:23:26 vsys19 kernel: [7654313.031122] end_request: I/O error, dev vdk, sector 8692280
  Nov  4 01:23:26 vsys19 kernel: [7654313.031325] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086023)
  Nov  4 01:23:26 vsys19 kernel: [7654313.031388] end_request: I/O error, dev vdk, sector 8693288
  Nov  4 01:23:26 vsys19 kernel: [7654313.031527] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086149)
  Nov  4 01:23:26 vsys19 kernel: [7654313.031598] end_request: I/O error, dev vdk, sector 8694296
  Nov  4 01:23:26 vsys19 kernel: [7654313.031736] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086275)
  Nov  4 01:23:26 vsys19 kernel: [7654313.031798] end_request: I/O error, dev vdk, sector 8695304
  Nov  4 01:23:26 vsys19 kernel: [7654313.031933] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086401)

  KVM host :
  # cat /etc/debian_version 
  stretch/sid

  Debian

  
  # uname -a
  Linux asus1 4.5.5-custom #1 SMP Sun May 22 21:14:57 CEST 2016 x86_64 GNU/Linux

  # dpkg -l | grep -i qemu
  ii  ipxe-qemu                             1.0.0+git-20150424.a25a16d-1    all          PXE boot firmware - ROM images for qemu
  ii  qemu                                  1:2.5+dfsg-5+b1                 amd64        fast processor emulator
  ii  qemu-kvm                              1:2.5+dfsg-5+b1                 amd64        QEMU Full virtualization on x86 hardware
  ii  qemu-slof                             20151103+dfsg-2                 all          Slimline Open Firmware -- QEMU PowerPC version
  ii  qemu-system                           1:2.5+dfsg-5+b1                 amd64        QEMU full system emulation binaries
  ii  qemu-system-arm                       1:2.5+dfsg-5+b1                 amd64        QEMU full system emulation binaries (arm)
  ii  qemu-system-common                    1:2.5+dfsg-5+b1                 amd64        QEMU full system emulation binaries (common files)
  ii  qemu-system-mips                      1:2.5+dfsg-5+b1                 amd64        QEMU full system emulation binaries (mips)
  ii  qemu-system-misc                      1:2.5+dfsg-5+b1                 amd64        QEMU full system emulation binaries (miscelaneous)
  ii  qemu-system-ppc                       1:2.5+dfsg-5+b1                 amd64        QEMU full system emulation binaries (ppc)
  ii  qemu-system-sparc                     1:2.5+dfsg-5+b1                 amd64        QEMU full system emulation binaries (sparc)
  ii  qemu-system-x86                       1:2.5+dfsg-5+b1                 amd64        QEMU full system emulation binaries (x86)
  ii  qemu-user                             1:2.5+dfsg-5+b1                 amd64        QEMU user mode emulation binaries
  ii  qemu-user-binfmt                      1:2.5+dfsg-5+b1                 amd64        QEMU user mode binfmt registration for qemu-user
  ii  qemu-utils                            1:2.5+dfsg-5+b1                 amd64        QEMU utilities
  ii  qemubuilder                           0.80                            amd64        pbuilder using QEMU as backend

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1639225/+subscriptions

^ permalink raw reply

* [xen-unstable test] 104015: tolerable FAIL - PUSHED
From: osstest service owner @ 2017-01-04  4:26 UTC (permalink / raw)
  To: xen-devel, osstest-admin

flight 104015 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104015/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check    fail  like 104004
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop             fail like 104004
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop             fail like 104004
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop            fail like 104004
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop            fail like 104004
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check    fail  like 104004
 test-armhf-armhf-libvirt     13 saverestore-support-check    fail  like 104004
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 104004
 test-amd64-amd64-xl-rtds      9 debian-install               fail  like 104004

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start                  fail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      12 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     12 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-check        fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm      12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-xsm      13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl          12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-check        fail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-check    fail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-check        fail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-check    fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-check    fail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-check        fail never pass
 test-armhf-armhf-xl-rtds     12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-rtds     13 saverestore-support-check    fail   never pass
 test-armhf-armhf-xl-vhd      11 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-vhd      12 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  e34bc403c3c7dc0075111fa9cd29e2a385bc66ed
baseline version:
 xen                  ee524f2bfa681ad116b8ae925fa8f3f18ee12ba5

Last test of basis   104004  2017-01-03 01:59:38 Z    1 days
Failing since        104008  2017-01-03 11:13:37 Z    0 days    2 attempts
Testing same since   104015  2017-01-03 19:45:46 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  George Dunlap <george.dunlap@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Kevin Tian <kevin.tian@intel.com>
  Wei Liu <wei.liu2@citrix.com>

jobs:
 build-amd64-xsm                                              pass    
 build-armhf-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64-xtf                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-prev                                             pass    
 build-i386-prev                                              pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumprun                                          pass    
 build-i386-rumprun                                           pass    
 test-xtf-amd64-amd64-1                                       pass    
 test-xtf-amd64-amd64-2                                       pass    
 test-xtf-amd64-amd64-3                                       pass    
 test-xtf-amd64-amd64-4                                       pass    
 test-xtf-amd64-amd64-5                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm                pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm                 pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm                pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm                 pass    
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm        pass    
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm         pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-armhf-armhf-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-xl-xsm                                      pass    
 test-armhf-armhf-xl-xsm                                      pass    
 test-amd64-i386-xl-xsm                                       pass    
 test-amd64-amd64-qemuu-nested-amd                            fail    
 test-amd64-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    
 test-amd64-amd64-rumprun-amd64                               pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumprun-i386                                 pass    
 test-amd64-amd64-qemuu-nested-intel                          pass    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-migrupgrade                                 pass    
 test-amd64-i386-migrupgrade                                  pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-amd64-amd64-amd64-pvgrub                                pass    
 test-amd64-amd64-i386-pvgrub                                 pass    
 test-amd64-amd64-pygrub                                      pass    
 test-armhf-armhf-libvirt-qcow2                               pass    
 test-amd64-amd64-xl-qcow2                                    pass    
 test-armhf-armhf-libvirt-raw                                 pass    
 test-amd64-i386-xl-raw                                       pass    
 test-amd64-amd64-xl-rtds                                     fail    
 test-armhf-armhf-xl-rtds                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     pass    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     pass    
 test-amd64-amd64-libvirt-vhd                                 pass    
 test-armhf-armhf-xl-vhd                                      pass    
 test-amd64-amd64-xl-qemut-winxpsp3                           pass    
 test-amd64-i386-xl-qemut-winxpsp3                            pass    
 test-amd64-amd64-xl-qemuu-winxpsp3                           pass    
 test-amd64-i386-xl-qemuu-winxpsp3                            pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=e34bc403c3c7dc0075111fa9cd29e2a385bc66ed
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
++++ getconfig Repos
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable e34bc403c3c7dc0075111fa9cd29e2a385bc66ed
+ branch=xen-unstable
+ revision=e34bc403c3c7dc0075111fa9cd29e2a385bc66ed
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
++++ getconfig Repos
++++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"Repos"} or die $!;
        '
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' xe34bc403c3c7dc0075111fa9cd29e2a385bc66ed = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osstest@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
                use Osstest;
                readglobalconfig();
                print $c{"OsstestUpstream"} or die $!;
        '
++ :
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osstest@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/qemu-xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
++ : daily-cron.xen-unstable
++ : git://xenbits.xen.org/qemu-xen.git
++ : git://git.qemu.org/qemu.git
+ TREE_LINUX=osstest@xenbits.xen.org:/home/xen/git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
+ TREE_XEN=osstest@xenbits.xen.org:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xen.org:/home/xen/git/libvirt.git
+ TREE_RUMPRUN=osstest@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
+ TREE_SEABIOS=osstest@xenbits.xen.org:/home/xen/git/osstest/seabios.git
+ TREE_OVMF=osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
+ TREE_XTF=osstest@xenbits.xen.org:/home/xen/git/xtf.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /home/osstest/repos/xen
+ git push osstest@xenbits.xen.org:/home/xen/git/xen.git e34bc403c3c7dc0075111fa9cd29e2a385bc66ed:refs/heads/master
To osstest@xenbits.xen.org:/home/xen/git/xen.git
   ee524f2..e34bc40  e34bc403c3c7dc0075111fa9cd29e2a385bc66ed -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply

* [Qemu-devel] [Bug 1102027] Re: QED Time travel
From: Launchpad Bug Tracker @ 2017-01-04  4:17 UTC (permalink / raw)
  To: qemu-devel
In-Reply-To: <20130120115433.12489.5115.malonedeb@soybean.canonical.com>

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1102027

Title:
  QED Time travel

Status in QEMU:
  Expired

Bug description:
  This night after a reboot of a VM, it was back to 8 Oct. 2012, i've
  lost all data between 8 Oct 2012 and now. I've check the QED file and
  mount on another VM, all seems OK.

  This QED has a raw backfile with the base OS (debian) shared with many
  others QED. It has NO snapshot.

  QEMU emulator version 1.1.2

  Does anyone have a hint ?

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1102027/+subscriptions

^ permalink raw reply

* [Qemu-devel] [Bug 1317603] Re: qemu-system-ppc does not terminate on VM exit
From: Launchpad Bug Tracker @ 2017-01-04  4:17 UTC (permalink / raw)
  To: qemu-devel
In-Reply-To: <20140508172525.21754.50051.malonedeb@chaenomeles.canonical.com>

[Expired for qemu (Ubuntu) because there has been no activity for 60
days.]

** Changed in: qemu (Ubuntu)
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1317603

Title:
  qemu-system-ppc does not terminate on VM exit

Status in QEMU:
  Won't Fix
Status in qemu package in Ubuntu:
  Expired

Bug description:
  When a VM is created for a p4080-e500mc  ; the VM can not be  rebooted
  or terminated.

  The qemu-system-ppc process must be killed.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: qemu-system-ppc 2.0.0~rc1+dfsg-0ubuntu3.1
  ProcVersionSignature: Ubuntu 3.13.0-24.46-powerpc-e500mc 3.13.9
  Uname: Linux 3.13.9+ ppc
  ApportVersion: 2.14.1-0ubuntu3
  Architecture: powerpc
  Date: Thu May  8 12:20:57 2014
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=<set>
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: qemu
  UpgradeStatus: Upgraded to trusty on 2014-04-29 (9 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1317603/+subscriptions

^ permalink raw reply

* [Qemu-devel] [Bug 612297] Re: qemu-kvm fails to detect mouse while Windows 95 setup
From: Launchpad Bug Tracker @ 2017-01-04  4:17 UTC (permalink / raw)
  To: qemu-devel
In-Reply-To: <20100801164711.20463.98993.malonedeb@soybean.canonical.com>

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/612297

Title:
  qemu-kvm fails to detect mouse while Windows 95 setup

Status in QEMU:
  Expired

Bug description:
  CPU: AMD Phenom II X4 945
  KVM-Version: qemu-kvm-0.12.4+dfsg (Debian package)
  Kernel: linux-2.6.26.8-rt16
  arch: x86_64
  Guest: Windows 95 B

  I'm trying to install Windows 95 B on qemu-kvm with this options:

  kvm /var/mmn/vm/Win95/Win95.img -name "Windows 95" -M pc-0.12 -m 512M
  -rtc base=localtime -k de -soundhw sb16 -vga cirrus -net
  user,hostname=w95vm -net nic,model=ne2k_pci -boot a -fda
  /var/mmn/vm/floppy/win95B_Drive-D-boot.img -cdrom
  /var/mmn/vm/CD/win95-setup.iso -no-acpi -no-kvm -usb

  I've also tried some other option, but always the same: no ps/2 mouse
  detection. And usb mouse is not supported by Windows 95 B while setup
  process. This is only possible later by installing the extension
  usbsupp.exe after the system setup.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/612297/+subscriptions

^ permalink raw reply

* [Qemu-devel] [Bug 590552] Re: New default network card doesn't work with tap networking
From: Launchpad Bug Tracker @ 2017-01-04  4:18 UTC (permalink / raw)
  To: qemu-devel
In-Reply-To: <20100606230821.4593.45646.malonedeb@soybean.canonical.com>

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/590552

Title:
  New default network card doesn't work with tap networking

Status in QEMU:
  Expired

Bug description:
  Unfortunately, I can provide very little information.

  Hope this will be useful anyway.

  I've upgraded qemu using debian apt to lastest unstable (QEMU PC
  emulator version 0.12.4 (Debian 0.12.4+dfsg-2), Copyright (c)
  2003-2008 Fabrice Bellard): looks like at some point the default
  network card for -net nic option was switched to intel gigabit instead
  of the good old ne2k_pci.

  I was using -net tap -net nic options and my network stopped working.
  When not working,
  - tcpdump on the host shows me taht all packets are sent and received fine from guest
  - tcpdump on guest shows that packets from host are NOT received

  obviously, both host tap interface and guest eth0 interfaces, routing
  tables, dns, firewall, etc... are well configured.

  Having banged my head for a while, I finally stopped the host and
  started it again using -net nic,model=ne2k_pci option, then my network
  magically started working again.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/590552/+subscriptions

^ permalink raw reply

* [Qemu-devel] [Bug 1119686] Re: Incorrect handling of icebp
From: Launchpad Bug Tracker @ 2017-01-04  4:17 UTC (permalink / raw)
  To: qemu-devel
In-Reply-To: <20130208193040.11551.94134.malonedeb@chaenomeles.canonical.com>

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1119686

Title:
  Incorrect handling of icebp

Status in QEMU:
  Expired

Bug description:
  Wine conformance suite tests the behavior of various low-level Windows
  API functions. One of the tests involves checking the interaction of
  breakpoints and exceptions, and in particular the 'icebp' breakpoint.
  This test works on a Windows XP machine running either on the metal or
  in VMware ESX but fails when run in QEmu.

  To reproduce the issue grab the attached 'exception.exe' file and run
  it. If you get 'Test failed' lines like below then it means the
  problem is still present:

      exception.c:202: exception 0: 80000004 flags:0 addr:003F0000
      exception.c:208: Test failed: 0: Wrong exception address 003F0000/003F0001
      exception.c:214: this is the last test seen before the exception
      exception: unhandled exception 80000004 at 003F0000
      exception.c:202: exception 0: c0000027 flags:2 addr:7C80E0B9
      exception.c:205: Test failed: 0: Wrong exception code c0000027/80000004
      exception.c:208: Test failed: 0: Wrong exception address 7C80E0B9/003F0001

  Note that this bug was not present in QEmu 1.1.2+dfsg-5 (Debian
  Testing) but is now present in 1.4.0~rc0+dfsg-1exp (Debian
  Experimental).

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1119686/+subscriptions

^ permalink raw reply

* [Qemu-devel] [Bug 809912] Re: qemu-kvm -m bigger 4096 aborts with 'Bad ram offset'
From: Launchpad Bug Tracker @ 2017-01-04  4:17 UTC (permalink / raw)
  To: qemu-devel
In-Reply-To: <20110713143335.13610.27004.malonedeb@chaenomeles.canonical.com>

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/809912

Title:
  qemu-kvm -m bigger 4096 aborts with 'Bad ram offset'

Status in QEMU:
  Expired

Bug description:
  When I try to start a virtual machine (x86_64 guest on a x86_64 host
  that has 32GB memory, using kvm_amd module, both host and guest
  running linux-2.6.39 kernels) with "qemu-system-x86_64 -cpu host -smp
  2 -m 4096 ...", shortly after the guest kernel starts, qemu aborts
  with a message "Bad ram offset 11811c000".

  With e.g. "-m 3500" (or lower), the virtual machine runs fine.

  I experience this both using qemu-kvm 0.14.1 and a recent version from git
  commit 525e3df73e40290e95743d4c8f8b64d8d9cbe021
  Merge: d589310 75ef849
  Author: Avi Kivity <avi@redhat.com>
  Date:   Mon Jul 4 13:36:06 2011 +0300

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/809912/+subscriptions

^ permalink raw reply

* [Qemu-devel] [Bug 441672] Re: Windos XP BSOD with HP Photosmart usb device attached
From: Launchpad Bug Tracker @ 2017-01-04  4:17 UTC (permalink / raw)
  To: qemu-devel
In-Reply-To: <20091003195706.32421.28307.malonedeb@gangotri.canonical.com>

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/441672

Title:
  Windos XP BSOD with HP Photosmart usb device attached

Status in QEMU:
  Expired

Bug description:
  https://bugzilla.redhat.com/show_bug.cgi?id=524723 has all the details
  of the problem.

  I was just testing attaching a USB device to see if it really worked, and tried my HP Photosmart C5580 All-in-One
  printer/scanner, and the Windows XP box then started getting bluescreens and crashing at random
  (fairly short :-) intervals.

  My latest attempt was on a fedora rawhide system with pretty up to date software
  (qemu-kvm-0.11.0-2.fc12.x86_64), and the crashes still happen.

  A reply to that bugzilla recommended adding this upstream bug, so here
  it is.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/441672/+subscriptions

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.