[Qemu-devel] [RFC PATCH V1 09/14] xilinx_intc: Added fdt generic platform support

2011-08-25 Thread Peter A. G. Crosthwaite
Signed-off-by: Peter A. G. Crosthwaite 
---
 hw/xilinx_intc.c |   35 ++-
 1 files changed, 34 insertions(+), 1 deletions(-)

diff --git a/hw/xilinx_intc.c b/hw/xilinx_intc.c
index cb72d5a..aa7783a 100644
--- a/hw/xilinx_intc.c
+++ b/hw/xilinx_intc.c
@@ -158,9 +158,11 @@ static int xilinx_intc_init(SysBusDevice *dev)
 return 0;
 }
 
+#define QDEV_NAME "xilinx,intc"
+
 static SysBusDeviceInfo xilinx_intc_info = {
 .init = xilinx_intc_init,
-.qdev.name  = "xilinx,intc",
+.qdev.name  = QDEV_NAME,
 .qdev.size  = sizeof(struct xlx_pic),
 .qdev.props = (Property[]) {
 DEFINE_PROP_UINT32("kind-of-intr", struct xlx_pic, c_kind_of_intr, 0),
@@ -174,3 +176,34 @@ static void xilinx_intc_register(void)
 }
 
 device_init(xilinx_intc_register)
+
+#ifdef CONFIG_FDT
+
+#include "fdt_generic_qdev.h"
+
+static FDTQDevPropMapping *
+xilinx_intc_fdt_qdev_map(char *node_path, FDTMachineInfo *fdti)
+{
+FDTQDevPropMapping *ret = g_malloc0(sizeof(*ret) * 2);
+struct FDTQDevPropMapping sprops [] = {
+{
+.name = "kind-of-intr",
+.src.u32 = qemu_devtree_getprop(fdti->fdt, NULL, node_path,
+"xlnx,kind-of-intr", 0, 0)
+},{
+   .name = NULL
+}
+};
+return memcpy(ret, sprops, sizeof(*ret) * 2);
+}
+
+FDTQDevOps xilinx_intc_fdt_qdev_ops = {
+.dev_name = QDEV_NAME,
+.is_intc = 32,
+.map = xilinx_intc_fdt_qdev_map,
+};
+
+fdt_qdev_register_compatibility(&xilinx_intc_fdt_qdev_ops,
+"xlnx,xps-intc-1.00.a");
+
+#endif /* CONFIG_FDT */
-- 
1.7.3.2




[Qemu-devel] [RFC PATCH V1 10/14] xilinx_ethlite: Added fdt generic platform support

2011-08-25 Thread Peter A. G. Crosthwaite
Signed-off-by: Peter A. G. Crosthwaite 
---
 hw/xilinx_ethlite.c |   39 ++-
 1 files changed, 38 insertions(+), 1 deletions(-)

diff --git a/hw/xilinx_ethlite.c b/hw/xilinx_ethlite.c
index f35ba84..c06b015 100644
--- a/hw/xilinx_ethlite.c
+++ b/hw/xilinx_ethlite.c
@@ -221,9 +221,11 @@ static int xilinx_ethlite_init(SysBusDevice *dev)
 return 0;
 }
 
+#define QDEV_NAME "xilinx,ethlite"
+
 static SysBusDeviceInfo xilinx_ethlite_info = {
 .init = xilinx_ethlite_init,
-.qdev.name  = "xilinx,ethlite",
+.qdev.name  = QDEV_NAME,
 .qdev.size  = sizeof(struct xlx_ethlite),
 .qdev.props = (Property[]) {
 DEFINE_PROP_UINT32("txpingpong", struct xlx_ethlite, c_tx_pingpong, 1),
@@ -239,3 +241,38 @@ static void xilinx_ethlite_register(void)
 }
 
 device_init(xilinx_ethlite_register)
+
+#ifdef CONFIG_FDT
+
+#include "fdt_generic_qdev.h"
+
+static FDTQDevPropMapping *
+xilinx_ethlite_fdt_qdev_map(char *node_path, FDTMachineInfo *fdti)
+{
+FDTQDevPropMapping *ret = g_malloc0(sizeof(*ret) * 3);
+struct FDTQDevPropMapping sprops [] = {
+{
+.name = "txpingpong",
+.src.u32 = qemu_devtree_getprop(fdti->fdt, NULL, node_path,
+"xlnx,tx-ping-pong", 0, 0)
+},{
+.name = "rxpingpong",
+.src.u32 = qemu_devtree_getprop(fdti->fdt, NULL, node_path,
+"xlnx,rx-ping-pong", 0, 0)
+},{
+   .name = NULL
+}
+};
+return memcpy(ret, sprops, sizeof(*ret) * 3);
+}
+
+FDTQDevOps xilinx_ethlite_fdt_qdev_ops = {
+.dev_name = QDEV_NAME,
+.is_nic = 1,
+.map = xilinx_ethlite_fdt_qdev_map,
+};
+
+fdt_qdev_register_compatibility(&xilinx_ethlite_fdt_qdev_ops,
+"xlnx,xps-ethernetlite-1.00.a");
+
+#endif /*CONFIG_FDT */
-- 
1.7.3.2




[Qemu-devel] [RFC PATCH V1 08/14] xilinx_timer: Added fdt_generic platform support

2011-08-25 Thread Peter A. G. Crosthwaite
Signed-off-by: Peter A. G. Crosthwaite 
---
 hw/xilinx_timer.c |   39 ++-
 1 files changed, 38 insertions(+), 1 deletions(-)

diff --git a/hw/xilinx_timer.c b/hw/xilinx_timer.c
index f1c7abc..8fe32f6 100644
--- a/hw/xilinx_timer.c
+++ b/hw/xilinx_timer.c
@@ -215,9 +215,11 @@ static int xilinx_timer_init(SysBusDevice *dev)
 return 0;
 }
 
+#define QDEV_NAME "xilinx,timer"
+
 static SysBusDeviceInfo xilinx_timer_info = {
 .init = xilinx_timer_init,
-.qdev.name  = "xilinx,timer",
+.qdev.name  = QDEV_NAME,
 .qdev.size  = sizeof(struct timerblock),
 .qdev.props = (Property[]) {
 DEFINE_PROP_UINT32("frequency", struct timerblock, freq_hz,   0),
@@ -232,3 +234,38 @@ static void xilinx_timer_register(void)
 }
 
 device_init(xilinx_timer_register)
+
+#ifdef CONFIG_FDT
+
+#include "fdt_generic_qdev.h"
+
+#define FREQ_HZ (62 * 100)
+
+static FDTQDevPropMapping *
+xilinx_timer_fdt_qdev_map(char *node_path, FDTMachineInfo *fdti)
+{
+FDTQDevPropMapping *ret = g_malloc0(sizeof(*ret) * 3);
+struct FDTQDevPropMapping sprops [] = {
+{
+.name = "frequency",
+.src.u32 = FREQ_HZ
+},{
+.name = "nr-timers",
+.src.u32 = 2 - qemu_devtree_getprop(fdti->fdt, NULL, node_path,
+  "xlnx,one-timer-only", 0, 0)
+},{
+   .name = NULL
+}
+};
+return memcpy(ret, sprops, sizeof(*ret) * 3);
+}
+
+FDTQDevOps xilinx_timer_fdt_qdev_ops = {
+.dev_name = QDEV_NAME,
+.map = xilinx_timer_fdt_qdev_map,
+};
+
+fdt_qdev_register_compatibility(&xilinx_timer_fdt_qdev_ops,
+"xlnx,xps-timer-1.00.a");
+
+#endif /* CONFIG_FDT */
-- 
1.7.3.2




[Qemu-devel] [RFC PATCH V1 11/14] vl.c: Added hw_dtb/kern_dtb command line opts

2011-08-25 Thread Peter A. G. Crosthwaite
Added command line options to specify device-tree-blobs for fdt generic
platforms. Different dtbs can be used for software and harware by using
both options concurrently

Signed-off-by: Peter A. G. Crosthwaite 
---
 qemu-options.hx |   47 +++
 sysemu.h|4 
 vl.c|   19 +++
 3 files changed, 70 insertions(+), 0 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index d86815d..b778471 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2444,6 +2444,53 @@ Specify a trace file to log output traces to.
 ETEXI
 #endif
 
+HXCOMM Flat device-tree commandline options
+DEFHEADING()
+DEFHEADING(Flat device-tree options:)
+STEXI
+@table @option
+ETEXI
+
+DEF("hw-dtb", HAS_ARG, QEMU_OPTION_hwdtb, \
+"-hw-dtb dtb  flat device tree describing hardware system\n",
+QEMU_ARCH_MICROBLAZE | QEMU_ARCH_PPC)
+STEXI
+@item -hw-dtb @var{hw-dtb}
+use @var{hw-dtb} as flat device tree describing hardware system
+ETEXI
+
+DEF("kern-dtb", HAS_ARG, QEMU_OPTION_kerndtb, \
+"-kern-dtb dtb   flat device tree passed to kernel boot\n",
+QEMU_ARCH_MICROBLAZE | QEMU_ARCH_PPC)
+STEXI
+@item -kern-dtb @var{kern-dtb}
+use @var{kern-dtb} as flat device tree passed to kernel boot
+ETEXI
+
+STEXI
+@end table
+ETEXI
+
+
+HXCOMM AXIS device specific commandline options
+DEFHEADING()
+DEFHEADING(AXIS device options:)
+STEXI
+@table @option
+ETEXI
+
+DEF("bootsel", HAS_ARG, QEMU_OPTION_bootsel, \
+"-bootsel  Reset value of boot select register\n",
+QEMU_ARCH_CRIS | QEMU_ARCH_MIPS | QEMU_ARCH_ARM)
+STEXI
+@item -bootsel @var{bootsel}
+use @var{bootsel} as the reset value for the bootsel register.
+ETEXI
+
+STEXI
+@end table
+ETEXI
+
 HXCOMM This is the last statement. Insert new options before this line!
 STEXI
 @end table
diff --git a/sysemu.h b/sysemu.h
index 9090457..2108a67 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -122,6 +122,10 @@ extern int no_quit;
 extern int no_shutdown;
 extern int semihosting_enabled;
 extern int old_param;
+
+extern const char *qemu_hwdtb;
+extern const char *qemu_kerndtb;
+
 extern int boot_menu;
 extern uint8_t *boot_splash_filedata;
 extern int boot_splash_filedata_size;
diff --git a/vl.c b/vl.c
index 9cd67a3..38cc153 100644
--- a/vl.c
+++ b/vl.c
@@ -227,6 +227,10 @@ int alt_grab = 0;
 int ctrl_grab = 0;
 unsigned int nb_prom_envs = 0;
 const char *prom_envs[MAX_PROM_ENVS];
+#ifdef CONFIG_FDT
+const char *qemu_hwdtb = NULL;
+const char *qemu_kerndtb = NULL;
+#endif
 int boot_menu;
 uint8_t *boot_splash_filedata;
 int boot_splash_filedata_size;
@@ -2928,6 +2932,21 @@ int main(int argc, char **argv, char **envp)
 }
 xen_mode = XEN_ATTACH;
 break;
+#ifdef CONFIG_FDT
+case QEMU_OPTION_hwdtb:
+qemu_hwdtb = optarg;
+break;
+case QEMU_OPTION_kerndtb:
+qemu_kerndtb = optarg;
+break;
+#else
+case QEMU_OPTION_hwdtb:
+case QEMU_OPTION_kerndtb:
+printf("Option %s not supported by this qemu build"
+" (libfdt missing).\n", popt->name);
+exit(1);
+break;
+#endif
 #ifdef CONFIG_SIMPLE_TRACE
 case QEMU_OPTION_trace:
 opts = qemu_opts_parse(qemu_find_opts("trace"), optarg, 0);
-- 
1.7.3.2




[Qemu-devel] [PATCH] disasm: update comment

2011-08-25 Thread Frediano Ziglio

Signed-off-by: Frediano Ziglio 
---
 disas.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/disas.c b/disas.c
index 1334b8e..611b30b 100644
--- a/disas.c
+++ b/disas.c
@@ -137,7 +137,7 @@ print_insn_thumb1(bfd_vma pc, disassemble_info *info)
 
 /* Disassemble this for me please... (debugging). 'flags' has the following
values:
-i386 - nonzero means 16 bit code
+i386 - 1 means 16 bit code, 2 means 64 bit code
 arm  - nonzero means thumb code
 ppc  - nonzero means little endian
 other targets - unused
-- 
1.7.1




Re: [Qemu-devel] [PATCH v3 5/6] vga: Use linear mapping + dirty logging in chain 4 memory access mode

2011-08-25 Thread Avi Kivity

On 08/22/2011 08:12 PM, Jan Kiszka wrote:

Most VGA memory access modes require MMIO handling as they demand weird
logic to get a byte from or into the video RAM. However, there is one
exception: chain 4 mode with all memory planes enabled for writing. This
mode actually allows lineary mapping, which can then be combined with
dirty logging to accelerate KVM.

This patch accelerates specifically VBE accesses like they are used by
grub in graphical mode. Not only the standard VGA adapter benefits from
this, also vmware and spice in VGA mode.




On which version of grub does this work?  This isn't having any effect 
on my Fedora grub.


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.




[Qemu-devel] [PATCH] qcow2: use always stderr for debugging

2011-08-25 Thread Frediano Ziglio
let all DEBUG_ALLOC2 printf goes to stderr

Signed-off-by: Frediano Ziglio 
---
 block/qcow2-cluster.c  |2 +-
 block/qcow2-refcount.c |4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 9269dda..9034840 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -53,7 +53,7 @@ int qcow2_grow_l1_table(BlockDriverState *bs, int min_size, 
bool exact_size)
 }
 
 #ifdef DEBUG_ALLOC2
-printf("grow l1_table from %d to %d\n", s->l1_size, new_l1_size);
+fprintf(stderr, "grow l1_table from %d to %d\n", s->l1_size, new_l1_size);
 #endif
 
 new_l1_size2 = sizeof(uint64_t) * new_l1_size;
diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c
index 2a915be..fbf28da 100644
--- a/block/qcow2-refcount.c
+++ b/block/qcow2-refcount.c
@@ -422,7 +422,7 @@ static int QEMU_WARN_UNUSED_RESULT 
update_refcount(BlockDriverState *bs,
 int ret;
 
 #ifdef DEBUG_ALLOC2
-printf("update_refcount: offset=%" PRId64 " size=%" PRId64 " addend=%d\n",
+fprintf(stderr, "update_refcount: offset=%" PRId64 " size=%" PRId64 " 
addend=%d\n",
offset, length, addend);
 #endif
 if (length < 0) {
@@ -556,7 +556,7 @@ retry:
 }
 }
 #ifdef DEBUG_ALLOC2
-printf("alloc_clusters: size=%" PRId64 " -> %" PRId64 "\n",
+fprintf(stderr, "alloc_clusters: size=%" PRId64 " -> %" PRId64 "\n",
 size,
 (s->free_cluster_index - nb_clusters) << s->cluster_bits);
 #endif
-- 
1.7.1




[Qemu-devel] [PATCH] qcow2: remove unused qcow2_create_refcount_update function

2011-08-25 Thread Frediano Ziglio

Signed-off-by: Frediano Ziglio 
---
 block/qcow2-refcount.c |   18 --
 block/qcow2.h  |2 --
 2 files changed, 0 insertions(+), 20 deletions(-)

diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c
index 2a915be..62946bb 100644
--- a/block/qcow2-refcount.c
+++ b/block/qcow2-refcount.c
@@ -680,24 +680,6 @@ void qcow2_free_any_clusters(BlockDriverState *bs,
 
 
 
-void qcow2_create_refcount_update(QCowCreateState *s, int64_t offset,
-int64_t size)
-{
-int refcount;
-int64_t start, last, cluster_offset;
-uint16_t *p;
-
-start = offset & ~(s->cluster_size - 1);
-last = (offset + size - 1)  & ~(s->cluster_size - 1);
-for(cluster_offset = start; cluster_offset <= last;
-cluster_offset += s->cluster_size) {
-p = &s->refcount_block[cluster_offset >> s->cluster_bits];
-refcount = be16_to_cpu(*p);
-refcount++;
-*p = cpu_to_be16(refcount);
-}
-}
-
 /* update the refcounts of snapshots and the copied flag */
 int qcow2_update_snapshot_refcount(BlockDriverState *bs,
 int64_t l1_table_offset, int l1_size, int addend)
