From: Gonglei arei.gong...@huawei.com
After commit 89b516d8, some logics is turbid.
First, vhost-usr-test.c rely on glib-compat.h because
of using G_TIME_SPAN_SECOND [glib 2.26] and g_get_monotonic_time(),
but vhost-usr-test.c defined QEMU_GLIB_COMPAT_H, which make
glib-compat.h will not be
On 10/26/2014 08:46 AM, arei.gong...@huawei.com wrote:
From: Gonglei arei.gong...@huawei.com
After commit 89b516d8, some logics is turbid.
First, vhost-usr-test.c rely on glib-compat.h because
of using G_TIME_SPAN_SECOND [glib 2.26] and g_get_monotonic_time(),
but vhost-usr-test.c
On 2014/10/26 15:55, Paolo Bonzini wrote:
On 10/26/2014 08:46 AM, arei.gong...@huawei.com wrote:
From: Gonglei arei.gong...@huawei.com
After commit 89b516d8, some logics is turbid.
First, vhost-usr-test.c rely on glib-compat.h because
of using G_TIME_SPAN_SECOND [glib 2.26] and
No change since previous repost, except I have rebased it against git
head.
Three line change for obvious bug. Can I get another review?
Previous discussion:
https://lists.gnu.org/archive/html/qemu-devel/2014-10/threads.html#00518
Rich.
qemu_opt_get_number returns a uint64_t, and curl_easy_setopt expects a
long (not an int).
Store the timeout (which is a positive number of seconds) as a
uint64_t. Check that the number given by the user is reasonable.
Cast it to long before calling curl_easy_setopt.
Example error message after
On 2014/10/26 16:42, Richard W.M. Jones wrote:
qemu_opt_get_number returns a uint64_t, and curl_easy_setopt expects a
long (not an int).
Store the timeout (which is a positive number of seconds) as a
uint64_t. Check that the number given by the user is reasonable.
Cast it to long before
From: Jan Kiszka jan.kis...@siemens.com
qemu_shutdown_requested may be interrupted by qemu_system_killed. If the
latter sets shutdown_requested after qemu_shutdown_requested has read it
but before it was cleared, the shutdown event is lost. Fix this by using
atomic_xchg.
Signed-off-by: Jan
From: Jan Kiszka jan.kis...@siemens.com
This reverts commit 15124e142034d21341ec9f1a304a1dc5a6c25681. It breaks
debuggability of qemu.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Feel free to apply this before or after Make qemu_shutdown_requested
signal-safe.
main-loop.c | 3 ---
1
On 2014/10/26 17:32, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
qemu_shutdown_requested may be interrupted by qemu_system_killed. If the
latter sets shutdown_requested after qemu_shutdown_requested has read it
but before it was cleared, the shutdown event is lost. Fix this by
On 2014/10/26 17:32, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
This reverts commit 15124e142034d21341ec9f1a304a1dc5a6c25681. It breaks
debuggability of qemu.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Thanks, please add my 'Reported-by' tag and
Reviewed-by:
On Sun, Oct 26, 2014 at 04:57:46PM +0800, Gonglei wrote:
On 2014/10/26 16:42, Richard W.M. Jones wrote:
qemu_opt_get_number returns a uint64_t, and curl_easy_setopt expects a
long (not an int).
Store the timeout (which is a positive number of seconds) as a
uint64_t. Check that the
On 2014/10/26 18:22, Richard W.M. Jones wrote:
It's just there to stop unreasonable timeouts or negative numbers.
10 s is 27 hours, and no webserver I know of would keep a
connection open that long. Possibly not even the IP stack.
Yes, it is. But 26 hours is OK? I just think we should
On Sun, Oct 26, 2014 at 06:45:02PM +0800, Gonglei wrote:
On 2014/10/26 18:22, Richard W.M. Jones wrote:
It's just there to stop unreasonable timeouts or negative numbers.
10 s is 27 hours, and no webserver I know of would keep a
connection open that long. Possibly not even the IP
On 2014/10/26 18:48, Richard W.M. Jones wrote:
On Sun, Oct 26, 2014 at 06:45:02PM +0800, Gonglei wrote:
On 2014/10/26 18:22, Richard W.M. Jones wrote:
It's just there to stop unreasonable timeouts or negative numbers.
10 s is 27 hours, and no webserver I know of would keep a
connection
On Sun, Oct 26, 2014 at 06:55:21PM +0800, Gonglei wrote:
On 2014/10/26 18:48, Richard W.M. Jones wrote:
On Sun, Oct 26, 2014 at 06:45:02PM +0800, Gonglei wrote:
On 2014/10/26 18:22, Richard W.M. Jones wrote:
It's just there to stop unreasonable timeouts or negative numbers.
10 s
v2:
- Define the maximum timeout in a macro.
- Reduce the maximum timeout to 1 s (instead of 10 s).
qemu_opt_get_number returns a uint64_t, and curl_easy_setopt expects a
long (not an int). There is no warning about the latter type error
because curl_easy_setopt uses a varargs argument.
Store the timeout (which is a positive number of seconds) as a
uint64_t. Check that the number given by the
On 2014/10/26 19:05, Richard W.M. Jones wrote:
qemu_opt_get_number returns a uint64_t, and curl_easy_setopt expects a
long (not an int). There is no warning about the latter type error
because curl_easy_setopt uses a varargs argument.
Store the timeout (which is a positive number of
On Sat, Oct 25, 2014 at 04:24:52PM +0800, john.liuli wrote:
From: Li Liu john.li...@huawei.com
This set of patches try to implemet irqfd support of vhost-net
based on virtio-mmio.
I had posted a mail to talking about the status of vhost-net
on kvm-arm refer to
On Sat, Oct 25, 2014 at 04:24:54PM +0800, john.liuli wrote:
From: Li Liu john.li...@huawei.com
This irq handler will get the interrupt reason from a
shared memory. And will be assigned only while irqfd
enabled.
Signed-off-by: Li Liu john.li...@huawei.com
---
On Sat, Oct 25, 2014 at 04:24:53PM +0800, john.liuli wrote:
From: Li Liu john.li...@huawei.com
Add a new register offset VIRTIO_MMIO_ISRMEM which help to
estblish a shared memory region between virtio-mmio driver
and qemu with two purposes:
1.Guest virtio-mmio driver can get the interrupt
On 2014-10-21 00:34, Knut Omang wrote:
@@ -65,11 +66,12 @@ struct VTDContextCacheEntry {
};
struct VTDAddressSpace {
-uint8_t bus_num;
+PCIDevice *dev;
This change is not helpful for clean handling of non-PCI devices (i.e.
platform device interrupt remapping = you had to pull
On Sun, 2014-10-26 at 13:06 +0100, Jan Kiszka wrote:
On 2014-10-21 00:34, Knut Omang wrote:
@@ -65,11 +66,12 @@ struct VTDContextCacheEntry {
};
struct VTDAddressSpace {
-uint8_t bus_num;
+PCIDevice *dev;
This change is not helpful for clean handling of non-PCI devices
And I still shall try qemu and kernel distribution for testing.
But excuse me, maybe I can not finish within this month, I shall try to
finish within next month.
Thanks.
发自我的 iPad
在 2014年10月22日，上午8:28，Chen Gang gang.chen.5...@gmail.com 写道：
OK, thanks, there are multiple branches in
Hello Guenter Roeck:
I still shall try qemu and kernel distribution, next, since it can do
it successfully (whether 'sim' can be success or not).
But excuse me, maybe I can not finish microblaze qemu test within this
month, hope I can finish within next month (2014-11-30).
Thank your
On Sun, Oct 26, 2014 at 02:15:24PM +0100, Knut Omang wrote:
On Sun, 2014-10-26 at 13:06 +0100, Jan Kiszka wrote:
On 2014-10-21 00:34, Knut Omang wrote:
@@ -65,11 +66,12 @@ struct VTDContextCacheEntry {
};
struct VTDAddressSpace {
-uint8_t bus_num;
+PCIDevice *dev;
v5:
Add qemu-iotests for qcow2 shrinking. Do some modifications based on MAX's
suggestions in v4.
v4:
Add deal with COW clusters in l2 table. When using COW, some of (l2_entry
s-cluster_bits) will larger than s-refcount_table_size, so need to discard
this l2_entry.
v3:
Fixed host cluster
Add qemu-iotests for qcow2 shrinking.
e.g:
$ ./check -qcow2 110
Signed-off-by: Jun Li junm...@gmail.com
---
tests/qemu-iotests/110 | 76 ++
tests/qemu-iotests/110.out | 13
tests/qemu-iotests/group | 1 +
3 files changed, 90
This patch is the realization of new function qcow2_shrink_l1_and_l2_table.
This function will shrink/discard l1 and l2 table when do qcow2 shrinking.
Signed-off-by: Jun Li junm...@gmail.com
---
v5:
Do some modifications based on MAX's suggestion. Thanks for MAX.
In v5, do l2 shrinking
When every item of refcount block is NULL, free refcount block and reset the
corresponding item of refcount table with NULL. At the same time, put this
cluster to s-free_cluster_index.
Signed-off-by: Jun Li junm...@gmail.com
---
v5:
Just instead write_reftable_entry with bdrv_pwrite_sync. As
Public bug reported:
Following the guide at
http://www.linux-kvm.org/page/USB_Host_Device_Assigned_to_Guest
Qemu is launched with qemu-system-x86_64 /dev/vgstripe/kvm_wifi -enable-kvm -m
512 -k fr -net nic -net tap,ifname=tap1,script=/bin/ifup.script -kernel
On Wed, Oct 22, 2014 at 11:59:06AM +0200, Gerd Hoffmann wrote:
syntax error
## Error: catX not defined
syntax error
## Error: catX not defined
No kernel provides dtb named vexpress-v2p-ca9.dtb
No value for u_kernel. Getting help.
[ ... ]
Google finds me this:
Hello,
I am using the latest stable version 2.1.2 of qemu and I noticed that some
commands which are fully supported for the i386 architecture, in ARM
emulation they are not offered. I am referring specifically to info tlb
and info mem, as I am mainly interested in the MMU of ARM and memory
QEMU should convert signal number reciving from GDB cilent
from gdb-signal number to target sginal number - using gdb_signal_to_target().
In this case, GDB_SIG_BUS is 10. However, 10 is SIGUSR1 for target.
So QEMU continues with the wrong signal number.
#include stdio.h
#include signal.h
void
On 26 October 2014 16:01, Kostas Alexiou ekale...@gmail.com wrote:
I am using the latest stable version 2.1.2 of qemu and I noticed that some
commands which are fully supported for the i386 architecture, in ARM
emulation they are not offered. I am referring specifically to info tlb
and info
On 24 October 2014 23:43, Greg Bellows greg.bell...@linaro.org wrote:
Based on our discussion, I looked into a table lookup approach to replace
the arm_phys_excp_target_el() as we discussed. I have something working but
still need to verify it is 100% correct. Before I went much further, I
On 10/24/2014 10:04 PM, Eric Blake wrote:
On 10/24/2014 01:06 AM, Wen Congyang wrote:
Introduce a xen-load-devices-state QAPI command that can be used to load
the state of all devices, but not the RAM or the block devices of the
VM.
We only have hmp commands savevm/loadvm, and qmp commands
On 10/26/14 21:28, Chen Gang wrote:
Hello Guenter Roeck:
I still shall try qemu and kernel distribution, next, since it can do
it successfully (whether 'sim' can be success or not).
I got confirmation from microblaze members, at present, microblaze sim
can not full simulate entire system,
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: qemu (Ubuntu Vivid)
Status: New = Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1368815
Title:
39 matches
Mail list logo
