date:20120420

Il 19/04/2012 21:34, Luiz Capitulino ha scritto:
 If this turns out to be a problem for libvirt, I'd say it's a libvirt bug.

FWIW, I agree completely.

Paolo

Re: [Qemu-devel] [PATCH 00/16] QEMU vhost-scsi support

2012-04-20 Thread ronnie sahlberg

On Fri, Apr 20, 2012 at 5:00 PM, Nicholas A. Bellinger
n...@linux-iscsi.org wrote:
 On Thu, 2012-04-19 at 19:20 -0500, Anthony Liguori wrote:
 Hi Nicholas,

 On 04/19/2012 06:53 PM, Nicholas A. Bellinger wrote:
  On Thu, 2012-04-19 at 07:30 -0500, Anthony Liguori wrote:
  However, for storage, be it scsi or direct access, the same problem really
  doesn't exist.  There isn't an obvious benefit to being in the kernel.
 
 
  In the modern Linux v3.x tree, it was decided there is an obvious
  benefit to fabric drivers developers for going ahead and putting proper
  SCSI target logic directly into the kernel..  ;)

 I'm sure there are obvious benefits to having the kernel have SCSI target 
 logic.
   I'm not claiming that there isn't.

 But there is not an obvious benefit to doing SCSI emulation *for virtual
 machine* guests in the kernel.

 Guests are unconditionally hostile.  There is no qualification here.  Public
 clouds are the obvious example of this.

 TCM runs in the absolute most privileged context possible.  When you're 
 dealing
 with extremely hostile input, it's pretty obvious that you want to run it in 
 the
 lowest privileged context as humanly possible.


 The argument that a SCSI target for virtual machines is so complex that
 it can't possibly be implemented properly in the kernel is a bunch of
 non-sense.

There are also other benefits to NOT implement scsi emulation in the
kernel, aside from the security aspect of running large amounts of
code inside kernel context vs within restricted userspace context.

I am very happy to be able to add emulation of new opcodes or new
features to tgtd WITHOUT having to recompile my kernel.


regards
ronnie sahlberg

Re: [Qemu-devel] [PATCH 00/16] QEMU vhost-scsi support

2012-04-20 Thread Nicholas A. Bellinger

On Fri, 2012-04-20 at 17:50 +1000, ronnie sahlberg wrote:
 On Fri, Apr 20, 2012 at 5:00 PM, Nicholas A. Bellinger
 n...@linux-iscsi.org wrote:
  On Thu, 2012-04-19 at 19:20 -0500, Anthony Liguori wrote:
  Hi Nicholas,
 

SNIP

  The argument that a SCSI target for virtual machines is so complex that
  it can't possibly be implemented properly in the kernel is a bunch of
  non-sense.
 
 There are also other benefits to NOT implement scsi emulation in the
 kernel, aside from the security aspect of running large amounts of
 code inside kernel context vs within restricted userspace context.
 
 I am very happy to be able to add emulation of new opcodes or new
 features to tgtd WITHOUT having to recompile my kernel.
 
 

We can certainly add new emulation to an in-kernel target w/o having to
actually rebuild vmlinuz..  You just have to ensure that target_core_mod
is being built as a loadable module.

;)

--nab

Re: [Qemu-devel] [PATCH v8 2/4] sockets: change inet_connect() to support nonblock socket

2012-04-20 Thread Orit Wasserman

On 04/20/2012 07:40 AM, Amos Kong wrote:
 Add a bool argument to inet_connect() to assign if set socket
 to block/nonblock, and delete original argument 'socktype'
 that is unused.
 Add a new argument to inet_connect()/inet_connect_opts(),
 to pass back connect error by error class.
 
 Retry to connect when -EINTR is got. Connect's successful
 for nonblock socket when following errors are got, user
 should wait for connecting by select():
   -EINPROGRESS
   -EWOULDBLOCK (win32)
   -WSAEALREADY (win32)
 
 Change nbd, vnc to use new interface.
 
 Changes from v7:
 - posix: let EWOULDBLOCK fall through to CONNECT_FAILED path
 - fix typo
 
 Signed-off-by: Amos Kong ak...@redhat.com
 ---
  nbd.c  |2 +-
  qemu-char.c|2 +-
  qemu-sockets.c |   46 +++---
  qemu_socket.h  |6 --
  ui/vnc.c   |2 +-
  5 files changed, 46 insertions(+), 12 deletions(-)
 
 diff --git a/nbd.c b/nbd.c
 index 406e555..bb71f00 100644
 --- a/nbd.c
 +++ b/nbd.c
 @@ -146,7 +146,7 @@ int tcp_socket_outgoing(const char *address, uint16_t 
 port)
  
  int tcp_socket_outgoing_spec(const char *address_and_port)
  {
 -return inet_connect(address_and_port, SOCK_STREAM);
 +return inet_connect(address_and_port, true, NULL);
  }
  
  int tcp_socket_incoming(const char *address, uint16_t port)
 diff --git a/qemu-char.c b/qemu-char.c
 index 74c60e1..aeee2e8 100644
 --- a/qemu-char.c
 +++ b/qemu-char.c
 @@ -2444,7 +2444,7 @@ static CharDriverState *qemu_chr_open_socket(QemuOpts 
 *opts)
  if (is_listen) {
  fd = inet_listen_opts(opts, 0);
  } else {
 -fd = inet_connect_opts(opts);
 +fd = inet_connect_opts(opts, NULL);
  }
  }
  if (fd  0) {
 diff --git a/qemu-sockets.c b/qemu-sockets.c
 index 6bcb8e3..66799fc 100644
 --- a/qemu-sockets.c
 +++ b/qemu-sockets.c
 @@ -51,6 +51,9 @@ static QemuOptsList dummy_opts = {
  },{
  .name = ipv6,
  .type = QEMU_OPT_BOOL,
 +},{
 +.name = block,
 +.type = QEMU_OPT_BOOL,
  },
  { /* end if list */ }
  },
 @@ -194,14 +197,15 @@ listen:
  return slisten;
  }
  
 -int inet_connect_opts(QemuOpts *opts)
 +int inet_connect_opts(QemuOpts *opts, Error **errp)
  {
  struct addrinfo ai,*res,*e;
  const char *addr;
  const char *port;
  char uaddr[INET6_ADDRSTRLEN+1];
  char uport[33];
 -int sock,rc;
 +int sock, rc, err;
 +bool block;
  
  memset(ai,0, sizeof(ai));
  ai.ai_flags = AI_CANONNAME | AI_ADDRCONFIG;
 @@ -210,8 +214,10 @@ int inet_connect_opts(QemuOpts *opts)
  
  addr = qemu_opt_get(opts, host);
  port = qemu_opt_get(opts, port);
 +block = qemu_opt_get_bool(opts, block, 0);
  if (addr == NULL || port == NULL) {
  fprintf(stderr, inet_connect: host and/or port not specified\n);
 +error_set(errp, QERR_SOCKET_CREATE_FAILED);
  return -1;
  }
  
 @@ -224,6 +230,7 @@ int inet_connect_opts(QemuOpts *opts)
  if (0 != (rc = getaddrinfo(addr, port, ai, res))) {
  fprintf(stderr,getaddrinfo(%s,%s): %s\n, addr, port,
  gai_strerror(rc));
 +error_set(errp, QERR_SOCKET_CREATE_FAILED);
   return -1;
  }
  
 @@ -241,19 +248,38 @@ int inet_connect_opts(QemuOpts *opts)
  continue;
  }
  setsockopt(sock,SOL_SOCKET,SO_REUSEADDR,(void*)on,sizeof(on));
 -
 +if (!block) {
 +socket_set_nonblock(sock);
 +}
  /* connect to peer */
 -if (connect(sock,e-ai_addr,e-ai_addrlen)  0) {
 +do {
 +err = 0;
 +if (connect(sock, e-ai_addr, e-ai_addrlen)  0) {
 +err = -socket_error();
 +}
 +} while (err == -EINTR);
 +
 +  #ifdef _WIN32
 +if (!block  (err == -EINPROGRESS || err == -EWOULDBLOCK
 +   || err == -WSAEALREADY)) {
 +  #else
 +if (!block  (err == -EINPROGRESS)) {
 +  #endif
 +error_set(errp, QERR_SOCKET_CONNECT_IN_PROGRESS);
 +}
 +if (err  0  !error_is_type(*errp, 
 QERR_SOCKET_CONNECT_IN_PROGRESS)) {
  if (NULL == e-ai_next)
  fprintf(stderr, %s: connect(%s,%s,%s,%s): %s\n, 
 __FUNCTION__,
  inet_strfamily(e-ai_family),
  e-ai_canonname, uaddr, uport, strerror(errno));
  closesocket(sock);
 +sock = -1;
  continue;
  }
  freeaddrinfo(res);
  return sock;
  }
 +error_set(errp, QERR_SOCKET_CONNECT_FAILED);
  freeaddrinfo(res);
  return -1;
  }
 @@ -449,14 +475,20 @@ int inet_listen(const char *str, char *ostr, int olen,
  return sock;
  }
  
 -int inet_connect(const char *str, int socktype)
 +int inet_connect(const char *str, bool block, Error **errp)
  {
  QemuOpts *opts;
  int sock = -1;
  
  opts =

Re: [Qemu-devel] [PATCH v8 4/4] use inet_listen()/inet_connect() to support ipv6 migration

2012-04-20 Thread Orit Wasserman

On 04/20/2012 07:43 AM, Amos Kong wrote:
 Use help functions in qemu-socket.c for tcp migration,
 which already support ipv6 addresses.
 
 Currently errp will be set to UNDEFINED_ERROR when migration fails,
 qemu would output migration failed: ..., and current user can
 see a message(An undefined error has occurred) in monitor.
 
 This patch changed tcp_start_outgoing_migration()/inet_connect()
 /inet_connect_opts(), socket error would be passed back,
 then current user can see a meaningful err message in monitor.
 
 Qemu will exit if listening fails, so output socket error
 to qemu stderr.
 
 For IPv6 brackets must be mandatory if you require a port.
 Referencing to RFC5952, the recommended format is:
   [2312::8274]:5200
 
 test status: Successed
 listen side: qemu-kvm  -incoming tcp:[2312::8274]:5200
 client side: qemu-kvm ...
  (qemu) migrate -d tcp:[2312::8274]:5200
 
 ---
 Changes from v7:
 - add unknown error process
 
 Signed-off-by: Amos Kong ak...@redhat.com
 ---
  migration-tcp.c |   77 
 +++
  migration.c |   14 ++
  migration.h |7 +++--
  vl.c|6 
  4 files changed, 38 insertions(+), 66 deletions(-)
 
 diff --git a/migration-tcp.c b/migration-tcp.c
 index 35a5781..440804d 100644
 --- a/migration-tcp.c
 +++ b/migration-tcp.c
 @@ -79,45 +79,32 @@ static void tcp_wait_for_connect(void *opaque)
  }
  }
  
 -int tcp_start_outgoing_migration(MigrationState *s, const char *host_port)
 +int tcp_start_outgoing_migration(MigrationState *s, const char *host_port,
 + Error **errp)
  {
 -struct sockaddr_in addr;
 -int ret;
 -
 -ret = parse_host_port(addr, host_port);
 -if (ret  0) {
 -return ret;
 -}
 -
  s-get_error = socket_errno;
  s-write = socket_write;
  s-close = tcp_close;
  
 -s-fd = qemu_socket(PF_INET, SOCK_STREAM, 0);
 -if (s-fd == -1) {
 -DPRINTF(Unable to open socket);
 -return -socket_error();
 -}
 -
 -socket_set_nonblock(s-fd);
 -
 -do {
 -ret = connect(s-fd, (struct sockaddr *)addr, sizeof(addr));
 -if (ret == -1) {
 -ret = -socket_error();
 -}
 -if (ret == -EINPROGRESS || ret == -EWOULDBLOCK) {
 -qemu_set_fd_handler2(s-fd, NULL, NULL, tcp_wait_for_connect, s);
 -return 0;
 -}
 -} while (ret == -EINTR);
 +s-fd = inet_connect(host_port, false, errp);
  
 -if (ret  0) {
 +if (!error_is_set(errp)) {
 +migrate_fd_connect(s);
 +} else if (error_is_type(*errp, QERR_SOCKET_CONNECT_IN_PROGRESS)) {
 +DPRINTF(connect in progress\n);
 +qemu_set_fd_handler2(s-fd, NULL, NULL, tcp_wait_for_connect, s);
 +} else if (error_is_type(*errp, QERR_SOCKET_CREATE_FAILED)) {
 +DPRINTF(connect failed\n);
 +return -1;
 +} else if (error_is_type(*errp, QERR_SOCKET_CONNECT_FAILED)) {
  DPRINTF(connect failed\n);
  migrate_fd_error(s);
 -return ret;
 +return -1;
 +} else {
 +DPRINTF(unknown error\n);
 +return -1;
  }
 -migrate_fd_connect(s);
 +
  return 0;
  }
  
 @@ -155,40 +142,18 @@ out2:
  close(s);
  }
  
 -int tcp_start_incoming_migration(const char *host_port)
 +int tcp_start_incoming_migration(const char *host_port, Error **errp)
  {
 -struct sockaddr_in addr;
 -int val;
  int s;
  
 -DPRINTF(Attempting to start an incoming migration\n);
 -
 -if (parse_host_port(addr, host_port)  0) {
 -fprintf(stderr, invalid host/port combination: %s\n, host_port);
 -return -EINVAL;
 -}
 -
 -s = qemu_socket(PF_INET, SOCK_STREAM, 0);
 -if (s == -1) {
 -return -socket_error();
 -}
 -
 -val = 1;
 -setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (const char *)val, sizeof(val));
 +s = inet_listen(host_port, NULL, 256, SOCK_STREAM, 0, errp);
  
 -if (bind(s, (struct sockaddr *)addr, sizeof(addr)) == -1) {
 -goto err;
 -}
 -if (listen(s, 1) == -1) {
 -goto err;
 +if (s  0) {
 +return -1;
  }
  
  qemu_set_fd_handler2(s, NULL, tcp_accept_incoming_migration, NULL,
   (void *)(intptr_t)s);
  
  return 0;
 -
 -err:
 -close(s);
 -return -socket_error();
  }
 diff --git a/migration.c b/migration.c
 index 94f7839..6289bc7 100644
 --- a/migration.c
 +++ b/migration.c
 @@ -60,13 +60,13 @@ static MigrationState *migrate_get_current(void)
  return current_migration;
  }
  
 -int qemu_start_incoming_migration(const char *uri)
 +int qemu_start_incoming_migration(const char *uri, Error **errp)
  {
  const char *p;
  int ret;
  
  if (strstart(uri, tcp:, p))
 -ret = tcp_start_incoming_migration(p);
 +ret = tcp_start_incoming_migration(p, errp);
  #if !defined(WIN32)
  else if (strstart(uri, exec:, p))
  ret =

Re: [Qemu-devel] [PATCH 14/20] qcow2: Factor out count_cow_clusters

Am 19.04.2012 23:18, schrieb Marcelo Tosatti:
 On Thu, Apr 19, 2012 at 05:14:20PM -0300, Marcelo Tosatti wrote:
 There is one intended change in functionality in this patch, which is
 that it allocates new clusters even when it could satisfy the first part
 of the request with already allocated clusters. In order to check if
 there is a problem with this scenario, the following patch should revert
 to the old behaviour:

 --- a/block/qcow2-cluster.c
 +++ b/block/qcow2-cluster.c
 @@ -847,7 +847,7 @@ again:
  keep_clusters = count_contiguous_clusters(nb_clusters,
 s-cluster_size,
l2_table[l2_index],
 0, 0);
  assert(keep_clusters = nb_clusters);
 -nb_clusters -= keep_clusters;
 +nb_clusters = 0;
  } else {
  /* For the moment, overwrite compressed clusters one by one */
  if (cluster_offset  QCOW_OFLAG_COMPRESSED) {

 The rest is meant to be a functionally equivalent rewrite of the old
 code that was required in order to allow this change.

 Testing.
 
 Corruption gone with patch above.

Okay, so something must be wrong only with the new code paths, which
makes things a bit easier. I'll have another closer look. Stefan, can
you re-review 250196f1 as well?

Kevin

Re: [Qemu-devel] [PATCH 00/16] QEMU vhost-scsi support

Il 20/04/2012 09:00, Nicholas A. Bellinger ha scritto:
 On Thu, 2012-04-19 at 19:20 -0500, Anthony Liguori wrote:
 TCM runs in the absolute most privileged context possible.  When you're 
 dealing 
 with extremely hostile input, it's pretty obvious that you want to run it in 
 the 
 lowest privileged context as humanly possible.
 
 The argument that a SCSI target for virtual machines is so complex that
 it can't possibly be implemented properly in the kernel is a bunch of
 non-sense.

I agree.  A VM is not any more hostile than another iSCSI initiator.
lio _always_ must assume to operates in a hostile environment.

 Being able to identify which virtio-scsi guests can actually connect via
 vhost-scsi into individual tcm_vhost endpoints is step one here.

Yes, the ACL system in lio is quite good for this.

 Well, using a raw device from userspace there is still going to be a
 SG-IO memcpy going on here between user - kernel in current code,
 yes..?
 
 Being able to deliver interrupts and SGL memory directly into tcm_vhost
 cmwq kernel context for backend device execution w/o QEMU userspace
 involvement or extra SGL memcpy is the perceived performance benefit
 here.
 
 How much benefit will this actually provide across single port and multi
 port tcm_vhost LUNs into a single guest..?  That still remains to be
 demonstrated with performance+throughput benchmarks..

Yes, this is the key.

The problems I have with vhost-scsi are, from easiest to hardest:

- completely different configuration mechanism with respect to the
in-QEMU target (fix: need to integrate configfs into scsi-{disk,generic}).

- no support for migration (there can be pending SCSI requests at
migration time, that need to be restarted on the destination)

- no support for non-raw images (fix: use NBD on a Unix socket? perhaps
add an NBD backend to lio)

- cannot migrate from lio-target to QEMU-target and vice versa.

The first three are definitely fixable.

 In order for QEMU userspace to support this, Linux would need to expose
 a method to userspace for issuing DIF protected CDBs.  This userspace
 API currently does not exist AFAIK, so a kernel-level approach is the
 currently the only option when it comes to supporting end-to-end block
 protection information originating from within Linux guests.

I think it would be worthwhile to have this in userspace too.

 (Note this is going to involve a virtio-scsi spec rev as well)

Yes.  By the way, another possible modification could be to tell the
guest what is its (initiator) WWPN.

Paolo

Re: [Qemu-devel] [PATCH v3] qemu-img: let 'qemu-img convert' flush data

Am 13.04.2012 11:17, schrieb Liu Yuan:
 From: Liu Yuan tailai...@taobao.com
 
 The 'qemu-img convert -h' advertise that the default cache mode is
 'writeback', while in fact it is 'unsafe'.
 
 This patch 1) fix the help manual and 2) let bdrv_close() call bdrv_flush()
 
 2) is needed because some backend storage doesn't have a self-flush
 mechanism(for e.g., sheepdog), so we need to call bdrv_flush() to make
 sure the image is really writen to the storage instead of hanging around
 writeback cache forever.
 
 Signed-off-by: Liu Yuan tailai...@taobao.com
 ---
  block.c|1 +
  qemu-img.c |4 ++--
  2 files changed, 3 insertions(+), 2 deletions(-)
 
 diff --git a/block.c b/block.c
 index c0c90f0..1ee2bf0 100644
 --- a/block.c
 +++ b/block.c
 @@ -812,6 +812,7 @@ unlink_and_fail:
  
  void bdrv_close(BlockDriverState *bs)
  {
 +bdrv_flush(bs);
  if (bs-drv) {
  if (bs-job) {
  block_job_cancel_sync(bs-job);
 diff --git a/qemu-img.c b/qemu-img.c
 index 6a61ca8..6e54db3 100644
 --- a/qemu-img.c
 +++ b/qemu-img.c
 @@ -66,8 +66,8 @@ static void help(void)
   'filename' is a disk image filename\n
   'fmt' is the disk image format. It is guessed automatically in 
 most cases\n
   'cache' is the cache mode used to write the output disk image, 
 the valid\n
 -   options are: 'none', 'writeback' (default), 'writethrough', 
 'directsync'\n
 -   and 'unsafe'\n
 +   options are: 'none', 'writeback', 'writethrough', 
 'directsync'\n
 +   and 'unsafe' (default)\n
   'size' is the disk image size in bytes. Optional suffixes\n
 'k' or 'K' (kilobyte, 1024), 'M' (megabyte, 1024k), 'G' 
 (gigabyte, 1024M)\n
 and T (terabyte, 1024G) are supported. 'b' is ignored.\n

You can't say it like this, this would apply to all qemu subcommands.
qemu-img only uses unsafe when it doesn't harm the integrity of the
image, which is only the case for qemu-img convert. I think we need to
say something like:

options are: 'none', 'writeback' (default, except for convert),
'writethrough', 'directsync' and 'unsafe' (default for convert)

Kevin

Re: [Qemu-devel] Intermittent e1000 failure on qemu-kvm 1.0

2012-04-20 Thread Chris Webb

Hi. Sorry for the slow follow-up.

Stefan Hajnoczi stefa...@gmail.com writes:

 Yes, it's odd that QEMU changes make the issue go away but tcpdump
 suggests the packet is not being sent from the bridge to the tap
 device.

Indeed. I really don't understand how to the two could possible interact!

 e1000 and rtl8139 both use the same QEMU network subsystem code.  I
 don't see an obvious difference between the two.

I wondered whether it could be some sort of checksum offloading which
doesn't apply for virtio or rtl8139, but otherwise I agree it's extremely
strange.

 Since this issue only happens once in many QEMU runs are you sure that
 -usbdevice tablet really makes the issue go away?

I ran in a tight loop without it for around 500 iterations, and have done so
again to confirm. Typically it fails within 20-40 iterations with -usbdevice
tablet present.

 Are you using ebtables?  I know you mentioned disabling iptables and
 it would be good to try the same for ebtables if you use it.

We're normally using ebtables, but I completely flushed all the tables and
set policy of ACCEPT for these tests to eliminate the possibility of bugs in
my table create code.

 In order to debug the host networking issue you may be able to use
 ebtables/iptables LOG targets to collect information on how far
 exactly the packets are getting.  For example, you could try logging
 all packets destined for the guest MAC address - and if the log
 information includes the network interface you should see the packet
 move between its source, the bridge, and the destination interface.  I
 have never tried this but it might work.

I will have a play with this.

Cheers,

Chris.

Re: [Qemu-devel] [PATCH 3/4] Switch from array based resource allocation to list

2012-04-20 Thread Alexey Korolev


[...]
 [Patch 5]
 Track-alignment-explicitly
 Almost the same as the previous, just changed priority from r-align to 
 r-sum when setting start address of root regions.

 I guess there are more chances to fit memory regions if we try place regions 
 with higher r-sum like it was before.
 Consider default config
 #define BUILD_PCIMEM_START   0xe000
 #define BUILD_PCIMEM_END  0xfec0

 Image we have 1 pref. mem. region of 128MB. And many small memory regions 
 which take rest of available 492MB - 128MB
 If we have alignment priority.
 PCI pref memory region will start from F000 
 and
 PCI memoryregion will start from 0xe000
 and do not fit.

The section with the lowest alignment would get allocated first and be
at a higher address.  So, in your example, the regular memory region
would be assigned 0xe800 and then pref mem would be assigned
0xe000.

Your example is why alignment should be used instead of size.  If size
is used, then what you cite above occurs (pref mem has the lower size
and is thus allocated first at the higher address).

Ahh the lowest alignment! In other words if we go from PCIMEM_START to 
PCIMEM_END we first
assign address range for the region with the largest PCI resource size (highest 
alignment). 
I see. I will put it back then.


On patch 10, it would be preferable to separate the dynamic
calculation of sum/alignment changes from the 64bit support.
Otherwise, the core algorithm of patch 10 looks okay.  Though it seems
like the code is recalculating sum/alignment more than needed, and I
think the list manipulation in pci_region_migrate_64bit_entries could
be streamlined.
Right, sum/alignment recalculation is important for migration. Will split it 
and submit new series.

Thanks,
Alexey

Re: [Qemu-devel] [PATCH 09/15] target-i386: Add property getter for CPU model

Am 20.04.2012 02:14, schrieb Michael Roth:
 On Wed, Apr 18, 2012 at 01:11:13AM +0200, Andreas Färber wrote:
 Signed-off-by: Andreas Färber afaer...@suse.de
 ---
  target-i386/cpu.c |   14 +-
  1 files changed, 13 insertions(+), 1 deletions(-)

 diff --git a/target-i386/cpu.c b/target-i386/cpu.c
 index 21041b5..2beb3ab 100644
 --- a/target-i386/cpu.c
 +++ b/target-i386/cpu.c
 @@ -640,6 +640,18 @@ static void x86_cpuid_version_set_family(Object *obj, 
 Visitor *v, void *opaque,
  }
  }
  
 +static void x86_cpuid_version_get_model(Object *obj, Visitor *v, void 
 *opaque,
 +const char *name, Error **errp)
 +{
 +X86CPU *cpu = X86_CPU(obj);
 +CPUX86State *env = cpu-env;
 +int64_t value;
 +
 +value = (env-cpuid_version  4)  0xf;
 +value |= (env-cpuid_version  16)  0xf;
 
 I think this needs to be:
 
 value |= ((env-cpuid_version  16)  0xf)  4;

You're right! Thanks for catching this.

/-F

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

[Qemu-devel] [PATCH v4] qemu-img: let 'qemu-img convert' flush data

2012-04-20 Thread Liu Yuan

From: Liu Yuan tailai...@taobao.com

The 'qemu-img convert -h' advertise that the default cache mode is
'writeback', while in fact it is 'unsafe'.

This patch 1) fix the help manual and 2) let bdrv_close() call bdrv_flush()

2) is needed because some backend storage doesn't have a self-flush
mechanism(for e.g., sheepdog), so we need to call bdrv_flush() to make
sure the image is really writen to the storage instead of hanging around
writeback cache forever.

