I'm using the ppc-linux-user target to run processes in a Debian
Wheezy filesystem I built using multistrap. I built qemu from
yesterday's head of the git tree.
When I try to run a Python JSON database called jsonstore, I qemu-ppc
barfs with an "Invalid data memory access", with the invalid addres
This fixes "Cannot open audit interface - aborting." when the
EAFNOSUPPORT errno differs between the target and host
architectures (e.g. mips target and x86_64 host).
Signed-off-by: Ed Swierk
---
linux-user/syscall.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
comparison
to fail and resulting in lots of spurious "Unsupported ioctl" errors.
Changing the target_cmd field in the ioctl_entries list to a signed int
causes those values to be sign-extended as well during the comparison.
Signed-off-by: Ed Swierk
---
linux-user/syscall.c | 2 +-
1 file
Without this fix, qemu segfaults when emulating the sigaltstack syscall,
because it incorrectly treats the ss_flags field as 64 bits rather than 32
bits.
Signed-off-by: Ed Swierk
---
linux-user/mips64/target_signal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/linux-user
dn't find out why coreboot did
> that. I assume it was a mistake, and the original code was supposed to
> be reading the DRB[0-7] registers (offsets 0x60-0x67).
>
> Document that coreboot-specific register offset in a macro and a
> comment, for future reference.
>
>
> only need for nonblocking operations.
>
> Signed-off-by: Arnd Bergmann
This works for me.
Acked-by: Ed Swierk
Commit c62313bbdc48f72e93fa8196f2fff96ba35e4e9d seems to have broken
the getfd monitor command in qemu 0.12.
tcp_chr_read() calls tcp_chr_recv(), which checks whether the received
message includes an SCM_RIGHTS header, and if so, stores the received
fd in the CharDriverState struct. tcp_chr_read()
On Mon, Feb 22, 2010 at 12:51 PM, Luiz Capitulino
wrote:
> On Fri, 19 Feb 2010 10:21:41 -0800
> Ed Swierk wrote:
>
>> Commit c62313bbdc48f72e93fa8196f2fff96ba35e4e9d seems to have broken
>> the getfd monitor command in qemu 0.12.
>
> Does it work with current master?
On Mon, Feb 22, 2010 at 12:51 PM, Luiz Capitulino
wrote:
> How do you reproduce it?
Here's a test program that reproduces the problem. Start qemu with
-chardev socket,id=monitor,path=/tmp/qemu-monitor,server,nowait -mon
chardev=monitor,mode=readline
and run check_getfd /tmp/qemu-monitor. It w
r than mapping it from the
full ROM image.
Both of these changes are the result of random hacking rather than any
real understanding of the issues involved. I'd appreciate any better
ideas.
Signed-off-by: Ed Swierk
---
hw/pc.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff
On Thu, Nov 26, 2009 at 9:24 AM, Glauber Costa wrote:
> This is an early version of smp support in kvm that kinda works.
Can you please elaborate on "smp support"? The KVM FAQ makes some
rather broad claims about smp support already:
Does KVM support SMP hosts?
Yes.
Does KVM support SMP g
On Mon, Nov 30, 2009 at 4:31 PM, Ed Swierk wrote:
> On Thu, Nov 26, 2009 at 9:24 AM, Glauber Costa wrote:
>> This is an early version of smp support in kvm that kinda works.
>
> Can you please elaborate on "smp support"? The KVM FAQ makes some
> rather broad claims a
I'm having trouble building OpenHackWare (the firmware for qemu-system-ppc)
from source on a PPC machine running Fedora 6, using either gcc 4.1.1 or gcc
3.4.6. I'm using the source tarball
http://perso.magic.fr/l_indien/OpenHackWare/0.4/OpenHackWare-0.4.1.tar.bz2,
with the patch pc-bios/ohw.dif
On Thursday 19 April 2007 09:58:30 Daniel Jacobowitz wrote:
> I posted some other patches for OpenHackWare when I was experimenting
> with OpenBSD; I think this is the one you need, to the linker script:
>
> -.rodata: { *(.rodata) } > bios
> +.rodata: { *(.rodata*) } > bios
The attached patch addresses a few problems in OpenHackWare:
- The return value from the OpenFirmware read function should not exceed the
actual file size by more than one block; otherwise the Linux kernel's
initramfs routines get confused by the extra junk and reject the initramfs.
- The OpenF
On Wednesday 16 May 2007 14:31:38 H. Peter Anvin wrote:
> As rewritten, it should follow the current version of the Linux boot
> protocol specification and recommendations. As a side benefit, it no
> longer relies on load_linux.S; instead I have a small code generator
> which can be used to set up
On Monday 21 May 2007 03:40:12 Markus Hitter wrote:
> Somewhere in the FAQs, the state of Classic Mac OS ist mentioned as
> "it is being worked on". Is this still true, is it possible to join
> the effort?
I'm not aware of anyone currently working on classic Mac OS support. PowerPC
system emulati
When the USB OHCI controller starts, a periodic end-of-frame routine
writes to a chunk of memory set aside by the device driver. If the
machine reboots or the OS kexecs, the controller continues writing
even though the memory is no longer owned by the device driver,
causing random, mysterious corr
On 7/27/07, David Woodhouse <[EMAIL PROTECTED]> wrote:
> I'm not sure if it's supposed to be able to run yaboot, but it doesn't
> seem to. I've tried running the netboot images (which are just a zImage
> containing kernel+initrd) and I think I had problems with that too --
> but at least that was a
On 8/16/07, Christian MICHON <[EMAIL PROTECTED]> wrote:
> blame it on gmail. this is the default behaviour.
> it's obviously not intended...
At the risk of drifting further off-topic, I'd just point out that you
can press Ctrl-End in the Gmail message window before you type your
reply.
--Ed
On 10/28/07, Rob Landley <[EMAIL PROTECTED]> wrote:
> Hmmm... All the kernels I've built for this project are static. In theory I
> can add "ne.irq=9" to the kernel command line, but in practice it doesn't
> seem to work. Nor does ne.0.irq=9 or irq=9
>
> However, when I hardwire "dev->irq=9;" in
On 6/5/06, René Korthaus <[EMAIL PROTECTED]> wrote:
I researched current qemu cvs and found out that the patch was
integrated not complete but to 95%. There are two lines in slirp/
misc.c that need a change (patch attached). Tested to work with Mac
OS X host and debian guest i could reach the Apa
On 6/25/06, VMiklos <[EMAIL PROTECTED]> wrote:
initrd=initrd-i686.img.gz -> dropped
load_ramdisk=1 -> dropped
prompt_ramdisk=0 -> dropped
ramdisk_size=33888 -> dropped
rw -> kept
root=/dev/ram -> dropped
console=ttyS0 -> kept as you requested
now it panics with:
"RAMDISK: Couldn't find valid RAM
On 6/28/06, Paul Robinson <[EMAIL PROTECTED]> wrote:
How should you pronounce Qemu?
FYI, my best guess is Q (as in the letter Q) followed by the first 2
syllables of emulator.
That's how I've always pronounced it, but I've also heard people say
"kee-moo", which I have to admit is kind of cute.
The attached patch makes two changes needed to boot Linux on qemu with
a large (>256KB) LinuxBIOS image instead of the built-in BIOS:
- Increases the space set aside for the BIOS from 256KB to 2MB; this
could of course be increased further, but 2MB seems to be the largest
EEPROM hardware currentl
Currently qemu's i440FX PCI bridge emulation code does not set the
registers indicating the amount of RAM installed in each DIMM slot.
LinuxBIOS relies on this information to properly set up RAM before
booting Linux.
The attached patch sets a i440FX configuration register indicating the
highest R
Linux 2.6.17 running on the latest qemu snapshot is unable to route
IRQs to more than 4 network interfaces when running without ACPI, and
is limited to 2 network interfaces with ACPI enabled.
With 8 network interfaces and ACPI disabled, I get the following
kernel output during boot:
ne2k-pci.c:v
On 9/14/06, Joseph Miller <[EMAIL PROTECTED]> wrote:
I'm running a terminal server under qemu with kqemu compiled into my kernel
under the -kernel-kqemu for fastest performance. What is the most efficient
method of -net ? I was using -net user with OpenVPN to connect to my
internal LAN, but I h
After spending some time trying to figure out why the emulated UHCI
USB controller is so slow, I switched uhci_usb_init() in hw/pc.c to
ohci_usb_init(). To my delight, Linux booted up and detected the
controller on the first try, and accessing an emulated block device is
2 to 3 times faster.
It s
qemu allows redirecting the monitor to a named pipe (fifo): if you
specify "-monitor pipe:/my/fifo", it opens "/my/fifo" and uses it for
communication in both directions.
Unfortunately pipes are unidirectional on Linux. The pipe(7) man page
says: "Portability notes: On some systems (but not Linux
The attached patch adds SMBus host support to the emulated PIIX4 power
management device (acpi.c), and adds an emulated serial EEPROM device
accessible via the SMBus interface.
I tried to follow the Intel 82371AB spec for the SMBus support; the
interface should be generic enough to implement a va
On 1/23/07, Fabrice Bellard <[EMAIL PROTECTED]> wrote:
OK, but avoid using mmap() in the device code. Moreover, files in the
BIOS directory are not writable.
OK. Would it be better to do the following:
- add a command-line option -seeprom that sets the file to use as
backing store for the smbu
Here's a revised patch with the mmap stuff removed. I'll refine the
persistence support, but in the meantime the EEPROM device is usable
even if it forgets its contents when qemu exits.
--Ed
Index: qemu-0.8.2/hw/acpi.c
===
--- qemu-0
Windows 2000 boots and PC Wizard 2007 displays the following
information under the Mainboard category:
> SMBus/i2c Bus : Yes
>> General Information
Device : 82371AB/EB/MB PIIX4/E/M Power Management Controller
Revision : 0
Frequency : 16 KHz
Address : 0xB100
>> Device
On 1/31/07, Thiemo Seufer <[EMAIL PROTECTED]> wrote:
It doesn't apply for current CVS. Could you please update the patch?
I would also prefer to have enums instead of raw constants in all those
case statements.
Here you go.
--Ed
diff -BurN qemu-snapshot-2007-01-22_05.orig/hw/acpi.c qemu-snapsh
This patch fixes an apparent typo in hw/usb.h.
--Ed
Index: qemu-snapshot-2007-02-02_05/hw/usb.h
===
--- qemu-snapshot-2007-02-02_05.orig/hw/usb.h
+++ qemu-snapshot-2007-02-02_05/hw/usb.h
@@ -164,7 +164,7 @@ struct USBPacket {
US
I'm attempting to boot a Linux disk image with the SYSLINUX boot
loader using the -nographic option. On the latest qemu CVS, the boot
loader hangs before printing "Ready" and booting the kernel. But if I
use the same version of qemu with the BIOS from 0.8.2, it boots just
fine.
For a simple test
On 2/5/07, Ed Swierk <[EMAIL PROTECTED]> wrote:
I'm attempting to boot a Linux disk image with the SYSLINUX boot
loader using the -nographic option. On the latest qemu CVS, the boot
loader hangs before printing "Ready" and booting the kernel. But if I
use the same version
On 2/5/07, Ed Swierk <[EMAIL PROTECTED]> wrote:
I'm attempting to boot a Linux disk image with the SYSLINUX boot
loader using the -nographic option. On the latest qemu CVS, the boot
loader hangs before printing "Ready" and booting the kernel. But if I
use the same version
The latest bochs bios (bochs-20070105 snapshot) seems to fix the
SYSLINUX hanging issue. The bios.bin is attached.
--Ed
bios.bin.bz2
Description: BZip2 compressed data
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/l
On 2/6/07, Ed Swierk <[EMAIL PROTECTED]> wrote:
The latest bochs bios (bochs-20070105 snapshot) seems to fix the
SYSLINUX hanging issue. The bios.bin is attached.
Oops--this is BIOS-bochs-legacy. BIOS-bochs-latest still breaks SYSLINUX.
This change fixes the SYSLINUX hang. Thanks!
--Ed
On 2/8/07, Fabrice Bellard <[EMAIL PROTECTED]> wrote:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard07/02/08 22:17:34
Modified files:
pc-bios: bios.diff bios.bin
Log message:
On 2/9/07, Paul Brook <[EMAIL PROTECTED]> wrote:
I've very little sympathy (read: none) for people who "accidentally" break
things by running them as root.
Sure, but there are plenty of other ways to accidentally mess up the
permissions of a disk image file. A while back I had to strace qemu to
LinuxBIOS writes the IRQ routing table (PIRQ) to 0xf000 and then reads
it back to verify the write. Currently qemu maps the top 128 KB of the
BIOS into ISA address space (0xe000 - 0x) as ROM, which causes the
write to fail, preventing Linux from finding interrupt routing info.
This patch chan
qemu 0.9.0 on Linux crashes with SIGSEGV after read() on a char device
returns 0, which occurs if the char device is a fifo and the writer
closes the file.
In this case, fd_chr_read() and stdio_read() react by removing the IO
handler and freeing it. Unfortunately main_loop_wait() is unprepared
to
On 2/13/07, Ed Swierk <[EMAIL PROTECTED]> wrote:
This patch changes qemu to map the BIOS into ISA address space as RAM
instead of ROM, allowing LinuxBIOS to run on qemu with no further
modifications (although the DRAM size is still not detected properly).
Unfortunately this isn'
On 2/15/07, Thomas Petazzoni <[EMAIL PROTECTED]> wrote:
BTW, is there a reason why a disk image is required when using the
-kernel option ?
In the following case: -kernel vmlinuz -append "nfsroot=blabla", we
could boot over the network, without the need for any disk image, but
Qemu wants to have
Has anyone succeeded in booting a Linux 2.6 kernel on Qemu PPC? If so,
what distribution did you use?
Thanks,
--Ed
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Here is a patch that sets the hostname in the DHCP response generated
by qemu's user-net DHCP server, and adds a new -hostname command line
option to specify the value.
If the guest OS is configured properly, the value received in the DHCP
response is automatically used to set the machine's hostna
Daniel Veillard wrote:
> enclosed is a first version of a patch to allow remote access and control
> for QEmu instances, I'm not suggesting to apply it as is (though it seems
> to work in my limited testing) but would rather like to get comments back
> for choices I'm facing.
This sounds pretty ni
On 3/11/06, Paul Brook <[EMAIL PROTECTED]> wrote:
> This should be set via -net user,hostname=foo. No need for a separate option.
I agree, since the hostname is relevant only for user-net interfaces.
An updated patch is attached.
The only issue is that there's just a single, global hostname, not
I'm still getting a kernel panic running a Linux guest kernel with
-kernel-qemu. I'm using kqemu-1.3.0pre5 and
qemu-snapshot-2006-03-27_23.
The guest kernel is a precompiled Fedora Core 4 kernel, version
2.6.14-1.1656_FC4. It works fine with kqemu in non-kernel-kqemu mode.
Any hints for how to tr
On 3/28/06, Jens Axboe <[EMAIL PROTECTED]> wrote:
> > monitor/mwait feature present.
> > using mwait in idle threads.
>
> [snip]
>
> > invalid operand: [#1]
> > Modules linked in:
> > CPU:0
> > EIP:0060:[]Not tainted VLI
> > EFLAGS: 00010246 (2.6.14-1.1656_FC4)
> > EIP is at mwai
Currently the user-level networking (slirp) code in qemu uses subnet
10.0.2.0/24. Changing this hardcoded value, which can be desirable if
that subnet is already used for other purposes, requires recompiling
qemu.
The attached patch makes the subnet configurable on the command line
via a new "subn
On 4/28/06, Ben Dailey <[EMAIL PROTECTED]> wrote:
After much searching I believe I have found a problem with the bochs
bios in cvs. I found that I was not able to boot the fedora core 5 or 4
or 3 rescue cds or the Fedora 4 image from free.oszoo.org. Fedora core 2
booted correctly as well as Windo
On 4/28/06, Fabrice Bellard <[EMAIL PROTECTED]> wrote:
The bug comes from the APM CPU idle function added in the Bochs BIOS. I
am about to commit a fix.
The fixed BIOS works fine. Thanks!
--Ed
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://
A couple of serious problems remain in the slirp redirection code
after the patch Paul applied on 23 April.
* If the IP address returned by gethostbyname(gethostname()) is the
address of one of the host's Ethernet interfaces, bringing down that
interface or changing its IP address disrupts redir
The attached patch fixes a bug in the slirp memory management code.
m_inc() is called during IP reassembly for IP datagrams greater than 4
KB, as arises with NFS. Currently the code assumes that realloc()
always resizes the buffer without moving it; if the buffer is moved,
the m_data pointer is le
Another memory management bug in the slirp code causes qemu to crash
while attempting to reassemble a fragmented IP packet. While iterating
through a list of buffers, if m_cat() moves the current buffer, the
pointer to the next buffer is read from an invalid location.
The attached patch simply re
In several places in qemu's slirp code, signed and unsigned ints are
used interchangeably when dealing with IP packet lengths and offsets.
This causes IP packets greater than 32K in length to be scrambled in
various interesting ways that are extremely difficult to troubleshoot.
Although large IP
Three bugs in the slirp code have an enormous adverse effect on
networking performance.
1. The maximum TCP segment size for data flowing from the VM to the
host is unnecessarily limited to 512 bytes. 1460 bytes is the
appropriate value for Ethernet.
2. TCP acknowledgements are being delayed unne
A bug in console.c causes heap corruption when qemu is started without
a graphical console (-nographic). In this case, the console height and
width are both 0, resulting in allocation of a zero-length cells
array.
Heap corruption is caused by code that assumes the cells array always
has at least
The qemu -kernel option currently requires specifying a hard disk
image with -hda. Ostensibly at least one hard disk is needed for
qemu's boot loader to populate the partition table in its array of
boot sectors.
Passing -hda /dev/zero tricks qemu into booting, which demonstrates
that the requirem
qemu fails to boot recent releases of Fedora Core with the
-kernel/-initrd options, since the kernel is large enough to overrun
the space allocated to it by qemu's built-in bootloader.
The attached patch simply moves the base address of the initrd to a
higher location, which allows sufficient spa
qemu hangs when an i386 Linux host resumes from suspend (swsusp2),
because the host's TSC is reset to a value lower than it was before
the suspend.
Although this is a bug in the host OS, the attached patch (originally
from John Coiner) is simple and makes qemu more resilient to weird
host tick co
On 5/1/06, Fabrice Bellard <[EMAIL PROTECTED]> wrote:
I am not sure this patch is sufficient: sometimes our_addr is used to
open socket on the host side and 10.0.2.2 has a meanning only on the VM
side.
Indeed, our_addr seems to be used for two distinct purposes:
- application protocol emulatio
On 5/1/06, Fabrice Bellard <[EMAIL PROTECTED]> wrote:
Why not changing the definition itself to uint16_t and verifying each
occurence of ip_off and ip_len ?
Indeed, why not. This is the solution adopted by Apple's OpenDarwin
(another BSD derivative). The attached patch changes the signed
defini
On 5/1/06, Ben Taylor <[EMAIL PROTECTED]> wrote:
Am I seeing a problem in line 98 of slirp/misc.c?
Yes--thanks for finding that.
An amended patch is attached.
--Ed
diff -BurN qemu.orig/slirp/ip_icmp.c qemu/slirp/ip_icmp.c
--- qemu.orig/slirp/ip_icmp.c 2004-04-22 00:10:47.0 +
+++ q
In environments where the 10.0.2.0/24 subnet is already used for
another purpose, it's useful to be able to configure a different -net
user (slirp) subnet, such as 192.168.100.0/24.
The attached patch adds a subnet option to -user net. Currently only
/24 subnets (mask 255.255.255.0) are accepted.
It's not clear to me why it works, or if it's just papering
over a bug elsewhere, or if there are any possible side effects.
Suggested-by: Andrew Jones
Signed-off-by: Ed Swierk
diff --git a/hw/net/e1000.c b/hw/net/e1000.c
index 6eac66d..c891b67 100644
--- a/hw/net/e1000.c
+++ b/hw/n
On Thu, Sep 15, 2016 at 2:15 AM, Denis V. Lunev wrote:
> On 09/13/2016 11:59 PM, Konrad Rzeszutek Wilk wrote:
> > On Thu, Sep 01, 2016 at 10:57:48AM -0700, Ed Swierk wrote:
> >> Windows 8, 10 and Server 2012 guests hang intermittently while booting
> >> on Xen 4.5.3 wi
I'm wondering what it will take to finish up work on vmgenid.
https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg05599.html
It appears all of the designs explored through the 19 iterations were
problematic in some way. Is any of them vaguely acceptable to all
involved in the discussions? Or
e and cluster size. The resulting
default cache size is just large enough to service random accesses in
the entire image.
Signed-off-by: Ed Swierk
---
block/qcow2.c | 5 ++---
block/qcow2.h | 4
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index 91
On Tue, Oct 4, 2016 at 7:31 AM, Alberto Garcia wrote:
> That might be a lot of memory if the image is big. 1 TB qcow2 image ==
> 128 MB L2 cache.
>
> See https://bugzilla.redhat.com/show_bug.cgi?id=1377735#c2
>
> If we want to add this feature, I think I'd rather make it explicit.
I agree explici
r the entire virtual disk.
Signed-off-by: Ed Swierk
---
block/qcow2.c| 16 +---
docs/qcow2-cache.txt | 10 --
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index 91ef4df..6f3a6ed 100644
--- a/block/qcow2.c
+++ b/block/qc
On Thu, Sep 15, 2016 at 5:36 PM, Michael S. Tsirkin wrote:
> On Thu, Sep 15, 2016 at 05:23:28PM -0700, Ed Swierk wrote:
>> I'm wondering what it will take to finish up work on vmgenid.
>>
>> https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg05599.html
>
> W
On Fri, Oct 7, 2016 at 6:46 AM, Frank Myhr wrote:
> On 10/07/2016 06:56 AM, Alberto Garcia wrote:
>>
>> I would like to know what's the use case you (Frank, Ed)
>> are thinking about:
>
>
>> - Are we talking about command-line options, QMP, or both?
>
>
> Command-line options alone are sufficient
Shortly after I start qemu 2.7.0 with a qcow2 disk image created with
-o cluster_size=1048576, it prints the following and dies:
block/qcow2.c:2451: qcow2_co_pwrite_zeroes: Assertion `head + count <=
s->cluster_size' failed.
I narrowed the problem to bdrv_co_do_pwrite_zeroes(), called by
bdrv_ali
On Thu, Oct 20, 2016 at 6:38 PM, Eric Blake wrote:
> On 10/20/2016 07:24 PM, Ed Swierk wrote:
>> Changing max_transfer in the normal write case to
>> MIN_NON_ZERO(alignment, MAX_WRITE_ZEROES_BOUNCE_BUFFER) appears to fix
>> the problem, but I don't pretend to understand
On Mon, Oct 24, 2016 at 2:21 PM, Eric Blake wrote:
> How are you getting max_transfer == 65536? I can't reproduce it with
> the following setup:
>
> $ qemu-img create -f qcow2 -o cluster_size=1M file 10M
> $ qemu-io -f qcow2 -c 'w 7m 1k' file
> $ qemu-io -f qcow2 -c 'w -z 8003584 2093056' file
>
Interactive access to a guest serial console can be enabled by hooking
the serial device to a pty backend, e.g. -device
isa-serial,chardev=cs0 -chardev pty,id=cs0. With libvirt this can be
configured via .
Output from the same serial device can also be logged to a file by
adding logfile=/somefile
On Fri, Jan 27, 2017 at 1:40 AM, Daniel P. Berrange wrote:
> On Thu, Jan 26, 2017 at 05:07:16PM -0800, Ed Swierk wrote:
>> Currently qemu_chr_fe_write() calls qemu_chr_fe_write_log() only for
>> data consumed by the backend chr_write function. With the pty backend,
>> pty_
lient like virsh console happens to be
connected.
Signed-off-by: Ed Swierk
---
qemu-char.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qemu-char.c b/qemu-char.c
index 676944a..ccb6923 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1528,7 +1528,7 @@ static int pty_chr_
On Tue, Jan 31, 2017 at 7:34 AM, Paolo Bonzini wrote:
>
>
> On 31/01/2017 04:39, Daniel P. Berrange wrote:
>> I don't think so - retrying in this way is pointless IMHO - it is just
>> going to get the same result on every retry on 99% of occassions.
>
> Just to provide the full context, the retry
On Tue, Jan 31, 2017 at 6:06 AM, Marc-André Lureau wrote:
> I think this can be confusing if some backends silently drop the data (under
> disconnected state), while other don't. Perhaps we should have instead a new
> common chardev property "hup-drop" ? (suggestions for better name welcome)
Ei
Recently I noticed that when I configure a virtio-scsi-pci device
using an iothread, as soon as the guest virtio-scsi driver loads, the
iothread spins at 100%:
-object iothread,id=iothread1 -device virtio-scsi-pci,iothread=iothread1
This occurs whether or not a disk is attached, with either
pol
On Wed, Feb 8, 2017 at 8:33 AM, Ed Swierk wrote:
> Recently I noticed that when I configure a virtio-scsi-pci device
> using an iothread, as soon as the guest virtio-scsi driver loads, the
> iothread spins at 100%:
>
> -object iothread,id=iothread1 -device virtio-scsi-pci,iot
On Wed, Feb 8, 2017 at 5:47 PM, Fam Zheng wrote:
> No, something is wrong. The polling shouldn't keep running when there is no
> I/O
> activity.
>
> Can you try "perf top" to see what poll handlers are spinning?
Samples: 288K of event 'cycles', Event count (approx.): 57149970643
Overhead Shared
On Wed, Feb 8, 2017 at 6:52 PM, Fam Zheng wrote:
> This means virtio-scsi event vq handler is returning true but actually no
> progress is made. Can you try the following patch to see if it's because a
> stalled cache of VQ index?
>
> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> index 63
On Thu, Feb 9, 2017 at 2:12 AM, Fam Zheng wrote:
> This should fix it:
>
> https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg01874.html
I tested this patch and found it fixes the problem. Thanks for the
speedy response!
--Ed
ing. As a result aio_poll() will spin on
> the "non-empty" VQ and take 100% host CPU.
>
> Fix this by reporting actual progress from virtio queue aio handlers.
>
> Reported-by: Ed Swierk
> Signed-off-by: Fam Zheng
Tested-by: Ed Swierk
> ---
> hw/block/dataplane/vir
e_*_vq to
> their callers - and wrap the broken assertions in.
>
> Signed-off-by: Fam Zheng
Verified this fixes the assertion failure on 2.9.0-rc0.
Tested-by: Ed Swierk
On Tue, Mar 14, 2017 at 8:36 AM, Fam Zheng wrote:
> diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
> index e7466d3..4939f1f 100644
> --- a/hw/scsi/virtio-scsi.c
> +++ b/hw/scsi/virtio-scsi.c
> ...
> bool virtio_scsi_handle_event_vq(VirtIOSCSI *s, VirtQueue *vq)
> {
> -virtio_scsi
On Tue, Mar 14, 2017 at 8:36 AM, Fam Zheng wrote:
> After the AioContext lock push down, there is a race between
> virtio_scsi_dataplane_start and those "assert(s->ctx &&
> s->dataplane_started)", because the latter doesn't isn't wrapped in
> aio_context_acquire.
>
> Reproducer is simply booting a
On Mar 16, 2017 23:02, "Fam Zheng" wrote:
On Thu, 03/16 17:26, Ed Swierk wrote:
> On Tue, Mar 14, 2017 at 8:36 AM, Fam Zheng wrote:
> > After the AioContext lock push down, there is a race between
> > virtio_scsi_dataplane_start and those "assert(s->ctx &
sable_cnt > 0' failed.
whereas without the iothread the assertion failure does not occur.
--Ed
On Thu, Mar 16, 2017 at 5:26 PM, Ed Swierk wrote:
> With this change on top of 2.9.0-rc0, I am able to boot a Linux guest
> from a virtio-scsi drive with an iothread, e.g.
>
> qemu-sys
On Fri, Mar 17, 2017 at 10:15 AM, Paolo Bonzini wrote:
>
>
> On 17/03/2017 18:11, Paolo Bonzini wrote:
>>
>>
>> On 17/03/2017 17:55, Ed Swierk wrote:
>>> I'm running into the same problem taking an external snapshot with a
>>> virtio-blk drive
On Fri, Mar 17, 2017 at 12:27 PM, Paolo Bonzini wrote:
> And this is a fix, but I have no idea why/how it works and what else it
> may break.
>
> Patches 1 and 2 are pretty obvious and would be the first step towards
> eliminating aio_disable/enable_external altogether.
>
> However I got patch 3 m
t;I’m well on my way to implementing this, but I am really new to the
>> >>QEMU code base and am struggling with some concepts. Please see
>> >> below:
>> >>
>> >>On Oct 5, 2016, at 6:29 PM, Michael S. Tsirkin
>> >>
&g
code to read out the new fw cfg.
> Thus guest can not reliably detect that host didn't update the gen id -
> new one might be there in fw cfg but not yet read.
>
> RSDP never changes during guest lifetime so the issue does
> not occur.
>
> On Tue, Jan 17, 2017 at 06:26:57AM
1 - 100 of 132 matches
Mail list logo
