Re: [Qemu-devel] Still build failure for qemu-1.0

[Aneesh Kumar K.V]

On Fri, 02 Dec 2011 14:22:03 +0100, erik.r...@rdsoftware.de wrote:
> Hi all,
> 
> there was the promise to test the build failure from rc4 with the released
> version and that it should work.
> 
> Its still present :-( please assist me here:
> 
>   CClibhw64/9pfs/coxattr.o
>   CClibhw64/9pfs/virtio-9p-handle.o
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c: In function
> 'handle_update_file_cred':
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:95: warning: implicit
> declaration of function 'openat'
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:95: warning: nested extern
> declaration of 'openat'
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:103: warning: implicit
> declaration of function 'fchownat'
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:103: warning: nested extern
> declaration of 'fchownat'
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c: In function 'handle_lstat':
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:120: warning: implicit
> declaration of function 'fstatat'
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:120: warning: nested extern
> declaration of 'fstatat'
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c: In function 'handle_readlink':
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:135: warning: implicit
> declaration of function 'readlinkat'
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:135: warning: nested extern
> declaration of 'readlinkat'
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c: In function 'handle_opendir':
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:167: warning: implicit
> declaration of function 'fdopendir'
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:167: warning: nested extern
> declaration of 'fdopendir'
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:167: warning: assignment
> makes pointer from integer without a cast
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c: In function 'handle_mknod':
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:265: warning: implicit
> declaration of function 'mknodat'
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:265: warning: nested extern
> declaration of 'mknodat'
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c: In function 'handle_mkdir':
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:283: warning: implicit
> declaration of function 'mkdirat'
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:283: warning: nested extern
> declaration of 'mkdirat'
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c: In function 'handle_symlink':
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:333: warning: implicit
> declaration of function 'symlinkat'
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:333: warning: nested extern
> declaration of 'symlinkat'
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c: In function 'handle_link':
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:363: warning: implicit
> declaration of function 'linkat'
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:363: warning: nested extern
> declaration of 'linkat'
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c: In function 'handle_renameat':
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:570: warning: implicit
> declaration of function 'renameat'
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:570: warning: nested extern
> declaration of 'renameat'
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c: In function 'handle_unlinkat':
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:593: warning: implicit
> declaration of function 'unlinkat'
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:593: warning: nested extern
> declaration of 'unlinkat'
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c: In function
> 'handle_ioc_getversion':
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:616: error:
> 'FS_IOC_GETVERSION' undeclared (first use in this function)
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:616: error: (Each undeclared
> identifier is reported only once
> /home/erik/qemu-1.0/hw/9pfs/virtio-9p-handle.c:616: error: for each
> function it appears in.)
> make[2]: *** [9pfs/virtio-9p-handle.o] Error 1
> make[1]: *** [subdir-libhw64] Error 2
> make[1]: Leaving directory `/home/erik/qemu-1.0'

Can you try the below patch ?

>From 08397638951fd3c131a6145c849f0a218aa52347 Mon Sep 17 00:00:00 2001
From: "Aneesh Kumar K.V" 
Date: Tue, 29 Nov 2011 15:10:52 +0530
Subject: [PATCH] hw/9pfs: Improve portability to older systems

handle fs driver require a set of newly added syscalls. Don't
Compile handle FS driver if those syscalls are not available.
Instead of adding #ifdef for all those syscalls we check for
open by handle syscall. If that is available then rest of the
syscalls used by the driver should be available.

Signed-off-by: Aneesh Kumar K.V 
---
 Makefile.objs  |4 ++--
 fsdev/qemu-fsdev.c |2 ++
 hw/9pfs/virtio-9p-handle.c |   33 -
 3 files changed, 4 insertions(+), 35 deletions(-)

diff --git a/Makefile.objs b/Makefile.objs
index d7a6539..3a699ee 100644
--- a/Make

Re: [Qemu-devel] Improve QEMU performance with LLVM codegen and other techniques

[陳韋任]

> > 3. Then a trace composed of TCG blocks is sent to a LLVM translator. The 
> > translator
> >   generates the host binary for the trace into a LLVM code cache, and patch 
> > the
> 
> I don't fully understand this part. Do you disassemble the x86 blob that TCG 
> emitted?

  We ask TCG to disassemble the guest binary where the trace beginning with
_again_ to get a set of TCG blocks, then sent them to the LLVM translator.
 
> > the moment (make the situation simpler), I think we still don't have to 
> > check
> > the blocks' hflags and segment descriptors in the trace to see if they 
> > match.
> 
> Yeah. You only need to be sync'ed with the invalidation then. And make sure 
> you patch the TB atomically, so you don't have a separate thread accidentally 
> run half your code and half the old code.

  Sync'ed with the invalidation means tb_flush, cpu_unlink and 
tb_phys_invalidate?
 
Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj

Re: [Qemu-devel] [RFC][PATCH 02/16] kvm: Move kvmclock into hw/kvm folder

[Jan Kiszka]

On 2011-12-03 20:00, Andreas Färber wrote:
> Am 03.12.2011 12:17, schrieb Jan Kiszka:
>> From: Jan Kiszka 
>>
>> More KVM-specific devices will come, so let's start with moving the
>> kvmclock into a dedicated folder.
>>
>> Signed-off-by: Jan Kiszka 
>> ---
> 
>> diff --git a/Makefile.target b/Makefile.target
>> index 1e90df7..3a9e95d 100644
>> --- a/Makefile.target
>> +++ b/Makefile.target
>> @@ -231,7 +231,7 @@ obj-i386-y += vmport.o
>>  obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
>>  obj-i386-y += debugcon.o multiboot.o
>>  obj-i386-y += pc_piix.o
>> -obj-i386-$(CONFIG_KVM) += kvmclock.o
>> +obj-i386-$(CONFIG_KVM) += kvm/clock.o
>>  obj-i386-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
>>  
>>  # shared objects
> 
>> diff --git a/hw/kvmclock.c b/hw/kvm/clock.c
>> similarity index 96%
>> rename from hw/kvmclock.c
>> rename to hw/kvm/clock.c
>> index 5388bc4..aa37c5d 100644
>> --- a/hw/kvmclock.c
>> +++ b/hw/kvm/clock.c
>> @@ -11,11 +11,11 @@
>>   *
>>   */
>>  
>> -#include "qemu-common.h"
>> -#include "sysemu.h"
>> -#include "sysbus.h"
>> -#include "kvm.h"
>> -#include "kvmclock.h"
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>>  
>>  #include 
>>  #include 
> 
> Please don't start using system includes for everything. Rather extend
> QEMU_CFLAGS to contain the right user include path(s).

No problem - and no need to tweak any CFLAGS ("" only adds . to the
header search paths).

Do we have a convention that every include in <> is considered system
header? Should probably be documented then (and code should be converted
gradually).

Jan



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] endless loop when use qemu-system-mipsel to load bios

[Stefan Weil]

Am 16.11.2011 16:21, schrieb rui chen:

sorry, here is my new patch file:

From 05f4abe8d8c37f1585f2bb7cb89b15426044bb65 Mon Sep 17 00:00:00 2001
From: Chen Rui mailto:chenn...@gmail.com>>
Date: Sun, 13 Nov 2011 19:42:42 +0800
Subject: [PATCH] resolve an endless loop when use qemu-system-mipsel 
to load bios



Signed-off-by: Chen Rui mailto:chenn...@gmail.com>>
---
 hw/mips_malta.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/mips_malta.c b/hw/mips_malta.c
index bb49749..e7dfbd6 100644
--- a/hw/mips_malta.c
+++ b/hw/mips_malta.c
@@ -911,6 +911,7 @@ void mips_malta_init (ram_addr_t ram_size,
 uint32_t *end = addr + bios_size;
 while (addr < end) {
 bswap32s(addr);
+addr++;
 }
 }
 #endif
--
1.7.1


This patch fixes a regression introduced by commit
d758525180e0efff8a59cfea11f5f8348014ff6a
(More phys_ram_base elimination).

Please apply it to QEMU git master (with a modified subject, s/use/using/).

Tested-by: Stefan Weil 

Regards,
Stefan Weil

Re: [Qemu-devel] [PATCH v2 00/18] qom: dynamic properties and composition tree (v2)

[Anthony Liguori]

On 12/03/2011 08:24 AM, Paolo Bonzini wrote:

On 12/03/2011 03:40 AM, Anthony Liguori wrote:

That is still true. The next step, inheritance, will pull the properties
into a base class. That base class can be used elsewhere outside of the
device model.

But this is already a 20 patch series. If you want all of that in one
series, it's going to be 100 patches that are not terribly easy to
review at once.


Without a design document and a roadmap, however, it's impossible to try to
understand how the pieces will be together. 100 patches may require some time to
digest, but 20 patches require a crystal ball to figure out what's ahead.


You can see a bit further by looking at:

https://github.com/aliguori/qemu/commits/qom-next

That fills out the composition tree pretty well for the pc.  The next step is 
aggressive refactoring such that the qdev objects reflect the composition.  IOW, 
we should create the rtc from within the piix3 initialization function.


But before we can do that, we need to split construction and introduce realize 
which requires inheritance.


So I'd like to fill out the composition tree next (HEAD~2 in that branch, but 
split up nicely).  Having a flushed out composition tree really helps figure out 
what the code should look like and my hope is that other platforms can start 
refactoring too.


Inheritance is not terribly hard.  First step is adding a type pointer to 
DeviceState *, and then introducing some dynamic_cast-like macros and then 
touching every file to use them.


Second step is QOM-style methods and polymorphism.  That's not terribly hard 
either.

Once we have that, we can do realize.

Note that I haven't really talked about busses.  I do want to get rid of qdev 
busses but I'm in no rush at all.  We can do 95% of the necessary refactoring 
without touching busses and hot plug and I think that's the right strategy.





Make sure that all required abstractions can be implemented in
terms of a QOM composition tree.


Not composition tree, you mean via the link graph.


I mean both, but the link graph is already understandable (1-to-1 is easy).
Right now I can hardly understand how the composition tree will work, for
example: how do you constrain children to be subclasses of some class (or to
implement some interface)?


Composition never involves subclasses.  The tree I point you to above is about 
as complete as it can be right now without doing more qdev conversions.  It 
should answer all of your questions re: composition.



2) Related to this, you have a lot of nice infrastructure, but (unlike
what you did with QAPI) you haven't provided yet a clear plan for how
to get rid of the old code. You also have only very limited uses of
the infrastructure (see above).


Old style properties go away as they're converted to new style properties.


And how do they? How much code churn does that entail, in the devices and in
general? In fact, why do they need conversion at all? Static properties are
special enough to warrant something special.


They can stay around forever (or until someone needs non-static properties) but 
I strongly suspect that we'll get rid of most of them as part of refactoring.


An awful lot of properties deal with connecting to back ends and/or bus 
addressing.  None of that will be needed anymore.



If you want to see how this all is going to look, look at the old tree
:-) That's where we're going to end up.


Let's write documentation on that already.


I have written lots of documentation.  Just take a look at the wiki.  Nothing 
speaks better than code.



It's better for various reasons--type safety and ease of use--even if
it costs some boilerplate. For example the child property should be
as simple as

+struct ChildDeviceProperty {
+ DeviceProperty prop;
+ DeviceState *child;
+}
+
+struct DevicePropertyInfo child_device_property_info = {
+ .size = sizeof(ChildDeviceProperty);
+ .get = qdev_get_child_property,
+};
+
void qdev_property_add_child(DeviceState *dev, const char *name,
DeviceState *child, Error **errp)
{
gchar *type;

type = g_strdup_printf("child<%s>", child->info->name);

- qdev_property_add(dev, name, type, qdev_get_child_property,
- NULL, NULL, child, errp);
+ prop = (ChildDeviceProperty *)
+ qdev_property_add(&child_device_property_info,
+ dev, name, type, errp);
+
+ /* TODO: check errp, if it is NULL -> return immediately. */
+ prop->child = child;


This seems quite a bit uglier to me.


I did say it costs some boilerplate, but it's once per type and you said there's
a dozen of those. The type safety and more flexibility (an arbitrary struct for
subclasses rather than an opaque pointer) is worth the ugliness.


I disagree.  Take a look at how string properties work in the above tree.  It's 
strongly type safe.  My old qom tree builds properties based on code generation 
too so the whole discussion on safety is somewhat moot.





I think also that the type should not be part of DeviceProperty.
Instead it should be defined by s

[Qemu-devel] [PATCH] w32: Disable buffering for log file

[Stefan Weil]

W32 does not support line buffering, but it supports unbuffered output.

Unbuffered output is better for writing to qemu.log than fully buffered
output because it also shows the latest log messages when an application
crash occurs.

Signed-off-by: Stefan Weil 
---
 exec.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/exec.c b/exec.c
index 6b92198..d8b2180 100644
--- a/exec.c
+++ b/exec.c
@@ -1603,8 +1603,10 @@ void cpu_set_log(int log_flags)
 static char logfile_buf[4096];
 setvbuf(logfile, logfile_buf, _IOLBF, sizeof(logfile_buf));
 }
-#elif !defined(_WIN32)
-/* Win32 doesn't support line-buffering and requires size >= 2 */
+#elif defined(_WIN32)
+/* Win32 doesn't support line-buffering, so use unbuffered output. */
+setvbuf(logfile, NULL, _IONBF, 0);
+#else
 setvbuf(logfile, NULL, _IOLBF, 0);
 #endif
 log_append = 1;
-- 
1.7.2.5

[Qemu-devel] [PATCH] w32: QEMU applications with SDL are always GUI applications

[Stefan Weil]

Since commit 1d14ffa97eacd3cb722271eaf6f093038396eac4 (in 2005),
QEMU applications on W32 don't use the default SDL compiler flags:

Instead of a GUI application, a console application is created.

This has disadvantages (there is always an empty console window) and
no obvious reason, so this patch removes the strange flag modification.

The SDL GUI applications still can be run from a console window
and even send stdout and stderr to that console by setting environment
variable SDL_STDIO_REDIRECT=no.

Signed-off-by: Stefan Weil 
---
 configure |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index ac4840d..f2fdb1d 100755
--- a/configure
+++ b/configure
@@ -1522,9 +1522,6 @@ EOF
   if compile_prog "$sdl_cflags" "$sdl_libs" ; then
 sdl_libs="$sdl_libs -lX11"
   fi
-  if test "$mingw32" = "yes" ; then
-sdl_libs="`echo $sdl_libs | sed s/-mwindows//g` -mconsole"
-  fi
   libs_softmmu="$sdl_libs $libs_softmmu"
 fi
 
-- 
1.7.2.5

Re: [Qemu-devel] [RFC][PATCH 02/16] kvm: Move kvmclock into hw/kvm folder

[Andreas Färber]

Am 03.12.2011 12:17, schrieb Jan Kiszka:
> From: Jan Kiszka 
> 
> More KVM-specific devices will come, so let's start with moving the
> kvmclock into a dedicated folder.
> 
> Signed-off-by: Jan Kiszka 
> ---

> diff --git a/Makefile.target b/Makefile.target
> index 1e90df7..3a9e95d 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -231,7 +231,7 @@ obj-i386-y += vmport.o
>  obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
>  obj-i386-y += debugcon.o multiboot.o
>  obj-i386-y += pc_piix.o
> -obj-i386-$(CONFIG_KVM) += kvmclock.o
> +obj-i386-$(CONFIG_KVM) += kvm/clock.o
>  obj-i386-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
>  
>  # shared objects

> diff --git a/hw/kvmclock.c b/hw/kvm/clock.c
> similarity index 96%
> rename from hw/kvmclock.c
> rename to hw/kvm/clock.c
> index 5388bc4..aa37c5d 100644
> --- a/hw/kvmclock.c
> +++ b/hw/kvm/clock.c
> @@ -11,11 +11,11 @@
>   *
>   */
>  
> -#include "qemu-common.h"
> -#include "sysemu.h"
> -#include "sysbus.h"
> -#include "kvm.h"
> -#include "kvmclock.h"
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
>  
>  #include 
>  #include 

Please don't start using system includes for everything. Rather extend
QEMU_CFLAGS to contain the right user include path(s).

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [Bug 899140] Re: Problem with Linux Kernel Traffic Control

[Stefan Hajnoczi]

On Fri, Dec 2, 2011 at 2:42 PM, Vincent Autefage
<899...@bugs.launchpad.net> wrote:
> *root@A# tc qdisc add dev eth0 root tbf rate 20mbit burst 20480 latency
> 50ms*
>
> *root@B# **ifconfig eth0 192.168.0.2*
>
> Then if we check with /Iperf/, the real rate will be about 100kbit/s :

What is the iperf result without tc?  It's worth checking what rate
the unlimited interface saturates at before applying tc.  Perhaps this
setup is just performing very poorly and it has nothing to do with tc.

Stefan

Re: [Qemu-devel] [Bug 899143] [NEW] Raw img not recognized by Windows

[Stefan Hajnoczi]

On Fri, Dec 2, 2011 at 2:45 PM, Vincent Autefage
<899...@bugs.launchpad.net> wrote:
> $ qemu-img create -f raw root.img 100GB
> $ mkntfs -F root.img
> $ qemu -name W -sdl -m 2048 -enable-kvm -localtime -k fr -hda root.img
> -cdrom windows7.iso -boot d -net nic,macaddr=a0:00:00:00:00:01 -net
> user,vlan=0

QEMU does recognize the raw image.  You can check this by running
'info block' at the QEMU monitor (Ctrl-Alt-2) and you'll see ide-hd0
is the raw image file you specified.  Press Ctrl-Alt-1 to get back to
the VM display.

The problem is that the Windows installer does not like the disk image
you have prepared.  A normal harddisk has a master boot record but you
created a raw image without a master boot record.  The Windows
installer is being picky/careful and not displaying this non-standard
disk you created.

Skip the mkntfs step and the installer works fine.  There's no need to
create the file system because the installer will do it for you.

Stefan

[Qemu-devel] [Bug 899664] [NEW] Bad internet performance for Host to Guest or Guest to Host

[max]

Public bug reported:

Hi, 
Internet performance for Host to Quest is low. 
The speed Guest to same Guest is  11.3 Gbits/sec
The speed Host to same Host is  similar (9.8-11 Gbits/sec)

But the speed from Guest to Host is slow and around 1Gbit/sec. 
In the reality traffic never leave a Host. I expected that in this case speed 
should be close to Host to Host. 
It is important for virtual infrastructure when you have several Guests on a 
same Host. Guest to Guest on a same host has speed  around 1 Gbits/sec too. 

Below you can find testes and additional information:

=
biouml@biouml-db:~$ iperf -c 192.168.2.31 -t 30 #Guest to Guest 

Client connecting to 192.168.2.31, TCP port 5001
TCP window size: 49.7 KByte (default)

[  3] local 192.168.2.31 port 52170 connected with 192.168.2.31 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-30.0 sec  39.6 GBytes  11.3 Gbits/sec

biouml@biouml-db:~$ iperf -c 192.168.2.11 -t 30 # Guest to Host

Client connecting to 192.168.2.11, TCP port 5001
TCP window size: 43.4 KByte (default)

[  3] local 192.168.2.31 port 47148 connected with 192.168.2.11 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-30.0 sec  3.69 GBytes  1.06 Gbits/sec
biouml@biouml-db:~$ 

root@s2-8core:~# iperf -c 192.168.2.30 -t 30 #host to guest

Client connecting to 192.168.2.30, TCP port 5001
TCP window size: 16.0 KByte (default)

[  3] local 192.168.2.11 port 57403 connected with 192.168.2.30 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-30.0 sec  5.47 GBytes  1.57 Gbits/sec

==
root@s2-8core:~# iperf -c 192.168.2.11 -t 30 #host to host

Client connecting to 192.168.2.11, TCP port 5001
TCP window size: 49.7 KByte (default)

[  3] local 192.168.2.11 port 38313 connected with 192.168.2.11 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-30.0 sec  34.5 GBytes  9.87 Gbits/sec
root@s2-8core:~# 


I am using virtio drivers and virtual machine was started with following
parameters:

/usr/bin/kvm -S -M pc-1.0 -enable-kvm -m 4096 -smp 
4,sockets=4,cores=1,threads=1 -name one-25 -uuid 
d1e125ee-d692-4598-3a75-441cd79a513a -nodefconfig -nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/one-25.monitor,server,nowait 
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown 
-drive 
file=/var/lib/one/OpenNebula/var//25/images/disk.0,if=none,id=drive-virtio-disk0,format=raw,cache=none
 -device 
virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
 -drive 
file=/var/lib/one/OpenNebula/var//25/images/disk.1,if=none,id=drive-virtio-disk3,format=raw
 -device 
virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk3,id=virtio-disk3 
-netdev tap,fd=19,id=hostnet0 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=02:00:c0:a8:02:02,bus=pci.0,addr=0x3 
-usb -device usb-mouse,id=input0 -vnc 0.0.0.0:98 -vga cirrus -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
=
Qemu version:
root@s2-8core:~# /usr/bin/kvm --version
QEMU emulator version 0.15.92, Copyright (c) 2003-2008 Fabrice Bellard

root@s2-8core:~# ls -la /usr/bin/kvm
lrwxrwxrwx 1 root root 27 2011-11-07 17:34 /usr/bin/kvm -> 
/usr/bin/qemu-system-x86_64

==
Bridge configuration:

root@s2-8core:~# cat /etc/network/interfaces 
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto eth1 
iface eth1 inet manual

auto br0
iface br0 inet static
address 192.168.2.11
network 192.168.2.0
netmask 255.255.255.0
broadcast 192.168.2.255
gateway 192.168.2.1
bridge_ports eth0
bridge_stp on
bridge_fd 0
bridge_maxwait 0
root@s2-8core:~# 

root@s2-8core:~# brctl show
bridge name bridge id   STP enabled interfaces
br0 8000.001e8cec6113   yes eth0
vnet0
virbr0  8000.   yes 

root@s2-8core:~# brctl --version
bridge-utils, 1.5
===

Re: [Qemu-devel] [PATCH v2 00/18] qom: dynamic properties and composition tree (v2)

[Paolo Bonzini]

On 12/03/2011 03:40 AM, Anthony Liguori wrote:

That is still true. The next step, inheritance, will pull the properties
into a base class. That base class can be used elsewhere outside of the
device model.

But this is already a 20 patch series. If you want all of that in one
series, it's going to be 100 patches that are not terribly easy to
review at once.


Without a design document and a roadmap, however, it's impossible to try 
to understand how the pieces will be together.  100 patches may require 
some time to digest, but 20 patches require a crystal ball to figure out 
what's ahead.



Make sure that all required abstractions can be implemented in
terms of a QOM composition tree.


Not composition tree, you mean via the link graph.


I mean both, but the link graph is already understandable (1-to-1 is 
easy).  Right now I can hardly understand how the composition tree will 
work, for example: how do you constrain children to be subclasses of 
some class (or to implement some interface)?



2) Related to this, you have a lot of nice infrastructure, but (unlike
what you did with QAPI) you haven't provided yet a clear plan for how
to get rid of the old code. You also have only very limited uses of
the infrastructure (see above).