Signed-off-by: Liu Yuan tailai...@taobao.com
---
 block.c|1 +
 qemu-img.c |4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/block.c b/block.c
index c0c90f0..1ee2bf0 100644
--- a/block.c
+++ b/block.c
@@ -812,6 +812,7 @@ unlink_and_fail:
 
 void bdrv_close(BlockDriverState *bs)
 {
+bdrv_flush(bs);
 if (bs-drv) {
 if (bs-job) {
 block_job_cancel_sync(bs-job);
diff --git a/qemu-img.c b/qemu-img.c
index 6a61ca8..0ae543c 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -66,8 +66,8 @@ static void help(void)
  'filename' is a disk image filename\n
  'fmt' is the disk image format. It is guessed automatically in 
most cases\n
  'cache' is the cache mode used to write the output disk image, 
the valid\n
-   options are: 'none', 'writeback' (default), 'writethrough', 
'directsync'\n
-   and 'unsafe'\n
+   options are: 'none', 'writeback' (default, except for 
convert), 'writethrough',\n
+   'directsync' and 'unsafe' (default for convert)\n
  'size' is the disk image size in bytes. Optional suffixes\n
'k' or 'K' (kilobyte, 1024), 'M' (megabyte, 1024k), 'G' 
(gigabyte, 1024M)\n
and T (terabyte, 1024G) are supported. 'b' is ignored.\n
-- 
1.7.8.2

Re: [Qemu-devel] [PATCH v4] qemu-img: let 'qemu-img convert' flush data

Am 20.04.2012 11:10, schrieb Liu Yuan:
 From: Liu Yuan tailai...@taobao.com
 
 The 'qemu-img convert -h' advertise that the default cache mode is
 'writeback', while in fact it is 'unsafe'.
 
 This patch 1) fix the help manual and 2) let bdrv_close() call bdrv_flush()
 
 2) is needed because some backend storage doesn't have a self-flush
 mechanism(for e.g., sheepdog), so we need to call bdrv_flush() to make
 sure the image is really writen to the storage instead of hanging around
 writeback cache forever.
 
 Signed-off-by: Liu Yuan tailai...@taobao.com

Thanks, applied to the block branch.

Kevin

Re: [Qemu-devel] SD card subsystem synchronous I/O

On Fri, Apr 20, 2012 at 12:21 AM, andrzej zaborowski balr...@gmail.com wrote:
 On 18 April 2012 14:35, Stefan Hajnoczi stefa...@gmail.com wrote:
 Recently there have been new SD card emulation patches so I want to
 raise the issue of synchronous I/O while there is focus on the SD
 subsystem.  Maybe some of the people who are improving the SD
 subsystem will be able to help.

 sd_blk_read() and sd_blk_write() use the synchronous block I/O
 functions to read/write data on behalf of the guest.  Device emulation
 runs in the vcpu thread with the QEMU global mutex held, and therefore
 both the guest vcpu and QEMU's own monitor and VNC server are
 unresponsive while bdrv_read()/bdrv_write() is blocked.

 This makes bdrv_read()/bdrv_write() in device emulation code a
 performance problem - the guest becomes unresponsive and laggy under
 heavy I/O.  In extreme cases, like image files on NFS with a network
 connectivity issue, it can affect the reliability of QEMU as a whole
 because the monitor and VNC are unavailable until the I/O operation
 completes.

 Device emulation should use the bdrv_aio_readv()/bdrv_aio_writev()
 functions so that control can return to the guest.  When the I/O
 operation completes a callback function is invoked and the device
 emulation can signal completion to the guest - usually by setting bits
 in hardware registers and raising an interrupt.  The result is good
 responsiveness and the monitor/VNC remain available even under heavy
 I/O.

 The challenge is how to convert hw/sd.c and possibly update emulated
 SD controllers.  We need to stop assuming that a read/write operation
 can be performed instantly and need to use a
 bdrv_aio_readv()/bdrv_aio_writev() callback function to complete the
 I/O.

 Since I am not familiar with the SD specification or the hw/sd.c code
 very well I want to check:

 * Is anyone willing to convert the SD subsystem?

 * Will it be possible to convert just hw/sd.c without affecting
 emulated SD controllers?
  * If we're going to need to fix all controllers in addition to
 hw/sd.c, then adding more controllers grows the problem.

 Yes, controllers would be affected, but there are various ways to go
 about it.  Some could be simple to implement (looking at
 pxa2xx_mmci.c).  First of all the SD specification pretty much assumes
 the storage medium is flash and data is available immediately after
 it is requested.  The host drives the clock and there's a fixed number
 of cycles that pass between a command and the response.  There's a
 mechanism for the card to indicate it is busy programming after data
 is written, but it doesn't apply to some types of writes.

 However the number of cycles between command and response can be
 different between card manufacturers, so it looks like the card can
 pull either the CMD and the DAT line high before starting to send the
 command response or the data.  In qemu you could either make the data
 transfers async, or the response transfers async, there's no need to
 do both.

 If the image is on a network filesystem then there could be problems
 caused by the synchronous IO.  Anything else, I'd guess that the
 caches, readahead and what not make sync IO the same or unnoticeably
 faster overall.  pxa2xx_mmci.c would be easy to convert to async, but
 some host controllers that are more software than hardware might
 theoretically give up if the card doesn't respond in N cycles.

Even in a case where the bus specification is strict about timing it's
possible that the controllers that guest drivers talk to hide those
details and instead work on an interrupt-driven basis.

In other words, maybe most of the work will be converting controllers
to implement the busy state while we do actual block I/O.  Is this
possible or do SD controllers expose the real low-level timing aspects
of the bus to the guest drivers?

Stefan

Re: [Qemu-devel] Compile/link errors

Am 24.02.2012 19:24, schrieb Anthony Liguori:
 On 02/24/2012 12:09 PM, Andreas Färber wrote:
 Am 24.02.2012 18:27, schrieb Anthony Liguori:
 On 02/24/2012 11:11 AM, Gerhard Wiesinger wrote:
 Hello,

 I'm having compile/link errors on
 85f38553031b1a6e07f786c9ab0d403af7252b4f:
 LINK x86_64-softmmu/qemu-system-x86_64
 ../libhw64/virtio-pci.o: In function `virtio_scsi_exit_pci':
 /root/download/qemu/git/qemu/hw/virtio-pci.c:956: undefined
 reference to
 `virtio_scsi_exit'
 ../libhw64/virtio-pci.o: In function `virtio_scsi_init_pci':
 /root/download/qemu/git/qemu/hw/virtio-pci.c:939: undefined
 reference to
 `virtio_scsi_init'
 collect2: ld returned 1 exit status

 Clean compile.

 Any ideas?

 You have a stale configuration file.  A 'make distclean' should help.

 Such errors indicate a dependency issue that should be fixed though.
 (Same error here. Rebuilding after rm -rf * worked.)

 When I change target-specific default configs it always seemed to work
 okay, is pci.mak different in any way? Or maybe some make target is
 lacking a dependency on the regenerated config files?
 
 %/config-devices.mak: default-configs/%.mak
 
 I think you could add default-configs/pci.mak to this stanza and it
 would have regenerated here.

I've revisited this now, and it seems that scripts/make_device_config.sh
already generates a .d file for each generated config, so in theory your
suggestion should not be necessary.

I wonder if the issue is that that dependency file says
x86_64-softmmu/default-configs.mak: /path/to/default-configs/pci.mak
rather than just default-configs.mak: /path/to/default-configs/pci.mak?

Andreas

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

[Qemu-devel] [PATCH 0/5] qemu-timer: Clean code

These patches remove timer code which is no longer needed
and try to improve the remaining code.

[PATCH 1/5] qemu-timer: Remove redundant include statements
[PATCH 2/5] qemu-timer: Remove unused function qemu_alarm_pending
[PATCH 3/5] qemu-timer: Use bool, false, true for boolean values
[PATCH 4/5] qemu-timer: Remove function alarm_has_dynticks
[PATCH 5/5] qemu-timer: Optimize data structures

[Qemu-devel] [PATCH 4/5] qemu-timer: Remove function alarm_has_dynticks

Some time ago, the last time which did not have dynticks was removed,
so now all timers have dynticks.

I also removed a misleading error message for the dynticks timer.
If timer_create fails, there is already an error message, and
QEMU will use the unix timer which also provides dynamic ticks,
therefore dynamic ticks are not disabled.

Signed-off-by: Stefan Weil s...@weilnetz.de
---
 qemu-timer.c |   31 ++-
 1 files changed, 6 insertions(+), 25 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 73ffe25..1fbc2df 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -87,11 +87,6 @@ static bool qemu_timer_expired_ns(QEMUTimer *timer_head, 
int64_t current_time)
 return timer_head  (timer_head-expire_time = current_time);
 }
 
