Re: [Qemu-devel] [PATCH 1/3] vmstate: add no_migrate flag to VMStateDescription
register_device_unmigratable()? Right, but can we have some continuity at least between the two interfaces? At least make the vmstate flag 'unmigratable' or rename the function to qdev_set_no_migrate(). Will rename the flag. BTW, should this be a vmstate flag or a qdev flag? vmstate. savevm.c doesn't look at the qdev tree. cheers, Gerd
Re: [Qemu-devel] [RFC v3 31/56] ac97: convert to memory API
Shouldn't it be possible to do something like:
typedef struct OldMemoryRegionOps {
MemoryRegionOps parent_ops;
CPUReadMemoryFunc *readfn[3];
CPUWriteMemoryFunc *writefn[3];
void *opaque;
} OldMemoryRegionOps;
That should allow old-style implementations to be converted without
introducing trampoline functions everywhere.
I should, I'll give it a go.
[Qemu-devel] How to run realview-pbx-a9 image in qemu
Hello, I downloaded latest qemu 0.14.1, it should support realview-pbx-a9 board now from below cmd. $ qemu-system-arm -M ?|grep Cortex-A9 realview-pbx-a9 ARM RealView Platform Baseboard Explore for Cortex-A9 Then I compiled a zImage from latest mainline with use realview-smp_defconfig as config file, but unfortunately qemu can't run with the image, I had tried the below instructions. 1. qemu-system-arm -M realview-pbx-a9 -kernel zImage -initrd initrd.img -nographic -append console=ttyAMA0 2. qemu-system-arm -M realview-pbx-a9 -m 1024M -kernel zImage -nographic -append root=/dev/nfs nfsroot=128.225.160.22:/home/work/rootfs rw console=ttyAMA0 rdinit=/sbin/init -net nic -net tap,ifname=tap0,script=no Both instructions can't work, console is hang and no informations is appeared. so I am wondering if there are something wrong about the kernel, am I choose the wrong config file for realview-pbx-a9 board? Or the native mainline kernel can't boot on qemu? Any suggestions? Thanks a lot! Regards, Xiao
Re: [Qemu-devel] PCI with Xilinx virtex-ml507 board
Hi, The emulated board and fpga config doesnt have pci. It does have a xilinx ll-temac ethernet mac though. I have patches for that, its on my todo list to post them. Right now im on the road with little access to my stuff. It'll have to wait, sorry. If you dont need a particular mac, you could try to change the dtb and qemu to instantiate a xilinx ethlite mac which qemu upstream does emulate. I suggest looking at the microblaze boards as reference. Good luck, Edgar --- Sent from my android device On Jul 11, 2011 5:31 AM, Lê Đức Tài letai_d...@yahoo.com.vn wrote: Hi, It seems that virtex board doesn't have a PCI bus emulation. I have tried to create one using ppc4xx_pci_init() function but it doesn't work. Could you help me some ideas to create PCI bus for virtex board? Or if you have already implemented PCI for virtex (I think that PCI is necessary to init Ethernet), could you send me the patch? Thank you very much, Tai
Re: [Qemu-devel] IO errors in guest caused by LTP dio test
Am 28.06.2011 10:50, schrieb Kevin Wolf: Am 27.06.2011 18:08, schrieb Andi Kleen: On Mon, Jun 27, 2011 at 05:59:41PM +0200, Kevin Wolf wrote: Am 23.06.2011 01:36, schrieb Andi Kleen: Running LTP testcases/kernel/io/direct_io/test_dma_thread_diotest7 causes IO errors in the guest. There are no IO errors on the host. Kernel Linux 3.0.0-rc* Using a standard emulated IDE -hda image. Couldn't reproduce this in a quick test with a random guest I had available. What is your complete qemu command line? Is the problem new -m 1500M -smp 2 \ -hda ~/qemu/suse-11.1-64.img\ -kernel arch/x86/boot/bzImage -append root=/dev/sda1 debug $EXTRA $@ Could it be related to the image? suse11.3-64.img: Qemu Image, Format: Qcow , Version: 1 , Disk Size could be: 83886080 * 256 bytes Oh, this is a qcow1 image? Interesting, I didn't expect that people are still using this format. :-) Definitely worth trying a raw image or at least qcow2. The old qcow1 format driver hasn't been actively maintained for quite a while now. with the 3.0 RCs or does it also happen with kernels that my existing guests are likely to have in use - say, the F15 kernel? It happened on older kernels too. I guess with virtio-blk you don't see the problems? Will try later. Ok, thanks. It looked like an IDE problem at first, but now that you mention it's a qcow1 image, I think it could just as well be an image format driver bug. No news is good news? Does it work with a different image format? Kevin
Re: [Qemu-devel] How to run realview-pbx-a9 image in qemu
On 11 July 2011 09:21, Xiao Jiang jgq...@gmail.com wrote: Hello, I downloaded latest qemu 0.14.1, it should support realview-pbx-a9 board now from below cmd. $ qemu-system-arm -M ?|grep Cortex-A9 realview-pbx-a9 ARM RealView Platform Baseboard Explore for Cortex-A9 Then I compiled a zImage from latest mainline with use realview-smp_defconfig as config file, but unfortunately qemu can't run with the image, I had tried the below instructions. 1. qemu-system-arm -M realview-pbx-a9 -kernel zImage -initrd initrd.img -nographic -append console=ttyAMA0 2. qemu-system-arm -M realview-pbx-a9 -m 1024M -kernel zImage -nographic -append root=/dev/nfs nfsroot=128.225.160.22:/home/work/rootfs rw console=ttyAMA0 rdinit=/sbin/init -net nic -net tap,ifname=tap0,script=no Both instructions can't work, console is hang and no informations is appeared. so I am wondering if there are something wrong about the kernel, am I choose the wrong config file for realview-pbx-a9 board? Or the native mainline kernel can't boot on qemu? Any suggestions? Thanks a lot! The command I use is: sudo ./arm-softmmu/qemu-system-arm -M realview-pbx-a9 -m 1024 -kernel thekernel -serial telnet::,server -append console=earlycon console=ttyS0 console=ttyAMA0 earlyprintk root=/dev/nfs nfsroot=10.1.1.1:/armroot rw ip=10.1.1.2:10.1.1.1:10.1.1.1:255.255.255.0:armqemu nfsrootdebug -net nic -net tap,ifname=tap0,script=no,downscript=no and then telnet to port to get the console. (I'm using the linaro qemu tree). Dave
Re: [Qemu-devel] How to run realview-pbx-a9 image in qemu
David Gilbert wrote: On 11 July 2011 09:21, Xiao Jiang jgq...@gmail.com wrote: Hello, I downloaded latest qemu 0.14.1, it should support realview-pbx-a9 board now from below cmd. $ qemu-system-arm -M ?|grep Cortex-A9 realview-pbx-a9 ARM RealView Platform Baseboard Explore for Cortex-A9 Then I compiled a zImage from latest mainline with use realview-smp_defconfig as config file, but unfortunately qemu can't run with the image, I had tried the below instructions. 1. qemu-system-arm -M realview-pbx-a9 -kernel zImage -initrd initrd.img -nographic -append console=ttyAMA0 2. qemu-system-arm -M realview-pbx-a9 -m 1024M -kernel zImage -nographic -append root=/dev/nfs nfsroot=128.225.160.22:/home/work/rootfs rw console=ttyAMA0 rdinit=/sbin/init -net nic -net tap,ifname=tap0,script=no Both instructions can't work, console is hang and no informations is appeared. so I am wondering if there are something wrong about the kernel, am I choose the wrong config file for realview-pbx-a9 board? Or the native mainline kernel can't boot on qemu? Any suggestions? Thanks a lot! The command I use is: sudo ./arm-softmmu/qemu-system-arm -M realview-pbx-a9 -m 1024 -kernel thekernel -serial telnet::,server -append console=earlycon console=ttyS0 console=ttyAMA0 earlyprintk root=/dev/nfs nfsroot=10.1.1.1:/armroot rw ip=10.1.1.2:10.1.1.1:10.1.1.1:255.255.255.0:armqemu nfsrootdebug -net nic -net tap,ifname=tap0,script=no,downscript=no and then telnet to port to get the console. (I'm using the linaro qemu tree). Hi Dave, Thanks you very much, I will try it :) Regards, Xiao Dave
Re: [Qemu-devel] Taking live snapshots of running VMs
On 07/09/11 00:24, Ahmed M. Azab wrote: Hi All, Is there a way to take a live memory snapshot of a running VM without freezing or stopping this VM? I explored the Qemu code and documentation and I found two ways to take a snapshot: What you are talking about is called a 'checkpoint', not a snapshot. There has been a lot of confusion around the naming, but it really helps if we try to use the right names. Checkpoints are for things you want to be able to restart, ie. with memory, snapshots are just data, ie. disks. Cheers, Jes
[Qemu-devel] [Bug 808588] Re: Netperf tests cause i82551 network down
related fix in driver: http://marc.info/?l=linux-netdevm=118859393206222w=3 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/808588 Title: Netperf tests cause i82551 network down Status in QEMU: New Bug description: 1. boot up a guest with 82551 nic # qemu-kvm -net nic,model=i82551 ... 2. launch netperf server in the guest 3.on the host for b in 32 64 128 256 512 1024 1460 2048 4096 8192 9000 16384 32768 65495 65507 do ./netperf -t TCP_STREAM -f m -H guest ip -P 0 -l 10 -- -m $b done for b in 32 64 128 256 512 1024 1460 2048 4096 8192 9000 16384 32768 65495 65507 do ./netperf -t UDP_STREAM -f m -H guest ip -P 0 -l 10 -- -m $b done Result: Guest network becomes down netperf client output: ./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 32 87380 16384 3210.97 19.61 ./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 64 87380 16384 6411.55 79.68 ./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 128 87380 1638412810.16 14.20 ./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 256 87380 1638425611.17 12.85 ./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 512 87380 1638451210.01 16.38 ./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 1024 Interrupted system call netperf: remote error 4./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 1460 establish control: are you sure there is a netserver listening on 10.66.9.39 at port 12865? establish_control could not establish the control connection from 0.0.0.0 port 0 address family AF_UNSPEC to 10.66.9.39 port 12865 address family AF_UNSPEC ./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 2048 qemu debug message: EE100 nic_receive command 0x, link 0x3d3e6822, addr 0x, size 1518 EE100 nic_can_receive 0x29a0180 EE100 nic_receive 0x29a0180 received broadcast, len=60 EE100 nic_receive Receive buffer (0 bytes) too small for data (60 bytes); data truncated EE100 nic_receive command 0x8000, link 0x37b32022, addr 0x, size 0 ^^ EE100 nic_receive receive: Running out of frames EE100 eepro100_write1 addr=Command/Status+1 val=0x20 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/808588/+subscriptions
Re: [Qemu-devel] [PATCH 2/2] qemu-io: Fix if scoping bug
On Mon, Jul 11, 2011 at 6:25 AM, Devin Nakamura devin...@gmail.com wrote:
diff --git a/qemu-io.c b/qemu-io.c
index e484f40..85cfe27 100644
--- a/qemu-io.c
+++ b/qemu-io.c
@@ -449,7 +449,7 @@ static int read_f(int argc, char **argv)
return 0;
}
- if (!pflag)
+ if (!pflag) {
if (offset 0x1ff) {
printf(offset % PRId64 is not sector aligned\n,
offset);
Wait, this is not enough. The indentation and curlies are so broken
here :). The if (offset 0x1ff) statement needs a closing curly.
The code should be:
if (!pflag) {
if (offset 0x1ff) {
printf(offset % PRId64 is not sector aligned\n,
offset);
return 0;
}
if (count 0x1ff) {
printf(count %d is not sector aligned\n,
count);
return 0;
}
}
Stefan
[Qemu-devel] qdev for programmers writeup
Hi,
this is a partial version of a qdev for programmers document I've been
working on. Comments are welcome.
Paolo
- 8 -
== qdev overview and concepts ==
qdev is the factory interface that QEMU uses to create guest devices and
connect them to each other. It also provides a uniform way to expose host
devices (character, network and block) to the guest. In the remainder,
unless specified explicitly, device will refer to _guest_ devices.
qdev exposes a device tree that alternates buses (qbuses) and devices
(qdevs). The root of the tree is the system bus SysBus. Devices can be
leaves, or they can expose buses and talk to the devices on those buses.
Such relation does not cover host counterparts of the devices, which
are not part of the device tree.
A device's interaction occurs by invoking services specific to the kind of
bus. In general, if a device or bus X wants to requests something from Y,
X needs to know the type of Y, and of course needs to have a pointer to
it. In a properly qdevified board, these assumptions hold:
- qdev enforces what bus a device is placed on;
- buses are not user-visible;
- initialization of buses is driven exclusively by the parent device, and
initialization of devices is driven by the parent bus and a well-defined
set of properties (defined per-device);
- buses do not know what device exposes them;
- devices do not know what device exposes their bus.
With these assumptions in place, leaf devices are the simplest to understand.
They only make requests to the bus and/or to the character/block/network
subsystems; and possibly, they provide services (routines) used by
the bus and the grandparent device.
Intermediate devices also have to provide glue between their parent bus
and their child bus(es), and buses likewise glue two devices. Depending
on the kind of bus and the relationship of a device with the bus (parent
or child), different sets of services may be defined. For example, a SCSI
bus mediates many kinds of interaction:
- from a SCSI controller to a SCSI device (e.g., start process this
command);
- from a SCSI bus to a child device (e.g., cancel this command due to a
bus reset);
- from a SCSI bus to its parent controller (e.g., this piece of data was
sent to you by a SCSI device);
- from a SCSI controller to its child bus (e.g., I dealt with this data,
please transfer more);
- from a SCSI device to its parent bus (e.g., please pass this data on
to the controller);
In general, the following rules and best practices are common:
- devices interact with their parent bus, and vice versa;
- buses interact with their parent devices, and vice versa;
- occasionally, devices may interact directly with their grandchildren
devices, but _not_ vice versa; interaction with the grandfather
device is mediated by the parent bus;
- in addition, devices interact freely with their host counterparts
(that is, character/block/network devices).
qdev defines a set of data structures, and devices use them to expose
metainformation to the rest of QEMU and to the user. The qdev system
is object-oriented; qdev data structures can be subclassed and used to
store additional information, including function pointers for bus-
specific services. The remainder of this document explains how to
define and use these data structures.
== Implementation techniques ==
qdev exposes an object-oriented mechanism in C through containment (C
replacement for inheritance, so to speak) and tries to make this
as type-safe as possible by leveraging the DO_UPCAST macro.
Sample structure definitions for a superclass and subclass are as follows:
typedef struct Superclass {
int field1;
int field2;
struct Superclass *field3;
} Superclass;
typedef struct Subclass {
struct Superclass sup;
int subfield1;
int subfield2;
} Subclass;
In many cases, C programmers pass such objects using an opaque pointer
(void *). These are then casted to the appropriate subtype like
void func (void *opaque)
{
Subclass *s = (Subclass *) opaque;
...
}
QEMU prefers to always use a more type-safe approach that passes the
pointer to the superclass. The cast is then done using the
aforementioned macro:
void func (Superclass *state)
{
/* more typesafe version of (Subclass *) state, that also
verifies that state-sup == state.
- First argument: subclass type.
- Second argument: field being accessed.
- Third argument: variable being casted. */
Subclass *sub = DO_UPCAST(Subclass, sup, state);
}
Casts to a superclass are done with state-sup. This scheme is quite
handy to use, even though may be a bit strange-looking at the beginning.
== qdev data structures ==
This part of the document explains the data structures used by qdev.
These include the class hierarchies for
Re: [Qemu-devel] qdev for programmers writeup
On 11 July 2011 11:20, Paolo Bonzini pbonz...@redhat.com wrote: This is cool; more qdev documentation is really useful. One point I'd like clarification on is when you need to invent a new bus type. Sometimes it's pretty obvious because there's a real hardware bus type there (PCI, SCSI) that you're modelling. It's the edge cases I find confusing -- for instance, do we need a qbus for the connection between an SD card controller and the SD card model (hw/sd.c) ? There's a well defined pluggable interface between those two parts but there's only ever one SD card so a bus would be a bit odd. The first step is very important to achieve a quality conversion to qdev. QEMU includes partial conversions to qdev that have a large amount of SysBus devices, or devices that use DEFINE_PROP_PTR. In many cases, this is because the authors did not introduce a board-specific bus type to mediate access to the board resources. Together with such a bus type there should be a single root board-specific device that is attached to SysBus. An interrupt controller is usually a good candidate for this because it takes qemu_irqs from the outside, and can make good use of the specificities of SysBus. ...and this bit I don't understand. Why is SysBus a bad thing? It generally seems to me to be the right way to represent a bit of hardware which is fundamentally providing a memory mapped interface plus some GPIO lines. If you make your board use sysbus then it's easy to just plug in any existing sysbus device model qemu already has; if every board has its own bus type instead then this reuse just becomes unnecessarily harder, it seems to me. Also having the interrupt controller be the board specific device which you attach to sysbus seems totally wrong to me. This doesn't match hardware at all -- the interrupt controller deals with interrupt lines and isn't in the path for memory transactions at all. (The hierarchy for memory accesses may be completely different from how interrupts are wired, for that matter.) -- PMM
Re: [Qemu-devel] [RFC v3 31/56] ac97: convert to memory API
On 07/11/2011 04:42 AM, Anthony Liguori wrote:
On 07/10/2011 03:33 PM, malc wrote:
On Sun, 10 Jul 2011, Avi Kivity wrote:
fixes BAR sizing as well.
I find this patch disgusting, the read and write handlers in particular.
Shouldn't it be possible to do something like:
typedef struct OldMemoryRegionOps {
MemoryRegionOps parent_ops;
CPUReadMemoryFunc *readfn[3];
CPUWriteMemoryFunc *writefn[3];
void *opaque;
} OldMemoryRegionOps;
That should allow old-style implementations to be converted without
introducing trampoline functions everywhere.
Here's a new version:
diff --git a/hw/ac97.c b/hw/ac97.c
index 0b59896..b4f377d 100644
--- a/hw/ac97.c
+++ b/hw/ac97.c
@@ -160,8 +160,9 @@ typedef struct AC97LinkState {
SWVoiceIn *voice_mc;
int invalid_freq[3];
uint8_t silence[128];
-uint32_t base[2];
int bup_flag;
+MemoryRegion io_nam;
+MemoryRegion io_nabm;
} AC97LinkState;
enum {
@@ -583,7 +584,7 @@ static uint32_t nam_readw (void *opaque, uint32_t addr)
{
AC97LinkState *s = opaque;
uint32_t val = ~0U;
-uint32_t index = addr - s-base[0];
+uint32_t index = addr;
s-cas = 0;
val = mixer_load (s, index);
return val;
@@ -611,7 +612,7 @@ static void nam_writeb (void *opaque, uint32_t addr,
uint32_t val)
static void nam_writew (void *opaque, uint32_t addr, uint32_t val)
{
AC97LinkState *s = opaque;
-uint32_t index = addr - s-base[0];
+uint32_t index = addr;
s-cas = 0;
switch (index) {
case AC97_Reset:
@@ -714,7 +715,7 @@ static uint32_t nabm_readb (void *opaque, uint32_t addr)
{
AC97LinkState *s = opaque;
AC97BusMasterRegs *r = NULL;
-uint32_t index = addr - s-base[1];
+uint32_t index = addr;
uint32_t val = ~0U;
switch (index) {
@@ -769,7 +770,7 @@ static uint32_t nabm_readw (void *opaque, uint32_t addr)
{
AC97LinkState *s = opaque;
AC97BusMasterRegs *r = NULL;
-uint32_t index = addr - s-base[1];
+uint32_t index = addr;
uint32_t val = ~0U;
switch (index) {
@@ -798,7 +799,7 @@ static uint32_t nabm_readl (void *opaque, uint32_t addr)
{
AC97LinkState *s = opaque;
AC97BusMasterRegs *r = NULL;
-uint32_t index = addr - s-base[1];
+uint32_t index = addr;
uint32_t val = ~0U;
switch (index) {
@@ -848,7 +849,7 @@ static void nabm_writeb (void *opaque, uint32_t
addr, uint32_t val)
{
AC97LinkState *s = opaque;
AC97BusMasterRegs *r = NULL;
-uint32_t index = addr - s-base[1];
+uint32_t index = addr;
switch (index) {
case PI_LVI:
case PO_LVI:
@@ -904,7 +905,7 @@ static void nabm_writew (void *opaque, uint32_t
addr, uint32_t val)
{
AC97LinkState *s = opaque;
AC97BusMasterRegs *r = NULL;
-uint32_t index = addr - s-base[1];
+uint32_t index = addr;
switch (index) {
case PI_SR:
case PO_SR:
@@ -924,7 +925,7 @@ static void nabm_writel (void *opaque, uint32_t
addr, uint32_t val)
{
AC97LinkState *s = opaque;
AC97BusMasterRegs *r = NULL;
-uint32_t index = addr - s-base[1];
+uint32_t index = addr;
switch (index) {
case PI_BDBAR:
case PO_BDBAR:
@@ -1230,31 +1231,33 @@ static const VMStateDescription vmstate_ac97 = {
}
};
-static void ac97_map (PCIDevice *pci_dev, int region_num,
- pcibus_t addr, pcibus_t size, int type)
-{
-AC97LinkState *s = DO_UPCAST (AC97LinkState, dev, pci_dev);
-PCIDevice *d = s-dev;
-
-if (!region_num) {
-s-base[0] = addr;
-register_ioport_read (addr, 256 * 1, 1, nam_readb, d);
-register_ioport_read (addr, 256 * 2, 2, nam_readw, d);
-register_ioport_read (addr, 256 * 4, 4, nam_readl, d);
-register_ioport_write (addr, 256 * 1, 1, nam_writeb, d);
-register_ioport_write (addr, 256 * 2, 2, nam_writew, d);
-register_ioport_write (addr, 256 * 4, 4, nam_writel, d);
-}
-else {
-s-base[1] = addr;
-register_ioport_read (addr, 64 * 1, 1, nabm_readb, d);
-register_ioport_read (addr, 64 * 2, 2, nabm_readw, d);
-register_ioport_read (addr, 64 * 4, 4, nabm_readl, d);
-register_ioport_write (addr, 64 * 1, 1, nabm_writeb, d);
-register_ioport_write (addr, 64 * 2, 2, nabm_writew, d);
-register_ioport_write (addr, 64 * 4, 4, nabm_writel, d);
-}
-}
+static const MemoryRegionPortio nam_portio[] = {
+{ 0, 256 * 1, 1, .read = nam_readb, },
+{ 0, 256 * 2, 2, .read = nam_readw, },
+{ 0, 256 * 4, 4, .read = nam_readl, },
+{ 0, 256 * 1, 1, .write = nam_writeb, },
+{ 0, 256 * 2, 2, .write = nam_writew, },
+{ 0, 256 * 4, 4, .write = nam_writel, },
+PORTIO_END,
+};
+
+static MemoryRegionOps ac97_io_nam_ops = {
+.old_portio = nam_portio,
+};
+
+static const MemoryRegionPortio nabm_portio[] = {
+{ 0, 64 * 1, 1, .read = nabm_readb, },
+{ 0, 64 * 2, 2, .read = nabm_readw, },
+{ 0, 64 * 4, 4, .read = nabm_readl, },
+{ 0, 64 * 1, 1,
Re: [Qemu-devel] [PATCH 1/1] virtio-console: Prevent abort()s in case of host chardev close
Amit Shah amit.s...@redhat.com writes:
A host chardev could close just before the guest sends some data to be
written. This will cause an -EPIPE error. This shouldn't be propagated
to virtio-serial-bus.
Ideally we should close the port once -EPIPE is received, but since the
chardev interface doesn't return such meaningful values to its users,
all we get is -1 for any kind of error. Just return 0 for now and wait
for chardevs to return better error messages to act better on the return
messages.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-console.c | 20 ++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/hw/virtio-console.c b/hw/virtio-console.c
index b076331..a25c29e 100644
--- a/hw/virtio-console.c
+++ b/hw/virtio-console.c
@@ -24,8 +24,24 @@ typedef struct VirtConsole {
static ssize_t flush_buf(VirtIOSerialPort *port, const uint8_t *buf, size_t
len)
{
VirtConsole *vcon = DO_UPCAST(VirtConsole, port, port);
-
-return qemu_chr_write(vcon-chr, buf, len);
+ssize_t ret;
+
+ret = qemu_chr_write(vcon-chr, buf, len);
+if (ret 0 ret != -EAGAIN) {
+/*
+ * Ideally we'd get a better error code than just -1, but
+ * that's what the chardev interface gives us right now. If
+ * we had a finer-grained message, like -EPIPE, we could close
+ * this connection. Absent such error messages, the most we
+ * can do is to return 0 here.
+ *
+ * This will prevent stray -1 values to go to
+ * virtio-serial-bus.c and cause abort()s in
+ * do_flush_queued_data().
+ */
+ret = 0;
+}
+return ret;
}
/* Callback function that's called when the guest opens the port */
qemu_chr_write() is the obvious wrapper around the chr_write() method.
What's the contract for that method? Specifically, is the error value
-1, -errno, or any negative value?
Unless it's -errno, we should *not* test for -EAGAIN here.
What's the impact of silently ignoring errors other than EPIPE?
[Qemu-devel] [Bug 808737] [NEW] No option to load additional binary files from command line in QEMU
Public bug reported: There is no command line option like -kerner, or -initrd to load an arbitrary binary file to a RAM location when launching QEMU. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/808737 Title: No option to load additional binary files from command line in QEMU Status in QEMU: New Bug description: There is no command line option like -kerner, or -initrd to load an arbitrary binary file to a RAM location when launching QEMU. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/808737/+subscriptions
[Qemu-devel] KVM call egenda for July 12
Hi Please send in any agenda items you are interested in covering. Later, Juan.
Re: [Qemu-devel] [PATCH 0/2] netdev fixes
Markus Armbruster arm...@redhat.com writes: Ping? Could someone please take pity and review or commit this? Thanks.
Re: [Qemu-devel] qdev for programmers writeup
On 07/11/2011 12:46 PM, Peter Maydell wrote:
One point I'd like clarification on is when you need to invent
a new bus type.
As rarely as possible, but as often as necessary? :P
New buses limit reusability of the models, but you need one whenever the
existing buses do not express how two devices interact.
Sometimes it's pretty obvious because there's
a real hardware bus type there (PCI, SCSI) that you're modelling.
It's the edge cases I find confusing -- for instance, do we need
a qbus for the connection between an SD card controller and the
SD card model (hw/sd.c) ? There's a well defined pluggable interface
between those two parts but there's only ever one SD card so a bus
would be a bit odd.
Perhaps not and you can use containment. A very similar case is the
16550 device, which has both an ISA (ioport-based) interface and a
generic memory-mapped interface. Anthony at some point argued that if
serial_mm_init was qdev-ified, one should describe SerialState as a
separate 16550 device, and then put a bus between {isa,mm}-serial and
thisg 16550 device. But perhaps including a SerialState struct into
both ISASerialState and the (hypothetical) MMSerialState is enough.
I think you have to look at the properties of the child device and the
interfaces between the devices. For SerialState, the properties would
be chardev and baudbase, and just a qemu_irq between the parent and
child. For SDState, the only property of the SDState would be the
blockdev, and again a couple GPIO pins between the two.
It probably would be feasible to separate the two. But then without a
clean plan about hiding such internal devices, it is likely a useless
complication for the user to see the existence of the SerialState and
SDState.
Together with such
a bus type there should be a single root board-specific device that is
attached to SysBus. An interrupt controller is usually a good candidate
for this because it takes qemu_irqs from the outside, and can make good
use of the specificities of SysBus.
...and this bit I don't understand. Why is SysBus a bad thing?
1) because SysBus devices are in general not accessible from the
command-line or configuration files.
2) because SysBus hardcodes in the source code some things that ought to
be device properties, for example the MMIO base address. The presence
of MMIO in sysbus_create_simple/sysbus_create_varargs is totally
unnecessary IMHO.
It generally seems to me to be the right way to represent a bit of
hardware which is fundamentally providing a memory mapped interface
plus some GPIO lines. If you make your board use sysbus then it's
easy to just plug in any existing sysbus device model qemu already
has; if every board has its own bus type instead then this reuse
just becomes unnecessarily harder, it seems to me.
That's true, but the only way to plug in those device models would be
with C code. You cannot just play with -device to reconfigure them.
It's not like SysBus has any problem; but it is right now the only
choice you have if you want a reusable model, and that means that
reusability can only be done at the cost of rebuilding QEMU.
For example, one reusable device is gpio_i2c. However, I cannot simply
take it and add it to a new board. I need to add glue like this:
/* dev is my GPIO device. */
i2c_dev = sysbus_create_simple(gpio_i2c, -1, NULL);
qdev_connect_gpio_out(i2c_dev, 0, qdev_get_gpio_in(dev, 29));
qdev_connect_gpio_out(dev, 3, qdev_get_gpio_in(i2c_dev, 0));
qdev_connect_gpio_out(dev, 4, qdev_get_gpio_in(i2c_dev, 1));
and recompile QEMU.
In fact, perhaps qdev_{connect_gpio_out,get_gpio_in} should never have
been public. Imagine we added to qdev GPIO properties and we used them
like this in gpio_i2c:
/* gpio_out=N means connect my 0th output pin to the parent's
N-th input pin. */
DEFINE_PROP_GPIO_OUT(gpio_out, 0),
/* gpio_in=N means connect my 0th input pin to the parent's
N-th output pin. */
DEFINE_PROP_GPIO_IN(gpio_in, 0),
DEFINE_PROP_GPIO_IN(gpio_clk, 1)
Then we define a GPIOBus that is really a bare-bones BusState, with no
MMIO and nothing. However, GPIO chips would expose one such bus, and a
lot of reusable components could be moved from SysBus to GPIOBus... and
get -device configuration at once! With this in place you can do:
-device gpio_i2c,gpio_out=29,gpio_in=3,gpio_clk=4
or in a configuration file:
[device gpio_i2c]
gpio_out = 29
gpio_in = 3
gpio_clk = 4
or if you really have to do it in C:
dev = qdev_create(gpiobus-bus, gpio_i2c);
qdev_set_prop_set_gpio_out(gpio_out, 29);
qdev_set_prop_set_gpio_in(gpio_in, 3);
qdev_set_prop_set_gpio_in(gpio_clk, 4);
qdev_init_nofail(dev);
Even the C code would already be an improvement, because the client code
has no idea of the pin numbers of gpio_i2c.
Note that gpio_i2c is already a well-defined device, and it uses only a
bunch of qdev
Re: [Qemu-devel] live block copy/stream/snapshot discussion
On Tue, Jul 05, 2011 at 05:17:49PM +0300, Dor Laor wrote: Anthony advised to clone http://wiki.qemu.org/index.php?title=Features/LiveBlockMigrationFuture to the list in order to encourage discussion, so here it is: qemu is expected to support these features (some already implemented): = Live features = == Live block copy == Ability to copy 1+ virtual disk from the source backing file/block device to a new target that is accessible by the host. The copy supposed to be executed while the VM runs in a transparent way. == Live snapshots and live snapshot merge == Live snapshot is already incorporated (by Jes) in qemu (still need virt-agent work to freeze the guest FS). Live snapshot merge is required in order of reducing the overhead caused by the additional snapshots (sometimes over raw device). We'll use live copy to do the live merge This line seems outdated. Kevin and Marcelo have suggested a separate live commit operation that does not use the unified block copy/image streaming mechanism. = Solutions = == Non shared storage == Either use iscsi (target and initiator) or NBD or proprietary qemu solution. iScsi in theory is the best but there is a problem of dealing with COW images - iScsi cannot report the COW level and detect un-allocated blocks. This might force us to use proprietary solution. An interesting option (by Orit Wasserman) was to use iScsi for exporting the images externally to qemu level and qemu will access as if they were a local device. This can work well w/o almost any effort. What do we do with chains of COW files? We create up to N such iscsi connections for every COW file in the chain. If there is a discovery mechanism to locate LUNs then it would be possible to use this approach. However, using iSCSI but placing all the copy-on-write intelligence into the QEMU initiator is overkill since we need to support SAN/NAS appliances that provide snapshots, copy-on-write, and thin provisioning anyway. If you look at what other hypervisors are doing, they are trying to offload as much storage processing onto the appliance as possible. We probably want the appliance to do those operations for us, so implementing them in the initiator for some cases is duplicating that code and making the system more complex. The real problem is that we're lacking a library interface to manage volumes, including snapshots. I don't think that QEMU needs to drive this interface. It should be libvirt (which deals with storage pools and volumes today already). Once we do have an interface defined, I think it makes less sense implementing all of this in QEMU when this storage management functionality really belongs in NAS/SAN appliances and software targets. == Live block migration == Use the streaming approach + regular live migration + iscsi: Execute regular live migration and at the end of it, start streaming. If there is no shared storage, use the external iscsi and behave as if the image is local. At the end of the streaming operation there will be a new local base image. == Block mirror layer == Was invented in order to duplicate write IOs for the source and destination images. It prevents the potential race when both qemu and the management crash at the end of the block copy stage and it is unknown whether management should pick the source or the destination == Streaming == No need for mirror since only the destination changes and is writable. == Block copy background task == Can be shared between block copy and streaming == Live snapshot == It can be seen as a (local) stream that preserve the current COW chain = Use cases = 1. Basic streaming, single base master image on source storage, need to be instantiated on destination storage The base image is a single level COW format (file or lvm). The base is RO and only new destination is RW. base' is empty at the beginning. The base image content is being copied in the background to base'. At the end of the operation, base' is a standalone image w/o depending on the base image. a. Case of a shared storage streaming guest boot Before: src storage: base dst storage: none After src storage: base dst storage: base' b. Case of no shared storage streaming guest boot Every thing is the same, we use external iscsi target on the src host and external iscsi initiator on the destination host. Qemu boots from the destination by using the iscsi access. This is transparent to qemu (expect cmd syntax change ). Once the streaming is over, we can live drop the usage of iscsi and open the image directly (some sort of null live copy) c. Live
[Qemu-devel] [PATCH 0/4] scsi fixes
Hi all, these are some fixes I found during debugging my megasas HBA emulation. This time I've sent them as a separate patchset for inclusion. All of them have been acked, so please apply. Hannes Reinecke (4): iov: Update parameter usage in iov_(to|from)_buf() scsi: Add 'hba_private' to SCSIRequest scsi-disk: Fixup debugging statement scsi-disk: Mask out serial number EVPD hw/esp.c |2 +- hw/lsi53c895a.c| 22 +++- hw/scsi-bus.c |9 +-- hw/scsi-disk.c | 21 ++- hw/scsi-generic.c |5 ++- hw/scsi.h | 10 ++-- hw/spapr_vscsi.c | 29 --- hw/usb-msd.c |9 +--- hw/virtio-net.c|2 +- hw/virtio-serial-bus.c |2 +- iov.c | 49 ++- iov.h | 10 12 files changed, 84 insertions(+), 86 deletions(-) -- 1.7.3.4
[Qemu-devel] [PATCH 1/4] iov: Update parameter usage in iov_(to|from)_buf()
iov_to_buf() has an 'offset' parameter, iov_from_buf() hasn't.
This patch adds the missing parameter to iov_from_buf().
It also renames the 'offset' parameter to 'iov_off' to
emphasize it's the offset into the iovec and not the buffer.
Signed-off-by: Hannes Reinecke h...@suse.de
Acked-by: Alexander Graf ag...@suse.de
---
hw/virtio-net.c|2 +-
hw/virtio-serial-bus.c |2 +-
iov.c | 49 ++-
iov.h | 10
4 files changed, 34 insertions(+), 29 deletions(-)
diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index 6997e02..a32cc01 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -657,7 +657,7 @@ static ssize_t virtio_net_receive(VLANClientState *nc,
const uint8_t *buf, size_
/* copy in packet. ugh */
len = iov_from_buf(sg, elem.in_num,
- buf + offset, size - offset);
+ buf + offset, 0, size - offset);
total += len;
offset += len;
/* If buffers can't be merged, at this point we
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index 7f6db7b..53c58d0 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -103,7 +103,7 @@ static size_t write_to_port(VirtIOSerialPort *port,
}
len = iov_from_buf(elem.in_sg, elem.in_num,
- buf + offset, size - offset);
+ buf + offset, 0, size - offset);
offset += len;
virtqueue_push(vq, elem, len);
diff --git a/iov.c b/iov.c
index 588cd04..1e02791 100644
--- a/iov.c
+++ b/iov.c
@@ -14,56 +14,61 @@
#include iov.h
-size_t iov_from_buf(struct iovec *iov, unsigned int iovcnt,
-const void *buf, size_t size)
+size_t iov_from_buf(struct iovec *iov, unsigned int iov_cnt,
+const void *buf, size_t iov_off, size_t size)
{
-size_t offset;
+size_t iovec_off, buf_off;
unsigned int i;
-offset = 0;
-for (i = 0; offset size i iovcnt; i++) {
-size_t len;
+iovec_off = 0;
+buf_off = 0;
+for (i = 0; i iov_cnt size; i++) {
+if (iov_off (iovec_off + iov[i].iov_len)) {
+size_t len = MIN((iovec_off + iov[i].iov_len) - iov_off, size);
-len = MIN(iov[i].iov_len, size - offset);
+memcpy(iov[i].iov_base + (iov_off - iovec_off), buf + buf_off,
len);
-memcpy(iov[i].iov_base, buf + offset, len);
-offset += len;
+buf_off += len;
+iov_off += len;
+size -= len;
+}
+iovec_off += iov[i].iov_len;
}
-return offset;
+return buf_off;
}
-size_t iov_to_buf(const struct iovec *iov, const unsigned int iovcnt,
- void *buf, size_t offset, size_t size)
+size_t iov_to_buf(const struct iovec *iov, const unsigned int iov_cnt,
+ void *buf, size_t iov_off, size_t size)
{
uint8_t *ptr;
-size_t iov_off, buf_off;
+size_t iovec_off, buf_off;
unsigned int i;
ptr = buf;
-iov_off = 0;
+iovec_off = 0;
buf_off = 0;
-for (i = 0; i iovcnt size; i++) {
-if (offset (iov_off + iov[i].iov_len)) {
-size_t len = MIN((iov_off + iov[i].iov_len) - offset , size);
+for (i = 0; i iov_cnt size; i++) {
+if (iov_off (iovec_off + iov[i].iov_len)) {
+size_t len = MIN((iovec_off + iov[i].iov_len) - iov_off , size);
-memcpy(ptr + buf_off, iov[i].iov_base + (offset - iov_off), len);
+memcpy(ptr + buf_off, iov[i].iov_base + (iov_off - iovec_off),
len);
buf_off += len;
-offset += len;
+iov_off += len;
size -= len;
}
-iov_off += iov[i].iov_len;
+iovec_off += iov[i].iov_len;
}
return buf_off;
}
-size_t iov_size(const struct iovec *iov, const unsigned int iovcnt)
+size_t iov_size(const struct iovec *iov, const unsigned int iov_cnt)
{
size_t len;
unsigned int i;
len = 0;
-for (i = 0; i iovcnt; i++) {
+for (i = 0; i iov_cnt; i++) {
len += iov[i].iov_len;
}
return len;
diff --git a/iov.h b/iov.h
index 60a8547..110f67a 100644
--- a/iov.h
+++ b/iov.h
@@ -12,8 +12,8 @@
#include qemu-common.h
-size_t iov_from_buf(struct iovec *iov, unsigned int iovcnt,
-const void *buf, size_t size);
-size_t iov_to_buf(const struct iovec *iov, const unsigned int iovcnt,
- void *buf, size_t offset, size_t size);
-size_t iov_size(const struct iovec *iov, const unsigned int iovcnt);
+size_t iov_from_buf(struct iovec *iov, unsigned int iov_cnt,
+const void *buf, size_t iov_off, size_t size);
+size_t iov_to_buf(const struct iovec *iov, const unsigned int iov_cnt,
+ void *buf, size_t iov_off, size_t size);
+size_t iov_size(const struct iovec *iov, const unsigned int iov_cnt);
--
1.7.3.4
[Qemu-devel] [PATCH 2/4] scsi: Add 'hba_private' to SCSIRequest
'tag' is just an abstraction to identify the command
from the driver. So we should make that explicit by
replacing 'tag' with a driver-defined pointer 'hba_private'.
This saves the lookup for driver handling several commands
in parallel.
'tag' is still being kept for tracing purposes.
Signed-off-by: Hannes Reinecke h...@suse.de
Acked-by: Paolo Bonzini pbonz...@redhat.com
---
hw/esp.c |2 +-
hw/lsi53c895a.c | 22 --
hw/scsi-bus.c |9 ++---
hw/scsi-disk.c|4 ++--
hw/scsi-generic.c |5 +++--
hw/scsi.h | 10 +++---
hw/spapr_vscsi.c | 29 +
hw/usb-msd.c |9 +
8 files changed, 37 insertions(+), 53 deletions(-)
diff --git a/hw/esp.c b/hw/esp.c
index 8e95672..69209bd 100644
--- a/hw/esp.c
+++ b/hw/esp.c
@@ -244,7 +244,7 @@ static void do_busid_cmd(ESPState *s, uint8_t *buf, uint8_t
busid)
DPRINTF(do_busid_cmd: busid 0x%x\n, busid);
lun = busid 7;
-s-current_req = scsi_req_new(s-current_dev, 0, lun);
+s-current_req = scsi_req_new(s-current_dev, 0, lun, NULL);
datalen = scsi_req_enqueue(s-current_req, buf);
s-ti_size = datalen;
if (datalen != 0) {
diff --git a/hw/lsi53c895a.c b/hw/lsi53c895a.c
index 940b43a..69eec1d 100644
--- a/hw/lsi53c895a.c
+++ b/hw/lsi53c895a.c
@@ -661,7 +661,7 @@ static lsi_request *lsi_find_by_tag(LSIState *s, uint32_t
tag)
static void lsi_request_cancelled(SCSIRequest *req)
{
LSIState *s = DO_UPCAST(LSIState, dev.qdev, req-bus-qbus.parent);
-lsi_request *p;
+lsi_request *p = req-hba_private;
if (s-current req == s-current-req) {
scsi_req_unref(req);
@@ -670,7 +670,6 @@ static void lsi_request_cancelled(SCSIRequest *req)
return;
}
-p = lsi_find_by_tag(s, req-tag);
if (p) {
QTAILQ_REMOVE(s-queue, p, next);
scsi_req_unref(req);
@@ -680,18 +679,12 @@ static void lsi_request_cancelled(SCSIRequest *req)
/* Record that data is available for a queued command. Returns zero if
the device was reselected, nonzero if the IO is deferred. */
-static int lsi_queue_tag(LSIState *s, uint32_t tag, uint32_t len)
+static int lsi_queue_req(LSIState *s, SCSIRequest *req, uint32_t len)
{
-lsi_request *p;
-
-p = lsi_find_by_tag(s, tag);
-if (!p) {
-BADF(IO with unknown tag %d\n, tag);
-return 1;
-}
+lsi_request *p = req-hba_private;
if (p-pending) {
-BADF(Multiple IO pending for tag %d\n, tag);
+BADF(Multiple IO pending for request %p\n, p);
}
p-pending = len;
/* Reselect if waiting for it, or if reselection triggers an IRQ
@@ -743,9 +736,9 @@ static void lsi_transfer_data(SCSIRequest *req, uint32_t
len)
LSIState *s = DO_UPCAST(LSIState, dev.qdev, req-bus-qbus.parent);
int out;
-if (s-waiting == 1 || !s-current || req-tag != s-current-tag ||
+if (s-waiting == 1 || !s-current || req-hba_private != s-current ||
(lsi_irq_on_rsl(s) !(s-scntl1 LSI_SCNTL1_CON))) {
-if (lsi_queue_tag(s, req-tag, len)) {
+if (lsi_queue_req(s, req, len)) {
return;
}
}
@@ -789,7 +782,8 @@ static void lsi_do_command(LSIState *s)
assert(s-current == NULL);
s-current = qemu_mallocz(sizeof(lsi_request));
s-current-tag = s-select_tag;
-s-current-req = scsi_req_new(dev, s-current-tag, s-current_lun);
+s-current-req = scsi_req_new(dev, s-current-tag, s-current_lun,
+ s-current);
n = scsi_req_enqueue(s-current-req, buf);
if (n) {
diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c
index ad6a730..8b1a412 100644
--- a/hw/scsi-bus.c
+++ b/hw/scsi-bus.c
@@ -131,7 +131,8 @@ int scsi_bus_legacy_handle_cmdline(SCSIBus *bus)
return res;
}
-SCSIRequest *scsi_req_alloc(size_t size, SCSIDevice *d, uint32_t tag, uint32_t
lun)
+SCSIRequest *scsi_req_alloc(size_t size, SCSIDevice *d, uint32_t tag,
+uint32_t lun, void *hba_private)
{
SCSIRequest *req;
@@ -141,14 +142,16 @@ SCSIRequest *scsi_req_alloc(size_t size, SCSIDevice *d,
uint32_t tag, uint32_t l
req-dev = d;
req-tag = tag;
req-lun = lun;
+req-hba_private = hba_private;
req-status = -1;
trace_scsi_req_alloc(req-dev-id, req-lun, req-tag);
return req;
}
-SCSIRequest *scsi_req_new(SCSIDevice *d, uint32_t tag, uint32_t lun)
+SCSIRequest *scsi_req_new(SCSIDevice *d, uint32_t tag, uint32_t lun,
+ void *hba_private)
{
-return d-info-alloc_req(d, tag, lun);
+return d-info-alloc_req(d, tag, lun, hba_private);
}
uint8_t *scsi_req_get_buf(SCSIRequest *req)
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index a8c7372..c2a99fe 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -81,13 +81,13 @@ static int scsi_handle_rw_error(SCSIDiskReq *r, int error,
int type);
static int scsi_disk_emulate_command(SCSIDiskReq *r, uint8_t *outbuf);
static
[Qemu-devel] [PATCH] vhost build fix for i386
vhost.c uses __sync_fetch_and_and(), which is only
available for -march=i486 and above (see
https://bugzilla.redhat.com/show_bug.cgi?id=624279).
Signed-off-by: Wolfgang Mauerer wolfgang.maue...@siemens.com
---
configure | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/configure b/configure
index 88159ac..3b6facb 100755
--- a/configure
+++ b/configure
@@ -2464,6 +2464,29 @@ if test $trace_backend = dtrace; then
fi
##
+# __sync_fetch_and_and requires at least -march=i486. Many toolchains
+# use i686 as default anyway, but for those that don't, an explicit
+# specification is necessary
+if test $vhost_net = yes test $cpu = i386; then
+ cat $TMPC EOF
+int sfaa(unsigned *ptr)
+{
+ return __sync_fetch_and_and(ptr, 0);
+}
+
+int main(int argc, char **argv)
+{
+ int val = 42;
+ sfaa(val);
+ return val;
+}
+EOF
+ if ! compile_prog ; then
+CFLAGS+=-march=i486
+ fi
+fi
+
+##
# End of CC checks
# After here, no more $cc or $ld runs
--
1.6.4
[Qemu-devel] [PATCH 3/4] scsi-disk: Fixup debugging statement
A debugging statement wasn't converted to the new interface.
Signed-off-by: Hannes Reinecke h...@suse.de
Acked-by: Paolo Bonzini pbonz...@redhat.com
---
hw/scsi-disk.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index c2a99fe..5804662 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -1007,7 +1007,7 @@ static int32_t scsi_send_command(SCSIRequest *req,
uint8_t *buf)
command = buf[0];
outbuf = (uint8_t *)r-iov.iov_base;
-DPRINTF(Command: lun=%d tag=0x%x data=0x%02x, lun, tag, buf[0]);
+DPRINTF(Command: lun=%d tag=0x%x data=0x%02x, req-lun, req-tag,
buf[0]);
if (scsi_req_parse(r-req, buf) != 0) {
BADF(Unsupported command length, command %x\n, command);
--
1.7.3.4
Re: [Qemu-devel] KVM call egenda for July 12
Am 11.07.2011 um 13:46 schrieb Juan Quintela quint...@redhat.com: Hi Please send in any agenda items you are interested in covering. Device passthrough on non-PCI (take 2) Alex
[Qemu-devel] [PATCH 4/4] scsi-disk: Mask out serial number EVPD
If the serial number is not set we should mask it out in the
list of supported VPD pages and mark it as not supported.
Signed-off-by: Hannes Reinecke h...@suse.de
Acked-by: Paolo Bonzini pbonz...@redhat.com
---
hw/scsi-disk.c | 15 ---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 5804662..05d14ab 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -398,7 +398,8 @@ static int scsi_disk_emulate_inquiry(SCSIRequest *req,
uint8_t *outbuf)
buffer size %zd\n, req-cmd.xfer);
pages = buflen++;
outbuf[buflen++] = 0x00; // list of supported pages (this page)
-outbuf[buflen++] = 0x80; // unit serial number
+if (s-serial)
+outbuf[buflen++] = 0x80; // unit serial number
outbuf[buflen++] = 0x83; // device identification
if (s-drive_kind == SCSI_HD) {
outbuf[buflen++] = 0xb0; // block limits
@@ -409,8 +410,14 @@ static int scsi_disk_emulate_inquiry(SCSIRequest *req,
uint8_t *outbuf)
}
case 0x80: /* Device serial number, optional */
{
-int l = strlen(s-serial);
+int l;
+if (!s-serial) {
+DPRINTF(Inquiry (EVPD[Serial number] not supported\n);
+return -1;
+}
+
+l = strlen(s-serial);
if (l req-cmd.xfer)
l = req-cmd.xfer;
if (l 20)
@@ -1203,7 +1210,9 @@ static int scsi_initfn(SCSIDevice *dev, SCSIDriveKind
kind)
if (!s-serial) {
/* try to fall back to value set with legacy -drive serial=... */
dinfo = drive_get_by_blockdev(s-bs);
-s-serial = qemu_strdup(*dinfo-serial ? dinfo-serial : 0);
+if (*dinfo-serial) {
+s-serial = qemu_strdup(dinfo-serial);
+}
}
if (!s-version) {
--
1.7.3.4
Re: [Qemu-devel] [Qemu-trivial] [PATCH] vhost build fix for i386
On Mon, Jul 11, 2011 at 1:57 PM, Wolfgang Mauerer wolfgang.maue...@siemens.com wrote: vhost.c uses __sync_fetch_and_and(), which is only available for -march=i486 and above (see https://bugzilla.redhat.com/show_bug.cgi?id=624279). Seems reasonable. I am happy to add it to the trivial-patches tree but will wait another day to let others who are better gcc wizards consider it. Stefan
Re: [Qemu-devel] [PATCH 2/2] qemu-io: Fix if scoping bug
Am 11.07.2011 11:47, schrieb Stefan Hajnoczi:
On Mon, Jul 11, 2011 at 6:25 AM, Devin Nakamura devin...@gmail.com wrote:
diff --git a/qemu-io.c b/qemu-io.c
index e484f40..85cfe27 100644
--- a/qemu-io.c
+++ b/qemu-io.c
@@ -449,7 +449,7 @@ static int read_f(int argc, char **argv)
return 0;
}
-if (!pflag)
+if (!pflag) {
if (offset 0x1ff) {
printf(offset % PRId64 is not sector aligned\n,
offset);
Wait, this is not enough. The indentation and curlies are so broken
here :). The if (offset 0x1ff) statement needs a closing curly.
It's actually there, patch 1 already contains it. Breaks bisectability,
of course.
Kevin
Re: [Qemu-devel] [PATCH 1/2] qemu-io: Fix formatting
Am 11.07.2011 07:25, schrieb Devin Nakamura:
Replaced tabs with spaces, 8 space indentations with 4 space
indentation, and other fixes to better adhere to CODING_STYLE
Signed-off-by: Devin Nakamura devin...@gmail.com
---
qemu-io.c | 2653
+++--
1 files changed, 1331 insertions(+), 1322 deletions(-)
@@ -1630,80 +1639,78 @@ open_help(void)
static int open_f(int argc, char **argv);
static const cmdinfo_t open_cmd = {
- .name = open,
- .altname= o,
- .cfunc = open_f,
- .argmin = 1,
- .argmax = -1,
- .flags = CMD_NOFILE_OK,
- .args = [-Crsn] [path],
- .oneline= open the file specified by path,
- .help = open_help,
+.name = open,
+.altname= o,
+.cfunc = open_f,
+.argmin = 1,
+.argmax = -1,
+.flags = CMD_NOFILE_OK,
+.args = [-Crsn] [path],
+.oneline= open the file specified by path,
+.help = open_help,
};
-static int
-open_f(int argc, char **argv)
+static int open_f(int argc, char **argv)
{
- int flags = 0;
- int readonly = 0;
- int growable = 0;
- int c;
-
- while ((c = getopt(argc, argv, snrg)) != EOF) {
- switch (c) {
- case 's':
- flags |= BDRV_O_SNAPSHOT;
- break;
- case 'n':
- flags |= BDRV_O_NOCACHE | BDRV_O_CACHE_WB;
- break;
- case 'r':
- readonly = 1;
- break;
- case 'g':
- growable = 1;
- break;
- default:
- return command_usage(open_cmd);
- }
- }
-
- if (!readonly) {
-flags |= BDRV_O_RDWR;
+int flags = 0;
+int readonly = 0;
+int growable = 0;
+int c;
+
+while ((c = getopt(argc, argv, snrg)) != EOF) {
+switch (c) {
+case 's':
+flags |= BDRV_O_SNAPSHOT;
+break;
+case 'n':
+flags |= BDRV_O_NOCACHE;
This was BDRV_O_NOCACHE | BDRV_O_CACHE_WB before.
+break;
+case 'r':
+readonly = 1;
+break;
+case 'g':
+growable = 1;
+break;
+default:
+return command_usage(open_cmd);
}
+}
+
+if (!readonly) {
+flags |= BDRV_O_RDWR;
+}
- if (optind != argc - 1)
- return command_usage(open_cmd);
+if (optind != argc - 1) {
+return command_usage(open_cmd);
+}
- return openfile(argv[optind], flags, growable);
+return openfile(argv[optind], flags, growable);
}
-static int
-init_args_command(
-int index)
+static int init_args_command(int index)
{
- /* only one device allowed so far */
- if (index = 1)
- return 0;
- return ++index;
+/* only one device allowed so far */
+if (index = 1) {
+return 0;
+}
+return ++index;
}
-static int
-init_check_command(
- const cmdinfo_t *ct)
+static int init_check_command(const cmdinfo_t *ct)
{
- if (ct-flags CMD_FLAG_GLOBAL)
- return 1;
- if (!(ct-flags CMD_NOFILE_OK) !bs) {
- fprintf(stderr, no file open, try 'help open'\n);
- return 0;
- }
- return 1;
+if (ct-flags CMD_FLAG_GLOBAL) {
+return 1;
+}
+if (!(ct-flags CMD_NOFILE_OK) !bs) {
+fprintf(stderr, no file open, try 'help open'\n);
+return 0;
+}
+return 1;
}
static void usage(const char *name)
{
- printf(
+printf(
Usage: %s [-h] [-V] [-rsnm] [-c cmd] ... [file]\n
QEMU Disk exerciser\n
\n
@@ -1717,115 +1724,117 @@ static void usage(const char *name)
-h, --help display this help and exit\n
-V, --versionoutput version information and exit\n
\n,
- name);
+name);
}
int main(int argc, char **argv)
{
- int readonly = 0;
- int growable = 0;
- const char *sopt = hVc:rsnmgk;
-const struct option lopt[] = {
- { help, 0, NULL, 'h' },
- { version, 0, NULL, 'V' },
- { offset, 1, NULL, 'o' },
- { cmd, 1, NULL, 'c' },
- { read-only, 0, NULL, 'r' },
- { snapshot, 0, NULL, 's' },
- { nocache, 0, NULL, 'n' },
- { misalign, 0, NULL, 'm' },
- { growable, 0, NULL, 'g' },
- { native-aio, 0, NULL, 'k' },
- { NULL, 0, NULL, 0 }
- };
- int c;
- int opt_index = 0;
- int flags = 0;
-
- progname = basename(argv[0]);
-
- while ((c = getopt_long(argc, argv, sopt, lopt, opt_index)) != -1) {
-
Re: [Qemu-devel] qemu-user[armel/mips] and debian-rootfs
On 07/02/2011 02:52 AM, Lisandro Damián Nicanor Pérez Meyer wrote: I have clearly not been verbose enough, so I'll better try to solve that :-) The problem is the following: once I create a chroot, I copy /usr/bin/qemu- mips-static to $CHROOT/usr/bin and then chroot $CHROOT. Now if I do run touch on any file, I get: root@debian:/# touch tito /usr/bin/touch: setting times of `tito': Level 2 not synchronized Once again, any pointer to try to debug it would be highly appreciated. You can run /usr/bin/qemu-mips-static -strace /bin/touch tito to see what syscall are being run, and what gives the level2 error. Some basic details should also be provided for good bugreport: 1. version of qemu being used (a release or latest git?) 2. host linux version (2.6.?) and architecture (i386, x86_64, ?) 3. version of debian used to create chroot (lenny. squeeze, sid, ??) Riku
Re: [Qemu-devel] [PATCH 0/4] scsi fixes
On Mon, Jul 11, 2011 at 2:02 PM, Hannes Reinecke h...@suse.de wrote: Hi all, these are some fixes I found during debugging my megasas HBA emulation. This time I've sent them as a separate patchset for inclusion. All of them have been acked, so please apply. Are SCSI patches going through Kevin's tree? If not, perhaps Paolo or I should keep a tree and start doing some sanity testing on the subsystem in the future. Stefan
Re: [Qemu-devel] [PATCH 2/2] qemu-io: Fix if scoping bug
On Mon, Jul 11, 2011 at 2:18 PM, Kevin Wolf kw...@redhat.com wrote:
Am 11.07.2011 11:47, schrieb Stefan Hajnoczi:
On Mon, Jul 11, 2011 at 6:25 AM, Devin Nakamura devin...@gmail.com wrote:
diff --git a/qemu-io.c b/qemu-io.c
index e484f40..85cfe27 100644
--- a/qemu-io.c
+++ b/qemu-io.c
@@ -449,7 +449,7 @@ static int read_f(int argc, char **argv)
return 0;
}
- if (!pflag)
+ if (!pflag) {
if (offset 0x1ff) {
printf(offset % PRId64 is not sector aligned\n,
offset);
Wait, this is not enough. The indentation and curlies are so broken
here :). The if (offset 0x1ff) statement needs a closing curly.
It's actually there, patch 1 already contains it. Breaks bisectability,
of course.
Devin,
Please make patch 1 only fix formatting and move any other changes
into later patches.
Stefan
Re: [Qemu-devel] [Bug 808737] [NEW] No option to load additional binary files from command line in QEMU
On Mon, Jul 11, 2011 at 12:41 PM, Anup Patel 808...@bugs.launchpad.net wrote: Public bug reported: There is no command line option like -kerner, or -initrd to load an arbitrary binary file to a RAM location when launching QEMU. It depends on your target (e.g. qemu-system-x86_64) but you can load your own code as a bzImage or multiboot binary. Both formats are documented: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/x86/boot.txt http://www.gnu.org/software/grub/manual/multiboot/multiboot.html The problem with loading binary code is that you quickly want some options (is this real mode or protected mode code?, what address to load at?, are there any modules/initrd extras elsewhere in memory?). That's basically what multiboot is for. Does multiboot do what you need? If not, please be more specific and describe your target machine and use case. Stefan
Re: [Qemu-devel] [PATCH 0/4] scsi fixes
Am 11.07.2011 15:34, schrieb Stefan Hajnoczi: On Mon, Jul 11, 2011 at 2:02 PM, Hannes Reinecke h...@suse.de wrote: Hi all, these are some fixes I found during debugging my megasas HBA emulation. This time I've sent them as a separate patchset for inclusion. All of them have been acked, so please apply. Are SCSI patches going through Kevin's tree? If not, perhaps Paolo or I should keep a tree and start doing some sanity testing on the subsystem in the future. As long as we don't have a SCSI maintainer, I'm going to pick them up for the block tree when they have receive some review. Doesn't mean that nobody should be doing sanity testing, of course. If anyone wants to take care of picking up and reviewing all SCSI patches, I'm also happy to pull from a separate tree. Kevin
[Qemu-devel] [PATCH] virtio: fix indirect descriptor buffer overflow
We were previously allowing arbitrarily-long indirect descriptors, which
could lead to a buffer overflow in qemu-kvm process.
CVE-2011-2212
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/virtio.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/hw/virtio.c b/hw/virtio.c
index e6043de..8a6f38c 100644
--- a/hw/virtio.c
+++ b/hw/virtio.c
@@ -449,9 +449,17 @@ int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
struct iovec *sg;
if (vring_desc_flags(desc_pa, i) VRING_DESC_F_WRITE) {
+if (elem-in_num = ARRAY_SIZE(elem-in_sg)) {
+error_report(Too many write descriptors in indirect table);
+exit(1);
+}
elem-in_addr[elem-in_num] = vring_desc_addr(desc_pa, i);
sg = elem-in_sg[elem-in_num++];
} else {
+if (elem-out_num = ARRAY_SIZE(elem-out_sg)) {
+error_report(Too many read descriptors in indirect table);
+exit(1);
+}
elem-out_addr[elem-out_num] = vring_desc_addr(desc_pa, i);
sg = elem-out_sg[elem-out_num++];
}
--
1.7.5.53.gc233e
[Qemu-devel] [PATCH 1/7] arm-semi: Provide access to CLI arguments passed through the -append option
From: Cédric VINCENT cedric.vinc...@st.com
This patch basically adapts the new semi-hosting command-line support
-- introduced by Wolfgang Schildbach in the commit 2e8785ac -- for use
in system-mode.
Note that the arm_cmdline_len and host_cmdline_len variables were
renamed respectively input_size and output_size because:
* in C, the term length is generally used to count the number of
character in a string, not to count the number of bytes in a
buffer (as it is the case here).
* in QEMU, the term host is used to name variables that are in
the host address space, not to name variables in the target
address space (as it is the case here).
* in the case of this system-call, the terms input and output
fit the semantic of the official ARM semi-hosting specification
quite well.
I know renaming can be considered harmful but I do think in this case
the semantic really matters to keep this code more understandable.
Signed-off-by: Cédric VINCENT cedric.vinc...@st.com
Reviewed-by: Christophe Lyon christophe.l...@st.com
Cc: Peter Maydell peter.mayd...@linaro.org
Cc: Paul Brook p...@codesourcery.com
Cc: Wolfgang Schildbach ws...@dolby.com
Cc: Riku Voipio riku.voi...@iki.fi
Signed-off-by: Riku Voipio riku.voi...@linaro.org
---
arm-semi.c | 113 +++
1 files changed, 67 insertions(+), 46 deletions(-)
diff --git a/arm-semi.c b/arm-semi.c
index 5a62d03..873518a 100644
--- a/arm-semi.c
+++ b/arm-semi.c
@@ -34,6 +34,7 @@
#else
#include qemu-common.h
#include gdbstub.h
+#include hw/arm-misc.h
#endif
#define SYS_OPEN0x01
@@ -369,68 +370,88 @@ uint32_t do_arm_semihosting(CPUState *env)
return syscall_err;
#endif
case SYS_GET_CMDLINE:
-#ifdef CONFIG_USER_ONLY
-/* Build a commandline from the original argv. */
{
-char *arm_cmdline_buffer;
-const char *host_cmdline_buffer;
+/* Build a command-line from the original argv.
+ *
+ * The inputs are:
+ * * ARG(0), pointer to a buffer of at least the size
+ * specified in ARG(1).
+ * * ARG(1), size of the buffer pointed to by ARG(0) in
+ * bytes.
+ *
+ * The outputs are:
+ * * ARG(0), pointer to null-terminated string of the
+ * command line.
+ * * ARG(1), length of the string pointed to by ARG(0).
+ */
-unsigned int i;
-unsigned int arm_cmdline_len = ARG(1);
-unsigned int host_cmdline_len =
-ts-info-arg_end-ts-info-arg_start;
+char *output_buffer;
+size_t input_size = ARG(1);
+size_t output_size;
+int status = 0;
-if (!arm_cmdline_len || host_cmdline_len arm_cmdline_len) {
-return -1; /* not enough space to store command line */
-}
+/* Compute the size of the output string. */
+#if !defined(CONFIG_USER_ONLY)
+output_size = strlen(ts-boot_info-kernel_filename)
++ 1 /* Separating space. */
++ strlen(ts-boot_info-kernel_cmdline)
++ 1; /* Terminating null byte. */
+#else
+unsigned int i;
-if (!host_cmdline_len) {
+output_size = ts-info-arg_end - ts-info-arg_start;
+if (!output_size) {
/* We special-case the empty command line case (argc==0).
Just provide the terminating 0. */
-arm_cmdline_buffer = lock_user(VERIFY_WRITE, ARG(0), 1, 0);
-arm_cmdline_buffer[0] = 0;
-unlock_user(arm_cmdline_buffer, ARG(0), 1);
+output_size = 1;
+}
+#endif
-/* Adjust the commandline length argument. */
-SET_ARG(1, 0);
-return 0;
+if (output_size input_size) {
+ /* Not enough space to store command-line arguments. */
+return -1;
}
-/* lock the buffers on the ARM side */
-arm_cmdline_buffer =
-lock_user(VERIFY_WRITE, ARG(0), host_cmdline_len, 0);
-host_cmdline_buffer =
-lock_user(VERIFY_READ, ts-info-arg_start,
- host_cmdline_len, 1);
+/* Adjust the command-line length. */
+SET_ARG(1, output_size - 1);
-if (arm_cmdline_buffer host_cmdline_buffer)
-{
-/* the last argument is zero-terminated;
- no need for additional termination */
-memcpy(arm_cmdline_buffer, host_cmdline_buffer,
- host_cmdline_len);
+/* Lock the buffer on the ARM side. */
+output_buffer =
[Qemu-devel] [PATCH 2/7] linux-user: Add support for KD...LED ioctls
From: Cédric VINCENT cedric.vinc...@st.com
DirectFB-1.0 uses at least one of the four added ioctls, and the three
others were added for completeness. This patch was validated with the
program setleds and the following Makefile:
SETLEDS_INIT = setleds -v -num -caps -scroll
SETLEDS_TESTS = sh -c ' \
setleds -v +num +caps +scroll; \
setleds -v -num -caps -scroll; \
setleds -v +num -caps -scroll; \
setleds -v +num +caps -scroll; \
setleds -v +num +caps +scroll; \
setleds -v -num +caps +scroll; \
setleds -v -num -caps +scroll; \
setleds -v -num -caps -scroll'
SETLEDS_HOST = setleds
SETLEDS_QEMU = SETLEDS_QEMU not set
.PHONY: setleds_tests
setleds_tests:
rm -f setleds.host setleds.target
$(SETLEDS_INIT:setleds=$(SETLEDS_HOST))
$(SETLEDS_TESTS:setleds=$(SETLEDS_HOST)) setleds.host
$(SETLEDS_INIT:setleds=$(SETLEDS_QEMU))
$(SETLEDS_TESTS:setleds=$(SETLEDS_QEMU)) setleds.target
cmp setleds.host setleds.target
Signed-off-by: Cédric VINCENT cedric.vinc...@st.com
Cc: Riku Voipio riku.voi...@iki.fi
Signed-off-by: Riku Voipio riku.voi...@linaro.org
---
linux-user/ioctls.h |4
linux-user/syscall_defs.h |4
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
index 42b3ae3..68418e4 100644
--- a/linux-user/ioctls.h
+++ b/linux-user/ioctls.h
@@ -59,6 +59,10 @@
IOCTL(KDSKBMODE, 0, TYPE_INT)
IOCTL(KDGKBENT, IOC_RW, MK_PTR(MK_STRUCT(STRUCT_kbentry)))
IOCTL(KDGKBSENT, IOC_RW, MK_PTR(MK_STRUCT(STRUCT_kbsentry)))
+ IOCTL(KDGKBLED, 0, TYPE_INT)
+ IOCTL(KDSKBLED, 0, TYPE_INT)
+ IOCTL(KDGETLED, 0, TYPE_INT)
+ IOCTL(KDSETLED, 0, TYPE_INT)
IOCTL(BLKROSET, IOC_W, MK_PTR(TYPE_INT))
IOCTL(BLKROGET, IOC_R, MK_PTR(TYPE_INT))
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 04c268d..2b74547 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -708,6 +708,10 @@ struct target_pollfd {
#define TARGET_KDSKBMODE 0x4b45
#define TARGET_KDGKBENT 0x4B46 /* gets one entry in
translation table */
#define TARGET_KDGKBSENT 0x4B48 /* gets one function key string entry */
+#define TARGET_KDGKBLED0x4B64 /* get led flags (not lights) */
+#define TARGET_KDSKBLED0x4B65 /* set led flags (not lights) */
+#define TARGET_KDGETLED0x4B31 /* return current led state */
+#define TARGET_KDSETLED0x4B32 /* set led state [lights, not flags] */
#define TARGET_SIOCATMARK 0x8905
--
1.7.4.1
Re: [Qemu-devel] [PATCH 0/4] scsi fixes
On 07/11/2011 03:42 PM, Kevin Wolf wrote: Am 11.07.2011 15:34, schrieb Stefan Hajnoczi: On Mon, Jul 11, 2011 at 2:02 PM, Hannes Reineckeh...@suse.de wrote: Hi all, these are some fixes I found during debugging my megasas HBA emulation. This time I've sent them as a separate patchset for inclusion. All of them have been acked, so please apply. Are SCSI patches going through Kevin's tree? If not, perhaps Paolo or I should keep a tree and start doing some sanity testing on the subsystem in the future. As long as we don't have a SCSI maintainer, I'm going to pick them up for the block tree when they have receive some review. Doesn't mean that nobody should be doing sanity testing, of course. If anyone wants to take care of picking up and reviewing all SCSI patches, I'm also happy to pull from a separate tree. Patches have already been reviewed and tested, in conjunction with my megasas HBA emulation patchset. This is just a repost as a separate patchset to get them in. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
[Qemu-devel] [PATCH 0/7] pending linux-user patches
From: Riku Voipio riku.voi...@linaro.org Following linux-user patches have been submitted since the last round. Last chance to comment before I ask for pull. Patches also available in the git repository at: git://git.linaro.org/people/rikuvoipio/qemu.git linux-user-for-upstream Cédric VINCENT (4): arm-semi: Provide access to CLI arguments passed through the -append option linux-user: Add support for KD...LED ioctls linux-user: Add support for more VT ioctls linux-user: Add support for even more FB ioctls Peter Maydell (3): linux-user: Add syscall numbers from kernel 2.6.39.2 linux-user: Implement prlimit64 syscall linux-user/syscall.c: Enforce pselect6 sigset size restrictions arm-semi.c | 113 +--- linux-user/alpha/syscall_nr.h | 23 +++- linux-user/arm/syscall_nr.h| 13 linux-user/cris/syscall_nr.h |2 + linux-user/i386/syscall_nr.h | 12 linux-user/ioctls.h| 13 linux-user/m68k/syscall_nr.h | 16 + linux-user/main.c | 27 + linux-user/microblaze/syscall_nr.h | 14 - linux-user/mips/syscall_nr.h | 13 linux-user/mips64/syscall_nr.h | 13 linux-user/mipsn32/syscall_nr.h| 14 + linux-user/ppc/syscall_nr.h| 30 ++ linux-user/s390x/syscall_nr.h | 13 - linux-user/sh4/syscall_nr.h| 32 ++ linux-user/sparc/syscall_nr.h | 12 linux-user/sparc64/syscall_nr.h| 12 linux-user/syscall.c | 48 +++ linux-user/syscall_defs.h | 17 ++ linux-user/syscall_types.h | 20 ++ linux-user/x86_64/syscall_nr.h | 12 21 files changed, 418 insertions(+), 51 deletions(-) -- 1.7.4.1
[Qemu-devel] [PATCH 4/7] linux-user: Add support for even more FB ioctls
From: Cédric VINCENT cedric.vinc...@st.com
This patch was validated with programs from DirectFB-1.0 and
WebKit/DirectFB.
Signed-off-by: Cédric VINCENT cedric.vinc...@st.com
Cc: Riku Voipio riku.voi...@iki.fi
Signed-off-by: Riku Voipio riku.voi...@linaro.org
---
linux-user/ioctls.h|5 +
linux-user/syscall_defs.h |5 +
linux-user/syscall_types.h | 13 +
3 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
index 7bc1c48..6514502 100644
--- a/linux-user/ioctls.h
+++ b/linux-user/ioctls.h
@@ -329,6 +329,11 @@
IOCTL(FBIOGET_FSCREENINFO, IOC_R,
MK_PTR(MK_STRUCT(STRUCT_fb_fix_screeninfo)))
IOCTL(FBIOGET_VSCREENINFO, IOC_R,
MK_PTR(MK_STRUCT(STRUCT_fb_var_screeninfo)))
IOCTL(FBIOPUT_VSCREENINFO, IOC_W,
MK_PTR(MK_STRUCT(STRUCT_fb_var_screeninfo)))
+ IOCTL(FBIOGETCMAP,IOC_RW, MK_PTR(MK_STRUCT(STRUCT_fb_cmap)))
+ IOCTL(FBIOPUTCMAP,IOC_RW, MK_PTR(MK_STRUCT(STRUCT_fb_cmap)))
+ IOCTL(FBIOPAN_DISPLAY,IOC_RW,
MK_PTR(MK_STRUCT(STRUCT_fb_var_screeninfo)))
+ IOCTL(FBIOGET_CON2FBMAP, IOC_RW, MK_PTR(MK_STRUCT(STRUCT_fb_con2fbmap)))
+ IOCTL(FBIOPUT_CON2FBMAP, IOC_RW, MK_PTR(MK_STRUCT(STRUCT_fb_con2fbmap)))
IOCTL(VT_OPENQRY, IOC_R, MK_PTR(TYPE_INT))
IOCTL(VT_GETSTATE, IOC_R, MK_PTR(MK_STRUCT(STRUCT_vt_stat)))
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 4a59b36..1b73451 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -932,6 +932,11 @@ struct target_pollfd {
#define TARGET_FBIOGET_VSCREENINFO0x4600
#define TARGET_FBIOPUT_VSCREENINFO0x4601
#define TARGET_FBIOGET_FSCREENINFO0x4602
+#define TARGET_FBIOGETCMAP0x4604
+#define TARGET_FBIOPUTCMAP0x4605
+#define TARGET_FBIOPAN_DISPLAY0x4606
+#define TARGET_FBIOGET_CON2FBMAP 0x460F
+#define TARGET_FBIOPUT_CON2FBMAP 0x4610
/* vt ioctls */
#define TARGET_VT_OPENQRY 0x5600
diff --git a/linux-user/syscall_types.h b/linux-user/syscall_types.h
index 94b0ce0..c370125 100644
--- a/linux-user/syscall_types.h
+++ b/linux-user/syscall_types.h
@@ -161,6 +161,19 @@ STRUCT(fb_var_screeninfo,
TYPE_INT, /* rotate */
MK_ARRAY(TYPE_INT, 5)) /* reserved */
+STRUCT(fb_cmap,
+ TYPE_INT, /* start */
+ TYPE_INT, /* len*/
+ TYPE_PTRVOID, /* red*/
+ TYPE_PTRVOID, /* green */
+ TYPE_PTRVOID, /* blue */
+ TYPE_PTRVOID) /* transp */
+
+STRUCT(fb_con2fbmap,
+ TYPE_INT, /* console */
+ TYPE_INT) /* framebuffer */
+
+
STRUCT(vt_stat,
TYPE_SHORT, /* v_active */
TYPE_SHORT, /* v_signal */
--
1.7.4.1
[Qemu-devel] [PATCH 5/7] linux-user: Add syscall numbers from kernel 2.6.39.2
From: Peter Maydell peter.mayd...@linaro.org Add syscall numbers for new syscall numbers; this brings us into line with Linux 2.6.39.2. Signed-off-by: Peter Maydell peter.mayd...@linaro.org Signed-off-by: Riku Voipio riku.voi...@linaro.org --- linux-user/alpha/syscall_nr.h | 23 ++- linux-user/arm/syscall_nr.h| 13 + linux-user/cris/syscall_nr.h |2 ++ linux-user/i386/syscall_nr.h | 12 linux-user/m68k/syscall_nr.h | 16 linux-user/main.c | 27 +++ linux-user/microblaze/syscall_nr.h | 14 -- linux-user/mips/syscall_nr.h | 13 + linux-user/mips64/syscall_nr.h | 13 + linux-user/mipsn32/syscall_nr.h| 14 ++ linux-user/ppc/syscall_nr.h| 30 ++ linux-user/s390x/syscall_nr.h | 13 +++-- linux-user/sh4/syscall_nr.h| 32 linux-user/sparc/syscall_nr.h | 12 linux-user/sparc64/syscall_nr.h| 12 linux-user/x86_64/syscall_nr.h | 12 16 files changed, 253 insertions(+), 5 deletions(-) diff --git a/linux-user/alpha/syscall_nr.h b/linux-user/alpha/syscall_nr.h index e3127df..f6284db 100644 --- a/linux-user/alpha/syscall_nr.h +++ b/linux-user/alpha/syscall_nr.h @@ -411,4 +411,25 @@ #define TARGET_NR_signalfd 476 #define TARGET_NR_timerfd 477 #define TARGET_NR_eventfd 478 - +#define TARGET_NR_recvmmsg 479 +#define TARGET_NR_fallocate 480 +#define TARGET_NR_timerfd_create481 +#define TARGET_NR_timerfd_settime 482 +#define TARGET_NR_timerfd_gettime 483 +#define TARGET_NR_signalfd4 484 +#define TARGET_NR_eventfd2 485 +#define TARGET_NR_epoll_create1 486 +#define TARGET_NR_dup3 487 +#define TARGET_NR_pipe2 488 +#define TARGET_NR_inotify_init1 489 +#define TARGET_NR_preadv490 +#define TARGET_NR_pwritev 491 +#define TARGET_NR_rt_tgsigqueueinfo 492 +#define TARGET_NR_perf_event_open 493 +#define TARGET_NR_fanotify_init 494 +#define TARGET_NR_fanotify_mark 495 +#define TARGET_NR_prlimit64 496 +#define TARGET_NR_name_to_handle_at 497 +#define TARGET_NR_open_by_handle_at 498 +#define TARGET_NR_clock_adjtime 499 +#define TARGET_NR_syncfs500 diff --git a/linux-user/arm/syscall_nr.h b/linux-user/arm/syscall_nr.h index 79a216a..7f05879 100644 --- a/linux-user/arm/syscall_nr.h +++ b/linux-user/arm/syscall_nr.h @@ -365,3 +365,16 @@ #define TARGET_NR_dup3 (358) #define TARGET_NR_pipe2(359) #define TARGET_NR_inotify_init1(360) +#define TARGET_NR_preadv (361) +#define TARGET_NR_pwritev (362) +#define TARGET_NR_rt_tgsigqueueinfo(363) +#define TARGET_NR_perf_event_open (364) +#define TARGET_NR_recvmmsg (365) +#define TARGET_NR_accept4 (366) +#define TARGET_NR_fanotify_init(367) +#define TARGET_NR_fanotify_mark(368) +#define TARGET_NR_prlimit64(369) +#define TARGET_NR_name_to_handle_at(370) +#define TARGET_NR_open_by_handle_at(371) +#define TARGET_NR_clock_adjtime(372) +#define TARGET_NR_syncfs (373) diff --git a/linux-user/cris/syscall_nr.h b/linux-user/cris/syscall_nr.h index 6132817..98f1a0b 100644 --- a/linux-user/cris/syscall_nr.h +++ b/linux-user/cris/syscall_nr.h @@ -333,3 +333,5 @@ #define TARGET_NR_dup3 330 #define TARGET_NR_pipe2 331 #define TARGET_NR_inotify_init1 332 +#define TARGET_NR_preadv 333 +#define TARGET_NR_pwritev334 diff --git a/linux-user/i386/syscall_nr.h b/linux-user/i386/syscall_nr.h index 3ef71ce..74abfca 100644 --- a/linux-user/i386/syscall_nr.h +++ b/linux-user/i386/syscall_nr.h @@ -335,3 +335,15 @@ #define TARGET_NR_dup3 330 #define TARGET_NR_pipe2331 #define TARGET_NR_inotify_init1332 +#define TARGET_NR_preadv333 +#define TARGET_NR_pwritev 334 +#define TARGET_NR_rt_tgsigqueueinfo 335 +#define TARGET_NR_perf_event_open 336 +#define TARGET_NR_recvmmsg 337 +#define TARGET_NR_fanotify_init 338 +#define TARGET_NR_fanotify_mark 339 +#define TARGET_NR_prlimit64 340 +#define TARGET_NR_name_to_handle_at 341 +#define
[Qemu-devel] [PATCH 6/7] linux-user: Implement prlimit64 syscall
From: Peter Maydell peter.mayd...@linaro.org
Implement the prlimit64 syscall.
Slightly modified to apply upstream -Riku
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Riku Voipio riku.voi...@linaro.org
---
linux-user/syscall.c | 43 +++
linux-user/syscall_defs.h |4
2 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index fed7a8f..e2f356b 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -559,6 +559,21 @@ _syscall6(int, sys_pselect6, int, nfds, fd_set *, readfds,
fd_set *, writefds,
fd_set *, exceptfds, struct timespec *, timeout, void *, sig);
#endif
+#if defined(TARGET_NR_prlimit64)
+#ifndef __NR_prlimit64
+# define __NR_prlimit64 -1
+#endif
+#define __NR_sys_prlimit64 __NR_prlimit64
+/* The glibc rlimit structure may not be that used by the underlying syscall */
+struct host_rlimit64 {
+uint64_t rlim_cur;
+uint64_t rlim_max;
+};
+_syscall4(int, sys_prlimit64, pid_t, pid, int, resource,
+ const struct host_rlimit64 *, new_limit,
+ struct host_rlimit64 *, old_limit)
+#endif
+
extern int personality(int);
extern int flock(int, int);
extern int setfsuid(int);
@@ -7990,6 +8005,34 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
arg1,
}
#endif
#endif
+#ifdef TARGET_NR_prlimit64
+case TARGET_NR_prlimit64:
+{
+/* args: pid, resource number, ptr to new rlimit, ptr to old rlimit */
+struct target_rlimit64 *target_rnew, *target_rold;
+struct host_rlimit64 rnew, rold, *rnewp = 0;
+if (arg3) {
+if (!lock_user_struct(VERIFY_READ, target_rnew, arg3, 1)) {
+goto efault;
+}
+rnew.rlim_cur = tswap64(target_rnew-rlim_cur);
+rnew.rlim_max = tswap64(target_rnew-rlim_max);
+unlock_user_struct(target_rnew, arg3, 0);
+rnewp = rnew;
+}
+
+ret = get_errno(sys_prlimit64(arg1, arg2, rnewp, arg4 ? rold : 0));
+if (!is_error(ret) arg4) {
+if (!lock_user_struct(VERIFY_WRITE, target_rold, arg4, 1)) {
+goto efault;
+}
+target_rold-rlim_cur = tswap64(rold.rlim_cur);
+target_rold-rlim_max = tswap64(rold.rlim_max);
+unlock_user_struct(target_rold, arg4, 1);
+}
+break;
+}
+#endif
default:
unimplemented:
gemu_log(qemu: Unsupported syscall: %d\n, num);
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 1b73451..1fdc84d 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -2293,3 +2293,7 @@ struct target_epoll_event {
target_epoll_data_t data;
};
#endif
+struct target_rlimit64 {
+uint64_t rlim_cur;
+uint64_t rlim_max;
+};
--
1.7.4.1
[Qemu-devel] [PATCH 7/7] linux-user/syscall.c: Enforce pselect6 sigset size restrictions
From: Peter Maydell peter.mayd...@linaro.org
Enforce the same restriction on the size of the sigset passed to
pselect6 as the Linux kernel does. This is both correct and silences
a gcc 4.6 warning about a write-only variable.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Riku Voipio riku.voi...@linaro.org
---
linux-user/syscall.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index e2f356b..90f6789 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -5699,6 +5699,11 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
arg1,
if (arg_sigset) {
sig.set = set;
+if (arg_sigsize != sizeof(*target_sigset)) {
+/* Like the kernel, we enforce correct size sigsets */
+ret = -TARGET_EINVAL;
+goto fail;
+}
target_sigset = lock_user(VERIFY_READ, arg_sigset,
sizeof(*target_sigset), 1);
if (!target_sigset) {
--
1.7.4.1
Re: [Qemu-devel] qemu-user[armel/mips] and debian-rootfs
On Mon, Jul 11, 2011 at 11:10:50AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: Thanks Riku! This bug has already been solved by Wesley Terpstra: http://lists.nongnu.org/archive/html/qemu-devel/2011-07/msg00313.html Ok, I missed these patches. Will adjust the linux-user patchset to include these patches if no bugs found in them. Riku
Re: [Qemu-devel] qemu-user[armel/mips] and debian-rootfs
On Lun 11 Jul 2011 10:45:27 riku voipio escribió: On 07/02/2011 02:52 AM, Lisandro Damián Nicanor Pérez Meyer wrote: I have clearly not been verbose enough, so I'll better try to solve that :-) The problem is the following: once I create a chroot, I copy /usr/bin/qemu- mips-static to $CHROOT/usr/bin and then chroot $CHROOT. Now if I do run touch on any file, I get: root@debian:/# touch tito /usr/bin/touch: setting times of `tito': Level 2 not synchronized Once again, any pointer to try to debug it would be highly appreciated. You can run /usr/bin/qemu-mips-static -strace /bin/touch tito to see what syscall are being run, and what gives the level2 error. Some basic details should also be provided for good bugreport: 1. version of qemu being used (a release or latest git?) 2. host linux version (2.6.?) and architecture (i386, x86_64, ?) 3. version of debian used to create chroot (lenny. squeeze, sid, ??) Riku Thanks Riku! This bug has already been solved by Wesley Terpstra: http://lists.nongnu.org/archive/html/qemu-devel/2011-07/msg00313.html I have patched the debian package, rebuilt and use it perfectly :-) Kinds regards, Lisandro. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
[Qemu-devel] [Bug 808737] Re: No option to load additional binary files from command line in QEMU
Just to add to my use case.
Currently, to load a test binary called arm_test.bin.patched i have
hacked QEMU in the following manner:
diff --git a/hw/arm_boot.c b/hw/arm_boot.c
index bfac982..e4873d4 100644
--- a/hw/arm_boot.c
+++ b/hw/arm_boot.c
@@ -280,6 +280,13 @@ void arm_load_kernel(CPUState *env, struct arm_boot_info
*info)
info-smp_loader_start);
}
info-initrd_size = initrd_size;
+} else {
+initrd_size = load_image_targphys(arm_test.bin, 0x10, 0x100);
+if (initrd_size 0) {
+fprintf(stderr, qemu: could not load arm test code '%s'\n,
+arm_test.bin);
+exit(1);
+}
}
info-is_linux = is_linux;
--Anup
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/808737
Title:
No option to load additional binary files from command line in QEMU
Status in QEMU:
New
Bug description:
There is no command line option like -kerner, or -initrd to load an
arbitrary binary file to a RAM location when launching QEMU.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/808737/+subscriptions
Re: [Qemu-devel] qdev for programmers writeup
On 11 July 2011 13:48, Paolo Bonzini pbonz...@redhat.com wrote:
On 07/11/2011 12:46 PM, Peter Maydell wrote:
Paolo wrote:
Together with such
a bus type there should be a single root board-specific device that is
attached to SysBus. An interrupt controller is usually a good candidate
for this because it takes qemu_irqs from the outside, and can make good
use of the specificities of SysBus.
...and this bit I don't understand. Why is SysBus a bad thing?
1) because SysBus devices are in general not accessible from the
command-line or configuration files.
2) because SysBus hardcodes in the source code some things that ought to be
device properties, for example the MMIO base address. The presence of MMIO
in sysbus_create_simple/sysbus_create_varargs is totally unnecessary IMHO.
MMIO base address shouldn't be a device property anyway -- it is
a property of the machine (board) model, ie how am I wiring up
these devices?, not a property of the device itself.
It generally seems to me to be the right way to represent a bit of
hardware which is fundamentally providing a memory mapped interface
plus some GPIO lines. If you make your board use sysbus then it's
easy to just plug in any existing sysbus device model qemu already
has; if every board has its own bus type instead then this reuse
just becomes unnecessarily harder, it seems to me.
That's true, but the only way to plug in those device models would be with C
code. You cannot just play with -device to reconfigure them.
I think the C source level reuse is more important and more useful
than plugging stuff around with -device, because in practice messing
about with the memory map of an embedded board isn't something people
typically want to do, because the kernel will have more-or-less
hardcoded where the devices are anyhow. (Also if you have one bus type
per board then you're still very limited in what you can do with -device
because you can't plug in some random other sysbus device anyway.) So if
we want to allow runtime configurability of boards like that we need
to do it by providing runtime configurability of sysbus devices.
(which approximately equates to runtime script-driven machine models).
In fact, perhaps qdev_{connect_gpio_out,get_gpio_in} should never have been
public. Imagine we added to qdev GPIO properties and we used them like this
in gpio_i2c:
/* gpio_out=N means connect my 0th output pin to the parent's
N-th input pin. */
DEFINE_PROP_GPIO_OUT(gpio_out, 0),
/* gpio_in=N means connect my 0th input pin to the parent's
N-th output pin. */
DEFINE_PROP_GPIO_IN(gpio_in, 0),
DEFINE_PROP_GPIO_IN(gpio_clk, 1)
I think it would be better to think of GPIO as a special (simple)
case of a generic desire to plug devices into each other (this is what
SystemC calls a port: basically an interface (API) defined so that
two things can make calls to arbitrary callback functions on the other
end of a connection). How ports are wired up is a property of the
machine model, not a property of the device at either end, and I think
it is better for the syntax not to mix up ports and properties.
Also, you want to be able to actually name your output pins, so
at a board level you can talk about wiring up sd_controller.wprot,
not sd_controller.gpio[3]... (Yes, this is to some extent just syntax
but I really don't want to end up with machine level modelling looking
like:
[device gpio_i2c]
gpio_out = 29
gpio_in = 3
gpio_clk = 4
...because that's just not really maintainable IMHO.)
Also having the interrupt controller be the board specific device
which you attach to sysbus seems totally wrong to me. This doesn't
match hardware at all -- the interrupt controller deals with
interrupt lines and isn't in the path for memory transactions at
all.
Well, it is clear that buses should be modelled after the way data flows.
But what is data? If data is what is being written, buses should be
modelled after the way memory transactions flow. If data is what is being
made available, buses are modelled more after the way interrupts flow.
GPIO is a strange thing in the middle. :)
Actually I think we should really be modelling buses only where the
hardware actually has a bus, ie a coherent collection of signals
between multiple devices such that you could in theory plug in
different devices in different slots. The memory transaction
related connections are much more buslike than interrupt wiring.
-- PMM
[Qemu-devel] [PATCH 3/7] linux-user: Add support for more VT ioctls
From: Cédric VINCENT cedric.vinc...@st.com
DirectFB-1.0 uses at least two of the four added ioctls, and the two
others were added for completeness. This patch was validated with the
program vlock -all/-new.
Signed-off-by: Cédric VINCENT cedric.vinc...@st.com
Cc: Riku Voipio riku.voi...@iki.fi
Signed-off-by: Riku Voipio riku.voi...@linaro.org
---
linux-user/ioctls.h|4
linux-user/syscall_defs.h |4
linux-user/syscall_types.h |7 +++
3 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
index 68418e4..7bc1c48 100644
--- a/linux-user/ioctls.h
+++ b/linux-user/ioctls.h
@@ -336,3 +336,7 @@
IOCTL(VT_WAITACTIVE, 0, TYPE_INT)
IOCTL(VT_LOCKSWITCH, 0, TYPE_INT)
IOCTL(VT_UNLOCKSWITCH, 0, TYPE_INT)
+ IOCTL(VT_GETMODE, IOC_RW, MK_PTR(MK_STRUCT(STRUCT_vt_mode)))
+ IOCTL(VT_SETMODE, IOC_RW, MK_PTR(MK_STRUCT(STRUCT_vt_mode)))
+ IOCTL(VT_RELDISP, 0, TYPE_INT)
+ IOCTL(VT_DISALLOCATE, 0, TYPE_INT)
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 2b74547..4a59b36 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -940,6 +940,10 @@ struct target_pollfd {
#define TARGET_VT_WAITACTIVE 0x5607
#define TARGET_VT_LOCKSWITCH 0x560b
#define TARGET_VT_UNLOCKSWITCH0x560c
+#define TARGET_VT_GETMODE 0x5601
+#define TARGET_VT_SETMODE 0x5602
+#define TARGET_VT_RELDISP 0x5605
+#define TARGET_VT_DISALLOCATE 0x5608
/* from asm/termbits.h */
diff --git a/linux-user/syscall_types.h b/linux-user/syscall_types.h
index 0e67cd8..94b0ce0 100644
--- a/linux-user/syscall_types.h
+++ b/linux-user/syscall_types.h
@@ -166,6 +166,13 @@ STRUCT(vt_stat,
TYPE_SHORT, /* v_signal */
TYPE_SHORT) /* v_state */
+STRUCT(vt_mode,
+ TYPE_CHAR, /* mode */
+ TYPE_CHAR, /* waitv */
+ TYPE_SHORT, /* relsig */
+ TYPE_SHORT, /* acqsig */
+ TYPE_SHORT) /* frsig */
+
STRUCT(fiemap_extent,
TYPE_ULONGLONG, /* fe_logical */
TYPE_ULONGLONG, /* fe_physical */
--
1.7.4.1
[Qemu-devel] [Bug 808737] Re: No option to load additional binary files from command line in QEMU
I am trying to develop a lightweight hypervisor for ARM Cortex-A8. In my case I have to load hypervisor elf as kernel and there and number of other binaries like flattened device tree binary for hypervisor configuration, guest kernel binary, guest ramdisk, etc. Currently, I am developing it for Realview PB-A8 board. For loading the above specified images I have to hack QEMU in hw/arm_boot.c, which is not a good solution. In general, I will encounter similar problem for any other architecture too. What I wish is that can QEMU have an command option to load a binary file to a physical location after system initialization is done and before QEMU starts emulating a virtual CPU. (Note: the command line option will be concerned with physical address and not virtual address so in case of x86_64 it does not matter if) I believe this option can be very handy for OS development and/or firmware development which require multiple binaries. Do you think multiboot is suitable for scenario ?? --Anup -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/808737 Title: No option to load additional binary files from command line in QEMU Status in QEMU: New Bug description: There is no command line option like -kerner, or -initrd to load an arbitrary binary file to a RAM location when launching QEMU. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/808737/+subscriptions
Re: [Qemu-devel] live block copy/stream/snapshot discussion
Kevin, Marcelo,
I'd like to reach agreement on the QMP/HMP APIs for live block copy
and image streaming. Libvirt has acked the image streaming APIs that
Adam proposed and I think they are a good fit for the feature. I have
described that API below for your review (it's exactly what the QED
Image Streaming patches provide).
Marcelo: Are you happy with this API for live block copy? Also please
take a look at the switch command that I am proposing.
Image streaming API
===
For leaf images with copy-on-read semantics, the stream commands allow the user
to populate local blocks by manually streaming them from the backing image.
Once all blocks have been streamed, the dependency on the original backing
image can be removed. Therefore, stream commands can be used to implement
post-copy live block migration and rapid deployment.
The block_stream command can be used to stream a single cluster, to
start streaming the entire device, and to cancel an active stream. It
is easiest to allow the block_stream command to manage streaming for the
entire device but a managent tool could use single cluster mode to
throttle the I/O rate.
The command synopses are as follows:
block_stream
Copy data from a backing file into a block device.
If the optional 'all' argument is true, this operation is performed in the
background until the entire backing file has been copied. The status of
ongoing block_stream operations can be checked with query-block-stream.
Arguments:
- all:copy entire device (json-bool, optional)
- stop: stop copying to device (json-bool, optional)
- device: device name (json-string)
Return:
- device: device name (json-string)
- len:size of the device, in bytes (json-int)
- offset: ending offset of the completed I/O, in bytes (json-int)
Examples:
- { execute: block_stream, arguments: { device: virtio0 } }
- { return: { device: virtio0, len: 10737418240, offset: 512 } }
- { execute: block_stream, arguments: { all: true, device:
virtio0 } }
- { return: {} }
- { execute: block_stream, arguments: { stop: true, device:
virtio0 } }
- { return: {} }
query-block-stream
--
Show progress of ongoing block_stream operations.
Return a json-array of all operations. If no operation is active then an empty
array will be returned. Each operation is a json-object with the following
data:
- device: device name (json-string)
- len:size of the device, in bytes (json-int)
- offset: ending offset of the completed I/O, in bytes (json-int)
Example:
- { execute: query-block-stream }
- { return:[
{ device: virtio0, len: 10737418240, offset: 709632}
]
}
Block device switching API
==
Extend the 'change' command to support changing the image file without
media change notification.
Perhaps we should take the opportunity to add a format argument for
image files?
change
--
Change a removable medium or VNC configuration.
Arguments:
- device: device name (json-string)
- target: filename or item (json-string)
- arg: additional argument (json-string, optional)
- notify: whether to notify guest, defaults to true (json-bool, optional)
Examples:
1. Change a removable medium
- { execute: change,
arguments: { device: ide1-cd0,
target: /srv/images/Fedora-12-x86_64-DVD.iso } }
- { return: {} }
2. Change a disk without media change notification
- { execute: change,
arguments: { device: virtio-blk0,
target: /srv/images/vm_1.img,
notify: false } }
3. Change VNC password
- { execute: change,
arguments: { device: vnc, target: password,
arg: foobar1 } }
- { return: {} }
How live block copy works
=
Live block copy does the following:
1. Create the destination file: qemu-img create -f $cow_fmt -o
backing_file=$base destination.$cow_fmt
2. Switch to the destination file: change -n virtio-blk0 /srv/images/vm_1.img
3. Stream the base into the image file: block_stream -a virtio-blk0
Stefan
[Qemu-devel] [PATCH v3 2/2] qemu-io: Fix if scoping bug
Fix a bug caused by lack of braces in if statement
Lack of braces means that if(count 0x1ff) is never reached
Conflicts:
qemu-io.c
Signed-off-by: Devin Nakamura devin...@gmail.com
---
qemu-io.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/qemu-io.c b/qemu-io.c
index e3c825f..a553d0c 100644
--- a/qemu-io.c
+++ b/qemu-io.c
@@ -449,7 +449,7 @@ static int read_f(int argc, char **argv)
return 0;
}
-if (!pflag)
+if (!pflag) {
if (offset 0x1ff) {
printf(offset % PRId64 is not sector aligned\n,
offset);
@@ -460,6 +460,7 @@ static int read_f(int argc, char **argv)
count);
return 0;
}
+}
buf = qemu_io_alloc(count, 0xab);
--
1.7.6.rc1
Re: [Qemu-devel] Taking live snapshots of running VMs
Am 09.07.2011 00:24, schrieb Ahmed M. Azab: Hi All, Is there a way to take a live memory snapshot of a running VM without freezing or stopping this VM? I explored the Qemu code and documentation and I found two ways to take a snapshot: 1-Using savevm Qemu monitor command, which freezes the VM for tens of seconds 2-Using migrate and select the destination as a file, which forces the machine to stop after the snapshot is saved. In production environments (where delaying the operations of a VM is very critical), it is always useful to take memory snapshots to do system analysis or forensics. I think Qemu should provide a way to take a snapshot based on QOW technque of memory pages (same as the QCOW disk snapshoting). If such technique does not exist, I am willing it devlop it myself, but I wonder if the Qemu community will be interested to add my patch to future versions. All the code that deals with memory is already there and used for migration. I think what you really need is a combination of savevm and live migration, such that you live migrate the VM state into the qcow2 image and when the migration has completed, you take a disk snapshot and continue the VM. It shouldn't be too hard to do this. All of the building blocks are there, they just need to be combined in the right way. I would be interested in a patch allowing this. Having said that, I think there are more variations that we'll want to support. Basically the dimensions that I see are: 1. Disk-only vs. complete VM state 2. Store VM state internally in qcow2 vs. an external file 3. Use internal vs. external disk snapshots Ideally, we would allow users to choose freely. For example, internal disk snapshot with external VM state is a combination that I think could be very useful. Kevin
Re: [Qemu-devel] [PATCH 5/7] linux-user: Add syscall numbers from kernel 2.6.39.2
On Mon, Jul 11, 2011 at 04:11:00PM +0200, riku.voi...@iki.fi wrote: From: Peter Maydell peter.mayd...@linaro.org Add syscall numbers for new syscall numbers; this brings us into line with Linux 2.6.39.2. The syscall #123 on SH4 should be TARGET_NR_cacheflush instead of TARGET_NR_modify_ldt [1]. The only consequence of this misnaming is that many Unsupported syscall warnings are issued when emulating JIT compilers. Note that this misnaming was not introduced by this patch, should I submit another patch or do you wish to include this change into this one? Regards, Cedric. [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/sh/include/asm/unistd_32.h#l135
Re: [Qemu-devel] migration: new sections and backward compatibility.
Am 07.07.2011 17:23, schrieb Paolo Bonzini: On 07/07/2011 01:02 PM, Alexander Graf wrote: I'd guess the best would be to have a special VMSTATE that means broken old version doesn't send a section which we can set for special -M? No, the best would be to have a serious migration format, based for example on ASN.1 which Michael Tsirkin was playing with. We cannot keep bolting more and more stuff on top of the current protocol, especially since adding a new protocol is not that hard (old machine types can keep the old protocol). And even more so with the old format being ambiguous. We haven't decided yet what to do with subsections of structs, have we? Kevin
Re: [Qemu-devel] [Bug 808737] Re: No option to load additional binary files from command line in QEMU
On Mon, Jul 11, 2011 at 3:14 PM, Anup Patel 808...@bugs.launchpad.net wrote: I am trying to develop a lightweight hypervisor for ARM Cortex-A8. In my case I have to load hypervisor elf as kernel and there and number of other binaries like flattened device tree binary for hypervisor configuration, guest kernel binary, guest ramdisk, etc. Currently, I am developing it for Realview PB-A8 board. For loading the above specified images I have to hack QEMU in hw/arm_boot.c, which is not a good solution. In general, I will encounter similar problem for any other architecture too. What I wish is that can QEMU have an command option to load a binary file to a physical location after system initialization is done and before QEMU starts emulating a virtual CPU. (Note: the command line option will be concerned with physical address and not virtual address so in case of x86_64 it does not matter if) I believe this option can be very handy for OS development and/or firmware development which require multiple binaries. Do you think multiboot is suitable for scenario ?? Doesn't arm_boot.c already load an arbitrary binary when the image is neither a kernel ELF or uboot image? I don't know the arm_boot.c details but skimming the source shows it already does load_image_targphys(). Stefan
Re: [Qemu-devel] [PATCH v5] Add support for Zipit Z2 machine
On Wednesday 06 July 2011 16:52:49 Vasily Khoruzhick wrote:
Zipit Z2 is small PXA270 based handheld.
Ping?
Signed-off-by: Vasily Khoruzhick anars...@gmail.com
---
v2: codestyle fixes, added VMStateDescription for LCD device and AER915,
traces clean up.
v3: no changes
v4: no changes
v5: use DPRINTF for debug-related traces, add missing fields to
VMStateDescription for LCD device and AER915
Makefile.target |1 +
hw/z2.c | 358
+++ 2 files changed,
359 insertions(+), 0 deletions(-)
create mode 100644 hw/z2.c
diff --git a/Makefile.target b/Makefile.target
index a53a2ff..9ed230d 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -360,6 +360,7 @@ obj-arm-y += omap2.o omap_dss.o soc_dma.o
omap_gptimer.o omap_synctimer.o \ obj-arm-y += omap_sx1.o palm.o tsc210x.o
obj-arm-y += nseries.o blizzard.o onenand.o vga.o cbus.o tusb6010.o
usb-musb.o obj-arm-y += mst_fpga.o mainstone.o
+obj-arm-y += z2.o
obj-arm-y += musicpal.o bitbang_i2c.o marvell_88w8618_audio.o
obj-arm-y += framebuffer.o
obj-arm-y += syborg.o syborg_fb.o syborg_interrupt.o syborg_keyboard.o
diff --git a/hw/z2.c b/hw/z2.c
new file mode 100644
index 000..f93a1bf
--- /dev/null
+++ b/hw/z2.c
@@ -0,0 +1,358 @@
+/*
+ * PXA270-based Zipit Z2 device
+ *
+ * Copyright (c) 2011 by Vasily Khoruzhick anars...@gmail.com
+ *
+ * Code is based on mainstone platform.
+ *
+ * This code is licensed under the GNU GPL v2.
+ */
+
+#include hw.h
+#include pxa.h
+#include arm-misc.h
+#include devices.h
+#include i2c.h
+#include ssi.h
+#include boards.h
+#include sysemu.h
+#include flash.h
+#include blockdev.h
+#include console.h
+#include audio/audio.h
+
+#ifdef DEBUG_Z2
+#define DPRINTF(fmt, ...) \
+printf(fmt, ## __VA_ARGS__)
+#else
+#define DPRINTF(fmt, ...)
+#endif
+
+static struct keymap map[0x100] = {
+[0 ... 0xff] = { -1, -1 },
+[0x3b] = {0, 0}, /* Option = F1 */
+[0xc8] = {0, 1}, /* Up */
+[0xd0] = {0, 2}, /* Down */
+[0xcb] = {0, 3}, /* Left */
+[0xcd] = {0, 4}, /* Right */
+[0xcf] = {0, 5}, /* End */
+[0x0d] = {0, 6}, /* KPPLUS */
+[0xc7] = {1, 0}, /* Home */
+[0x10] = {1, 1}, /* Q */
+[0x17] = {1, 2}, /* I */
+[0x22] = {1, 3}, /* G */
+[0x2d] = {1, 4}, /* X */
+[0x1c] = {1, 5}, /* Enter */
+[0x0c] = {1, 6}, /* KPMINUS */
+[0xc9] = {2, 0}, /* PageUp */
+[0x11] = {2, 1}, /* W */
+[0x18] = {2, 2}, /* O */
+[0x23] = {2, 3}, /* H */
+[0x2e] = {2, 4}, /* C */
+[0x38] = {2, 5}, /* LeftAlt */
+[0xd1] = {3, 0}, /* PageDown */
+[0x12] = {3, 1}, /* E */
+[0x19] = {3, 2}, /* P */
+[0x24] = {3, 3}, /* J */
+[0x2f] = {3, 4}, /* V */
+[0x2a] = {3, 5}, /* LeftShift */
+[0x01] = {4, 0}, /* Esc */
+[0x13] = {4, 1}, /* R */
+[0x1e] = {4, 2}, /* A */
+[0x25] = {4, 3}, /* K */
+[0x30] = {4, 4}, /* B */
+[0x1d] = {4, 5}, /* LeftCtrl */
+[0x0f] = {5, 0}, /* Tab */
+[0x14] = {5, 1}, /* T */
+[0x1f] = {5, 2}, /* S */
+[0x26] = {5, 3}, /* L */
+[0x31] = {5, 4}, /* N */
+[0x39] = {5, 5}, /* Space */
+[0x3c] = {6, 0}, /* Stop = F2 */
+[0x15] = {6, 1}, /* Y */
+[0x20] = {6, 2}, /* D */
+[0x0e] = {6, 3}, /* Backspace */
+[0x32] = {6, 4}, /* M */
+[0x33] = {6, 5}, /* Comma */
+[0x3d] = {7, 0}, /* Play = F3 */
+[0x16] = {7, 1}, /* U */
+[0x21] = {7, 2}, /* F */
+[0x2c] = {7, 3}, /* Z */
+[0x27] = {7, 4}, /* Semicolon */
+[0x34] = {7, 5}, /* Dot */
+};
+
+#define Z2_RAM_SIZE 0x0200
+#define Z2_FLASH_BASE 0x
+#define Z2_FLASH_SIZE 0x0080
+
+static struct arm_boot_info z2_binfo = {
+.loader_start = PXA2XX_SDRAM_BASE,
+.ram_size = Z2_RAM_SIZE,
+};
+
+#define Z2_GPIO_SD_DETECT 96
+#define Z2_GPIO_AC_IN 0
+#define Z2_GPIO_KEY_ON 1
+#define Z2_GPIO_LCD_CS 88
+
+typedef struct {
+SSISlave ssidev;
+int32_t selected;
+int32_t enabled;
+uint8_t buf[3];
+uint32_t cur_reg;
+int pos;
+} ZipitLCD;
+
+static uint32_t zipit_lcd_transfer(SSISlave *dev, uint32_t value)
+{
+ZipitLCD *z = FROM_SSI_SLAVE(ZipitLCD, dev);
+uint16_t val;
+if (z-selected) {
+z-buf[z-pos] = value 0xff;
+z-pos++;
+}
+if (z-pos == 3) {
+switch (z-buf[0]) {
+case 0x74:
+DPRINTF(%s: reg: 0x%.2x\n, __func__, z-buf[2]);
+z-cur_reg = z-buf[2];
+break;
+case 0x76:
+val = z-buf[1] 8 | z-buf[2];
+DPRINTF(%s: value: 0x%.4x\n, __func__, val);
+if (z-cur_reg == 0x22 val == 0x) {
+z-enabled = 1;
+printf(%s: LCD enabled\n, __func__);
+} else if (z-cur_reg == 0x10 val == 0x) {
+z-enabled = 0;
+printf(%s:
Re: [Qemu-devel] qdev for programmers writeup
On 07/11/2011 04:44 PM, Peter Maydell wrote: That's true, but the only way to plug in those device models would be with C code. You cannot just play with -device to reconfigure them. I think the C source level reuse is more important and more useful than plugging stuff around with -device, because in practice messing about with the memory map of an embedded board isn't something people typically want to do, because the kernel will have more-or-less hardcoded where the devices are anyhow. That's just because ARM doesn't (yet?) do device trees... :) (Also if you have one bus type per board then you're still very limited in what you can do with -device because you can't plug in some random other sysbus device anyway.) I'm not talking about one bus type per board! I'm talking about as few as possible board-specific root devices, and sharing buses between boards as much as possible. So if we want to allow runtime configurability of boards like that we need to do it by providing runtime configurability of sysbus devices. But we already have properties as a runtime configurability mechanism, and the additional functionality provided by SysBus is exactly to bypass it. In that sense SysBus is bad (if used widely as it is now). It is also bad because SysBus takes device metainformation (number of IRQ lines, size of MMIO and PIO areas) and puts it into per-device structure. I think it would be better to think of GPIO as a special (simple) case of a generic desire to plug devices into each other (this is what SystemC calls a port: basically an interface (API) defined so that two things can make calls to arbitrary callback functions on the other end of a connection). How ports are wired up is a property of the machine model, not a property of the device at either end But in practice you tend to have tree-like relationships. Even if it is just a two-level tree with a GPIO chip or interrupt controller at one end, and everything else at the other. Also, you want to be able to actually name your output pins, so at a board level you can talk about wiring up sd_controller.wprot, not sd_controller.gpio[3]... (Yes, this is to some extent just syntax but I really don't want to end up with machine level modelling looking like: It _is_ really just syntax. In my examples I used the raw values for GPIO pin numbers because that's what we have. So, right now there is no way to use symbolic values, but nothing forbids adding one. Or even automatically generating the QEMU .conf from something else. If you are using C code, of course you have #defines/enums. Well, it is clear that buses should be modelled after the way data flows. But what is data? If data is what is being written, buses should be modelled after the way memory transactions flow. If data is what is being made available, buses are modelled more after the way interrupts flow. GPIO is a strange thing in the middle. :) Actually I think we should really be modelling buses only where the hardware actually has a bus, ie a coherent collection of signals between multiple devices such that you could in theory plug in different devices in different slots. The memory transaction related connections are much more buslike than interrupt wiring. I'm not sure, perhaps the naming is bad. Abstracting from the name for a moment, unifying interrupts/GPIO with the qbus concept seemed natural to me in most of the cases I looked at. And it makes the handling of GPIO in qdev less schizophrenic; qdev seems to treat the qbus (whatever it is) as the One True Mechanism to join devices, and then adds GPIO on the side while providing no way to configure it. If you try to match the qdev tree with the tree of qemu_irq, the design becomes a lot more coherent. Paolo
Re: [Qemu-devel] migration: new sections and backward compatibility.
On 07/11/2011 05:32 PM, Kevin Wolf wrote: I'd guess the best would be to have a special VMSTATE that means broken old version doesn't send a section which we can set for special -M? No, the best would be to have a serious migration format, based for example on ASN.1 which Michael Tsirkin was playing with. We cannot keep bolting more and more stuff on top of the current protocol, especially since adding a new protocol is not that hard (old machine types can keep the old protocol). And even more so with the old format being ambiguous. We haven't decided yet what to do with subsections of structs, have we? I hope to test this week the prototype I sent. Paolo
Re: [Qemu-devel] [Bug 808737] Re: No option to load additional binary files from command line in QEMU
On 11 July 2011 16:23, Stefan Hajnoczi stefa...@gmail.com wrote: Doesn't arm_boot.c already load an arbitrary binary when the image is neither a kernel ELF or uboot image? I don't know the arm_boot.c details but skimming the source shows it already does load_image_targphys(). The assumption is that an ELF image is a random raw binary, and a non-ELF image is an actual kernel. I hate this and would much rather we had a more generic way of saying look, just load this ELF file into physical memory please (and that -kernel always treated its argument as an actual kernel, but that would break backwards compatibility :-() -- PMM -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/808737 Title: No option to load additional binary files from command line in QEMU Status in QEMU: New Bug description: There is no command line option like -kerner, or -initrd to load an arbitrary binary file to a RAM location when launching QEMU. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/808737/+subscriptions
[Qemu-devel] [PATCH 2/2] syscall: pselect arg_sigsize variable was write only
Remove it.
Signed-off-by: Juan Quintela quint...@redhat.com
---
linux-user/syscall.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index fed7a8f..35bbe36 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -5634,7 +5634,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
size_t size;
} sig, *sig_ptr;
-abi_ulong arg_sigset, arg_sigsize, *arg7;
+abi_ulong arg_sigset, *arg7;
target_sigset_t *target_sigset;
n = arg1;
@@ -5679,7 +5679,6 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
goto efault;
}
arg_sigset = tswapl(arg7[0]);
-arg_sigsize = tswapl(arg7[1]);
unlock_user(arg7, arg6, 0);
if (arg_sigset) {
--
1.7.6
[Qemu-devel] [PATCH 0/2] Yet more gcc warnings fixes
More places that have write only variables.
Once here, why we have clovvered arg7 is a good question (TM)
abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
abi_long arg2, abi_long arg3, abi_long arg4,
abi_long arg5, abi_long arg6, abi_long arg7,
abi_long arg8)
{
.
abi_ulong arg_sigset, *arg7;
Using a different name could be a good idea.
Please, apply.
Later, Juan.
Juan Quintela (2):
xen_mapcache: remove unused variable
syscall: pselect arg_sigsize variable was write only
linux-user/syscall.c |3 +--
xen-mapcache.c |3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
--
1.7.6
[Qemu-devel] [PATCH 1/2] xen_mapcache: remove unused variable
Signed-off-by: Juan Quintela quint...@redhat.com
---
xen-mapcache.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/xen-mapcache.c b/xen-mapcache.c
index fac47cd..e2e324d 100644
--- a/xen-mapcache.c
+++ b/xen-mapcache.c
@@ -232,7 +232,7 @@ uint8_t *qemu_map_cache(target_phys_addr_t phys_addr,
target_phys_addr_t size, u
ram_addr_t qemu_ram_addr_from_mapcache(void *ptr)
{
-MapCacheEntry *entry = NULL, *pentry = NULL;
+MapCacheEntry *entry = NULL;
MapCacheRev *reventry;
target_phys_addr_t paddr_index;
target_phys_addr_t size;
@@ -258,7 +258,6 @@ ram_addr_t qemu_ram_addr_from_mapcache(void *ptr)
entry = mapcache-entry[paddr_index % mapcache-nr_buckets];
while (entry (entry-paddr_index != paddr_index || entry-size !=
size)) {
-pentry = entry;
entry = entry-next;
}
if (!entry) {
--
1.7.6
Re: [Qemu-devel] [PATCH 2/2] syscall: pselect arg_sigsize variable was write only
On 11 July 2011 17:15, Juan Quintela quint...@redhat.com wrote: Remove it. Signed-off-by: Juan Quintela quint...@redhat.com http://patchwork.ozlabs.org/patch/104232/ in the current linux-user pullreq is a fix for this. -- PMM
Re: [Qemu-devel] [PATCH 1/1] QMP: add snapshot_blkdev command
On Fri, 8 Jul 2011 14:00:13 +0200
jes.soren...@redhat.com wrote:
From: Jes Sorensen jes.soren...@redhat.com
Add QMP bits for snapshot_blkdev command. This is the same as
snapshot_blkdev in the human monitor. The command is synchronous.
In the future async commands and or a break down of the functionality
into multiple commands might be added.
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
qmp-commands.hx | 38 ++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 92c5c3a..eb135c1 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -694,6 +694,44 @@ Example:
EQMP
{
+.name = blockdev-snapshot,
blockdev-snapshot-sync.
+.args_type = device:B,snapshot_file:s?,format:s?,
+.params = device [new-image-file] [format],
+.help = initiates a live snapshot\n\t\t\t
+ of device. If a new image file is specified,
the\n\t\t\t
+ new image file will become the new root
image.\n\t\t\t
+ If format is specified, the snapshot file
will\n\t\t\t
+ be created in that format. Otherwise the\n\t\t\t
+ snapshot will be internal! (currently unsupported),
The 'otherwise' part is a bit confusing. You document something as if it were
supported then you say it's not supported. I recommend to just not document it
instead.
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_snapshot_blkdev,
+},
+
+SQMP
+blockdev-snapshot-sync
+--
+
+Synchronous snapshot of block device, using snapshot file as target,
+if provided.
In QMP only this text is used, the text in '.help' is discarded. Please,
move all command documentation here.
+
+Arguments:
+
+- device: device name to snapshot (json-string)
+- snapshot_file: name of new image file (json-string)
+- format: format of new image (json-string)
+
+Example:
+
+- { execute: blockdev-snapshot, arguments: { device: ide-hd0,
+snapshot_file:
We are trying to standardize the use of hyphen in QMP.
+/some/place/my-image,
+ format: qcow2
+ } }
+- { return: {} }
+
+EQMP
+
+{
.name = balloon,
.args_type = value:M,
.params = target,
Re: [Qemu-devel] qdev for programmers writeup
On 11 July 2011 16:29, Paolo Bonzini pbonz...@redhat.com wrote: On 07/11/2011 04:44 PM, Peter Maydell wrote: (Also if you have one bus type per board then you're still very limited in what you can do with -device because you can't plug in some random other sysbus device anyway.) I'm not talking about one bus type per board! I'm talking about as few as possible board-specific root devices, and sharing buses between boards as much as possible. Er, doesn't that just get you sysbus again? Also if you have a root device and it's not the CPU then something's a bit odd. (The CPU lives above the interrupt controller in the interrupt tree if you want to look at it like that.) So if we want to allow runtime configurability of boards like that we need to do it by providing runtime configurability of sysbus devices. But we already have properties as a runtime configurability mechanism, and the additional functionality provided by SysBus is exactly to bypass it. In that sense SysBus is bad (if used widely as it is now). It is also bad because SysBus takes device metainformation (number of IRQ lines, size of MMIO and PIO areas) and puts it into per-device structure. I think the real reason so many devices use sysbus is that it is basically I'm a device and I support some gpio signals and some memory mappings, which is just a very natural way to model a lot of things. It's also an easy to use API for machine models to instantiate and wire up both IRQs and memory mappings. If we want less use of sysbus then we need to have the basic qdev device model have much better support for doing this. I think it would be better to think of GPIO as a special (simple) case of a generic desire to plug devices into each other (this is what SystemC calls a port: basically an interface (API) defined so that two things can make calls to arbitrary callback functions on the other end of a connection). How ports are wired up is a property of the machine model, not a property of the device at either end But in practice you tend to have tree-like relationships. Even if it is just a two-level tree with a GPIO chip or interrupt controller at one end, and everything else at the other. Yes, but the tree-like relation of the memory transaction bus/interconnect isn't necessarily the same as the tree-like relation of the interrupt controllers; and the tree-like relation of the clocks might be different again. And even if things tend to be tree-like, you still need to support arbitrary inter-wiring for the corner cases (like this MMC controller's 'card present' wire needs to connect to the board-register model's input). You can model trees with arbitrary interconnections, but not vice-versa. Insisting that interrupts are always a tree also rules out ever having qemu support multiple distinct CPUs where some interrupt sources end up going to more than one CPU; I'd rather we didn't bake that kind of assumption into the core device model if possible. (This view of the world, which I accept is not really qdev's, says that a bus is really just a conveniently named and manipulable bundle of connections.) -- PMM
Re: [Qemu-devel] [PATCH 1/1] QMP: add snapshot_blkdev command
On Mon, 11 Jul 2011 19:50:45 +0200
Jes Sorensen jes.soren...@redhat.com wrote:
On 07/11/11 18:35, Luiz Capitulino wrote:
On Fri, 8 Jul 2011 14:00:13 +0200
jes.soren...@redhat.com wrote:
From: Jes Sorensen jes.soren...@redhat.com
Add QMP bits for snapshot_blkdev command. This is the same as
snapshot_blkdev in the human monitor. The command is synchronous.
In the future async commands and or a break down of the functionality
into multiple commands might be added.
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
qmp-commands.hx | 38 ++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 92c5c3a..eb135c1 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -694,6 +694,44 @@ Example:
EQMP
{
+.name = blockdev-snapshot,
blockdev-snapshot-sync.
argh, will fix
+.args_type = device:B,snapshot_file:s?,format:s?,
+.params = device [new-image-file] [format],
+.help = initiates a live snapshot\n\t\t\t
+ of device. If a new image file is specified,
the\n\t\t\t
+ new image file will become the new root
image.\n\t\t\t
+ If format is specified, the snapshot file
will\n\t\t\t
+ be created in that format. Otherwise the\n\t\t\t
+ snapshot will be internal! (currently
unsupported),
The 'otherwise' part is a bit confusing. You document something as if it
were
supported then you say it's not supported. I recommend to just not document
it
instead.
Ok
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_snapshot_blkdev,
+},
+
+SQMP
+blockdev-snapshot-sync
+--
+
+Synchronous snapshot of block device, using snapshot file as target,
+if provided.
In QMP only this text is used, the text in '.help' is discarded. Please,
move all command documentation here.
If .help isn't used, then please remove it from the struct. It is really
pointless to keep carrying both around.
Yes, sorry for that. It will be completely dropped when we move to the QAPI
(which uses a schema file).
+
+Arguments:
+
+- device: device name to snapshot (json-string)
+- snapshot_file: name of new image file (json-string)
+- format: format of new image (json-string)
+
+Example:
+
+- { execute: blockdev-snapshot, arguments: { device: ide-hd0,
+snapshot_file:
We are trying to standardize the use of hyphen in QMP.
Sorry, but I haven't got a clue what you mean here.
The argument is called snapshot_file but it should be called snapshot-file.
[Qemu-devel] [PATCH v3] QMP: add snapshot_blkdev command
From: Jes Sorensen jes.soren...@redhat.com
Add QMP bits for snapshot_blkdev command. This is the same as
snapshot_blkdev in the human monitor. The command is synchronous.
In the future async commands and or a break down of the functionality
into multiple commands might be added.
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
qmp-commands.hx | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 92c5c3a..2b9f6af 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -694,6 +694,41 @@ Example:
EQMP
{
+.name = blockdev-snapshot-sync,
+.args_type = device:B,snapshot-file:s?,format:s?,
+.params = device [new-image-file] [format],
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_snapshot_blkdev,
+},
+
+SQMP
+blockdev-snapshot-sync
+--
+
+Synchronous snapshot of a block device. snapshot_file specifies the
+target of the new image. If the file exists, or if it is a device, the
+snapshot will be created in the existing file/device. If does not
+exist, a new file will be created. format specifies the format of the
+snapshot image, default is qcow2.
+
+Arguments:
+
+- device: device name to snapshot (json-string)
+- snapshot_file: name of new image file (json-string)
+- format: format of new image (json-string)
+
+Example:
+
+- { execute: blockdev-snapshot, arguments: { device: ide-hd0,
+snapshot-file:
+/some/place/my-image,
+ format: qcow2
+ } }
+- { return: {} }
+
+EQMP
+
+{
.name = balloon,
.args_type = value:M,
.params = target,
--
1.7.4.4
Re: [Qemu-devel] [PATCH v1 0/8]: QMP: Thin provisioning support
On Tue, 5 Jul 2011 15:17:43 -0300 Luiz Capitulino lcapitul...@redhat.com wrote: Roughly speaking, thin provisioning is a feature where the VM is started with a small storage and when a no space error is triggered, more space is allocated and the VM is put to run again. block guys ping? This series has some block layer changes which would be nice to get feedback from you. This series allows a management tool using QMP to implement thin provisioning support. It does the following: 1. patches 1/8 and 2/8 extend the query-status command to contain a more complete and descriptive status 2. patches 3/8 to 6/8 add support to the block layer to track the status of the last executed I/O operation. This is supported by ide, virtio and scsi devices 3. The last two patches extend the query-block and info block commands to print the last I/O status field (this is per device) Basically, all a management tool has to do to implement thin provisioning is to wait for a BLOCK_IO_ERROR event (or the STOP event), check the VM is stopped by issuing query-status and then find which device failed by using query-block. Of course that the VM has to be configured to stop on errors. A last important detail: Anthony has proposed how the query-status command should be extended to support this[1]. However, I had to make the following changes to his original proposal: - Added states: debug, inmigrate, load-state-error and internal-error - Dropped: singlestep You'll find more details in the patches, thanks! [1] http://lists.nongnu.org/archive/html/qemu-devel/2011-06/msg00352.html block.c | 37 - block.h |7 +++ block_int.h |2 ++ gdbstub.c |4 hw/ide/core.c |6 ++ hw/scsi-disk.c |7 +++ hw/virtio-blk.c |4 hw/watchdog.c |1 + kvm-all.c |1 + migration.c |3 +++ monitor.c |8 +--- qmp-commands.hx | 23 ++- sysemu.h| 19 +++ vl.c| 37 + 14 files changed, 154 insertions(+), 5 deletions(-)
Re: [Qemu-devel] live block copy/stream/snapshot discussion
On Mon, Jul 11, 2011 at 03:47:15PM +0100, Stefan Hajnoczi wrote:
Kevin, Marcelo,
I'd like to reach agreement on the QMP/HMP APIs for live block copy
and image streaming. Libvirt has acked the image streaming APIs that
Adam proposed and I think they are a good fit for the feature. I have
described that API below for your review (it's exactly what the QED
Image Streaming patches provide).
Marcelo: Are you happy with this API for live block copy? Also please
take a look at the switch command that I am proposing.
Image streaming API
===
For leaf images with copy-on-read semantics, the stream commands allow the
user
to populate local blocks by manually streaming them from the backing image.
Once all blocks have been streamed, the dependency on the original backing
image can be removed. Therefore, stream commands can be used to implement
post-copy live block migration and rapid deployment.
The block_stream command can be used to stream a single cluster, to
start streaming the entire device, and to cancel an active stream. It
is easiest to allow the block_stream command to manage streaming for the
entire device but a managent tool could use single cluster mode to
throttle the I/O rate.
The command synopses are as follows:
block_stream
Copy data from a backing file into a block device.
If the optional 'all' argument is true, this operation is performed in the
background until the entire backing file has been copied. The status of
ongoing block_stream operations can be checked with query-block-stream.
Arguments:
- all:copy entire device (json-bool, optional)
- stop: stop copying to device (json-bool, optional)
- device: device name (json-string)
It must be possible to specify backing file that will be
active after streaming finishes (data from that file will not
be streamed into active file, of course).
Return:
- device: device name (json-string)
- len:size of the device, in bytes (json-int)
- offset: ending offset of the completed I/O, in bytes (json-int)
Examples:
- { execute: block_stream, arguments: { device: virtio0 } }
- { return: { device: virtio0, len: 10737418240, offset: 512 } }
- { execute: block_stream, arguments: { all: true, device:
virtio0 } }
- { return: {} }
- { execute: block_stream, arguments: { stop: true, device:
virtio0 } }
- { return: {} }
query-block-stream
--
Show progress of ongoing block_stream operations.
Return a json-array of all operations. If no operation is active then an
empty
array will be returned. Each operation is a json-object with the following
data:
- device: device name (json-string)
- len:size of the device, in bytes (json-int)
- offset: ending offset of the completed I/O, in bytes (json-int)
Example:
- { execute: query-block-stream }
- { return:[
{ device: virtio0, len: 10737418240, offset: 709632}
]
}
Block device switching API
==
Extend the 'change' command to support changing the image file without
media change notification.
Perhaps we should take the opportunity to add a format argument for
image files?
change
--
Change a removable medium or VNC configuration.
Arguments:
- device: device name (json-string)
- target: filename or item (json-string)
- arg: additional argument (json-string, optional)
- notify: whether to notify guest, defaults to true (json-bool, optional)
Examples:
1. Change a removable medium
- { execute: change,
arguments: { device: ide1-cd0,
target: /srv/images/Fedora-12-x86_64-DVD.iso
} }
- { return: {} }
2. Change a disk without media change notification
- { execute: change,
arguments: { device: virtio-blk0,
target: /srv/images/vm_1.img,
notify: false } }
3. Change VNC password
- { execute: change,
arguments: { device: vnc, target: password,
arg: foobar1 } }
- { return: {} }
How live block copy works
=
Live block copy does the following:
1. Create the destination file: qemu-img create -f $cow_fmt -o
backing_file=$base destination.$cow_fmt
2. Switch to the destination file: change -n virtio-blk0 /srv/images/vm_1.img
The snapshot command (snapshot_blkdev) can be used for these two steps.
3. Stream the base into the image file: block_stream -a virtio-blk0
Stefan
[Qemu-devel] How to measure guest instruction count ?
Hi all, I am new to qemu. Recently, I was trying to measure the performance(MIPS) of qemu executing splash2 benchmark. At first, I am trying the -icount flag built in qemu, but with the limited user manual. I also read the post on Qemu-devel Precise guest instruction count.http://lists.gnu.org/archive/html/qemu-devel/2009-03/msg00498.html I can not understand how it works very well. Can anyone explain to me how to get the instruction count number by the -icount feature? Also, in order to get an accurate performance, I need to skip the instructions during boot up process. I want to only calculate the instruction count of executing the splash2 benchmark. Can anyone give me some hint where can I start with? If I am not clear enough, please let me know. Thanks in advance for any reply. Jeff Yu
Re: [Qemu-devel] [PATCH 1/1] QMP: add snapshot_blkdev command
On 07/11/11 18:35, Luiz Capitulino wrote:
On Fri, 8 Jul 2011 14:00:13 +0200
jes.soren...@redhat.com wrote:
From: Jes Sorensen jes.soren...@redhat.com
Add QMP bits for snapshot_blkdev command. This is the same as
snapshot_blkdev in the human monitor. The command is synchronous.
In the future async commands and or a break down of the functionality
into multiple commands might be added.
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
qmp-commands.hx | 38 ++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 92c5c3a..eb135c1 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -694,6 +694,44 @@ Example:
EQMP
{
+.name = blockdev-snapshot,
blockdev-snapshot-sync.
argh, will fix
+.args_type = device:B,snapshot_file:s?,format:s?,
+.params = device [new-image-file] [format],
+.help = initiates a live snapshot\n\t\t\t
+ of device. If a new image file is specified,
the\n\t\t\t
+ new image file will become the new root
image.\n\t\t\t
+ If format is specified, the snapshot file
will\n\t\t\t
+ be created in that format. Otherwise the\n\t\t\t
+ snapshot will be internal! (currently unsupported),
The 'otherwise' part is a bit confusing. You document something as if it were
supported then you say it's not supported. I recommend to just not document it
instead.
Ok
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_snapshot_blkdev,
+},
+
+SQMP
+blockdev-snapshot-sync
+--
+
+Synchronous snapshot of block device, using snapshot file as target,
+if provided.
In QMP only this text is used, the text in '.help' is discarded. Please,
move all command documentation here.
If .help isn't used, then please remove it from the struct. It is really
pointless to keep carrying both around.
+
+Arguments:
+
+- device: device name to snapshot (json-string)
+- snapshot_file: name of new image file (json-string)
+- format: format of new image (json-string)
+
+Example:
+
+- { execute: blockdev-snapshot, arguments: { device: ide-hd0,
+snapshot_file:
We are trying to standardize the use of hyphen in QMP.
Sorry, but I haven't got a clue what you mean here.
Jes
[Qemu-devel] [Bug 808588] Re: Netperf tests cause i82551 network down
** Changed in: qemu Assignee: (unassigned) = Stefan Weil (ubuntu-weilnetz) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/808588 Title: Netperf tests cause i82551 network down Status in QEMU: New Bug description: 1. boot up a guest with 82551 nic # qemu-kvm -net nic,model=i82551 ... 2. launch netperf server in the guest 3.on the host for b in 32 64 128 256 512 1024 1460 2048 4096 8192 9000 16384 32768 65495 65507 do ./netperf -t TCP_STREAM -f m -H guest ip -P 0 -l 10 -- -m $b done for b in 32 64 128 256 512 1024 1460 2048 4096 8192 9000 16384 32768 65495 65507 do ./netperf -t UDP_STREAM -f m -H guest ip -P 0 -l 10 -- -m $b done Result: Guest network becomes down netperf client output: ./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 32 87380 16384 3210.97 19.61 ./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 64 87380 16384 6411.55 79.68 ./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 128 87380 1638412810.16 14.20 ./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 256 87380 1638425611.17 12.85 ./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 512 87380 1638451210.01 16.38 ./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 1024 Interrupted system call netperf: remote error 4./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 1460 establish control: are you sure there is a netserver listening on 10.66.9.39 at port 12865? establish_control could not establish the control connection from 0.0.0.0 port 0 address family AF_UNSPEC to 10.66.9.39 port 12865 address family AF_UNSPEC ./netperf -t TCP_STREAM -f m -H 10.66.9.39 -P 0 -l 10 -- -m 2048 qemu debug message: EE100 nic_receive command 0x, link 0x3d3e6822, addr 0x, size 1518 EE100 nic_can_receive 0x29a0180 EE100 nic_receive 0x29a0180 received broadcast, len=60 EE100 nic_receive Receive buffer (0 bytes) too small for data (60 bytes); data truncated EE100 nic_receive command 0x8000, link 0x37b32022, addr 0x, size 0 ^^ EE100 nic_receive receive: Running out of frames EE100 eepro100_write1 addr=Command/Status+1 val=0x20 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/808588/+subscriptions
Re: [Qemu-devel] qemu - SCSI disk Device Model, Serial Number, and Firmware Version?
* Dave Seddon d...@seddon.ca [2011-06-07 02:28]: Greetings, Just wondering if it would be difficult to add the ability to define the SCSI disk Device Model, Serial Number, and Firmware Version. I've been using the '-device lsi' successfully to emulate the LSI controller, but now I want to emulate certain disks too. e.g. I've been using this: --- ... -drive if=none,id=disk00,file=/home/das/documents/qemu/disk00.img.qcow,media=disk,cache=writeback \ -device lsi \ -device scsi-disk,drive=disk00,bus=scsi.0 \ ... --- The reason this would be really cool is that tools like smartmontools seem to match on the Device Model, and the device-model QEMU hasn't made it into the list yet. What's the end goal here? Are you really passing an entire disk to the guest and want to have the guest monitor the device? If not, then I suggest just disabling smartmontools since it won't give you meaningful data anyhow. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ry...@us.ibm.com
[Qemu-devel] [Bug 802588] Re: Latest GIT version fails to compile on Linux - setjmp.h problem
Patch http://patchwork.ozlabs.org/patch/103157/ is a possible solution for this problem. ** Changed in: qemu Assignee: (unassigned) = Stefan Weil (ubuntu-weilnetz) ** Changed in: qemu Status: New = Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/802588 Title: Latest GIT version fails to compile on Linux - setjmp.h problem Status in QEMU: Fix Committed Bug description: Git version: f26e428da505709ec03b2ed2c9eb3db82b30bd7b Gcc: 4.6.1 Host: Debinan/x86_64 Fails to compile at In file included from /usr/include/png.h:518:0, from ui/vnc-enc-tight.c:37: /usr/include/pngconf.h: At top level: /usr/include/pngconf.h:371:21: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘.’ token /usr/include/pngconf.h:372:12: error: unknown type name ‘__dont__’ /usr/include/pngconf.h:372:29: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘it’ /usr/include/pngconf.h:372:29: error: unknown type name ‘it’ Looking at pngconf.h around line 370 gives the reason for the compilation failure: # ifdef _SETJMP_H /* If you encounter a compiler error here, see the explanation * near the end of INSTALL. */ __pngconf.h__ in libpng already includes setjmp.h; __dont__ include it again.; # endif To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/802588/+subscriptions
Re: [Qemu-devel] [PATCH 2/2] syscall: pselect arg_sigsize variable was write only
Juan Quintela quint...@redhat.com wrote: Remove it. Signed-off-by: Juan Quintela quint...@redhat.com /me nacks himself Peter one is better, it even makes sense, go figure O:-)
[Qemu-devel] [PATCH v2 5/5] block: add bdrv_copy_header()
Signed-off-by: Devin Nakamura devin...@gmail.com
---
block.c | 12
block.h |2 ++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/block.c b/block.c
index 39510cb..69a3e13 100644
--- a/block.c
+++ b/block.c
@@ -3065,3 +3065,15 @@ int bdrv_map(BlockDriverState *bs, uint64_t
*guest_offset,
return drv-bdrv_map(bs, guest_offset, host_offset,
contiguous_bytes);
}
+
+int bdrv_copy_header(BlockDriverState *bs)
+{
+BlockDriver *drv = bs-drv;
+if (!drv) {
+return -ENOMEDIUM;
+}
+if (!drv-bdrv_copy_header) {
+return -ENOTSUP;
+}
+return drv-bdrv_copy_header(bs);
+}
diff --git a/block.h b/block.h
index ed21ead..0583875 100644
--- a/block.h
+++ b/block.h
@@ -256,6 +256,8 @@ int bdrv_get_mapping(BlockDriverState *bs, uint64_t
*guest_offset,
uint64_t *host_offset, uint64_t *contiguous_bytes);
int bdrv_map(BlockDriverState *bs, uint64_t *guest_offset,
uint64_t *host_offset, uint64_t *contiguous_bytes);
+int bdrv_copy_header(BlockDriverState *bs);
+
typedef enum {
BLKDBG_L1_UPDATE,
--
1.7.6.rc1
[Qemu-devel] [PATCH v2 4/5] block: add bdrv_map()
Signed-off-by: Devin Nakamura devin...@gmail.com
---
block.c | 14 ++
block.h |2 ++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/block.c b/block.c
index 3874ed5..39510cb 100644
--- a/block.c
+++ b/block.c
@@ -3051,3 +3051,17 @@ int bdrv_get_mapping(BlockDriverState *bs, uint64_t
*guest_offset,
return drv-bdrv_get_mapping(bs, guest_offset, host_offset,
contiguous_bytes);
}
+
+int bdrv_map(BlockDriverState *bs, uint64_t *guest_offset,
+ uint64_t *host_offset, uint64_t *contiguous_bytes)
+{
+BlockDriver *drv = bs-drv;
+if (!drv) {
+return -ENOMEDIUM;
+}
+if (!drv-bdrv_map) {
+return -ENOTSUP;
+}
+return drv-bdrv_map(bs, guest_offset, host_offset,
+contiguous_bytes);
+}
diff --git a/block.h b/block.h
index 8207389..ed21ead 100644
--- a/block.h
+++ b/block.h
@@ -254,6 +254,8 @@ int bdrv_open_conversion_target(BlockDriverState **bs, char
*filename,
char *target_fmt, QEMUOptionParameter
*options);
int bdrv_get_mapping(BlockDriverState *bs, uint64_t *guest_offset,
uint64_t *host_offset, uint64_t *contiguous_bytes);
+int bdrv_map(BlockDriverState *bs, uint64_t *guest_offset,
+ uint64_t *host_offset, uint64_t *contiguous_bytes);
typedef enum {
BLKDBG_L1_UPDATE,
--
1.7.6.rc1
[Qemu-devel] [PATCH v2 3/5] block: add bdrv_get_mapping()
Signed-off-by: Devin Nakamura devin...@gmail.com
---
block.c | 14 ++
block.h |2 ++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/block.c b/block.c
index 97d5a6b..3874ed5 100644
--- a/block.c
+++ b/block.c
@@ -3037,3 +3037,17 @@ int bdrv_open_conversion_target(BlockDriverState **bs,
(*bs)-opaque = qemu_malloc(drv-instance_size);
return drv-bdrv_open_conversion_target(*bs, filename, options);
}
+
+int bdrv_get_mapping(BlockDriverState *bs, uint64_t *guest_offset,
+ uint64_t *host_offset, uint64_t *contiguous_bytes)
+{
+BlockDriver *drv = bs-drv;
+if (!drv) {
+return -ENOMEDIUM;
+}
+if (!drv-bdrv_get_mapping) {
+return -ENOTSUP;
+}
+return drv-bdrv_get_mapping(bs, guest_offset, host_offset,
+contiguous_bytes);
+}
diff --git a/block.h b/block.h
index da87afb..8207389 100644
--- a/block.h
+++ b/block.h
@@ -252,6 +252,8 @@ int bdrv_in_use(BlockDriverState *bs);
int bdrv_open_conversion_target(BlockDriverState **bs, char *filename,
char *target_fmt, QEMUOptionParameter
*options);
+int bdrv_get_mapping(BlockDriverState *bs, uint64_t *guest_offset,
+ uint64_t *host_offset, uint64_t *contiguous_bytes);
typedef enum {
BLKDBG_L1_UPDATE,
--
1.7.6.rc1
Re: [Qemu-devel] [PATCH v6 4/4] guest agent: add guest agent RPCs/commands
On 07/08/2011 10:14 AM, Luiz Capitulino wrote:
On Tue, 5 Jul 2011 08:21:40 -0500
Michael Rothmdr...@linux.vnet.ibm.com wrote:
This adds the initial set of QMP/QAPI commands provided by the guest
agent:
guest-sync
guest-ping
guest-info
guest-shutdown
guest-file-open
guest-file-read
guest-file-write
guest-file-seek
guest-file-close
guest-fsfreeze-freeze
guest-fsfreeze-thaw
guest-fsfreeze-status
The input/output specification for these commands are documented in the
schema.
Example usage:
host:
qemu -device virtio-serial \
-chardev socket,path=/tmp/vs0.sock,server,nowait,id=qga0 \
-device virtserialport,chardev=qga0,name=qga0
...
echo {'execute':'guest-info'} | socat stdio \
unix-connect:/tmp/qga0.sock
guest:
qemu-ga -c virtio-serial -p /dev/virtio-ports/qga0 \
-p /var/run/qemu-guest-agent.pid -d
Signed-off-by: Michael Rothmdr...@linux.vnet.ibm.com
---
Makefile | 15 ++-
qemu-ga.c |4 +
qerror.h |3 +
qga/guest-agent-commands.c | 501
qga/guest-agent-core.h |2 +
5 files changed, 523 insertions(+), 2 deletions(-)
create mode 100644 qga/guest-agent-commands.c
diff --git a/Makefile b/Makefile
index b2e8593..7e4f722 100644
--- a/Makefile
+++ b/Makefile
@@ -175,15 +175,26 @@ $(qapi-dir)/test-qmp-commands.h:
$(qapi-dir)/test-qmp-marshal.c
$(qapi-dir)/test-qmp-marshal.c: $(SRC_PATH)/qapi-schema-test.json
$(SRC_PATH)/scripts/qapi-commands.py
$(call quiet-command,python $(SRC_PATH)/scripts/qapi-commands.py -o $(qapi-dir) -p
test- $, GEN $@)
+$(qapi-dir)/qga-qapi-types.c: $(qapi-dir)/qga-qapi-types.h
+$(qapi-dir)/qga-qapi-types.h: $(SRC_PATH)/qapi-schema-guest.json
$(SRC_PATH)/scripts/qapi-types.py
+ $(call quiet-command,python $(SRC_PATH)/scripts/qapi-types.py -o $(qapi-dir) -p
qga- $, GEN $@)
+$(qapi-dir)/qga-qapi-visit.c: $(qapi-dir)/qga-qapi-visit.h
+$(qapi-dir)/qga-qapi-visit.h: $(SRC_PATH)/qapi-schema-guest.json
$(SRC_PATH)/scripts/qapi-visit.py
+ $(call quiet-command,python $(SRC_PATH)/scripts/qapi-visit.py -o $(qapi-dir) -p
qga- $, GEN $@)
+$(qapi-dir)/qga-qmp-marshal.c: $(SRC_PATH)/qapi-schema-guest.json
$(SRC_PATH)/scripts/qapi-commands.py
+ $(call quiet-command,python $(SRC_PATH)/scripts/qapi-commands.py -o $(qapi-dir) -p
qga- $, GEN $@)
+
test-visitor.o: $(addprefix $(qapi-dir)/, test-qapi-types.c test-qapi-types.h
test-qapi-visit.c test-qapi-visit.h)
test-visitor: test-visitor.o qfloat.o qint.o qdict.o qstring.o qlist.o
qbool.o $(qapi-obj-y) error.o osdep.o qemu-malloc.o $(oslib-obj-y) qjson.o
json-streamer.o json-lexer.o json-parser.o qerror.o qemu-error.o qemu-tool.o
$(qapi-dir)/test-qapi-visit.o $(qapi-dir)/test-qapi-types.o
test-qmp-commands.o: $(addprefix $(qapi-dir)/, test-qapi-types.c
test-qapi-types.h test-qapi-visit.c test-qapi-visit.h test-qmp-marshal.c
test-qmp-commands.h)
test-qmp-commands: test-qmp-commands.o qfloat.o qint.o qdict.o qstring.o
qlist.o qbool.o $(qapi-obj-y) error.o osdep.o qemu-malloc.o $(oslib-obj-y)
qjson.o json-streamer.o json-lexer.o json-parser.o qerror.o qemu-error.o
qemu-tool.o $(qapi-dir)/test-qapi-visit.o $(qapi-dir)/test-qapi-types.o
$(qapi-dir)/test-qmp-marshal.o module.o
-QGALIB=qga/guest-agent-command-state.o
+QGALIB=qga/guest-agent-command-state.o qga/guest-agent-commands.o
+
+qemu-ga.o: $(qapi-dir)/qga-qapi-types.c $(qapi-dir)/qga-qapi-types.h
$(qapi-dir)/qga-qapi-visit.c $(qapi-dir)/qga-qmp-marshal.c
-qemu-ga$(EXESUF): qemu-ga.o $(QGALIB) qemu-tool.o qemu-error.o error.o
$(oslib-obj-y) $(trace-obj-y) $(block-obj-y) $(qobject-obj-y) $(version-obj-y)
$(qapi-obj-y) qemu-timer-common.o qemu-sockets.o module.o qapi/qmp-dispatch.o
qapi/qmp-registry.o
+qemu-ga$(EXESUF): qemu-ga.o $(QGALIB) qemu-tool.o qemu-error.o error.o
$(oslib-obj-y) $(trace-obj-y) $(block-obj-y) $(qobject-obj-y) $(version-obj-y)
$(qapi-obj-y) qemu-timer-common.o qemu-sockets.o module.o qapi/qmp-dispatch.o
qapi/qmp-registry.o $(qapi-dir)/qga-qapi-visit.o $(qapi-dir)/qga-qmp-marshal.o
QEMULIBS=libhw32 libhw64 libuser libdis libdis-user
diff --git a/qemu-ga.c b/qemu-ga.c
index 649c16a..04ead22 100644
--- a/qemu-ga.c
+++ b/qemu-ga.c
@@ -637,6 +637,9 @@ int main(int argc, char **argv)
g_log_set_default_handler(ga_log, s);
g_log_set_fatal_mask(NULL, G_LOG_LEVEL_ERROR);
s-logging_enabled = true;
+s-command_state = ga_command_state_new();
+ga_command_state_init(s, s-command_state);
+ga_command_state_init_all(s-command_state);
ga_state = s;
module_call_init(MODULE_INIT_QAPI);
@@ -645,6 +648,7 @@ int main(int argc, char **argv)
g_main_loop_run(ga_state-main_loop);
+ga_command_state_cleanup_all(ga_state-command_state);
unlink(pidfile);
return 0;
diff --git a/qerror.h b/qerror.h
index 9a9fa5b..0f618ac 100644
--- a/qerror.h
+++ b/qerror.h
@@
Re: [Qemu-devel] [PATCH v3] QMP: add snapshot_blkdev command
On Mon, 11 Jul 2011 20:01:09 +0200
jes.soren...@redhat.com wrote:
From: Jes Sorensen jes.soren...@redhat.com
Add QMP bits for snapshot_blkdev command. This is the same as
snapshot_blkdev in the human monitor. The command is synchronous.
In the future async commands and or a break down of the functionality
into multiple commands might be added.
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
qmp-commands.hx | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 92c5c3a..2b9f6af 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -694,6 +694,41 @@ Example:
EQMP
{
+.name = blockdev-snapshot-sync,
+.args_type = device:B,snapshot-file:s?,format:s?,
You changed from an underline to a hyphen as I asked, but the implementation
still expects an underline. I fixed that myself to avoid multiple submissions
because of a small thing (also fixed the command name in the subject).
The patch I merged follows for reference. Please, test your patches before
submitting next time.
Subject: [PATCH] QMP: add snapshot-blkdev-sync command
Add QMP bits for snapshot_blkdev command. This is the same as
snapshot_blkdev in the human monitor. The command is synchronous.
In the future async commands and or a break down of the functionality
into multiple commands might be added.
Also change the 'snapshot_file' argument to 'snapshot-file' in
the human monitor, so that it matches QMP.
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
Signed-off-by: Luiz Capitulino lcapitul...@gmail.com
---
blockdev.c |4 ++--
hmp-commands.hx |2 +-
qmp-commands.hx | 34 ++
3 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index 7d579d6..1a96d3c 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -572,7 +572,7 @@ void do_commit(Monitor *mon, const QDict *qdict)
int do_snapshot_blkdev(Monitor *mon, const QDict *qdict, QObject **ret_data)
{
const char *device = qdict_get_str(qdict, device);
-const char *filename = qdict_get_try_str(qdict, snapshot_file);
+const char *filename = qdict_get_try_str(qdict, snapshot-file);
const char *format = qdict_get_try_str(qdict, format);
BlockDriverState *bs;
BlockDriver *drv, *old_drv, *proto_drv;
@@ -581,7 +581,7 @@ int do_snapshot_blkdev(Monitor *mon, const QDict *qdict,
QObject **ret_data)
char old_filename[1024];
if (!filename) {
-qerror_report(QERR_MISSING_PARAMETER, snapshot_file);
+qerror_report(QERR_MISSING_PARAMETER, snapshot-file);
ret = -1;
goto out;
}
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 6ad8806..c857827 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -840,7 +840,7 @@ ETEXI
{
.name = snapshot_blkdev,
-.args_type = device:B,snapshot_file:s?,format:s?,
+.args_type = device:B,snapshot-file:s?,format:s?,
.params = device [new-image-file] [format],
.help = initiates a live snapshot\n\t\t\t
of device. If a new image file is specified,
the\n\t\t\t
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 92c5c3a..5d44edf 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -694,6 +694,40 @@ Example:
EQMP
{
+.name = blockdev-snapshot-sync,
+.args_type = device:B,snapshot-file:s?,format:s?,
+.params = device [new-image-file] [format],
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_snapshot_blkdev,
+},
+
+SQMP
+blockdev-snapshot-sync
+--
+
+Synchronous snapshot of a block device. snapshot-file specifies the
+target of the new image. If the file exists, or if it is a device, the
+snapshot will be created in the existing file/device. If does not
+exist, a new file will be created. format specifies the format of the
+snapshot image, default is qcow2.
+
+Arguments:
+
+- device: device name to snapshot (json-string)
+- snapshot-file: name of new image file (json-string)
+- format: format of new image (json-string, optional)
+
+Example:
+
+- { execute: blockdev-snapshot, arguments: { device: ide-hd0,
+snapshot-file:
+/some/place/my-image,
+format: qcow2 } }
+- { return: {} }
+
+EQMP
+
+{
.name = balloon,
.args_type = value:M,
.params = target,
--
1.7.6.134.gcf13f
Re: [Qemu-devel] [PATCH v3] QMP: add snapshot_blkdev command
On 07/11/11 22:24, Luiz Capitulino wrote:
On Mon, 11 Jul 2011 20:01:09 +0200
jes.soren...@redhat.com wrote:
From: Jes Sorensen jes.soren...@redhat.com
Add QMP bits for snapshot_blkdev command. This is the same as
snapshot_blkdev in the human monitor. The command is synchronous.
In the future async commands and or a break down of the functionality
into multiple commands might be added.
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
qmp-commands.hx | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 92c5c3a..2b9f6af 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -694,6 +694,41 @@ Example:
EQMP
{
+.name = blockdev-snapshot-sync,
+.args_type = device:B,snapshot-file:s?,format:s?,
You changed from an underline to a hyphen as I asked, but the implementation
still expects an underline. I fixed that myself to avoid multiple submissions
because of a small thing (also fixed the command name in the subject).
The patch I merged follows for reference. Please, test your patches before
submitting next time.
Sorry that is no go, you just broke the hmp implementation - you cannot
change the hmp behavior like that.
Jes
Re: [Qemu-devel] [PATCH v3] QMP: add snapshot_blkdev command
On Mon, 11 Jul 2011 22:28:57 +0200
Jes Sorensen jes.soren...@redhat.com wrote:
On 07/11/11 22:24, Luiz Capitulino wrote:
On Mon, 11 Jul 2011 20:01:09 +0200
jes.soren...@redhat.com wrote:
From: Jes Sorensen jes.soren...@redhat.com
Add QMP bits for snapshot_blkdev command. This is the same as
snapshot_blkdev in the human monitor. The command is synchronous.
In the future async commands and or a break down of the functionality
into multiple commands might be added.
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
qmp-commands.hx | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 92c5c3a..2b9f6af 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -694,6 +694,41 @@ Example:
EQMP
{
+.name = blockdev-snapshot-sync,
+.args_type = device:B,snapshot-file:s?,format:s?,
You changed from an underline to a hyphen as I asked, but the implementation
still expects an underline. I fixed that myself to avoid multiple
submissions
because of a small thing (also fixed the command name in the subject).
The patch I merged follows for reference. Please, test your patches before
submitting next time.
Sorry that is no go, you just broke the hmp implementation - you cannot
change the hmp behavior like that.
HMP uses positional arguments, so changing argument names makes no
difference. And, apart from some exceptions, it's not an stable interface,
anyway...
Re: [Qemu-devel] [PATCH v6 4/4] guest agent: add guest agent RPCs/commands
On Mon, 11 Jul 2011 15:11:26 -0500
Michael Roth mdr...@linux.vnet.ibm.com wrote:
On 07/08/2011 10:14 AM, Luiz Capitulino wrote:
On Tue, 5 Jul 2011 08:21:40 -0500
Michael Rothmdr...@linux.vnet.ibm.com wrote:
This adds the initial set of QMP/QAPI commands provided by the guest
agent:
guest-sync
guest-ping
guest-info
guest-shutdown
guest-file-open
guest-file-read
guest-file-write
guest-file-seek
guest-file-close
guest-fsfreeze-freeze
guest-fsfreeze-thaw
guest-fsfreeze-status
The input/output specification for these commands are documented in the
schema.
Example usage:
host:
qemu -device virtio-serial \
-chardev socket,path=/tmp/vs0.sock,server,nowait,id=qga0 \
-device virtserialport,chardev=qga0,name=qga0
...
echo {'execute':'guest-info'} | socat stdio \
unix-connect:/tmp/qga0.sock
guest:
qemu-ga -c virtio-serial -p /dev/virtio-ports/qga0 \
-p /var/run/qemu-guest-agent.pid -d
Signed-off-by: Michael Rothmdr...@linux.vnet.ibm.com
---
Makefile | 15 ++-
qemu-ga.c |4 +
qerror.h |3 +
qga/guest-agent-commands.c | 501
qga/guest-agent-core.h |2 +
5 files changed, 523 insertions(+), 2 deletions(-)
create mode 100644 qga/guest-agent-commands.c
diff --git a/Makefile b/Makefile
index b2e8593..7e4f722 100644
--- a/Makefile
+++ b/Makefile
@@ -175,15 +175,26 @@ $(qapi-dir)/test-qmp-commands.h:
$(qapi-dir)/test-qmp-marshal.c
$(qapi-dir)/test-qmp-marshal.c: $(SRC_PATH)/qapi-schema-test.json
$(SRC_PATH)/scripts/qapi-commands.py
$(call quiet-command,python $(SRC_PATH)/scripts/qapi-commands.py -o
$(qapi-dir) -p test- $, GEN $@)
+$(qapi-dir)/qga-qapi-types.c: $(qapi-dir)/qga-qapi-types.h
+$(qapi-dir)/qga-qapi-types.h: $(SRC_PATH)/qapi-schema-guest.json
$(SRC_PATH)/scripts/qapi-types.py
+ $(call quiet-command,python $(SRC_PATH)/scripts/qapi-types.py -o
$(qapi-dir) -p qga- $, GEN $@)
+$(qapi-dir)/qga-qapi-visit.c: $(qapi-dir)/qga-qapi-visit.h
+$(qapi-dir)/qga-qapi-visit.h: $(SRC_PATH)/qapi-schema-guest.json
$(SRC_PATH)/scripts/qapi-visit.py
+ $(call quiet-command,python $(SRC_PATH)/scripts/qapi-visit.py -o
$(qapi-dir) -p qga- $, GEN $@)
+$(qapi-dir)/qga-qmp-marshal.c: $(SRC_PATH)/qapi-schema-guest.json
$(SRC_PATH)/scripts/qapi-commands.py
+ $(call quiet-command,python $(SRC_PATH)/scripts/qapi-commands.py -o
$(qapi-dir) -p qga- $, GEN $@)
+
test-visitor.o: $(addprefix $(qapi-dir)/, test-qapi-types.c
test-qapi-types.h test-qapi-visit.c test-qapi-visit.h)
test-visitor: test-visitor.o qfloat.o qint.o qdict.o qstring.o qlist.o
qbool.o $(qapi-obj-y) error.o osdep.o qemu-malloc.o $(oslib-obj-y) qjson.o
json-streamer.o json-lexer.o json-parser.o qerror.o qemu-error.o
qemu-tool.o $(qapi-dir)/test-qapi-visit.o $(qapi-dir)/test-qapi-types.o
test-qmp-commands.o: $(addprefix $(qapi-dir)/, test-qapi-types.c
test-qapi-types.h test-qapi-visit.c test-qapi-visit.h test-qmp-marshal.c
test-qmp-commands.h)
test-qmp-commands: test-qmp-commands.o qfloat.o qint.o qdict.o qstring.o
qlist.o qbool.o $(qapi-obj-y) error.o osdep.o qemu-malloc.o $(oslib-obj-y)
qjson.o json-streamer.o json-lexer.o json-parser.o qerror.o qemu-error.o
qemu-tool.o $(qapi-dir)/test-qapi-visit.o $(qapi-dir)/test-qapi-types.o
$(qapi-dir)/test-qmp-marshal.o module.o
-QGALIB=qga/guest-agent-command-state.o
+QGALIB=qga/guest-agent-command-state.o qga/guest-agent-commands.o
+
+qemu-ga.o: $(qapi-dir)/qga-qapi-types.c $(qapi-dir)/qga-qapi-types.h
$(qapi-dir)/qga-qapi-visit.c $(qapi-dir)/qga-qmp-marshal.c
-qemu-ga$(EXESUF): qemu-ga.o $(QGALIB) qemu-tool.o qemu-error.o error.o
$(oslib-obj-y) $(trace-obj-y) $(block-obj-y) $(qobject-obj-y)
$(version-obj-y) $(qapi-obj-y) qemu-timer-common.o qemu-sockets.o module.o
qapi/qmp-dispatch.o qapi/qmp-registry.o
+qemu-ga$(EXESUF): qemu-ga.o $(QGALIB) qemu-tool.o qemu-error.o error.o
$(oslib-obj-y) $(trace-obj-y) $(block-obj-y) $(qobject-obj-y)
$(version-obj-y) $(qapi-obj-y) qemu-timer-common.o qemu-sockets.o module.o
qapi/qmp-dispatch.o qapi/qmp-registry.o $(qapi-dir)/qga-qapi-visit.o
$(qapi-dir)/qga-qmp-marshal.o
QEMULIBS=libhw32 libhw64 libuser libdis libdis-user
diff --git a/qemu-ga.c b/qemu-ga.c
index 649c16a..04ead22 100644
--- a/qemu-ga.c
+++ b/qemu-ga.c
@@ -637,6 +637,9 @@ int main(int argc, char **argv)
g_log_set_default_handler(ga_log, s);
g_log_set_fatal_mask(NULL, G_LOG_LEVEL_ERROR);
s-logging_enabled = true;
+s-command_state = ga_command_state_new();
+ga_command_state_init(s, s-command_state);
+ga_command_state_init_all(s-command_state);
ga_state = s;
module_call_init(MODULE_INIT_QAPI);
Re: [Qemu-devel] [RFC v3 31/56] ac97: convert to memory API
On Mon, 11 Jul 2011, Avi Kivity wrote:
On 07/11/2011 04:42 AM, Anthony Liguori wrote:
On 07/10/2011 03:33 PM, malc wrote:
On Sun, 10 Jul 2011, Avi Kivity wrote:
fixes BAR sizing as well.
I find this patch disgusting, the read and write handlers in particular.
Shouldn't it be possible to do something like:
typedef struct OldMemoryRegionOps {
MemoryRegionOps parent_ops;
CPUReadMemoryFunc *readfn[3];
CPUWriteMemoryFunc *writefn[3];
void *opaque;
} OldMemoryRegionOps;
That should allow old-style implementations to be converted without
introducing trampoline functions everywhere.
Here's a new version:
This one looks acceptable[1], original submission said:
fixes BAR sizing as well. what was wrong with it?
[..snip..]
P.S. Sans minor inconsistency with trailing commas.
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] Fixed bug [Bug 38672] - bugzilla.kernel.org
On 2011-07-08 22:26, Stefan BOSAK wrote: Hello. Bug is in (xen-mapcache.c): Reported-by: Steve stefan.bo...@gmail.com Signed-off-by: Steve stefan.bo...@gmail.com diff --git a/xen-mapcache.c b/xen-mapcache.c index 57fe24d..1c3b5bf 100644 --- a/xen-mapcache.c +++ b/xen-mapcache.c @@ -107,7 +107,7 @@ void qemu_map_cache_init(void) size = mapcache-nr_buckets * sizeof (MapCacheEntry); size = (size + XC_PAGE_SIZE - 1) ~(XC_PAGE_SIZE - 1); DPRINTF(qemu_map_cache_init, nr_buckets = %lx size %lu\n, mapcache-nr_buckets, size); -mapcache-entry = qemu_mallocz(size); +mapcache-entry = qemu_mallocz(size*sizeof(MapCacheEntry)); This is obviously (see a few lines above) already correct and can't be related to your problems - the Xen bits aren't even executed in KVM mode. The bug you stumbled over finally cost my nerves today as well. The regression comes from commit 38bee5dc94. I'll poke the author. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v2 4/5] exec.c: refactor cpu_physical_memory_map
On 2011-05-19 19:35, stefano.stabell...@eu.citrix.com wrote: From: Stefano Stabellini stefano.stabell...@eu.citrix.com Introduce qemu_ram_ptr_length that takes an address and a size as parameters rather than just an address. Refactor cpu_physical_memory_map so that we call qemu_ram_ptr_length only once rather than calling qemu_get_ram_ptr one time per page. This is not only more efficient but also tries to simplify the logic of the function. Currently we are relying on the fact that all the pages are mapped contiguously in qemu's address space: we have a check to make sure that the virtual address returned by qemu_get_ram_ptr from the second call on is consecutive. Now we are making this more explicit replacing all the calls to qemu_get_ram_ptr with a single call to qemu_ram_ptr_length passing a size argument. This breaks cpu_physical_memory_map for 4G addresses on PC. Effectively, it doesn't account for the PCI gap, ie. that the RAM block is actually mapped in two chunks into the guest physical memory. One outcome is that QEMU aborts when we try to process an address that is now outside RAM. Simple to reproduce with a virtio NIC and 5G guest memory, even without KVM. Please fix or revert. Thanks, Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v6 4/4] guest agent: add guest agent RPCs/commands
On 07/11/2011 04:12 PM, Luiz Capitulino wrote:
On Mon, 11 Jul 2011 15:11:26 -0500
Michael Rothmdr...@linux.vnet.ibm.com wrote:
On 07/08/2011 10:14 AM, Luiz Capitulino wrote:
On Tue, 5 Jul 2011 08:21:40 -0500
Michael Rothmdr...@linux.vnet.ibm.com wrote:
This adds the initial set of QMP/QAPI commands provided by the guest
agent:
guest-sync
guest-ping
guest-info
guest-shutdown
guest-file-open
guest-file-read
guest-file-write
guest-file-seek
guest-file-close
guest-fsfreeze-freeze
guest-fsfreeze-thaw
guest-fsfreeze-status
The input/output specification for these commands are documented in the
schema.
Example usage:
host:
qemu -device virtio-serial \
-chardev socket,path=/tmp/vs0.sock,server,nowait,id=qga0 \
-device virtserialport,chardev=qga0,name=qga0
...
echo {'execute':'guest-info'} | socat stdio \
unix-connect:/tmp/qga0.sock
guest:
qemu-ga -c virtio-serial -p /dev/virtio-ports/qga0 \
-p /var/run/qemu-guest-agent.pid -d
Signed-off-by: Michael Rothmdr...@linux.vnet.ibm.com
---
Makefile | 15 ++-
qemu-ga.c |4 +
qerror.h |3 +
qga/guest-agent-commands.c | 501
qga/guest-agent-core.h |2 +
5 files changed, 523 insertions(+), 2 deletions(-)
create mode 100644 qga/guest-agent-commands.c
diff --git a/Makefile b/Makefile
index b2e8593..7e4f722 100644
--- a/Makefile
+++ b/Makefile
@@ -175,15 +175,26 @@ $(qapi-dir)/test-qmp-commands.h:
$(qapi-dir)/test-qmp-marshal.c
$(qapi-dir)/test-qmp-marshal.c: $(SRC_PATH)/qapi-schema-test.json
$(SRC_PATH)/scripts/qapi-commands.py
$(call quiet-command,python $(SRC_PATH)/scripts/qapi-commands.py -o $(qapi-dir) -p
test- $, GEN $@)
+$(qapi-dir)/qga-qapi-types.c: $(qapi-dir)/qga-qapi-types.h
+$(qapi-dir)/qga-qapi-types.h: $(SRC_PATH)/qapi-schema-guest.json
$(SRC_PATH)/scripts/qapi-types.py
+ $(call quiet-command,python $(SRC_PATH)/scripts/qapi-types.py -o $(qapi-dir) -p
qga- $, GEN $@)
+$(qapi-dir)/qga-qapi-visit.c: $(qapi-dir)/qga-qapi-visit.h
+$(qapi-dir)/qga-qapi-visit.h: $(SRC_PATH)/qapi-schema-guest.json
$(SRC_PATH)/scripts/qapi-visit.py
+ $(call quiet-command,python $(SRC_PATH)/scripts/qapi-visit.py -o $(qapi-dir) -p
qga- $, GEN $@)
+$(qapi-dir)/qga-qmp-marshal.c: $(SRC_PATH)/qapi-schema-guest.json
$(SRC_PATH)/scripts/qapi-commands.py
+ $(call quiet-command,python $(SRC_PATH)/scripts/qapi-commands.py -o $(qapi-dir) -p
qga- $, GEN $@)
+
test-visitor.o: $(addprefix $(qapi-dir)/, test-qapi-types.c
test-qapi-types.h test-qapi-visit.c test-qapi-visit.h)
test-visitor: test-visitor.o qfloat.o qint.o qdict.o qstring.o qlist.o
qbool.o $(qapi-obj-y) error.o osdep.o qemu-malloc.o $(oslib-obj-y) qjson.o
json-streamer.o json-lexer.o json-parser.o qerror.o qemu-error.o qemu-tool.o
$(qapi-dir)/test-qapi-visit.o $(qapi-dir)/test-qapi-types.o
test-qmp-commands.o: $(addprefix $(qapi-dir)/, test-qapi-types.c
test-qapi-types.h test-qapi-visit.c test-qapi-visit.h test-qmp-marshal.c
test-qmp-commands.h)
test-qmp-commands: test-qmp-commands.o qfloat.o qint.o qdict.o qstring.o
qlist.o qbool.o $(qapi-obj-y) error.o osdep.o qemu-malloc.o $(oslib-obj-y)
qjson.o json-streamer.o json-lexer.o json-parser.o qerror.o qemu-error.o
qemu-tool.o $(qapi-dir)/test-qapi-visit.o $(qapi-dir)/test-qapi-types.o
$(qapi-dir)/test-qmp-marshal.o module.o
-QGALIB=qga/guest-agent-command-state.o
+QGALIB=qga/guest-agent-command-state.o qga/guest-agent-commands.o
+
+qemu-ga.o: $(qapi-dir)/qga-qapi-types.c $(qapi-dir)/qga-qapi-types.h
$(qapi-dir)/qga-qapi-visit.c $(qapi-dir)/qga-qmp-marshal.c
-qemu-ga$(EXESUF): qemu-ga.o $(QGALIB) qemu-tool.o qemu-error.o error.o
$(oslib-obj-y) $(trace-obj-y) $(block-obj-y) $(qobject-obj-y) $(version-obj-y)
$(qapi-obj-y) qemu-timer-common.o qemu-sockets.o module.o qapi/qmp-dispatch.o
qapi/qmp-registry.o
+qemu-ga$(EXESUF): qemu-ga.o $(QGALIB) qemu-tool.o qemu-error.o error.o
$(oslib-obj-y) $(trace-obj-y) $(block-obj-y) $(qobject-obj-y) $(version-obj-y)
$(qapi-obj-y) qemu-timer-common.o qemu-sockets.o module.o qapi/qmp-dispatch.o
qapi/qmp-registry.o $(qapi-dir)/qga-qapi-visit.o $(qapi-dir)/qga-qmp-marshal.o
QEMULIBS=libhw32 libhw64 libuser libdis libdis-user
diff --git a/qemu-ga.c b/qemu-ga.c
index 649c16a..04ead22 100644
--- a/qemu-ga.c
+++ b/qemu-ga.c
@@ -637,6 +637,9 @@ int main(int argc, char **argv)
g_log_set_default_handler(ga_log, s);
g_log_set_fatal_mask(NULL, G_LOG_LEVEL_ERROR);
s-logging_enabled = true;
+s-command_state = ga_command_state_new();
+ga_command_state_init(s, s-command_state);
+ga_command_state_init_all(s-command_state);
ga_state = s;
module_call_init(MODULE_INIT_QAPI);
@@ -645,6 +648,7 @@ int main(int argc, char **argv)
g_main_loop_run(ga_state-main_loop);
+
Re: [Qemu-devel] [SeaBIOS] SeaBIOS error with Juniper FreeBSD kernel
Are all versions based on FreeBSD 4.11? Are newer versions still affected? Newer versions should be based on 6.1 but there are a lot of changes. I haven't had a chance to test with something newer yet. -Brandon
Re: [Qemu-devel] [PATCH v5 05/18] qapi: add QMP input visitor
On 07/07/2011 09:32 AM, Luiz Capitulino wrote:
On Tue, 5 Jul 2011 08:02:32 -0500
Michael Rothmdr...@linux.vnet.ibm.com wrote:
A type of Visiter class that is used to walk a qobject's
structure and assign each entry to the corresponding native C type.
Command marshaling function will use this to pull out QMP command
parameters recieved over the wire and pass them as native arguments
to the corresponding C functions.
Signed-off-by: Michael Rothmdr...@linux.vnet.ibm.com
---
Makefile.objs|2 +-
qapi/qmp-input-visitor.c | 264 ++
qapi/qmp-input-visitor.h | 27 +
qerror.h |3 +
4 files changed, 295 insertions(+), 1 deletions(-)
create mode 100644 qapi/qmp-input-visitor.c
create mode 100644 qapi/qmp-input-visitor.h
diff --git a/Makefile.objs b/Makefile.objs
index 0077014..997ecef 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -375,7 +375,7 @@ libcacard-y = cac.o event.o vcard.o vreader.o
vcard_emul_nss.o vcard_emul_type.o
##
# qapi
-qapi-nested-y = qapi-visit-core.o
+qapi-nested-y = qapi-visit-core.o qmp-input-visitor.o
qapi-obj-y = $(addprefix qapi/, $(qapi-nested-y))
vl.o: QEMU_CFLAGS+=$(GPROF_CFLAGS)
diff --git a/qapi/qmp-input-visitor.c b/qapi/qmp-input-visitor.c
new file mode 100644
index 000..80912bb
--- /dev/null
+++ b/qapi/qmp-input-visitor.c
@@ -0,0 +1,264 @@
+/*
+ * Input Visitor
+ *
+ * Copyright IBM, Corp. 2011
+ *
+ * Authors:
+ * Anthony Liguorialigu...@us.ibm.com
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2.1 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ *
+ */
+
+#include qmp-input-visitor.h
+#include qemu-queue.h
+#include qemu-common.h
+#include qemu-objects.h
+#include qerror.h
+
+#define QIV_STACK_SIZE 1024
+
+typedef struct StackObject
+{
+const QObject *obj;
+const QListEntry *entry;
+} StackObject;
+
+struct QmpInputVisitor
+{
+Visitor visitor;
+const QObject *obj;
+StackObject stack[QIV_STACK_SIZE];
+int nb_stack;
+};
+
+static QmpInputVisitor *to_qiv(Visitor *v)
+{
+return container_of(v, QmpInputVisitor, visitor);
+}
+
+static const QObject *qmp_input_get_object(QmpInputVisitor *qiv, const char
*name)
+{
+const QObject *qobj;
+
+if (qiv-nb_stack == 0) {
+qobj = qiv-obj;
+} else {
+qobj = qiv-stack[qiv-nb_stack - 1].obj;
+}
+
+if (name qobject_type(qobj) == QTYPE_QDICT) {
+return qdict_get(qobject_to_qdict(qobj), name);
+} else if (qiv-nb_stack 0 qobject_type(qobj) == QTYPE_QLIST) {
+return qlist_entry_obj(qiv-stack[qiv-nb_stack - 1].entry);
+}
+
+return qobj;
+}
+
+static void qmp_input_push(QmpInputVisitor *qiv, const QObject *obj, Error
**errp)
+{
+qiv-stack[qiv-nb_stack].obj = obj;
+if (qobject_type(obj) == QTYPE_QLIST) {
+qiv-stack[qiv-nb_stack].entry = qlist_first(qobject_to_qlist(obj));
+}
+qiv-nb_stack++;
+
+if (qiv-nb_stack= QIV_STACK_SIZE) {
+error_set(errp, QERR_BUFFER_OVERRUN);
+return;
+}
+}
+
+static void qmp_input_pop(QmpInputVisitor *qiv, Error **errp)
+{
+qiv-nb_stack--;
+if (qiv-nb_stack 0) {
+error_set(errp, QERR_BUFFER_OVERRUN);
+return;
+}
+}
+
+static void qmp_input_start_struct(Visitor *v, void **obj, const char *kind,
const char *name, size_t size, Error **errp)
+{
+QmpInputVisitor *qiv = to_qiv(v);
+const QObject *qobj = qmp_input_get_object(qiv, name);
+
+if (!qobj || qobject_type(qobj) != QTYPE_QDICT) {
+error_set(errp, QERR_INVALID_PARAMETER_TYPE, name ? name : null,
QDict);
+return;
+}
+
+qmp_input_push(qiv, qobj, errp);
+if (error_is_set(errp)) {
+return;
+}
+
+if (obj) {
+*obj = qemu_mallocz(size);
+}
+}
+
+static void qmp_input_end_struct(Visitor *v, Error **errp)
+{
+QmpInputVisitor *qiv = to_qiv(v);
+
+qmp_input_pop(qiv, errp);
+}
+
+static void qmp_input_start_list(Visitor *v, const char *name, Error **errp)
+{
+QmpInputVisitor *qiv = to_qiv(v);
+const QObject *qobj = qmp_input_get_object(qiv, name);
+
+if (!qobj || qobject_type(qobj) != QTYPE_QLIST) {
+error_set(errp, QERR_INVALID_PARAMETER_TYPE, name ? name : null,
list);
+return;
+}
+
+qmp_input_push(qiv, qobj, errp);
+}
+
+static GenericList *qmp_input_next_list(Visitor *v, GenericList **list, Error
**errp)
+{
+QmpInputVisitor *qiv = to_qiv(v);
+GenericList *entry;
+StackObject *so =qiv-stack[qiv-nb_stack - 1];
+
+if (so-entry == NULL) {
+return NULL;
+}
+
+entry = qemu_mallocz(sizeof(*entry));
+if (*list) {
+so-entry = qlist_next(so-entry);
+if (so-entry == NULL) {
+qemu_free(entry);
+return NULL;
+}
+(*list)-next = entry;
+}
+*list = entry;
+
+
+return entry;
+}
+
+static
[Qemu-devel] buildbot failure in qemu on block_x86_64_debian_5_0
The Buildbot has detected a new failure on builder block_x86_64_debian_5_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/block_x86_64_debian_5_0/builds/31 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_block' triggered this build Build Source Stamp: [branch block] HEAD Blamelist: BUILD FAILED: failed git sincerely, -The Buildbot
[Qemu-devel] buildbot failure in qemu on block_i386_debian_5_0
The Buildbot has detected a new failure on builder block_i386_debian_5_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/block_i386_debian_5_0/builds/31 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_block' triggered this build Build Source Stamp: [branch block] HEAD Blamelist: BUILD FAILED: failed git sincerely, -The Buildbot
[Qemu-devel] Về: PCI with Xilinx virtex-ml507 board
On Jul 11, 2011 15:31, Edgar E. Iglesias edgar.igles...@gmail.com wrote: On Jul 11, 2011 5:31 AM, Lê Đức Tài letai_d...@yahoo.com.vn wrote: Hi, It seems that virtex board doesn't have a PCI bus emulation. I have tried to create one using ppc4xx_pci_init() function but it doesn't work. Could you help me some ideas to create PCI bus for virtex board? Or if you have already implemented PCI for virtex (I think that PCI is necessary to init Ethernet), could you send me the patch? Thank you very much, Tai Hi, The emulated board and fpga config doesnt have pci. It does have a xilinx ll-temac ethernet mac though. I have patches for that, its on my todo list to post them. Right now im on the road with little access to my stuff. It'll have to wait, sorry. If you dont need a particular mac, you could try to change the dtb and qemu to instantiate a xilinx ethlite mac which qemu upstream does emulate. I suggest looking at the microblaze boards as reference. Good luck, Edgar Thank you for your suggestion, Tai
[Qemu-devel] Need help: IO Functionality for Hardware
I am attempting to develop some code for a new board and am stuck trying to implement a working IO system. How can I stream input to my qemu-system-X executable and, for example, get something to be output from it, say, print to screen, without using fprintf? Thanks! Also, what does cpu_physical_memory_read and the write version do, and how are they ever called? -- Philip Z Loh, Intern at Aeste Works (M), Candidate for Bachelor of Science in Engineering: Computing.
[Qemu-devel] [Bug 808737] Re: No option to load additional binary files from command line in QEMU
I understand that we should not change -kernel option for backwards compatibility, that's why I suggest some new option for loading arbitrary binary file (not necessarily ELF file). This option would just mean: Just blindly load the given file to the given physical address. We can also pass this options multiple times in command line to load different files. I don't know if such an option would create problems in any other part of QEMU. Is it possible to have such an option in QEMU ? This problem has been bugging me since a year now so, it will be a great help if we can have it. Thanks, --Anup -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/808737 Title: No option to load additional binary files from command line in QEMU Status in QEMU: New Bug description: There is no command line option like -kerner, or -initrd to load an arbitrary binary file to a RAM location when launching QEMU. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/808737/+subscriptions
Re: [Qemu-devel] How to run realview-pbx-a9 image in qemu
David Gilbert wrote: On 11 July 2011 09:21, Xiao Jiang jgq...@gmail.com wrote: Hello, I downloaded latest qemu 0.14.1, it should support realview-pbx-a9 board now from below cmd. $ qemu-system-arm -M ?|grep Cortex-A9 realview-pbx-a9 ARM RealView Platform Baseboard Explore for Cortex-A9 Then I compiled a zImage from latest mainline with use realview-smp_defconfig as config file, but unfortunately qemu can't run with the image, I had tried the below instructions. 1. qemu-system-arm -M realview-pbx-a9 -kernel zImage -initrd initrd.img -nographic -append console=ttyAMA0 2. qemu-system-arm -M realview-pbx-a9 -m 1024M -kernel zImage -nographic -append root=/dev/nfs nfsroot=128.225.160.22:/home/work/rootfs rw console=ttyAMA0 rdinit=/sbin/init -net nic -net tap,ifname=tap0,script=no Both instructions can't work, console is hang and no informations is appeared. so I am wondering if there are something wrong about the kernel, am I choose the wrong config file for realview-pbx-a9 board? Or the native mainline kernel can't boot on qemu? Any suggestions? Thanks a lot! The command I use is: sudo ./arm-softmmu/qemu-system-arm -M realview-pbx-a9 -m 1024 -kernel thekernel -serial telnet::,server -append console=earlycon console=ttyS0 console=ttyAMA0 earlyprintk root=/dev/nfs nfsroot=10.1.1.1:/armroot rw ip=10.1.1.2:10.1.1.1:10.1.1.1:255.255.255.0:armqemu nfsrootdebug -net nic -net tap,ifname=tap0,script=no,downscript=no and then telnet to port to get the console. (I'm using the linaro qemu tree). Hi Dave, It looks like I am not in luck, qemu still can't run successfully. I recompiled the qemu from linaro qemu tree and executed below instructions in order. 1. open window A, run below cmd. xjiang@xjiang-desktop:~/work/qemu$ sudo qemu-system-arm -M realview-pbx-a9 -m 1024 -kernel zImage-cortex-a9 -serial telnet::,server -append console=earlycon console=ttyS0 console=ttyAMA0 earlyprintk root=/dev/nfs nfsroot=10.1.6.6:/home/gjiang/work/ti_sitara_am35xx-standard-glibc_std ip=10.1.6.8:10.1.6.6:10.1.6.1:255.255.255.0 -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=no,downscript=no QEMU waiting for connection on: telnet:0.0.0.0:,server 2. open another window B, telnet to port . xjiang@xjiang-desktop$ telnet localhost Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host. 3, Then in window A, VNC server running on `127.0.0.1:5901' is appeared, so I open terminal service client, set the computer name to 127.0.0.1:5901 and selected vnc protocol. But after I clicked connect I can't see any infos, and the window named as TightVNC: QEMU is totally black. Are there something wrong in above instructions? or there are other necessary cmds which I have missed? Thanks in advance! Regards, Xiao Dave
Re: [Qemu-devel] How to run realview-pbx-a9 image in qemu
Xiao Jiang wrote: David Gilbert wrote: On 11 July 2011 09:21, Xiao Jiang jgq...@gmail.com wrote: Hello, I downloaded latest qemu 0.14.1, it should support realview-pbx-a9 board now from below cmd. $ qemu-system-arm -M ?|grep Cortex-A9 realview-pbx-a9 ARM RealView Platform Baseboard Explore for Cortex-A9 Then I compiled a zImage from latest mainline with use realview-smp_defconfig as config file, but unfortunately qemu can't run with the image, I had tried the below instructions. 1. qemu-system-arm -M realview-pbx-a9 -kernel zImage -initrd initrd.img -nographic -append console=ttyAMA0 2. qemu-system-arm -M realview-pbx-a9 -m 1024M -kernel zImage -nographic -append root=/dev/nfs nfsroot=128.225.160.22:/home/work/rootfs rw console=ttyAMA0 rdinit=/sbin/init -net nic -net tap,ifname=tap0,script=no Both instructions can't work, console is hang and no informations is appeared. so I am wondering if there are something wrong about the kernel, am I choose the wrong config file for realview-pbx-a9 board? Or the native mainline kernel can't boot on qemu? Any suggestions? Thanks a lot! The command I use is: sudo ./arm-softmmu/qemu-system-arm -M realview-pbx-a9 -m 1024 -kernel thekernel -serial telnet::,server -append console=earlycon console=ttyS0 console=ttyAMA0 earlyprintk root=/dev/nfs nfsroot=10.1.1.1:/armroot rw ip=10.1.1.2:10.1.1.1:10.1.1.1:255.255.255.0:armqemu nfsrootdebug -net nic -net tap,ifname=tap0,script=no,downscript=no and then telnet to port to get the console. (I'm using the linaro qemu tree). Hi Dave, It looks like I am not in luck, qemu still can't run successfully. I recompiled the qemu from linaro qemu tree and executed below instructions in order. 1. open window A, run below cmd. xjiang@xjiang-desktop:~/work/qemu$ sudo qemu-system-arm -M realview-pbx-a9 -m 1024 -kernel zImage-cortex-a9 -serial telnet::,server -append console=earlycon console=ttyS0 console=ttyAMA0 earlyprintk root=/dev/nfs nfsroot=10.1.6.6:/home/gjiang/work/ti_sitara_am35xx-standard-glibc_std ip=10.1.6.8:10.1.6.6:10.1.6.1:255.255.255.0 -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=no,downscript=no QEMU waiting for connection on: telnet:0.0.0.0:,server 2. open another window B, telnet to port . xjiang@xjiang-desktop$ telnet localhost Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host. 3, Then in window A, VNC server running on `127.0.0.1:5901' is appeared, so I open terminal service client, set the computer name to 127.0.0.1:5901 and selected vnc protocol. But after I clicked connect I can't see any infos, and the window named as TightVNC: QEMU is totally black. Fatal infos appeared in window A after some time, pls see belows. xjiang@xjiang-desktop:~/work/qemu$ sudo qemu-system-arm -M realview-pbx-a9 -m 1024 -kernel zImage-cortex-a9 -serial telnet::,server -append console=earlycon console=ttyS0 console=ttyAMA0 earlyprintk root=/dev/nfs nfsroot=10.1.6.6:/home/gjiang/work/ti_sitara_am35xx-standard-glibc_std ip=10.1.6.8:10.1.6.6:10.1.6.1:255.255.255.0 -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=no,downscript=no QEMU waiting for connection on: telnet:0.0.0.0:,server VNC server running on `127.0.0.1:5901' qemu: fatal: Trying to execute code outside RAM or ROM at 0x1000 R00=c03442e4 R01=0124 R02= R03=c02ced38 R04= R05=00208f4c R06=0020799c R07=0001 R08=0009 R09=00209a74 R10=27d312c8 R11=00208a20 R12=0001b80e R13=002088b0 R14=00101a08 R15=1000 PSR=21d3 --C- A svc32 Thanks, Xiao Are there something wrong in above instructions? or there are other necessary cmds which I have missed? Thanks in advance! Regards, Xiao Dave
