Re: [Qemu-devel] [PATCH V5 0/5] tests: Add the image fuzzer with qcow2 support

2014-08-07 Thread Stefan Hajnoczi
On Wed, Aug 06, 2014 at 05:12:45PM +0400, Maria Kustova wrote:
> 
> This patch series introduces the image fuzzer, a tool for stability and
> reliability testing.
> Its approach is to run large amount of tests in background. During every test 
> a
> program (e.g. qemu-img) is called to read or modify an invalid test image.
> A test image has valid inner structure defined by its format specification 
> with
> some fields having random invalid values.
> 
> Patch 1 contains documentation for the image fuzzer, patch 2 is the test 
> runner
> and remaining ones relate to the image generator for qcow2 format.
> 
> This patch series was created for the 'block-next' branch.
> 
> v4 -> v5:
> Runner:
>  * Added a warning message if a backing file failed to be created (based on
>the review of Fam Zheng)
>  * Back up a test image before every test command
>  * Fixed always logged messages of a program under test
>  * Added a warning message if a wrong name of a program under test is 
> specified
>  * Made offset and length qemu-io arguments multiple of a sector size
>  * Print all errors to stderr

Can runner.py be moved to tests/image-fuzzer/runner.py?

That way it's immediately clear how to launch the fuzzer when looking at
the image-fuzzer/ directory.

Stefan


pgpH0nbwn6fMU.pgp
Description: PGP signature


Re: [Qemu-devel] [PATCH V5 2/5] runner: Tool for fuzz tests execution

2014-08-07 Thread Stefan Hajnoczi
On Wed, Aug 06, 2014 at 05:12:47PM +0400, Maria Kustova wrote:
> The purpose of the test runner is to prepare the test environment (e.g. create
> a work directory, a test image, etc), execute a program under test with
> parameters, indicate a test failure if the program was killed during the test
> execution and collect core dumps, logs and other test artifacts.
> 
> The test runner doesn't depend on an image format or a program will be tested,
> so it can be used with any external image generator and program under test.
> 
> Signed-off-by: Maria Kustova 
> ---
>  tests/image-fuzzer/runner/runner.py | 405 
> 
>  1 file changed, 405 insertions(+)
>  create mode 100755 tests/image-fuzzer/runner/runner.py

Reviewed-by: Stefan Hajnoczi 


pgpbmejfZDgSn.pgp
Description: PGP signature


Re: [Qemu-devel] [PATCH V5 1/6] icount: Add QemuOpts for icount

2014-08-07 Thread Markus Armbruster
Sebastian Tanase  writes:

> Make icount parameter use QemuOpts style options in order
> to easily add other suboptions.
>
> Signed-off-by: Sebastian Tanase 
> Tested-by: Camille Bégué 
> Signed-off-by: Paolo Bonzini 
[...]
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 9e54686..143def4 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -3011,11 +3011,11 @@ re-inject them.
>  ETEXI
>  
>  DEF("icount", HAS_ARG, QEMU_OPTION_icount, \
> -"-icount [N|auto]\n" \
> +"-icount [shift=N|auto]\n" \
>  "enable virtual instruction counter with 2^N clock ticks 
> per\n" \
>  "instruction\n", QEMU_ARCH_ALL)
>  STEXI
> -@item -icount [@var{N}|auto]
> +@item -icount [shift=@var{N}|auto]
>  @findex -icount
>  Enable virtual instruction counter.  The virtual cpu will execute one
>  instruction every 2^@var{N} ns of virtual time.  If @code{auto} is specified


"shift=" is documented to be required, but...

[...]
> diff --git a/vl.c b/vl.c
> index 41ddcd2..103027f 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -537,6 +537,20 @@ static QemuOptsList qemu_mem_opts = {
>  },
>  };
>  
> +static QemuOptsList qemu_icount_opts = {
> +.name = "icount",
> +.implied_opt_name = "shift",

... it's actually optional.  Please fix the documentation.
I guess [[shift=][N|auto] would be correct.

> +.merge_lists = true,
> +.head = QTAILQ_HEAD_INITIALIZER(qemu_icount_opts.head),
> +.desc = {
> +{
> +.name = "shift",
> +.type = QEMU_OPT_STRING,
> +},
> +{ /* end of list */ }
> +},
> +};
> +
>  /**
>   * Get machine options
>   *
[...]



Re: [Qemu-devel] [PATCH 2/2] sheepdog: improve error handling for a case of failed lock

2014-08-07 Thread Liu Yuan
On Fri, Aug 08, 2014 at 03:17:59PM +0900, Hitoshi Mitake wrote:
> At Fri, 8 Aug 2014 13:31:39 +0800,
> Liu Yuan wrote:
> > 
> > On Thu, Aug 07, 2014 at 04:28:40PM +0900, Hitoshi Mitake wrote:
> > > Recently, sheepdog revived its VDI locking functionality. This patch
> > > updates sheepdog driver of QEMU for this feature:
> > > 
> > > 1. Improve error message when QEMU fails to acquire lock of
> > > VDI. Current sheepdog driver prints an error message "VDI isn't
> > > locked" when it fails to acquire lock. It is a little bit confusing
> > > because the mesage says VDI isn't locked but it is actually locked by
> > > other VM. This patch modifies this confusing message.
> > > 
> > > 2. Change error code for a case of failed locking. -EBUSY is a
> > > suitable one.
> > > 
> > > Reported-by: Valerio Pachera 
> > > Cc: Kevin Wolf 
> > > Cc: Stefan Hajnoczi 
> > > Cc: Liu Yuan 
> > > Cc: MORITA Kazutaka 
> > > Signed-off-by: Hitoshi Mitake 
> > > ---
> > >  block/sheepdog.c | 4 
> > >  1 file changed, 4 insertions(+)
> > > 
> > > diff --git a/block/sheepdog.c b/block/sheepdog.c
> > > index 36f76f0..0b3f86d 100644
> > > --- a/block/sheepdog.c
> > > +++ b/block/sheepdog.c
> > > @@ -1112,9 +1112,13 @@ static int find_vdi_name(BDRVSheepdogState *s, 
> > > const char *filename,
> > >  
> > >  if (rsp->result != SD_RES_SUCCESS) {
> > >  error_setg(errp, "cannot get vdi info, %s, %s %" PRIu32 " %s",
> > > +   rsp->result == SD_RES_VDI_NOT_LOCKED ?
> > 
> > I'm puzzled by this check.
> > 
> > we use SD_RES_VDI_LOCKED to indicate vid is already locked, no?
> 
> We use SD_RES_VDI_NOT_LOCKED for indicating locking by this VM fails.
> 
> > 
> > > +   "VDI is already locked by other VM" :

But this message said it was locked by others, and we have SD_RES_VDI_LOCKED for
this case.

We need fix sheep daemon for this case to return SD_RES_VDI_LOCKED for already
locked case and NOT_LOCKED for other sheep internal errors.

> > > sd_strerror(rsp->result), filename, snapid, tag);
> > >  if (rsp->result == SD_RES_NO_VDI) {
> > >  ret = -ENOENT;
> > > +} else if (rsp->result == SD_RES_VDI_NOT_LOCKED) {
> > > +ret = -EBUSY;
> > >  } else {
> > >  ret = -EIO;
> > >  }
> > 
> > It is better to use switch case to handle the result.
> 
> using switch statement in this case only increases a number of lines
> of code:
> 
> Current change:
> if (rsp->result == SD_RES_NO_VDI) {
> ret = -ENOENT;
> } else if (rsp->result == SD_RES_VDI_NOT_LOCKED) {
> ...
> 
> Change with switch:
> switch (rsp->result) {
>   case SD_RES_NO_VDI:
> ret = -ENOENT;
>   break;
>   case SD_RES_VDI_NOT_LOCKED:
> ...
> 
> The change with switch statement requires one more line for break;. I
> think if statement is suitable for this case.

If you insist on 'if-else' over swtich case, it is fine with me. But I'd suggest
switch-case because it looks cleaner and easier to understand if we have more
than 2 branches.

Thanks
Yuan



Re: [Qemu-devel] [Bug 1352555] Re: iproute2 incompatibility

2014-08-07 Thread swestlake
i discovered with iproute2 i have to manually bring the "lo" interface 
link up which to me is pretty new.. after which the spice port can 
immediately work with 127.0.0.1:.

what I originally meant when installing iproute2 on debian was that it 
uninstalls ifupdown as well as iproute.

I don't know the full plans of the debian team if they will ever release 
a startup script for iproute2 or if its meant to be the "default" 
package that will be replacing iproute&ifupdown.. but the ifconfig 
command is still left intact, ifup & ifdown are taken out.

also if you don't mind to tell me whether if I can address something 
which I'm really after which lead me to trying iproute2 since I'm having 
a real problem with kvm

  --> I'm having issues with "two" model=virtio defined nics that are 
bridged to two hypervisor tap interfaces.  Having two virtio network 
adapters is unstable with the current kvm build I'm using.i suppose I 
can provide details on this but I'm trying to demonstrate to you guys 
I'm not trolling in anyways and sorry I started out lacking a lot of 
details on my first bug report which should of come off much better than 
this..

Anyways I've been able to resolve the 'ip link set lo up' and the 
solution seemed stupid but I don't suppose many people are even using 
iproute2.

there's also an additional advantage with iproute2 which is why I'm 
trying it because the "bridge" command utility that comes with it offers 
more options per "bridge port" ...and this "bridge" command works with 
currently created devices with brctl and complements it(brctl is still 
available after iproute2 is installed).  With iproute&ifupdown I don't 
have access to this new 'bridge' command feature

So far my kvm machine works perfectly well with just 1 bridged tap 
device but can't work with "two".  I'm using virtio acceleration with a 
virtio-capable kernel, by which the kernel image is passed to the 
-kernel parameter option to the kvm command. (All tap devices are 
pre-created with the root account)

The reason why and what I'm really after is if somebody knows if the 
latest kvm build can handle two "virtio" nics that is stable(not using 
"passthrough", .. just two virtio-accelerated nic devices that are 
associated each separately on the hypervisor). I can't seem to find this 
information anywhere. (dmesg indicates to me everything is virtio.. My 
VM os is on /dev/vda1...  I'm able to use two virtio raw image drives 
without issue. ) I've been upgrading the VM's kernel from 3.2 to 3.14 
i386 and have it to the kvm command line.

fwiw,
nic 1-> public IP address in the VM, works perfect well through the 
hypervisor's bridged tap device.

nic 2-> another model=virtio device.  When this second nic device is 
added it doesn't matter whether or not this interface in the VM (eth1) 
is "up" or "down", as long as a "second" nic interface is passed to the 
kvm instance, nic 1 miserably stalls.. though it is capable of very 
small network traffic and chokes miserably on the data-link layer (nic 1 
exponentially increases in ARP requesting it's gateway mac-address and 
barely passes a simple nslookup. I get to scrutinize traffic with 
tcpdump against the bridge interface)

where can i ask this for more current-build information about the 
stability of multiple virtio nic interfaces? (I'm not using passthrough 
at all which is something much more advanced)

thanks, sorry for the lack of details..

-Scott

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

Title:
  iproute2 incompatibility

Status in QEMU:
  Invalid

Bug description:
  installed iproute2 which replaced ifupdown, kvm no longer connects to
  tap devices and is unable to create spice sockets

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



[Qemu-devel] [PATCH] cluster/zookeeper: add log information for zk auto-recoonect

2014-08-07 Thread Liu Yuan
Reported-by: Valerio Pachera 
Signed-off-by: Liu Yuan 
---
 sheep/group.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sheep/group.c b/sheep/group.c
index 06a80bd..08e3884 100644
--- a/sheep/group.c
+++ b/sheep/group.c
@@ -979,7 +979,7 @@ static int send_join_request(void)
 {
struct sd_node *n = &sys->this_node;
 
-   sd_info("%s", node_to_str(n));
+   sd_info("%s going to rejoin the cluster", node_to_str(n));
return sys->cdrv->join(n, &sys->cinfo, sizeof(sys->cinfo));
 }
 
-- 
1.9.1




Re: [Qemu-devel] [PATCH V5 1/5] docs: Specification for the image fuzzer

2014-08-07 Thread Stefan Hajnoczi
On Wed, Aug 06, 2014 at 05:12:46PM +0400, Maria Kustova wrote:
> 'Overall fuzzer requirements' chapter contains the current product vision and
> features done and to be done. This chapter is still in progress.
> 
> Signed-off-by: Maria Kustova 
> ---
>  tests/image-fuzzer/docs/image-fuzzer.txt | 239 
> +++
>  1 file changed, 239 insertions(+)
>  create mode 100644 tests/image-fuzzer/docs/image-fuzzer.txt
> 
> diff --git a/tests/image-fuzzer/docs/image-fuzzer.txt 
> b/tests/image-fuzzer/docs/image-fuzzer.txt
> new file mode 100644
> index 000..efe0ed4
> --- /dev/null
> +++ b/tests/image-fuzzer/docs/image-fuzzer.txt

Please put documentation into QEMU's top-level docs/ directory.


pgpVRCDyXZIzV.pgp
Description: PGP signature


Re: [Qemu-devel] [PATCH 2/2] sheepdog: improve error handling for a case of failed lock

2014-08-07 Thread Hitoshi Mitake
At Fri, 8 Aug 2014 13:31:39 +0800,
Liu Yuan wrote:
> 
> On Thu, Aug 07, 2014 at 04:28:40PM +0900, Hitoshi Mitake wrote:
> > Recently, sheepdog revived its VDI locking functionality. This patch
> > updates sheepdog driver of QEMU for this feature:
> > 
> > 1. Improve error message when QEMU fails to acquire lock of
> > VDI. Current sheepdog driver prints an error message "VDI isn't
> > locked" when it fails to acquire lock. It is a little bit confusing
> > because the mesage says VDI isn't locked but it is actually locked by
> > other VM. This patch modifies this confusing message.
> > 
> > 2. Change error code for a case of failed locking. -EBUSY is a
> > suitable one.
> > 
> > Reported-by: Valerio Pachera 
> > Cc: Kevin Wolf 
> > Cc: Stefan Hajnoczi 
> > Cc: Liu Yuan 
> > Cc: MORITA Kazutaka 
> > Signed-off-by: Hitoshi Mitake 
> > ---
> >  block/sheepdog.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/block/sheepdog.c b/block/sheepdog.c
> > index 36f76f0..0b3f86d 100644
> > --- a/block/sheepdog.c
> > +++ b/block/sheepdog.c
> > @@ -1112,9 +1112,13 @@ static int find_vdi_name(BDRVSheepdogState *s, const 
> > char *filename,
> >  
> >  if (rsp->result != SD_RES_SUCCESS) {
> >  error_setg(errp, "cannot get vdi info, %s, %s %" PRIu32 " %s",
> > +   rsp->result == SD_RES_VDI_NOT_LOCKED ?
> 
> I'm puzzled by this check.
> 
> we use SD_RES_VDI_LOCKED to indicate vid is already locked, no?

We use SD_RES_VDI_NOT_LOCKED for indicating locking by this VM fails.

> 
> > +   "VDI is already locked by other VM" :
> > sd_strerror(rsp->result), filename, snapid, tag);
> >  if (rsp->result == SD_RES_NO_VDI) {
> >  ret = -ENOENT;
> > +} else if (rsp->result == SD_RES_VDI_NOT_LOCKED) {
> > +ret = -EBUSY;
> >  } else {
> >  ret = -EIO;
> >  }
> 
> It is better to use switch case to handle the result.

using switch statement in this case only increases a number of lines
of code:

Current change:
if (rsp->result == SD_RES_NO_VDI) {
ret = -ENOENT;
} else if (rsp->result == SD_RES_VDI_NOT_LOCKED) {
...

Change with switch:
switch (rsp->result) {
case SD_RES_NO_VDI:
ret = -ENOENT;
break;
case SD_RES_VDI_NOT_LOCKED:
...

The change with switch statement requires one more line for break;. I
think if statement is suitable for this case.

Thanks,
Hitoshi



Re: [Qemu-devel] [PATCH 1/2] sheepdog: adopting protocol update for VDI locking

2014-08-07 Thread Hitoshi Mitake
At Fri, 8 Aug 2014 13:20:39 +0800,
Liu Yuan wrote:
> 
> On Thu, Aug 07, 2014 at 04:28:39PM +0900, Hitoshi Mitake wrote:
> > The update is required for supporting iSCSI multipath. It doesn't
> > affect behavior of QEMU driver but adding a new field to vdi request
> > struct is required.
> > 
> > Cc: Kevin Wolf 
> > Cc: Stefan Hajnoczi 
> > Cc: Liu Yuan 
> > Cc: MORITA Kazutaka 
> > Signed-off-by: Hitoshi Mitake 
> > ---
> >  block/sheepdog.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/block/sheepdog.c b/block/sheepdog.c
> > index 8d9350c..36f76f0 100644
> > --- a/block/sheepdog.c
> > +++ b/block/sheepdog.c
> > @@ -103,6 +103,9 @@
> >  #define SD_INODE_SIZE (sizeof(SheepdogInode))
> >  #define CURRENT_VDI_ID 0
> >  
> > +#define LOCK_TYPE_NORMAL 1
> > +#define LOCK_TYPE_SHARED 2  /* for iSCSI multipath */
> 
> How about
> 
> #define LOCK_TYPE_NORMAL 0
> #define LOCK_TYPE_SHARED 1
> 
> Then we don't need this patch. Since qemu won't make use of multipath for the
> near future, we should avoid adding stuff related to multipath to qemu driver.

(Cc-ing current Kazutaka-san's address)

I think this isn't a good idea. Because it means that sheep has an
assumption about padding field of the request data struct. This sort
of workaround can cause hard to find problems in the future.

Thanks,
Hitoshi

> 
> Thanks
> Yuan
> 
> > +
> >  typedef struct SheepdogReq {
> >  uint8_t proto_ver;
> >  uint8_t opcode;
> > @@ -166,7 +169,8 @@ typedef struct SheepdogVdiReq {
> >  uint8_t copy_policy;
> >  uint8_t reserved[2];
> >  uint32_t snapid;
> > -uint32_t pad[3];
> > +uint32_t type;
> > +uint32_t pad[2];
> >  } SheepdogVdiReq;
> >  
> >  typedef struct SheepdogVdiRsp {
> > @@ -1090,6 +1094,7 @@ static int find_vdi_name(BDRVSheepdogState *s, const 
> > char *filename,
> >  memset(&hdr, 0, sizeof(hdr));
> >  if (lock) {
> >  hdr.opcode = SD_OP_LOCK_VDI;
> > +hdr.type = LOCK_TYPE_NORMAL;
> >  } else {
> >  hdr.opcode = SD_OP_GET_VDI_INFO;
> >  }
> > @@ -1793,6 +1798,7 @@ static void sd_close(BlockDriverState *bs)
> >  memset(&hdr, 0, sizeof(hdr));
> >  
> >  hdr.opcode = SD_OP_RELEASE_VDI;
> > +hdr.type = LOCK_TYPE_NORMAL;
> >  hdr.base_vdi_id = s->inode.vdi_id;
> >  wlen = strlen(s->name) + 1;
> >  hdr.data_length = wlen;
> > -- 
> > 1.8.3.2
> > 



Re: [Qemu-devel] [PATCH v6 1/7] exec: add parameter errp to qemu_ram_alloc and qemu_ram_alloc_from_ptr

2014-08-07 Thread Hu Tao
On Thu, Aug 07, 2014 at 09:24:35PM +1000, Peter Crosthwaite wrote:
> On Thu, Aug 7, 2014 at 7:10 PM, Hu Tao  wrote:
> > Add parameter errp to qemu_ram_alloc and qemu_ram_alloc_from_ptr so that
> > we can handle errors.
> >
> > Signed-off-by: Hu Tao 
> 
> Reviewed-by: Peter Crosthwaite 
> 
> Optional nit-picky suggestions below.
> 
> > ---
> >  exec.c  | 36 +++-
> >  include/exec/ram_addr.h |  4 ++--
> >  memory.c|  6 +++---
> >  3 files changed, 32 insertions(+), 14 deletions(-)
> >
> > diff --git a/exec.c b/exec.c
> > index 765bd94..accba00 100644
> > --- a/exec.c
> > +++ b/exec.c
> > @@ -1224,7 +1224,7 @@ static int memory_try_enable_merging(void *addr, 
> > size_t len)
> >  return qemu_madvise(addr, len, QEMU_MADV_MERGEABLE);
> >  }
> >
> > -static ram_addr_t ram_block_add(RAMBlock *new_block)
> > +static ram_addr_t ram_block_add(RAMBlock *new_block, Error **errp)
> >  {
> >  RAMBlock *block;
> >  ram_addr_t old_ram_size, new_ram_size;
> > @@ -1241,9 +1241,11 @@ static ram_addr_t ram_block_add(RAMBlock *new_block)
> >  } else {
> >  new_block->host = phys_mem_alloc(new_block->length);
> >  if (!new_block->host) {
> > -fprintf(stderr, "Cannot set up guest memory '%s': %s\n",
> > -new_block->mr->name, strerror(errno));
> > -exit(1);
> > +error_setg_errno(errp, errno,
> > + "cannot set up guest memory '%s'",
> > + new_block->mr->name);
> 
> Out of scope, but if you do need to respin you could change to
> memory_region_name to avoid the direct struct access of private mr
> fields.

Okay.

> 
> > +qemu_mutex_unlock_ramlist();
> > +return -1;
> >  }
> >  memory_try_enable_merging(new_block->host, new_block->length);
> >  }
> > @@ -1294,6 +1296,8 @@ ram_addr_t qemu_ram_alloc_from_file(ram_addr_t size, 
> > MemoryRegion *mr,
> >  Error **errp)
> >  {
> >  RAMBlock *new_block;
> > +ram_addr_t addr;
> > +Error *local_err = NULL;
> >
> >  if (xen_enabled()) {
> >  error_setg(errp, "-mem-path not supported with Xen");
> > @@ -1323,14 +1327,22 @@ ram_addr_t qemu_ram_alloc_from_file(ram_addr_t 
> > size, MemoryRegion *mr,
> >  return -1;
> >  }
> >
> > -return ram_block_add(new_block);
> > +addr = ram_block_add(new_block, &local_err);
> > +if (local_err) {
> > +g_free(new_block);
> > +error_propagate(errp, local_err);
> 
> > +return -1;
> 
> This should be redundant I think. You are unnecessarily defining the
> error return code in two places when you can just propagate the return
> code from the botched ram_block_add().

It did but mst suggested return -1 instead.

Regards,
Hu

> 
> > +}
> > +return addr;
> >  }
> >  #endif
> >
> >  ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
> > -   MemoryRegion *mr)
> > +   MemoryRegion *mr, Error **errp)
> >  {
> >  RAMBlock *new_block;
> > +ram_addr_t addr;
> > +Error *local_err = NULL;
> >
> >  size = TARGET_PAGE_ALIGN(size);
> >  new_block = g_malloc0(sizeof(*new_block));
> > @@ -1341,12 +1353,18 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, 
> > void *host,
> >  if (host) {
> >  new_block->flags |= RAM_PREALLOC;
> >  }
> > -return ram_block_add(new_block);
> > +addr = ram_block_add(new_block, &local_err);
> > +if (local_err) {
> > +g_free(new_block);
> > +error_propagate(errp, local_err);
> > +return -1;
> 
> Ditto.
> 
> Regards,
> Peter
> 
> > +}
> > +return addr;
> >  }
> >
> > -ram_addr_t qemu_ram_alloc(ram_addr_t size, MemoryRegion *mr)
> > +ram_addr_t qemu_ram_alloc(ram_addr_t size, MemoryRegion *mr, Error **errp)
> >  {
> > -return qemu_ram_alloc_from_ptr(size, NULL, mr);
> > +return qemu_ram_alloc_from_ptr(size, NULL, mr, errp);
> >  }
> >
> >  void qemu_ram_free_from_ptr(ram_addr_t addr)
> > diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
> > index 6593be1..cf1d4c7 100644
> > --- a/include/exec/ram_addr.h
> > +++ b/include/exec/ram_addr.h
> > @@ -26,8 +26,8 @@ ram_addr_t qemu_ram_alloc_from_file(ram_addr_t size, 
> > MemoryRegion *mr,
> >  bool share, const char *mem_path,
> >  Error **errp);
> >  ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
> > -   MemoryRegion *mr);
> > -ram_addr_t qemu_ram_alloc(ram_addr_t size, MemoryRegion *mr);
> > +   MemoryRegion *mr, Error **errp);
> > +ram_addr_t qemu_ram_alloc(ram_addr_t size, MemoryRegion *mr, Error **errp);
> >  int qemu_get_ram_fd(ram_addr_t addr);
> >  void *q

Re: [Qemu-devel] [RFC PATCH 10/10] cpus: reclaim allocated vCPU objects

2014-08-07 Thread Gu Zheng
Hi Anshul,
On 08/07/2014 09:31 PM, Anshul Makkar wrote:

> Thanks Gu.. cpu-hotunplug is working fine in my  tests.

Thanks for your quick test.

> 
> For cpu-hotplug, I get inconsistent result if I delete arbitrary cpu
> and not just the last one.
> 
> for eg
> list of cpus: 1, 2 ,3
> device_add cpu 4
> device_add cpu 5
> device_add cpu 6

What type id do you use here? apic-id or device id?

> 
> device_del cpu 4
> device_del cpu 6

Could you please offer the detail reproduce info? the more the better.

> 
> now if I do device_add cpu6, then cpu 4 gets added and now if I try to
> do add cpu 4 or 6, it says cpu already exist.. Its a kind of vague
> behaviour.. Do, we follow any protocol here while adding and deleting
> cpus.

There is not strict restriction here. Does the following routine match
the condition you mentioned? It works fine in my box.

Original cpus:0,1 maxcpus:6
(qemu) device_add qemu64-x86_64-cpu,apic-id=2,id=cpu2
(qemu) device_add qemu64-x86_64-cpu,apic-id=3,id=cpu3
(qemu) device_add qemu64-x86_64-cpu,apic-id=4,id=cpu4

(qemu) device_del cpu2
(qemu) device_del cpu4

(qemu) device_add qemu64-x86_64-cpu,apic-id=4,id=cpu4
(qemu) device_add qemu64-x86_64-cpu,apic-id=2,id=cpu2

Thanks,
Gu

> 
> Thanks
> Anshul Makkar
> www.justkernel.com
> 
> On Thu, Aug 7, 2014 at 6:54 AM, Gu Zheng  wrote:
>> After ACPI get a signal to eject a vCPU, the vCPU must be
>> removed from CPU list,before the vCPU really removed,  then
>> release the all related vCPU objects.
>> But we do not close KVM vcpu fd, just record it into a list, in
>> order to reuse it.
>>
>> Signed-off-by: Chen Fan 
>> Signed-off-by: Gu Zheng 
>> ---
>>  cpus.c   |   37 
>>  include/sysemu/kvm.h |1 +
>>  kvm-all.c|   57 
>> +-
>>  3 files changed, 94 insertions(+), 1 deletions(-)
>>
>> diff --git a/cpus.c b/cpus.c
>> index 4dfb889..9a73407 100644
>> --- a/cpus.c
>> +++ b/cpus.c
>> @@ -786,6 +786,24 @@ void async_run_on_cpu(CPUState *cpu, void (*func)(void 
>> *data), void *data)
>>  qemu_cpu_kick(cpu);
>>  }
>>
>> +static void qemu_kvm_destroy_vcpu(CPUState *cpu)
>> +{
>> +CPU_REMOVE(cpu);
>> +
>> +if (kvm_destroy_vcpu(cpu) < 0) {
>> +fprintf(stderr, "kvm_destroy_vcpu failed.\n");
>> +exit(1);
>> +}
>> +
>> +object_unparent(OBJECT(cpu));
>> +}
>> +
>> +static void qemu_tcg_destroy_vcpu(CPUState *cpu)
>> +{
>> +CPU_REMOVE(cpu);
>> +object_unparent(OBJECT(cpu));
>> +}
>> +
>>  static void flush_queued_work(CPUState *cpu)
>>  {
>>  struct qemu_work_item *wi;
>> @@ -877,6 +895,11 @@ static void *qemu_kvm_cpu_thread_fn(void *arg)
>>  }
>>  }
>>  qemu_kvm_wait_io_event(cpu);
>> +if (cpu->exit && !cpu_can_run(cpu)) {
>> +qemu_kvm_destroy_vcpu(cpu);
>> +qemu_mutex_unlock(&qemu_global_mutex);
>> +return NULL;
>> +}
>>  }
>>
>>  return NULL;
>> @@ -929,6 +952,7 @@ static void tcg_exec_all(void);
>>  static void *qemu_tcg_cpu_thread_fn(void *arg)
>>  {
>>  CPUState *cpu = arg;
>> +CPUState *remove_cpu = NULL;
>>
>>  qemu_tcg_init_cpu_signals();
>>  qemu_thread_get_self(cpu->thread);
>> @@ -961,6 +985,16 @@ static void *qemu_tcg_cpu_thread_fn(void *arg)
>>  }
>>  }
>>  qemu_tcg_wait_io_event();
>> +CPU_FOREACH(cpu) {
>> +if (cpu->exit && !cpu_can_run(cpu)) {
>> +remove_cpu = cpu;
>> +break;
>> +}
>> +}
>> +if (remove_cpu) {
>> +qemu_tcg_destroy_vcpu(remove_cpu);
>> +remove_cpu = NULL;
>> +}
>>  }
>>
>>  return NULL;
>> @@ -1316,6 +1350,9 @@ static void tcg_exec_all(void)
>>  break;
>>  }
>>  } else if (cpu->stop || cpu->stopped) {
>> +if (cpu->exit) {
>> +next_cpu = CPU_NEXT(cpu);
>> +}
>>  break;
>>  }
>>  }
>> diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
>> index 174ea36..88e2403 100644
>> --- a/include/sysemu/kvm.h
>> +++ b/include/sysemu/kvm.h
>> @@ -178,6 +178,7 @@ int kvm_has_intx_set_mask(void);
>>
>>  int kvm_init_vcpu(CPUState *cpu);
>>  int kvm_cpu_exec(CPUState *cpu);
>> +int kvm_destroy_vcpu(CPUState *cpu);
>>
>>  #ifdef NEED_CPU_H
>>
>> diff --git a/kvm-all.c b/kvm-all.c
>> index 1402f4f..d0caeff 100644
>> --- a/kvm-all.c
>> +++ b/kvm-all.c
>> @@ -74,6 +74,12 @@ typedef struct KVMSlot
>>
>>  typedef struct kvm_dirty_log KVMDirtyLog;
>>
>> +struct KVMParkedVcpu {
>> +unsigned long vcpu_id;
>> +int kvm_fd;
>> +QLIST_ENTRY(KVMParkedVcpu) node;
>> +};
>> +
>>  struct KVMState
>>  {
>>  KVMSlot *slots;
>> @@ -108,6 +114,7 @@ struct KVMState
>>  QTAILQ_HEAD(msi_hashtab, KVMMSIRoute) msi_hashtab[KVM_MSI_HASHTAB_SIZE];
>>  bool direct_msi;
>>  #endif
>> +QLIST_HEAD(, KVMParkedVcpu) kvm_parked_vcpus;
>>  };

[Qemu-devel] [Bug 1354279] [NEW] The guest will be destroyed after hot remove the VF from the guest.

2014-08-07 Thread chao zhou
Public bug reported:

Environment:

Host OS (ia32/ia32e/IA64):ia32e
Guest OS (ia32/ia32e/IA64):ia32e
Guest OS Type (Linux/Windows):Linux
kvm.git Commit:9f6226a762c7ae02f6a23a3d4fc552dafa57ea23
qemu.git Commit:5a7348045091a2bc15d85bb177e5956aa6114e5a
Host Kernel Version:3.16.0-rc1
Hardware:Romley_EP, Ivytown_EP,Haswell_EP


Bug detailed description:
--
hot add the VF to the guest, then hot remove the VF from the guest, the guest 
will be destroyed.

note:
1. when hot add the VF with vfio, the hot remove the VF from the guest, the 
guest works fine.
2. this shoule be a qemu bug:
kvm   +   qemu= result
9f6226a7  +  5a734804 = bad
9f6226a7  +  9f862687 = good


Reproduce steps:

1. create guest
qemu-system-x86_64 --enable-kvm -m 1024 -smp 4 -net none rhel6u5.qcow -monitor 
pty
2. hot add the vf to guest
echo "device_add pci-assign,host=05:10.0,id=nic" >/dev/pts/x
cat /dev/pts/x
3. hot remove the VF froem guest
echo "device_del nic" >/dev/pts/x

Current result:

the guest willl be destroyed after hot remove the VF from the guest

Expected result:

the guest works fine after hot remove the VF from the guest


Basic root-causing log:
--
[root@vt-snb9 qemu.git]# qemu-system-x86_64 -enable-kvm -m 1024 -smp 2 -net 
none rhel6u5.qcow -monitor pty
VNC server running on `::1:5900'
**
ERROR:qom/object.c:725:object_unref: assertion failed: (obj->ref > 0)
Aborted (core dumped)

** 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/1354279

Title:
  The guest will be destroyed after hot remove the VF from the guest.

Status in QEMU:
  New

Bug description:
  Environment:
  
  Host OS (ia32/ia32e/IA64):ia32e
  Guest OS (ia32/ia32e/IA64):ia32e
  Guest OS Type (Linux/Windows):Linux
  kvm.git Commit:9f6226a762c7ae02f6a23a3d4fc552dafa57ea23
  qemu.git Commit:5a7348045091a2bc15d85bb177e5956aa6114e5a
  Host Kernel Version:3.16.0-rc1
  Hardware:Romley_EP, Ivytown_EP,Haswell_EP

  
  Bug detailed description:
  --
  hot add the VF to the guest, then hot remove the VF from the guest, the guest 
will be destroyed.

  note:
  1. when hot add the VF with vfio, the hot remove the VF from the guest, the 
guest works fine.
  2. this shoule be a qemu bug:
  kvm   +   qemu= result
  9f6226a7  +  5a734804 = bad
  9f6226a7  +  9f862687 = good


  Reproduce steps:
  
  1. create guest
  qemu-system-x86_64 --enable-kvm -m 1024 -smp 4 -net none rhel6u5.qcow 
-monitor pty
  2. hot add the vf to guest
  echo "device_add pci-assign,host=05:10.0,id=nic" >/dev/pts/x
  cat /dev/pts/x
  3. hot remove the VF froem guest
  echo "device_del nic" >/dev/pts/x

  Current result:
  
  the guest willl be destroyed after hot remove the VF from the guest

  Expected result:
  
  the guest works fine after hot remove the VF from the guest

  
  Basic root-causing log:
  --
  [root@vt-snb9 qemu.git]# qemu-system-x86_64 -enable-kvm -m 1024 -smp 2 -net 
none rhel6u5.qcow -monitor pty
  VNC server running on `::1:5900'
  **
  ERROR:qom/object.c:725:object_unref: assertion failed: (obj->ref > 0)
  Aborted (core dumped)

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



[Qemu-devel] [Bug 1354279] Re: The guest will be destroyed after hot remove the VF from the guest.

2014-08-07 Thread chao zhou
the first bad commit is:
commit 22a893e4f55344f96e1aafc66f5fedc491a5ca97
Author: Paolo Bonzini 
Date:   Wed Jun 11 10:58:06 2014 +0200

memory: MemoryRegion: replace owner field with QOM parent

The two are now the same.

Reviewed-by: Peter Crosthwaite 
Signed-off-by: Paolo Bonzini 

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

Title:
  The guest will be destroyed after hot remove the VF from the guest.

Status in QEMU:
  New

Bug description:
  Environment:
  
  Host OS (ia32/ia32e/IA64):ia32e
  Guest OS (ia32/ia32e/IA64):ia32e
  Guest OS Type (Linux/Windows):Linux
  kvm.git Commit:9f6226a762c7ae02f6a23a3d4fc552dafa57ea23
  qemu.git Commit:5a7348045091a2bc15d85bb177e5956aa6114e5a
  Host Kernel Version:3.16.0-rc1
  Hardware:Romley_EP, Ivytown_EP,Haswell_EP

  
  Bug detailed description:
  --
  hot add the VF to the guest, then hot remove the VF from the guest, the guest 
will be destroyed.

  note:
  1. when hot add the VF with vfio, the hot remove the VF from the guest, the 
guest works fine.
  2. this shoule be a qemu bug:
  kvm   +   qemu= result
  9f6226a7  +  5a734804 = bad
  9f6226a7  +  9f862687 = good


  Reproduce steps:
  
  1. create guest
  qemu-system-x86_64 --enable-kvm -m 1024 -smp 4 -net none rhel6u5.qcow 
