[Qemu-devel] [PATCH v2] Add -netdev to man page
There's missing -netdev description in the man page for qemu. As this is
recommended way to create network backend, lack of documentation can discourage
its usage.
Signed-off-by: Miroslav Rezanina
V2:
- Fixed spelling errors
- Fixed net and dhcpstart range values
Patch:
-
diff --git a/qemu-options.hx b/qemu-options.hx
index b129996..666fd58 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1292,6 +1292,275 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev,
#endif
"socket],id=str[,option][,option][,...]\n", QEMU_ARCH_ALL)
STEXI
+@item -netdev user|tap|vde|socket,id=@var{str}[,option][,option][,...]
+
+Create a new network backend. The backend's @option{id} can be used with
+the @option{-device} option to connect a backend with a device, e.g.
+
+@example
+-netdev user,id=mynet -device e1000,netdev=mynet
+@end example
+
+You can use following types of backend:
+
+@table @option
+
+@item -netdev user
+
+User networking is default network backend. This backend does not require root
+privileges, does not allow ICMP traffic, and guest is not directly accessible
+from the host or the external network.
+
+Valid options are:
+
+@table @option
+
+@item restrict=on|off
+If this option is enabled, the guest will be isolated, i.e. it will not be
+able to contact the host and no guest IP packets will be routed over the host
+to the outside. This option does not affect explicitly set forwarding rules.
+
+@item net=@var{addr}[/@var{mask}]
+Set the IP network address the guest will see. Optionally specify the netmask,
+either in the form a.b.c.d or as number of valid top-most bits. Default is
+10.0.2.0/24.
+
+@item host=@var{addr}
+Specify the guest-visible address of the host. Default is the 2nd IP in the
+guest network, i.e. x.x.x.2.
+
+@item hostname=@var{name}
+Specifies the client hostname reported by the builtin DHCP server.
+
+@item dhcpstart=@var{addr}
+Specify the first of the 16 IPs the built-in DHCP server can assign. Default
+is the 15th to 30st IP in the guest network, i.e. x.x.x.15 to x.x.x.30.
+
+@item dns=@var{addr}
+Specify the guest-visible address of the virtual nameserver. The address must
+be different from the host address. Default is the 3rd IP in the guest network,
+i.e. x.x.x.3.
+
+@item tftp=@var{dir}
+When using the user mode network stack, activate a built-in TFTP
+server. The files in @var{dir} will be exposed as the root of a TFTP server.
+The TFTP client on the guest must be configured in binary mode (use the command
+@code{bin} of the Unix TFTP client).
+
+@item bootfile=@var{file}
+When using the user mode network stack, broadcast @var{file} as the BOOTP
+filename. In conjunction with @option{tftp}, this can be used to network boot
+a guest from a local directory.
+
+Example (using pxelinux):
+@example
+qemu -hda linux.img -boot n -netdev
user,id=netid,tftp=/path/to/tftp/files,bootfile=/pxelinux.0
+@end example
+
+@item smb=@var{dir}[,smbserver=@var{addr}]
+When using the user mode network stack, activate a built-in SMB
+server so that Windows OSes can access to the host files in @file{@var{dir}}
+transparently. The IP address of the SMB server can be set to @var{addr}. By
+default the 4th IP in the guest network is used, i.e. x.x.x.4.
+
+In the guest Windows OS, the line:
+@example
+10.0.2.4 smbserver
+@end example
+must be added in the file @file{C:\WINDOWS\LMHOSTS} (for windows 9x/Me)
+or @file{C:\WINNT\SYSTEM32\DRIVERS\ETC\LMHOSTS} (Windows NT/2000).
+
+Then @file{@var{dir}} can be accessed in @file{\\smbserver\qemu}.
+
+Note that a SAMBA server must be installed on the host OS in
+@file{/usr/sbin/smbd}. QEMU was tested successfully with smbd versions from
+Red Hat 9, Fedora Core 3 and OpenSUSE 11.x.
+
+@item
hostfwd=[tcp|udp]:[@var{hostaddr}]:@var{hostport}-[@var{guestaddr}]:@var{guestport}
+Redirect incoming TCP or UDP connections to the host port @var{hostport} to
+the guest IP address @var{guestaddr} on guest port @var{guestport}. If
+@var{guestaddr} is not specified, its value is x.x.x.15 (default first address
+given by the built-in DHCP server). By specifying @var{hostaddr}, the rule can
+be bound to a specific host interface. If no connection type is set, TCP is
+used. This option can be given multiple times.
+
+For example, to redirect host X11 connection from screen 1 to guest
+screen 0, use the following:
+
+@example
+# on the host
+qemu -netdev user,id=netid,hostfwd=tcp:127.0.0.1:6001-:6000 [...]
+# this host xterm should open in the guest X11 server
+xterm -display :1
+@end example
+
+To redirect telnet connections from host port to telnet port on
+the guest, use the following:
+
+@example
+# on the host
+qemu -netdev user,id=netid,hostfwd=tcp:::23 [...]
+telnet localhost
+@end example
+
+Then when you use on the host @code{telnet localhost }, you
+connect to the guest telnet server.
+
+@item guestfwd=[tcp]:@var{server}:@var{port}-@var{dev}
+Forward guest TCP connections to the IP address @var{server} on port @var{port}
+to the character
[Qemu-devel] [PATCH] target-mips: Fix some helper functions (VR54xx multiplication)
Commits b5dc7732e1cc2fb549e48b7b5d664f2c79628e2e and
be24bb4f3007c3e07cbf1934f7e781493d876ab7 optimized the code
and removed the correct setting of t0. Fix this.
gcc-4.7 detected this bug because parameter arg1 was unused
but set in set_HIT0_LO and set_HI_LOT0.
Cc: Aurelien Jarno
Signed-off-by: Stefan Weil
---
Is anybody using QEMU with MIPS VR5432 code which uses the
special multiply opcodes? I don't have such code, so I could
not test my patch.
Regards,
Stefan Weil
target-mips/op_helper.c | 75 ++
1 files changed, 29 insertions(+), 46 deletions(-)
diff --git a/target-mips/op_helper.c b/target-mips/op_helper.c
index c51b9cb..8556c17 100644
--- a/target-mips/op_helper.c
+++ b/target-mips/op_helper.c
@@ -199,115 +199,98 @@ static inline void set_HILO (uint64_t HILO)
env->active_tc.HI[0] = (int32_t)(HILO >> 32);
}
-static inline void set_HIT0_LO (target_ulong arg1, uint64_t HILO)
+static inline target_ulong set_HIT0_LO(uint64_t HILO)
{
+target_ulong tmp;
env->active_tc.LO[0] = (int32_t)(HILO & 0x);
-arg1 = env->active_tc.HI[0] = (int32_t)(HILO >> 32);
+tmp = env->active_tc.HI[0] = (int32_t)(HILO >> 32);
+return tmp;
}
-static inline void set_HI_LOT0 (target_ulong arg1, uint64_t HILO)
+static inline target_ulong set_HI_LOT0(uint64_t HILO)
{
-arg1 = env->active_tc.LO[0] = (int32_t)(HILO & 0x);
+target_ulong tmp = env->active_tc.LO[0] = (int32_t)(HILO & 0x);
env->active_tc.HI[0] = (int32_t)(HILO >> 32);
+return tmp;
}
/* Multiplication variants of the vr54xx. */
target_ulong helper_muls (target_ulong arg1, target_ulong arg2)
{
-set_HI_LOT0(arg1, 0 - ((int64_t)(int32_t)arg1 * (int64_t)(int32_t)arg2));
-
-return arg1;
+return set_HI_LOT0(0 - ((int64_t)(int32_t)arg1 * (int64_t)(int32_t)arg2));
}
target_ulong helper_mulsu (target_ulong arg1, target_ulong arg2)
{
-set_HI_LOT0(arg1, 0 - ((uint64_t)(uint32_t)arg1 *
(uint64_t)(uint32_t)arg2));
-
-return arg1;
+return set_HI_LOT0(0 - (uint64_t)(uint32_t)arg1 *
(uint64_t)(uint32_t)arg2);
}
target_ulong helper_macc (target_ulong arg1, target_ulong arg2)
{
-set_HI_LOT0(arg1, ((int64_t)get_HILO()) + ((int64_t)(int32_t)arg1 *
(int64_t)(int32_t)arg2));
-
-return arg1;
+return set_HI_LOT0((int64_t)get_HILO() + (int64_t)(int32_t)arg1 *
+ (int64_t)(int32_t)arg2);
}
target_ulong helper_macchi (target_ulong arg1, target_ulong arg2)
{
-set_HIT0_LO(arg1, ((int64_t)get_HILO()) + ((int64_t)(int32_t)arg1 *
(int64_t)(int32_t)arg2));
-
-return arg1;
+return set_HIT0_LO((int64_t)get_HILO() + (int64_t)(int32_t)arg1 *
+ (int64_t)(int32_t)arg2);
}
target_ulong helper_maccu (target_ulong arg1, target_ulong arg2)
{
-set_HI_LOT0(arg1, ((uint64_t)get_HILO()) + ((uint64_t)(uint32_t)arg1 *
(uint64_t)(uint32_t)arg2));
-
-return arg1;
+return set_HI_LOT0((uint64_t)get_HILO() + (uint64_t)(uint32_t)arg1 *
+ (uint64_t)(uint32_t)arg2);
}
target_ulong helper_macchiu (target_ulong arg1, target_ulong arg2)
{
-set_HIT0_LO(arg1, ((uint64_t)get_HILO()) + ((uint64_t)(uint32_t)arg1 *
(uint64_t)(uint32_t)arg2));
-
-return arg1;
+return set_HIT0_LO((uint64_t)get_HILO() + (uint64_t)(uint32_t)arg1 *
+ (uint64_t)(uint32_t)arg2);
}
target_ulong helper_msac (target_ulong arg1, target_ulong arg2)
{
-set_HI_LOT0(arg1, ((int64_t)get_HILO()) - ((int64_t)(int32_t)arg1 *
(int64_t)(int32_t)arg2));
-
-return arg1;
+return set_HI_LOT0((int64_t)get_HILO() - (int64_t)(int32_t)arg1 *
+ (int64_t)(int32_t)arg2);
}
target_ulong helper_msachi (target_ulong arg1, target_ulong arg2)
{
-set_HIT0_LO(arg1, ((int64_t)get_HILO()) - ((int64_t)(int32_t)arg1 *
(int64_t)(int32_t)arg2));
-
-return arg1;
+return set_HIT0_LO((int64_t)get_HILO() - (int64_t)(int32_t)arg1 *
+ (int64_t)(int32_t)arg2);
}
target_ulong helper_msacu (target_ulong arg1, target_ulong arg2)
{
-set_HI_LOT0(arg1, ((uint64_t)get_HILO()) - ((uint64_t)(uint32_t)arg1 *
(uint64_t)(uint32_t)arg2));
-
-return arg1;
+return set_HI_LOT0((uint64_t)get_HILO() - (uint64_t)(uint32_t)arg1 *
+ (uint64_t)(uint32_t)arg2);
}
target_ulong helper_msachiu (target_ulong arg1, target_ulong arg2)
{
-set_HIT0_LO(arg1, ((uint64_t)get_HILO()) - ((uint64_t)(uint32_t)arg1 *
(uint64_t)(uint32_t)arg2));
-
-return arg1;
+return set_HIT0_LO((uint64_t)get_HILO() - (uint64_t)(uint32_t)arg1 *
+ (uint64_t)(uint32_t)arg2);
}
target_ulong helper_mulhi (target_ulong arg1, target_ulong arg2)
{
-set_HIT0_LO(arg1, (int64_t)(int32_t)arg1 * (int64_t)(int32_t
[Qemu-devel] KVM/QEMU: Support executing from flash device
On Tue, Oct 25, 2011 at 00:47, Avi Kivity wrote: > The core issue that kvm (the kernel part) supports two styles of memory: > read/write RAM, and read/write MMIO. ROM wants writes to be ignored, > and rom/device wants reads serviced from memory and writes serviced by > userspace (as MMIO). > > It should not be too hard to patch kvm to support these additional two > styles. The entry point is the KVM_SET_USER_MEMORY_REGION ioctl to > define the new attributes for the region, and kvm_mmu_page_fault() to > map these pages as read-only and emulate writes (for ROM/device regions). Additional context for CC'd kvm-devel: I would like to support executing from an emulated flash memory on kvm. The flash memory would be a CFI (Firmware Hub-like) device which is programmed via MMIO at the same addresses in memory where the execution would occur. What is needed is: 1. The ability to set a region to allow read/exec, but trap to qemu on writes. 2. qemu should then be able to set the region to trap on reads/exec/writes. 3. qemu should be able to then restore the region to the initial state. Here is my plan: 1. Add KVM_CAP_REGION_WRITE_TRAP 2. Add kvm_memory_region::flags KVM_MEMSLOT_TRAP_WRITES 3. Update page table creation to trap on writes when KVM_MEMSLOT_TRAP_WRITES is set Is this plan heading in the right direction? Regarding emulating ROM (as you mentioned above): I think that it can trap to qemu and QEMU can ignore it. This would be a performance hit, but I don't think it is expected that lots of writes to a ROM will occur. Do you agree? -Jordan
Re: [Qemu-devel] BlockDriverState stack and BlockListeners
On 03/03/2012 13:46, Stefan Hajnoczi wrote: On Wed, Feb 29, 2012 at 8:38 AM, Ori Mamluk wrote: I think the BlockFilter direction goes very well with our plans for a replication module. I guess it would take some discussions and time to form a solid layer for the BlockFilters, and I'd like to move ahead in parallel with the replication module. Will the replicatoin module still use a custom network protocol or do you plan to implement the in-process NBD server? I have added the in-process NBD server idea to the Google Summer of Code 2012 project ideas page. Perhaps students will be interested in implementing it this summer. But if you are already working on it I can remove the idea, please let me know. Thanks, Stefan I prefer not to do it as NBD server, mainly because NBD by definition requires a port per volume and I think it will pose a management overhead. So my current plan is a custom protocol - but it's still TBD.
Re: [Qemu-devel] IRQ number, interrupt number, interrupt line & GPIO[in/out]
On Sun, Mar 4, 2012 at 1:12 AM, Peter Maydell wrote: > 2012/3/3 Zhi Yong Wu : >> thanks a lot for your help, they are very in theory.:). actually these >> concepts all exist in QEMU. I would like to know how they work >> together. > > It's a mess. qemu_irq is the most fundamental data type we > use to model a general 'pin' or 'signal' line; despite the name > it can be used for other things besides interrupt lines, like > general purpose I/O. This is used by basically all devices. > > The base class Device for all devices implemented using the > QEMU Object Model provides a number of qdev_* functions for > registering and manipulating input and output I/O lines, > eg qdev_get_gpio_in and qdev_connect_gpio_out. These are > written in terms of the basic qemu_irq type. Despite the > 'gpio' name, you can use these for interrupt lines if you want. > > The SysBus class (used for a lot of devices which are really > just trying to provide memory-mapped I/O and some interrupt > or signal lines) also provides an abstraction of qemu_irq > (functions sysbus_connect_irq(), sysbus_init_irq(), etc). > Again, there's no reason you can't use these for other > purposes than interrupts, although since every SysBus device > is also a Device, mostly by convention the sysbus abstraction > is used for the real outbound interrupt lines and the Device > gpio abstraction for everything else. > > My opinion is that we should clean this up as part of properly > converting to the new object model. In particular SysBus should > just disappear and all Devices should be able to export named > input and output signals, which can be used for interrupts > or general I/O or whatever. Unfortunately we're probably > stuck with the incredibly badly named 'qemu_irq' type for the > rest of eternity... thanks > > -- PMM -- Regards, Zhi Yong Wu
[Qemu-devel] [Bug 946043] [NEW] Serial Named Pipe Unrecognized Windows 7
Public bug reported: I created a named pipe serial hardware and supplied '/tmp/debug' which I created using mkfifo This is the snippet from ps -aux -chardev pipe,id=charserial0,path=/tmp/debug -device isa-serial,chardev=charserial0,id=serial0 failure@ubuntu1:~$ ls -al /tmp/debug* prwxrwxrwx 1 jgp jgp 0 2012-03-03 18:40 /tmp/debug prwxrwxrwx 1 jgp jgp 0 2012-03-03 18:40 /tmp/debug.in However inside the Windows 7 guest (even after a restart) nothing is recognized. Even after going through the add legacy hardware motions it's still not picked up. ** Affects: qemu Importance: Undecided Status: New ** Tags: kvm serial windows -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/946043 Title: Serial Named Pipe Unrecognized Windows 7 Status in QEMU: New Bug description: I created a named pipe serial hardware and supplied '/tmp/debug' which I created using mkfifo This is the snippet from ps -aux -chardev pipe,id=charserial0,path=/tmp/debug -device isa-serial,chardev=charserial0,id=serial0 failure@ubuntu1:~$ ls -al /tmp/debug* prwxrwxrwx 1 jgp jgp 0 2012-03-03 18:40 /tmp/debug prwxrwxrwx 1 jgp jgp 0 2012-03-03 18:40 /tmp/debug.in However inside the Windows 7 guest (even after a restart) nothing is recognized. Even after going through the add legacy hardware motions it's still not picked up. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/946043/+subscriptions
[Qemu-devel] [PATCH] linux-user: resolve reserved_va vma downwards
After consulting with Paul Brook, we concluded that it's best to search
the VMA space downwards, so that we don't even get the chance to conflict
with the brk range.
This patch resolves a bunch of allocation conflicts when using -R.
Signed-off-by: Alexander Graf
---
This replaces the other patches I sent out earlier today.
---
linux-user/main.c |1 +
linux-user/mmap.c | 35 ---
linux-user/qemu.h |1 +
3 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/linux-user/main.c b/linux-user/main.c
index 6a5dfde..d61d731 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -3437,6 +3437,7 @@ int main(int argc, char **argv, char **envp)
guest_base = HOST_PAGE_ALIGN((unsigned long)p);
}
qemu_log("Reserved 0x%lx bytes of guest address space\n", reserved_va);
+mmap_next_start = reserved_va;
}
if (reserved_va || have_guest_base) {
diff --git a/linux-user/mmap.c b/linux-user/mmap.c
index e4db455..2620f88 100644
--- a/linux-user/mmap.c
+++ b/linux-user/mmap.c
@@ -212,7 +212,7 @@ static int mmap_frag(abi_ulong real_start,
#else
# define TASK_UNMAPPED_BASE 0x1800
#endif
-static abi_ulong mmap_next_start = TASK_UNMAPPED_BASE;
+abi_ulong mmap_next_start = TASK_UNMAPPED_BASE;
unsigned long last_brk;
@@ -222,7 +222,7 @@ unsigned long last_brk;
static abi_ulong mmap_find_vma_reserved(abi_ulong start, abi_ulong size)
{
abi_ulong addr;
-abi_ulong last_addr;
+abi_ulong end_addr;
int prot;
int looped = 0;
@@ -230,25 +230,38 @@ static abi_ulong mmap_find_vma_reserved(abi_ulong start,
abi_ulong size)
return (abi_ulong)-1;
}
-last_addr = start;
-for (addr = start; last_addr + size != addr; addr += qemu_host_page_size) {
-if (last_addr + size >= RESERVED_VA
-|| (abi_ulong)(last_addr + size) < last_addr) {
+size = HOST_PAGE_ALIGN(size);
+end_addr = start + size;
+if (end_addr > RESERVED_VA) {
+end_addr = RESERVED_VA;
+}
+addr = end_addr - qemu_host_page_size;
+
+while (1) {
+if (addr > end_addr) {
if (looped) {
return (abi_ulong)-1;
}
-last_addr = qemu_host_page_size;
-addr = 0;
+end_addr = RESERVED_VA;
+addr = end_addr - qemu_host_page_size;
looped = 1;
continue;
}
prot = page_get_flags(addr);
if (prot) {
-last_addr = addr + qemu_host_page_size;
+end_addr = addr;
+}
+if (addr + size == end_addr) {
+break;
}
+addr -= qemu_host_page_size;
+}
+
+if (start == mmap_next_start) {
+mmap_next_start = addr;
}
-mmap_next_start = addr;
-return last_addr;
+
+return addr;
}
#endif
diff --git a/linux-user/qemu.h b/linux-user/qemu.h
index aa06acf..5dc0720 100644
--- a/linux-user/qemu.h
+++ b/linux-user/qemu.h
@@ -254,6 +254,7 @@ abi_long target_mremap(abi_ulong old_addr, abi_ulong
old_size,
abi_ulong new_addr);
int target_msync(abi_ulong start, abi_ulong len, int flags);
extern unsigned long last_brk;
+extern abi_ulong mmap_next_start;
void mmap_lock(void);
void mmap_unlock(void);
abi_ulong mmap_find_vma(abi_ulong, abi_ulong);
--
1.6.0.2
[Qemu-devel] NBD broken ?
Hi, since commit ae255e523, qemu with NBD hangs at startup (when it tries to access the disk): commit ae255e523c256cf0708f1c16cb946ff96340a800 Author: Paolo Bonzini Date: Thu Sep 8 14:28:59 2011 +0200 nbd: switch to asynchronous operation Signed-off-by: Paolo Bonzini Reverting this patch corrects the problem. My system is an Ubuntu 11.04 x86_64 (But the bug is also seen on RHEL6). qemu is configured only with "--target-list=x86_64-softmmu". My test case is: ./qemu-nbd -k /tmp/nbd-socket -t /ISO/ubuntu-11.04-desktop-i386.iso ./x86_64-softmmu/qemu-system-x86_64 -cdrom nbd:unix:/tmp/nbd-socket Same problem with a TCP socket, with/without KVM, with an x86_64 guest, with -hda... Regards, Laurent
Re: [Qemu-devel] [PATCH] linux-user: guard mmap_next_start from specific maps
> If the guest process tells us to map at a specific address, we shouldn't
> increase the "last automatic mapping ended here" variable.
That sounds reasonable, in fact I'd go further. Tests on an x86-linux machine
(both 32-bit and 64-bit userspace) show that if the requested address is not
available then it is completely ignored.
> +if (start == mmap_next_start && addr >= TASK_UNMAPPED_BASE) {
> +mmap_next_start = addr;
Code does not match description.
Paul
Re: [Qemu-devel] [PATCH] linux-user: map at TARGET_UNMAPPED_BASE with reserved_va
> When mmap()'ing memory somewhere where it's not allowed, we should not > default to the "next free page" which could be right after brk()'ed memory, > but rather at TARGET_UNMAPPED_BASE, which ensures that brk() can extend its > space later on. NACK, As discussed on IRC. Effectively prevents mmap from allocating below TARGET_UNMAPPED_BASE. This wastes a lot of perfectly good address space. With small -R values it leaves mmap with no usable virtual address space. Paul
[Qemu-devel] [PATCH v2] linux-user: map at TARGET_UNMAPPED_BASE with reserved_va
When mmap()'ing memory somewhere where it's not allowed, we should not
default to the "next free page" which could be right after brk()'ed memory,
but rather at TARGET_UNMAPPED_BASE, which ensures that brk() can extend its
space later on.
Reported-by: Bernhard M. Wiedemann
Signed-off-by: Alexander Graf
---
v1 -> v2:
- use consistent constant naming
diff --git a/linux-user/mmap.c b/linux-user/mmap.c
index e4db455..2245f40 100644
--- a/linux-user/mmap.c
+++ b/linux-user/mmap.c
@@ -244,7 +244,13 @@ static abi_ulong mmap_find_vma_reserved(abi_ulong start,
abi_ulong size)
}
prot = page_get_flags(addr);
if (prot) {
-last_addr = addr + qemu_host_page_size;
+if (addr < TASK_UNMAPPED_BASE) {
+/* Someone randomly shot into potential brk space,
+ better remap higher up when already remapping */
+last_addr = TASK_UNMAPPED_BASE;
+} else {
+last_addr = addr + qemu_host_page_size;
+}
}
}
mmap_next_start = addr;
[Qemu-devel] [PATCH] linux-user: guard mmap_next_start from specific maps
If the guest process tells us to map at a specific address, we shouldn't
increase the "last automatic mapping ended here" variable.
This patch brings the reserved_va code in line with the default case.
Signed-off-by: Alexander Graf
---
linux-user/mmap.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/linux-user/mmap.c b/linux-user/mmap.c
index 2245f40..a0c1347 100644
--- a/linux-user/mmap.c
+++ b/linux-user/mmap.c
@@ -253,7 +253,11 @@ static abi_ulong mmap_find_vma_reserved(abi_ulong start,
abi_ulong size)
}
}
}
-mmap_next_start = addr;
+
+if (start == mmap_next_start && addr >= TASK_UNMAPPED_BASE) {
+mmap_next_start = addr;
+}
+
return last_addr;
}
#endif
--
1.6.0.2
Re: [Qemu-devel] ARM brk bug
Paul Brook writes: >> 15545 brk(NULL) = 0x00012000 >> 15545 brk(0x00812000) = 0x00012000 > > This is your bug. According to the trace above, the brk call fails, but > returns success anyway. A quick look at do_brk confirms this suspicion. This is not a bug. The brk syscall always returns the break value, either the new one (on success) or the current one (on failure). Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
[Qemu-devel] [PATCH] linux-user: map at TARGET_UNMAPPED_BASE with reserved_va
When mmap()'ing memory somewhere where it's not allowed, we should not
default to the "next free page" which could be right after brk()'ed memory,
but rather at TARGET_UNMAPPED_BASE, which ensures that brk() can extend its
space later on.
Reported-by: Bernhard M. Wiedemann
Signed-off-by: Alexander Graf
---
linux-user/mmap.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/linux-user/mmap.c b/linux-user/mmap.c
index e4db455..4219b16 100644
--- a/linux-user/mmap.c
+++ b/linux-user/mmap.c
@@ -244,7 +244,13 @@ static abi_ulong mmap_find_vma_reserved(abi_ulong start,
abi_ulong size)
}
prot = page_get_flags(addr);
if (prot) {
-last_addr = addr + qemu_host_page_size;
+if (addr < mmap_next_start) {
+/* Someone randomly shot into potential brk space,
+ better remap higher up when already remapping */
+last_addr = TASK_UNMAPPED_BASE;
+} else {
+last_addr = addr + qemu_host_page_size;
+}
}
}
mmap_next_start = addr;
--
1.6.0.2
Re: [Qemu-devel] ARM brk bug
On Sat, 3 Mar 2012, Alexander Graf wrote:
>
> On 02.03.2012, at 18:49, Peter Maydell wrote:
>
> > On 27 February 2012 15:16, Bernhard M. Wiedemann wrote:
> >> I found that running a debian arm5 bash with qemu runs into varying
> >> problems with -R but works without.
> >
> > So I had a look at this this afternoon, and what seems to be happening
> > is that with -R, the call to target_mmap() in elfload.c:setup_arg_pages()
> > (which creates the stack) is putting the stack immediately after the
> > bash BSS segment in the address space. This means that brk() will
> > never be able to expand, and it looks like something in either bash
> > or libc's locale code isn't correctly handling the failure, so we
> > crash. (The segfault is from a strlen(NULL) from setlocale() I think.)
> >
> > We should probably try to put the stack somewhere more sensible than
> > where it currently ends up...
>
> I wrote a small test case to reproduce the breakage as far as I understood it
> at least:
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> int main(int argc, char **argv)
> {
> void *curbrk;
> void *tmp;
> char buf[1024];
> int fd, r;
>
> tmp = mmap((void*)0x5000UL, 0x1, PROT_READ|PROT_WRITE,
>MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
You are setting a bad example here (not that i know if that makes a
dent of a practical difference in this case): passing 0 as an fd even
in MAP_ANONYMOUS case is unsafe.
[..snip..]
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] ARM brk bug
> In QEMU with -R > > $ qemu-arm -R $(( 0x1000 )) ./brk > mmap: 0x935000 > current brk: 0x > -8000 ---p 00:00 0 > 8000-9000 r-xp 08:09 1248935408 /brk > 9000-0001 ---p 00:00 0 > 0001-00011000 r--p 08:09 1248935408 /brk > 00011000-00012000 rw-p 1000 08:09 1248935408 /brk > 00012000-00013000 ---p 00:00 0 > 00013000-00813000 rw-p 00:00 0 Would tell us a lot more if (a) you gave us the map before the strace call, and (b) the requested size wasn't the same as the default stack size. > > qemu's strace says: > 15545 mmap2(NULL,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) > = 0x00834000 [...] > 15545 > mmap2(0x5000,65536,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,0,0) > = 0x00935000 [...] > 15545 brk(NULL) = 0x00012000 > 15545 brk(0x00812000) = 0x00012000 This is your bug. According to the trace above, the brk call fails, but returns success anyway. A quick look at do_brk confirms this suspicion. Paul
Re: [Qemu-devel] ARM brk bug
On 03.03.2012, at 22:02, Alexander Graf wrote: [...] > > $ qemu-arm -R $(( 0x1000 )) ./brk > mmap: 0x935000 > current brk: 0x > -8000 ---p 00:00 0 > 8000-9000 r-xp 08:09 1248935408 /brk > 9000-0001 ---p 00:00 0 > 0001-00011000 r--p 08:09 1248935408 /brk > 00011000-00012000 rw-p 1000 08:09 1248935408 /brk > 00012000-00013000 ---p 00:00 0 > 00013000-00813000 rw-p 00:00 0 > 00813000-0082b000 r-xp 08:09 1248675559 /lib/ld-2.15.so > 0082b000-00832000 ---p 00:00 0 > 00832000-00833000 r--p 00017000 08:09 1248675559 /lib/ld-2.15.so > 00833000-00834000 rw-p 00018000 08:09 1248675559 /lib/ld-2.15.so > 00834000-00835000 rw-p 00:00 0 > 00835000-00838000 ---p 00:00 0 > 00838000-00915000 r-xp 08:09 1248675566 /lib/libc-2.15.so > 00915000-0091c000 ---p 000dd000 08:09 1248675566 /lib/libc-2.15.so > 0091c000-0091e000 r--p 000dc000 08:09 1248675566 /lib/libc-2.15.so > 0091e000-0091f000 rw-p 000de000 08:09 1248675566 /lib/libc-2.15.so > 0091f000-00922000 rw-p 00:00 0 > 00922000-0092b000 r-xp 08:09 1248678464 /lib/libgcc_s.so.1 > 0092b000-00932000 ---p 9000 08:09 1248678464 /lib/libgcc_s.so.1 > 00932000-00933000 r--p 8000 08:09 1248678464 /lib/libgcc_s.so.1 > 00933000-00934000 rw-p 9000 08:09 1248678464 /lib/libgcc_s.so.1 > 00934000-00946000 rw-p 00:00 0 > 00013000-00813000 rw-p 00:00 0 [stack] > > qemu's strace says: > 15545 mmap2(NULL,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = > 0x00834000 > [...] > 15545 > mmap2(0x5000,65536,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,0,0) = > 0x00935000 > [...] > 15545 brk(NULL) = 0x00012000 > 15545 brk(0x00812000) = 0x00012000 > > I wonder who allocates the chunk from 00012000-00013000? I don't see any > syscall returning an address in that range on the trace. Oooh that's our reserved memory range. Yikes. I think I'm slowly grasping what's going wrong here. Alex
Re: [Qemu-devel] ARM brk bug
On 02.03.2012, at 18:49, Peter Maydell wrote:
> On 27 February 2012 15:16, Bernhard M. Wiedemann wrote:
>> I found that running a debian arm5 bash with qemu runs into varying
>> problems with -R but works without.
>
> So I had a look at this this afternoon, and what seems to be happening
> is that with -R, the call to target_mmap() in elfload.c:setup_arg_pages()
> (which creates the stack) is putting the stack immediately after the
> bash BSS segment in the address space. This means that brk() will
> never be able to expand, and it looks like something in either bash
> or libc's locale code isn't correctly handling the failure, so we
> crash. (The segfault is from a strlen(NULL) from setlocale() I think.)
>
> We should probably try to put the stack somewhere more sensible than
> where it currently ends up...
I wrote a small test case to reproduce the breakage as far as I understood it
at least:
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char **argv)
{
void *curbrk;
void *tmp;
char buf[1024];
int fd, r;
tmp = mmap((void*)0x5000UL, 0x1, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
printf("mmap: %p\n", tmp);
curbrk = sbrk(8 * 1024 * 1024);
printf("current brk: %p\n", curbrk);
fd = open("/proc/self/maps", O_RDONLY);
while ((r = read(fd, buf, sizeof(buf))) > 0) {
write(1, buf, r);
}
return 0;
}
On real hw:
$ ./brk
mmap: 0x40056000
current brk: 0x12000
8000-9000 r-xp b3:02 29374 /root/brk-bug/brk
0001-00011000 r--p b3:02 29374 /root/brk-bug/brk
00011000-00012000 rw-p 1000 b3:02 29374 /root/brk-bug/brk
00012000-00812000 rw-p 00:00 0 [heap]
40014000-40015000 rw-p 00:00 0
40035000-4004d000 r-xp b3:02 6823 /lib/ld-2.15.so
4004d000-4004e000 rw-p 00:00 0
40054000-40055000 r--p 00017000 b3:02 6823 /lib/ld-2.15.so
40055000-40056000 rw-p 00018000 b3:02 6823 /lib/ld-2.15.so
40056000-40066000 rw-p 00:00 0
4008e000-4008f000 rw-p 00:00 0
400a8000-400b1000 r-xp b3:02 6846 /lib/libgcc_s.so.1
400b1000-400b8000 ---p 9000 b3:02 6846 /lib/libgcc_s.so.1
400b8000-400b9000 r--p 8000 b3:02 6846 /lib/libgcc_s.so.1
400b9000-400ba000 rw-p 9000 b3:02 6846 /lib/libgcc_s.so.1
4015-4022d000 r-xp b3:02 6830 /lib/libc-2.15.so
4022d000-40234000 ---p 000dd000 b3:02 6830 /lib/libc-2.15.so
40234000-40236000 r--p 000dc000 b3:02 6830 /lib/libc-2.15.so
40236000-40237000 rw-p 000de000 b3:02 6830 /lib/libc-2.15.so
40237000-4023a000 rw-p 00:00 0
bee3f000-bee6 rw-p 00:00 0 [stack]
-1000 r-xp 00:00 0 [vectors]
strace says:
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40082000
[...]
mmap2(0x5000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) =
0x40018000
[...]
brk(0) = 0x12000
brk(0x812000) = 0x812000
In QEMU with -R
$ qemu-arm -R $(( 0x1000 )) ./brk
mmap: 0x935000
current brk: 0x
-8000 ---p 00:00 0
8000-9000 r-xp 08:09 1248935408 /brk
9000-0001 ---p 00:00 0
0001-00011000 r--p 08:09 1248935408 /brk
00011000-00012000 rw-p 1000 08:09 1248935408 /brk
00012000-00013000 ---p 00:00 0
00013000-00813000 rw-p 00:00 0
00813000-0082b000 r-xp 08:09 1248675559 /lib/ld-2.15.so
0082b000-00832000 ---p 00:00 0
00832000-00833000 r--p 00017000 08:09 1248675559 /lib/ld-2.15.so
00833000-00834000 rw-p 00018000 08:09 1248675559 /lib/ld-2.15.so
00834000-00835000 rw-p 00:00 0
00835000-00838000 ---p 00:00 0
00838000-00915000 r-xp 08:09 1248675566 /lib/libc-2.15.so
00915000-0091c000 ---p 000dd000 08:09 1248675566 /lib/libc-2.15.so
0091c000-0091e000 r--p 000dc000 08:09 1248675566 /lib/libc-2.15.so
0091e000-0091f000 rw-p 000de000 08:09 1248675566 /lib/libc-2.15.so
0091f000-00922000 rw-p 00:00 0
00922000-0092b000 r-xp 08:09 1248678464 /lib/libgcc_s.so.1
0092b000-00932000 ---p 9000 08:09 1248678464 /lib/libgcc_s.so.1
00932000-00933000 r--p 8000 08:09 1248678464 /lib/libgcc_s.so.1
00933000-00934000 rw-p 9000 08:09 1248678464 /lib/libgcc_s.so.1
00934000-00946000 rw-p 00:00 0
00013000-00813000 rw-p 00:00 0 [stack]
qemu's strace says:
15545 mmap2(NULL,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) =
0x00834000
[...]
15545
mmap2(0x5000,65536,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,0,0) =
0x00935000
[...]
15545 brk(NULL) = 0x00012000
15545 brk(0x00812000) = 0x00012000
I wonder who allocates the chunk from 00012000
Re: [Qemu-devel] [PATCH] PCI Using macro definition instead of a simple digit
Am 03.03.2012 13:38, schrieb Wanpeng Li:
> PCI_CLASS_DISPLAY_VGA has already defined in hw/pci_ids.h, so use the
> macro definition instead of a simple digit.
>
> Signed-off-by: Wanpeng Li
Number matches,
Acked-by: Andreas Färber
Cc'ing mst.
There's probably much more uses of magic number in the individual PCI
devices, host controllers and bridges.
Andreas
> ---
> hw/pci.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/hw/pci.c b/hw/pci.c
> index fe71666..274d86d 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -1784,7 +1784,7 @@ static int pci_add_option_rom(PCIDevice *pdev, bool
> is_default_rom)
> * for 0.11 compatibility.
> */
> int class = pci_get_word(pdev->config + PCI_CLASS_DEVICE);
> -if (class == 0x0300) {
> +if (class == PCI_CLASS_DISPLAY_VGA) {
> rom_add_vga(pdev->romfile);
> } else {
> rom_add_option(pdev->romfile, -1);
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] Add -netdev to man page
- Original Message -
> From: "Markus Armbruster"
> To: "Miroslav Rezanina"
> Cc: qemu-devel@nongnu.org
> Sent: Thursday, March 1, 2012 4:50:35 PM
> Subject: Re: [Qemu-devel] [PATCH] Add -netdev to man page
>
> Miroslav Rezanina writes:
>
> > There's missing -netdev description in the man page for qemu. As
> > this is
> > recommended way to create network backend, lack of documentation
> > can discourage
> > its usage.
>
> Very much appreciated!
>
> > -net option is preserved but marked as obsolete way.
> >
> > Signed-off-by: Miroslav Rezanina
> >
> > Patch:
> > -
> > diff --git a/qemu-options.hx b/qemu-options.hx
> > index b129996..a1d61b6 100644
> > --- a/qemu-options.hx
> > +++ b/qemu-options.hx
> > @@ -1292,6 +1292,268 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev,
> > #endif
> > "socket],id=str[,option][,option][,...]\n", QEMU_ARCH_ALL)
> > STEXI
> > +@item -netdev
> > user|tap|vde|socket,id=@var{str}[,option][,option][,...]
> > +
> > +Create a new network backend to the guest. The backend's
> > @option{id} can be used with
>
> Suggest to drop "to the guest".
>
ok.
> > +the @option{-device} option to connect a backend with a device,
> > +e.g.
> > +
> > +@example
> > +-netdev user,id=mynet -device e1000,netdev=mynet
> > +@end example
> > +
> > +You can use following types of backend:
> > +
> > +@table @option
> > +
> > +@item -netdev user
> > +
> > +User networking is default network backend. This backend does not
> > require root
> > +priviledges, does not allow ICMP trafic and host is not directly
> > accessible
> > +from the host or the external network.
>
> privileges
>
> traffic
>
> Suggest you use a spell checker :)
>
> Comma after "traffic", please.
>
> Err, "host is not directly accessible from the host"... Do you mean
> "guest is not"?
>
> > +Valid options are:
> > +
> > +@table @option
> > +
> > +@item restrict=y|yes|n|no
>
> For -net, this is documented as restrict=on|off. All these values
> are
> actually recognized. I find that somewhat baroque, and don't
> particularly care which ones you document :)
>
I will go on|off way even if yes|no is possible. No need to use special
handling.
> > +If this options is enabled, the guest will be isolated, i.e. it
> > will not be
>
> option
>
> > +able to contact the host and no guest IP packets will be routed
> > over the host
> > +to the outside. This option does not affect explicitly set
> > forwarding rules.
> > +
> > +@item net=@var{addr}[/@var{mask}]
> > +Set the IP network address the guest will see. Optionally specify
> > the netmask,
> > +either in the form a.b.c.d or as number of valid top-most bits.
> > Default is
> > +10.0.2.0/8.
>
> Documentation of -net has /24 here. One of them might be wrong (I
> didn't check).
>
You're right. I worked on both RHEL and upstream man page in paralel and
there's different text in both version. Correct value is /24.
> > +
> > +@item host=@var{addr}
> > +Specify the guest-visible address of the host. Default is the 2nd
> > IP in the
> > +guest network, i.e. x.x.x.2.
> > +
> > +@item hostname=@var{name}
> > +Specifies the client hostname reported by the builtin DHCP server.
> > +
> > +@item dhcpstart=@var{addr}
> > +Specify the first of the 16 IPs the built-in DHCP server can
> > assign. Default
> > +is the 16th to 31st IP in the guest network, i.e. x.x.x.16 to
> > x.x.x.31.
>
> Documentation of -net has 15th here. One of them might be wrong (I
> didn't check).
Yes, 15 is correct start but I'm not sure with end value -> is 16 IP used
so last address is x.x.x.30 or is x.x.x.31 really last address?
>
> > +@item dns=@var{addr}
> > +Specify the guest-visible address of the virtual nameserver. The
> > address must
> > +be different from the host address. Default is the 3rd IP in the
> > guest network,
> > +i.e. x.x.x.3.
> > +
> > +@item tftp=@var{dir}
> > +When using the user mode network stack, activate a built-in TFTP
> > +server. The files in @var{dir} will be exposed as the root of a
> > TFTP server.
> > +The TFTP client on the guest must be configured in binary mode
> > (use the command
> > +@code{bin} of the Unix TFTP client).
> > +
> > +@item bootfile=@var{file}
> > +When using the user mode network stack, broadcast @var{file} as
> > the BOOTP
> > +filename. In conjunction with @option{tftp}, this can be used to
> > network boot
> > +a guest from a local directory.
> > +
> > +Example (using pxelinux):
> > +@example
> > +qemu -hda linux.img -boot n -netdev
> > user,id=netid,tftp=/path/to/tftp/files,bootfile=/pxelinux.0
> > +@end example
> > +
> > +@item smb=@var{dir}[,smbserver=@var{addr}]
> > +When using the user mode network stack, activate a built-in SMB
> > +server so that Windows OSes can access to the host files in
> > @file{@var{dir}}
> > +transparently. The IP address of the SMB server can be set to
> > @var{addr}. By
> > +default the 4th IP in the guest network is used, i.e. x.x.x.4.
> > +
> > +In the guest Windows OS, the line:
> > +@example
> >
Re: [Qemu-devel] [PATCH 7/7] pseries: Configure PCI bridge using properties
Am 28.02.2012 04:18, schrieb David Gibson:
> From: Alexey Kardashevskiy
>
> Currently, the function spapr_create_phb() uses its parameters to
> initialize the correct memory windows for the new PCI Host Bridge
> (PHB). This is not the way things are supposed to be done with qdevs,
> and means you can't create extra PHBs easily using -device.
>
> Since pSeries machines can and do have many PHBs with various
> configurations, this is a real limitation, not just a theoretical.
> This patch, therefore, alters the PHB initialization code to use qdev
> properties to set these parameters of the new bridge, moving most of
> the code from spapr_create_phb() to spapr_phb_init().
>
> While we're at it, we change the naming of each PCI bus and its
> associated memory regions to be less arbitrary and make it easier to
> relate the guest and qemu views of memory to each other.
>
> Signed-off-by: Alexey Kardashevskiy
> Signed-off-by: David Gibson
> ---
> hw/spapr.c |2 +-
> hw/spapr_pci.c | 149 ++-
> hw/spapr_pci.h |5 +-
> 3 files changed, 84 insertions(+), 72 deletions(-)
> diff --git a/hw/spapr_pci.c b/hw/spapr_pci.c
> index b0254ee..654cb56 100644
> --- a/hw/spapr_pci.c
> +++ b/hw/spapr_pci.c
> @@ -161,49 +161,6 @@ static void pci_spapr_set_irq(void *opaque, int irq_num,
> int level)
> qemu_set_irq(phb->lsi_table[irq_num].qirq, level);
> }
>
> -static int spapr_phb_init(SysBusDevice *s)
> -{
> -sPAPRPHBState *phb = FROM_SYSBUS(sPAPRPHBState, s);
> -int i;
> -
> -/* Initialize the LSI table */
> -for (i = 0; i < SPAPR_PCI_NUM_LSI; i++) {
> -qemu_irq qirq;
> -uint32_t num;
> -
> -qirq = spapr_allocate_lsi(0, &num);
> -if (!qirq) {
> -return -1;
> -}
> -
> -phb->lsi_table[i].dt_irq = num;
> -phb->lsi_table[i].qirq = qirq;
> -}
> -
> -return 0;
> -}
> -
> -static void spapr_phb_class_init(ObjectClass *klass, void *data)
> -{
> -SysBusDeviceClass *sdc = SYS_BUS_DEVICE_CLASS(klass);
> -
> -sdc->init = spapr_phb_init;
> -}
> -
> -static TypeInfo spapr_phb_info = {
> -.name = "spapr-pci-host-bridge",
> -.parent= TYPE_SYS_BUS_DEVICE,
> -.instance_size = sizeof(sPAPRPHBState),
> -.class_init= spapr_phb_class_init,
> -};
> -
> -static void spapr_register_types(void)
> -{
> -type_register_static(&spapr_phb_info);
> -}
> -
> -type_init(spapr_register_types)
> -
> static uint64_t spapr_io_read(void *opaque, target_phys_addr_t addr,
>unsigned size)
> {
> @@ -297,14 +248,76 @@ void spapr_create_phb(sPAPREnvironment *spapr,
> PCI_DEVFN(0, 0),
> SPAPR_PCI_NUM_LSI);
>
> +QLIST_INSERT_HEAD(&spapr->phbs, phb, list);
> +
> +/* Initialize the LSI table */
> +for (i = 0; i < SPAPR_PCI_NUM_LSI; i++) {
> +qemu_irq qirq;
> +uint32_t num;
> +
> +qirq = spapr_allocate_lsi(0, &num);
> +if (!qirq) {
> +return -1;
> +}
> +
> +phb->lsi_table[i].dt_irq = num;
> +phb->lsi_table[i].qirq = qirq;
> +}
> +
> +return 0;
> +}
> +
> +static Property spapr_phb_properties[] = {
> +DEFINE_PROP_HEX64("buid", sPAPRPHBState, buid, 0),
> +DEFINE_PROP_HEX64("mem_win_addr", sPAPRPHBState, mem_win_addr, 0),
> +DEFINE_PROP_HEX64("mem_win_size", sPAPRPHBState, mem_win_size,
> 0x2000),
> +DEFINE_PROP_HEX64("io_win_addr", sPAPRPHBState, io_win_addr, 0),
> +DEFINE_PROP_HEX64("io_win_size", sPAPRPHBState, io_win_size, 0x1),
> +DEFINE_PROP_END_OF_LIST(),
> +};
> +
> +static void spapr_phb_class_init(ObjectClass *klass, void *data)
> +{
> +SysBusDeviceClass *sdc = SYS_BUS_DEVICE_CLASS(klass);
> +DeviceClass *dc = DEVICE_CLASS(klass);
> +
> +sdc->init = spapr_phb_init;
> +dc->props = spapr_phb_properties;
> +}
> +
> +static TypeInfo spapr_phb_info = {
> +.name = "spapr-pci-host-bridge",
> +.parent= TYPE_SYS_BUS_DEVICE,
> +.instance_size = sizeof(sPAPRPHBState),
> +.class_init= spapr_phb_class_init,
> +};
> +
> +static void spapr_register_pci_type(void)
> +{
> +type_register_static(&spapr_phb_info);
> +
> spapr_rtas_register("read-pci-config", rtas_read_pci_config);
> spapr_rtas_register("write-pci-config", rtas_write_pci_config);
> spapr_rtas_register("ibm,read-pci-config", rtas_ibm_read_pci_config);
> spapr_rtas_register("ibm,write-pci-config", rtas_ibm_write_pci_config);
> +}
>
> -QLIST_INSERT_HEAD(&spapr->phbs, phb, list);
> +type_init(spapr_register_pci_type)
Please respect the recently enforced convention of naming the function
..._register_types as before and best putting it and type_init() in the
bottom so that we don't end up with multiple ones per file.
And registering types is all such a function can safely d
Re: [Qemu-devel] Support for Nested Paging
> Does QEMU emulate the Nested Page Tables implemented by AMD-V architecture or > the Intel VT? I think the answer is no. > Also I am trying to understand the QEMU source with an objective of > participating in the Google Summer of Code and contributing to QEMU. I have > tried tracing through the code but seems this link > http://repo.or.cz/w/qemu/stefanha.git/blob_plain/refs/heads/tracing:/docs/tracing.txt > is not updated because many of the options do not work here. I would very > happy if someone could provide me links to a good starting point to > understand QEMU source code. The "tracing" you mentioned is not tend to help reading the code. Depends on which part of QEMU you're trying to play with, you have some background knowledge of it. See "Getting to know the code" on the QEMU wiki [1]. And the slides mentioned on the mail below is a good start. http://www.mail-archive.com/qemu-devel@nongnu.org/msg99864.html HTH, chenwj [1] http://wiki.qemu.org/Documentation/GettingStartedDevelopers#Getting_to_know_the_code -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH] PPC: Fix large page support in TCG
Am 03.03.2012 17:39, schrieb Nathan Whitehorn:
> Fix large page support in TCG. The old code would overwrite the large
> page table entry with the fake 4 KB
> one generated here whenever the ref/change bits were updated, causing it
> to point to the wrong area of memory. Instead of creating a fake PTE,
> just update the real address at the end.
>
> Signed-off-by: Nathan Whitehorn
cc'ing Alex and qemu-ppc.
/-F
> ---
> target-ppc/helper.c | 11 +--
> 1 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/target-ppc/helper.c b/target-ppc/helper.c
> index 928fbcf..0f5ad2e 100644
> --- a/target-ppc/helper.c
> +++ b/target-ppc/helper.c
> @@ -597,12 +597,6 @@ static inline int _find_pte(CPUState *env,
> mmu_ctx_t *ctx,
> int is_64b, int h,
> pte1 = ldq_phys(env->htab_base + pteg_off + (i * 16) + 8);
> }
>
> -/* We have a TLB that saves 4K pages, so let's
> - * split a huge page to 4k chunks */
> -if (target_page_bits != TARGET_PAGE_BITS)
> -pte1 |= (ctx->eaddr & (( 1 << target_page_bits ) - 1))
> - & TARGET_PAGE_MASK;
> -
> r = pte64_check(ctx, pte0, pte1, h, rw, type);
> LOG_MMU("Load pte from " TARGET_FMT_lx " => " TARGET_FMT_lx
> " "
> TARGET_FMT_lx " %d %d %d " TARGET_FMT_lx "\n",
> @@ -678,6 +672,11 @@ static inline int _find_pte(CPUState *env,
> mmu_ctx_t *ctx,
> int is_64b, int h,
> }
> }
>
> +/* We have a TLB that saves 4K pages, so let's
> + * split a huge page to 4k chunks */
> +if (target_page_bits != TARGET_PAGE_BITS)
> + ctx->raddr |= (ctx->eaddr & (( 1 << target_page_bits ) - 1))
> + & TARGET_PAGE_MASK;
> return ret;
> }
>
> --
> 1.7.9
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] PPC: Add PIR register to POWER7 CPU
Am 03.03.2012 17:36, schrieb Nathan Whitehorn: > The POWER7 emulation is missing the Processor Identification Register, > mandatory in recent POWER CPUs, that is required for SMP on at least > some operating systems (e.g. FreeBSD) to function properly. This patch > copies the existing PIR code from the other CPUs that implement it. > > Signed-off-by: Nathan Whitehorn Please always cc the respective maintainers (and lists) according to MAINTAINERS. CC'ing Alex and qemu-ppc. > --- > target-ppc/translate_init.c |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c > index 8a7233f..01f4030 100644 > --- a/target-ppc/translate_init.c > +++ b/target-ppc/translate_init.c > @@ -6537,6 +6537,11 @@ static void init_proc_POWER7 (CPUPPCState *env) > /* Time base */ > gen_tbl(env); > #if !defined(CONFIG_USER_ONLY) > +/* Processor identification */ > +spr_register(env, SPR_PIR, "PIR", > + SPR_NOACCESS, SPR_NOACCESS, > + &spr_read_generic, &spr_write_pir, Indentation looks weird here. Stray tab maybe? Andreas > + 0x); > /* PURR & SPURR: Hack - treat these as aliases for the TB for now */ > spr_register(env, SPR_PURR, "PURR", > &spr_read_purr, SPR_NOACCESS, > -- > 1.7.9 -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] Fix build with stub USB backend
Am 03.03.2012 17:38, schrieb Nathan Whitehorn:
> Recent changes to the signature of usb_host_device_open() have broken
> the stub USB backend. This updates the stub version of
> usb_host_device_open() to correspond to the new API.
>
> Signed-off-by: Nathan Whitehorn
Looks like a duplicate, a similar patch was just applied.
Andreas
> ---
> usb-stub.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/usb-stub.c b/usb-stub.c
> index 9c3fcea..b4e10c1 100644
> --- a/usb-stub.c
> +++ b/usb-stub.c
> @@ -41,7 +41,7 @@ void usb_host_info(Monitor *mon)
> }
>
> /* XXX: modify configure to compile the right host driver */
> -USBDevice *usb_host_device_open(const char *devname)
> +USBDevice *usb_host_device_open(USBBus *bus, const char *devname)
> {
> return NULL;
> }
> --
> 1.7.9
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] i.MX support
Hi, Am 02.03.2012 17:29, schrieb Pierre Ficheux: > I'm looking for information about ARM/i.MX support in QEMU (i.MX23). > I've found some patches around but I didn't find anything in the Git tree. > > Here is a discussion from 2011 about i.MX31 patches: > > http://comments.gmane.org/gmane.comp.emulators.qemu/125932 If you need i.MX31 support in QEMU then someone will need to pick up those patches, rebase them onto the QOM model and fix any remaining issues. You should coordinate that with the patch author (cc'ed). Adding a feature page on the Wiki to track merge progress might also be a good idea. Now regarding i.MX23, you would need to find out what the difference to i.MX31 is (e.g., ARM9 vs. ARM11, maybe same UART?) and, most likely, do some coding of your own for anything i.MX23-specific. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PULL 0/4] arm-devs queue
On Fri, Mar 2, 2012 at 12:07, Peter Maydell wrote: > Hi; this is a pullreq for the arm-devs queue; nothing hugely exciting > here unless you count the final part of the -dtb support. Please pull. Thanks, pulled. > thanks > -- PMM > > The following changes since commit 7c51c1aa03a52b9fd75ed1ade2e65d079ae4d50e: > > Merge remote-tracking branch 'kwolf/for-anthony' into staging (2012-02-29 > 12:57:28 -0600) > > are available in the git repository at: > > git://git.linaro.org/people/pmaydell/qemu-arm.git arm-devs.for-upstream > > Grant Likely (1): > arm: add device tree support > > Peter Maydell (1): > hw/arm11mpcore: Fix broken realview_mpcore/arm11mpcore_priv properties > > Rusty Russell (2): > arm: clean up GIC constants > arm: make sure that number of irqs can be represented in GICD_TYPER. > > Makefile.target | 1 + > configure | 1 + > hw/arm-misc.h | 1 + > hw/arm11mpcore.c | 20 +- > hw/arm_boot.c | 102 ++--- > hw/arm_gic.c | 50 -- > qemu-config.c | 4 ++ > qemu-options.hx | 9 + > vl.c | 8 > 9 files changed, 161 insertions(+), 35 deletions(-) >
Re: [Qemu-devel] [PATCH] usb: Fix signature of stub usb_host_device_open
Thanks, applied.
On Thu, Mar 1, 2012 at 09:43, Jan Kiszka wrote:
> This was a breakage of 3741715cf2.
>
> Signed-off-by: Jan Kiszka
> ---
> usb-stub.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/usb-stub.c b/usb-stub.c
> index 9c3fcea..b4e10c1 100644
> --- a/usb-stub.c
> +++ b/usb-stub.c
> @@ -41,7 +41,7 @@ void usb_host_info(Monitor *mon)
> }
>
> /* XXX: modify configure to compile the right host driver */
> -USBDevice *usb_host_device_open(const char *devname)
> +USBDevice *usb_host_device_open(USBBus *bus, const char *devname)
> {
> return NULL;
> }
> --
> 1.7.3.4
>
Re: [Qemu-devel] [PULL 00/12] target-xtensa queue
On Sun, Feb 26, 2012 at 17:34, Max Filippov wrote: >> Hi. >> >> This is a pull request for my current target-xtensa queue. >> Changes in the queue are: >> - 'info tlb' monitor command; >> - debug option implementation; >> - a few minor fixes. > > ping? Thanks, pulled. >> >> Debug option series has been posted to the list as an RFC, there were no >> changes >> in it since then. >> >> Please pull. >> >> Thanks. >> -- Max >> >> The following changes since commit 99c7f87826337fa81f2f0f9baa9ca0a44faf90e9: >> >> input: send kbd+mouse events only to running guests. (2012-02-17 11:02:55 >> -0600) >> >> are available in the git repository at: >> git://jcmvbkbc.spb.ru/dumb/qemu-xtensa.git xtensa >> >> Max Filippov (12): >> target-xtensa: define TLB_TEMPLATE for MMU-less cores >> target-xtensa: implement info tlb monitor command >> target-xtensa: fetch 3rd opcode byte only when needed >> target-xtensa: add DEBUGCAUSE SR and configuration >> target-xtensa: implement instruction breakpoints >> target-xtensa: add ICOUNT SR and debug exception >> exec: add missing breaks to the watch_mem_write >> exec: fix check_watchpoint exiting cpu_loop >> exec: let cpu_watchpoint_insert accept larger watchpoints >> target-xtensa: add DBREAK data breakpoints >> target-xtensa: add DEBUG_SECTION to overlay tool >> target-xtensa: add breakpoint tests >> >> exec.c | 18 +++- >> hmp-commands.hx | 2 +- >> monitor.c | 4 +- >> target-xtensa/core-dc232b.c | 1 + >> target-xtensa/core-fsf.c | 1 + >> target-xtensa/cpu.h | 43 >> target-xtensa/helper.c | 110 >> target-xtensa/helpers.h | 7 ++ >> target-xtensa/op_helper.c | 100 ++ >> target-xtensa/overlay_tool.h | 23 - >> target-xtensa/translate.c | 156 - >> tests/tcg/xtensa/Makefile | 1 + >> tests/tcg/xtensa/test_break.S | 223 >> + >> 13 files changed, 674 insertions(+), 15 deletions(-) >> create mode 100644 tests/tcg/xtensa/test_break.S >> >> -- >> 1.7.7.6 > > -- > Thanks. > -- Max
[Qemu-devel] [PATCH] PPC: Fix large page support in TCG
Fix large page support in TCG. The old code would overwrite the large
page table entry with the fake 4 KB
one generated here whenever the ref/change bits were updated, causing it
to point to the wrong area of memory. Instead of creating a fake PTE,
just update the real address at the end.
Signed-off-by: Nathan Whitehorn
---
target-ppc/helper.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/target-ppc/helper.c b/target-ppc/helper.c
index 928fbcf..0f5ad2e 100644
--- a/target-ppc/helper.c
+++ b/target-ppc/helper.c
@@ -597,12 +597,6 @@ static inline int _find_pte(CPUState *env,
mmu_ctx_t *ctx,
int is_64b, int h,
pte1 = ldq_phys(env->htab_base + pteg_off + (i * 16) + 8);
}
-/* We have a TLB that saves 4K pages, so let's
- * split a huge page to 4k chunks */
-if (target_page_bits != TARGET_PAGE_BITS)
-pte1 |= (ctx->eaddr & (( 1 << target_page_bits ) - 1))
- & TARGET_PAGE_MASK;
-
r = pte64_check(ctx, pte0, pte1, h, rw, type);
LOG_MMU("Load pte from " TARGET_FMT_lx " => "
TARGET_FMT_lx " "
TARGET_FMT_lx " %d %d %d " TARGET_FMT_lx "\n",
@@ -678,6 +672,11 @@ static inline int _find_pte(CPUState *env,
mmu_ctx_t *ctx,
int is_64b, int h,
}
}
+/* We have a TLB that saves 4K pages, so let's
+ * split a huge page to 4k chunks */
+if (target_page_bits != TARGET_PAGE_BITS)
+ ctx->raddr |= (ctx->eaddr & (( 1 << target_page_bits ) - 1))
+ & TARGET_PAGE_MASK;
return ret;
}
--
1.7.9
[Qemu-devel] [PATCH] Fix build with stub USB backend
Recent changes to the signature of usb_host_device_open() have broken
the stub USB backend. This updates the stub version of
usb_host_device_open() to correspond to the new API.
Signed-off-by: Nathan Whitehorn
---
usb-stub.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/usb-stub.c b/usb-stub.c
index 9c3fcea..b4e10c1 100644
--- a/usb-stub.c
+++ b/usb-stub.c
@@ -41,7 +41,7 @@ void usb_host_info(Monitor *mon)
}
/* XXX: modify configure to compile the right host driver */
-USBDevice *usb_host_device_open(const char *devname)
+USBDevice *usb_host_device_open(USBBus *bus, const char *devname)
{
return NULL;
}
--
1.7.9
[Qemu-devel] [PATCH] PPC: Add PIR register to POWER7 CPU
The POWER7 emulation is missing the Processor Identification Register, mandatory in recent POWER CPUs, that is required for SMP on at least some operating systems (e.g. FreeBSD) to function properly. This patch copies the existing PIR code from the other CPUs that implement it. Signed-off-by: Nathan Whitehorn --- target-ppc/translate_init.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c index 8a7233f..01f4030 100644 --- a/target-ppc/translate_init.c +++ b/target-ppc/translate_init.c @@ -6537,6 +6537,11 @@ static void init_proc_POWER7 (CPUPPCState *env) /* Time base */ gen_tbl(env); #if !defined(CONFIG_USER_ONLY) +/* Processor identification */ +spr_register(env, SPR_PIR, "PIR", + SPR_NOACCESS, SPR_NOACCESS, + &spr_read_generic, &spr_write_pir, + 0x); /* PURR & SPURR: Hack - treat these as aliases for the TB for now */ spr_register(env, SPR_PURR, "PURR", &spr_read_purr, SPR_NOACCESS, -- 1.7.9
[Qemu-devel] [PATCH] Fix build on FreeBSD
Fix a missing header required to build on recent FreeBSD. Signed-off-by: Nathan Whitehorn --- os-posix.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/os-posix.c b/os-posix.c index dbf3b24..83b14a0 100644 --- a/os-posix.c +++ b/os-posix.c @@ -45,6 +45,10 @@ #include #endif +#ifdef __FreeBSD__ +#include +#endif + #ifdef CONFIG_EVENTFD #include #endif -- 1.7.9
Re: [Qemu-devel] [PATCH v1 1/1] mips: properly compute hflags and fcr0 on cpu reset
On 03/03/2012 10:45 AM, Andreas Färber wrote:
> Am 02.03.2012 22:03, schrieb Meador Inge:
>> Currently 'cpu_reset' doesn't fully compute all of the needed
>> HFLAGs and fails to setup fcr0 after clearing the CPU state.
>> This can cause instruction exceptions. For example, using
>> 'madd.d' on machines that should support it is kindly greeted
>> with:
>>
>> qemu: uncaught target signal 4 (Illegal instruction) - core dumped
>> Illegal instruction (core dumped)
>>
>> because fcr0 is bogus and MIPS_HFLAG_COP1X is not correcly set in hflags.
>>
>> This is fixed by modifying 'cpu_reset' to use 'compute_hflags' and
>> initializing 'fcr0' from the current CPU model.
>
> fcr0 issue has also been
>
> Reported-by: Khansa Butt
>
> e.g., http://patchwork.ozlabs.org/patch/133974/
Ah, thanks. The fcr0 fix had been sitting in our local tree for a while and I
just forgot to check upstream patch submissions. I need to get in the habit of
looking at patchwork first.
> Your use of compute_hflags() looks more future-proof.
>
>>
>> Signed-off-by: Maciej W. Rozycki
>> Signed-off-by: Nathan Froyd
>> Signed-off-by: Meador Inge
>> ---
>> target-mips/cpu.h | 49
>> +++
>> target-mips/op_helper.c | 49
>> ---
>> target-mips/translate.c | 17 +++
>> 3 files changed, 53 insertions(+), 62 deletions(-)
>>
>> diff --git a/target-mips/cpu.h b/target-mips/cpu.h
>> index 71cb4e8..fc65348 100644
>> --- a/target-mips/cpu.h
>> +++ b/target-mips/cpu.h
>> @@ -737,4 +737,53 @@ static inline void cpu_pc_from_tb(CPUState *env,
>> TranslationBlock *tb)
>> env->hflags |= tb->flags & MIPS_HFLAG_BMASK;
>> }
>>
>> +static inline void compute_hflags(CPUState *env)
>> +{
>
> Moving helper functions like these to cpu.h has proven troublesome for
> QOM'ification (when they need access to MIPSCPU[Class] in addition to
> CPUMIPSState) but it'll do for now.
Okay, I will keep that in mind for the future. Thanks for the review.
> Reviewed-by: Andreas Färber
>
> Andreas
>
--
Meador Inge
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software
[Qemu-devel] [PATCH] PCI Using macro definition instead of a simple digit
PCI_CLASS_DISPLAY_VGA has already defined in hw/pci_ids.h, so use the
macro definition instead of a simple digit.
Signed-off-by: Wanpeng Li
---
hw/pci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index fe71666..274d86d 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1784,7 +1784,7 @@ static int pci_add_option_rom(PCIDevice *pdev, bool
is_default_rom)
* for 0.11 compatibility.
*/
int class = pci_get_word(pdev->config + PCI_CLASS_DEVICE);
-if (class == 0x0300) {
+if (class == PCI_CLASS_DISPLAY_VGA) {
rom_add_vga(pdev->romfile);
} else {
rom_add_option(pdev->romfile, -1);
--
1.7.5.4
Re: [Qemu-devel] IRQ number, interrupt number, interrupt line & GPIO[in/out]
2012/3/3 Zhi Yong Wu : > thanks a lot for your help, they are very in theory.:). actually these > concepts all exist in QEMU. I would like to know how they work > together. It's a mess. qemu_irq is the most fundamental data type we use to model a general 'pin' or 'signal' line; despite the name it can be used for other things besides interrupt lines, like general purpose I/O. This is used by basically all devices. The base class Device for all devices implemented using the QEMU Object Model provides a number of qdev_* functions for registering and manipulating input and output I/O lines, eg qdev_get_gpio_in and qdev_connect_gpio_out. These are written in terms of the basic qemu_irq type. Despite the 'gpio' name, you can use these for interrupt lines if you want. The SysBus class (used for a lot of devices which are really just trying to provide memory-mapped I/O and some interrupt or signal lines) also provides an abstraction of qemu_irq (functions sysbus_connect_irq(), sysbus_init_irq(), etc). Again, there's no reason you can't use these for other purposes than interrupts, although since every SysBus device is also a Device, mostly by convention the sysbus abstraction is used for the real outbound interrupt lines and the Device gpio abstraction for everything else. My opinion is that we should clean this up as part of properly converting to the new object model. In particular SysBus should just disappear and all Devices should be able to export named input and output signals, which can be used for interrupts or general I/O or whatever. Unfortunately we're probably stuck with the incredibly badly named 'qemu_irq' type for the rest of eternity... -- PMM
[Qemu-devel] i.MX support
Hi, I'm looking for information about ARM/i.MX support in QEMU (i.MX23). I've found some patches around but I didn't find anything in the Git tree. Here is a discussion from 2011 about i.MX31 patches: http://comments.gmane.org/gmane.comp.emulators.qemu/125932 Any idea ? regards -- Pierre FICHEUX -/- CTO OWI, France -\- pierre.fich...@openwide.fr http://ingenierie.openwide.fr http://www.ficheux.org I would love to change the world, but they won't give me the source code
Re: [Qemu-devel] [PATCH 3/4] net: split hostname and service by last colon
On 03/02/2012 05:35 AM, Kevin Wolf wrote: > Am 02.03.2012 10:58, schrieb Amos Kong: >> On 02/03/12 11:38, Amos Kong wrote: > --- a/net.c > +++ b/net.c > @@ -84,7 +84,7 @@ static int get_str_sep(char *buf, int buf_size, > const char **pp, int sep) > const char *p, *p1; > int len; > p = *pp; > -p1 = strchr(p, sep); > +p1 = strrchr(p, sep); > if (!p1) > return -1; > len = p1 - p; And what if the port isn't specified? I think you would erroneously interpret the last part of the IP address as port. >> Hi Kevin, port must be specified in '-incoming' parameters and migrate >> monitor cmd. >> >> qemu-kvm ... -incoming tcp:$host:$port >> (qemu) migrate -d tcp:$host:$port >> >> >> If use boot up guest by wrong cmdline, qemu will report an error msg. >> >> # ./x86_64-softmmu/qemu-system-x86_64 --enable-kvm -boot n -incoming >> tcp:2312::8272 -monitor stdio >> qemu-system-x86_64: qemu: getaddrinfo: Name or service not known >> tcp_server_start: Invalid argument >> Migration failed. Exit code tcp:2312::8272(-22), exiting. > Which is because 2312: isn't a valid IP address, right? But what if you > have something like 2312::1234:8272? If you misinterpret the 8272 as a > port number, the remaining address is still a valid IPv6 address. This is made irrelevant by PATCH 4/4, which allows for the IP address to be placed inside brackets: [2312::8272]:port (at least it's irrelevant if your documentation *requires* brackets for all numeric ipv6-address:port pairs, which is strongly recommended by RFC 5952). It really is impossible to disambiguate the meaning of the final ":" unless you require these brackets (or 1) require full specification of all potential colons in the IPv6 address or require that the port *always* be specified, neither of which seem acceptable to me).
Re: [Qemu-devel] IRQ number, interrupt number, interrupt line & GPIO[in/out]
> Can anyone explain their relationship and difference among them? It > is very appreciated if you can make some comments. thanks. I think IRQ number, interrupt number are quite similar things. You can check PIC [1] first, especially 8259A [2]. When a device raise an interrupt, the interrupt is delivered to CPU through PIC. Each device attaches itself to one of PIC's pins. Thus, when we say the IRQ number of device X is Y, it means device X attaches itself to PIC's pin Y. PIC will deliver the highest priority interrupt to the CPU. The term "interrupt line" might appear in PCI context [3]. BIOS usually uses interrupt line to represent what PIC pin the device attatches to. Note that PIC (Programmable Interrupt Controller) and PCI (Peripheral Component Interconnect) are different things. GPIO mostly is used on SoC. It depends on the vendor how to use GPIO. One of GPIO capabilities is similar to PIC, I guess. But I leave this to SoC experts. I strongly recommend the book [5] if you want to learn how things work. HTH, chenwj [1] http://en.wikipedia.org/wiki/Programmable_Interrupt_Controller [2] http://en.wikipedia.org/wiki/Intel_8259 [3] http://en.wikipedia.org/wiki/Conventional_PCI [4] http://en.wikipedia.org/wiki/General_Purpose_Input/Output [5] 系统虚拟化:原理与实现 -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH v1 1/1] mips: properly compute hflags and fcr0 on cpu reset
Am 02.03.2012 22:03, schrieb Meador Inge:
> Currently 'cpu_reset' doesn't fully compute all of the needed
> HFLAGs and fails to setup fcr0 after clearing the CPU state.
> This can cause instruction exceptions. For example, using
> 'madd.d' on machines that should support it is kindly greeted
> with:
>
> qemu: uncaught target signal 4 (Illegal instruction) - core dumped
> Illegal instruction (core dumped)
>
> because fcr0 is bogus and MIPS_HFLAG_COP1X is not correcly set in hflags.
>
> This is fixed by modifying 'cpu_reset' to use 'compute_hflags' and
> initializing 'fcr0' from the current CPU model.
fcr0 issue has also been
Reported-by: Khansa Butt
e.g., http://patchwork.ozlabs.org/patch/133974/
Your use of compute_hflags() looks more future-proof.
>
> Signed-off-by: Maciej W. Rozycki
> Signed-off-by: Nathan Froyd
> Signed-off-by: Meador Inge
> ---
> target-mips/cpu.h | 49
> +++
> target-mips/op_helper.c | 49
> ---
> target-mips/translate.c | 17 +++
> 3 files changed, 53 insertions(+), 62 deletions(-)
>
> diff --git a/target-mips/cpu.h b/target-mips/cpu.h
> index 71cb4e8..fc65348 100644
> --- a/target-mips/cpu.h
> +++ b/target-mips/cpu.h
> @@ -737,4 +737,53 @@ static inline void cpu_pc_from_tb(CPUState *env,
> TranslationBlock *tb)
> env->hflags |= tb->flags & MIPS_HFLAG_BMASK;
> }
>
> +static inline void compute_hflags(CPUState *env)
> +{
Moving helper functions like these to cpu.h has proven troublesome for
QOM'ification (when they need access to MIPSCPU[Class] in addition to
CPUMIPSState) but it'll do for now.
Reviewed-by: Andreas Färber
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] Support for Nested Paging
Hi, I am a student currently working on development of a Hypervisor for JOS Operating System. I run JOS over QEMU's emulation of x86 architecture. Currently I am planning to add Nested Page Table support to JOS. Does QEMU emulate the Nested Page Tables implemented by AMD-V architecture or the Intel VT? Also I am trying to understand the QEMU source with an objective of participating in the Google Summer of Code and contributing to QEMU. I have tried tracing through the code but seems this link http://repo.or.cz/w/qemu/stefanha.git/blob_plain/refs/heads/tracing:/docs/tracing.txt is not updated because many of the options do not work here. I would very happy if someone could provide me links to a good starting point to understand QEMU source code. Thanks, Ankur
Re: [Qemu-devel] [PATCH 0/2] linux-user: Support prctl PR_GET/SET_NAME
Hello, 2012/2/22 Peter Maydell : > Ping? In case it helps, I have successfully tested this patch running adduser on Debian armhf target emulated via qemu-arm-static. Tested-by: Hector Oron > On 3 February 2012 13:53, Peter Maydell wrote: >> These patches add support for the prctl options PR_GET_NAME >> and PR_SET_NAME. In particular, perl 5.14 will use PR_SET_NAME >> if you change the value of $0, which means that adduser will >> fail if run under qemu with a sufficiently modern perl. >> >> Patch one is just indentation cleanup, the meat is patch 2. >> >> The only other prctl options which take pointer arguments are >> all architecture specific, so there didn't seem much point in >> adding them (they all work like PR_GET_PDEATHSIG in that they >> pass an int* to be filled in); we'd have to actually emulate them >> if we cared about them. >> >> Peter Maydell (2): >> linux-user/syscall.c: Fix indentation in prctl handling >> linux-user: Add support for prctl PR_GET_NAME and PR_SET_NAME >> >> linux-user/syscall.c | 53 >> - >> 1 files changed, 39 insertions(+), 14 deletions(-) >> >> > -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
[Qemu-devel] [PATCH] PCI Using macro definition instead of a simple digit
PCI_CLASS_DISPLAY_VGA has already defined in hw/pci_ids.h, so use the
macro definition instead of a simple digit.
Signed-off-by: Wanpeng Li
---
hw/pci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index fe71666..274d86d 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1784,7 +1784,7 @@ static int pci_add_option_rom(PCIDevice *pdev, bool
is_default_rom)
* for 0.11 compatibility.
*/
int class = pci_get_word(pdev->config + PCI_CLASS_DEVICE);
-if (class == 0x0300) {
+if (class == PCI_CLASS_DISPLAY_VGA) {
rom_add_vga(pdev->romfile);
} else {
rom_add_option(pdev->romfile, -1);
--
1.7.5.4
Re: [Qemu-devel] How QEMU handle precise exception?
On Wed, Feb 29, 2012 at 12:45, 陳韋任 wrote: > Hi all, > > I would like to know how QEMU handle precise exception. Basically, QEMU need > to maintain a well-defined guest architecture state (register + memory) before > returning to the exception handler. > > For the guest register, does QEMU save the guest registers (except guest pc) > before every guest instruction which might raise exception? There are different approaches. Most registers (for example EAX on i386) in CPUState are kept in synch. Actually guest PC is not updated after every instruction, only before instructions that can cause exceptions and after each basic block. PC can be also recomputed with "search PC" function. Many targets implement lazy handling of condition codes (NZVC etc.), so they need to be computed when they are accessed. In many architectures, FPU is running more or less asynchronously to the core, but in QEMU, FPU instructions are calculated immediately. Corner cases (like STI on x86 or priority order of simultaneously active exceptions) should be also handled correctly. > For the guest memory, > is it because how QEMU does (see below) so that guest memory is in a > consistent > state when guest exception occured? > > - Emulate guest "store" memory operations in the same order as in the > original > program order. > > - Emulate all potentially trapping guest instructions in the same order with > respect to the guest store instructions. Memory operations are not reordered in any way. > > Thanks! > > Regards, > chenwj > > -- > Wei-Ren Chen (陳韋任) > Computer Systems Lab, Institute of Information Science, > Academia Sinica, Taiwan (R.O.C.) > Tel:886-2-2788-3799 #1667 > Homepage: http://people.cs.nctu.edu.tw/~chenwj >
Re: [Qemu-devel] [PATCH 6/6] kvm: Fix dirty tracking with large kernel page size
On Mon, Feb 27, 2012 at 00:36, Alexander Graf wrote: > > On 26.02.2012, at 22:41, Blue Swirl wrote: > >> On Fri, Feb 24, 2012 at 00:23, David Gibson >> wrote: >>> From: Benjamin Herrenschmidt >>> >>> If the kernel page size is larger than TARGET_PAGE_SIZE, which >>> happens for example on ppc64 with kernels compiled for 64K pages, >>> the dirty tracking doesn't work. >> >> I think a better solution would be to push this to memory API and >> underlying exec.c dirty tracking so that they use the same page size >> as kernel (only in this KVM case, in general dirty tracking should >> match TARGET_PAGE_SIZE granularity). > > Yeah, that would allow us to make sure we only align MMIO regions where we > can, but I don't think it's an easy change to make. And this way the common > page size throughout QEMU is TARGET_PAGE_SIZE, which other pieces of code > rely on. Also, dynamically changing TARGET_PAGE_SIZE has unknown performance > implications. > > So for the time being, I definitely think this is the right approach. It's > easy and isolated :). Laziness ;-) This could be the initial approach though and someone could improve upon it later. For better performance, KVM and QEMU could even share the bit maps (if the page sizes are kept in synch) so there would be no need to synchronize. But if MMU page sizes are not constant (huge pages, huge gaps), also bit map approach could be suboptimal and some other way could be needed. > > > Alex >
Re: [Qemu-devel] SPARC64: unable to boot OpenBIOS from git master
On Mon, Feb 27, 2012 at 06:36, Mark Cave-Ayland wrote: > Hi all, > > I've been experimenting with SPARC64 under QEMU, and with current git master > I am unable to boot OpenBIOS at all with the following error: > > OpenBIOS for Sparc64 > Unhandled Exception 0x0032 > PC = 0xffd19d84 NPC = 0xffd19d88 > Stopping execution > > Using git bisect indicates that the problem lies with the following commit: > > > commit d5f27e88699f14c802d66c01de70e5ea37b7153a > Author: Michael S. Tsirkin > Date: Tue Feb 21 15:57:58 2012 +0200 > > pci: set memory type for memory behind the bridge > > As we make upper bits in IO and prefetcheable memory > registers writeable, we should declare support > for 64 bit prefetcheable memory and 32 bit io > in the bridge. > > This changes the default for apb, dec, but I'm guessing > they got the defaults wrong by accident. > Alternatively, we could let bridges declare lack of > 64 bit support and make the upper bits read-only zero. > > With this applied, we can drop these bits > from express code. > > Reported-by: Gerd Hoffmann > Signed-off-by: Michael S. Tsirkin > > Could someone familiar with apb,dec ack this please? > Signed-off-by: Anthony Liguori > > > Does anyone have an idea as to whether this is something that needs to be > fixed in QEMU or OpenBIOS? No idea. Michael, should the commit be reverted? It's easy to confirm the bug, just run qemu-system-sparc64 without any arguments. Bug: black screen, no bug: yellow screen with OpenBIOS boot text. In fact, it's pretty annoying to see that even this very minimal amount of testing effort has not been spent by a critical subsystem maintainer. > > Many thanks, > > Mark. >
[Qemu-devel] [PATCH] coroutine-gthread.c: Avoid threading APIs deprecated in GLib 2.31
The GLib threading APIs were revamped in GLib 2.31 and a number
of the old interfaces were deprecated, which means they provoke
compilation warnings (errors if -Werror) now. Add support for the
new interfaces while retaining the old ones so we can still compile
on older versions of GLib too.
Signed-off-by: Peter Maydell
---
In particular, this fixes compilation failure on ARM hosts running
Ubuntu Precise. Seems kinda ugly to me, suggestions for improvement
welcomed.
coroutine-gthread.c | 96 ++-
1 files changed, 87 insertions(+), 9 deletions(-)
diff --git a/coroutine-gthread.c b/coroutine-gthread.c
index 662801b..30c24c9 100644
--- a/coroutine-gthread.c
+++ b/coroutine-gthread.c
@@ -26,13 +26,93 @@ typedef struct {
Coroutine base;
GThread *thread;
bool runnable;
+bool free_on_thread_exit;
CoroutineAction action;
} CoroutineGThread;
-static GCond *coroutine_cond;
static GStaticMutex coroutine_lock = G_STATIC_MUTEX_INIT;
+
+/* GLib 2.31 and beyond deprecated various parts of the thread API,
+ * but the new interfaces are not available in older GLib versions
+ * so we have to cope with both.
+ */
+#if GLIB_CHECK_VERSION(2, 31, 0)
+/* Default zero-initialisation is sufficient for 2.31+ GCond */
+static GCond the_coroutine_cond;
+static GCond *coroutine_cond = &the_coroutine_cond;
+static inline void init_coroutine_cond(void)
+{
+}
+
+/* Awkwardly, the GPrivate API doesn't provide a way to update the
+ * GDestroyNotify handler for the coroutine key dynamically. So instead
+ * we track whether or not the CoroutineGThread should be freed on
+ * thread exit / coroutine key update using the free_on_thread_exit
+ * field.
+ */
+static void coroutine_destroy_notify(gpointer data)
+{
+CoroutineGThread *co = data;
+if (co && co->free_on_thread_exit) {
+g_free(co);
+}
+}
+
+static GPrivate coroutine_key = G_PRIVATE_INIT(coroutine_destroy_notify);
+
+static inline CoroutineGThread *get_coroutine_key(void)
+{
+return g_private_get(&coroutine_key);
+}
+
+static inline void set_coroutine_key(CoroutineGThread *co,
+ bool free_on_thread_exit)
+{
+/* Unlike g_static_private_set() this does not call the GDestroyNotify
+ * if the previous value of the key was NULL. Fortunately we only need
+ * the GDestroyNotify in the non-NULL key case.
+ */
+co->free_on_thread_exit = free_on_thread_exit;
+g_private_replace(&coroutine_key, co);
+}
+
+static inline GThread *create_thread(GThreadFunc func, gpointer data)
+{
+return g_thread_new("coroutine", func, data);
+}
+
+#else
+
+/* Handle older GLib versions */
+static GCond *coroutine_cond;
+static inline void init_coroutine_cond(void)
+{
+coroutine_cond = g_cond_new();
+}
+
static GStaticPrivate coroutine_key = G_STATIC_PRIVATE_INIT;
+static inline CoroutineGThread *get_coroutine_key(void)
+{
+return g_static_private_get(&coroutine_key);
+}
+
+static inline void set_coroutine_key(CoroutineGThread *co,
+ bool free_on_thread_exit)
+{
+g_static_private_set(&coroutine_key, co,
+ free_on_thread_exit ? (GDestroyNotify)g_free : NULL);
+}
+
+static inline GThread *create_thread(GThreadFunc func, gpointer data)
+{
+return g_thread_create_full(func, data, 0, TRUE, TRUE,
+G_THREAD_PRIORITY_NORMAL, NULL);
+}
+
+#endif
+
+
static void __attribute__((constructor)) coroutine_init(void)
{
if (!g_thread_supported()) {
@@ -44,7 +124,7 @@ static void __attribute__((constructor)) coroutine_init(void)
#endif
}
-coroutine_cond = g_cond_new();
+init_coroutine_cond();
}
static void coroutine_wait_runnable_locked(CoroutineGThread *co)
@@ -65,7 +145,7 @@ static gpointer coroutine_thread(gpointer opaque)
{
CoroutineGThread *co = opaque;
-g_static_private_set(&coroutine_key, co, NULL);
+set_coroutine_key(co, false);
coroutine_wait_runnable(co);
co->base.entry(co->base.entry_arg);
qemu_coroutine_switch(&co->base, co->base.caller, COROUTINE_TERMINATE);
@@ -77,8 +157,7 @@ Coroutine *qemu_coroutine_new(void)
CoroutineGThread *co;
co = g_malloc0(sizeof(*co));
-co->thread = g_thread_create_full(coroutine_thread, co, 0, TRUE, TRUE,
- G_THREAD_PRIORITY_NORMAL, NULL);
+co->thread = create_thread(coroutine_thread, co);
if (!co->thread) {
g_free(co);
return NULL;
@@ -117,12 +196,11 @@ CoroutineAction qemu_coroutine_switch(Coroutine *from_,
Coroutine *qemu_coroutine_self(void)
{
-CoroutineGThread *co = g_static_private_get(&coroutine_key);
-
+CoroutineGThread *co = get_coroutine_key();
if (!co) {
co = g_malloc0(sizeof(*co));
co->runnable = true;
-g_static_private_set(&coroutine_key, co, (GDestroyNotify)g_free);
+set_coroutine_key(co, true);
}
return &co-
Re: [Qemu-devel] QEMU desired libiscsi.so clashes with libiscsi.so from iscsi-initiator-utils
On 03.03.2012 15:15, Andreas Färber wrote: > Am 03.03.2012 07:43, schrieb ronnie sahlberg: >> Yes, >> >> Very unfortuante since libiscsi is such a nice name for a >> multiplatform library what even works on win32 :-( >> >> I have so renamed it to libiscsiclient and sent a patch to qemu to >> this list to use -liscsiclient instead of -liscsi > > Mind letting us know which library exactly this clashes with (URL)? > According to Hannes there was no clash on openSUSE (which I would call a > standard Linux distro as well), so it sounded like a Fedora-specific > packaging problem to him. It looks like iscsi-initiator-utils package in fedora is built using shared libiscsi which appears to be package-specific, e.g. http://www.rpmseek.com/rpm/iscsi-initiator-utils-6.2.0.870-13.fc13.x86_64.html?hl=com&cx=0:-:0:8107228:0:0:0: Files: /sbin/iscsi-iname /sbin/iscsiadm /sbin/iscsid /sbin/iscsistart /usr/lib64/libiscsi.so.0 ... I'd rename _that_ library to be libiscsi-initiator-utils.so, to reflect the name of the package in question, since it - again - _appears_ to be package-specific. Thanks, /mjt >> tarballs can be found at >> https://github.com/sahlberg/libiscsi/downloads >> >> >> That resolves all issues you are concerned about ? >> >> >> regards >> ronnie sahlberg >> >> On Tue, Feb 14, 2012 at 12:24 AM, Daniel P. Berrange >> wrote: >>> I was investigating how to build latest QEMU with the iSCSI block driver >>> enabled. I saw that configure wanted a libiscsi.so, so I installed that >>> library from Fedora RPMs via the iscsi-initiator-utils package, but it >>> still wouldn't build. >>> >>> After further investigation, I find that QEMU in fact wants a completely >>> different, unlreated libiscsi.so library: >>> >>> https://github.com/sahlberg/libiscsi >>> >>> Obviously we have a problem here because we can't have two different >>> libraries called libiscsi.so installed at the same time. >>> >>> Since iscsi-initiator-utils is a standard Linux distro package whose usage >>> of libiscsi.so predates this github project, it seems that to resolve this >>> it will be neccessary to rename the latter. eg perhaps libiscsi-client.so ? >>> >>> The followup question is where to find actual libiscsi releases to package >>> up for OS distros ? It is not very desirable to just package GIT snapshots. >>> >>> Regards, >>> Daniel >>> -- >>> |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ >>> :| >>> |: http://libvirt.org -o- http://virt-manager.org >>> :| >>> |: http://autobuild.org -o- http://search.cpan.org/~danberr/ >>> :| >>> |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc >>> :| >
Re: [Qemu-devel] BlockDriverState stack and BlockListeners
On Wed, Feb 29, 2012 at 8:38 AM, Ori Mamluk wrote: > I think the BlockFilter direction goes very well with our plans for a > replication module. > I guess it would take some discussions and time to form a solid layer for > the BlockFilters, and I'd like to move ahead in parallel with the > replication module. Will the replicatoin module still use a custom network protocol or do you plan to implement the in-process NBD server? I have added the in-process NBD server idea to the Google Summer of Code 2012 project ideas page. Perhaps students will be interested in implementing it this summer. But if you are already working on it I can remove the idea, please let me know. Thanks, Stefan
Re: [Qemu-devel] QEMU desired libiscsi.so clashes with libiscsi.so from iscsi-initiator-utils
Am 03.03.2012 07:43, schrieb ronnie sahlberg: > Yes, > > Very unfortuante since libiscsi is such a nice name for a > multiplatform library what even works on win32 :-( > > I have so renamed it to libiscsiclient and sent a patch to qemu to > this list to use -liscsiclient instead of -liscsi Mind letting us know which library exactly this clashes with (URL)? According to Hannes there was no clash on openSUSE (which I would call a standard Linux distro as well), so it sounded like a Fedora-specific packaging problem to him. Andreas > tarballs can be found at > https://github.com/sahlberg/libiscsi/downloads > > > That resolves all issues you are concerned about ? > > > regards > ronnie sahlberg > > On Tue, Feb 14, 2012 at 12:24 AM, Daniel P. Berrange > wrote: >> I was investigating how to build latest QEMU with the iSCSI block driver >> enabled. I saw that configure wanted a libiscsi.so, so I installed that >> library from Fedora RPMs via the iscsi-initiator-utils package, but it >> still wouldn't build. >> >> After further investigation, I find that QEMU in fact wants a completely >> different, unlreated libiscsi.so library: >> >> https://github.com/sahlberg/libiscsi >> >> Obviously we have a problem here because we can't have two different >> libraries called libiscsi.so installed at the same time. >> >> Since iscsi-initiator-utils is a standard Linux distro package whose usage >> of libiscsi.so predates this github project, it seems that to resolve this >> it will be neccessary to rename the latter. eg perhaps libiscsi-client.so ? >> >> The followup question is where to find actual libiscsi releases to package >> up for OS distros ? It is not very desirable to just package GIT snapshots. >> >> Regards, >> Daniel >> -- >> |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| >> |: http://libvirt.org -o- http://virt-manager.org :| >> |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| >> |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH] Change library from libiscsi to libiscsiclient to match library rename in libiscsi
On 03.03.2012 10:38, Ronnie Sahlberg wrote:
> Signed-off-by: Ronnie Sahlberg
> ---
> configure |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/configure b/configure
> index fb0e18e..294c0c1 100755
> --- a/configure
> +++ b/configure
> @@ -2503,9 +2503,9 @@ if test "$libiscsi" != "no" ; then
> #include
> int main(void) { iscsi_create_context(""); return 0; }
> EOF
> - if compile_prog "-Werror" "-liscsi" ; then
> + if compile_prog "-Werror" "-liscsiclient" ; then
> libiscsi="yes"
> -LIBS="$LIBS -liscsi"
> +LIBS="$LIBS -liscsiclient"
>else
> if test "$libiscsi" = "yes" ; then
>feature_not_found "libiscsi"
Shouldn't we rename the feature and the --with/--without
name too here? This appears to be partial "fix" for the
name change.
For the feature, I'd suggest using --with-iscsi instead of
--with-libiscsiclient. But... dunno.
Thanks,
/mjt
Re: [Qemu-devel] buildbot failure in qemu on block_mingw32
Am 03.03.2012 03:05, schrieb q...@buildbot.b1-systems.de: The Buildbot has detected a new failure on builder block_mingw32 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/block_mingw32/builds/144 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: kraxel_rhel61 Build Reason: The Nightly scheduler named 'nightly_block' triggered this build Build Source Stamp: [branch block] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot This is not a new failure because it was already reported, and there are two identical patches which both fix it: http://patchwork.ozlabs.org/patch/143918/ http://patchwork.ozlabs.org/patch/143973/ Could someone with commit rights please commit one of these patches to QEMU git master? Thanks, Stefan Weil