Old style properties go away as they're converted to new style properties.


And how do they?  How much code churn does that entail, in the devices 
and in general?  In fact, why do they need conversion at all?  Static 
properties are special enough to warrant something special.



If you want to see how this all is going to look, look at the old tree
:-) That's where we're going to end up.


Let's write documentation on that already.


It's better for various reasons--type safety and ease of use--even if
it costs some boilerplate. For example the child property should be
as simple as

+struct ChildDeviceProperty {
+ DeviceProperty prop;
+ DeviceState *child;
+}
+
+struct DevicePropertyInfo child_device_property_info = {
+ .size = sizeof(ChildDeviceProperty);
+ .get = qdev_get_child_property,
+};
+
void qdev_property_add_child(DeviceState *dev, const char *name,
DeviceState *child, Error **errp)
{
gchar *type;

type = g_strdup_printf("child<%s>", child->info->name);

- qdev_property_add(dev, name, type, qdev_get_child_property,
- NULL, NULL, child, errp);
+ prop = (ChildDeviceProperty *)
+ qdev_property_add(&child_device_property_info,
+ dev, name, type, errp);
+
+ /* TODO: check errp, if it is NULL -> return immediately. */
+ prop->child = child;


This seems quite a bit uglier to me.


I did say it costs some boilerplate, but it's once per type and you said 
there's a dozen of those.  The type safety and more flexibility (an 
arbitrary struct for subclasses rather than an opaque pointer) is worth 
the ugliness.



I think also that the type should not be part of DeviceProperty.
Instead it should be defined by subclasses, with the
DevicePropertyInfo providing a function to format the type to a
string.


I don't really know what you mean by this.


Once the type is written as child, you've lost all info on it. 
 Each property type should have its own representation for types (it 
can be implicit, or it can be an enum, or it can be a DeviceInfo), with 
a method to pretty-print it.



We jump too quickly at
doing conversions without thinking through the underlying interface.


I hoped you had thought it through. ;)


You may find it odd to hear me say this, but I grow weary of adding too
much class hierarchy and inheritance with properties. Yes, we could make
it very sophisticated but in practice it doesn't have to be. Properties
should be one of two things: primitive types or link/childs.


... and interfaces.  Accessing them by name as a property should work well.


This is where qdev goes very wrong. It mixes up user interface details
(how to format an integer on the command line) with implementation
details. There's no reason we should be indicating whether a property
should be display in hex or decimal in the device itself.


That's totally true.  But there's no reason why qdev properties cannot 
be split in two parts, a sane one and a legacy one.  If you don't do 
this, you take the unmodifiable ABI and force its use as an API 
throughout all QOM.  We can do better.



For artificial properties you would need one-off classes; but you can
still provide a helper that creates a specialized
DeviceProperty+DevicePropertyInfo from the functions. I'm thinking of
how people implement prototype-based OO on top of class-based OO, but
it might be just a macro.


I think you're over thinking the problem. There are going to be maybe a
dozen property types and that's it. They all with correspond exactly to
C types with the exception of links/children.


I was thinking of one-off types such as rtc's struct tm.  Also, besides 
C primitive types there will be property types for structs: for example 
virtio or SCSI requests, S/G lists, and so on.


Paolo

[Qemu-devel] Western Union Online : Message Alert!

[westernunion]

Dear Western Union Customer

From: westernun...@westernunion.com
Subject: Western Union Online : Message Alert!

You have (1) unread Message!


Your Western Union Account is currently locked.


As a security measure you must provide your credit card cvv ( the
last 3 digits on the back of your card ) to unlock your account.


Regarding this, please follow the link below to resolve this
issue:

http://www.bavaria-waermepumpen.com/www.westernunion.no/WUCOMWEB/staticMid.do/countryCode/NO/


Western Union Holdings, All Rights Reserved .
  

[Qemu-devel] [RFC][PATCH 10/16] memory: Introduce memory_region_init_reservation

[Jan Kiszka]

From: Jan Kiszka 

Introduce a memory region type that can reserve I/O space. Such regions
are useful for modeling I/O that is only handled outside of QEMU, i.e.
in the context of an accelerator like KVM. Any access to such a region
from QEMU is a bug and will be reported as such.

Signed-off-by: Jan Kiszka 
---
 memory.c |   35 +++
 memory.h |   15 +++
 2 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/memory.c b/memory.c
index dc5e35d..a40990c 100644
--- a/memory.c
+++ b/memory.c
@@ -1003,6 +1003,41 @@ void memory_region_init_rom_device(MemoryRegion *mr,
 mr->backend_registered = true;
 }
 
+static uint64_t invalid_read(void *opaque, target_phys_addr_t addr,
+ unsigned size)
+{
+MemoryRegion *mr = opaque;
+
+fprintf(stderr, "Invalid read from memory region %s\n", mr->name);
+abort();
+}
+
+static void invalid_write(void *opaque, target_phys_addr_t addr, uint64_t data,
+  unsigned size)
+{
+MemoryRegion *mr = opaque;
+
+fprintf(stderr, "Invalid write to memory region %s\n", mr->name);
+abort();
+}
+
+static const MemoryRegionOps reservation_ops = {
+.read = invalid_read,
+.write = invalid_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
+};
+
+void memory_region_init_reservation(MemoryRegion *mr,
+const char *name,
+uint64_t size)
+{
+memory_region_init(mr, name, size);
+mr->ops = &reservation_ops;
+mr->opaque = mr;
+mr->terminates = true;
+mr->backend_registered = false;
+}
+
 void memory_region_destroy(MemoryRegion *mr)
 {
 assert(QTAILQ_EMPTY(&mr->subregions));
diff --git a/memory.h b/memory.h
index d5b47da..4ff441f 100644
--- a/memory.h
+++ b/memory.h
@@ -242,6 +242,21 @@ void memory_region_init_rom_device(MemoryRegion *mr,
uint64_t size);
 
 /**
+ * memory_region_init_reservation: Initialize a memory region that reserves
+ * I/O space.
+ *
+ * A reservation region primariy serves debugging purposes.  It claims I/O
+ * space that is not supposed to be handled by QEMU itself.  Any access via
+ * the memory API will cause an abort().
+ *
+ * @mr: the #MemoryRegion to be initialized
+ * @name: used for debugging; not visible to the user or ABI
+ * @size: size of the region.
+ */
+void memory_region_init_reservation(MemoryRegion *mr,
+const char *name,
+uint64_t size);
+/**
  * memory_region_destroy: Destroy a memory region and relaim all resources.
  *
  * @mr: the region to be destroyed.  May not currently be a subregion
-- 
1.7.3.4

[Qemu-devel] [RFC][PATCH 05/16] apic: Open-code timer save/restore

[Jan Kiszka]

From: Jan Kiszka 

To enable migration between accelerated and non-accelerated APIC models,
we will need to handle the timer saving and restoring specially and can
no longer rely on the automatics of VMSTATE_TIMER. Specifically,
accelerated model will not start any QEMUTimer.

This patch therefore factors out the generic bits into apic_next_timer
and introduces a post-load callback that can be implemented differently
by both models.

Signed-off-by: Jan Kiszka 
---
 hw/apic.c  |   30 --
 hw/apic_common.c   |   51 +--
 hw/apic_internal.h |3 +++
 3 files changed, 64 insertions(+), 20 deletions(-)

diff --git a/hw/apic.c b/hw/apic.c
index 27b18d6..9b83c0c 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -516,25 +516,9 @@ static uint32_t apic_get_current_count(APICState *s)
 
 static void apic_timer_update(APICState *s, int64_t current_time)
 {
-int64_t next_time, d;
-
-if (!(s->lvt[APIC_LVT_TIMER] & APIC_LVT_MASKED)) {
-d = (current_time - s->initial_count_load_time) >>
-s->count_shift;
-if (s->lvt[APIC_LVT_TIMER] & APIC_LVT_TIMER_PERIODIC) {
-if (!s->initial_count)
-goto no_timer;
-d = ((d / ((uint64_t)s->initial_count + 1)) + 1) * 
((uint64_t)s->initial_count + 1);
-} else {
-if (d >= s->initial_count)
-goto no_timer;
-d = (uint64_t)s->initial_count + 1;
-}
-next_time = s->initial_count_load_time + (d << s->count_shift);
-qemu_mod_timer(s->timer, next_time);
-s->next_time = next_time;
+if (apic_next_timer(s, current_time)) {
+qemu_mod_timer(s->timer, s->next_time);
 } else {
-no_timer:
 qemu_del_timer(s->timer);
 }
 }
@@ -756,6 +740,15 @@ static const MemoryRegionOps apic_io_ops = {
 .endianness = DEVICE_NATIVE_ENDIAN,
 };
 
+static void apic_post_load(APICState *s)
+{
+if (s->timer_expiry != -1) {
+qemu_mod_timer(s->timer, s->timer_expiry);
+} else {
+qemu_del_timer(s->timer);
+}
+}
+
 static int apic_init(SysBusDevice *dev)
 {
 APICState *s = FROM_SYSBUS(APICState, dev);
@@ -772,6 +765,7 @@ static int apic_init(SysBusDevice *dev)
 s->timer = qemu_new_timer_ns(vm_clock, apic_timer, s);
 s->set_base = apic_set_base;
 s->set_tpr = apic_set_tpr;
+s->post_load = apic_post_load;
 local_apics[s->idx] = s;
 return 0;
 }
diff --git a/hw/apic_common.c b/hw/apic_common.c
index 7d30356..84a3a27 100644
--- a/hw/apic_common.c
+++ b/hw/apic_common.c
@@ -80,6 +80,39 @@ int apic_get_irq_delivered(void)
 return apic_irq_delivered;
 }
 
+bool apic_next_timer(APICState *s, int64_t current_time)
+{
+int64_t d;
+
+/* We need to store the timer state separately to support APIC
+ * implementations that maintain a non-QEMU timer, e.g. inside the
+ * host kernel. This open-coded state allows us to migrate between
+ * both models. */
+s->timer_expiry = -1;
+
+if (s->lvt[APIC_LVT_TIMER] & APIC_LVT_MASKED) {
+return false;
+}
+
+d = (current_time - s->initial_count_load_time) >> s->count_shift;
+
+if (s->lvt[APIC_LVT_TIMER] & APIC_LVT_TIMER_PERIODIC) {
+if (!s->initial_count) {
+return false;
+}
+d = ((d / ((uint64_t)s->initial_count + 1)) + 1) *
+((uint64_t)s->initial_count + 1);
+} else {
+if (d >= s->initial_count) {
+return false;
+}
+d = (uint64_t)s->initial_count + 1;
+}
+s->next_time = s->initial_count_load_time + (d << s->count_shift);
+s->timer_expiry = s->next_time;
+return true;
+}
+
 void apic_init_reset(DeviceState *d)
 {
 APICState *s = DO_UPCAST(APICState, busdev.qdev, d);
@@ -107,7 +140,10 @@ void apic_init_reset(DeviceState *d)
 s->next_time = 0;
 s->wait_for_sipi = 1;
 
-qemu_del_timer(s->timer);
+if (s->timer) {
+qemu_del_timer(s->timer);
+}
+s->timer_expiry = -1;
 }
 
 void apic_reset(DeviceState *d)