-monitor pty
  2. hot add the vf to guest
  echo "device_add pci-assign,host=05:10.0,id=nic" >/dev/pts/x
  cat /dev/pts/x
  3. hot remove the VF froem guest
  echo "device_del nic" >/dev/pts/x

  Current result:
  
  the guest willl be destroyed after hot remove the VF from the guest

  Expected result:
  
  the guest works fine after hot remove the VF from the guest

  
  Basic root-causing log:
  --
  [root@vt-snb9 qemu.git]# qemu-system-x86_64 -enable-kvm -m 1024 -smp 2 -net 
none rhel6u5.qcow -monitor pty
  VNC server running on `::1:5900'
  **
  ERROR:qom/object.c:725:object_unref: assertion failed: (obj->ref > 0)
  Aborted (core dumped)

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



[Qemu-devel] [Bug 994378] Re: Nested-virt)L1 (kvm on kvm)guest panic with parameter “-cpu host” in qemu command line.

2014-08-07 Thread chao zhou
** Changed in: qemu
   Status: New => Fix Released

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

Title:
  Nested-virt)L1 (kvm on kvm)guest panic with parameter “-cpu host” in
  qemu command line.

Status in QEMU:
  Fix Released

Bug description:
  Environment:
  
  Host OS (ia32/ia32e/IA64):ia32e
  Guest OS (ia32/ia32e/IA64):ia32e
  Guest OS Type (Linux/Windows):Linux
  kvm.git Commit:19853301ef3289bda2d5264c1093e74efddaeab9
  qemu-kvm Commit:69abebf20280152da8fa7c418a819ae51e862231
  Host Kernel Version:3.4.0-rc3
  Hardware:WSM-EP, Romley-EP

  
  Bug detailed description:
  --
  (KVM on KVM) L1 guest panic when starting the L1 guest with “-cpu host” 
parameter in qemu command line.

  Note:
  1. when creating guest with “-cpu qemu64,+vmx”, L1 guest and L2 guest can boot
  up. 
  2. This should be a qemu-kvm bug. using '-cpu host' parameter, the following 
is the result.
  Kvm+ qemu-kvm =result
  19853301 + 69abebf2  = bad
  19853301 + 44755ea3  = good
  3. when booting up the guest with  the good commit of 19853301 + 44755ea3, 
you can see some
  error info, but nested virt works fine. (L1 and L2 guest can boot up.)
  “error: feature "i64" not available in set
  error: bad option value [extfeature_edx = i64 xd syscall]” 

  some logs 
  [root@vt-snb9 x86_64-softmmu]# ./qemu-system-x86_64 -m 2048 -net 
nic,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /root/nested-kvm.qcow 
-cpu host
  error: feature "i64" not available in set
  error: bad option value [extfeature_edx = i64 xd syscall]
  error: feature "i64" not available in set
  error: bad option value [extfeature_edx = i64 xd syscall]
  error: feature "i64" not available in set
  error: bad option value [extfeature_edx = i64 syscall xd]
  error: feature "i64" not available in set
  error: bad option value [extfeature_edx = i64 syscall xd]
  VNC server running on `::1:5900'


  Reproduce steps:
  
  1.start up a host with kvm (commit: 19853301)
  2.rmmod kvm_intel
  3.modprobe kvm_intel nested=1
  4.qemu-system-x86_64 -m 2048  -hda L1-kvm.img -cpu host


  Current result:
  
  L1 guest panic.

  Expected result:
  
  L1 guest and L2 guest boot up correctly.

  Basic root-causing log:
  --

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



[Qemu-devel] [Bug 994378] Re: Nested-virt)L1 (kvm on kvm)guest panic with parameter “-cpu host” in qemu command line.

2014-08-07 Thread chao zhou
when L1 guest kernel: 3.16.0(kvm.git+ qemu.git: c77dcacb..-69f87f71)
create L1 guest:
qemu-system-x86_64 -enable-kvm -m 6G -smp 4 -net nic,macaddr=00:12:31:45:56:13 
-net tap,script=/etc/kvm/qemu-ifup ia32e_nested-kvm.img -cpu host
the L1 guest boot up fine

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

Title:
  Nested-virt)L1 (kvm on kvm)guest panic with parameter “-cpu host” in
  qemu command line.

Status in QEMU:
  New

Bug description:
  Environment:
  
  Host OS (ia32/ia32e/IA64):ia32e
  Guest OS (ia32/ia32e/IA64):ia32e
  Guest OS Type (Linux/Windows):Linux
  kvm.git Commit:19853301ef3289bda2d5264c1093e74efddaeab9
  qemu-kvm Commit:69abebf20280152da8fa7c418a819ae51e862231
  Host Kernel Version:3.4.0-rc3
  Hardware:WSM-EP, Romley-EP

  
  Bug detailed description:
  --
  (KVM on KVM) L1 guest panic when starting the L1 guest with “-cpu host” 
parameter in qemu command line.

  Note:
  1. when creating guest with “-cpu qemu64,+vmx”, L1 guest and L2 guest can boot
  up. 
  2. This should be a qemu-kvm bug. using '-cpu host' parameter, the following 
is the result.
  Kvm+ qemu-kvm =result
  19853301 + 69abebf2  = bad
  19853301 + 44755ea3  = good
  3. when booting up the guest with  the good commit of 19853301 + 44755ea3, 
you can see some
  error info, but nested virt works fine. (L1 and L2 guest can boot up.)
  “error: feature "i64" not available in set
  error: bad option value [extfeature_edx = i64 xd syscall]” 

  some logs 
  [root@vt-snb9 x86_64-softmmu]# ./qemu-system-x86_64 -m 2048 -net 
nic,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /root/nested-kvm.qcow 
-cpu host
  error: feature "i64" not available in set
  error: bad option value [extfeature_edx = i64 xd syscall]
  error: feature "i64" not available in set
  error: bad option value [extfeature_edx = i64 xd syscall]
  error: feature "i64" not available in set
  error: bad option value [extfeature_edx = i64 syscall xd]
  error: feature "i64" not available in set
  error: bad option value [extfeature_edx = i64 syscall xd]
  VNC server running on `::1:5900'


  Reproduce steps:
  
  1.start up a host with kvm (commit: 19853301)
  2.rmmod kvm_intel
  3.modprobe kvm_intel nested=1
  4.qemu-system-x86_64 -m 2048  -hda L1-kvm.img -cpu host


  Current result:
  
  L1 guest panic.

  Expected result:
  
  L1 guest and L2 guest boot up correctly.

  Basic root-causing log:
  --

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



Re: [Qemu-devel] [PATCH 2/2] sheepdog: improve error handling for a case of failed lock

2014-08-07 Thread Liu Yuan
On Thu, Aug 07, 2014 at 04:28:40PM +0900, Hitoshi Mitake wrote:
> Recently, sheepdog revived its VDI locking functionality. This patch
> updates sheepdog driver of QEMU for this feature:
> 
> 1. Improve error message when QEMU fails to acquire lock of
> VDI. Current sheepdog driver prints an error message "VDI isn't
> locked" when it fails to acquire lock. It is a little bit confusing
> because the mesage says VDI isn't locked but it is actually locked by
> other VM. This patch modifies this confusing message.
> 
> 2. Change error code for a case of failed locking. -EBUSY is a
> suitable one.
> 
> Reported-by: Valerio Pachera 
> Cc: Kevin Wolf 
> Cc: Stefan Hajnoczi 
> Cc: Liu Yuan 
> Cc: MORITA Kazutaka 
> Signed-off-by: Hitoshi Mitake 
> ---
>  block/sheepdog.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/block/sheepdog.c b/block/sheepdog.c
> index 36f76f0..0b3f86d 100644
> --- a/block/sheepdog.c
> +++ b/block/sheepdog.c
> @@ -1112,9 +1112,13 @@ static int find_vdi_name(BDRVSheepdogState *s, const 
> char *filename,
>  
>  if (rsp->result != SD_RES_SUCCESS) {
>  error_setg(errp, "cannot get vdi info, %s, %s %" PRIu32 " %s",
> +   rsp->result == SD_RES_VDI_NOT_LOCKED ?

I'm puzzled by this check.

we use SD_RES_VDI_LOCKED to indicate vid is already locked, no?

> +   "VDI is already locked by other VM" :
> sd_strerror(rsp->result), filename, snapid, tag);
>  if (rsp->result == SD_RES_NO_VDI) {
>  ret = -ENOENT;
> +} else if (rsp->result == SD_RES_VDI_NOT_LOCKED) {
> +ret = -EBUSY;
>  } else {
>  ret = -EIO;
>  }

It is better to use switch case to handle the result.

Thanks
Yuan



[Qemu-devel] [Bug 994378] Re: Nested-virt)L1 (kvm on kvm)guest panic with parameter “-cpu host” in qemu command line.

2014-08-07 Thread chao zhou
this patch fixed the bug:
commit 338b522ca43cfd32d11a370f4203bcd089c6c877
Author: Kan Liang 
Date:   Mon Jul 14 12:25:56 2014 -0700

perf/x86/intel: Protect LBR and extra_regs against KVM lying

With -cpu host, KVM reports LBR and extra_regs support, if the host has
support.

When the guest perf driver tries to access LBR or extra_regs MSR,
it #GPs all MSR accesses,since KVM doesn't handle LBR and extra_regs 
support.
So check the related MSRs access right once at initialization time to avoid
the error access at runtime.

For reproducing the issue, please build the kernel with CONFIG_KVM_INTEL = y
(for host kernel).
And CONFIG_PARAVIRT = n and CONFIG_KVM_GUEST = n (for guest kernel).
Start the guest with -cpu host.
Run perf record with --branch-any or --branch-filter in guest to trigger LBR
Run perf stat offcore events (E.g. LLC-loads/LLC-load-misses ...) in guest 
to
trigger offcore_rsp #GP

Signed-off-by: Kan Liang 
Signed-off-by: Peter Zijlstra 
Cc: Andi Kleen 
Cc: Arnaldo Carvalho de Melo 
Cc: Linus Torvalds 
Cc: Maria Dimakopoulou 
Cc: Mark Davies 
Cc: Paul Mackerras 
Cc: Stephane Eranian 
Cc: Yan, Zheng 
Link: 
http://lkml.kernel.org/r/1405365957-20202-1-git-send-email-kan.li...@intel.com
Signed-off-by: Ingo Molnar 

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

Title:
  Nested-virt)L1 (kvm on kvm)guest panic with parameter “-cpu host” in
  qemu command line.

Status in QEMU:
  New

Bug description:
  Environment:
  
  Host OS (ia32/ia32e/IA64):ia32e
  Guest OS (ia32/ia32e/IA64):ia32e
  Guest OS Type (Linux/Windows):Linux
  kvm.git Commit:19853301ef3289bda2d5264c1093e74efddaeab9
  qemu-kvm Commit:69abebf20280152da8fa7c418a819ae51e862231
  Host Kernel Version:3.4.0-rc3
  Hardware:WSM-EP, Romley-EP

  
  Bug detailed description:
  --
  (KVM on KVM) L1 guest panic when starting the L1 guest with “-cpu host” 
parameter in qemu command line.

  Note:
  1. when creating guest with “-cpu qemu64,+vmx”, L1 guest and L2 guest can boot
  up. 
  2. This should be a qemu-kvm bug. using '-cpu host' parameter, the following 
is the result.
  Kvm+ qemu-kvm =result
  19853301 + 69abebf2  = bad
  19853301 + 44755ea3  = good
  3. when booting up the guest with  the good commit of 19853301 + 44755ea3, 
you can see some
  error info, but nested virt works fine. (L1 and L2 guest can boot up.)
  “error: feature "i64" not available in set
  error: bad option value [extfeature_edx = i64 xd syscall]” 

  some logs 
  [root@vt-snb9 x86_64-softmmu]# ./qemu-system-x86_64 -m 2048 -net 
nic,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /root/nested-kvm.qcow 
-cpu host
  error: feature "i64" not available in set
  error: bad option value [extfeature_edx = i64 xd syscall]
  error: feature "i64" not available in set
  error: bad option value [extfeature_edx = i64 xd syscall]
  error: feature "i64" not available in set
  error: bad option value [extfeature_edx = i64 syscall xd]
  error: feature "i64" not available in set
  error: bad option value [extfeature_edx = i64 syscall xd]
  VNC server running on `::1:5900'


  Reproduce steps:
  
  1.start up a host with kvm (commit: 19853301)
  2.rmmod kvm_intel
  3.modprobe kvm_intel nested=1
  4.qemu-system-x86_64 -m 2048  -hda L1-kvm.img -cpu host


  Current result:
  
  L1 guest panic.

  Expected result:
  
  L1 guest and L2 guest boot up correctly.

  Basic root-causing log:
  --

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



Re: [Qemu-devel] [PATCH 1/2] sheepdog: adopting protocol update for VDI locking

2014-08-07 Thread Liu Yuan
On Thu, Aug 07, 2014 at 04:28:39PM +0900, Hitoshi Mitake wrote:
> The update is required for supporting iSCSI multipath. It doesn't
> affect behavior of QEMU driver but adding a new field to vdi request
> struct is required.
> 
> Cc: Kevin Wolf 
> Cc: Stefan Hajnoczi 
> Cc: Liu Yuan 
> Cc: MORITA Kazutaka 
> Signed-off-by: Hitoshi Mitake 
> ---
>  block/sheepdog.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/block/sheepdog.c b/block/sheepdog.c
> index 8d9350c..36f76f0 100644
> --- a/block/sheepdog.c
> +++ b/block/sheepdog.c
> @@ -103,6 +103,9 @@
>  #define SD_INODE_SIZE (sizeof(SheepdogInode))
>  #define CURRENT_VDI_ID 0
>  
> +#define LOCK_TYPE_NORMAL 1
> +#define LOCK_TYPE_SHARED 2  /* for iSCSI multipath */

How about

#define LOCK_TYPE_NORMAL 0
#define LOCK_TYPE_SHARED 1

Then we don't need this patch. Since qemu won't make use of multipath for the
near future, we should avoid adding stuff related to multipath to qemu driver.

Thanks
Yuan

