Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On 03/23/2010 09:24 PM, Anthony Liguori wrote: We also provide an API for guest creation (the qemu command line). As an aside, I'd like to see all command line options have qmp equivalents (most of them can be implemented with a 'set' command that writes qdev values). This allows a uniform way to control a guest, whether at startup or runtime. You start with a case, cold-plug a motherboard, cpus, memory, disk controllers, and power it on. I would also like a way to read the entire qdev tree from qmp. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On 03/23/2010 08:00 PM, Avi Kivity wrote: On 03/23/2010 06:06 PM, Anthony Liguori wrote: I thought the monitor protocol *was* our API. If not, why not? It is. But our API is missing key components like guest enumeration. So the fundamental topic here is, do we introduce these missing components to allow people to build directly to our interface or do we make use of the functionality that libvirt already provides if they can plumb our API directly to users. Guest enumeration is another API. Over the kvm call I suggested a qemu concentrator that would keep track of all running qemus, and would hand out monitor connections to users. It can do the enumeration (likely using qmp). Libvirt could talk to that, like it does with other hypervisors. To elaborate qemud - daemonaizes itself - listens on /var/lib/qemud/guests for incoming guest connections - listens on /var/lib/qemud/clients for incoming client connections - filters access according to uid (SCM_CREDENTIALS) - can pass a new monitor to client (SCM_RIGHTS) - supports 'list' command to query running guests - async messages on guest startup/exit qemu - with -qemud option, connects to qemud (or maybe automatically?) qemudc - command-line client, can access qemu human monitor -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
Re: [Qemu-devel] Supporting hypervisor specific APIs in libvirt
On 03/23/2010 09:31 PM, Anthony Liguori wrote: One problem is that this is libvirt version specific. For example, libvirt x doesn't support spice so we control that thorough qmp. But libvirt x+1 does support spice and now it gets confused about all the spice messages. That's only a problem if we only support a single QMP session. This is exactly why we need to support multiple QMP sessions (and do). It's unrelated to the number of sessions. libvirt expects state that it manages in qemu not to change randomly. Users know that, so they will only manage non-libvirt state in their private session. But a new version of libvirt may expand its scope and start managing this area, leading to conflicts. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/23/2010 08:23 PM, Daniel P. Berrange wrote: On Tue, Mar 23, 2010 at 08:00:21PM +0200, Avi Kivity wrote: On 03/23/2010 06:06 PM, Anthony Liguori wrote: I thought the monitor protocol *was* our API. If not, why not? It is. But our API is missing key components like guest enumeration. So the fundamental topic here is, do we introduce these missing components to allow people to build directly to our interface or do we make use of the functionality that libvirt already provides if they can plumb our API directly to users. Guest enumeration is another API. Over the kvm call I suggested a qemu concentrator that would keep track of all running qemus, and would hand out monitor connections to users. It can do the enumeration (likely using qmp). Libvirt could talk to that, like it does with other hypervisors. The libvirt QEMU driver started out as a fairly simple "concentrator" not doing much beyond spawning QEMU with argv& issuing monitor commands. The host concentrator inevitably needs to be involved in the OS level integration with features such as cgroups, selinux/apparmounr, host NIC management, storage, iptables, etc. If you look at the daemons for Xen, VirtualBox, VMWare, that other libvirt drivers talk to, they all do far more than just enumeration of VMs. A QEMU concentrator may start out simple, but it will end up growing over time to re-implememt much, if not all, the stuff that libvirt already provides for QEMU in terms of host level APIs. The idea is not to replace libvirt, but provide something that sits underneath. It wouldn't do any non-qemu host-level APIs. If the core problem here is to provide app developers access to the full range of QEMU functionality, the re-implementing the entire of the libvirt QEMU driver is rather over the top way to achieve that. It's trivial to expose all qemu functionality by exposing a qmp connection. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
[Qemu-devel] Regarding tcg_gen_helper
Hello,
My name is Aravind. I am working on a project which involves inserting code
to call one of my functions.
This is what it looks like:
//The function to be called.
void log_entry(int reg, int data)
{
printf("REG access\n");
printf("Data got REG = %d and data = %d\n", reg, data);
fprintf(logfileptr, "Register = %d, Data = %d\n", reg, data);
}
static inline void gen_reg_log(int reg, int data)
{
//This is effectively calling tcg_gen_helper64 without the sizemask
TCGv_ptr fn;
TCGArg args[2];
fn = tcg_const_ptr((tcg_target_long)log_entry);
args[0] = GET_TCGV_I64(reg);
args[1] = GET_TCGV_I64(data);
tcg_gen_callN(&tcg_ctx, fn, 0, 0, 0, 2, args);
tcg_temp_free_ptr(fn);
}
When I run this, I get a segfault. I do not know where to proceed. Any
suggestions will be appreciated.
Thanks,
Aravind.
[Qemu-devel] Exposing monitor on socket interface?
Hi, Is it possible to use -monitor option to expose the monitor on socket interface, such as TCP or Unix domain port, so I can access the monitor using non-stdio way? Thanks a lot, Jun
[Qemu-devel] Windows XP and 2003 fails to install
Windows XP and 2003 are not installing on current kvm via libvirt, due to an issue with the drive geometry presented via the BIOS. They do not reboot, after the first portion of the install. libvirt version 0.7.6 is utilizing the -drive ... / -device ... command line arguments to qemu-kvm, which are not correctly interacting with the bios causing incorrect geometry to be provided in the bios calls. If you use the -hda ... command line parameter to specify the disk (or the implicit version), then Windows will install correctly. I was able to change the code to artificially indicate that the bios should provide a translated geometry (as it does for -file), which resulted in the correct geometry being written to the master boot record (or at least the same as I get with old style way of providing a file to -hda. So far in debugging this, I've been able to determine that there is a CMOS byte which indicates to the BIOS what IDE drives should use translation. This gets handled correctly for the old way of specifying drives, but the same isn't done in the qdev storage device code. Any tips on how this should be resolved? Bruce
[Qemu-devel] Re: hi, may I ask some help on the paravirtualization of KVM?
On (Wed) Mar 24 2010 [11:35:09], Liang YANG wrote: > > Last, start the image Guest use qemu-system-x86_64 -net nic, > model=virtio. This time I can see virtio_net module in GuestOS, but it > doesn't work. The qemu didn't emulate the virtio net device. So I > update the code located in pc_init1(), where the net model is set. > After this time update, I can start the kvm-paravirtualization > successfully. So this is a bug; can you please post the patch you made? I don't think anyone else has complained of this so must be specific to your setup. Amit -- http://log.amitshah.net/
Re: [Qemu-devel] [PATCH -V2 00/22] virtio-9p: paravirtual file system passthrough
On Tue, 23 Mar 2010 20:17:33 -0300, Luiz Capitulino wrote: > On Tue, 16 Mar 2010 14:44:58 +0530 > "Aneesh Kumar K.V" wrote: > > > Hi, > > > > > > This patch series adds a paravirtual file system passthrough mechanism to > > QEMU > > based on the 9P protocol. With the current implementation, all I/O is > > implemented > > in the VCPU thread. We've modified the protocol handlers so that we can > > support > > dispatch I/O in a thread pool. The actual thread pool implementation will > > be posted later > > > > This patch set should work with any recent Linux kernel as virtio-9p has > > been > > supported for a few kernel releases now. Export dir is specified using the > > below > > Qemu option. > > > > -device virtio-9p-pci,share_path=/mnt/,mount_tag=v_mnt > > > > mount_tag is used to identify the mount point in the kernel. This will be > > available in Linux > > kernel via /sys/devices/virtio-pci/virtio1/mount_tag file. > > I tried this very '-device' line and I can see that the guest has loaded > the virtio modules, but there isn't anything in the virtio0 directory other > than standard sysfs files. > > Is there a way to debug this? > which version of the kernel ? The latest linus tree have all the needed changes. You should have /sys/bus/virtio/drivers/9pnet_virtio/ if you have CONFIG_NET_9P_VIRTIO enabled. You can then find mount tag at virtio/mount_tag > Something possibly related is that, I had to rewind the tree by some commits > because this series doesn't apply against current HEAD. The patches are against 0aef4261ac0ec9089ade0e3a92f986cb4ba7317e of the master branch -aneesh
[Qemu-devel] Re: hi, may I ask some help on the paravirtualization of KVM?
Maybe I solove the problem. I use the qemu-img make a new GustOS img. And install the debian5 on the image file with option -net nic, model=virtio. ./x86_64-softmmu/qemu-system-x86_64 -hda debian.img -cdrom debian.iso -net nic, model=virtio Then I update the kernel image file with virtio, virtio_pci, virtio_ring, virtio_blk, virtio_net modules added to file /etc/initram-tools/modules. Last, start the image Guest use qemu-system-x86_64 -net nic, model=virtio. This time I can see virtio_net module in GuestOS, but it doesn't work. The qemu didn't emulate the virtio net device. So I update the code located in pc_init1(), where the net model is set. After this time update, I can start the kvm-paravirtualization successfully. Thanks for your help. On Tue, Mar 23, 2010 at 10:09 PM, Liang YANG wrote: > I use the qemu-kvm-0.12-3 version source file. Just follow the typical > three steps: ./configure && make && make install. > > After I configure, following is output: > > Install prefix /usr/local > BIOS directory /usr/local/share/qemu > binary directory /usr/local/bin > Manual directory /usr/local/share/man > ELF interp prefix /usr/gnemul/qemu-%M > Source path /root/svt/qemu-kvm-0.12.3 > C compiler gcc > Host C compiler gcc > CFLAGS -O2 -g > QEMU_CFLAGS -m32 -Wold-style-definition -Wold-style-declaration > -I. -I$(SRC_PATH) -U_FORTIFY_SOURCE -D_GNU_SOURCE > -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes > -Wredundant-decls -Wall -Wundef -Wendif-labels -Wwrite-strings > -Wmissing-prototypes -fno-strict-aliasing > LDFLAGS -Wl,--warn-common -m32 -g > make make > install install > host CPU i386 > host big endian no > target list x86_64-softmmu > tcg debug enabled no > gprof enabled no > sparse enabled no > strip binaries yes > profiler no > static build no > -Werror enabled no > SDL support yes > curses support yes > curl support yes > check support no > mingw32 support no > Audio drivers oss > Extra audio cards ac97 es1370 sb16 > Block whitelist > Mixer emulation no > VNC TLS support yes > VNC SASL support yes > xen support no > CPU emulation yes > brlapi support no > bluez support no > Documentation no > NPTL support yes > GUEST_BASE yes > PIE user targets no > vde support no > IO thread no > Linux AIO support no > Install blobs yes > KVM support yes > KVM PIT support yes > KVM device assig. yes > KVM trace support no > fdt support no > preadv support no > fdatasync yes > uuid support yes > > All compile procedure seems normal. No warning exists. And I use this > command to start the GuestOS: > ./x86_64-softmmu/qemu-system-x86_64 -m 1024 /root/redhat.img -net > nic, model=virtio -net tap, script=/etc/qemu-ifup > > The qemu-ifup script is : > #!/bin/sh > #sample /etc/qemu-ifup to have bridged networking between qemu > instances and your real net > # You need "youruser ALL=(root) NOPASSWD: /etc/qemu-ifup" in /etc/sudoers > # You also need enough rights on /dev/tun > if [ $UID -ne 0 ] > then > sudo $0 $1 > exit > fi > /sbin/ifconfig $1 promisc 0.0.0.0 > if ! /sbin/ifconfig br0 > then > /usr/sbin/brctl addbr br0 > /usr/sbin/brctl addif br0 eth0 > /sbin/ifconfig br0 up > addr=`/sbin/ip addr | grep eth0 | grep inet | sed -e 's/eth0/dev > br0/' -e s/inet//` > /sbin/ip addr add $addr > fi > /usr/sbin/brctl addif br0 $1 > /usr/sbin/brctl stp br0 off > /sbin/ip route | grep eth0 | while read route > do > newroute=`echo $route | sed s/eth0/br0/ ` > /sbin/ip route del $route > /sbin/ip route add $newroute > done > > > > On Tue, Mar 23, 2010 at 9:59 PM, Amit Shah wrote: >> Hello, >> >> [any reason you dropped the CC list? CC'ing qemu-devel, where this is >> relevant.] >> >> On (Tue) Mar 23 2010 [21:46:28], Liang YANG wrote: >>> I check the 'lspci -v' result, only find RTL-8139 realtek ethernet. I >>> think the option model=virtio does't make effect. >> >> Then something is wrong. I get a virtio ethernet device using >> model=virtio. >> >> Which qemu version are you using? >> >>> Simultaneously, I have the a look at the code. The function pc_init1() >>> seem not change the network model as the option assigned. >>> >>> Do you ever meet this case? >> >> I've not seen this. >> >>> On Tue, Mar 23, 2010 at 9:08 PM, Amit Shah wrote: >>> > On (Sun) Mar 21 2010 [20:18:53], Liang YANG wrote: >>> >> I want to set up the virtio-net for the GuestOS on KVM. Following is my >>> >> steps: >>> >> >>> >> 1.Compile the kvm-88 and make, make install. >>> >> 2.Compile the GuestOS(redhat) with kernel version 2.6.27.45(with >>> >> virtio support). The required option are all selected. >>> >> o CONFIG_VIRTIO_PCI=y (Virtualization -> PCI driver for >>> >> virtio devices) >>> >> o CONFIG_VIRTIO_BALLOON=y (Virtualization -> Virtio balloon >>> >> driver) >>> >>
[Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Juan Quintela writes: > > - networking: man, setting networking is a mess, libvirt just does it > for you. Agreed it's messy, but isn't this something that the standard qemu command line tool could potentially do better by itself? I don't see why you need a wrapper for that. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/23/2010 01:23 PM, Daniel P. Berrange wrote: On Tue, Mar 23, 2010 at 08:00:21PM +0200, Avi Kivity wrote: On 03/23/2010 06:06 PM, Anthony Liguori wrote: I thought the monitor protocol *was* our API. If not, why not? It is. But our API is missing key components like guest enumeration. So the fundamental topic here is, do we introduce these missing components to allow people to build directly to our interface or do we make use of the functionality that libvirt already provides if they can plumb our API directly to users. Guest enumeration is another API. Over the kvm call I suggested a qemu concentrator that would keep track of all running qemus, and would hand out monitor connections to users. It can do the enumeration (likely using qmp). Libvirt could talk to that, like it does with other hypervisors. The libvirt QEMU driver started out as a fairly simple "concentrator" not doing much beyond spawning QEMU with argv& issuing monitor commands. The host concentrator inevitably needs to be involved in the OS level integration with features such as cgroups, selinux/apparmounr, host NIC management, storage, iptables, etc. If you look at the daemons for Xen, VirtualBox, VMWare, that other libvirt drivers talk to, they all do far more than just enumeration of VMs. But with Xen, VirtualBox, and VMware, if you create a VM through the native interfaces, you'll see that virtual machine with libvirt. virt-top will show meaningful results for those VMs and almost all of libvirt's functionality will work as expected. Likewise, if you create a virtual machine with libvirt, when you do an xm list, run the VirtualBox GUI, or use VirtualCenter, you see that guest and you can interact with it through those interfaces. What that means is that if you write a libvirt application and need to use a feature that libvirt doesn't support for xen, you can also fall back to the Xend API. That's currently missing with qemu. A QEMU concentrator may start out simple, but it will end up growing over time to re-implememt much, if not all, the stuff that libvirt already provides for QEMU in terms of host level APIs. If the core problem here is to provide app developers access to the full range of QEMU functionality, the re-implementing the entire of the libvirt QEMU driver is rather over the top way to achieve that. The goal is not to replicate libvirt but to let a more complete, qemu specific API co-exist with libvirt just as is implemented for almost all of the other hypervisors libvirt supports. Regards, Anthony Liguori Regards, Daniel
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On 03/23/2010 06:25 PM, Jamie Lokier wrote: Alexander Graf wrote: I don't see why we shouldn't be able to automatically generate libqemu.so. We have the *.hx files that describe the syntax of parameters plus list all available options / commands. I'm not sure how exactly QMP works, but having a generic QMP command to list all available options would be handy too. By then we could automate most of the library, making the glueing really easy. If libvirt doesn't properly link against libqemu anymore we also know why: The ABI changed. I'm thinking most potential uses of the binary API, other than C programmers, would be happier with a D-Bus version generated from those same *.hx files. Because then it's easy to call the API from Python, Perl, even shell, etc. Whereas libqemu.so would be relatively difficult to use from those languages. My thinking with respect to libqemu.so is that it should be mostly autogenerated. QMP supports introspection, we should be able to generate an idl description of QMP via introspection and then build all of the function stubs from that idl. Then there is no opportunity for libqemu to be out of date. All we really need to write for libqemu is some core bits to deal with transport specific issues. (Aside: I don't particularly like D-Bus. But it does seem to work for this sort of thing.) I don't think d-bus is a good fit as a core qemu service. It's not commonly used on other platform and it introduces quite a bit of overhead for non-Unix platforms. But that certainly doesn't mean that a d-bus service implemented on top of libqemu (even autogenerated from our IDL) would be a bad project. Regards, Anthony Liguori -- Jamie
Re: [Qemu-devel] Re: Completing big real mode emulation
Avi Kivity wrote: > >Either way - then we should make the goal of the project to support those > >old boot loaders. IMHO it should contain visibility. Doing theoretical > >stuff is just less fun for all parties. Or does that stuff work already? > > Mostly those old guests aged beyond usefulness. They are still broken, > but nobody installs new images. Old images installed via workarounds work. Hey :) I still install old OSes occasionally, so that I can build and test code that will run on other people's still-running old machines. -- Jamie
Re: [Qemu-devel] Execute a char buffer without loading ELF
> I am involved in a project that we use Qemu user mode for i386 > (./i386-linux-user/qemu-i386). I want to modify the source code > in such a way to make qemu execute a buffer of bytes (given from the comman > line for example) rather than loading > an ELF file and executing. I started looking at linux-user/linuxload.c > loader_exec() function and linux-user/elfload.c load_elf_binary() > function. Is there a way to bypass the loading of an ELF file and load a > single buffer of bytes (that is i386 code) into memory > and make Qemu start execution on it? Short answer is no. Long answer is: - Creating an ELF image from a blob of data if fairly trivial, so you don't really need this functionality. - You're using linux usermode emulation. Linux doesn't load and execute random data. Neither do we. - Loading a blob of code at an arbitrary location probably won't do what you want anyway. Paul
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
Alexander Graf wrote: > I don't see why we shouldn't be able to automatically generate > libqemu.so. We have the *.hx files that describe the syntax of > parameters plus list all available options / commands. I'm not sure > how exactly QMP works, but having a generic QMP command to list all > available options would be handy too. > > By then we could automate most of the library, making the glueing > really easy. If libvirt doesn't properly link against libqemu anymore > we also know why: The ABI changed. I'm thinking most potential uses of the binary API, other than C programmers, would be happier with a D-Bus version generated from those same *.hx files. Because then it's easy to call the API from Python, Perl, even shell, etc. Whereas libqemu.so would be relatively difficult to use from those languages. (Aside: I don't particularly like D-Bus. But it does seem to work for this sort of thing.) -- Jamie
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
Anthony Liguori wrote: > On 03/23/2010 10:57 AM, Paul Brook wrote: > >I thought the monitor protocol *was* our API. If not, why not? > > It is. But our API is missing key components like guest enumeration. Is that simply enumerating running qemu instances, and asking each one about things like it's name, VNC port, etc.? Having each qemu publish itself through D-Bus or Avahi (to find the list of running instances), and every info query go through the monitor, would seem a clean solution to that. Are there any other missing key components? -- Jamie
Re: [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Juan Quintela wrote: > - monitor: I need a way to get to the monitor when going through > libvirt, in the past you couldn't allow this, but now it looks > possible. Now you can just start another monitor connection to qemu :-) Previously I've used a multiplexing script which accepts multiple monitor connections, and passes the commands to the real connection. It's not ideal because a slow command blocks any others, but it basically works. > - changing the emulator: It is normal for me to be using several qemu > binaries for testing, changing it with libvirt is just a mess. Same here, except not just for testing: I need to use different qemu binaries for production use, because newer ones don't work with some VM images that work on older ones. > - virt-viewer: I want to be able to switch consoles, period. A decent VNC client gets close to this. If the qemus advertised themselves, some VNC clients would show a list of them automatically. As it is, I use Gnome's VNC client with a bookmark for each VM, which works quite well. It even has tabs :-) > - networking: man, setting networking is a mess, libvirt just does it > for you. networking is often a mess, and what libvirt does isn't always what you want, even if it often is. I need the option to set up networking separately and have libvirt use what it's given, otherwise I cannot use it. -- Jamie
Re: [Qemu-devel] [PATCH -V2 00/22] virtio-9p: paravirtual file system passthrough
On Tue, 16 Mar 2010 14:44:58 +0530 "Aneesh Kumar K.V" wrote: > Hi, > > > This patch series adds a paravirtual file system passthrough mechanism to QEMU > based on the 9P protocol. With the current implementation, all I/O is > implemented > in the VCPU thread. We've modified the protocol handlers so that we can > support > dispatch I/O in a thread pool. The actual thread pool implementation will be > posted later > > This patch set should work with any recent Linux kernel as virtio-9p has been > supported for a few kernel releases now. Export dir is specified using the > below > Qemu option. > > -device virtio-9p-pci,share_path=/mnt/,mount_tag=v_mnt > > mount_tag is used to identify the mount point in the kernel. This will be > available in Linux > kernel via /sys/devices/virtio-pci/virtio1/mount_tag file. I tried this very '-device' line and I can see that the guest has loaded the virtio modules, but there isn't anything in the virtio0 directory other than standard sysfs files. Is there a way to debug this? Something possibly related is that, I had to rewind the tree by some commits because this series doesn't apply against current HEAD. > > Changes from V1: > a) fsstress test suite runs successfully with the patches. That should > indicate patches are stable > enough to be merged. > b) Added proper error handling to all posix_* calls. > c) Fixed code to follow Qemu coding style. > d) Other bug fixes most of which are folded back into the original patches > e) rebased to qemu master 0aef4261ac0ec9089ade0e3a92f986cb4ba7317e > > > -aneesh > > >
Re: [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Gerd Hoffmann wrote: > >- networking: man, setting networking is a mess, libvirt just does it > > for you. > > +1 > > Even when not using libvirt for a reason or another I usually hook my > virtual machines into virbr0 (libvirt default network). I had the opposite problem. Needed to use multiple bridges and have some VMs behind NAT without a bridge (private IPs), and some using separately firewalled bridges (needed to behave like real attached hardware with their original MACs, but be firewalled). I couldn't see how to do it easily with libvirt, so used qemu directly. -- Jamie
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
Anthony Liguori wrote: > (like mDNS or SLP). The later mechanism scales better and tends to > be more robust. (Aside: mDNS is blocked on some larger networks because it creates too much load. On those networks, an aggregator is essential - or a protocol which scales better (less broadcasting)). Doesn't libvirt use mDNS already to discover multiple hosts on a network, for remote access? If so, why can't exactly the same protocol be used to enumerate multiple VMs on each host? If not, why not? -- Jamie
[Qemu-devel] [PATCH 0/2] tcg-hppa finish, v3
Changes from v2 to v3: * millicode division routines removed in favour of generic code. r~ Richard Henderson (2): tcg-hppa: Compute is_write in cpu_signal_handler. tcg-hppa: Finish the port. configure |5 +- cpu-exec.c| 38 +- tcg/hppa/tcg-target.c | 1758 ++--- tcg/hppa/tcg-target.h | 142 + 4 files changed, 1289 insertions(+), 654 deletions(-)
[Qemu-devel] [PATCH 1/2] tcg-hppa: Compute is_write in cpu_signal_handler.
---
cpu-exec.c | 38 +++---
1 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/cpu-exec.c b/cpu-exec.c
index bcfcda2..14204f4 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -1193,15 +1193,39 @@ int cpu_signal_handler(int host_signum, void *pinfo,
{
struct siginfo *info = pinfo;
struct ucontext *uc = puc;
-unsigned long pc;
-int is_write;
+unsigned long pc = uc->uc_mcontext.sc_iaoq[0];
+uint32_t insn = *(uint32_t *)pc;
+int is_write = 0;
+
+/* XXX: need kernel patch to get write flag faster. */
+switch (insn >> 26) {
+case 0x1a: /* STW */
+case 0x19: /* STH */
+case 0x18: /* STB */
+case 0x1b: /* STWM */
+is_write = 1;
+break;
+
+case 0x09: /* CSTWX, FSTWX, FSTWS */
+case 0x0b: /* CSTDX, FSTDX, FSTDS */
+/* Distinguish from coprocessor load ... */
+is_write = (insn >> 9) & 1;
+break;
+
+case 0x03:
+switch ((insn >> 6) & 15) {
+case 0xa: /* STWS */
+case 0x9: /* STHS */
+case 0x8: /* STBS */
+case 0xe: /* STWAS */
+case 0xc: /* STBYS */
+is_write = 1;
+}
+break;
+}
-pc = uc->uc_mcontext.sc_iaoq[0];
-/* FIXME: compute is_write */
-is_write = 0;
return handle_cpu_signal(pc, (unsigned long)info->si_addr,
- is_write,
- &uc->uc_sigmask, puc);
+ is_write, &uc->uc_sigmask, puc);
}
#else
--
1.6.6.1
[Qemu-devel] Re: [PATCH v2 0/2] monitor: convert do_device_del() to QObject, QError
On Mon, 22 Mar 2010 11:38:12 +0100 Markus Armbruster wrote: > v2: Supply a missing error conversion pointed out by Luiz It looks ok now. > > Markus Armbruster (2): > qdev: Convert qdev_unplug() to QError > monitor: convert do_device_del() to QObject, QError > > hw/qdev.c | 11 +-- > hw/qdev.h |2 +- > qemu-monitor.hx |3 ++- > 3 files changed, 8 insertions(+), 8 deletions(-) >
Re: [Qemu-devel] BeOS R5 boot failure
> http://bochs.cvs.sourceforge.net/bochs/bochs/CHANGES?view=markup&content-type=text/vnd.viewcvs-markup&revision=REL_2_4_2_FINAL > > > 2.2.5 December 2005 BeOS boot failure fix in the PCI IDE code > > 2.3.5 September 2007 [1500216] Bochs fails to boot BeOs CD Hmm actually, I begin to think it just doesn't like booting from a partition image directly. The fact the bootloader lists the volume misleads into thinking it can boot... Using the image as cdrom with a floppy image works fine. Also, the log says ...ata/0/master/0/0_0 and 0_0 is supposed to be the first partition, which of course doesn't exist (and thus has a size of 0...), the whole block device should have been .../raw instead. I suppose I've been way too used to Haiku being able to boot this way. Those images were meant to be used in a FAT or ext2 partition, not straight away as disk images, unlike in Haiku. I suppose it was just too obvious :^) François.
[Qemu-devel] Re: [PATCH v2 11/11] monitor: New commands netdev_add, netdev_del
On Mon, 22 Mar 2010 10:48:53 +0100
Markus Armbruster wrote:
> Monitor commands to go with -netdev.
>
> Signed-off-by: Markus Armbruster
> ---
> net.c | 57
> ++-
> net.h |2 +
> qemu-monitor.hx | 30
> 3 files changed, 88 insertions(+), 1 deletions(-)
>
> diff --git a/net.c b/net.c
> index 1f3c39c..80e9025 100644
> --- a/net.c
> +++ b/net.c
> @@ -1122,7 +1122,7 @@ int net_client_init(Monitor *mon, QemuOpts *opts, int
> is_netdev)
> }
>
> qerror_report(QERR_INVALID_PARAMETER_VALUE, "type",
> - "a network backend type");
> + "a network client type");
> return -1;
> }
>
> @@ -1186,6 +1186,61 @@ void net_host_device_remove(Monitor *mon, const QDict
> *qdict)
> qemu_del_vlan_client(vc);
> }
>
> +/**
> + * do_netdev_add(): Add a host network device
> + *
> + * Argument qdict contains
> + * - "type": the device type, "tap", "user", ...
> + * - "id": the device's ID (must be unique)
Consecutive calls of this command in qmp with the same id succeeds, but
I couldn't understand why.
Other than that looks ok, although I'm not familiar with the device
handling machinery in qemu.
> + * - device options
> + *
> + * Example:
> + *
> + * { "type": "user", "id": "netdev1", "hostname": "a-guest" }
> + */
> +int do_netdev_add(Monitor *mon, const QDict *qdict, QObject **ret_data)
> +{
> +QemuOpts *opts;
> +int res;
> +
> +opts = qemu_opts_from_qdict(&qemu_netdev_opts, qdict);
> +if (!opts) {
> +return -1;
> +}
> +
> +res = net_client_init(mon, opts, 1);
> +qemu_opts_del(opts);
> +return res;
> +}
> +
> +/**
> + * do_netdev_del(): Delete a host network device
> + *
> + * Argument qdict contains
> + * - "id": the device's ID
> + *
> + * Example:
> + *
> + * { "id": "netdev1" }
> + */
> +int do_netdev_del(Monitor *mon, const QDict *qdict, QObject **ret_data)
> +{
> +const char *id = qdict_get_str(qdict, "id");
> +VLANClientState *vc;
> +
> +vc = qemu_find_netdev(id);
> +if (!vc || vc->info->type == NET_CLIENT_TYPE_NIC) {
> +qerror_report(QERR_DEVICE_NOT_FOUND, id);
> +return -1;
> +}
> +if (vc->peer) {
> +qerror_report(QERR_DEVICE_IN_USE, id);
> +return -1;
> +}
> +qemu_del_vlan_client(vc);
> +return 0;
> +}
> +
> void net_set_boot_mask(int net_boot_mask)
> {
> int i;
> diff --git a/net.h b/net.h
> index 16f19c5..ce9e2c6 100644
> --- a/net.h
> +++ b/net.h
> @@ -166,6 +166,8 @@ void net_cleanup(void);
> void net_set_boot_mask(int boot_mask);
> void net_host_device_add(Monitor *mon, const QDict *qdict);
> void net_host_device_remove(Monitor *mon, const QDict *qdict);
> +int do_netdev_add(Monitor *mon, const QDict *qdict, QObject **ret_data);
> +int do_netdev_del(Monitor *mon, const QDict *qdict, QObject **ret_data);
>
> #define DEFAULT_NETWORK_SCRIPT "/etc/qemu-ifup"
> #define DEFAULT_NETWORK_DOWN_SCRIPT "/etc/qemu-ifdown"
> diff --git a/qemu-monitor.hx b/qemu-monitor.hx
> index 5308f36..ff5f099 100644
> --- a/qemu-monitor.hx
> +++ b/qemu-monitor.hx
> @@ -913,6 +913,36 @@ STEXI
> Remove host VLAN client.
> ETEXI
>
> +{
> +.name = "netdev_add",
> +.args_type = "netdev:O",
> +.params = "[user|tap|socket],id=str[,prop=value][,...]",
> +.help = "add host network device",
> +.user_print = monitor_user_noop,
> +.mhandler.cmd_new = do_netdev_add,
> +},
> +
> +STEXI
> +...@item netdev_add
> +...@findex netdev_add
> +Add host network device.
> +ETEXI
> +
> +{
> +.name = "netdev_del",
> +.args_type = "id:s",
> +.params = "id",
> +.help = "remove host network device",
> +.user_print = monitor_user_noop,
> +.mhandler.cmd_new = do_netdev_del,
> +},
> +
> +STEXI
> +...@item netdev_del
> +...@findex netdev_del
> +Remove host network device.
> +ETEXI
> +
> #ifdef CONFIG_SLIRP
> {
> .name = "hostfwd_add",
[Qemu-devel] Re: [PATCH v2 0/6] error: Clean up after recent changes
On Mon, 22 Mar 2010 10:28:59 +0100 Markus Armbruster wrote: > Cleaner integration of location tracking with qemu-tool.c. Move > qerror_report() where it belongs. > > v2: Remove an assertion that unreachable code can't be reached, at > Blue Swirl's request. Rebased. > > Markus Armbruster (6): > error: Trim includes after "Move qemu_error & friends..." > error: Trim includes in qerror.c > error: Trim includes after "Infrastructure to track locations..." > error: Make use of error_set_progname() optional > error: Link qemu-img, qemu-nbd, qemu-io with qemu-error.o > error: Move qerror_report() from qemu-error.[ch] to qerror.[ch] Looks good. > > Makefile |6 +++--- > hw/qdev-properties.c |1 + > monitor.c|2 -- > monitor.h|1 - > qemu-error.c | 20 +--- > qemu-error.h |6 -- > qemu-tool.c | 49 +++-- > qerror.c | 22 -- > qerror.h |5 + > sysemu.h |2 -- > 10 files changed, 45 insertions(+), 69 deletions(-) >
[Qemu-devel] Compile files only once: some planning
Hi, Here's some planning for getting most files compiled as few times as possible. Comments and suggestions are welcome. I have now converted most of the easy cases which were compiled for all targets, saving about 200 compiles for full build with default set of targets (~1500 files compiled). For the easy files, the rules can be just moved from Makefile.target to Makefile.objs without impact. If the file was compiled conditionally, the rules may need to be added to default-configs/*.mak. Some defines, like TARGET_PAGE_SIZE or TARGET_WORDS_BIGENDIAN can be pushed to board level. The target dependent cases should be next. On full build, each MIPS device file gets compiled four times, PPC files three times and x86 twice. The devices for architectures that are compiled only once (ARM, Cris, Sparc32 etc.) do not need to be touched. I think it's better to add a new line for each device to default-configs instead of adding just CONFIG_MIPS for example. The harder cases are those where the device code depends somehow on the architecture. Some thoughts follow. vl.c: a lot of work. Maybe the CPUState stuff should be separated to a new file. virtio-*.c: push TARGET_PAGE_SIZE to board level, it's not so easy though. rtl8139.c, e1000.c: need to convert ldl/stl to cpu_physical_memory_read/write. ide/core.c: win2k flag could be passed from board level, or the code could just be enabled here because the flag is x86 only in vl.c. pckbd.c, vmmouse.c, x86 CPU: On x86 only, vmmouse wants to insert key events to pckbd buffer and pckbd is connected to x86 A20 line. The solution could be to use qemu_irq signals to handle A20 line changes and some code reorganization. dma.c: DMA_schedule needs access to CPUState. mc146818.c: coalesced IRQs only for x86, also APIC dependency. fpu/softfloat.c, fpu/softfloat-native.c: may need some #define adjustment.
Re: [Qemu-devel] BeOS R5 boot failure
> http://bochs.cvs.sourceforge.net/bochs/bochs/CHANGES?view=markup&content-type=text/vnd.viewcvs-markup&revision=REL_2_4_2_FINAL > > > 2.2.5 December 2005 BeOS boot failure fix in the PCI IDE code > > 2.3.5 September 2007 [1500216] Bochs fails to boot BeOs CD > I had a look at it, but it seems it's only about DMA... and the code in hw/ide/ seems to already or the status reg with BM_STATUS_INT (4) in many places... Seems to be something else maybe. François.
Re: [Qemu-devel] [PATCH 001/399] target-arm: Fix handling of AL condition in IT instruction
On Wed, Mar 17, 2010 at 01:56:07PM +0100, Johan Bengtsson wrote:
> Do not try to insert a conditional jump over next instruction when the
> condition code is AL as this will trigger an internal error.
>
> Signed-off-by: Johan Bengtsson
Thanks, applied.
> ---
> target-arm/translate.c |8 +---
> 1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/target-arm/translate.c b/target-arm/translate.c
> index 786c329..554583d 100644
> --- a/target-arm/translate.c
> +++ b/target-arm/translate.c
> @@ -8328,9 +8328,11 @@ static void disas_thumb_insn(CPUState *env,
> DisasContext *s)
>
> if (s->condexec_mask) {
> cond = s->condexec_cond;
> -s->condlabel = gen_new_label();
> -gen_test_cc(cond ^ 1, s->condlabel);
> -s->condjmp = 1;
> +if (cond != 0x0e) { /* Skip conditional when condition is AL. */
> + s->condlabel = gen_new_label();
> + gen_test_cc(cond ^ 1, s->condlabel);
> + s->condjmp = 1;
> +}
> }
>
> insn = lduw_code(s->pc);
> --
> 1.6.3.3
>
>
>
>
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH 3/4] tcg-hppa: Finish the port.
On Wed, Mar 17, 2010 at 07:56:12AM -0700, Richard Henderson wrote: > On 03/16/2010 06:58 PM, Stuart Brady wrote: > > The tcg_reg_free() calls worry me slightly, but I assume they're safe... > > Yeah, that one's rather gross. > > Since Aurelien's generic div/rem patch I could simply remove all > that millicode stuff, including that tcg_reg_free, and let the > generic code handle this instead. Which would get to the same > millicode routine via one or two extra levels of indirection. > > Thoughts? > I think that's the way to go. Can you please send a new patch doing that? -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH 2/4] tcg-hppa: Fix 64-bit argument ordering.
On Sat, Feb 20, 2010 at 11:32:23AM -0800, Richard Henderson wrote: > Signed-off-by: Richard Henderson Thanks, applied. > --- > tcg/tcg.c | 12 +++- > 1 files changed, 11 insertions(+), 1 deletions(-) > > diff --git a/tcg/tcg.c b/tcg/tcg.c > index 1818868..d753149 100644 > --- a/tcg/tcg.c > +++ b/tcg/tcg.c > @@ -596,7 +596,17 @@ void tcg_gen_callN(TCGContext *s, TCGv_ptr func, > unsigned int flags, > real_args++; > } > #endif > -#ifdef TCG_TARGET_WORDS_BIGENDIAN > + /* If stack grows up, then we will be placing successive > +arguments at lower addresses, which means we need to > +reverse the order compared to how we would normally > +treat either big or little-endian. For those arguments > +that will wind up in registers, this still works for > +HPPA (the only current STACK_GROWSUP target) since the > +argument registers are *also* allocated in decreasing > +order. If another such target is added, this logic may > +have to get more complicated to differentiate between > +stack arguments and register arguments. */ > +#if defined(TCG_TARGET_WORDS_BIGENDIAN) != defined(TCG_TARGET_STACK_GROWSUP) > *gen_opparam_ptr++ = args[i] + 1; > *gen_opparam_ptr++ = args[i]; > #else > -- > 1.6.6.1 > > > > -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH 1/4] tcg-hppa: Fix const errors in hppa-dis.c.
On Sat, Feb 20, 2010 at 11:31:31AM -0800, Richard Henderson wrote:
> Signed-off-by: Richard Henderson
Thanks, applied.
> ---
> hppa-dis.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hppa-dis.c b/hppa-dis.c
> index 9d96d72..49f99c8 100644
> --- a/hppa-dis.c
> +++ b/hppa-dis.c
> @@ -576,7 +576,7 @@ struct pa_opcode
> const char *name;
> unsigned long int match; /* Bits that must be set... */
> unsigned long int mask; /* ... in these bits. */
> -char *args;
> +const char *args;
> enum pa_arch arch;
> char flags;
> };
> @@ -2753,7 +2753,7 @@ print_insn_hppa (bfd_vma memaddr, disassemble_info
> *info)
> int sf = GET_FIELD (insn, 19, 20);
> const char * const * source = float_format_names;
> const char * const * dest = float_format_names;
> - char *t = "";
> + const char *t = "";
>
> if (sub == 4)
> {
> --
> 1.6.6.1
>
>
>
>
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH] remove remaining occurrences AREG[1-9] and TCG_AREG[1-9]
On Fri, Mar 19, 2010 at 11:31:15AM +0100, Paolo Bonzini wrote:
> Signed-off-by: Paolo Bonzini
> ---
> dyngen-exec.h | 26 --
> tcg/arm/tcg-target.h|2 --
> tcg/hppa/tcg-target.h |2 --
> tcg/i386/tcg-target.h |2 --
> tcg/mips/tcg-target.h |2 --
> tcg/ppc/tcg-target.h|2 --
> tcg/ppc64/tcg-target.h |2 --
> tcg/s390/tcg-target.h |3 ---
> tcg/sparc/tcg-target.h |8 +---
> tcg/x86_64/tcg-target.h |2 --
> 10 files changed, 1 insertions(+), 50 deletions(-)
Acked-by: Aurelien Jarno
> diff --git a/dyngen-exec.h b/dyngen-exec.h
> index 0353f36..d04eda8 100644
> --- a/dyngen-exec.h
> +++ b/dyngen-exec.h
> @@ -50,62 +50,36 @@ extern int printf(const char *, ...);
>
> #if defined(__i386__)
> #define AREG0 "ebp"
> -#define AREG1 "ebx"
> -#define AREG2 "esi"
> #elif defined(__x86_64__)
> #define AREG0 "r14"
> -#define AREG1 "r15"
> -#define AREG2 "r12"
> #elif defined(_ARCH_PPC)
> #define AREG0 "r27"
> -#define AREG1 "r24"
> -#define AREG2 "r25"
> #elif defined(__arm__)
> #define AREG0 "r7"
> -#define AREG1 "r4"
> -#define AREG2 "r5"
> #elif defined(__hppa__)
> #define AREG0 "r17"
> -#define AREG1 "r14"
> -#define AREG2 "r15"
> #elif defined(__mips__)
> #define AREG0 "fp"
> -#define AREG1 "s0"
> -#define AREG2 "s1"
> #elif defined(__sparc__)
> #ifdef CONFIG_SOLARIS
> #define AREG0 "g2"
> -#define AREG1 "g3"
> -#define AREG2 "g4"
> #else
> #ifdef __sparc_v9__
> #define AREG0 "g5"
> -#define AREG1 "g6"
> -#define AREG2 "g7"
> #else
> #define AREG0 "g6"
> -#define AREG1 "g1"
> -#define AREG2 "g2"
> #endif
> #endif
> #elif defined(__s390__)
> #define AREG0 "r10"
> -#define AREG1 "r7"
> -#define AREG2 "r8"
> #elif defined(__alpha__)
> /* Note $15 is the frame pointer, so anything in op-i386.c that would
> require a frame pointer, like alloca, would probably loose. */
> #define AREG0 "$15"
> -#define AREG1 "$9"
> -#define AREG2 "$10"
> #elif defined(__mc68000)
> #define AREG0 "%a5"
> -#define AREG1 "%a4"
> -#define AREG2 "%d7"
> #elif defined(__ia64__)
> #define AREG0 "r7"
> -#define AREG1 "r4"
> -#define AREG2 "r5"
> #else
> #error unsupported CPU
> #endif
> diff --git a/tcg/arm/tcg-target.h b/tcg/arm/tcg-target.h
> index 4cad967..7242be8 100644
> --- a/tcg/arm/tcg-target.h
> +++ b/tcg/arm/tcg-target.h
> @@ -73,8 +73,6 @@ enum {
> enum {
> /* Note: must be synced with dyngen-exec.h */
> TCG_AREG0 = TCG_REG_R7,
> -TCG_AREG1 = TCG_REG_R4,
> -TCG_AREG2 = TCG_REG_R5,
> };
>
> static inline void flush_icache_range(unsigned long start, unsigned long
> stop)
> diff --git a/tcg/hppa/tcg-target.h b/tcg/hppa/tcg-target.h
> index fa39bfc..e956e71 100644
> --- a/tcg/hppa/tcg-target.h
> +++ b/tcg/hppa/tcg-target.h
> @@ -83,8 +83,6 @@ enum {
>
> /* Note: must be synced with dyngen-exec.h */
> #define TCG_AREG0 TCG_REG_R17
> -#define TCG_AREG1 TCG_REG_R14
> -#define TCG_AREG2 TCG_REG_R15
>
> static inline void flush_icache_range(unsigned long start, unsigned long
> stop)
> {
> diff --git a/tcg/i386/tcg-target.h b/tcg/i386/tcg-target.h
> index e994fd5..7bb765e 100644
> --- a/tcg/i386/tcg-target.h
> +++ b/tcg/i386/tcg-target.h
> @@ -62,8 +62,6 @@ enum {
>
> /* Note: must be synced with dyngen-exec.h */
> #define TCG_AREG0 TCG_REG_EBP
> -#define TCG_AREG1 TCG_REG_EBX
> -#define TCG_AREG2 TCG_REG_ESI
>
> static inline void flush_icache_range(unsigned long start, unsigned long
> stop)
> {
> diff --git a/tcg/mips/tcg-target.h b/tcg/mips/tcg-target.h
> index 377b0c8..6b7741c 100644
> --- a/tcg/mips/tcg-target.h
> +++ b/tcg/mips/tcg-target.h
> @@ -95,8 +95,6 @@ enum {
>
> /* Note: must be synced with dyngen-exec.h */
> #define TCG_AREG0 TCG_REG_FP
> -#define TCG_AREG1 TCG_REG_S0
> -#define TCG_AREG2 TCG_REG_S1
>
> #include
>
> diff --git a/tcg/ppc/tcg-target.h b/tcg/ppc/tcg-target.h
> index 0c71a11..5cae81f 100644
> --- a/tcg/ppc/tcg-target.h
> +++ b/tcg/ppc/tcg-target.h
> @@ -91,7 +91,5 @@ enum {
> #define TCG_TARGET_HAS_orc_i32
>
> #define TCG_AREG0 TCG_REG_R27
> -#define TCG_AREG1 TCG_REG_R24
> -#define TCG_AREG2 TCG_REG_R25
>
> #define TCG_TARGET_HAS_GUEST_BASE
> diff --git a/tcg/ppc64/tcg-target.h b/tcg/ppc64/tcg-target.h
> index f5de642..e367751 100644
> --- a/tcg/ppc64/tcg-target.h
> +++ b/tcg/ppc64/tcg-target.h
> @@ -98,7 +98,5 @@ enum {
> /* #define TCG_TARGET_HAS_orc_i64 */
>
> #define TCG_AREG0 TCG_REG_R27
> -#define TCG_AREG1 TCG_REG_R24
> -#define TCG_AREG2 TCG_REG_R25
>
> #define TCG_TARGET_HAS_GUEST_BASE
> diff --git a/tcg/s390/tcg-target.h b/tcg/s390/tcg-target.h
> index e803401..82e2be7 100644
> --- a/tcg/s390/tcg-target.h
> +++ b/tcg/s390/tcg-target.h
> @@ -84,9 +84,6 @@ enum {
> enum {
> /* Note: must be synced with dyngen-exec.h */
> TCG_AREG0 = TCG_REG_R10,
> -TCG_AREG1 = TCG_REG_R7,
> -TCG_AREG2 = TCG_REG_R8,
> -TCG_AREG3 = TCG_REG_R9,
> };
>
> static inline void flush_icache_range(unsigned l
[Qemu-devel] Re: [RFC] vhost-blk implementation
Michael S. Tsirkin wrote: On Tue, Mar 23, 2010 at 10:57:33AM -0700, Badari Pulavarty wrote: Michael S. Tsirkin wrote: On Mon, Mar 22, 2010 at 05:34:04PM -0700, Badari Pulavarty wrote: Write Results: == I see degraded IO performance when doing sequential IO write tests with vhost-blk compared to virtio-blk. # time dd of=/dev/vda if=/dev/zero bs=2M oflag=direct I get ~110MB/sec with virtio-blk, but I get only ~60MB/sec with vhost-blk. Wondering why ? Try to look and number of interrupts and/or number of exits. I checked interrupts and IO exits - there is no major noticeable difference between vhost-blk and virtio-blk scenerios. It could also be that you are overrunning some queue. I don't see any exit mitigation strategy in your patch: when there are already lots of requests in a queue, it's usually a good idea to disable notifications and poll the queue as requests complete. That could help performance. Do you mean poll eventfd for new requests instead of waiting for new notifications ? Where do you do that in vhost-net code ? vhost_disable_notify does this. Unlike network socket, since we are dealing with a file, there is no ->poll support for it. So I can't poll for the data. And also, Issue I am having is on the write() side. Not sure I understand. I looked at it some more - I see 512K write requests on the virtio-queue in both vhost-blk and virtio-blk cases. Both qemu or vhost is doing synchronous writes to page cache (there is no write batching in qemu that is affecting this case). I still puzzled on why virtio-blk outperforms vhost-blk. Thanks, Badari If you say the number of requests is the same, we are left with: - requests are smaller for some reason? - something is causing retries? No. IO requests sizes are exactly same (512K) in both cases. There are no retries or errors in both cases. One thing I am not clear is - for some reason guest kernel could push more data into virtio-ring in case of virtio-blk vs vhost-blk. Is this possible ? Does guest gets to run much sooner in virtio-blk case than vhost-blk ? Sorry, if its dumb question - I don't understand all the vhost details :( Thanks, Badari
[Qemu-devel] Re: [RFC] vhost-blk implementation
Michael S. Tsirkin wrote: On Mon, Mar 22, 2010 at 05:34:04PM -0700, Badari Pulavarty wrote: Write Results: == I see degraded IO performance when doing sequential IO write tests with vhost-blk compared to virtio-blk. # time dd of=/dev/vda if=/dev/zero bs=2M oflag=direct I get ~110MB/sec with virtio-blk, but I get only ~60MB/sec with vhost-blk. Wondering why ? Try to look and number of interrupts and/or number of exits. I checked interrupts and IO exits - there is no major noticeable difference between vhost-blk and virtio-blk scenerios. It could also be that you are overrunning some queue. I don't see any exit mitigation strategy in your patch: when there are already lots of requests in a queue, it's usually a good idea to disable notifications and poll the queue as requests complete. That could help performance. Do you mean poll eventfd for new requests instead of waiting for new notifications ? Where do you do that in vhost-net code ? Unlike network socket, since we are dealing with a file, there is no ->poll support for it. So I can't poll for the data. And also, Issue I am having is on the write() side. I looked at it some more - I see 512K write requests on the virtio-queue in both vhost-blk and virtio-blk cases. Both qemu or vhost is doing synchronous writes to page cache (there is no write batching in qemu that is affecting this case). I still puzzled on why virtio-blk outperforms vhost-blk. Thanks, Badari
[Qemu-devel] Re: [RFC] vhost-blk implementation
Michael S. Tsirkin wrote: On Mon, Mar 22, 2010 at 05:34:04PM -0700, Badari Pulavarty wrote: Write Results: == I see degraded IO performance when doing sequential IO write tests with vhost-blk compared to virtio-blk. # time dd of=/dev/vda if=/dev/zero bs=2M oflag=direct I get ~110MB/sec with virtio-blk, but I get only ~60MB/sec with vhost-blk. Wondering why ? Try to look and number of interrupts and/or number of exits. It could also be that you are overrunning some queue. Yeah. I don't see any exit mitigation strategy in your patch: when there are already lots of requests in a queue, it's usually a good idea to disable notifications and poll the queue as requests complete. That could help performance. Thanks for the suggestions. I will take a closer look. Thanks, Badari
[Qemu-devel] Re: hi, may I ask some help on the paravirtualization of KVM?
I use the qemu-kvm-0.12-3 version source file. Just follow the typical three steps: ./configure && make && make install. After I configure, following is output: Install prefix/usr/local BIOS directory/usr/local/share/qemu binary directory /usr/local/bin Manual directory /usr/local/share/man ELF interp prefix /usr/gnemul/qemu-%M Source path /root/svt/qemu-kvm-0.12.3 C compilergcc Host C compiler gcc CFLAGS-O2 -g QEMU_CFLAGS -m32 -Wold-style-definition -Wold-style-declaration -I. -I$(SRC_PATH) -U_FORTIFY_SOURCE -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wendif-labels -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing LDFLAGS -Wl,--warn-common -m32 -g make make install install host CPU i386 host big endian no target list x86_64-softmmu tcg debug enabled no gprof enabled no sparse enabledno strip binariesyes profiler no static build no -Werror enabled no SDL support yes curses supportyes curl support yes check support no mingw32 support no Audio drivers oss Extra audio cards ac97 es1370 sb16 Block whitelist Mixer emulation no VNC TLS support yes VNC SASL support yes xen support no CPU emulation yes brlapi supportno bluez supportno Documentation no NPTL support yes GUEST_BASEyes PIE user targets no vde support no IO thread no Linux AIO support no Install blobs yes KVM support yes KVM PIT support yes KVM device assig. yes KVM trace support no fdt support no preadv supportno fdatasync yes uuid support yes All compile procedure seems normal. No warning exists. And I use this command to start the GuestOS: ./x86_64-softmmu/qemu-system-x86_64 -m 1024 /root/redhat.img -net nic, model=virtio -net tap, script=/etc/qemu-ifup The qemu-ifup script is : #!/bin/sh #sample /etc/qemu-ifup to have bridged networking between qemu instances and your real net # You need "youruser ALL=(root) NOPASSWD: /etc/qemu-ifup" in /etc/sudoers # You also need enough rights on /dev/tun if [ $UID -ne 0 ] then sudo $0 $1 exit fi /sbin/ifconfig $1 promisc 0.0.0.0 if ! /sbin/ifconfig br0 then /usr/sbin/brctl addbr br0 /usr/sbin/brctl addif br0 eth0 /sbin/ifconfig br0 up addr=`/sbin/ip addr | grep eth0 | grep inet | sed -e 's/eth0/dev br0/' -e s/inet//` /sbin/ip addr add $addr fi /usr/sbin/brctl addif br0 $1 /usr/sbin/brctl stp br0 off /sbin/ip route | grep eth0 | while read route do newroute=`echo $route | sed s/eth0/br0/ ` /sbin/ip route del $route /sbin/ip route add $newroute done On Tue, Mar 23, 2010 at 9:59 PM, Amit Shah wrote: > Hello, > > [any reason you dropped the CC list? CC'ing qemu-devel, where this is > relevant.] > > On (Tue) Mar 23 2010 [21:46:28], Liang YANG wrote: >> I check the 'lspci -v' result, only find RTL-8139 realtek ethernet. I >> think the option model=virtio does't make effect. > > Then something is wrong. I get a virtio ethernet device using > model=virtio. > > Which qemu version are you using? > >> Simultaneously, I have the a look at the code. The function pc_init1() >> seem not change the network model as the option assigned. >> >> Do you ever meet this case? > > I've not seen this. > >> On Tue, Mar 23, 2010 at 9:08 PM, Amit Shah wrote: >> > On (Sun) Mar 21 2010 [20:18:53], Liang YANG wrote: >> >> I want to set up the virtio-net for the GuestOS on KVM. Following is my >> >> steps: >> >> >> >> 1.Compile the kvm-88 and make, make install. >> >> 2.Compile the GuestOS(redhat) with kernel version 2.6.27.45(with >> >> virtio support). The required option are all selected. >> >> o CONFIG_VIRTIO_PCI=y (Virtualization -> PCI driver for >> >> virtio devices) >> >> o CONFIG_VIRTIO_BALLOON=y (Virtualization -> Virtio balloon >> >> driver) >> >> o CONFIG_VIRTIO_BLK=y (Device Drivers -> Block -> Virtio block >> >> driver) >> >> o CONFIG_VIRTIO_NET=y (Device Drivers -> Network device >> >> support -> Virtio network driver) >> >> o CONFIG_VIRTIO=y (automatically selected) >> >> o CONFIG_VIRTIO_RING=y (automatically selected) >> >> 3.Then start up the GuestOS by such command: >> >> x86_64-softmmu/qemu-system-x86_64 -m 1024 /root/redhat.img >> >> -net nic,model=virtio -net tap,script=/etc/kvm/qemu-ifup >> >> 4.Result is this: >> >> * The Guest OS start up. >> >> * But the network not, no eth-X device found. >> >> * lsmod | grep virtio get none module about virtio >> > >> > Since you selected the virtio options as 'y', they are directly compiled >> > into the kernel and hence you won't see the modules. >> > >> > Check your 'lspci -v' output. You should see the virtio device there. >> > You can also try some usual things like 'ifconfig eth0 up', etc., to get >> > the interface. >> > >> >
[Qemu-devel] Trying to build an Ubuntu-x64-guest on Windows-XP-x86-Host on x86-PC failed
Hi, I read, that it´s possible, to emulate an x64-Processor with QEMU on an x86-based PC, isn´t it. When I run the installation of Ubuntu-9.10-x64 under Qemu-Manager 6.0 under Windows-XP, I always get an storage-error. Who can help me, to solve that problem? With best regards, Christoph Funda _ autocreated E-Mail Appendix / automatisch erzeugter E-Mail Anhang Christoph Funda Diehl BGT Defence GmbH & Co. KG Fischbachstrasse 16 90552 Roethenbach a d Pegnitz http://www.diehl-bgt-defence.de Telefon: +49 911 957 2134 Telefax: +49 911 957 2710 mailto:christoph.fu...@diehl-bgt-defence.de _ Diehl BGT Defence GmbH & Co. KG Sitz der Gesellschaft: Ueberlingen - Amtsgericht Freiburg i. Br. HRA 581075 Persoenlich haftende Gesellschafterin: Diehl BGT Defence Verwaltungs-GmbH Sitz der Gesellschaft: Ueberlingen - Amtsgericht Freiburg i. Br. HRB 581694 Geschaeftsfuehrer: Dipl.-Ing. (FH) Peter Ibbeken (Sprecher), Dipl.-Betrw. (BA) Thomas Bodenmueller _
[Qemu-devel] development documents
Hi, all. I have just touched QEMU and I am doing experiments of malware using the emulator. I need some development docs for reference. Appreciate your help.
[Qemu-devel] [RFC] vhost-blk implementation
Hi,
Inspired by vhost-net implementation, I did initial prototype
of vhost-blk to see if it provides any benefits over QEMU virtio-blk.
I haven't handled all the error cases, fixed naming conventions etc.,
but the implementation is stable to play with. I tried not to deviate
from vhost-net implementation where possible.
NOTE: Only change I had to make to vhost core code is to
increase VHOST_NET_MAX_SG to 130 (128+2) in vhost.h
Performance:
=
I have done simple tests to see how it performs. I got very
encouraging results on sequential read tests. But on sequential
write tests, I see degrade over virtio-blk. I can't figure out and
explain why. Can some one shed light on whats happening here ?
Read Results:
=
Test does read of 84GB file from the host (through virtio). I unmount
and mount the filesystem on the host to make sure there is nothing
in the page cache..
with vhost-blk:
# time dd if=/dev/vda of=/dev/null bs=128k iflag=direct
64+0 records in
64+0 records out
8388608 bytes (84 GB) copied, 126.135 seconds, 665 MB/s
real2m6.137s
user0m0.281s
sys 0m14.725s
without vhost-blk: (virtio)
---
# time dd if=/dev/vda of=/dev/null bs=128k iflag=direct
64+0 records in
64+0 records out
8388608 bytes (84 GB) copied, 275.466 seconds, 305 MB/s
real4m35.468s
user0m0.373s
sys 0m48.074s
Write Results:
==
I see degraded IO performance when doing sequential IO write
tests with vhost-blk compared to virtio-blk.
# time dd of=/dev/vda if=/dev/zero bs=2M oflag=direct
I get ~110MB/sec with virtio-blk, but I get only ~60MB/sec with
vhost-blk. Wondering why ?
Comments/flames ?
Thanks,
Badari
vhost-blk is in-kernel accelerator for virtio-blk.
At this time, this is a prototype based on virtio-net.
Lots of error handling and clean up needs to be done.
Read performance is pretty good over QEMU virtio-blk, but
write performance is not anywhere close to QEMU virtio-blk.
Why ?
Signed-off-by: Badari Pulavarty
---
drivers/vhost/blk.c | 242
1 file changed, 242 insertions(+)
Index: net-next/drivers/vhost/blk.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ net-next/drivers/vhost/blk.c2010-03-22 18:07:18.156584400 -0400
@@ -0,0 +1,242 @@
+ /*
+ * virtio-block server in host kernel.
+ * Inspired by vhost-net and shamlessly ripped code from it :)
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "vhost.h"
+
+#define VHOST_BLK_VQ_MAX 1
+
+struct vhost_blk {
+ struct vhost_dev dev;
+ struct vhost_virtqueue vqs[VHOST_BLK_VQ_MAX];
+ struct vhost_poll poll[VHOST_BLK_VQ_MAX];
+};
+
+static int do_handle_io(struct file *file, uint32_t type, uint64_t sector,
+ struct iovec *iov, int in)
+{
+ loff_t pos = sector << 8;
+ int ret = 0;
+
+ if (type & VIRTIO_BLK_T_FLUSH) {
+ ret = vfs_fsync(file, file->f_path.dentry, 1);
+ } else if (type & VIRTIO_BLK_T_OUT) {
+ ret = vfs_writev(file, iov, in, &pos);
+ } else {
+ ret = vfs_readv(file, iov, in, &pos);
+ }
+ return ret;
+}
+
+static void handle_blk(struct vhost_blk *blk)
+{
+ struct vhost_virtqueue *vq = &blk->dev.vqs[0];
+ unsigned head, out, in;
+ struct virtio_blk_outhdr hdr;
+ int r, nvecs;
+ uint8_t status = 0;
+
+ use_mm(blk->dev.mm);
+ mutex_lock(&vq->mutex);
+
+ vhost_disable_notify(vq);
+
+ for (;;) {
+ head = vhost_get_vq_desc(&blk->dev, vq, vq->iov,
+ARRAY_SIZE(vq->iov),
+&out, &in, NULL, NULL);
+ if (head == vq->num) {
+ if (unlikely(vhost_enable_notify(vq))) {
+ vhost_disable_notify(vq);
+ continue;
+ }
+ break;
+ }
+
+ BUG_ON(vq->iov[0].iov_len != 16);
+
+ r = copy_from_user(&hdr, vq->iov[0].iov_base, sizeof hdr);
+ if (r < 0) {
+ printk("copy from user failed\n");
+ vhost_discard_vq_desc(vq);
+ break;
+ }
+
+ nvecs = out - 1;
+ if (hdr.type == VIRTIO_BLK_T_IN)
+ nvecs = in - 1;
+
+ r = do_handle_io(vq->private_data, hdr.type, hdr.sector,
&vq->iov[1], nvecs);
+ status = (r < 0) ? VIRTIO_BLK_S_IOERR : VIRTIO_BLK_S_OK;
+
+ nvecs++;
+ BUG_ON(vq->iov[nvecs].iov_len != 1);
+
+ if (copy_to_user(vq->iov[nvecs].iov_base, &status, sizeof
status) < 0) {
[Qemu-devel] [PATCH 2/2] Added monitor commands: 'keyboard_set' and 'info keybaord'
Two new monitor commands: adding ability to handle which keyboard qemu will
use and to see which keyboard are currently available.
$ info keyboard
$ keyboard_set
Signed-off-by: Shahar Havivi
---
console.h |4 ++
input.c | 104 +++
monitor.c |8
qemu-monitor.hx | 17 +
qerror.c|8
5 files changed, 141 insertions(+), 0 deletions(-)
diff --git a/console.h b/console.h
index 16c9c3d..7efa88e 100644
--- a/console.h
+++ b/console.h
@@ -85,6 +85,10 @@ void do_info_mice_print(Monitor *mon, const QObject *data);
void do_info_mice(Monitor *mon, QObject **ret_data);
void do_mouse_set(Monitor *mon, const QDict *qdict);
+void do_info_keyboard_print(Monitor *mon, const QObject *data);
+void do_info_keyboard(Monitor *mon, QObject **ret_data);
+int do_keyboard_set(Monitor *mon, const QDict *qdict, QObject **ret_data);
+
/* keysym is a unicode code except for special keys (see QEMU_KEY_xxx
constants) */
#define QEMU_KEY_ESC1(c) ((c) | 0xe100)
diff --git a/input.c b/input.c
index 563ecad..4daaeb0 100644
--- a/input.c
+++ b/input.c
@@ -368,3 +368,107 @@ void qemu_remove_mouse_mode_change_notifier(Notifier
*notify)
{
notifier_list_remove(&mouse_mode_notifiers, notify);
}
+
+static void info_keyboard_iter(QObject *data, void *opaque)
+{
+QDict *kbd;
+Monitor *mon = opaque;
+
+kbd = qobject_to_qdict(data);
+monitor_printf(mon, "%c Keyboard #%" PRId64 ": %s\n",
+ (qdict_get_bool(kbd, "current") ? '*' : ' '),
+ qdict_get_int(kbd, "index"), qdict_get_str(kbd, "name"));
+}
+
+void do_info_keyboard_print(Monitor *mon, const QObject *data)
+{
+QList *kbd_list;
+
+kbd_list = qobject_to_qlist(data);
+if (qlist_empty(kbd_list)) {
+monitor_printf(mon, "No keyboard devices connected\n");
+return;
+}
+
+qlist_iter(kbd_list, info_keyboard_iter, mon);
+}
+
+/*
+ * do_info_keyboard(): Show VM keyboard information
+ *
+ * Each keyboard is represented by a QDict, the returned QObject is
+ * a QList of all keyboards.
+ *
+ * The keyboard QDict contains the following:
+ *
+ * - "name": keyboard's name
+ * - "index": keyboard's index
+ * - "current": true if this keyboard is receiving events, false otherwise
+ *
+ * Example:
+ *
+ * [ { "name": "QEMU USB Keyboard", "index": 0, "current": false },
+ * { "name": "QEMU PS/2 Keyboard", "index": 1, "current": true } ]
+ */
+void do_info_keyboard(Monitor *mon, QObject **ret_data)
+{
+QEMUPutKbdEntry *cursor;
+QList *kbd_list;
+int index = 0;
+
+kbd_list = qlist_new();
+
+if (!qemu_put_kbd_event_head) {
+goto out;
+}
+
+cursor = qemu_put_kbd_event_head;
+while (cursor != NULL) {
+QObject *obj;
+obj = qobject_from_jsonf("{ 'name': %s, 'index': %d, 'current': %i }",
+ cursor->qemu_put_kbd_name,
+ index, cursor == qemu_put_kbd_event_current);
+qlist_append_obj(kbd_list, obj);
+index++;
+cursor = cursor->next;
+}
+out:
+*ret_data = QOBJECT(kbd_list);
+}
+
+/*
+ * do_keyboard_set(): Set active keyboard
+ *
+ * Argument qdict contains
+ * - "index": the keyboard index to set
+ *
+ * Example:
+ *
+ * { "index": "0" }
+ */
+int do_keyboard_set(Monitor *mon, const QDict *qdict, QObject **ret_data)
+{
+QEMUPutKbdEntry *cursor;
+int i = 0;
+int index = qdict_get_int(qdict, "index");
+
+if (!qemu_put_kbd_event_head) {
+qerror_report(QERR_DEVICE_NOT_FOUND, "keyboard");
+return -1;
+}
+
+cursor = qemu_put_kbd_event_head;
+while (cursor != NULL && index != i) {
+i++;
+cursor = cursor->next;
+}
+
+if (cursor != NULL) {
+qemu_put_kbd_event_current = cursor;
+}
+else {
+qerror_report(QERR_INVALID_PARAMETER, "index");
+return -1;
+}
+return 0;
+}
diff --git a/monitor.c b/monitor.c
index 0448a70..cc95b3d 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2783,6 +2783,14 @@ static const mon_cmd_t info_cmds[] = {
.mhandler.info_new = do_info_mice,
},
{
+.name = "keyboard",
+.args_type = "",
+.params = "",
+.help = "show which guest keyboard is receiving events",
+.user_print = do_info_keyboard_print,
+.mhandler.info_new = do_info_keyboard,
+},
+{
.name = "vnc",
.args_type = "",
.params = "",
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index 5308f36..e9beb12 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -659,6 +659,23 @@ info mice
@end example
ETEXI
+{
+.name = "keyboard_set",
+.args_type = "index:i",
+.params = "index",
+.help = "set which keyboard device receives events",
+.mhandler.cmd_new = do_keyboard_set,
+},
+
+STEXI
+...@item keyboard_set @var{in
Re: [Qemu-devel] git head broken? (x86 softmmu w/o kvm)
Anthony Liguori writes: > Hi, > > On 03/23/2010 02:24 PM, Blue Swirl wrote: >> On 3/23/10, Aurelien Jarno wrote: >> >>> On Tue, Mar 23, 2010 at 03:27:26AM +0100, Aurelien Jarno wrote: >>> > On Mon, Mar 22, 2010 at 10:25:24PM +0100, Juergen Lock wrote: >>> > > Hi! >>> > > >>> > > I just wanted to make another FreeBSD qemu git head snaphot port >>> update, >>> > > and found both i386-softmmu and x86_64-softmmu no longer boot, they >>> seem >>> > > to hang early in the bios before it prints anything, last tb seems >>> to be >>> > > this loop: >>> > > >>> > >>> > A quick bisect revealed it has been broken by this patch: >>> > >>> >>> >>> I have just pushed a patch to fix the problem. >>> >> Thanks, sorry for the trouble. >> > > It would be nice to send a series like this to the list first in the > future to give people a heads up. It's a useful set of clean-ups but > it's nice to give people a chance to provide input. It's not merely "nice", it's how we work. It's a far more important and useful rule than where to put the curlies and such. And yes, the patch series is good stuff.
[Qemu-devel] [PATCH 1/2] Support for multiple keyboard devices
Currently you get segfault when trying to remove keyboard (device_del
monitor command) because no keyboard handling is done.
This patch add QEMUPutKbdEntry structure, handling each keyboard entry.
Adding a keyboard add to the list, removing keyboard select the previous
keyboard in list.
Signed-off-by: Shahar Havivi
---
console.h| 12 ++-
hw/adb.c |2 +-
hw/escc.c|3 +-
hw/musicpal.c|2 +-
hw/nseries.c |4 +-
hw/palm.c|2 +-
hw/ps2.c |2 +-
hw/pxa2xx_keypad.c |2 +-
hw/spitz.c |2 +-
hw/stellaris_input.c |2 +-
hw/syborg_keyboard.c |2 +-
hw/usb-hid.c | 10 --
hw/xenfb.c |4 +-
input.c | 90 -
14 files changed, 112 insertions(+), 27 deletions(-)
diff --git a/console.h b/console.h
index 6def115..16c9c3d 100644
--- a/console.h
+++ b/console.h
@@ -41,7 +41,17 @@ typedef struct QEMUPutLEDEntry {
QTAILQ_ENTRY(QEMUPutLEDEntry) next;
} QEMUPutLEDEntry;
-void qemu_add_kbd_event_handler(QEMUPutKBDEvent *func, void *opaque);
+typedef struct QEMUPutKbdEntry {
+char *qemu_put_kbd_name;
+QEMUPutKBDEvent *qemu_put_kbd_event;
+void *qemu_put_kbd_event_opaque;
+struct QEMUPutKbdEntry *next;
+} QEMUPutKbdEntry;
+
+QEMUPutKbdEntry *qemu_add_kbd_event_handler(QEMUPutKBDEvent *func,
+void *opaque,
+const char *name);
+void qemu_remove_kbd_event_handler(QEMUPutKbdEntry *entry);
QEMUPutMouseEntry *qemu_add_mouse_event_handler(QEMUPutMouseEvent *func,
void *opaque, int absolute,
const char *name);
diff --git a/hw/adb.c b/hw/adb.c
index 4fb7a62..09afcf9 100644
--- a/hw/adb.c
+++ b/hw/adb.c
@@ -304,7 +304,7 @@ void adb_kbd_init(ADBBusState *bus)
s = qemu_mallocz(sizeof(KBDState));
d = adb_register_device(bus, ADB_KEYBOARD, adb_kbd_request,
adb_kbd_reset, s);
-qemu_add_kbd_event_handler(adb_kbd_put_keycode, d);
+qemu_add_kbd_event_handler(adb_kbd_put_keycode, d, "adb");
register_savevm("adb_kbd", -1, 1, adb_kbd_save,
adb_kbd_load, s);
}
diff --git a/hw/escc.c b/hw/escc.c
index 6d2fd36..2b21d98 100644
--- a/hw/escc.c
+++ b/hw/escc.c
@@ -919,7 +919,8 @@ static int escc_init1(SysBusDevice *dev)
"QEMU Sun Mouse");
}
if (s->chn[1].type == kbd) {
-qemu_add_kbd_event_handler(sunkbd_event, &s->chn[1]);
+qemu_add_kbd_event_handler(sunkbd_event, &s->chn[1],
+ "QEMU Sun Keyboard");
}
return 0;
diff --git a/hw/musicpal.c b/hw/musicpal.c
index 7fc9fb3..aca8a88 100644
--- a/hw/musicpal.c
+++ b/hw/musicpal.c
@@ -1447,7 +1447,7 @@ static int musicpal_key_init(SysBusDevice *dev)
qdev_init_gpio_out(&dev->qdev, s->out, ARRAY_SIZE(s->out));
-qemu_add_kbd_event_handler(musicpal_key_event, s);
+qemu_add_kbd_event_handler(musicpal_key_event, s, "Musicpal");
return 0;
}
diff --git a/hw/nseries.c b/hw/nseries.c
index 0273eee..abfcec3 100644
--- a/hw/nseries.c
+++ b/hw/nseries.c
@@ -262,7 +262,7 @@ static void n800_tsc_kbd_setup(struct n800_s *s)
if (n800_keys[i] >= 0)
s->keymap[n800_keys[i]] = i;
-qemu_add_kbd_event_handler(n800_key_event, s);
+qemu_add_kbd_event_handler(n800_key_event, s, "Nokia n800");
tsc210x_set_transform(s->ts.chip, &n800_pointercal);
}
@@ -371,7 +371,7 @@ static void n810_kbd_setup(struct n800_s *s)
if (n810_keys[i] > 0)
s->keymap[n810_keys[i]] = i;
-qemu_add_kbd_event_handler(n810_key_event, s);
+qemu_add_kbd_event_handler(n810_key_event, s, "Nokia n810");
/* Attach the LM8322 keyboard to the I2C bus,
* should happen in n8x0_i2c_setup and s->kbd be initialised here. */
diff --git a/hw/palm.c b/hw/palm.c
index 6d19167..1b405d4 100644
--- a/hw/palm.c
+++ b/hw/palm.c
@@ -228,7 +228,7 @@ static void palmte_init(ram_addr_t ram_size,
palmte_microwire_setup(cpu);
-qemu_add_kbd_event_handler(palmte_button_event, cpu);
+qemu_add_kbd_event_handler(palmte_button_event, cpu, "Palm Keyboard");
palmte_gpio_setup(cpu);
diff --git a/hw/ps2.c b/hw/ps2.c
index f0b206a..886da37 100644
--- a/hw/ps2.c
+++ b/hw/ps2.c
@@ -596,7 +596,7 @@ void *ps2_kbd_init(void (*update_irq)(void *, int), void
*update_arg)
s->common.update_arg = update_arg;
s->scancode_set = 2;
vmstate_register(0, &vmstate_ps2_keyboard, s);
-qemu_add_kbd_event_handler(ps2_put_keycode, s);
+qemu_add_kbd_event_handler(ps2_put_keycode, s, "QEMU PS/2 Keyboard");
qemu_register_reset(ps2_kbd_reset, s);
return s;
}
diff --git a/hw/pxa2xx_keypad.c b/hw/pxa2xx_keypad.c
index 060df58..7fa5af9 100644
--- a/hw/pxa2xx_ke
[Qemu-devel] [PATCH 0/2] Qemu support for multiple keyboard devices - v2
* After Anthony patches, and Luiz comments Qemu support for multiple keyboard devices: Patch #1 adding keyboard is done to list instead of "last added keyboard wins", when removing keyboard via device_del - next keyboard selected. Patch #2 adding 2 new monitor command to handle keyboard list: 'info keyboard' - show all keyboards and mark the current one 'keyboard_set' - set active keyboard by index as display in 'info keyboard' Shahar Havivi (2): Support for multiple keyboard devices Added monitor commands: 'keyboard_set' and 'info keybaord' console.h| 16 - hw/adb.c |2 +- hw/escc.c|3 +- hw/musicpal.c|2 +- hw/nseries.c |4 +- hw/palm.c|2 +- hw/ps2.c |2 +- hw/pxa2xx_keypad.c |2 +- hw/spitz.c |2 +- hw/stellaris_input.c |2 +- hw/syborg_keyboard.c |2 +- hw/usb-hid.c | 10 ++- hw/xenfb.c |4 +- input.c | 194 +++--- monitor.c|8 ++ qemu-monitor.hx | 17 + qerror.c |8 ++ 17 files changed, 253 insertions(+), 27 deletions(-)
Re: [Qemu-devel] [PATCH] Fix bsd-user broken by commit b5ec5ce0e39d6e7ea707d5604a5f6d567dfd2f48
Thanks, applied.
On 3/22/10, Juergen Lock wrote:
> Signed-off-by: Juergen Lock
>
> --- a/bsd-user/main.c
> +++ b/bsd-user/main.c
> @@ -759,6 +759,10 @@ int main(int argc, char **argv)
> }
>
> cpu_model = NULL;
> +#if defined(cpudef_setup)
> +cpudef_setup(); /* parse cpu definitions in target config file (TBD) */
> +#endif
> +
> optind = 1;
> for(;;) {
> if (optind >= argc)
>
>
>
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On 03/23/2010 01:07 PM, Daniel P. Berrange wrote: On Tue, Mar 23, 2010 at 11:06:20AM -0500, Anthony Liguori wrote: On 03/23/2010 10:57 AM, Paul Brook wrote: I think there is a serious divergence of approach there, instanciating API stating 'we are gonna deprecate them sooner or later' tell the application developper 'my time is more important than yours' and not really something I like to carry to the API users. The main goal of libvirt remains to provide APIs needed to unify the development of the virtualization layers. Having APIs which makes sense only for one or 2 virtualization engines is not a problem in itself, it just raises questions about the actual semantic of that API. If that semantic is sound, then I see no reason to not add it, really and we actually often do. Yeah, but the problem we're facing is, I want there to be an API added to the management layer as part of the feature commit in qemu. If there has to be a discussion and decisions about how to model the API, it's not going to be successful. I thought the monitor protocol *was* our API. If not, why not? It is. But our API is missing key components like guest enumeration. So the fundamental topic here is, do we introduce these missing components to allow people to build directly to our interface or do we make use of the functionality that libvirt already provides if they can plumb our API directly to users. There's two levels of API here - VM level API - essentially APIs for the QMP protocol& qdev ARGV format - Host level API - guest enumeration, integration with other OS services like cgroups, selinux, etc QEMU has historically only cared about the per-VM level, but has not actually provided any formal library APIs even for the monitor protocol or command line syntax. We also provide an API for guest creation (the qemu command line). When we create a guest, we don't integrate with things like cgroups and selinux and we probably never will. This is a place where libvirt adds value. The fundamental problem we have is that once you create a qemu instance, you cannot find it from a third party tool. That's a problem we ought to solve and I'd like to see that be common across qemu and libvirt. I don't see that as us growing our scope into libvirt's space. I think libvirt does two things. It provides a generic interface to hypervisors and if people write to this interface, they get better portability and the ability to management many platforms. It also provides a certain amount of host services management that can include things not directly related to qemu (like network management) and services that further connect qemu to host services (like selinux labelling). What I would like to see is that a user can write to the libvirt API and then call out to qemu specific functions when necessary. I'd also like a user be able to interact directly with qemu without using the libvirt generic API. The user should be able to still see the VMs and ultimately interact with them through libvirt. The user should be able to use libvirt to deal with host services too (like storage and network pools). The key is not to have two mutual exclusive management mechanisms but a set of complementary APIs. The biggest obstacle I see is libvirt's remote management interface. I think it's addressable though. For instance, if libqemu.so provided a QMP IO interface, libvirt-qemu could basically provide an interface to create that context and otherwise have users use the libqemu.so interfaces directly. IOW, libqemu.so would provide interfaces that looked like: QMPContext *qemu_connect_by_name(const char *name); int qemu_pci_add(QMPContext *ctxt, ...); And libvirt would provide interfaces that looked like: virQemuPtr *virDomainGetQemuPtr(virDomainPtr *ptr); QMPContext *virQemuCreateQMPContext(virQemuPtr *ptr); With respect to keep tracking of which operations are done through qemu, we should discuss the technical challenges of this and figure out how we can solve them. The libqmp.so& libqdev.so could then be used both directly against a single QEMU process spawned manually, but also indirectly via libvirt. That's not quite what I'm looking for because then it's really two separate interfaces. I'd rather see complementary interfaces much like how Cairo integrates with GTK/GDK or even how GDK integrates with X11. Regards, Anthony Liguori
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On 03/23/2010 01:00 PM, Avi Kivity wrote: On 03/23/2010 06:06 PM, Anthony Liguori wrote: I thought the monitor protocol *was* our API. If not, why not? It is. But our API is missing key components like guest enumeration. So the fundamental topic here is, do we introduce these missing components to allow people to build directly to our interface or do we make use of the functionality that libvirt already provides if they can plumb our API directly to users. Guest enumeration is another API. Over the kvm call I suggested a qemu concentrator that would keep track of all running qemus, and would hand out monitor connections to users. It can do the enumeration (likely using qmp). Libvirt could talk to that, like it does with other hypervisors. If you think about network management, it's the difference between having a central management server that you add physical machines to, verses having physical machines use an advertisement mechanism (like mDNS or SLP). The later mechanism scales better and tends to be more robust. For instance, it's very common for VNC servers to advertise themselves via mDNS and it's also common for VNC clients to support this. It requires no central server to keep track of VNC instances and generally provides much better usability. Regards, Anthony Liguori
[Qemu-devel] Re: [PATCH] Fix recent pxa270 serial breakage
Thanks, applied. I've checked that the other parts of the commit don't have the same problem. Sorry for the trouble. On 3/23/10, Lars Munch wrote: > > This fixes a copy/paste bug introduced in commit > 2d48377a8531de63ec1d0c4b9b1959dc4b78356c that pushed TARGET_WORDS_BIGENDIAN > dependency to board level. > > Signed-off-by: Lars Munch > --- > hw/pxa2xx.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/hw/pxa2xx.c b/hw/pxa2xx.c > index 4fafba2..4f9b95b 100644 > --- a/hw/pxa2xx.c > +++ b/hw/pxa2xx.c > @@ -2084,7 +2084,7 @@ PXA2xxState *pxa270_init(unsigned int sdram_size, > const char *revision) > #else > serial_mm_init(pxa270_serial[i].io_base, 2, > s->pic[pxa270_serial[i].irqn], 14857000/16, > - serial_hds[i], 1, 1); > + serial_hds[i], 1, 0); > #endif > else > break; > > -- > 1.7.0.2 > >
Re: [Qemu-devel] Supporting hypervisor specific APIs in libvirt
On 03/23/2010 12:57 PM, Avi Kivity wrote: On 03/22/2010 09:25 PM, Anthony Liguori wrote: Hi, I've mentioned this to a few folks already but I wanted to start a proper thread. We're struggling in qemu with usability and one area that concerns me is the disparity in features that are supported by qemu vs what's implemented in libvirt. This isn't necessarily libvirt's problem if it's mission is to provide a common hypervisor API that covers the most commonly used features. However, for qemu, we need an API that covers all of our features that people can develop against. The ultimate question we need to figure out is, should we encourage our users to always use libvirt or should we build our own API for people (and libvirt) to consume. I don't think it's necessarily a big technical challenge for libvirt to support qemu more completely. I think it amounts to introducing a series of virQemu APIs that implement qemu specific functions. Over time, qemu specific APIs can be deprecated in favour of more generic virDomain APIs. What's the feeling about this from the libvirt side of things? Is there interest in support hypervisor specific interfaces should we be looking to provide our own management interface for libvirt to consume? One option is to expose a qmp connection to the client. Of course that introduces a consistency problem (libvirt plugs in a card, user plugs it own, libvirt is confused). If the user promises to behave, it can work for stuff that's 100% orthogonal to libvirt. With GTK/GDK/Cairo/etc, the expectation is that users behave. For things like GDK, most people never break out to X11 unless they absolute have to. The Cairo API is nice enough though that GDK doesn't even attempt to introduce wrappers. If you muck with X11, accessing the same info with GDK might prove harmful. One problem is that this is libvirt version specific. For example, libvirt x doesn't support spice so we control that thorough qmp. But libvirt x+1 does support spice and now it gets confused about all the spice messages. That's only a problem if we only support a single QMP session. This is exactly why we need to support multiple QMP sessions (and do). Regards, Anthony Liguori
Re: [Qemu-devel] about subpage
On 3/23/10, Michael Qiu wrote: > Hi, > Can anyone tell me what subpage for in exec.c? It's there so that several devices can register MMIO ranges that happen to be in the same target physical page.
Re: [Qemu-devel] git head broken? (x86 softmmu w/o kvm)
Hi, On 03/23/2010 02:24 PM, Blue Swirl wrote: On 3/23/10, Aurelien Jarno wrote: On Tue, Mar 23, 2010 at 03:27:26AM +0100, Aurelien Jarno wrote: > On Mon, Mar 22, 2010 at 10:25:24PM +0100, Juergen Lock wrote: > > Hi! > > > > I just wanted to make another FreeBSD qemu git head snaphot port update, > > and found both i386-softmmu and x86_64-softmmu no longer boot, they seem > > to hang early in the bios before it prints anything, last tb seems to be > > this loop: > > > > A quick bisect revealed it has been broken by this patch: > I have just pushed a patch to fix the problem. Thanks, sorry for the trouble. It would be nice to send a series like this to the list first in the future to give people a heads up. It's a useful set of clean-ups but it's nice to give people a chance to provide input. Regards, Anthony Liguori
Re: [Qemu-devel] git head broken? (x86 softmmu w/o kvm)
On 3/23/10, Aurelien Jarno wrote: > On Tue, Mar 23, 2010 at 03:27:26AM +0100, Aurelien Jarno wrote: > > On Mon, Mar 22, 2010 at 10:25:24PM +0100, Juergen Lock wrote: > > > Hi! > > > > > > I just wanted to make another FreeBSD qemu git head snaphot port update, > > > and found both i386-softmmu and x86_64-softmmu no longer boot, they seem > > > to hang early in the bios before it prints anything, last tb seems to be > > > this loop: > > > > > > > A quick bisect revealed it has been broken by this patch: > > > > > I have just pushed a patch to fix the problem. Thanks, sorry for the trouble.
Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On Tue, Mar 23, 2010 at 08:00:21PM +0200, Avi Kivity wrote: > On 03/23/2010 06:06 PM, Anthony Liguori wrote: > >>I thought the monitor protocol *was* our API. If not, why not? > > > >It is. But our API is missing key components like guest enumeration. > >So the fundamental topic here is, do we introduce these missing > >components to allow people to build directly to our interface or do we > >make use of the functionality that libvirt already provides if they > >can plumb our API directly to users. > > > > Guest enumeration is another API. > > Over the kvm call I suggested a qemu concentrator that would keep track > of all running qemus, and would hand out monitor connections to users. > It can do the enumeration (likely using qmp). Libvirt could talk to > that, like it does with other hypervisors. The libvirt QEMU driver started out as a fairly simple "concentrator" not doing much beyond spawning QEMU with argv & issuing monitor commands. The host concentrator inevitably needs to be involved in the OS level integration with features such as cgroups, selinux/apparmounr, host NIC management, storage, iptables, etc. If you look at the daemons for Xen, VirtualBox, VMWare, that other libvirt drivers talk to, they all do far more than just enumeration of VMs. A QEMU concentrator may start out simple, but it will end up growing over time to re-implememt much, if not all, the stuff that libvirt already provides for QEMU in terms of host level APIs. If the core problem here is to provide app developers access to the full range of QEMU functionality, the re-implementing the entire of the libvirt QEMU driver is rather over the top way to achieve that. Regards, Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
[Qemu-devel] Re: [RFC] vhost-blk implementation
On Tue, Mar 23, 2010 at 10:57:33AM -0700, Badari Pulavarty wrote: > Michael S. Tsirkin wrote: >> On Mon, Mar 22, 2010 at 05:34:04PM -0700, Badari Pulavarty wrote: >> >>> Write Results: >>> == >>> >>> I see degraded IO performance when doing sequential IO write >>> tests with vhost-blk compared to virtio-blk. >>> >>> # time dd of=/dev/vda if=/dev/zero bs=2M oflag=direct >>> >>> I get ~110MB/sec with virtio-blk, but I get only ~60MB/sec with >>> vhost-blk. Wondering why ? >>> >> >> Try to look and number of interrupts and/or number of exits. >> > > I checked interrupts and IO exits - there is no major noticeable > difference between > vhost-blk and virtio-blk scenerios. >> It could also be that you are overrunning some queue. >> >> I don't see any exit mitigation strategy in your patch: >> when there are already lots of requests in a queue, it's usually >> a good idea to disable notifications and poll the >> queue as requests complete. That could help performance. >> > Do you mean poll eventfd for new requests instead of waiting for new > notifications ? > Where do you do that in vhost-net code ? vhost_disable_notify does this. > Unlike network socket, since we are dealing with a file, there is no > ->poll support for it. > So I can't poll for the data. And also, Issue I am having is on the > write() side. Not sure I understand. > I looked at it some more - I see 512K write requests on the > virtio-queue in both vhost-blk and virtio-blk cases. Both qemu or > vhost is doing synchronous writes to page cache (there is no write > batching in qemu that is affecting this case). I still puzzled on > why virtio-blk outperforms vhost-blk. > > Thanks, > Badari If you say the number of requests is the same, we are left with: - requests are smaller for some reason? - something is causing retries? -- MST
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On Tue, Mar 23, 2010 at 11:06:20AM -0500, Anthony Liguori wrote: > On 03/23/2010 10:57 AM, Paul Brook wrote: > >>>I think there is a serious divergence of approach there, instanciating > >>>API stating 'we are gonna deprecate them sooner or later' tell the > >>>application developper 'my time is more important than yours' and not > >>>really something I like to carry to the API users. > >>>The main goal of libvirt remains to provide APIs needed to unify the > >>>development of the virtualization layers. Having APIs which makes > >>>sense only for one or 2 virtualization engines is not a problem in > >>>itself, it just raises questions about the actual semantic of that API. > >>>If that semantic is sound, then I see no reason to not add it, really > >>>and we actually often do. > >>> > >>Yeah, but the problem we're facing is, I want there to be an API added > >>to the management layer as part of the feature commit in qemu. If there > >>has to be a discussion and decisions about how to model the API, it's > >>not going to be successful. > >> > >I thought the monitor protocol *was* our API. If not, why not? > > It is. But our API is missing key components like guest enumeration. > So the fundamental topic here is, do we introduce these missing > components to allow people to build directly to our interface or do we > make use of the functionality that libvirt already provides if they can > plumb our API directly to users. There's two levels of API here - VM level API - essentially APIs for the QMP protocol & qdev ARGV format - Host level API - guest enumeration, integration with other OS services like cgroups, selinux, etc QEMU has historically only cared about the per-VM level, but has not actually provided any formal library APIs even for the monitor protocol or command line syntax. libvirt has obviously focused on the host level APIs, and directly figured out the implicit VM level "API" that was exposed from QEMU. I think this is a good split to maintain, because when you get to the host level API you start interacting / integrating beyond just QEMU with OS services like cgroups, selinux, iptables, host networking, etc. QEMU might start with a simple daemon for enumerating VMsbut that's how libvirt's QEMU driver started off. Over time that "simple" demon would grow to end up doing all the things that libvirt currently does. This duplication of functionality doesn't seem like a good use of development resources to me. Now libvirt does not currently directly expose the two VM level APIs that QEMU has (qdev ARGV, and QMP protocol), which is where our feature timelag comes from. If we can figure out a way to expose those two, then there shouldn't be a need for QEMU to get into duplicate host-level APIs like enumeration. There could still be useful APIs that QEMU can expose those. For example, consider if QEMU provided - libqmp.so - API(s) for each monitor command that serialized to/from JSON format string - libqdev.so - API(s) for constructing qdev strings, that can then be used as ARGV values, or QMP parameter values. Next consider if libvirt provided a way to pass extra ARGV down to QEMU, and also provided a way to send/recv JSON commands/events. The libqmp.so & libqdev.so could then be used both directly against a single QEMU process spawned manually, but also indirectly via libvirt. eg, to use snapshots with libvirt, an app would use libqmp.so to generate a QMP command for snapshotting, send it to the VM via the libvirt API for monitor injection and get the response. The nice aspect of this is that libvirt is actually adding value to libqmp.so, because users would now have secure remote access to the QEMU monitor, tunnelled via libvirtd. It also avoids adding an arbitrary number of extra APIs to libvirt - we just need the API to send and recv JSON in libvirt, and libqmp.so can then be used ontop of that In ascii art you'd end up with two models Interacting with a single VM directly: Application -> libqmp.so/libqdev.so -> QEMU Interacting with many VMs via libvirt Application -> libvirt API > libvirtd > QEMU | ^ | | +> libqmp.so ---+ +> libqdev.so --+ So primarily an app would still use libvirt as the host level management API, but libqmp.so proxied via libvirt would also allow access to arbitrary extra features. This avoids the big overlap in functionality between libvirt & QEMU apis, which would occurr if QEMU started doing multiple VM mgmt too. Regards, Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
[Qemu-devel] [PATCH 2/3] QError: New QERR_MIGRATION_FAILED
Signed-off-by: Markus Armbruster
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 560e70d..05ea9de 100644
--- a/qerror.c
+++ b/qerror.c
@@ -141,6 +141,10 @@ static const QErrorStringTable qerror_table[] = {
.desc = "Using KVM without %(capability), %(feature) unavailable",
},
{
+.error_fmt = QERR_MIGRATION_FAILED,
+.desc = "Migration failed"
+},
+{
.error_fmt = QERR_MIGRATION_IN_PROGRESS,
.desc = "Migration already in progress"
},
diff --git a/qerror.h b/qerror.h
index ecc13e4..b0f909c 100644
--- a/qerror.h
+++ b/qerror.h
@@ -121,6 +121,9 @@ QError *qobject_to_qerror(const QObject *obj);
#define QERR_KVM_MISSING_CAP \
"{ 'class': 'KVMMissingCap', 'data': { 'capability': %s, 'feature': %s } }"
+#define QERR_MIGRATION_FAILED \
+"{ 'class': 'MigrationFailed', 'data': {} }"
+
#define QERR_MIGRATION_IN_PROGRESS \
"{ 'class': 'MigrationInProgress', 'data': {} }"
--
1.6.6.1
[Qemu-devel] [PATCH 3/3] monitor: Convert do_migrate() to QError
Human monitor error message changes from "unknown migration protocol:
FOO" to "Invalid parameter uri".
The conversion is shallow: the FOO_start_outgoing_migration() aren't
converted. Converting them is a big job for relatively little
practical benefit, so leave it for later.
Signed-off-by: Markus Armbruster
---
migration.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/migration.c b/migration.c
index 05f6cc5..47d2ab5 100644
--- a/migration.c
+++ b/migration.c
@@ -56,14 +56,14 @@ void qemu_start_incoming_migration(const char *uri)
int do_migrate(Monitor *mon, const QDict *qdict, QObject **ret_data)
{
-MigrationState *s = NULL;
+MigrationState *s;
const char *p;
int detach = qdict_get_int(qdict, "detach");
const char *uri = qdict_get_str(qdict, "uri");
if (current_migration &&
current_migration->get_status(current_migration) == MIG_STATE_ACTIVE) {
-monitor_printf(mon, "migration already in progress\n");
+qerror_report(QERR_MIGRATION_IN_PROGRESS);
return -1;
}
@@ -86,12 +86,13 @@ int do_migrate(Monitor *mon, const QDict *qdict, QObject
**ret_data)
(int)qdict_get_int(qdict, "inc"));
#endif
} else {
-monitor_printf(mon, "unknown migration protocol: %s\n", uri);
+qerror_report(QERR_INVALID_PARAMETER, "uri");
return -1;
}
if (s == NULL) {
-monitor_printf(mon, "migration failed\n");
+/* TODO push error reporting into the FOO_start_outgoing_migration() */
+qerror_report(QERR_MIGRATION_FAILED);
return -1;
}
--
1.6.6.1
[Qemu-devel] [PATCH 0/3] Convert do_migrate() to QError
Markus Armbruster (3): QError: New QERR_MIGRATION_IN_PROGRESS QError: New QERR_MIGRATION_FAILED monitor: Convert do_migrate() to QError migration.c |9 + qerror.c|8 qerror.h|6 ++ 3 files changed, 19 insertions(+), 4 deletions(-)
[Qemu-devel] [PATCH 1/3] QError: New QERR_MIGRATION_IN_PROGRESS
Signed-off-by: Markus Armbruster
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 8d885cd..560e70d 100644
--- a/qerror.c
+++ b/qerror.c
@@ -141,6 +141,10 @@ static const QErrorStringTable qerror_table[] = {
.desc = "Using KVM without %(capability), %(feature) unavailable",
},
{
+.error_fmt = QERR_MIGRATION_IN_PROGRESS,
+.desc = "Migration already in progress"
+},
+{
.error_fmt = QERR_MISSING_PARAMETER,
.desc = "Parameter '%(name)' is missing",
},
diff --git a/qerror.h b/qerror.h
index bae08c0..ecc13e4 100644
--- a/qerror.h
+++ b/qerror.h
@@ -121,6 +121,9 @@ QError *qobject_to_qerror(const QObject *obj);
#define QERR_KVM_MISSING_CAP \
"{ 'class': 'KVMMissingCap', 'data': { 'capability': %s, 'feature': %s } }"
+#define QERR_MIGRATION_IN_PROGRESS \
+"{ 'class': 'MigrationInProgress', 'data': {} }"
+
#define QERR_MISSING_PARAMETER \
"{ 'class': 'MissingParameter', 'data': { 'name': %s } }"
--
1.6.6.1
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On 03/23/2010 06:06 PM, Anthony Liguori wrote: I thought the monitor protocol *was* our API. If not, why not? It is. But our API is missing key components like guest enumeration. So the fundamental topic here is, do we introduce these missing components to allow people to build directly to our interface or do we make use of the functionality that libvirt already provides if they can plumb our API directly to users. Guest enumeration is another API. Over the kvm call I suggested a qemu concentrator that would keep track of all running qemus, and would hand out monitor connections to users. It can do the enumeration (likely using qmp). Libvirt could talk to that, like it does with other hypervisors. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
Re: [Qemu-devel] Supporting hypervisor specific APIs in libvirt
On 03/22/2010 09:25 PM, Anthony Liguori wrote: Hi, I've mentioned this to a few folks already but I wanted to start a proper thread. We're struggling in qemu with usability and one area that concerns me is the disparity in features that are supported by qemu vs what's implemented in libvirt. This isn't necessarily libvirt's problem if it's mission is to provide a common hypervisor API that covers the most commonly used features. However, for qemu, we need an API that covers all of our features that people can develop against. The ultimate question we need to figure out is, should we encourage our users to always use libvirt or should we build our own API for people (and libvirt) to consume. I don't think it's necessarily a big technical challenge for libvirt to support qemu more completely. I think it amounts to introducing a series of virQemu APIs that implement qemu specific functions. Over time, qemu specific APIs can be deprecated in favour of more generic virDomain APIs. What's the feeling about this from the libvirt side of things? Is there interest in support hypervisor specific interfaces should we be looking to provide our own management interface for libvirt to consume? One option is to expose a qmp connection to the client. Of course that introduces a consistency problem (libvirt plugs in a card, user plugs it own, libvirt is confused). If the user promises to behave, it can work for stuff that's 100% orthogonal to libvirt. One problem is that this is libvirt version specific. For example, libvirt x doesn't support spice so we control that thorough qmp. But libvirt x+1 does support spice and now it gets confused about all the spice messages. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
[Qemu-devel] Execute a char buffer without loading ELF
Hello, I am involved in a project that we use Qemu user mode for i386 (./i386-linux-user/qemu-i386). I want to modify the source code in such a way to make qemu execute a buffer of bytes (given from the comman line for example) rather than loading an ELF file and executing. I started looking at linux-user/linuxload.c loader_exec() function and linux-user/elfload.c load_elf_binary() function. Is there a way to bypass the loading of an ELF file and load a single buffer of bytes (that is i386 code) into memory and make Qemu start execution on it? Any help or comment is very very appreciated. Thanx in advance
[Qemu-devel] about subpage
Hi, Can anyone tell me what subpage for in exec.c? Best regards
Re: [Qemu-devel] Re: [PATCH 4/9] virtio-serial: Handle scatter-gather buffers for control messages
On Tue, Mar 23, 2010 at 09:45:08PM +0530, Amit Shah wrote:
> On (Tue) Mar 23 2010 [17:51:26], Michael S. Tsirkin wrote:
> > On Mon, Mar 22, 2010 at 10:48:02AM +0530, Amit Shah wrote:
> > > On (Sat) Mar 20 2010 [09:40:50], Avi Kivity wrote:
> > > > On 03/19/2010 01:58 PM, Amit Shah wrote:
> > > >> +
> > > >> +offset = 0;
> > > >> +for (i = 0; i< elem.out_num; i++) {
> > > >> +memcpy(buf + offset, elem.out_sg[i].iov_base,
> > > >> + elem.out_sg[i].iov_len);
> > > >> +offset += elem.out_sg[i].iov_len;
> > > >> +}
> > > >> +len = cur_len;
> > > >> +
> > > >> +handle_control_message(vser, buf, len);
> > > >> +virtqueue_push(vq,&elem, len);
> > > >> +}
> > > >> +if (len) {
> > > >> +qemu_free(buf);
> > > >> }
> > > >> virtio_notify(vdev, vq);
> > > >> }
> > > >
> > > > Isn't there some virtio function to linearize requests?
> > >
> > > I don't see one.
> >
> > virtio-net has iov_fill. Reuse it?
>
> Hm, yeah. Any ideas on how to share it? Put it in some common file?
>
> Just copying it seems good for now..
>
> Amit
Add iov.c
--
MST
[Qemu-devel] [PATCH] Fix recent pxa270 serial breakage
This fixes a copy/paste bug introduced in commit 2d48377a8531de63ec1d0c4b9b1959dc4b78356c that pushed TARGET_WORDS_BIGENDIAN dependency to board level. Signed-off-by: Lars Munch --- hw/pxa2xx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/pxa2xx.c b/hw/pxa2xx.c index 4fafba2..4f9b95b 100644 --- a/hw/pxa2xx.c +++ b/hw/pxa2xx.c @@ -2084,7 +2084,7 @@ PXA2xxState *pxa270_init(unsigned int sdram_size, const char *revision) #else serial_mm_init(pxa270_serial[i].io_base, 2, s->pic[pxa270_serial[i].irqn], 14857000/16, - serial_hds[i], 1, 1); + serial_hds[i], 1, 0); #endif else break; -- 1.7.0.2
Re: [Qemu-devel] Re: [PATCH 4/9] virtio-serial: Handle scatter-gather buffers for control messages
On (Tue) Mar 23 2010 [17:51:26], Michael S. Tsirkin wrote:
> On Mon, Mar 22, 2010 at 10:48:02AM +0530, Amit Shah wrote:
> > On (Sat) Mar 20 2010 [09:40:50], Avi Kivity wrote:
> > > On 03/19/2010 01:58 PM, Amit Shah wrote:
> > >> +
> > >> +offset = 0;
> > >> +for (i = 0; i< elem.out_num; i++) {
> > >> +memcpy(buf + offset, elem.out_sg[i].iov_base,
> > >> + elem.out_sg[i].iov_len);
> > >> +offset += elem.out_sg[i].iov_len;
> > >> +}
> > >> +len = cur_len;
> > >> +
> > >> +handle_control_message(vser, buf, len);
> > >> +virtqueue_push(vq,&elem, len);
> > >> +}
> > >> +if (len) {
> > >> +qemu_free(buf);
> > >> }
> > >> virtio_notify(vdev, vq);
> > >> }
> > >
> > > Isn't there some virtio function to linearize requests?
> >
> > I don't see one.
>
> virtio-net has iov_fill. Reuse it?
Hm, yeah. Any ideas on how to share it? Put it in some common file?
Just copying it seems good for now..
Amit
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
> > I think there is a serious divergence of approach there, instanciating > > API stating 'we are gonna deprecate them sooner or later' tell the > > application developper 'my time is more important than yours' and not > > really something I like to carry to the API users. > > The main goal of libvirt remains to provide APIs needed to unify the > > development of the virtualization layers. Having APIs which makes > > sense only for one or 2 virtualization engines is not a problem in > > itself, it just raises questions about the actual semantic of that API. > > If that semantic is sound, then I see no reason to not add it, really > > and we actually often do. > > Yeah, but the problem we're facing is, I want there to be an API added > to the management layer as part of the feature commit in qemu. If there > has to be a discussion and decisions about how to model the API, it's > not going to be successful. I thought the monitor protocol *was* our API. If not, why not? Paul
Re: [Qemu-devel] Re: [PATCH 4/9] virtio-serial: Handle scatter-gather buffers for control messages
On Mon, Mar 22, 2010 at 10:48:02AM +0530, Amit Shah wrote:
> On (Sat) Mar 20 2010 [09:40:50], Avi Kivity wrote:
> > On 03/19/2010 01:58 PM, Amit Shah wrote:
> >> +
> >> +offset = 0;
> >> +for (i = 0; i< elem.out_num; i++) {
> >> +memcpy(buf + offset, elem.out_sg[i].iov_base,
> >> + elem.out_sg[i].iov_len);
> >> +offset += elem.out_sg[i].iov_len;
> >> +}
> >> +len = cur_len;
> >> +
> >> +handle_control_message(vser, buf, len);
> >> +virtqueue_push(vq,&elem, len);
> >> +}
> >> +if (len) {
> >> +qemu_free(buf);
> >> }
> >> virtio_notify(vdev, vq);
> >> }
> >
> > Isn't there some virtio function to linearize requests?
>
> I don't see one.
>
> Amit
virtio-net has iov_fill. Reuse it?
--
MST
Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On 03/23/2010 10:57 AM, Paul Brook wrote: I think there is a serious divergence of approach there, instanciating API stating 'we are gonna deprecate them sooner or later' tell the application developper 'my time is more important than yours' and not really something I like to carry to the API users. The main goal of libvirt remains to provide APIs needed to unify the development of the virtualization layers. Having APIs which makes sense only for one or 2 virtualization engines is not a problem in itself, it just raises questions about the actual semantic of that API. If that semantic is sound, then I see no reason to not add it, really and we actually often do. Yeah, but the problem we're facing is, I want there to be an API added to the management layer as part of the feature commit in qemu. If there has to be a discussion and decisions about how to model the API, it's not going to be successful. I thought the monitor protocol *was* our API. If not, why not? It is. But our API is missing key components like guest enumeration. So the fundamental topic here is, do we introduce these missing components to allow people to build directly to our interface or do we make use of the functionality that libvirt already provides if they can plumb our API directly to users. Regards, Anthony Liguori Paul
[Qemu-devel] Re: [PATCH 9/9] virtio-serial: Handle scatter/gather input from the guest
On (Tue) Mar 23 2010 [20:00:19], Amit Shah wrote:
> @@ -369,16 +370,23 @@ static void handle_output(VirtIODevice *vdev, VirtQueue
> *vq)
> * with it. Just ignore the data in that case.
> */
> if (!port->info->have_data) {
> -ret = 0;
> goto next_buf;
> }
>
> -/* The guest always sends only one sg */
> -ret = port->info->have_data(port, elem.out_sg[0].iov_base,
> -elem.out_sg[0].iov_len);
> +for (i = 0; i < elem.out_num; i++) {
> +size_t ret;
> +
> +ret = port->info->have_data(port, elem.out_sg[0].iov_base,
> +elem.out_sg[0].iov_len);
> +if (ret < elem.out_sg[0].iov_len) {
> +/* We couldn't write the entire iov; stop processing now */
> +break;
We should increment len here if ret > 0.
I'll post a followup patch that does this.
> +}
> +len += ret;
> +}
>
> next_buf:
> -virtqueue_push(vq, &elem, ret);
> +virtqueue_push(vq, &elem, len);
> }
> virtio_notify(vdev, vq);
> }
> --
> 1.6.2.5
>
Amit
[Qemu-devel] KVM call minutes for Mar 23
migration (we didn't end last week) - monotonic increasing version doesn't capture individual features (backporting features may not require earlier features, now id is incorrect) - use subsections - can create new namespace within subsection (ide/$featre/$distro) - would need to coordinate section naming - documentation of on-wire migration protocol needed, can be there - rewind file (non-trivial) to update version to earlier id - send maximum always, not worrying about non-linear feature creep virtIODevice model (see Virtio cleaup thread). What is the best model for this? - multiple inheritance concern...far enough away, can handle on list, nothing pressing here state and roadmap for upstream merge of in-kernel device models - glauber has posted, received feedback, working through feedback, will respin and repost soon merging qemu-kvm.git's implementation as is and cleaning it up in qemu.git? - would need to drop features, so people will still use qemu-kvm - extboot, ia64, in-kernel pit, device assignment, associated cmd line options - the biggest blocking is glauber's smp/irq chip - kvmctl (ported to qemu now) could go into - agraf glad to help w/ device assignment - avi wants to move it to uio + irqfd (need uio iommu support and msi support) libqemu and libvirt - simple qmp wrapper would be enough - would drop the libvirt functionality (like hv agnostic) - separate issues... - 1) libqemu as a simple mgmt interface to qemu - 2) libvirt qemu-direct, libvirt users ability to get all qemu features - approaching from different ends of problem...could coexist. - out of time...next week, on list in the interim
[Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On 03/23/2010 09:51 AM, Daniel Veillard wrote: On Mon, Mar 22, 2010 at 02:25:00PM -0500, Anthony Liguori wrote: Hi, Hi Anthony, I've mentioned this to a few folks already but I wanted to start a proper thread. We're struggling in qemu with usability and one area that concerns me is the disparity in features that are supported by qemu vs what's implemented in libvirt. If you could come up with a list, then I would have an easier job answering, honnestly I have the feeling we spent the last 6 months filling that gap in a really fast way. qemu-doc.texi is a list of most of the command line features we support. The help output of the monitor shows what we support in that interface. It doesn't take a lot to read through it and see the things not supported by libvirt. libvirt supports a relatively small amount of our overall features (although a good chunk of the most common set). However, for qemu, we need an API that covers all of our features that people can develop against. The ultimate question we need to figure out is, should we encourage our users to always use libvirt or should we build our own API for people (and libvirt) to consume. I don't think it's necessarily a big technical challenge for libvirt to support qemu more completely. I think it amounts to introducing a series of virQemu APIs that implement qemu specific functions. Over time, qemu specific APIs can be deprecated in favour of more generic virDomain APIs. But one point of libvirt is that once an API is there we don't break it. I think there is a serious divergence of approach there, instanciating API stating 'we are gonna deprecate them sooner or later' tell the application developper 'my time is more important than yours' and not really something I like to carry to the API users. The main goal of libvirt remains to provide APIs needed to unify the development of the virtualization layers. Having APIs which makes sense only for one or 2 virtualization engines is not a problem in itself, it just raises questions about the actual semantic of that API. If that semantic is sound, then I see no reason to not add it, really and we actually often do. Yeah, but the problem we're facing is, I want there to be an API added to the management layer as part of the feature commit in qemu. If there has to be a discussion and decisions about how to model the API, it's not going to be successful. Supporting legacy APIs forever is not a viable option for a project like qemu. Things evolve quickly and we need a mechanism to deprecate APIs over time. What's the feeling about this from the libvirt side of things? Is there interest in support hypervisor specific interfaces should we be looking to provide our own management interface for libvirt to consume? The real question is what do you actually want to build. Any management application really. Even with something like virt-manager, there's a ton of useful features that qemu supports (like migration status reporting) that libvirt doesn't support. Most of the feedback I have seen in this thread so far are mostly request to be able to hack on a qemu instance launched via libvirt. It's not about the "hacker" use-case. It's about making sure that we've got 100% feature coverage in our management API. All of the management tools that focus on KVM have had this problem that I am aware of. We need to come up with a way that we can very easily plumb new qemu functions through the management interface. Regards, Anthony Liguori
[Qemu-devel] Re: [PATCH 0/9] v2: Fixes, new way of discovering ports
Amit Shah wrote: > Hello, > > These patches rework the way ports are announced to the guests. A > control message is used to let the guest know a new port is > added. Initial port discovery and port hot-plug work via this way now. > > This was done to have the host and guest port numbering in sync to > avoid surprises after several hotplug/unplug operations and > migrations. > > The ability to assign a particular port number to ports is also added > so that management software can control the placement of ports. > > The other patches to handle scatter/gather for guest data and > migration fixes remain the same. > > Please review. Acked-by: Juan Quintela it fixes the migration troubles/questions that I raised. From possible NULL dereference to checking maximum numbers of ports. Thanks, Juan.
[Qemu-devel] [PATCH 9/9] virtio-serial: Handle scatter/gather input from the guest
Current guests don't send more than one iov but it can change later.
Ensure we handle that case.
Signed-off-by: Amit Shah
CC: Avi Kivity
---
hw/virtio-serial-bus.c | 22 +++---
1 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index fe976ec..2ca3c0a 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -355,11 +355,12 @@ static void handle_output(VirtIODevice *vdev, VirtQueue
*vq)
while (virtqueue_pop(vq, &elem)) {
VirtIOSerialPort *port;
-size_t ret;
+size_t len;
+unsigned int i;
+len = 0;
port = find_port_by_vq(vser, vq);
if (!port) {
-ret = 0;
goto next_buf;
}
@@ -369,16 +370,23 @@ static void handle_output(VirtIODevice *vdev, VirtQueue
*vq)
* with it. Just ignore the data in that case.
*/
if (!port->info->have_data) {
-ret = 0;
goto next_buf;
}
-/* The guest always sends only one sg */
-ret = port->info->have_data(port, elem.out_sg[0].iov_base,
-elem.out_sg[0].iov_len);
+for (i = 0; i < elem.out_num; i++) {
+size_t ret;
+
+ret = port->info->have_data(port, elem.out_sg[0].iov_base,
+elem.out_sg[0].iov_len);
+if (ret < elem.out_sg[0].iov_len) {
+/* We couldn't write the entire iov; stop processing now */
+break;
+}
+len += ret;
+}
next_buf:
-virtqueue_push(vq, &elem, ret);
+virtqueue_push(vq, &elem, len);
}
virtio_notify(vdev, vq);
}
--
1.6.2.5
[Qemu-devel] [PATCH 8/9] virtio-serial: Handle scatter-gather buffers for control messages
Current control messages are small enough to not be split into multiple
buffers but we could run into such a situation in the future or a
malicious guest could cause such a situation.
So handle the entire iov request for control messages.
Also ensure the size of the control request is >= what we expect
otherwise we risk accessing memory that we don't own.
Signed-off-by: Amit Shah
CC: Avi Kivity
Reported-by: Avi Kivity
---
hw/virtio-serial-bus.c | 44 +---
1 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index 6d12c10..fe976ec 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -205,7 +205,7 @@ size_t virtio_serial_guest_ready(VirtIOSerialPort *port)
}
/* Guest wants to notify us of some event */
-static void handle_control_message(VirtIOSerial *vser, void *buf)
+static void handle_control_message(VirtIOSerial *vser, void *buf, size_t len)
{
struct VirtIOSerialPort *port;
struct virtio_console_control cpkt, *gcpkt;
@@ -214,6 +214,11 @@ static void handle_control_message(VirtIOSerial *vser,
void *buf)
gcpkt = buf;
+if (len < sizeof(cpkt)) {
+/* The guest sent an invalid control packet */
+return;
+}
+
cpkt.event = lduw_p(&gcpkt->event);
cpkt.value = lduw_p(&gcpkt->value);
@@ -297,12 +302,45 @@ static void control_out(VirtIODevice *vdev, VirtQueue *vq)
{
VirtQueueElement elem;
VirtIOSerial *vser;
+uint8_t *buf;
+size_t len;
vser = DO_UPCAST(VirtIOSerial, vdev, vdev);
+len = 0;
+buf = NULL;
while (virtqueue_pop(vq, &elem)) {
-handle_control_message(vser, elem.out_sg[0].iov_base);
-virtqueue_push(vq, &elem, elem.out_sg[0].iov_len);
+unsigned int i;
+size_t cur_len, offset;
+
+cur_len = 0;
+for (i = 0; i < elem.out_num; i++) {
+cur_len += elem.out_sg[i].iov_len;
+}
+/*
+ * Allocate a new buf only if we didn't have one previously or
+ * if the size of the buf differs
+ */
+if (cur_len != len) {
+if (len) {
+qemu_free(buf);
+}
+buf = qemu_malloc(cur_len);
+}
+
+offset = 0;
+for (i = 0; i < elem.out_num; i++) {
+memcpy(buf + offset, elem.out_sg[i].iov_base,
+ elem.out_sg[i].iov_len);
+offset += elem.out_sg[i].iov_len;
+}
+len = cur_len;
+
+handle_control_message(vser, buf, len);
+virtqueue_push(vq, &elem, len);
+}
+if (len) {
+qemu_free(buf);
}
virtio_notify(vdev, vq);
}
--
1.6.2.5
[Qemu-devel] [PATCH 7/9] virtio-serial-bus: Let the guest know of host connection changes after migration
If the host connection to a port is closed on the destination machine
after migration, when the connection was open on the source, the host
has to be informed of that.
Similar for a host connection open on the destination.
Signed-off-by: Amit Shah
---
hw/virtio-serial-bus.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index dd50f2d..6d12c10 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -408,6 +408,7 @@ static void virtio_serial_save(QEMUFile *f, void *opaque)
QTAILQ_FOREACH(port, &s->ports, next) {
qemu_put_be32s(f, &port->id);
qemu_put_byte(f, port->guest_connected);
+qemu_put_byte(f, port->host_connected);
}
}
@@ -461,11 +462,21 @@ static int virtio_serial_load(QEMUFile *f, void *opaque,
int version_id)
/* Items in struct VirtIOSerialPort */
for (i = 0; i < nr_active_ports; i++) {
uint32_t id;
+bool host_connected;
id = qemu_get_be32(f);
port = find_port_by_id(s, id);
port->guest_connected = qemu_get_byte(f);
+host_connected = qemu_get_byte(f);
+if (host_connected != port->host_connected) {
+/*
+ * We have to let the guest know of the host connection
+ * status change
+ */
+send_control_event(port, VIRTIO_CONSOLE_PORT_OPEN,
+ port->host_connected);
+}
}
return 0;
}
--
1.6.2.5
[Qemu-devel] [PATCH 6/9] virtio-serial-bus: Use control messages to notify guest of new ports
Allow the port 'id's to be set by a user on the command line. This is
needed by management apps that will want a stable port numbering scheme
for hot-plug/unplug and migration.
Since the port numbers are shared with the guest (to identify ports in
control messages), we just send a control message to the guest
indicating addition of new ports (hot-plug) or notifying the guest of
the available ports when the guest sends us a DEVICE_READY control
message.
Signed-off-by: Amit Shah
---
hw/virtio-console.c|2 +
hw/virtio-serial-bus.c | 182 +++-
hw/virtio-serial.h | 17 +++--
3 files changed, 130 insertions(+), 71 deletions(-)
diff --git a/hw/virtio-console.c b/hw/virtio-console.c
index e915491..6b8 100644
--- a/hw/virtio-console.c
+++ b/hw/virtio-console.c
@@ -99,6 +99,7 @@ static VirtIOSerialPortInfo virtconsole_info = {
.exit = virtconsole_exitfn,
.qdev.props = (Property[]) {
DEFINE_PROP_UINT8("is_console", VirtConsole, port.is_console, 1),
+DEFINE_PROP_UINT32("nr", VirtConsole, port.id, VIRTIO_CONSOLE_BAD_ID),
DEFINE_PROP_CHR("chardev", VirtConsole, chr),
DEFINE_PROP_STRING("name", VirtConsole, port.name),
DEFINE_PROP_END_OF_LIST(),
@@ -133,6 +134,7 @@ static VirtIOSerialPortInfo virtserialport_info = {
.init = virtserialport_initfn,
.exit = virtconsole_exitfn,
.qdev.props = (Property[]) {
+DEFINE_PROP_UINT32("nr", VirtConsole, port.id, VIRTIO_CONSOLE_BAD_ID),
DEFINE_PROP_CHR("chardev", VirtConsole, chr),
DEFINE_PROP_STRING("name", VirtConsole, port.name),
DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index e8eb5aa..dd50f2d 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -41,6 +41,10 @@ struct VirtIOSerial {
VirtIOSerialBus *bus;
QTAILQ_HEAD(, VirtIOSerialPort) ports;
+
+/* bitmap for identifying active ports */
+uint32_t *ports_map;
+
struct virtio_console_config config;
};
@@ -48,6 +52,10 @@ static VirtIOSerialPort *find_port_by_id(VirtIOSerial *vser,
uint32_t id)
{
VirtIOSerialPort *port;
+if (id == VIRTIO_CONSOLE_BAD_ID) {
+return NULL;
+}
+
QTAILQ_FOREACH(port, &vser->ports, next) {
if (port->id == id)
return port;
@@ -205,14 +213,25 @@ static void handle_control_message(VirtIOSerial *vser,
void *buf)
size_t buffer_len;
gcpkt = buf;
-port = find_port_by_id(vser, ldl_p(&gcpkt->id));
-if (!port)
-return;
cpkt.event = lduw_p(&gcpkt->event);
cpkt.value = lduw_p(&gcpkt->value);
+port = find_port_by_id(vser, ldl_p(&gcpkt->id));
+if (!port && cpkt.event != VIRTIO_CONSOLE_DEVICE_READY)
+return;
+
switch(cpkt.event) {
+case VIRTIO_CONSOLE_DEVICE_READY:
+/*
+ * The device is up, we can now tell the device about all the
+ * ports we have here.
+ */
+QTAILQ_FOREACH(port, &vser->ports, next) {
+send_control_event(port, VIRTIO_CONSOLE_PORT_ADD, 1);
+}
+break;
+
case VIRTIO_CONSOLE_PORT_READY:
/*
* Now that we know the guest asked for the port name, we're
@@ -367,13 +386,16 @@ static void virtio_serial_save(QEMUFile *f, void *opaque)
/* The config space */
qemu_put_be16s(f, &s->config.cols);
qemu_put_be16s(f, &s->config.rows);
-qemu_put_be32s(f, &s->config.nr_ports);
-/* Items in struct VirtIOSerial */
+qemu_put_be32s(f, &s->config.max_nr_ports);
+
+/* The ports map */
-qemu_put_be32s(f, &s->bus->max_nr_ports);
+qemu_put_buffer(f, (uint8_t *)s->ports_map,
+sizeof(uint32_t) * (s->config.max_nr_ports + 31) / 32);
+
+/* Ports */
-/* Do this because we might have hot-unplugged some ports */
nr_active_ports = 0;
QTAILQ_FOREACH(port, &s->ports, next)
nr_active_ports++;
@@ -384,11 +406,6 @@ static void virtio_serial_save(QEMUFile *f, void *opaque)
* Items in struct VirtIOSerialPort.
*/
QTAILQ_FOREACH(port, &s->ports, next) {
-/*
- * We put the port number because we may not have an active
- * port at id 0 that's reserved for a console port, or in case
- * of ports that might have gotten unplugged
- */
qemu_put_be32s(f, &port->id);
qemu_put_byte(f, port->guest_connected);
}
@@ -398,7 +415,8 @@ static int virtio_serial_load(QEMUFile *f, void *opaque,
int version_id)
{
VirtIOSerial *s = opaque;
VirtIOSerialPort *port;
-uint32_t max_nr_ports, nr_active_ports, nr_ports;
+size_t ports_map_size;
+uint32_t max_nr_ports, nr_active_ports, *ports_map;
unsigned int i;
if (version_id > 2) {
@@ -415,29 +433,28 @@ static int virtio_serial_load(QEMUFile *f, void *opaque,
int version_id)
/* The config space */
qemu_get_be16s(f, &s->con
[Qemu-devel] [PATCH 5/9] virtio-serial: save/load: Ensure we have hot-plugged ports instantiated
If some ports that were hot-plugged on the source are not available on
the destination, fail migration instead of trying to deref a NULL
pointer.
Signed-off-by: Amit Shah
Reported-by: Juan Quintela
---
hw/virtio-serial-bus.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index bf7899c..e8eb5aa 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -447,6 +447,13 @@ static int virtio_serial_load(QEMUFile *f, void *opaque,
int version_id)
id = qemu_get_be32(f);
port = find_port_by_id(s, id);
+if (!port) {
+/*
+ * The requested port was hot-plugged on the source but we
+ * don't have it
+ */
+return -EINVAL;
+}
port->guest_connected = qemu_get_byte(f);
}
--
1.6.2.5
[Qemu-devel] [PATCH 4/9] virtio-serial: Update copyright year to 2010
Signed-off-by: Amit Shah --- hw/virtio-console.c|2 +- hw/virtio-serial-bus.c |2 +- hw/virtio-serial.h |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/hw/virtio-console.c b/hw/virtio-console.c index bd44ec6..e915491 100644 --- a/hw/virtio-console.c +++ b/hw/virtio-console.c @@ -1,7 +1,7 @@ /* * Virtio Console and Generic Serial Port Devices * - * Copyright Red Hat, Inc. 2009 + * Copyright Red Hat, Inc. 2009, 2010 * * Authors: * Amit Shah diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c index 7e9df96..bf7899c 100644 --- a/hw/virtio-serial-bus.c +++ b/hw/virtio-serial-bus.c @@ -1,7 +1,7 @@ /* * A bus for connecting virtio serial and console ports * - * Copyright (C) 2009 Red Hat, Inc. + * Copyright (C) 2009, 2010 Red Hat, Inc. * * Author(s): * Amit Shah diff --git a/hw/virtio-serial.h b/hw/virtio-serial.h index f297b00..632d31b 100644 --- a/hw/virtio-serial.h +++ b/hw/virtio-serial.h @@ -2,7 +2,7 @@ * Virtio Serial / Console Support * * Copyright IBM, Corp. 2008 - * Copyright Red Hat, Inc. 2009 + * Copyright Red Hat, Inc. 2009, 2010 * * Authors: * Christian Ehrhardt -- 1.6.2.5
[Qemu-devel] [PATCH 3/9] virtio-serial: Remove redundant check for 0-sized write request
The check for a 0-sized write request to a guest port is not necessary;
the while loop below won't be executed in this case and all will be
fine.
Signed-off-by: Amit Shah
---
hw/virtio-serial-bus.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index f43d1fc..7e9df96 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -83,9 +83,6 @@ static size_t write_to_port(VirtIOSerialPort *port,
if (!virtio_queue_ready(vq)) {
return 0;
}
-if (!size) {
-return 0;
-}
while (offset < size) {
int i;
--
1.6.2.5
[Qemu-devel] [PATCH 2/9] virtio-serial-bus: save/load: Ensure nr_ports on src and dest are same.
The number of ports on the source as well as the destination machines
should match. If they don't, it means some ports that got hotplugged on
the source aren't instantiated on the destination. Or that ports that
were hot-unplugged on the source are created on the destination.
Signed-off-by: Amit Shah
Reported-by: Juan Quintela
---
hw/virtio-serial-bus.c | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index 36985a1..f43d1fc 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -401,7 +401,7 @@ static int virtio_serial_load(QEMUFile *f, void *opaque,
int version_id)
{
VirtIOSerial *s = opaque;
VirtIOSerialPort *port;
-uint32_t max_nr_ports, nr_active_ports;
+uint32_t max_nr_ports, nr_active_ports, nr_ports;
unsigned int i;
if (version_id > 2) {
@@ -418,7 +418,21 @@ static int virtio_serial_load(QEMUFile *f, void *opaque,
int version_id)
/* The config space */
qemu_get_be16s(f, &s->config.cols);
qemu_get_be16s(f, &s->config.rows);
-s->config.nr_ports = qemu_get_be32(f);
+nr_ports = qemu_get_be32(f);
+
+if (nr_ports != s->config.nr_ports) {
+/*
+ * Source hot-plugged/unplugged ports and we don't have all of
+ * them here.
+ *
+ * Note: This condition cannot check for all hotplug/unplug
+ * events: eg, if one port was hot-plugged and one was
+ * unplugged, the nr_ports remains the same but the port id's
+ * would have changed and we won't catch it here. A later
+ * check for !find_port_by_id() will confirm if this happened.
+ */
+return -EINVAL;
+}
/* Items in struct VirtIOSerial */
--
1.6.2.5
[Qemu-devel] [PATCH 1/9] virtio-serial-bus: save/load: Ensure target has enough ports
The target could be started with max_nr_ports for a virtio-serial device
lesser than what was available on the source machine. Fail the migration
in such a case.
Signed-off-by: Amit Shah
Reported-by: Juan Quintela
---
hw/virtio-serial-bus.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index 17c1ec1..36985a1 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -374,6 +374,8 @@ static void virtio_serial_save(QEMUFile *f, void *opaque)
/* Items in struct VirtIOSerial */
+qemu_put_be32s(f, &s->bus->max_nr_ports);
+
/* Do this because we might have hot-unplugged some ports */
nr_active_ports = 0;
QTAILQ_FOREACH(port, &s->ports, next)
@@ -399,7 +401,7 @@ static int virtio_serial_load(QEMUFile *f, void *opaque,
int version_id)
{
VirtIOSerial *s = opaque;
VirtIOSerialPort *port;
-uint32_t nr_active_ports;
+uint32_t max_nr_ports, nr_active_ports;
unsigned int i;
if (version_id > 2) {
@@ -420,6 +422,12 @@ static int virtio_serial_load(QEMUFile *f, void *opaque,
int version_id)
/* Items in struct VirtIOSerial */
+qemu_get_be32s(f, &max_nr_ports);
+if (max_nr_ports > s->bus->max_nr_ports) {
+/* Source could have more ports than us. Fail migration. */
+return -EINVAL;
+}
+
qemu_get_be32s(f, &nr_active_ports);
/* Items in struct VirtIOSerialPort */
--
1.6.2.5
[Qemu-devel] [PATCH 0/9] v2: Fixes, new way of discovering ports
Hello, These patches rework the way ports are announced to the guests. A control message is used to let the guest know a new port is added. Initial port discovery and port hot-plug work via this way now. This was done to have the host and guest port numbering in sync to avoid surprises after several hotplug/unplug operations and migrations. The ability to assign a particular port number to ports is also added so that management software can control the placement of ports. The other patches to handle scatter/gather for guest data and migration fixes remain the same. Please review. Amit Shah (9): virtio-serial-bus: save/load: Ensure target has enough ports virtio-serial-bus: save/load: Ensure nr_ports on src and dest are same. virtio-serial: Remove redundant check for 0-sized write request virtio-serial: Update copyright year to 2010 virtio-serial: save/load: Ensure we have hot-plugged ports instantiated virtio-serial-bus: Use control messages to notify guest of new ports virtio-serial-bus: Let the guest know of host connection changes after migration virtio-serial: Handle scatter-gather buffers for control messages virtio-serial: Handle scatter/gather input from the guest hw/virtio-console.c|4 +- hw/virtio-serial-bus.c | 245 +--- hw/virtio-serial.h | 19 ++-- 3 files changed, 205 insertions(+), 63 deletions(-)
[Qemu-devel] Re: hi, may I ask some help on the paravirtualization of KVM?
Hello, [any reason you dropped the CC list? CC'ing qemu-devel, where this is relevant.] On (Tue) Mar 23 2010 [21:46:28], Liang YANG wrote: > I check the 'lspci -v' result, only find RTL-8139 realtek ethernet. I > think the option model=virtio does't make effect. Then something is wrong. I get a virtio ethernet device using model=virtio. Which qemu version are you using? > Simultaneously, I have the a look at the code. The function pc_init1() > seem not change the network model as the option assigned. > > Do you ever meet this case? I've not seen this. > On Tue, Mar 23, 2010 at 9:08 PM, Amit Shah wrote: > > On (Sun) Mar 21 2010 [20:18:53], Liang YANG wrote: > >> I want to set up the virtio-net for the GuestOS on KVM. Following is my > >> steps: > >> > >> 1.Compile the kvm-88 and make, make install. > >> 2.Compile the GuestOS(redhat) with kernel version 2.6.27.45(with > >> virtio support). The required option are all selected. > >> o CONFIG_VIRTIO_PCI=y (Virtualization -> PCI driver for > >> virtio devices) > >> o CONFIG_VIRTIO_BALLOON=y (Virtualization -> Virtio balloon > >> driver) > >> o CONFIG_VIRTIO_BLK=y (Device Drivers -> Block -> Virtio block > >> driver) > >> o CONFIG_VIRTIO_NET=y (Device Drivers -> Network device > >> support -> Virtio network driver) > >> o CONFIG_VIRTIO=y (automatically selected) > >> o CONFIG_VIRTIO_RING=y (automatically selected) > >> 3.Then start up the GuestOS by such command: > >> x86_64-softmmu/qemu-system-x86_64 -m 1024 /root/redhat.img > >> -net nic,model=virtio -net tap,script=/etc/kvm/qemu-ifup > >> 4.Result is this: > >> * The Guest OS start up. > >> * But the network not, no eth-X device found. > >> * lsmod | grep virtio get none module about virtio > > > > Since you selected the virtio options as 'y', they are directly compiled > > into the kernel and hence you won't see the modules. > > > > Check your 'lspci -v' output. You should see the virtio device there. > > You can also try some usual things like 'ifconfig eth0 up', etc., to get > > the interface. > > > > Amit > > -- > > http://log.amitshah.net/ > > > > > > -- > BestRegards. > YangLiang > _ > Department of Computer Science . > School of Electronics Engineering & Computer Science . > _ Amit -- http://log.amitshah.net/
[Qemu-devel] Re: KVM call agenda for Mar 23
Juan Quintela wrote: > Chris Wright wrote: >> Please send in any agenda items you are interested in covering. >> >> Yes, usability is a valid topic esp. if you promise to come w/ GUI patches. > > - migration (we didn't end last week) I told last Tuesday that I will look at the latest vmstate changes This is a search of VMSTATE/qemu_get() of commits of this year. The Anthony/Avi? (I don't remember) of checking if feature was used _before_ sending it would have fixed all of them. Indeed the balloon statistics one. Problem is that if we go this route we need: - subsections (is the easy way to go), almost there - being able to change the version_id of the _current_ section. That is _not easy_ with current design (we can't rewind the file). That means that we need something like imprement vmstet_save() to a buffer, check the function there and push it from there. This still don't fixes all problems, because what do we do when we have two independent features and only one is needed? vmstate-foo: id = 4 vmstate-foo: id = 5 bar1 subsection (optional depending of this function) vmstate-foo: id = 6 bar1 subsection (optional depending of this function) bar2 subsection (optional depending of this other function) what do we do if bar2 is needed but bar1 is not needed? Other option is just sent: vmstate-foo: id = 4 bar1 subsection (optional depending of this function) bar2 subsection (optional depending of this other function) (same version id for the general one). As subsections would get a different id_section, that could even work on devices that don't know about this new sections, because they would find a ->section_id that they don't understand/don't expect there). What do you think? Later, Juan. commit ed487bb1d69040b9dac64a4fc076d8dd82b131d6 Author: Marcelo Tosatti Date: Thu Feb 11 18:19:44 2010 -0200 ide save/restore pio/atapi cmd transfer fields and io buffer Save/restore information necessary to continue in progress PIO/ATAPI CMD transfers. This includes the IO buffer. - we can test if lenght != 0 and not sent it in that case. no infrastructure to do it otherwise. commit 31827373f03b0ff1550d45ddef0ca1305a2ae70d Author: Jan Kiszka Date: Mon Dec 14 12:26:17 2009 +0100 kvm: x86: Use separate exception_injected CPUState field Marcelo correctly remarked that there are usage conflicts between QEMU core code and KVM /wrt exception_index. So spend a separate field and also save/restore it properly. Signed-off-by: Jan Kiszka Signed-off-by: Anthony Liguori - exception_index/injected, we "could" do same trick that for ide. commit 1a03675db146dfc760b3b48b3448075189f142cc Author: Glauber Costa Date: Thu Oct 22 10:26:56 2009 -0200 v2: properly save kvm system time msr registers - avi states that a test if the msr has ever used could be used here commit a0fb002c6462d21ceb9eac8c5772e469ec189374 Author: Jan Kiszka Date: Wed Nov 25 00:33:03 2009 +0100 kvm: x86: Add support for VCPU event states I guess no way around for this one. It could be disabled for non kvm users, but that is it. balloon statistics: commit 625a5befc2e3200b396594f002218d235e375da5 Author: Adam Litke Date: Tue Jan 26 14:17:35 2010 -0600 virtio: Add memory statistics reporting to the balloon driver In this case, I don't know what to do (notice that this bit has never been in stable and has been dropped from qemu.git), it was wrong form other reasons.
Re: [Qemu-devel] BeOS R5 boot failure
> It's a known bug but nobody knows or has time to apply a solution. > > Bochs had the same bug and corrected it about November 2009, maybe > checking their commit will make light to correct QEMU. Ok, I might have a look at it, thanks. > > It seems VirtualBox has the same issue. Older versions (ZETA) seem > > to > > work fine, but they have a totally different IDE subsystem. > > VirtualPC had the same fail also. > Zeta however is not an older version but a newer one. Yes I messed up, I meant newer of course. > Considering Zeta is a non-authorized hack, who knows what have they > changed. I do, I worked at yellowTAB for a while. :p ZETA switched to a customized version of the "IDE Replacement" stack from Thomas Kurschel at some point: http://bebits.com/app/2625 This whole FUD about ZETA not being legal has nothing to do in here. Besides, if PalmSource/Palm/ACCESS loose documents in their cupboards it's not my fault. François.
Re: [Qemu-devel] Re: KVM call agenda for Mar 23
On 03/23/10 13:45, Anthony Liguori wrote: I don't think we can pull in: - extboot - ia64 - in-kernel pit[1] - associated command line options - device passthrough The question is, if we dropped those things, would people actually use qemu.git instead of qemu-kvm.git. If the answer is "no", what set of things do we need in order for people to focus on qemu.git instead of qemu-kvm.git. I am not sure if anyone is still actively working on ia64. According to the qemu-kvm.git logs, there hasn't been any real ia64 changes to the code since my last commit in June of last year and then a couple of minor configure bits. IMHO we can just let it rot - not sure if Xiantao is still interested? Cheers, Jes
Re: [Qemu-devel] BeOS R5 boot failure
El 23/03/2010, a las 10:07, François Revol escribió: I've been trying for some time to get an old BeOS R5 image to boot, but it seems it doesn't like QEMU's IDE controller: Trying /dev/disk/ide/ata/0/master/0/raw IDE PCI -- find_devices: intel 82371SB (PIIX3) chipset IDE PCI -- find_devices: controller supports DMA IDE ATA -- configure_device: selected dma mode bad, disable dma for this device IDE ATA -- get_bios_driveinfo: ata/0/0 match bios drive 0x80 found boot device: /dev/disk/ide/ata/0/master/0/raw IDE PCI -- find_devices: intel 82371SB (PIIX3) chipset IDE PCI -- find_devices: controller supports DMA IDE ATA -- configure_device: selected dma mode bad, disable dma for this device IDE ATA -- get_bios_driveinfo: ata/0/0 match bios drive 0x80 IDE PCI -- find_devices: intel 82371SB (PIIX3) chipset IDE PCI -- find_devices: controller supports DMA IDE ATA -- configure_device: selected dma mode bad, disable dma for this device IDE ATA -- get_bios_driveinfo: ata/0/0 match bios drive 0x80 warning: fs blocks fa000 larger than device blocks 0 bad super block KERNEL PANIC: was unable to mount /dev/disk/ide/ata/0/master/0/0_0 type bfs on /boot Anyone has a clue ? It's a known bug but nobody knows or has time to apply a solution. Bochs had the same bug and corrected it about November 2009, maybe checking their commit will make light to correct QEMU. It seems VirtualBox has the same issue. Older versions (ZETA) seem to work fine, but they have a totally different IDE subsystem. VirtualPC had the same fail also. Zeta however is not an older version but a newer one. Considering Zeta is a non-authorized hack, who knows what have they changed. The bug is present on BeOS R3, R4, R4.5 and R5. The warning suggest the block device is seen as having a size of 0, though oddly it seems to be able to read from it since it gets the size of the BFS in the superblock... I've rebuilt with DEBUG_IDE and put a log here: http://revolf.free.fr/beos/qemu-beosr5-bad-ide-20100323.log Note disabling DMA in the boot menu (space bar, Select safe mode options) doesn't help either... Use F1 at boot to get serial output. The image is available here: http://bebits.com/app/2680 (BeOS R5 Personal Edition for Linux) François.
[Qemu-devel] Re: KVM call agenda for Mar 23
On 03/23/2010 02:45 PM, Anthony Liguori wrote: On 03/23/2010 04:52 AM, Avi Kivity wrote: On 03/23/2010 11:31 AM, Jan Kiszka wrote: Chris Wright wrote: Please send in any agenda items you are interested in covering. Yes, usability is a valid topic esp. if you promise to come w/ GUI patches. - state and roadmap for upstream merge of in-kernel device models (looks to me like this central merge effort is stalled ATM) - alternative path of merging qemu-kvm.git's implementation as is and cleaning it up in qemu.git. For kvm.git, I wouldn't dream of merging something with outstanding issues and cleaning them up "later", but the situation is somewhat different with qemu vs qemu-kvm. I don't think we can pull in: - extboot - ia64 - in-kernel pit[1] - associated command line options - device passthrough I'm not proposing these for merge, except [1]. The question is, if we dropped those things, would people actually use qemu.git instead of qemu-kvm.git. If the answer is "no", what set of things do we need in order for people to focus on qemu.git instead of qemu-kvm.git. Device passthrough is sufficiently obscure that most people could use qemu.git (not distributions, though). ia64 is dead. Command line options would need to be cleaned up. We'd need an extboot replacement, people do boot from virtio. [1] I'd like to revisit this discussion. We originally went the in-kernel pit route because of difficulties changing qemu. That's a bad reason to put something in the kernel. I'd prefer to see us fix qemu. After that, we can look at in-kernel pit and see if there are any remaining advantages (like performance). If it's significant, we can still merge in-kernel pit. The reason was drift compensation IIRC. Also, some guests read the time back from the PIT. Perhaps that's no longer the case with hpet enabled by default. Drift compensation can be done in qemu by exposing ack notifiers to userspace; that's also needed for rtc drift compensation for Windows. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: KVM call agenda for Mar 23
On 03/23/2010 04:52 AM, Avi Kivity wrote: On 03/23/2010 11:31 AM, Jan Kiszka wrote: Chris Wright wrote: Please send in any agenda items you are interested in covering. Yes, usability is a valid topic esp. if you promise to come w/ GUI patches. - state and roadmap for upstream merge of in-kernel device models (looks to me like this central merge effort is stalled ATM) - alternative path of merging qemu-kvm.git's implementation as is and cleaning it up in qemu.git. For kvm.git, I wouldn't dream of merging something with outstanding issues and cleaning them up "later", but the situation is somewhat different with qemu vs qemu-kvm. I don't think we can pull in: - extboot - ia64 - in-kernel pit[1] - associated command line options - device passthrough The question is, if we dropped those things, would people actually use qemu.git instead of qemu-kvm.git. If the answer is "no", what set of things do we need in order for people to focus on qemu.git instead of qemu-kvm.git. [1] I'd like to revisit this discussion. We originally went the in-kernel pit route because of difficulties changing qemu. That's a bad reason to put something in the kernel. I'd prefer to see us fix qemu. After that, we can look at in-kernel pit and see if there are any remaining advantages (like performance). If it's significant, we can still merge in-kernel pit. Regards, Anthony Liguori
[Qemu-devel] Re: [RFC] vhost-blk implementation
On Mon, Mar 22, 2010 at 05:34:04PM -0700, Badari Pulavarty wrote: > Write Results: > == > > I see degraded IO performance when doing sequential IO write > tests with vhost-blk compared to virtio-blk. > > # time dd of=/dev/vda if=/dev/zero bs=2M oflag=direct > > I get ~110MB/sec with virtio-blk, but I get only ~60MB/sec with > vhost-blk. Wondering why ? Try to look and number of interrupts and/or number of exits. It could also be that you are overrunning some queue. I don't see any exit mitigation strategy in your patch: when there are already lots of requests in a queue, it's usually a good idea to disable notifications and poll the queue as requests complete. That could help performance. -- MST
[Qemu-devel] Re: KVM call agenda for Mar 23
On 03/23/2010 01:11 AM, Chris Wright wrote: Please send in any agenda items you are interested in covering. Yes, usability is a valid topic esp. if you promise to come w/ GUI patches. I can't make today's call. I'd hoping there's a discussion about libqemu and libvirt though and that someone sends out notes afterwards :-) Regards, Anthony Liguori thanks, -chris -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Qemu-devel] Re: [PATCH 0/9] Virtio cleanups
"Michael S. Tsirkin" wrote:
> On Tue, Mar 23, 2010 at 11:40:46AM +, Paul Brook wrote:
>> > > Right. The only real challenge is dealing with legacy save/restore and
>> > > command line syntax. For save/restore, we can possibly have a dummy
>> > > device that can split the VirtioPCI device state from the virtio device
>> > > states and do the right thing.
>> > >
>> > > I'm not sure what we should do for command line syntax. We can keep
>> > > -drive working as is. Do we need to support -device based creation? I
>> > > don't think we've really considered what to do in a situation like this.
>> >
>> > If we need to change command line because of an implementation
>> > change, IMO something is wrong with the design.
>> > Users shouldn't care about non-existent virtio bus.
>>
>> I don't find this argument convincing. If we need to change the
>> internal structure of a machine, then users who manipulate the machine
>> configuration are going to have to compensate for this.
>> This kind of change is pretty much unavoidable when we get the device
>> model wrong.
>
> I am yet to see why the model is wrong. virtio devices
> on pci bus and on s390 bus are different virtual hardware
> devices. There's no emulated bus.
Look the other way around. You don't want to see :(
> This is not much different from e100 - it can emulate tens
> of device variants - e100 bus?
it is. very different. All e100 implementation is in eepro100.c. And
all hangs from the PCI bus -> where to put PCIDevice (or DeviceState if
your preffer is trivial) -> in PCIDevice.
In this case you want to:
- share virtio bits between virtio devices
- share virtio-pci bits between virtio-pci devices
- implement each virtio-device in a different file
Fix is trivial if you are ok with the e100 example. Just concatenate
all virtio* files in a single one. Force all virtio-pci to know about
virtio-sysborg and virtio-s390. And the rest of things. And you are
done.
And no, for more that you complain that qemu model is wrong, that it
should allow multiple inheritance, it would not appear from nowhere.
support is not there at this point -> virtio devices use a hack to
simulate it.
> Anyway, people really want to share implementation and
> want to do this by means of a bus, ok, but there is nothing here
> that users care about.
Here we agree. I haven't think about the vmstate changes because I
don't have still so clear how our system would look.
> And if we let implermentation leak out to command line, we will have
> compat problems down the line.
Problem here was the model=virtio vs model=virtio-{net,blk,...} that
gerd showed. I don't know if there is a way to hack qdev to allow this
sharing of a single name.
>> The best we can realistically do is avoid making these
>> changes on a stable branch, and arrange for outdated configs to be
>> rejected rather than silently doing the wrong thing.
>>
>> Paul
>
> Practically speaking, we are bound to change internal representation in
> the future, and breaking scripts, management tools, documentation and
> simple user habits with each such change would be very bad.
Here we are (again), back at square 0.
Current implementation is hackish, every "cleaner" alternative is not
backward compatible. And to make it backward compatible, we need to add
(at least) as much hackinesh as current implementation.
Later, Juan.
[Qemu-devel] Re: KVM call agenda for Mar 23
On 03/23/2010 01:13 PM, Jan Kiszka wrote: The benefit would be that qemu-kvm.git would become a staging tree instead of the master repository for kvm users. As an example, we wouldn't have any bisectability problems. kvm features would need to be written just once. The last item would imply throwing away what qemu.git already cleaned up - or finally convert the rest. There is no lazy path. The code would remain but be disabled (#ifdef KVM_UPSTREAM) (just as with qemu-kvm.git). The only difference is qemu.git would be usable for kvm users. I'd prefer it if the cleanup happened out-of-tree and quickly. We are more than half-way through this, so let's focus efforts for the last bits that make the difference widely negligible. This investment should pay off rather quickly. If we merge now, we merge the half-completed effort so we don't lose anything. However, if we can complete the merge quickly, I'm all for it. I don't want to introduce the ugliness into qemu.git any more than you do. One issue of merging blindly is the command line option zoo of qemu-kvm. I don't think we want this upstream first and then deprecate it quickly again. Good point. Note, the above discussion ignores extboot and device assignment, but let's focus on the thorny bits first. I don't think extboot will make it upstream anymore, now that there is an effort for a gpxe-based virtio boot loader. Sure, an equivalent is fine. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Trying to build an Ubuntu-x64-guest on Windows-XP-x86-Host on x86-PC failed
Hi, I read, that it´s possible, to emulate an x64-Processor with QEMU on an x86-based PC, isn´t it. When I run the installation of Ubuntu-9.10-x64 under Qemu-Manager 6.0 under Windows-XP, I always get an storage-error. Who can help me, to solve that problem? With best regards, Christoph Funda _ autocreated E-Mail Appendix / automatisch erzeugter E-Mail Anhang Christoph Funda Diehl BGT Defence GmbH & Co. KG Fischbachstrasse 16 90552 Roethenbach a d Pegnitz http://www.diehl-bgt-defence.de Telefon: +49 911 957 2134 Telefax: +49 911 957 2710 mailto:christoph.fu...@diehl-bgt-defence.de _ Diehl BGT Defence GmbH & Co. KG Sitz der Gesellschaft: Ueberlingen - Amtsgericht Freiburg i. Br. HRA 581075 Persoenlich haftende Gesellschafterin: Diehl BGT Defence Verwaltungs-GmbH Sitz der Gesellschaft: Ueberlingen - Amtsgericht Freiburg i. Br. HRB 581694 Geschaeftsfuehrer: Dipl.-Ing. (FH) Peter Ibbeken (Sprecher), Dipl.-Betrw. (BA) Thomas Bodenmueller _
[Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
"Daniel P. Berrange" wrote: > On Tue, Mar 23, 2010 at 11:50:57AM +0100, Juan Quintela wrote: >> Gerd Hoffmann wrote: >> >> - networking: man, setting networking is a mess, libvirt just does it >> >>for you. >> > >> > +1 >> > >> > Even when not using libvirt for a reason or another I usually hook my >> > virtual machines into virbr0 (libvirt default network). >> >> This is a war for another day :-) >> >> I have that very same setup on my laptop. But I already use dnsmasq for >> other reasons -> no way to share dnsmasq with libvirt, libvirt want to >> use a different one -> have to configure two things, especially if I >> want specific names (in my dnsmasq setup already) for some of my guests. > > FYI, the dnsmasq maintainer has actually volunteered todo some enhancements > to dnsmasq to allow a prexisting instance of dnsmasq to play nicely with > libvirt's needs. This should pretty much solve that problem Great! /me reserves beer for him. Once there, making it to play well with selinux + dbus will make it just perfect :-) (I haven't checked if this worked in the last year, so ...) Later, Juan.
Re: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups
On Tue, Mar 23, 2010 at 11:40:46AM +, Paul Brook wrote: > > > Right. The only real challenge is dealing with legacy save/restore and > > > command line syntax. For save/restore, we can possibly have a dummy > > > device that can split the VirtioPCI device state from the virtio device > > > states and do the right thing. > > > > > > I'm not sure what we should do for command line syntax. We can keep > > > -drive working as is. Do we need to support -device based creation? I > > > don't think we've really considered what to do in a situation like this. > > > > If we need to change command line because of an implementation > > change, IMO something is wrong with the design. > > Users shouldn't care about non-existent virtio bus. > > I don't find this argument convincing. If we need to change the > internal structure of a machine, then users who manipulate the machine > configuration are going to have to compensate for this. > This kind of change is pretty much unavoidable when we get the device > model wrong. I am yet to see why the model is wrong. virtio devices on pci bus and on s390 bus are different virtual hardware devices. There's no emulated bus. This is not much different from e100 - it can emulate tens of device variants - e100 bus? Anyway, people really want to share implementation and want to do this by means of a bus, ok, but there is nothing here that users care about. And if we let implermentation leak out to command line, we will have compat problems down the line. > The best we can realistically do is avoid making these > changes on a stable branch, and arrange for outdated configs to be > rejected rather than silently doing the wrong thing. > > Paul Practically speaking, we are bound to change internal representation in the future, and breaking scripts, management tools, documentation and simple user habits with each such change would be very bad. -- MST
Re: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups
> > Right. The only real challenge is dealing with legacy save/restore and > > command line syntax. For save/restore, we can possibly have a dummy > > device that can split the VirtioPCI device state from the virtio device > > states and do the right thing. > > > > I'm not sure what we should do for command line syntax. We can keep > > -drive working as is. Do we need to support -device based creation? I > > don't think we've really considered what to do in a situation like this. > > If we need to change command line because of an implementation > change, IMO something is wrong with the design. > Users shouldn't care about non-existent virtio bus. I don't find this argument convincing. If we need to change the internal structure of a machine, then users who manipulate the machine configuration are going to have to compensate for this. This kind of change is pretty much unavoidable when we get the device model wrong. The best we can realistically do is avoid making these changes on a stable branch, and arrange for outdated configs to be rejected rather than silently doing the wrong thing. Paul
[Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt
On Mon, Mar 22, 2010 at 04:49:21PM -0500, Anthony Liguori wrote: > On 03/22/2010 03:10 PM, Daniel P. Berrange wrote: > >>This isn't necessarily libvirt's problem if it's mission is to provide a > >>common hypervisor API that covers the most commonly used features. > >> > >That is more or less our current mission. If this mission leads to QEMU > >creating a non-libvirt based API& telling people to use that instead, > >then I'd say libvirt's mission needs to change to avoid that scenario ! > >I strongly believe that libvirt's strategy is good for application > >developers over the medium to long term. We need to figure out how to > >get rid of the short term pain from the feature timelag, rather than > >inventing a new library API for them to use. > > > > Well that's certainly a good thing :-) > > >>However, for qemu, we need an API that covers all of our features that > >>people can develop against. The ultimate question we need to figure out > >>is, should we encourage our users to always use libvirt or should we > >>build our own API for people (and libvirt) to consume. > >> > >>I don't think it's necessarily a big technical challenge for libvirt to > >>support qemu more completely. I think it amounts to introducing a > >>series of virQemu APIs that implement qemu specific functions. Over > >>time, qemu specific APIs can be deprecated in favour of more generic > >>virDomain APIs. > >> > >Stepping back a bit first, there are the two core areas in which people can > >be limited by libvirt currently. > > > > 1. Monitor commands > > 2. Command line flags > > > >Ultimately, IIUC, you are suggesting we need to allow arbitrary passthrough > >for both of these in libvirt. > > > >At the libvirt level, we have 3 core requirements > > > > 1. The XML format is extend only (new elements allowed, or add attributes > > or children to existing elements) > > 2. The C library API is append only (new symbols only) > > 3. The RPC wire protocol is append only (maps 1-1 to the C API generally) > > > > We have a slightly different mentality within QEMU I think. Here's > roughly how I'd characterize our guarantees. > > 1. For any two versions of QEMU, we try to guarantee that the same VM, > as far as the guest sees it, can be created. > 2. We tend to avoid changing command line syntax unless the syntax was > previously undefined. > 3. QMP supports enumeration and feature negotiation. This enables a > client to discover which functions are supported. > 4. We try to maintain monitor interfaces but provide no guarantees of > compatibility. > > >The core question for us as libvirt developers is how we could support > >QEMU specific features that may change arbitrarily, without it impacting > >on our ability to maintain these 3 requirements for the non-hypervisor > >specific APIs. > > > >We don't ever want to be in a situation where a QEMU specific API will > >require us to change the soname of the main libvirt library, or introduce > >incompatible wire protocol changes. If we were to introduce QEMU specific > >APIs, we also need a way to easily remove those over time, as& when we > >have them available as generic APIs. > > > >At the C API level, this to me suggests that we'd want to introduce a > >separate libvirt-qemu.so library for the QEMU specific APIs. This > >library would not have the same requirements of fixed long term ABI > >that the main libvirt.so did. We'd add QEMU APIs to libvirt-qemu.so > >any time needed, but remove them when the equivalent functionality > >were in libvirt.so, and increment the soname of libvirt-qemu.so at > >that point. > > > > How different is having a libvirt-qemu.so from having a libqemu.so that > libvirt.so uses? > > Practically speaking, if libvirt-qemu.so uses a separate XML namespace, > does the fact that we use a different config format matter since you can > transform our config format to XML and vice versa? If an application used libqemu.so directly, they would be excluding themselves from much of the libvirt ecosystem which would otherwise be beneficial to their needs. For example, with libvirt-qemu.so, you could still use libvirt's secure remote API access, all the authentication & authorization capabilities on the API. It could also be intergrated into the other libvirt language bindings, and mapping layers such as libvirt-CIM, libvirt-qpid, etc. Applications may still also want the benefit of the libvirt hypervisor-agnostic APIs, for example, virt-manager wants to use libvirt.so primary so it can support QEMU, Xen, VMWare etc, but it might also want to access qemu specific features via libvirt-qemu.so It could not use libqemu.so because it would not be accessible via the libvirt remote RPC layer. > I think the problem is, if libvirt.so introduces a common API, removing > it from libvirt-qemu.so is burdensome to an end-user. For someone > designing a QEMU specific management application, why should they have > to update their