@@ -172,12 +208,23 @@ static int apic_load_old(QEMUFile *f, void *opaque, int 
version_id)
 return 0;
 }
 
+static int apic_dispatch_post_load(void *opaque, int version_id)
+{
+APICState *s = opaque;
+
+if (s->post_load) {
+s->post_load(s);
+}
+return 0;
+}
+
 const VMStateDescription vmstate_apic = {
 .name = "apic",
 .version_id = 3,
 .minimum_version_id = 3,
 .minimum_version_id_old = 1,
 .load_state_old = apic_load_old,
+.post_load = apic_dispatch_post_load,
 .fields  = (VMStateField[]) {
 VMSTATE_UINT32(apicbase, APICState),
 VMSTATE_UINT8(id, APICState),
@@ -197,7 +244,7 @@ const VMStateDescription vmstate_apic = {
 VMSTATE_UINT32(initial_count, APICState),
 VMSTATE_INT64(initial_count_load_time, APICState),
 VMSTATE_INT64(next_time, APICState),
-VMSTATE_TIMER(timer, APICState),
+VMSTATE_

[Qemu-devel] [RFC][PATCH 07/16] ioapic: Convert to memory API

[Jan Kiszka]

From: Jan Kiszka 

This maintains the old imprecise access size handling.

Signed-off-by: Jan Kiszka 
---
 hw/ioapic.c |   28 +++-
 1 files changed, 11 insertions(+), 17 deletions(-)

diff --git a/hw/ioapic.c b/hw/ioapic.c
index 61991d7..56b1612 100644
--- a/hw/ioapic.c
+++ b/hw/ioapic.c
@@ -86,6 +86,7 @@ typedef struct IOAPICState IOAPICState;
 
 struct IOAPICState {
 SysBusDevice busdev;
+MemoryRegion io_memory;
 uint8_t id;
 uint8_t ioregsel;
 uint32_t irr;
@@ -195,7 +196,8 @@ void ioapic_eoi_broadcast(int vector)
 }
 }
 
-static uint32_t ioapic_mem_readl(void *opaque, target_phys_addr_t addr)
+static uint64_t
+ioapic_mem_read(void *opaque, target_phys_addr_t addr, unsigned int size)
 {
 IOAPICState *s = opaque;
 int index;
@@ -234,7 +236,8 @@ static uint32_t ioapic_mem_readl(void *opaque, 
target_phys_addr_t addr)
 }
 
 static void
-ioapic_mem_writel(void *opaque, target_phys_addr_t addr, uint32_t val)
+ioapic_mem_write(void *opaque, target_phys_addr_t addr, uint64_t val,
+ unsigned int size)
 {
 IOAPICState *s = opaque;
 int index;
@@ -309,32 +312,23 @@ static void ioapic_reset(DeviceState *d)
 }
 }
 
-static CPUReadMemoryFunc * const ioapic_mem_read[3] = {
-ioapic_mem_readl,
-ioapic_mem_readl,
-ioapic_mem_readl,
-};
-
-static CPUWriteMemoryFunc * const ioapic_mem_write[3] = {
-ioapic_mem_writel,
-ioapic_mem_writel,
-ioapic_mem_writel,
+static const MemoryRegionOps ioapic_io_ops = {
+.read = ioapic_mem_read,
+.write = ioapic_mem_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
 };
 
 static int ioapic_init1(SysBusDevice *dev)
 {
 IOAPICState *s = FROM_SYSBUS(IOAPICState, dev);
-int io_memory;
 static int ioapic_no;
 
 if (ioapic_no >= MAX_IOAPICS) {
 return -1;
 }
 
-io_memory = cpu_register_io_memory(ioapic_mem_read,
-   ioapic_mem_write, s,
-   DEVICE_NATIVE_ENDIAN);
-sysbus_init_mmio(dev, 0x1000, io_memory);
+memory_region_init_io(&s->io_memory, &ioapic_io_ops, s, "ioapic", 0x1000);
+sysbus_init_mmio_region(dev, &s->io_memory);
 
 qdev_init_gpio_in(&dev->qdev, ioapic_set_irq, IOAPIC_NUM_PINS);
 
-- 
1.7.3.4

[Qemu-devel] [RFC][PATCH 11/16] kvm: Introduce core services for in-kernel irqchip support

[Jan Kiszka]

From: Jan Kiszka 

Add the basic infrastructure to active in-kernel irqchip support, inject
interrupts into these models, and maintain IRQ routes.

Routing is optional and depends on the host arch supporting
KVM_CAP_IRQ_ROUTING. When it's not available on x86, we loose the HPET
as we can't route GSI0 to IOAPIC pin 2.

In-kernel irqchip support will once be controlled by the machine
property 'kernel_irqchip', but this is not yet wired up.

Signed-off-by: Jan Kiszka 
---
 kvm-all.c |  149 +
 kvm.h |8 +++
 target-i386/kvm.c |   11 
 3 files changed, 168 insertions(+), 0 deletions(-)

diff --git a/kvm-all.c b/kvm-all.c
index e7faf5c..a85e14f 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -76,6 +76,13 @@ struct KVMState
 int pit_in_kernel;
 int xsave, xcrs;
 int many_ioeventfds;
+int irqchip_inject_ioctl;
+#ifdef KVM_CAP_IRQ_ROUTING
+struct kvm_irq_routing *irq_routes;
+int nr_allocated_irq_routes;
+uint32_t *used_gsi_bitmap;
+unsigned int max_gsi;
+#endif
 };
 
 KVMState *kvm_state;
@@ -692,6 +699,138 @@ static void kvm_handle_interrupt(CPUState *env, int mask)
 }
 }
 
+int kvm_irqchip_set_irq(KVMState *s, int irq, int level)
+{
+struct kvm_irq_level event;
+int ret;
+
+assert(s->irqchip_in_kernel);
+
+event.level = level;
+event.irq = irq;
+ret = kvm_vm_ioctl(s, s->irqchip_inject_ioctl, &event);
+if (ret < 0) {
+perror("kvm_set_irqchip_line");
+abort();
+}
+
+return (s->irqchip_inject_ioctl == KVM_IRQ_LINE) ? 1 : event.status;
+}
+
+#ifdef KVM_CAP_IRQ_ROUTING
+static void set_gsi(KVMState *s, unsigned int gsi)
+{
+assert(gsi < s->max_gsi);
+
+s->used_gsi_bitmap[gsi / 32] |= 1U << (gsi % 32);
+}
+
+static void kvm_init_irq_routing(KVMState *s)
+{
+int gsi_count;
+
+gsi_count = kvm_check_extension(s, KVM_CAP_IRQ_ROUTING);
+if (gsi_count > 0) {
+unsigned int gsi_bits, i;
+
+/* Round up so we can search ints using ffs */
+gsi_bits = (gsi_count + 31) / 32;
+s->used_gsi_bitmap = g_malloc0(gsi_bits / 8);
+s->max_gsi = gsi_bits;
+
+/* Mark any over-allocated bits as already in use */
+for (i = gsi_count; i < gsi_bits; i++) {
+set_gsi(s, i);
+}
+}
+
+s->irq_routes = g_malloc0(sizeof(*s->irq_routes));
+s->nr_allocated_irq_routes = 0;
+
+kvm_arch_init_irq_routing(s);
+}
+
+static void kvm_add_routing_entry(KVMState *s,
+  struct kvm_irq_routing_entry *entry)
+{
+struct kvm_irq_routing_entry *new;
+int n, size;
+
+if (s->irq_routes->nr == s->nr_allocated_irq_routes) {
+n = s->nr_allocated_irq_routes * 2;
+if (n < 64) {
+n = 64;
+}
+size = sizeof(struct kvm_irq_routing);
+size += n * sizeof(*new);
+s->irq_routes = g_realloc(s->irq_routes, size);
+s->nr_allocated_irq_routes = n;
+}
+n = s->irq_routes->nr++;
+new = &s->irq_routes->entries[n];
+memset(new, 0, sizeof(*new));
+new->gsi = entry->gsi;
+new->type = entry->type;
+new->flags = entry->flags;
+new->u = entry->u;
+
+set_gsi(s, entry->gsi);
+}
+
+void kvm_irqchip_add_route(KVMState *s, int irq, int irqchip, int pin)
+{
+struct kvm_irq_routing_entry e;
+
+e.gsi = irq;
+e.type = KVM_IRQ_ROUTING_IRQCHIP;
+e.flags = 0;
+e.u.irqchip.irqchip = irqchip;
+e.u.irqchip.pin = pin;
+kvm_add_routing_entry(s, &e);
+}
+
+int kvm_irqchip_commit_routes(KVMState *s)
+{
+s->irq_routes->flags = 0;
+return kvm_vm_ioctl(s, KVM_SET_GSI_ROUTING, s->irq_routes);
+}
+
+#else /* !KVM_CAP_IRQ_ROUTING */
+
+static void kvm_init_irq_routing(KVMState *s)
+{
+}
+#endif /* !KVM_CAP_IRQ_ROUTING */
+
+static int kvm_irqchip_create(KVMState *s)
+{
+QemuOptsList *list = qemu_find_opts("machine");
+int ret;
+
+if (QTAILQ_EMPTY(&list->head) ||
+!qemu_opt_get_bool(QTAILQ_FIRST(&list->head),
+   "kernel_irqchip", false) ||
+!kvm_check_extension(s, KVM_CAP_IRQCHIP)) {
+return 0;
+}
+
+ret = kvm_vm_ioctl(s, KVM_CREATE_IRQCHIP);
+if (ret < 0) {
+fprintf(stderr, "Create kernel irqchip failed\n");
+return ret;
+}
+
+s->irqchip_inject_ioctl = KVM_IRQ_LINE;
+if (kvm_check_extension(s, KVM_CAP_IRQ_INJECT_STATUS)) {
+s->irqchip_inject_ioctl = KVM_IRQ_LINE_STATUS;
+}
+s->irqchip_in_kernel = 1;
+
+kvm_init_irq_routing(s);
+
+return 0;
+}
+
 int kvm_init(void)
 {
 static const char upgrade_note[] =
@@ -786,6 +925,11 @@ int kvm_init(void)
 goto err;
 }
 
+ret = kvm_irqchip_create(s);
+if (ret < 0) {
+goto err;
+}
+
 kvm_state = s;
 cpu_register_phys_memory_client(&kvm_cpu_phys_memory_client);
 
@@ -,6 +1255,11 @@ int kvm_has_many_ioeventfds(void)
 return kvm_state->many_ioeventfds;
 }
 
+int kvm_has

[Qemu-devel] [RFC][PATCH 04/16] apic: Factor out core for KVM reuse

[Jan Kiszka]

From: Jan Kiszka 

The KVM in-kernel APIC model will reuse parts of the user space model,
namely the vmstate, reset handling, IRQ coalescing tracker, some init
steps and the base and tpr set/get routines. For the latter, we also
prepare set callbacks as KVM will override those.

Signed-off-by: Jan Kiszka 
---
 Makefile.target|2 +-
 hw/apic.c  |  260 +++-
 hw/apic_common.c   |  215 +++
 hw/apic_internal.h |  108 ++
 trace-events   |2 +-
 5 files changed, 339 insertions(+), 248 deletions(-)
 create mode 100644 hw/apic_common.c
 create mode 100644 hw/apic_internal.h

diff --git a/Makefile.target b/Makefile.target
index 3a9e95d..7bb6b13 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -226,7 +226,7 @@ obj-$(CONFIG_IVSHMEM) += ivshmem.o
 # Hardware support
 obj-i386-y += vga.o
 obj-i386-y += mc146818rtc.o pc.o
-obj-i386-y += cirrus_vga.o sga.o apic.o ioapic.o piix_pci.o
+obj-i386-y += cirrus_vga.o sga.o apic_common.o apic.o ioapic.o piix_pci.o
 obj-i386-y += vmport.o
 obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
 obj-i386-y += debugcon.o multiboot.o
diff --git a/hw/apic.c b/hw/apic.c
index 2644a82..27b18d6 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -16,53 +16,13 @@
  * You should have received a copy of the GNU Lesser General Public
  * License along with this library; if not, see 
  */
-#include "hw.h"
+#include "apic_internal.h"
 #include "apic.h"
 #include "ioapic.h"
-#include "qemu-timer.h"
 #include "host-utils.h"
-#include "sysbus.h"
 #include "trace.h"
 #include "pc.h"
 
-/* APIC Local Vector Table */
-#define APIC_LVT_TIMER   0
-#define APIC_LVT_THERMAL 1
-#define APIC_LVT_PERFORM 2
-#define APIC_LVT_LINT0   3
-#define APIC_LVT_LINT1   4
-#define APIC_LVT_ERROR   5
-#define APIC_LVT_NB  6
-
-/* APIC delivery modes */
-#define APIC_DM_FIXED  0
-#define APIC_DM_LOWPRI 1
-#define APIC_DM_SMI2
-#define APIC_DM_NMI4
-#define APIC_DM_INIT   5
-#define APIC_DM_SIPI   6
-#define APIC_DM_EXTINT 7
-
-/* APIC destination mode */
-#define APIC_DESTMODE_FLAT 0xf
-#define APIC_DESTMODE_CLUSTER  1
-
-#define APIC_TRIGGER_EDGE  0
-#define APIC_TRIGGER_LEVEL 1
-
-#defineAPIC_LVT_TIMER_PERIODIC (1<<17)
-#defineAPIC_LVT_MASKED (1<<16)
-#defineAPIC_LVT_LEVEL_TRIGGER  (1<<15)
-#defineAPIC_LVT_REMOTE_IRR (1<<14)
-#defineAPIC_INPUT_POLARITY (1<<13)
-#defineAPIC_SEND_PENDING   (1<<12)
-
-#define ESR_ILLEGAL_ADDRESS (1 << 7)
-
-#define APIC_SV_DIRECTED_IO (1<<12)
-#define APIC_SV_ENABLE  (1<<8)
-
-#define MAX_APICS 255
 #define MAX_APIC_WORDS 8
 
 /* Intel APIC constants: from include/asm/msidef.h */
@@ -75,40 +35,7 @@
 #define MSI_ADDR_DEST_ID_SHIFT 12
 #defineMSI_ADDR_DEST_ID_MASK   0x000
 