> +
>  typedef struct SheepdogReq {
>  uint8_t proto_ver;
>  uint8_t opcode;
> @@ -166,7 +169,8 @@ typedef struct SheepdogVdiReq {
>  uint8_t copy_policy;
>  uint8_t reserved[2];
>  uint32_t snapid;
> -uint32_t pad[3];
> +uint32_t type;
> +uint32_t pad[2];
>  } SheepdogVdiReq;
>  
>  typedef struct SheepdogVdiRsp {
> @@ -1090,6 +1094,7 @@ static int find_vdi_name(BDRVSheepdogState *s, const 
> char *filename,
>  memset(&hdr, 0, sizeof(hdr));
>  if (lock) {
>  hdr.opcode = SD_OP_LOCK_VDI;
> +hdr.type = LOCK_TYPE_NORMAL;
>  } else {
>  hdr.opcode = SD_OP_GET_VDI_INFO;
>  }
> @@ -1793,6 +1798,7 @@ static void sd_close(BlockDriverState *bs)
>  memset(&hdr, 0, sizeof(hdr));
>  
>  hdr.opcode = SD_OP_RELEASE_VDI;
> +hdr.type = LOCK_TYPE_NORMAL;
>  hdr.base_vdi_id = s->inode.vdi_id;
>  wlen = strlen(s->name) + 1;
>  hdr.data_length = wlen;
> -- 
> 1.8.3.2
> 



[Qemu-devel] [PATCH] linux-user: Fix syscall instruction usermode emulation on X86_64

2014-08-07 Thread Jincheng Miao
Currently syscall instruction is buggy on user mode X86_64,
the EIP is updated after do_syscall(), that is too late for
clone(). Because clone() will create a thread at the env->EIP
(the address of syscall insn), and then child thread enters
do_syscall() again, that is not expected. Sometimes it is tragic.

User mode syscall insn emulation is not used MSR, so the
action should be same to INT 0x80. INT 0x80 will update EIP in
do_interrupt(), ditto for syscall() for consistency.

Signed-off-by: Jincheng Miao 
---
 linux-user/main.c|1 -
 target-i386/seg_helper.c |4 ++--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/linux-user/main.c b/linux-user/main.c
index b453a39..472a16d 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -309,7 +309,6 @@ void cpu_loop(CPUX86State *env)
   env->regs[8],
   env->regs[9],
   0, 0);
-env->eip = env->exception_next_eip;
 break;
 #endif
 case EXCP0B_NOSEG:
diff --git a/target-i386/seg_helper.c b/target-i386/seg_helper.c
index 2d970d0..13eefba 100644
--- a/target-i386/seg_helper.c
+++ b/target-i386/seg_helper.c
@@ -1127,8 +1127,8 @@ static void do_interrupt_user(CPUX86State *env, int 
intno, int is_int,
 
 /* Since we emulate only user space, we cannot do more than
exiting the emulation with the suitable exception and error
-   code */
-if (is_int) {
+   code. So update EIP for INT 0x80 and EXCP_SYSCALL. */
+if (is_int || intno == EXCP_SYSCALL) {
 env->eip = next_eip;
 }
 }
-- 
1.7.1




Re: [Qemu-devel] [PATCH v4 06/15] target-tricore: Add instructions of SRC opcode format

2014-08-07 Thread Richard Henderson
> +static inline void gen_add_d(TCGv ret, TCGv r1, TCGv r2)
> +{
> +TCGv t0 = tcg_temp_new_i32();
> +/* Addition and set V/SV bits */
> +tcg_gen_add_tl(ret, r1, r2);
> +/* calc V bit */
> +tcg_gen_xor_tl(cpu_PSW_V, ret, r1);
> +tcg_gen_xor_tl(t0, r1, r2);
> +tcg_gen_andc_tl(cpu_PSW_V, cpu_PSW_V, t0);

I'd prefer not to see a v5 until you've actually tested some of this.  If that
requires that you implement some of the 32-bit instructions, so be it.

You cannot overwrite any of the inputs until you've computed overflow.  Since
you're passing the cpu_gpr_d variables directly, which means that any insn that
computes a = a + b overwrites r1 before you've used it in either xor.

> +static inline void gen_cond_add(int cond, TCGv r1, TCGv r2, TCGv r3,
> +TCGv r4)

The type of cond should be TCGCond.

> +/* Calc PSW_V */
> +tcg_gen_xor_tl(temp, temp, r1);
> +tcg_gen_xor_tl(temp, r1, r2);
> +tcg_gen_andc_tl(temp2, temp, t0);
> +tcg_gen_movcond_tl(cond, cpu_PSW_V, r4, t0, temp2, cpu_PSW_V);
> +/* Set PSW_SV */
> +tcg_gen_or_tl(cpu_PSW_SV, temp2, cpu_PSW_SV);
> +/* calc AV bit */
> +tcg_gen_add_tl(temp2, temp2, temp);
> +tcg_gen_xor_tl(temp2, temp2, temp);
> +tcg_gen_movcond_tl(cond, cpu_PSW_AV, r4, t0, temp2, cpu_PSW_AV);
> +/* calc SAV bit */
> +tcg_gen_or_tl(cpu_PSW_SAV, temp2, cpu_PSW_SAV);

The sticky bits still need a movcond.  Or create a setcond mask like

mask = r4 cond 0
mask = mask << 31
temp2 &= mask
PSW_SV |= temp2;
...
temp2 &= mask
PSW_SAV |= temp2

> +static void gen_shaci(TCGv ret, TCGv r1, int32_t shift_count)
> +{
> +uint32_t msk, msk_start;
> +TCGv temp = tcg_temp_new();
> +TCGv temp2 = tcg_temp_new();
> +TCGv t_max = tcg_const_i32(0x7FFF >> shift_count);
> +TCGv t_min = tcg_const_i32(-(0x8000L) >> shift_count);

These constants are only used in the shift_count > 0 case, and indeed cannot be
computed except within the shift_count > 0 case without provoking underined
behaviour.

> +if (shift_count == 0) {
> +/* Clear PSW.C */
> +tcg_gen_movi_tl(cpu_PSW_C, 0);
> +tcg_gen_mov_tl(ret, r1);

Also clear V.

> +} else if (shift_count == 32) {
> +/* fill ret completly with sign bit */
> +tcg_gen_sari_tl(ret, r1, 31);

Should be shift_count == -32; also clear V.

> +} else if (shift_count > 0) {
> +tcg_gen_shli_tl(ret, r1, shift_count);
> +/* calc carry */
> +msk_start = 32 - shift_count;
> +msk = ((1 << shift_count) - 1) << msk_start;
> +tcg_gen_andi_tl(cpu_PSW_C, r1, msk);
> +/* calc v/sv bits */
> +tcg_gen_setcond_tl(TCG_COND_GT, temp, r1, t_max);
> +tcg_gen_setcond_tl(TCG_COND_LT, temp2, r1, t_min);
> +tcg_gen_or_tl(cpu_PSW_V, temp, temp2);
> +/* calc sv */
> +tcg_gen_or_tl(cpu_PSW_SV, cpu_PSW_V, cpu_PSW_SV);

You must compute C and V before overwriting r1.

> +} else {
> +tcg_gen_sari_tl(ret, r1, -(shift_count));
> +/* calc carry */
> +msk = (1 << (shift_count - 1)) - 1;
> +tcg_gen_andi_tl(cpu_PSW_C, r1, msk);

Likewise, and clear V.


r~



Re: [Qemu-devel] [PATCH v4 01/15] target-tricore: Add target stubs and qom-cpu

2014-08-07 Thread Richard Henderson
On 08/07/2014 04:34 AM, Bastian Koppelmann wrote:
> +/* PSW flag cache for faster execution
> +   if flag != 0 then flag is set. Else flag is not set.
> +*/
> +target_ulong PSW_USB_C;
> +target_ulong PSW_USB_V;
> +target_ulong PSW_USB_SV;
> +target_ulong PSW_USB_AV;  /* Only if bit 31 set, then flag is set. */
> +target_ulong PSW_USB_SAV; /* Only if bit 31 set, then flag is set. */

V and SV are also only set if bit 31 is set, the way we're computing overflow
from addition.  Of course, overflow from saturation or multiplication isn't
being computed into bit 31, so there is a decision to make.

Depending on how important it is for ADDX+ADDC to be implemented efficiently,
vs how important is for SHA to be quick, you may wish to have C already set to
0/1 only.


r~



Re: [Qemu-devel] [PATCH v3 07/10] linux-user: check return value of malloc()

2014-08-07 Thread zhanghailiang

On 2014/8/8 1:19, Richard Henderson wrote:

On 08/06/2014 10:01 PM, zhanghailiang wrote:

  if (!lock_user_struct(VERIFY_READ, target_mb, msgp, 0))
  return -TARGET_EFAULT;
  host_mb = malloc(msgsz+sizeof(long));
+if (!host_mb) {
+return -TARGET_ENOMEM;
+}


lock_user allocates memory; returning from the middle leaks it.



Hmm, it is my fault, i will correct it. Thanks, Richard.

Best regards,
zhanghailiang




[Qemu-devel] [PATCH] linux-user: fix readlink handling with magic exe symlink

2014-08-07 Thread Mike Frysinger
From: Mike Frysinger 

The current code always returns the length of the path when it should
be returning the number of bytes it wrote to the output string.

Further, readlink is not supposed to append a NUL byte, but the current
snprintf logic will always do just that.

Even further, if you pass in a length of 0, you're suppoesd to get back
an error (EINVAL), but the current logic just returns 0.

Further still, if there was an error reading the symlink, we should not
go ahead and try to read the target buffer as it is garbage.

Simple test for the first two issues:
$ cat test.c
int main() {
char buf[50];
size_t len;
for (len = 0; len < 10; ++len) {
memset(buf, '!', sizeof(buf));
ssize_t ret = readlink("/proc/self/exe", buf, len);
buf[20] = '\0';
printf("readlink(/proc/self/exe, {%s}, %zu) = %zi\n", buf, len, ret);
}
return 0;
}

Now compare the output of the native:
$ gcc test.c -o /tmp/x
$ /tmp/x
$ strace /tmp/x

With what qemu does:
$ armv7a-cros-linux-gnueabi-gcc test.c -o /tmp/x -static
$ qemu-arm /tmp/x
$ qemu-arm -strace /tmp/x

Signed-off-by: Mike Frysinger 
---
 linux-user/syscall.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index a50229d..bd10a6b 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -6620,11 +6620,22 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
arg1,
 p2 = lock_user(VERIFY_WRITE, arg2, arg3, 0);
 if (!p || !p2) {
 ret = -TARGET_EFAULT;
+} else if (!arg3) {
+/* Short circuit this for the magic exe check. */
+ret = -TARGET_EINVAL;
 } else if (is_proc_myself((const char *)p, "exe")) {
 char real[PATH_MAX], *temp;
 temp = realpath(exec_path, real);
-ret = temp == NULL ? get_errno(-1) : strlen(real) ;
-snprintf((char *)p2, arg3, "%s", real);
+/* Return value is # of bytes that we wrote to the buffer. */
+if (temp == NULL) {
+ret = get_errno(-1);
+} else {
+/* Don't worry about sign mismatch as earlier mapping
+ * logic would have thrown a bad address error. */
+ret = MIN(strlen(real), arg3);
+/* We cannot NUL terminate the string. */
+memcpy(p2, real, ret);
+}
 } else {
 ret = get_errno(readlink(path(p), p2, arg3));
 }
-- 
2.0.0.526.g5318336




Re: [Qemu-devel] [000/108] Patch Round-up for stable 2.0.1, freeze on 2014-08-12

2014-08-07 Thread Michael Roth
Quoting Eric Blake (2014-08-07 16:23:14)
> On 08/06/2014 02:38 PM, Michael Roth wrote:
> > Hi everyone,
> > 
> > The following new patches are queued for QEMU stable v2.0.1:
> > 
> >   https://github.com/mdroth/qemu/commits/stable-2.0-staging
> > 
> > The release is planned for 2014-08-15:
> > 
> >   http://wiki.qemu.org/Planning/2.0
> > 
> > Please respond here or CC qemu-sta...@nongnu.org on any patches you
> > think should be included in the release.
> > 
> > Due to delays, this is the final planned release for the 2.0.0 series.
> > We will return to the standard 2-release cycle for 2.1 (one midway
> > during 2.2 development cycle, one immediately following 2.2 release)
> > 
> > Testing/feedback is greatly appreciated.
> 
> Another useful one to avoid a segfault during drive-mirror (possibly
> more related patches, as I know Kevin did several qiov cleanups, but at
> least this one was easy for me to hit in testing):
> 
> Kevin Wolf
> 5a0f6fd5 mirror: Fix qiov size for short requests

Pushed now. Preceded it with:

  d0d83e8 qemu-iotests: Test 0-length image for mirror

to bring 041 iotests closer in sync and add coverage
for previous patches.

> 
> -- 
> Eric Blake   eblake redhat com+1-919-301-3266
> Libvirt virtualization library http://libvirt.org




[Qemu-devel] [Bug 1354167] [NEW] On VM restart: Could not open 'poppy.qcow2': Could not read snapshots: File too large

2014-08-07 Thread Todd
Public bug reported:

I'm unable to restart a VM.   virt-manager is giving me:

Error starting domain: internal error: process exited while connecting
to monitor: qemu-system-x86_64: -drive
file=/var/lib/libvirt/images/poppy.qcow2,if=none,id=drive-virtio-
disk0,format=qcow2: could not open disk image
/var/lib/libvirt/images/poppy.qcow2: Could not read snapshots: File too
large


>From the command line trying to check the image also gives me:
qemu-img check poppy.qcow2
qemu-img: Could not open 'poppy.qcow2': Could not read snapshots: File too large


This bug appears with both the default install of qemu for ubuntu 14.04:
qemu-img version 2.0.0, Copyright (c) 2004-2008 Fabrice Bellard

And the latest version.
qemu-img version 2.1.50, Copyright (c) 2004-2008 Fabrice Bellard


Host: 
Dual E5-2650 v2 @ 2.60GHz
32GB Memory
4TB Disk space (2.1TB Free) 

Host OS: Ubuntu 14.04.1 LTS 64bit

Guest:
Ubuntu 14.04 64bit
Storage Size: 500gb

** 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/1354167

Title:
  On VM restart: Could not open 'poppy.qcow2': Could not read snapshots:
  File too large

Status in QEMU:
  New

Bug description:
  I'm unable to restart a VM.   virt-manager is giving me:

  Error starting domain: internal error: process exited while connecting
  to monitor: qemu-system-x86_64: -drive
  file=/var/lib/libvirt/images/poppy.qcow2,if=none,id=drive-virtio-
  disk0,format=qcow2: could not open disk image
  /var/lib/libvirt/images/poppy.qcow2: Could not read snapshots: File
  too large

  
  From the command line trying to check the image also gives me:
  qemu-img check poppy.qcow2
  qemu-img: Could not open 'poppy.qcow2': Could not read snapshots: File too 
large

  
  This bug appears with both the default install of qemu for ubuntu 14.04:
  qemu-img version 2.0.0, Copyright (c) 2004-2008 Fabrice Bellard

  And the latest version.
  qemu-img version 2.1.50, Copyright (c) 2004-2008 Fabrice Bellard

  
  Host: 
  Dual E5-2650 v2 @ 2.60GHz
  32GB Memory
  4TB Disk space (2.1TB Free) 

  Host OS: Ubuntu 14.04.1 LTS 64bit

  Guest:
  Ubuntu 14.04 64bit
  Storage Size: 500gb

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



Re: [Qemu-devel] [PULL 0/3] qga: support fsfreeze'ing specific mounts

2014-08-07 Thread Eric Blake
On 08/07/2014 04:10 PM, Michael Roth wrote:
> Hello,
> 
> Please pull the following changes, which add a new guest-fsfreeze-freeze-list
> command to qemu-ga that supports specifying specific mounts to freeze, and
> improves the introspection information from guest-info by explicitly
> blacklisting/reporting commands that aren't supported on a particular guest.
> 
> The following changes since commit 2ee55b8351910e5dd898f52415064a4c5479baba:
> 
>   Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into 
> staging (2014-08-07 14:54:47 +0100)
> 
> are available in the git repository at:
> 
> 
>   git://github.com/mdroth/qemu.git qga-pull-2014-08-07
> 
> for you to fetch changes up to 30043300803c1a16e3acedf973fc20a849e3be6e:
> 
>   qga: Disable unsupported commands by default (2014-08-07 16:59:41 -0500)
> 
> 
> Tomoki Sekiyama (3):
>   qga: Add guest-fsfreeze-freeze-list command
>   qga: Add guest-get-fsinfo command
>   qga: Disable unsupported commands by default

This series includes .json patches that call out 2.1 even though it is
2.2 material; I'm okay with deferring the fix to a followup patch if it
is easier to not have to bother with a v2 pull request.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [RESEND PATCH v5 1/3] qga: Add guest-fsfreeze-freeze-list command

2014-08-07 Thread Michael Roth
Quoting Eric Blake (2014-08-07 17:03:57)
> On 06/30/2014 03:51 PM, Tomoki Sekiyama wrote:
> > If an array of mount point paths is specified as 'mountpoints' argument
> > of guest-fsfreeze-freeze-list, qemu-ga will only freeze the file systems
> > mounted on specified paths in Linux guests. Otherwise, it works as the
> > same way as guest-fsfreeze-freeze.
> > This would be useful when the host wants to create partial disk snapshots.
> > 
> > Signed-off-by: Tomoki Sekiyama 
> > Reviewed-by: Eric Blake 
> > ---
> >  qga/commands-posix.c |   32 +++-
> >  qga/commands-win32.c |9 +
> >  qga/qapi-schema.json |   17 +
> >  3 files changed, 57 insertions(+), 1 deletion(-)
> > 
> 
> > +++ b/qga/qapi-schema.json
> > @@ -387,6 +387,23 @@
> >'returns': 'int' }
> >  
> >  ##
> > +# @guest-fsfreeze-freeze-list:
> > +#
> > +# Sync and freeze specified guest filesystems
> > +#
> > +# @mountpoints: #optional an array of mountpoints of filesystems to be 
> > frozen.
> > +#   If omitted, every mounted filesystem is frozen.
> > +#
> > +# Returns: Number of file systems currently frozen. On error, all 
> > filesystems
> > +# will be thawed.
> > +#
> > +# Since: 2.1
> 
> This missed 2.1.  We'll need a followup patch (or rebase mdroth's
> staging tree) to bump this to 2.2.

Yikes, thanks for the quick catch. Updated the versions in qga branch
and in the pull branch that was just sent.

> 
> -- 
> Eric Blake   eblake redhat com+1-919-301-3266
> Libvirt virtualization library http://libvirt.org




[Qemu-devel] [PATCH 2/3] qga: Add guest-get-fsinfo command

2014-08-07 Thread Michael Roth
From: Tomoki Sekiyama 

Add command to get mounted filesystems information in the guest.
The returned value contains a list of mountpoint paths and
corresponding disks info such as disk bus type, drive address,
and the disk controllers' PCI addresses, so that management layer
such as libvirt can resolve the disk backends.

For example, when `lsblk' result is:

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdb  8:16   01G  0 disk
`-sdb1   8:17   0 1024M  0 part
  `-vg0-lv0253:10  1.4G  0 lvm  /mnt/test
sdc  8:32   01G  0 disk
`-sdc1   8:33   0  512M  0 part
  `-vg0-lv0253:10  1.4G  0 lvm  /mnt/test
vda252:00   25G  0 disk
`-vda1 252:10   25G  0 part /

where sdb is a SCSI disk with PCI controller :00:0a.0 and ID=1,
  sdc is an IDE disk with PCI controller :00:01.1, and
  vda is a virtio-blk disk with PCI device :00:06.0,

guest-get-fsinfo command will return the following result:

{"return":
 [{"name":"dm-1",
   "mountpoint":"/mnt/test",
   "disk":[
{"bus-type":"scsi","bus":0,"unit":1,"target":0,
 "pci-controller":{"bus":0,"slot":10,"domain":0,"function":0}},
{"bus-type":"ide","bus":0,"unit":0,"target":0,
 "pci-controller":{"bus":0,"slot":1,"domain":0,"function":1}}],
   "type":"xfs"},
  {"name":"vda1", "mountpoint":"/",
   "disk":[
{"bus-type":"virtio","bus":0,"unit":0,"target":0,
 "pci-controller":{"bus":0,"slot":6,"domain":0,"function":0}}],
   "type":"ext4"}]}

In Linux guest, the disk information is resolved from sysfs. So far,
it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86
hosts, and "disk" parameter may be empty for unsupported disk types.

Signed-off-by: Tomoki Sekiyama 
Signed-off-by: Michael Roth 
---
 qga/commands-posix.c | 438 ++-
 qga/commands-win32.c |   6 +
 qga/qapi-schema.json |  79 ++
 3 files changed, 522 insertions(+), 1 deletion(-)

diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 883e3c5..6b8e9c4 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -575,6 +576,7 @@ static void guest_file_init(void)
 typedef struct FsMount {
 char *dirname;
 char *devtype;
+unsigned int devmajor, devminor;
 QTAILQ_ENTRY(FsMount) next;
 } FsMount;
 
@@ -596,15 +598,40 @@ static void free_fs_mount_list(FsMountList *mounts)
  }
 }
 
+static int dev_major_minor(const char *devpath,
+   unsigned int *devmajor, unsigned int *devminor)
+{
+struct stat st;
+
+*devmajor = 0;
+*devminor = 0;
+
+if (stat(devpath, &st) < 0) {
+slog("failed to stat device file '%s': %s", devpath, strerror(errno));
+return -1;
+}
+if (S_ISDIR(st.st_mode)) {
+/* It is bind mount */
+return -2;
+}
+if (S_ISBLK(st.st_mode)) {
+*devmajor = major(st.st_rdev);
+*devminor = minor(st.st_rdev);
+return 0;
+}
+return -1;
+}
+
 /*
  * Walk the mount table and build a list of local file systems
  */
-static void build_fs_mount_list(FsMountList *mounts, Error **errp)
+static void build_fs_mount_list_from_mtab(FsMountList *mounts, Error **errp)
 {
 struct mntent *ment;
 FsMount *mount;
 char const *mtab = "/proc/self/mounts";
 FILE *fp;
+unsigned int devmajor, devminor;
 
 fp = setmntent(mtab, "r");
 if (!fp) {
@@ -624,20 +651,423 @@ static void build_fs_mount_list(FsMountList *mounts, 
Error **errp)
 (strcmp(ment->mnt_type, "cifs") == 0)) {
 continue;
 }
+if (dev_major_minor(ment->mnt_fsname, &devmajor, &devminor) == -2) {
+/* Skip bind mounts */
+continue;
+}
 
 mount = g_malloc0(sizeof(FsMount));
 mount->dirname = g_strdup(ment->mnt_dir);
 mount->devtype = g_strdup(ment->mnt_type);
+mount->devmajor = devmajor;
+mount->devminor = devminor;
 
 QTAILQ_INSERT_TAIL(mounts, mount, next);
 }
 
 endmntent(fp);
 }
+
+static void decode_mntname(char *name, int len)
+{
+int i, j = 0;
+for (i = 0; i <= len; i++) {
+if (name[i] != '\\') {
+name[j++] = name[i];
+} else if (name[i + 1] == '\\') {
+name[j++] = '\\';
+i++;
+} else if (name[i + 1] >= '0' && name[i + 1] <= '3' &&
+   name[i + 2] >= '0' && name[i + 2] <= '7' &&
+   name[i + 3] >= '0' && name[i + 3] <= '7') {
+name[j++] = (name[i + 1] - '0') * 64 +
+(name[i + 2] - '0') * 8 +
+(name[i + 3] - '0');
+i += 3;
+} else {
+name[j++] = name[i];
+}
+}
+}
+
+static void build_fs_mount_list(FsM

[Qemu-devel] [PATCH 1/3] qga: Add guest-fsfreeze-freeze-list command

2014-08-07 Thread Michael Roth
From: Tomoki Sekiyama 

If an array of mount point paths is specified as 'mountpoints' argument
of guest-fsfreeze-freeze-list, qemu-ga will only freeze the file systems
mounted on specified paths in Linux guests. Otherwise, it works as the
same way as guest-fsfreeze-freeze.
This would be useful when the host wants to create partial disk snapshots.

Signed-off-by: Tomoki Sekiyama 
Reviewed-by: Eric Blake 
Signed-off-by: Michael Roth 
---
 qga/commands-posix.c | 32 +++-
 qga/commands-win32.c |  9 +
 qga/qapi-schema.json | 17 +
 3 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 8e6272c..883e3c5 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -710,13 +710,21 @@ GuestFsfreezeStatus qmp_guest_fsfreeze_status(Error 
**errp)
 return GUEST_FSFREEZE_STATUS_THAWED;
 }
 
+int64_t qmp_guest_fsfreeze_freeze(Error **errp)
+{
+return qmp_guest_fsfreeze_freeze_list(false, NULL, errp);
+}
+
 /*
  * Walk list of mounted file systems in the guest, and freeze the ones which
  * are real local file systems.
  */
-int64_t qmp_guest_fsfreeze_freeze(Error **errp)
+int64_t qmp_guest_fsfreeze_freeze_list(bool has_mountpoints,
+   strList *mountpoints,
+   Error **errp)
 {
 int ret = 0, i = 0;
+strList *list;
 FsMountList mounts;
 struct FsMount *mount;
 Error *local_err = NULL;
@@ -741,6 +749,19 @@ int64_t qmp_guest_fsfreeze_freeze(Error **errp)
 ga_set_frozen(ga_state);
 
 QTAILQ_FOREACH_REVERSE(mount, &mounts, FsMountList, next) {
+/* To issue fsfreeze in the reverse order of mounts, check if the
+ * mount is listed in the list here */
+if (has_mountpoints) {
+for (list = mountpoints; list; list = list->next) {
+if (strcmp(list->value, mount->dirname) == 0) {
+break;
+}
+}
+if (!list) {
+continue;
+}
+}
+
 fd = qemu_open(mount->dirname, O_RDONLY);
 if (fd == -1) {
 error_setg_errno(errp, errno, "failed to open %s", mount->dirname);
@@ -1474,6 +1495,15 @@ int64_t qmp_guest_fsfreeze_freeze(Error **errp)
 return 0;
 }
 
+int64_t qmp_guest_fsfreeze_freeze_list(bool has_mountpoints,
+   strList *mountpoints,
+   Error **errp)
+{
+error_set(errp, QERR_UNSUPPORTED);
+
+return 0;
+}
+
 int64_t qmp_guest_fsfreeze_thaw(Error **errp)
 {
 error_set(errp, QERR_UNSUPPORTED);
diff --git a/qga/commands-win32.c b/qga/commands-win32.c
index e769396..94877e9 100644
--- a/qga/commands-win32.c
+++ b/qga/commands-win32.c
@@ -206,6 +206,15 @@ error:
 return 0;
 }
 
+int64_t qmp_guest_fsfreeze_freeze_list(bool has_mountpoints,
+   strList *mountpoints,
+   Error **errp)
+{
+error_set(errp, QERR_UNSUPPORTED);
+
+return 0;
+}
+
 /*
  * Thaw local file systems using Volume Shadow-copy Service.
  */
diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json
index a8cdcb3..caa4612 100644
--- a/qga/qapi-schema.json
+++ b/qga/qapi-schema.json
@@ -387,6 +387,23 @@
   'returns': 'int' }
 
 ##
+# @guest-fsfreeze-freeze-list:
+#
+# Sync and freeze specified guest filesystems
+#
+# @mountpoints: #optional an array of mountpoints of filesystems to be frozen.
+#   If omitted, every mounted filesystem is frozen.
+#
+# Returns: Number of file systems currently frozen. On error, all filesystems
+# will be thawed.
+#
+# Since: 2.1
+##
+{ 'command': 'guest-fsfreeze-freeze-list',
+  'data':{ '*mountpoints': ['str'] },
+  'returns': 'int' }
+
+##
 # @guest-fsfreeze-thaw:
 #
 # Unfreeze all frozen guest filesystems
-- 
1.9.1




[Qemu-devel] [PATCH 3/3] qga: Disable unsupported commands by default

2014-08-07 Thread Michael Roth
From: Tomoki Sekiyama 

Currently management softwares cannot know whether a qemu-ga command is
supported or not on the running platform until they actually execute it.
This patch disables unsupported commands at launch time of qemu-ga, so that
management softwares can check whether they are supported from 'enabled'
property of the result from 'guest-info' command.

Signed-off-by: Tomoki Sekiyama 
Signed-off-by: Michael Roth 
---
 qga/commands-posix.c   | 38 ++
 qga/commands-win32.c   | 32 +++-
 qga/guest-agent-core.h |  1 +
 qga/main.c |  1 +
 4 files changed, 71 insertions(+), 1 deletion(-)

diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 6b8e9c4..7eed7f4 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -1955,6 +1955,44 @@ void qmp_guest_fstrim(bool has_minimum, int64_t minimum, 
Error **errp)
 }
 #endif
 
+/* add unsupported commands to the blacklist */
+GList *ga_command_blacklist_init(GList *blacklist)
+{
+#if !defined(__linux__)
+{
+const char *list[] = {
+"guest-suspend-disk", "guest-suspend-ram",
+"guest-suspend-hybrid", "guest-network-get-interfaces",
+"guest-get-vcpus", "guest-set-vcpus", NULL};
+char **p = (char **)list;
+
+while (*p) {
+blacklist = g_list_append(blacklist, *p++);
+}
+}
+#endif
+
+#if !defined(CONFIG_FSFREEZE)
+{
+const char *list[] = {
+"guest-get-fsinfo", "guest-fsfreeze-status",
+"guest-fsfreeze-freeze", "guest-fsfreeze-freeze-list",
+"guest-fsfreeze-thaw", "guest-get-fsinfo", NULL};
+char **p = (char **)list;
+
+while (*p) {
+blacklist = g_list_append(blacklist, *p++);
+}
+}
+#endif
+
+#if !defined(CONFIG_FSTRIM)
+blacklist = g_list_append(blacklist, (char *)"guest-fstrim");
+#endif
+
+return blacklist;
+}
+
 /* register init/cleanup routines for stateful command groups */
 void ga_command_state_init(GAState *s, GACommandState *cs)
 {
diff --git a/qga/commands-win32.c b/qga/commands-win32.c
index 3b667f5..3bcbeae 100644
--- a/qga/commands-win32.c
+++ b/qga/commands-win32.c
@@ -446,10 +446,40 @@ int64_t qmp_guest_set_vcpus(GuestLogicalProcessorList 
*vcpus, Error **errp)
 return -1;
 }
 
+/* add unsupported commands to the blacklist */
+GList *ga_command_blacklist_init(GList *blacklist)
+{
+const char *list_unsupported[] = {
+"guest-file-open", "guest-file-close", "guest-file-read",
+"guest-file-write", "guest-file-seek", "guest-file-flush",
+"guest-suspend-hybrid", "guest-network-get-interfaces",
+"guest-get-vcpus", "guest-set-vcpus",
+"guest-fsfreeze-freeze-list", "guest-get-fsinfo",
+"guest-fstrim", NULL};
+char **p = (char **)list_unsupported;
+
+while (*p) {
+blacklist = g_list_append(blacklist, *p++);
+}
+
+if (!vss_init(true)) {
+const char *list[] = {
+"guest-get-fsinfo", "guest-fsfreeze-status",
+"guest-fsfreeze-freeze", "guest-fsfreeze-thaw", NULL};
+p = (char **)list;
+
+while (*p) {
+blacklist = g_list_append(blacklist, *p++);
+}
+}
+
+return blacklist;
+}
+
 /* register init/cleanup routines for stateful command groups */
 void ga_command_state_init(GAState *s, GACommandState *cs)
 {
-if (vss_init(true)) {
+if (!vss_initialized()) {
 ga_command_state_add(cs, NULL, guest_fsfreeze_cleanup);
 }
 }
diff --git a/qga/guest-agent-core.h b/qga/guest-agent-core.h
index e422208..e92c6ab 100644
--- a/qga/guest-agent-core.h
+++ b/qga/guest-agent-core.h
@@ -19,6 +19,7 @@ typedef struct GAState GAState;
 typedef struct GACommandState GACommandState;
 extern GAState *ga_state;
 
+GList *ga_command_blacklist_init(GList *blacklist);
 void ga_command_state_init(GAState *s, GACommandState *cs);
 void ga_command_state_add(GACommandState *cs,
   void (*init)(void),
diff --git a/qga/main.c b/qga/main.c
index 8b927c9..227f2bd 100644
--- a/qga/main.c
+++ b/qga/main.c
@@ -1144,6 +1144,7 @@ int main(int argc, char **argv)
 goto out_bad;
 }
 
+blacklist = ga_command_blacklist_init(blacklist);
 if (blacklist) {
 s->blacklist = blacklist;
 do {
-- 
1.9.1




[Qemu-devel] [PULL 0/3] qga: support fsfreeze'ing specific mounts

2014-08-07 Thread Michael Roth
Hello,

Please pull the following changes, which add a new guest-fsfreeze-freeze-list
command to qemu-ga that supports specifying specific mounts to freeze, and
improves the introspection information from guest-info by explicitly
blacklisting/reporting commands that aren't supported on a particular guest.

The following changes since commit 2ee55b8351910e5dd898f52415064a4c5479baba:

  Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging 
(2014-08-07 14:54:47 +0100)

are available in the git repository at:


  git://github.com/mdroth/qemu.git qga-pull-2014-08-07

for you to fetch changes up to 30043300803c1a16e3acedf973fc20a849e3be6e:

  qga: Disable unsupported commands by default (2014-08-07 16:59:41 -0500)


Tomoki Sekiyama (3):
  qga: Add guest-fsfreeze-freeze-list command
  qga: Add guest-get-fsinfo command
  qga: Disable unsupported commands by default

 qga/commands-posix.c   | 508 
-
 qga/commands-win32.c   |  47 +-
 qga/guest-agent-core.h |   1 +
 qga/main.c |   1 +
 qga/qapi-schema.json   |  96 
 5 files changed, 650 insertions(+), 3 deletions(-)





Re: [Qemu-devel] [RESEND PATCH v5 2/3] qga: Add guest-get-fsinfo command

2014-08-07 Thread Eric Blake
On 06/30/2014 03:51 PM, Tomoki Sekiyama wrote:
> Add command to get mounted filesystems information in the guest.
> The returned value contains a list of mountpoint paths and
> corresponding disks info such as disk bus type, drive address,
> and the disk controllers' PCI addresses, so that management layer
> such as libvirt can resolve the disk backends.
> 

> In Linux guest, the disk information is resolved from sysfs. So far,
> it only supports virtio-blk, virtio-scsi, IDE, SATA, SCSI disks on x86
> hosts, and "disk" parameter may be empty for unsupported disk types.
> 
> Signed-off-by: Tomoki Sekiyama 
> ---
>  qga/commands-posix.c |  438 
> ++
>  qga/commands-win32.c |6 +
>  qga/qapi-schema.json |   79 +
>  3 files changed, 522 insertions(+), 1 deletion(-)
> 

> +##
> +# @GuestDiskBusType
> +#
> +# An enumeration of bus type of disks
> +#
> +# @ide: IDE disks
> +# @fdc: floppy disks
> +# @scsi: SCSI disks
> +# @virtio: virtio disks
> +# @xen: Xen disks
> +# @usb: USB disks
> +# @uml: UML disks
> +# @sata: SATA disks
> +# @sd: SD cards
> +#
> +# Since: 2.1

Another change to 2.2.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [RESEND PATCH v5 1/3] qga: Add guest-fsfreeze-freeze-list command

2014-08-07 Thread Eric Blake
On 06/30/2014 03:51 PM, Tomoki Sekiyama wrote:
> If an array of mount point paths is specified as 'mountpoints' argument
> of guest-fsfreeze-freeze-list, qemu-ga will only freeze the file systems
> mounted on specified paths in Linux guests. Otherwise, it works as the
> same way as guest-fsfreeze-freeze.
> This would be useful when the host wants to create partial disk snapshots.
> 
> Signed-off-by: Tomoki Sekiyama 
> Reviewed-by: Eric Blake 
> ---
>  qga/commands-posix.c |   32 +++-
>  qga/commands-win32.c |9 +
>  qga/qapi-schema.json |   17 +
>  3 files changed, 57 insertions(+), 1 deletion(-)
> 

> +++ b/qga/qapi-schema.json
> @@ -387,6 +387,23 @@
>'returns': 'int' }
>  
>  ##
> +# @guest-fsfreeze-freeze-list:
> +#
> +# Sync and freeze specified guest filesystems
> +#
> +# @mountpoints: #optional an array of mountpoints of filesystems to be 
> frozen.
> +#   If omitted, every mounted filesystem is frozen.
> +#
> +# Returns: Number of file systems currently frozen. On error, all filesystems
> +# will be thawed.
> +#
> +# Since: 2.1

This missed 2.1.  We'll need a followup patch (or rebase mdroth's
staging tree) to bump this to 2.2.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [000/108] Patch Round-up for stable 2.0.1, freeze on 2014-08-12

2014-08-07 Thread Eric Blake
On 08/07/2014 09:50 AM, Eric Blake wrote:
> On 08/07/2014 03:19 AM, Michael Roth wrote:
>>>
>>> Libvirt could support active commit against qemu 2.0.1 if you backport
>>> these patches:
>>>
>>> Jeff Cody
>>>   7676e2c597 block: make 'top' argument to block-commit optional
>>>
>>> Fam Zheng
>>>   9e48b02540 mirror: Go through ready -> complete process for 0 len image
>>
>> Actually ended up needing the following with a few fix-ups:
>>
>> 7676e2c->98103fa block: make 'top' argument to block-commit optional
>> 8b9a30c->e5f0eb0 qemu-iotests: Test BLOCK_JOB_READY event for 0Kb image 
>> active commit
>> 9e48b02->43ac708 mirror: Go through ready -> complete process for 0 len image
>> dc71ce4->8e09e20 blockjob: Add block_job_yield()
>> 373df5b->520b341 mirror: Fix resource leak when bdrv_getlength fails
>>
>> I've gone ahead and pushed them, but please test as we generally don't
>> do features (even backward-compatible ones) for stable, and this wasn't
>> as trivial as I was hoping.
> 
> Yes, I'll test and report back.

Testing complete - without the patches (commit e0efb023 on your branch),
libvirt 1.2.7 failed to run an active commit, even though I could run
one by hand via QMP; with the patches (commit 98103fa7 on your branch)
libvirt detected active commit and managed it just fine. I've replied
separately with a couple more patches (one that I needed for getting a
build made for running my tests, another for a coredump in drive-mirror
that I triggered while setting up my active commit tests).

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] Mousegrab broken with vfio in 2.1.0 (was: [PATCH 00/25] qemu gtk ui overhaul)

2014-08-07 Thread Benedikt Morbach
On Thu, 2014-08-07 at 00:22 +0200, Benedikt Morbach wrote:
> I think one of those gtk patches broke mouse/keyboard grab for my
> Windows 8 vfio/vga-passthrough setup in 2.1.0 and I was instructed on
> IRC to report that here.
> 
> With 2.0.0 I got a black qemu window with "This VM has no graphic
> display device", which I could click on to get a mouse grab.
> With 2.1.0 I just get the qemu monitor window.
> If I press Ctrl-Alt-g or use the corresponding menu entry, the gtk
> window grabs the input devices and the titlebar changes to "press
> Ctrl-Alt-g to release grab", but none of the input reaches the vm.
> 
> I tried all of {gtk3, sdl} x {usb-mouse, usb-tablet}:
> With gtk3, none worked.
> With sdl usb-tablet worked, but I haven't figured out how to do an
> actual mouse grab. (maybe related to me passing "-vga none"?)
> 
> If I drop the "-vga none" I can get a mouse-grab, but the passed-through
> gpu won't work, so this is no option for me.
> 
> If needed I can produce some logs with both 2.0 and 2.1, but I don't
> know what options I should pass to qemu to make those useful.
> 
> Here is how I start qemu:
> qemu-system-x86_64
> -enable-kvm -M q35  -cpu host,hv-time,kvm=off -vga none
> -m 8192 -smp 2,sockets=1,cores=2,threads=1
> -bios /usr/share/qemu/bios.bin
> -device 
> ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1
> -device 
> vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on
> -device vfio-pci,host=01:00.1,bus=root.1,addr=00.1
> -drive file=/mnt/images/Win8.raw,id=disk,format=raw,if=virtio
> -device ich9-intel-hda,bus=pcie.0,addr=1b.0,id=sound0
> -device hda-micro,id=sound0-codec0,bus=sound0.0,cad=0 
> -net bridge -net nic,model=virtio
> -rtc base=localtime
> -usb
> -usbdevice mouse
> -usbdevice keyboard

I have now bisected this down to:

commit ed1132e41a31ded554adc542ddf043714f05b9d0 

   

gtk: support multiple gfx displays

Each display gets its own tab.  Tab switching continues to work like it
did, just the hotkeys of the vte consoles changes in case a secondary
display is present as it will get ctrl-alt-2 assigned and the vtes are
shifted by one.




Re: [Qemu-devel] [RESEND PATCH v5 0/3] qga: Add guest-fsfreeze-freeze-list command

2014-08-07 Thread Michael Roth
Quoting Tomoki Sekiyama (2014-06-30 16:51:21)
> Hi,
> 
> As patch 3/3 was missing in the last post, I'm resending this patchset.
> 
> ===
> This is v5 patch for qemu-ga to add functions to freeze specific file systems
> mounted in a guest.
> 
> Changes since v4:
>  - PATCH 2: fix coding styles (spaces around operators)
> make decode_mntname() more generic
> rename functions to avoid leading '__'
> improve compatibility with older Linux
>  - PATCH 3 (new in v5): disable unsupported commands by default
>  (v4: http://lists.gnu.org/archive/html/qemu-devel/2014-06/msg01357.html)


Thanks! Applied to qga tree:

  https://github.com/mdroth/qemu/commits/qga

> 
> ---
> Tomoki Sekiyama (3):
>   qga: Add guest-fsfreeze-freeze-list command
>   qga: Add guest-get-fsinfo command
>   qga: Disable unsupported commands by default
> 
> 
>  qga/commands-posix.c   |  508 
> 
>  qga/commands-win32.c   |   47 
>  qga/guest-agent-core.h |1 
>  qga/main.c |1 
>  qga/qapi-schema.json   |   96 +
>  5 files changed, 650 insertions(+), 3 deletions(-)
> 
> -- 
> Regards,
> Tomoki Sekiyama




Re: [Qemu-devel] [000/108] Patch Round-up for stable 2.0.1, freeze on 2014-08-12

2014-08-07 Thread Eric Blake
On 08/06/2014 02:38 PM, Michael Roth wrote:
> Hi everyone,
> 
> The following new patches are queued for QEMU stable v2.0.1:
> 
>   https://github.com/mdroth/qemu/commits/stable-2.0-staging
> 
> The release is planned for 2014-08-15:
> 
>   http://wiki.qemu.org/Planning/2.0
> 
> Please respond here or CC qemu-sta...@nongnu.org on any patches you
> think should be included in the release.
> 
> Due to delays, this is the final planned release for the 2.0.0 series.
> We will return to the standard 2-release cycle for 2.1 (one midway
> during 2.2 development cycle, one immediately following 2.2 release)
> 
> Testing/feedback is greatly appreciated.

Another useful one to avoid a segfault during drive-mirror (possibly
more related patches, as I know Kevin did several qiov cleanups, but at
least this one was easy for me to hit in testing):

Kevin Wolf
5a0f6fd5 mirror: Fix qiov size for short requests

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [000/108] Patch Round-up for stable 2.0.1, freeze on 2014-08-12

2014-08-07 Thread Eric Blake
On 08/07/2014 03:10 PM, Peter Maydell wrote:
> On 7 August 2014 21:55, Eric Blake  wrote:
>> Turns out to be caused by leftovers, from trying an incremental build in
>> the same tree where I had 2.1 object files.  Maybe the makefiles can be
>> improved to deal gracefully with this case, but as a clean build didn't
>> suffer from the problem, it's not a showstopper.
> 
> That kind of 'deal with changes across time' robustness is
> difficult, I think. At any rate we don't deal with it at all well
> in many different aspects of our build system. We don't
> even guarantee that a make clean/distclean will fix things...

Yeah, I just have to get into a better habit of rebuilding the world
when switching across drastically different branches (or maintaining
parallel build trees, or ...).  I'm not asking for an instant solution,
because I know firsthand how hard it can be :)

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [000/108] Patch Round-up for stable 2.0.1, freeze on 2014-08-12

2014-08-07 Thread Peter Maydell
On 7 August 2014 21:55, Eric Blake  wrote:
> Turns out to be caused by leftovers, from trying an incremental build in
> the same tree where I had 2.1 object files.  Maybe the makefiles can be
> improved to deal gracefully with this case, but as a clean build didn't
> suffer from the problem, it's not a showstopper.

That kind of 'deal with changes across time' robustness is
difficult, I think. At any rate we don't deal with it at all well
in many different aspects of our build system. We don't
even guarantee that a make clean/distclean will fix things...

thanks
-- PMM



Re: [Qemu-devel] [PATCH 0/3] qcow2: Prevent corruption-related crashes

2014-08-07 Thread Eric Blake
On 08/07/2014 02:47 PM, Max Reitz wrote:
> The first two patches in this series address
> https://bugs.launchpad.net/qemu/+bug/1349972.
> 
> For the third patch I found it hard to write an appropriate test case
> (it would have to make qemu-img check repair some leaks but induce the
> corruption prevention at the same time). One can use the test image from
> the bug report above, set the refcount block offset to 0 and that works.
> However, the patch is simple enough that no test should be necessary.

Series: Reviewed-by: Eric Blake 

> 
> 
> Max Reitz (3):
>   qcow2: Catch !*host_offset for data allocation
>   iotests: Add test for image header overlap
>   block: Catch !bs->drv in bdrv_check()
> 
>  block.c|  3 +++
>  block/qcow2-cluster.c  | 11 +++
>  tests/qemu-iotests/060 |  9 +
>  tests/qemu-iotests/060.out |  8 
>  4 files changed, 31 insertions(+)
> 

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [000/108] Patch Round-up for stable 2.0.1, freeze on 2014-08-12

2014-08-07 Thread Eric Blake
On 08/07/2014 02:23 PM, Eric Blake wrote:

>>
>> I tried to compile on Fedora 20, but had to backport this to get it to work:
>>
>> Luiz Capitulino
>> a49db98d fpu: softfloat: drop INLINE macro
> 
> Oops, spoke too soon.  I hit another build failure - anyone recognize
> this, or which commit to backport?
> 
> make[1]: *** No rule to make target
> `/home/eblake/qemu/hw/i386/ssdt-mem.dsl', needed by
> `hw/i386/ssdt-mem.hex'.  Stop.
> make: *** [subdir-x86_64-softmmu] Error 2

Turns out to be caused by leftovers, from trying an incremental build in
the same tree where I had 2.1 object files.  Maybe the makefiles can be
improved to deal gracefully with this case, but as a clean build didn't
suffer from the problem, it's not a showstopper.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature


[Qemu-devel] [PATCH 2/3] iotests: Add test for image header overlap

2014-08-07 Thread Max Reitz
Add a test for an image with an unallocated image header; instead of an
assertion, this should result in the image being marked corrupt.

Signed-off-by: Max Reitz 
---
 tests/qemu-iotests/060 | 9 +
 tests/qemu-iotests/060.out | 8 
 2 files changed, 17 insertions(+)

diff --git a/tests/qemu-iotests/060 b/tests/qemu-iotests/060
index 3cffc12..830386f 100755
--- a/tests/qemu-iotests/060
+++ b/tests/qemu-iotests/060
@@ -164,6 +164,15 @@ wait_break 0
 write 64k 64k
 resume 0" | $QEMU_IO | _filter_qemu_io
 
+echo
+echo "=== Testing unallocated image header ==="
+echo
+_make_test_img 64M
+# Create L1/L2
+$QEMU_IO -c "$OPEN_RW" -c "write 0 64k" | _filter_qemu_io
+poke_file "$TEST_IMG" "$rb_offset" "\x00\x00"
+$QEMU_IO -c "$OPEN_RW" -c "write 64k 64k" | _filter_qemu_io
+
 # success, all done
 echo "*** done"
 rm -f $seq.full
diff --git a/tests/qemu-iotests/060.out b/tests/qemu-iotests/060.out
index a517948..c27c952 100644
--- a/tests/qemu-iotests/060.out
+++ b/tests/qemu-iotests/060.out
@@ -93,4 +93,12 @@ blkdebug: Suspended request '0'
 write failed: Input/output error
 blkdebug: Resuming request '0'
 aio_write failed: No medium found
+
+=== Testing unallocated image header ===
+
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864 
+wrote 65536/65536 bytes at offset 0
+64 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+qcow2: Preventing invalid write on metadata (overlaps with qcow2_header); 
image marked as corrupt.
+write failed: Input/output error
 *** done
-- 
2.0.3




[Qemu-devel] [PATCH 1/3] qcow2: Catch !*host_offset for data allocation

2014-08-07 Thread Max Reitz
qcow2_alloc_cluster_offset() uses host_offset == 0 as "no preferred
offset" for the (data) cluster range to be allocated. However, this
offset is actually valid and may be allocated on images with a corrupted
refcount table or first refcount block.

In this case, the corruption prevention should normally catch that
write anyway (because it would overwrite the image header). But since 0
is a special value here, the function assumes that nothing has been
allocated at all which it asserts against.

Because this condition is not qemu's fault but rather that of a broken
image, it shouldn't throw an assertion but rather mark the image corrupt
and show an appropriate message, which this patch does by calling the
corruption check earlier than it would be called normally (before the
assertion).

Signed-off-by: Max Reitz 
---
 block/qcow2-cluster.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 4208dc0..c6af456 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -1106,6 +1106,17 @@ static int handle_alloc(BlockDriverState *bs, uint64_t 
guest_offset,
 return 0;
 }
 
+/* !*host_offset would overwrite the image header and is reserved for "no
+ * host offset preferred". If 0 was a valid host offset, it'd trigger the
+ * following overlap check; do that now to avoid having an invalid value in
+ * *host_offset. */
+if (!alloc_cluster_offset) {
+ret = qcow2_pre_write_overlap_check(bs, 0, alloc_cluster_offset,
+nb_clusters * s->cluster_size);
+assert(ret < 0);
+goto fail;
+}
+
 /*
  * Save info needed for meta data update.
  *
-- 
2.0.3




[Qemu-devel] [PATCH 0/3] qcow2: Prevent corruption-related crashes

2014-08-07 Thread Max Reitz
The first two patches in this series address
https://bugs.launchpad.net/qemu/+bug/1349972.

For the third patch I found it hard to write an appropriate test case
(it would have to make qemu-img check repair some leaks but induce the
corruption prevention at the same time). One can use the test image from
the bug report above, set the refcount block offset to 0 and that works.
However, the patch is simple enough that no test should be necessary.


Max Reitz (3):
  qcow2: Catch !*host_offset for data allocation
  iotests: Add test for image header overlap
  block: Catch !bs->drv in bdrv_check()

 block.c|  3 +++
 block/qcow2-cluster.c  | 11 +++
 tests/qemu-iotests/060 |  9 +
 tests/qemu-iotests/060.out |  8 
 4 files changed, 31 insertions(+)

-- 
2.0.3




[Qemu-devel] [PATCH 3/3] block: Catch !bs->drv in bdrv_check()

2014-08-07 Thread Max Reitz
qemu-img check calls bdrv_check() twice if the first run repaired some
inconsistencies. If the first run however again triggered corruption
prevention (on qcow2) due to very bad inconsistencies, bs->drv may be
NULL afterwards. Thus, bdrv_check() should check whether bs->drv is set.

Signed-off-by: Max Reitz 
---
 block.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/block.c b/block.c
index 8cf519b..2b470d8 100644
--- a/block.c
+++ b/block.c
@@ -2203,6 +2203,9 @@ bool bdrv_dev_is_medium_locked(BlockDriverState *bs)
  */
 int bdrv_check(BlockDriverState *bs, BdrvCheckResult *res, BdrvCheckMode fix)
 {
+if (bs->drv == NULL) {
+return -ENOMEDIUM;
+}
 if (bs->drv->bdrv_check == NULL) {
 return -ENOTSUP;
 }
-- 
2.0.3




Re: [Qemu-devel] [PATCH] arm/virt: Use PSCI v0.2 function IDs in the DT when KVM uses PSCI v0.2

2014-08-07 Thread Christoffer Dall
On Thu, Aug 07, 2014 at 07:06:12PM +0100, Peter Maydell wrote:
> On 7 August 2014 17:30, Christoffer Dall  wrote:
> > The current code supplies the PSCI v0.1 funciton IDs in the DT even when
> 
> "function"
> 
> > KVM uses PSCI v0.2.
> >
> > This will break guest kernels that only support PSCI v0.1 as they will
> > use the IDs provided in the DT.  Guest kernels with PSCI v0.2 support
> > are not affected by this patch, because they ignore the function IDs in
> > the device tree and rely on the architecture definition.
> >
> > Define QEMU versions of the constants and check that they correspond to
> > the Linux defines on Linux build hosts.  After this patch, both guest
> > kernels with PSCI v0.1 support and guest kernels with PSCI v0.2 should
> > work.
> >
> > Tested on TC2 for 32-bit and APM Mustang for 64-bit (aarch64 guest
> > only).  Both cases tested with 3.14 and linus/master and verified I
> > could bring up 2 cpus with both guest kernels.
> >
> > Signed-off-by: Christoffer Dall 
> > ---
> >  hw/arm/virt.c   | 25 ++---
> >  target-arm/kvm-consts.h | 23 +++
> >  2 files changed, 45 insertions(+), 3 deletions(-)
> >
> > diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> > index ba94298..4e882bc 100644
> > --- a/hw/arm/virt.c
> > +++ b/hw/arm/virt.c
> > @@ -194,20 +194,39 @@ static void fdt_add_psci_node(const VirtBoardInfo 
> > *vbi)
> >
> >  /* No PSCI for TCG yet */
> >  if (kvm_enabled()) {
> > +uint32_t cpu_off_fn;
> > +uint32_t cpu_on_fn;
> > +uint32_t migrate_fn;
> > +
> >  qemu_fdt_add_subnode(fdt, "/psci");
> >  if (armcpu->psci_version == 2) {
> >  const char comp[] = "arm,psci-0.2\0arm,psci";
> >  qemu_fdt_setprop(fdt, "/psci", "compatible", comp, 
> > sizeof(comp));
> > +
> > +if (arm_feature(&armcpu->env, ARM_FEATURE_AARCH64)) {
> > +cpu_off_fn = QEMU_PSCI_0_2_FN_CPU_OFF;
> > +cpu_on_fn = QEMU_PSCI_0_2_FN64_CPU_ON;
> > +migrate_fn = QEMU_PSCI_0_2_FN64_MIGRATE;
> > +} else {
> > +cpu_off_fn = QEMU_PSCI_0_2_FN_CPU_OFF;
> > +cpu_on_fn = QEMU_PSCI_0_2_FN_CPU_ON;
> > +migrate_fn = QEMU_PSCI_0_2_FN_MIGRATE;
> > +}
> >  } else {
> >  qemu_fdt_setprop_string(fdt, "/psci", "compatible", 
> > "arm,psci");
> > +
> > +cpu_off_fn = PSCI_FN_CPU_OFF;
> > +cpu_on_fn = PSCI_FN_CPU_ON;
> > +migrate_fn = PSCI_FN_MIGRATE;
> 
> 
> I see that linux/psci.h defines PSCI_0_2_FN64_CPU_SUSPEND
> and PSCI_0_2_FN_CPU_SUSPEND, neither of which are
> the same as PSCI_FN_CPU_SUSPEND. Shouldn't we be
> using the 0.2 values for SUSPEND too?

we should, I'm an idiot.

> 
> (Sharing the CPU_OFF value is correct by the spec I see,
> but it would probably be better outside the if() and with a comment,
> since it otherwise looks a lot like an error.)

good point, fixed for v2.  Will give it a quick test tomorrow and then
send it out.

-Christoffer

> 
> >  }
> >
> >  qemu_fdt_setprop_string(fdt, "/psci", "method", "hvc");
> >  qemu_fdt_setprop_cell(fdt, "/psci", "cpu_suspend",
> >PSCI_FN_CPU_SUSPEND);
> > -qemu_fdt_setprop_cell(fdt, "/psci", "cpu_off", PSCI_FN_CPU_OFF);
> > -qemu_fdt_setprop_cell(fdt, "/psci", "cpu_on", PSCI_FN_CPU_ON);
> > -qemu_fdt_setprop_cell(fdt, "/psci", "migrate", PSCI_FN_MIGRATE);
> > +
> > +qemu_fdt_setprop_cell(fdt, "/psci", "cpu_off", cpu_off_fn);
> > +qemu_fdt_setprop_cell(fdt, "/psci", "cpu_on", cpu_on_fn);
> > +qemu_fdt_setprop_cell(fdt, "/psci", "migrate", migrate_fn);
> >  }
> >  }
> >
> > diff --git a/target-arm/kvm-consts.h b/target-arm/kvm-consts.h
> > index 6009a33..a8df135 100644
> > --- a/target-arm/kvm-consts.h
> > +++ b/target-arm/kvm-consts.h
> > @@ -17,6 +17,7 @@
> >  #ifdef CONFIG_KVM
> >  #include "qemu/compiler.h"
> >  #include 
> > +#include 
> >
> >  #define MISMATCH_CHECK(X, Y) QEMU_BUILD_BUG_ON(X != Y)
> >
> > @@ -50,6 +51,28 @@ MISMATCH_CHECK(PSCI_FN_CPU_OFF, KVM_PSCI_FN_CPU_OFF)
> >  MISMATCH_CHECK(PSCI_FN_CPU_ON, KVM_PSCI_FN_CPU_ON)
> >  MISMATCH_CHECK(PSCI_FN_MIGRATE, KVM_PSCI_FN_MIGRATE)
> >
> > +#define QEMU_PSCI_0_2_FN_BASE 0x8400
> > +#define QEMU_PSCI_0_2_FN(n) (QEMU_PSCI_0_2_FN_BASE + (n))
> > +
> > +#define QEMU_PSCI_0_2_64BIT 0x4000
> > +#define QEMU_PSCI_0_2_FN64_BASE \
> > +(QEMU_PSCI_0_2_FN_BASE + QEMU_PSCI_0_2_64BIT)
> > +#define QEMU_PSCI_0_2_FN64(n) (QEMU_PSCI_0_2_FN64_BASE + (n))
> > +
> > +#define QEMU_PSCI_0_2_FN_CPU_OFF QEMU_PSCI_0_2_FN(2)
> > +#define QEMU_PSCI_0_2_FN_CPU_ON QEMU_PSCI_0_2_FN(3)
> > +#define QEMU_PSCI_0_2_FN_MIGRATE QEMU_PSCI_0_2_FN(5)
> > +
> > +#define QEMU_PSCI_0_2_FN64_CPU_OFF QEMU_PSCI_0_2_FN64(2)
> > +#define QEMU_PSCI_0_2_FN64_CPU_ON QEMU_PSCI_0_2_FN64(3)
> > +#define QEMU_PSCI_0_2_FN64_MIGRATE QEMU_PSCI_0_2_FN6

Re: [Qemu-devel] [000/108] Patch Round-up for stable 2.0.1, freeze on 2014-08-12

2014-08-07 Thread Eric Blake
On 08/07/2014 02:21 PM, Eric Blake wrote:
> On 08/06/2014 02:38 PM, Michael Roth wrote:
>> Hi everyone,
>>
>> The following new patches are queued for QEMU stable v2.0.1:
>>
>>   https://github.com/mdroth/qemu/commits/stable-2.0-staging
>>

>> Testing/feedback is greatly appreciated.
>>
> 
> I tried to compile on Fedora 20, but had to backport this to get it to work:
> 
> Luiz Capitulino
> a49db98d fpu: softfloat: drop INLINE macro

Oops, spoke too soon.  I hit another build failure - anyone recognize
this, or which commit to backport?

make[1]: *** No rule to make target
`/home/eblake/qemu/hw/i386/ssdt-mem.dsl', needed by
`hw/i386/ssdt-mem.hex'.  Stop.
make: *** [subdir-x86_64-softmmu] Error 2

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [000/108] Patch Round-up for stable 2.0.1, freeze on 2014-08-12

2014-08-07 Thread Eric Blake
On 08/06/2014 02:38 PM, Michael Roth wrote:
> Hi everyone,
> 
> The following new patches are queued for QEMU stable v2.0.1:
> 
>   https://github.com/mdroth/qemu/commits/stable-2.0-staging
> 
> The release is planned for 2014-08-15:
> 
>   http://wiki.qemu.org/Planning/2.0
> 
> Please respond here or CC qemu-sta...@nongnu.org on any patches you
> think should be included in the release.
> 
> Due to delays, this is the final planned release for the 2.0.0 series.
> We will return to the standard 2-release cycle for 2.1 (one midway
> during 2.2 development cycle, one immediately following 2.2 release)
> 
> Testing/feedback is greatly appreciated.
> 

I tried to compile on Fedora 20, but had to backport this to get it to work:

Luiz Capitulino
a49db98d fpu: softfloat: drop INLINE macro

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH] arm/virt: Use PSCI v0.2 function IDs in the DT when KVM uses PSCI v0.2

