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:
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
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 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 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 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 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
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 (
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
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
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/
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
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
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
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;
> > > +
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
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
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
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 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 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: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 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
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 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.
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: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: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 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 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 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
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/
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 +---
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
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
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.
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
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
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
41 matches
Mail list logo