-static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
-{
-return !!t-rearm;
-}
-
 static int64_t qemu_next_alarm_deadline(void)
 {
 int64_t delta;
@@ -124,7 +119,6 @@ static int64_t qemu_next_alarm_deadline(void)
 static void qemu_rearm_alarm_timer(struct qemu_alarm_timer *t)
 {
 int64_t nearest_delta_ns;
-assert(alarm_has_dynticks(t));
 if (!rt_clock-active_timers 
 !vm_clock-active_timers 
 !host_clock-active_timers) {
@@ -483,9 +477,8 @@ static void host_alarm_handler(int host_signum)
 if (!t)
return;
 
-if (alarm_has_dynticks(t) ||
-qemu_next_alarm_deadline () = 0) {
-t-expired = alarm_has_dynticks(t);
+if (qemu_next_alarm_deadline() = 0) {
+t-expired = true;
 t-pending = true;
 qemu_notify_event();
 }
@@ -524,10 +517,6 @@ static int dynticks_start_timer(struct qemu_alarm_timer *t)
 
 if (timer_create(CLOCK_REALTIME, ev, host_timer)) {
 perror(timer_create);
-
-/* disable dynticks */
-fprintf(stderr, Dynamic Ticks disabled\n);
-
 return -1;
 }
 
@@ -636,8 +625,8 @@ static void CALLBACK mm_alarm_handler(UINT uTimerID, UINT 
uMsg,
 if (!t) {
 return;
 }
-if (alarm_has_dynticks(t) || qemu_next_alarm_deadline() = 0) {
-t-expired = alarm_has_dynticks(t);
+if (qemu_next_alarm_deadline() = 0) {
+t-expired = true;
 t-pending = true;
 qemu_notify_event();
 }
@@ -646,7 +635,6 @@ static void CALLBACK mm_alarm_handler(UINT uTimerID, UINT 
uMsg,
 static int mm_start_timer(struct qemu_alarm_timer *t)
 {
 TIMECAPS tc;
-UINT flags;
 
 memset(tc, 0, sizeof(tc));
 timeGetDevCaps(tc, sizeof(tc));
@@ -654,18 +642,11 @@ static int mm_start_timer(struct qemu_alarm_timer *t)
 mm_period = tc.wPeriodMin;
 timeBeginPeriod(mm_period);
 
-flags = TIME_CALLBACK_FUNCTION;
-if (alarm_has_dynticks(t)) {
-flags |= TIME_ONESHOT;
-} else {
-flags |= TIME_PERIODIC;
-}
-
 mm_timer = timeSetEvent(1,  /* interval (ms) */
 mm_period,  /* resolution */
 mm_alarm_handler,   /* function */
 (DWORD_PTR)t,   /* parameter */
-flags);
+TIME_ONESHOT | TIME_CALLBACK_FUNCTION);
 
 if (!mm_timer) {
 fprintf(stderr, Failed to initialize win32 alarm timer: %ld\n,
@@ -720,7 +701,7 @@ static int win32_start_timer(struct qemu_alarm_timer *t)
   host_alarm_handler,
   t,
   1,
-  alarm_has_dynticks(t) ? 360 : 1,
+  360,
   WT_EXECUTEINTIMERTHREAD);
 
 if (!success) {
-- 
1.7.9

[Qemu-devel] [PATCH 2/5] qemu-timer: Remove unused function qemu_alarm_pending

The last user of this function was removed by commit
12d4536f7d911b6d87a766ad7300482ea663cea2.

Signed-off-by: Stefan Weil s...@weilnetz.de
---
 qemu-timer.c |5 -
 qemu-timer.h |1 -
 2 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 87d9636..38adb0d 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -87,11 +87,6 @@ static bool qemu_timer_expired_ns(QEMUTimer *timer_head, 
int64_t current_time)
 return timer_head  (timer_head-expire_time = current_time);
 }
 
-int qemu_alarm_pending(void)
-{
-return alarm_timer-pending;
-}
-
 static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
 {
 return !!t-rearm;
diff --git a/qemu-timer.h b/qemu-timer.h
index 1cfc9e0..dfb0744 100644
--- a/qemu-timer.h
+++ b/qemu-timer.h
@@ -55,7 +55,6 @@ uint64_t qemu_timer_expire_time_ns(QEMUTimer *ts);
 
 void qemu_run_timers(QEMUClock *clock);
 void qemu_run_all_timers(void);
-int qemu_alarm_pending(void);
 void configure_alarms(char const *opt);
 int qemu_calculate_timeout(void);
 void init_clocks(void);
-- 
1.7.9

Re: [Qemu-devel] [PATCH 2/2] Expose tsc deadline timer cpuid to guest

2012-04-20 Thread Jan Kiszka

On 2012-04-19 22:03, Eduardo Habkost wrote:
 Jan/Avi: ping?
 
 I would like to get this ABI detail clarified so it can be implemented
 the right way on Qemu and KVM.
 
 My proposal is to simply add tsc-deadline to the data returned by
 GET_SUPPORTED_CPUID, making KVM_CAP_TSC_DEADLINE_TIMER unnecessary.
 

IIRC, there were problems with this model to exclude that the feature
gets reported this way without ensuring that in-kernel irqchip is
actually activated. Please browse the discussions, it should be
documented there.

Jan

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

Re: [Qemu-devel] [PATCH 4/5] qemu-timer: Remove function alarm_has_dynticks

Il 20/04/2012 12:03, Stefan Weil ha scritto:
 Some time ago, the last time which did not have dynticks was removed,
 so now all timers have dynticks.
 
 I also removed a misleading error message for the dynticks timer.
 If timer_create fails, there is already an error message, and
 QEMU will use the unix timer which also provides dynamic ticks,
 therefore dynamic ticks are not disabled.
 
 Signed-off-by: Stefan Weil s...@weilnetz.de
 ---
  qemu-timer.c |   31 ++-
  1 files changed, 6 insertions(+), 25 deletions(-)
 
 diff --git a/qemu-timer.c b/qemu-timer.c
 index 73ffe25..1fbc2df 100644
 --- a/qemu-timer.c
 +++ b/qemu-timer.c
 @@ -87,11 +87,6 @@ static bool qemu_timer_expired_ns(QEMUTimer *timer_head, 
 int64_t current_time)
  return timer_head  (timer_head-expire_time = current_time);
  }
  
 -static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
 -{
 -return !!t-rearm;
 -}
 -
  static int64_t qemu_next_alarm_deadline(void)
  {
  int64_t delta;
 @@ -124,7 +119,6 @@ static int64_t qemu_next_alarm_deadline(void)
  static void qemu_rearm_alarm_timer(struct qemu_alarm_timer *t)
  {
  int64_t nearest_delta_ns;
 -assert(alarm_has_dynticks(t));
  if (!rt_clock-active_timers 
  !vm_clock-active_timers 
  !host_clock-active_timers) {
 @@ -483,9 +477,8 @@ static void host_alarm_handler(int host_signum)
  if (!t)
   return;
  
 -if (alarm_has_dynticks(t) ||
 -qemu_next_alarm_deadline () = 0) {
 -t-expired = alarm_has_dynticks(t);
 +if (qemu_next_alarm_deadline() = 0) {

This is actually if (true).

 +t-expired = true;
  t-pending = true;
  qemu_notify_event();
  }
 @@ -524,10 +517,6 @@ static int dynticks_start_timer(struct qemu_alarm_timer 
 *t)
  
  if (timer_create(CLOCK_REALTIME, ev, host_timer)) {
  perror(timer_create);
 -
 -/* disable dynticks */
 -fprintf(stderr, Dynamic Ticks disabled\n);
 -
  return -1;
  }
  
 @@ -636,8 +625,8 @@ static void CALLBACK mm_alarm_handler(UINT uTimerID, UINT 
 uMsg,
  if (!t) {
  return;
  }
 -if (alarm_has_dynticks(t) || qemu_next_alarm_deadline() = 0) {
 -t-expired = alarm_has_dynticks(t);
 +if (qemu_next_alarm_deadline() = 0) {
 +t-expired = true;
  t-pending = true;
  qemu_notify_event();
  }

This too.

Otherwise the series look good, thanks!

Paolo

 @@ -646,7 +635,6 @@ static void CALLBACK mm_alarm_handler(UINT uTimerID, UINT 
 uMsg,
  static int mm_start_timer(struct qemu_alarm_timer *t)
  {
  TIMECAPS tc;
 -UINT flags;
  
  memset(tc, 0, sizeof(tc));
  timeGetDevCaps(tc, sizeof(tc));
 @@ -654,18 +642,11 @@ static int mm_start_timer(struct qemu_alarm_timer *t)
  mm_period = tc.wPeriodMin;
  timeBeginPeriod(mm_period);
  
 -flags = TIME_CALLBACK_FUNCTION;
 -if (alarm_has_dynticks(t)) {
 -flags |= TIME_ONESHOT;
 -} else {
 -flags |= TIME_PERIODIC;
 -}
 -
  mm_timer = timeSetEvent(1,  /* interval (ms) */
  mm_period,  /* resolution */
  mm_alarm_handler,   /* function */
  (DWORD_PTR)t,   /* parameter */
 -flags);
 +TIME_ONESHOT | TIME_CALLBACK_FUNCTION);
  
  if (!mm_timer) {
  fprintf(stderr, Failed to initialize win32 alarm timer: %ld\n,
 @@ -720,7 +701,7 @@ static int win32_start_timer(struct qemu_alarm_timer *t)
host_alarm_handler,
t,
1,
 -  alarm_has_dynticks(t) ? 360 : 1,
 +  360,
WT_EXECUTEINTIMERTHREAD);
  
  if (!success) {

Re: [Qemu-devel] [PULL 00/20] Block patches

Am 13.03.2012 03:23, schrieb Anthony Liguori:
 On 03/12/2012 10:19 AM, Kevin Wolf wrote:
 The following changes since commit
 a348f108842fb928563865c9918642900cd0d477:

Add missing const attributes for MemoryRegionOps (2012-03-11
 11:40:15 +)

 are available in the git repository at:
git://repo.or.cz/qemu/kevin.git for-anthony

 Alex Barcelo (4):
coroutine: adding sigaltstack method (.c source)
coroutine: adding configure choose mechanism for coroutine backend
coroutine: adding configure option for sigaltstack coroutine
 backend
test-coroutine: add performance test for nesting

 Kevin Wolf (8):
qcow2: Add some tracing
qcow2: Add error messages in qcow2_truncate
qemu-iotests: Mark some tests as quick
make check: Add qemu-iotests subset
Add 'make check-block'
qcow2: Factor out count_cow_clusters
qcow2: Add qcow2_alloc_clusters_at()
qcow2: Reduce number of I/O requests

 Paolo Bonzini (6):
Group snapshot: Fix format name for backing file
use QSIMPLEQ_FOREACH_SAFE when freeing list elements
qapi: complete implementation of unions
rename blockdev-group-snapshot-sync
add mode field to blockdev-snapshot-sync transaction item
qmp: convert blockdev-snapshot-sync to a wrapper around
 transactions

 Stefan Hajnoczi (2):
qed: do not evict in-use L2 table cache entries
block: handle -EBUSY in bdrv_commit_all()
 
 
 Pulled.  Thanks.
 
 And the make check integration with qemu-iotest is sweet!

Anthony, seems you forgot to push?

Reason I'm asking is that I've been seeing the following annoying
problem on master:

$ make check-block
/home/andreas/QEMU/qemu/tests/qemu-iotests-quick.sh
hostname: Name or service not known
hostname: Name or service not known
QEMU  -- this_should_be_unused
QEMU_IMG  -- /home/andreas/QEMU/build/qemu-img
QEMU_IO   -- /home/andreas/QEMU/build/qemu-io
IMGFMT-- qcow2
IMGPROTO  -- file
PLATFORM  -- Linux/x86_64  3.1.9-1.4-desktop

002 [12:07:08] [12:07:14] - output mismatch (see 002.out.bad)
--- 002.out 2012-04-15 03:15:14.764142157 +0200
+++ 002.out.bad 2012-04-20 12:07:14.829106591 +0200
@@ -1,4 +1,5 @@
 QA output created by 002
+hostname: Name or service not known
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728

 == reading whole image ==
004 [12:07:14] [12:07:15] - output mismatch (see 004.out.bad)
--- 004.out 2012-04-15 03:15:14.764142157 +0200
+++ 004.out.bad 2012-04-20 12:07:15.449108889 +0200
@@ -1,4 +1,5 @@
 QA output created by 004
+hostname: Name or service not known
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728

 write before image boundary
011 [12:07:15] [12:07:16] - output mismatch (see 011.out.bad)
--- 011.out 2012-04-15 03:15:14.764142157 +0200
+++ 011.out.bad 2012-04-20 12:07:16.991114606 +0200
@@ -1,4 +1,5 @@
 QA output created by 011
+hostname: Name or service not known

 creating image
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=6442450944
012 [12:07:17] [12:07:17] - output mismatch (see 012.out.bad)
--- 012.out 2012-04-15 03:15:14.764142157 +0200
+++ 012.out.bad 2012-04-20 12:07:17.195115362 +0200
@@ -1,4 +1,5 @@
 QA output created by 012
+hostname: Name or service not known
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728

 == mark image read-only
016 [12:07:17] [12:07:17] [not run]
016 -- not suitable for this image format: qcow2
017 [12:07:17] [12:07:21] - output mismatch (see 017.out.bad)
--- 017.out 2012-04-15 03:15:14.779142203 +0200
+++ 017.out.bad 2012-04-20 12:07:21.347130741 +0200
@@ -1,4 +1,5 @@
 QA output created by 017
+hostname: Name or service not known
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=6442450944
 Filling base image

019 [12:07:21] [12:07:25] - output mismatch (see 019.out.bad)
--- 019.out 2012-04-15 03:15:14.779142203 +0200
+++ 019.out.bad 2012-04-20 12:07:25.920147663 +0200
@@ -1,4 +1,5 @@
 QA output created by 019
+hostname: Name or service not known
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=6442450944
cluster_size=65536
 Filling base image

020 [12:07:25] [12:07:29] - output mismatch (see 020.out.bad)
--- 020.out 2012-04-15 03:15:14.780142206 +0200
+++ 020.out.bad 2012-04-20 12:07:29.987162699 +0200
@@ -1,4 +1,5 @@
 QA output created by 020
+hostname: Name or service not known
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=6442450944
 Filling base image

024 [12:07:30] [12:07:32] - output mismatch (see 024.out.bad)
--- 024.out 2012-04-15 03:15:14.784142219 +0200
+++ 024.out.bad 2012-04-20 12:07:32.842173240 +0200
@@ -1,4 +1,5 @@
 QA output created by 024
+hostname: Name or service not known
 Creating backing file

 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
cluster_size=65536
025 [12:07:32] [12:07:38] - output mismatch

Re: [Qemu-devel] [PULL 00/20] Block patches

Am 20.04.2012 12:16, schrieb Andreas Färber:
 Am 13.03.2012 03:23, schrieb Anthony Liguori:
 On 03/12/2012 10:19 AM, Kevin Wolf wrote:
 The following changes since commit
 a348f108842fb928563865c9918642900cd0d477:

Add missing const attributes for MemoryRegionOps (2012-03-11
 11:40:15 +)

 are available in the git repository at:
git://repo.or.cz/qemu/kevin.git for-anthony

 Alex Barcelo (4):
coroutine: adding sigaltstack method (.c source)
coroutine: adding configure choose mechanism for coroutine backend
coroutine: adding configure option for sigaltstack coroutine
 backend
test-coroutine: add performance test for nesting

 Kevin Wolf (8):
qcow2: Add some tracing
qcow2: Add error messages in qcow2_truncate
qemu-iotests: Mark some tests as quick
make check: Add qemu-iotests subset
Add 'make check-block'
qcow2: Factor out count_cow_clusters
qcow2: Add qcow2_alloc_clusters_at()
qcow2: Reduce number of I/O requests

 Paolo Bonzini (6):
Group snapshot: Fix format name for backing file
use QSIMPLEQ_FOREACH_SAFE when freeing list elements
qapi: complete implementation of unions
rename blockdev-group-snapshot-sync
add mode field to blockdev-snapshot-sync transaction item
qmp: convert blockdev-snapshot-sync to a wrapper around
 transactions

 Stefan Hajnoczi (2):
qed: do not evict in-use L2 table cache entries
block: handle -EBUSY in bdrv_commit_all()


 Pulled.  Thanks.

 And the make check integration with qemu-iotest is sweet!
 
 Anthony, seems you forgot to push?

Oops, I retreat the question, should've looked at the dates more closely
- thread being bumped to top was due to a problem, not due to the PULL
as I assumed.

Below problem with make check-block still applies though. :)

Andreas

 
 Reason I'm asking is that I've been seeing the following annoying
 problem on master:
 
 $ make check-block
 /home/andreas/QEMU/qemu/tests/qemu-iotests-quick.sh
 hostname: Name or service not known
 hostname: Name or service not known
 QEMU  -- this_should_be_unused
 QEMU_IMG  -- /home/andreas/QEMU/build/qemu-img
 QEMU_IO   -- /home/andreas/QEMU/build/qemu-io
 IMGFMT-- qcow2
 IMGPROTO  -- file
 PLATFORM  -- Linux/x86_64  3.1.9-1.4-desktop
 
 002   [12:07:08] [12:07:14] - output mismatch (see 002.out.bad)
 --- 002.out   2012-04-15 03:15:14.764142157 +0200
 +++ 002.out.bad   2012-04-20 12:07:14.829106591 +0200
 @@ -1,4 +1,5 @@
  QA output created by 002
 +hostname: Name or service not known
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728
 
  == reading whole image ==
 004   [12:07:14] [12:07:15] - output mismatch (see 004.out.bad)
 --- 004.out   2012-04-15 03:15:14.764142157 +0200
 +++ 004.out.bad   2012-04-20 12:07:15.449108889 +0200
 @@ -1,4 +1,5 @@
  QA output created by 004
 +hostname: Name or service not known
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728
 
  write before image boundary
 011   [12:07:15] [12:07:16] - output mismatch (see 011.out.bad)
 --- 011.out   2012-04-15 03:15:14.764142157 +0200
 +++ 011.out.bad   2012-04-20 12:07:16.991114606 +0200
 @@ -1,4 +1,5 @@
  QA output created by 011
 +hostname: Name or service not known
 
  creating image
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=6442450944
 012   [12:07:17] [12:07:17] - output mismatch (see 012.out.bad)
 --- 012.out   2012-04-15 03:15:14.764142157 +0200
 +++ 012.out.bad   2012-04-20 12:07:17.195115362 +0200
 @@ -1,4 +1,5 @@
  QA output created by 012
 +hostname: Name or service not known
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728
 
  == mark image read-only
 016   [12:07:17] [12:07:17] [not run]
   016 -- not suitable for this image format: qcow2
 017   [12:07:17] [12:07:21] - output mismatch (see 017.out.bad)
 --- 017.out   2012-04-15 03:15:14.779142203 +0200
 +++ 017.out.bad   2012-04-20 12:07:21.347130741 +0200
 @@ -1,4 +1,5 @@
  QA output created by 017
 +hostname: Name or service not known
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=6442450944
  Filling base image
 
 019   [12:07:21] [12:07:25] - output mismatch (see 019.out.bad)
 --- 019.out   2012-04-15 03:15:14.779142203 +0200
 +++ 019.out.bad   2012-04-20 12:07:25.920147663 +0200
 @@ -1,4 +1,5 @@
  QA output created by 019
 +hostname: Name or service not known
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=6442450944
 cluster_size=65536
  Filling base image
 
 020   [12:07:25] [12:07:29] - output mismatch (see 020.out.bad)
 --- 020.out   2012-04-15 03:15:14.780142206 +0200
 +++ 020.out.bad   2012-04-20 12:07:29.987162699 +0200
 @@ -1,4 +1,5 @@
  QA output created by 020
 +hostname: Name or service not known
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=6442450944
  Filling base image
 
 024   [12:07:30] [12:07:32] - output

[Qemu-devel] [PATCH 1/5] qemu-timer: Remove redundant include statements

qemu-timer.h includes qemu-common.h which already includes time.h,
sys/time.h, windows.h, unistd.h, fcntl.h, errno.h and signal.h.

Therefore those include statements are redundant and can be removed.

Signed-off-by: Stefan Weil s...@weilnetz.de
---
 qemu-timer.c |   11 ++-
 qemu-timer.h |6 --
 2 files changed, 2 insertions(+), 15 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 17915df..87d9636 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -29,23 +29,16 @@
 
 #include hw/hw.h
 
-#include unistd.h
-#include fcntl.h
-#include time.h
-#include errno.h
-#include sys/time.h
-#include signal.h
+#include qemu-timer.h
+
 #ifdef __FreeBSD__
 #include sys/param.h
 #endif
 
 #ifdef _WIN32
-#include windows.h
 #include mmsystem.h
 #endif
 
-#include qemu-timer.h
-
 /***/
 /* timers */
 
diff --git a/qemu-timer.h b/qemu-timer.h
index 661bbe7..1cfc9e0 100644
--- a/qemu-timer.h
+++ b/qemu-timer.h
@@ -4,12 +4,6 @@
 #include qemu-common.h
 #include main-loop.h
 #include notify.h
-#include time.h
-#include sys/time.h
-
-#ifdef _WIN32
-#include windows.h
-#endif
 
 /* timers */
 
-- 
1.7.9

Re: [Qemu-devel] [RFC PATCH 6/9] pc: pass paravirt info for hotplug memory slots to BIOS

2012-04-20 Thread Igor Mammedov


On 04/19/2012 04:08 PM, Vasilis Liaskovitis wrote:

  The numa_fw_cfg paravirt interface is extended to include SRAT information for
  all hotplug-able memslots. There are 3 words for each hotplug-able memory 
slot,
  denoting start address, size and node proximity. nb_numa_nodes is set to 1 by
  default (not 0), so that we always pass srat info to SeaBIOS.

  This information is used by Seabios to build hotplug memory device objects at 
runtime.

  Signed-off-by: Vasilis Liaskovitisvasilis.liaskovi...@profitbricks.com
---
  hw/pc.c |   59 +--
  vl.c|4 +++-
  2 files changed, 56 insertions(+), 7 deletions(-)

diff --git a/hw/pc.c b/hw/pc.c
index 67f0479..f1f550a 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -46,6 +46,7 @@
  #include ui/qemu-spice.h
  #include memory.h
  #include exec-memory.h
+#include memslot.h

  /* output Bochs bios info messages */
  //#define DEBUG_BIOS
@@ -592,12 +593,15 @@ int e820_add_entry(uint64_t address, uint64_t length, 
uint32_t type)
  return index;
  }

+static void bochs_bios_setup_hp_memslots(uint64_t *fw_cfg_slots);
+
  static void *bochs_bios_init(void)
  {
  void *fw_cfg;
  uint8_t *smbios_table;
  size_t smbios_len;
  uint64_t *numa_fw_cfg;
+uint64_t *hp_memslots_fw_cfg;
  int i, j;

  register_ioport_write(0x400, 1, 2, bochs_bios_write, NULL);
@@ -630,28 +634,71 @@ static void *bochs_bios_init(void)
  fw_cfg_add_bytes(fw_cfg, FW_CFG_HPET, (uint8_t *)hpet_cfg,
   sizeof(struct hpet_fw_config));
  /* allocate memory for the NUMA channel: one (64bit) word for the number
- * of nodes, one word for each VCPU-node and one word for each node to
- * hold the amount of memory.
+ * of nodes, one word for the number of hotplug memory slots, one word
+ * for each VCPU-node, one word for each node to hold the amount of 
memory.
+ * Finally three words for each hotplug memory slot, denoting start 
address,
+ * size and node proximity.
   */
-numa_fw_cfg = g_malloc0((1 + max_cpus + nb_numa_nodes) * 8);
+numa_fw_cfg = g_malloc0((2 + max_cpus + nb_numa_nodes + 3 * 
nb_hp_memslots) * 8);
  numa_fw_cfg[0] = cpu_to_le64(nb_numa_nodes);
+numa_fw_cfg[1] = cpu_to_le64(nb_hp_memslots);

this will brake compatibility if guest was migrated from old-new qemu
than on reboot it will use old bios that expects numa_fw_cfg[1] to be something 
else.
Could memslots info be moved to the end of an existing interface?


+
  for (i = 0; i  max_cpus; i++) {
  for (j = 0; j  nb_numa_nodes; j++) {
  if (node_cpumask[j]  (1  i)) {
-numa_fw_cfg[i + 1] = cpu_to_le64(j);
+numa_fw_cfg[i + 2] = cpu_to_le64(j);
  break;
  }
  }
  }
  for (i = 0; i  nb_numa_nodes; i++) {
-numa_fw_cfg[max_cpus + 1 + i] = cpu_to_le64(node_mem[i]);
+numa_fw_cfg[max_cpus + 2 + i] = cpu_to_le64(node_mem[i]);
  }
+
+hp_memslots_fw_cfg = numa_fw_cfg + 2 + max_cpus + nb_numa_nodes;
+if (nb_hp_memslots)
+bochs_bios_setup_hp_memslots(hp_memslots_fw_cfg);
+
  fw_cfg_add_bytes(fw_cfg, FW_CFG_NUMA, (uint8_t *)numa_fw_cfg,
- (1 + max_cpus + nb_numa_nodes) * 8);
+ (2 + max_cpus + nb_numa_nodes + 3 * nb_hp_memslots) * 8);

  return fw_cfg;
  }

+static void bochs_bios_setup_hp_memslots(uint64_t *fw_cfg_slots)
+{
+int i = 0;
+Error *err = NULL;
+DeviceState *dev;
+MemSlotState *slot;
+char *type;
+BusState *bus = sysbus_get_default();
+
+QTAILQ_FOREACH(dev,bus-children, sibling) {
+type = object_property_get_str(OBJECT(dev), type,err);
+if (err) {
+error_free(err);
+fprintf(stderr, error getting device type\n);
+exit(1);
+}
+
+if (!strcmp(type, memslot)) {
+if (!dev-id) {
+error_free(err);
+fprintf(stderr, error getting memslot device id\n);
+exit(1);
+}
+if (!strcmp(dev-id, initialslot)) continue;
+slot = MEMSLOT(dev);
+fw_cfg_slots[3 * slot-idx] = cpu_to_le64(slot-start);
+fw_cfg_slots[3 * slot-idx + 1] = cpu_to_le64(slot-size);
+fw_cfg_slots[3 * slot-idx + 2] = cpu_to_le64(slot-node);
+i++;
+}
+}
+assert(i == nb_hp_memslots);
+}
+
  static long get_file_size(FILE *f)
  {
  long where, size;
diff --git a/vl.c b/vl.c
index ae91a8a..50df453 100644
--- a/vl.c
+++ b/vl.c
@@ -3428,8 +3428,10 @@ int main(int argc, char **argv, char **envp)

  register_savevm_live(NULL, ram, 0, 4, NULL, ram_save_live, NULL,
   ram_load, NULL);
+if (!nb_numa_nodes)
+nb_numa_nodes = 1;

-if (nb_numa_nodes  0) {
+{
  int i;

  if (nb_numa_nodes  MAX_NODES) {


--
-
 Igor

Re: [Qemu-devel] [PULL 00/20] Block patches

Am 20.04.2012 12:16, schrieb Andreas Färber:
 Am 13.03.2012 03:23, schrieb Anthony Liguori:
 On 03/12/2012 10:19 AM, Kevin Wolf wrote:
 The following changes since commit
 a348f108842fb928563865c9918642900cd0d477:

Add missing const attributes for MemoryRegionOps (2012-03-11
 11:40:15 +)

 are available in the git repository at:
git://repo.or.cz/qemu/kevin.git for-anthony

 Alex Barcelo (4):
coroutine: adding sigaltstack method (.c source)
coroutine: adding configure choose mechanism for coroutine backend
coroutine: adding configure option for sigaltstack coroutine
 backend
test-coroutine: add performance test for nesting

 Kevin Wolf (8):
qcow2: Add some tracing
qcow2: Add error messages in qcow2_truncate
qemu-iotests: Mark some tests as quick
make check: Add qemu-iotests subset
Add 'make check-block'
qcow2: Factor out count_cow_clusters
qcow2: Add qcow2_alloc_clusters_at()
qcow2: Reduce number of I/O requests

 Paolo Bonzini (6):
Group snapshot: Fix format name for backing file
use QSIMPLEQ_FOREACH_SAFE when freeing list elements
qapi: complete implementation of unions
rename blockdev-group-snapshot-sync
add mode field to blockdev-snapshot-sync transaction item
qmp: convert blockdev-snapshot-sync to a wrapper around
 transactions

 Stefan Hajnoczi (2):
qed: do not evict in-use L2 table cache entries
block: handle -EBUSY in bdrv_commit_all()


 Pulled.  Thanks.

 And the make check integration with qemu-iotest is sweet!
 
 Anthony, seems you forgot to push?
 
 Reason I'm asking is that I've been seeing the following annoying
 problem on master:
 
 $ make check-block
 /home/andreas/QEMU/qemu/tests/qemu-iotests-quick.sh
 hostname: Name or service not known
 hostname: Name or service not known
 QEMU  -- this_should_be_unused
 QEMU_IMG  -- /home/andreas/QEMU/build/qemu-img
 QEMU_IO   -- /home/andreas/QEMU/build/qemu-io
 IMGFMT-- qcow2
 IMGPROTO  -- file
 PLATFORM  -- Linux/x86_64  3.1.9-1.4-desktop
 
 002   [12:07:08] [12:07:14] - output mismatch (see 002.out.bad)
 --- 002.out   2012-04-15 03:15:14.764142157 +0200
 +++ 002.out.bad   2012-04-20 12:07:14.829106591 +0200
 @@ -1,4 +1,5 @@
  QA output created by 002
 +hostname: Name or service not known
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728
 
  == reading whole image ==
 004   [12:07:14] [12:07:15] - output mismatch (see 004.out.bad)
 --- 004.out   2012-04-15 03:15:14.764142157 +0200
 +++ 004.out.bad   2012-04-20 12:07:15.449108889 +0200
 @@ -1,4 +1,5 @@
  QA output created by 004
 +hostname: Name or service not known
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728
 
  write before image boundary
 011   [12:07:15] [12:07:16] - output mismatch (see 011.out.bad)
 --- 011.out   2012-04-15 03:15:14.764142157 +0200
 +++ 011.out.bad   2012-04-20 12:07:16.991114606 +0200
 @@ -1,4 +1,5 @@
  QA output created by 011
 +hostname: Name or service not known
 
  creating image
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=6442450944
 012   [12:07:17] [12:07:17] - output mismatch (see 012.out.bad)
 --- 012.out   2012-04-15 03:15:14.764142157 +0200
 +++ 012.out.bad   2012-04-20 12:07:17.195115362 +0200
 @@ -1,4 +1,5 @@
  QA output created by 012
 +hostname: Name or service not known
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728
 
  == mark image read-only
 016   [12:07:17] [12:07:17] [not run]
   016 -- not suitable for this image format: qcow2
 017   [12:07:17] [12:07:21] - output mismatch (see 017.out.bad)
 --- 017.out   2012-04-15 03:15:14.779142203 +0200
 +++ 017.out.bad   2012-04-20 12:07:21.347130741 +0200
 @@ -1,4 +1,5 @@
  QA output created by 017
 +hostname: Name or service not known
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=6442450944
  Filling base image
 
 019   [12:07:21] [12:07:25] - output mismatch (see 019.out.bad)
 --- 019.out   2012-04-15 03:15:14.779142203 +0200
 +++ 019.out.bad   2012-04-20 12:07:25.920147663 +0200
 @@ -1,4 +1,5 @@
  QA output created by 019
 +hostname: Name or service not known
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=6442450944
 cluster_size=65536
  Filling base image
 
 020   [12:07:25] [12:07:29] - output mismatch (see 020.out.bad)
 --- 020.out   2012-04-15 03:15:14.780142206 +0200
 +++ 020.out.bad   2012-04-20 12:07:29.987162699 +0200
 @@ -1,4 +1,5 @@
  QA output created by 020
 +hostname: Name or service not known
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=6442450944
  Filling base image
 
 024   [12:07:30] [12:07:32] - output mismatch (see 024.out.bad)
 --- 024.out   2012-04-15 03:15:14.784142219 +0200
 +++ 024.out.bad   2012-04-20 12:07:32.842173240 +0200
 @@ -1,4 +1,5 @@
  QA output created by 024
 +hostname: Name or service not known
  Creating backing

[Qemu-devel] [PATCH 3/5] qemu-timer: Use bool, false, true for boolean values

This avoids conversions between int and bool / char.

It also makes the code more readable.

Signed-off-by: Stefan Weil s...@weilnetz.de
---
 qemu-timer.c |   31 ---
 qemu-timer.h |6 +++---
 2 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 38adb0d..73ffe25 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -48,7 +48,7 @@
 
 struct QEMUClock {
 int type;
-int enabled;
+bool enabled;
 
 QEMUTimer *active_timers;
 
@@ -76,8 +76,8 @@ struct qemu_alarm_timer {
 #elif defined(_WIN32)
 HANDLE timer;
 #endif
-char expired;
-char pending;
+bool expired;
+bool pending;
 };
 
 static struct qemu_alarm_timer *alarm_timer;
@@ -251,13 +251,13 @@ static QEMUClock *qemu_new_clock(int type)
 
 clock = g_malloc0(sizeof(QEMUClock));
 clock-type = type;
-clock-enabled = 1;
+clock-enabled = true;
 clock-last = INT64_MIN;
 notifier_list_init(clock-reset_notifiers);
 return clock;
 }
 
-void qemu_clock_enable(QEMUClock *clock, int enabled)
+void qemu_clock_enable(QEMUClock *clock, bool enabled)
 {
 bool old = clock-enabled;
 clock-enabled = enabled;
@@ -370,17 +370,18 @@ void qemu_mod_timer(QEMUTimer *ts, int64_t expire_time)
 qemu_mod_timer_ns(ts, expire_time * ts-scale);
 }
 
-int qemu_timer_pending(QEMUTimer *ts)
+bool qemu_timer_pending(QEMUTimer *ts)
 {
 QEMUTimer *t;
 for (t = ts-clock-active_timers; t != NULL; t = t-next) {
-if (t == ts)
-return 1;
+if (t == ts) {
+return true;
+}
 }
-return 0;
+return false;
 }
 
-int qemu_timer_expired(QEMUTimer *timer_head, int64_t current_time)
+bool qemu_timer_expired(QEMUTimer *timer_head, int64_t current_time)
 {
 return qemu_timer_expired_ns(timer_head, current_time * timer_head-scale);
 }
@@ -458,7 +459,7 @@ uint64_t qemu_timer_expire_time_ns(QEMUTimer *ts)
 
 void qemu_run_all_timers(void)
 {
-alarm_timer-pending = 0;
+alarm_timer-pending = false;
 
 /* vm time timers */
 qemu_run_timers(vm_clock);
@@ -467,7 +468,7 @@ void qemu_run_all_timers(void)
 
 /* rearm timer, if not periodic */
 if (alarm_timer-expired) {
-alarm_timer-expired = 0;
+alarm_timer-expired = false;
 qemu_rearm_alarm_timer(alarm_timer);
 }
 }
@@ -485,7 +486,7 @@ static void host_alarm_handler(int host_signum)
 if (alarm_has_dynticks(t) ||
 qemu_next_alarm_deadline () = 0) {
 t-expired = alarm_has_dynticks(t);
-t-pending = 1;
+t-pending = true;
 qemu_notify_event();
 }
 }
@@ -637,7 +638,7 @@ static void CALLBACK mm_alarm_handler(UINT uTimerID, UINT 
uMsg,
 }
 if (alarm_has_dynticks(t) || qemu_next_alarm_deadline() = 0) {
 t-expired = alarm_has_dynticks(t);
-t-pending = 1;
+t-pending = true;
 qemu_notify_event();
 }
 }
@@ -794,7 +795,7 @@ int init_timer_alarm(void)
 
 /* first event is at time 0 */
 atexit(quit_timers);
-t-pending = 1;
+t-pending = true;
 alarm_timer = t;
 
 return 0;
diff --git a/qemu-timer.h b/qemu-timer.h
index dfb0744..b7c646f 100644
--- a/qemu-timer.h
+++ b/qemu-timer.h
@@ -36,7 +36,7 @@ int64_t qemu_get_clock_ns(QEMUClock *clock);
 int64_t qemu_clock_has_timers(QEMUClock *clock);
 int64_t qemu_clock_expired(QEMUClock *clock);
 int64_t qemu_clock_deadline(QEMUClock *clock);
-void qemu_clock_enable(QEMUClock *clock, int enabled);
+void qemu_clock_enable(QEMUClock *clock, bool enabled);
 void qemu_clock_warp(QEMUClock *clock);
 
 void qemu_register_clock_reset_notifier(QEMUClock *clock, Notifier *notifier);
@@ -49,8 +49,8 @@ void qemu_free_timer(QEMUTimer *ts);
 void qemu_del_timer(QEMUTimer *ts);
 void qemu_mod_timer_ns(QEMUTimer *ts, int64_t expire_time);
 void qemu_mod_timer(QEMUTimer *ts, int64_t expire_time);
-int qemu_timer_pending(QEMUTimer *ts);
-int qemu_timer_expired(QEMUTimer *timer_head, int64_t current_time);
+bool qemu_timer_pending(QEMUTimer *ts);
+bool qemu_timer_expired(QEMUTimer *timer_head, int64_t current_time);
 uint64_t qemu_timer_expire_time_ns(QEMUTimer *ts);
 
 void qemu_run_timers(QEMUClock *clock);
-- 
1.7.9

Re: [Qemu-devel] [RFC 0/13] Support for guest visible IOMMUs

Am 20.04.2012 06:16, schrieb David Gibson:
 I'm really hoping I can get some extra review of this code path.  I
 believe it's correct, but it's not straightforward to test, since it
 will not be exercise by correct guest software.

Sounds like a good case for qtest. Did you consider that?

Kevin

Re: [Qemu-devel] [PULL 00/20] Block patches

Am 20.04.2012 12:37, schrieb Kevin Wolf:
 Am 20.04.2012 12:16, schrieb Andreas Färber:
 [...] I've been seeing the following annoying
 problem on master:

 $ make check-block
 /home/andreas/QEMU/qemu/tests/qemu-iotests-quick.sh
 hostname: Name or service not known
 hostname: Name or service not known
 QEMU  -- this_should_be_unused
 QEMU_IMG  -- /home/andreas/QEMU/build/qemu-img
 QEMU_IO   -- /home/andreas/QEMU/build/qemu-io
 IMGFMT-- qcow2
 IMGPROTO  -- file
 PLATFORM  -- Linux/x86_64  3.1.9-1.4-desktop

 002  [12:07:08] [12:07:14] - output mismatch (see 002.out.bad)
 --- 002.out  2012-04-15 03:15:14.764142157 +0200
 +++ 002.out.bad  2012-04-20 12:07:14.829106591 +0200
 @@ -1,4 +1,5 @@
  QA output created by 002
 +hostname: Name or service not known
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728

  == reading whole image ==
 004  [12:07:14] [12:07:15] - output mismatch (see 004.out.bad)
 --- 004.out  2012-04-15 03:15:14.764142157 +0200
 +++ 004.out.bad  2012-04-20 12:07:15.449108889 +0200
 @@ -1,4 +1,5 @@
  QA output created by 004
 +hostname: Name or service not known
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728

  write before image boundary
 011  [12:07:15] [12:07:16] - output mismatch (see 011.out.bad)
 --- 011.out  2012-04-15 03:15:14.764142157 +0200
 +++ 011.out.bad  2012-04-20 12:07:16.991114606 +0200
 @@ -1,4 +1,5 @@
  QA output created by 011
 +hostname: Name or service not known

  creating image
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=6442450944
 012  [12:07:17] [12:07:17] - output mismatch (see 012.out.bad)
 --- 012.out  2012-04-15 03:15:14.764142157 +0200
 +++ 012.out.bad  2012-04-20 12:07:17.195115362 +0200
 @@ -1,4 +1,5 @@
  QA output created by 012
 +hostname: Name or service not known
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728

  == mark image read-only
 016  [12:07:17] [12:07:17] [not run]
  016 -- not suitable for this image format: qcow2
 017  [12:07:17] [12:07:21] - output mismatch (see 017.out.bad)
 --- 017.out  2012-04-15 03:15:14.779142203 +0200
 +++ 017.out.bad  2012-04-20 12:07:21.347130741 +0200
 @@ -1,4 +1,5 @@
  QA output created by 017
 +hostname: Name or service not known
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=6442450944
  Filling base image

 019  [12:07:21] [12:07:25] - output mismatch (see 019.out.bad)
 --- 019.out  2012-04-15 03:15:14.779142203 +0200
 +++ 019.out.bad  2012-04-20 12:07:25.920147663 +0200
 @@ -1,4 +1,5 @@
  QA output created by 019
 +hostname: Name or service not known
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=6442450944
 cluster_size=65536
  Filling base image

 020  [12:07:25] [12:07:29] - output mismatch (see 020.out.bad)
 --- 020.out  2012-04-15 03:15:14.780142206 +0200
 +++ 020.out.bad  2012-04-20 12:07:29.987162699 +0200
 @@ -1,4 +1,5 @@
  QA output created by 020
 +hostname: Name or service not known
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=6442450944
  Filling base image

 024  [12:07:30] [12:07:32] - output mismatch (see 024.out.bad)
 --- 024.out  2012-04-15 03:15:14.784142219 +0200
 +++ 024.out.bad  2012-04-20 12:07:32.842173240 +0200
 @@ -1,4 +1,5 @@
  QA output created by 024
 +hostname: Name or service not known
  Creating backing file

  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1073741824
 cluster_size=65536
 025  [12:07:32] [12:07:38] - output mismatch (see 025.out.bad)
 --- 025.out  2012-04-15 03:15:14.784142219 +0200
 +++ 025.out.bad  2012-04-20 12:07:38.543194283 +0200
 @@ -1,4 +1,5 @@
  QA output created by 025
 +hostname: Name or service not known
  === Creating image

  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728
 027  [12:07:38] [12:07:39] - output mismatch (see 027.out.bad)
 --- 027.out  2012-04-15 03:15:14.78514 +0200
 +++ 027.out.bad  2012-04-20 12:07:39.340197224 +0200
 @@ -1,4 +1,5 @@
  QA output created by 027
 +hostname: Name or service not known
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728

  == writing first cluster to populate metadata ==
 029  [12:07:39] [12:07:49] - output mismatch (see 029.out.bad)
 --- 029.out  2012-04-15 03:15:14.78514 +0200
 +++ 029.out.bad  2012-04-20 12:07:49.395234274 +0200
 @@ -1,4 +1,5 @@
  QA output created by 029
 +hostname: Name or service not known
  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864
 cluster_size=65536
  wrote 4096/4096 bytes at offset 0
  4 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 031  [12:07:49] [12:07:49] - output mismatch (see 031.out.bad)
 --- 031.out  2012-04-19 17:15:59.313430818 +0200
 +++ 031.out.bad  2012-04-20 12:07:49.787235706 +0200
 @@ -1,4 +1,5 @@
  QA output created by 031
 +hostname: Name or service not known

  === Create image with unknown header extension ===

 Not run: 016
 Failures: 002 004 011 012 017 019 020 024 025 027 029

[Qemu-devel] [PATCH 5/5] qemu-timer: Optimize data structures

Remove all holes which were found by pahole on Linux x86_64
(and replace struct QEMUTimer by QEMUTimer).

Signed-off-by: Stefan Weil s...@weilnetz.de
---
 qemu-timer.c |   14 +++---
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 1fbc2df..2546640 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -47,22 +47,22 @@
 #define QEMU_CLOCK_HOST 2
 
 struct QEMUClock {
-int type;
-bool enabled;
-
 QEMUTimer *active_timers;
 
 NotifierList reset_notifiers;
 int64_t last;
+
+int type;
+bool enabled;
 };
 
 struct QEMUTimer {
-QEMUClock *clock;
 int64_t expire_time;   /* in nanoseconds */
-int scale;
+QEMUClock *clock;
 QEMUTimerCB *cb;
 void *opaque;
-struct QEMUTimer *next;
+QEMUTimer *next;
+int scale;
 };
 
 struct qemu_alarm_timer {
@@ -71,8 +71,8 @@ struct qemu_alarm_timer {
 void (*stop)(struct qemu_alarm_timer *t);
 void (*rearm)(struct qemu_alarm_timer *t, int64_t nearest_delta_ns);
 #if defined(__linux__)
-int fd;
 timer_t timer;
+int fd;
 #elif defined(_WIN32)
 HANDLE timer;
 #endif
-- 
1.7.9

[Qemu-devel] [PATCH v2 4/5] qemu-timer: Remove function alarm_has_dynticks

Some time ago, the last time which did not have dynticks was removed,
so now all timers have dynticks.

I also removed a misleading error message for the dynticks timer.
If timer_create fails, there is already an error message, and
QEMU will use the unix timer which also provides dynamic ticks,
therefore dynamic ticks are not disabled.

v2:
Remove two if statements because they were always true
(thanks to Paolo Bonzini for this correction).

Signed-off-by: Stefan Weil s...@weilnetz.de
---
 qemu-timer.c |   39 ---
 1 files changed, 8 insertions(+), 31 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 73ffe25..8dd8b9f 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -87,11 +87,6 @@ static bool qemu_timer_expired_ns(QEMUTimer *timer_head, 
int64_t current_time)
 return timer_head  (timer_head-expire_time = current_time);
 }
 
-static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
-{
-return !!t-rearm;
-}
-
 static int64_t qemu_next_alarm_deadline(void)
 {
 int64_t delta;
@@ -124,7 +119,6 @@ static int64_t qemu_next_alarm_deadline(void)
 static void qemu_rearm_alarm_timer(struct qemu_alarm_timer *t)
 {
 int64_t nearest_delta_ns;
-assert(alarm_has_dynticks(t));
 if (!rt_clock-active_timers 
 !vm_clock-active_timers 
 !host_clock-active_timers) {
@@ -483,12 +477,9 @@ static void host_alarm_handler(int host_signum)
 if (!t)
return;
 
-if (alarm_has_dynticks(t) ||
-qemu_next_alarm_deadline () = 0) {
-t-expired = alarm_has_dynticks(t);
-t-pending = true;
-qemu_notify_event();
-}
+t-expired = true;
+t-pending = true;
+qemu_notify_event();
 }
 
 #if defined(__linux__)
@@ -524,10 +515,6 @@ static int dynticks_start_timer(struct qemu_alarm_timer *t)
 
 if (timer_create(CLOCK_REALTIME, ev, host_timer)) {
 perror(timer_create);
-
-/* disable dynticks */
-fprintf(stderr, Dynamic Ticks disabled\n);
-
 return -1;
 }
 
@@ -636,17 +623,14 @@ static void CALLBACK mm_alarm_handler(UINT uTimerID, UINT 
uMsg,
 if (!t) {
 return;
 }
-if (alarm_has_dynticks(t) || qemu_next_alarm_deadline() = 0) {
-t-expired = alarm_has_dynticks(t);
-t-pending = true;
-qemu_notify_event();
-}
+t-expired = true;
+t-pending = true;
+qemu_notify_event();
 }
 
 static int mm_start_timer(struct qemu_alarm_timer *t)
 {
 TIMECAPS tc;
-UINT flags;
 
 memset(tc, 0, sizeof(tc));
 timeGetDevCaps(tc, sizeof(tc));
@@ -654,18 +638,11 @@ static int mm_start_timer(struct qemu_alarm_timer *t)
 mm_period = tc.wPeriodMin;
 timeBeginPeriod(mm_period);
 
-flags = TIME_CALLBACK_FUNCTION;
-if (alarm_has_dynticks(t)) {
-flags |= TIME_ONESHOT;
-} else {
-flags |= TIME_PERIODIC;
-}
-
 mm_timer = timeSetEvent(1,  /* interval (ms) */
 mm_period,  /* resolution */
 mm_alarm_handler,   /* function */
 (DWORD_PTR)t,   /* parameter */
-flags);
+TIME_ONESHOT | TIME_CALLBACK_FUNCTION);
 
 if (!mm_timer) {
 fprintf(stderr, Failed to initialize win32 alarm timer: %ld\n,
@@ -720,7 +697,7 @@ static int win32_start_timer(struct qemu_alarm_timer *t)
   host_alarm_handler,
   t,
   1,
-  alarm_has_dynticks(t) ? 360 : 1,
+  360,
   WT_EXECUTEINTIMERTHREAD);
 
 if (!success) {
-- 
1.7.9

Re: [Qemu-devel] [PULL 00/20] Block patches

Am 20.04.2012 12:38, schrieb Andreas Färber:
 Am 20.04.2012 12:37, schrieb Kevin Wolf:
 Am 20.04.2012 12:16, schrieb Andreas Färber:
 [...] I've been seeing the following annoying
 problem on master:

 However `hostname` returns myhostname.site just fine, and I don't
 understand why a user's local hostname should be causing 100% test
 failures for block I/O tests in the first place...

 Could someone please check on that?

 common.config has this line:

HOST=`hostname -s`

 Does hostname -s work as well when you invoke it manually?
 
 Ah no, that one doesn't. (I spotted just `hostname` in common.rc.)

Interesting that it can fail when getting the full host name works.

 But anyway,
 $HOST seems to be completely unused, so I guess we could just remove
 this line.
 
 Maybe it matters for NBD or iSCSI? But if prerequisites were not right I
 would expect the tests to be skipped, not failing.

I suspect the author (Christoph?) just didn't expect that this could
ever fail.

And well, qemu-iotests doesn't do any NBD or iSCSI tests (yet). I
grepped for HOST and found no user at all.

Kevin

[Qemu-devel] [PATCH] iotests: Resolve test failures caused by hostname

`hostname -s` may output an errror:
hostname: Name or service not known
This causes all tests to fail for `make check-block`.

Suppress such error messages, letting the tests succeed.

Signed-off-by: Andreas Färber afaer...@suse.de
---
 tests/qemu-iotests/common.config |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tests/qemu-iotests/common.config b/tests/qemu-iotests/common.config
index a220684..df082e7 100644
--- a/tests/qemu-iotests/common.config
+++ b/tests/qemu-iotests/common.config
@@ -36,7 +36,7 @@ export LANG=C
 
 PATH=.:$PATH
 
-HOST=`hostname -s`
+HOST=`hostname -s 2 /dev/null`
 HOSTOS=`uname -s`
 
 EMAIL=root@localhost# where auto-qa will send its status messages
-- 
1.7.7

Re: [Qemu-devel] [RFC PATCH 2/9][SeaBIOS] Implement acpi-dsdt functions for memory hotplug.

2012-04-20 Thread Igor Mammedov


On 04/19/2012 04:08 PM, Vasilis Liaskovitis wrote:

Extend the DSDT to include methods for handling memory hot-add and hot-remove
notifications and memory device status requests. These functions are called
from the memory device SSDT methods.

Eject has only been tested with level gpe event, but will be changed to edge gpe
event soon, according to recent master patch for other ACPI hotplug events.

Signed-off-by: Vasilis Liaskovitisvasilis.liaskovi...@profitbricks.com
---
  src/acpi-dsdt.dsl |   68 +++-
  1 files changed, 66 insertions(+), 2 deletions(-)

diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl
index 4bdc268..184daf0 100644
--- a/src/acpi-dsdt.dsl
+++ b/src/acpi-dsdt.dsl
@@ -709,9 +709,72 @@ DefinitionBlock (
  }
  Return(One)
  }
-}

+/* Objects filled in by run-time generated SSDT */
+External(MTFY, MethodObj)
+External(MEON, PkgObj)
+
+Method (CMST, 1, NotSerialized) {
+// _STA method - return ON status of memdevice
+// Local0 = MEON flag for this cpu
+Store(DerefOf(Index(MEON, Arg0)), Local0)
+If (Local0) { Return(0xF) } Else { Return(0x0) }
+}
+/* Memory eject notify method */
+OperationRegion(MEMJ, SystemIO, 0xaf40, 32)
+Field (MEMJ, ByteAcc, NoLock, Preserve)
+{
+MPE, 256
+}
+
+Method (MPEJ, 2, NotSerialized) {
+// _EJ0 method - eject callback
+Store(ShiftLeft(1,Arg0), MPE)
+Sleep(200)
+}

MPE is write only and only one memslot is ejected at a time. Why 256 bit-field 
is here then?
Could we use just 1 byte and write a slot number into it and save some io 
address space this way?


+
+/* Memory hotplug notify method */
+OperationRegion(MEST, SystemIO, 0xaf20, 32)

It's more a suggestion: move it a bit farther to allow maybe 1024 cpus in the 
future.
That will prevent compatibility a headache, if we decide to expand support to 
more then
256 cpus.

Or event better to make this address configurable in run-time and build this 
var along
with SSDT (converting along the way all other hard-coded io ports to the same 
generic
run-time interface). This wish is out of scope of this patch-set, but what
do you think about the idea?


+Field (MEST, ByteAcc, NoLock, Preserve)
+{
+MES, 256
+}
+
+Method(MESC, 0) {
+// Local5 = active memdevice bitmap
+Store (MES, Local5)
+// Local2 = last read byte from bitmap
+Store (Zero, Local2)
+// Local0 = memory device iterator
+Store (Zero, Local0)
+While (LLess(Local0, SizeOf(MEON))) {
+// Local1 = MEON flag for this memory device
+Store(DerefOf(Index(MEON, Local0)), Local1)
+If (And(Local0, 0x07)) {
+// Shift down previously read bitmap byte
+ShiftRight(Local2, 1, Local2)
+} Else {
+// Read next byte from memdevice bitmap
+Store(DerefOf(Index(Local5, ShiftRight(Local0, 3))), 
Local2)
+}
+// Local3 = active state for this memory device
+Store(And(Local2, 1), Local3)

+If (LNotEqual(Local1, Local3)) {
+// State change - update MEON with new state
+Store(Local3, Index(MEON, Local0))
+// Do MEM notify
+If (LEqual(Local3, 1)) {
+MTFY(Local0, 1)
+} Else {
+MTFY(Local0, 3)
+}
+}
+Increment(Local0)
+}
+Return(One)
+}
+}
  /
   * General purpose events
   /
@@ -732,7 +795,8 @@ DefinitionBlock (
  Return(\_SB.PRSC())
  }
  Method(_L03) {
-Return(0x01)
+// Memory hotplug event
+Return(\_SB.MESC())
  }
  Method(_L04) {
  Return(0x01)


--
-
 Igor

Re: [Qemu-devel] [PATCH] iotests: Resolve test failures caused by hostname

Am 20.04.2012 12:50, schrieb Andreas Färber:
 `hostname -s` may output an errror:
 hostname: Name or service not known
 This causes all tests to fail for `make check-block`.
 
 Suppress such error messages, letting the tests succeed.
 
 Signed-off-by: Andreas Färber afaer...@suse.de

Thanks, applied to the block branch.

Kevin

[Qemu-devel] [PATCH] usb: add serial number generator

2012-04-20 Thread Gerd Hoffmann

This patch adds a function which creates unique serial numbers for usb
devices and puts it into use.  Windows guests tend to become unhappy if
they find two identical usb devices in the system.  Effects range from
non-functional devices (with yellow exclamation mark in device manager)
to BSODs.  Handing out unique serial numbers to devices fixes this.

With this patch applied almost all emulated devices get a generated,
unique serial number.  There are two exceptions:

 * usb-storage devices will prefer a user-specified serial number
   and will only get a generated number in case the serial property
   is unset.
 * usb-hid devices keep the fixed serial number 42 as it is used
   to signal remote wakeup actually works.
   See commit 7b074a22dab4bdda9864b933f1bc811a3db42845

Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
 hw/usb/desc.c |   32 
 hw/usb/desc.h |1 +
 hw/usb/dev-audio.c|1 +
 hw/usb/dev-bluetooth.c|1 +
 hw/usb/dev-hub.c  |1 +
 hw/usb/dev-network.c  |1 +
 hw/usb/dev-serial.c   |1 +
 hw/usb/dev-smartcard-reader.c |1 +
 hw/usb/dev-storage.c  |2 ++
 hw/usb/dev-wacom.c|1 +
 10 files changed, 42 insertions(+), 0 deletions(-)

diff --git a/hw/usb/desc.c b/hw/usb/desc.c
index 3c77368..e8a3c6a 100644
--- a/hw/usb/desc.c
+++ b/hw/usb/desc.c
@@ -1,3 +1,5 @@
+#include ctype.h
+
 #include hw/usb.h
 #include hw/usb/desc.h
 #include trace.h
@@ -412,6 +414,36 @@ void usb_desc_set_string(USBDevice *dev, uint8_t index, 
const char *str)
 s-str = g_strdup(str);
 }
 
+/*
+ * This function creates a serial number for a usb device.
+ * The serial number should:
+ *   (a) Be unique within the virtual machine.
+ *   (b) Be constant, so you don't get a new one each
+ *   time the guest is started.
+ * So we are using the physical location to generate a serial number
+ * from it.  It has three pieces:  First a fixed, device-specific
+ * prefix.  Second the device path of the host controller (which is
+ * the pci address in most cases).  Third the physical port path.
+ * Results in serial numbers like this: 314159-:00:1d.7-3.
+ */
+void usb_desc_create_serial(USBDevice *dev)
+{
+DeviceState *hcd = dev-qdev.parent_bus-parent;
+const USBDesc *desc = usb_device_get_usb_desc(dev);
+int index = desc-id.iSerialNumber;
+char serial[64];
+int dst;
+
+assert(index != 0  desc-str[index] != NULL);
+dst = snprintf(serial, sizeof(serial), %s, desc-str[index]);
+if (hcd  hcd-parent_bus  hcd-parent_bus-info-get_dev_path) {
+char *path = hcd-parent_bus-info-get_dev_path(hcd);
+dst += snprintf(serial+dst, sizeof(serial)-dst, -%s, path);
+}
+dst += snprintf(serial+dst, sizeof(serial)-dst, -%s, dev-port-path);
+usb_desc_set_string(dev, index, serial);
+}
+
 const char *usb_desc_get_string(USBDevice *dev, uint8_t index)
 {
 USBDescString *s;
diff --git a/hw/usb/desc.h b/hw/usb/desc.h
index d164e8f..7cf5442 100644
--- a/hw/usb/desc.h
+++ b/hw/usb/desc.h
@@ -171,6 +171,7 @@ int usb_desc_other(const USBDescOther *desc, uint8_t *dest, 
size_t len);
 void usb_desc_init(USBDevice *dev);
 void usb_desc_attach(USBDevice *dev);
 void usb_desc_set_string(USBDevice *dev, uint8_t index, const char *str);
+void usb_desc_create_serial(USBDevice *dev);
 const char *usb_desc_get_string(USBDevice *dev, uint8_t index);
 int usb_desc_string(USBDevice *dev, int index, uint8_t *dest, size_t len);
 int usb_desc_get_descriptor(USBDevice *dev, int value, uint8_t *dest, size_t 
len);
diff --git a/hw/usb/dev-audio.c b/hw/usb/dev-audio.c
index 426b95c..79b75fb 100644
--- a/hw/usb/dev-audio.c
+++ b/hw/usb/dev-audio.c
@@ -648,6 +648,7 @@ static int usb_audio_initfn(USBDevice *dev)
 {
 USBAudioState *s = DO_UPCAST(USBAudioState, dev, dev);
 
+usb_desc_create_serial(dev);
 usb_desc_init(dev);
 s-dev.opaque = s;
 AUD_register_card(usb-audio, s-card);
diff --git a/hw/usb/dev-bluetooth.c b/hw/usb/dev-bluetooth.c
index 195370c..6b74eff 100644
--- a/hw/usb/dev-bluetooth.c
+++ b/hw/usb/dev-bluetooth.c
@@ -494,6 +494,7 @@ static void usb_bt_handle_destroy(USBDevice *dev)
 
 static int usb_bt_initfn(USBDevice *dev)
 {
+usb_desc_create_serial(dev);
 usb_desc_init(dev);
 return 0;
 }
diff --git a/hw/usb/dev-hub.c b/hw/usb/dev-hub.c
index 9c91665..b5962da 100644
--- a/hw/usb/dev-hub.c
+++ b/hw/usb/dev-hub.c
@@ -520,6 +520,7 @@ static int usb_hub_initfn(USBDevice *dev)
 USBHubPort *port;
 int i;
 
+usb_desc_create_serial(dev);
 usb_desc_init(dev);
 s-intr = usb_ep_get(dev, USB_TOKEN_IN, 1);
 for (i = 0; i  NUM_PORTS; i++) {
diff --git a/hw/usb/dev-network.c b/hw/usb/dev-network.c
index cff55f2..b238a09 100644
--- a/hw/usb/dev-network.c
+++ b/hw/usb/dev-network.c
@@ -1324,6 +1324,7 @@ static int usb_net_initfn(USBDevice *dev)
 {
 USBNetState *s = DO_UPCAST(USBNetState, dev, dev);

[Qemu-devel] [PATCH 1/5] hw/ac97: Fix log message in mixer_load

Fix a small copy and paste error in logging.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 hw/ac97.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/ac97.c b/hw/ac97.c
index dd4917b..05ae63b 100644
--- a/hw/ac97.c
+++ b/hw/ac97.c
@@ -339,7 +339,7 @@ static uint16_t mixer_load (AC97LinkState *s, uint32_t i)
 uint16_t val = 0x;
 
 if (i + 2  sizeof (s-mixer_data)) {
-dolog (mixer_store: index %d out of bounds %zd\n,
+dolog (mixer_load: index %d out of bounds %zd\n,
i, sizeof (s-mixer_data));
 }
 else {
-- 
1.7.10

[Qemu-devel] [PATCH 2/5] hw/ac97: Make a bunch of mixer registers read only

The Linux ac97 driver tries to see if optional things like video input
volume control are available in 2 ways:
1) See if the mute bit is set after reset, if it is no further tests are done
2) If the mute bit is not set it does a write/read test of the mute bit

This patch changes our ac97 to conform to what the Linux driver expects, it
initializes registers for things which we don't emulate to 0 (so the mute bit
is not set) and makes them read only.

This causes Linux to now longer show the following (functionless)
controls in alsamixer:

Master Mono vol + mute
3d Control toggle
PCM out pre / post 3d select
Surround toggle
CD vol + mute
Mic vol + mute
Mic boost toggle
Mic mic1 / mic2 select
Video vol + mute
Phone vol + mute
Beep mono vol + mute
Aux vol + mute
Mono output mic / mix select
Sigmatel 4 speaker stereo toggle
Sigmatel ADC 6Db att toggle
Sigmatel DAC 6Db att toggle

This patch was also tested with a Windows XP guest and there it also makes
a number of functionless mixer controls go away.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 hw/ac97.c |   34 +++---
 1 file changed, 27 insertions(+), 7 deletions(-)

diff --git a/hw/ac97.c b/hw/ac97.c
index 05ae63b..432382d 100644
--- a/hw/ac97.c
+++ b/hw/ac97.c
@@ -51,6 +51,8 @@ enum {
 AC97_6Ch_Vol_C_LFE_Mute= 0x36,
 AC97_6Ch_Vol_L_R_Surround_Mute = 0x38,
 AC97_Vendor_Reserved   = 0x58,
+AC97_Sigmatel_Analog   = 0x6c, /* We emulate a Sigmatel codec */
+AC97_Sigmatel_Dac2Invert   = 0x6e, /* We emulate a Sigmatel codec */
 AC97_Vendor_ID1= 0x7c,
 AC97_Vendor_ID2= 0x7e
 };
@@ -500,14 +502,16 @@ static void mixer_reset (AC97LinkState *s)
 memset (s-mixer_data, 0, sizeof (s-mixer_data));
 memset (active, 0, sizeof (active));
 mixer_store (s, AC97_Reset   , 0x); /* 6940 */
-mixer_store (s, AC97_Master_Volume_Mono_Mute , 0x8000);
+mixer_store (s, AC97_Headphone_Volume_Mute   , 0x);
+mixer_store (s, AC97_Master_Volume_Mono_Mute , 0x);
+mixer_store (s, AC97_Master_Tone_RL,   0x);
 mixer_store (s, AC97_PC_BEEP_Volume_Mute , 0x);
-
-mixer_store (s, AC97_Phone_Volume_Mute   , 0x8008);
-mixer_store (s, AC97_Mic_Volume_Mute , 0x8008);
-mixer_store (s, AC97_CD_Volume_Mute  , 0x8808);
-mixer_store (s, AC97_Aux_Volume_Mute , 0x8808);
-mixer_store (s, AC97_Record_Gain_Mic_Mute, 0x8000);
+mixer_store (s, AC97_Phone_Volume_Mute   , 0x);
+mixer_store (s, AC97_Mic_Volume_Mute , 0x);
+mixer_store (s, AC97_CD_Volume_Mute  , 0x);
+mixer_store (s, AC97_Video_Volume_Mute   , 0x);
+mixer_store (s, AC97_Aux_Volume_Mute , 0x);
+mixer_store (s, AC97_Record_Gain_Mic_Mute, 0x);
 mixer_store (s, AC97_General_Purpose , 0x);
 mixer_store (s, AC97_3D_Control  , 0x);
 mixer_store (s, AC97_Powerdown_Ctrl_Stat , 0x000f);
@@ -654,6 +658,22 @@ static void nam_writew (void *opaque, uint32_t addr, 
uint32_t val)
 val);
 }
 break;
+case AC97_Headphone_Volume_Mute:
+case AC97_Master_Volume_Mono_Mute:
+case AC97_Master_Tone_RL:
+case AC97_PC_BEEP_Volume_Mute:
+case AC97_Phone_Volume_Mute:
+case AC97_Mic_Volume_Mute:
+case AC97_CD_Volume_Mute:
+case AC97_Video_Volume_Mute:
+case AC97_Aux_Volume_Mute:
+case AC97_Record_Gain_Mic_Mute:
+case AC97_General_Purpose:
+case AC97_3D_Control:
+case AC97_Sigmatel_Analog:
+case AC97_Sigmatel_Dac2Invert:
+/* None of the features in these regs are emulated, so they are RO */
+break;
 default:
 dolog (U nam writew %#x - %#x\n, addr, val);
 mixer_store (s, index, val);
-- 
1.7.10

[Qemu-devel] [PATCH 3/5] hw/ac97: Use AC97_Record_Gain_Mute not AC97_Line_In_Volume_Mute

After commit 19677a380a70348134ed7650b294522617eb03fc:
hw/ac97: add support for volume control

We are (correctly) using AC97_Record_Gain_Mute and not AC97_Line_In_Volume_Mute
for recording volume, but various places in hw/ac97 were still assumimg that
we are using AC97_Line_In_Volume_Mute for record volume control, this patch
fixes this.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 hw/ac97.c |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/hw/ac97.c b/hw/ac97.c
index 432382d..524dd7f 100644
--- a/hw/ac97.c
+++ b/hw/ac97.c
@@ -508,6 +508,7 @@ static void mixer_reset (AC97LinkState *s)
 mixer_store (s, AC97_PC_BEEP_Volume_Mute , 0x);
 mixer_store (s, AC97_Phone_Volume_Mute   , 0x);
 mixer_store (s, AC97_Mic_Volume_Mute , 0x);
+mixer_store (s, AC97_Line_In_Volume_Mute , 0x);
 mixer_store (s, AC97_CD_Volume_Mute  , 0x);
 mixer_store (s, AC97_Video_Volume_Mute   , 0x);
 mixer_store (s, AC97_Aux_Volume_Mute , 0x);
@@ -533,7 +534,7 @@ static void mixer_reset (AC97LinkState *s)
 record_select (s, 0);
 set_volume (s, AC97_Master_Volume_Mute, 0x8000);
 set_volume (s, AC97_PCM_Out_Volume_Mute, 0x8808);
-set_volume (s, AC97_Line_In_Volume_Mute, 0x8808);
+set_volume (s, AC97_Record_Gain_Mute, 0x8808);
 
 reset_voices (s, active);
 }
@@ -596,7 +597,6 @@ static void nam_writew (void *opaque, uint32_t addr, 
uint32_t val)
 case AC97_PCM_Out_Volume_Mute:
 case AC97_Master_Volume_Mute:
 case AC97_Record_Gain_Mute:
-case AC97_Line_In_Volume_Mute:
 set_volume (s, index, val);
 break;
 case AC97_Record_Select:
@@ -664,6 +664,7 @@ static void nam_writew (void *opaque, uint32_t addr, 
uint32_t val)
 case AC97_PC_BEEP_Volume_Mute:
 case AC97_Phone_Volume_Mute:
 case AC97_Mic_Volume_Mute:
+case AC97_Line_In_Volume_Mute:
 case AC97_CD_Volume_Mute:
 case AC97_Video_Volume_Mute:
 case AC97_Aux_Volume_Mute:
@@ -1175,8 +1176,8 @@ static int ac97_post_load (void *opaque, int version_id)
 mixer_load (s, AC97_Master_Volume_Mute));
 set_volume (s, AC97_PCM_Out_Volume_Mute,
 mixer_load (s, AC97_PCM_Out_Volume_Mute));
-set_volume (s, AC97_Line_In_Volume_Mute,
-mixer_load (s, AC97_Line_In_Volume_Mute));
+set_volume (s, AC97_Record_Gain_Mute,
+mixer_load (s, AC97_Record_Gain_Mute));
 
 active[PI_INDEX] = !!(s-bm_regs[PI_INDEX].cr  CR_RPBM);
 active[PO_INDEX] = !!(s-bm_regs[PO_INDEX].cr  CR_RPBM);
-- 
1.7.10

[Qemu-devel] [PATCH 4/5] hw/ac97: Mask out unused bits of volume controls

The Linux ac97 drivers does a number of register read/write tests to
see how much resolution a volume control actually has.

This patch takes this into account by masking out any bits written to
a volume control reg which should not be there according to the spec.

After this the Linux ac97 driver correctly uses a range of 0 - 0x1f for
the PCM out volume, as stated in the spec, and we can fix the FIXME
in update_combined_volume_out().

This patch was also tested with a Windows XP guest without any issues.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 hw/ac97.c |   20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/hw/ac97.c b/hw/ac97.c
index 524dd7f..a245c97 100644
--- a/hw/ac97.c
+++ b/hw/ac97.c
@@ -455,8 +455,7 @@ static void update_combined_volume_out (AC97LinkState *s)
 
 get_volume (mixer_load (s, AC97_Master_Volume_Mute), 0x3f, 1,
 mute, lvol, rvol);
-/* FIXME: should be 1f according to spec */
-get_volume (mixer_load (s, AC97_PCM_Out_Volume_Mute), 0x3f, 1,
+get_volume (mixer_load (s, AC97_PCM_Out_Volume_Mute), 0x1f, 1,
 pmute, plvol, prvol);
 
 mute = mute | pmute;
@@ -479,11 +478,22 @@ static void update_volume_in (AC97LinkState *s)
 
 static void set_volume (AC97LinkState *s, int index, uint32_t val)
 {
-mixer_store (s, index, val);
-if (index == AC97_Master_Volume_Mute || index == AC97_PCM_Out_Volume_Mute) 
{
+switch (index) {
+case AC97_Master_Volume_Mute:
+val = 0xbf3f;
+mixer_store (s, index, val);
 update_combined_volume_out (s);
-} else if (index == AC97_Record_Gain_Mute) {
+break;
+case AC97_PCM_Out_Volume_Mute:
+val = 0x9f1f;
+mixer_store (s, index, val);
+update_combined_volume_out (s);
+break;
+case AC97_Record_Gain_Mute:
+val = 0x8f0f;
+mixer_store (s, index, val);
 update_volume_in (s);
+break;
 }
 }
 
-- 
1.7.10

[Qemu-devel] [PATCH 5/5] hw/ac97: Mask out the EAPD bit on Powerdown Ctrl/Stat writes

The Linux AC97 driver tests this bit to decide wether or not to show
an External amplifier toggle control.

This patch was also tested with a Windows XP guest without any issues.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 hw/ac97.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/ac97.c b/hw/ac97.c
index a245c97..557f7b0 100644
--- a/hw/ac97.c
+++ b/hw/ac97.c
@@ -600,7 +600,7 @@ static void nam_writew (void *opaque, uint32_t addr, 
uint32_t val)
 mixer_reset (s);
 break;
 case AC97_Powerdown_Ctrl_Stat:
-val = ~0xf;
+val = ~0x800f;
 val |= mixer_load (s, index)  0xf;
 mixer_store (s, index, val);
 break;
-- 
1.7.10

Re: [Qemu-devel] [PATCH 00/16] QEMU vhost-scsi support

On Fri, Apr 20, 2012 at 8:46 AM, Paolo Bonzini pbonz...@redhat.com wrote:
 Il 20/04/2012 09:00, Nicholas A. Bellinger ha scritto:
 On Thu, 2012-04-19 at 19:20 -0500, Anthony Liguori wrote:
 TCM runs in the absolute most privileged context possible.  When you're 
 dealing
 with extremely hostile input, it's pretty obvious that you want to run it 
 in the
 lowest privileged context as humanly possible.

 The argument that a SCSI target for virtual machines is so complex that
 it can't possibly be implemented properly in the kernel is a bunch of
 non-sense.

 I agree.  A VM is not any more hostile than another iSCSI initiator.
 lio _always_ must assume to operates in a hostile environment.

 Being able to identify which virtio-scsi guests can actually connect via
 vhost-scsi into individual tcm_vhost endpoints is step one here.

 Yes, the ACL system in lio is quite good for this.

 Well, using a raw device from userspace there is still going to be a
 SG-IO memcpy going on here between user - kernel in current code,
 yes..?

 Being able to deliver interrupts and SGL memory directly into tcm_vhost
 cmwq kernel context for backend device execution w/o QEMU userspace
 involvement or extra SGL memcpy is the perceived performance benefit
 here.

 How much benefit will this actually provide across single port and multi
 port tcm_vhost LUNs into a single guest..?  That still remains to be
 demonstrated with performance+throughput benchmarks..

 Yes, this is the key.

The overall goal is for virtio-scsi to compete with or be faster than
virtio-blk, whether we go the tcm_vhost or the QEMU SCSI emulation
route.  So Cong and I discussed the details of such a benchmark
yesterday.  The results will be presented to the QEMU community when
they have been collected - maybe a topic for the KVM community call.

 The problems I have with vhost-scsi are, from easiest to hardest:

 - completely different configuration mechanism with respect to the
 in-QEMU target (fix: need to integrate configfs into scsi-{disk,generic}).

Why is this a problem?  The target is a lot richer than QEMU's SCSI
emulation.  All the ACLs and other configuration should be done using
RTSadmin or configfs.  I don't think it makes sense to duplicate that
into QEMU.

 - no support for migration (there can be pending SCSI requests at
 migration time, that need to be restarted on the destination)

Yes and it hasn't been thought through by me at least ;-).  So
migration is indeed a challenge that needs to be worked through.

 - no support for non-raw images (fix: use NBD on a Unix socket? perhaps
 add an NBD backend to lio)

For me this is the biggest issue with kernel-level storage for virtual
machines.  We have NBD today but it goes through the network stack
using a limited protocol and probably can't do zero-copy.

The most promising option I found was dm-userspace
(http://wiki.xensource.com/xenwiki/DmUserspace), which implements a
device-mapper target with an in-kernel MMU-like lookup mechanism that
calls out to userspace when block addresses need to be translated.
It's not anywhere near to upstream and hasn't been pushed for several
years.  On the plus side we could also write a userspace
implementation of this so that QEMU image formats continue to be
portable to other host OSes without duplicating code.

If tcm_vhost only works with raw images then I don't see it as a
realistic option given the effort it will require to complete and
maintain.

 In order for QEMU userspace to support this, Linux would need to expose
 a method to userspace for issuing DIF protected CDBs.  This userspace
 API currently does not exist AFAIK, so a kernel-level approach is the
 currently the only option when it comes to supporting end-to-end block
 protection information originating from within Linux guests.

 I think it would be worthwhile to have this in userspace too.

 (Note this is going to involve a virtio-scsi spec rev as well)

 Yes.  By the way, another possible modification could be to tell the
 guest what is its (initiator) WWPN.

Going back to ALUA, I'd like to understand ALUA multipathing a bit
better.  I've never played with multipath, hence my questions:

I have a SAN with multiple controllers and ALUA support - so ALUA
multipathing is possible.  Now I want my KVM guests to take advantage
of multipath themselves.  Since the LIO target virtualizes the SCSI
bus (the host admin defines LUNs, target ports, and ACLs that do not
have to map 1:1 to the SAN) we also have to implement ALUA in the
virtio-scsi target.  The same would be true for QEMU SCSI emulation.

How would we configure LIO's ALUA in this case?  We really want to
reflect the port attributes (available/offline,
optimized/non-optimized) that the external SAN fabric reports.  Is
this supported by LIO?

Does it even make sense to pass the multipathing up into the guest?
If we terminate it on the host using Linux's ALUA support, we can hide
multipath entirely from the guest.  Do we lose an obvious advantage

Re: [Qemu-devel] [PATCH v3 2/4] m25p80: initial verion

On Fri, Apr 20, 2012 at 3:12 AM, Peter A. G. Crosthwaite
peter.crosthwa...@petalogix.com wrote:
 +static inline void flash_sync_area(struct flash *s, int64_t off, int64_t len)
 +{
 +    int64_t start, end;
 +
 +    if (!s-bdrv) {
 +        return;
 +    }
 +
 +    start = off / 512;
 +    end = (off + len) / 512;
 +    bdrv_write(s-bdrv, start, s-storage + (start * 512), end - start);

Is it possible to use bdrv_aio_write() like in flash_sync_page()?

Stefan

Re: [Qemu-devel] [PATCH v3] ARM: Exynos4210 IRQ: Introduce new IRQ gate functionality.

On 17 April 2012 06:41, Evgeny Voevodin e.voevo...@samsung.com wrote:
 +static Property exynos4210_irq_gate_properties[] = {
 +    DEFINE_PROP_UINT32(n_in, Exynos4210IRQGateState, n_in, 1),
 +    DEFINE_PROP_END_OF_LIST(),
 +};
 +
  static const VMStateDescription vmstate_exynos4210_irq_gate = {
     .name = exynos4210.irq_gate,
 -    .version_id = 1,
 -    .minimum_version_id = 1,
 -    .minimum_version_id_old = 1,
 +    .version_id = 2,
 +    .minimum_version_id = 2,
 +    .minimum_version_id_old = 2,
     .fields = (VMStateField[]) {
 -        VMSTATE_UINT32_ARRAY(gpio_level, Exynos4210IRQGateState,
 -                EXYNOS4210_IRQ_GATE_NINPUTS),
 +        VMSTATE_UINT32(n_in, Exynos4210IRQGateState),
 +        VMSTATE_VBUFFER_UINT32(level, Exynos4210IRQGateState, 1, NULL, 0, 
 n_in),
         VMSTATE_END_OF_LIST()

n_in is constant, so you shouldn't need to save/restore it, right?

Otherwise looks good.

PS: 3 days is a bit eager to be sending pings :-) I'd suggest about
a week as the usual time to leave...

-- PMM

Re: [Qemu-devel] [PATCH 04/15] target-i386: Add family property to X86CPU

Am 20.04.2012 00:34, schrieb Michael Roth:
 On Wed, Apr 18, 2012 at 01:11:08AM +0200, Andreas Färber wrote:
 Add the property early in the initfn so that it can be used in helpers
 such as mce_init().

 Signed-off-by: Andreas Färber afaer...@suse.de
 ---
  target-i386/cpu.c |   38 +-
  1 files changed, 33 insertions(+), 5 deletions(-)

 diff --git a/target-i386/cpu.c b/target-i386/cpu.c
 index d30185b..aa0d328 100644
 --- a/target-i386/cpu.c
 +++ b/target-i386/cpu.c
[...]
 @@ -952,6 +972,9 @@ int cpu_x86_register(X86CPU *cpu, const char *cpu_model)
  env-cpuid_svm_features = TCG_SVM_FEATURES;
  }
  x86_cpuid_set_model_id(env, def-model_id);
 +if (error_is_set(error)) {
 
 Missing an error_free(error) here

Thanks, fixed on qom-cpu-x86 branch.

Andreas

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

Re: [Qemu-devel] SD card subsystem synchronous I/O

2012-04-20 Thread andrzej zaborowski

On 20 April 2012 11:50, Stefan Hajnoczi stefa...@gmail.com wrote:
 On Fri, Apr 20, 2012 at 12:21 AM, andrzej zaborowski balr...@gmail.com 
 wrote:
 Yes, controllers would be affected, but there are various ways to go
 about it.  Some could be simple to implement (looking at
 pxa2xx_mmci.c).  First of all the SD specification pretty much assumes
 the storage medium is flash and data is available immediately after
 it is requested.  The host drives the clock and there's a fixed number
 of cycles that pass between a command and the response.  There's a
 mechanism for the card to indicate it is busy programming after data
 is written, but it doesn't apply to some types of writes.

 However the number of cycles between command and response can be
 different between card manufacturers, so it looks like the card can
 pull either the CMD and the DAT line high before starting to send the
 command response or the data.  In qemu you could either make the data
 transfers async, or the response transfers async, there's no need to
 do both.

 If the image is on a network filesystem then there could be problems
 caused by the synchronous IO.  Anything else, I'd guess that the
 caches, readahead and what not make sync IO the same or unnoticeably
 faster overall.  pxa2xx_mmci.c would be easy to convert to async, but
 some host controllers that are more software than hardware might
 theoretically give up if the card doesn't respond in N cycles.

 Even in a case where the bus specification is strict about timing it's
 possible that the controllers that guest drivers talk to hide those
 details and instead work on an interrupt-driven basis.

Yep.


 In other words, maybe most of the work will be converting controllers
 to implement the busy state while we do actual block I/O.  Is this
 possible or do SD controllers expose the real low-level timing aspects
 of the bus to the guest drivers?

The PXA270 one does not and it would be quite easy to convert, as
mentioned.  It's probably true for most SoCs' controllers.  Many
devices (not necessarily emulated in Qemu) just have the SD card's
pads wired to GPIOs and driven in software or other solutions between
fully software and fully hardware.  Linux doesn't have any generic
bit banging driver for them as far as I can see.

Cheers

Re: [Qemu-devel] [PATCH v1 1/3] xilinx_zynq: added smp support

On 2 April 2012 06:20, Peter A. G. Crosthwaite
peter.crosthwa...@petalogix.com wrote:
 Added linux smp support for the xilinx zynq platform (2x cpus are supported)

 Signed-off-by: Peter A. G. Crosthwaite peter.crosthwa...@petalogix.com
 ---
  hw/xilinx_zynq.c |   64 -
  1 files changed, 53 insertions(+), 11 deletions(-)

 diff --git a/hw/xilinx_zynq.c b/hw/xilinx_zynq.c
 index 7290c64..56d0b96 100644
 --- a/hw/xilinx_zynq.c
 +++ b/hw/xilinx_zynq.c
 @@ -30,6 +30,42 @@

  #define IRQ_OFFSET 32 /* pic interrupts start from index 32 */

 +#define SMP_BOOT_ADDR 0x0fff
 +
 +static void zynq_reset_secondary(CPUARMState *env,
 +                                    const struct arm_boot_info *info)
 +{
 +    env-regs[15] = SMP_BOOT_ADDR;
 +}
 +
 +/* Entry point for secondary CPU */
 +static uint32_t zynq_smpboot[] = {
 +    0xe59f0020, /* ldr     r0, privbase */
 +    0xe3a004FF, /* mov     r0 = 0xFFF0 */
 +    0xe38008FF, /* orr     ...*/
 +    0xe3800CFF, /* orr      */
 +    0xe38000F0, /* orr     . */

These four insns are a rather longwinded way of saying
0xe3ef /* ldr r0, =0xfff0 (mvn r0, #15) */
aren't they?

 +    0xe320f002, /* wfe */
 +    0xe5901000, /* ldr     r1, [r0] */
 +    0xe1110001, /* tst     r1, r1 */
 +    0x0afb, /* beq     wfe */
 +    0xe12fff11, /* bx      r1 */
 +    0,
 +    0
 +};

Who is responsible for resetting the 0xFFF0
location so that on reset the secondary CPUs don't
immediately leave their pen? It looks from a quick glance
like this is in the on-chip RAM, is that right?
(If it is in RAM, then maybe you should be using the
default_reset_secondary() rather than your own version?)

-- PMM

Re: [Qemu-devel] [PATCH] iotests: Resolve test failures caused by hostname


Am 20.04.2012 12:59, schrieb Kevin Wolf:

Am 20.04.2012 12:50, schrieb Andreas Färber:

`hostname -s` may output an errror:
hostname: Name or service not known
This causes all tests to fail for `make check-block`.

Suppress such error messages, letting the tests succeed.

Signed-off-by: Andreas Färber afaer...@suse.de


Thanks, applied to the block branch.

Kevin


Do we really need the '-s'? There are versions of hostname
which don't support the '-s' option (for example on MinGW).

Stefan

Re: [Qemu-devel] [PATCH v3] ARM: Exynos4210 IRQ: Introduce new IRQ gate functionality.

2012-04-20 Thread Evgeny Voevodin


On 20.04.2012 15:13, Peter Maydell wrote:

On 17 April 2012 06:41, Evgeny Voevodine.voevo...@samsung.com  wrote:

+static Property exynos4210_irq_gate_properties[] = {
+DEFINE_PROP_UINT32(n_in, Exynos4210IRQGateState, n_in, 1),
+DEFINE_PROP_END_OF_LIST(),
+};
+
  static const VMStateDescription vmstate_exynos4210_irq_gate = {
 .name = exynos4210.irq_gate,
-.version_id = 1,
-.minimum_version_id = 1,
-.minimum_version_id_old = 1,
+.version_id = 2,
+.minimum_version_id = 2,
+.minimum_version_id_old = 2,
 .fields = (VMStateField[]) {
-VMSTATE_UINT32_ARRAY(gpio_level, Exynos4210IRQGateState,
-EXYNOS4210_IRQ_GATE_NINPUTS),
+VMSTATE_UINT32(n_in, Exynos4210IRQGateState),
+VMSTATE_VBUFFER_UINT32(level, Exynos4210IRQGateState, 1, NULL, 0, 
n_in),
 VMSTATE_END_OF_LIST()

n_in is constant, so you shouldn't need to save/restore it, right?


Oh, seems so. It's not changing during run-time.


Otherwise looks good.

PS: 3 days is a bit eager to be sending pings :-) I'd suggest about
a week as the usual time to leave...


Ok, sorry :)


-- PMM




--
Kind regards,
Evgeny Voevodin,
Leading Software Engineer,
ASWG, Moscow RD center, Samsung Electronics
e-mail: e.voevo...@samsung.com

Re: [Qemu-devel] [PATCH 1/2] qemu-ga: generate missing stubs for fsfreeze

On Thu, Apr 19, 2012 at 10:49:16AM -0500, Michael Roth wrote:
 On Tue, Apr 17, 2012 at 12:07:38PM -0500, Michael Roth wrote:
  When linux-specific commands (including guest-fsfreeze-*) were consolidated
  under defined(__linux__), we forgot to account for the case where
  defined(__linux__)  !defined(FIFREEZE). As a result stubs are no longer
  being generated on linux hosts that don't have FIFREEZE support. Fix
  this.
  
  Tested-by: Andreas Färber afaer...@suse.de
  Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
 
 Hi Stefan,
 
 Please ignore these for trivial, gonna submit a qemu-ga pull for these since
 a build fix is involved.

Sure.

Stefan

Re: [Qemu-devel] [RFC 0/13] Support for guest visible IOMMUs

2012-04-20 Thread David Gibson

On Fri, Apr 20, 2012 at 12:39:36PM +0200, Kevin Wolf wrote:
 Am 20.04.2012 06:16, schrieb David Gibson:
  I'm really hoping I can get some extra review of this code path.  I
  believe it's correct, but it's not straightforward to test, since it
  will not be exercise by correct guest software.
 
 Sounds like a good case for qtest. Did you consider that?

Only in the sense that I really hope to be able to find time sometime
to get my head around qtest so I can use it for this amongst other
things.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [Qemu-devel] [RFC 0/2]: qemu-ga: drop automatic reaper

2012-04-20 Thread Michal Privoznik

On 19.04.2012 21:34, Luiz Capitulino wrote:
 On Thu, 19 Apr 2012 13:57:48 -0500
 Michael Roth mdr...@linux.vnet.ibm.com wrote:
 
 On Thu, Apr 19, 2012 at 02:36:53PM -0300, Luiz Capitulino wrote:
 Michael,

 I'm going to revive this topic one more time. I was working on v2 of my 
 fixes
 to the suspend race bugs and really thought that the real problem is that 
 the
 code shouldn't be that complex.

 Basically, this series drops the automatic reaper and adds waitpid() calls 
 related logic to the suspend and shutdown functions.

 My objective with this RFC is to understand why this can't be done.

 Hi Luiz,

 CC'ing Michael as some of these suggestions might affect his work on
 libvirt integration.
 
 I forgot to CC him and Eric.
 
 Thanks for taking the time to implement what this would look like
 this. I think this is a sensible approach in general, the main issue
 for me is the specific commands currently impacted by such a change:
 suspend and shutdown.

 While we do document that these commands may not return a response,
 the new behavior actually introduces a pathological assurance that
 they *won't* return a response:
 shutdown/pm-suspend/echo mem /sys/power/state never return, or don't
 return till the guest wakes up.
 
 Yes, but that can be viewed as an implementation detail because this is
 also possible with the current code (ie. if the suspend process manages
 to suspend the guest before qemu-ga is able to emit a response).
 
 So *every* suspend/shutdown command will result in a timeout or
 indefinite hang to the user. Honestly I just find the behavior
 completely unexpected/unintuitive and would prefer to reduce it to
 being a corner case. As the code stands currently it's actually
 extremely rare that a response won't be returned before the commands
 are executed.
 
 I don't think we can assume this is a corner case. It all depends on how
 the two processes are scheduled. On an idle VM it's more likely that qemu-ga
 will emit the response first because the suspend process does more I/O, but
 that really depends on the scheduler/system load. This is also true for the
 shutdown command.
 
 As we have discussed with Anthony on irc months ago, the client can't expect
 a response from this command and should reset the connection before sending
 new commands when the VM resumes.
 
 If this turns out to be a problem for libvirt, I'd say it's a libvirt bug.
 
 So that's why we're jumping through hoops atm. It's more a
 philosophical reason than a technical one.

 But if we were to do things as you proposed and document things as
 this command will *only* show a response on error, I guess maybe I
 can live with that... in the case of shutdown older clients will
 start seeing timeouts where they previously expected a nothing
 response. The nothing response never entailed success or failure so
 this shouldn't break anything that wasn't already broken however...
 
 Yes, and again, depending on the VM load it's possible that the VM vanishes
 before qemu-ga emits its response.
 
 But, I think if we tell users we'll *only* send response on error,
 we should do our part to *not* send the responses, rather than relying
 on them having implemented the reset mechanism to throw them away after
 guest wake-up. What we could do is allow a command to set a flag, after
 it reaps it's child (in the case of suspend this would be after
 wake-up, for shutdown it'd basically be a no-op, but worth adding
 for readability sake), to have qemu-ga not send a response. We'd
 implement it similarly to how we did ga_set_response_delimited().
 
 Fine with me. Stating that do not wait for an OK response, because none
 will be sent sounds clearer than an OK response may, or may not be
 emitted. Or it may be emitted when the VM resumes.


Just to make this clear: this report-only-error behavior concerns only
guest-suspend-* and guest-shutdown commands, right? Because otherwise,
if we enable such behavior for all commands (e.g. fsfreeze) I think we
are entering the world of pain.

From user POV there is a huge difference between those 2 sets of
commands (suspend/shutdown on one side, the others on the other side):
- the first emits an event on qemu monitor, so libvirt can catch that
and confirm suspend/shutdown has succeeded
- while the latter emits no event, it is impossible to determine command
successfulness. Simply, because it is hard to tell if command is in
execution phase (e.g. kernel is syncing disks) or command has already
finished (and FS is frozen already).

Therefore, I can live with making commands from suspend/shutdown family
only-error-reporting as long as I can check guest has been really
suspended/shut off.

Michal

Re: [Qemu-devel] [PATCH] arm-dis: Fix spelling in comments (iff - if)

On Tue, Apr 17, 2012 at 07:58:13PM +0200, Stefan Weil wrote:
 The spelling 'iff' is sometimes used for 'if and only if'.
 Even if that meaning could be applied here, it is not used
 consistently. It is also quite unusual to use 'if and only if'
 in technical documentation. Therefore a simple 'if' should be
 preferred here.
 
 Signed-off-by: Stefan Weil s...@weilnetz.de
 ---
  arm-dis.c |   22 +++---
  1 files changed, 11 insertions(+), 11 deletions(-)

Given the discussion about the origin of this code I think it makes
sense to leave the 'iff' to reduce spurious differences.

I am not taking this patch for now.  Feel free to discuss more if you do
think it should go in.

Stefan

Re: [Qemu-devel] [PATCH] usb: add serial number generator


Hi,

Looks good, ack.

Regards,

Hans


On 04/20/2012 12:55 PM, Gerd Hoffmann wrote:

This patch adds a function which creates unique serial numbers for usb
devices and puts it into use.  Windows guests tend to become unhappy if
they find two identical usb devices in the system.  Effects range from
non-functional devices (with yellow exclamation mark in device manager)
to BSODs.  Handing out unique serial numbers to devices fixes this.

With this patch applied almost all emulated devices get a generated,
unique serial number.  There are two exceptions:

  * usb-storage devices will prefer a user-specified serial number
and will only get a generated number in case the serial property
is unset.
  * usb-hid devices keep the fixed serial number 42 as it is used
to signal remote wakeup actually works.
See commit 7b074a22dab4bdda9864b933f1bc811a3db42845

Signed-off-by: Gerd Hoffmannkra...@redhat.com
---
  hw/usb/desc.c |   32 
  hw/usb/desc.h |1 +
  hw/usb/dev-audio.c|1 +
  hw/usb/dev-bluetooth.c|1 +
  hw/usb/dev-hub.c  |1 +
  hw/usb/dev-network.c  |1 +
  hw/usb/dev-serial.c   |1 +
  hw/usb/dev-smartcard-reader.c |1 +
  hw/usb/dev-storage.c  |2 ++
  hw/usb/dev-wacom.c|1 +
  10 files changed, 42 insertions(+), 0 deletions(-)

diff --git a/hw/usb/desc.c b/hw/usb/desc.c
index 3c77368..e8a3c6a 100644
--- a/hw/usb/desc.c
+++ b/hw/usb/desc.c
@@ -1,3 +1,5 @@
+#includectype.h
+
  #include hw/usb.h
  #include hw/usb/desc.h
  #include trace.h
@@ -412,6 +414,36 @@ void usb_desc_set_string(USBDevice *dev, uint8_t index, 
const char *str)
  s-str = g_strdup(str);
  }

+/*
+ * This function creates a serial number for a usb device.
+ * The serial number should:
+ *   (a) Be unique within the virtual machine.
+ *   (b) Be constant, so you don't get a new one each
+ *   time the guest is started.
+ * So we are using the physical location to generate a serial number
+ * from it.  It has three pieces:  First a fixed, device-specific
+ * prefix.  Second the device path of the host controller (which is
+ * the pci address in most cases).  Third the physical port path.
+ * Results in serial numbers like this: 314159-:00:1d.7-3.
+ */
+void usb_desc_create_serial(USBDevice *dev)
+{
+DeviceState *hcd = dev-qdev.parent_bus-parent;
+const USBDesc *desc = usb_device_get_usb_desc(dev);
+int index = desc-id.iSerialNumber;
+char serial[64];
+int dst;
+
+assert(index != 0  desc-str[index] != NULL);
+dst = snprintf(serial, sizeof(serial), %s, desc-str[index]);
+if (hcd  hcd-parent_bus  hcd-parent_bus-info-get_dev_path) {
+char *path = hcd-parent_bus-info-get_dev_path(hcd);
+dst += snprintf(serial+dst, sizeof(serial)-dst, -%s, path);
+}
+dst += snprintf(serial+dst, sizeof(serial)-dst, -%s, dev-port-path);
+usb_desc_set_string(dev, index, serial);
+}
+
  const char *usb_desc_get_string(USBDevice *dev, uint8_t index)
  {
  USBDescString *s;
diff --git a/hw/usb/desc.h b/hw/usb/desc.h
index d164e8f..7cf5442 100644
--- a/hw/usb/desc.h
+++ b/hw/usb/desc.h
@@ -171,6 +171,7 @@ int usb_desc_other(const USBDescOther *desc, uint8_t *dest, 
size_t len);
  void usb_desc_init(USBDevice *dev);
  void usb_desc_attach(USBDevice *dev);
  void usb_desc_set_string(USBDevice *dev, uint8_t index, const char *str);
+void usb_desc_create_serial(USBDevice *dev);
  const char *usb_desc_get_string(USBDevice *dev, uint8_t index);
  int usb_desc_string(USBDevice *dev, int index, uint8_t *dest, size_t len);
  int usb_desc_get_descriptor(USBDevice *dev, int value, uint8_t *dest, size_t 
len);
diff --git a/hw/usb/dev-audio.c b/hw/usb/dev-audio.c
index 426b95c..79b75fb 100644
--- a/hw/usb/dev-audio.c
+++ b/hw/usb/dev-audio.c
@@ -648,6 +648,7 @@ static int usb_audio_initfn(USBDevice *dev)
  {
  USBAudioState *s = DO_UPCAST(USBAudioState, dev, dev);

+usb_desc_create_serial(dev);
  usb_desc_init(dev);
  s-dev.opaque = s;
  AUD_register_card(usb-audio,s-card);
diff --git a/hw/usb/dev-bluetooth.c b/hw/usb/dev-bluetooth.c
index 195370c..6b74eff 100644
--- a/hw/usb/dev-bluetooth.c
+++ b/hw/usb/dev-bluetooth.c
@@ -494,6 +494,7 @@ static void usb_bt_handle_destroy(USBDevice *dev)

  static int usb_bt_initfn(USBDevice *dev)
  {
+usb_desc_create_serial(dev);
  usb_desc_init(dev);
  return 0;
  }
diff --git a/hw/usb/dev-hub.c b/hw/usb/dev-hub.c
index 9c91665..b5962da 100644
--- a/hw/usb/dev-hub.c
+++ b/hw/usb/dev-hub.c
@@ -520,6 +520,7 @@ static int usb_hub_initfn(USBDevice *dev)
  USBHubPort *port;
  int i;

+usb_desc_create_serial(dev);
  usb_desc_init(dev);
  s-intr = usb_ep_get(dev, USB_TOKEN_IN, 1);
  for (i = 0; i  NUM_PORTS; i++) {
diff --git a/hw/usb/dev-network.c b/hw/usb/dev-network.c
index cff55f2..b238a09 100644
--- a/hw/usb/dev-network.c
+++

Re: [Qemu-devel] [Qemu-trivial] [PATCH] Add .gitignore for tests/

On Fri, Apr 20, 2012 at 11:40:24AM +1000, David Gibson wrote:
 The new autotests in tests/ generate a number of files, both
 executable and source, which are not caught by the existing .gitignore
 files.  This patch adds a new .gitignore in tests/ which covers these.
 
 Signed-off-by: David Gibson da...@gibson.dropbear.id.au
 ---
  tests/.gitignore |   13 +
  1 file changed, 13 insertions(+)
  create mode 100644 tests/.gitignore

I sent a similar patch recently but yours is more comprehensive.  I've
made one small change: instead of 'rtc-test' ignore 'tests/*-test' so
that future tests do not need to be added to .gitignore on a
case-by-case basis.

Thanks, applied to the trivial patches tree:
https://github.com/stefanha/qemu/commits/trivial-patches

Stefan

Re: [Qemu-devel] [Qemu-trivial] [PATCH] e1000: Fix spelling (segmentaion - segmentation) in debug output

On Wed, Apr 18, 2012 at 07:28:34AM +0200, Stefan Weil wrote:
 This was reported by https://bugs.launchpad.net/qemu/+bug/984476.
 
 I also changed the case for 'error'.
 
 Signed-off-by: Stefan Weil s...@weilnetz.de
 ---
  hw/e1000.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

Thanks, applied to the trivial patches tree:
https://github.com/stefanha/qemu/commits/trivial-patches

Stefan

Re: [Qemu-devel] [PATCH 14/20] qcow2: Factor out count_cow_clusters

On Fri, Apr 20, 2012 at 9:24 AM, Kevin Wolf kw...@redhat.com wrote:
 Am 19.04.2012 23:18, schrieb Marcelo Tosatti:
 On Thu, Apr 19, 2012 at 05:14:20PM -0300, Marcelo Tosatti wrote:
 There is one intended change in functionality in this patch, which is
 that it allocates new clusters even when it could satisfy the first part
 of the request with already allocated clusters. In order to check if
 there is a problem with this scenario, the following patch should revert
 to the old behaviour:

 --- a/block/qcow2-cluster.c
 +++ b/block/qcow2-cluster.c
 @@ -847,7 +847,7 @@ again:
          keep_clusters = count_contiguous_clusters(nb_clusters,
 s-cluster_size,
                                                    l2_table[l2_index],
 0, 0);
          assert(keep_clusters = nb_clusters);
 -        nb_clusters -= keep_clusters;
 +        nb_clusters = 0;
      } else {
          /* For the moment, overwrite compressed clusters one by one */
          if (cluster_offset  QCOW_OFLAG_COMPRESSED) {

 The rest is meant to be a functionally equivalent rewrite of the old
 code that was required in order to allow this change.

 Testing.

 Corruption gone with patch above.

 Okay, so something must be wrong only with the new code paths, which
 makes things a bit easier. I'll have another closer look. Stefan, can
 you re-review 250196f1 as well?

I'm taking a look.

Stefan

Re: [Qemu-devel] [PATCH] gitignore: ignore qtest binaries

On Fri, Apr 13, 2012 at 03:17:21PM +0100, Stefan Hajnoczi wrote:
 Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
 ---
  .gitignore |1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/.gitignore b/.gitignore
 index 9859c7d..db74219 100644
 --- a/.gitignore
 +++ b/.gitignore
 @@ -89,3 +89,4 @@ cscope.*
  tags
  TAGS
  *~
 +tests/*-test

Dropped in favor of the patch from David Gibson
da...@gibson.dropbear.id.au which does more.

Stefan

Re: [Qemu-devel] [PATCH 00/20] PPC: AREG0 conversion

2012-04-20 Thread Alexander Graf


On 16.04.2012, at 21:46, Blue Swirl wrote:

 On Mon, Apr 16, 2012 at 19:28, Peter Maydell peter.mayd...@linaro.org wrote:
 On 16 April 2012 20:12, Blue Swirl blauwir...@gmail.com wrote:
 On Mon, Apr 16, 2012 at 16:53, Alexander Graf ag...@suse.de wrote:
 If you can update it on top of ppc-next and add patch descriptions
 in every patch (more than just the subject line), I'll happily apply
 it and if possible also pull it in before the hard freeze.
 
 OK. Thanks for the review. But I'd prefer to apply them directly to
 qemu.git, because I'm using StGit for the patch stack and it doesn't
 work with different branches.
 
 I use stgit a lot and I haven't run into this issue yet... Couple
 of approaches that spring to mind:
 1. use stg rebase ppc-next to put your patch stack on top of
 ppc-next (This is how I did the recent cp15-rework series which sits
 on top of the drop-cpu_reset_model_id patchset, for instance.)
 2. create a new branch starting from ppc-next and stg pick the relevant
 patches into it. (I use that for sending subsets of omap related patches
 from qemu-linaro.)
 
 Thanks, cool. I'll try that. I'm considering dropping stgit (it has
 emptied too many patches) and use plain git, this way I could start
 using branches.

So how are things going there? Apparently all the patches from ppc-next should 
be in mainline, Andreas is happy with the state of QOM on PPC as it is by now 
too, so it's a perfect point in time to do this change!


Alex

Re: [Qemu-devel] [RFC 0/2]: qemu-ga: drop automatic reaper

Il 20/04/2012 14:07, Michal Privoznik ha scritto:
 Just to make this clear: this report-only-error behavior concerns only
 guest-suspend-* and guest-shutdown commands, right? Because otherwise,
 if we enable such behavior for all commands (e.g. fsfreeze) I think we
 are entering the world of pain.

Yes, of course.

I hadn't thought of the QEMU event, but that makes not reporting success
of suspend/shutdown totally acceptable.  Especially considering that the
guest can _never_ be sure that suspend will succeed, while QEMU can
report it accurately.

Paolo

[Qemu-devel] [PATCH 4/7] pflash_cfi01: remove redundant line

From: Eric Bénard e...@eukrea.com

Signed-off-by: Eric Bénard e...@eukrea.com
Reviewed-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 hw/pflash_cfi01.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/hw/pflash_cfi01.c b/hw/pflash_cfi01.c
index b03f623..d1c7423 100644
--- a/hw/pflash_cfi01.c
+++ b/hw/pflash_cfi01.c
@@ -144,7 +144,6 @@ static uint32_t pflash_read (pflash_t *pfl, 
target_phys_addr_t offset,
 } else {
 ret = p[offset];
 ret |= p[offset + 1]  8;
-ret |= p[offset + 1]  8;
 ret |= p[offset + 2]  16;
 ret |= p[offset + 3]  24;
 }
-- 
1.7.9.5

[Qemu-devel] [PATCH 5/7] spice-qemu-char.c: Show what name is unsupported

From: Eduardo Elias Ferreira ed...@linux.vnet.ibm.com

Signed-off-by: Eduardo Elias Ferreira ed...@linux.vnet.ibm.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 spice-qemu-char.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/spice-qemu-char.c b/spice-qemu-char.c
index 1e735ff..09aa22d 100644
--- a/spice-qemu-char.c
+++ b/spice-qemu-char.c
@@ -209,7 +209,7 @@ CharDriverState *qemu_chr_open_spice(QemuOpts *opts)
 }
 }
 if (subtype == NULL) {
-fprintf(stderr, spice-qemu-char: unsupported name\n);
+fprintf(stderr, spice-qemu-char: unsupported name: %s\n, name);
 print_allowed_subtypes();
 return NULL;
 }
-- 
1.7.9.5

[Qemu-devel] [PATCH 2/7] fix block_job_set_speed name in documentation

From: Paolo Bonzini pbonz...@redhat.com

Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 hmp-commands.hx |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index a6f5a84..461fa59 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -92,8 +92,8 @@ ETEXI
 },
 
 STEXI
-@item block_job_set_stream
-@findex block_job_set_stream
+@item block_job_set_speed
+@findex block_job_set_speed
 Set maximum speed for a background block operation.
 ETEXI
 
-- 
1.7.9.5

[Qemu-devel] [PATCH 3/7] qxl: Add missing GCC_FMT_ATTR and fix format specifier

From: Stefan Weil s...@weilnetz.de

val is an uint64_t, therefore %d was not correct.

Signed-off-by: Stefan Weil s...@weilnetz.de
Acked-by: Gerd Hoffmann kra...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 hw/qxl.c |2 +-
 hw/qxl.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/qxl.c b/hw/qxl.c
index db2318e..c3540c3 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1370,7 +1370,7 @@ async_common:
 case QXL_IO_DESTROY_SURFACE_WAIT:
 if (val = NUM_SURFACES) {
 qxl_guest_bug(d, QXL_IO_DESTROY_SURFACE (async=%d):
- %d = NUM_SURFACES, async, val);
+ % PRIu64  = NUM_SURFACES, async, val);
 goto cancel_async;
 }
 qxl_spice_destroy_surface_wait(d, val, async);
diff --git a/hw/qxl.h b/hw/qxl.h
index 11a0db3..cbb1e2d 100644
--- a/hw/qxl.h
+++ b/hw/qxl.h
@@ -127,7 +127,7 @@ typedef struct PCIQXLDevice {
 
 /* qxl.c */
 void *qxl_phys2virt(PCIQXLDevice *qxl, QXLPHYSICAL phys, int group_id);
-void qxl_guest_bug(PCIQXLDevice *qxl, const char *msg, ...);
+void qxl_guest_bug(PCIQXLDevice *qxl, const char *msg, ...) GCC_FMT_ATTR(2, 3);
 
 void qxl_spice_update_area(PCIQXLDevice *qxl, uint32_t surface_id,
struct QXLRect *area, struct QXLRect *dirty_rects,
-- 
1.7.9.5

[Qemu-devel] [PATCH 6/7] e1000: Fix spelling (segmentaion - segmentation) in debug output

From: Stefan Weil s...@weilnetz.de

This was reported by https://bugs.launchpad.net/qemu/+bug/984476.

I also changed the case for 'error'.

Signed-off-by: Stefan Weil s...@weilnetz.de
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 hw/e1000.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/e1000.c b/hw/e1000.c
index 7babc0b..9c76462 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -481,7 +481,7 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
 } while (split_size -= bytes);
 } else if (!tp-tse  tp-cptse) {
 // context descriptor TSE is not set, while data descriptor TSE is set
-DBGOUT(TXERR, TCP segmentaion Error\n);
+DBGOUT(TXERR, TCP segmentation error\n);
 } else {
 split_size = MIN(sizeof(tp-data) - tp-size, split_size);
 pci_dma_read(s-dev, addr, tp-data + tp-size, split_size);
-- 
1.7.9.5

[Qemu-devel] [PATCH 1/7] error.c: don't return value for void function

From: Amos Kong ak...@redhat.com

It is invalid to return a value from a function
returning void.

[C99 6.8.6.4 says A return statement with an expression shall not
appear in a function whose return type is void but gcc 4.6.3 with QEMU
compile flags does not complain.  It's still worth fixing this.  Stefan]

Signed-off-by: Amos Kong ak...@redhat.com
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 error.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/error.c b/error.c
index d3455ab..a52b771 100644
--- a/error.c
+++ b/error.c
@@ -93,7 +93,7 @@ QDict *error_get_data(Error *err)
 void error_set_field(Error *err, const char *field, const char *value)
 {
 QDict *dict = qdict_get_qdict(err-obj, data);
-return qdict_put(dict, field, qstring_from_str(value));
+qdict_put(dict, field, qstring_from_str(value));
 }
 
 void error_free(Error *err)
-- 
1.7.9.5

[Qemu-devel] [PULL 0/7] Trivial patches for 14 to 20 April 2012

The following changes since commit 51006bbc45bc74977ae538190a53df2af534acb9:

  Merge remote-tracking branch 'origin/master' into staging (2012-04-18 
10:06:09 -0500)

are available in the git repository at:


  git://github.com/stefanha/qemu.git trivial-patches

for you to fetch changes up to fe4477451f82028c042eb700a20185d8cf65:

  Add .gitignore for tests/ (2012-04-20 13:23:27 +0100)


Amos Kong (1):
  error.c: don't return value for void function

David Gibson (1):
  Add .gitignore for tests/

Eduardo Elias Ferreira (1):
  spice-qemu-char.c: Show what name is unsupported

Eric Bénard (1):
  pflash_cfi01: remove redundant line

Paolo Bonzini (1):
  fix block_job_set_speed name in documentation

Stefan Weil (2):
  qxl: Add missing GCC_FMT_ATTR and fix format specifier
  e1000: Fix spelling (segmentaion - segmentation) in debug output

 error.c   |2 +-
 hmp-commands.hx   |4 ++--
 hw/e1000.c|2 +-
 hw/pflash_cfi01.c |1 -
 hw/qxl.c  |2 +-
 hw/qxl.h  |2 +-
 spice-qemu-char.c |2 +-
 tests/.gitignore  |   13 +
 8 files changed, 20 insertions(+), 8 deletions(-)
 create mode 100644 tests/.gitignore
-- 
1.7.9.5

[Qemu-devel] [PATCH 7/7] Add .gitignore for tests/

From: David Gibson da...@gibson.dropbear.id.au

The new autotests in tests/ generate a number of files, both
executable and source, which are not caught by the existing .gitignore
files.  This patch adds a new .gitignore in tests/ which covers these.

[Changed 'rtc-test' to '*-test' so future tests do not need to be added
to .gitignore on a case-by-case basis.  Stefan]

Signed-off-by: David Gibson da...@gibson.dropbear.id.au
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 tests/.gitignore |   13 +
 1 file changed, 13 insertions(+)
 create mode 100644 tests/.gitignore

diff --git a/tests/.gitignore b/tests/.gitignore
new file mode 100644
index 000..f9041f3
--- /dev/null
+++ b/tests/.gitignore
@@ -0,0 +1,13 @@
+check-qdict
+check-qfloat
+check-qint
+check-qjson
+check-qlist
+check-qstring
+test-qapi-types.[ch]
+test-qapi-visit.[ch]
+test-qmp-commands.h
+test-qmp-commands
+test-qmp-input-strict
+test-qmp-marshal.c
+*-test
-- 
1.7.9.5

Re: [Qemu-devel] [PATCH 14/20] qcow2: Factor out count_cow_clusters

On Fri, Apr 20, 2012 at 1:27 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Fri, Apr 20, 2012 at 9:24 AM, Kevin Wolf kw...@redhat.com wrote:
Am 19.04.2012 23:18, schrieb Marcelo Tosatti:
On Thu, Apr 19, 2012 at 05:14:20PM -0300, Marcelo Tosatti wrote:
There is one intended change in functionality in this patch, which is
that it allocates new clusters even when it could satisfy the first part
of the request with already allocated clusters. In order to check if
there is a problem with this scenario, the following patch should revert
to the old behaviour:

--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -847,7 +847,7 @@ again:
keep_clusters = count_contiguous_clusters(nb_clusters,
s-cluster_size,
l2_table[l2_index],
0, 0);
assert(keep_clusters = nb_clusters);
- nb_clusters -= keep_clusters;
+ nb_clusters = 0;
} else {
/* For the moment, overwrite compressed clusters one by one */
if (cluster_offset QCOW_OFLAG_COMPRESSED) {

The rest is meant to be a functionally equivalent rewrite of the old
code that was required in order to allow this change.

Testing.

Corruption gone with patch above.

Okay, so something must be wrong only with the new code paths, which
makes things a bit easier. I'll have another closer look. Stefan, can
you re-review 250196f1 as well?

I'm taking a look.

Just looking at the qemu-img check output that Marcelo posted I'm
interpreting that as OFLAG_COPIED was set on the offset but its
refcount was 2.

The refcount shouldn't be 2 unless internal snapshots were used.

So we probably incremented the refcount either too often or for the
wrong block (which is more likely since the guest sees corruption).

Stefan

Re: [Qemu-devel] [PATCH 1/2 v5-test] add function DMA_set_return and DMA_set_channel_async in dma.c

Il 20/04/2012 04:36, Zhi Hui Li ha scritto:
 If I add the code :
if ((0 == (d-mask  mask))  (0 != (d-status  (mask  4 {
channel_run (icont, ichan);
}
 Because function DMA_set_return is called in fdctrl_read_DMA_cb and
 fdctrl_write_DMA_cb, the fdctrl_stop_transfer will release the channel,
 but fdctrl_stop_transfer is after the DMA_set_return, so the channel_run
 will run again, so here I delete the above code.

I looked again at the code, and man it is painful! :)  (Both the
synchronous and asynchronous versions).

I think the best bet is to do the transfer one sector at a time even in
the asynchronous code, and reuse the fifo buffer for this).

Remember that your final objective is to execute exactly the same code
that is in QEMU right now, only scattered across multiple function calls.

Some other notes:

- you don't need the opaque_cb.  Just pass the fdctrl, the dma_len can
be stored in there and the channel is already available

- the scan support is completely broken in QEMU already.  It always
returns SEH (scan equal hit), probably because of misplaced gotos.

Paolo

Re: [Qemu-devel] [PATCH 14/20] qcow2: Factor out count_cow_clusters

Am 20.04.2012 15:06, schrieb Stefan Hajnoczi:
 On Fri, Apr 20, 2012 at 1:27 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
 On Fri, Apr 20, 2012 at 9:24 AM, Kevin Wolf kw...@redhat.com wrote:
 Am 19.04.2012 23:18, schrieb Marcelo Tosatti:
 On Thu, Apr 19, 2012 at 05:14:20PM -0300, Marcelo Tosatti wrote:
 There is one intended change in functionality in this patch, which is
 that it allocates new clusters even when it could satisfy the first part
 of the request with already allocated clusters. In order to check if
 there is a problem with this scenario, the following patch should revert
 to the old behaviour:

 --- a/block/qcow2-cluster.c
 +++ b/block/qcow2-cluster.c
 @@ -847,7 +847,7 @@ again:
  keep_clusters = count_contiguous_clusters(nb_clusters,
 s-cluster_size,
l2_table[l2_index],
 0, 0);
  assert(keep_clusters = nb_clusters);
 -nb_clusters -= keep_clusters;
 +nb_clusters = 0;
  } else {
  /* For the moment, overwrite compressed clusters one by one */
  if (cluster_offset  QCOW_OFLAG_COMPRESSED) {

 The rest is meant to be a functionally equivalent rewrite of the old
 code that was required in order to allow this change.

 Testing.

 Corruption gone with patch above.

 Okay, so something must be wrong only with the new code paths, which
 makes things a bit easier. I'll have another closer look. Stefan, can
 you re-review 250196f1 as well?

 I'm taking a look.
 
 Just looking at the qemu-img check output that Marcelo posted I'm
 interpreting that as OFLAG_COPIED was set on the offset but its
 refcount was 2.
 
 The refcount shouldn't be 2 unless internal snapshots were used.
 
 So we probably incremented the refcount either too often or for the
 wrong block (which is more likely since the guest sees corruption).

I've looked at the same thing now and I think the same cluster was used
both for a regular data allocation and for a new refcount block. This
may happen because alloc_refcount_block() uses s-free_cluster_index
which is updated by qcow2_alloc_cluster_noref(), but not by
qcow2_alloc_cluster_at(). Just a theory so far, though, and not yet
tried out in practice. If this is it, a patch would look like this
(completely untested as well):

--- a/block/qcow2-refcount.c
+++ b/block/qcow2-refcount.c
@@ -587,6 +587,7 @@ int qcow2_alloc_clusters_at(BlockDriverState *bs,
uint64_t offset,
 {
 BDRVQcowState *s = bs-opaque;
 uint64_t cluster_index;
+uint64_t old_free_cluster_index;
 int i, refcount, ret;

 /* Check how many clusters there are free */
@@ -602,11 +603,16 @@ int qcow2_alloc_clusters_at(BlockDriverState *bs,
uint64_t offset,
 }

 /* And then allocate them */
+old_free_cluster_index = s-free_cluster_index;
+s-free_cluster_index = cluster_index + i;
+
 ret = update_refcount(bs, offset, i  s-cluster_bits, 1);
 if (ret  0) {
 return ret;
 }

+s-free_cluster_index = old_free_cluster_index;
+
 return i;
 }

Kevin

[Qemu-devel] [PULL BUILD FIX] build xc_hvm_inject_msi on Xen 4.2

2012-04-20 Thread Stefano Stabellini

Anthony,
please pull:

git://xenbits.xen.org/people/sstabellini/qemu-dm.git build_fix


this small patch series fixes the build breakage introduced by
f1dbf015dfb0aa7f66f710a1f1bc58b662951de2 with Xen  4.2.

The problem is that xc_hvm_inject_msi is only defined from Xen 4.2
onwards so we need to provide a compatibility function for older Xen
versions.

Stefano Stabellini (2):
  xen,configure: detect Xen 4.2
  xen: add a dummy xc_hvm_inject_msi for Xen  4.2

 configure   |   25 +
 hw/pc.c |2 +-
 hw/xen.h|   10 ++
 hw/xen_common.h |   15 +++
 xen-all.c   |2 +-
 5 files changed, 52 insertions(+), 2 deletions(-)

Cheers,

Stefano

Re: [Qemu-devel] [RFC 0/2]: qemu-ga: drop automatic reaper

2012-04-20 Thread Luiz Capitulino

On Fri, 20 Apr 2012 14:07:16 +0200
Michal Privoznik mpriv...@redhat.com wrote:

  But, I think if we tell users we'll *only* send response on error,
  we should do our part to *not* send the responses, rather than relying
  on them having implemented the reset mechanism to throw them away after
  guest wake-up. What we could do is allow a command to set a flag, after
  it reaps it's child (in the case of suspend this would be after
  wake-up, for shutdown it'd basically be a no-op, but worth adding
  for readability sake), to have qemu-ga not send a response. We'd
  implement it similarly to how we did ga_set_response_delimited().
  
  Fine with me. Stating that do not wait for an OK response, because none
  will be sent sounds clearer than an OK response may, or may not be
  emitted. Or it may be emitted when the VM resumes.
 
 
 Just to make this clear: this report-only-error behavior concerns only
 guest-suspend-* and guest-shutdown commands, right? Because otherwise,
 if we enable such behavior for all commands (e.g. fsfreeze) I think we
 are entering the world of pain.

Exactly, this would only concern the suspend and shutdown commands.

 From user POV there is a huge difference between those 2 sets of
 commands (suspend/shutdown on one side, the others on the other side):
 - the first emits an event on qemu monitor, so libvirt can catch that
 and confirm suspend/shutdown has succeeded

Oops, this is a different subject but there's a problem here. Events are just
hints, they shouldn't be your definitive source of information.

For shutdown and suspend-disk, I think that the best indication that
the command has succeeded is that the VM will successfully exit. We could
also have a special exit status code for suspend-to-disk, because the
command could run in parallel with the user powering off the VM and libvirt
wouldn't know that (and would think the VM is suspended, while it's really
powered-off).

For suspend-ram and suspend-hybrid, we're missing a 'suspended' RunState.
The event serve as a good hint and you can use it, but if it's lost for some
reason (eg. libvirt crashes before it's received) then libvirt can learn the
VM state by issuing query-status.

Now, going back to the original subject. I have to admit that I'm not sure
what's the best way to go here.

I'll try to recapitulate (for myself and for those that may be confused) I'll be
verbose a bit.

We have two qemu-ga commands that are special: guest-shutdown and the 
guest-suspend
family. They are special because they shut down the VM or suspend its execution
(meaning that the world of qemu-ga is gone or gets completely frozen).

Today, shutdown is an asynchronous operation: qemu-ga gets the shutdown process
started and returns to accept new commands. For qemu-ga clients, this implies:

 1. errors in the shutdown operation are not reported back
 2. qemu-ga doesn't block

For qemu-ga this implies having a way to automatically reap terminated children
processes.

The guest-suspend commands do the same when executing the suspend operation,
but before they do that they need to query the VM for suspend support and
this is done by executing pm-is-supported (if available). This fact shouldn't
be visible to qemu-ga clients, but it has two internal implications:

 1. The operation is half synchronous and half asynchronous
 2. In order to bypass the automatic process reaper in qemu-ga when executing
pm-is-supported, we have to play tricks that makes the suspend code
more complex than it should be

We have two options:

 1. Keep the current behavior (explained above, shutdown is async, suspend
is half sync half async). For libvirt this means nothing changes, for
qemu-ga this means more complex code

 2. Change everything to be synchronous (this series). This essentially means:

 A. errors are going to reported back
 B. qemu-ga will block
 C. we avoid all the dirty tricks, and qemu-ga code becomes simpler
 D. In theory, this should be a compatible change due to the end of world
nature of the commands involved

A third possible option would be to have asynchronous support. But I'm not
sure whether this would fit well and how complex this would be (specially
because of fork()).

[Qemu-devel] [PATCH] qcow2: Fix refcount block allocation during qcow2_allocate_cluster_at()

Refcount block allocation and refcount table growth rely on
s-free_cluster_index pointing to somewhere after the current
allocation. Change qcow2_allocate_cluster_at() to fulfill this
assumption.

Without this change it could happen that a newly allocated refcount
block and the allocated data block point to the same area in the image
file, causing data corruption in the long run.

This fixes a bug that became first visible after commit 250196f1.

Signed-off-by: Kevin Wolf kw...@redhat.com
---
 block/qcow2-refcount.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c
index 565bd54..6c38337 100644
--- a/block/qcow2-refcount.c
+++ b/block/qcow2-refcount.c
@@ -587,6 +587,7 @@ int qcow2_alloc_clusters_at(BlockDriverState *bs, uint64_t 
offset,
 {
 BDRVQcowState *s = bs-opaque;
 uint64_t cluster_index;
+uint64_t old_free_cluster_index;
 int i, refcount, ret;
 
 /* Check how many clusters there are free */
@@ -602,11 +603,16 @@ int qcow2_alloc_clusters_at(BlockDriverState *bs, 
uint64_t offset,
 }
 
 /* And then allocate them */
+old_free_cluster_index = s-free_cluster_index;
+s-free_cluster_index = cluster_index + i;
+
 ret = update_refcount(bs, offset, i  s-cluster_bits, 1);
 if (ret  0) {
 return ret;
 }
 
+s-free_cluster_index = old_free_cluster_index;
+
 return i;
 }
 
-- 
1.7.6.5

Re: [Qemu-devel] [RFC PATCH 2/9][SeaBIOS] Implement acpi-dsdt functions for memory hotplug.

2012-04-20 Thread Vasilis Liaskovitis

Hi,

On Fri, Apr 20, 2012 at 12:55:24PM +0200, Igor Mammedov wrote:
 +/* Memory eject notify method */
 +OperationRegion(MEMJ, SystemIO, 0xaf40, 32)
 +Field (MEMJ, ByteAcc, NoLock, Preserve)
 +{
 +MPE, 256
 +}
 +
 +Method (MPEJ, 2, NotSerialized) {
 +// _EJ0 method - eject callback
 +Store(ShiftLeft(1,Arg0), MPE)
 +Sleep(200)
 +}
 MPE is write only and only one memslot is ejected at a time. Why 256 
 bit-field is here then?
 Could we use just 1 byte and write a slot number into it and save some io 
 address space this way?

good point. This was implemented similarly to the hot-add/status register only
for symmetry, but you are right, since only one slot is ejected at a time, this
can be reduced to one byte and save space. I will update for the next version.

 
 +
 +/* Memory hotplug notify method */
 +OperationRegion(MEST, SystemIO, 0xaf20, 32)
 It's more a suggestion: move it a bit farther to allow maybe 1024 cpus in the 
 future.
 That will prevent compatibility a headache, if we decide to expand support to 
 more then
 256 cpus.

ok, I will move it to 0xaf80 or higher (so cpu-hotplug could be extended to at
least 1024 cpus)

 
 Or event better to make this address configurable in run-time and build this 
 var along
 with SSDT (converting along the way all other hard-coded io ports to the same 
 generic
 run-time interface). This wish is out of scope of this patch-set, but what
 do you think about the idea?

yes, that would give more flexibility and avoid more compatibility headaches.
As you say it's not a main issue for the series, but I can work on it as we 
start
converting hardcoded i/o ports to configurable properties.

thanks,

- Vasilis

Re: [Qemu-devel] [RFC PATCH 0/9] ACPI memory hotplug

2012-04-20 Thread Vasilis Liaskovitis

On Thu, Apr 19, 2012 at 04:08:38PM +0200, Vasilis Liaskovitis wrote:
 
 series is based on uq/master for qemu-kvm, and master for seabios. Can be 
 found
 also at:
forgot to paste the repo links in the original coverletter, here they are if
someone wants them:

https://github.com/vliaskov/qemu-kvm/commits/memory-hotplug 
https://github.com/vliaskov/seabios/commits/memory-hotplug

thanks,

- Vasilis

Re: [Qemu-devel] [PATCH v2 01/14] target-arm: Add QOM subclasses for each ARM cpu implementation

Am 15.04.2012 01:18, schrieb Peter Maydell:
 On 14 April 2012 18:39, Andreas Färber afaer...@suse.de wrote:
 Am 14.04.2012 18:42, schrieb Peter Maydell:
 Register subclasses for each ARM CPU implementation (with the
 exception of pxa270, which is an alias for pxa270-a0).

 This is no longer accurate, we do have a subclass for pxa270 again.
 
 Oops, yes.
 
 +/* pxa270 is a legacy alias for pxa270-a0 */
 +{ .name = pxa270,  .initfn = pxa270a0_initfn },
 +{ .name = pxa270-a0,   .initfn = pxa270a0_initfn },
 +{ .name = pxa270-a1,   .initfn = pxa270a1_initfn },
 +{ .name = pxa270-b0,   .initfn = pxa270b0_initfn },
 +{ .name = pxa270-b1,   .initfn = pxa270b1_initfn },
 +{ .name = pxa270-c0,   .initfn = pxa270c0_initfn },
 +{ .name = pxa270-c5,   .initfn = pxa270c5_initfn },

 Wrt the comment: What's your plan for these? I think an earlier patch of
 mine went back to keeping only pxa270 and having the other ones be
 aliases for pxa270 plus some object_property_set_int()s. Are you
 planning to keep their initfns around instead?
 
 I don't really have a plan here -- these are a little ugly but not
 horrifically or wide-rangingly so, so I will probably leave them be
 in favour of trying to deal with other bits of the codebase, unless
 fixing them falls out in the wash of some kind of rev/patchlevel
 property at some point.
 
 Maybe just say an alias for? (no need to resend)
 
 Agreed.

Updated version

Acked-by: Andreas Färber afaer...@suse.de

Thanks,
/-F

 
 -- PMM
 

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

Re: [Qemu-devel] [PATCH v1 1/3] xilinx_zynq: added smp support

2012-04-20 Thread John Linn

 -Original Message-
 From: Peter Crosthwaite [mailto:peter.crosthwa...@petalogix.com]
 Sent: Thursday, April 19, 2012 11:18 PM
 To: John Linn
 Cc: qemu-devel@nongnu.org; p...@codesourcery.com;
 peter.mayd...@linaro.org; edgar.igles...@gmail.com; Duy Le;
 john.willi...@petalogix.com
 Subject: Re: [PATCH v1 1/3] xilinx_zynq: added smp support
 
 Ping!
 
 I realise there were issues with the other patches in this series, but
 this one on its own is self contained and valuable in its own right.
 Can we get a review accordingly?

Sure.

-- John

 
 Regards,
 Peter
 
 On Wed, Apr 11, 2012 at 3:50 AM, John Linn john.l...@xilinx.com wrote:
  -Original Message-
  From: Peter A. G. Crosthwaite
 [mailto:peter.crosthwa...@petalogix.com]
  Sent: Sunday, April 01, 2012 10:20 PM
  To: peter.crosthwa...@petalogix.com; qemu-devel@nongnu.org;
  p...@codesourcery.com; peter.mayd...@linaro.org;
  edgar.igles...@gmail.com
  Cc: Duy Le; John Linn; john.willi...@petalogix.com
  Subject: [PATCH v1 1/3] xilinx_zynq: added smp support
 
  Added linux smp support for the xilinx zynq platform (2x cpus are
  supported)
 
  Signed-off-by: Peter A. G. Crosthwaite
  peter.crosthwa...@petalogix.com
 
  Signed-off-by: John Linn john.l...@xilinx.com
 
  ---
   hw/xilinx_zynq.c |   64
  --
  ---
   1 files changed, 53 insertions(+), 11 deletions(-)
 
  diff --git a/hw/xilinx_zynq.c b/hw/xilinx_zynq.c
  index 7290c64..56d0b96 100644
  --- a/hw/xilinx_zynq.c
  +++ b/hw/xilinx_zynq.c
  @@ -30,6 +30,42 @@
 
   #define IRQ_OFFSET 32 /* pic interrupts start from index 32 */
 
  +#define SMP_BOOT_ADDR 0x0fff
  +
  +static void zynq_reset_secondary(CPUARMState *env,
  +                                    const struct arm_boot_info
 *info)
  +{
  +    env-regs[15] = SMP_BOOT_ADDR;
  +}
  +
  +/* Entry point for secondary CPU */
  +static uint32_t zynq_smpboot[] = {
  +    0xe59f0020, /* ldr     r0, privbase */
  +    0xe3a004FF, /* mov     r0 = 0xFFF0 */
  +    0xe38008FF, /* orr     ...*/
  +    0xe3800CFF, /* orr      */
  +    0xe38000F0, /* orr     . */
  +    0xe320f002, /* wfe */
  +    0xe5901000, /* ldr     r1, [r0] */
  +    0xe1110001, /* tst     r1, r1 */
  +    0x0afb, /* beq     wfe */
  +    0xe12fff11, /* bx      r1 */
  +    0,
  +    0
  +};
  +
  +static void zynq_write_secondary_boot(CPUARMState *env,
  +                                    const struct arm_boot_info
 *info)
  +{
  +    int n;
  +
  +    for (n = 0; n  ARRAY_SIZE(zynq_smpboot); n++) {
  +        zynq_smpboot[n] = tswap32(zynq_smpboot[n]);
  +    }
  +    rom_add_blob_fixed(smpboot, zynq_smpboot,
 sizeof(zynq_smpboot),
  +            SMP_BOOT_ADDR);
  +}
  +
   static struct arm_boot_info zynq_binfo = {};
 
   static void gem_init(NICInfo *nd, uint32_t base, qemu_irq irq)
  @@ -60,19 +96,21 @@ static void zynq_init(ram_addr_t ram_size, const
  char *boot_device,
       qemu_irq pic[64];
       NICInfo *nd;
       int n;
  -    qemu_irq cpu_irq;
  +    qemu_irq cpu_irq[2];
 
       if (!cpu_model) {
           cpu_model = cortex-a9;
       }
 
  -    env = cpu_init(cpu_model);
  -    if (!env) {
  -        fprintf(stderr, Unable to find CPU definition\n);
  -        exit(1);
  +    for (n = 0; n  smp_cpus; n++) {
  +        env = cpu_init(cpu_model);
  +        if (!env) {
  +            fprintf(stderr, Unable to find CPU definition\n);
  +            exit(1);
  +        }
  +        irqp = arm_pic_init_cpu(env);
  +        cpu_irq[n] = irqp[ARM_PIC_CPU_IRQ];
       }
  -    irqp = arm_pic_init_cpu(env);
  -    cpu_irq = irqp[ARM_PIC_CPU_IRQ];
 
       /* max 2GB ram */
       if (ram_size  0x8000) {
  @@ -103,11 +141,13 @@ static void zynq_init(ram_addr_t ram_size,
 const
  char *boot_device,
       sysbus_mmio_map(sysbus_from_qdev(dev), 0, 0xF800);
 
       dev = qdev_create(NULL, a9mpcore_priv);
  -    qdev_prop_set_uint32(dev, num-cpu, 1);
  +    qdev_prop_set_uint32(dev, num-cpu, smp_cpus);
       qdev_init_nofail(dev);
       busdev = sysbus_from_qdev(dev);
       sysbus_mmio_map(busdev, 0, 0xF8F0);
  -    sysbus_connect_irq(busdev, 0, cpu_irq);
  +    for (n = 0; n  smp_cpus; n++) {
  +        sysbus_connect_irq(busdev, n, cpu_irq[n]);
  +    }
 
       for (n = 0; n  64; n++) {
           pic[n] = qdev_get_gpio_in(dev, n);
  @@ -134,7 +174,9 @@ static void zynq_init(ram_addr_t ram_size, const
  char *boot_device,
       zynq_binfo.kernel_filename = kernel_filename;
       zynq_binfo.kernel_cmdline = kernel_cmdline;
       zynq_binfo.initrd_filename = initrd_filename;
  -    zynq_binfo.nb_cpus = 1;
  +    zynq_binfo.nb_cpus = smp_cpus;
  +    zynq_binfo.write_secondary_boot = zynq_write_secondary_boot;
  +    zynq_binfo.secondary_cpu_reset_hook = zynq_reset_secondary;
       zynq_binfo.board_id = 0xd32;
       zynq_binfo.loader_start = 0;
       arm_load_kernel(first_cpu, zynq_binfo);
  @@ -145,7 +187,7 @@ static QEMUMachine zynq_machine = {
       .desc = Xilinx

[Qemu-devel] [PATCH] Remove extra pthread switch

2012-04-20 Thread Peter Portante

From the Department of the Redundancy Department:
  remove the extra pthread switch which might be there
  from the package config check for gthreads.

Signed-off-by: Peter Portante peter.porta...@redhat.com
---
 configure |   11 ++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/configure b/configure
index 8b4e3c1..0038dfc 100755
--- a/configure
+++ b/configure
@@ -2039,7 +2039,16 @@ else
   for pthread_lib in $PTHREADLIBS_LIST; do
 if compile_prog  $pthread_lib ; then
   pthread=yes
-  LIBS=$pthread_lib $LIBS
+  found=no
+  for lib_entry in $LIBS; do
+if test $lib_entry = $pthread_lib; then
+  found=yes
+  break
+fi
+  done
+  if test $found = no; then
+LIBS=$pthread_lib $LIBS
+  fi
   break
 fi
   done
-- 
1.7.7.6

Re: [Qemu-devel] [PATCH v2 02/14] target-arm: Move feature bit settings to CPU init fns

Am 14.04.2012 18:42, schrieb Peter Maydell:
 Move the setting of the feature bits from cpu_reset_model_id()
 to each CPU's instance init function. This requires us to move
 the features field in CPUARMState so that it is not cleared
 on reset.
 
 Signed-off-by: Peter Maydell peter.mayd...@linaro.org
 ---
[...]
 diff --git a/target-arm/cpu.c b/target-arm/cpu.c
 index 3565472..958f5c5 100644
 --- a/target-arm/cpu.c
 +++ b/target-arm/cpu.c
[...]
  static void pxa270c0_initfn(Object *obj)
  {
  ARMCPU *cpu = ARM_CPU(obj);
 +set_feature(cpu-env, ARM_FEATURE_V5);
 +set_feature(cpu-env, ARM_FEATURE_XSCALE);
 +set_feature(cpu-env, ARM_FEATURE_IWMMXT);
  cpu-midr = ARM_CPUID_PXA270_C0;
  }
  
  static void pxa270c5_initfn(Object *obj)
  {
  ARMCPU *cpu = ARM_CPU(obj);
 +set_feature(cpu-env, ARM_FEATURE_V7);
 +set_feature(cpu-env, ARM_FEATURE_VFP4);
 +set_feature(cpu-env, ARM_FEATURE_VFP_FP16);
 +set_feature(cpu-env, ARM_FEATURE_NEON);
 +set_feature(cpu-env, ARM_FEATURE_THUMB2EE);
 +set_feature(cpu-env, ARM_FEATURE_ARM_DIV);
 +set_feature(cpu-env, ARM_FEATURE_V7MP);
  cpu-midr = ARM_CPUID_PXA270_C5;
  }

Beep! Glad I took the time to compare each model... :)

Once this is fixed, Acked-by.

/-F

  
  static void arm_any_initfn(Object *obj)
  {
  ARMCPU *cpu = ARM_CPU(obj);
 +set_feature(cpu-env, ARM_FEATURE_V7);
 +set_feature(cpu-env, ARM_FEATURE_VFP4);
 +set_feature(cpu-env, ARM_FEATURE_VFP_FP16);
 +set_feature(cpu-env, ARM_FEATURE_NEON);
 +set_feature(cpu-env, ARM_FEATURE_THUMB2EE);
 +set_feature(cpu-env, ARM_FEATURE_ARM_DIV);
 +set_feature(cpu-env, ARM_FEATURE_V7MP);
  cpu-midr = ARM_CPUID_ANY;
  }
  
[...]
 diff --git a/target-arm/helper.c b/target-arm/helper.c
 index afcd68c..e495de6 100644
 --- a/target-arm/helper.c
 +++ b/target-arm/helper.c
[...]
 @@ -220,17 +163,13 @@ static void cpu_reset_model_id(CPUARMState *env, 
 uint32_t id)
  case ARM_CPUID_PXA270_B1:
  case ARM_CPUID_PXA270_C0:
  case ARM_CPUID_PXA270_C5:
 -set_feature(env, ARM_FEATURE_V5);
 -set_feature(env, ARM_FEATURE_XSCALE);
  /* JTAG_ID is ((id  28) | 0x09265013) */
 -set_feature(env, ARM_FEATURE_IWMMXT);
  env-iwmmxt.cregs[ARM_IWMMXT_wCID] = 0x69051000 | 'Q';
  env-cp15.c0_cachetype = 0xd172172;
  env-cp15.c1_sys = 0x0078;
  break;
  case ARM_CPUID_SA1100:
  case ARM_CPUID_SA1110:
 -set_feature(env, ARM_FEATURE_STRONGARM);
  env-cp15.c1_sys = 0x0070;
  break;
  default:

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

Re: [Qemu-devel] [PATCH v2 03/14] target-arm: Move FPSID config to cpu init fns

Am 14.04.2012 18:42, schrieb Peter Maydell:
 Move the reset FPSID to the ARMCPU struct, and set it in the
 per-implementation instance init function. At reset we then
 just copy the reset value into the CPUARMState field.
 
 Signed-off-by: Peter Maydell peter.mayd...@linaro.org
 ---
  target-arm/cpu-qom.h |1 +
  target-arm/cpu.c |9 +
  target-arm/helper.c  |   10 ++
  3 files changed, 12 insertions(+), 8 deletions(-)

Acked-by: Andreas Färber afaer...@suse.de

/-F

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

Re: [Qemu-devel] [PATCH v2 02/14] target-arm: Move feature bit settings to CPU init fns

On 20 April 2012 15:43, Andreas Färber afaer...@suse.de wrote:
 Am 14.04.2012 18:42, schrieb Peter Maydell:
  static void pxa270c5_initfn(Object *obj)
  {
      ARMCPU *cpu = ARM_CPU(obj);
 +    set_feature(cpu-env, ARM_FEATURE_V7);
 +    set_feature(cpu-env, ARM_FEATURE_VFP4);
 +    set_feature(cpu-env, ARM_FEATURE_VFP_FP16);
 +    set_feature(cpu-env, ARM_FEATURE_NEON);
 +    set_feature(cpu-env, ARM_FEATURE_THUMB2EE);
 +    set_feature(cpu-env, ARM_FEATURE_ARM_DIV);
 +    set_feature(cpu-env, ARM_FEATURE_V7MP);
      cpu-midr = ARM_CPUID_PXA270_C5;
  }

 Beep! Glad I took the time to compare each model... :)

 Once this is fixed, Acked-by.

Oops. Fixed version:

static void pxa270c5_initfn(Object *obj)
{
ARMCPU *cpu = ARM_CPU(obj);
set_feature(cpu-env, ARM_FEATURE_V5);
set_feature(cpu-env, ARM_FEATURE_XSCALE);
set_feature(cpu-env, ARM_FEATURE_IWMMXT);
cpu-midr = ARM_CPUID_PXA270_C5;
}

-- PMM

Re: [Qemu-devel] [PATCH 2/2] Expose tsc deadline timer cpuid to guest

2012-04-20 Thread Eduardo Habkost

On Fri, Apr 20, 2012 at 12:12:38PM +0200, Jan Kiszka wrote:
 On 2012-04-19 22:03, Eduardo Habkost wrote:
  Jan/Avi: ping?
  
  I would like to get this ABI detail clarified so it can be implemented
  the right way on Qemu and KVM.
  
  My proposal is to simply add tsc-deadline to the data returned by
  GET_SUPPORTED_CPUID, making KVM_CAP_TSC_DEADLINE_TIMER unnecessary.
  
 
 IIRC, there were problems with this model to exclude that the feature
 gets reported this way without ensuring that in-kernel irqchip is
 actually activated. Please browse the discussions, it should be
 documented there.

The flag was never added to GET_SUPPORTED_CPUID on any of the git
repositories I have checked, and I don't see that being done anywhere on
my KVM mailing list archives, either. So I don't see how we could have
had issues with GET_SUPPORTED_CPUID, if it was never present on the
code.

What was present on the code before the fix, was coded that
unconditinally enabled the flag even if Qemu never asked for it, and
that really was wrong.

GET_SUPPORTED_CPUID doesn't enable any flag: it just tells userspace
that the hardware and KVM supports the feature (and, surprise, this is
exactly what KVM_CAP_TSC_DEADLINE_TIMER means too, isn't it?). It's up
to userspace to enable the CPUID bits according to user requirements and
userspace capabilities (in other words: only when userspace knows it is
safe because the in-kernel irqchip is enabled).

If the above is not what GET_SUPPORTED_CPUID means, I would like to get
that clarified, so I can submit an updated to KVM API documentation.

-- 
Eduardo

Re: [Qemu-devel] [PATCH v2 04/14] target-arm: Move MVFR* setup to per cpu init fns

Am 14.04.2012 18:42, schrieb Peter Maydell:
 Move the MVFR* VFP feature register values to ARMCPU,
 so they are set up by the implementation-specific instance
 init functions rather than in cpu_reset_model_id().
 
 Signed-off-by: Peter Maydell peter.mayd...@linaro.org

Acked-by: Andreas Färber afaer...@suse.de

/-F

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

Re: [Qemu-devel] [PATCH v2 05/14] target-arm: Move CTR setup to per cpu init fns

Am 14.04.2012 18:42, schrieb Peter Maydell:
 Move CTR (cache type register) value to an ARMCPU field
 set up by per-cpu init fns.
 
 Signed-off-by: Peter Maydell peter.mayd...@linaro.org

Acked-by: Andreas Färber afaer...@suse.de

/-F

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

Re: [Qemu-devel] [PATCH 2/2] Expose tsc deadline timer cpuid to guest

2012-04-20 Thread Jan Kiszka

On 2012-04-20 17:00, Eduardo Habkost wrote:
 On Fri, Apr 20, 2012 at 12:12:38PM +0200, Jan Kiszka wrote:
 On 2012-04-19 22:03, Eduardo Habkost wrote:
 Jan/Avi: ping?

 I would like to get this ABI detail clarified so it can be implemented
 the right way on Qemu and KVM.

 My proposal is to simply add tsc-deadline to the data returned by
 GET_SUPPORTED_CPUID, making KVM_CAP_TSC_DEADLINE_TIMER unnecessary.


 IIRC, there were problems with this model to exclude that the feature
 gets reported this way without ensuring that in-kernel irqchip is
 actually activated. Please browse the discussions, it should be
 documented there.
 
 The flag was never added to GET_SUPPORTED_CPUID on any of the git
 repositories I have checked, and I don't see that being done anywhere on
 my KVM mailing list archives, either. So I don't see how we could have
 had issues with GET_SUPPORTED_CPUID, if it was never present on the
 code.
 
 What was present on the code before the fix, was coded that
 unconditinally enabled the flag even if Qemu never asked for it, and
 that really was wrong.
 
 GET_SUPPORTED_CPUID doesn't enable any flag: it just tells userspace
 that the hardware and KVM supports the feature (and, surprise, this is
 exactly what KVM_CAP_TSC_DEADLINE_TIMER means too, isn't it?). It's up
 to userspace to enable the CPUID bits according to user requirements and
 userspace capabilities (in other words: only when userspace knows it is
 safe because the in-kernel irqchip is enabled).
 
 If the above is not what GET_SUPPORTED_CPUID means, I would like to get
 that clarified, so I can submit an updated to KVM API documentation.

Does old userspace filter out flags from GET_SUPPORTED_CPUID that it
does not understand?

Jan

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

Re: [Qemu-devel] [PATCH v2 06/14] target-arm: Move SCTLR reset value setup to per cpu init fns

Am 14.04.2012 18:42, schrieb Peter Maydell:
 Move the reset value of SCTLR to ARMCPU, initialised in
 the per-cpu init functions. It can then be reset by a
 simple copy, and we can drop the code from cpu_reset_model_id().
 
 Signed-off-by: Peter Maydell peter.mayd...@linaro.org

Acked-by: Andreas Färber afaer...@suse.de

/-F

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

Re: [Qemu-devel] [PATCH v2] versatiblepb: add NOR flash support

On 16 April 2012 16:02, Eric Bénard e...@eukrea.com wrote:
 - add support for the 64MB NOR CFI01 flash available at
 0x3400 on the versatilepb board
 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0225d/BBAJIHEC.html

 - tested with barebox bootloader

 Signed-off-by: Eric Bénard e...@eukrea.com

Reviewed-by: Peter Maydell peter.mayd...@linaro.org

-- PMM

Re: [Qemu-devel] [PATCH 2/2] Expose tsc deadline timer cpuid to guest

2012-04-20 Thread Eduardo Habkost

On Fri, Apr 20, 2012 at 05:19:17PM +0200, Jan Kiszka wrote:
 On 2012-04-20 17:00, Eduardo Habkost wrote:
  On Fri, Apr 20, 2012 at 12:12:38PM +0200, Jan Kiszka wrote:
  On 2012-04-19 22:03, Eduardo Habkost wrote:
  Jan/Avi: ping?
 
  I would like to get this ABI detail clarified so it can be implemented
  the right way on Qemu and KVM.
 
  My proposal is to simply add tsc-deadline to the data returned by
  GET_SUPPORTED_CPUID, making KVM_CAP_TSC_DEADLINE_TIMER unnecessary.
 
 
  IIRC, there were problems with this model to exclude that the feature
  gets reported this way without ensuring that in-kernel irqchip is
  actually activated. Please browse the discussions, it should be
  documented there.
  
  The flag was never added to GET_SUPPORTED_CPUID on any of the git
  repositories I have checked, and I don't see that being done anywhere on
  my KVM mailing list archives, either. So I don't see how we could have
  had issues with GET_SUPPORTED_CPUID, if it was never present on the
  code.
  
  What was present on the code before the fix, was coded that
  unconditinally enabled the flag even if Qemu never asked for it, and
  that really was wrong.
  
  GET_SUPPORTED_CPUID doesn't enable any flag: it just tells userspace
  that the hardware and KVM supports the feature (and, surprise, this is
  exactly what KVM_CAP_TSC_DEADLINE_TIMER means too, isn't it?). It's up
  to userspace to enable the CPUID bits according to user requirements and
  userspace capabilities (in other words: only when userspace knows it is
  safe because the in-kernel irqchip is enabled).
  
  If the above is not what GET_SUPPORTED_CPUID means, I would like to get
  that clarified, so I can submit an updated to KVM API documentation.
 
 Does old userspace filter out flags from GET_SUPPORTED_CPUID that it
 does not understand?

It's even more strict than that: it only enables what was explicitly
enabled on the CPU model asked by the user.

But:

The only exception is -cpu host, that tries to enable everything, even
flags Qemu never heard of, and that is something that may require some
changes on the API design (or at least documentation clarifications).

Today -cpu host can't differentiate (A) a feature that KVM supports
and emulate by itself and can be enabled without any support from
userspace and (B) a feature that KVM supports but need support from
userspace to be enabled. I am sure we will be able to find multiple
examples of (B) inside the flags returned by GET_SUPPORTED_CPUID today.

We could decide to never add any new flag to GET_SUPPORTED_CPUID if it
requires additional userspace support to work, from now on, and create
new KVM_CAP_* flags for them. But, we really want to do that for almost
every new CPUID feature bit in the future?

We also have the problem of defining what requires support from
userspace to work means: I am not sure this has the same meaning for
everybody. Many new features require userspace support only for
migration, and nothing else, but some users don't need migration to
work. Do those features qualify as (A), or as (B)?

-- 
Eduardo

[Qemu-devel] [PATCH] Bug fix for #986241: spell env correctly

2012-04-20 Thread Peter Portante

Signed-off-by: Peter Portante peter.porta...@redhat.com
---
 hw/spapr_hcall.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/spapr_hcall.c b/hw/spapr_hcall.c
index 634763e..94bb504 100644
--- a/hw/spapr_hcall.c
+++ b/hw/spapr_hcall.c
@@ -482,7 +482,7 @@ static target_ulong register_dtl(CPUPPCState *env, 
target_ulong addr)
 return H_SUCCESS;
 }
 
-static target_ulong deregister_dtl(CPUPPCState *emv, target_ulong addr)
+static target_ulong deregister_dtl(CPUPPCState *env, target_ulong addr)
 {
 env-dispatch_trace_log = 0;
 env-dtl_size = 0;
-- 
1.7.7.6

[Qemu-devel] [Bug 986241] [NEW] Misspelling of env parameter in deregister_dtl() [hw/spapr_hcall.c]

2012-04-20 Thread Peter Portante

Public bug reported:

Looks like there is a simple misspelling of the env parameter, as emv,
in hw/spapr_hcall.c:485:

  static target_ulong deregister_dtl(CPUPPCState *emv, target_ulong
addr)

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

Title:
  Misspelling of env parameter in deregister_dtl() [hw/spapr_hcall.c]

Status in QEMU:
  New

Bug description:
  Looks like there is a simple misspelling of the env parameter, as
  emv, in hw/spapr_hcall.c:485:

static target_ulong deregister_dtl(CPUPPCState *emv, target_ulong
  addr)

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

Re: [Qemu-devel] [PATCH v2 09/14] target-arm: Move feature register setup to per-CPU init fns

Am 14.04.2012 18:42, schrieb Peter Maydell:
 Move feature register value setup to per-CPU init functions.
 
 Signed-off-by: Peter Maydell peter.mayd...@linaro.org
 ---
  target-arm/cpu-qom.h |   14 
  target-arm/cpu.c |   91 
 ++
  target-arm/helper.c  |   73 
  3 files changed, 119 insertions(+), 59 deletions(-)
[...]
 diff --git a/target-arm/cpu.c b/target-arm/cpu.c
 index 900bfc7..924aaed 100644
 --- a/target-arm/cpu.c
 +++ b/target-arm/cpu.c
[...]
 @@ -202,6 +257,18 @@ static void cortex_a8_initfn(Object *obj)
  cpu-mvfr1 = 0x00011100;
  cpu-ctr = 0x82048004;
  cpu-reset_sctlr = 0x00c50078;
 +cpu-id_pfr0 = 0x1031;
 +cpu-id_pfr1 = 0x11;
 +cpu-id_dfr0 = 0x400;
 +cpu-id_afr0 = 0;
 +cpu-id_mmfr0 = 0x3113;
 +cpu-id_mmfr1 = 0x2000;
 +cpu-id_mmfr2 = 0x01202000;

Missing cpu-id_mmfr3 = 0x11;

 +cpu-id_isar0 = 0x0010;
 +cpu-id_isar1 = 0x12112111;
 +cpu-id_isar2 = 0x21232031;
 +cpu-id_isar3 = 0x2131;
 +cpu-id_isar4 = 0x0042;
  }
  
  static void cortex_a9_initfn(Object *obj)
 @@ -223,6 +290,18 @@ static void cortex_a9_initfn(Object *obj)
  cpu-mvfr1 = 0x0111;
  cpu-ctr = 0x80038003;
  cpu-reset_sctlr = 0x00c50078;
 +cpu-id_pfr0 = 0x1031;
 +cpu-id_pfr1 = 0x11;
 +cpu-id_dfr0 = 0x000;
 +cpu-id_afr0 = 0;
 +cpu-id_mmfr0 = 0x00100103;
 +cpu-id_mmfr1 = 0x2000;
 +cpu-id_mmfr2 = 0x0123;

Missing cpu-id_mmfr3 = 0x2111;

 +cpu-id_isar0 = 0x0010;
 +cpu-id_isar1 = 0x13112111;
 +cpu-id_isar2 = 0x21232041;
 +cpu-id_isar3 = 0x2131;
 +cpu-id_isar4 = 0x0042;
  }
  
  static void cortex_a15_initfn(Object *obj)
 @@ -242,6 +321,18 @@ static void cortex_a15_initfn(Object *obj)
  cpu-mvfr1 = 0x;
  cpu-ctr = 0x8444c004;
  cpu-reset_sctlr = 0x00c50078;
 +cpu-id_pfr0 = 0x1131;
 +cpu-id_pfr1 = 0x00011011;
 +cpu-id_dfr0 = 0x02010555;
 +cpu-id_afr0 = 0x;
 +cpu-id_mmfr0 = 0x10201105;
 +cpu-id_mmfr1 = 0x2000;
 +cpu-id_mmfr2 = 0x0124;

Missing cpu-id_mmfr3 = 0x02102211;

 +cpu-id_isar0 = 0x02101110;
 +cpu-id_isar1 = 0x13112111;
 +cpu-id_isar2 = 0x21232041;
 +cpu-id_isar3 = 0x2131;
 +cpu-id_isar4 = 0x10011142;
  }
  
  static void ti925t_initfn(Object *obj)

Apart from the omissions looking fine, Acked-by if fixed.

Andreas

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

Re: [Qemu-devel] [PATCH v2 09/14] target-arm: Move feature register setup to per-CPU init fns

On 20 April 2012 16:50, Andreas Färber afaer...@suse.de wrote:
 Missing cpu-id_mmfr3 = 0x11;
[etc]

Whoops, that was a bit sloppy. Fixed and new version pushed
to git://git.linaro.org/people/pmaydell/qemu-arm.git drop-reset-model-id

-- PMM

Re: [Qemu-devel] [PATCH v2 11/14] target-arm: Move cache ID register setup to cpu specific init fns

Am 14.04.2012 18:42, schrieb Peter Maydell:
 Move cache ID register reset out of cpu_reset_model_id() by
 creating a field for the reset value in ARMCPU and setting it
 up in the cpu specific init functions.
 
 Signed-off-by: Peter Maydell peter.mayd...@linaro.org
 ---
  target-arm/cpu-qom.h |5 +
  target-arm/cpu.c |   11 +++
  target-arm/helper.c  |   13 ++---
  3 files changed, 18 insertions(+), 11 deletions(-)
[...]
 diff --git a/target-arm/cpu.c b/target-arm/cpu.c
 index 924aaed..63de462 100644
 --- a/target-arm/cpu.c
 +++ b/target-arm/cpu.c
 @@ -269,6 +269,10 @@ static void cortex_a8_initfn(Object *obj)
  cpu-id_isar2 = 0x21232031;
  cpu-id_isar3 = 0x2131;
  cpu-id_isar4 = 0x0042;
 +cpu-clidr = (1  27) | (2  24) | 3;
 +cpu-ccsidr[0] = 0xe007e01a; /* 16k L1 dcache. */
 +cpu-ccsidr[1] = 0x2007e01a; /* 16k L1 icache. */
 +cpu-ccsidr[2] = 0xf000; /* No L2 icache. */
  }
  
  static void cortex_a9_initfn(Object *obj)
 @@ -302,6 +306,9 @@ static void cortex_a9_initfn(Object *obj)
  cpu-id_isar2 = 0x21232041;
  cpu-id_isar3 = 0x2131;
  cpu-id_isar4 = 0x0042;
 +cpu-clidr = (1  27) | (2  24) | 3;

Copypaste, should be (1  27) | (1  24) | 3.

/-F

 +cpu-ccsidr[0] = 0xe00fe015; /* 16k L1 dcache. */
 +cpu-ccsidr[1] = 0x200fe015; /* 16k L1 icache. */
  }
  
  static void cortex_a15_initfn(Object *obj)
[...]
 diff --git a/target-arm/helper.c b/target-arm/helper.c
 index fb618a7..5cbc7e0 100644
 --- a/target-arm/helper.c
 +++ b/target-arm/helper.c
 @@ -25,21 +25,10 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t 
 id)
  case ARM_CPUID_ARM11MPCORE:
  break;
  case ARM_CPUID_CORTEXA8:
 -env-cp15.c0_clid = (1  27) | (2  24) | 3;
 -env-cp15.c0_ccsid[0] = 0xe007e01a; /* 16k L1 dcache. */
 -env-cp15.c0_ccsid[1] = 0x2007e01a; /* 16k L1 icache. */
 -env-cp15.c0_ccsid[2] = 0xf000; /* No L2 icache. */
  break;
  case ARM_CPUID_CORTEXA9:
 -env-cp15.c0_clid = (1  27) | (1  24) | 3;
 -env-cp15.c0_ccsid[0] = 0xe00fe015; /* 16k L1 dcache. */
 -env-cp15.c0_ccsid[1] = 0x200fe015; /* 16k L1 icache. */
  break;
  case ARM_CPUID_CORTEXA15:
 -env-cp15.c0_clid = 0x0a200023;
 -env-cp15.c0_ccsid[0] = 0x701fe00a; /* 32K L1 dcache */
 -env-cp15.c0_ccsid[1] = 0x201fe00a; /* 32K L1 icache */
 -env-cp15.c0_ccsid[2] = 0x711fe07a; /* 4096K L2 unified cache */
  break;
  case ARM_CPUID_CORTEXM3:
  break;
[snip]

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

Re: [Qemu-devel] [PATCH v2 11/14] target-arm: Move cache ID register setup to cpu specific init fns

On 20 April 2012 17:00, Andreas Färber afaer...@suse.de wrote:
 Am 14.04.2012 18:42, schrieb Peter Maydell:
 +    cpu-clidr = (1  27) | (2  24) | 3;

 Copypaste, should be (1  27) | (1  24) | 3.

Fixed and pushed, sigh.

-- PMM

Re: [Qemu-devel] [PATCH v2 12/14] target-arm: Drop cpu_reset_model_id()