2014-08-07 Thread Zi Shen Lim
On Thu, Aug 7, 2014 at 9:30 AM, Christoffer Dall
 wrote:
>
> The current code supplies the PSCI v0.1 funciton IDs in the DT even when
> KVM uses PSCI v0.2.
>
> This will break guest kernels that only support PSCI v0.1 as they will
> use the IDs provided in the DT.  Guest kernels with PSCI v0.2 support
> are not affected by this patch, because they ignore the function IDs in
> the device tree and rely on the architecture definition.
>
> Define QEMU versions of the constants and check that they correspond to
> the Linux defines on Linux build hosts.  After this patch, both guest
> kernels with PSCI v0.1 support and guest kernels with PSCI v0.2 should
> work.
>
> Tested on TC2 for 32-bit and APM Mustang for 64-bit (aarch64 guest
> only).  Both cases tested with 3.14 and linus/master and verified I
> could bring up 2 cpus with both guest kernels.
>
> Signed-off-by: Christoffer Dall 
> ---
>  hw/arm/virt.c   | 25 ++---
>  target-arm/kvm-consts.h | 23 +++
>  2 files changed, 45 insertions(+), 3 deletions(-)
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index ba94298..4e882bc 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -194,20 +194,39 @@ static void fdt_add_psci_node(const VirtBoardInfo *vbi)
>
>  /* No PSCI for TCG yet */
>  if (kvm_enabled()) {
> +uint32_t cpu_off_fn;
> +uint32_t cpu_on_fn;
> +uint32_t migrate_fn;
> +
>  qemu_fdt_add_subnode(fdt, "/psci");
>  if (armcpu->psci_version == 2) {
>  const char comp[] = "arm,psci-0.2\0arm,psci";
>  qemu_fdt_setprop(fdt, "/psci", "compatible", comp, sizeof(comp));
> +
> +if (arm_feature(&armcpu->env, ARM_FEATURE_AARCH64)) {
> +cpu_off_fn = QEMU_PSCI_0_2_FN_CPU_OFF;

Should this be QEMU_PSCI_0_2_FN64_CPU_OFF instead?

>
> +cpu_on_fn = QEMU_PSCI_0_2_FN64_CPU_ON;
> +migrate_fn = QEMU_PSCI_0_2_FN64_MIGRATE;
> +} else {
> +cpu_off_fn = QEMU_PSCI_0_2_FN_CPU_OFF;
> +cpu_on_fn = QEMU_PSCI_0_2_FN_CPU_ON;
> +migrate_fn = QEMU_PSCI_0_2_FN_MIGRATE;
> +}





Re: [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm

2014-08-07 Thread Serge E. Hallyn
Quoting Alex Bligh (a...@alex.org.uk):
> Serge,
> 
> On 7 Aug 2014, at 03:50, Serge Hallyn  wrote:
> 
> > This worked for me when migrating by hand.  I'm trying to make it work
> > through libvirt, using the following patch.  (So whether to have
> > pc-1.0 be treated as qemu's or qemu-kvm's pc-1.0 is specifed using a
> > boolean in /etc/libvirt/qemu.conf)  Qemu starts with decent
> > looking args, but for some reason the the migration is failing -
> > still looking through the logfile to figure out why.
> 
> Are you using exactly the same arguments by hand and with libvirt?
> 
> Also, on reflection, given one of the changes between 1.0 and 2.0
> is ACPI, I should probably have done some testing with an ACPI
> enabled image, rather than just cirros (which not ACPI enabled);
> any chance this is ACPI related?

A-ha, acpi wasn't a problem.  I actually had a general migration
problem even when coming from other utopic hosts.  With that fixed,
I've got successful migration from qemu-kvm 1.0 in precise to
a utopic host.

-serge



Re: [Qemu-devel] [PATCH v4 00/21] block: Handle failure for potentially large allocations

2014-08-07 Thread Max Reitz

On 24.06.2014 17:36, Kevin Wolf wrote:

A not too small part of the recent CVEs were DoS scenarios by letting
qemu abort with too large memory allocations. We generally "fixed" these
cases by setting some limits on values read from image files that
influence the size of allocations.

Because we still need to allow reading large images, this works only to
a certain degree and we still can get fairly large allocations, which
are not unthinkable to fail on some machines.

This series converts potentially large allocations to g_try_malloc() and
friends and handles failure gracefully e.g. by returning -ENOMEM. This
may cause hot-plug of a new disk or individual requests to fail, but the
VM as a whole can keep running.


Ping – is there anything missing here? This series does contain one 
patch from me, so I'm naturally interested in seeing this series getting 
merged. ;-)


Max



Re: [Qemu-devel] [PATCH] arm/virt: Use PSCI v0.2 function IDs in the DT when KVM uses PSCI v0.2

2014-08-07 Thread Peter Maydell
On 7 August 2014 17:30, Christoffer Dall  wrote:
> The current code supplies the PSCI v0.1 funciton IDs in the DT even when

"function"

> KVM uses PSCI v0.2.
>
> This will break guest kernels that only support PSCI v0.1 as they will
> use the IDs provided in the DT.  Guest kernels with PSCI v0.2 support
> are not affected by this patch, because they ignore the function IDs in
> the device tree and rely on the architecture definition.
>
> Define QEMU versions of the constants and check that they correspond to
> the Linux defines on Linux build hosts.  After this patch, both guest
> kernels with PSCI v0.1 support and guest kernels with PSCI v0.2 should
> work.
>
> Tested on TC2 for 32-bit and APM Mustang for 64-bit (aarch64 guest
> only).  Both cases tested with 3.14 and linus/master and verified I
> could bring up 2 cpus with both guest kernels.
>
> Signed-off-by: Christoffer Dall 
> ---
>  hw/arm/virt.c   | 25 ++---
>  target-arm/kvm-consts.h | 23 +++
>  2 files changed, 45 insertions(+), 3 deletions(-)
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index ba94298..4e882bc 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -194,20 +194,39 @@ static void fdt_add_psci_node(const VirtBoardInfo *vbi)
>
>  /* No PSCI for TCG yet */
>  if (kvm_enabled()) {
> +uint32_t cpu_off_fn;
> +uint32_t cpu_on_fn;
> +uint32_t migrate_fn;
> +
>  qemu_fdt_add_subnode(fdt, "/psci");
>  if (armcpu->psci_version == 2) {
>  const char comp[] = "arm,psci-0.2\0arm,psci";
>  qemu_fdt_setprop(fdt, "/psci", "compatible", comp, sizeof(comp));
> +
> +if (arm_feature(&armcpu->env, ARM_FEATURE_AARCH64)) {
> +cpu_off_fn = QEMU_PSCI_0_2_FN_CPU_OFF;
> +cpu_on_fn = QEMU_PSCI_0_2_FN64_CPU_ON;
> +migrate_fn = QEMU_PSCI_0_2_FN64_MIGRATE;
> +} else {
> +cpu_off_fn = QEMU_PSCI_0_2_FN_CPU_OFF;
> +cpu_on_fn = QEMU_PSCI_0_2_FN_CPU_ON;
> +migrate_fn = QEMU_PSCI_0_2_FN_MIGRATE;
> +}
>  } else {
>  qemu_fdt_setprop_string(fdt, "/psci", "compatible", "arm,psci");
> +
> +cpu_off_fn = PSCI_FN_CPU_OFF;
> +cpu_on_fn = PSCI_FN_CPU_ON;
> +migrate_fn = PSCI_FN_MIGRATE;


I see that linux/psci.h defines PSCI_0_2_FN64_CPU_SUSPEND
and PSCI_0_2_FN_CPU_SUSPEND, neither of which are
the same as PSCI_FN_CPU_SUSPEND. Shouldn't we be
using the 0.2 values for SUSPEND too?

(Sharing the CPU_OFF value is correct by the spec I see,
but it would probably be better outside the if() and with a comment,
since it otherwise looks a lot like an error.)

>  }
>
>  qemu_fdt_setprop_string(fdt, "/psci", "method", "hvc");
>  qemu_fdt_setprop_cell(fdt, "/psci", "cpu_suspend",
>PSCI_FN_CPU_SUSPEND);
> -qemu_fdt_setprop_cell(fdt, "/psci", "cpu_off", PSCI_FN_CPU_OFF);
> -qemu_fdt_setprop_cell(fdt, "/psci", "cpu_on", PSCI_FN_CPU_ON);
> -qemu_fdt_setprop_cell(fdt, "/psci", "migrate", PSCI_FN_MIGRATE);
> +
> +qemu_fdt_setprop_cell(fdt, "/psci", "cpu_off", cpu_off_fn);
> +qemu_fdt_setprop_cell(fdt, "/psci", "cpu_on", cpu_on_fn);
> +qemu_fdt_setprop_cell(fdt, "/psci", "migrate", migrate_fn);
>  }
>  }
>
> diff --git a/target-arm/kvm-consts.h b/target-arm/kvm-consts.h
> index 6009a33..a8df135 100644
> --- a/target-arm/kvm-consts.h
> +++ b/target-arm/kvm-consts.h
> @@ -17,6 +17,7 @@
>  #ifdef CONFIG_KVM
>  #include "qemu/compiler.h"
>  #include 
> +#include 
>
>  #define MISMATCH_CHECK(X, Y) QEMU_BUILD_BUG_ON(X != Y)
>
> @@ -50,6 +51,28 @@ MISMATCH_CHECK(PSCI_FN_CPU_OFF, KVM_PSCI_FN_CPU_OFF)
>  MISMATCH_CHECK(PSCI_FN_CPU_ON, KVM_PSCI_FN_CPU_ON)
>  MISMATCH_CHECK(PSCI_FN_MIGRATE, KVM_PSCI_FN_MIGRATE)
>
> +#define QEMU_PSCI_0_2_FN_BASE 0x8400
> +#define QEMU_PSCI_0_2_FN(n) (QEMU_PSCI_0_2_FN_BASE + (n))
> +
> +#define QEMU_PSCI_0_2_64BIT 0x4000
> +#define QEMU_PSCI_0_2_FN64_BASE \
> +(QEMU_PSCI_0_2_FN_BASE + QEMU_PSCI_0_2_64BIT)
> +#define QEMU_PSCI_0_2_FN64(n) (QEMU_PSCI_0_2_FN64_BASE + (n))
> +
> +#define QEMU_PSCI_0_2_FN_CPU_OFF QEMU_PSCI_0_2_FN(2)
> +#define QEMU_PSCI_0_2_FN_CPU_ON QEMU_PSCI_0_2_FN(3)
> +#define QEMU_PSCI_0_2_FN_MIGRATE QEMU_PSCI_0_2_FN(5)
> +
> +#define QEMU_PSCI_0_2_FN64_CPU_OFF QEMU_PSCI_0_2_FN64(2)
> +#define QEMU_PSCI_0_2_FN64_CPU_ON QEMU_PSCI_0_2_FN64(3)
> +#define QEMU_PSCI_0_2_FN64_MIGRATE QEMU_PSCI_0_2_FN64(5)
> +
> +MISMATCH_CHECK(QEMU_PSCI_0_2_FN_CPU_OFF, PSCI_0_2_FN_CPU_OFF)
> +MISMATCH_CHECK(QEMU_PSCI_0_2_FN_CPU_ON, PSCI_0_2_FN_CPU_ON)
> +MISMATCH_CHECK(QEMU_PSCI_0_2_FN_MIGRATE, PSCI_0_2_FN_MIGRATE)
> +MISMATCH_CHECK(QEMU_PSCI_0_2_FN64_CPU_ON, PSCI_0_2_FN64_CPU_ON)
> +MISMATCH_CHECK(QEMU_PSCI_0_2_FN64_MIGRATE, PSCI_0_2_FN64_MIGRATE)
> +

This now clashes awkwardly with the way we previously had
PSCI_* for the QEMU versions and KVM

Re: [Qemu-devel] [PATCH v3 07/10] linux-user: check return value of malloc()

2014-08-07 Thread Richard Henderson
On 08/06/2014 10:01 PM, zhanghailiang wrote:
>  if (!lock_user_struct(VERIFY_READ, target_mb, msgp, 0))
>  return -TARGET_EFAULT;
>  host_mb = malloc(msgsz+sizeof(long));
> +if (!host_mb) {
> +return -TARGET_ENOMEM;
> +}

lock_user allocates memory; returning from the middle leaks it.


r~



[Qemu-devel] [PATCH] arm/virt: Use PSCI v0.2 function IDs in the DT when KVM uses PSCI v0.2

2014-08-07 Thread Christoffer Dall
The current code supplies the PSCI v0.1 funciton IDs in the DT even when
KVM uses PSCI v0.2.

This will break guest kernels that only support PSCI v0.1 as they will
use the IDs provided in the DT.  Guest kernels with PSCI v0.2 support
are not affected by this patch, because they ignore the function IDs in
the device tree and rely on the architecture definition.

Define QEMU versions of the constants and check that they correspond to
the Linux defines on Linux build hosts.  After this patch, both guest
kernels with PSCI v0.1 support and guest kernels with PSCI v0.2 should
work.

Tested on TC2 for 32-bit and APM Mustang for 64-bit (aarch64 guest
only).  Both cases tested with 3.14 and linus/master and verified I
could bring up 2 cpus with both guest kernels.

Signed-off-by: Christoffer Dall 
---
 hw/arm/virt.c   | 25 ++---
 target-arm/kvm-consts.h | 23 +++
 2 files changed, 45 insertions(+), 3 deletions(-)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index ba94298..4e882bc 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -194,20 +194,39 @@ static void fdt_add_psci_node(const VirtBoardInfo *vbi)
 
 /* No PSCI for TCG yet */
 if (kvm_enabled()) {
+uint32_t cpu_off_fn;
+uint32_t cpu_on_fn;
+uint32_t migrate_fn;
+
 qemu_fdt_add_subnode(fdt, "/psci");
 if (armcpu->psci_version == 2) {
 const char comp[] = "arm,psci-0.2\0arm,psci";
 qemu_fdt_setprop(fdt, "/psci", "compatible", comp, sizeof(comp));
+
+if (arm_feature(&armcpu->env, ARM_FEATURE_AARCH64)) {
+cpu_off_fn = QEMU_PSCI_0_2_FN_CPU_OFF;
+cpu_on_fn = QEMU_PSCI_0_2_FN64_CPU_ON;
+migrate_fn = QEMU_PSCI_0_2_FN64_MIGRATE;
+} else {
+cpu_off_fn = QEMU_PSCI_0_2_FN_CPU_OFF;
+cpu_on_fn = QEMU_PSCI_0_2_FN_CPU_ON;
+migrate_fn = QEMU_PSCI_0_2_FN_MIGRATE;
+}
 } else {
 qemu_fdt_setprop_string(fdt, "/psci", "compatible", "arm,psci");
+
+cpu_off_fn = PSCI_FN_CPU_OFF;
+cpu_on_fn = PSCI_FN_CPU_ON;
+migrate_fn = PSCI_FN_MIGRATE;
 }
 
 qemu_fdt_setprop_string(fdt, "/psci", "method", "hvc");
 qemu_fdt_setprop_cell(fdt, "/psci", "cpu_suspend",
   PSCI_FN_CPU_SUSPEND);
-qemu_fdt_setprop_cell(fdt, "/psci", "cpu_off", PSCI_FN_CPU_OFF);
-qemu_fdt_setprop_cell(fdt, "/psci", "cpu_on", PSCI_FN_CPU_ON);
-qemu_fdt_setprop_cell(fdt, "/psci", "migrate", PSCI_FN_MIGRATE);
+
+qemu_fdt_setprop_cell(fdt, "/psci", "cpu_off", cpu_off_fn);
+qemu_fdt_setprop_cell(fdt, "/psci", "cpu_on", cpu_on_fn);
+qemu_fdt_setprop_cell(fdt, "/psci", "migrate", migrate_fn);
 }
 }
 
diff --git a/target-arm/kvm-consts.h b/target-arm/kvm-consts.h
index 6009a33..a8df135 100644
--- a/target-arm/kvm-consts.h
+++ b/target-arm/kvm-consts.h
@@ -17,6 +17,7 @@
 #ifdef CONFIG_KVM
 #include "qemu/compiler.h"
 #include 
+#include 
 
 #define MISMATCH_CHECK(X, Y) QEMU_BUILD_BUG_ON(X != Y)
 
@@ -50,6 +51,28 @@ MISMATCH_CHECK(PSCI_FN_CPU_OFF, KVM_PSCI_FN_CPU_OFF)
 MISMATCH_CHECK(PSCI_FN_CPU_ON, KVM_PSCI_FN_CPU_ON)
 MISMATCH_CHECK(PSCI_FN_MIGRATE, KVM_PSCI_FN_MIGRATE)
 
+#define QEMU_PSCI_0_2_FN_BASE 0x8400
+#define QEMU_PSCI_0_2_FN(n) (QEMU_PSCI_0_2_FN_BASE + (n))
+
+#define QEMU_PSCI_0_2_64BIT 0x4000
+#define QEMU_PSCI_0_2_FN64_BASE \
+(QEMU_PSCI_0_2_FN_BASE + QEMU_PSCI_0_2_64BIT)
+#define QEMU_PSCI_0_2_FN64(n) (QEMU_PSCI_0_2_FN64_BASE + (n))
+
+#define QEMU_PSCI_0_2_FN_CPU_OFF QEMU_PSCI_0_2_FN(2)
+#define QEMU_PSCI_0_2_FN_CPU_ON QEMU_PSCI_0_2_FN(3)
+#define QEMU_PSCI_0_2_FN_MIGRATE QEMU_PSCI_0_2_FN(5)
+
+#define QEMU_PSCI_0_2_FN64_CPU_OFF QEMU_PSCI_0_2_FN64(2)
+#define QEMU_PSCI_0_2_FN64_CPU_ON QEMU_PSCI_0_2_FN64(3)
+#define QEMU_PSCI_0_2_FN64_MIGRATE QEMU_PSCI_0_2_FN64(5)
+
+MISMATCH_CHECK(QEMU_PSCI_0_2_FN_CPU_OFF, PSCI_0_2_FN_CPU_OFF)
+MISMATCH_CHECK(QEMU_PSCI_0_2_FN_CPU_ON, PSCI_0_2_FN_CPU_ON)
+MISMATCH_CHECK(QEMU_PSCI_0_2_FN_MIGRATE, PSCI_0_2_FN_MIGRATE)
+MISMATCH_CHECK(QEMU_PSCI_0_2_FN64_CPU_ON, PSCI_0_2_FN64_CPU_ON)
+MISMATCH_CHECK(QEMU_PSCI_0_2_FN64_MIGRATE, PSCI_0_2_FN64_MIGRATE)
+
 /* Note that KVM uses overlapping values for AArch32 and AArch64
  * target CPU numbers. AArch32 targets:
  */
-- 
2.0.0




Re: [Qemu-devel] [000/108] Patch Round-up for stable 2.0.1, freeze on 2014-08-12

2014-08-07 Thread Michael Roth
Quoting Eric Blake (2014-08-07 10:50:41)
> On 08/07/2014 03:19 AM, Michael Roth wrote:
> >>
> >> Libvirt could support active commit against qemu 2.0.1 if you backport
> >> these patches:
> >>
> >> Jeff Cody
> >>   7676e2c597 block: make 'top' argument to block-commit optional
> >>
> >> Fam Zheng
> >>   9e48b02540 mirror: Go through ready -> complete process for 0 len image
> > 
> > Actually ended up needing the following with a few fix-ups:
> > 
> > 7676e2c->98103fa block: make 'top' argument to block-commit optional
> > 8b9a30c->e5f0eb0 qemu-iotests: Test BLOCK_JOB_READY event for 0Kb image 
> > active commit
> > 9e48b02->43ac708 mirror: Go through ready -> complete process for 0 len 
> > image
> > dc71ce4->8e09e20 blockjob: Add block_job_yield()
> > 373df5b->520b341 mirror: Fix resource leak when bdrv_getlength fails
> > 
> > I've gone ahead and pushed them, but please test as we generally don't
> > do features (even backward-compatible ones) for stable, and this wasn't
> > as trivial as I was hoping.
> 
> Yes, I'll test and report back.  However, I don't think this is a

Thanks!

> Yes, I'll test and report back.  However, I don't think this is a
> feature addition, so much as a bug fix for an existing feature (all the
> hard work for active commit was already in 2.0, all that was missing was
> a way for libvirt to introspect that it existed, and some corner case
> bugs with 0-length images).

Well, I think it would be hard to draw the line if you start getting into
things like new command-line options and such, but the distinction does
seem reasonable in this case.

> 
> -- 
> Eric Blake   eblake redhat com+1-919-301-3266
> Libvirt virtualization library http://libvirt.org




[Qemu-devel] [Bug 1353947] Re: Hypervisor with QEMU-2.0/libvirtd 1.2.2 stack when launching VM with CirrOS or Ubuntu 12.04

2014-08-07 Thread Serge Hallyn
Sorry, I'm having trouble following your findings.  Could you please give a new 
table, like
this:

==
GuestOS  | Guestkernel  |  HostOS  | Hostkernel |  qemu version| 
libvirt version  | nic type   | Pass/Fail
==
cirros   | ???  | 12.04| 3.2| 1.0+noroms-0ubuntu13 | 
0.9.8-2ubuntu17  |  intel SR-IOV  | F
==
cirros   | ???  | 12.04| 3.13   | 1.0+noroms-0ubuntu13 | 
0.9.8-2ubuntu17  |  intel SR-IOV  | P
==
(...0
==

Ideally we could determine whether the kernel version is at all related, or 
whether it
is purely tied to qemu version.

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

Title:
  Hypervisor with QEMU-2.0/libvirtd 1.2.2 stack when launching VM with
  CirrOS or Ubuntu 12.04

Status in QEMU:
  New

Bug description:
  The issue observed when running an hypervisor with QEMU 2.0/libvirtd 1.2.2
  The VM network interface is attached to a PCI virtual function (SR-IOV).

  When we ran VM with guest OS CirrOS or Ubuntu 12.04 we observed an hipervisor 
hang shortly after the VM is loaded
  We observed the same issue with Mellanox NIC and with Intel NIC

  We’ve tried few combinations of {GuestOS}X{Hypervisor} and we got the 
following findings:
  When a hypervisor is running QEMU 1.5/libvirtd 1.1.1 - no issue observed
  When a hypervisor is running QEMU 2.0/libvirtd 1.2.2 - CirrOS and Ubuntu 
12.04 guest OSes caused hypervisor hang
  When a hypervisor is running QEMU 2.0/libvirtd 1.2.2 - CentOS 6.4 and Ubuntu 
13.10 - no issue observed

  The problematic guest OSes are with kernel versions ~3.2.y

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



Re: [Qemu-devel] [000/108] Patch Round-up for stable 2.0.1, freeze on 2014-08-12

2014-08-07 Thread Eric Blake
On 08/07/2014 03:19 AM, Michael Roth wrote:
>>
>> Libvirt could support active commit against qemu 2.0.1 if you backport
>> these patches:
>>
>> Jeff Cody
>>   7676e2c597 block: make 'top' argument to block-commit optional
>>
>> Fam Zheng
>>   9e48b02540 mirror: Go through ready -> complete process for 0 len image
> 
> Actually ended up needing the following with a few fix-ups:
> 
> 7676e2c->98103fa block: make 'top' argument to block-commit optional
> 8b9a30c->e5f0eb0 qemu-iotests: Test BLOCK_JOB_READY event for 0Kb image 
> active commit
> 9e48b02->43ac708 mirror: Go through ready -> complete process for 0 len image
> dc71ce4->8e09e20 blockjob: Add block_job_yield()
> 373df5b->520b341 mirror: Fix resource leak when bdrv_getlength fails
> 
> I've gone ahead and pushed them, but please test as we generally don't
> do features (even backward-compatible ones) for stable, and this wasn't
> as trivial as I was hoping.

Yes, I'll test and report back.  However, I don't think this is a
feature addition, so much as a bug fix for an existing feature (all the
hard work for active commit was already in 2.0, all that was missing was
a way for libvirt to introspect that it existed, and some corner case
bugs with 0-length images).

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] aarch64 & gdb: warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml"

2014-08-07 Thread Peter Maydell
On 7 August 2014 16:06, Richard W.M. Jones  wrote:
> On Thu, Aug 07, 2014 at 02:53:33PM +0100, Peter Maydell wrote:
>> I think the biggest difficulty is not the code to actually
>> do the switch but figuring out what the command line
>> UI to request "start in AArch32" ought to be and how that
>> then gets plumbed into the code to do the actual work.
>
> Out of interest, how do you do this on real hardware?

Depends what level you're thinking at. At the absolute
lowest level, the Cortex-A57 for instance has an input
signal that's sampled on reset that indicates whether it
starts in AArch32 or AArch64. (In QEMU terms that would
be a CPU QOM property.) I'd expect that most boards
in practice would just hardwire that, though, since the
first thing that runs is going to be board-specific bootrom
code and having that be multi-width would be pointless
when you can just have the bootrom start EL2 in
AArch32 if it really needs to.

I don't know what the typical boot loader does. For
UEFI the files it boots are PE/COFF so in theory
it could look at the header (but I'm told that at the
moment 64-bit UEFI simply assumes 64-bit kernels).
I think u-boot also currently assumes 64-bit kernels
if it's a 64-bit u-boot.

Basically virtual machines are about the only place
where you'd actually want to run a 32 bit kernel if
your hardware supports 64 bit. So the only precedent
we have here is kvmtool, which currently requires
you to pass a command line argument if you want
your 64-bit guest CPU to start in AArch32.

thanks
-- PMM



Re: [Qemu-devel] [PATCH v2 4/4] parallels: 2TB+ parallels images support

2014-08-07 Thread Denis V. Lunev

On 07/08/14 19:22, Denis V. Lunev wrote:

Another question - do you have any sample images?  If they compress

well (bzip2 does a good job with most blank images) it would be nice
to have a couple of parallels images (e.g. one "WithouFreSpacExt" and
one "WithoutFreeSpace") in the tests sample_images directory. If you
can provide both types of images, I'll amend test 076 to include them.

I can go ahead and give my R-b for this patch:
no prob, I have access to them. I'll provide a collection within next 
series.


There is some other incompatible stuff add...


/stuff add.../stuff to add.../



Re: [Qemu-devel] [PATCH RFC 0/3] dataplane: dataplane: more graceful error handling

2014-08-07 Thread Cornelia Huck
On Thu, 7 Aug 2014 16:39:01 +0200
Kevin Wolf  wrote:

> Am 25.07.2014 um 14:10 hat Cornelia Huck geschrieben:
> > Currently, qemu will take a hard exit if it fails to set up guest or
> > host notifiers, giving no real clue as to what went wrong (e.g., when
> > out of file descriptors).
> > 
> > This patchset tries to make this more manageable: Both by improving the
> > error message and by gracefully falling back to non-dataplane in case of
> > errors.
> > 
> > Patches are also available on
> > 
> > git://github.com/cohuck/qemu dataplane-graceful-fail
> > 
> > Thoughts?
> 
> I think Stefan should comment on this, but I certainly welcome every
> patch that fixes an exit(1) call.
> 
> I'm not entirely sure about the added fprintf(). It feels wrong, but of
> course it's a lot less wrong than exiting. 

Well, I was only enhancing an existing message :) At least the admin
has a chance to find out now what went wrong.

> Ideally already adding the
> device with dataplane enabled would fail so that we can return a proper
> QMP error message instead of just dumping something on stderr. Not sure
> if it's possible, though, I don't really know that code.

The problem is that we won't fail until after we actually try to start
dataplane (i.e. when the guest is trying to use the device). Depending
on the guest, this may be when the guest has already been running for a
time (e.g. when the guest disables using some devices and the guest
admin enables them manually later).

> 
> Nothing to stop this series anyway.
> 
> Kevin
> 




Re: [Qemu-devel] [PATCH v2 4/4] parallels: 2TB+ parallels images support

2014-08-07 Thread Denis V. Lunev

On 07/08/14 19:14, Jeff Cody wrote:

On Thu, Aug 07, 2014 at 07:03:12PM +0400, Denis V. Lunev wrote:

On 07/08/14 18:39, Jeff Cody wrote:

On Mon, Jul 28, 2014 at 08:23:55PM +0400, Denis V. Lunev wrote:

Parallels has released in the recent updates of Parallels Server 5/6
new addition to his image format. Images with signature WithouFreSpacExt
have offsets in the catalog coded not as offsets in sectors (multiple
of 512 bytes) but offsets coded in blocks (i.e. header->tracks * 512)

In this case all 64 bits of header->nb_sectors are used for image size.

This patch implements support of this for qemu-img and also adds specific
check for an incorrect image. Images with block size greater than
INT_MAX/513 are not supported. The biggest available Parallels image
cluster size in the field is 1 Mb. Thus this limit will not hurt
anyone.

Signed-off-by: Denis V. Lunev 
CC: Jeff Cody 
CC: Kevin Wolf 
CC: Stefan Hajnoczi 
---
  block/parallels.c | 25 -
  1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/block/parallels.c b/block/parallels.c
index 466705e..4414a9d 100644
--- a/block/parallels.c
+++ b/block/parallels.c
@@ -30,6 +30,7 @@
  /**/
  #define HEADER_MAGIC "WithoutFreeSpace"
+#define HEADER_MAGIC2 "WithouFreSpacExt"
  #define HEADER_VERSION 2
  #define HEADER_SIZE 64
