Hi There
I am new to qemu development but wanted to give a hand with the alpha
port. Unfortinuatly it is not that easy to get the initial development
environment up and running. So I ask you for help
I downloaded qemu 0.12.50 using git. That compiled cleanly on ubuntu
9.10, including qemu-alpha
> There's a problem with the current implementation of mmap
> in linux-user such that it can return addresses that are
> outside the "valid" address space of the guest.
How do I, either
1. avoid the problem? (Give the guest a larger valid address space)
2. Fix the problem ? (Could you give 4 line
Hi all !
First of all, please, excuse me for my english.
I'm running qemu (kvm) on a debian testing host, qemu version is 0.9.1-1.
I've got a vm that's running windows xp. For testing, i would like to use
an usb device (dongle) needed for me vpn connection (Checkpoint).
In qem
Public bug reported:
Hello,
In qemu-system-riscv64, following a QEMU update, I get all sort of weird
and not easily reproducible crashes in my risc-v guest.
I have bissected this issue to commit c7b951718815694284501ed01fec7acb8654db7b.
Some TLB flushes were removed in the following places
(struct audio_pcm_info *info, void *buf, int
len);
diff --git a/audio/paaudio.c b/audio/paaudio.c
index 65beb6f010..089af32e4d 100644
--- a/audio/paaudio.c
+++ b/audio/paaudio.c
@@ -1,16 +1,44 @@
-/* public domain */
+/*
+ * QEMU ALSA audio driver
+ *
+ * Copyright (c) 2017 Martin Schrodt
It has been solved thanks to the mailing-list members.
** Changed in: qemu
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1832535
Title:
[riscv/regress
there are many discus about using keyboard and mouse with VGA passthru,
so I add a graphic_console to vfio.c, like puv3.c.
I test it with SDL and VNC Access, the Keyboard works, the mouse work
good without absolute version like "-usbdevice mouse".
Default it boot with "QEMU PS/2 M
Am 10.04.2014 22:29, schrieb Alex Williamson:
> I don't think vfio is the one to be creating a dummy console, besides
> there's no reason you can't have multiple vfio devices with x-vga=on.
> There should probably be some dummy console driver so you can add
> -device dummy-console to the commandli
t's a GCC bug. We have worked around it in recent versions of QEMU;
| what version are you trying to compile?
I'm using bisect to find a runtime behavior bug (OpenBSD/amd64 current's
cd53.iso segv's in
userland) that showed up since 1.4.0 release. So understandably I'
t's a GCC bug. We have worked around it in recent versions of QEMU;
| what version are you trying to compile?
|
| You can compile that file with "-O2 -fno-gcse".
|
| Paolo
I don't note a huge improvement:
load averages: 6.74, 6.23, 5.17leveno.fries.ne
Penned by Paolo Bonzini on 20130321 3:25.51, we have:
| Il 21/03/2013 08:53, qemu-de...@email.fries.net ha scritto:
| > load averages: 6.74, 6.23, 5.17leveno.fries.net
02:42:23
| > 201 processes: 200 idle, 1 on processor
| > CPU0 states: 0.4% user, 0.0% n
Penned by ? (Wei-Ren Chen) on 20130322 2:30.14, we have:
| > Still no joy:
| >
| > PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND
| > 21212 todd -5 20 1142M 118M sleep/0 - 1:03 37.30% cc1
| >
| > cc -I. -I/home/todd/git/sw
Using a 0.8.0, 0.8.1, and a few days old CVS version of qemu with dos 6.22 / win 3.11 I have tried installing the qemm extended memory manager (google, second page, get qemm97) and no matter what settings I give it, when it has been installed and reboots, qemu locks up.It says it might lock up and
Hi all,
I noticed that IA64 host suport is only in develpment from Qemu's official Website. Can anyone tell me the current status about it ? Now I want to run X86 guest OS on IA64 host.
Can I get it happen ? Currently, Seems sourcecode of Qemu was recursivly compiled in IA64 enviro
Hi List,
This morning I ran across a thread on this list from Oct'11 about slow
booting with large initrd images. Reading through that thread, I didn't
really see any sort of definitive resolution to the problem.
Also, this morning, I upgraded Qemu-KVM to latest
06:57:59 -0600, Dyweni - Qemu-Devel wrote:
Hi,
I am unable to boot KVM using a usb flash drive. I'm using QEMU-KVM
built
from GIT MASTER as of this morning.
Here's my QEMU-KVM startup options:
qemu-system-x86_64
-curses
-m 512
-snapshot
-device piix3-usb-uhci
-drive id=usbflash,file=fl
Hi All,
In QEMU-KVM 0.14, I was able to simulate booting from a USB Flash drive
with
these options:
qemu-system-x86_64 \
-curses \
-m 512 \
-snapshot \
-device piix3-usb-uhci \
-drive id=usbflash,file=flash.img,if=none,boot=on,cache=writeback
Hi,
I am unable to boot KVM using a usb flash drive. I'm using QEMU-KVM
built
from GIT MASTER as of this morning.
Here's my QEMU-KVM startup options:
qemu-system-x86_64 \
-curses \
-m 512 \
-snapshot \
-device piix3-usb-uhci \
-drive id=usb
Hi All,
Here is the log when booting SeaBIOS with debuging enabled:
+ qemu-system-x86_64 -m 512 -snapshot -device piix3-usb-uhci -drive
id=usbflash,file=flash.img,if=none,boot=on,cache=writeback -device
usb-storage,drive=usbflash -net nic,macaddr=00:AA:00:AA:62:AA,vlan=0
-net tap,vlan=0
Hi All,
I have good and bad news...
I tested QEMU-KVM using branches 'master'
(9501d0f1b6efc83f69d06b27a625bad71d30d58b) and 'uq/master'
(6a48ffaaa732b2142c1b5030178f2d4a0fa499fe). Seabios used was the
version
included in those branches (no -L switch). Both branches faile
Hi List!
I'm running into an issue compiling QEMU with RBD support.
>From the Wiki (http://ceph.newdream.net/wiki/QEMU-RBD), I should be
able to do the following:
$ git clone git://git.qemu.org/qemu.git
$ cd qemu
$ ./configure --enable-rbd
$ make; make install
However, the configure
rbd.so -> librbd.so.1.0.0
/usr/lib64/librbd.so.1 -> librbd.so.1.0.0
/usr/lib64/librbd.so.1.0.0
The QEMU configure script is looking for a function called
'rados_initialize' within the header file 'rados/librados.h'.
I checked the rados include/lib files for that funct
Hi List!
I am tripping across this error as soon as the qemu rbd disk is
probed by the windows 2000 installer:
VNC server running on `127.0.0.1:5900'
terminate called after throwing an instance of 'ceph::buffer::end_of_buffer'
what(): buffer::end_of_buffer
Aborted (core dumped
Hi List!
I upgraded Ceph to the latest development version
Commit: 0edbc75a5fe8c3028faf85546f3264d28653ea3f
Pulled from: git://ceph.newdream.net/ceph.git
I recompiled the latest GIT version of QEMU-KVM (with Josh Durgin's
patches) against the latest git version of Ceph.
Ho
Hi Josh/Lists!
463 ::decode(*data_bl, iter);
(gdb) print r
$1 = 0
(gdb) print data_bl
$2 = (ceph::bufferlist *) 0x7f16f40d6060
(gdb) print data_bl->_len
$3 = 0
(gdb) print iter->off
$4 = 20
Thanks,
Dyweni
> CCing the ceph list.
>
> On 05/06/2011 12:23 PM, Dywe
0, _off = 0, _len = 0}, last_p = {
bl = 0x7f16f40d6170, ls = 0x7f16f40d6170, off = 0, p = {_M_node =
0x7f16f40d6170}, p_off = 0}}, pbl = 0x0, buf = 0x0, maxlen = 0}
Thanks,
Dyweni
> On Fri, 6 May 2011, Dyweni - Qemu-Devel wrote:
>> Hi Josh/Lists!
>>
>> 463 ::de
Thanks,
Dyweni
> f 9 (or 8?)
> p n
> p s
>
> (BTW this might be faster over irc, #ceph on irc.oftc.net)
>
> Thanks!
> sage
>
>
> On Fri, 6 May 2011, Dyweni - Qemu-Devel wrote:
>
>> Hi Sage/Lists!
>>
>>
>> (gdb) print c->bl._len
>
Hi Sage/Lists!
Yes! The entire Ceph cluster (1 Mon, 1 MSD, 3 OSD) are 32bit linux.
The machine running Qemu is 64bit linux.
Thanks,
Dyweni
> On Fri, 6 May 2011, Dyweni - Qemu-Devel wrote:
>> Hi Sage/Lists!
>>
>>
>> (gdb) f 8
>> #8 0x7f170174198
Qemu does not close its filedescriptors (or setting the FD_CLOEXEC) when
invoking the /etc/qemu-ifup script.
Hence any background process spawned from there (such as a dhcpd) will
also inherit the open filedescriptor, preventing the relevant decide
(/dev/net/tup) to be reused later on:
If
de; /* Tracks E1000_TXD_CMD_IDE bit. */
+QEMUTimer *flush_queue_timer;
+
/* Compatibility flags for migration to/from qemu 1.3.0 and older */
#define E1000_FLAG_AUTONEG_BIT 0
#define E1000_FLAG_MIT_BIT 1
@@ -366,6 +368,7 @@ static void e1000_reset(void *opaque)
timer_del(d->autoneg
Original Message
Subject: Re: [Qemu-devel] [PATCH RFC v19 11/13] target-avr: Put all translation
code into one compilation unit
Local Time: June 13, 2017 10:07 PM
UTC Time: June 13, 2017 8:07 PM
From: th...@redhat.com
To: Michael Rolnik , qemu-devel@nongnu.org
Richard Henderson
Hello.
I have forgot about this. I even unable to remember what I have done.
Unfortunately I can't help you. Sorry.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1169049
Title:
do not st
Anyone can explain what is the blocking problem for this target to be pulled
upstream?
I apologize for bothering but I don't have the workflow clear in my mind.
thanks,
Anichang
> Original Message
> Subject: Re: [PATCH RFC v19 00/13] QEMU AVR 8 bit cores
> Local
Hi all,
I just resurrected the target-avr patchset from Michael Rolnik. Following the
details:
commit f2bca179dbfc3f378b131ed619d07db946bae598
Merge: 43771d5 ed250c0
Author: Ani Chang
Date: Fri Jun 2 01:17:34 2017 +0200
target/avr: resurrected (see mailing list qemu-devel, Richard Henderson
When the guest OS needs to send the mouse commands it will at least in
the case
of Windows 10 set the KBD_MODE_DISABLE_MOUSE bit to prevent interrupts
from
causing stream desynchronisation.
Here is Windows 10 attempting to issue a PS/2 mouse reset without this
fix where
you can see the mouse p
Hi All,
I am writing some code that needs to share a block of ram between a
Windows guest and Linux host. For this I am using the ivshmem device and
I have written a very primitive driver for windows that allows a single
application to request to memory map the pci bar (shared memory) into
th
Hi,
A .qcow file was deleted by mistake. No recovery or backup is available.
Hard disk was plugged out from the NAS after half a hour to prevent
Synology OS operations writing over desallocated stockage. The file
system on the virtual disk was ntfs. Virtualisation OS is Proxmox.
Ease Us Data
I just updated to the latest build and applied this patch set, now on VM
reset the qemu crashes with the following assert:
ivshmem.c:467: ivshmem_add_kvm_msi_virq: Assertion
`!s->msi_vectors[vector].pdev' failed.
On 2017-11-15 18:31, Ladi Prosek wrote:
Fixes bugs in the ivshme
I can confirm that these patches work as expected. Thank you kindly Alex
for your hard work!
Tested-by: Geoffrey McRae
On 2018-11-15 07:50, Alex Williamson wrote:
QEMU exposes gen1 PCI-express interconnect devices supporting only
2.5GT/s and x1 width. It might not seem obvious that a
On 2018-10-08 10:38, Fam Zheng wrote:
On Fri, 10/05 10:00, yuchenlin wrote:
Ping?
Hi,
This was merged as 51b3c6b73acae1e3fd3c7d441fc86dd17356695f.
Fam
Hi,
Thank you for your information.
yuchenlin
On 2018-09-13 16:34, Fam Zheng wrote:
> On Thu, 09/13 16:29, yuchen...@synology.com wro
initialized.
vhost_verify_ring_mappings may use uninitialized vhost_virtqueue
such that vhost_verify_ring_part_mapping returns ENOMEM.
When encountered this problem, we got the following logs:
qemu-system-x86_64: Unable to map available ring for ring 0
qemu-system-x86_64: Verify ring failure on
and event vq.
In this case, ctrl and event vq are not initialized.
vhost_verify_ring_mappings may use uninitialized vhost_virtqueue
such that vhost_verify_ring_part_mapping returns ENOMEM.
When encountered this problem, we got the following logs:
qemu-system-x86_64: Unable to map available
From: yuchenlin
Signed-off-by: yuchenlin
---
hw/display/vga_int.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/hw/display/vga_int.h b/hw/display/vga_int.h
index 6e4fa48a79..55c418eab5 100644
--- a/hw/display/vga_int.h
+++ b/hw/display/vga_int.h
@@ -166,7 +166,6 @@ MemoryRegion *vga_init_i
(VGACommonState *s);
void vga_dirty_log_start(VGACommonState *s);
void vga_dirty_log_stop(VGACommonState *s);
Added to vga queue.
thanks,
Gerd
Hi, Gerd
Laurent has sent a pull request for this trivial commit.
See:
http://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg05896.html
Thanks
Ping?
On 2018-09-13 16:34, Fam Zheng wrote:
On Thu, 09/13 16:29, yuchen...@synology.com wrote:
From: yuchenlin
There is a rare case which the size of last compressed cluster
is larger than the cluster size, which will cause the file is
not aligned at the sector boundary.
There are three reas
On 2018-12-28 22:50, Julio Faracco wrote:
This is a trivial patch to fix a wrong value for block terminator.
The old value was 0x7fff which is wrong. It was not affecting the
code because QEMU dmg block is not handling block terminator right now.
Neverthless, it should be fixed.
Signed-off
From: yuchenlin
There is a rare case which the size of last compressed cluster
is larger than the cluster size, which will cause the file is
not aligned at the sector boundary.
Signed-off-by: yuchenlin
---
block/vmdk.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/blo
Public bug reported:
this is a problem in the qemu-binfmt-conf.sh script and maybe somewhere
else. the version i checked is the current github mirror
https://github.com/qemu/qemu/blob/master/scripts/qemu-binfmt-conf.sh
i am running linux mint 19 32bit on a 32bit x86 cpu and i want to run
some
Ping!
yuchen...@synology.com 於 2018-08-28 11:18 寫道：
> From: yuchenlin There is a rare case which the size
> of last compressed cluster is larger than the cluster size, which will cause
> the file is not aligned at the sector boundary. Signed-off-by: yuchenlin
> --- block/vmdk.c | 18 +
QEMUIOVector *qiov) > { > + if (bytes == 0) {
> > > Where is this bytes == 0 condition from?
From the end of convert_do_copy in qemu-img.c.
if (s->compressed && !s->ret) {
/* signal EOF to align */
ret = blk_pwrite_compressed(s->target, 0, NULL, 0);
if (ret <
On 2018-09-12 19:54, Fam Zheng wrote:
On Tue, 08/28 11:17, yuchen...@synology.com wrote:
From: yuchenlin
There is a rare case which the size of last compressed cluster
is larger than the cluster size, which will cause the file is
not aligned at the sector boundary.
Signed-off-by: yuchenlin
-
From: yuchenlin
There is a rare case which the size of last compressed cluster
is larger than the cluster size, which will cause the file is
not aligned at the sector boundary.
Signed-off-by: yuchenlin
---
v1 -> v2:
* Add more detail comment.
* Add QEMU_ALIGN_UP to show the intention more clear
On 2018-09-13 10:54, Fam Zheng wrote:
On Thu, 09/13 10:31, yuchen...@synology.com wrote:
From: yuchenlin
There is a rare case which the size of last compressed cluster
is larger than the cluster size, which will cause the file is
not aligned at the sector boundary.
The code looks good to me.
From: yuchenlin
There is a rare case which the size of last compressed cluster
is larger than the cluster size, which will cause the file is
not aligned at the sector boundary.
There are three reasons to do it. First, if vmdk doesn't align at
the sector boundary, there may be many undefined beha
Public bug reported:
I have qemu windows build 2.12.90, haxm 7.2.0. Ubuntu, nor arch linux does not
works when i turn on hax acceleration. Permanent kernel panics, black screen
freezing and other crashes happens when i run qemu.
Qemu crashed with hax - when i ran it from iso. It crashed on
qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1781211
Title:
HAXM acceleration does not work at all.
Status in QEMU:
New
Bug description:
I have qemu windows build 2.12.90, haxm 7.2.0. Ubuntu, nor arch linux does
not works when i turn on hax acceleration
Public bug reported:
Attempting to emulate some baremetal ARM cortex-M* firmware with gdb
causes a segfault every time.
qemu invocation:
qemu-system-arm -machine none -cpu cortex-m3 -nographic -monitor null -serial
null -s -S -device loader,file=firmware.elf
qemu seems to startup fine with
follow-up to IRC discussions with stsquad and danpb : the problem is
"-machine none" which prevents all the data structures from being
initialized properly.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.lau
/show_bug.cgi?id=1481253
https://bugs.launchpad.net/qemu/+bug/1703506
v7:
Rebased on top of latest tree after 2.12 release and done few basic
tests. There are
no changes except for few minor hunks. Hopefully this gets pulled
into 2.13 release.
Please review, let me know of any feedback.
v6:
1.Fixed
From: Andrew Oates
On Linux, SOCK_DGRAM+IPPROTO_ICMP sockets give only the ICMP packet when
read from. On macOS, however, the socket acts like a SOCK_RAW socket
and includes the IP header as well.
This change strips the extra IP header from the received packet on macOS
before sending it to the
From: Andrew Oates
On Linux, SOCK_DGRAM+IPPROTO_ICMP sockets give only the ICMP packet when
read from. On macOS, however, the socket acts like a SOCK_RAW socket
and includes the IP header as well.
This change strips the extra IP header from the received packet on macOS
before sending it to the
From: yuchenlin
When the condition of each if or else if is true,
the code flow will goto fail. Which means we can decouple
if else if chain to get some readability.
Signed-off-by: yuchenlin
---
block/vdi.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
dif
From: yuchenlin
This series refine some code in vdi.c, includes:
* Remvoe CONFIG_VDI_WRITE because there is no reason to leave an always on
and cannot configure option in the code-side.
* decouple if else if chain to get more readability.
Thanks,
yuchenlin
yuchenlin (2):
vdi: remove CONFIG
From: yuchenlin
The CONFIG_VDI_WRITE is here when the first time vdi is added.
But there is no reason to leave an always on and cannot configure option
in the code-side.
Signed-off-by: yuchenlin
---
block/vdi.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/block/vdi.c b/block/vdi.c
i
Hi, Stefan
I agree that redundancy of If else may helps people to understand the code.
However, CONFIG_VDI_WRITE only contributes:
#if defined(CONFIG_VDI_WRITE)
.bdrv_co_pwritev = vdi_co_pwritev,
#endif
I think we don't need CONFIG_VDI_WRITE to document the code.
As its name implies, vdi_co_pwr
ards,
Yan.
On 15 Oct 2017, at 12:32, geoff--- via Qemu-devel
wrote:
Hi All,
I am writing some code that needs to share a block of ram between a
Windows guest and Linux host. For this I am using the ivshmem
device and I have written a very primitive driver for windows that
allows a single appli
On 2017-10-18 16:31, Ladi Prosek wrote:
Hi Geoff,
On Mon, Oct 16, 2017 at 8:31 PM, wrote:
Hi Yan & Ladi.
I have written an initial implementation that supports just the shared
memory
mapping at this time. I plan to add events also but before I go
further I
would
like some feedback if possi
On 2017-10-18 17:50, Ladi Prosek wrote:
On Wed, Oct 18, 2017 at 7:50 AM, wrote:
On 2017-10-18 16:31, Ladi Prosek wrote:
Hi Geoff,
On Mon, Oct 16, 2017 at 8:31 PM, wrote:
Hi Yan & Ladi.
I have written an initial implementation that supports just the
shared
memory
mapping at this time.
Hi Ladi & Yan,
I am pleased to present the completed driver for review, please see:
https://github.com/gnif/kvm-guest-drivers-windows
All issues previously mentioned have been addressed and all missing
functionality has been added.
Please note that this work has exposed a bug in the
my lack of familiarity with Visual
Studio, give me gcc and vim any day :).
Thanks!
All issues previously mentioned have been addressed and all missing
functionality has been added.
Please note that this work has exposed a bug in the qemu ivshmem
virtual device itself, it seems that if the MSI int
On 2017-10-19 20:01, Ladi Prosek wrote:
On Thu, Oct 19, 2017 at 10:44 AM, wrote:
On 2017-10-19 19:35, Ladi Prosek wrote:
On Wed, Oct 18, 2017 at 5:04 PM, wrote:
Hi Ladi & Yan,
I am pleased to present the completed driver for review, please see:
https://github.com/gnif/kvm-guest-drivers
On 2017-10-19 20:07, ge...@hostfission.com wrote:
On 2017-10-19 20:01, Ladi Prosek wrote:
On Thu, Oct 19, 2017 at 10:44 AM, wrote:
On 2017-10-19 19:35, Ladi Prosek wrote:
On Wed, Oct 18, 2017 at 5:04 PM, wrote:
Hi Ladi & Yan,
I am pleased to present the completed driver for review, ple
On 2017-10-19 20:51, Ladi Prosek wrote:
On Thu, Oct 19, 2017 at 11:41 AM, wrote:
On 2017-10-19 20:07, ge...@hostfission.com wrote:
On 2017-10-19 20:01, Ladi Prosek wrote:
On Thu, Oct 19, 2017 at 10:44 AM, wrote:
On 2017-10-19 19:35, Ladi Prosek wrote:
On Wed, Oct 18, 2017 at 5:04 PM
Hi All,
I have started to dig into why ntp seems to slow down graphics
performance on
AMD systems using PCI passthrough and figured I would report what I have
so far
discovered. I have noted the primary point of failure seems to be
specifically
with PhysX. This is why people only see a slow do
>Could you please try to replace the -virtfs option with these two options:
>
>-fsdev local,id=shared,path=/home/mahmood/Downloads \
>-device virtio-9p-pci,fsdev=shared,mount_tag=Downloads
Still get the same error!
mahmood@cluster:qemu-vm$ qemu-system-x86_64 -m 4000 -cpu Opter
The security_model=none also doesn't work and get the same error.
mahmood@cluster:qemu-vm$ qemu-system-x86_64 -version
QEMU emulator version 1.7.0, Copyright (c) 2003-2008 Fabrice Bellard
I know it is old but I think I installed this version three years ago due to
the Rocks-6 versio
Hello again,I installed 2.5.0 quickly and it was pretty straight forward!
Here is the error message I get regarding the 'virtio-9p-pci'
mahmood@cluster:qemu-vm$ qemu-system-x86_64 -m 4000 -cpu Opteron_G5 -smp 2 -hda
centos7.img -boot c -usbdevice tablet -enable-kvm -device
e1
OK. I reconfigured 2.9.0 with --enable-virtfs. Please note:
1- If I use -virtfs option, I get
qemu-option.c:547: opt_set: Assertion `opt->str' failed
2- If I use -fsdev and -device, then I *must* use security_model
3- If I use -fsdev and -device and security_model, then the gue
Hello again,
For the command
mount -t 9p -o trans=virtio Downloads /media/Downloads
inside the Centos-7 guest, I get this error
mount: unknown filesystem type '9p'
Any thought?
Regards,
Mahmood
Thanks Ladi, I had not yet had time to dig into these, this patch set
resolves all issues I was aware of.
Tested-by: Geoffrey McRae
On 2017-11-11 04:34, Ladi Prosek wrote:
As of commit 660c97eef6f8 ("ivshmem: use kvm irqfd for msi
notifications"),
QEMU cr
On 2017-11-14 04:27, Markus Armbruster wrote:
Ladi Prosek writes:
Adds a rollback path to ivshmem_enable_irqfd() and fixes
ivshmem_disable_irqfd() to bail if irqfd has not been enabled.
Signed-off-by: Ladi Prosek
Is this a theoretical bug, or can you trigger it?
It is reproducible, I can
Public bug reported:
This would be a useful feature. Many kernels, particularly hobbyist
kernels, have support for ATAGS.
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to
if I wait around 30 minutes to an hour I can
restart and it will boot fine again with iommu=pt (I get a kernel panic
if i don't use iommu=pt)
Hardware
Ryzen R5 1600
asrock ab350m pro4
32gb ram
Host gpu RX580
Guest gpu GTX1070
--
You received this bug notification because you are a member of
From: yuchenlin
VMDK has a hard limitation of extent size, which is due to the size of grain
table entry is 32 bits. It means it can only point to a grain located at
offset = 2^32. To prevent offset overflow and record a useless offset
in grain table. We should return un-support here.
Signed-off
From: yuchenlin
VMDK has a hard limitation of extent size, which is due to the size of grain
table entry is 32 bits. It means it can only point to a grain located at
offset = 2^32. To avoid writing the user data beyond limitation and record a
useless offset
in grain table. We should return ERROR
From: yuchenlin
VMDK has a hard limitation of extent size, which is due to the size of grain
table entry is 32 bits. It means it can only point to a grain located at
offset = 2^32. To avoid writing the user data beyond limitation and record a
useless offset
in grain table. We should return ERROR
l implementation follows "Synchronous/precise" approach that is
write-back is discarded and "EPCR (no delay slot)" <= "Address of
instruction that caused exception".
Currently I'm focused on implementation snoop-invalidation logic in
MAROCCHINO and cou
This allows guest's to correctly reinitialize and identify the mouse
should the guest decide to re-scan or reset during mouse input events.
Signed-off-by: Geoffrey McRae
---
hw/input/ps2.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/input/ps2.c b/hw/input/ps2.c
index 06f5d2ac4a..
This fixes an issue by adding bounds checking to multi-byte packets
where the PS/2 mouse data stream may become corrupted due to data
being discarded when the PS/2 ringbuffer is full.
Interrupts for Multi-byte responses are postponed until the final
byte has been queued.
These changes fix a bug
On 2018-05-07 22:21, Gerd Hoffmann wrote:
On Mon, May 07, 2018 at 10:00:22PM +1000, geoff--- via Qemu-devel
wrote:
This allows guest's to correctly reinitialize and identify the mouse
should the guest decide to re-scan or reset during mouse input events.
Signed-off-by: Geoffrey McRae
--
On 2018-05-07 22:34, Gerd Hoffmann wrote:
diff --git a/hw/input/ps2.c b/hw/input/ps2.c
index 6edf046820..011290920f 100644
--- a/hw/input/ps2.c
+++ b/hw/input/ps2.c
@@ -192,12 +192,50 @@ void ps2_queue(PS2State *s, int b)
{
PS2Queue *q = &s->queue;
-if (q->count >= PS2_QUEUE_SIZE - 1)
On 2018-05-07 22:41, Gerd Hoffmann wrote:
On Mon, May 07, 2018 at 10:26:24PM +1000, geoff--- via Qemu-devel
wrote:
On 2018-05-07 22:21, Gerd Hoffmann wrote:
> On Mon, May 07, 2018 at 10:00:22PM +1000, geoff--- via Qemu-devel wrote:
> > This allows guest's to correctly reinitializ
From: Andrew Wood
Signed-off-by: Andrew Wood
---
os-posix.c | 1 +
vl.c | 13 +++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/os-posix.c b/os-posix.c
index b9c2343b1e..68d70f269b 100644
--- a/os-posix.c
+++ b/os-posix.c
@@ -70,6 +70,7 @@ void os_setup_signal
Hi All,
I am having some very strange issues with Qemu and memory copy
performance. It seems that when performing buffer -> buffer copies of
8MB or lower the performance is horrid.
Test program:
#include
#include
#include
#include
#include
static inline uint64_t nanotime()
{
str
(wrong bug, sorry!)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1350435
Title:
tcg.c:1693: tcg fatal error
Status in launchpad-buildd:
Won't Fix
Status in QEMU:
Fix Released
Status in
Hello, this seems to be still an issue
W: Failure while unpacking required packages. This will be attempted up to
five times.
W: See //debootstrap/debootstrap.log for details (possibly the package
/var/cache/apt/archives/bash_4.4.18-1ubuntu1_arm64.deb is at fault)
dpkg -l |grep qemu
ii ipxe
error will occur:
qemu-system-x86_64: AHCI: Failed to start FIS receive engine: bad FIS receive
buffer address
qemu-system-x86_64: Failed to load ich9_ahci:ahci
qemu-system-x86_64: error while loading state for instance 0x0 of device
':00:1a.0/ich9_ahci'
qemu-system-x86_64: load
-- Best regards, Andy Chiu John Snow 於 2019-09-10 02:13 寫道：
> > > > On 9/9/19 1:18 PM, andychiu via Qemu-devel wrote: > > If Windows 10
guests have enabled 'turn off hard disk after idle' > > option in power
settings, and the guest has a SATA disk plugged in,
[reg:PxIS] @ 0x10:
0x0002
ahci_mem_write_host ahci(0x7fcc4e19b4a0) write4 [reg:IS] @ 0x8:
0x0001
---
--
Best regards,
Andy Chiu
On 2019/9/10 上午2:13, John Snow wrote:
On 9/9/19 1:18 PM, andychiu via Qemu-devel wrote:
If
Text from "docs/nvdimm.txt" says:
Guest Data Persistence
--
Though QEMU supports multiple types of vNVDIMM backends on Linux,
currently the only one that can guarantee the guest write persistence
is the device DAX on the real NVDIMM device (e.g., /dev/dax0.0), to
501 - 600 of 1350 matches
Mail list logo