-#define MSI_ADDR_SIZE   0x10
-
-typedef struct APICState APICState;
-
-struct APICState {
-SysBusDevice busdev;
-MemoryRegion io_memory;
-void *cpu_env;
-uint32_t apicbase;
-uint8_t id;
-uint8_t arb_id;
-uint8_t tpr;
-uint32_t spurious_vec;
-uint8_t log_dest;
-uint8_t dest_mode;
-uint32_t isr[8];  /* in service register */
-uint32_t tmr[8];  /* trigger mode register */
-uint32_t irr[8]; /* interrupt request register */
-uint32_t lvt[APIC_LVT_NB];
-uint32_t esr; /* error register */
-uint32_t icr[2];
-
-uint32_t divide_conf;
-int count_shift;
-uint32_t initial_count;
-int64_t initial_count_load_time, next_time;
-uint32_t idx;
-QEMUTimer *timer;
-int sipi_vector;
-int wait_for_sipi;
-};
-
 static APICState *local_apics[MAX_APICS + 1];
-static int apic_irq_delivered;
 
 static void apic_set_irq(APICState *s, int vector_num, int trigger_mode);
 static void apic_update_irq(APICState *s);
@@ -293,14 +220,8 @@ void apic_deliver_irq(uint8_t dest, uint8_t dest_mode, 
uint8_t delivery_mode,
 apic_bus_deliver(deliver_bitmask, delivery_mode, vector_num, trigger_mode);
 }
 
-void cpu_set_apic_base(DeviceState *d, uint64_t val)
+static void apic_set_base(APICState *s, uint64_t val)
 {
-APICState *s = DO_UPCAST(APICState, busdev.qdev, d);
-
-trace_cpu_set_apic_base(val);
-
-if (!s)
-return;
 s->apicbase = (val & 0xf000) |
 (s->apicbase & (MSR_IA32_APICBASE_BSP | MSR_IA32_APICBASE_ENABLE));
 /* if disabled, cannot be enabled again */
@@ -311,32 +232,12 @@ void cpu_set_apic_base(DeviceState *d, uint64_t val)
 }
 }
 