@@ -54,6 +55,8 @@ typedef struct BDRVParallelsState {
  unsigned int catalog_size;
  unsigned int tracks;
+
+unsigned int off_multiplier;
  } BDRVParallelsState;
  static int parallels_probe(const uint8_t *buf, int buf_size, const char 
*filename)
@@ -63,7 +66,8 @@ static int parallels_probe(const uint8_t *buf, int buf_size, 
const char *filenam
  if (buf_size < HEADER_SIZE)
  return 0;
-if (!memcmp(ph->magic, HEADER_MAGIC, 16) &&
+if ((!memcmp(ph->magic, HEADER_MAGIC, 16) ||
+!memcmp(ph->magic, HEADER_MAGIC2, 16)) &&
  (le32_to_cpu(ph->version) == HEADER_VERSION))
  return 100;
@@ -85,21 +89,31 @@ static int parallels_open(BlockDriverState *bs, QDict 
*options, int flags,
  goto fail;
  }
+bs->total_sectors = le64_to_cpu(ph.nb_sectors);
+
  if (le32_to_cpu(ph.version) != HEADER_VERSION) {
  goto fail_format;
  }
-if (memcmp(ph.magic, HEADER_MAGIC, 16)) {
+if (!memcmp(ph.magic, HEADER_MAGIC, 16)) {
+s->off_multiplier = 1;
+bs->total_sectors = 0x & bs->total_sectors;
+} else if (!memcmp(ph.magic, HEADER_MAGIC2, 16)) {
+s->off_multiplier = le32_to_cpu(ph.tracks);
+} else {
  goto fail_format;
  }
-bs->total_sectors = 0x & le64_to_cpu(ph.nb_sectors);
-
  s->tracks = le32_to_cpu(ph.tracks);
  if (s->tracks == 0) {
  error_setg(errp, "Invalid image: Zero sectors per track");
  ret = -EINVAL;
  goto fail;
  }
+if (s->tracks > INT32_MAX/513) {
+error_setg(errp, "Invalid image: Too big cluster");
+ret = -EFBIG;
+goto fail;
+}
  s->catalog_size = le32_to_cpu(ph.catalog_entries);
  if (s->catalog_size > INT_MAX / 4) {
@@ -139,7 +153,8 @@ static int64_t seek_to_sector(BlockDriverState *bs, int64_t 
sector_num)
  /* not allocated */
  if ((index > s->catalog_size) || (s->catalog_bitmap[index] == 0))
  return -1;
-return (uint64_t)(s->catalog_bitmap[index] + offset) * 512;
+return
+((uint64_t)s->catalog_bitmap[index] * s->off_multiplier + offset) * 
512;

This still does a cast to uint_64_t, instead of int64_t; not sure it
really matters in practice, as we should be safe now from exceeding an
int64_t value in the end result.

this is safe due to above check for s->tracks > INT32_MAX/513
Actually, original code has exactly the same cast and the situation
is exactly the same before the patch (uint32_t value * 1) and after
the patch (uint32_t * (something < INT32_MAX/513))

Though I can change the cast to int64_t, I do not see much difference.
Should I do this?


Right, as I said in practice it should now be safe from exceeding an
int64_t (due to the bounds check on s->tracks). I think it is worth
changing if someone else requests a respin for another reason, but
probably not to do a respin for this on its own.

Another question - do you have any sample images?  If they compress
well (bzip2 does a good job with most blank images) it would be nice
to have a couple of parallels images (e.g. one "WithouFreSpacExt" and
one "WithoutFreeSpace") in the tests sample_images directory.  If you
can provide both types of images, I'll amend test 076 to include them.

I can go ahead and give my R-b for this patch:
no prob, I have access to them. I'll provide a collection within next 
series.


There is some other incompatible stuff add...


Reviewed-by: Jeff Cody 


Thank you :)






  }
  static int parallels_read(BlockDriverState *bs, int64_t sector_num,
--
1.9.1









Re: [Qemu-devel] [PATCH v2 4/4] parallels: 2TB+ parallels images support

2014-08-07 Thread Jeff Cody
On Thu, Aug 07, 2014 at 07:03:12PM +0400, Denis V. Lunev wrote:
> On 07/08/14 18:39, Jeff Cody wrote:
> >On Mon, Jul 28, 2014 at 08:23:55PM +0400, Denis V. Lunev wrote:
> >>Parallels has released in the recent updates of Parallels Server 5/6
> >>new addition to his image format. Images with signature WithouFreSpacExt
> >>have offsets in the catalog coded not as offsets in sectors (multiple
> >>of 512 bytes) but offsets coded in blocks (i.e. header->tracks * 512)
> >>
> >>In this case all 64 bits of header->nb_sectors are used for image size.
> >>
> >>This patch implements support of this for qemu-img and also adds specific
> >>check for an incorrect image. Images with block size greater than
> >>INT_MAX/513 are not supported. The biggest available Parallels image
> >>cluster size in the field is 1 Mb. Thus this limit will not hurt
> >>anyone.
> >>
> >>Signed-off-by: Denis V. Lunev 
> >>CC: Jeff Cody 
> >>CC: Kevin Wolf 
> >>CC: Stefan Hajnoczi 
> >>---
> >>  block/parallels.c | 25 -
> >>  1 file changed, 20 insertions(+), 5 deletions(-)
> >>
> >>diff --git a/block/parallels.c b/block/parallels.c
> >>index 466705e..4414a9d 100644
> >>--- a/block/parallels.c
> >>+++ b/block/parallels.c
> >>@@ -30,6 +30,7 @@
> >>  /**/
> >>  #define HEADER_MAGIC "WithoutFreeSpace"
> >>+#define HEADER_MAGIC2 "WithouFreSpacExt"
> >>  #define HEADER_VERSION 2
> >>  #define HEADER_SIZE 64
> >>@@ -54,6 +55,8 @@ typedef struct BDRVParallelsState {
> >>  unsigned int catalog_size;
> >>  unsigned int tracks;
> >>+
> >>+unsigned int off_multiplier;
> >>  } BDRVParallelsState;
> >>  static int parallels_probe(const uint8_t *buf, int buf_size, const char 
> >> *filename)
> >>@@ -63,7 +66,8 @@ static int parallels_probe(const uint8_t *buf, int 
> >>buf_size, const char *filenam
> >>  if (buf_size < HEADER_SIZE)
> >>  return 0;
> >>-if (!memcmp(ph->magic, HEADER_MAGIC, 16) &&
> >>+if ((!memcmp(ph->magic, HEADER_MAGIC, 16) ||
> >>+!memcmp(ph->magic, HEADER_MAGIC2, 16)) &&
> >>  (le32_to_cpu(ph->version) == HEADER_VERSION))
> >>  return 100;
> >>@@ -85,21 +89,31 @@ static int parallels_open(BlockDriverState *bs, QDict 
> >>*options, int flags,
> >>  goto fail;
> >>  }
> >>+bs->total_sectors = le64_to_cpu(ph.nb_sectors);
> >>+
> >>  if (le32_to_cpu(ph.version) != HEADER_VERSION) {
> >>  goto fail_format;
> >>  }
> >>-if (memcmp(ph.magic, HEADER_MAGIC, 16)) {
> >>+if (!memcmp(ph.magic, HEADER_MAGIC, 16)) {
> >>+s->off_multiplier = 1;
> >>+bs->total_sectors = 0x & bs->total_sectors;
> >>+} else if (!memcmp(ph.magic, HEADER_MAGIC2, 16)) {
> >>+s->off_multiplier = le32_to_cpu(ph.tracks);
> >>+} else {
> >>  goto fail_format;
> >>  }
> >>-bs->total_sectors = 0x & le64_to_cpu(ph.nb_sectors);
> >>-
> >>  s->tracks = le32_to_cpu(ph.tracks);
> >>  if (s->tracks == 0) {
> >>  error_setg(errp, "Invalid image: Zero sectors per track");
> >>  ret = -EINVAL;
> >>  goto fail;
> >>  }
> >>+if (s->tracks > INT32_MAX/513) {
> >>+error_setg(errp, "Invalid image: Too big cluster");
> >>+ret = -EFBIG;
> >>+goto fail;
> >>+}
> >>  s->catalog_size = le32_to_cpu(ph.catalog_entries);
> >>  if (s->catalog_size > INT_MAX / 4) {
> >>@@ -139,7 +153,8 @@ static int64_t seek_to_sector(BlockDriverState *bs, 
> >>int64_t sector_num)
> >>  /* not allocated */
> >>  if ((index > s->catalog_size) || (s->catalog_bitmap[index] == 0))
> >>  return -1;
> >>-return (uint64_t)(s->catalog_bitmap[index] + offset) * 512;
> >>+return
> >>+((uint64_t)s->catalog_bitmap[index] * s->off_multiplier + offset) 
> >>* 512;
> >This still does a cast to uint_64_t, instead of int64_t; not sure it
> >really matters in practice, as we should be safe now from exceeding an
> >int64_t value in the end result.
> 
> this is safe due to above check for s->tracks > INT32_MAX/513
> Actually, original code has exactly the same cast and the situation
> is exactly the same before the patch (uint32_t value * 1) and after
> the patch (uint32_t * (something < INT32_MAX/513))
> 
> Though I can change the cast to int64_t, I do not see much difference.
> Should I do this?
>

Right, as I said in practice it should now be safe from exceeding an
int64_t (due to the bounds check on s->tracks). I think it is worth
changing if someone else requests a respin for another reason, but
probably not to do a respin for this on its own.

Another question - do you have any sample images?  If they compress
well (bzip2 does a good job with most blank images) it would be nice
to have a couple of parallels images (e.g. one "WithouFreSpacExt" and
one "WithoutFreeSpace") in the tests sample_images directory.  If you
can provide both types of images, I'll amend test 076 to include them.

I ca

Re: [Qemu-devel] aarch64 & gdb: warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml"

2014-08-07 Thread Richard W.M. Jones
On Thu, Aug 07, 2014 at 02:53:33PM +0100, Peter Maydell wrote:
> On 7 August 2014 14:43, Christopher Covington  wrote:
> > On 08/07/2014 08:03 AM, Peter Maydell wrote:
> >> No, because at the moment our AArch64 TCG implementation
> >> (and the way we configure KVM) assumes that the highest
> >> exception level is running AArch64. We might fix this eventually,
> >> though.
> >
> > When EL3 and EL2 support is added, the bootloader will
> > presumably have to be modified to make the switch from
> > EL3 into EL2. In my experience switching into AArch32
> > EL2 instead of AArch64 EL2 is an easy option to add.
> 
> I think the biggest difficulty is not the code to actually
> do the switch but figuring out what the command line
> UI to request "start in AArch32" ought to be and how that
> then gets plumbed into the code to do the actual work.

Out of interest, how do you do this on real hardware?

Rich.

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



Re: [Qemu-devel] [PATCH v2 4/4] parallels: 2TB+ parallels images support

2014-08-07 Thread Denis V. Lunev

On 07/08/14 18:39, Jeff Cody wrote:

On Mon, Jul 28, 2014 at 08:23:55PM +0400, Denis V. Lunev wrote:

Parallels has released in the recent updates of Parallels Server 5/6
new addition to his image format. Images with signature WithouFreSpacExt
have offsets in the catalog coded not as offsets in sectors (multiple
of 512 bytes) but offsets coded in blocks (i.e. header->tracks * 512)

In this case all 64 bits of header->nb_sectors are used for image size.

This patch implements support of this for qemu-img and also adds specific
check for an incorrect image. Images with block size greater than
INT_MAX/513 are not supported. The biggest available Parallels image
cluster size in the field is 1 Mb. Thus this limit will not hurt
anyone.

Signed-off-by: Denis V. Lunev 
CC: Jeff Cody 
CC: Kevin Wolf 
CC: Stefan Hajnoczi 
---
  block/parallels.c | 25 -
  1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/block/parallels.c b/block/parallels.c
index 466705e..4414a9d 100644
--- a/block/parallels.c
+++ b/block/parallels.c
@@ -30,6 +30,7 @@
  /**/
  
  #define HEADER_MAGIC "WithoutFreeSpace"

+#define HEADER_MAGIC2 "WithouFreSpacExt"
  #define HEADER_VERSION 2
  #define HEADER_SIZE 64
  
@@ -54,6 +55,8 @@ typedef struct BDRVParallelsState {

  unsigned int catalog_size;
  
  unsigned int tracks;

+
+unsigned int off_multiplier;
  } BDRVParallelsState;
  
  static int parallels_probe(const uint8_t *buf, int buf_size, const char *filename)

@@ -63,7 +66,8 @@ static int parallels_probe(const uint8_t *buf, int buf_size, 
const char *filenam
  if (buf_size < HEADER_SIZE)
  return 0;
  
-if (!memcmp(ph->magic, HEADER_MAGIC, 16) &&

+if ((!memcmp(ph->magic, HEADER_MAGIC, 16) ||
+!memcmp(ph->magic, HEADER_MAGIC2, 16)) &&
  (le32_to_cpu(ph->version) == HEADER_VERSION))
  return 100;
  
@@ -85,21 +89,31 @@ static int parallels_open(BlockDriverState *bs, QDict *options, int flags,

  goto fail;
  }
  
+bs->total_sectors = le64_to_cpu(ph.nb_sectors);

+
  if (le32_to_cpu(ph.version) != HEADER_VERSION) {
  goto fail_format;
  }
-if (memcmp(ph.magic, HEADER_MAGIC, 16)) {
+if (!memcmp(ph.magic, HEADER_MAGIC, 16)) {
+s->off_multiplier = 1;
+bs->total_sectors = 0x & bs->total_sectors;
+} else if (!memcmp(ph.magic, HEADER_MAGIC2, 16)) {
+s->off_multiplier = le32_to_cpu(ph.tracks);
+} else {
  goto fail_format;
  }
  
-bs->total_sectors = 0x & le64_to_cpu(ph.nb_sectors);

-
  s->tracks = le32_to_cpu(ph.tracks);
  if (s->tracks == 0) {
  error_setg(errp, "Invalid image: Zero sectors per track");
  ret = -EINVAL;
  goto fail;
  }
+if (s->tracks > INT32_MAX/513) {
+error_setg(errp, "Invalid image: Too big cluster");
+ret = -EFBIG;
+goto fail;
+}
  
  s->catalog_size = le32_to_cpu(ph.catalog_entries);

  if (s->catalog_size > INT_MAX / 4) {
@@ -139,7 +153,8 @@ static int64_t seek_to_sector(BlockDriverState *bs, int64_t 
sector_num)
  /* not allocated */
  if ((index > s->catalog_size) || (s->catalog_bitmap[index] == 0))
  return -1;
-return (uint64_t)(s->catalog_bitmap[index] + offset) * 512;
+return
+((uint64_t)s->catalog_bitmap[index] * s->off_multiplier + offset) * 
512;

This still does a cast to uint_64_t, instead of int64_t; not sure it
really matters in practice, as we should be safe now from exceeding an
int64_t value in the end result.


this is safe due to above check for s->tracks > INT32_MAX/513
Actually, original code has exactly the same cast and the situation
is exactly the same before the patch (uint32_t value * 1) and after
the patch (uint32_t * (something < INT32_MAX/513))

Though I can change the cast to int64_t, I do not see much difference.
Should I do this?


  }
  
  static int parallels_read(BlockDriverState *bs, int64_t sector_num,

--
1.9.1







Re: [Qemu-devel] aarch64 & gdb: warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml"

2014-08-07 Thread Peter Maydell
On 7 August 2014 15:13, Christopher Covington  wrote:
> On 08/07/2014 09:53 AM, Peter Maydell wrote:
>> I think the biggest difficulty is not the code to actually
>> do the switch but figuring out what the command line
>> UI to request "start in AArch32" ought to be and how that
>> then gets plumbed into the code to do the actual work.
>
> ELF-32 file passed to -kernel seems to me like a reasonable place to start.

The semantics of "-kernel got a 32-bit ELF file" are "this is
not a Linux kernel image at all", so that won't work. In general
kernels aren't ELF files (either for AArch32 or AArch64).

(Also, what if you want to start your guest via UEFI bios
blob and having it load the kernel off a disk image?)

thanks
-- PMM



Re: [Qemu-devel] [PATCH v3 0/5] Allow VPC and VDI to be created over protocols

2014-08-07 Thread Kevin Wolf
Am 23.07.2014 um 23:22 hat Jeff Cody geschrieben:
> Changes from v2 -> v3:
> * Patch 2: Removed extra #ifdef __linux__ from top of file (Max)
> * Patch 4: Removed extra #ifdef __linux__ from top of file (Max)
> * Patch 5: Removed output from debug cruft (Max)
> * Added Max's R-b to remaining patches
> 
> Changes from v1 -> v2:
> * Patch 2: Use'bs' instead of 'bs->file' (Max)
> * Patch 3: Same as patch 2 (ripple through)
> * Patch 5: Update VDI test for static image (Kevin)
> * Added Max's R-b to patches 1,3,4
> 
> This allows VPC and VDI to be created over protocols; currently, they use
> posix calls directly to open, seek, and write into new image files.  This
> obviously precludes them from being able to be created over a protocol, like
> glusterfs.

Thanks, applied to the block branch.

I have one general remark, though: When creating an image, there's
little reason to use bdrv_pwrite_sync() instead of bdrv_pwrite(). If it
crashes in the middle, the file will be thrown away anyway. So it only
slows things down a bit for no benefit. Might be worth a follow-up.

Kevin



Re: [Qemu-devel] [PATCH v2 4/4] parallels: 2TB+ parallels images support

2014-08-07 Thread Jeff Cody
On Mon, Jul 28, 2014 at 08:23:55PM +0400, Denis V. Lunev wrote:
> Parallels has released in the recent updates of Parallels Server 5/6
> new addition to his image format. Images with signature WithouFreSpacExt
> have offsets in the catalog coded not as offsets in sectors (multiple
> of 512 bytes) but offsets coded in blocks (i.e. header->tracks * 512)
> 
> In this case all 64 bits of header->nb_sectors are used for image size.
> 
> This patch implements support of this for qemu-img and also adds specific
> check for an incorrect image. Images with block size greater than
> INT_MAX/513 are not supported. The biggest available Parallels image
> cluster size in the field is 1 Mb. Thus this limit will not hurt
> anyone.
> 
> Signed-off-by: Denis V. Lunev 
> CC: Jeff Cody 
> CC: Kevin Wolf 
> CC: Stefan Hajnoczi 
> ---
>  block/parallels.c | 25 -
>  1 file changed, 20 insertions(+), 5 deletions(-)
> 
> diff --git a/block/parallels.c b/block/parallels.c
> index 466705e..4414a9d 100644
> --- a/block/parallels.c
> +++ b/block/parallels.c
> @@ -30,6 +30,7 @@
>  /**/
>  
>  #define HEADER_MAGIC "WithoutFreeSpace"
> +#define HEADER_MAGIC2 "WithouFreSpacExt"
>  #define HEADER_VERSION 2
>  #define HEADER_SIZE 64
>  
> @@ -54,6 +55,8 @@ typedef struct BDRVParallelsState {
>  unsigned int catalog_size;
>  
>  unsigned int tracks;
> +
> +unsigned int off_multiplier;
>  } BDRVParallelsState;
>  
>  static int parallels_probe(const uint8_t *buf, int buf_size, const char 
> *filename)
> @@ -63,7 +66,8 @@ static int parallels_probe(const uint8_t *buf, int 
> buf_size, const char *filenam
>  if (buf_size < HEADER_SIZE)
>  return 0;
>  
> -if (!memcmp(ph->magic, HEADER_MAGIC, 16) &&
> +if ((!memcmp(ph->magic, HEADER_MAGIC, 16) ||
> +!memcmp(ph->magic, HEADER_MAGIC2, 16)) &&
>  (le32_to_cpu(ph->version) == HEADER_VERSION))
>  return 100;
>  
> @@ -85,21 +89,31 @@ static int parallels_open(BlockDriverState *bs, QDict 
> *options, int flags,
>  goto fail;
>  }
>  
> +bs->total_sectors = le64_to_cpu(ph.nb_sectors);
> +
>  if (le32_to_cpu(ph.version) != HEADER_VERSION) {
>  goto fail_format;
>  }
> -if (memcmp(ph.magic, HEADER_MAGIC, 16)) {
> +if (!memcmp(ph.magic, HEADER_MAGIC, 16)) {
> +s->off_multiplier = 1;
> +bs->total_sectors = 0x & bs->total_sectors;
> +} else if (!memcmp(ph.magic, HEADER_MAGIC2, 16)) {
> +s->off_multiplier = le32_to_cpu(ph.tracks);
> +} else {
>  goto fail_format;
>  }
>  
> -bs->total_sectors = 0x & le64_to_cpu(ph.nb_sectors);
> -
>  s->tracks = le32_to_cpu(ph.tracks);
>  if (s->tracks == 0) {
>  error_setg(errp, "Invalid image: Zero sectors per track");
>  ret = -EINVAL;
>  goto fail;
>  }
> +if (s->tracks > INT32_MAX/513) {
> +error_setg(errp, "Invalid image: Too big cluster");
> +ret = -EFBIG;
> +goto fail;
> +}
>  
>  s->catalog_size = le32_to_cpu(ph.catalog_entries);
>  if (s->catalog_size > INT_MAX / 4) {
> @@ -139,7 +153,8 @@ static int64_t seek_to_sector(BlockDriverState *bs, 
> int64_t sector_num)
>  /* not allocated */
>  if ((index > s->catalog_size) || (s->catalog_bitmap[index] == 0))
>  return -1;
> -return (uint64_t)(s->catalog_bitmap[index] + offset) * 512;
> +return
> +((uint64_t)s->catalog_bitmap[index] * s->off_multiplier + offset) * 
> 512;

This still does a cast to uint_64_t, instead of int64_t; not sure it
really matters in practice, as we should be safe now from exceeding an
int64_t value in the end result.

>  }
>  
>  static int parallels_read(BlockDriverState *bs, int64_t sector_num,
> -- 
> 1.9.1
> 
> 



Re: [Qemu-devel] [PATCH RFC 0/3] dataplane: dataplane: more graceful error handling

2014-08-07 Thread Kevin Wolf
Am 25.07.2014 um 14:10 hat Cornelia Huck geschrieben:
> Currently, qemu will take a hard exit if it fails to set up guest or
> host notifiers, giving no real clue as to what went wrong (e.g., when
> out of file descriptors).
> 
> This patchset tries to make this more manageable: Both by improving the
> error message and by gracefully falling back to non-dataplane in case of
> errors.
> 
> Patches are also available on
> 
> git://github.com/cohuck/qemu dataplane-graceful-fail
> 
> Thoughts?

I think Stefan should comment on this, but I certainly welcome every
patch that fixes an exit(1) call.

I'm not entirely sure about the added fprintf(). It feels wrong, but of
course it's a lot less wrong than exiting. Ideally already adding the
device with dataplane enabled would fail so that we can return a proper
QMP error message instead of just dumping something on stderr. Not sure
if it's possible, though, I don't really know that code.

Nothing to stop this series anyway.

Kevin



Re: [Qemu-devel] [PATCH v2 3/4] parallels: split check for parallels format in parallels_open

2014-08-07 Thread Jeff Cody
On Mon, Jul 28, 2014 at 08:23:54PM +0400, Denis V. Lunev wrote:
> and rework error path a bit. There is no difference at the moment, but
> the code will be definitely shorter when additional processing will
> be required for WithouFreSpacExt
> 
> Signed-off-by: Denis V. Lunev 
> CC: Jeff Cody 
> CC: Kevin Wolf 
> CC: Stefan Hajnoczi 
> ---
>  block/parallels.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/block/parallels.c b/block/parallels.c
> index 16d14ad..466705e 100644
> --- a/block/parallels.c
> +++ b/block/parallels.c
> @@ -85,11 +85,11 @@ static int parallels_open(BlockDriverState *bs, QDict 
> *options, int flags,
>  goto fail;
>  }
>  
> -if (memcmp(ph.magic, HEADER_MAGIC, 16) ||
> -(le32_to_cpu(ph.version) != HEADER_VERSION)) {
> -error_setg(errp, "Image not in Parallels format");
> -ret = -EINVAL;
> -goto fail;
> +if (le32_to_cpu(ph.version) != HEADER_VERSION) {
> +goto fail_format;
> +}
> +if (memcmp(ph.magic, HEADER_MAGIC, 16)) {
> +goto fail_format;
>  }
>  
>  bs->total_sectors = 0x & le64_to_cpu(ph.nb_sectors);
> @@ -120,6 +120,9 @@ static int parallels_open(BlockDriverState *bs, QDict 
> *options, int flags,
>  qemu_co_mutex_init(&s->lock);
>  return 0;
>  
> +fail_format:
> +error_setg(errp, "Image not in Parallels format");
> +ret = -EINVAL;
>  fail:
>  g_free(s->catalog_bitmap);
>  return ret;
> -- 
> 1.9.1
> 
>

Reviewed-by: Jeff Cody 



Re: [Qemu-devel] [PATCH v2 1/4] parallels: extend parallels format header with actual data values

2014-08-07 Thread Jeff Cody
On Mon, Jul 28, 2014 at 08:23:52PM +0400, Denis V. Lunev wrote:
> Parallels image format has several additional fields inside:
> - nb_sectors is actually 64 bit wide. Upper 32bits are not used for
>   images with signature "WithoutFreeSpace" and must be explicitly
>   zeroed according to Parallels. They will be used for images with
>   signature "WithouFreSpacExt"
> - inuse is magic which means that the image is currently opened for
>   read/write or was not closed correctly, the magic is 0x746f6e59
> - data_off is the location of the first data block. It can be zero
>   and in this case data starts just beyond the header aligned to
>   512 bytes. Though this field does not matter for read-only driver
> 
> This patch adds these values to struct parallels_header and adds
> proper handling of nb_sectors for currently supported WithoutFreeSpace
> images.
> 
> WithouFreSpacExt will be covered in next patches.
> 
> Signed-off-by: Denis V. Lunev 
> CC: Kevin Wolf 
> CC: Stefan Hajnoczi 
> CC: Jeff Cody 
> ---
>  block/parallels.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/block/parallels.c b/block/parallels.c
> index 1a5bd35..e39 100644
> --- a/block/parallels.c
> +++ b/block/parallels.c
> @@ -41,8 +41,10 @@ struct parallels_header {
>  uint32_t cylinders;
>  uint32_t tracks;
>  uint32_t catalog_entries;
> -uint32_t nb_sectors;
> -char padding[24];
> +uint64_t nb_sectors;
> +uint32_t inuse;
> +uint32_t data_off;
> +char padding[12];
>  } QEMU_PACKED;
>  
>  typedef struct BDRVParallelsState {
> @@ -90,7 +92,7 @@ static int parallels_open(BlockDriverState *bs, QDict 
> *options, int flags,
>  goto fail;
>  }
>  
> -bs->total_sectors = le32_to_cpu(ph.nb_sectors);
> +bs->total_sectors = 0x & le64_to_cpu(ph.nb_sectors);
>  
>  s->tracks = le32_to_cpu(ph.tracks);
>  if (s->tracks == 0) {
> -- 
> 1.9.1
> 
>

Reviewed-by: Jeff Cody 



Re: [Qemu-devel] [PATCH 2/2] scsi-bus: Convert DeviceClass init to realize

2014-08-07 Thread Kevin Wolf
Am 05.08.2014 um 11:11 hat Fam Zheng geschrieben:
> Replace "init/destroy" with "realize/unrealize" in SCSIDeviceClass,
> which has errp as a parameter. So all the implementations now uses
> error_setg instead of error_report for reporting error.
> 
> Also in lsi53c895a, report the error when initializing the if=scsi
> devices, before dropping it, because the callee's error_report is
> changed to error_segs.
> 
> Signed-off-by: Fam Zheng 
> ---
>  hw/scsi/lsi53c895a.c   |  2 ++
>  hw/scsi/scsi-bus.c | 64 ++---
>  hw/scsi/scsi-disk.c| 78 
> --
>  hw/scsi/scsi-generic.c | 37 +++---
>  include/hw/scsi/scsi.h |  7 +++--
>  tests/qemu-iotests/051.out |  4 +--
>  6 files changed, 96 insertions(+), 96 deletions(-)
> 
> diff --git a/hw/scsi/lsi53c895a.c b/hw/scsi/lsi53c895a.c
> index 786d848..dbc98a0 100644
> --- a/hw/scsi/lsi53c895a.c
> +++ b/hw/scsi/lsi53c895a.c
> @@ -19,6 +19,7 @@
>  #include "hw/pci/pci.h"
>  #include "hw/scsi/scsi.h"
>  #include "sysemu/dma.h"
> +#include "qemu/error-report.h"
>  
>  //#define DEBUG_LSI
>  //#define DEBUG_LSI_REG
> @@ -2121,6 +2122,7 @@ static int lsi_scsi_init(PCIDevice *dev)
>  if (!d->hotplugged) {
>  scsi_bus_legacy_handle_cmdline(&s->bus, &err);
>  if (err != NULL) {
> +error_report("%s", error_get_pretty(err));
>  error_free(err);
>  return -1;
>  }

Wouldn't qerror_report_err() be more useful? Or is already a QMP error
emitted in a different place in the callchain?

The same question is true for the added error_report() calls in patch 1.

> @@ -169,43 +168,40 @@ static int scsi_qdev_init(DeviceState *qdev)
>  d = scsi_device_find(bus, dev->channel, dev->id, ++lun);
>  } while (d && d->lun == lun && lun < bus->info->max_lun);
>  if (d && d->lun == lun) {
> -error_report("no free lun");
> -goto err;
> +error_setg(errp, "no free lun");
> +return;
>  }
>  dev->lun = lun;
>  } else {
>  d = scsi_device_find(bus, dev->channel, dev->id, dev->lun);
>  assert(d);
>  if (d->lun == dev->lun && dev != d) {
> -error_report("lun already used by '%s'", d->qdev.id);
> -goto err;
> +error_setg(errp, "lun already used by '%s'", d->qdev.id);
> +return;
>  }
>  }
>  
>  QTAILQ_INIT(&dev->requests);
> -rc = scsi_device_init(dev);
> -if (rc == 0) {
> +scsi_device_realize(dev, &local_err);
> +if (local_err) {
>  dev->vmsentry = qemu_add_vm_change_state_handler(scsi_dma_restart_cb,
>   dev);
> +error_propagate(errp, local_err);
>  }

Maybe I'm misunderstanding something, but it looks to me as if the
handler was previously installed in case of success, and now it's only
installed on failure?

>  
>  if (bus->info->hotplug) {
>  bus->info->hotplug(bus, dev);
>  }
> -
> -err:
> -return rc;
>  }

> diff --git a/tests/qemu-iotests/051.out b/tests/qemu-iotests/051.out
> index d7b0f50..f6d9dc1 100644
> --- a/tests/qemu-iotests/051.out
> +++ b/tests/qemu-iotests/051.out
> @@ -122,7 +122,7 @@ QEMU_PROG: -drive if=virtio: Device 'virtio-blk-pci' 
> could not be initialized
>  
>  Testing: -drive if=scsi
>  QEMU X.Y.Z monitor - type 'help' for more information
> -(qemu) QEMU_PROG: -drive if=scsi: Device needs media, but drive is empty
> +(qemu) QEMU_PROG: Device needs media, but drive is empty
>  QEMU_PROG: Device initialization failed.
>  QEMU_PROG: Initialization of device lsi53c895a failed

The old error message was certainly more useful. Not sure if there's a
good way to retain it, though.

Kevin



Re: [Qemu-devel] aarch64 & gdb: warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml"

2014-08-07 Thread Christopher Covington
On 08/07/2014 09:53 AM, Peter Maydell wrote:
> On 7 August 2014 14:43, Christopher Covington  wrote:
>> On 08/07/2014 08:03 AM, Peter Maydell wrote:
>>> No, because at the moment our AArch64 TCG implementation
>>> (and the way we configure KVM) assumes that the highest
>>> exception level is running AArch64. We might fix this eventually,
>>> though.
>>
>> When EL3 and EL2 support is added, the bootloader will
>> presumably have to be modified to make the switch from
>> EL3 into EL2. In my experience switching into AArch32
>> EL2 instead of AArch64 EL2 is an easy option to add.
> 
> I think the biggest difficulty is not the code to actually
> do the switch but figuring out what the command line
> UI to request "start in AArch32" ought to be and how that
> then gets plumbed into the code to do the actual work.

ELF-32 file passed to -kernel seems to me like a reasonable place to start.

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.



Re: [Qemu-devel] [PATCH] test-coroutine: add baseline test that times the cost of function calls

2014-08-07 Thread Kevin Wolf
Am 07.08.2014 um 11:33 hat Stefan Hajnoczi geschrieben:
> On Wed, Aug 06, 2014 at 11:33:41AM +0200, Paolo Bonzini wrote:
> > This can be used to compute the cost of coroutine operations.  In the
> > end the cost of the function call is a few clock cycles, so it's pretty
> > cheap for now, but it may become more relevant as the coroutine code
> > is optimized.
> > 
> > For example, here are the results on my machine:
> > 
> >Function call 1 iterations: 0.173884 s
> >Yield 1 iterations: 8.445064 s
> >Lifecycle 100 iterations: 0.098445 s
> >Nesting 1 iterations of 1000 depth each: 7.406431 s
> > 
> > One yield takes 83 nanoseconds, one enter takes 97 nanoseconds,
> > one coroutine allocation takes (roughly, since some of the allocations
> > in the nesting test do hit the pool) 739 nanoseconds:
> > 
> >(8.445064 - 0.173884) * 10^9 / 1 = 82.7
> >(0.098445 * 100 - 0.173884) * 10^9 / 1 = 96.7
> >(7.406431 * 10 - 0.173884) * 10^9 / 1 = 738.9
> > 
> > Signed-off-by: Paolo Bonzini 
> > ---
> >  tests/test-coroutine.c | 24 
> >  1 files changed, 24 insertions(+)
> 
> Can't hurt to have this as a comparison.
> 
> Reviewed-by: Stefan Hajnoczi 

Thanks, applied to the block branch.

Kevin


pgpfObFISDGgp.pgp
Description: PGP signature


Re: [Qemu-devel] [PATCH 0/2] VHDX endian fixes, error reporting

2014-08-07 Thread Kevin Wolf
Am 07.08.2014 um 12:05 hat Stefan Hajnoczi geschrieben:
> On Wed, Aug 06, 2014 at 03:54:56PM -0400, Jeff Cody wrote:
> > This series is mainly for some bug fixes related to VHDX endianness, 
> > stemming
> > from code reviews done by Markus Armbruster and Paolo Bonzini.  Once I did 
> > some
> > testing on a big-endian machine, several more endian related errors were
> > discovered, as well.  All endian related fixes are in patch 2.
> > 
> > Jeff Cody (2):
> >   block: vhdx - add error check
> >   block: VHDX endian fixes
> > 
> >  block/vhdx-endian.c | 11 +--
> >  block/vhdx-log.c| 48 ++---
> >  block/vhdx.c| 89 
> > +++--
> >  block/vhdx.h|  1 +
> >  4 files changed, 93 insertions(+), 56 deletions(-)
> 
> Reviewed-by: Stefan Hajnoczi 

Thanks, applied to the block branch.

Kevin


pgpt1mndJaZaP.pgp
Description: PGP signature


Re: [Qemu-devel] aarch64 & gdb: warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml"

2014-08-07 Thread Peter Maydell
On 7 August 2014 14:43, Christopher Covington  wrote:
> On 08/07/2014 08:03 AM, Peter Maydell wrote:
>> No, because at the moment our AArch64 TCG implementation
>> (and the way we configure KVM) assumes that the highest
>> exception level is running AArch64. We might fix this eventually,
>> though.
>
> When EL3 and EL2 support is added, the bootloader will
> presumably have to be modified to make the switch from
> EL3 into EL2. In my experience switching into AArch32
> EL2 instead of AArch64 EL2 is an easy option to add.

I think the biggest difficulty is not the code to actually
do the switch but figuring out what the command line
UI to request "start in AArch32" ought to be and how that
then gets plumbed into the code to do the actual work.

thanks
-- PMM



Re: [Qemu-devel] [PATCH v1 00/17] dataplane: optimization and multi virtqueue support

2014-08-07 Thread Kevin Wolf
Am 07.08.2014 um 12:27 hat Ming Lei geschrieben:
> On Wed, Aug 6, 2014 at 11:40 PM, Kevin Wolf  wrote:
> > Am 06.08.2014 um 13:28 hat Ming Lei geschrieben:
> >> On Wed, Aug 6, 2014 at 6:09 PM, Kevin Wolf  wrote:
> >> > Am 06.08.2014 um 11:37 hat Ming Lei geschrieben:
> >> >> On Wed, Aug 6, 2014 at 4:48 PM, Kevin Wolf  wrote:
> >> >> > However, I just wasn't sure whether a change on this level would be
> >> >> > relevant in a realistic environment. This is the reason why I wanted 
> >> >> > to
> >> >> > get a benchmark involving the block layer and some I/O.
> >> >> >
> >> >> >> From the profiling data in below link:
> >> >> >>
> >> >> >> http://pastebin.com/YwH2uwbq
> >> >> >>
> >> >> >> With coroutine, the running time for same loading is increased
> >> >> >> ~50%(1.325s vs. 0.903s), and dcache load events is increased
> >> >> >> ~35%(693M vs. 512M), insns per cycle is decreased by ~50%(
> >> >> >> 1.35 vs. 1.63), compared with bypassing coroutine(-b parameter).
> >> >> >>
> >> >> >> The bypass code in the benchmark is very similar with the approach
> >> >> >> used in the bypass patch, since linux-aio with O_DIRECT seldom
> >> >> >> blocks in the the kernel I/O path.
> >> >> >>
> >> >> >> Maybe the benchmark is a bit extremely, but given modern storage
> >> >> >> device may reach millions of IOPS, and it is very easy to slow down
> >> >> >> the I/O by coroutine.
> >> >> >
> >> >> > I think in order to optimise coroutines, such benchmarks are fair 
> >> >> > game.
> >> >> > It's just not guaranteed that the effects are exactly the same on real
> >> >> > workloads, so we should take the results with a grain of salt.
> >> >> >
> >> >> > Anyhow, the coroutine version of your benchmark is buggy, it leaks all
> >> >> > coroutines instead of exiting them, so it can't make any use of the
> >> >> > coroutine pool. On my laptop, I get this (where fixed coroutine is a
> >> >> > version that simply removes the yield at the end):
> >> >> >
> >> >> > | bypass| fixed coro| buggy coro
> >> >> > +---+---+--
> >> >> > time| 1.09s | 1.10s | 1.62s
> >> >> > L1-dcache-loads | 921,836,360   | 932,781,747   | 1,298,067,438
> >> >> > insns per cycle | 2.39  | 2.39  | 1.90
> >> >> >
> >> >> > Begs the question whether you see a similar effect on a real qemu and
> >> >> > the coroutine pool is still not big enough? With correct use of
> >> >> > coroutines, the difference seems to be barely measurable even without
> >> >> > any I/O involved.
> >> >>
> >> >> When I comment qemu_coroutine_yield(), looks result of
> >> >> bypass and fixed coro is very similar as your test, and I am just
> >> >> wondering if stack is always switched in qemu_coroutine_enter()
> >> >> without calling qemu_coroutine_yield().
> >> >
> >> > Yes, definitely. qemu_coroutine_enter() always involves calling
> >> > qemu_coroutine_switch(), which is the stack switch.
> >> >
> >> >> Without the yield, the benchmark can't emulate coroutine usage in
> >> >> bdrv_aio_readv/writev() path any more, and bypass in the patchset
> >> >> skips two qemu_coroutine_enter() and one qemu_coroutine_yield()
> >> >> for each bdrv_aio_readv/writev().
> >> >
> >> > It's not completely comparable anyway because you're not going through a
> >> > main loop and callbacks from there for your benchmark.
> >> >
> >> > But fair enough: Keep the yield, but enter the coroutine twice then. You
> >> > get slightly worse results then, but that's more like doubling the very
> >> > small difference between "bypass" and "fixed coro" (1.11s / 946,434,327
> >> > / 2.37), not like the horrible performance of the buggy version.
> >>
> >> Yes, I compared that too, looks no big difference.
> >>
> >> >
> >> > Actually, that's within the error of measurement for time and
> >> > insns/cycle, so running it for a bit longer:
> >> >
> >> > | bypass| coro  | + yield   | buggy coro
> >> > +---+---+---+--
> >> > time| 21.45s| 21.68s| 21.83s| 97.05s
> >> > L1-dcache-loads | 18,049 M  | 18,387 M  | 18,618 M  | 26,062 M
> >> > insns per cycle | 2.42  | 2.40  | 2.41  | 1.75
> >> >
> >> >> >> > I played a bit with the following, I hope it's not too naive. I 
> >> >> >> > couldn't
> >> >> >> > see a difference with your patches, but at least one reason for 
> >> >> >> > this is
> >> >> >> > probably that my laptop SSD isn't fast enough to make the CPU the
> >> >> >> > bottleneck. Haven't tried ramdisk yet, that would probably be the 
> >> >> >> > next
> >> >> >> > thing. (I actually wrote the patch up just for some profiling on 
> >> >> >> > my own,
> >> >> >> > not for comparing throughput, but it should be usable for that as 
> >> >> >> > well.)
> >> >> >>
> >> >> >> This might not be good for the test since it is basically a 
> >> >> >> sequential
> >> >> >> read test, which can be

Re: [Qemu-devel] aarch64 & gdb: warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml"

2014-08-07 Thread Christopher Covington
On 08/07/2014 08:03 AM, Peter Maydell wrote:
> On 7 August 2014 12:43, Richard W.M. Jones  wrote:
>> On Thu, Aug 07, 2014 at 12:35:27PM +0100, Peter Maydell wrote:
>>> On 7 August 2014 12:29, Richard W.M. Jones  wrote:
 On Thu, Aug 07, 2014 at 12:18:49PM +0100, Peter Maydell wrote:
> you didn't select a 32 bit CPU either explicitly or by default
> on the QEMU command line? Note that '-machine type=virt'
> defaults to a Cortex-A15 even in qemu-softmmu-aarch64
> (this is unfortunate but fallout from the fact that we started
> the virt model with the A15. Maybe we should make it not
> have a default and require a CPU specification...)

 Yes, this is indeed the case.  It also explains why I could get TCG
 working at all until I added -cpu cortex-a57.  Now it is working.

 I really think this choice of cpu_model = "cortex-a15" for -M virt is
 a poor one.  It should always default to something working.
>>>
>>> cortex-a15 *does* work, it's just a 32 bit CPU. It will function
>>> exactly the same as if you asked for an A15 in qemu-system-arm.
>>> Obviously if you try to feed it an AArch64 kernel it will behave
>>> the same way as if you'd tried to boot an AArch64 kernel on
>>> A15 hardware, so don't do that.
>>
>> Can't a 32 bit kernel run on -cpu cortex-a5x?  (I've not tried.)
> 
> No, because at the moment our AArch64 TCG implementation
> (and the way we configure KVM) assumes that the highest
> exception level is running AArch64. We might fix this eventually,
> though.

When EL3 and EL2 support is added, the bootloader will presumably have to be
modified to make the switch from EL3 into EL2. In my experience switching into
AArch32 EL2 instead of AArch64 EL2 is an easy option to add.

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.



[Qemu-devel] [PATCH v4 15/15] target-tricore: Add instructions of SR opcode format

2014-08-07 Thread Bastian Koppelmann
Add instructions of SR opcode format.
Add micro-op generator functions for saturate.
Add helper return from exception (rfe).

Signed-off-by: Bastian Koppelmann 
---
v3 -> v4:
- Replace first movcond with tcg_gen_setcond and second with tcg_gen_or at 
RSUB insn.
- Add AV, SAV calculation to RSUB insn.

 target-tricore/helper.h|   1 +
 target-tricore/op_helper.c |  52 +
 target-tricore/translate.c | 113 +
 3 files changed, 166 insertions(+)

diff --git a/target-tricore/helper.h b/target-tricore/helper.h
index 3c73234..7b7d74b 100644
--- a/target-tricore/helper.h
+++ b/target-tricore/helper.h
@@ -22,3 +22,4 @@ DEF_HELPER_3(sub_ssov, i32, env, i32, i32)
 DEF_HELPER_2(call, void, env, i32)
 DEF_HELPER_1(ret, void, env)
 DEF_HELPER_2(bisr, void, env, i32)
+DEF_HELPER_1(rfe, void, env)
diff --git a/target-tricore/op_helper.c b/target-tricore/op_helper.c
index c9cf0de..44bdb27 100644
--- a/target-tricore/op_helper.c
+++ b/target-tricore/op_helper.c
@@ -99,6 +99,21 @@ static int cdc_decrement(target_ulong *psw)
 return 0;
 }

+static bool cdc_zero(target_ulong *psw)
+{
+int cdc = *psw & MASK_PSW_CDC;
+/* Returns TRUE if PSW.CDC.COUNT == 0 or if PSW.CDC ==
+   7'b111, otherwise returns FALSE. */
+if (cdc == 0x7f) {
+return true;
+}
+/* find CDC.COUNT */
+int lo = clo32((*psw & MASK_PSW_CDC) << (32 - 7));
+int mask = (1u << (7 - lo)) - 1;
+int count = *psw & mask;
+return count == 0;
+}
+
 static void save_context_upper(CPUTRICOREState *env, int ea,
target_ulong *new_FCX)
 {
@@ -302,6 +317,43 @@ void helper_bisr(CPUTRICOREState *env, uint32_t const9)
 }
 }

+void helper_rfe(CPUTRICOREState *env)
+{
+target_ulong ea;
+target_ulong new_PCXI;
+target_ulong new_PSW;
+/* if (PCXI[19: 0] == 0) then trap(CSU); */
+if ((env->PCXI & 0xf) == 0) {
+/* raise csu trap */
+}
+/* if (PCXI.UL == 0) then trap(CTYP); */
+if ((env->PCXI & MASK_PCXI_UL) == 0) {
+/* raise CTYP trap */
+}
+/* if (!cdc_zero() AND PSW.CDE) then trap(NEST); */
+if (!cdc_zero(&(env->PSW)) && (env->PSW & MASK_PSW_CDE)) {
+/* raise MNG trap */
+}
+/* ICR.IE = PCXI.PIE; */
+env->ICR = (env->ICR & ~MASK_ICR_IE) + ((env->PCXI & MASK_PCXI_PIE) >> 15);
+/* ICR.CCPN = PCXI.PCPN; */
+env->ICR = (env->ICR & ~MASK_ICR_CCPN) +
+   ((env->PCXI & MASK_PCXI_PCPN) >> 24);
+/*EA = {PCXI.PCXS, 6'b0, PCXI.PCXO, 6'b0};*/
+ea = ((env->PCXI & MASK_PCXI_PCXS) << 12) +
+ ((env->PCXI & MASK_PCXI_PCXO) << 6);
+/*{new_PCXI, PSW, A[10], A[11], D[8], D[9], D[10], D[11], A[12],
+  A[13], A[14], A[15], D[12], D[13], D[14], D[15]} = M(EA, 16 * word);
+  M(EA, word) = FCX;*/
+restore_context_upper(env, ea, &new_PCXI, &new_PSW);
+/* FCX[19: 0] = PCXI[19: 0]; */
+env->FCX = (env->FCX & 0xfff0) + (env->PCXI & 0x000f);
+/* PCXI = new_PCXI; */
+env->PCXI = new_PCXI;
+/* write psw */
+psw_write(env, new_PSW);
+}
+
 static inline void QEMU_NORETURN do_raise_exception_err(CPUTRICOREState *env,
 uint32_t exception,
 int error_code,
diff --git a/target-tricore/translate.c b/target-tricore/translate.c
index 0bb6ea1..2b95cd9 100644
--- a/target-tricore/translate.c
+++ b/target-tricore/translate.c
@@ -241,6 +241,29 @@ static inline void gen_mul_i32s(TCGv ret, TCGv r1, TCGv r2)
 tcg_temp_free(low);
 }

+static void gen_saturate(TCGv ret, TCGv arg, int32_t up, int32_t low)
+{
+TCGv sat_neg = tcg_const_i32(low);
+TCGv temp = tcg_const_i32(up);
+
+/* sat_neg = (arg < low ) ? low : arg; */
+tcg_gen_movcond_tl(TCG_COND_LT, sat_neg, arg, sat_neg, arg, sat_neg);
+
+/* ret = (sat_neg > up ) ? up  : sat_neg; */
+tcg_gen_movcond_tl(TCG_COND_GT, ret, sat_neg, temp, temp, sat_neg);
+
+tcg_temp_free(sat_neg);
+tcg_temp_free(temp);
+}
+
+static void gen_saturate_u(TCGv ret, TCGv arg, int32_t up)
+{
+TCGv temp = tcg_const_i32(up);
+/* sat_neg = (arg > up ) ? up : arg; */
+tcg_gen_movcond_tl(TCG_COND_GTU, ret, arg, temp, temp, arg);
+tcg_temp_free(temp);
+}
+
 static void gen_shi(TCGv ret, TCGv r1, int32_t shift_count)
 {
 if (shift_count == -32) {
@@ -444,6 +467,15 @@ static void gen_compute_branch(DisasContext *ctx, uint32_t 
opc, int r1,
 case OPC1_16_SBR_LOOP:
 gen_loop(ctx, r1, offset * 2 - 32);
 break;
+/* SR-format jumps */
+case OPC1_16_SR_JI:
+tcg_gen_andi_tl(cpu_PC, cpu_gpr_a[r1], 0xfffe);
+tcg_gen_exit_tb(0);
+break;
+case OPC2_16_SR_RET:
+gen_helper_ret(cpu_env);
+tcg_gen_exit_tb(0);
+break;
 default:
 printf("Branch Error at %x\n", ctx->pc);
 }
@@ -760,6 +792,69 @@ static void decode_sro_opc(DisasContext *ctx, int op1)

[Qemu-devel] [PULL v2 10/11] monitor: Add drift info to 'info jit'

2014-08-07 Thread Paolo Bonzini
From: Sebastian Tanase 

Show in 'info jit' the current delay between the host clock
and the guest clock. In addition, print the maximum advance
and delay of the guest compared to the host.

Signed-off-by: Sebastian Tanase 
Tested-by: Camille Bégué 
Signed-off-by: Paolo Bonzini 
---
 cpu-exec.c|  6 ++
 cpus.c| 19 +++
 include/qemu-common.h |  4 
 monitor.c |  1 +
 4 files changed, 30 insertions(+)

diff --git a/cpu-exec.c b/cpu-exec.c
index 3c14502..cbc8067 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -105,6 +105,12 @@ static void init_delay_params(SyncClocks *sc,
sc->realtime_clock +
cpu_get_clock_offset();
 sc->last_cpu_icount = cpu->icount_extra + cpu->icount_decr.u16.low;
+if (sc->diff_clk < max_delay) {
+max_delay = sc->diff_clk;
+}
+if (sc->diff_clk > max_advance) {
+max_advance = sc->diff_clk;
+}
 
 /* Print every 2s max if the guest is late. We limit the number
of printed messages to NB_PRINT_MAX(currently 100) */
diff --git a/cpus.c b/cpus.c
index 19245e9..2b5c0bd 100644
--- a/cpus.c
+++ b/cpus.c
@@ -64,6 +64,8 @@
 #endif /* CONFIG_LINUX */
 
 static CPUState *next_cpu;
+int64_t max_delay;
+int64_t max_advance;
 
 bool cpu_is_stopped(CPUState *cpu)
 {
@@ -1552,3 +1554,20 @@ void qmp_inject_nmi(Error **errp)
 error_set(errp, QERR_UNSUPPORTED);
 #endif
 }
+
+void dump_drift_info(FILE *f, fprintf_function cpu_fprintf)
+{
+if (!use_icount) {
+return;
+}
+
+cpu_fprintf(f, "Host - Guest clock  %"PRIi64" ms\n",
+(cpu_get_clock() - cpu_get_icount())/SCALE_MS);
+if (icount_align_option) {
+cpu_fprintf(f, "Max guest delay %"PRIi64" ms\n", 
-max_delay/SCALE_MS);
+cpu_fprintf(f, "Max guest advance   %"PRIi64" ms\n", 
max_advance/SCALE_MS);
+} else {
+cpu_fprintf(f, "Max guest delay NA\n");
+cpu_fprintf(f, "Max guest advance   NA\n");
+}
+}
diff --git a/include/qemu-common.h b/include/qemu-common.h
index 5d10ac2..bcf7a6a 100644
--- a/include/qemu-common.h
+++ b/include/qemu-common.h
@@ -109,6 +109,10 @@ static inline char *realpath(const char *path, char 
*resolved_path)
 void configure_icount(QemuOpts *opts, Error **errp);
 extern int use_icount;
 extern int icount_align_option;
+/* drift information for info jit command */
+extern int64_t max_delay;
+extern int64_t max_advance;
+void dump_drift_info(FILE *f, fprintf_function cpu_fprintf);
 
 #include "qemu/osdep.h"
 #include "qemu/bswap.h"
diff --git a/monitor.c b/monitor.c
index 5bc70a6..cdbaa60 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1047,6 +1047,7 @@ static void do_info_registers(Monitor *mon, const QDict 
*qdict)
 static void do_info_jit(Monitor *mon, const QDict *qdict)
 {
 dump_exec_info((FILE *)mon, monitor_fprintf);
+dump_drift_info((FILE *)mon, monitor_fprintf);
 }
 
 static void do_info_history(Monitor *mon, const QDict *qdict)
-- 
1.8.3.1



[Qemu-devel] [PATCH v4 14/15] target-tricore: Add instructions of SLR, SSRO and SRO opcode format

2014-08-07 Thread Bastian Koppelmann
Add instructions of SLR, SSRO and SRO opcode format.

Signed-off-by: Bastian Koppelmann 

Reviewed-by: Richard Henderson 
---
 target-tricore/translate.c | 121 +
 1 file changed, 121 insertions(+)

diff --git a/target-tricore/translate.c b/target-tricore/translate.c
index ce90a60..0bb6ea1 100644
--- a/target-tricore/translate.c
+++ b/target-tricore/translate.c
@@ -682,6 +682,84 @@ static void decode_sc_opc(DisasContext *ctx, int op1)
 break;
 }
 }
+
+static void decode_slr_opc(DisasContext *ctx, int op1)
+{
+int r1, r2;
+
+r1 = MASK_OP_SLR_D(ctx->opcode);
+r2 = MASK_OP_SLR_S2(ctx->opcode);
+
+switch (op1) {
+/* SLR-format */
+case OPC1_16_SLR_LD_A:
+tcg_gen_qemu_ld_tl(cpu_gpr_a[r1], cpu_gpr_a[r2], ctx->mem_idx, 
MO_LESL);
+break;
+case OPC1_16_SLR_LD_A_POSTINC:
+tcg_gen_qemu_ld_tl(cpu_gpr_a[r1], cpu_gpr_a[r2], ctx->mem_idx, 
MO_LESL);
+tcg_gen_addi_tl(cpu_gpr_a[r2], cpu_gpr_a[r2], 4);
+break;
+case OPC1_16_SLR_LD_BU:
+tcg_gen_qemu_ld_tl(cpu_gpr_d[r1], cpu_gpr_a[r2], ctx->mem_idx, MO_UB);
+break;
+case OPC1_16_SLR_LD_BU_POSTINC:
+tcg_gen_qemu_ld_tl(cpu_gpr_d[r1], cpu_gpr_a[r2], ctx->mem_idx, MO_UB);
+tcg_gen_addi_tl(cpu_gpr_a[r2], cpu_gpr_a[r2], 1);
+break;
+case OPC1_16_SLR_LD_H:
+tcg_gen_qemu_ld_tl(cpu_gpr_d[r1], cpu_gpr_a[r2], ctx->mem_idx, 
MO_LESW);
+break;
+case OPC1_16_SLR_LD_H_POSTINC:
+tcg_gen_qemu_ld_tl(cpu_gpr_d[r1], cpu_gpr_a[r2], ctx->mem_idx, 
MO_LESW);
+tcg_gen_addi_tl(cpu_gpr_a[r2], cpu_gpr_a[r2], 2);
+break;
+case OPC1_16_SLR_LD_W:
+tcg_gen_qemu_ld_tl(cpu_gpr_d[r1], cpu_gpr_a[r2], ctx->mem_idx, 
MO_LESW);
+break;
+case OPC1_16_SLR_LD_W_POSTINC:
+tcg_gen_qemu_ld_tl(cpu_gpr_d[r1], cpu_gpr_a[r2], ctx->mem_idx, 
MO_LESW);
+tcg_gen_addi_tl(cpu_gpr_a[r2], cpu_gpr_a[r2], 4);
+break;
+}
+}
+
+static void decode_sro_opc(DisasContext *ctx, int op1)
+{
+int r2;
+int32_t address;
+
+r2 = MASK_OP_SRO_S2(ctx->opcode);
+address = MASK_OP_SRO_OFF4(ctx->opcode);
+
+/* SRO-format */
+switch (op1) {
+case OPC1_16_SRO_LD_A:
+gen_offset_ld(ctx, cpu_gpr_a[15], cpu_gpr_a[r2], address * 4, MO_LESL);
+break;
+case OPC1_16_SRO_LD_BU:
+gen_offset_ld(ctx, cpu_gpr_d[15], cpu_gpr_a[r2], address, MO_UB);
+break;
+case OPC1_16_SRO_LD_H:
+gen_offset_ld(ctx, cpu_gpr_d[15], cpu_gpr_a[r2], address, MO_LESW);
+break;
+case OPC1_16_SRO_LD_W:
+gen_offset_ld(ctx, cpu_gpr_d[15], cpu_gpr_a[r2], address * 4, MO_LESL);
+break;
+case OPC1_16_SRO_ST_A:
+gen_offset_st(ctx, cpu_gpr_a[15], cpu_gpr_a[r2], address * 4, MO_LESL);
+break;
+case OPC1_16_SRO_ST_B:
+gen_offset_st(ctx, cpu_gpr_d[15], cpu_gpr_a[r2], address, MO_UB);
+break;
+case OPC1_16_SRO_ST_H:
+gen_offset_st(ctx, cpu_gpr_d[15], cpu_gpr_a[r2], address * 2, MO_LESW);
+break;
+case OPC1_16_SRO_ST_W:
+gen_offset_st(ctx, cpu_gpr_d[15], cpu_gpr_a[r2], address * 4, MO_LESL);
+break;
+}
+}
+
 static void decode_16Bit_opc(CPUTRICOREState *env, DisasContext *ctx)
 {
 int op1;
@@ -825,6 +903,49 @@ static void decode_16Bit_opc(CPUTRICOREState *env, 
DisasContext *ctx)
 case OPC1_16_SC_SUB_A:
 decode_sc_opc(ctx, op1);
 break;
+/* SLR-format */
+case OPC1_16_SLR_LD_A:
+case OPC1_16_SLR_LD_A_POSTINC:
+case OPC1_16_SLR_LD_BU:
+case OPC1_16_SLR_LD_BU_POSTINC:
+case OPC1_16_SLR_LD_H:
+case OPC1_16_SLR_LD_H_POSTINC:
+case OPC1_16_SLR_LD_W:
+case OPC1_16_SLR_LD_W_POSTINC:
+decode_slr_opc(ctx, op1);
+break;
+/* SRO-format */
+case OPC1_16_SRO_LD_A:
+case OPC1_16_SRO_LD_BU:
+case OPC1_16_SRO_LD_H:
+case OPC1_16_SRO_LD_W:
+case OPC1_16_SRO_ST_A:
+case OPC1_16_SRO_ST_B:
+case OPC1_16_SRO_ST_H:
+case OPC1_16_SRO_ST_W:
+decode_sro_opc(ctx, op1);
+break;
+/* SSRO-format */
+case OPC1_16_SSRO_ST_A:
+r1 = MASK_OP_SSRO_S1(ctx->opcode);
+const16 = MASK_OP_SSRO_OFF4(ctx->opcode);
+gen_offset_st(ctx, cpu_gpr_a[r1], cpu_gpr_a[15], const16 * 4, MO_LESL);
+break;
+case OPC1_16_SSRO_ST_B:
+r1 = MASK_OP_SSRO_S1(ctx->opcode);
+const16 = MASK_OP_SSRO_OFF4(ctx->opcode);
+gen_offset_st(ctx, cpu_gpr_d[r1], cpu_gpr_a[15], const16, MO_UB);
+break;
+case OPC1_16_SSRO_ST_H:
+r1 = MASK_OP_SSRO_S1(ctx->opcode);
+const16 = MASK_OP_SSRO_OFF4(ctx->opcode);
+gen_offset_st(ctx, cpu_gpr_d[r1], cpu_gpr_a[15], const16 * 2, MO_LESW);
+break;
+case OPC1_16_SSRO_ST_W:
+r1 = MASK_OP_SSRO_S1(ctx->opcode);
+const16 = MASK_OP_SSRO_OFF4(ctx->opcode);
+gen_offset_st(ctx, cpu_gpr_d[r1], cpu_gpr_a[15], const16 * 4, MO_LESL);
+break;
 }
 

[Qemu-devel] [Bug 1353947] [NEW] Hypervisor with QEMU-2.0/libvirtd 1.2.2 stack when launching VM with CirrOS or Ubuntu 12.04

2014-08-07 Thread Eyal Perry
Public bug reported:

The issue observed when running an hypervisor with QEMU 2.0/libvirtd 1.2.2
The VM network interface is attached to a PCI virtual function (SR-IOV).

When we ran VM with guest OS CirrOS or Ubuntu 12.04 we observed an hipervisor 
hang shortly after the VM is loaded
We observed the same issue with Mellanox NIC and with Intel NIC

We’ve tried few combinations of {GuestOS}X{Hypervisor} and we got the following 
findings:
When a hypervisor is running QEMU 1.5/libvirtd 1.1.1 - no issue observed
When a hypervisor is running QEMU 2.0/libvirtd 1.2.2 - CirrOS and Ubuntu 12.04 
guest OSes caused hypervisor hang
When a hypervisor is running QEMU 2.0/libvirtd 1.2.2 - CentOS 6.4 and Ubuntu 
13.10 - no issue observed

The problematic guest OSes are with kernel versions ~3.2.y

** Affects: qemu
 Importance: Undecided
 Status: New

** Attachment added: "screen shot of hypervisor hang"
   
https://bugs.launchpad.net/bugs/1353947/+attachment/4171909/+files/qemu-issue%5B1%5D.png

** Information type changed from Private Security to Public

** Summary changed:

- Hypervisor with QEMU-2.0 stack when launching VM with CirrOS or Ubuntu 12.04
+ Hypervisor with QEMU-2.0/libvirtd 1.2.2 stack when launching VM with CirrOS 
or Ubuntu 12.04

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

Title:
  Hypervisor with QEMU-2.0/libvirtd 1.2.2 stack when launching VM with
  CirrOS or Ubuntu 12.04

Status in QEMU:
  New

Bug description:
  The issue observed when running an hypervisor with QEMU 2.0/libvirtd 1.2.2
  The VM network interface is attached to a PCI virtual function (SR-IOV).

  When we ran VM with guest OS CirrOS or Ubuntu 12.04 we observed an hipervisor 
hang shortly after the VM is loaded
  We observed the same issue with Mellanox NIC and with Intel NIC

  We’ve tried few combinations of {GuestOS}X{Hypervisor} and we got the 
following findings:
  When a hypervisor is running QEMU 1.5/libvirtd 1.1.1 - no issue observed
  When a hypervisor is running QEMU 2.0/libvirtd 1.2.2 - CirrOS and Ubuntu 
12.04 guest OSes caused hypervisor hang
  When a hypervisor is running QEMU 2.0/libvirtd 1.2.2 - CentOS 6.4 and Ubuntu 
13.10 - no issue observed

  The problematic guest OSes are with kernel versions ~3.2.y

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



[Qemu-devel] [PULL v2 00/11] KVM, icount changes for 2014-08-06

2014-08-07 Thread Paolo Bonzini
The following changes since commit 41a1a9c42c4e0fb5f1b94aa8b72e42f66ebde3d9:

  po: Update German translation (2014-07-28 23:37:17 +0200)

are available in the git repository at:

  git://github.com/bonzini/qemu.git tags/for-upstream

for you to fetch changes up to eddedd546a68f6ac864b71d50dd8d39b939b724b:

  target-mips: Ignore unassigned accesses with KVM (2014-08-07 15:09:48 +0200)


KVM changes include a MIPS patch and the testdev backend used by the
ARM kvm-unit-tests.  icount include the first part of reverse execution
and Sebastian Tanase's patches to slow down -icount execution to the
desired speed of the target.

v1->v2: fix dump_drift_info to print nothing outside icount mode,
and to compile on 32-bit architectures


James Hogan (1):
  target-mips: Ignore unassigned accesses with KVM

KONRAD Frederic (3):
  icount: put icount variables into TimerState.
  migration: migrate icount fields.
  timer: add cpu_icount_to_ns function.

Paolo Bonzini (1):
  backends: Introduce chr-testdev

Sebastian Tanase (6):
  icount: Fix virtual clock start value on ARM
  icount: Add QemuOpts for icount
  icount: Add align option to icount
  cpu-exec: Add sleeping algorithm
  cpu-exec: Print to console if the guest is late
  monitor: Add drift info to 'info jit'

 backends/Makefile.objs  |   2 +-
 backends/testdev.c  | 131 
 cpu-exec.c  | 116 ++
 cpus.c  | 118 ---
 include/qemu-common.h   |   8 ++-
 include/qemu/timer.h|   2 +
 include/sysemu/char.h   |   3 ++
 monitor.c   |   1 +
 qapi-schema.json|   3 +-
 qemu-char.c |   4 ++
 qemu-options.hx |  17 +--
 qtest.c |  13 -
 stubs/Makefile.objs |   1 +
 stubs/chr-testdev.c |   7 +++
 target-mips/op_helper.c |  11 
 vl.c|  39 +++---
 16 files changed, 444 insertions(+), 32 deletions(-)
 create mode 100644 backends/testdev.c
 create mode 100644 stubs/chr-testdev.c
-- 
1.8.3.1




Re: [Qemu-devel] [RFC PATCH 10/10] cpus: reclaim allocated vCPU objects

2014-08-07 Thread Anshul Makkar
Thanks Gu.. cpu-hotunplug is working fine in my  tests.

For cpu-hotplug, I get inconsistent result if I delete arbitrary cpu
and not just the last one.

for eg
list of cpus: 1, 2 ,3
device_add cpu 4
device_add cpu 5
device_add cpu 6

device_del cpu 4
device_del cpu 6

now if I do device_add cpu6, then cpu 4 gets added and now if I try to
do add cpu 4 or 6, it says cpu already exist.. Its a kind of vague
behaviour.. Do, we follow any protocol here while adding and deleting
cpus.

Thanks
Anshul Makkar
www.justkernel.com

On Thu, Aug 7, 2014 at 6:54 AM, Gu Zheng  wrote:
> After ACPI get a signal to eject a vCPU, the vCPU must be
> removed from CPU list,before the vCPU really removed,  then
> release the all related vCPU objects.
> But we do not close KVM vcpu fd, just record it into a list, in
> order to reuse it.
>
> Signed-off-by: Chen Fan 
> Signed-off-by: Gu Zheng 
> ---
>  cpus.c   |   37 
>  include/sysemu/kvm.h |1 +
>  kvm-all.c|   57 
> +-
>  3 files changed, 94 insertions(+), 1 deletions(-)
>
> diff --git a/cpus.c b/cpus.c
> index 4dfb889..9a73407 100644
> --- a/cpus.c
> +++ b/cpus.c
> @@ -786,6 +786,24 @@ void async_run_on_cpu(CPUState *cpu, void (*func)(void 
> *data), void *data)
>  qemu_cpu_kick(cpu);
>  }
>
> +static void qemu_kvm_destroy_vcpu(CPUState *cpu)
> +{
> +CPU_REMOVE(cpu);
> +
> +if (kvm_destroy_vcpu(cpu) < 0) {
> +fprintf(stderr, "kvm_destroy_vcpu failed.\n");
> +exit(1);
> +}
> +
> +object_unparent(OBJECT(cpu));
> +}
> +
> +static void qemu_tcg_destroy_vcpu(CPUState *cpu)
> +{
> +CPU_REMOVE(cpu);
> +object_unparent(OBJECT(cpu));
> +}
> +
>  static void flush_queued_work(CPUState *cpu)
>  {
>  struct qemu_work_item *wi;
> @@ -877,6 +895,11 @@ static void *qemu_kvm_cpu_thread_fn(void *arg)
>  }
>  }
>  qemu_kvm_wait_io_event(cpu);
> +if (cpu->exit && !cpu_can_run(cpu)) {
> +qemu_kvm_destroy_vcpu(cpu);
> +qemu_mutex_unlock(&qemu_global_mutex);
> +return NULL;
> +}
>  }
>
>  return NULL;
> @@ -929,6 +952,7 @@ static void tcg_exec_all(void);
>  static void *qemu_tcg_cpu_thread_fn(void *arg)
>  {
>  CPUState *cpu = arg;
> +CPUState *remove_cpu = NULL;
>
>  qemu_tcg_init_cpu_signals();
>  qemu_thread_get_self(cpu->thread);
> @@ -961,6 +985,16 @@ static void *qemu_tcg_cpu_thread_fn(void *arg)
>  }
>  }
>  qemu_tcg_wait_io_event();
> +CPU_FOREACH(cpu) {
> +if (cpu->exit && !cpu_can_run(cpu)) {
> +remove_cpu = cpu;
> +break;
> +}
> +}
> +if (remove_cpu) {
> +qemu_tcg_destroy_vcpu(remove_cpu);
> +remove_cpu = NULL;
> +}
>  }
>
>  return NULL;
> @@ -1316,6 +1350,9 @@ static void tcg_exec_all(void)
>  break;
>  }
>  } else if (cpu->stop || cpu->stopped) {
> +if (cpu->exit) {
> +next_cpu = CPU_NEXT(cpu);
> +}
>  break;
>  }
>  }
> diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
> index 174ea36..88e2403 100644
> --- a/include/sysemu/kvm.h
> +++ b/include/sysemu/kvm.h
> @@ -178,6 +178,7 @@ int kvm_has_intx_set_mask(void);
>
>  int kvm_init_vcpu(CPUState *cpu);
>  int kvm_cpu_exec(CPUState *cpu);
> +int kvm_destroy_vcpu(CPUState *cpu);
>
>  #ifdef NEED_CPU_H
>
> diff --git a/kvm-all.c b/kvm-all.c
> index 1402f4f..d0caeff 100644
> --- a/kvm-all.c
> +++ b/kvm-all.c
> @@ -74,6 +74,12 @@ typedef struct KVMSlot
>
>  typedef struct kvm_dirty_log KVMDirtyLog;
>
> +struct KVMParkedVcpu {
> +unsigned long vcpu_id;
> +int kvm_fd;
> +QLIST_ENTRY(KVMParkedVcpu) node;
> +};
> +
>  struct KVMState
>  {
>  KVMSlot *slots;
> @@ -108,6 +114,7 @@ struct KVMState
>  QTAILQ_HEAD(msi_hashtab, KVMMSIRoute) msi_hashtab[KVM_MSI_HASHTAB_SIZE];
>  bool direct_msi;
>  #endif
> +QLIST_HEAD(, KVMParkedVcpu) kvm_parked_vcpus;
>  };
>
>  KVMState *kvm_state;
> @@ -226,6 +233,53 @@ static int kvm_set_user_memory_region(KVMState *s, 
> KVMSlot *slot)
>  return kvm_vm_ioctl(s, KVM_SET_USER_MEMORY_REGION, &mem);
>  }
>
> +int kvm_destroy_vcpu(CPUState *cpu)
> +{
> +KVMState *s = kvm_state;
> +long mmap_size;
> +struct KVMParkedVcpu *vcpu = NULL;
> +int ret = 0;
> +
> +DPRINTF("kvm_destroy_vcpu\n");
> +
> +mmap_size = kvm_ioctl(s, KVM_GET_VCPU_MMAP_SIZE, 0);
> +if (mmap_size < 0) {
> +ret = mmap_size;
> +DPRINTF("KVM_GET_VCPU_MMAP_SIZE failed\n");
> +goto err;
> +}
> +
> +ret = munmap(cpu->kvm_run, mmap_size);
> +if (ret < 0) {
> +goto err;
> +}
> +
> +vcpu = g_malloc0(sizeof(*vcpu));
> +vcpu->vcpu_id = kvm_arch_vcpu_id(cpu);
> +vcpu->kvm_fd = cpu->kvm_fd;
> +QLIST_INSERT_HEAD(&kvm_state->kvm_parked_vcpus,

[Qemu-devel] [PATCH v4 03/15] target-tricore: Add softmmu support

2014-08-07 Thread Bastian Koppelmann
Add basic softmmu support for TriCore

Signed-off-by: Bastian Koppelmann 
---
 target-tricore/helper.c| 54 +-
 target-tricore/op_helper.c | 33 +++-
 2 files changed, 85 insertions(+), 2 deletions(-)

diff --git a/target-tricore/helper.c b/target-tricore/helper.c
index 0794672..22acb83 100644
--- a/target-tricore/helper.c
+++ b/target-tricore/helper.c
@@ -24,10 +24,62 @@
 
 #include "cpu.h"
 
+enum {
+TLBRET_DIRTY = -4,
+TLBRET_INVALID = -3,
+TLBRET_NOMATCH = -2,
+TLBRET_BADADDR = -1,
+TLBRET_MATCH = 0
+};
+
+#if defined(CONFIG_SOFTMMU)
+static int get_physical_address(CPUTRICOREState *env, hwaddr *physical,
+int *prot, target_ulong address,
+int rw, int access_type)
+{
+int ret = TLBRET_MATCH;
+
+*physical = address & 0x;
+*prot = PAGE_READ | PAGE_WRITE;
+
+return ret;
+}
+#endif
+
+/* TODO: Add exeption support*/
+static void raise_mmu_exception(CPUTRICOREState *env, target_ulong address,
+int rw, int tlb_error)
+{
+}
+
 int cpu_tricore_handle_mmu_fault(CPUState *cs, target_ulong address,
  int rw, int mmu_idx)
 {
-return 0;
+TRICORECPU *cpu = TRICORE_CPU(cs);
+CPUTRICOREState *env = &cpu->env;
+hwaddr physical;
+int prot;
+int access_type;
+int ret = 0;
+
+rw &= 1;
+access_type = ACCESS_INT;
+ret = get_physical_address(env, &physical, &prot,
+   address, rw, access_type);
+qemu_log("%s address=" TARGET_FMT_lx " ret %d physical " TARGET_FMT_plx
+ " prot %d\n", __func__, address, ret, physical, prot);
+
+if (ret == TLBRET_MATCH) {
+tlb_set_page(cs, address & TARGET_PAGE_MASK,
+ physical & TARGET_PAGE_MASK, prot | PAGE_EXEC,
+ mmu_idx, TARGET_PAGE_SIZE);
+ret = 0;
+} else if (ret < 0) {
+raise_mmu_exception(env, address, rw, ret);
+ret = 1;
+}
+
+return ret;
 }
 
 void tricore_cpu_do_interrupt(CPUState *cs)
diff --git a/target-tricore/op_helper.c b/target-tricore/op_helper.c
index 275790b..2e5981f 100644
--- a/target-tricore/op_helper.c
+++ b/target-tricore/op_helper.c
@@ -20,8 +20,39 @@
 #include "exec/helper-proto.h"
 #include "exec/cpu_ldst.h"
 
+static inline void QEMU_NORETURN do_raise_exception_err(CPUTRICOREState *env,
+uint32_t exception,
+int error_code,
+uintptr_t pc)
+{
+CPUState *cs = CPU(tricore_env_get_cpu(env));
+cs->exception_index = exception;
+env->error_code = error_code;
+
+if (pc) {
+/* now we have a real cpu fault */
+cpu_restore_state(cs, pc);
+}
+
+cpu_loop_exit(cs);
+}
+
+static inline void QEMU_NORETURN do_raise_exception(CPUTRICOREState *env,
+uint32_t exception,
+uintptr_t pc)
+{
+do_raise_exception_err(env, exception, 0, pc);
+}
+
 void tlb_fill(CPUState *cs, target_ulong addr, int is_write, int mmu_idx,
   uintptr_t retaddr)
 {
+int ret;
+ret = cpu_tricore_handle_mmu_fault(cs, addr, is_write, mmu_idx);
+if (ret) {
+TRICORECPU *cpu = TRICORE_CPU(cs);
+CPUTRICOREState *env = &cpu->env;
+do_raise_exception_err(env, cs->exception_index,
+   env->error_code, retaddr);
+}
 }
-
-- 
2.0.4




[Qemu-devel] [PATCH v4 10/15] target-tricore: Add instructions of SB opcode format

2014-08-07 Thread Bastian Koppelmann
Add instructions of SB opcode format.
Add helper call/ret.
Add micro-op generator functions for branches.
Add makro to generate helper functions.

Signed-off-by: Bastian Koppelmann 
---
v3 -> v4:
- Add missing break in gen_compute_branch at CALL insn.

 target-tricore/helper.h|   3 +
 target-tricore/op_helper.c | 180 +
 target-tricore/translate.c |  89 ++
 3 files changed, 272 insertions(+)

diff --git a/target-tricore/helper.h b/target-tricore/helper.h
index 299bd77..adf5b26 100644
--- a/target-tricore/helper.h
+++ b/target-tricore/helper.h
@@ -18,3 +18,6 @@
 /* Arithmetic */
 DEF_HELPER_3(add_ssov, i32, env, i32, i32)
 DEF_HELPER_3(sub_ssov, i32, env, i32, i32)
+/* CSA */
+DEF_HELPER_2(call, void, env, i32)
+DEF_HELPER_1(ret, void, env)
diff --git a/target-tricore/op_helper.c b/target-tricore/op_helper.c
index 6d94f0b..0006d44 100644
--- a/target-tricore/op_helper.c
+++ b/target-tricore/op_helper.c
@@ -63,6 +63,186 @@ target_ulong helper_sub_ssov(CPUTRICOREState *env, 
target_ulong r1,
 return ret;
 }

+/* context save area (CSA) related helpers */
+
+static int cdc_increment(target_ulong *psw)
+{
+if ((*psw & MASK_PSW_CDC) == 0x7f) {
+return 0;
+}
+
+(*psw)++;
+/* check for overflow */
+int lo = clo32((*psw & MASK_PSW_CDC) << (32 - 7));
+int mask = (1u << (7 - lo)) - 1;
+int count = *psw & mask;
+if (count == 0) {
+(*psw)--;
+return 1;
+}
+return 0;
+}
+
+static int cdc_decrement(target_ulong *psw)
+{
+if ((*psw & MASK_PSW_CDC) == 0x7f) {
+return 0;
+}
+/* check for underflow */
+int lo = clo32((*psw & MASK_PSW_CDC) << (32 - 7));
+int mask = (1u << (7 - lo)) - 1;
+int count = *psw & mask;
+if (count == 0) {
+return 1;
+}
+(*psw)--;
+return 0;
+}
+
+static void save_context_upper(CPUTRICOREState *env, int ea,
+   target_ulong *new_FCX)
+{
+*new_FCX = cpu_ldl_data(env, ea);
+cpu_stl_data(env, ea, env->PCXI);
+cpu_stl_data(env, ea+4, env->PSW);
+cpu_stl_data(env, ea+8, env->gpr_a[10]);
+cpu_stl_data(env, ea+12, env->gpr_a[11]);
+cpu_stl_data(env, ea+16, env->gpr_d[8]);
+cpu_stl_data(env, ea+20, env->gpr_d[9]);
+cpu_stl_data(env, ea+24, env->gpr_d[10]);
+cpu_stl_data(env, ea+28, env->gpr_d[11]);
+cpu_stl_data(env, ea+32, env->gpr_a[12]);
+cpu_stl_data(env, ea+36, env->gpr_a[13]);
+cpu_stl_data(env, ea+40, env->gpr_a[14]);
+cpu_stl_data(env, ea+44, env->gpr_a[15]);
+cpu_stl_data(env, ea+48, env->gpr_d[12]);
+cpu_stl_data(env, ea+52, env->gpr_d[13]);
+cpu_stl_data(env, ea+56, env->gpr_d[14]);
+cpu_stl_data(env, ea+60, env->gpr_d[15]);
+
+}
+
+static void restore_context_upper(CPUTRICOREState *env, int ea,
+  target_ulong *new_PCXI, target_ulong 
*new_PSW)
+{
+*new_PCXI = cpu_ldl_data(env, ea);
+*new_PSW = cpu_ldl_data(env, ea+4);
+env->gpr_a[10] = cpu_ldl_data(env, ea+8);
+env->gpr_a[11] = cpu_ldl_data(env, ea+12);
+env->gpr_d[8]  = cpu_ldl_data(env, ea+16);
+env->gpr_d[9]  = cpu_ldl_data(env, ea+20);
+env->gpr_d[10] = cpu_ldl_data(env, ea+24);
+env->gpr_d[11] = cpu_ldl_data(env, ea+28);
+env->gpr_a[12] = cpu_ldl_data(env, ea+32);
+env->gpr_a[13] = cpu_ldl_data(env, ea+36);
+env->gpr_a[14] = cpu_ldl_data(env, ea+40);
+env->gpr_a[15] = cpu_ldl_data(env, ea+44);
+env->gpr_d[12] = cpu_ldl_data(env, ea+48);
+env->gpr_d[13] = cpu_ldl_data(env, ea+52);
+env->gpr_d[14] = cpu_ldl_data(env, ea+56);
+env->gpr_d[15] = cpu_ldl_data(env, ea+60);
+cpu_stl_data(env, ea, env->FCX);
+}
+
+void helper_call(CPUTRICOREState *env, uint32_t next_pc)
+{
+target_ulong tmp_FCX;
+target_ulong ea;
+target_ulong new_FCX;
+target_ulong psw;
+
+psw = psw_read(env);
+/* if (FCX == 0) trap(FCU); */
+if (env->FCX == 0) {
+/* FCU trap */
+}
+/* if (PSW.CDE) then if (cdc_increment()) then trap(CDO); */
+if (psw & MASK_PSW_CDE) {
+if (cdc_increment(&psw)) {
+/* CDO trap */
+}
+}
+/* PSW.CDE = 1;*/
+psw |= MASK_PSW_CDE;
+/* tmp_FCX = FCX; */
+tmp_FCX = env->FCX;
+/* EA = {FCX.FCXS, 6'b0, FCX.FCXO, 6'b0}; */
+ea = ((env->FCX & MASK_FCX_FCXS) << 12) +
+ ((env->FCX & MASK_FCX_FCXO) << 6);
+/* new_FCX = M(EA, word);
+   M(EA, 16 * word) = {PCXI, PSW, A[10], A[11], D[8], D[9], D[10], D[11],
+  A[12], A[13], A[14], A[15], D[12], D[13], D[14],
+  D[15]}; */
+save_context_upper(env, ea, &new_FCX);
+
+/* PCXI.PCPN = ICR.CCPN; */
+env->PCXI = (env->PCXI & 0xff) +
+((env->ICR & MASK_ICR_CCPN) << 24);
+/* PCXI.PIE = ICR.IE; */
+env->PCXI = ((env->PCXI & ~MASK_PCXI_PIE) +
+((env->ICR & MASK_ICR_IE) << 15));
+/* PCXI.UL = 1; */
+env->PCXI |= MASK_

[Qemu-devel] [PATCH v4 04/15] target-tricore: Add initialization for translation and activate target

2014-08-07 Thread Bastian Koppelmann
Add tcg and cpu model initialization.
Add gen_intermediate_code function.
Activate target in configure and add softmmu config.

Signed-off-by: Bastian Koppelmann 
---
 configure   |   5 ++
 default-configs/tricore-softmmu.mak |   3 +
 target-tricore/translate.c  | 165 
 3 files changed, 173 insertions(+)
 create mode 100644 default-configs/tricore-softmmu.mak

diff --git a/configure b/configure
index f7685b5..5003e28 100755
--- a/configure
+++ b/configure
@@ -4965,6 +4965,9 @@ case "$target_name" in
 TARGET_BASE_ARCH=mips
 echo "TARGET_ABI_MIPSN64=y" >> $config_target_mak
   ;;
+  tricore)
+target_phys_bits=32
+  ;;
   moxie)
   ;;
   or32)
@@ -5162,6 +5165,8 @@ for i in $ARCH $TARGET_BASE_ARCH ; do
 echo "CONFIG_MIPS_DIS=y"  >> $config_target_mak
 echo "CONFIG_MIPS_DIS=y"  >> config-all-disas.mak
   ;;
+  tricore*)
+  ;;
   moxie*)
 echo "CONFIG_MOXIE_DIS=y"  >> $config_target_mak
 echo "CONFIG_MOXIE_DIS=y"  >> config-all-disas.mak
diff --git a/default-configs/tricore-softmmu.mak 
b/default-configs/tricore-softmmu.mak
new file mode 100644
index 000..48ccd12
--- /dev/null
+++ b/default-configs/tricore-softmmu.mak
@@ -0,0 +1,3 @@
+include pci.mak
+CONFIG_PFLASH_CFI01=y
+CONFIG_SMC91C111=y
diff --git a/target-tricore/translate.c b/target-tricore/translate.c
index 5bb212d..7275c49 100644
--- a/target-tricore/translate.c
+++ b/target-tricore/translate.c
@@ -26,6 +26,26 @@
 #include "exec/helper-proto.h"
 #include "exec/helper-gen.h"
 
+/*
+ * TCG registers
+ */
+static TCGv cpu_PC;
+static TCGv cpu_PCXI;
+static TCGv cpu_PSW;
+static TCGv cpu_ICR;
+/* GPR registers */
+static TCGv cpu_gpr_a[16];
+static TCGv cpu_gpr_d[16];
+/* PSW Flag cache */
+static TCGv cpu_PSW_C;
+static TCGv cpu_PSW_V;
+static TCGv cpu_PSW_SV;
+static TCGv cpu_PSW_AV;
+static TCGv cpu_PSW_SAV;
+/* CPU env */
+static TCGv_ptr cpu_env;
+
+#include "exec/gen-icount.h"
 
 static const char *regnames_a[] = {
   "a0"  , "a1"  , "a2"  , "a3" , "a4"  , "a5" ,
@@ -39,6 +59,25 @@ static const char *regnames_d[] = {
   "d12" , "d13" , "d14" , "d15",
 };
 
+typedef struct DisasContext {
+struct TranslationBlock *tb;
+target_ulong pc, saved_pc, next_pc;
+uint32_t opcode;
+int singlestep_enabled;
+/* Routine used to access memory */
+int mem_idx;
+uint32_t hflags, saved_hflags;
+int bstate;
+} DisasContext;
+
+enum {
+
+BS_NONE   = 0,
+BS_STOP   = 1,
+BS_BRANCH = 2,
+BS_EXCP   = 3,
+};
+
 void tricore_cpu_dump_state(CPUState *cs, FILE *f,
 fprintf_function cpu_fprintf, int flags)
 {
@@ -62,10 +101,88 @@ void tricore_cpu_dump_state(CPUState *cs, FILE *f,
 
 }
 
+static void decode_16Bit_opc(CPUTRICOREState *env, DisasContext *ctx)
+{
+}
+
+static void decode_32Bit_opc(CPUTRICOREState *env, DisasContext *ctx)
+{
+}
+
+static void decode_opc(CPUTRICOREState *env, DisasContext *ctx, int *is_branch)
+{
+/* 16-Bit Instruction */
+if ((ctx->opcode & 0x1) == 0) {
+ctx->next_pc = ctx->pc + 2;
+decode_16Bit_opc(env, ctx);
+/* 32-Bit Instruction */
+} else {
+ctx->next_pc = ctx->pc + 4;
+decode_32Bit_opc(env, ctx);
+}
+}
+
 static inline void
 gen_intermediate_code_internal(TRICORECPU *cpu, struct TranslationBlock *tb,
   int search_pc)
 {
+CPUState *cs = CPU(cpu);
+CPUTRICOREState *env = &cpu->env;
+DisasContext ctx;
+target_ulong pc_start;
+int num_insns;
+uint16_t *gen_opc_end;
+
+if (search_pc) {
+qemu_log("search pc %d\n", search_pc);
+}
+
+num_insns = 0;
+pc_start = tb->pc;
+gen_opc_end = tcg_ctx.gen_opc_buf + OPC_MAX_SIZE;
+ctx.pc = pc_start;
+ctx.saved_pc = -1;
+ctx.tb = tb;
+ctx.singlestep_enabled = cs->singlestep_enabled;
+ctx.bstate = BS_NONE;
+ctx.mem_idx = cpu_mmu_index(env);
+
+tcg_clear_temp_count();
+gen_tb_start();
+while (ctx.bstate == BS_NONE) {
+ctx.opcode = cpu_ldl_code(env, ctx.pc);
+decode_opc(env, &ctx, 0);
+
+num_insns++;
+
+ctx.pc = ctx.next_pc;
+if (tcg_ctx.gen_opc_ptr >= gen_opc_end) {
+break;
+}
+if (singlestep) {
+break;
+}
+}
+
+gen_tb_end(tb, num_insns);
+*tcg_ctx.gen_opc_ptr = INDEX_op_end;
+if (search_pc) {
+printf("done_generating search pc\n");
+} else {
+tb->size = ctx.pc - pc_start;
+tb->icount = num_insns;
+}
+if (tcg_check_temp_count()) {
+printf("LEAK at %08x\n", env->PC);
+}
+
+#ifdef DEBUG_DISAS
+if (qemu_loglevel_mask(CPU_LOG_TB_IN_ASM)) {
+qemu_log("IN: %s\n", lookup_symbol(pc_start));
+log_target_disas(env, pc_start, ctx.pc - pc_start, 0);
+qemu_log("\n");
+}
+#endif
 }
 
 void
@@ -93,8 +210,56 @@ restore_state_to_opc(CPUTRICOREState *env, TranslationBlock 
*tb, int pc_pos)
 
 void cpu_s

[Qemu-devel] [PATCH v4 13/15] target-tricore: Add instructions of SC opcode format

2014-08-07 Thread Bastian Koppelmann
Add instructions of SC opcode format.
Add helper for begin interrupt service routine.

Signed-off-by: Bastian Koppelmann 

Reviewed-by: Richard Henderson 
---
 target-tricore/helper.h|  1 +
 target-tricore/op_helper.c | 59 ++
 target-tricore/translate.c | 48 +
 3 files changed, 108 insertions(+)

diff --git a/target-tricore/helper.h b/target-tricore/helper.h
index adf5b26..3c73234 100644
--- a/target-tricore/helper.h
+++ b/target-tricore/helper.h
@@ -21,3 +21,4 @@ DEF_HELPER_3(sub_ssov, i32, env, i32, i32)
 /* CSA */
 DEF_HELPER_2(call, void, env, i32)
 DEF_HELPER_1(ret, void, env)
+DEF_HELPER_2(bisr, void, env, i32)
diff --git a/target-tricore/op_helper.c b/target-tricore/op_helper.c
index 0006d44..c9cf0de 100644
--- a/target-tricore/op_helper.c
+++ b/target-tricore/op_helper.c
@@ -122,6 +122,28 @@ static void save_context_upper(CPUTRICOREState *env, int 
ea,

 }

+static void save_context_lower(CPUTRICOREState *env, int ea,
+   target_ulong *new_FCX)
+{
+*new_FCX = cpu_ldl_data(env, ea);
+cpu_stl_data(env, ea, env->PCXI);
+cpu_stl_data(env, ea+4, env->PSW);
+cpu_stl_data(env, ea+8, env->gpr_a[2]);
+cpu_stl_data(env, ea+12, env->gpr_a[3]);
+cpu_stl_data(env, ea+16, env->gpr_d[0]);
+cpu_stl_data(env, ea+20, env->gpr_d[1]);
+cpu_stl_data(env, ea+24, env->gpr_d[2]);
+cpu_stl_data(env, ea+28, env->gpr_d[3]);
+cpu_stl_data(env, ea+32, env->gpr_a[4]);
+cpu_stl_data(env, ea+36, env->gpr_a[5]);
+cpu_stl_data(env, ea+40, env->gpr_a[6]);
+cpu_stl_data(env, ea+44, env->gpr_a[7]);
+cpu_stl_data(env, ea+48, env->gpr_d[4]);
+cpu_stl_data(env, ea+52, env->gpr_d[5]);
+cpu_stl_data(env, ea+56, env->gpr_d[6]);
+cpu_stl_data(env, ea+60, env->gpr_d[7]);
+}
+
 static void restore_context_upper(CPUTRICOREState *env, int ea,
   target_ulong *new_PCXI, target_ulong 
*new_PSW)
 {
@@ -243,6 +265,43 @@ void helper_ret(CPUTRICOREState *env)
 }
 }

+void helper_bisr(CPUTRICOREState *env, uint32_t const9)
+{
+target_ulong tmp_FCX;
+target_ulong ea;
+target_ulong new_FCX;
+
+if (env->FCX == 0) {
+/* FCU trap */
+}
+
+tmp_FCX = env->FCX;
+ea = ((env->FCX & 0xf) << 12) + ((env->FCX & 0x) << 6);
+
+save_context_lower(env, ea, &new_FCX);
+
+/* PCXI.PCPN = ICR.CCPN */
+env->PCXI = (env->PCXI & 0xff) +
+ ((env->ICR & MASK_ICR_CCPN) << 24);
+/* PCXI.PIE  = ICR.IE */
+env->PCXI = ((env->PCXI & ~MASK_PCXI_PIE) +
+ ((env->ICR & MASK_ICR_IE) << 15));
+/* PCXI.UL = 0 */
+env->PCXI &= ~(MASK_PCXI_UL);
+/* PCXI[19: 0] = FCX[19: 0] */
+env->PCXI = (env->PCXI & 0xfff0) + (env->FCX & 0xf);
+/* FXC[19: 0] = new_FCX[19: 0] */
+env->FCX = (env->FCX & 0xfff0) + (new_FCX & 0xf);
+/* ICR.IE = 1 */
+env->ICR |= MASK_ICR_IE;
+
+env->ICR |= const9; /* ICR.CCPN = const9[7: 0];*/
+
+if (tmp_FCX == env->LCX) {
+/* FCD trap */
+}
+}
+
 static inline void QEMU_NORETURN do_raise_exception_err(CPUTRICOREState *env,
 uint32_t exception,
 int error_code,
diff --git a/target-tricore/translate.c b/target-tricore/translate.c
index eb7be30..ce90a60 100644
--- a/target-tricore/translate.c
+++ b/target-tricore/translate.c
@@ -646,6 +646,42 @@ static void decode_ssr_opc(DisasContext *ctx, int op1)
 }
 }

+static void decode_sc_opc(DisasContext *ctx, int op1)
+{
+int32_t const16;
+
+const16 = MASK_OP_SC_CONST8(ctx->opcode);
+
+switch (op1) {
+case OPC1_16_SC_AND:
+tcg_gen_andi_tl(cpu_gpr_d[15], cpu_gpr_d[15], const16);
+break;
+case OPC1_16_SC_BISR:
+gen_helper_1arg(bisr, const16 & 0xff);
+break;
+case OPC1_16_SC_LD_A:
+gen_offset_ld(ctx, cpu_gpr_a[15], cpu_gpr_a[10], const16 * 4, MO_LESL);
+break;
+case OPC1_16_SC_LD_W:
+gen_offset_ld(ctx, cpu_gpr_d[15], cpu_gpr_a[10], const16 * 4, MO_LESL);
+break;
+case OPC1_16_SC_MOV:
+tcg_gen_movi_tl(cpu_gpr_d[15], const16);
+break;
+case OPC1_16_SC_OR:
+tcg_gen_ori_tl(cpu_gpr_d[15], cpu_gpr_d[15], const16);
+break;
+case OPC1_16_SC_ST_A:
+gen_offset_st(ctx, cpu_gpr_a[15], cpu_gpr_a[10], const16 * 4, MO_LESL);
+break;
+case OPC1_16_SC_ST_W:
+gen_offset_st(ctx, cpu_gpr_d[15], cpu_gpr_a[10], const16 * 4, MO_LESL);
+break;
+case OPC1_16_SC_SUB_A:
+tcg_gen_subi_tl(cpu_gpr_a[10], cpu_gpr_a[10], const16);
+break;
+}
+}
 static void decode_16Bit_opc(CPUTRICOREState *env, DisasContext *ctx)
 {
 int op1;
@@ -777,6 +813,18 @@ static void decode_16Bit_opc(CPUTRICOREState *env, 
DisasContext *ctx)
 address = MASK_OP_SBR_DISP4(ctx->opcode);
 gen_comp

[Qemu-devel] [PATCH v4 06/15] target-tricore: Add instructions of SRC opcode format

2014-08-07 Thread Bastian Koppelmann
Add instructions of SRC opcode format.
Add micro-op generator functions for add, conditional add/sub and shi/shai.

Signed-off-by: Bastian Koppelmann 
---
v3 -> v4:
- Remove gen_calc_psw_sv, gen_calc_psw_av, gen_calc_psw_sav functions.
- Replace gen_calc_psw_sv, gen_calc_psw_sav, gen_calc_psw_av calls.
- Rename gen_add_i32 to gen_add_d.
- Remove psw calculation from ADD_A.
- Replace makro OP_COND with function gen_cond_add, gen_cond_addi.
- gen_shaci now uses only 32 bit tcg shifts and implments special case of 
exactly 32 bit long shift.
- gen_cond_add now sets V and AV bits conditionaly through temp registers.

 target-tricore/helper.h|  16 
 target-tricore/translate.c | 222 +
 2 files changed, 238 insertions(+)

diff --git a/target-tricore/helper.h b/target-tricore/helper.h
index e69de29..5884240 100644
--- a/target-tricore/helper.h
+++ b/target-tricore/helper.h
@@ -0,0 +1,16 @@
+/*
+ *  Copyright (c) 2012-2014 Bastian Koppelmann C-Lab/University Paderborn
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ */
diff --git a/target-tricore/translate.c b/target-tricore/translate.c
index 0d30c51..ed2bf9b 100644
--- a/target-tricore/translate.c
+++ b/target-tricore/translate.c
@@ -27,6 +27,7 @@
 #include "exec/helper-gen.h"

 #include "tricore-opcodes.h"
+
 /*
  * TCG registers
  */
@@ -102,8 +103,229 @@ void tricore_cpu_dump_state(CPUState *cs, FILE *f,

 }

+/*
+ * Functions to generate micro-ops
+ */
+
+/* Functions for arithmetic instructions  */
+
+static inline void gen_add_d(TCGv ret, TCGv r1, TCGv r2)
+{
+TCGv t0 = tcg_temp_new_i32();
+/* Addition and set V/SV bits */
+tcg_gen_add_tl(ret, r1, r2);
+/* calc V bit */
+tcg_gen_xor_tl(cpu_PSW_V, ret, r1);
+tcg_gen_xor_tl(t0, r1, r2);
+tcg_gen_andc_tl(cpu_PSW_V, cpu_PSW_V, t0);
+/* Calc SV bit */
+tcg_gen_or_tl(cpu_PSW_SV, cpu_PSW_SV, cpu_PSW_V);
+/* Calc AV/SAV bits */
+tcg_gen_add_tl(cpu_PSW_AV, ret, ret);
+tcg_gen_xor_tl(cpu_PSW_AV, ret, cpu_PSW_AV);
+/* calc SAV */
+tcg_gen_or_tl(cpu_PSW_SAV, cpu_PSW_SAV, cpu_PSW_AV);
+tcg_temp_free(t0);
+}
+
+static inline void gen_addi_d(TCGv ret, TCGv r1, target_ulong r2)
+{
+TCGv temp = tcg_const_i32(r2);
+gen_add_d(ret, r1, temp);
+tcg_temp_free(temp);
+}
+
+static inline void gen_cond_add(int cond, TCGv r1, TCGv r2, TCGv r3,
+TCGv r4)
+{
+TCGv temp = tcg_temp_new();
+TCGv temp2 = tcg_temp_new();
+TCGv t0 = tcg_const_i32(0);
+
+tcg_gen_add_tl(temp, r1, r2);
+tcg_gen_movcond_tl(cond, r3, r4, t0, temp, r3);
+/* Calc PSW_V */
+tcg_gen_xor_tl(temp, temp, r1);
+tcg_gen_xor_tl(temp, r1, r2);
+tcg_gen_andc_tl(temp2, temp, t0);
+tcg_gen_movcond_tl(cond, cpu_PSW_V, r4, t0, temp2, cpu_PSW_V);
+/* Set PSW_SV */
+tcg_gen_or_tl(cpu_PSW_SV, temp2, cpu_PSW_SV);
+/* calc AV bit */
+tcg_gen_add_tl(temp2, temp2, temp);
+tcg_gen_xor_tl(temp2, temp2, temp);
+tcg_gen_movcond_tl(cond, cpu_PSW_AV, r4, t0, temp2, cpu_PSW_AV);
+/* calc SAV bit */
+tcg_gen_or_tl(cpu_PSW_SAV, temp2, cpu_PSW_SAV);
+
+tcg_temp_free(t0);
+tcg_temp_free(temp);
+tcg_temp_free(temp2);
+}
+
+static inline void gen_condi_add(int cond, TCGv r1, int32_t r2,
+ TCGv r3, TCGv r4)
+{
+TCGv temp = tcg_const_i32(r2);
+gen_cond_add(cond, r1, temp, r3, r4);
+tcg_temp_free(temp);
+}
+
+static void gen_shi(TCGv ret, TCGv r1, int32_t shift_count)
+{
+if (shift_count == -32) {
+tcg_gen_movi_tl(ret, 0);
+} else if (shift_count >= 0) {
+tcg_gen_shli_tl(ret, r1, shift_count);
+} else {
+tcg_gen_shri_tl(ret, r1, (-shift_count));
+}
+}
+
+static void gen_shaci(TCGv ret, TCGv r1, int32_t shift_count)
+{
+uint32_t msk, msk_start;
+TCGv temp = tcg_temp_new();
+TCGv temp2 = tcg_temp_new();
+TCGv t_max = tcg_const_i32(0x7FFF >> shift_count);
+TCGv t_min = tcg_const_i32(-(0x8000L) >> shift_count);
+TCGv t_0 = tcg_const_i32(0);
+
+if (shift_count == 0) {
+/* Clear PSW.C */
+tcg_gen_movi_tl(cpu_PSW_C, 0);
+tcg_gen_mov_tl(ret, r1);
+} else if (shift_count == 32) {
+/* fill ret completly with sign bit */
+tcg_gen_sari_tl(ret, r1, 31);
+} else if

[Qemu-devel] [PATCH v4 02/15] target-tricore: Add board for systemmode

2014-08-07 Thread Bastian Koppelmann
Add basic board to allow systemmode emulation

Signed-off-by: Bastian Koppelmann 
---
 hw/tricore/Makefile.objs   |   1 +
 hw/tricore/tricore_testboard.c | 129 +
 include/hw/tricore/tricore.h   |  54 +
 3 files changed, 184 insertions(+)
 create mode 100644 hw/tricore/Makefile.objs
 create mode 100644 hw/tricore/tricore_testboard.c
 create mode 100644 include/hw/tricore/tricore.h

diff --git a/hw/tricore/Makefile.objs b/hw/tricore/Makefile.objs
new file mode 100644
index 000..435e095
--- /dev/null
+++ b/hw/tricore/Makefile.objs
@@ -0,0 +1 @@
+obj-y += tricore_testboard.o
diff --git a/hw/tricore/tricore_testboard.c b/hw/tricore/tricore_testboard.c
new file mode 100644
index 000..fee67b1
--- /dev/null
+++ b/hw/tricore/tricore_testboard.c
@@ -0,0 +1,129 @@
+/*
+ * TriCore Baseboard System emulation.
+ *
+ * Copyright (c) 2014 Bastian Koppelmann
+ *
+ * This code is licensed under the GPL.
+ */
+
+#include "hw/hw.h"
+#include "hw/devices.h"
+#include "net/net.h"
+#include "sysemu/sysemu.h"
+#include "hw/boards.h"
+#include "hw/loader.h"
+#include "sysemu/blockdev.h"
+#include "exec/address-spaces.h"
+#include "hw/block/flash.h"
+#include "elf.h"
+#include "hw/tricore/tricore.h"
+
+#define TRICORE_FLASH_ADDR 0xa000
+#define TRICORE_FLASH_SIZE (2 * 1024 * 1024)
+#define TRICORE_FLASH_SECT_SIZE (256 * 1024)
+
+
+/* Board init.  */
+
+static struct tricore_boot_info tricoretb_binfo;
+
+static void tricore_load_kernel(CPUTRICOREState *env)
+{
+int64_t entry;
+long kernel_size;
+
+kernel_size = load_elf(tricoretb_binfo.kernel_filename, NULL,
+   NULL, (uint64_t *)&entry, NULL,
+   NULL, 0,
+   ELF_MACHINE, 1);
+if (kernel_size <= 0) {
+fprintf(stderr, "qemu: no kernel file '%s'\n",
+tricoretb_binfo.kernel_filename);
+exit(1);
+}
+env->PC = entry;
+
+}
+
+static void tricore_testboard_init(MachineState *machine, int board_id)
+{
+TRICORECPU *cpu;
+CPUTRICOREState *env;
+
+MemoryRegion *sysmem = get_system_memory();
+MemoryRegion *ext_cram = g_new(MemoryRegion, 1);
+MemoryRegion *ext_dram = g_new(MemoryRegion, 1);
+MemoryRegion *int_cram = g_new(MemoryRegion, 1);
+MemoryRegion *int_dram = g_new(MemoryRegion, 1);
+MemoryRegion *pcp_data = g_new(MemoryRegion, 1);
+MemoryRegion *pcp_text = g_new(MemoryRegion, 1);
+DriveInfo *dinfo;
+
+if (!machine->cpu_model) {
+machine->cpu_model = "tc1796";
+}
+cpu = cpu_tricore_init(machine->cpu_model);
+env = &cpu->env;
+if (!cpu) {
+fprintf(stderr, "Unable to find CPU definition\n");
+exit(1);
+}
+memory_region_init_ram(ext_cram, NULL, "powerlink_ext_c.ram", 2*1024*1024);
+vmstate_register_ram_global(ext_cram);
+memory_region_init_ram(ext_dram, NULL, "powerlink_ext_d.ram", 4*1024*1024);
+vmstate_register_ram_global(ext_dram);
+memory_region_init_ram(int_cram, NULL, "powerlink_int_c.ram", 48*1024);
+vmstate_register_ram_global(int_cram);
+memory_region_init_ram(int_dram, NULL, "powerlink_int_d.ram", 48*1024);
+vmstate_register_ram_global(int_dram);
+memory_region_init_ram(pcp_data, NULL, "powerlink_pcp_data.ram", 16*1024);
+vmstate_register_ram_global(pcp_data);
+memory_region_init_ram(pcp_text, NULL, "powerlink_pcp_text.ram", 32*1024);
+vmstate_register_ram_global(pcp_text);
+
+memory_region_add_subregion(sysmem, 0x8000, ext_cram);
+memory_region_add_subregion(sysmem, 0xa100, ext_dram);
+memory_region_add_subregion(sysmem, 0xd400, int_cram);
+memory_region_add_subregion(sysmem, 0xd000, int_dram);
+memory_region_add_subregion(sysmem, 0xf005, pcp_data);
+memory_region_add_subregion(sysmem, 0xf006, pcp_text);
+
+dinfo = drive_get(IF_PFLASH, 0, 0);
+if (!pflash_cfi01_register(TRICORE_FLASH_ADDR, NULL,
+  "tricore_testboard.flash",
+  TRICORE_FLASH_SIZE, dinfo ? dinfo->bdrv : NULL,
+  TRICORE_FLASH_SECT_SIZE,
+  TRICORE_FLASH_SIZE / TRICORE_FLASH_SECT_SIZE,
+  2, 0x00, 0x00, 0x, 0x0, 0)) {
+
+fprintf(stderr, "qemu: Error registering flash memory.\n");
+} else {
+env->PC = TRICORE_FLASH_ADDR;
+}
+
+tricoretb_binfo.ram_size = machine->ram_size;
+tricoretb_binfo.kernel_filename = machine->kernel_filename;
+
+if (machine->kernel_filename) {
+tricore_load_kernel(env);
+}
+}
+
+static void tricoreboard_init(MachineState *machine)
+{
+tricore_testboard_init(machine, 0x183);
+}
+
+static QEMUMachine ttb_machine = {
+.name = "TriCore testboard",
+.desc = "Just for testing",
+.init = tricoreboard_init,
+.is_default = 1,
+};
+
+static void tricore_testboard_machine_init(void)
+{
+qemu_register_machine(&ttb_machine);
+}
+

[Qemu-devel] [PATCH v4 00/15] TriCore architecture guest implementation

2014-08-07 Thread Bastian Koppelmann
Hi,

my aim is to add Infineon's TriCore architecture to QEMU. This series of 
patches adds the target stubs, a basic testboard and a softmmu for system mode 
emulation. Furthermore it adds all the 16 bit long instructions of the 
architecture grouped by opcode format.

After this series of patches. Another one will follow, which adds a lot of the 
32 bit long instructions.

All the best

Bastian

v3 -> v4:
- tricore_cpu_type_info changed to abstract.
- Change documentation of PSW_USB_AV and PSW_USB_SAV bit to only use bit 31.
- Change psw_read/_write to only use bit 31 for PSW_USB_AV and PSW_USB_SAV.
- Remove gen_calc_psw_sv, gen_calc_psw_av, gen_calc_psw_sav functions.
- Rename gen_add_i32 to gen_add_d.
- Remove psw calculation from ADD_A.
- Replace makro OP_COND with function gen_cond_add, gen_cond_addi.
- gen_shaci now uses only 32 bit tcg shifts and implments special case of 
exactly 32 bit long shift.
- gen_cond_add now sets V and AV bits conditionaly through temp registers.
- Rename gen_sub_i32 to gen_sub_d.
- Fix V bit calculation in gen_sub_d and gen_mul_i32s.
- helper_add/sub_ssov now uses sign extended arguments.
- Remove unnecessary temp register in gen_adds/_subs.
- Add missing break in gen_compute_branch at CALL insn.
- Replace movcond with setcond at RSUB insn.
- Add AV, SAV calculation to RSUB insn.

Bastian Koppelmann (15):
  target-tricore: Add target stubs and qom-cpu
  target-tricore: Add board for systemmode
  target-tricore: Add softmmu support
  target-tricore: Add initialization for translation and activate target
  target-tricore: Add masks and opcodes for decoding
  target-tricore: Add instructions of SRC opcode format
  target-tricore: Add instructions of SRR opcode format
  target-tricore: Add instructions of SSR opcode format
  target-tricore: Add instructions of SRRS and SLRO opcode format
  target-tricore: Add instructions of SB opcode format
  target-tricore: Add instructions of SBC and SBRN opcode format
  target-tricore: Add instructions of SBR opcode format
  target-tricore: Add instructions of SC opcode format
  target-tricore: Add instructions of SLR, SSRO and SRO opcode format
  target-tricore: Add instructions of SR opcode format

 arch_init.c |2 +
 configure   |5 +
 cpu-exec.c  |   11 +-
 cpus.c  |6 +
 default-configs/tricore-softmmu.mak |3 +
 hw/tricore/Makefile.objs|1 +
 hw/tricore/tricore_testboard.c  |  129 
 include/elf.h   |2 +
 include/hw/tricore/tricore.h|   54 ++
 include/sysemu/arch_init.h  |1 +
 target-tricore/Makefile.objs|1 +
 target-tricore/cpu-qom.h|   71 ++
 target-tricore/cpu.c|  191 +
 target-tricore/cpu.h|  401 ++
 target-tricore/helper.c |  144 
 target-tricore/helper.h |   25 +
 target-tricore/op_helper.c  |  392 ++
 target-tricore/translate.c  | 1222 ++
 target-tricore/tricore-defs.h   |   28 +
 target-tricore/tricore-opcodes.h| 1406 +++
 20 files changed, 4094 insertions(+), 1 deletion(-)
 create mode 100644 default-configs/tricore-softmmu.mak
 create mode 100644 hw/tricore/Makefile.objs
 create mode 100644 hw/tricore/tricore_testboard.c
 create mode 100644 include/hw/tricore/tricore.h
 create mode 100644 target-tricore/Makefile.objs
 create mode 100644 target-tricore/cpu-qom.h
 create mode 100644 target-tricore/cpu.c
 create mode 100644 target-tricore/cpu.h
 create mode 100644 target-tricore/helper.c
 create mode 100644 target-tricore/helper.h
 create mode 100644 target-tricore/op_helper.c
 create mode 100644 target-tricore/translate.c
 create mode 100644 target-tricore/tricore-defs.h
 create mode 100644 target-tricore/tricore-opcodes.h

--
2.0.4




[Qemu-devel] [PATCH v4 11/15] target-tricore: Add instructions of SBC and SBRN opcode format

2014-08-07 Thread Bastian Koppelmann
Add instructions of SBC and SBRN opcode format.

Signed-off-by: Bastian Koppelmann 

Reviewed-by: Richard Henderson 
---
 target-tricore/translate.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/target-tricore/translate.c b/target-tricore/translate.c
index 18bfffb..9a03544 100644
--- a/target-tricore/translate.c
+++ b/target-tricore/translate.c
@@ -358,6 +358,8 @@ static inline void gen_branch_condi(DisasContext *ctx, int 
cond, TCGv r1,
 static void gen_compute_branch(DisasContext *ctx, uint32_t opc, int r1,
int r2 , int32_t constant , int32_t offset)
 {
+TCGv temp;
+
 switch (opc) {
 /* SB-format jumps */
 case OPC1_16_SB_J:
@@ -374,6 +376,26 @@ static void gen_compute_branch(DisasContext *ctx, uint32_t 
opc, int r1,
 case OPC1_16_SB_JNZ:
 gen_branch_condi(ctx, TCG_COND_NE, cpu_gpr_d[15], 0, offset);
 break;
+/* SBC-format jumps */
+case OPC1_16_SBC_JEQ:
+gen_branch_condi(ctx, TCG_COND_NE, cpu_gpr_d[15], constant, offset);
+break;
+case OPC1_16_SBC_JNE:
+gen_branch_condi(ctx, TCG_COND_NE, cpu_gpr_d[15], constant, offset);
+break;
+/* SBRN-format jumps */
+case OPC1_16_SBRN_JZ_T:
+temp = tcg_temp_new();
+tcg_gen_andi_tl(temp, cpu_gpr_d[15], 0x1u << constant);
+gen_branch_condi(ctx, TCG_COND_EQ, temp, 0, offset);
+tcg_temp_free(temp);
+break;
+case OPC1_16_SBRN_JNZ_T:
+temp = tcg_temp_new();
+tcg_gen_andi_tl(temp, cpu_gpr_d[15], 0x1u << constant);
+gen_branch_condi(ctx, TCG_COND_NE, temp, 0, offset);
+tcg_temp_free(temp);
+break;
 default:
 printf("Branch Error at %x\n", ctx->pc);
 }
@@ -677,6 +699,20 @@ static void decode_16Bit_opc(CPUTRICOREState *env, 
DisasContext *ctx)
 address = MASK_OP_SB_DISP8_SEXT(ctx->opcode);
 gen_compute_branch(ctx, op1, 0, 0, 0, address);
 break;
+/* SBC-format */
+case OPC1_16_SBC_JEQ:
+case OPC1_16_SBC_JNE:
+address = MASK_OP_SBC_DISP4(ctx->opcode);
+const16 = MASK_OP_SBC_CONST4_SEXT(ctx->opcode);
+gen_compute_branch(ctx, op1, 0, 0, const16, address);
+break;
+/* SBRN-format */
+case OPC1_16_SBRN_JNZ_T:
+case OPC1_16_SBRN_JZ_T:
+address = MASK_OP_SBRN_DISP4(ctx->opcode);
+const16 = MASK_OP_SBRN_N(ctx->opcode);
+gen_compute_branch(ctx, op1, 0, 0, const16, address);
+break;
 }
 }

--
2.0.4




[Qemu-devel] [PATCH v4 05/15] target-tricore: Add masks and opcodes for decoding

2014-08-07 Thread Bastian Koppelmann
Add masks and opcodes for decoding TriCore instructions.

Signed-off-by: Bastian Koppelmann 
---
 target-tricore/translate.c   |1 +
 target-tricore/tricore-opcodes.h | 1406 ++
 2 files changed, 1407 insertions(+)
 create mode 100644 target-tricore/tricore-opcodes.h

diff --git a/target-tricore/translate.c b/target-tricore/translate.c
index 7275c49..0d30c51 100644
--- a/target-tricore/translate.c
+++ b/target-tricore/translate.c
@@ -26,6 +26,7 @@
 #include "exec/helper-proto.h"
 #include "exec/helper-gen.h"
 
+#include "tricore-opcodes.h"
 /*
  * TCG registers
  */
diff --git a/target-tricore/tricore-opcodes.h b/target-tricore/tricore-opcodes.h
new file mode 100644
index 000..9c6ec01
--- /dev/null
+++ b/target-tricore/tricore-opcodes.h
@@ -0,0 +1,1406 @@
+/*
+ *  Copyright (c) 2012-2014 Bastian Koppelmann C-Lab/University Paderborn
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ */
+
+/*
+ * Opcode Masks for Tricore
+ * Format MASK_OP_InstrFormatName_Field
+ */
+
+/* This creates a mask with bits start .. end set to 1 and applies it to op */
+#define MASK_BITS_SHIFT(op, start, end) (extract32(op, (start), \
+(end) - (start) + 1))
+#define MASK_BITS_SHIFT_SEXT(op, start, end) (sextract32(op, (start),\
+ (end) - (start) + 1))
+
+/* new opcode masks */
+
+#define MASK_OP_MAJOR(op)  MASK_BITS_SHIFT(op, 0, 7)
+
+/* 16-Bit Formats */
+#define MASK_OP_SB_DISP8(op)   MASK_BITS_SHIFT(op, 8, 15)
+#define MASK_OP_SB_DISP8_SEXT(op) MASK_BITS_SHIFT_SEXT(op, 8, 15)
+
+#define MASK_OP_SBC_CONST4(op) MASK_BITS_SHIFT(op, 12, 15)
+#define MASK_OP_SBC_CONST4_SEXT(op) MASK_BITS_SHIFT_SEXT(op, 12, 15)
+#define MASK_OP_SBC_DISP4(op)  MASK_BITS_SHIFT(op, 8, 11)
+
+#define MASK_OP_SBR_S2(op) MASK_BITS_SHIFT(op, 12, 15)
+#define MASK_OP_SBR_DISP4(op)  MASK_BITS_SHIFT(op, 8, 11)
+
+#define MASK_OP_SBRN_N(op) MASK_BITS_SHIFT(op, 12, 15)
+#define MASK_OP_SBRN_DISP4(op) MASK_BITS_SHIFT(op, 8, 11)
+
+#define MASK_OP_SC_CONST8(op)  MASK_BITS_SHIFT(op, 8, 15)
+
+#define MASK_OP_SLR_S2(op) MASK_BITS_SHIFT(op, 12, 15)
+#define MASK_OP_SLR_D(op)  MASK_BITS_SHIFT(op, 8, 11)
+
+#define MASK_OP_SLRO_OFF4(op)  MASK_BITS_SHIFT(op, 12, 15)
+#define MASK_OP_SLRO_D(op) MASK_BITS_SHIFT(op, 8, 11)
+
+#define MASK_OP_SR_OP2(op) MASK_BITS_SHIFT(op, 12, 15)
+#define MASK_OP_SR_S1D(op) MASK_BITS_SHIFT(op, 8, 11)
+
+#define MASK_OP_SRC_CONST4(op) MASK_BITS_SHIFT(op, 12, 15)
+#define MASK_OP_SRC_CONST4_SEXT(op) MASK_BITS_SHIFT_SEXT(op, 12, 15)
+#define MASK_OP_SRC_S1D(op)MASK_BITS_SHIFT(op, 8, 11)
+
+#define MASK_OP_SRO_S2(op) MASK_BITS_SHIFT(op, 12, 15)
+#define MASK_OP_SRO_OFF4(op)   MASK_BITS_SHIFT(op, 8, 11)
+
+#define MASK_OP_SRR_S2(op) MASK_BITS_SHIFT(op, 12, 15)
+#define MASK_OP_SRR_S1D(op)MASK_BITS_SHIFT(op, 8, 11)
+
+#define MASK_OP_SRRS_S2(op)MASK_BITS_SHIFT(op, 12, 15)
+#define MASK_OP_SRRS_S1D(op)   MASK_BITS_SHIFT(op, 8, 11)
+#define MASK_OP_SRRS_N(op) MASK_BITS_SHIFT(op, 6, 7)
+
+#define MASK_OP_SSR_S2(op) MASK_BITS_SHIFT(op, 12, 15)
+#define MASK_OP_SSR_S1(op) MASK_BITS_SHIFT(op, 8, 11)
+
+#define MASK_OP_SSRO_OFF4(op)  MASK_BITS_SHIFT(op, 12, 15)
+#define MASK_OP_SSRO_S1(op)MASK_BITS_SHIFT(op, 8, 11)
+
+/* 32-Bit Formats */
+
+/* ABS Format */
+#define MASK_OP_ABS_OFF18(op)  (MASK_BITS_SHIFT(op, 16, 21) +   \
+   (MASK_BITS_SHIFT(op, 28, 31) << 6) + \
+   (MASK_BITS_SHIFT(op, 22, 25) << 10) +\
+   (MASK_BITS_SHIFT(op, 12, 15) << 14))
+#define MASK_OP_ABS_OP2(op)MASK_BITS_SHIFT(op, 26, 27)
+#define MASK_OP_ABS_S1D(op)MASK_BITS_SHIFT(op, 8, 11)
+
+/* ABSB Format */
+#define MASK_OP_ABSB_OFF18(op) MASK_OP_ABS_OFF18(op)
+#define MASK_OP_ABSB_OP2(op)   MASK_BITS_SHIFT(op, 26, 27)
+#define MASK_OP_ABSB_B(op) MASK_BITS_SHIFT(op, 11, 11)
+#define MASK_OP_ABSB_BPOS(op)  MASK_BITS_SHIFT(op, 7, 10)
+
+/* B Format   */
+#define MASK_OP_B_DISP24(op)   (MASK_BITS_SHIFT(op, 16, 31) + \
+   (MASK_BITS_SHIFT(op, 8, 15) << 16))
+/* BIT Format */
+#define MASK_OP_BIT_D(op)  MASK_BITS_SHIFT(op, 28, 31)
+#define MASK_OP_BIT_POS2(op)   MASK_BITS_SHIFT(op, 23, 27)
+#define MASK_OP_BIT_OP2(op)MASK_BITS_SHIFT(op,

[Qemu-devel] [PATCH v4 09/15] target-tricore: Add instructions of SRRS and SLRO opcode format

2014-08-07 Thread Bastian Koppelmann
Add instructions of SSRS and SLRO opcode format.
Add micro-op generator functions for offset loads.

Signed-off-by: Bastian Koppelmann 

Reviewed-by: Richard Henderson 
---
 target-tricore/translate.c | 54 ++
 1 file changed, 54 insertions(+)

diff --git a/target-tricore/translate.c b/target-tricore/translate.c
index 6f696fb..5ddbc84 100644
--- a/target-tricore/translate.c
+++ b/target-tricore/translate.c
@@ -107,6 +107,26 @@ void tricore_cpu_dump_state(CPUState *cs, FILE *f,
  * Functions to generate micro-ops
  */

+/* Functions for load/save to/from memory */
+
+static inline void gen_offset_ld(DisasContext *ctx, TCGv r1, TCGv r2,
+ int16_t con, TCGMemOp mop)
+{
+TCGv temp = tcg_temp_new();
+tcg_gen_addi_tl(temp, r2, con);
+tcg_gen_qemu_ld_tl(r1, temp, ctx->mem_idx, mop);
+tcg_temp_free(temp);
+}
+
+static inline void gen_offset_st(DisasContext *ctx, TCGv r1, TCGv r2,
+ int16_t con, TCGMemOp mop)
+{
+TCGv temp = tcg_temp_new();
+tcg_gen_addi_tl(temp, r2, con);
+tcg_gen_qemu_st_tl(r1, temp, ctx->mem_idx, mop);
+tcg_temp_free(temp);
+}
+
 /* Functions for arithmetic instructions  */

 static inline void gen_add_d(TCGv ret, TCGv r1, TCGv r2)
@@ -479,6 +499,9 @@ static void decode_ssr_opc(DisasContext *ctx, int op1)
 static void decode_16Bit_opc(CPUTRICOREState *env, DisasContext *ctx)
 {
 int op1;
+int r1, r2;
+int32_t const16;
+TCGv temp;

 op1 = MASK_OP_MAJOR(ctx->opcode);

@@ -534,6 +557,37 @@ static void decode_16Bit_opc(CPUTRICOREState *env, 
DisasContext *ctx)
 case OPC1_16_SSR_ST_W_POSTINC:
 decode_ssr_opc(ctx, op1);
 break;
+/* SRRS-format */
+case OPC1_16_SRRS_ADDSC_A:
+r2 = MASK_OP_SRRS_S2(ctx->opcode);
+r1 = MASK_OP_SRRS_S1D(ctx->opcode);
+const16 = MASK_OP_SRRS_N(ctx->opcode);
+temp = tcg_temp_new();
+tcg_gen_shli_tl(temp, cpu_gpr_d[15], const16);
+tcg_gen_add_tl(cpu_gpr_a[r1], cpu_gpr_a[r2], temp);
+tcg_temp_free(temp);
+break;
+/* SLRO-format */
+case OPC1_16_SLRO_LD_A:
+r1 = MASK_OP_SLRO_D(ctx->opcode);
+const16 = MASK_OP_SLRO_OFF4(ctx->opcode);
+gen_offset_ld(ctx, cpu_gpr_a[r1], cpu_gpr_a[15], const16 * 4, MO_LESL);
+break;
+case OPC1_16_SLRO_LD_BU:
+r1 = MASK_OP_SLRO_D(ctx->opcode);
+const16 = MASK_OP_SLRO_OFF4(ctx->opcode);
+gen_offset_ld(ctx, cpu_gpr_d[r1], cpu_gpr_a[15], const16, MO_UB);
+break;
+case OPC1_16_SLRO_LD_H:
+r1 = MASK_OP_SLRO_D(ctx->opcode);
+const16 = MASK_OP_SLRO_OFF4(ctx->opcode);
+gen_offset_ld(ctx, cpu_gpr_d[r1], cpu_gpr_a[15], const16 * 2, MO_LESW);
+break;
+case OPC1_16_SLRO_LD_W:
+r1 = MASK_OP_SLRO_D(ctx->opcode);
+const16 = MASK_OP_SLRO_OFF4(ctx->opcode);
+gen_offset_ld(ctx, cpu_gpr_d[r1], cpu_gpr_a[15], const16 * 4, MO_LESL);
+break;
 }
 }

--
2.0.4




[Qemu-devel] [PATCH v4 08/15] target-tricore: Add instructions of SSR opcode format

2014-08-07 Thread Bastian Koppelmann
Add instructions of SSR opcode format.

Signed-off-by: Bastian Koppelmann 

Reviewed-by: Richard Henderson 
---
 target-tricore/translate.c | 50 ++
 1 file changed, 50 insertions(+)

diff --git a/target-tricore/translate.c b/target-tricore/translate.c
index 8778f3b..6f696fb 100644
--- a/target-tricore/translate.c
+++ b/target-tricore/translate.c
@@ -437,6 +437,45 @@ static void decode_srr_opc(DisasContext *ctx, int op1)
 }
 }