diff --git a/block/qcow2.h b/block/qcow2.h
index de23abe..c8ca3bc 100644
--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -189,8 +189,6 @@ void qcow2_free_clusters(BlockDriverState *bs,
 void qcow2_free_any_clusters(BlockDriverState *bs,
 uint64_t cluster_offset, int nb_clusters);
 
-void qcow2_create_refcount_update(QCowCreateState *s, int64_t offset,
-int64_t size);
 int qcow2_update_snapshot_refcount(BlockDriverState *bs,
 int64_t l1_table_offset, int l1_size, int addend);
 
-- 
1.7.1




Re: [Qemu-devel] Guest kernel device compatability auto-detection

2011-08-25 Thread Richard W.M. Jones
On Thu, Aug 25, 2011 at 08:33:04AM +0300, Avi Kivity wrote:
> On 08/25/2011 08:21 AM, Sasha Levin wrote:
> >Hi,
> >
> >Currently when we run the guest we treat it as a black box, we're not
> >quite sure what it's going to start and whether it supports the same
> >features we expect it to support when running it from the host.
> >
> >This forces us to start the guest with the safest defaults possible, for
> >example: '-drive file=my_image.qcow2' will be started with slow IDE
> >emulation even though the guest is capable of virtio.
> >
> >I'm currently working on a method to try and detect whether the guest
> >kernel has specific configurations enabled and either warn the user if
> >we know the kernel is not going to properly work or use better defaults
> >if we know some advanced features are going to work.
> >
> >How am I planning to do it? First, we'll try finding which kernel the
> >guest is going to boot (easy when user does '-kernel', less easy when
> >the user boots an image). For simplicity sake I'll stick with the
> >'-kernel' option for now.
> >
> >Once we have the kernel we can do two things:
> >  1. See if the kernel was built with CONFIG_IKCONFIG.
> >
> >  2. Try finding the System.map which belongs to the kernel, it's
> >provided with all distro kernels so we can expect it to be around. If we
> >did find it we repeat the same process as in #1.
> >
> >If we found one of the above, we start matching config sets ("we need
> >a,b,c,d for virtio, let's see if it's all there"). Once we find a good
> >config set, we use it for defaults. If we didn't find a good config set
> >we warn the user and don't even bother starting the guest.
> >
> >If we couldn't find either, we can just default to whatever we have as
> >defaults now.
> >
> >
> >To sum it up, I was wondering if this approach has been considered
> >before and whether it sounds interesting enough to try.
> >
> 
> This is a similar problem to p2v or v2v - taking a guest that used
> to run on physical or virtual hardware, and modifying it to run on
> (different) virtual hardware.  The first step is what you're looking
> for - detecting what the guest currently supports.
> 
> You can look at http://libguestfs.org/virt-v2v/ for an example.  I'm
> also copying Richard Jones, who maintains libguestfs, which does the
> actual poking around in the guest.

Yes, as Avi says, we do all of the above already.  Including
for Windows guests.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org



Re: [Qemu-devel] Guest kernel device compatability auto-detection

2011-08-25 Thread Sasha Levin
On Thu, 2011-08-25 at 08:32 +0100, Richard W.M. Jones wrote:
> On Thu, Aug 25, 2011 at 08:33:04AM +0300, Avi Kivity wrote:
> > On 08/25/2011 08:21 AM, Sasha Levin wrote:
> > >Hi,
> > >
> > >Currently when we run the guest we treat it as a black box, we're not
> > >quite sure what it's going to start and whether it supports the same
> > >features we expect it to support when running it from the host.
> > >
> > >This forces us to start the guest with the safest defaults possible, for
> > >example: '-drive file=my_image.qcow2' will be started with slow IDE
> > >emulation even though the guest is capable of virtio.
> > >
> > >I'm currently working on a method to try and detect whether the guest
> > >kernel has specific configurations enabled and either warn the user if
> > >we know the kernel is not going to properly work or use better defaults
> > >if we know some advanced features are going to work.
> > >
> > >How am I planning to do it? First, we'll try finding which kernel the
> > >guest is going to boot (easy when user does '-kernel', less easy when
> > >the user boots an image). For simplicity sake I'll stick with the
> > >'-kernel' option for now.
> > >
> > >Once we have the kernel we can do two things:
> > >  1. See if the kernel was built with CONFIG_IKCONFIG.
> > >
> > >  2. Try finding the System.map which belongs to the kernel, it's
> > >provided with all distro kernels so we can expect it to be around. If we
> > >did find it we repeat the same process as in #1.
> > >
> > >If we found one of the above, we start matching config sets ("we need
> > >a,b,c,d for virtio, let's see if it's all there"). Once we find a good
> > >config set, we use it for defaults. If we didn't find a good config set
> > >we warn the user and don't even bother starting the guest.
> > >
> > >If we couldn't find either, we can just default to whatever we have as
> > >defaults now.
> > >
> > >
> > >To sum it up, I was wondering if this approach has been considered
> > >before and whether it sounds interesting enough to try.
> > >
> > 
> > This is a similar problem to p2v or v2v - taking a guest that used
> > to run on physical or virtual hardware, and modifying it to run on
> > (different) virtual hardware.  The first step is what you're looking
> > for - detecting what the guest currently supports.
> > 
> > You can look at http://libguestfs.org/virt-v2v/ for an example.  I'm
> > also copying Richard Jones, who maintains libguestfs, which does the
> > actual poking around in the guest.
> 
> Yes, as Avi says, we do all of the above already.  Including
> for Windows guests.

>From what I gathered libguestfs only provides access to the guests'
image.

Which part is doing the IKCONFIG or System.map probing? Or is it done in
a different way?

-- 

Sasha.




Re: [Qemu-devel] Guest kernel device compatability auto-detection

2011-08-25 Thread Richard W.M. Jones
On Thu, Aug 25, 2011 at 10:40:34AM +0300, Sasha Levin wrote:
> From what I gathered libguestfs only provides access to the guests'
> image.

Correct.

> Which part is doing the IKCONFIG or System.map probing? Or is it done in
> a different way?

You'll have to see what Matt's doing in the virt-v2v code for the
details, but in general we have full access to:

 - grub.conf (to determine which kernel will boot)
 - the kernel image
 - the corresponding System.map and config
 - the modules directory
 - the Xorg config
 - boot.ini or BCD (to determine which NT kernel will boot)
 - the Windows Registry
 - the list of packages installed (to see if VMware-tools or some other
   guest agent is installed)

So working out what drivers are available is just a tedious matter of
iterating across each of these places in the filesystem.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top



[Qemu-devel] [PULL] Fix for ppc/escc crash

2011-08-25 Thread Avi Kivity

Anthony/Blue, please pull from:

  git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/urgent

to receive a fix for a crash caused by the memory API conversion:

Avi Kivity (1):
  ppc_oldworld, ppc_newworld: fix escc BAR related crash

 hw/ppc_newworld.c |5 -
 hw/ppc_oldworld.c |6 --
 2 files changed, 8 insertions(+), 3 deletions(-)

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.




[Qemu-devel] [PULL] Memory API conversions, batch 5

2011-08-25 Thread Avi Kivity

Please pull from

  git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/batch

to receive the fifth memory API conversions batch.  There is really 
nothing notable, except perhaps the first use of the transaction API.


While the patches have been on the list for just a short time, they have 
received quite extensive review, for which I am thankful.


Avi Kivity (22):
  stellaris_enet: convert to memory API
  sysbus: add helpers to add and delete memory regions to the 
system bus

  pci_host: convert conf index and data ports to memory API
  ReadWriteHandler: remove
  an5206: convert to memory API
  armv7m: convert to memory API
  axis_dev88: convert to memory API (RAM only)
  sysbus: add sysbus_add_memory_overlap()
  integratorcp: convert to memory API (RAM/flash only)
  leon3: convert to memory API
  cirrus: wrap memory update in a transaction
  piix_pci: wrap memory update in a transaction
  Makefile.hw: allow hw/ files to include glib headers
  pflash_cfi01/pflash_cfi02: convert to memory API
  dummy_m68k: convert to memory API
  g364fb: convert to memory API
  lm32_boards: convert to memory API
  mainstone: convert to memory API
  mcf5208: convert to memory API
  milkymist-minimac2: convert to memory API
  milkymist-softusb: convert to memory API
  milkymist: convert to memory API

 Makefile.hw   |1 +
 Makefile.target   |1 -
 hw/an5206.c   |   12 --
 hw/arm-misc.h |5 ++-
 hw/armv7m.c   |   22 +
 hw/axis_dev88.c   |   16 
 hw/cirrus_vga.c   |2 +
 hw/collie.c   |   16 ---
 hw/dec_pci.c  |   13 +++---
 hw/dummy_m68k.c   |7 ++-
 hw/flash.h|   16 +--
 hw/g364fb.c   |   60 ++
 hw/grackle_pci.c  |   13 +++---
 hw/gumstix.c  |   28 +++-
 hw/integratorcp.c |   28 +
 hw/leon3.c|   15 ---
 hw/lm32_boards.c  |   29 +++-
 hw/mainstone.c|   33 --
 hw/mcf5208.c  |   72 ++-
 hw/milkymist-minimac2.c   |   43 +--
 hw/milkymist-softusb.c|   48 +++---
 hw/milkymist.c|   16 ---
 hw/mips.h |4 +-
 hw/mips_jazz.c|3 +-
 hw/mips_malta.c   |   45 +++-
 hw/mips_r4k.c |   20 +
 hw/musicpal.c |   15 ---
 hw/omap_sx1.c |   21 +
 hw/pci_host.c |   86 
+-

 hw/pci_host.h |   16 +++
 hw/petalogix_ml605_mmu.c  |7 ++-
 hw/petalogix_s3adsp1800_mmu.c |8 ++-
 hw/pflash_cfi01.c |   67 ++---
 hw/pflash_cfi02.c |   93 
-

 hw/piix_pci.c |   13 +-
 hw/ppc405_boards.c|   63 +++
 hw/ppc4xx_pci.c   |   10 +++--
 hw/ppce500_pci.c  |   21 -
 hw/prep_pci.c |   12 -
 hw/r2d.c  |7 ++-
 hw/stellaris.c|5 ++-
 hw/stellaris_enet.c   |   29 +---
 hw/sysbus.c   |   29 +
 hw/sysbus.h   |8 
 hw/unin_pci.c |   82 ++--
 hw/virtex_ml507.c |7 ++-
 hw/z2.c   |   15 ---
 rwhandler.c   |   87 
--

 rwhandler.h   |   27 
 49 files changed, 638 insertions(+), 658 deletions(-)
 delete mode 100644 rwhandler.c
 delete mode 100644 rwhandler.h

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.




Re: [Qemu-devel] [PATCH] qemu-coroutine: Add simple work queue support

2011-08-25 Thread Stefan Hajnoczi
On Thu, Aug 25, 2011 at 04:46:59PM +1000, Peter Crosthwaite wrote:
> Hi Stefan,
> 
> I have ccd you on a RFC containing the work that this patch uses. I have
> also changed the name of the function to co_queue_enter_next() as i think
> yield was not the appropriate name. The idea is the top level thread which
> is managing the work queue can transfer into coroutine context with the
> function, so this function is more of an "enter" function than a "yield"
> function. I cant see any technical reasons why it needs the coroutine_fn
> restriction, as this in not required by qemu_coroutine_enter, which is the
> backend of this function.

You are right, I was confused by the "yield" in the name :).  It doesn't
need to be coroutine_fn.

Stefan



[Qemu-devel] [PATCH 00/19] Memory API conversions: batch 6

2011-08-25 Thread Avi Kivity
More fairly straightforward conversions.  If you have limited time,
please review my patches, as Richard's have already been reviewed.

Avi Kivity (9):
  mips_fulong2e: convert to memory API
  mips_jazz: convert to memory API
  mips_malta: convert to memory API
  mips_mipssim: convert to memory API
  mips_r4k: convert to memory API
  musicpal: convert to memory API
  omap1: convert to memory API (part I)
  omap1: convert to memory API (part II)
  pci: simplify memory region registration

Richard Henderson (10):
  pci: add pci_address_space_io()
  isa: Pass i/o address space to isa_bus_new
  isa: add isa_register_ioport()
  pc: Re-order pc_init1 to initialize the ISA bus before ISA devices
  cs4231a: Convert to MemoryRegion
  i8254: Convert to MemoryRegion
  i8259: Convert to MemoryRegion
  pckbd: Convert to MemoryRegion
  serial: Convert serial_isa_initfn to MemoryRegion
  fdc: Convert isabus_fdc_init1 to MemoryRegion

 hw/cs4231a.c   |   38 ++--
 hw/fdc.c   |   53 --
 hw/i8254.c |   16 ++-
 hw/i8259.c |   65 +--
 hw/isa-bus.c   |   14 ++-
 hw/isa.h   |7 +-
 hw/mips_fulong2e.c |   17 +-
 hw/mips_jazz.c |   96 +-
 hw/mips_malta.c|   53 +++---
 hw/mips_mipssim.c  |   16 +-
 hw/mips_r4k.c  |   40 ++---
 hw/musicpal.c  |  243 ++--
 hw/omap.h  |   18 ++-
 hw/omap1.c |  533 
 hw/omap_sx1.c  |4 +-
 hw/palm.c  |4 +-
 hw/pc.h|2 +-
 hw/pc_piix.c   |   24 ++-
 hw/pci.c   |   20 +-
 hw/pci.h   |1 +
 hw/pckbd.c |   59 ---
 hw/piix4.c |2 +-
 hw/piix_pci.c  |2 +-
 hw/ppc_prep.c  |2 +-
 hw/serial.c|   15 ++-
 hw/sun4u.c |2 +-
 hw/vt82c686.c  |2 +-
 27 files changed, 730 insertions(+), 618 deletions(-)

-- 
1.7.5.3




[Qemu-devel] [PATCH 14/19] i8254: Convert to MemoryRegion

2011-08-25 Thread Avi Kivity
From: Richard Henderson 

Signed-off-by: Richard Henderson 
Signed-off-by: Avi Kivity 
---
 hw/i8254.c |   16 +---
 1 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/hw/i8254.c b/hw/i8254.c
index a9ca9f6..12571ef 100644
--- a/hw/i8254.c
+++ b/hw/i8254.c
@@ -55,6 +55,7 @@ typedef struct PITChannelState {
 
 typedef struct PITState {
 ISADevice dev;
+MemoryRegion ioports;
 uint32_t irq;
 uint32_t iobase;
 PITChannelState channels[3];
@@ -506,6 +507,16 @@ void hpet_pit_enable(void)
 pit_load_count(s, 0);
 }
 
+static const MemoryRegionPortio pit_portio[] = {
+{ 0, 4, 1, .write = pit_ioport_write },
+{ 0, 3, 1, .read = pit_ioport_read },
+PORTIO_END_OF_LIST()
+};
+
+static const MemoryRegionOps pit_ioport_ops = {
+.old_portio = pit_portio
+};
+
 static int pit_initfn(ISADevice *dev)
 {
 PITState *pit = DO_UPCAST(PITState, dev, dev);
@@ -516,9 +527,8 @@ static int pit_initfn(ISADevice *dev)
 s->irq_timer = qemu_new_timer_ns(vm_clock, pit_irq_timer, s);
 s->irq = isa_get_irq(pit->irq);
 
-register_ioport_write(pit->iobase, 4, 1, pit_ioport_write, pit);
-register_ioport_read(pit->iobase, 3, 1, pit_ioport_read, pit);
-isa_init_ioport(dev, pit->iobase);
+memory_region_init_io(&pit->ioports, &pit_ioport_ops, pit, "pit", 4);
+isa_register_ioport(dev, &pit->ioports, pit->iobase);
 
 qdev_set_legacy_instance_id(&dev->qdev, pit->iobase, 2);
 
-- 
1.7.5.3




[Qemu-devel] [PATCH 15/19] i8259: Convert to MemoryRegion

2011-08-25 Thread Avi Kivity
From: Richard Henderson 

The only non-obvious part is pic_poll_read which used
"addr1 >> 7" to detect whether one referred to either
the master or slave PIC.  Instead, test this directly.

Signed-off-by: Richard Henderson 
Signed-off-by: Avi Kivity 
---
 hw/i8259.c |   65 ++-
 1 files changed, 46 insertions(+), 19 deletions(-)

diff --git a/hw/i8259.c b/hw/i8259.c
index c0b96ab..e5323ff 100644
--- a/hw/i8259.c
+++ b/hw/i8259.c
@@ -59,6 +59,8 @@ typedef struct PicState {
 uint8_t elcr; /* PIIX edge/trigger selection*/
 uint8_t elcr_mask;
 PicState2 *pics_state;
+MemoryRegion base_io;
+MemoryRegion elcr_io;
 } PicState;
 
 struct PicState2 {
@@ -284,13 +286,15 @@ static void pic_reset(void *opaque)
 /* Note: ELCR is not reset */
 }
 
-static void pic_ioport_write(void *opaque, uint32_t addr, uint32_t val)
+static void pic_ioport_write(void *opaque, target_phys_addr_t addr64,
+ uint64_t val64, unsigned size)
 {
 PicState *s = opaque;
+uint32_t addr = addr64;
+uint32_t val = val64;
 int priority, cmd, irq;
 
 DPRINTF("write: addr=0x%02x val=0x%02x\n", addr, val);
-addr &= 1;
 if (addr == 0) {
 if (val & 0x10) {
 /* init */
@@ -374,19 +378,21 @@ static void pic_ioport_write(void *opaque, uint32_t addr, 
uint32_t val)
 }
 }
 
-static uint32_t pic_poll_read (PicState *s, uint32_t addr1)
+static uint32_t pic_poll_read(PicState *s)
 {
 int ret;
 
 ret = pic_get_irq(s);
 if (ret >= 0) {
-if (addr1 >> 7) {
+bool slave = (s == &isa_pic->pics[1]);
+
+if (slave) {
 s->pics_state->pics[0].isr &= ~(1 << 2);
 s->pics_state->pics[0].irr &= ~(1 << 2);
 }
 s->irr &= ~(1 << ret);
 s->isr &= ~(1 << ret);
-if (addr1 >> 7 || ret != 2)
+if (slave || ret != 2)
 pic_update_irq(s->pics_state);
 } else {
 ret = 0x07;
@@ -396,16 +402,15 @@ static uint32_t pic_poll_read (PicState *s, uint32_t 
addr1)
 return ret;
 }
 
-static uint32_t pic_ioport_read(void *opaque, uint32_t addr1)
+static uint64_t pic_ioport_read(void *opaque, target_phys_addr_t addr1,
+unsigned size)
 {
 PicState *s = opaque;
-unsigned int addr;
+unsigned int addr = addr1;
 int ret;
 
-addr = addr1;
-addr &= 1;
 if (s->poll) {
-ret = pic_poll_read(s, addr1);
+ret = pic_poll_read(s);
 s->poll = 0;
 } else {
 if (addr == 0) {
@@ -417,7 +422,7 @@ static uint32_t pic_ioport_read(void *opaque, uint32_t 
addr1)
 ret = s->imr;
 }
 }
-DPRINTF("read: addr=0x%02x val=0x%02x\n", addr1, ret);
+DPRINTF("read: addr=0x%02x val=0x%02x\n", addr, ret);
 return ret;
 }
 
@@ -427,22 +432,24 @@ uint32_t pic_intack_read(PicState2 *s)
 {
 int ret;
 
-ret = pic_poll_read(&s->pics[0], 0x00);
+ret = pic_poll_read(&s->pics[0]);
 if (ret == 2)
-ret = pic_poll_read(&s->pics[1], 0x80) + 8;
+ret = pic_poll_read(&s->pics[1]) + 8;
 /* Prepare for ISR read */
 s->pics[0].read_reg_select = 1;
 
 return ret;
 }
 
-static void elcr_ioport_write(void *opaque, uint32_t addr, uint32_t val)
+static void elcr_ioport_write(void *opaque, target_phys_addr_t addr,
+  uint64_t val, unsigned size)
 {
 PicState *s = opaque;
 s->elcr = val & s->elcr_mask;
 }
 
-static uint32_t elcr_ioport_read(void *opaque, uint32_t addr1)
+static uint64_t elcr_ioport_read(void *opaque, target_phys_addr_t addr,
+ unsigned size)
 {
 PicState *s = opaque;
 return s->elcr;
@@ -474,15 +481,35 @@ static const VMStateDescription vmstate_pic = {
 }
 };
 
+static const MemoryRegionOps pic_base_ioport_ops = {
+.read = pic_ioport_read,
+.write = pic_ioport_write,
+.impl = {
+.min_access_size = 1,
+.max_access_size = 1,
+},
+};
+
+static const MemoryRegionOps pic_elcr_ioport_ops = {
+.read = elcr_ioport_read,
+.write = elcr_ioport_write,
+.impl = {
+.min_access_size = 1,
+.max_access_size = 1,
+},
+};
+
 /* XXX: add generic master/slave system */
 static void pic_init1(int io_addr, int elcr_addr, PicState *s)
 {
-register_ioport_write(io_addr, 2, 1, pic_ioport_write, s);
-register_ioport_read(io_addr, 2, 1, pic_ioport_read, s);
+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, io_addr);
 if (elcr_addr >= 0) {
-register_ioport_write(elcr_addr, 1, 1, elcr_ioport_write, s);
-register_ioport_read(elcr_addr, 1, 1, elcr_ioport_read, s);
+isa_register_ioport(NULL, &s->elcr_io, elcr_addr);
 }
+
 vmstate_register(NULL, io_addr, &vmstate_pic, s);
 qemu_register_rese

[Qemu-devel] [PATCH 10/19] isa: Pass i/o address space to isa_bus_new

2011-08-25 Thread Avi Kivity
From: Richard Henderson 

Not used yet, but at least we're provided with the correct region.

Signed-off-by: Richard Henderson 
Signed-off-by: Avi Kivity 
---
 hw/isa-bus.c   |4 +++-
 hw/isa.h   |2 +-
 hw/mips_jazz.c |   17 ++---
 hw/mips_r4k.c  |2 +-
 hw/pc_piix.c   |2 +-
 hw/piix4.c |2 +-
 hw/piix_pci.c  |2 +-
 hw/ppc_prep.c  |2 +-
 hw/sun4u.c |2 +-
 hw/vt82c686.c  |2 +-
 10 files changed, 21 insertions(+), 16 deletions(-)

diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index 1cb497f..d067505 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -24,6 +24,7 @@
 
 struct ISABus {
 BusState qbus;
+MemoryRegion *address_space_io;
 qemu_irq *irqs;
 };
 static ISABus *isabus;
@@ -39,7 +40,7 @@ static struct BusInfo isa_bus_info = {
 .get_fw_dev_path = isabus_get_fw_dev_path,
 };
 
-ISABus *isa_bus_new(DeviceState *dev)
+ISABus *isa_bus_new(DeviceState *dev, MemoryRegion *address_space_io)
 {
 if (isabus) {
 fprintf(stderr, "Can't create a second ISA bus\n");
@@ -51,6 +52,7 @@ ISABus *isa_bus_new(DeviceState *dev)
 }
 
 isabus = FROM_QBUS(ISABus, qbus_create(&isa_bus_info, dev, NULL));
+isabus->address_space_io = address_space_io;
 return isabus;
 }
 
diff --git a/hw/isa.h b/hw/isa.h
index f344699..390e2d4 100644
--- a/hw/isa.h
+++ b/hw/isa.h
@@ -25,7 +25,7 @@ struct ISADeviceInfo {
 isa_qdev_initfn init;
 };
 
-ISABus *isa_bus_new(DeviceState *dev);
+ISABus *isa_bus_new(DeviceState *dev, MemoryRegion *address_space_io);
 void isa_bus_irqs(qemu_irq *irqs);
 qemu_irq isa_get_irq(int isairq);
 void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq);
diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c
index 91e15b9..4aa5aa4 100644
--- a/hw/mips_jazz.c
+++ b/hw/mips_jazz.c
@@ -102,10 +102,11 @@ static void cpu_request_exit(void *opaque, int irq, int 
level)
 }
 }
 
-static
-void mips_jazz_init (MemoryRegion *address_space, ram_addr_t ram_size,
- const char *cpu_model,
- enum jazz_model_e jazz_model)
+static void mips_jazz_init(MemoryRegion *address_space,
+   MemoryRegion *address_space_io,
+   ram_addr_t ram_size,
+   const char *cpu_model,
+   enum jazz_model_e jazz_model)
 {
 char *filename;
 int bios_size, n;
@@ -181,7 +182,7 @@ void mips_jazz_init (MemoryRegion *address_space, 
ram_addr_t ram_size,
 
 /* ISA devices */
 i8259 = i8259_init(env->irq[4]);
-isa_bus_new(NULL);
+isa_bus_new(NULL, address_space_io);
 isa_bus_irqs(i8259);
 cpu_exit_irq = qemu_allocate_irqs(cpu_request_exit, NULL, 1);
 DMA_init(0, cpu_exit_irq);
@@ -286,7 +287,8 @@ void mips_magnum_init (ram_addr_t ram_size,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
 {
-mips_jazz_init(get_system_memory(), ram_size, cpu_model, JAZZ_MAGNUM);
+mips_jazz_init(get_system_memory(), get_system_io(),
+   ram_size, cpu_model, JAZZ_MAGNUM);
 }
 
 static
@@ -295,7 +297,8 @@ void mips_pica61_init (ram_addr_t ram_size,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
 {
-mips_jazz_init(get_system_memory(), ram_size, cpu_model, JAZZ_PICA61);
+mips_jazz_init(get_system_memory(), get_system_io(),
+   ram_size, cpu_model, JAZZ_PICA61);
 }
 
 static QEMUMachine mips_magnum_machine = {
diff --git a/hw/mips_r4k.c b/hw/mips_r4k.c
index efa4b05..670acd4 100644
--- a/hw/mips_r4k.c
+++ b/hw/mips_r4k.c
@@ -259,7 +259,7 @@ void mips_r4k_init (ram_addr_t ram_size,
 
 /* The PIC is attached to the MIPS CPU INT0 pin */
 i8259 = i8259_init(env->irq[2]);
-isa_bus_new(NULL);
+isa_bus_new(NULL, get_system_io());
 isa_bus_irqs(i8259);
 
 rtc_init(2000, NULL);
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 75d96d9..9a8f580 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -149,7 +149,7 @@ static void pc_init1(MemoryRegion *system_memory,
 } else {
 pci_bus = NULL;
 i440fx_state = NULL;
-isa_bus_new(NULL);
+isa_bus_new(NULL, system_io);
 }
 isa_bus_irqs(isa_irq);
 
diff --git a/hw/piix4.c b/hw/piix4.c
index 9590e7b..2fd1171 100644
--- a/hw/piix4.c
+++ b/hw/piix4.c
@@ -87,7 +87,7 @@ static int piix4_initfn(PCIDevice *dev)
 {
 PIIX4State *d = DO_UPCAST(PIIX4State, dev, dev);
 
-isa_bus_new(&d->dev.qdev);
+isa_bus_new(&d->dev.qdev, pci_address_space_io(dev));
 piix4_dev = &d->dev;
 qemu_register_reset(piix4_reset, d);
 return 0;
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 8f6ea42..d183443 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -504,7 +504,7 @@ static int piix3_initfn(PCIDevice *dev)
 {
 PIIX3State *d = DO_UPCAST(PIIX3State, dev, dev);
 
-isa

[Qemu-devel] [PATCH 08/19] omap1: convert to memory API (part II)

2011-08-25 Thread Avi Kivity
Signed-off-by: Avi Kivity 
---
 hw/omap.h  |7 ++-
 hw/omap1.c |  195 
 2 files changed, 111 insertions(+), 91 deletions(-)

diff --git a/hw/omap.h b/hw/omap.h
index bae6bed..bb25754 100644
--- a/hw/omap.h
+++ b/hw/omap.h
@@ -677,7 +677,8 @@ void omap_uart_reset(struct omap_uart_s *s);
 void omap_uart_attach(struct omap_uart_s *s, CharDriverState *chr);
 
 struct omap_mpuio_s;
-struct omap_mpuio_s *omap_mpuio_init(target_phys_addr_t base,
+struct omap_mpuio_s *omap_mpuio_init(MemoryRegion *system_memory,
+target_phys_addr_t base,
 qemu_irq kbd_int, qemu_irq gpio_int, qemu_irq wakeup,
 omap_clk clk);
 qemu_irq *omap_mpuio_in_get(struct omap_mpuio_s *s);
@@ -829,6 +830,9 @@ struct omap_mpu_state_s {
 MemoryRegion id_iomem_ed4;
 MemoryRegion id_iomem_e20;
 MemoryRegion mpui_iomem;
+MemoryRegion tcmi_iomem;
+MemoryRegion clkm_iomem;
+MemoryRegion clkdsp_iomem;
 
 struct omap_dma_port_if_s {
 uint32_t (*read[3])(struct omap_mpu_state_s *s,
@@ -911,6 +915,7 @@ struct omap_mpu_state_s {
 uint32_t tcmi_regs[17];
 
 struct dpll_ctl_s {
+MemoryRegion iomem;
 uint16_t mode;
 omap_clk dpll;
 } dpll[3];
diff --git a/hw/omap1.c b/hw/omap1.c
index 0f7e14f..05e38fc 100644
--- a/hw/omap1.c
+++ b/hw/omap1.c
@@ -1236,11 +1236,16 @@ static struct omap_tipb_bridge_s *omap_tipb_bridge_init(
 }
 
 /* Dummy Traffic Controller's Memory Interface */
-static uint32_t omap_tcmi_read(void *opaque, target_phys_addr_t addr)
+static uint64_t omap_tcmi_read(void *opaque, target_phys_addr_t addr,
+   unsigned size)
 {
 struct omap_mpu_state_s *s = (struct omap_mpu_state_s *) opaque;
 uint32_t ret;
 
+if (size != 4) {
+return omap_badwidth_read32(opaque, addr);
+}
+
 switch (addr) {
 case 0x00: /* IMIF_PRIO */
 case 0x04: /* EMIFS_PRIO */
@@ -1270,10 +1275,14 @@ static uint32_t omap_tcmi_read(void *opaque, 
target_phys_addr_t addr)
 }
 
 static void omap_tcmi_write(void *opaque, target_phys_addr_t addr,
-uint32_t value)
+uint64_t value, unsigned size)
 {
 struct omap_mpu_state_s *s = (struct omap_mpu_state_s *) opaque;
 
+if (size != 4) {
+return omap_badwidth_write32(opaque, addr, value);
+}
+
 switch (addr) {
 case 0x00: /* IMIF_PRIO */
 case 0x04: /* EMIFS_PRIO */
@@ -1300,16 +1309,10 @@ static void omap_tcmi_write(void *opaque, 
target_phys_addr_t addr,
 }
 }
 
-static CPUReadMemoryFunc * const omap_tcmi_readfn[] = {
-omap_badwidth_read32,
-omap_badwidth_read32,
-omap_tcmi_read,
-};
-
-static CPUWriteMemoryFunc * const omap_tcmi_writefn[] = {
-omap_badwidth_write32,
-omap_badwidth_write32,
-omap_tcmi_write,
+static const MemoryRegionOps omap_tcmi_ops = {
+.read = omap_tcmi_read,
+.write = omap_tcmi_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
 };
 
 static void omap_tcmi_reset(struct omap_mpu_state_s *mpu)
@@ -1331,21 +1334,25 @@ static void omap_tcmi_reset(struct omap_mpu_state_s 
*mpu)
 mpu->tcmi_regs[0x40 >> 2] = 0x;
 }
 
-static void omap_tcmi_init(target_phys_addr_t base,
+static void omap_tcmi_init(MemoryRegion *memory, target_phys_addr_t base,
 struct omap_mpu_state_s *mpu)
 {
-int iomemtype = cpu_register_io_memory(omap_tcmi_readfn,
-omap_tcmi_writefn, mpu, DEVICE_NATIVE_ENDIAN);
-
-cpu_register_physical_memory(base, 0x100, iomemtype);
+memory_region_init_io(&mpu->tcmi_iomem, &omap_tcmi_ops, mpu,
+  "omap-tcmi", 0x100);
+memory_region_add_subregion(memory, base, &mpu->tcmi_iomem);
 omap_tcmi_reset(mpu);
 }
 
 /* Digital phase-locked loops control */
-static uint32_t omap_dpll_read(void *opaque, target_phys_addr_t addr)
+static uint64_t omap_dpll_read(void *opaque, target_phys_addr_t addr,
+   unsigned size)
 {
 struct dpll_ctl_s *s = (struct dpll_ctl_s *) opaque;
 
+if (size != 2) {
+return omap_badwidth_read16(opaque, addr);
+}
+
 if (addr == 0x00)  /* CTL_REG */
 return s->mode;
 
@@ -1354,13 +1361,17 @@ static uint32_t omap_dpll_read(void *opaque, 
target_phys_addr_t addr)
 }
 
 static void omap_dpll_write(void *opaque, target_phys_addr_t addr,
-uint32_t value)
+uint64_t value, unsigned size)
 {
 struct dpll_ctl_s *s = (struct dpll_ctl_s *) opaque;
 uint16_t diff;
 static const int bypass_div[4] = { 1, 2, 4, 4 };
 int div, mult;
 
+if (size != 2) {
+return omap_badwidth_write16(opaque, addr, value);
+}
+
 if (addr == 0x00) {/* CTL_REG */
 /* See omap_ulpd_pm_write() too */
 diff = s->mode & value;
@@ -1386,16 +1397,10 @@ static void omap_dpll_write(void *opaque, 
target_phys_addr_t addr,
 }
 }
 
-static CPUReadMemor

[Qemu-devel] [PATCH 02/19] mips_jazz: convert to memory API

2011-08-25 Thread Avi Kivity
Signed-off-by: Avi Kivity 
---
 hw/mips_jazz.c |   81 +++
 1 files changed, 40 insertions(+), 41 deletions(-)

diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c
index a741086..91e15b9 100644
--- a/hw/mips_jazz.c
+++ b/hw/mips_jazz.c
@@ -52,44 +52,42 @@ static void main_cpu_reset(void *opaque)
 cpu_reset(env);
 }
 
-static uint32_t rtc_readb(void *opaque, target_phys_addr_t addr)
+static uint64_t rtc_read(void *opaque, target_phys_addr_t addr, unsigned size)
 {
 return cpu_inw(0x71);
 }
 
-static void rtc_writeb(void *opaque, target_phys_addr_t addr, uint32_t val)
+static void rtc_write(void *opaque, target_phys_addr_t addr,
+  uint64_t val, unsigned size)
 {
 cpu_outw(0x71, val & 0xff);
 }
 
-static CPUReadMemoryFunc * const rtc_read[3] = {
-rtc_readb,
-rtc_readb,
-rtc_readb,
+static const MemoryRegionOps rtc_ops = {
+.read = rtc_read,
+.write = rtc_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
 };
 
-static CPUWriteMemoryFunc * const rtc_write[3] = {
-rtc_writeb,
-rtc_writeb,
-rtc_writeb,
-};
-
-static void dma_dummy_writeb(void *opaque, target_phys_addr_t addr, uint32_t 
val)
+static uint64_t dma_dummy_read(void *opaque, target_phys_addr_t addr,
+   unsigned size)
 {
 /* Nothing to do. That is only to ensure that
  * the current DMA acknowledge cycle is completed. */
+return 0xff;
 }
 
-static CPUReadMemoryFunc * const dma_dummy_read[3] = {
-NULL,
-NULL,
-NULL,
-};
+static void dma_dummy_write(void *opaque, target_phys_addr_t addr,
+uint64_t val, unsigned size)
+{
+/* Nothing to do. That is only to ensure that
+ * the current DMA acknowledge cycle is completed. */
+}
 
-static CPUWriteMemoryFunc * const dma_dummy_write[3] = {
-dma_dummy_writeb,
-dma_dummy_writeb,
-dma_dummy_writeb,
+static const MemoryRegionOps dma_dummy_ops = {
+.read = dma_dummy_read,
+.write = dma_dummy_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
 };
 
 #define MAGNUM_BIOS_SIZE_MAX 0x7e000
@@ -105,7 +103,7 @@ static void cpu_request_exit(void *opaque, int irq, int 
level)
 }
 
 static
-void mips_jazz_init (ram_addr_t ram_size,
+void mips_jazz_init (MemoryRegion *address_space, ram_addr_t ram_size,
  const char *cpu_model,
  enum jazz_model_e jazz_model)
 {
@@ -115,7 +113,8 @@ void mips_jazz_init (ram_addr_t ram_size,
 qemu_irq *rc4030, *i8259;
 rc4030_dma *dmas;
 void* rc4030_opaque;
-int s_rtc, s_dma_dummy;
+MemoryRegion *rtc = g_new(MemoryRegion, 1);
+MemoryRegion *dma_dummy = g_new(MemoryRegion, 1);
 NICInfo *nd;
 DeviceState *dev;
 SysBusDevice *sysbus;
@@ -123,8 +122,9 @@ void mips_jazz_init (ram_addr_t ram_size,
 DriveInfo *fds[MAX_FD];
 qemu_irq esp_reset, dma_enable;
 qemu_irq *cpu_exit_irq;
-ram_addr_t ram_offset;
-ram_addr_t bios_offset;
+MemoryRegion *ram = g_new(MemoryRegion, 1);
+MemoryRegion *bios = g_new(MemoryRegion, 1);
+MemoryRegion *bios2 = g_new(MemoryRegion, 1);
 
 /* init CPUs */
 if (cpu_model == NULL) {
@@ -143,14 +143,15 @@ void mips_jazz_init (ram_addr_t ram_size,
 qemu_register_reset(main_cpu_reset, env);
 
 /* allocate RAM */
-ram_offset = qemu_ram_alloc(NULL, "mips_jazz.ram", ram_size);
-cpu_register_physical_memory(0, ram_size, ram_offset | IO_MEM_RAM);
+memory_region_init_ram(ram, NULL, "mips_jazz.ram", ram_size);
+memory_region_add_subregion(address_space, 0, ram);
 
-bios_offset = qemu_ram_alloc(NULL, "mips_jazz.bios", MAGNUM_BIOS_SIZE);
-cpu_register_physical_memory(0x1fc0LL,
- MAGNUM_BIOS_SIZE, bios_offset | IO_MEM_ROM);
-cpu_register_physical_memory(0xfff0LL,
- MAGNUM_BIOS_SIZE, bios_offset | IO_MEM_ROM);
+memory_region_init_ram(bios, NULL, "mips_jazz.bios", MAGNUM_BIOS_SIZE);
+memory_region_set_readonly(bios, true);
+memory_region_init_alias(bios2, "mips_jazz.bios", bios,
+ 0, MAGNUM_BIOS_SIZE);
+memory_region_add_subregion(address_space, 0x1fc0LL, bios);
+memory_region_add_subregion(address_space, 0xfff0LL, bios);
 
 /* load the BIOS image. */
 if (bios_name == NULL)
@@ -175,9 +176,8 @@ void mips_jazz_init (ram_addr_t ram_size,
 
 /* Chipset */
 rc4030_opaque = rc4030_init(env->irq[6], env->irq[3], &rc4030, &dmas);
-s_dma_dummy = cpu_register_io_memory(dma_dummy_read, dma_dummy_write, NULL,
- DEVICE_NATIVE_ENDIAN);
-cpu_register_physical_memory(0x8000d000, 0x1000, s_dma_dummy);
+memory_region_init_io(dma_dummy, &dma_dummy_ops, NULL, "dummy_dma", 
0x1000);
+memory_region_add_subregion(address_space, 0x8000d000, dma_dummy);
 
 /* ISA devices */
 i8259 = i8259_init(env->irq[4]);
@@ -240,9 +240,8 @@ void mips_jazz_init (ram

[Qemu-devel] [PATCH] build: sort objects to remove duplicates for link

2011-08-25 Thread Stefan Hajnoczi
Avoid duplicate object files during the link.  There are legitimate
cases where a link command-line would include duplicate object files
because two independent subsystems both depend on common infrastructure.

Use GNU make's $(sort) function to remove duplicate object files from
the link command-line.

Signed-off-by: Stefan Hajnoczi 
---
Your patch seems fine but we need to avoid duplicate object files during the
link phase.  Otherwise we run into linker warnings because qemu-timer-common.o
is linked multiple times.  Please include this patch and resend the two
together with this patch as 1/2 and yours as 2/2.

 rules.mak |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/rules.mak b/rules.mak
index 884d421..04a9198 100644
--- a/rules.mak
+++ b/rules.mak
@@ -31,7 +31,7 @@ endif
 %.o: %.m
$(call quiet-command,$(CC) $(QEMU_INCLUDES) $(QEMU_CFLAGS) 
$(QEMU_DGFLAGS) $(CFLAGS) -c -o $@ $<,"  OBJC  $(TARGET_DIR)$@")
 
-LINK = $(call quiet-command,$(CC) $(QEMU_CFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ 
$(1) $(LIBS),"  LINK  $(TARGET_DIR)$@")
+LINK = $(call quiet-command,$(CC) $(QEMU_CFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ 
$(sort $(1)) $(LIBS),"  LINK  $(TARGET_DIR)$@")
 
 %$(EXESUF): %.o
$(call LINK,$^)
-- 
1.7.5.4




Re: [Qemu-devel] [PATCH] disasm: update comment

2011-08-25 Thread Stefan Hajnoczi
On Thu, Aug 25, 2011 at 09:14:38AM +0200, Frediano Ziglio wrote:
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  disas.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Thanks, applied to the trivial patches tree:
http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/trivial-patches

Stefan



[Qemu-devel] [PATCH 07/19] omap1: convert to memory API (part I)

2011-08-25 Thread Avi Kivity
Signed-off-by: Avi Kivity 
---
 hw/omap.h |   11 ++-
 hw/omap1.c|  338 +++-
 hw/omap_sx1.c |4 +-
 hw/palm.c |4 +-
 4 files changed, 203 insertions(+), 154 deletions(-)

diff --git a/hw/omap.h b/hw/omap.h
index db101c6..bae6bed 100644
--- a/hw/omap.h
+++ b/hw/omap.h
@@ -822,6 +822,14 @@ struct omap_mpu_state_s {
 
 qemu_irq wakeup;
 
+MemoryRegion ulpd_pm_iomem;
+MemoryRegion pin_cfg_iomem;
+MemoryRegion id_iomem;
+MemoryRegion id_iomem_e18;
+MemoryRegion id_iomem_ed4;
+MemoryRegion id_iomem_e20;
+MemoryRegion mpui_iomem;
+
 struct omap_dma_port_if_s {
 uint32_t (*read[3])(struct omap_mpu_state_s *s,
 target_phys_addr_t offset);
@@ -943,7 +951,8 @@ struct omap_mpu_state_s {
 };
 
 /* omap1.c */
-struct omap_mpu_state_s *omap310_mpu_init(unsigned long sdram_size,
+struct omap_mpu_state_s *omap310_mpu_init(MemoryRegion *system_memory,
+unsigned long sdram_size,
 const char *core);
 
 /* omap2.c */
diff --git a/hw/omap1.c b/hw/omap1.c
index 614fd31..0f7e14f 100644
--- a/hw/omap1.c
+++ b/hw/omap1.c
@@ -84,6 +84,7 @@ void omap_badwidth_write32(void *opaque, target_phys_addr_t 
addr,
 
 /* MPU OS timers */
 struct omap_mpu_timer_s {
+MemoryRegion iomem;
 qemu_irq irq;
 omap_clk clk;
 uint32_t val;
@@ -179,10 +180,15 @@ static void omap_timer_clk_setup(struct omap_mpu_timer_s 
*timer)
 timer->rate = omap_clk_getrate(timer->clk);
 }
 
-static uint32_t omap_mpu_timer_read(void *opaque, target_phys_addr_t addr)
+static uint64_t omap_mpu_timer_read(void *opaque, target_phys_addr_t addr,
+unsigned size)
 {
 struct omap_mpu_timer_s *s = (struct omap_mpu_timer_s *) opaque;
 
+if (size != 4) {
+return omap_badwidth_read32(opaque, addr);
+}
+
 switch (addr) {
 case 0x00: /* CNTL_TIMER */
 return (s->enable << 5) | (s->ptv << 2) | (s->ar << 1) | s->st;
@@ -199,10 +205,14 @@ static uint32_t omap_mpu_timer_read(void *opaque, 
target_phys_addr_t addr)
 }
 
 static void omap_mpu_timer_write(void *opaque, target_phys_addr_t addr,
-uint32_t value)
+ uint64_t value, unsigned size)
 {
 struct omap_mpu_timer_s *s = (struct omap_mpu_timer_s *) opaque;
 
+if (size != 4) {
+return omap_badwidth_write32(opaque, addr, value);
+}
+
 switch (addr) {
 case 0x00: /* CNTL_TIMER */
 omap_timer_sync(s);
@@ -226,16 +236,10 @@ static void omap_mpu_timer_write(void *opaque, 
target_phys_addr_t addr,
 }
 }
 
-static CPUReadMemoryFunc * const omap_mpu_timer_readfn[] = {
-omap_badwidth_read32,
-omap_badwidth_read32,
-omap_mpu_timer_read,
-};
-
-static CPUWriteMemoryFunc * const omap_mpu_timer_writefn[] = {
-omap_badwidth_write32,
-omap_badwidth_write32,
-omap_mpu_timer_write,
+static const MemoryRegionOps omap_mpu_timer_ops = {
+.read = omap_mpu_timer_read,
+.write = omap_mpu_timer_write,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 static void omap_mpu_timer_reset(struct omap_mpu_timer_s *s)
@@ -250,10 +254,10 @@ static void omap_mpu_timer_reset(struct omap_mpu_timer_s 
*s)
 s->it_ena = 1;
 }
 
-static struct omap_mpu_timer_s *omap_mpu_timer_init(target_phys_addr_t base,
+static struct omap_mpu_timer_s *omap_mpu_timer_init(MemoryRegion 
*system_memory,
+target_phys_addr_t base,
 qemu_irq irq, omap_clk clk)
 {
-int iomemtype;
 struct omap_mpu_timer_s *s = (struct omap_mpu_timer_s *)
 g_malloc0(sizeof(struct omap_mpu_timer_s));
 
@@ -264,9 +268,10 @@ static struct omap_mpu_timer_s 
*omap_mpu_timer_init(target_phys_addr_t base,
 omap_mpu_timer_reset(s);
 omap_timer_clk_setup(s);
 
-iomemtype = cpu_register_io_memory(omap_mpu_timer_readfn,
-omap_mpu_timer_writefn, s, DEVICE_NATIVE_ENDIAN);
-cpu_register_physical_memory(base, 0x100, iomemtype);
+memory_region_init_io(&s->iomem, &omap_mpu_timer_ops, s,
+  "omap-mpu-timer", 0x100);
+
+memory_region_add_subregion(system_memory, base, &s->iomem);
 
 return s;
 }
@@ -274,16 +279,22 @@ static struct omap_mpu_timer_s 
*omap_mpu_timer_init(target_phys_addr_t base,
 /* Watchdog timer */
 struct omap_watchdog_timer_s {
 struct omap_mpu_timer_s timer;
+MemoryRegion iomem;
 uint8_t last_wr;
 int mode;
 int free;
 int reset;
 };
 
-static uint32_t omap_wd_timer_read(void *opaque, target_phys_addr_t addr)
+static uint64_t omap_wd_timer_read(void *opaque, target_phys_addr_t addr,
+   unsigned size)
 {
 struct omap_watchdog_timer_s *s = (struct omap_watchdog_timer_s *) opaque;
 
+if (size != 2) {
+return omap_badwidth_read16(opaque, addr);
+}
+
 switch (addr) {
 case 0x00: /* CNTL_TIMER */
 return (s->timer.ptv << 9) | (s->t

[Qemu-devel] [PATCH 18/19] fdc: Convert isabus_fdc_init1 to MemoryRegion

2011-08-25 Thread Avi Kivity
From: Richard Henderson 

This requires some amount of hoop-jumping, so that we don't
inadvertently claim port 0x3f6, which is used by ISA IDE.

The sysbus initialization path is as yet unconverted.

Signed-off-by: Richard Henderson 
Signed-off-by: Avi Kivity 
---
 hw/fdc.c |   53 +
 1 files changed, 33 insertions(+), 20 deletions(-)

diff --git a/hw/fdc.c b/hw/fdc.c
index 580b657..c3ae956 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -425,6 +425,7 @@ typedef struct FDCtrlSysBus {
 
 typedef struct FDCtrlISABus {
 ISADevice busdev;
+MemoryRegion io_0, io_7;
 struct FDCtrl state;
 int32_t bootindexA;
 int32_t bootindexB;
@@ -490,16 +491,6 @@ static void fdctrl_write (void *opaque, uint32_t reg, 
uint32_t value)
 }
 }
 
-static uint32_t fdctrl_read_port (void *opaque, uint32_t reg)
-{
-return fdctrl_read(opaque, reg & 7);
-}
-
-static void fdctrl_write_port (void *opaque, uint32_t reg, uint32_t value)
-{
-fdctrl_write(opaque, reg & 7, value);
-}
-
 static uint32_t fdctrl_read_mem (void *opaque, target_phys_addr_t reg)
 {
 return fdctrl_read(opaque, (uint32_t)reg);
@@ -1891,6 +1882,34 @@ static int fdctrl_init_common(FDCtrl *fdctrl)
 return fdctrl_connect_drives(fdctrl);
 }
 
+static uint32_t fdctrl_read_port_7(void *opaque, uint32_t reg)
+{
+return fdctrl_read(opaque, reg + 7);
+}
+
+static void fdctrl_write_port_7(void *opaque, uint32_t reg, uint32_t value)
+{
+fdctrl_write(opaque, reg + 7, value);
+}
+
+static const MemoryRegionPortio fdc_portio_0[] = {
+{ 1, 5, 1, .read = fdctrl_read, .write = fdctrl_write },
+PORTIO_END_OF_LIST()
+};
+
+static const MemoryRegionPortio fdc_portio_7[] = {
+{ 0, 1, 1, .read = fdctrl_read_port_7, .write = fdctrl_write_port_7 },
+PORTIO_END_OF_LIST()
+};
+
+static const MemoryRegionOps fdc_ioport_0_ops = {
+.old_portio = fdc_portio_0
+};
+
+static const MemoryRegionOps fdc_ioport_7_ops = {
+.old_portio = fdc_portio_7
+};
+
 static int isabus_fdc_init1(ISADevice *dev)
 {
 FDCtrlISABus *isa = DO_UPCAST(FDCtrlISABus, busdev, dev);
@@ -1900,16 +1919,10 @@ static int isabus_fdc_init1(ISADevice *dev)
 int dma_chann = 2;
 int ret;
 
-register_ioport_read(iobase + 0x01, 5, 1,
- &fdctrl_read_port, fdctrl);
-register_ioport_read(iobase + 0x07, 1, 1,
- &fdctrl_read_port, fdctrl);
-register_ioport_write(iobase + 0x01, 5, 1,
-  &fdctrl_write_port, fdctrl);
-register_ioport_write(iobase + 0x07, 1, 1,
-  &fdctrl_write_port, fdctrl);
-isa_init_ioport_range(dev, iobase, 6);
-isa_init_ioport(dev, iobase + 7);
+memory_region_init_io(&isa->io_0, &fdc_ioport_0_ops, fdctrl, "fdc", 6);
+memory_region_init_io(&isa->io_7, &fdc_ioport_7_ops, fdctrl, "fdc", 1);
+isa_register_ioport(dev, &isa->io_0, iobase);
+isa_register_ioport(dev, &isa->io_7, iobase + 7);
 
 isa_init_irq(&isa->busdev, &fdctrl->irq, isairq);
 fdctrl->dma_chann = dma_chann;
-- 
1.7.5.3




[Qemu-devel] [PATCH 11/19] isa: add isa_register_ioport()

2011-08-25 Thread Avi Kivity
From: Richard Henderson 

To replace isa_init_ioport and isa_init_ioport_range
as the ISA devices are converted to the memory api.

[avi: use memory_region_size()]

Signed-off-by: Richard Henderson 
Signed-off-by: Avi Kivity 
---
 hw/isa-bus.c |   10 ++
 hw/isa.h |5 -
 2 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index d067505..6c15a31 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -108,6 +108,16 @@ void isa_init_ioport(ISADevice *dev, uint16_t ioport)
 isa_init_ioport_range(dev, ioport, 1);
 }
 
+void isa_register_ioport(ISADevice *dev, MemoryRegion *io, uint16_t start)
+{
+memory_region_add_subregion(isabus->address_space_io, start, io);
+if (dev != NULL) {
+assert(dev->nio < ARRAY_SIZE(dev->io));
+dev->io[dev->nio++] = io;
+isa_init_ioport_range(dev, start, memory_region_size(io));
+}
+}
+
 static int isa_qdev_init(DeviceState *qdev, DeviceInfo *base)
 {
 ISADevice *dev = DO_UPCAST(ISADevice, qdev, qdev);
diff --git a/hw/isa.h b/hw/isa.h
index 390e2d4..432d17a 100644
--- a/hw/isa.h
+++ b/hw/isa.h
@@ -13,10 +13,12 @@ typedef struct ISADeviceInfo ISADeviceInfo;
 
 struct ISADevice {
 DeviceState qdev;
+MemoryRegion *io[32];
 uint32_t isairq[2];
-int nirqs;
 uint16_t ioports[32];
+int nirqs;
 int nioports;
+int nio;
 };
 
 typedef int (*isa_qdev_initfn)(ISADevice *dev);
@@ -29,6 +31,7 @@ ISABus *isa_bus_new(DeviceState *dev, MemoryRegion 
*address_space_io);
 void isa_bus_irqs(qemu_irq *irqs);
 qemu_irq isa_get_irq(int isairq);
 void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq);
+void isa_register_ioport(ISADevice *dev, MemoryRegion *io, uint16_t start);
 void isa_init_ioport(ISADevice *dev, uint16_t ioport);
 void isa_init_ioport_range(ISADevice *dev, uint16_t start, uint16_t length);
 void isa_qdev_register(ISADeviceInfo *info);
-- 
1.7.5.3




[Qemu-devel] [PATCH 05/19] mips_r4k: convert to memory API

2011-08-25 Thread Avi Kivity
Signed-off-by: Avi Kivity 
---
 hw/mips_r4k.c |   38 ++
 1 files changed, 14 insertions(+), 24 deletions(-)

diff --git a/hw/mips_r4k.c b/hw/mips_r4k.c
index 51dc868..efa4b05 100644
--- a/hw/mips_r4k.c
+++ b/hw/mips_r4k.c
@@ -42,8 +42,8 @@ static struct _loaderparams {
 const char *initrd_filename;
 } loaderparams;
 
-static void mips_qemu_writel (void *opaque, target_phys_addr_t addr,
- uint32_t val)
+static void mips_qemu_write (void *opaque, target_phys_addr_t addr,
+ uint64_t val, unsigned size)
 {
 if ((addr & 0x) == 0 && val == 42)
 qemu_system_reset_request ();
@@ -51,25 +51,18 @@ static void mips_qemu_writel (void *opaque, 
target_phys_addr_t addr,
 qemu_system_shutdown_request ();
 }
 
-static uint32_t mips_qemu_readl (void *opaque, target_phys_addr_t addr)
+static uint64_t mips_qemu_read (void *opaque, target_phys_addr_t addr,
+unsigned size)
 {
 return 0;
 }
 
-static CPUWriteMemoryFunc * const mips_qemu_write[] = {
-&mips_qemu_writel,
-&mips_qemu_writel,
-&mips_qemu_writel,
+static const MemoryRegionOps mips_qemu_ops = {
+.read = mips_qemu_read,
+.write = mips_qemu_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
 };
 
-static CPUReadMemoryFunc * const mips_qemu_read[] = {
-&mips_qemu_readl,
-&mips_qemu_readl,
-&mips_qemu_readl,
-};
-
-static int mips_qemu_iomemtype = 0;
-
 typedef struct ResetData {
 CPUState *env;
 uint64_t vector;
@@ -163,9 +156,10 @@ void mips_r4k_init (ram_addr_t ram_size,
 const char *initrd_filename, const char *cpu_model)
 {
 char *filename;
-ram_addr_t ram_offset;
 MemoryRegion *address_space_mem = get_system_memory();
+MemoryRegion *ram = g_new(MemoryRegion, 1);
 MemoryRegion *bios = g_new(MemoryRegion, 1);
+MemoryRegion *iomem = g_new(MemoryRegion, 1);
 int bios_size;
 CPUState *env;
 ResetData *reset_info;
@@ -200,16 +194,12 @@ void mips_r4k_init (ram_addr_t ram_size,
 ((unsigned int)ram_size / (1 << 20)));
 exit(1);
 }
-ram_offset = qemu_ram_alloc(NULL, "mips_r4k.ram", ram_size);
+memory_region_init_ram(ram, NULL, "mips_r4k.ram", ram_size);
 
-cpu_register_physical_memory(0, ram_size, ram_offset | IO_MEM_RAM);
+memory_region_add_subregion(address_space_mem, 0, ram);
 
-if (!mips_qemu_iomemtype) {
-mips_qemu_iomemtype = cpu_register_io_memory(mips_qemu_read,
- mips_qemu_write, NULL,
- DEVICE_NATIVE_ENDIAN);
-}
-cpu_register_physical_memory(0x1fbf, 0x1, mips_qemu_iomemtype);
+memory_region_init_io(iomem, &mips_qemu_ops, NULL, "mips-qemu", 0x1);
+memory_region_add_subregion(address_space_mem, 0x1fbf, iomem);
 
 /* Try to load a BIOS image. If this fails, we continue regardless,
but initialize the hardware ourselves. When a kernel gets
-- 
1.7.5.3




[Qemu-devel] [PATCH 09/19] pci: add pci_address_space_io()

2011-08-25 Thread Avi Kivity
From: Richard Henderson 

Returns the I/O address space.  Useful for implementing
PCI-ISA bridge devices.

Signed-off-by: Richard Henderson 
Signed-off-by: Avi Kivity 
---
 hw/pci.c |5 +
 hw/pci.h |1 +
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index 6124790..1a5d2b6 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -2170,3 +2170,8 @@ MemoryRegion *pci_address_space(PCIDevice *dev)
 {
 return dev->bus->address_space_mem;
 }
+
+MemoryRegion *pci_address_space_io(PCIDevice *dev)
+{
+return dev->bus->address_space_io;
+}
diff --git a/hw/pci.h b/hw/pci.h
index 391217e..6bdbe4c 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -221,6 +221,7 @@ void pci_default_write_config(PCIDevice *d,
 void pci_device_save(PCIDevice *s, QEMUFile *f);
 int pci_device_load(PCIDevice *s, QEMUFile *f);
 MemoryRegion *pci_address_space(PCIDevice *dev);
+MemoryRegion *pci_address_space_io(PCIDevice *dev);
 
 typedef void (*pci_set_irq_fn)(void *opaque, int irq_num, int level);
 typedef int (*pci_map_irq_fn)(PCIDevice *pci_dev, int irq_num);
-- 
1.7.5.3




[Qemu-devel] [PATCH 1/2] Fix up some style nits of last uq/master merge

2011-08-25 Thread Stefan Hajnoczi
From: Jan Kiszka 

Signed-off-by: Jan Kiszka 
Signed-off-by: Stefan Hajnoczi 
---
 cutils.c  |2 +-
 target-i386/kvm.c |5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/cutils.c b/cutils.c
index f2bcf20..c91f887 100644
--- a/cutils.c
+++ b/cutils.c
@@ -408,7 +408,7 @@ fail:
 
 int64_t strtosz_suffix(const char *nptr, char **end, const char default_suffix)
 {
-return strtosz_suffix_unit(nptr, end, default_suffix, 1024);
+return strtosz_suffix_unit(nptr, end, default_suffix, 1024);
 }
 
 int64_t strtosz(const char *nptr, char **end)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index bd850ed..1d9b20c 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -501,8 +501,9 @@ int kvm_arch_init_vcpu(CPUState *env)
 qemu_add_vm_change_state_handler(cpu_update_state, env);
 
 r = kvm_vcpu_ioctl(env, KVM_SET_CPUID2, &cpuid_data);
-if (r)
-   return r;
+if (r) {
+return r;
+}
 
 r = kvm_check_extension(env->kvm_state, KVM_CAP_TSC_CONTROL);
 if (r && env->tsc_khz) {
-- 
1.7.5.4




[Qemu-devel] [PATCH 2/2] disasm: update comment

2011-08-25 Thread Stefan Hajnoczi
From: Frediano Ziglio 

Signed-off-by: Frediano Ziglio 
Signed-off-by: Stefan Hajnoczi 
---
 disas.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/disas.c b/disas.c
index 1334b8e..611b30b 100644
--- a/disas.c
+++ b/disas.c
@@ -137,7 +137,7 @@ print_insn_thumb1(bfd_vma pc, disassemble_info *info)
 
 /* Disassemble this for me please... (debugging). 'flags' has the following
values:
-i386 - nonzero means 16 bit code
+i386 - 1 means 16 bit code, 2 means 64 bit code
 arm  - nonzero means thumb code
 ppc  - nonzero means little endian
 other targets - unused
-- 
1.7.5.4




[Qemu-devel] [PULL 0/2] Trivial patches for August 13 to 25 2011

2011-08-25 Thread Stefan Hajnoczi
The following changes since commit 89da90b1b4acf24a9a3f2fd197b1bdf69ab24e72:

  gt64xxx: fix crash in gt64120_pci_mapping() (2011-08-24 21:11:21 +0200)

are available in the git repository at:
  ssh://repo.or.cz/srv/git/qemu/stefanha.git trivial-patches

Frediano Ziglio (1):
  disasm: update comment

Jan Kiszka (1):
  Fix up some style nits of last uq/master merge

 cutils.c  |2 +-
 disas.c   |2 +-
 target-i386/kvm.c |5 +++--
 3 files changed, 5 insertions(+), 4 deletions(-)

-- 
1.7.5.4




[Qemu-devel] [PATCH 16/19] pckbd: Convert to MemoryRegion

2011-08-25 Thread Avi Kivity
From: Richard Henderson 

Slightly non-obvious with mips_jazz passing in the region
structure to populate.

Signed-off-by: Richard Henderson 
Signed-off-by: Avi Kivity 
---
 hw/mips_jazz.c |4 ++-
 hw/pc.h|2 +-
 hw/pckbd.c |   59 ++-
 3 files changed, 40 insertions(+), 25 deletions(-)

diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c
index 4aa5aa4..8a3c3b0 100644
--- a/hw/mips_jazz.c
+++ b/hw/mips_jazz.c
@@ -115,6 +115,7 @@ static void mips_jazz_init(MemoryRegion *address_space,
 rc4030_dma *dmas;
 void* rc4030_opaque;
 MemoryRegion *rtc = g_new(MemoryRegion, 1);
+MemoryRegion *i8042 = g_new(MemoryRegion, 1);
 MemoryRegion *dma_dummy = g_new(MemoryRegion, 1);
 NICInfo *nd;
 DeviceState *dev;
@@ -245,7 +246,8 @@ static void mips_jazz_init(MemoryRegion *address_space,
 memory_region_add_subregion(address_space, 0x80004000, rtc);
 
 /* Keyboard (i8042) */
-i8042_mm_init(rc4030[6], rc4030[7], 0x80005000, 0x1000, 0x1);
+i8042_mm_init(rc4030[6], rc4030[7], i8042, 0x1000, 0x1);
+memory_region_add_subregion(address_space, 0x80005000, i8042);
 
 /* Serial ports */
 if (serial_hds[0]) {
diff --git a/hw/pc.h b/hw/pc.h
index dae736e..28ed210 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -118,7 +118,7 @@ void vmmouse_set_data(const uint32_t *data);
 
 void i8042_init(qemu_irq kbd_irq, qemu_irq mouse_irq, uint32_t io_base);
 void i8042_mm_init(qemu_irq kbd_irq, qemu_irq mouse_irq,
-   target_phys_addr_t base, ram_addr_t size,
+   MemoryRegion *region, ram_addr_t size,
target_phys_addr_t mask);
 void i8042_isa_mouse_fake_event(void *opaque);
 void i8042_setup_a20_line(ISADevice *dev, qemu_irq *a20_out);
diff --git a/hw/pckbd.c b/hw/pckbd.c
index a272ccd..06b40c5 100644
--- a/hw/pckbd.c
+++ b/hw/pckbd.c
@@ -400,33 +400,27 @@ static void kbd_mm_writeb (void *opaque, 
target_phys_addr_t addr, uint32_t value
 kbd_write_data(s, 0, value & 0xff);
 }
 
-static CPUReadMemoryFunc * const kbd_mm_read[] = {
-&kbd_mm_readb,
-&kbd_mm_readb,
-&kbd_mm_readb,
-};
-
-static CPUWriteMemoryFunc * const kbd_mm_write[] = {
-&kbd_mm_writeb,
-&kbd_mm_writeb,
-&kbd_mm_writeb,
+static const MemoryRegionOps i8042_mmio_ops = {
+.endianness = DEVICE_NATIVE_ENDIAN,
+.old_mmio = {
+.read = { kbd_mm_readb, kbd_mm_readb, kbd_mm_readb },
+.write = { kbd_mm_writeb, kbd_mm_writeb, kbd_mm_writeb },
+},
 };
 
 void i8042_mm_init(qemu_irq kbd_irq, qemu_irq mouse_irq,
-   target_phys_addr_t base, ram_addr_t size,
+   MemoryRegion *region, ram_addr_t size,
target_phys_addr_t mask)
 {
 KBDState *s = g_malloc0(sizeof(KBDState));
-int s_io_memory;
 
 s->irq_kbd = kbd_irq;
 s->irq_mouse = mouse_irq;
 s->mask = mask;
 
 vmstate_register(NULL, 0, &vmstate_kbd, s);
-s_io_memory = cpu_register_io_memory(kbd_mm_read, kbd_mm_write, s,
- DEVICE_NATIVE_ENDIAN);
-cpu_register_physical_memory(base, size, s_io_memory);
+
+memory_region_init_io(region, &i8042_mmio_ops, s, "i8042", size);
 
 s->kbd = ps2_kbd_init(kbd_update_kbd_irq, s);
 s->mouse = ps2_mouse_init(kbd_update_aux_irq, s);
@@ -435,7 +429,8 @@ void i8042_mm_init(qemu_irq kbd_irq, qemu_irq mouse_irq,
 
 typedef struct ISAKBDState {
 ISADevice dev;
-KBDState  kbd;
+KBDState kbd;
+MemoryRegion io[2];
 } ISAKBDState;
 
 void i8042_isa_mouse_fake_event(void *opaque)
@@ -464,19 +459,37 @@ static const VMStateDescription vmstate_kbd_isa = {
 }
 };
 
+static const MemoryRegionPortio i8042_data_portio[] = {
+{ 0, 1, 1, .read = kbd_read_data, .write = kbd_write_data },
+PORTIO_END_OF_LIST()
+};
+
+static const MemoryRegionPortio i8042_cmd_portio[] = {
+{ 0, 1, 1, .read = kbd_read_status, .write = kbd_write_command },
+PORTIO_END_OF_LIST()
+};
+
+static const MemoryRegionOps i8042_data_ops = {
+.old_portio = i8042_data_portio
+};
+
+static const MemoryRegionOps i8042_cmd_ops = {
+.old_portio = i8042_cmd_portio
+};
+
 static int i8042_initfn(ISADevice *dev)
 {
-KBDState *s = &(DO_UPCAST(ISAKBDState, dev, dev)->kbd);
+ISAKBDState *isa_s = DO_UPCAST(ISAKBDState, dev, dev);
+KBDState *s = &isa_s->kbd;
 
 isa_init_irq(dev, &s->irq_kbd, 1);
 isa_init_irq(dev, &s->irq_mouse, 12);
 
-register_ioport_read(0x60, 1, 1, kbd_read_data, s);
-register_ioport_write(0x60, 1, 1, kbd_write_data, s);
-isa_init_ioport(dev, 0x60);
-register_ioport_read(0x64, 1, 1, kbd_read_status, s);
-register_ioport_write(0x64, 1, 1, kbd_write_command, s);
-isa_init_ioport(dev, 0x64);
+memory_region_init_io(isa_s->io + 0, &i8042_data_ops, s, "i8042-data", 1);
+isa_register_ioport(dev, isa_s->io + 0, 0x60);
+
+memory_region_init_io(isa_s->io + 1, &i8042_cmd_ops, s, "i8042-cmd", 1);
+isa_register_ioport(d

[Qemu-devel] [PATCH 06/19] musicpal: convert to memory API

2011-08-25 Thread Avi Kivity
Signed-off-by: Avi Kivity 
---
 hw/musicpal.c |  243 +++--
 1 files changed, 99 insertions(+), 144 deletions(-)

diff --git a/hw/musicpal.c b/hw/musicpal.c
index 5e74ee7..ffde117 100644
--- a/hw/musicpal.c
+++ b/hw/musicpal.c
@@ -19,6 +19,7 @@
 #include "console.h"
 #include "i2c.h"
 #include "blockdev.h"
+#include "exec-memory.h"
 
 #define MP_MISC_BASE0x80002000
 #define MP_MISC_SIZE0x1000
@@ -142,6 +143,7 @@ typedef struct mv88w8618_rx_desc {
 
 typedef struct mv88w8618_eth_state {
 SysBusDevice busdev;
+MemoryRegion iomem;
 qemu_irq irq;
 uint32_t smir;
 uint32_t icr;
@@ -260,7 +262,8 @@ static void eth_send(mv88w8618_eth_state *s, int 
queue_index)
 } while (desc_addr != s->tx_queue[queue_index]);
 }
 
-static uint32_t mv88w8618_eth_read(void *opaque, target_phys_addr_t offset)
+static uint64_t mv88w8618_eth_read(void *opaque, target_phys_addr_t offset,
+   unsigned size)
 {
 mv88w8618_eth_state *s = opaque;
 
@@ -302,7 +305,7 @@ static uint32_t mv88w8618_eth_read(void *opaque, 
target_phys_addr_t offset)
 }
 
 static void mv88w8618_eth_write(void *opaque, target_phys_addr_t offset,
-uint32_t value)
+uint64_t value, unsigned size)
 {
 mv88w8618_eth_state *s = opaque;
 
@@ -353,16 +356,10 @@ static void mv88w8618_eth_write(void *opaque, 
target_phys_addr_t offset,
 }
 }
 
-static CPUReadMemoryFunc * const mv88w8618_eth_readfn[] = {
-mv88w8618_eth_read,
-mv88w8618_eth_read,
-mv88w8618_eth_read
-};
-
-static CPUWriteMemoryFunc * const mv88w8618_eth_writefn[] = {
-mv88w8618_eth_write,
-mv88w8618_eth_write,
-mv88w8618_eth_write
+static const MemoryRegionOps mv88w8618_eth_ops = {
+.read = mv88w8618_eth_read,
+.write = mv88w8618_eth_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
 };
 
 static void eth_cleanup(VLANClientState *nc)
@@ -387,10 +384,9 @@ static int mv88w8618_eth_init(SysBusDevice *dev)
 sysbus_init_irq(dev, &s->irq);
 s->nic = qemu_new_nic(&net_mv88w8618_info, &s->conf,
   dev->qdev.info->name, dev->qdev.id, s);
-s->mmio_index = cpu_register_io_memory(mv88w8618_eth_readfn,
-   mv88w8618_eth_writefn, s,
-   DEVICE_NATIVE_ENDIAN);
-sysbus_init_mmio(dev, MP_ETH_SIZE, s->mmio_index);
+memory_region_init_io(&s->iomem, &mv88w8618_eth_ops, s, "mv88w8618-eth",
+  MP_ETH_SIZE);
+sysbus_init_mmio_region(dev, &s->iomem);
 return 0;
 }
 
@@ -444,6 +440,7 @@ static SysBusDeviceInfo mv88w8618_eth_info = {
 
 typedef struct musicpal_lcd_state {
 SysBusDevice busdev;
+MemoryRegion iomem;
 uint32_t brightness;
 uint32_t mode;
 uint32_t irqctrl;
@@ -528,7 +525,8 @@ static void musicpal_lcd_gpio_brigthness_in(void *opaque, 
int irq, int level)
 s->brightness |= level << irq;
 }
 
-static uint32_t musicpal_lcd_read(void *opaque, target_phys_addr_t offset)
+static uint64_t musicpal_lcd_read(void *opaque, target_phys_addr_t offset,
+  unsigned size)
 {
 musicpal_lcd_state *s = opaque;
 
@@ -542,7 +540,7 @@ static uint32_t musicpal_lcd_read(void *opaque, 
target_phys_addr_t offset)
 }
 
 static void musicpal_lcd_write(void *opaque, target_phys_addr_t offset,
-   uint32_t value)
+   uint64_t value, unsigned size)
 {
 musicpal_lcd_state *s = opaque;
 
@@ -581,29 +579,21 @@ static void musicpal_lcd_write(void *opaque, 
target_phys_addr_t offset,
 }
 }
 
-static CPUReadMemoryFunc * const musicpal_lcd_readfn[] = {
-musicpal_lcd_read,
-musicpal_lcd_read,
-musicpal_lcd_read
-};
-
-static CPUWriteMemoryFunc * const musicpal_lcd_writefn[] = {
-musicpal_lcd_write,
-musicpal_lcd_write,
-musicpal_lcd_write
+static const MemoryRegionOps musicpal_lcd_ops = {
+.read = musicpal_lcd_read,
+.write = musicpal_lcd_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
 };
 
 static int musicpal_lcd_init(SysBusDevice *dev)
 {
 musicpal_lcd_state *s = FROM_SYSBUS(musicpal_lcd_state, dev);
-int iomemtype;
 
 s->brightness = 7;
 
-iomemtype = cpu_register_io_memory(musicpal_lcd_readfn,
-   musicpal_lcd_writefn, s,
-   DEVICE_NATIVE_ENDIAN);
-sysbus_init_mmio(dev, MP_LCD_SIZE, iomemtype);
+memory_region_init_io(&s->iomem, &musicpal_lcd_ops, s,
+  "musicpal-lcd", MP_LCD_SIZE);
+sysbus_init_mmio_region(dev, &s->iomem);
 
 s->ds = graphic_console_init(lcd_refresh, lcd_invalidate,
  NULL, NULL, s);
@@ -645,6 +635,7 @@ static SysBusDeviceInfo musicpal_lcd_info = {
 typedef struct mv88w8618_pic_state
 {
 SysBusDevice busdev;
+MemoryRegion iomem

[Qemu-devel] [PATCH 03/19] mips_malta: convert to memory API

2011-08-25 Thread Avi Kivity
Signed-off-by: Avi Kivity 
---
 hw/mips_malta.c |   53 +++--
 1 files changed, 27 insertions(+), 26 deletions(-)

diff --git a/hw/mips_malta.c b/hw/mips_malta.c
index b5c9bcf..a093b65 100644
--- a/hw/mips_malta.c
+++ b/hw/mips_malta.c
@@ -57,6 +57,9 @@
 #define MAX_IDE_BUS 2
 
 typedef struct {
+MemoryRegion iomem;
+MemoryRegion iomem_lo; /* 0 - 0x900 */
+MemoryRegion iomem_hi; /* 0xa00 - 0x10 */
 uint32_t leds;
 uint32_t brk;
 uint32_t gpout;
@@ -215,7 +218,8 @@ static void eeprom24c0x_write(int scl, int sda)
 eeprom.sda = sda;
 }
 
-static uint32_t malta_fpga_readl(void *opaque, target_phys_addr_t addr)
+static uint64_t malta_fpga_read(void *opaque, target_phys_addr_t addr,
+unsigned size)
 {
 MaltaFPGAState *s = opaque;
 uint32_t val = 0;
@@ -302,8 +306,8 @@ static uint32_t malta_fpga_readl(void *opaque, 
target_phys_addr_t addr)
 return val;
 }
 
-static void malta_fpga_writel(void *opaque, target_phys_addr_t addr,
-  uint32_t val)
+static void malta_fpga_write(void *opaque, target_phys_addr_t addr,
+ uint64_t val, unsigned size)
 {
 MaltaFPGAState *s = opaque;
 uint32_t saddr;
@@ -328,7 +332,7 @@ static void malta_fpga_writel(void *opaque, 
target_phys_addr_t addr,
 
 /* ASCIIWORD Register */
 case 0x00410:
-snprintf(s->display_text, 9, "%08X", val);
+snprintf(s->display_text, 9, "%08X", (uint32_t)val);
 malta_fpga_update_display(s);
 break;
 
@@ -388,16 +392,10 @@ static void malta_fpga_writel(void *opaque, 
target_phys_addr_t addr,
 }
 }
 
-static CPUReadMemoryFunc * const malta_fpga_read[] = {
-   malta_fpga_readl,
-   malta_fpga_readl,
-   malta_fpga_readl
-};
-
-static CPUWriteMemoryFunc * const malta_fpga_write[] = {
-   malta_fpga_writel,
-   malta_fpga_writel,
-   malta_fpga_writel
+static const MemoryRegionOps malta_fpga_ops = {
+.read = malta_fpga_read,
+.write = malta_fpga_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
 };
 
 static void malta_fpga_reset(void *opaque)
@@ -429,20 +427,22 @@ static void malta_fpga_led_init(CharDriverState *chr)
 qemu_chr_fe_printf(chr, "++\r\n");
 }
 
-static MaltaFPGAState *malta_fpga_init(target_phys_addr_t base, qemu_irq 
uart_irq, CharDriverState *uart_chr)
+static MaltaFPGAState *malta_fpga_init(MemoryRegion *address_space,
+ target_phys_addr_t base, qemu_irq uart_irq, CharDriverState *uart_chr)
 {
 MaltaFPGAState *s;
-int malta;
 
 s = (MaltaFPGAState *)g_malloc0(sizeof(MaltaFPGAState));
 
-malta = cpu_register_io_memory(malta_fpga_read,
-   malta_fpga_write, s,
-   DEVICE_NATIVE_ENDIAN);
+memory_region_init_io(&s->iomem, &malta_fpga_ops, s,
+  "malta-fpga", 0x10);
+memory_region_init_alias(&s->iomem_lo, "malta-fpga",
+ &s->iomem, 0, 0x900);
+memory_region_init_alias(&s->iomem_hi, "malta-fpga",
+ &s->iomem, 0xa00, 0x1-0xa00);
 
-cpu_register_physical_memory(base, 0x900, malta);
-/* 0xa00 is less than a page, so will still get the right offsets.  */
-cpu_register_physical_memory(base + 0xa00, 0x10 - 0xa00, malta);
+memory_region_add_subregion(address_space, base, &s->iomem_lo);
+memory_region_add_subregion(address_space, base + 0xa00, &s->iomem_hi);
 
 s->display = qemu_chr_new("fpga", "vc:320x200", malta_fpga_led_init);
 
@@ -762,8 +762,8 @@ void mips_malta_init (ram_addr_t ram_size,
   const char *initrd_filename, const char *cpu_model)
 {
 char *filename;
-ram_addr_t ram_offset;
 MemoryRegion *address_space_mem = get_system_memory();
+MemoryRegion *ram = g_new(MemoryRegion, 1);
 MemoryRegion *bios = g_new(MemoryRegion, 1);
 MemoryRegion *bios_1e0 = g_new(MemoryRegion, 1);
 MemoryRegion *bios_1fc = g_new(MemoryRegion, 1);
@@ -820,11 +820,11 @@ void mips_malta_init (ram_addr_t ram_size,
 bios_ops = &pflash_cfi01_ops_le;
 #endif
 
-ram_offset = qemu_ram_alloc(NULL, "mips_malta.ram", ram_size);
+memory_region_init_ram(ram, NULL, "mips_malta.ram", ram_size);
 memory_region_init_rom_device(bios, bios_ops, NULL,
   "mips_malta.bios", BIOS_SIZE);
 
-cpu_register_physical_memory(0, ram_size, ram_offset | IO_MEM_RAM);
+memory_region_add_subregion(address_space_mem, 0, ram);
 
 /* Map the bios at two physical locations, as on the real board. */
 memory_region_init_alias(bios_1e0, "bios-1e0", bios, 0, BIOS_SIZE);
@@ -833,7 +833,8 @@ void mips_malta_init (ram_addr_t ram_size,
 memory_region_add_subregion(address_space_mem, 0x1fc0LL, bios_1fc);
 
 /* FPGA */
-malta_fpga_init(0x1f00LL, env->irq[2], serial_hds[2]);
+malta_fpga_init(address_space_mem, 0x1f00LL,
+

[Qemu-devel] [PATCH 17/19] serial: Convert serial_isa_initfn to MemoryRegion

2011-08-25 Thread Avi Kivity
From: Richard Henderson 

The serial_mm_init path is as yet unconverted.

Signed-off-by: Richard Henderson 
Signed-off-by: Avi Kivity 
---
 hw/serial.c |   15 ---
 1 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/hw/serial.c b/hw/serial.c
index ed7fd0a..2e6d212 100644
--- a/hw/serial.c
+++ b/hw/serial.c
@@ -157,6 +157,7 @@ struct SerialState {
 
 typedef struct ISASerialState {
 ISADevice dev;
+MemoryRegion io;
 uint32_t index;
 uint32_t iobase;
 uint32_t isairq;
@@ -755,6 +756,15 @@ void serial_set_frequency(SerialState *s, uint32_t 
frequency)
 static const int isa_serial_io[MAX_SERIAL_PORTS] = { 0x3f8, 0x2f8, 0x3e8, 
0x2e8 };
 static const int isa_serial_irq[MAX_SERIAL_PORTS] = { 4, 3, 4, 3 };
 
+static const MemoryRegionPortio serial_portio[] = {
+{ 0, 8, 1, .read = serial_ioport_read, .write = serial_ioport_write },
+PORTIO_END_OF_LIST()
+};
+
+static const MemoryRegionOps serial_io_ops = {
+.old_portio = serial_portio
+};
+
 static int serial_isa_initfn(ISADevice *dev)
 {
 static int index;
@@ -776,9 +786,8 @@ static int serial_isa_initfn(ISADevice *dev)
 serial_init_core(s);
 qdev_set_legacy_instance_id(&dev->qdev, isa->iobase, 3);
 
-register_ioport_write(isa->iobase, 8, 1, serial_ioport_write, s);
-register_ioport_read(isa->iobase, 8, 1, serial_ioport_read, s);
-isa_init_ioport_range(dev, isa->iobase, 8);
+memory_region_init_io(&isa->io, &serial_io_ops, s, "serial", 8);
+isa_register_ioport(dev, &isa->io, isa->iobase);
 return 0;
 }
 
-- 
1.7.5.3




Re: [Qemu-devel] [PATCH] hw/smc91c111: Convert to MemoryRegion

2011-08-25 Thread Avi Kivity

On 08/24/2011 08:28 PM, Peter Maydell wrote:

Signed-off-by: Peter Maydell
---
This is against master and doesn't depend on or conflict with anything
that's in Avi's branch. (I needed this because I've just rebased qemu-linaro
on master and one of the omap3 boards connects an smc91c111 up to the
omap_gpmc, which means it needs to be able to expose a MemoryRegion*.)



Thanks, applied to memory/queue.  If you need this in soon, feel free to 
ask Anthony to merge it.


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.




[Qemu-devel] [PATCH 12/19] pc: Re-order pc_init1 to initialize the ISA bus before ISA devices

2011-08-25 Thread Avi Kivity
From: Richard Henderson 

In particular, the i8259 was being initialized before the ISA bus,
leading to a crash.

Signed-off-by: Richard Henderson 
Signed-off-by: Avi Kivity 
---
 hw/pc_piix.c |   22 --
 1 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 9a8f580..322f267 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -123,17 +123,7 @@ static void pc_init1(MemoryRegion *system_memory,
pci_memory, &ram_memory);
 }
 
-if (!xen_enabled()) {
-cpu_irq = pc_allocate_cpu_irq();
-i8259 = i8259_init(cpu_irq[0]);
-} else {
-i8259 = xen_interrupt_controller_init();
-}
 isa_irq_state = g_malloc0(sizeof(*isa_irq_state));
-isa_irq_state->i8259 = i8259;
-if (pci_enabled) {
-ioapic_init(isa_irq_state);
-}
 isa_irq = qemu_allocate_irqs(isa_irq_handler, isa_irq_state, 24);
 
 if (pci_enabled) {
@@ -153,6 +143,18 @@ static void pc_init1(MemoryRegion *system_memory,
 }
 isa_bus_irqs(isa_irq);
 
+if (!xen_enabled()) {
+cpu_irq = pc_allocate_cpu_irq();
+i8259 = i8259_init(cpu_irq[0]);
+} else {
+i8259 = xen_interrupt_controller_init();
+}
+
+isa_irq_state->i8259 = i8259;
+if (pci_enabled) {
+ioapic_init(isa_irq_state);
+}
+
 pc_register_ferr_irq(isa_get_irq(13));
 
 pc_vga_init(pci_enabled? pci_bus: NULL);
-- 
1.7.5.3




Re: [Qemu-devel] [PATCH v3 5/6] vga: Use linear mapping + dirty logging in chain 4 memory access mode

2011-08-25 Thread Jan Kiszka
On 2011-08-25 09:19, Avi Kivity wrote:
> On 08/22/2011 08:12 PM, Jan Kiszka wrote:
>> Most VGA memory access modes require MMIO handling as they demand weird
>> logic to get a byte from or into the video RAM. However, there is one
>> exception: chain 4 mode with all memory planes enabled for writing. This
>> mode actually allows lineary mapping, which can then be combined with
>> dirty logging to accelerate KVM.
>>
>> This patch accelerates specifically VBE accesses like they are used by
>> grub in graphical mode. Not only the standard VGA adapter benefits from
>> this, also vmware and spice in VGA mode.
>>
>>
> 
> On which version of grub does this work?  This isn't having any effect 
> on my Fedora grub.

It's both grub1 (0.97) in graphical mode as used by OpenSUSE 11.4 and
grub2 (1.99-rc1) of Ubuntu 11.04.

Is Fedora's grub still slow or was it already fast before? Which Fedora?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



Re: [Qemu-devel] [PATCH 10/14] qapi: add change-vnc-password

2011-08-25 Thread Gerd Hoffmann

On 08/24/11 20:43, Anthony Liguori wrote:

This is a new QMP only command that only changes the VNC password.


What is wrong with "set_password vnc $secret" ?

cheers,
  Gerd




[Qemu-devel] [PATCH] vga: Silence bogus gcc warning about uninitialized variables

2011-08-25 Thread Jan Kiszka
Some gcc versions do not properly detect that all possible cases are
covered and base and size are always initialized. Please gcc by defining
a pseudo default case.

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

diff --git a/hw/vga.c b/hw/vga.c
index 851fd68..125fb29 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -176,6 +176,7 @@ static void vga_update_memory_access(VGACommonState *s)
 size = 0x8000;
 break;
 case 3:
+default:
 base = 0xb8000;
 size = 0x8000;
 break;
-- 
1.7.3.4



[Qemu-devel] [PATCH 04/19] mips_mipssim: convert to memory API

2011-08-25 Thread Avi Kivity
Signed-off-by: Avi Kivity 
---
 hw/mips_mipssim.c |   16 +---
 1 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/hw/mips_mipssim.c b/hw/mips_mipssim.c
index 0d46cc4..d013494 100644
--- a/hw/mips_mipssim.c
+++ b/hw/mips_mipssim.c
@@ -35,6 +35,7 @@
 #include "mips-bios.h"
 #include "loader.h"
 #include "elf.h"
+#include "exec-memory.h"
 
 static struct _loaderparams {
 int ram_size;
@@ -119,8 +120,9 @@ mips_mipssim_init (ram_addr_t ram_size,
const char *initrd_filename, const char *cpu_model)
 {
 char *filename;
-ram_addr_t ram_offset;
-ram_addr_t bios_offset;
+MemoryRegion *address_space_mem = get_system_memory();
+MemoryRegion *ram = g_new(MemoryRegion, 1);
+MemoryRegion *bios = g_new(MemoryRegion, 1);
 CPUState *env;
 ResetData *reset_info;
 int bios_size;
@@ -144,14 +146,14 @@ mips_mipssim_init (ram_addr_t ram_size,
 qemu_register_reset(main_cpu_reset, reset_info);
 
 /* Allocate RAM. */
-ram_offset = qemu_ram_alloc(NULL, "mips_mipssim.ram", ram_size);
-bios_offset = qemu_ram_alloc(NULL, "mips_mipssim.bios", BIOS_SIZE);
+memory_region_init_ram(ram, NULL, "mips_mipssim.ram", ram_size);
+memory_region_init_ram(bios, NULL, "mips_mipssim.bios", BIOS_SIZE);
+memory_region_set_readonly(bios, true);
 
-cpu_register_physical_memory(0, ram_size, ram_offset | IO_MEM_RAM);
+memory_region_add_subregion(address_space_mem, 0, ram);
 
 /* Map the BIOS / boot exception handler. */
-cpu_register_physical_memory(0x1fc0LL,
- BIOS_SIZE, bios_offset | IO_MEM_ROM);
+memory_region_add_subregion(address_space_mem, 0x1fc0LL, bios);
 /* Load a BIOS / boot exception handler image. */
 if (bios_name == NULL)
 bios_name = BIOS_FILENAME;
-- 
1.7.5.3




[Qemu-devel] [PATCH 01/19] mips_fulong2e: convert to memory API

2011-08-25 Thread Avi Kivity
Signed-off-by: Avi Kivity 
---
 hw/mips_fulong2e.c |   17 ++---
 1 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/hw/mips_fulong2e.c b/hw/mips_fulong2e.c
index ec8c88e..abe3056 100644
--- a/hw/mips_fulong2e.c
+++ b/hw/mips_fulong2e.c
@@ -38,6 +38,7 @@
 #include "vt82c686.h"
 #include "mc146818rtc.h"
 #include "blockdev.h"
+#include "exec-memory.h"
 
 #define DEBUG_FULONG2E_INIT
 
@@ -256,7 +257,9 @@ static void mips_fulong2e_init(ram_addr_t ram_size, const 
char *boot_device,
 const char *initrd_filename, const char *cpu_model)
 {
 char *filename;
-unsigned long ram_offset, bios_offset;
+MemoryRegion *address_space_mem = get_system_memory();
+MemoryRegion *ram = g_new(MemoryRegion, 1);
+MemoryRegion *bios = g_new(MemoryRegion, 1);
 long bios_size;
 int64_t kernel_entry;
 qemu_irq *i8259;
@@ -288,12 +291,12 @@ static void mips_fulong2e_init(ram_addr_t ram_size, const 
char *boot_device,
 bios_size = 1024 * 1024;
 
 /* allocate RAM */
-ram_offset = qemu_ram_alloc(NULL, "fulong2e.ram", ram_size);
-bios_offset = qemu_ram_alloc(NULL, "fulong2e.bios", bios_size);
+memory_region_init_ram(ram, NULL, "fulong2e.ram", ram_size);
+memory_region_init_ram(bios, NULL, "fulong2e.bios", bios_size);
+memory_region_set_readonly(bios, true);
 
-cpu_register_physical_memory(0, ram_size, ram_offset);
-cpu_register_physical_memory(0x1fc0LL,
-  bios_size, bios_offset | IO_MEM_ROM);
+memory_region_add_subregion(address_space_mem, 0, ram);
+memory_region_add_subregion(address_space_mem, 0x1fc0LL, bios);
 
 /* We do not support flash operation, just loading pmon.bin as raw BIOS.
  * Please use -L to set the BIOS path and -bios to set bios name. */
@@ -304,7 +307,7 @@ static void mips_fulong2e_init(ram_addr_t ram_size, const 
char *boot_device,
 loaderparams.kernel_cmdline = kernel_cmdline;
 loaderparams.initrd_filename = initrd_filename;
 kernel_entry = load_kernel (env);
-write_bootloader(env, qemu_get_ram_ptr(bios_offset), kernel_entry);
+write_bootloader(env, memory_region_get_ram_ptr(bios), kernel_entry);
 } else {
 if (bios_name == NULL) {
 bios_name = FULONG_BIOSNAME;
-- 
1.7.5.3




[Qemu-devel] [PATCH 13/19] cs4231a: Convert to MemoryRegion

2011-08-25 Thread Avi Kivity
From: Richard Henderson 

Signed-off-by: Richard Henderson 
Signed-off-by: Avi Kivity 
---
 hw/cs4231a.c |   38 +++---
 1 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/hw/cs4231a.c b/hw/cs4231a.c
index 598f032..e16665e 100644
--- a/hw/cs4231a.c
+++ b/hw/cs4231a.c
@@ -59,6 +59,7 @@ static struct {
 typedef struct CSState {
 ISADevice dev;
 QEMUSoundCard card;
+MemoryRegion ioports;
 qemu_irq pic;
 uint32_t regs[CS_REGS];
 uint8_t dregs[CS_DREGS];
@@ -74,14 +75,6 @@ typedef struct CSState {
 int16_t *tab;
 } CSState;
 
-#define IO_READ_PROTO(name) \
-static uint32_t name (void *opaque, uint32_t addr)
-
-#define IO_WRITE_PROTO(name)\
-static void name (void *opaque, uint32_t addr, uint32_t val)
-
-#define GET_SADDR(addr) (addr & 3)
-
 #define MODE2 (1 << 6)
 #define MCE (1 << 6)
 #define PMCE (1 << 4)
@@ -353,12 +346,12 @@ static void cs_reset_voices (CSState *s, uint32_t val)
 }
 }
 
-IO_READ_PROTO (cs_read)
+static uint64_t cs_read(void *opaque, target_phys_addr_t addr, unsigned size)
 {
 CSState *s = opaque;
 uint32_t saddr, iaddr, ret;
 
-saddr = GET_SADDR (addr);
+saddr = addr;
 iaddr = ~0U;
 
 switch (saddr) {
@@ -390,12 +383,14 @@ IO_READ_PROTO (cs_read)
 return ret;
 }
 
-IO_WRITE_PROTO (cs_write)
+static void cs_write(void *opaque, target_phys_addr_t addr,
+ uint64_t val64, unsigned size)
 {
 CSState *s = opaque;
-uint32_t saddr, iaddr;
+uint32_t saddr, iaddr, val;
 
-saddr = GET_SADDR (addr);
+saddr = addr;
+val = val64;
 
 switch (saddr) {
 case Index_Address:
@@ -637,18 +632,23 @@ static const VMStateDescription vmstate_cs4231a = {
 }
 };
 
+static const MemoryRegionOps cs_ioport_ops = {
+.read = cs_read,
+.write = cs_write,
+.impl = {
+.min_access_size = 1,
+.max_access_size = 1,
+}
+};
+
 static int cs4231a_initfn (ISADevice *dev)
 {
 CSState *s = DO_UPCAST (CSState, dev, dev);
-int i;
 
 isa_init_irq (dev, &s->pic, s->irq);
 
-for (i = 0; i < 4; i++) {
-isa_init_ioport(dev, i);
-register_ioport_write (s->port + i, 1, 1, cs_write, s);
-register_ioport_read (s->port + i, 1, 1, cs_read, s);
-}
+memory_region_init_io(&s->ioports, &cs_ioport_ops, s, "cs4231a", 4);
+isa_register_ioport(dev, &s->ioports, s->port);
 
 DMA_register_channel (s->dma, cs_dma_read, s);
 
-- 
1.7.5.3




Re: [Qemu-devel] [PATCH v3 5/6] vga: Use linear mapping + dirty logging in chain 4 memory access mode

2011-08-25 Thread Avi Kivity

On 08/25/2011 12:07 PM, Jan Kiszka wrote:

>>
>
>  On which version of grub does this work?  This isn't having any effect
>  on my Fedora grub.

It's both grub1 (0.97) in graphical mode as used by OpenSUSE 11.4 and
grub2 (1.99-rc1) of Ubuntu 11.04.

Is Fedora's grub still slow or was it already fast before? Which Fedora?



Still slow.  I tried an old F11 image I had lying around, and -snapshot 
/dev/sda, but this laptop was installed many years ago.  I'll download 
some more images and try.



--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.




Re: [Qemu-devel] [PATCH v3 5/6] vga: Use linear mapping + dirty logging in chain 4 memory access mode

2011-08-25 Thread Jan Kiszka
On 2011-08-25 11:16, Avi Kivity wrote:
> On 08/25/2011 12:07 PM, Jan Kiszka wrote:

>>>
>>>  On which version of grub does this work?  This isn't having any effect
>>>  on my Fedora grub.
>>
>> It's both grub1 (0.97) in graphical mode as used by OpenSUSE 11.4 and
>> grub2 (1.99-rc1) of Ubuntu 11.04.
>>
>> Is Fedora's grub still slow or was it already fast before? Which Fedora?
>>
> 
> Still slow.  I tried an old F11 image I had lying around, and -snapshot 
> /dev/sda, but this laptop was installed many years ago.  I'll download 
> some more images and try.

You may also want to instrument vga_update_memory_access if some
requirement for linear mapping is not fulfilled.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



[Qemu-devel] [PATCH 19/19] pci: simplify memory region registration

2011-08-25 Thread Avi Kivity
The two code paths (for ADDRESS_SPACE_IO and ADDRESS_SPACE_MEM) are almost
identical.  Unify them.

Signed-off-by: Avi Kivity 
---
 hw/pci.c |   15 ---
 1 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index 1a5d2b6..e9e37ef 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1059,18 +1059,11 @@ static void pci_update_mappings(PCIDevice *d)
  * Teach them such cases, such that filtered_size < size and
  * addr & (size - 1) != 0.
  */
-if (r->type & PCI_BASE_ADDRESS_SPACE_IO) {
-memory_region_add_subregion_overlap(r->address_space,
-r->addr,
-r->memory,
-1);
-} else {
-memory_region_add_subregion_overlap(r->address_space,
-pci_to_cpu_addr(d->bus,
-r->addr),
-r->memory,
-1);
+if (!(r->type & PCI_BASE_ADDRESS_SPACE_IO)) {
+new_addr = pci_to_cpu_addr(d->bus, new_addr);
 }
+memory_region_add_subregion_overlap(r->address_space,
+new_addr, r->memory, 1);
 }
 }
 }
-- 
1.7.5.3




Re: [Qemu-devel] [PATCH] qed: make qed_alloc_clusters round up offset to nearest cluster

2011-08-25 Thread Stefan Hajnoczi
On Tue, Aug 23, 2011 at 02:38:00PM +0200, Kevin Wolf wrote:
> Am 16.08.2011 01:16, schrieb Devin Nakamura:
> > Signed-off-by: Devin Nakamura 
> > ---
> >  block/qed.c |2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/block/qed.c b/block/qed.c
> > index 333f067..9a1e49c 100644
> > --- a/block/qed.c
> > +++ b/block/qed.c
> > @@ -263,6 +263,8 @@ static int qed_read_string(BlockDriverState *file, 
> > uint64_t offset, size_t n,
> >   */
> >  static uint64_t qed_alloc_clusters(BDRVQEDState *s, unsigned int n)
> >  {
> > +s->file_size =  qed_start_of_cluster(s, s->file_size +
> > + s->header.cluster_size - 1);
> >  uint64_t offset = s->file_size;
> >  s->file_size += n * s->header.cluster_size;
> >  return offset;
> 
> Stefan, Devin, have you come to a conclusion about this patch?

Yes, I suggested keeping the current contraint that file_size is
cluster-aligned.

Devin, does that work for you?

Stefan



Re: [Qemu-devel] [RFC PATCH V1 12/14] microblaze: Make the MSR PVR bit non writable

2011-08-25 Thread Peter Maydell
On 25 August 2011 07:41, Peter A. G. Crosthwaite
 wrote:
> From: Edgar E. Iglesias 
>
> Instead of hardcoding it to 1.

This and patch 13/14 seem to be generic target-microblaze
fixes -- did you mean to include them in this devicetree
series rather than sending them separately?

-- PMM



Re: [Qemu-devel] [PATCH 2/2] disasm: update comment

2011-08-25 Thread Peter Maydell
On 25 August 2011 09:44, Stefan Hajnoczi  wrote:
>  /* Disassemble this for me please... (debugging). 'flags' has the following
>    values:
> -    i386 - nonzero means 16 bit code
> +    i386 - 1 means 16 bit code, 2 means 64 bit code

...presumably 0 means 32 bit code, by elimination ?

-- PMM



Re: [Qemu-devel] [PATCH 2/2] disasm: update comment

2011-08-25 Thread Frediano Ziglio
2011/8/25 Peter Maydell :
> On 25 August 2011 09:44, Stefan Hajnoczi  wrote:
>>  /* Disassemble this for me please... (debugging). 'flags' has the following
>>    values:
>> -    i386 - nonzero means 16 bit code
>> +    i386 - 1 means 16 bit code, 2 means 64 bit code
>
> ...presumably 0 means 32 bit code, by elimination ?
>
> -- PMM
>

Currently you can pass even 10 :)
Yes, 0 (default) means 32 bit.

Frediano



Re: [Qemu-devel] X86 CPU topology broken in qemu ?

2011-08-25 Thread Avi Kivity
> Hi,
> 
> I see that x86 CPU topology inside VM is not showing up as specified.
> With some debugging, I found out that the root cause for this: qemu is
> not enumerating the apic ids correctly for vcpus. I made the below
> hackish change to get it working. Has anybody else seen this problem
> ? This patch is on qemu-kvm-0.14.1. Using 2.6.39 for guest.
> 
> ***
> Fix apic id enumeration
> 
> apic id returned to guest kernel in ebx for cpuid(function=1) depends
> on
> CPUX86State->cpuid_apic_id which gets populated after the cpuid
> information
> is cached in the host kernel.
> 
> Fix this by setting cpuid_apic_id before cpuid information is passed
> to
> the host kernel.
> 

> Index: qemu-kvm-0.14.1/hw/pc.c
> ===
> --- qemu-kvm-0.14.1.orig/hw/pc.c
> +++ qemu-kvm-0.14.1/hw/pc.c

Please post a patch against qemu.git master branch.

> 
> + if (env->cpuid_features & CPUID_APIC)
> + env->cpuid_apic_id = env->cpu_index;
> +

qemu coding style requires braces even around single statements in if () blocks.




Re: [Qemu-devel] Guest kernel device compatability auto-detection

2011-08-25 Thread Richard W.M. Jones
On Thu, Aug 25, 2011 at 08:48:25AM +0100, Richard W.M. Jones wrote:
> On Thu, Aug 25, 2011 at 10:40:34AM +0300, Sasha Levin wrote:
> > From what I gathered libguestfs only provides access to the guests'
> > image.
> 
> Correct.
> 
> > Which part is doing the IKCONFIG or System.map probing? Or is it done in
> > a different way?
> 
> You'll have to see what Matt's doing in the virt-v2v code for the
> details, but in general we have full access to:
> 
>  - grub.conf (to determine which kernel will boot)
>  - the kernel image
>  - the corresponding System.map and config
>  - the modules directory
>  - the Xorg config
>  - boot.ini or BCD (to determine which NT kernel will boot)
>  - the Windows Registry
>  - the list of packages installed (to see if VMware-tools or some other
>guest agent is installed)
> 
> So working out what drivers are available is just a tedious matter of
> iterating across each of these places in the filesystem.

We had some interesting discussion on IRC about this.

Detecting if a guest "supports virtio" is a tricky problem, and it
goes beyond what the guest kernel can do.  For Linux guests you also
need to check what userspace can do.  This means unpacking the initrd
and checking for virtio drivers [in the general case this is
intractable, but you can do it for specific distros].

You also need to check that udev has the correct rules and that LVM is
configured to see VGs on /dev/vd* devices.

Console and Xorg configuration may also need to be checked (for
virtio-console and Cirrus/QXL support resp.)

virt-v2v does quite a lot of work to *enable* virtio drivers
including:

 - possibly installing a new kernel and updating grub

 - rebuilding the initrd to include virtio drivers

 - adjusting many different config files

 - removing other guest tools and Xen drivers

 - reconfiguring SELinux

 - adding viostor driver to Windows and adjusting the Windows Registry
   Critical Device Database

Of course virt-v2v confines itself to specific known guests, and we
test it like crazy.

Here is the code:

http://git.fedorahosted.org/git/?p=virt-v2v.git;a=blob;f=lib/Sys/VirtConvert/Converter/RedHat.pm;hb=HEAD
http://git.fedorahosted.org/git/?p=virt-v2v.git;a=blob;f=lib/Sys/VirtConvert/Converter/Windows.pm;hb=HEAD

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/



[Qemu-devel] [PATCH] vhost-net: cleanup host notifiers at last step

2011-08-25 Thread Michael S. Tsirkin
When the vhost notifier is disabled, the userspace handler runs
immediately: virtio_pci_set_host_notifier_internal might
call virtio_queue_notify_vq.
Since the VQ state and the tap backend state aren't
recovered yet, this causes
"Guest moved used index from XXX to YYY" assertions.

The solution is to split out host notifier handling
from vhost VQ setup and disable notifiers as our last step
when we stop vhost-net. For symmetry enable them first thing
on start.

Signed-off-by: Michael S. Tsirkin 
---
 hw/vhost.c |   74 +--
 hw/vhost.h |2 +
 hw/vhost_net.c |   16 ++--
 3 files changed, 70 insertions(+), 22 deletions(-)

diff --git a/hw/vhost.c b/hw/vhost.c
index 1886067..0870cb7 100644
--- a/hw/vhost.c
+++ b/hw/vhost.c
@@ -515,11 +515,6 @@ static int vhost_virtqueue_init(struct vhost_dev *dev,
 };
 struct VirtQueue *vvq = virtio_get_queue(vdev, idx);
 
-if (!vdev->binding->set_host_notifier) {
-fprintf(stderr, "binding does not support host notifiers\n");
-return -ENOSYS;
-}
-
 vq->num = state.num = virtio_queue_get_num(vdev, idx);
 r = ioctl(dev->control, VHOST_SET_VRING_NUM, &state);
 if (r) {
@@ -567,12 +562,6 @@ static int vhost_virtqueue_init(struct vhost_dev *dev,
 r = -errno;
 goto fail_alloc;
 }
-r = vdev->binding->set_host_notifier(vdev->binding_opaque, idx, true);
-if (r < 0) {
-fprintf(stderr, "Error binding host notifier: %d\n", -r);
-goto fail_host_notifier;
-}
-
 file.fd = event_notifier_get_fd(virtio_queue_get_host_notifier(vvq));
 r = ioctl(dev->control, VHOST_SET_VRING_KICK, &file);
 if (r) {
@@ -591,8 +580,6 @@ static int vhost_virtqueue_init(struct vhost_dev *dev,
 
 fail_call:
 fail_kick:
-vdev->binding->set_host_notifier(vdev->binding_opaque, idx, false);
-fail_host_notifier:
 fail_alloc:
 cpu_physical_memory_unmap(vq->ring, virtio_queue_get_ring_size(vdev, idx),
   0, 0);
@@ -618,12 +605,6 @@ static void vhost_virtqueue_cleanup(struct vhost_dev *dev,
 .index = idx,
 };
 int r;
-r = vdev->binding->set_host_notifier(vdev->binding_opaque, idx, false);
-if (r < 0) {
-fprintf(stderr, "vhost VQ %d host cleanup failed: %d\n", idx, r);
-fflush(stderr);
-}
-assert (r >= 0);
 r = ioctl(dev->control, VHOST_GET_VRING_BASE, &state);
 if (r < 0) {
 fprintf(stderr, "vhost VQ %d ring restore failed: %d\n", idx, r);
@@ -697,6 +678,60 @@ bool vhost_dev_query(struct vhost_dev *hdev, VirtIODevice 
*vdev)
 hdev->force;
 }
 
+/* Stop processing guest IO notifications in qemu.
+ * Start processing them in vhost in kernel.
+ */
+int vhost_dev_enable_notifiers(struct vhost_dev *hdev, VirtIODevice *vdev)
+{
+int i, r;
+if (!vdev->binding->set_host_notifier) {
+fprintf(stderr, "binding does not support host notifiers\n");
+r = -ENOSYS;
+goto fail;
+}
+
+for (i = 0; i < hdev->nvqs; ++i) {
+r = vdev->binding->set_host_notifier(vdev->binding_opaque, i, true);
+if (r < 0) {
+fprintf(stderr, "vhost VQ %d notifier binding failed: %d\n", i, 
-r);
+goto fail_vq;
+}
+}
+
+return 0;
+fail_vq:
+while (--i >= 0) {
+r = vdev->binding->set_host_notifier(vdev->binding_opaque, i, false);
+if (r < 0) {
+fprintf(stderr, "vhost VQ %d notifier cleanup error: %d\n", i, -r);
+fflush(stderr);
+}
+assert (r >= 0);
+}
+fail:
+return r;
+}
+
+/* Stop processing guest IO notifications in vhost.
+ * Start processing them in qemu.
+ * This might actually run the qemu handlers right away,
+ * so virtio in qemu must be completely setup when this is called.
+ */
+void vhost_dev_disable_notifiers(struct vhost_dev *hdev, VirtIODevice *vdev)
+{
+int i, r;
+
+for (i = 0; i < hdev->nvqs; ++i) {
+r = vdev->binding->set_host_notifier(vdev->binding_opaque, i, false);
+if (r < 0) {
+fprintf(stderr, "vhost VQ %d notifier cleanup failed: %d\n", i, 
-r);
+fflush(stderr);
+}
+assert (r >= 0);
+}
+}
+
+/* Host notifiers must be enabled at this point. */
 int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev)
 {
 int i, r;
@@ -762,6 +797,7 @@ fail:
 return r;
 }
 
+/* Host notifiers must be enabled at this point. */
 void vhost_dev_stop(struct vhost_dev *hdev, VirtIODevice *vdev)
 {
 int i, r;
diff --git a/hw/vhost.h b/hw/vhost.h
index c8c595a..c9452f0 100644
--- a/hw/vhost.h
+++ b/hw/vhost.h
@@ -46,5 +46,7 @@ void vhost_dev_cleanup(struct vhost_dev *hdev);
 bool vhost_dev_query(struct vhost_dev *hdev, VirtIODevice *vdev);
 int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev);
 void vhost_dev_stop(struct vhost_dev *hdev, VirtIODevice *vdev);
+int vhost_dev_enable_notifiers(struct vhost_dev *hdev, VirtIODevice *vdev);
+voi

Re: [Qemu-devel] [RFC PATCH V1 12/14] microblaze: Make the MSR PVR bit non writable

2011-08-25 Thread Peter Crosthwaite
Hi Peter , I included them as they are prerequisite for patch 14. Edgar, can
we get a review / push of these two separate of this series so I can take
them out next revision ?

On Aug 25, 2011 7:34 PM, "Peter Maydell"  wrote:

On 25 August 2011 07:41, Peter A. G. Crosthwaite

 wrote:
> From: Edgar E. Iglesias 
>
...
This and patch 13/14 seem to be generic target-microblaze
fixes -- did you mean to include them in this devicetree
series rather than sending them separately?

-- PMM


Re: [Qemu-devel] [PATCH v3 5/6] vga: Use linear mapping + dirty logging in chain 4 memory access mode

2011-08-25 Thread Avi Kivity

On 08/25/2011 12:21 PM, Jan Kiszka wrote:

>
>  Still slow.  I tried an old F11 image I had lying around, and -snapshot
>  /dev/sda, but this laptop was installed many years ago.  I'll download
>  some more images and try.

You may also want to instrument vga_update_memory_access if some
requirement for linear mapping is not fulfilled.



Plain F15 is slow.  SR2 = SR4 = 0.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.




Re: [Qemu-devel] X86 CPU topology broken in qemu ?

2011-08-25 Thread Jan Kiszka
On 2011-08-17 07:25, Bharata B Rao wrote:
> Hi,
> 
> I see that x86 CPU topology inside VM is not showing up as specified.
> With some debugging, I found out that the root cause for this: qemu is
> not enumerating the apic ids correctly for vcpus. I made the below
> hackish change to get it working.  Has anybody else seen this problem
> ?  This patch is on qemu-kvm-0.14.1. Using 2.6.39 for guest.
> 
> ***
> Fix apic id enumeration
> 
> apic id returned to guest kernel in ebx for cpuid(function=1) depends on
> CPUX86State->cpuid_apic_id which gets populated after the cpuid information
> is cached in the host kernel.
> 
> Fix this by setting cpuid_apic_id before cpuid information is passed to
> the host kernel.
> 
> Signed-off-by: Bharata B Rao 
> ---
>  hw/pc.c   |4 +---
>  target-i386/kvm.c |3 +++
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> Index: qemu-kvm-0.14.1/hw/pc.c
> ===
> --- qemu-kvm-0.14.1.orig/hw/pc.c
> +++ qemu-kvm-0.14.1/hw/pc.c
> @@ -930,10 +930,8 @@ CPUState *pc_new_cpu(const char *cpu_mod
> fprintf(stderr, "Unable to find x86 CPU definition\n");
> exit(1);
> }
> -if ((env->cpuid_features & CPUID_APIC) || smp_cpus > 1) {
> -env->cpuid_apic_id = env->cpu_index;
> +if ((env->cpuid_features & CPUID_APIC) || smp_cpus > 1)
> env->apic_state = apic_init(env, env->cpuid_apic_id);
> -}
> qemu_register_reset(pc_cpu_reset, env);
> pc_cpu_reset(env);
> return env;
> Index: qemu-kvm-0.14.1/target-i386/kvm.c
> ===
> --- qemu-kvm-0.14.1.orig/target-i386/kvm.c
> +++ qemu-kvm-0.14.1/target-i386/kvm.c
> @@ -340,6 +340,9 @@ int kvm_arch_init_vcpu(CPUState *env)
> 
> cpuid_i = 0;
> 
> +if (env->cpuid_features & CPUID_APIC)
> +env->cpuid_apic_id = env->cpu_index;
> +

Moving it only here will break TCG mode. Make sure to test both. I guess
it's best to move cpuid_apic_id initialization into cpu_x86_init. And
you need to take care of the external APIC case (i486) as well.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



Re: [Qemu-devel] [PATCH v3 5/6] vga: Use linear mapping + dirty logging in chain 4 memory access mode

2011-08-25 Thread Jan Kiszka
On 2011-08-25 12:45, Avi Kivity wrote:
> On 08/25/2011 12:21 PM, Jan Kiszka wrote:
>>>
>>>  Still slow.  I tried an old F11 image I had lying around, and -snapshot
>>>  /dev/sda, but this laptop was installed many years ago.  I'll download
>>>  some more images and try.
>>
>> You may also want to instrument vga_update_memory_access if some
>> requirement for linear mapping is not fulfilled.
>>
> 
> Plain F15 is slow.  SR2 = SR4 = 0.

So it's not using chain4 mode. Can you check what mode the adapter is
actually in and how VRAM is accessed? Likely, there is nothing we can do
about it. /me just wonders what makes F15 grub behave differently from
other distro's versions...

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



Re: [Qemu-devel] [PATCH 1/3] Avoid the use of deprecated gnutls gnutls_*_set_priority functions.

2011-08-25 Thread Stefan Hajnoczi
On Mon, Jul 4, 2011 at 11:00 PM, Raghavendra D Prabhu
 wrote:
> The gnutls_*_set_priority family of functions has been marked deprecated
> in 2.12.x. These functions have been superceded by
> gnutls_priority_set_direct().
>
> Signed-off-by: Raghavendra D Prabhu 
> ---
>  ui/vnc-tls.c |   20 +---
>  1 files changed, 1 insertions(+), 19 deletions(-)
>
> diff --git a/ui/vnc-tls.c b/ui/vnc-tls.c
> index dec626c..33a5d8c 100644
> --- a/ui/vnc-tls.c
> +++ b/ui/vnc-tls.c
> @@ -286,10 +286,6 @@ int vnc_tls_validate_certificate(struct VncState *vs)
>
>  int vnc_tls_client_setup(struct VncState *vs,
>                          int needX509Creds) {
> -    static const int cert_type_priority[] = { GNUTLS_CRT_X509, 0 };
> -    static const int protocol_priority[]= { GNUTLS_TLS1_1, GNUTLS_TLS1_0, 
> GNUTLS_SSL3, 0 };
> -    static const int kx_anon[] = {GNUTLS_KX_ANON_DH, 0};
> -    static const int kx_x509[] = {GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA, 
> GNUTLS_KX_DHE_RSA, GNUTLS_KX_SRP, 0};
>
>     VNC_DEBUG("Do TLS setup\n");
>     if (vnc_tls_initialize() < 0) {
> @@ -310,21 +306,7 @@ int vnc_tls_client_setup(struct VncState *vs,
>             return -1;
>         }
>
> -        if (gnutls_kx_set_priority(vs->tls.session, needX509Creds ? kx_x509 
> : kx_anon) < 0) {
> -            gnutls_deinit(vs->tls.session);
> -            vs->tls.session = NULL;
> -            vnc_client_error(vs);
> -            return -1;
> -        }
> -
> -        if (gnutls_certificate_type_set_priority(vs->tls.session, 
> cert_type_priority) < 0) {
> -            gnutls_deinit(vs->tls.session);
> -            vs->tls.session = NULL;
> -            vnc_client_error(vs);
> -            return -1;
> -        }
> -
> -        if (gnutls_protocol_set_priority(vs->tls.session, protocol_priority) 
> < 0) {
> +        if (gnutls_priority_set_direct(vs->tls.session, needX509Creds ? 
> "NORMAL" : "NORMAL:+ANON-DH", NULL) < 0) {
>             gnutls_deinit(vs->tls.session);
>             vs->tls.session = NULL;
>             vnc_client_error(vs);
> --
> 1.7.6

Daniel,
This patch looks good to me but I don't know much about gnutls or
crypto in general.  Would you be willing to review this?

Thanks,
Stefan



Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings

2011-08-25 Thread Roedel, Joerg
On Wed, Aug 24, 2011 at 10:56:13AM -0400, Alex Williamson wrote:
> On Wed, 2011-08-24 at 10:43 +0200, Joerg Roedel wrote:
> > A side-note: Might it be better to expose assigned devices in a guest on
> > a seperate bus? This will make it easier to emulate an IOMMU for the
> > guest inside qemu.
> 
> I think we want that option, sure.  A lot of guests aren't going to
> support hotplugging buses though, so I think our default, map the entire
> guest model should still be using bus 0.  The ACPI gets a lot more
> complicated for that model too; dynamic SSDTs?  Thanks,

Ok, if only AMD-Vi should be emulated then it is not strictly
necessary. For this IOMMU we can specify that devices on the same bus
belong to different IOMMUs. So we can implement an IOMMU that handles
internal qemu-devices and one that handles pass-through devices.
Not sure if this is possible with VT-d too. Okay VT-d emulation would
also require that the devices emulation of a PCIe bridge, no?

Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632




Re: [Qemu-devel] [PATCH 1/3] Avoid the use of deprecated gnutls gnutls_*_set_priority functions.

2011-08-25 Thread Daniel P. Berrange
On Thu, Aug 25, 2011 at 11:54:41AM +0100, Stefan Hajnoczi wrote:
> On Mon, Jul 4, 2011 at 11:00 PM, Raghavendra D Prabhu
>  wrote:
> > The gnutls_*_set_priority family of functions has been marked deprecated
> > in 2.12.x. These functions have been superceded by
> > gnutls_priority_set_direct().
> >
> > Signed-off-by: Raghavendra D Prabhu 
> > ---
> >  ui/vnc-tls.c |   20 +---
> >  1 files changed, 1 insertions(+), 19 deletions(-)
> >
> > diff --git a/ui/vnc-tls.c b/ui/vnc-tls.c
> > index dec626c..33a5d8c 100644
> > --- a/ui/vnc-tls.c
> > +++ b/ui/vnc-tls.c
> > @@ -286,10 +286,6 @@ int vnc_tls_validate_certificate(struct VncState *vs)
> >
> >  int vnc_tls_client_setup(struct VncState *vs,
> >                          int needX509Creds) {
> > -    static const int cert_type_priority[] = { GNUTLS_CRT_X509, 0 };
> > -    static const int protocol_priority[]= { GNUTLS_TLS1_1, GNUTLS_TLS1_0, 
> > GNUTLS_SSL3, 0 };
> > -    static const int kx_anon[] = {GNUTLS_KX_ANON_DH, 0};
> > -    static const int kx_x509[] = {GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA, 
> > GNUTLS_KX_DHE_RSA, GNUTLS_KX_SRP, 0};
> >
> >     VNC_DEBUG("Do TLS setup\n");
> >     if (vnc_tls_initialize() < 0) {
> > @@ -310,21 +306,7 @@ int vnc_tls_client_setup(struct VncState *vs,
> >             return -1;
> >         }
> >
> > -        if (gnutls_kx_set_priority(vs->tls.session, needX509Creds ? 
> > kx_x509 : kx_anon) < 0) {
> > -            gnutls_deinit(vs->tls.session);
> > -            vs->tls.session = NULL;
> > -            vnc_client_error(vs);
> > -            return -1;
> > -        }
> > -
> > -        if (gnutls_certificate_type_set_priority(vs->tls.session, 
> > cert_type_priority) < 0) {
> > -            gnutls_deinit(vs->tls.session);
> > -            vs->tls.session = NULL;
> > -            vnc_client_error(vs);
> > -            return -1;
> > -        }
> > -
> > -        if (gnutls_protocol_set_priority(vs->tls.session, 
> > protocol_priority) < 0) {
> > +        if (gnutls_priority_set_direct(vs->tls.session, needX509Creds ? 
> > "NORMAL" : "NORMAL:+ANON-DH", NULL) < 0) {
> >             gnutls_deinit(vs->tls.session);
> >             vs->tls.session = NULL;
> >             vnc_client_error(vs);
> > --
> > 1.7.6
> 
> Daniel,
> This patch looks good to me but I don't know much about gnutls or
> crypto in general.  Would you be willing to review this?

ACK, this approach is different from what I did in libvirt, but it matches
the recommendations in the GNUTLS manual for setting priority, so I believe
it is good.

Signed-off-by: Daniel P. Berrange 

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|



Re: [Qemu-devel] [PULL] slirp: Fix issues with -mms-bitfields

2011-08-25 Thread Jan Kiszka
On 2011-08-25 03:14, TeLeMan wrote:
> On Wed, Aug 24, 2011 at 17:11, Jan Kiszka  wrote:
>> On 2011-08-23 12:49, TeLeMan wrote:
>>> On Sun, Aug 21, 2011 at 04:00, Stefan Weil  wrote:
 Am 15.08.2011 08:39, schrieb Jan Kiszka:
>
> The following changes since commit
> 3b6ffe50300f13240e1b46420ad05da1116df410:
>
> hw/scsi-bus.c: Fix use of uninitialised variable (2011-08-14 19:34:25
> +)
>
> are available in the git repository at:
> git://git.kiszka.org/qemu.git queues/slirp
>
> Jan Kiszka (1):
> slirp: Fix bit field types in IP header structs
>
> slirp/ip.h | 8 
> slirp/tcp.h | 4 ++--
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> ---
>
> slirp: Fix bit field types in IP header structs
>
> -mms-bitfields prevents that the bitfields in current IP header structs
> are packed into a single byte as it is required. Fix this by using
> uint8_t as backing type.
>
> Signed-off-by: Jan Kiszka 
> ---
> slirp/ip.h | 8 
> slirp/tcp.h | 4 ++--
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/slirp/ip.h b/slirp/ip.h
> index 48ea38e..72dbe9a 100644
> --- a/slirp/ip.h
> +++ b/slirp/ip.h
> @@ -74,10 +74,10 @@ typedef uint32_t n_long; /* long as received from the
> net */
> */
> struct ip {
> #ifdef HOST_WORDS_BIGENDIAN
> - u_int ip_v:4, /* version */
> + uint8_t ip_v:4, /* version */
> ip_hl:4; /* header length */
> #else
> - u_int ip_hl:4, /* header length */
> + uint8_t ip_hl:4, /* header length */
> ip_v:4; /* version */
> #endif
> uint8_t ip_tos; /* type of service */
> @@ -140,10 +140,10 @@ struct ip_timestamp {
> uint8_t ipt_len; /* size of structure (variable) */
> uint8_t ipt_ptr; /* index of current entry */
> #ifdef HOST_WORDS_BIGENDIAN
> - u_int ipt_oflw:4, /* overflow counter */
> + uint8_t ipt_oflw:4, /* overflow counter */
> ipt_flg:4; /* flags, see below */
> #else
> - u_int ipt_flg:4, /* flags, see below */
> + uint8_t ipt_flg:4, /* flags, see below */
> ipt_oflw:4; /* overflow counter */
> #endif
> union ipt_timestamp {
> diff --git a/slirp/tcp.h b/slirp/tcp.h
> index 9d06836..b3817cb 100644
> --- a/slirp/tcp.h
> +++ b/slirp/tcp.h
> @@ -51,10 +51,10 @@ struct tcphdr {
> tcp_seq th_seq; /* sequence number */
> tcp_seq th_ack; /* acknowledgement number */
> #ifdef HOST_WORDS_BIGENDIAN
> - u_int th_off:4, /* data offset */
> + uint8_t th_off:4, /* data offset */
> th_x2:4; /* (unused) */
> #else
> - u_int th_x2:4, /* (unused) */
> + uint8_t th_x2:4, /* (unused) */
> th_off:4; /* data offset */
> #endif
> uint8_t th_flags;

 Tested-by: Stefan Weil 

>>> slirp is still broken on my mingw32. I used "#progma
>>> pack(push,1)/#progma pack(pop)" to resolve this issue.
>>
>> Can you drill down to the bottom of this problem? What fields in what
>> struct are not properly packed? Maybe this is now a compiler bug, so
>> comparing versions may make sense as well.
> arphdr.ar_sip is not aligned on  a 4-byte boundary. See my previous post:
> http://lists.gnu.org/archive/html/qemu-devel/2011-08/msg00964.html

What a mess. Do we really have to go through all 257 packed data structs
in QEMU and add these MS compat bits to all potentially affected ones?

Jan



signature.asc
Description: OpenPGP digital signature


[Qemu-devel] [Bug 833658] [NEW] Qemu ppc does not boot Debian 3.1r8

2011-08-25 Thread Schulz
Public bug reported:

I tried booting the official image debian-31r8-powerpc-binary-1.iso with the 
following commandline:
qemu-system-ppc -boot d -cdrom ../debian-31r8-powerpc-binary-1.iso -hda hd.img. 
The booting process stops with CPU at 100%. I can choose to boot "install-2.4" 
or "install" which both hangs with the last output being "Loading ramdisk". I 
have also tried using the git-tree which crashes qemu with the message 
"qemu/memory.c:1183: memory_region_add_subregion_common: Assertion 
`!subregion->parent' failed." before even showing anything.

Additionally, qemu 0.14.1 shows the same behaviour but qemu 0.13 and
0.12.5 can boot beyond the "Loading ramdisk" message but stops
immediatly afterwards with a messed up console window (letters are
pushed into another, which makes them barely readable) when using
"install". Also "install-2.4" boots with 0.13 and 0.12.5 beyond the
"Loading ramdisk" message but stops with the last message being now
"returning 0x0140 from prom_init".

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/833658

Title:
  Qemu ppc does not boot Debian 3.1r8

Status in QEMU:
  New

Bug description:
  I tried booting the official image debian-31r8-powerpc-binary-1.iso with the 
following commandline:
  qemu-system-ppc -boot d -cdrom ../debian-31r8-powerpc-binary-1.iso -hda 
hd.img. The booting process stops with CPU at 100%. I can choose to boot 
"install-2.4" or "install" which both hangs with the last output being "Loading 
ramdisk". I have also tried using the git-tree which crashes qemu with the 
message "qemu/memory.c:1183: memory_region_add_subregion_common: Assertion 
`!subregion->parent' failed." before even showing anything.

  Additionally, qemu 0.14.1 shows the same behaviour but qemu 0.13 and
  0.12.5 can boot beyond the "Loading ramdisk" message but stops
  immediatly afterwards with a messed up console window (letters are
  pushed into another, which makes them barely readable) when using
  "install". Also "install-2.4" boots with 0.13 and 0.12.5 beyond the
  "Loading ramdisk" message but stops with the last message being now
  "returning 0x0140 from prom_init".

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/833658/+subscriptions



Re: [Qemu-devel] [PATCH v3 5/6] vga: Use linear mapping + dirty logging in chain 4 memory access mode

2011-08-25 Thread Avi Kivity

On 08/25/2011 01:51 PM, Jan Kiszka wrote:

>
>  Plain F15 is slow.  SR2 = SR4 = 0.

So it's not using chain4 mode. Can you check what mode the adapter is
actually in and how VRAM is accessed? Likely, there is nothing we can do
about it. /me just wonders what makes F15 grub behave differently from
other distro's versions...



Do you remember offhand which registers I need to look at?

We need a collection of gdb scripts to find a qdev, dump the memory 
hierarchy, look up gpas, and get info about specific devices.


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.




Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings

2011-08-25 Thread Roedel, Joerg
Hi Alex,

On Wed, Aug 24, 2011 at 05:13:49PM -0400, Alex Williamson wrote:
> Is this roughly what you're thinking of for the iommu_group component?
> Adding a dev_to_group iommu ops callback let's us consolidate the sysfs
> support in the iommu base.  Would AMD-Vi do something similar (or
> exactly the same) for group #s?  Thanks,

The concept looks good, I have some comments, though. On AMD-Vi the
implementation would look a bit different because there is a
data-structure were the information can be gathered from, so no need for
PCI bus scanning there.

> diff --git a/drivers/base/iommu.c b/drivers/base/iommu.c
> index 6e6b6a1..6b54c1a 100644
> --- a/drivers/base/iommu.c
> +++ b/drivers/base/iommu.c
> @@ -17,20 +17,56 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  static struct iommu_ops *iommu_ops;
>  
> +static ssize_t show_iommu_group(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "%lx", iommu_dev_to_group(dev));

Probably add a 0x prefix so userspace knows the format?

> +}
> +static DEVICE_ATTR(iommu_group, S_IRUGO, show_iommu_group, NULL);
> +
> +static int add_iommu_group(struct device *dev, void *unused)
> +{
> + if (iommu_dev_to_group(dev) >= 0)
> + return device_create_file(dev, &dev_attr_iommu_group);
> +
> + return 0;
> +}
> +
> +static int device_notifier(struct notifier_block *nb,
> +unsigned long action, void *data)
> +{
> + struct device *dev = data;
> +
> + if (action == BUS_NOTIFY_ADD_DEVICE)
> + return add_iommu_group(dev, NULL);
> +
> + return 0;
> +}
> +
> +static struct notifier_block device_nb = {
> + .notifier_call = device_notifier,
> +};
> +
>  void register_iommu(struct iommu_ops *ops)
>  {
>   if (iommu_ops)
>   BUG();
>  
>   iommu_ops = ops;
> +
> + /* FIXME - non-PCI, really want for_each_bus() */
> + bus_register_notifier(&pci_bus_type, &device_nb);
> + bus_for_each_dev(&pci_bus_type, NULL, NULL, add_iommu_group);
>  }

We need to solve this differently. ARM is starting to use the iommu-api
too and this definitly does not work there. One possible solution might
be to make the iommu-ops per-bus.

>  bool iommu_found(void)
> @@ -94,6 +130,14 @@ int iommu_domain_has_cap(struct iommu_domain *domain,
>  }
>  EXPORT_SYMBOL_GPL(iommu_domain_has_cap);
>  
> +long iommu_dev_to_group(struct device *dev)
> +{
> + if (iommu_ops->dev_to_group)
> + return iommu_ops->dev_to_group(dev);
> + return -ENODEV;
> +}
> +EXPORT_SYMBOL_GPL(iommu_dev_to_group);

Please rename this to iommu_device_group(). The dev_to_group name
suggests a conversion but it is actually just a property of the device.
Also the return type should not be long but something that fits into
32bit on all platforms. Since you use -ENODEV, probably s32 is a good
choice.

> +
>  int iommu_map(struct iommu_domain *domain, unsigned long iova,
> phys_addr_t paddr, int gfp_order, int prot)
>  {
> diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
> index f02c34d..477259c 100644
> --- a/drivers/pci/intel-iommu.c
> +++ b/drivers/pci/intel-iommu.c
> @@ -404,6 +404,7 @@ static int dmar_map_gfx = 1;
>  static int dmar_forcedac;
>  static int intel_iommu_strict;
>  static int intel_iommu_superpage = 1;
> +static int intel_iommu_no_mf_groups;
>  
>  #define DUMMY_DEVICE_DOMAIN_INFO ((struct device_domain_info *)(-1))
>  static DEFINE_SPINLOCK(device_domain_lock);
> @@ -438,6 +439,10 @@ static int __init intel_iommu_setup(char *str)
>   printk(KERN_INFO
>   "Intel-IOMMU: disable supported super page\n");
>   intel_iommu_superpage = 0;
> + } else if (!strncmp(str, "no_mf_groups", 12)) {
> + printk(KERN_INFO
> + "Intel-IOMMU: disable separate groups for 
> multifunction devices\n");
> + intel_iommu_no_mf_groups = 1;

This should really be a global iommu option and not be VT-d specific.

>  
>   str += strcspn(str, ",");
> @@ -3902,6 +3907,52 @@ static int intel_iommu_domain_has_cap(struct 
> iommu_domain *domain,
>   return 0;
>  }
>  
> +/* Group numbers are arbitrary.  Device with the same group number
> + * indicate the iommu cannot differentiate between them.  To avoid
> + * tracking used groups we just use the seg|bus|devfn of the lowest
> + * level we're able to differentiate devices */
> +static long intel_iommu_dev_to_group(struct device *dev)
> +{
> + struct pci_dev *pdev = to_pci_dev(dev);
> + struct pci_dev *bridge;
> + union {
> + struct {
> + u8 devfn;
> + u8 bus;
> + u16 segment;
> + } pci;
> + u32 group;
> + } id;
> +
> + if (iommu_no_mapping(dev))

Re: [Qemu-devel] [PATCH v3 5/6] vga: Use linear mapping + dirty logging in chain 4 memory access mode

2011-08-25 Thread Jan Kiszka
On 2011-08-25 13:19, Avi Kivity wrote:
> On 08/25/2011 01:51 PM, Jan Kiszka wrote:
>>>
>>>  Plain F15 is slow.  SR2 = SR4 = 0.
>>
>> So it's not using chain4 mode. Can you check what mode the adapter is
>> actually in and how VRAM is accessed? Likely, there is nothing we can do
>> about it. /me just wonders what makes F15 grub behave differently from
>> other distro's versions...
>>
> 
> Do you remember offhand which registers I need to look at?

No, just that there are quite a few. You could check e.g.
http://www.osdever.net/FreeVGA/vga/vga.htm for descriptions. Also check
what paths the mmio handlers take.

> 
> We need a collection of gdb scripts to find a qdev, dump the memory 
> hierarchy, look up gpas, and get info about specific devices.

...or finally have a "device-show" monitor command to dump the device
state. More stable /wrt QEMU internals.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



Re: [Qemu-devel] [PATCH v2 14/22] pflash_cfi01/pflash_cfi02: convert to memory API

2011-08-25 Thread Jan Kiszka
On 2011-08-24 15:40, Avi Kivity wrote:
> cfi02 is annoying in that is ignores some address bits; we probably
> want explicit support in the memory API for that.

...

> diff --git a/hw/musicpal.c b/hw/musicpal.c
> index 63dd391..5e74ee7 100644
> --- a/hw/musicpal.c
> +++ b/hw/musicpal.c
> @@ -1502,6 +1502,7 @@ static void musicpal_init(ram_addr_t ram_size,
>  unsigned long flash_size;
>  DriveInfo *dinfo;
>  ram_addr_t sram_off;
> +MemoryRegion *flash = g_new(MemoryRegion, 1);
>  
>  if (!cpu_model) {
>  cpu_model = "arm926";
> @@ -1565,21 +1566,23 @@ static void musicpal_init(ram_addr_t ram_size,
>   * image is smaller than 32 MB.
>   */
>  #ifdef TARGET_WORDS_BIGENDIAN
> -pflash_cfi02_register(0-MP_FLASH_SIZE_MAX, qemu_ram_alloc(NULL,
> -  "musicpal.flash", flash_size),
> +memory_region_init_rom_device(flash, &pflash_cfi02_ops_be,
> +  NULL, "musicpal.flash", flash_size);
> +pflash_cfi02_register(0-MP_FLASH_SIZE_MAX, flash,
>dinfo->bdrv, 0x1,
>(flash_size + 0x) >> 16,
>MP_FLASH_SIZE_MAX / flash_size,
>2, 0x00BF, 0x236D, 0x, 0x,
> -  0x, 0x2AAA, 1);
> +  0x, 0x2AAA);
>  #else
> -pflash_cfi02_register(0-MP_FLASH_SIZE_MAX, qemu_ram_alloc(NULL,
> -  "musicpal.flash", flash_size),
> +memory_region_init_rom_device(flash, &pflash_cfi02_ops_le,
> +  NULL, "musicpal.flash", flash_size);
> +pflash_cfi02_register(0-MP_FLASH_SIZE_MAX, flash,
>dinfo->bdrv, 0x1,
>(flash_size + 0x) >> 16,
>MP_FLASH_SIZE_MAX / flash_size,
>2, 0x00BF, 0x236D, 0x, 0x,
> -  0x, 0x2AAA, 0);
> +  0x, 0x2AAA);
>  #endif

This would deserve some reordering to reduce the code under #ifdef.

Anyway, it also breaks the musicpal (and presumably all other flash
users) because memory_region_init_rom_device is broken. It assumes
mr->ops is set, but I guess it rather should set that field itself, no?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



Re: [Qemu-devel] [PATCH v2 14/22] pflash_cfi01/pflash_cfi02: convert to memory API

2011-08-25 Thread Avi Kivity

On 08/25/2011 02:37 PM, Jan Kiszka wrote:

On 2011-08-24 15:40, Avi Kivity wrote:
>  cfi02 is annoying in that is ignores some address bits; we probably
>  want explicit support in the memory API for that.

...

>  diff --git a/hw/musicpal.c b/hw/musicpal.c
>  index 63dd391..5e74ee7 100644
>  --- a/hw/musicpal.c
>  +++ b/hw/musicpal.c
>  @@ -1502,6 +1502,7 @@ static void musicpal_init(ram_addr_t ram_size,
>   unsigned long flash_size;
>   DriveInfo *dinfo;
>   ram_addr_t sram_off;
>  +MemoryRegion *flash = g_new(MemoryRegion, 1);
>
>   if (!cpu_model) {
>   cpu_model = "arm926";
>  @@ -1565,21 +1566,23 @@ static void musicpal_init(ram_addr_t ram_size,
>* image is smaller than 32 MB.
>*/
>   #ifdef TARGET_WORDS_BIGENDIAN
>  -pflash_cfi02_register(0-MP_FLASH_SIZE_MAX, qemu_ram_alloc(NULL,
>  -  "musicpal.flash", flash_size),
>  +memory_region_init_rom_device(flash,&pflash_cfi02_ops_be,
>  +  NULL, "musicpal.flash", flash_size);
>  +pflash_cfi02_register(0-MP_FLASH_SIZE_MAX, flash,
> dinfo->bdrv, 0x1,
> (flash_size + 0x)>>  16,
> MP_FLASH_SIZE_MAX / flash_size,
> 2, 0x00BF, 0x236D, 0x, 0x,
>  -  0x, 0x2AAA, 1);
>  +  0x, 0x2AAA);
>   #else
>  -pflash_cfi02_register(0-MP_FLASH_SIZE_MAX, qemu_ram_alloc(NULL,
>  -  "musicpal.flash", flash_size),
>  +memory_region_init_rom_device(flash,&pflash_cfi02_ops_le,
>  +  NULL, "musicpal.flash", flash_size);
>  +pflash_cfi02_register(0-MP_FLASH_SIZE_MAX, flash,
> dinfo->bdrv, 0x1,
> (flash_size + 0x)>>  16,
> MP_FLASH_SIZE_MAX / flash_size,
> 2, 0x00BF, 0x236D, 0x, 0x,
>  -  0x, 0x2AAA, 0);
>  +  0x, 0x2AAA);
>   #endif

This would deserve some reordering to reduce the code under #ifdef.


Sure, but I try to avoid refactoring in these conversions.  We already 
have too many regressions.



Anyway, it also breaks the musicpal (and presumably all other flash
users) because memory_region_init_rom_device is broken. It assumes
mr->ops is set, but I guess it rather should set that field itself, no?



Right, thanks.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.




[Qemu-devel] [PATCH] memory: fix memory_region_init_rom_device() not initializing ->ops

2011-08-25 Thread Avi Kivity
Signed-off-by: Avi Kivity 
---
 memory.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/memory.c b/memory.c
index 8e9ac46..b91c5da 100644
--- a/memory.c
+++ b/memory.c
@@ -967,6 +967,7 @@ void memory_region_init_rom_device(MemoryRegion *mr,
uint64_t size)
 {
 memory_region_init(mr, name, size);
+mr->ops = ops;
 mr->terminates = true;
 mr->destructor = memory_region_destructor_rom_device;
 mr->ram_addr = qemu_ram_alloc(dev, name, size);
-- 
1.7.5.3





Re: [Qemu-devel] [PULL] slirp: Fix issues with -mms-bitfields

2011-08-25 Thread TeLeMan
On Thu, Aug 25, 2011 at 19:04, Jan Kiszka  wrote:
> On 2011-08-25 03:14, TeLeMan wrote:
>> On Wed, Aug 24, 2011 at 17:11, Jan Kiszka  wrote:
>>> On 2011-08-23 12:49, TeLeMan wrote:
 On Sun, Aug 21, 2011 at 04:00, Stefan Weil  wrote:
> Am 15.08.2011 08:39, schrieb Jan Kiszka:
>>
>> The following changes since commit
>> 3b6ffe50300f13240e1b46420ad05da1116df410:
>>
>> hw/scsi-bus.c: Fix use of uninitialised variable (2011-08-14 19:34:25
>> +)
>>
>> are available in the git repository at:
>> git://git.kiszka.org/qemu.git queues/slirp
>>
>> Jan Kiszka (1):
>> slirp: Fix bit field types in IP header structs
>>
>> slirp/ip.h | 8 
>> slirp/tcp.h | 4 ++--
>> 2 files changed, 6 insertions(+), 6 deletions(-)
>>
>> ---
>>
>> slirp: Fix bit field types in IP header structs
>>
>> -mms-bitfields prevents that the bitfields in current IP header structs
>> are packed into a single byte as it is required. Fix this by using
>> uint8_t as backing type.
>>
>> Signed-off-by: Jan Kiszka 
>> ---
>> slirp/ip.h | 8 
>> slirp/tcp.h | 4 ++--
>> 2 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/slirp/ip.h b/slirp/ip.h
>> index 48ea38e..72dbe9a 100644
>> --- a/slirp/ip.h
>> +++ b/slirp/ip.h
>> @@ -74,10 +74,10 @@ typedef uint32_t n_long; /* long as received from the
>> net */
>> */
>> struct ip {
>> #ifdef HOST_WORDS_BIGENDIAN
>> - u_int ip_v:4, /* version */
>> + uint8_t ip_v:4, /* version */
>> ip_hl:4; /* header length */
>> #else
>> - u_int ip_hl:4, /* header length */
>> + uint8_t ip_hl:4, /* header length */
>> ip_v:4; /* version */
>> #endif
>> uint8_t ip_tos; /* type of service */
>> @@ -140,10 +140,10 @@ struct ip_timestamp {
>> uint8_t ipt_len; /* size of structure (variable) */
>> uint8_t ipt_ptr; /* index of current entry */
>> #ifdef HOST_WORDS_BIGENDIAN
>> - u_int ipt_oflw:4, /* overflow counter */
>> + uint8_t ipt_oflw:4, /* overflow counter */
>> ipt_flg:4; /* flags, see below */
>> #else
>> - u_int ipt_flg:4, /* flags, see below */
>> + uint8_t ipt_flg:4, /* flags, see below */
>> ipt_oflw:4; /* overflow counter */
>> #endif
>> union ipt_timestamp {
>> diff --git a/slirp/tcp.h b/slirp/tcp.h
>> index 9d06836..b3817cb 100644
>> --- a/slirp/tcp.h
>> +++ b/slirp/tcp.h
>> @@ -51,10 +51,10 @@ struct tcphdr {
>> tcp_seq th_seq; /* sequence number */
>> tcp_seq th_ack; /* acknowledgement number */
>> #ifdef HOST_WORDS_BIGENDIAN
>> - u_int th_off:4, /* data offset */
>> + uint8_t th_off:4, /* data offset */
>> th_x2:4; /* (unused) */
>> #else
>> - u_int th_x2:4, /* (unused) */
>> + uint8_t th_x2:4, /* (unused) */
>> th_off:4; /* data offset */
>> #endif
>> uint8_t th_flags;
>
> Tested-by: Stefan Weil 
>
 slirp is still broken on my mingw32. I used "#progma
 pack(push,1)/#progma pack(pop)" to resolve this issue.
>>>
>>> Can you drill down to the bottom of this problem? What fields in what
>>> struct are not properly packed? Maybe this is now a compiler bug, so
>>> comparing versions may make sense as well.
>> arphdr.ar_sip is not aligned on  a 4-byte boundary. See my previous post:
>> http://lists.gnu.org/archive/html/qemu-devel/2011-08/msg00964.html
>
> What a mess. Do we really have to go through all 257 packed data structs
> in QEMU and add these MS compat bits to all potentially affected ones?
I prefer to detect -mms-bitfields and remove it in configure.



[Qemu-devel] [PATCH] ui: avoid use of deprecated gnutls_*_set_priority functions

2011-08-25 Thread Stefan Hajnoczi
From: Raghavendra D Prabhu 

The gnutls_*_set_priority family of functions has been marked deprecated
in 2.12.x. These functions have been superceded by
gnutls_priority_set_direct().

Signed-off-by: Raghavendra D Prabhu 
Signed-off-by: Daniel P. Berrange 
Signed-off-by: Stefan Hajnoczi 
---
Re-sending as a top-level patch because the other patches in the series have
other issues/discussions.  Let's get this independent patch in.

 ui/vnc-tls.c |   20 +---
 1 files changed, 1 insertions(+), 19 deletions(-)

diff --git a/ui/vnc-tls.c b/ui/vnc-tls.c
index 2e2456e..48c818a 100644
--- a/ui/vnc-tls.c
+++ b/ui/vnc-tls.c
@@ -286,10 +286,6 @@ int vnc_tls_validate_certificate(struct VncState *vs)
 
 int vnc_tls_client_setup(struct VncState *vs,
  int needX509Creds) {
-static const int cert_type_priority[] = { GNUTLS_CRT_X509, 0 };
-static const int protocol_priority[]= { GNUTLS_TLS1_1, GNUTLS_TLS1_0, 
GNUTLS_SSL3, 0 };
-static const int kx_anon[] = {GNUTLS_KX_ANON_DH, 0};
-static const int kx_x509[] = {GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA, 
GNUTLS_KX_DHE_RSA, GNUTLS_KX_SRP, 0};
 
 VNC_DEBUG("Do TLS setup\n");
 if (vnc_tls_initialize() < 0) {
@@ -310,21 +306,7 @@ int vnc_tls_client_setup(struct VncState *vs,
 return -1;
 }
 
-if (gnutls_kx_set_priority(vs->tls.session, needX509Creds ? kx_x509 : 
kx_anon) < 0) {
-gnutls_deinit(vs->tls.session);
-vs->tls.session = NULL;
-vnc_client_error(vs);
-return -1;
-}
-
-if (gnutls_certificate_type_set_priority(vs->tls.session, 
cert_type_priority) < 0) {
-gnutls_deinit(vs->tls.session);
-vs->tls.session = NULL;
-vnc_client_error(vs);
-return -1;
-}
-
-if (gnutls_protocol_set_priority(vs->tls.session, protocol_priority) < 
0) {
+if (gnutls_priority_set_direct(vs->tls.session, needX509Creds ? 
"NORMAL" : "NORMAL:+ANON-DH", NULL) < 0) {
 gnutls_deinit(vs->tls.session);
 vs->tls.session = NULL;
 vnc_client_error(vs);
-- 
1.7.5.4




Re: [Qemu-devel] [PATCH 08/14] qapi: convert eject (qmp and hmp) to QAPI

2011-08-25 Thread Kevin Wolf
Am 24.08.2011 20:43, schrieb Anthony Liguori:
> Signed-off-by: Anthony Liguori 
> ---
>  blockdev.c   |   22 +++---
>  blockdev.h   |1 -
>  hmp-commands.hx  |3 +--
>  hmp.c|   14 ++
>  hmp.h|1 +
>  qapi-schema.json |   25 +
>  qmp-commands.hx  |3 +--
>  7 files changed, 53 insertions(+), 16 deletions(-)

All of the conversion patches I've read so far add more lines than they
delete (even when you ignore changes to the schema, which is mostly new
documentation), even though I had expected code generation to do the
opposite, that is less hand-written code.

Is this expected, or are these first examples just exceptions?

> diff --git a/blockdev.c b/blockdev.c
> index d272659..6b7fc41 100644
> --- a/blockdev.c
> +++ b/blockdev.c
> @@ -16,6 +16,7 @@
>  #include "sysemu.h"
>  #include "hw/qdev.h"
>  #include "block_int.h"
> +#include "qmp-commands.h"
>  
>  static QTAILQ_HEAD(drivelist, DriveInfo) drives = 
> QTAILQ_HEAD_INITIALIZER(drives);
>  
> @@ -644,32 +645,31 @@ out:
>  return ret;
>  }
>  
> -static int eject_device(Monitor *mon, BlockDriverState *bs, int force)
> +static int eject_device(BlockDriverState *bs, int force, Error **errp)
>  {
>  if (!bdrv_is_removable(bs)) {
> -qerror_report(QERR_DEVICE_NOT_REMOVABLE, bdrv_get_device_name(bs));
> +error_set(errp, QERR_DEVICE_NOT_REMOVABLE, bdrv_get_device_name(bs));
>  return -1;
>  }
>  if (!force && bdrv_is_locked(bs)) {
> -qerror_report(QERR_DEVICE_LOCKED, bdrv_get_device_name(bs));
> +error_set(errp, QERR_DEVICE_LOCKED, bdrv_get_device_name(bs));
>  return -1;
>  }
>  bdrv_close(bs);
>  return 0;
>  }
>  
> -int do_eject(Monitor *mon, const QDict *qdict, QObject **ret_data)
> +void qmp_eject(const char *device, bool has_force, bool force, Error **errp)

Wow, this is ugly. :-)

I would suspect that many cases of optional arguments are like this: If
it isn't specified, the very first thing the monitor handler does is to
assign a default value (false in this case). Can't we include default
values in the schema and get the handling outside instead of an
additional has_xyz parameter that can easily be ignored by accident,
like in the code below?

>  {
>  BlockDriverState *bs;
> -int force = qdict_get_try_bool(qdict, "force", 0);
> -const char *filename = qdict_get_str(qdict, "device");
>  
> -bs = bdrv_find(filename);
> +bs = bdrv_find(device);
>  if (!bs) {
> -qerror_report(QERR_DEVICE_NOT_FOUND, filename);
> -return -1;
> +error_set(errp, QERR_DEVICE_NOT_FOUND, device);
> +return;
>  }
> -return eject_device(mon, bs, force);
> +
> +eject_device(bs, force, errp);
>  }

Kevin



Re: [Qemu-devel] [PATCH 09/14] qapi: convert block_passwd and add set-blockdev-password

2011-08-25 Thread Kevin Wolf
Am 24.08.2011 20:43, schrieb Anthony Liguori:
> block_passwd is unfortunately named so while converting block_passwd to QAPI,
> introduce a more properly named alias.
> 
> Signed-off-by: Anthony Liguori 

I'm not sure if I like the set-blockdev-password alias, for two reasons.

The first one is that blockdev_* is supposed to be the new, clean
interface, so I wouldn't add similarly named commands without having a
look at the big picture. For example, what again was the reason for
having the password separate from other block device options?

The second one is that names like set-foo, get-foo and frob-foo make it
very hard to see what I can do with a foo. If they are called as today
(drive_add, drive_del) and ideally use a consistent prefix (unlike
drive_*, block_*, snapshot_blkdev today), you'll find all of them in the
same place in the documentation and in HMP typing blockdev_ will
show you everything you can do with a block device.

Kevin



Re: [Qemu-devel] [PATCH] ui: avoid use of deprecated gnutls_*_set_priority functions

2011-08-25 Thread Peter Maydell
On 25 August 2011 13:11, Stefan Hajnoczi  wrote:
> From: Raghavendra D Prabhu 
>
> The gnutls_*_set_priority family of functions has been marked deprecated
> in 2.12.x. These functions have been superceded by
> gnutls_priority_set_direct().

Does this constitute a change in the required version of gnutls which
we need to document in the proto-changelog for the next release?
Is it worth updating the configure tls check to check for this function
so we fall back to no-tls if the system version is too old?

-- PMM



Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings

2011-08-25 Thread Roedel, Joerg
On Wed, Aug 24, 2011 at 11:07:46AM -0400, Alex Williamson wrote:
> On Wed, 2011-08-24 at 10:52 +0200, Roedel, Joerg wrote:
> > On Tue, Aug 23, 2011 at 01:08:29PM -0400, Alex Williamson wrote:
> > > On Tue, 2011-08-23 at 15:14 +0200, Roedel, Joerg wrote:
> > 
> > > > Handling it through fds is a good idea. This makes sure that everything
> > > > belongs to one process. I am not really sure yet if we go the way to
> > > > just bind plain groups together or if we create meta-groups. The
> > > > meta-groups thing seems somewhat cleaner, though.
> > > 
> > > I'm leaning towards binding because we need to make it dynamic, but I
> > > don't really have a good picture of the lifecycle of a meta-group.
> > 
> > In my view the life-cycle of the meta-group is a subrange of the
> > qemu-instance's life-cycle.
> 
> I guess I mean the lifecycle of a super-group that's actually exposed as
> a new group in sysfs.  Who creates it?  How?  How are groups dynamically
> added and removed from the super-group?  The group merging makes sense
> to me because it's largely just an optimization that qemu will try to
> merge groups.  If it works, great.  If not, it manages them separately.
> When all the devices from a group are unplugged, unmerge the group if
> necessary.

Right. The super-group thing is an optimization.

> We need to try the polite method of attempting to hot unplug the device
> from qemu first, which the current vfio code already implements.  We can
> then escalate if it doesn't respond.  The current code calls abort in
> qemu if the guest doesn't respond, but I agree we should also be
> enforcing this at the kernel interface.  I think the problem with the
> hard-unplug is that we don't have a good revoke mechanism for the mmio
> mmaps.

For mmio we could stop the guest and replace the mmio region with a
region that is filled with 0xff, no?

Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632




Re: [Qemu-devel] [PULL] slirp: Fix issues with -mms-bitfields

2011-08-25 Thread Jan Kiszka
On 2011-08-25 14:02, TeLeMan wrote:
> On Thu, Aug 25, 2011 at 19:04, Jan Kiszka  wrote:
>> On 2011-08-25 03:14, TeLeMan wrote:
>>> On Wed, Aug 24, 2011 at 17:11, Jan Kiszka  wrote:
 On 2011-08-23 12:49, TeLeMan wrote:
> On Sun, Aug 21, 2011 at 04:00, Stefan Weil  wrote:
>> Am 15.08.2011 08:39, schrieb Jan Kiszka:
>>>
>>> The following changes since commit
>>> 3b6ffe50300f13240e1b46420ad05da1116df410:
>>>
>>> hw/scsi-bus.c: Fix use of uninitialised variable (2011-08-14 19:34:25
>>> +)
>>>
>>> are available in the git repository at:
>>> git://git.kiszka.org/qemu.git queues/slirp
>>>
>>> Jan Kiszka (1):
>>> slirp: Fix bit field types in IP header structs
>>>
>>> slirp/ip.h | 8 
>>> slirp/tcp.h | 4 ++--
>>> 2 files changed, 6 insertions(+), 6 deletions(-)
>>>
>>> ---
>>>
>>> slirp: Fix bit field types in IP header structs
>>>
>>> -mms-bitfields prevents that the bitfields in current IP header structs
>>> are packed into a single byte as it is required. Fix this by using
>>> uint8_t as backing type.
>>>
>>> Signed-off-by: Jan Kiszka 
>>> ---
>>> slirp/ip.h | 8 
>>> slirp/tcp.h | 4 ++--
>>> 2 files changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/slirp/ip.h b/slirp/ip.h
>>> index 48ea38e..72dbe9a 100644
>>> --- a/slirp/ip.h
>>> +++ b/slirp/ip.h
>>> @@ -74,10 +74,10 @@ typedef uint32_t n_long; /* long as received from 
>>> the
>>> net */
>>> */
>>> struct ip {
>>> #ifdef HOST_WORDS_BIGENDIAN
>>> - u_int ip_v:4, /* version */
>>> + uint8_t ip_v:4, /* version */
>>> ip_hl:4; /* header length */
>>> #else
>>> - u_int ip_hl:4, /* header length */
>>> + uint8_t ip_hl:4, /* header length */
>>> ip_v:4; /* version */
>>> #endif
>>> uint8_t ip_tos; /* type of service */
>>> @@ -140,10 +140,10 @@ struct ip_timestamp {
>>> uint8_t ipt_len; /* size of structure (variable) */
>>> uint8_t ipt_ptr; /* index of current entry */
>>> #ifdef HOST_WORDS_BIGENDIAN
>>> - u_int ipt_oflw:4, /* overflow counter */
>>> + uint8_t ipt_oflw:4, /* overflow counter */
>>> ipt_flg:4; /* flags, see below */
>>> #else
>>> - u_int ipt_flg:4, /* flags, see below */
>>> + uint8_t ipt_flg:4, /* flags, see below */
>>> ipt_oflw:4; /* overflow counter */
>>> #endif
>>> union ipt_timestamp {
>>> diff --git a/slirp/tcp.h b/slirp/tcp.h
>>> index 9d06836..b3817cb 100644
>>> --- a/slirp/tcp.h
>>> +++ b/slirp/tcp.h
>>> @@ -51,10 +51,10 @@ struct tcphdr {
>>> tcp_seq th_seq; /* sequence number */
>>> tcp_seq th_ack; /* acknowledgement number */
>>> #ifdef HOST_WORDS_BIGENDIAN
>>> - u_int th_off:4, /* data offset */
>>> + uint8_t th_off:4, /* data offset */
>>> th_x2:4; /* (unused) */
>>> #else
>>> - u_int th_x2:4, /* (unused) */
>>> + uint8_t th_x2:4, /* (unused) */
>>> th_off:4; /* data offset */
>>> #endif
>>> uint8_t th_flags;
>>
>> Tested-by: Stefan Weil 
>>
> slirp is still broken on my mingw32. I used "#progma
> pack(push,1)/#progma pack(pop)" to resolve this issue.

 Can you drill down to the bottom of this problem? What fields in what
 struct are not properly packed? Maybe this is now a compiler bug, so
 comparing versions may make sense as well.
>>> arphdr.ar_sip is not aligned on  a 4-byte boundary. See my previous post:
>>> http://lists.gnu.org/archive/html/qemu-devel/2011-08/msg00964.html
>>
>> What a mess. Do we really have to go through all 257 packed data structs
>> in QEMU and add these MS compat bits to all potentially affected ones?
> I prefer to detect -mms-bitfields and remove it in configure.

/me too - if that is possible, ie. if the glib bits we are using doesn't
require us to apply that mode. Can anyone comment on this?

Jan



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH 12/14] qapi: introduce change-blockdev

2011-08-25 Thread Kevin Wolf
Am 24.08.2011 20:43, schrieb Anthony Liguori:
> A new QMP only command to change the blockdev associated with a block device.
> The semantics of change right now are just plain scary.  This command 
> introduces
> sane semantics.  For more details, see the documentation in the schema file.

Changes to semantics should be mentioned in the commit message, and in
more detail than just that they are sane (the documentation in the
schema file doesn't describe differences to the old command).

Just assuming that you are right about sanity, I wonder how sanity and
compatibility could possibly be achieved at once... I suspect the
semantics is clearer now in that it doesn't overload one command with
block and VNC subcommands, but I doubt that the semantics of the block
version is much better than before.

So please call the command drive_change, it's similar to drive_add and
drive_del, not to the future blockdev_add/remove.

> Signed-off-by: Anthony Liguori 
> ---
>  blockdev.c   |  108 
> +++---
>  qapi-schema.json |   30 +++
>  qmp-commands.hx  |8 
>  3 files changed, 140 insertions(+), 6 deletions(-)
> 
> diff --git a/blockdev.c b/blockdev.c
> index 37b2f29..c00c69d 100644
> --- a/blockdev.c
> +++ b/blockdev.c
> @@ -697,12 +697,101 @@ void qmp_block_passwd(const char *device, const char 
> *password, Error **err)
>  qmp_set_blockdev_password(device, password, err);
>  }
>  
> +static void qmp_bdrv_open_encrypted(BlockDriverState *bs, const char 
> *filename,
> +int bdrv_flags, BlockDriver *drv,
> +const char *password, Error **errp)
> +{
> +if (bdrv_open(bs, filename, bdrv_flags, drv) < 0) {
> +error_set(errp, QERR_OPEN_FILE_FAILED, filename);
> +return;
> +}
> +
> +if (bdrv_key_required(bs)) {
> +if (password) {
> +if (bdrv_set_key(bs, password) < 0) {
> +error_set(errp, QERR_INVALID_PASSWORD);
> +}
> +} else {
> +error_set(errp, QERR_DEVICE_ENCRYPTED, bdrv_get_device_name(bs),
> +  bdrv_get_encrypted_filename(bs));
> +}
> +} else if (password) {
> +error_set(errp, QERR_DEVICE_NOT_ENCRYPTED, bdrv_get_device_name(bs));
> +}
> +}
> +
> +void qmp_change_blockdev(const char *device, const char *filename,
> + bool has_format, const char *format,
> + bool has_password, const char *password,
> + Error **errp)
> +{
> +BlockDriverState *bs, *bs1;
> +BlockDriver *drv = NULL;
> +int bdrv_flags;
> +Error *err = NULL;
> +bool probed_raw = false;
> +
> +bs = bdrv_find(device);
> +if (!bs) {
> +error_set(errp, QERR_DEVICE_NOT_FOUND, device);
> +return;
> +}
> +
> +if (has_format) {
> +drv = bdrv_find_whitelisted_format(format);
> +if (!drv) {
> +error_set(errp, QERR_INVALID_BLOCK_FORMAT, format);
> +return;
> +}
> +}
> +
> +bdrv_flags = bdrv_is_read_only(bs) ? 0 : BDRV_O_RDWR;
> +bdrv_flags |= bdrv_is_snapshot(bs) ? BDRV_O_SNAPSHOT : 0;
> +
> +if (!has_password) {
> +password = NULL;
> +}
> +
> +/* Try to open once with a temporary block device to make sure that
> + * the disk isn't encrypted and we lack a key.  This also helps keep
> + * this operation as a transaction.  That is, if we fail, we try very
> + * hard to make sure that the state is the same as before the operation
> + * was started.
> + */
> +bs1 = bdrv_new("");
> +qmp_bdrv_open_encrypted(bs1, filename, bdrv_flags, drv, password, &err);
> +if (!has_format && bs1->drv->unsafe_probe) {
> +probed_raw = true;
> +}
> +bdrv_delete(bs1);
> +
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
> +
> +if (probed_raw) {
> +/* We will not auto probe raw files. */
> +error_set(errp, QERR_MISSING_PARAMETER, "format");
> +return;
> +}
> +
> +eject_device(bs, 0, &err);
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
> +
> +qmp_bdrv_open_encrypted(bs, filename, bdrv_flags, drv, password, errp);
> +}

Can't this share code with the old command? I don't like this duplication.

Kevin



Re: [Qemu-devel] [PATCH 12/14] qapi: introduce change-blockdev

2011-08-25 Thread Anthony Liguori

On 08/25/2011 07:46 AM, Kevin Wolf wrote:

Am 24.08.2011 20:43, schrieb Anthony Liguori:

A new QMP only command to change the blockdev associated with a block device.
The semantics of change right now are just plain scary.  This command introduces
sane semantics.  For more details, see the documentation in the schema file.


Changes to semantics should be mentioned in the commit message, and in
more detail than just that they are sane (the documentation in the
schema file doesn't describe differences to the old command).


Right, but the schema describes the old command.

There are a couple major differences with the new command vs old:

1) If you had a block device named 'vnc', the old command is broken.

2) For an encrypted device, the old change command returns an error but 
has semantically completed the operation.  The usage is:


(qemu) change ide0 foo.img
Error: device ide0 is encrypted
(qemu) block_passwd ide0 secret

Because even though an error is returned, the change operation has 
actually succeeded.  The new command has transactional semantics.  If an 
error is returned, nothing has happened.  To set passwords, an 
additional option is supported to specify the password.  So you would do:


(qemu) change-blockdev ide0 foo.img
Error: device ide0 is encrypted
(qemu) change-blockdev ide0 foo.img secret
(qemu)

In addition, change-blockdev will not allow you to perform unsafe 
probing.  You can only change to a raw device if you specify a raw format.




Just assuming that you are right about sanity, I wonder how sanity and
compatibility could possibly be achieved at once... I suspect the
semantics is clearer now in that it doesn't overload one command with
block and VNC subcommands, but I doubt that the semantics of the block
version is much better than before.


I don't see how we can change the behavior of the change command.


So please call the command drive_change, it's similar to drive_add and
drive_del, not to the future blockdev_add/remove.


Ack.


Signed-off-by: Anthony Liguori
---
  blockdev.c   |  108 +++---
  qapi-schema.json |   30 +++
  qmp-commands.hx  |8 
  3 files changed, 140 insertions(+), 6 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 37b2f29..c00c69d 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -697,12 +697,101 @@ void qmp_block_passwd(const char *device, const char 
*password, Error **err)
  qmp_set_blockdev_password(device, password, err);
  }

+static void qmp_bdrv_open_encrypted(BlockDriverState *bs, const char *filename,
+int bdrv_flags, BlockDriver *drv,
+const char *password, Error **errp)
+{
+if (bdrv_open(bs, filename, bdrv_flags, drv)<  0) {
+error_set(errp, QERR_OPEN_FILE_FAILED, filename);
+return;
+}
+
+if (bdrv_key_required(bs)) {
+if (password) {
+if (bdrv_set_key(bs, password)<  0) {
+error_set(errp, QERR_INVALID_PASSWORD);
+}
+} else {
+error_set(errp, QERR_DEVICE_ENCRYPTED, bdrv_get_device_name(bs),
+  bdrv_get_encrypted_filename(bs));
+}
+} else if (password) {
+error_set(errp, QERR_DEVICE_NOT_ENCRYPTED, bdrv_get_device_name(bs));
+}
+}
+
+void qmp_change_blockdev(const char *device, const char *filename,
+ bool has_format, const char *format,
+ bool has_password, const char *password,
+ Error **errp)
+{
+BlockDriverState *bs, *bs1;
+BlockDriver *drv = NULL;
+int bdrv_flags;
+Error *err = NULL;
+bool probed_raw = false;
+
+bs = bdrv_find(device);
+if (!bs) {
+error_set(errp, QERR_DEVICE_NOT_FOUND, device);
+return;
+}
+
+if (has_format) {
+drv = bdrv_find_whitelisted_format(format);
+if (!drv) {
+error_set(errp, QERR_INVALID_BLOCK_FORMAT, format);
+return;
+}
+}
+
+bdrv_flags = bdrv_is_read_only(bs) ? 0 : BDRV_O_RDWR;
+bdrv_flags |= bdrv_is_snapshot(bs) ? BDRV_O_SNAPSHOT : 0;
+
+if (!has_password) {
+password = NULL;
+}
+
+/* Try to open once with a temporary block device to make sure that
+ * the disk isn't encrypted and we lack a key.  This also helps keep
+ * this operation as a transaction.  That is, if we fail, we try very
+ * hard to make sure that the state is the same as before the operation
+ * was started.
+ */
+bs1 = bdrv_new("");
+qmp_bdrv_open_encrypted(bs1, filename, bdrv_flags, drv, password,&err);
+if (!has_format&&  bs1->drv->unsafe_probe) {
+probed_raw = true;
+}
+bdrv_delete(bs1);
+
+if (err) {
+error_propagate(errp, err);
+return;
+}
+
+if (probed_raw) {
+/* We will not auto probe raw files. */
+error_set(errp, QERR_MISSING_PARAMETER, "format");
+ 

Re: [Qemu-devel] [PULL] slirp: Fix issues with -mms-bitfields

2011-08-25 Thread Avi Kivity

On 08/25/2011 03:38 PM, Jan Kiszka wrote:

>>
>>  What a mess. Do we really have to go through all 257 packed data structs
>>  in QEMU and add these MS compat bits to all potentially affected ones?
>  I prefer to detect -mms-bitfields and remove it in configure.


Can use -mno-ms-bitfields later to override it.


/me too - if that is possible, ie. if the glib bits we are using doesn't
require us to apply that mode. Can anyone comment on this?



I'd shy away from that.  Even if it works now it may break later.

We should simply avoid bitfields on externally-defined formats; 
meanwhile we can use __attribute__((gcc_struct)) and keep using those we 
have already.


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.




Re: [Qemu-devel] [PULL] VirtFS coroutine changes patchset 2

2011-08-25 Thread Anthony Liguori

On 08/24/2011 10:32 AM, Aneesh Kumar K.V wrote:


The following changes since commit f1a7104a5f435a1bf2a1158e6f737dbd89e8c153:

   Merge remote-tracking branch 'pmaydell/armhw-for-upstream' into staging 
(2011-08-21 18:34:33 -0500)

are available in the git repository at:

   git://repo.or.cz/qemu/v9fs.git for-upstream-2


Pulled.  Thanks.

Regards,

Anthony Liguori



Aneesh Kumar K.V (17):
   hw/9pfs: Add yeild support for fstat coroutine
   hw/9pfs: Update v9fs_lock to use coroutines
   hw/9pfs: Update v9fs_getlock to use coroutines
   hw/9pfs: Add yield support for open and opendir coroutine
   hw/9pfs: Update v9fs_open to use coroutines
   hw/9pfs: Update v9fs_stat to use coroutines
   hw/9pfs: Update v9fs_walk to use coroutines
   hw/9pfs: Add yeild support for clunk related coroutine
   hw/9pfs: Update v9fs_clunk to use coroutines
   hw/9pfs: Add yield support for fsync coroutine
   hw/9pfs: Update v9fs_fsync to use coroutines
   hw/9pfs: Add yield support for pwritev coroutine
   hw/9pfs: Update v9fs_write to use coroutines
   hw/9pfs: Update v9fs_wstat to use coroutines
   hw/9pfs: Update v9fs_attach to use coroutines
   hw/9pfs: Add yield support for preadv coroutine
   hw/9pfs: Update v9fs_read to use coroutines

Harsh Prateek Bora (1):
   use readdir_r instead of readdir for reentrancy

Venkateswararao Jujjuri (6):
   hw/9pfs: Add yield support for open2 coroutine
   hw/9pfs: Update v9fs_lcreate to use coroutines
   hw/9pfs: Update v9fs_create to use coroutines
   hw/9pfs: Add yield support for symlin coroutine
   hw/9pfs: Update v9fs_symlink to use coroutines
   hw/9pfs: Add yield support for link coroutine

Venkateswararao Jujjuri (JV) (1):
   hw/9pfs: Update v9fs_link to use coroutines

  fsdev/file-op-9p.h|2 +-
  hw/9pfs/codir.c   |   40 +-
  hw/9pfs/cofile.c  |  131 
  hw/9pfs/cofs.c|   20 +
  hw/9pfs/coxattr.c |   34 +
  hw/9pfs/virtio-9p-coth.h  |   21 +-
  hw/9pfs/virtio-9p-local.c |7 +-
  hw/9pfs/virtio-9p.c   | 1859 +++--
  hw/9pfs/virtio-9p.h   |   79 --
  9 files changed, 857 insertions(+), 1336 deletions(-)







Re: [Qemu-devel] [PULL] Fix for ppc/escc crash

2011-08-25 Thread Anthony Liguori

On 08/25/2011 02:55 AM, Avi Kivity wrote:

Anthony/Blue, please pull from:

git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/urgent

to receive a fix for a crash caused by the memory API conversion:


Pulled.  Thanks.

Regards,

Anthony Liguori



Avi Kivity (1):
ppc_oldworld, ppc_newworld: fix escc BAR related crash

hw/ppc_newworld.c | 5 -
hw/ppc_oldworld.c | 6 --
2 files changed, 8 insertions(+), 3 deletions(-)






Re: [Qemu-devel] [PULL] Memory API conversions, batch 5

2011-08-25 Thread Anthony Liguori

On 08/25/2011 03:01 AM, Avi Kivity wrote:

Please pull from

git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/batch

to receive the fifth memory API conversions batch. There is really
nothing notable, except perhaps the first use of the transaction API.

While the patches have been on the list for just a short time, they have
received quite extensive review, for which I am thankful.


Pulled.  Thanks.

Regards,

Anthony Liguori



Avi Kivity (22):
stellaris_enet: convert to memory API
sysbus: add helpers to add and delete memory regions to the system bus
pci_host: convert conf index and data ports to memory API
ReadWriteHandler: remove
an5206: convert to memory API
armv7m: convert to memory API
axis_dev88: convert to memory API (RAM only)
sysbus: add sysbus_add_memory_overlap()
integratorcp: convert to memory API (RAM/flash only)
leon3: convert to memory API
cirrus: wrap memory update in a transaction
piix_pci: wrap memory update in a transaction
Makefile.hw: allow hw/ files to include glib headers
pflash_cfi01/pflash_cfi02: convert to memory API
dummy_m68k: convert to memory API
g364fb: convert to memory API
lm32_boards: convert to memory API
mainstone: convert to memory API
mcf5208: convert to memory API
milkymist-minimac2: convert to memory API
milkymist-softusb: convert to memory API
milkymist: convert to memory API

Makefile.hw | 1 +
Makefile.target | 1 -
hw/an5206.c | 12 --
hw/arm-misc.h | 5 ++-
hw/armv7m.c | 22 +
hw/axis_dev88.c | 16 
hw/cirrus_vga.c | 2 +
hw/collie.c | 16 ---
hw/dec_pci.c | 13 +++---
hw/dummy_m68k.c | 7 ++-
hw/flash.h | 16 +--
hw/g364fb.c | 60 ++
hw/grackle_pci.c | 13 +++---
hw/gumstix.c | 28 +++-
hw/integratorcp.c | 28 +
hw/leon3.c | 15 ---
hw/lm32_boards.c | 29 +++-
hw/mainstone.c | 33 --
hw/mcf5208.c | 72 ++-
hw/milkymist-minimac2.c | 43 +--
hw/milkymist-softusb.c | 48 +++---
hw/milkymist.c | 16 ---
hw/mips.h | 4 +-
hw/mips_jazz.c | 3 +-
hw/mips_malta.c | 45 +++-
hw/mips_r4k.c | 20 +
hw/musicpal.c | 15 ---
hw/omap_sx1.c | 21 +
hw/pci_host.c | 86 +-
hw/pci_host.h | 16 +++
hw/petalogix_ml605_mmu.c | 7 ++-
hw/petalogix_s3adsp1800_mmu.c | 8 ++-
hw/pflash_cfi01.c | 67 ++---
hw/pflash_cfi02.c | 93 -
hw/piix_pci.c | 13 +-
hw/ppc405_boards.c | 63 +++
hw/ppc4xx_pci.c | 10 +++--
hw/ppce500_pci.c | 21 -
hw/prep_pci.c | 12 -
hw/r2d.c | 7 ++-
hw/stellaris.c | 5 ++-
hw/stellaris_enet.c | 29 +---
hw/sysbus.c | 29 +
hw/sysbus.h | 8 
hw/unin_pci.c | 82 ++--
hw/virtex_ml507.c | 7 ++-
hw/z2.c | 15 ---
rwhandler.c | 87 --
rwhandler.h | 27 
49 files changed, 638 insertions(+), 658 deletions(-)
delete mode 100644 rwhandler.c
delete mode 100644 rwhandler.h






Re: [Qemu-devel] [PULL] slirp: Fix issues with -mms-bitfields

2011-08-25 Thread Anthony Liguori

On 08/25/2011 07:38 AM, Jan Kiszka wrote:

On 2011-08-25 14:02, TeLeMan wrote:

On Thu, Aug 25, 2011 at 19:04, Jan Kiszka  wrote:

What a mess. Do we really have to go through all 257 packed data structs
in QEMU and add these MS compat bits to all potentially affected ones?

I prefer to detect -mms-bitfields and remove it in configure.


/me too - if that is possible, ie. if the glib bits we are using doesn't
require us to apply that mode. Can anyone comment on this?


So why can't we just #pragma guard all of the slirp bits?  Why are we 
doing it on a per data structure basis?


Regards,

Anthony Liguori



Jan






Re: [Qemu-devel] [PULL 0/2] Trivial patches for August 13 to 25 2011

2011-08-25 Thread Anthony Liguori

On 08/25/2011 03:44 AM, Stefan Hajnoczi wrote:

The following changes since commit 89da90b1b4acf24a9a3f2fd197b1bdf69ab24e72:

   gt64xxx: fix crash in gt64120_pci_mapping() (2011-08-24 21:11:21 +0200)


Pulled.  Thanks.

Regards,

Anthony Liguori



are available in the git repository at:
   ssh://repo.or.cz/srv/git/qemu/stefanha.git trivial-patches

Frediano Ziglio (1):
   disasm: update comment

Jan Kiszka (1):
   Fix up some style nits of last uq/master merge

  cutils.c  |2 +-
  disas.c   |2 +-
  target-i386/kvm.c |5 +++--
  3 files changed, 5 insertions(+), 4 deletions(-)






Re: [Qemu-devel] [PULL] slirp: Fix issues with -mms-bitfields

2011-08-25 Thread Anthony Liguori

On 08/25/2011 08:02 AM, Avi Kivity wrote:

On 08/25/2011 03:38 PM, Jan Kiszka wrote:

>>
>> What a mess. Do we really have to go through all 257 packed data
structs
>> in QEMU and add these MS compat bits to all potentially affected ones?
> I prefer to detect -mms-bitfields and remove it in configure.


Can use -mno-ms-bitfields later to override it.


No, we can't do that.

The reason glib uses -mms-bitfields is that you need to use it in order 
to call Windows APIs which is does.  We will eventually need to do it 
anyway.





/me too - if that is possible, ie. if the glib bits we are using doesn't
require us to apply that mode. Can anyone comment on this?



I'd shy away from that. Even if it works now it may break later.

We should simply avoid bitfields on externally-defined formats;
meanwhile we can use __attribute__((gcc_struct)) and keep using those we
have already.


+1

Regards,

Anthony Liguori









Re: [Qemu-devel] [PULL] slirp: Fix issues with -mms-bitfields

2011-08-25 Thread Jan Kiszka
On 2011-08-25 15:07, Anthony Liguori wrote:
> On 08/25/2011 08:02 AM, Avi Kivity wrote:
>> On 08/25/2011 03:38 PM, Jan Kiszka wrote:
>>> >>
>>> >> What a mess. Do we really have to go through all 257 packed data
>>> structs
>>> >> in QEMU and add these MS compat bits to all potentially affected
>>> ones?
>>> > I prefer to detect -mms-bitfields and remove it in configure.
>>
>> Can use -mno-ms-bitfields later to override it.
> 
> No, we can't do that.
> 
> The reason glib uses -mms-bitfields is that you need to use it in order
> to call Windows APIs which is does.  We will eventually need to do it
> anyway.
> 
>>
>>> /me too - if that is possible, ie. if the glib bits we are using doesn't
>>> require us to apply that mode. Can anyone comment on this?
>>>
>>
>> I'd shy away from that. Even if it works now it may break later.
>>
>> We should simply avoid bitfields on externally-defined formats;
>> meanwhile we can use __attribute__((gcc_struct)) and keep using those we
>> have already.
> 
> +1

We aren't discussing bitfields anymore but essential unaligned (and
therefore packed) protocol structs.

And I'm not that much worried about going through the few slirp structs
but all the other 250 packed ones in entire QEMU.

Jan



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH 10/14] qapi: add change-vnc-password

2011-08-25 Thread Anthony Liguori

On 08/25/2011 04:07 AM, Gerd Hoffmann wrote:

On 08/24/11 20:43, Anthony Liguori wrote:

This is a new QMP only command that only changes the VNC password.


What is wrong with "set_password vnc $secret" ?


Overloading a single function to do multiple things makes the function 
hard to use.   Consider the C interface:


void qmp_set_password(QmpSession *sess, const char *protocol,
  const char *password, bool has_connected,
  const char *connected)

Since both protocol and connected are strings, you can get hard to debug 
errors by using the string "VNC" instead of "vnc" or "Keep" instead of 
"keep".  There's no obvious way to figure out what strings are valid for 
protocol programatically so if we added rdesktop or something like that, 
the interface would become awkward to use.


Likewise, it's non-intuitive that connected only has one valid value for 
VNC which means that for changing the VNC password, it's just extra 
typing.  Compare that to:


void qmp_change_vnc_password(QmpSession *sess, const char *password)

It's impossible to use wrong.  If we add a qmp_change_rdesktop_password, 
it's easily detectable.


Regards,

Anthony Liguori



cheers,
Gerd







Re: [Qemu-devel] [PULL] slirp: Fix issues with -mms-bitfields

2011-08-25 Thread Jan Kiszka
On 2011-08-25 15:06, Anthony Liguori wrote:
> On 08/25/2011 07:38 AM, Jan Kiszka wrote:
>> On 2011-08-25 14:02, TeLeMan wrote:
>>> On Thu, Aug 25, 2011 at 19:04, Jan Kiszka  wrote:
 What a mess. Do we really have to go through all 257 packed data
 structs
 in QEMU and add these MS compat bits to all potentially affected ones?
>>> I prefer to detect -mms-bitfields and remove it in configure.
>>
>> /me too - if that is possible, ie. if the glib bits we are using doesn't
>> require us to apply that mode. Can anyone comment on this?
> 
> So why can't we just #pragma guard all of the slirp bits?  Why are we
> doing it on a per data structure basis?

Packing all structs is not really a good idea, more a last resort.

Jan



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH] ui: avoid use of deprecated gnutls_*_set_priority functions

2011-08-25 Thread Daniel P. Berrange
On Thu, Aug 25, 2011 at 01:27:00PM +0100, Peter Maydell wrote:
> On 25 August 2011 13:11, Stefan Hajnoczi  wrote:
> > From: Raghavendra D Prabhu 
> >
> > The gnutls_*_set_priority family of functions has been marked deprecated
> > in 2.12.x. These functions have been superceded by
> > gnutls_priority_set_direct().
> 
> Does this constitute a change in the required version of gnutls which
> we need to document in the proto-changelog for the next release?
> Is it worth updating the configure tls check to check for this function
> so we fall back to no-tls if the system version is too old?

The  gnutls_priority_set_direct() function has existed since 2.1.7 according
to the GNUTLS NEWS files.

Our configure check merely looks for 'gnutls.h' which will match any
gnutls 1.x or 2.x release, and I can currently build qemu with TLS
support on a RHEL-5 host which has  gnutls 1.4.1

So I believe this change will significantly increase our min required
gnutls version. We could #ifdef the code to deal with this, or perhaps
do a patch based on use of  gnutls_set_default_priority() which I
believe is available in both 1.x and 2.x and is not deprecated

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|



Re: [Qemu-devel] [PULL] slirp: Fix issues with -mms-bitfields

2011-08-25 Thread Avi Kivity

On 08/25/2011 04:07 PM, Anthony Liguori wrote:

On 08/25/2011 08:02 AM, Avi Kivity wrote:

On 08/25/2011 03:38 PM, Jan Kiszka wrote:

>>
>> What a mess. Do we really have to go through all 257 packed data
structs
>> in QEMU and add these MS compat bits to all potentially affected 
ones?

> I prefer to detect -mms-bitfields and remove it in configure.


Can use -mno-ms-bitfields later to override it.


No, we can't do that.

The reason glib uses -mms-bitfields is that you need to use it in 
order to call Windows APIs which is does.  We will eventually need to 
do it anyway.


I meant, just for our own objects.  As long as there are no glib APIs 
which use bitfields, it should work.


However, I don't like it either, and prefer the 
__attribute__(((gcc_fields)) as well.


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.




Re: [Qemu-devel] [PULL] slirp: Fix issues with -mms-bitfields

2011-08-25 Thread Avi Kivity

On 08/25/2011 04:09 PM, Jan Kiszka wrote:

>>
>>  We should simply avoid bitfields on externally-defined formats;
>>  meanwhile we can use __attribute__((gcc_struct)) and keep using those we
>>  have already.
>
>  +1

We aren't discussing bitfields anymore but essential unaligned (and
therefore packed) protocol structs.

And I'm not that much worried about going through the few slirp structs
but all the other 250 packed ones in entire QEMU.



AFICT gcc_struct is also about alignment, so it should just_work.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.




Re: [Qemu-devel] [PULL] slirp: Fix issues with -mms-bitfields

2011-08-25 Thread Jan Kiszka
On 2011-08-25 15:15, Avi Kivity wrote:
> On 08/25/2011 04:07 PM, Anthony Liguori wrote:
>> On 08/25/2011 08:02 AM, Avi Kivity wrote:
>>> On 08/25/2011 03:38 PM, Jan Kiszka wrote:
 >>
 >> What a mess. Do we really have to go through all 257 packed data
 structs
 >> in QEMU and add these MS compat bits to all potentially affected
 ones?
 > I prefer to detect -mms-bitfields and remove it in configure.
>>>
>>> Can use -mno-ms-bitfields later to override it.
>>
>> No, we can't do that.
>>
>> The reason glib uses -mms-bitfields is that you need to use it in
>> order to call Windows APIs which is does.  We will eventually need to
>> do it anyway.
> 
> I meant, just for our own objects.  As long as there are no glib APIs
> which use bitfields, it should work.
> 
> However, I don't like it either, and prefer the
> __attribute__(((gcc_fields)) as well.

Could someone with a Windows environment test if that (or (packed,
gcc_fields)?) makes

struct {
unsigned char a;
unsigned int b;
};

truly packed again?

Jan



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH] qcow2: use always stderr for debugging

2011-08-25 Thread Kevin Wolf
Am 25.08.2011 09:23, schrieb Frediano Ziglio:
> let all DEBUG_ALLOC2 printf goes to stderr
> 
> Signed-off-by: Frediano Ziglio 

Thanks, applied to the block branch.

Kevin



Re: [Qemu-devel] [PULL] slirp: Fix issues with -mms-bitfields

2011-08-25 Thread Avi Kivity

On 08/25/2011 04:19 PM, Jan Kiszka wrote:

>
>  However, I don't like it either, and prefer the
>  __attribute__(((gcc_fields)) as well.

Could someone with a Windows environment test if that (or (packed,
gcc_fields)?) makes

struct {
unsigned char a;
unsigned int b;
};

truly packed again?



You'll need both attributes IIUC.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.




Re: [Qemu-devel] [PULL] slirp: Fix issues with -mms-bitfields

2011-08-25 Thread Avi Kivity

On 08/25/2011 04:13 PM, Jan Kiszka wrote:

>
>  So why can't we just #pragma guard all of the slirp bits?  Why are we
>  doing it on a per data structure basis?

Packing all structs is not really a good idea, more a last resort.



btw, how are the non-x86s handling this? by trapping and fixuping in the 
kernel?


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.




Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings

2011-08-25 Thread Alexander Graf

On 25.08.2011, at 07:31, Roedel, Joerg wrote:

> On Wed, Aug 24, 2011 at 11:07:46AM -0400, Alex Williamson wrote:
>> On Wed, 2011-08-24 at 10:52 +0200, Roedel, Joerg wrote:
> 

[...]

>> We need to try the polite method of attempting to hot unplug the device
>> from qemu first, which the current vfio code already implements.  We can
>> then escalate if it doesn't respond.  The current code calls abort in
>> qemu if the guest doesn't respond, but I agree we should also be
>> enforcing this at the kernel interface.  I think the problem with the
>> hard-unplug is that we don't have a good revoke mechanism for the mmio
>> mmaps.
> 
> For mmio we could stop the guest and replace the mmio region with a
> region that is filled with 0xff, no?

Sure, but that happens in user space. The question is how does kernel space 
enforce an MMIO region to not be mapped after the hotplug event occured? Keep 
in mind that user space is pretty much untrusted here - it doesn't have to be 
QEMU. It could just as well be a generic user space driver. And that can just 
ignore hotplug events.


Alex



Re: [Qemu-devel] [RFC PATCH V1 00/14] Dynamic machine model creation from device trees

2011-08-25 Thread Anthony Liguori

On 08/25/2011 01:41 AM, Peter A. G. Crosthwaite wrote:

Hello

This is a general RFC for a framework developed at Petalogix for creating QEMU models 
based on a passed device tree. Machine models are dynamically constructed from parsing a 
Device Tree Specification (DTS) - no more hard-coded machine models, which is critical 
for the FPGA-based platforms (i.e. target-microblaze) but also will be very useful for 
forthcoming DTS-driven ARM kernels as well. Device models (including QDev models) are 
tagged as being associated with a "compatible" string. If a node with the 
registered compatible string is found when the argument dts is parsed, then the QDev 
model is instantiated.

For example, An ethernet controller might have a device tree node:

 Ethernet_MAC: ethernet@8100 {
compatible = "xlnx,xps-ethernetlite-4.00.a", 
"xlnx,xps-ethernetlite-1.00.a";
device_type = "network";
interrupt-parent =<&xps_intc_0>;
interrupts =<  1 0>;
local-mac-address = [ 00 0a 35 00 22 01 ];
reg =<  0x8100 0x1>;
...
} ;

Our framework registers the compatibility  "xlnx,xps-ethernetlite-1.00.a" as 
being associated with the xilinx.ethlite qdev model (hw/xilinx_ethlite.c), and each time 
this compatiblity is discovered in the device tree, the qdev model is instantiated (see 
path 10/14 for code details on this particular example).The reg property is used to set 
the device base address and the interrupt properties are used to connect interrupts. 
Device tree (more info @ devicetree.org) provides a standarised way of specifiying such 
connecitons, and we use all this to create machine models.

Compatibilities are registered statically from within device models as such:

 fdt_qdev_register_compatibility(&xilinx_ethlite_fdt_qdev_ops,
 "xlnx,xps-ethernetlite-1.00.a");

Where the first argument is a struct containing constant and handlers provided 
by the deivce model to handle device instantiation. Device instantiation is 
performed by the framework (not the Qdev models themselves)

We have also set up a mechanism for machine models to communicate with each 
other by means other than bus transactions. DTS provides a means to specify 
arbitrary interconnections between devices, and we use this to instantiate 
connections such as hierarchical interrupt controllers and point to point DMA 
interconnections. This provides a consistent and clean way of specifying 
inter-device connectivity other than via the system bus.

The platform is tested for Xilinx Microblaze and PPC platforms, and we have 
been using it both interally at PetaLogix and publishing to customers for 
approx. 6 months now. We have setup FDT instantiation code for all of the 
xilinx microbalze/PPC supported periphperals. We are currently developing 
support for an ARM platform. The framework itself is however independent of 
architecture so this could be used for creating machine models for any machine.

This patch series is a minimal patch series containing support for only 
microblaze and a handful of peripherals. Support for a more complete range of 
device models and other cpu architectures will come in future patches.

We would welcome any comments or questions about the approach so that we can 
get it merged upstream.


This is just another form of -readconfig AFAICT.

I don't think the data representation really has anything to do with why 
we have hard coded machines.  The real work needs to happen in the 
device model (see my QEMU Object Model patches).


I'm also not a big fan of the DTS syntax for machine representation 
since it makes it very hard to represent backends.


Regards,

Anthony Liguori



Regards,
Peter

Edgar E. Iglesias (2):
   microblaze: Make the MSR PVR bit non writable
   microblaze: Add an MSR_PVR constant and use it.

Peter A. G. Crosthwaite (12):
   qemu-coroutine: Add simple work queue support
   device_tree: Extended interface for fdt_generic
   fdt_generic: First revision
   xilinx_uartlite: Added fdt gen. platform support
   pflash_cfi01: Added fdt generic platform support
   qdev: Added fn for querying device property types
   fdt_generic_qdev: first revision
   xilinx_timer: Added fdt_generic platform support
   xilinx_intc: Added fdt generic platform support
   xilinx_ethlite: Added fdt generic platform support
   vl.c: Added hw_dtb/kern_dtb command line opts
   microblaze_generic_fdt: first revision

  Makefile.objs |4 +
  Makefile.target   |1 +
  device_tree.c |  202 +++
  device_tree.h |   30 +++
  hw/fdt_generic.c  |  199 +++
  hw/fdt_generic.h  |   92 +
  hw/fdt_generic_devices.h  |8 +
  hw/fdt_generic_qdev.c |   75 +++
  hw/fdt_generic_qdev.h |   46 +

Re: [Qemu-devel] [PULL] slirp: Fix issues with -mms-bitfields

2011-08-25 Thread Anthony Liguori

On 08/25/2011 08:13 AM, Jan Kiszka wrote:

On 2011-08-25 15:06, Anthony Liguori wrote:

On 08/25/2011 07:38 AM, Jan Kiszka wrote:

On 2011-08-25 14:02, TeLeMan wrote:

On Thu, Aug 25, 2011 at 19:04, Jan Kiszka   wrote:

What a mess. Do we really have to go through all 257 packed data
structs
in QEMU and add these MS compat bits to all potentially affected ones?

I prefer to detect -mms-bitfields and remove it in configure.


/me too - if that is possible, ie. if the glib bits we are using doesn't
require us to apply that mode. Can anyone comment on this?


So why can't we just #pragma guard all of the slirp bits?  Why are we
doing it on a per data structure basis?


Packing all structs is not really a good idea, more a last resort.


It doesn't force packing, it forces GCC style structure layout.

Regards,

Anthony Liguori


Jan






[Qemu-devel] Questions regarding ivshmem spec

2011-08-25 Thread Sasha Levin
Hello,

I am looking to implement an ivshmem device for KVM tools, the purpose
is to provide same functionality as QEMU and interoperability with QEMU.

Going through the spec (I found here:
https://gitorious.org/nahanni/guest-code/blobs/master/device_spec.txt )
and the code in QEMU I have gathered several questions, I'll be happy
for some help with it.

1. File handles and guest IDs are passed between the server and the
peers using sockets, is the protocol itself documented anywhere? I would
like to be able to work alongside QEMU servers/peers.

2. The spec describes DOORBELL as an array of DWORDs, when one guest
wants to poke a different guest it would write something into the offset
of the other guest in the DOORBELL array.
Looking at the implementation in QEMU, DOORBELL is one DWORD, when
writing to it the upper WORD is the guest id and the lower WORD is the
value.
What am I missing here?

3. There are 3 ways for guests to communicate between each other, and
I'm assuming all guests using the same SHM block must use the same
method. Is it safe to assume we'll always use ioeventfds as in the
implementation now?

Thanks!

-- 

Sasha.




Re: [Qemu-devel] [PATCH 11/14] qapi: add change-vnc-listen

2011-08-25 Thread Luiz Capitulino
On Wed, 24 Aug 2011 13:43:06 -0500
Anthony Liguori  wrote:

> New QMP only command to change the VNC server's listening address.
> 
> Signed-off-by: Anthony Liguori 
> ---
>  qapi-schema.json |   14 ++
>  qmp-commands.hx  |8 
>  qmp.c|7 +++
>  3 files changed, 29 insertions(+), 0 deletions(-)
> 
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 3b2229f..211200a 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -109,3 +109,17 @@
>  # string.  Existing clients are unaffected by executing this command.
>  ##
>  { 'command': 'change-vnc-password', 'data': {'password': 'str'} }
> +
> +##
> +# @change-vnc-listen:
> +#
> +# Change the host that the VNC server listens on.
> +#
> +# @target:  the new server specification to listen on
> +#
> +# Since: 1.0
> +#
> +# Notes:  At this moment in time, the behavior of existing client connections
> +# when this command is executed is undefined.
> +##

What's the expected behaviour wrt authentication? Right now it will disable
any authentication set for the previous address. It should at least be noted
in the documentation if that's expected.

> +{ 'command': 'change-vnc-listen', 'data': {'target': 'str'} }
> diff --git a/qmp-commands.hx b/qmp-commands.hx
> index d60f72f..c0d0ca3 100644
> --- a/qmp-commands.hx
> +++ b/qmp-commands.hx
> @@ -876,6 +876,14 @@ EQMP
>  },
>  
>  {
> +.name   = "change-vnc-listen",
> +.args_type  = "target:s",
> +.params = "target",
> +.help   = "set vnc listening address",
> +.mhandler.cmd_new = qmp_marshal_input_change_vnc_listen,
> +},
> +
> +{
>  .name   = "set_password",
>  .args_type  = "protocol:s,password:s,connected:s?",
>  .params = "protocol password action-if-connected",
> diff --git a/qmp.c b/qmp.c
> index f817a88..73d6172 100644
> --- a/qmp.c
> +++ b/qmp.c
> @@ -35,3 +35,10 @@ void qmp_change_vnc_password(const char *password, Error 
> **err)
>  error_set(err, QERR_SET_PASSWD_FAILED);
>  }
>  }
> +
> +void qmp_change_vnc_listen(const char *target, Error **err)
> +{
> +if (vnc_display_open(NULL, target) < 0) {
> +error_set(err, QERR_VNC_SERVER_FAILED, target);
> +}
> +}




Re: [Qemu-devel] [PULL] slirp: Fix issues with -mms-bitfields

2011-08-25 Thread Jan Kiszka
On 2011-08-25 15:28, Anthony Liguori wrote:
> On 08/25/2011 08:13 AM, Jan Kiszka wrote:
>> On 2011-08-25 15:06, Anthony Liguori wrote:
>>> On 08/25/2011 07:38 AM, Jan Kiszka wrote:
 On 2011-08-25 14:02, TeLeMan wrote:
> On Thu, Aug 25, 2011 at 19:04, Jan Kiszka   wrote:
>> What a mess. Do we really have to go through all 257 packed data
>> structs
>> in QEMU and add these MS compat bits to all potentially affected
>> ones?
> I prefer to detect -mms-bitfields and remove it in configure.

 /me too - if that is possible, ie. if the glib bits we are using
 doesn't
 require us to apply that mode. Can anyone comment on this?
>>>
>>> So why can't we just #pragma guard all of the slirp bits?  Why are we
>>> doing it on a per data structure basis?
>>
>> Packing all structs is not really a good idea, more a last resort.
> 
> It doesn't force packing, it forces GCC style structure layout.

If we are talking about #pragma pack(...), then that's not what I read
in the docs.

Jan



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH 10/14] qapi: add change-vnc-password

2011-08-25 Thread Luiz Capitulino
On Wed, 24 Aug 2011 13:43:05 -0500
Anthony Liguori  wrote:

> This is a new QMP only command that only changes the VNC password.

Isn't this useful in HMP too?

> 
> Signed-off-by: Anthony Liguori 
> ---
>  qapi-schema.json |   13 +
>  qmp-commands.hx  |8 
>  qmp.c|   11 ++-
>  3 files changed, 31 insertions(+), 1 deletions(-)
> 
> diff --git a/qapi-schema.json b/qapi-schema.json
> index f159d81..3b2229f 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -96,3 +96,16 @@
>  { 'command': 'set-blockdev-password',
>'data': {'device': 'str', 'password': 'str'} }
>  
> +##
> +# @change-vnc-password:
> +#
> +# Change the VNC server password.
> +#
> +# @target:  the new password to use with VNC authentication

The argument name is "password".

> +#
> +# Since: 1.0
> +#
> +# Notes:  An empty password in this command will set the password to the 
> empty
> +# string.  Existing clients are unaffected by executing this command.
> +##
> +{ 'command': 'change-vnc-password', 'data': {'password': 'str'} }
> diff --git a/qmp-commands.hx b/qmp-commands.hx
> index 909c778..d60f72f 100644
> --- a/qmp-commands.hx
> +++ b/qmp-commands.hx
> @@ -868,6 +868,14 @@ Example:
>  EQMP
>  
>  {
> +.name   = "change-vnc-password",
> +.args_type  = "password:s",
> +.params = "password",
> +.help   = "set vnc password",
> +.mhandler.cmd_new = qmp_marshal_input_change_vnc_password,
> +},
> +
> +{
>  .name   = "set_password",
>  .args_type  = "protocol:s,password:s,connected:s?",
>  .params = "protocol password action-if-connected",
> diff --git a/qmp.c b/qmp.c
> index 8aa9c66..f817a88 100644
> --- a/qmp.c
> +++ b/qmp.c
> @@ -12,9 +12,11 @@
>   */
>  
>  #include "qemu-common.h"
> -#include "sysemu.h"
>  #include "qmp-commands.h"
>  
> +#include "sysemu.h"
> +#include "console.h"
> +
>  NameInfo *qmp_query_name(Error **errp)
>  {
>  NameInfo *info = g_malloc0(sizeof(*info));
> @@ -26,3 +28,10 @@ NameInfo *qmp_query_name(Error **errp)
>  
>  return info;
>  }
> +
> +void qmp_change_vnc_password(const char *password, Error **err)
> +{
> +if (vnc_display_password(NULL, password) < 0) {
> +error_set(err, QERR_SET_PASSWD_FAILED);
> +}
> +}




  1   2   3   >