-uint64_t cpu_get_apic_base(DeviceState *d)
-{
-APICState *s = DO_UPCAST(APICState, busdev.qdev, d);
-
-trace_cpu_get_apic_base(s ? (uint64_t)s->apicbase: 0);
-
-return s ? s->apicbase : 0;
-}
-
-void cpu_set_apic_tpr(DeviceState *d, uint8_t val)
+static void apic_set_tpr(APICState *s, uint8_t val)
 {
-

[Qemu-devel] [RFC][PATCH 00/16] uq/master: Introduce basic irqchip support

[Jan Kiszka]

Some weeks back I posted my MSI rework for qemu-kvm that shall once help
integrating those bits into upstream. After that I wondered how a
rewritten in-kernel irqchip model could look like and make use of this.
But then I realized that there is actually no technical need to role out
a first version of kvm irqchips that already support MSI. As the MSI
thing will likely take a few more iterations, I now decided to rush
forward with basic kvm irqchip for QEMU upstream. Here we go.

My idea was always to create proper alternatives to the existing user
space device models while keeping the vmstates 100% compatible. I think
I succeeded in this, tests worked fine so far. The kvm and the user
space models now have a common core where they share logic and specific
code modules where they differ. Also, I moved all kvm devices into
hw/kvm.

The in-kernel irqchip support can be controlled via a machine property
(-machine ...,kernel_irqchip=on), in contrast to qemu-kvm's dedicated
command line switch. This series keeps the support off by default
because we still lack the MSI bits as I explained. Also, in-kernel PIT
is not yet implemented and TPR patching/VAPIC (for Windows guests).

The merge story would basically look similar to what we did before with
the clean-room reimplementation of kvm for QEMU: Merge into upstream,
merge back into qemu-kvm, disabling the new bits for now, then gradually
switching over to the new services, specifically once they are
feature-equivalent. Of course, I will support these steps as usual.

So, feedback and review welcome!

Jan Kiszka (16):
  msi: Generalize msix_supported to msi_supported
  kvm: Move kvmclock into hw/kvm folder
  apic: Stop timer on reset
  apic: Factor out core for KVM reuse
  apic: Open-code timer save/restore
  i8259: Factor out core for KVM reuse
  ioapic: Convert to memory API
  ioapic: Reject non-dword accesses to IOWIN register
  ioapic: Factor out core for KVM reuse
  memory: Introduce memory_region_init_reservation
  kvm: Introduce core services for in-kernel irqchip support
  kvm: x86: Establish IRQ0 override control
  kvm: x86: Add user space part for in-kernel APIC
  kvm: x86: Add user space part for in-kernel i8259
  kvm: x86: Add user space part for in-kernel IOAPIC
  kvm: Arm in-kernel irqchip support

 Makefile.objs  |2 +-
 Makefile.target|6 +-
 configure  |1 +
 hw/apic.c  |  288 
 hw/apic_common.c   |  262 
 hw/apic_internal.h |  111 +++
 hw/i8259.c |   78 +---
 hw/i8259_common.c  |  103 ++
 hw/i8259_internal.h|   67 +
 hw/ioapic.c|  136 +++
 hw/ioapic_common.c |   89 
 hw/ioapic_internal.h   |   94 +
 hw/kvm/apic.c  |  147 
 hw/{kvmclock.c => kvm/clock.c} |   10 +-
 hw/{kvmclock.h => kvm/clock.h} |0
 hw/kvm/i8259.c |  154 +
 hw/kvm/ioapic.c|  120 +
 hw/msi.c   |8 +
 hw/msi.h   |2 +
 hw/msix.c  |9 +-
 hw/msix.h  |2 -
 hw/pc.c|   20 ++-
 hw/pc.h|1 +
 hw/pc_piix.c   |   67 +-
 kvm-all.c  |  154 +
 kvm-stub.c |5 +
 kvm.h  |   13 ++
 memory.c   |   35 +
 memory.h   |   15 ++
 qemu-config.c  |4 +
 qemu-options.hx|5 +-
 sysemu.h   |1 -
 target-i386/kvm.c  |   19 +++
 trace-events   |2 +-
 vl.c   |1 -
 35 files changed, 1548 insertions(+), 483 deletions(-)
 create mode 100644 hw/apic_common.c
 create mode 100644 hw/apic_internal.h
 create mode 100644 hw/i8259_common.c
 create mode 100644 hw/i8259_internal.h
 create mode 100644 hw/ioapic_common.c
 create mode 100644 hw/ioapic_internal.h
 create mode 100644 hw/kvm/apic.c
 rename hw/{kvmclock.c => kvm/clock.c} (96%)
 rename hw/{kvmclock.h => kvm/clock.h} (100%)
 create mode 100644 hw/kvm/i8259.c
 create mode 100644 hw/kvm/ioapic.c

-- 
1.7.3.4

[Qemu-devel] [RFC][PATCH 08/16] ioapic: Reject non-dword accesses to IOWIN register

[Jan Kiszka]

From: Jan Kiszka 

Aligns the model with the spec.

Signed-off-by: Jan Kiszka 
---
 hw/ioapic.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/hw/ioapic.c b/hw/ioapic.c
index 56b1612..eb75766 100644
--- a/hw/ioapic.c
+++ b/hw/ioapic.c
@@ -208,6 +208,9 @@ ioapic_mem_read(void *opaque, target_phys_addr_t addr, 
unsigned int size)
 val = s->ioregsel;
 break;
 case IOAPIC_IOWIN:
+if (size != 4) {
+break;
+}
 switch (s->ioregsel) {
 case IOAPIC_REG_ID:
 val = s->id << IOAPIC_ID_SHIFT;
@@ -247,6 +250,9 @@ ioapic_mem_write(void *opaque, target_phys_addr_t addr, 
uint64_t val,
 s->ioregsel = val;
 break;
 case IOAPIC_IOWIN:
+if (size != 4) {
+break;
+}
 DPRINTF("write: %08x = %08x\n", s->ioregsel, val);
 switch (s->ioregsel) {
 case IOAPIC_REG_ID:
-- 
1.7.3.4

[Qemu-devel] [RFC][PATCH 15/16] kvm: x86: Add user space part for in-kernel IOAPIC

[Jan Kiszka]

From: Jan Kiszka 

This introduces the KVM-accelerated IOAPIC model 'kvm-ioapic' and
extends the IRQ routing setup by the 0->2 redirection when needed.

The kvm-ioapic model has a property that allows to define its GSI base
for injecting interrupts into the kernel model. This will allow to
disentangle PIC and IOAPIC pins for chipsets that support more
sophisticated IRQ routes than the PIIX3. So far the base is kept at 0,
i.e. PIC and IOAPIC share pins 0..15.

Signed-off-by: Jan Kiszka 
---
 Makefile.target  |2 +-
 hw/ioapic_internal.h |1 +
 hw/kvm/ioapic.c  |  120 ++
 hw/pc_piix.c |   15 ++-
 4 files changed, 136 insertions(+), 2 deletions(-)
 create mode 100644 hw/kvm/ioapic.c

diff --git a/Makefile.target b/Makefile.target
index 850b80f..2f3407b 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -231,7 +231,7 @@ obj-i386-y += vmport.o
 obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
 obj-i386-y += debugcon.o multiboot.o
 obj-i386-y += pc_piix.o
-obj-i386-$(CONFIG_KVM) += kvm/clock.o kvm/apic.o kvm/i8259.o
+obj-i386-$(CONFIG_KVM) += kvm/clock.o kvm/apic.o kvm/i8259.o kvm/ioapic.o
 obj-i386-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
 
 # shared objects
diff --git a/hw/ioapic_internal.h b/hw/ioapic_internal.h
index bda3608..7d5f735 100644
--- a/hw/ioapic_internal.h
+++ b/hw/ioapic_internal.h
@@ -83,6 +83,7 @@ struct IOAPICState {
 
 void (*pre_save)(IOAPICState *s);
 void (*post_load)(IOAPICState *s);
+uint32_t kvm_gsi_base;
 };
 
 extern const VMStateDescription vmstate_ioapic;
diff --git a/hw/kvm/ioapic.c b/hw/kvm/ioapic.c
new file mode 100644
index 000..680229b
--- /dev/null
+++ b/hw/kvm/ioapic.c
@@ -0,0 +1,120 @@
+/*
+ * KVM in-kernel IOPIC support
+ *
+ * Copyright (c) 2011 Siemens AG
+ *
+ * Authors:
+ *  Jan Kiszka  
+ *
+ * This work is licensed under the terms of the GNU GPL version 2.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static void kvm_ioapic_get(IOAPICState *s)
+{
+struct kvm_irqchip chip;
+struct kvm_ioapic_state *kioapic;
+int ret, i;
+
+chip.chip_id = KVM_IRQCHIP_IOAPIC;
+ret = kvm_vm_ioctl(kvm_state, KVM_GET_IRQCHIP, &chip);
+if (ret < 0) {
+fprintf(stderr, "KVM_GET_IRQCHIP failed: %s\n", strerror(ret));
+abort();
+}
+
+kioapic = &chip.chip.ioapic;
+
+s->id = kioapic->id;
+s->ioregsel = kioapic->ioregsel;
+s->irr = kioapic->irr;
+for (i = 0; i < IOAPIC_NUM_PINS; i++) {
+s->ioredtbl[i] = kioapic->redirtbl[i].bits;
+}
+}
+
+static void kvm_ioapic_put(IOAPICState *s)
+{
+struct kvm_irqchip chip;
+struct kvm_ioapic_state *kioapic;
+int ret, i;
+
+chip.chip_id = KVM_IRQCHIP_IOAPIC;
+kioapic = &chip.chip.ioapic;
+
+kioapic->id = s->id;
+kioapic->ioregsel = s->ioregsel;
+kioapic->base_address = s->busdev.mmio[0].addr;
+kioapic->irr = s->irr;
+for (i = 0; i < IOAPIC_NUM_PINS; i++) {
+kioapic->redirtbl[i].bits = s->ioredtbl[i];
+}
+
+ret = kvm_vm_ioctl(kvm_state, KVM_SET_IRQCHIP, &chip);
+if (ret < 0) {
+fprintf(stderr, "KVM_GET_IRQCHIP failed: %s\n", strerror(ret));
+abort();
+}
+}
+
+static void kvm_ioapic_reset(DeviceState *d)
+{
+IOAPICState *s = DO_UPCAST(IOAPICState, busdev.qdev, d);
+
+ioapic_reset_internal(s);
+
+kvm_ioapic_put(s);
+}
+
+static void kvm_ioapic_set_irq(void *opaque, int irq, int level)
+{
+IOAPICState *s = opaque;
+int delivered;
+
+delivered = kvm_irqchip_set_irq(kvm_state, s->kvm_gsi_base + irq, level);
+apic_set_irq_delivered(delivered);
+}
+
+static int kvm_ioapic_init(SysBusDevice *dev)
+{
+IOAPICState *s = FROM_SYSBUS(IOAPICState, dev);
+
+memory_region_init_reservation(&s->io_memory, "kvm-ioapic", 0x1000);
+
+if (ioapic_init_common(s) < 0) {
+memory_region_destroy(&s->io_memory);
+return -1;
+}
+
+s->pre_save = kvm_ioapic_get;
+s->post_load = kvm_ioapic_put;
+
+qdev_init_gpio_in(&dev->qdev, kvm_ioapic_set_irq, IOAPIC_NUM_PINS);
+
+return 0;
+}
+
+static SysBusDeviceInfo kvm_ioapic_info = {
+.init = kvm_ioapic_init,
+.qdev.name = "kvm-ioapic",
+.qdev.size = sizeof(IOAPICState),
+.qdev.vmsd = &vmstate_ioapic,
+.qdev.reset = kvm_ioapic_reset,
+.qdev.no_user = 1,
+.qdev.props = (Property[]) {
+DEFINE_PROP_UINT32("gsi_base", IOAPICState, kvm_gsi_base, 0),
+DEFINE_PROP_END_OF_LIST(),
+}
+};
+
+static void kvm_ioapic_register_devices(void)
+{
+sysbus_register_withprop(&kvm_ioapic_info);
+}
+
+device_init(kvm_ioapic_register_devices)
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 351b032..624aecd 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -68,6 +68,15 @@ static void kvm_piix3_setup_irq_routing(bool pci_enabled)
 for (i = 8; i < 16; ++i) {
 kvm_irqchip_add_route(s, i, KVM_IRQCHIP_

[Qemu-devel] [RFC][PATCH 01/16] msi: Generalize msix_supported to msi_supported

[Jan Kiszka]

From: Jan Kiszka 

Rename msix_supported to msi_supported and control MSI and MSI-X
activation this way. That was likely to original intention for this
flag, but MSI support came after MSI-X.

Signed-off-by: Jan Kiszka 
---
 hw/msi.c  |8 
 hw/msi.h  |2 ++
 hw/msix.c |9 -
 hw/msix.h |2 --
 hw/pc.c   |4 ++--
 5 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/hw/msi.c b/hw/msi.c
index f214fcf..5d6ceb6 100644
--- a/hw/msi.c
+++ b/hw/msi.c
@@ -36,6 +36,9 @@
 
 #define PCI_MSI_VECTORS_MAX 32
 
+/* Flag for interrupt controller to declare MSI/MSI-X support */
+bool msi_supported;
+
 /* If we get rid of cap allocator, we won't need this. */
 static inline uint8_t msi_cap_sizeof(uint16_t flags)
 {
@@ -116,6 +119,11 @@ int msi_init(struct PCIDevice *dev, uint8_t offset,
 uint16_t flags;
 uint8_t cap_size;
 int config_offset;
+
+if (!msi_supported) {
+return -ENOTSUP;
+}
+
 MSI_DEV_PRINTF(dev,
"init offset: 0x%"PRIx8" vector: %"PRId8
" 64bit %d mask %d\n",
diff --git a/hw/msi.h b/hw/msi.h
index 5766018..3040bb0 100644
--- a/hw/msi.h
+++ b/hw/msi.h
@@ -24,6 +24,8 @@
 #include "qemu-common.h"
 #include "pci.h"
 
+extern bool msi_supported;
+
 bool msi_enabled(const PCIDevice *dev);
 int msi_init(struct PCIDevice *dev, uint8_t offset,
  unsigned int nr_vectors, bool msi64bit, bool msi_per_vector_mask);
diff --git a/hw/msix.c b/hw/msix.c
index b15bafc..8850fbd 100644
--- a/hw/msix.c
+++ b/hw/msix.c
@@ -12,6 +12,7 @@
  */
 
 #include "hw.h"
+#include "msi.h"
 #include "msix.h"
 #include "pci.h"
 #include "range.h"
@@ -32,9 +33,6 @@
 #define MSIX_MAX_ENTRIES 32
 
 
-/* Flag for interrupt controller to declare MSI-X support */
-int msix_supported;
-
 /* Add MSI-X capability to the config space for the device. */
 /* Given a bar and its size, add MSI-X table on top of it
  * and fill MSI-X capability in the config space.
@@ -212,10 +210,11 @@ int msix_init(struct PCIDevice *dev, unsigned short 
nentries,
   unsigned bar_nr, unsigned bar_size)
 {
 int ret;
+
 /* Nothing to do if MSI is not supported by interrupt controller */
-if (!msix_supported)
+if (!msi_supported) {
 return -ENOTSUP;
-
+}
 if (nentries > MSIX_MAX_ENTRIES)
 return -EINVAL;
 
diff --git a/hw/msix.h b/hw/msix.h
index 7e04336..5aba22b 100644
--- a/hw/msix.h
+++ b/hw/msix.h
@@ -29,6 +29,4 @@ void msix_notify(PCIDevice *dev, unsigned vector);
 
 void msix_reset(PCIDevice *dev);
 
-extern int msix_supported;
-
 #endif
diff --git a/hw/pc.c b/hw/pc.c
index 9328ee5..5225d5b 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -36,7 +36,7 @@
 #include "elf.h"
 #include "multiboot.h"
 #include "mc146818rtc.h"
-#include "msix.h"
+#include "msi.h"
 #include "sysbus.h"
 #include "sysemu.h"
 #include "blockdev.h"
@@ -896,7 +896,7 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
 apic_mapped = 1;
 }
 
-msix_supported = 1;
+msi_supported = true;
 
 return dev;
 }
-- 
1.7.3.4

[Qemu-devel] [RFC][PATCH 13/16] kvm: x86: Add user space part for in-kernel APIC

[Jan Kiszka]

From: Jan Kiszka 

This introduces the alternative APIC model 'kvm-apic' which makes use of
KVM's in-kernel device model. MSI is not yet supported, so we disable
this when the in-kernel model is in use.

Signed-off-by: Jan Kiszka 
---
 Makefile.target   |2 +-
 hw/kvm/apic.c |  147 +
 hw/pc.c   |   15 --
 kvm.h |3 +
 target-i386/kvm.c |8 +++
 5 files changed, 169 insertions(+), 6 deletions(-)
 create mode 100644 hw/kvm/apic.c

diff --git a/Makefile.target b/Makefile.target
index 4cd3c0e..66b42d5 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -231,7 +231,7 @@ obj-i386-y += vmport.o
 obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
 obj-i386-y += debugcon.o multiboot.o
 obj-i386-y += pc_piix.o
-obj-i386-$(CONFIG_KVM) += kvm/clock.o
+obj-i386-$(CONFIG_KVM) += kvm/clock.o kvm/apic.o
 obj-i386-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
 
 # shared objects
diff --git a/hw/kvm/apic.c b/hw/kvm/apic.c
new file mode 100644
index 000..fe811b6
--- /dev/null
+++ b/hw/kvm/apic.c
@@ -0,0 +1,147 @@
+/*
+ * KVM in-kernel APIC support
+ *
+ * Copyright (c) 2011 Siemens AG
+ *
+ * Authors:
+ *  Jan Kiszka  
+ *
+ * This work is licensed under the terms of the GNU GPL version 2.
+ * See the COPYING file in the top-level directory.
+ */
+#include 
+#include 
+
+static inline void kvm_apic_set_reg(struct kvm_lapic_state *kapic,
+   int reg_id, uint32_t val)
+{
+*((uint32_t *)(kapic->regs + (reg_id << 4))) = val;
+}
+
+static inline uint32_t kvm_apic_get_reg(struct kvm_lapic_state *kapic,
+   int reg_id)
+{
+return *((uint32_t *)(kapic->regs + (reg_id << 4)));
+}
+
+int kvm_put_apic(CPUState *env)
+{
+APICState *s = DO_UPCAST(APICState, busdev.qdev, env->apic_state);
+struct kvm_lapic_state kapic;
+int i;
+
+if (s && kvm_enabled() && kvm_irqchip_in_kernel()) {
+memset(&kapic, 0, sizeof(kapic));
+kvm_apic_set_reg(&kapic, 0x2, s->id << 24);
+kvm_apic_set_reg(&kapic, 0x8, s->tpr);
+kvm_apic_set_reg(&kapic, 0xd, s->log_dest << 24);
+kvm_apic_set_reg(&kapic, 0xe, s->dest_mode << 28 | 0x0fff);
+kvm_apic_set_reg(&kapic, 0xf, s->spurious_vec);
+for (i = 0; i < 8; i++) {
+kvm_apic_set_reg(&kapic, 0x10 + i, s->isr[i]);
+kvm_apic_set_reg(&kapic, 0x18 + i, s->tmr[i]);
+kvm_apic_set_reg(&kapic, 0x20 + i, s->irr[i]);
+}
+kvm_apic_set_reg(&kapic, 0x28, s->esr);
+kvm_apic_set_reg(&kapic, 0x30, s->icr[0]);
+kvm_apic_set_reg(&kapic, 0x31, s->icr[1]);
+for (i = 0; i < APIC_LVT_NB; i++) {
+kvm_apic_set_reg(&kapic, 0x32 + i, s->lvt[i]);
+}
+kvm_apic_set_reg(&kapic, 0x38, s->initial_count);
+kvm_apic_set_reg(&kapic, 0x3e, s->divide_conf);
+
+return kvm_vcpu_ioctl(env, KVM_SET_LAPIC, &kapic);
+}
+
+return 0;
+}
+
+int kvm_get_apic(CPUState *env)
+{
+APICState *s = DO_UPCAST(APICState, busdev.qdev, env->apic_state);
+struct kvm_lapic_state kapic;
+int ret, i, v;
+
+if (s && kvm_enabled() && kvm_irqchip_in_kernel()) {
+ret = kvm_vcpu_ioctl(env, KVM_GET_LAPIC, &kapic);
+if (ret < 0) {
+return ret;
+}
+
+s->id = kvm_apic_get_reg(&kapic, 0x2) >> 24;
+s->tpr = kvm_apic_get_reg(&kapic, 0x8);
+s->arb_id = kvm_apic_get_reg(&kapic, 0x9);
+s->log_dest = kvm_apic_get_reg(&kapic, 0xd) >> 24;
+s->dest_mode = kvm_apic_get_reg(&kapic, 0xe) >> 28;
+s->spurious_vec = kvm_apic_get_reg(&kapic, 0xf);
+for (i = 0; i < 8; i++) {
+s->isr[i] = kvm_apic_get_reg(&kapic, 0x10 + i);
+s->tmr[i] = kvm_apic_get_reg(&kapic, 0x18 + i);
+s->irr[i] = kvm_apic_get_reg(&kapic, 0x20 + i);
+}
+s->esr = kvm_apic_get_reg(&kapic, 0x28);
+s->icr[0] = kvm_apic_get_reg(&kapic, 0x30);
+s->icr[1] = kvm_apic_get_reg(&kapic, 0x31);
+for (i = 0; i < APIC_LVT_NB; i++) {
+s->lvt[i] = kvm_apic_get_reg(&kapic, 0x32 + i);
+}
+s->initial_count = kvm_apic_get_reg(&kapic, 0x38);
+s->divide_conf = kvm_apic_get_reg(&kapic, 0x3e);
+
+v = (s->divide_conf & 3) | ((s->divide_conf >> 1) & 4);
+s->count_shift = (v + 1) & 7;
+
+s->initial_count_load_time = qemu_get_clock_ns(vm_clock);
+apic_next_timer(s, s->initial_count_load_time);
+}
+return 0;
+}
+
+static void kvm_apic_set_base(APICState *s, uint64_t val)
+{
+s->apicbase = val;
+}
+
+static void kvm_apic_set_tpr(APICState *s, uint8_t val)
+{
+s->tpr = (val & 0x0f) << 4;
+}
+
+static int kvm_apic_init(SysBusDevice *dev)
+{
+APICState *s = FROM_SYSBUS(APICState, dev);
+
+memory_region_init_reservation(&s->io_memory, "kvm-apic-msi",
+   MSI_SPACE_SIZE);
+
+ 

[Qemu-devel] [RFC][PATCH 02/16] kvm: Move kvmclock into hw/kvm folder

[Jan Kiszka]

From: Jan Kiszka 

More KVM-specific devices will come, so let's start with moving the
kvmclock into a dedicated folder.

Signed-off-by: Jan Kiszka 
---
 Makefile.target|4 ++--
 configure  |1 +
 hw/{kvmclock.c => kvm/clock.c} |   10 +-
 hw/{kvmclock.h => kvm/clock.h} |0
 hw/pc_piix.c   |2 +-
 5 files changed, 9 insertions(+), 8 deletions(-)
 rename hw/{kvmclock.c => kvm/clock.c} (96%)
 rename hw/{kvmclock.h => kvm/clock.h} (100%)

diff --git a/Makefile.target b/Makefile.target
index 1e90df7..3a9e95d 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -231,7 +231,7 @@ obj-i386-y += vmport.o
 obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
 obj-i386-y += debugcon.o multiboot.o
 obj-i386-y += pc_piix.o
-obj-i386-$(CONFIG_KVM) += kvmclock.o
+obj-i386-$(CONFIG_KVM) += kvm/clock.o
 obj-i386-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
 
 # shared objects
@@ -421,7 +421,7 @@ qmp-commands-old.h: $(SRC_PATH)/qmp-commands.hx
 
 clean:
rm -f *.o *.a *~ $(PROGS) nwfpe/*.o fpu/*.o
-   rm -f *.d */*.d tcg/*.o ide/*.o 9pfs/*.o
+   rm -f *.d */*.d tcg/*.o ide/*.o 9pfs/*.o kvm/*.o
rm -f hmp-commands.h qmp-commands-old.h gdbstub-xml.c
 ifdef CONFIG_TRACE_SYSTEMTAP
rm -f *.stp
diff --git a/configure b/configure
index 4f87e0a..d768e44 100755
--- a/configure
+++ b/configure
@@ -3220,6 +3220,7 @@ mkdir -p $target_dir/fpu
 mkdir -p $target_dir/tcg
 mkdir -p $target_dir/ide
 mkdir -p $target_dir/9pfs
+mkdir -p $target_dir/kvm
 if test "$target" = "arm-linux-user" -o "$target" = "armeb-linux-user" -o 
"$target" = "arm-bsd-user" -o "$target" = "armeb-bsd-user" ; then
   mkdir -p $target_dir/nwfpe
 fi
diff --git a/hw/kvmclock.c b/hw/kvm/clock.c
similarity index 96%
rename from hw/kvmclock.c
rename to hw/kvm/clock.c
index 5388bc4..aa37c5d 100644
--- a/hw/kvmclock.c
+++ b/hw/kvm/clock.c
@@ -11,11 +11,11 @@
  *
  */
 
-#include "qemu-common.h"
-#include "sysemu.h"
-#include "sysbus.h"
-#include "kvm.h"
-#include "kvmclock.h"
+#include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
diff --git a/hw/kvmclock.h b/hw/kvm/clock.h
similarity index 100%
rename from hw/kvmclock.h
rename to hw/kvm/clock.h
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index c89042f..22997b0 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -34,7 +34,7 @@
 #include "boards.h"
 #include "ide.h"
 #include "kvm.h"
-#include "kvmclock.h"
+#include "kvm/clock.h"
 #include "sysemu.h"
 #include "sysbus.h"
 #include "arch_init.h"
-- 
1.7.3.4

Re: [Qemu-devel] [PATCH V3] Guest stop notification

[Jan Kiszka]

On 2011-12-03 12:42, Marcelo Tosatti wrote:
> On Sat, Dec 03, 2011 at 12:25:37PM +0100, Jan Kiszka wrote:
>> On 2011-12-03 12:19, Marcelo Tosatti wrote:
>>> On Sat, Dec 03, 2011 at 10:06:56AM +0100, Jan Kiszka wrote:
 On 2011-12-02 22:27, Eric B Munson wrote:
> On Fri, 02 Dec 2011, Jan Kiszka wrote:
>
>> On 2011-12-02 20:19, Eric B Munson wrote:
>>> Often when a guest is stopped from the qemu console, it will report 
>>> spurious
>>> soft lockup warnings on resume.  There are kernel patches being 
>>> discussed that
>>> will give the host the ability to tell the guest that it is being 
>>> stopped and
>>> should ignore the soft lockup warning that generates.
>>>
>>> Signed-off-by: Eric B Munson 
>>> Cc: Avi Kivity 
>>> Cc: Marcelo Tosatti 
>>> Cc: Jan Kiszka 
>>> Cc: ry...@linux.vnet.ibm.com
>>> Cc: aligu...@us.ibm.com
>>> Cc: k...@vger.kernel.org
>>>
>>> ---
>>> Changes from V2:
>>>  Move ioctl into hw/kvmclock.c so as other arches can use it as it is
>>> implemented
>>>
>>> Changes from V1:
>>>  Remove unnecessary encapsulating function
>>>
>>>  hw/kvmclock.c |   24 
>>>  1 files changed, 24 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/hw/kvmclock.c b/hw/kvmclock.c
>>> index 5388bc4..756839f 100644
>>> --- a/hw/kvmclock.c
>>> +++ b/hw/kvmclock.c
>>> @@ -16,6 +16,7 @@
>>>  #include "sysbus.h"
>>>  #include "kvm.h"
>>>  #include "kvmclock.h"
>>> +#include "cpu-all.h"
>>>  
>>>  #include 
>>>  #include 
>>> @@ -69,11 +70,34 @@ static void kvmclock_vm_state_change(void *opaque, 
>>> int running,
>>>  }
>>>  }
>>>  
>>> +static void kvmclock_vm_state_change_vcpu(void *opaque, int running,
>>> +  RunState state)
>>> +{
>>> +int ret;
>>> +CPUState *penv = first_cpu;
>>> +
>>> +if (running) {
>>> +   while (penv) {
>>
>> or: for (cpu = first_cpu; cpu != NULL; cpu = cpu->next_cpu) {
>>
>
> Functionally equivalent and I see both in the code, is there a standard?

 Not really. I once tried to introduce an iterator macro, but it was
 refused. The above is just more compact.

 But this is only a minor nit.

>
>>> +ret = kvm_vcpu_ioctl(penv, KVM_GUEST_PAUSED, 0);
>>> +if (ret) {
>>> +if (ret != ENOSYS) {
>>> +fprintf(stderr,
>>> +"kvmclock_vm_state_change_vcpu: %s\n",
>>> +strerror(-ret));
>>> +}
>>> +return;
>>> +}
>>> +penv = (CPUState *)penv->next_cpu;
>>
>> Unneeded cast.
>>
>
> Also following an example seen elsewhere.

 Generally, we try to avoid those pointless casts.

>
>>> +}
>>> +}
>>> +}
>>> +
>>
>> Again: please use checkpatch.pl.
>>
>
> Sorry, tough to get used to hitting space bar that many times...
>
>>>  static int kvmclock_init(SysBusDevice *dev)
>>>  {
>>>  KVMClockState *s = FROM_SYSBUS(KVMClockState, dev);
>>>  
>>>  qemu_add_vm_change_state_handler(kvmclock_vm_state_change, s);
>>> +qemu_add_vm_change_state_handler(kvmclock_vm_state_change_vcpu, 
>>> NULL);
>>>  return 0;
>>>  }
>>>  
>>
>> Why not extend the existing handler?
>
> Because the new handler doesn't touch the KVMClockState object.  If this 
> is
> preferred, I have no objection.

 The separate registration looks strange to me. And the fact that you
 don't need to object doesn't justify a callback of its own.

>
>>
>> I still wonder if the IOCTL interface is actually kvmclock specific. But
>> Marcello asked for this, and we could still change it when some arch
>> comes around that provides it independent of kvmclock.
>
> The flag itself is stored in the pvclock_vcpu_time_info structure, and 
> anything
> else that touches that structure uses ioctls.

 That's the host-guest interface. But I'm talking about the kvm-qemu
 interface here which has no relation to how the "was paused" information
 is transferred to the guest.

 Jan
>>>
>>> It is one simple, rarely used command. I don't see why another interface
>>> such as kvm_run would be beneficial for this case.
>>>
>>
>> I was referring to the relation between the IOCTL and kvmclock, but
>> IOCTL vs. kvm_run.
>>
>> Jan
> 
> Ah, OK. Yes, we better characterize it as KVMCLOCK specific (a generic
> "guest is paused" command is not the scope of this patch).
> 
> So appending KVMCLOCK_ to the ioctl definitions would make that more
> explicit.

IMHO, that would move things in the wrong direc

[Qemu-devel] [RFC][PATCH 16/16] kvm: Arm in-kernel irqchip support

[Jan Kiszka]

From: Jan Kiszka 

Make the basic in-kernel irqchip support selectable via
-machine ...,kernel_irqchip=on. Leave it off by default until it can
fully replace user space models.

Signed-off-by: Jan Kiszka 
---
 qemu-config.c   |4 
 qemu-options.hx |5 -
 2 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/qemu-config.c b/qemu-config.c
index 90b6b3e..fc25115 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -483,6 +483,10 @@ static QemuOptsList qemu_machine_opts = {
 .name = "accel",
 .type = QEMU_OPT_STRING,
 .help = "accelerator list",
+}, {
+.name = "kernel_irqchip",
+.type = QEMU_OPT_BOOL,
+.help = "use KVM in-kernel irqchip",
 },
 { /* End of list */ }
 },
diff --git a/qemu-options.hx b/qemu-options.hx
index 5d2a776..e10186b 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -31,7 +31,8 @@ DEF("machine", HAS_ARG, QEMU_OPTION_machine, \
 "-machine [type=]name[,prop[=value][,...]]\n"
 "selects emulated machine (-machine ? for list)\n"
 "property accel=accel1[:accel2[:...]] selects 
accelerator\n"
-"supported accelerators are kvm, xen, tcg (default: 
tcg)\n",
+"supported accelerators are kvm, xen, tcg (default: tcg)\n"
+"kernel_irqchip=on|off controls accelerated irqchip 
support\n",
 QEMU_ARCH_ALL)
 STEXI
 @item -machine [type=]@var{name}[,prop=@var{value}[,...]]
@@ -44,6 +45,8 @@ This is used to enable an accelerator. Depending on the 
target architecture,
 kvm, xen, or tcg can be available. By default, tcg is used. If there is more
 than one accelerator specified, the next one is used if the previous one fails
 to initialize.
+@item kernel_irqchip=on|off
+Enables in-kernel irqchip support for the chosen accelerator when available.
 @end table
 ETEXI
 
-- 
1.7.3.4

Re: [Qemu-devel] [PATCH V3] Guest stop notification

[Marcelo Tosatti]

On Sat, Dec 03, 2011 at 12:25:37PM +0100, Jan Kiszka wrote:
> On 2011-12-03 12:19, Marcelo Tosatti wrote:
> > On Sat, Dec 03, 2011 at 10:06:56AM +0100, Jan Kiszka wrote:
> >> On 2011-12-02 22:27, Eric B Munson wrote:
> >>> On Fri, 02 Dec 2011, Jan Kiszka wrote:
> >>>
>  On 2011-12-02 20:19, Eric B Munson wrote:
> > Often when a guest is stopped from the qemu console, it will report 
> > spurious
> > soft lockup warnings on resume.  There are kernel patches being 
> > discussed that
> > will give the host the ability to tell the guest that it is being 
> > stopped and
> > should ignore the soft lockup warning that generates.
> >
> > Signed-off-by: Eric B Munson 
> > Cc: Avi Kivity 
> > Cc: Marcelo Tosatti 
> > Cc: Jan Kiszka 
> > Cc: ry...@linux.vnet.ibm.com
> > Cc: aligu...@us.ibm.com
> > Cc: k...@vger.kernel.org
> >
> > ---
> > Changes from V2:
> >  Move ioctl into hw/kvmclock.c so as other arches can use it as it is
> > implemented
> >
> > Changes from V1:
> >  Remove unnecessary encapsulating function
> >
> >  hw/kvmclock.c |   24 
> >  1 files changed, 24 insertions(+), 0 deletions(-)
> >
> > diff --git a/hw/kvmclock.c b/hw/kvmclock.c
> > index 5388bc4..756839f 100644
> > --- a/hw/kvmclock.c
> > +++ b/hw/kvmclock.c
> > @@ -16,6 +16,7 @@
> >  #include "sysbus.h"
> >  #include "kvm.h"
> >  #include "kvmclock.h"
> > +#include "cpu-all.h"
> >  
> >  #include 
> >  #include 
> > @@ -69,11 +70,34 @@ static void kvmclock_vm_state_change(void *opaque, 
> > int running,
> >  }
> >  }
> >  
> > +static void kvmclock_vm_state_change_vcpu(void *opaque, int running,
> > +  RunState state)
> > +{
> > +int ret;
> > +CPUState *penv = first_cpu;
> > +
> > +if (running) {
> > +   while (penv) {
> 
>  or: for (cpu = first_cpu; cpu != NULL; cpu = cpu->next_cpu) {
> 
> >>>
> >>> Functionally equivalent and I see both in the code, is there a standard?
> >>
> >> Not really. I once tried to introduce an iterator macro, but it was
> >> refused. The above is just more compact.
> >>
> >> But this is only a minor nit.
> >>
> >>>
> > +ret = kvm_vcpu_ioctl(penv, KVM_GUEST_PAUSED, 0);
> > +if (ret) {
> > +if (ret != ENOSYS) {
> > +fprintf(stderr,
> > +"kvmclock_vm_state_change_vcpu: %s\n",
> > +strerror(-ret));
> > +}
> > +return;
> > +}
> > +penv = (CPUState *)penv->next_cpu;
> 
>  Unneeded cast.
> 
> >>>
> >>> Also following an example seen elsewhere.
> >>
> >> Generally, we try to avoid those pointless casts.
> >>
> >>>
> > +}
> > +}
> > +}
> > +
> 
>  Again: please use checkpatch.pl.
> 
> >>>
> >>> Sorry, tough to get used to hitting space bar that many times...
> >>>
> >  static int kvmclock_init(SysBusDevice *dev)
> >  {
> >  KVMClockState *s = FROM_SYSBUS(KVMClockState, dev);
> >  
> >  qemu_add_vm_change_state_handler(kvmclock_vm_state_change, s);
> > +qemu_add_vm_change_state_handler(kvmclock_vm_state_change_vcpu, 
> > NULL);
> >  return 0;
> >  }
> >  
> 
>  Why not extend the existing handler?
> >>>
> >>> Because the new handler doesn't touch the KVMClockState object.  If this 
> >>> is
> >>> preferred, I have no objection.
> >>
> >> The separate registration looks strange to me. And the fact that you
> >> don't need to object doesn't justify a callback of its own.
> >>
> >>>
> 
>  I still wonder if the IOCTL interface is actually kvmclock specific. But
>  Marcello asked for this, and we could still change it when some arch
>  comes around that provides it independent of kvmclock.
> >>>
> >>> The flag itself is stored in the pvclock_vcpu_time_info structure, and 
> >>> anything
> >>> else that touches that structure uses ioctls.
> >>
> >> That's the host-guest interface. But I'm talking about the kvm-qemu
> >> interface here which has no relation to how the "was paused" information
> >> is transferred to the guest.
> >>
> >> Jan
> > 
> > It is one simple, rarely used command. I don't see why another interface
> > such as kvm_run would be beneficial for this case.
> > 
> 
> I was referring to the relation between the IOCTL and kvmclock, but
> IOCTL vs. kvm_run.
> 
> Jan

Ah, OK. Yes, we better characterize it as KVMCLOCK specific (a generic
"guest is paused" command is not the scope of this patch).

So appending KVMCLOCK_ to the ioctl definitions would make that more
explicit.

Re: [Qemu-devel] [PATCH 1.0] 9pfs: improve portability to older systems

[Erik Rull]

Paolo Bonzini wrote:

On 11/30/2011 10:27 PM, Erik Rull wrote:

Erik, if you can test on your Debian 4.0 installation, that would be
nice. Thanks!


I will do so. Can you provide me a snapshot (.tgz) of the git? I have
heard that there are possibilities to create the tgz over some web
interfaces of git, but I didn't find them. I have only very restricted
web access.
Please help me for this time and / or provide me a short description how
to do it.
I will then try to give you feedback asap.


You can simply test 1.0 when it comes out. Testing that it compiles would
be 99% of the work. :)

Paolo



No, it does not compile :-( See my mail 2011-12-02 14:22

Best regards,

Erik

Re: [Qemu-devel] [PATCH 1.0] 9pfs: improve portability to older systems

[Erik Rull]

Paolo Bonzini wrote:

On 11/30/2011 10:27 PM, Erik Rull wrote:

Erik, if you can test on your Debian 4.0 installation, that would be
nice. Thanks!


I will do so. Can you provide me a snapshot (.tgz) of the git? I have
heard that there are possibilities to create the tgz over some web
interfaces of git, but I didn't find them. I have only very restricted
web access.
Please help me for this time and / or provide me a short description how
to do it.
I will then try to give you feedback asap.


You can simply test 1.0 when it comes out. Testing that it compiles would
be 99% of the work. :)

Paolo



No, it does not compile :-( See my mail 2011-12-02 14:22

Best regards,

Erik

[Qemu-devel] [RFC][PATCH 14/16] kvm: x86: Add user space part for in-kernel i8259

[Jan Kiszka]

From: Jan Kiszka 

Introduce the alternative 'kvm-i8259' device model that exploits KVM
in-kernel acceleration.

The PIIX3 initialization code is furthermore extended by KVM specific
IRQ route setup. Moreover, GSI injection differs in KVM mode from the
user space model. As we can dispatch ISA-range IRQs to both IOAPIC and
PIC inside the kernel, we do not need to inject them separately. This is
reflected by a KVM-specific GSI handler.

Signed-off-by: Jan Kiszka 
---
 Makefile.target |2 +-
 hw/kvm/i8259.c  |  154 +++
 hw/pc.h |1 +
 hw/pc_piix.c|   50 --
 4 files changed, 202 insertions(+), 5 deletions(-)
 create mode 100644 hw/kvm/i8259.c

diff --git a/Makefile.target b/Makefile.target
index 66b42d5..850b80f 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -231,7 +231,7 @@ obj-i386-y += vmport.o
 obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
 obj-i386-y += debugcon.o multiboot.o
 obj-i386-y += pc_piix.o
-obj-i386-$(CONFIG_KVM) += kvm/clock.o kvm/apic.o
+obj-i386-$(CONFIG_KVM) += kvm/clock.o kvm/apic.o kvm/i8259.o
 obj-i386-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o
 
 # shared objects
diff --git a/hw/kvm/i8259.c b/hw/kvm/i8259.c
new file mode 100644
index 000..9367781
--- /dev/null
+++ b/hw/kvm/i8259.c
@@ -0,0 +1,154 @@
+/*
+ * KVM in-kernel PIC (i8259) support
+ *
+ * Copyright (c) 2011 Siemens AG
+ *
+ * Authors:
+ *  Jan Kiszka  
+ *
+ * This work is licensed under the terms of the GNU GPL version 2.
+ * See the COPYING file in the top-level directory.
+ */
+#include 
+#include 
+#include 
+
+static void kvm_pic_get(PicState *s)
+{
+struct kvm_irqchip chip;
+struct kvm_pic_state *kpic;
+int ret;
+
+chip.chip_id = s->master ? KVM_IRQCHIP_PIC_MASTER : KVM_IRQCHIP_PIC_SLAVE;
+ret = kvm_vm_ioctl(kvm_state, KVM_GET_IRQCHIP, &chip);
+if (ret < 0) {
+fprintf(stderr, "KVM_GET_IRQCHIP failed: %s\n", strerror(ret));
+abort();
+}
+
+kpic = &chip.chip.pic;
+
+s->last_irr = kpic->last_irr;
+s->irr = kpic->irr;
+s->imr = kpic->imr;
+s->isr = kpic->isr;
+s->priority_add = kpic->priority_add;
+s->irq_base = kpic->irq_base;
+s->read_reg_select = kpic->read_reg_select;
+s->poll = kpic->poll;
+s->special_mask = kpic->special_mask;
+s->init_state = kpic->init_state;
+s->auto_eoi = kpic->auto_eoi;
+s->rotate_on_auto_eoi = kpic->rotate_on_auto_eoi;
+s->special_fully_nested_mode = kpic->special_fully_nested_mode;
+s->init4 = kpic->init4;
+s->elcr = kpic->elcr;
+s->elcr_mask = kpic->elcr_mask;
+}
+
+static void kvm_pic_put(PicState *s)
+{
+struct kvm_irqchip chip;
+struct kvm_pic_state *kpic;
+int ret;
+
+chip.chip_id = s->master ? KVM_IRQCHIP_PIC_MASTER : KVM_IRQCHIP_PIC_SLAVE;
+
+kpic = &chip.chip.pic;
+
+kpic->last_irr = s->last_irr;
+kpic->irr = s->irr;
+kpic->imr = s->imr;
+kpic->isr = s->isr;
+kpic->priority_add = s->priority_add;
+kpic->irq_base = s->irq_base;
+kpic->read_reg_select = s->read_reg_select;
+kpic->poll = s->poll;
+kpic->special_mask = s->special_mask;
+kpic->init_state = s->init_state;
+kpic->auto_eoi = s->auto_eoi;
+kpic->rotate_on_auto_eoi = s->rotate_on_auto_eoi;
+kpic->special_fully_nested_mode = s->special_fully_nested_mode;
+kpic->init4 = s->init4;
+kpic->elcr = s->elcr;
+kpic->elcr_mask = s->elcr_mask;
+
+ret = kvm_vm_ioctl(kvm_state, KVM_SET_IRQCHIP, &chip);
+if (ret < 0) {
+fprintf(stderr, "KVM_GET_IRQCHIP failed: %s\n", strerror(ret));
+abort();
+}
+}
+
+static void kvm_pic_reset(DeviceState *dev)
+{
+PicState *s = container_of(dev, PicState, dev.qdev);
+
+pic_reset_internal(s);
+s->elcr = 0;
+
+kvm_pic_put(s);
+}
+
+static void kvm_pic_set_irq(void *opaque, int irq, int level)
+{
+int delivered;
+
+delivered = kvm_irqchip_set_irq(kvm_state, irq, level);
+apic_set_irq_delivered(delivered);
+}
+
+static int kvm_pic_init(ISADevice *dev)
+{
+PicState *s = DO_UPCAST(PicState, dev, dev);
+
+memory_region_init_reservation(&s->base_io, "kvm-pic", 2);
+memory_region_init_reservation(&s->elcr_io, "kvm-elcr", 1);
+
+pic_init_common(s);
+
+s->pre_save = kvm_pic_get;
+s->post_load = kvm_pic_put;
+
+return 0;
+}
+
+qemu_irq *kvm_i8259_init(void)
+{
+ISADevice *dev;
+
+dev = isa_create("kvm-i8259");
+qdev_prop_set_uint32(&dev->qdev, "iobase", 0x20);
+qdev_prop_set_uint32(&dev->qdev, "elcr_addr", 0x4d0);
+qdev_prop_set_bit(&dev->qdev, "master", true);
+qdev_init_nofail(&dev->qdev);
+
+dev = isa_create("kvm-i8259");
+qdev_prop_set_uint32(&dev->qdev, "iobase", 0xa0);
+qdev_prop_set_uint32(&dev->qdev, "elcr_addr", 0x4d1);
+qdev_init_nofail(&dev->qdev);
+
+return qemu_allocate_irqs(kvm_pic_set_irq, NULL, ISA_NUM_IRQS);
+}
+
+static ISADeviceInfo kvm_i8259_info = {
+   

Re: [Qemu-devel] [PATCH V3] Guest stop notification

[Jan Kiszka]

On 2011-12-03 12:19, Marcelo Tosatti wrote:
> On Sat, Dec 03, 2011 at 10:06:56AM +0100, Jan Kiszka wrote:
>> On 2011-12-02 22:27, Eric B Munson wrote:
>>> On Fri, 02 Dec 2011, Jan Kiszka wrote:
>>>
 On 2011-12-02 20:19, Eric B Munson wrote:
> Often when a guest is stopped from the qemu console, it will report 
> spurious
> soft lockup warnings on resume.  There are kernel patches being discussed 
> that
> will give the host the ability to tell the guest that it is being stopped 
> and
> should ignore the soft lockup warning that generates.
>
> Signed-off-by: Eric B Munson 
> Cc: Avi Kivity 
> Cc: Marcelo Tosatti 
> Cc: Jan Kiszka 
> Cc: ry...@linux.vnet.ibm.com
> Cc: aligu...@us.ibm.com
> Cc: k...@vger.kernel.org
>
> ---
> Changes from V2:
>  Move ioctl into hw/kvmclock.c so as other arches can use it as it is
> implemented
>
> Changes from V1:
>  Remove unnecessary encapsulating function
>
>  hw/kvmclock.c |   24 
>  1 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/hw/kvmclock.c b/hw/kvmclock.c
> index 5388bc4..756839f 100644
> --- a/hw/kvmclock.c
> +++ b/hw/kvmclock.c
> @@ -16,6 +16,7 @@
>  #include "sysbus.h"
>  #include "kvm.h"
>  #include "kvmclock.h"
> +#include "cpu-all.h"
>  
>  #include 
>  #include 
> @@ -69,11 +70,34 @@ static void kvmclock_vm_state_change(void *opaque, 
> int running,
>  }
>  }
>  
> +static void kvmclock_vm_state_change_vcpu(void *opaque, int running,
> +  RunState state)
> +{
> +int ret;
> +CPUState *penv = first_cpu;
> +
> +if (running) {
> + while (penv) {

 or: for (cpu = first_cpu; cpu != NULL; cpu = cpu->next_cpu) {

>>>
>>> Functionally equivalent and I see both in the code, is there a standard?
>>
>> Not really. I once tried to introduce an iterator macro, but it was
>> refused. The above is just more compact.
>>
>> But this is only a minor nit.
>>
>>>
> +ret = kvm_vcpu_ioctl(penv, KVM_GUEST_PAUSED, 0);
> +if (ret) {
> +if (ret != ENOSYS) {
> +fprintf(stderr,
> +"kvmclock_vm_state_change_vcpu: %s\n",
> +strerror(-ret));
> +}
> +return;
> +}
> +penv = (CPUState *)penv->next_cpu;

 Unneeded cast.

>>>
>>> Also following an example seen elsewhere.
>>
>> Generally, we try to avoid those pointless casts.
>>
>>>
> +}
> +}
> +}
> +

 Again: please use checkpatch.pl.

>>>
>>> Sorry, tough to get used to hitting space bar that many times...
>>>
>  static int kvmclock_init(SysBusDevice *dev)
>  {
>  KVMClockState *s = FROM_SYSBUS(KVMClockState, dev);
>  
>  qemu_add_vm_change_state_handler(kvmclock_vm_state_change, s);
> +qemu_add_vm_change_state_handler(kvmclock_vm_state_change_vcpu, 
> NULL);
>  return 0;
>  }
>  

 Why not extend the existing handler?
>>>
>>> Because the new handler doesn't touch the KVMClockState object.  If this is
>>> preferred, I have no objection.
>>
>> The separate registration looks strange to me. And the fact that you
>> don't need to object doesn't justify a callback of its own.
>>
>>>

 I still wonder if the IOCTL interface is actually kvmclock specific. But
 Marcello asked for this, and we could still change it when some arch
 comes around that provides it independent of kvmclock.
>>>
>>> The flag itself is stored in the pvclock_vcpu_time_info structure, and 
>>> anything
>>> else that touches that structure uses ioctls.
>>
>> That's the host-guest interface. But I'm talking about the kvm-qemu
>> interface here which has no relation to how the "was paused" information
>> is transferred to the guest.
>>
>> Jan
> 
> It is one simple, rarely used command. I don't see why another interface
> such as kvm_run would be beneficial for this case.
> 

I was referring to the relation between the IOCTL and kvmclock, but
IOCTL vs. kvm_run.

Jan



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH V3] Guest stop notification

[Marcelo Tosatti]

On Sat, Dec 03, 2011 at 10:06:56AM +0100, Jan Kiszka wrote:
> On 2011-12-02 22:27, Eric B Munson wrote:
> > On Fri, 02 Dec 2011, Jan Kiszka wrote:
> > 
> >> On 2011-12-02 20:19, Eric B Munson wrote:
> >>> Often when a guest is stopped from the qemu console, it will report 
> >>> spurious
> >>> soft lockup warnings on resume.  There are kernel patches being discussed 
> >>> that
> >>> will give the host the ability to tell the guest that it is being stopped 
> >>> and
> >>> should ignore the soft lockup warning that generates.
> >>>
> >>> Signed-off-by: Eric B Munson 
> >>> Cc: Avi Kivity 
> >>> Cc: Marcelo Tosatti 
> >>> Cc: Jan Kiszka 
> >>> Cc: ry...@linux.vnet.ibm.com
> >>> Cc: aligu...@us.ibm.com
> >>> Cc: k...@vger.kernel.org
> >>>
> >>> ---
> >>> Changes from V2:
> >>>  Move ioctl into hw/kvmclock.c so as other arches can use it as it is
> >>> implemented
> >>>
> >>> Changes from V1:
> >>>  Remove unnecessary encapsulating function
> >>>
> >>>  hw/kvmclock.c |   24 
> >>>  1 files changed, 24 insertions(+), 0 deletions(-)
> >>>
> >>> diff --git a/hw/kvmclock.c b/hw/kvmclock.c
> >>> index 5388bc4..756839f 100644
> >>> --- a/hw/kvmclock.c
> >>> +++ b/hw/kvmclock.c
> >>> @@ -16,6 +16,7 @@
> >>>  #include "sysbus.h"
> >>>  #include "kvm.h"
> >>>  #include "kvmclock.h"
> >>> +#include "cpu-all.h"
> >>>  
> >>>  #include 
> >>>  #include 
> >>> @@ -69,11 +70,34 @@ static void kvmclock_vm_state_change(void *opaque, 
> >>> int running,
> >>>  }
> >>>  }
> >>>  
> >>> +static void kvmclock_vm_state_change_vcpu(void *opaque, int running,
> >>> +  RunState state)
> >>> +{
> >>> +int ret;
> >>> +CPUState *penv = first_cpu;
> >>> +
> >>> +if (running) {
> >>> + while (penv) {
> >>
> >> or: for (cpu = first_cpu; cpu != NULL; cpu = cpu->next_cpu) {
> >>
> > 
> > Functionally equivalent and I see both in the code, is there a standard?
> 
> Not really. I once tried to introduce an iterator macro, but it was
> refused. The above is just more compact.
> 
> But this is only a minor nit.
> 
> > 
> >>> +ret = kvm_vcpu_ioctl(penv, KVM_GUEST_PAUSED, 0);
> >>> +if (ret) {
> >>> +if (ret != ENOSYS) {
> >>> +fprintf(stderr,
> >>> +"kvmclock_vm_state_change_vcpu: %s\n",
> >>> +strerror(-ret));
> >>> +}
> >>> +return;
> >>> +}
> >>> +penv = (CPUState *)penv->next_cpu;
> >>
> >> Unneeded cast.
> >>
> > 
> > Also following an example seen elsewhere.
> 
> Generally, we try to avoid those pointless casts.
> 
> > 
> >>> +}
> >>> +}
> >>> +}
> >>> +
> >>
> >> Again: please use checkpatch.pl.
> >>
> > 
> > Sorry, tough to get used to hitting space bar that many times...
> > 
> >>>  static int kvmclock_init(SysBusDevice *dev)
> >>>  {
> >>>  KVMClockState *s = FROM_SYSBUS(KVMClockState, dev);
> >>>  
> >>>  qemu_add_vm_change_state_handler(kvmclock_vm_state_change, s);
> >>> +qemu_add_vm_change_state_handler(kvmclock_vm_state_change_vcpu, 
> >>> NULL);
> >>>  return 0;
> >>>  }
> >>>  
> >>
> >> Why not extend the existing handler?
> > 
> > Because the new handler doesn't touch the KVMClockState object.  If this is
> > preferred, I have no objection.
> 
> The separate registration looks strange to me. And the fact that you
> don't need to object doesn't justify a callback of its own.
> 
> > 
> >>
> >> I still wonder if the IOCTL interface is actually kvmclock specific. But
> >> Marcello asked for this, and we could still change it when some arch
> >> comes around that provides it independent of kvmclock.
> > 
> > The flag itself is stored in the pvclock_vcpu_time_info structure, and 
> > anything
> > else that touches that structure uses ioctls.
> 
> That's the host-guest interface. But I'm talking about the kvm-qemu
> interface here which has no relation to how the "was paused" information
> is transferred to the guest.
> 
> Jan

It is one simple, rarely used command. I don't see why another interface
such as kvm_run would be beneficial for this case.

[Qemu-devel] [RFC][PATCH 06/16] i8259: Factor out core for KVM reuse

[Jan Kiszka]

From: Jan Kiszka 

Analogously to the APIC, we will reuse some parts of the user space
i8259 model for KVM. In this case it is the PicState, vmstate
description, a reset core and some init bits.

Signed-off-by: Jan Kiszka 
---
 Makefile.objs   |2 +-
 hw/i8259.c  |   78 +-
 hw/i8259_common.c   |  103 +++
 hw/i8259_internal.h |   67 +
 4 files changed, 174 insertions(+), 76 deletions(-)
 create mode 100644 hw/i8259_common.c
 create mode 100644 hw/i8259_internal.h

diff --git a/Makefile.objs b/Makefile.objs
index 01587c8..5372eec 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -220,7 +220,7 @@ hw-obj-$(CONFIG_APPLESMC) += applesmc.o
 hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o ccid-card-passthru.o
 hw-obj-$(CONFIG_SMARTCARD_NSS) += ccid-card-emulated.o
 hw-obj-$(CONFIG_USB_REDIR) += usb-redir.o
-hw-obj-$(CONFIG_I8259) += i8259.o
+hw-obj-$(CONFIG_I8259) += i8259_common.o i8259.o
 
 # PPC devices
 hw-obj-$(CONFIG_PREP_PCI) += prep_pci.o
diff --git a/hw/i8259.c b/hw/i8259.c
index ab519de..e8a6a9a 100644
--- a/hw/i8259.c
+++ b/hw/i8259.c
@@ -26,6 +26,7 @@
 #include "isa.h"
 #include "monitor.h"
 #include "qemu-timer.h"
+#include "i8259_internal.h"
 
 /* debug PIC */
 //#define DEBUG_PIC
@@ -40,33 +41,6 @@
 //#define DEBUG_IRQ_LATENCY
 //#define DEBUG_IRQ_COUNT
 
-struct PicState {
-ISADevice dev;
-uint8_t last_irr; /* edge detection */
-uint8_t irr; /* interrupt request register */
-uint8_t imr; /* interrupt mask register */
-uint8_t isr; /* interrupt service register */
-uint8_t priority_add; /* highest irq priority */
-uint8_t irq_base;
-uint8_t read_reg_select;
-uint8_t poll;
-uint8_t special_mask;
-uint8_t init_state;
-uint8_t auto_eoi;
-uint8_t rotate_on_auto_eoi;
-uint8_t special_fully_nested_mode;
-uint8_t init4; /* true if 4 byte init */
-uint8_t single_mode; /* true if slave pic is not initialized */
-uint8_t elcr; /* PIIX edge/trigger selection*/
-uint8_t elcr_mask;
-qemu_irq int_out[1];
-uint32_t master; /* reflects /SP input pin */
-uint32_t iobase;
-uint32_t elcr_addr;
-MemoryRegion base_io;
-MemoryRegion elcr_io;
-};
-
 #if defined(DEBUG_PIC) || defined(DEBUG_IRQ_COUNT)
 static int irq_level[16];
 #endif
@@ -248,22 +222,7 @@ int pic_read_irq(PicState *s)
 
 static void pic_init_reset(PicState *s)
 {
-s->last_irr = 0;
-s->irr = 0;
-s->imr = 0;
-s->isr = 0;
-s->priority_add = 0;
-s->irq_base = 0;
-s->read_reg_select = 0;
-s->poll = 0;
-s->special_mask = 0;
-s->init_state = 0;
-s->auto_eoi = 0;
-s->rotate_on_auto_eoi = 0;
-s->special_fully_nested_mode = 0;
-s->init4 = 0;
-s->single_mode = 0;
-/* Note: ELCR is not reset */
+pic_reset_internal(s);
 pic_update_irq(s);
 }
 
@@ -418,32 +377,6 @@ static uint64_t elcr_ioport_read(void *opaque, 
target_phys_addr_t addr,
 return s->elcr;
 }
 
-static const VMStateDescription vmstate_pic = {
-.name = "i8259",
-.version_id = 1,
-.minimum_version_id = 1,
-.minimum_version_id_old = 1,
-.fields = (VMStateField[]) {
-VMSTATE_UINT8(last_irr, PicState),
-VMSTATE_UINT8(irr, PicState),
-VMSTATE_UINT8(imr, PicState),
-VMSTATE_UINT8(isr, PicState),
-VMSTATE_UINT8(priority_add, PicState),
-VMSTATE_UINT8(irq_base, PicState),
-VMSTATE_UINT8(read_reg_select, PicState),
-VMSTATE_UINT8(poll, PicState),
-VMSTATE_UINT8(special_mask, PicState),
-VMSTATE_UINT8(init_state, PicState),
-VMSTATE_UINT8(auto_eoi, PicState),
-VMSTATE_UINT8(rotate_on_auto_eoi, PicState),
-VMSTATE_UINT8(special_fully_nested_mode, PicState),
-VMSTATE_UINT8(init4, PicState),
-VMSTATE_UINT8(single_mode, PicState),
-VMSTATE_UINT8(elcr, PicState),
-VMSTATE_END_OF_LIST()
-}
-};
-
 static const MemoryRegionOps pic_base_ioport_ops = {
 .read = pic_ioport_read,
 .write = pic_ioport_write,
@@ -469,16 +402,11 @@ static int pic_initfn(ISADevice *dev)
 memory_region_init_io(&s->base_io, &pic_base_ioport_ops, s, "pic", 2);
 memory_region_init_io(&s->elcr_io, &pic_elcr_ioport_ops, s, "elcr", 1);
 
-isa_register_ioport(NULL, &s->base_io, s->iobase);
-if (s->elcr_addr != -1) {
-isa_register_ioport(NULL, &s->elcr_io, s->elcr_addr);
-}
+pic_init_common(s);
 
 qdev_init_gpio_out(&dev->qdev, s->int_out, ARRAY_SIZE(s->int_out));
 qdev_init_gpio_in(&dev->qdev, pic_set_irq, 8);
 
-qdev_set_legacy_instance_id(&dev->qdev, s->iobase, 1);
-
 return 0;
 }
 
diff --git a/hw/i8259_common.c b/hw/i8259_common.c
new file mode 100644
index 000..9d2fbc3
--- /dev/null
+++ b/hw/i8259_common.c
@@ -0,0 +1,103 @@
+/*
+ * QEMU 8259 - common bits of emulated and KVM kernel model
+ *
+ * Copyright (c) 2003-2004 Fabrice Bellard
+ * Copyrig

[Qemu-devel] [RFC][PATCH 09/16] ioapic: Factor out core for KVM reuse

[Jan Kiszka]

From: Jan Kiszka 

KVM will share the IOAPICState, the vmstate, the reset logic and certain
init parts with the user space model.

Signed-off-by: Jan Kiszka 
---
 Makefile.target  |2 +-
 hw/ioapic.c  |  108 -
 hw/ioapic_common.c   |   89 +
 hw/ioapic_internal.h |   93 +++
 4 files changed, 192 insertions(+), 100 deletions(-)
 create mode 100644 hw/ioapic_common.c
 create mode 100644 hw/ioapic_internal.h

diff --git a/Makefile.target b/Makefile.target
index 7bb6b13..4cd3c0e 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -226,7 +226,7 @@ obj-$(CONFIG_IVSHMEM) += ivshmem.o
 # Hardware support
 obj-i386-y += vga.o
 obj-i386-y += mc146818rtc.o pc.o
-obj-i386-y += cirrus_vga.o sga.o apic_common.o apic.o ioapic.o piix_pci.o
+obj-i386-y += cirrus_vga.o sga.o apic_common.o apic.o ioapic_common.o ioapic.o 
piix_pci.o
 obj-i386-y += vmport.o
 obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
 obj-i386-y += debugcon.o multiboot.o
diff --git a/hw/ioapic.c b/hw/ioapic.c
index eb75766..8876d5d 100644
--- a/hw/ioapic.c
+++ b/hw/ioapic.c
@@ -24,9 +24,7 @@
 #include "pc.h"
 #include "apic.h"
 #include "ioapic.h"
-#include "qemu-timer.h"
-#include "host-utils.h"
-#include "sysbus.h"
+#include "ioapic_internal.h"
 
 //#define DEBUG_IOAPIC
 
@@ -37,62 +35,6 @@
 #define DPRINTF(fmt, ...)
 #endif
 
-#define MAX_IOAPICS 1
-
-#define IOAPIC_VERSION  0x11
-
-#define IOAPIC_LVT_DEST_SHIFT   56
-#define IOAPIC_LVT_MASKED_SHIFT 16
-#define IOAPIC_LVT_TRIGGER_MODE_SHIFT   15
-#define IOAPIC_LVT_REMOTE_IRR_SHIFT 14
-#define IOAPIC_LVT_POLARITY_SHIFT   13
-#define IOAPIC_LVT_DELIV_STATUS_SHIFT   12
-#define IOAPIC_LVT_DEST_MODE_SHIFT  11
-#define IOAPIC_LVT_DELIV_MODE_SHIFT 8
-
-#define IOAPIC_LVT_MASKED   (1 << IOAPIC_LVT_MASKED_SHIFT)
-#define IOAPIC_LVT_REMOTE_IRR   (1 << IOAPIC_LVT_REMOTE_IRR_SHIFT)
-
-#define IOAPIC_TRIGGER_EDGE 0
-#define IOAPIC_TRIGGER_LEVEL1
-
-/*io{apic,sapic} delivery mode*/
-#define IOAPIC_DM_FIXED 0x0
-#define IOAPIC_DM_LOWEST_PRIORITY   0x1
-#define IOAPIC_DM_PMI   0x2
-#define IOAPIC_DM_NMI   0x4
-#define IOAPIC_DM_INIT  0x5
-#define IOAPIC_DM_SIPI  0x6
-#define IOAPIC_DM_EXTINT0x7
-#define IOAPIC_DM_MASK  0x7
-
-#define IOAPIC_VECTOR_MASK  0xff
-
-#define IOAPIC_IOREGSEL 0x00
-#define IOAPIC_IOWIN0x10
-
-#define IOAPIC_REG_ID   0x00
-#define IOAPIC_REG_VER  0x01
-#define IOAPIC_REG_ARB  0x02
-#define IOAPIC_REG_REDTBL_BASE  0x10
-#define IOAPIC_ID   0x00
-
-#define IOAPIC_ID_SHIFT 24
-#define IOAPIC_ID_MASK  0xf
-
-#define IOAPIC_VER_ENTRIES_SHIFT16
-
-typedef struct IOAPICState IOAPICState;
-
-struct IOAPICState {
-SysBusDevice busdev;
-MemoryRegion io_memory;
-uint8_t id;
-uint8_t ioregsel;
-uint32_t irr;
-uint64_t ioredtbl[IOAPIC_NUM_PINS];
-};
-
 static IOAPICState *ioapics[MAX_IOAPICS];
 
 static void ioapic_service(IOAPICState *s)
@@ -278,44 +220,11 @@ ioapic_mem_write(void *opaque, target_phys_addr_t addr, 
uint64_t val,
 }
 }
 
-static int ioapic_post_load(void *opaque, int version_id)
-{
-IOAPICState *s = opaque;
-
-if (version_id == 1) {
-/* set sane value */
-s->irr = 0;
-}
-return 0;
-}
-
-static const VMStateDescription vmstate_ioapic = {
-.name = "ioapic",
-.version_id = 3,
-.post_load = ioapic_post_load,
-.minimum_version_id = 1,
-.minimum_version_id_old = 1,
-.fields = (VMStateField[]) {
-VMSTATE_UINT8(id, IOAPICState),
-VMSTATE_UINT8(ioregsel, IOAPICState),
-VMSTATE_UNUSED_V(2, 8), /* to account for qemu-kvm's v2 format */
-VMSTATE_UINT32_V(irr, IOAPICState, 2),
-VMSTATE_UINT64_ARRAY(ioredtbl, IOAPICState, IOAPIC_NUM_PINS),
-VMSTATE_END_OF_LIST()
-}
-};
-
 static void ioapic_reset(DeviceState *d)
 {
 IOAPICState *s = DO_UPCAST(IOAPICState, busdev.qdev, d);
-int i;
 
-s->id = 0;
-s->ioregsel = 0;
-s->irr = 0;
-for (i = 0; i < IOAPIC_NUM_PINS; i++) {
-s->ioredtbl[i] = 1 << IOAPIC_LVT_MASKED_SHIFT;
-}
+ioapic_reset_internal(s);
 }
 
 static const MemoryRegionOps ioapic_io_ops = {
@@ -327,18 +236,19 @@ static const MemoryRegionOps ioapic_io_ops = {
 static int ioapic_init1(SysBusDevice *dev)
 {
 IOAPICState *s = FROM_SYSBUS(IOAPICState, dev);
-static int ioapic_no;
+int ioapic_no;
 
-if (ioapic_no >= MAX_IOAPICS) {
+memory_region_init_io(&s->io_memory, &ioapic_io_ops, s, "ioapic", 0x1000);
+
+ioapic_no = ioapic_init_common(s);
+if (ioapic_no < 0

[Qemu-devel] [RFC][PATCH 12/16] kvm: x86: Establish IRQ0 override control

[Jan Kiszka]

From: Jan Kiszka 

KVM is forced to disable the IRQ0 override when we run with in-kernel
irqchip but without IRQ routing support of the kernel. Set the fwcfg
value correspondingly. This aligns us with qemu-kvm.

Signed-off-by: Jan Kiszka 
---
 hw/pc.c|3 ++-
 kvm-all.c  |5 +
 kvm-stub.c |5 +
 kvm.h  |2 ++
 sysemu.h   |1 -
 vl.c   |1 -
 6 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/hw/pc.c b/hw/pc.c
index 5225d5b..715cc63 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -39,6 +39,7 @@
 #include "msi.h"
 #include "sysbus.h"
 #include "sysemu.h"
+#include "kvm.h"
 #include "blockdev.h"
 #include "ui/qemu-spice.h"
 #include "memory.h"
@@ -609,7 +610,7 @@ static void *bochs_bios_init(void)
 fw_cfg_add_i64(fw_cfg, FW_CFG_RAM_SIZE, (uint64_t)ram_size);
 fw_cfg_add_bytes(fw_cfg, FW_CFG_ACPI_TABLES, (uint8_t *)acpi_tables,
  acpi_tables_len);
-fw_cfg_add_bytes(fw_cfg, FW_CFG_IRQ0_OVERRIDE, &irq0override, 1);
+fw_cfg_add_i32(fw_cfg, FW_CFG_IRQ0_OVERRIDE, kvm_allows_irq0_override());
 
 smbios_table = smbios_get_table(&smbios_len);
 if (smbios_table)
diff --git a/kvm-all.c b/kvm-all.c
index a85e14f..665455c 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -1260,6 +1260,11 @@ int kvm_has_gsi_routing(void)
 return kvm_check_extension(kvm_state, KVM_CAP_IRQ_ROUTING);
 }
 
+int kvm_allows_irq0_override(void)
+{
+return !kvm_enabled() || !kvm_irqchip_in_kernel() || kvm_has_gsi_routing();
+}
+
 void kvm_setup_guest_memory(void *start, size_t size)
 {
 if (!kvm_has_sync_mmu()) {
diff --git a/kvm-stub.c b/kvm-stub.c
index 06064b9..6c2b06b 100644
--- a/kvm-stub.c
+++ b/kvm-stub.c
@@ -78,6 +78,11 @@ int kvm_has_many_ioeventfds(void)
 return 0;
 }
 
+int kvm_allows_irq0_override(void)
+{
+return 1;
+}
+
 void kvm_setup_guest_memory(void *start, size_t size)
 {
 }
diff --git a/kvm.h b/kvm.h
index 0d6c453..a3c87af 100644
--- a/kvm.h
+++ b/kvm.h
@@ -53,6 +53,8 @@ int kvm_has_xcrs(void);
 int kvm_has_many_ioeventfds(void);
 int kvm_has_gsi_routing(void);
 
+int kvm_allows_irq0_override(void);
+
 #ifdef NEED_CPU_H
 int kvm_init_vcpu(CPUState *env);
 
diff --git a/sysemu.h b/sysemu.h
index 22cd720..3bd896e 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -102,7 +102,6 @@ extern int vga_interface_type;
 extern int graphic_width;
 extern int graphic_height;
 extern int graphic_depth;
-extern uint8_t irq0override;
 extern DisplayType display_type;
 extern const char *keyboard_layout;
 extern int win2k_install_hack;
diff --git a/vl.c b/vl.c
index fcce25f..22d02b9 100644
--- a/vl.c
+++ b/vl.c
@@ -218,7 +218,6 @@ int no_reboot = 0;
 int no_shutdown = 0;
 int cursor_hide = 1;
 int graphic_rotate = 0;
-uint8_t irq0override = 1;
 const char *watchdog;
 QEMUOptionRom option_rom[MAX_OPTION_ROMS];
 int nb_option_roms;
-- 
1.7.3.4

[Qemu-devel] [RFC][PATCH 03/16] apic: Stop timer on reset

[Jan Kiszka]

From: Jan Kiszka 

All LVTs are masked on reset, so the timer becomes ineffective. Letting
it tick nevertheless is harmless, but will at least create a spurious
trace event.

Signed-off-by: Jan Kiszka 
---
 hw/apic.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/hw/apic.c b/hw/apic.c
index 8289eef..2644a82 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -528,6 +528,8 @@ void apic_init_reset(DeviceState *d)
 s->initial_count_load_time = 0;
 s->next_time = 0;
 s->wait_for_sipi = 1;
+
+qemu_del_timer(s->timer);
 }
 
 static void apic_startup(APICState *s, int vector_num)
-- 
1.7.3.4

Re: [Qemu-devel] [PATCH for v1.0 1/3] msix: track function masked in pci device state

[Jan Kiszka]

On 2011-12-03 00:34, Cam Macdonell wrote:
> So I believe my bug is due to the fact the new logic included in this
> patch requires msix_write_config() to be called to unmask the vectors.
>  Virtio-pci calls msix_write_config(), but ivshmem does not (nor does
> PCIe so I'm not sure if it's also affected).

msi[x]_write_config should not have to be called from device models but
it must be right now. I proposed a patch a while ago to improve this.
Same for msix_reset.

Jan



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH] Convert keymap file to UTF-8 encoding

[Peter Maydell]

On 3 December 2011 09:45, Stefan Weil  wrote:
> Most QEMU files either are pure ASCII or use UTF-8.
> Convert this keymap file which still used ISO-8859-1 to UTF-8.

Good catch -- I'd assumed the keymap files were binary :-)

-- PMM

[Qemu-devel] [PATCH] Convert keymap file to UTF-8 encoding

[Stefan Weil]

Most QEMU files either are pure ASCII or use UTF-8.
Convert this keymap file which still used ISO-8859-1 to UTF-8.

Signed-off-by: Stefan Weil 
---
 pc-bios/keymaps/is |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/pc-bios/keymaps/is b/pc-bios/keymaps/is
index 21dc1fd..935ac1d 100644
--- a/pc-bios/keymaps/is
+++ b/pc-bios/keymaps/is
@@ -1,4 +1,4 @@
-# 2004-03-16 Halld�r Gu�mundsson and Morten Lange
+# 2004-03-16 Halldór Guðmundsson and Morten Lange
 # Keyboard definition file for the Icelandic keyboard
 # to be used in rdesktop 1.3.x ( See rdesktop.org)
 # generated from XKB map de, and changed manually
-- 
1.7.0.4

Re: [Qemu-devel] [PATCH V3] Guest stop notification

[Jan Kiszka]

On 2011-12-02 22:27, Eric B Munson wrote:
> On Fri, 02 Dec 2011, Jan Kiszka wrote:
> 
>> On 2011-12-02 20:19, Eric B Munson wrote:
>>> Often when a guest is stopped from the qemu console, it will report spurious
>>> soft lockup warnings on resume.  There are kernel patches being discussed 
>>> that
>>> will give the host the ability to tell the guest that it is being stopped 
>>> and
>>> should ignore the soft lockup warning that generates.
>>>
>>> Signed-off-by: Eric B Munson 
>>> Cc: Avi Kivity 
>>> Cc: Marcelo Tosatti 
>>> Cc: Jan Kiszka 
>>> Cc: ry...@linux.vnet.ibm.com
>>> Cc: aligu...@us.ibm.com
>>> Cc: k...@vger.kernel.org
>>>
>>> ---
>>> Changes from V2:
>>>  Move ioctl into hw/kvmclock.c so as other arches can use it as it is
>>> implemented
>>>
>>> Changes from V1:
>>>  Remove unnecessary encapsulating function
>>>
>>>  hw/kvmclock.c |   24 
>>>  1 files changed, 24 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/hw/kvmclock.c b/hw/kvmclock.c
>>> index 5388bc4..756839f 100644
>>> --- a/hw/kvmclock.c
>>> +++ b/hw/kvmclock.c
>>> @@ -16,6 +16,7 @@
>>>  #include "sysbus.h"
>>>  #include "kvm.h"
>>>  #include "kvmclock.h"
>>> +#include "cpu-all.h"
>>>  
>>>  #include 
>>>  #include 
>>> @@ -69,11 +70,34 @@ static void kvmclock_vm_state_change(void *opaque, int 
>>> running,
>>>  }
>>>  }
>>>  
>>> +static void kvmclock_vm_state_change_vcpu(void *opaque, int running,
>>> +  RunState state)
>>> +{
>>> +int ret;
>>> +CPUState *penv = first_cpu;
>>> +
>>> +if (running) {
>>> +   while (penv) {
>>
>> or: for (cpu = first_cpu; cpu != NULL; cpu = cpu->next_cpu) {
>>
> 
> Functionally equivalent and I see both in the code, is there a standard?

Not really. I once tried to introduce an iterator macro, but it was
refused. The above is just more compact.

But this is only a minor nit.

> 
>>> +ret = kvm_vcpu_ioctl(penv, KVM_GUEST_PAUSED, 0);
>>> +if (ret) {
>>> +if (ret != ENOSYS) {
>>> +fprintf(stderr,
>>> +"kvmclock_vm_state_change_vcpu: %s\n",
>>> +strerror(-ret));
>>> +}
>>> +return;
>>> +}
>>> +penv = (CPUState *)penv->next_cpu;
>>
>> Unneeded cast.
>>
> 
> Also following an example seen elsewhere.

Generally, we try to avoid those pointless casts.

> 
>>> +}
>>> +}
>>> +}
>>> +
>>
>> Again: please use checkpatch.pl.
>>
> 
> Sorry, tough to get used to hitting space bar that many times...
> 
>>>  static int kvmclock_init(SysBusDevice *dev)
>>>  {
>>>  KVMClockState *s = FROM_SYSBUS(KVMClockState, dev);
>>>  
>>>  qemu_add_vm_change_state_handler(kvmclock_vm_state_change, s);
>>> +qemu_add_vm_change_state_handler(kvmclock_vm_state_change_vcpu, NULL);
>>>  return 0;
>>>  }
>>>  
>>
>> Why not extend the existing handler?
> 
> Because the new handler doesn't touch the KVMClockState object.  If this is
> preferred, I have no objection.

The separate registration looks strange to me. And the fact that you
don't need to object doesn't justify a callback of its own.

> 
>>
>> I still wonder if the IOCTL interface is actually kvmclock specific. But
>> Marcello asked for this, and we could still change it when some arch
>> comes around that provides it independent of kvmclock.
> 
> The flag itself is stored in the pvclock_vcpu_time_info structure, and 
> anything
> else that touches that structure uses ioctls.

That's the host-guest interface. But I'm talking about the kvm-qemu
interface here which has no relation to how the "was paused" information
is transferred to the guest.

Jan



signature.asc
Description: OpenPGP digital signature