+static void decode_ssr_opc(DisasContext *ctx, int op1)
+{
+int r1, r2;
+
+r1 = MASK_OP_SSR_S1(ctx->opcode);
+r2 = MASK_OP_SSR_S2(ctx->opcode);
+
+switch (op1) {
+case OPC1_16_SSR_ST_A:
+tcg_gen_qemu_st_tl(cpu_gpr_a[r1], cpu_gpr_a[r2], ctx->mem_idx, 
MO_LEUL);
+break;
+case OPC1_16_SSR_ST_A_POSTINC:
+tcg_gen_qemu_st_tl(cpu_gpr_a[r1], cpu_gpr_a[r2], ctx->mem_idx, 
MO_LEUL);
+tcg_gen_addi_tl(cpu_gpr_a[r2], cpu_gpr_a[r2], 4);
+break;
+case OPC1_16_SSR_ST_B:
+tcg_gen_qemu_st_tl(cpu_gpr_d[r1], cpu_gpr_a[r2], ctx->mem_idx, MO_UB);
+break;
+case OPC1_16_SSR_ST_B_POSTINC:
+tcg_gen_qemu_st_tl(cpu_gpr_d[r1], cpu_gpr_a[r2], ctx->mem_idx, MO_UB);
+tcg_gen_addi_tl(cpu_gpr_a[r2], cpu_gpr_a[r2], 1);
+break;
+case OPC1_16_SSR_ST_H:
+tcg_gen_qemu_st_tl(cpu_gpr_d[r1], cpu_gpr_a[r2], ctx->mem_idx, 
MO_LEUW);
+break;
+case OPC1_16_SSR_ST_H_POSTINC:
+tcg_gen_qemu_st_tl(cpu_gpr_d[r1], cpu_gpr_a[r2], ctx->mem_idx, 
MO_LEUW);
+tcg_gen_addi_tl(cpu_gpr_a[r2], cpu_gpr_a[r2], 2);
+break;
+case OPC1_16_SSR_ST_W:
+tcg_gen_qemu_st_tl(cpu_gpr_d[r1], cpu_gpr_a[r2], ctx->mem_idx, 
MO_LEUL);
+break;
+case OPC1_16_SSR_ST_W_POSTINC:
+tcg_gen_qemu_st_tl(cpu_gpr_d[r1], cpu_gpr_a[r2], ctx->mem_idx, 
MO_LEUL);
+tcg_gen_addi_tl(cpu_gpr_a[r2], cpu_gpr_a[r2], 4);
+break;
+}
+}
+
 static void decode_16Bit_opc(CPUTRICOREState *env, DisasContext *ctx)
 {
 int op1;
@@ -484,6 +523,17 @@ static void decode_16Bit_opc(CPUTRICOREState *env, 
DisasContext *ctx)
 case OPC1_16_SRR_XOR:
 decode_srr_opc(ctx, op1);
 break;
+/* SSR-format */
+case OPC1_16_SSR_ST_A:
+case OPC1_16_SSR_ST_A_POSTINC:
+case OPC1_16_SSR_ST_B:
+case OPC1_16_SSR_ST_B_POSTINC:
+case OPC1_16_SSR_ST_H:
+case OPC1_16_SSR_ST_H_POSTINC:
+case OPC1_16_SSR_ST_W:
+case OPC1_16_SSR_ST_W_POSTINC:
+decode_ssr_opc(ctx, op1);
+break;
 }
 }

