From: Gonglei
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 included.
Second, if we rem
On 10/26/2014 08:46 AM, arei.gong...@huawei.com wrote:
> From: Gonglei
>
> 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_COMPA
On 2014/10/26 15:55, Paolo Bonzini wrote:
>
>
> On 10/26/2014 08:46 AM, arei.gong...@huawei.com wrote:
>> From: Gonglei
>>
>> 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_t
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 t
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 bef
From: Jan Kiszka
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 Kiszka
---
vl.c | 4 +---
From: Jan Kiszka
This reverts commit 15124e142034d21341ec9f1a304a1dc5a6c25681. It breaks
debuggability of qemu.
Signed-off-by: Jan Kiszka
---
Feel free to apply this before or after "Make qemu_shutdown_requested
signal-safe".
main-loop.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/
On 2014/10/26 17:32, Jan Kiszka wrote:
> From: Jan Kiszka
>
> 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_xc
On 2014/10/26 17:32, Jan Kiszka wrote:
> From: Jan Kiszka
>
> This reverts commit 15124e142034d21341ec9f1a304a1dc5a6c25681. It breaks
> debuggability of qemu.
>
> Signed-off-by: Jan Kiszka
> ---
>
Thanks, please add my 'Reported-by' tag and
Reviewed-by: Gonglei
> Feel free to apply this b
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
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 shou
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
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
>>
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.
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 se
On Sat, Oct 25, 2014 at 04:24:52PM +0800, john.liuli wrote:
> From: Li Liu
>
> 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 http://www.spinics.net/lists/kvm-arm/msg1
On Sat, Oct 25, 2014 at 04:24:54PM +0800, john.liuli wrote:
> From: Li Liu
>
> 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
> ---
> drivers/virtio/virtio_mmio.c | 34 +
On Sat, Oct 25, 2014 at 04:24:53PM +0800, john.liuli wrote:
> From: Li Liu
>
> 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 reason.
> 2.Ch
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 p
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 no
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 写道：
>
> OK, thanks, there are multiple branches in upstream qemu. Sorry
> for my
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 information
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;
> > > +
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 clus
Add qemu-iotests for qcow2 shrinking.
e.g:
$ ./check -qcow2 110
Signed-off-by: Jun Li
---
tests/qemu-iotests/110 | 76 ++
tests/qemu-iotests/110.out | 13
tests/qemu-iotests/group | 1 +
3 files changed, 90 insertions(+)
create mode 10
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
---
v5:
Do some modifications based on MAX's suggestion. Thanks for MAX.
In v5, do l2 shrinking firstly, then do l1 shri
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
---
v5:
Just instead write_reftable_entry with bdrv_pwrite_sync. As
write_reftable_ent
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
/usr/src/linux_git/arch/x86_64/boot/
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:
>
> https://fe
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
ma
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
#include
void handle_signal (
On 26 October 2014 16:01, Kostas Alexiou 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 mem", as I am
On 24 October 2014 23:43, Greg Bellows 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
> thought I'd share my
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 qm
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 syst
On Fri, Oct 24, 2014 at 02:01:44PM -0200, Eduardo Habkost wrote:
> On Thu, Oct 23, 2014 at 11:02:43AM +0800, Chao Peng wrote:
> > Add AVX512 feature bits, register definition and corresponding
> > xsave/vmstate support.
> >
> > Signed-off-by: Chao Peng
> > ---
> [...]
I agree to the cleanup sche
On 24.10.2014 10:22, Linhaifeng wrote:
Hi,
I run qemu2.1 with 1G hugepage and found that VM can't start (too slowly?) but
can start with 2M hugepage quickly.
kernel version:3.10.0-123.6.3.el7.x86_64
command:qemu-kvm -name vm1 -enable-kvm -smp 2 -m 2048 -object
memory-backend-file,id=mem,size
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:
41 matches
Mail list logo