--
2.0.4




[Qemu-devel] [PATCH v4 01/15] target-tricore: Add target stubs and qom-cpu

2014-08-07 Thread Bastian Koppelmann
Add TriCore target stubs, and QOM cpu.

Signed-off-by: Bastian Koppelmann 
---
v3 -> v4:
- tricore_cpu_type_info changed to abstract.
- Change documentation of PSW_USB_AV and PSW_USB_SAV bit to only use bit 31.
- Change psw_read/_write to only use bit 31 for PSW_USB_AV and PSW_USB_SAV.

 arch_init.c   |   2 +
 cpu-exec.c|  11 +-
 cpus.c|   6 +
 include/elf.h |   2 +
 include/sysemu/arch_init.h|   1 +
 target-tricore/Makefile.objs  |   1 +
 target-tricore/cpu-qom.h  |  71 
 target-tricore/cpu.c  | 191 
 target-tricore/cpu.h  | 401 ++
 target-tricore/helper.c   |  92 ++
 target-tricore/helper.h   |   0
 target-tricore/op_helper.c|  27 +++
 target-tricore/translate.c| 100 +++
 target-tricore/tricore-defs.h |  28 +++
 14 files changed, 932 insertions(+), 1 deletion(-)
 create mode 100644 target-tricore/Makefile.objs
 create mode 100644 target-tricore/cpu-qom.h
 create mode 100644 target-tricore/cpu.c
 create mode 100644 target-tricore/cpu.h
 create mode 100644 target-tricore/helper.c
 create mode 100644 target-tricore/helper.h
 create mode 100644 target-tricore/op_helper.c
 create mode 100644 target-tricore/translate.c
 create mode 100644 target-tricore/tricore-defs.h

diff --git a/arch_init.c b/arch_init.c
index 8ddaf35..29a5821 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -104,6 +104,8 @@ int graphic_depth = 32;
 #define QEMU_ARCH QEMU_ARCH_XTENSA
 #elif defined(TARGET_UNICORE32)
 #define QEMU_ARCH QEMU_ARCH_UNICORE32
+#elif defined(TARGET_TRICORE)
+#define QEMU_ARCH QEMU_ARCH_TRICORE
 #endif

 const uint32_t arch_type = QEMU_ARCH;
diff --git a/cpu-exec.c b/cpu-exec.c
index 38e5f02..bcfa943 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -277,6 +277,7 @@ int cpu_exec(CPUArchState *env)
 #elif defined(TARGET_CRIS)
 #elif defined(TARGET_S390X)
 #elif defined(TARGET_XTENSA)
+#elif defined(TARGET_TRICORE)
 /* X */
 #else
 #error unsupported target CPU
@@ -327,7 +328,8 @@ int cpu_exec(CPUArchState *env)
 }
 #if defined(TARGET_ARM) || defined(TARGET_SPARC) || defined(TARGET_MIPS) || \
 defined(TARGET_PPC) || defined(TARGET_ALPHA) || defined(TARGET_CRIS) || \
-defined(TARGET_MICROBLAZE) || defined(TARGET_LM32) || 
defined(TARGET_UNICORE32)
+defined(TARGET_MICROBLAZE) || defined(TARGET_LM32) ||   \
+defined(TARGET_UNICORE32) || defined(TARGET_TRICORE)
 if (interrupt_request & CPU_INTERRUPT_HALT) {
 cpu->interrupt_request &= ~CPU_INTERRUPT_HALT;
 cpu->halted = 1;
@@ -443,6 +445,12 @@ int cpu_exec(CPUArchState *env)
 cc->do_interrupt(cpu);
 next_tb = 0;
 }
+#elif defined(TARGET_TRICORE)
+if ((interrupt_request & CPU_INTERRUPT_HARD)) {
+cc->do_interrupt(cpu);
+next_tb = 0;
+}
+
 #elif defined(TARGET_OPENRISC)
 {
 int idx = -1;
@@ -724,6 +732,7 @@ int cpu_exec(CPUArchState *env)
   | env->cc_dest | (env->cc_x << 4);
 #elif defined(TARGET_MICROBLAZE)
 #elif defined(TARGET_MIPS)
+#elif defined(TARGET_TRICORE)
 #elif defined(TARGET_MOXIE)
 #elif defined(TARGET_OPENRISC)
 #elif defined(TARGET_SH4)
diff --git a/cpus.c b/cpus.c
index 5e7f2cf..3262c6b 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1342,6 +1342,9 @@ CpuInfoList *qmp_query_cpus(Error **errp)
 #elif defined(TARGET_MIPS)
 MIPSCPU *mips_cpu = MIPS_CPU(cpu);
 CPUMIPSState *env = &mips_cpu->env;
+#elif defined(TARGET_TRICORE)
+TRICORECPU *tricore_cpu = TRICORE_CPU(cpu);
+CPUTRICOREState *env = &tricore_cpu->env;
 #endif

 cpu_synchronize_state(cpu);
@@ -1366,6 +1369,9 @@ CpuInfoList *qmp_query_cpus(Error **errp)
 #elif defined(TARGET_MIPS)
 info->value->has_PC = true;
 info->value->PC = env->active_tc.PC;
+#elif defined(TARGET_TRICORE)
+info->value->has_PC = true;
+info->value->PC = env->PC;
 #endif

 /* XXX: waiting for the qapi to support GSList */
diff --git a/include/elf.h b/include/elf.h
index e88d52f..70107f0 100644
--- a/include/elf.h
+++ b/include/elf.h
@@ -92,6 +92,8 @@ typedef int64_t  Elf64_Sxword;

 #define EM_SPARCV9 43  /* SPARC v9 64-bit */

+#define EM_TRICORE  44  /* Infineon TriCore */
+
 #define EM_IA_64   50  /* HP/Intel IA-64 */

 #define EM_X86_64  62  /* AMD x86-64 */
diff --git a/include/sysemu/arch_init.h b/include/sysemu/arch_init.h
index 182d48d..8939233 100644
--- a/include/sysemu/arch_init.h
+++ b/include/sysemu/arch_init.h
@@ -22,6 +22,7 @@ enum {
 QEMU_ARCH_OPENRISC = 8192,
 QEMU_ARCH_UNICORE32 = 0x4000,
 QEMU_ARCH_MOXIE = 0x8000,
+QEMU_ARCH_TRICORE = 0x1,
 };

 extern const uin

[Qemu-devel] [PATCH v4 12/15] target-tricore: Add instructions of SBR opcode format

2014-08-07 Thread Bastian Koppelmann
Add instructions of SBR opcode format.
Add gen_loop micro-op generator function.

Signed-off-by: Bastian Koppelmann 

Reviewed-by: Richard Henderson 
---
 target-tricore/translate.c | 66 +-
 1 file changed, 65 insertions(+), 1 deletion(-)

diff --git a/target-tricore/translate.c b/target-tricore/translate.c
index 9a03544..eb7be30 100644
--- a/target-tricore/translate.c
+++ b/target-tricore/translate.c
@@ -355,6 +355,18 @@ static inline void gen_branch_condi(DisasContext *ctx, int 
cond, TCGv r1,
 tcg_temp_free(temp);
 }

+static void gen_loop(DisasContext *ctx, int r1, int32_t offset)
+{
+int l1;
+l1 = gen_new_label();
+
+tcg_gen_subi_tl(cpu_gpr_a[r1], cpu_gpr_a[r1], 1);
+tcg_gen_brcondi_tl(TCG_COND_EQ, cpu_gpr_a[r1], -1, l1);
+gen_goto_tb(ctx, 1, ctx->pc + offset);
+gen_set_label(l1);
+gen_goto_tb(ctx, 0, ctx->next_pc);
+}
+
 static void gen_compute_branch(DisasContext *ctx, uint32_t opc, int r1,
int r2 , int32_t constant , int32_t offset)
 {
@@ -396,8 +408,44 @@ static void gen_compute_branch(DisasContext *ctx, uint32_t 
opc, int r1,
 gen_branch_condi(ctx, TCG_COND_NE, temp, 0, offset);
 tcg_temp_free(temp);
 break;
+/* SBR-format jumps */
+case OPC1_16_SBR_JEQ:
+gen_branch_cond(ctx, TCG_COND_NE, cpu_gpr_d[r1], cpu_gpr_d[15],
+offset);
+break;
+case OPC1_16_SBR_JNE:
+gen_branch_cond(ctx, TCG_COND_NE, cpu_gpr_d[r1], cpu_gpr_d[15],
+offset);
+break;
+case OPC1_16_SBR_JNZ:
+gen_branch_condi(ctx, TCG_COND_NE, cpu_gpr_d[r1], 0, offset);
+break;
+case OPC1_16_SBR_JNZ_A:
+gen_branch_condi(ctx, TCG_COND_NE, cpu_gpr_a[r1], 0, offset);
+break;
+case OPC1_16_SBR_JGEZ:
+gen_branch_condi(ctx, TCG_COND_GE, cpu_gpr_d[r1], 0, offset);
+break;
+case OPC1_16_SBR_JGTZ:
+gen_branch_condi(ctx, TCG_COND_GT, cpu_gpr_d[r1], 0, offset);
+break;
+case OPC1_16_SBR_JLEZ:
+gen_branch_condi(ctx, TCG_COND_LE, cpu_gpr_d[r1], 0, offset);
+break;
+case OPC1_16_SBR_JLTZ:
+gen_branch_condi(ctx, TCG_COND_LT, cpu_gpr_d[r1], 0, offset);
+break;
+case OPC1_16_SBR_JZ:
+gen_branch_condi(ctx, TCG_COND_EQ, cpu_gpr_d[r1], 0, offset);
+break;
+case OPC1_16_SBR_JZ_A:
+gen_branch_condi(ctx, TCG_COND_EQ, cpu_gpr_a[r1], 0, offset);
+break;
+case OPC1_16_SBR_LOOP:
+gen_loop(ctx, r1, offset * 2 - 32);
+break;
 default:
-printf("Branch Error at %x\n", ctx->pc);
+printf("Branch Error at %x\n", ctx->pc);
 }
 ctx->bstate = BS_BRANCH;
 }
@@ -713,6 +761,22 @@ static void decode_16Bit_opc(CPUTRICOREState *env, 
DisasContext *ctx)
 const16 = MASK_OP_SBRN_N(ctx->opcode);
 gen_compute_branch(ctx, op1, 0, 0, const16, address);
 break;
+/* SBR-format */
+case OPC1_16_SBR_JEQ:
+case OPC1_16_SBR_JGEZ:
+case OPC1_16_SBR_JGTZ:
+case OPC1_16_SBR_JLEZ:
+case OPC1_16_SBR_JLTZ:
+case OPC1_16_SBR_JNE:
+case OPC1_16_SBR_JNZ:
+case OPC1_16_SBR_JNZ_A:
+case OPC1_16_SBR_JZ:
+case OPC1_16_SBR_JZ_A:
+case OPC1_16_SBR_LOOP:
+r1 = MASK_OP_SBR_S2(ctx->opcode);
+address = MASK_OP_SBR_DISP4(ctx->opcode);
+gen_compute_branch(ctx, op1, r1, 0, 0, address);
+break;
 }
 }

--
2.0.4




[Qemu-devel] [PATCH v4 07/15] target-tricore: Add instructions of SRR opcode format

2014-08-07 Thread Bastian Koppelmann
Add instructions of SRR opcode format.
Add helper for add/sub_ssov.

Signed-off-by: Bastian Koppelmann 
---
v3 -> v4:
- Replace gen_calc_psw_sv, gen_calc_psw_sav, gen_calc_psw_av calls.
- Rename gen_sub_i32 to gen_sub_d.
- Fix V bit calculation in gen_sub_d and gen_mul_i32s.
- helper_add/sub_ssov now uses sign extended arguments.
- Remove unnecessary temp register in gen_adds/_subs.

 target-tricore/helper.h|   4 ++
 target-tricore/op_helper.c |  43 
 target-tricore/translate.c | 159 +
 3 files changed, 206 insertions(+)

diff --git a/target-tricore/helper.h b/target-tricore/helper.h
index 5884240..299bd77 100644
--- a/target-tricore/helper.h
+++ b/target-tricore/helper.h
@@ -14,3 +14,7 @@
  * You should have received a copy of the GNU Lesser General Public
  * License along with this library; if not, see .
  */
+
+/* Arithmetic */
+DEF_HELPER_3(add_ssov, i32, env, i32, i32)
+DEF_HELPER_3(sub_ssov, i32, env, i32, i32)
diff --git a/target-tricore/op_helper.c b/target-tricore/op_helper.c
index 2e5981f..6d94f0b 100644
--- a/target-tricore/op_helper.c
+++ b/target-tricore/op_helper.c
@@ -20,6 +20,49 @@
 #include "exec/helper-proto.h"
 #include "exec/cpu_ldst.h"

+#define SSOV(env, ret, arg, len) do {   \
+int64_t max_pos = INT##len ##_MAX;  \
+int64_t max_neg = INT##len ##_MIN;  \
+if (arg > max_pos) {\
+env->PSW_USB_V = 1; \
+env->PSW_USB_SV = 1;\
+ret = (target_ulong)max_pos;\
+} else {\
+if (arg < max_neg) {\
+env->PSW_USB_V = 1; \
+env->PSW_USB_SV = 1;\
+ret = (target_ulong)max_neg;\
+} else {\
+env->PSW_USB_V = 0; \
+ret = (target_ulong)arg;\
+}   \
+}   \
+env->PSW_USB_AV = arg ^ arg * 2u;   \
+env->PSW_USB_SAV |= env->PSW_USB_AV;\
+} while (0)
+
+target_ulong helper_add_ssov(CPUTRICOREState *env, target_ulong r1,
+ target_ulong r2)
+{
+target_ulong ret;
+int64_t t1 = sextract64(r1, 0, 32);
+int64_t t2 = sextract64(r2, 0, 32);
+int64_t result = t1 + t2;
+SSOV(env, ret, result, 32);
+return ret;
+}
+
+target_ulong helper_sub_ssov(CPUTRICOREState *env, target_ulong r1,
+ target_ulong r2)
+{
+target_ulong ret;
+int64_t t1 = sextract64(r1, 0, 32);
+int64_t t2 = sextract64(r2, 0, 32);
+int64_t result = t1 - t2;
+SSOV(env, ret, result, 32);
+return ret;
+}
+
 static inline void QEMU_NORETURN do_raise_exception_err(CPUTRICOREState *env,
 uint32_t exception,
 int error_code,
diff --git a/target-tricore/translate.c b/target-tricore/translate.c
index ed2bf9b..8778f3b 100644
--- a/target-tricore/translate.c
+++ b/target-tricore/translate.c
@@ -171,6 +171,48 @@ static inline void gen_condi_add(int cond, TCGv r1, 
int32_t r2,
 tcg_temp_free(temp);
 }

+static inline void gen_sub_d(TCGv ret, TCGv r1, TCGv r2)
+{
+TCGv temp = tcg_temp_new_i32();
+
+tcg_gen_sub_tl(ret, r1, r2);
+/* calc V bit */
+tcg_gen_xor_tl(cpu_PSW_V, ret, r1);
+tcg_gen_xor_tl(temp, r1, r2);
+tcg_gen_and_tl(cpu_PSW_V, cpu_PSW_V, temp);
+/* calc SV bit */
+tcg_gen_or_tl(cpu_PSW_SV, cpu_PSW_SV, cpu_PSW_V);
+/* Calc AV bit */
+tcg_gen_add_tl(cpu_PSW_AV, ret, ret);
+tcg_gen_xor_tl(cpu_PSW_AV, ret, cpu_PSW_AV);
+/* calc SAV bit */
+tcg_gen_or_tl(cpu_PSW_SAV, cpu_PSW_SAV, cpu_PSW_AV);
+
+tcg_temp_free(temp);
+}
+
+static inline void gen_mul_i32s(TCGv ret, TCGv r1, TCGv r2)
+{
+TCGv high = tcg_temp_new();
+TCGv low = tcg_temp_new();
+
+tcg_gen_muls2_tl(low, high, r1, r2);
+tcg_gen_mov_tl(ret, low);
+/* calc V bit */
+tcg_gen_sari_tl(low, low, 31);
+tcg_gen_setcond_tl(TCG_COND_NE, cpu_PSW_V, high, low);
+/* calc SV bit */
+tcg_gen_or_tl(cpu_PSW_SV, cpu_PSW_SV, cpu_PSW_V);
+/* Calc AV bit */
+tcg_gen_add_tl(cpu_PSW_AV, ret, ret);
+tcg_gen_xor_tl(cpu_PSW_AV, ret, cpu_PSW_AV);
+/* calc SAV bit */
+tcg_gen_or_tl(cpu_PSW_SAV, cpu_PSW_SAV, cpu_PSW_AV);
+
+tcg_temp_free(high);
+tcg_temp_free(low);
+}
+
 static void gen_shi(TCGv ret, TCGv r1, int32_t shift_count)
 {
 if (shift_count == -32) {
@@ -229,6 +271,16 @@ static void gen_shaci(TCGv ret, TCGv r1, int32_t 
shift_count)
 tcg_temp_free(t_min);
 }

+static inline void gen_adds(TCGv ret, TCGv r1, TCGv r2)
+{
+g

Re: [Qemu-devel] [PATCH v1 00/17] dataplane: optimization and multi virtqueue support

2014-08-07 Thread Ming Lei
On Thu, Aug 7, 2014 at 7:06 PM, Kevin Wolf  wrote:
> Am 07.08.2014 um 12:52 hat Ming Lei geschrieben:
>> On Thu, Aug 7, 2014 at 6:27 PM, Ming Lei  wrote:
>> > On Wed, Aug 6, 2014 at 11:40 PM, Kevin Wolf  wrote:
>>
>> > Also there are some problems with your patches which can't boot a
>> > VM in my environment:
>> >
>> > - __thread patch: looks there is no '__thread' used, and the patch
>> > basically makes bypass not workable.
>> >
>> > - bdrv_co_writev callback isn't set for raw-posix, looks my rootfs need to
>> > write during booting
>> >
>> > - another problem, I am investigating: laio isn't accessable
>> > in qemu_laio_process_completion() sometimes
>>
>> This one should be caused by accessing 'laiocb' after cb().
>
> I stumbled across the same problems this morning when I tried to
> actually run VMs with it instead of just qemu-img bench. They should all
> be fixed in my git repo now. (Haven't figured out yet why __thread
> doesn't work, so I have reverted that part, probably at the cost of some
> performance.)

In my test, looks no obvious performance effect by the commit, or by
pthread_getspecific() which should be fine for fast path. I also simply
revert it since __thread can't be added. Interesting, my other local change
is basically same with your change, :-)

Finally I implemented bypassing coroutine on your linux-aio coro patches,
for comparing bypass effect easily, now both are run in basically same
path except for coroutine APIs:

   git://kernel.ubuntu.com/ming/qemu.git  v2.1.0-mq.1-kevin-perf

The above branch only holds three patches which are against the
latest 'perf-bypass' branch of your tree.

Then I run it in VM on my server and still use the same fio(linux aio,
direct, 4k bs, 120sec) to test virtio-blk dataplane performance, and the
virtio-blk is backed by the /dev/nullb0 block device too.

+
-
without bypass(linux-aio coro)  |  with bypass linux-aio corou
 
---+--
1 vq, 2 jobs |101K iops  | 116K iops

4 vq, 4 jobs |121K iops  | 142K iops


Looks there is still some difference even applying linux-aio coroutine patches.

Now I am a bit more confident that coroutine is the cause of
performance difference...

Thanks,



Re: [Qemu-devel] [PATCH v5 0/8] modify boot order of guest, and take effect after rebooting

2014-08-07 Thread Gonglei (Arei)
> Subject: Re: [PATCH v5 0/8] modify boot order of guest, and take effect after
> rebooting
> 
> Il 07/08/2014 13:50, Gonglei (Arei) ha scritto:
> > Hi,
> >
> > Ping... please.
> >
> > TBH, I am confused which maintainer can maintain the patch serials about
> bootindex.
> >
> > Gerd is seemingly not in maillist later two weeks.
> >
> > Markus? Paolo? MST? PMM? Eduardo? Thanks for any help.
> 
> Gerd is on holiday, sorry.  I've left the patch review to him so far, so
> I'd rather wait for him to come back.
> 
> Paolo

OK, Thanks! Paolo.

Best regards,
-Gonglei



Re: [Qemu-devel] [PATCH v5 0/8] modify boot order of guest, and take effect after rebooting

2014-08-07 Thread Paolo Bonzini
Il 07/08/2014 13:50, Gonglei (Arei) ha scritto:
> Hi,
> 
> Ping... please. 
> 
> TBH, I am confused which maintainer can maintain the patch serials about 
> bootindex.
> 
> Gerd is seemingly not in maillist later two weeks.
> 
> Markus? Paolo? MST? PMM? Eduardo? Thanks for any help.

Gerd is on holiday, sorry.  I've left the patch review to him so far, so
I'd rather wait for him to come back.

Paolo



  1   2   >