Re: [Qemu-devel] [PATCH] add fd limitations for avoiding a buffer overflow

[Amos Kong]

On Sun, Jan 27, 2013 at 01:41:57PM +0200, Michael S. Tsirkin wrote:
> On Fri, Jan 25, 2013 at 04:14:49PM +0800, Amos Kong wrote:
> > FD_SET() and FD_CLR() are used to add and remove one descriptor from a
> > set, the 'fd' should be less than FD_SETSIZE. Glibc will give a warning
> > and crash the qemu when we set a fd (1024) to a set.
> > 
> >  # qemu -device virtio-net-pci,netdev=macvtap_netdev,mac=92:ff:8a:11:fe:57
> >-netdev tap,id=macvtap_netdev,fd=1024 1024<>/dev/tap4
> > 
> > *** buffer overflow detected ***: x86_64-softmmu/qemu-system-x86_64
> > terminated
> > === Backtrace: =
> > /lib64/libc.so.6(__fortify_fail+0x37)[0x7f842a2134a7]
> > /lib64/libc.so.6(+0x35e9d08620)[0x7f842a211620]
> > /lib64/libc.so.6(+0x35e9d0a417)[0x7f842a213417]
> > x86_64-softmmu/qemu-system-x86_64(+0x1901fd)[0x7f842f09f1fd]
> > x86_64-softmmu/qemu-system-x86_64(+0x198388)[0x7f842f0a7388]
> > x86_64-softmmu/qemu-system-x86_64(main+0xfa9)[0x7f842ef897a9]
> > /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f842a12aa05]
> > x86_64-softmmu/qemu-system-x86_64(+0x7ed49)[0x7f842ef8dd49]
> > === Memory map: 
> > 
> 
> This is simply because we are using select for polling, right?
 
Yes.

> > This patch added limitations when init tap device and set fd handler
> > for synchronous IO.
> > 
> > Signed-off-by: Amos Kong 
> 
> > ---
> >  iohandler.c |3 +++
> >  net/tap.c   |3 ++-
> >  2 files changed, 5 insertions(+), 1 deletions(-)
> > 
> > diff --git a/iohandler.c b/iohandler.c
> > index 2523adc..c22edab 100644
> > --- a/iohandler.c
> > +++ b/iohandler.c
> > @@ -66,6 +66,9 @@ int qemu_set_fd_handler2(int fd,
> >  }
> >  }
> >  } else {
> > +if (fd >= FD_SETSIZE) {
> > +return 1;
> > +}
> >  QLIST_FOREACH(ioh, &io_handlers, next) {
> >  if (ioh->fd == fd)
> >  goto found;
> > diff --git a/net/tap.c b/net/tap.c
> > index eb40c42..be856dd 100644
> > --- a/net/tap.c
> > +++ b/net/tap.c
> > @@ -618,7 +618,8 @@ int net_init_tap(const NetClientOptions *opts, const 
> > char *name,
> >  }
> >  
> >  fd = monitor_handle_fd_param(cur_mon, tap->fd);
> > -if (fd == -1) {
> > +if (fd == -1 || fd >= FD_SETSIZE) {
> > +error_report("Invalid fd : %d", fd);
> >  return -1;
> >  }
> 
> The fd is actually valid. It's simply too high.
> And if this triggered it's quite possibly that
> the fd passed in is 1023 but the moment we try to
> allocate our own fd, it will be 1024 so boom.
> 
> So maybe, the right thing to do here is to use poll or epoll?
 
Stefan posted some selected solution, let's see others comments.

Re: [Qemu-devel] [ANNOUNCE] checkpatch and git-am bots

[Andreas Färber]

Am 21.01.2013 19:45, schrieb Anthony Liguori:
> I've published the code for patches although I've not announced it yet.
> I'm still making some CLI changes but hope to do a proper announcement
> in the next week or so.
> 
> http://github.com/aliguori/patches.git
> 
> If anyone wants to try it out, let me know, and I would be happy to
> answer questions/help you set it up.

$ patches fetch http://wiki.qemu.org/patches/patches.json
Traceback (most recent call last):
  File "/usr/local/bin/patches", line 140, in 
sys.exit(main(sys.argv[1:]))
  File "/usr/local/bin/patches", line 136, in main
return args.func(args)
  File "/usr/local/bin/patches", line 31, in do_fetch
return fetch.main(args)
  File "/usr/local/lib/python2.7/site-packages/patchlib/fetch.py", line
22, in main
fetch(args.url[0])
  File "/usr/local/lib/python2.7/site-packages/patchlib/fetch.py", line
36, in fetch
fp = urlopen(url)
  File "/usr/lib64/python2.7/urllib2.py", line 126, in urlopen
return _opener.open(url, data, timeout)
  File "/usr/lib64/python2.7/urllib2.py", line 392, in open
protocol = req.get_type()
  File "/usr/lib64/python2.7/urllib2.py", line 254, in get_type
raise ValueError, "unknown url type: %s" % self.__original
ValueError: unknown url type: h

Am I missing some Python dependency? I can access the URL from my browser.

Regards,
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] hd-geo-test failing on OpenIndiana

[Paolo Bonzini]

Il 28/01/2013 08:53, Markus Armbruster ha scritto:
> Andreas Färber  writes:
> 
>> Hello Markus,
>>
>> On OpenIndiana 151a7 I am seeing assertion failures for ret == 0 in
>> hd-geo-test.c:35:create_test_img(). It seems it is refusing to blow up
>> the temporary file. Any suggestion what to do about that?
> 
> Fine print on ftruncate():
> 
> If fildes refers to a regular file, the ftruncate() function shall
> cause the size of the file to be truncated to length.  If the size
> of the file previously exceeded length, the extra data shall no
> longer be available to reads on the file.  If the file previously
> was smaller than this size, ftruncate() shall either increase the
> size of the file or fail.  XSI-conformant systems shall increase the
> size of the file.  If the file size is increased, the extended area
> shall appear as if it were zero-filled. The value of the seek
> pointer shall not be modified by a call to ftruncate().
> 
> Looks like OpenIndiana got stuck in the 20th century.
> 
> If you care for such losing systems, you need create_test_img to fall
> back or switch wholesale to a less elegant way to create the image.

Traditionally you used a 1-byte write to create a sparse file, preceeded
by an lseek to offset SIZE-1.

Paolo

Re: [Qemu-devel] hd-geo-test failing on OpenIndiana

[Andreas Färber]

Am 28.01.2013 08:53, schrieb Markus Armbruster:
> Andreas Färber  writes:
> Fine print on ftruncate():
> 
> If fildes refers to a regular file, the ftruncate() function shall
> cause the size of the file to be truncated to length.  If the size
> of the file previously exceeded length, the extra data shall no
> longer be available to reads on the file.  If the file previously
> was smaller than this size, ftruncate() shall either increase the
> size of the file or fail.  XSI-conformant systems shall increase the
> size of the file.  If the file size is increased, the extended area
> shall appear as if it were zero-filled. The value of the seek
> pointer shall not be modified by a call to ftruncate().
> 
> Looks like OpenIndiana got stuck in the 20th century.
> 
> If you care for such losing systems,

I've been involved in the development of Haiku (BeOS-derived), and I can
assure you that writing an XSI-conformant system even in the 21st
century is not a piece of cake! ;-)

> you need create_test_img to fall
> back or switch wholesale to a less elegant way to create the image.

I'll look into Paolo's suggestion, thanks.

Wasn't aware it was trying to create a 4 GiB file, maybe my VM was just
too small...

Cheers,
Andreas

Re: [Qemu-devel] [RFC] FDT as a git submodule?

[Gerd Hoffmann]

  Hi,

> This really is more of a distro problem than a QEMU one. If your
> distro doesn't package libfdt, chances are quite good it just sucks.

Or just a little older.  Packaging dtc + libfdt is a pretty recent
thing, many not-that-recent distros don't have it.

The libfdt installed on the rhel6 build bots didn't came with the distro
for example.

> Nobody would think of bundling glib as a git submodule.

Find a linux distro which is younger than 10 years and doesn't include glib.

Try the same with libfdt, then compare the results ...

cheers,
  Gerd

Re: [Qemu-devel] [PATCH qom-cpu for-1.4 5/6] target-s390x: Mark as unmigratable

[Alexander Graf]

On 01/28/2013 01:13 AM, Andreas Färber wrote:

CPU_SAVE_VERSION was undefined, so "cpu_common" VMState and
cpu_{save,load}() were not registered. They were no-ops.
Therefore there is no backwards compatibility to keep, so we can mark
S390CPU as unmigratable at device level.

Signed-off-by: Andreas Färber


Semantically

  Acked-by: Alexander Graf 

but from the style or modeling perspective, I can't really say much :).


Alex


---
  target-s390x/Makefile.objs |1 -
  target-s390x/cpu.c |   10 +-
  target-s390x/machine.c |   30 --
  3 Dateien geändert, 9 Zeilen hinzugefügt(+), 32 Zeilen entfernt(-)
  delete mode 100644 target-s390x/machine.c

diff --git a/target-s390x/Makefile.objs b/target-s390x/Makefile.objs
index e728abf..a4a4c1a 100644
--- a/target-s390x/Makefile.objs
+++ b/target-s390x/Makefile.objs
@@ -1,4 +1,3 @@
  obj-y += translate.o helper.o cpu.o interrupt.o
  obj-y += int_helper.o fpu_helper.o cc_helper.o mem_helper.o misc_helper.o
-obj-$(CONFIG_SOFTMMU) += machine.o
  obj-$(CONFIG_KVM) += kvm.o
diff --git a/target-s390x/cpu.c b/target-s390x/cpu.c
index 0b68db8..a0c4479 100644
--- a/target-s390x/cpu.c
+++ b/target-s390x/cpu.c
@@ -26,8 +26,8 @@
  #include "cpu.h"
  #include "qemu-common.h"
  #include "qemu/timer.h"
-#ifndef CONFIG_USER_ONLY
  #include "hw/hw.h"
+#ifndef CONFIG_USER_ONLY
  #include "sysemu/arch_init.h"
  #endif

@@ -135,13 +135,21 @@ static void s390_cpu_finalize(Object *obj)
  #endif
  }

+static const VMStateDescription vmstate_s390_cpu = {
+.name = "cpu",
+.unmigratable = 1,
+};
+
  static void s390_cpu_class_init(ObjectClass *oc, void *data)
  {
  S390CPUClass *scc = S390_CPU_CLASS(oc);
  CPUClass *cc = CPU_CLASS(scc);
+DeviceClass *dc = DEVICE_CLASS(oc);

  scc->parent_reset = cc->reset;
  cc->reset = s390_cpu_reset;
+
+dc->vmsd =&vmstate_s390_cpu;
  }

  static const TypeInfo s390_cpu_type_info = {
diff --git a/target-s390x/machine.c b/target-s390x/machine.c
deleted file mode 100644
index 3e79be6..000
--- a/target-s390x/machine.c
+++ /dev/null
@@ -1,30 +0,0 @@
-/*
- * QEMU S390x machine definitions
- *
- * Copyright (c) 2009 Alexander Graf
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2 of the License, or (at your option) any later version.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, see.
- */
-
-#include "hw/hw.h"
-#include "hw/boards.h"
-
-void cpu_save(QEMUFile *f, void *opaque)
-{
-}
-
-int cpu_load(QEMUFile *f, void *opaque, int version_id)
-{
-return 0;
-}

Re: [Qemu-devel] [PATCH v2 00/20] Add Faraday A36x SoC platform support

[Kuo-Jung Su]

2013/1/28 Andreas Färber 

> Am 25.01.2013 09:19, schrieb Kuo-Jung Su:
> > From: Kuo-Jung Su 
> >
> > These patches introduce Faraday A36x SoC platform support.
> >
> > Faraday provides ARMv4/ARMv5TE compatible solutions,
> > and focus on ASIC design service.
> >
> > Here are some public documents for you reference.
> >
> > http://www.faraday-tech.com/html/documentation/index.html
> >
> > The pre-built images are also available at my Google Drive:
> >
> > https://docs.google.com/folder/d/0BwfiewvSmUgAX2pTTmtUMGFCZW8/edit
> >
> > Here is the image file list:
> >
> > 1. android-4.0.4/zImage: A369 linux-3.0.31
> > 2. android-4.0.4/romfs-4.0.4.tar.bz2: android-4.0.4
> > 3. nand.img.bz2: A369 nand flash image
> > 4. rom.img.bz2: A369 embedded ROM image
> > 5. u-boot: A369 u-boot-2012.10 ELF file
> > 6. zImage: A369 linux-3.4.12 + initramfs
> > 7. README
>
> Thank you for posting these test images. Could you also publish your
> patches on some public git branch so that one doesn't need to manually
> apply 20 or more patches to test it? (e.g., GitHub, repo.or.cz, ...)
>
> Another thing you could look into is qemu-jeos.git support - could you
> supply configs for building an upstream Linux kernel for testing? You
> can look at arm-vexpress.cfg as template.
>
>
Sorry, there are lot of patches, and most of them have coding styles.
Becuase the entire open source release (I mean 'mine' open source release)
was
initialated 2 weeks ago.
And yes, you might have noticed. The QEMU is my very 1st open source
release

And there are somehing make things even worst 
For example:

In u-boot, there are already some bad code / or heavily un-tested code
have release to its git tree.
i.e.
1. The ftsdc010_esdhc contributed by Andes Technology (a subsidiary of
Faraday)
simply doesn't work at Faraday A369 in u-boot-2013.01.
One of my colleague has ever make it work in u-boot-2010.09,
but its performanceis only 1/10 of mine ...

2. The ftgmac100 is somehow contributed by someone should do that with a
untested version, although it seemds to work correctly with MMU
disabled.

All of these, means after applying my patch, you would have multi-pile
drivers
against the same hardware

If none of these were problem to you, I'll tried to make them open source
later.

And for a record, in my original open source schedule, the following items
would be release in turn.

1) qemu (a36x)
2) u-boot-2013.01
3) linux-3.4.12
4) falinux (It's a combination of uClinux and build-root, was my personal
linux BSP, and now seems to be an official one in Faraday)
5) android-4.0.4
6) linux-3.0.31 for android
7) android-dist (A clone of falinux, which is designed to genrated andoird
images)
8) contiki-2.6
9) contiki-2.6-dist (A clone of falinux, which is designed to genrated
contiki images)
10) ecos-3.0
11) ecos-dist (A clone of falinux, which is designed to genrated contiki
images)
12) virgil (A referenced ROM code for my projects, which is also a
RTOS/FreeRTOS)

Because Faraday is actually a ASIC desgin service company, it usualy cares
nothing
about software and intends to make them all open sourced to catch more
customers.

> Changes for v2:
> >
> >1. coding style fixes (verified with checkpatch.pl)
> >2. add Faraday A360 support
> >3. add Faraday USB 2.0 EHCI support
> >4. merge a369_scu.c into a369.c
> >5. introduce QOM coding style
> >6. remove lowercase Macros: min(), max()
> >7. name all struct as CamelCase style
> >8. move function prototypes from .c to faraday.h
> >9. use switch instead of if statement in a369_ahbc_write
> >   10. remove debug prints
> >   11. update all uarts in A36x to DEVICE_LITTLE_ENDIAN.
> >   12. move the variable definitions to the start of the function,
> >   instead of inside a do { } while(0)
> >   13. remove disabled and commented out code.
> >   14. use hw_error() and exit() upon pflash register failed.
> >   15. add const prior to TypeInfo (i.e. static *const*
> >   TypeInfo ftrtc011_info)
> >   16. add le32_to_cpu/cpu_to_le32 to the descriptor processing in
> >   FTGMAC100/FTMAC110.
> >   17. update the GPL license to GPL v2 (except for FTLCDC200,
> >   it's based on pl110.c which is LGPL.)
> >   18. add const to src_* in the DMA controllers (FTAPBBRG020/FTDMAC020)
> >
> >   Note:
> >   1. Thanks to the comments from KONRAD, Andreas, Paul and Blue.
> >  But if there is still something missed, please kindly remind me to
> fix.
> >  Thanks!
>
> Your detailed change log is very helpful, thank you. When you post a v3
> however, please post the patch series as a top-level patchset (i.e., the
> cover letter not as a reply, just the actual patches to the cover
> letter), the change log then should be sufficient to understand its
> historical context and that makes it a little easier for humans or
> Anthony's scripts to find the latest patch versions.
>
>
Sorry, I can't get you very well...
I guess I'm not supposed to use --in-reply-to= with

Re: [Qemu-devel] [RFC] FDT as a git submodule?

[Paolo Bonzini]

Il 28/01/2013 09:37, Gerd Hoffmann ha scritto:
>   Hi,
> 
>> This really is more of a distro problem than a QEMU one. If your
>> distro doesn't package libfdt, chances are quite good it just sucks.
> 
> Or just a little older.  Packaging dtc + libfdt is a pretty recent
> thing, many not-that-recent distros don't have it.
> 
> The libfdt installed on the rhel6 build bots didn't came with the distro
> for example.

FWIW, libfdt is now in EPEL.

Paolo

Re: [Qemu-devel] [PATCH V15 0/9] libqblock qemu block layer library

[Paolo Bonzini]

Il 28/01/2013 03:13, Wenchao Xia ha scritto:
> Sorry for that, do you know how to enable these extra checks?
> I used default configuration by "./configure" and did not check out
> this errors.

Probably you need to upgrade to a newer version of GCC.

Paolo

Re: [Qemu-devel] [RFC] FDT as a git submodule?

[Alexander Graf]

On 01/27/2013 03:34 PM, Anthony Liguori wrote:

Alexander Graf  writes:


Am 26.01.2013 um 19:13 schrieb Peter Crosthwaite:


Hi All,

On Sat, Jan 26, 2013 at 2:49 AM, Peter Maydell  wrote:

On 26 January 2013 10:11, Andreas Färber  wrote:

You forget that a "distro" is pretty much a Linux concept. There is no
such thing on W32 (openSUSE doesn't package it for MinGW either), and on
Darwin the various competing ports systems suck IMO.

On OpenBSD there's a "dtc" port but we'd need to assure it's installed
on the build bots before we mandate it, same for the Linux build bots.

Even on Linux having a libfdt that's available to compile against
is a comparatively recent thing -- it was only early 2012 IIRC that
Debian/Ubuntu got this, for instance.


I'm not objecting to mandating it but would like to propose to only
mandate it for the targets that need it. I.e., if no libfdt available,
don't install microblaze and ppc softmmu targets. That would still allow
the average user to emulate x86 or arm without hassles, and it should
not be needed for linux-user.

Im not proposing to mandate it at all initially. Just setup the
configurator such that if you --enable-fdt it gives you an option to
submodule it rather than just hard failing at configure time. Its
annoying to have to provide instructions for all the different distros
for apt/yum or build from source for this component. A "normal" build
of QEMU would be unaffected.


I'm leaning towards making FDT compulsory for ARM too: the kernel
is moving strongly in this direction and it is just annoying to
get a qemu that gives up when it encounters an FDT. The only reason
I haven't so far is just that availability in distros/OSes is too
spotty. An in-tree libfdt would solve that.


+1. The context of this for us is ARM as well not just out
Microblaze/PPC targets. Zynq with no FDT is of limited use and will
puke for anyone trying to boot Zynq Linux.


The pixman submodule has not been working well for me, it's not a
universally working solution to be copied either.

OTOH libfdt is:
* less than 4000 lines of code, half of which is the public .h file
* specifically intended by upstream to be taken and dropped into
   other peoples' projects (this is how you have to use it if you're
   a bootloader, for instance)
* built by just having your usual make process compile and link
   in an extra seven .c files

I don't know if we'd use a git submodule though -- we only want
a single subdir of upstream's git repo, not the whole thing.

I kinda want to take a "better than nothin" philosophy here. If the
upstream DTC is broken then you can still fall back to your distros.
With the proposal as it stands, your distro FDT will take precedent
over the submodule flow anyway. 4000 Lines is a pritty cheap download.

Fair enough.

Anthony, could you please create a mirror of dtc on git.qemu.org so we
can create a submodule against it.

Done.

http://git.qemu.org/?p=dtc.git;a=tree


Peter, could you please cook up a patch to

  * build libfdt/dtc from a git submodule if it's not found in the 
system and

  * make libfdt mandatory for at least PPC


Thanks!

Alex

Re: [Qemu-devel] [PATCH for-1.4] block/raw-posix: Build fix for O_ASYNC

[Stefan Hajnoczi]

On Sat, Jan 26, 2013 at 02:38:45PM +0100, Andreas Färber wrote:
> Commit eeb6b45d48800e96f67ef2a5c80332557fd45ddb (block: raw-posix image
> file reopen) broke the build on OpenIndiana.
> 
> illumos has no O_ASYNC. Exclude it from flags to be compared and
> use I_SETSIG ioctl after newly opening file.
> 
> Cf. e61ab1da7e98357da47c54d8f893b9bd6ff2f7f9 for qemu-ga.
> 
> Cc: qemu-sta...@nongnu.org (1.3.x)
> Cc: Jeff Cody 
> Signed-off-by: Andreas Färber 
> ---
>  block/raw-posix.c |   14 +-
>  1 Datei geändert, 13 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)

Thanks, applied to my block tree:
https://github.com/stefanha/qemu/commits/block

Stefan

Re: [Qemu-devel] [PATCH] Add a disk format named iROW, supporting high-efficiency VM snapshot

[Kevin Wolf]

[ Fixed CC email addresses ]

Am 26.01.2013 08:29, schrieb zhengjs@gmail.com:
> From: Jingsheng Zheng 
> 
> iRow (imporved Redirect-on-Write) is a disk format supporting high-efficiency 
> VM disk snapshot.
> iROW uses bitmap to reduce the amount of metadata, so that both the VM disk 
> snapshot key operations
> performance and the VM disk I/O performance would be enhanced at the same 
> time.
> 
> Signed-off-by : JingshengZheng 
> 
> ---
>  block/Makefile.objs |1 +
>  block/irow.c| 2257 
> +++
>  block/irow.h|  135 +++

Is this meant as an implementation for an existing image format that is
used by other products, or is meant to be new native qemu file format?

If the former, the commit message is lacking pointers to these other
products, as well as a link to the specification.

If the latter, doc/specs/irow.txt is the file that is missing and would
have to be reviewed before we look at any of the code. Additionally, you
would need to have a very strong justification for introducing a new
format because it introduces a maintenance burden for qemu. That
includes data on why (and if you're going for performance, how much)
it's better than existing formats, how much of this is really related to
the format rather than the driver, and why existing drivers can't be
extended to achieve the same.


Codewise, this isn't nearly compliant to the qemu coding style, please
use scripts/checkpatch.pl:

total: 2022 errors, 343 warnings, 2398 lines checked


Please provide at least a spec before we can review this.

Kevin

Re: [Qemu-devel] [RFC] FDT as a git submodule?

[Peter Maydell]

On 28 January 2013 08:58, Alexander Graf  wrote:
> Peter, could you please cook up a patch to
>
>   * build libfdt/dtc from a git submodule if it's not found in the system
> and
>   * make libfdt mandatory for at least PPC

...with an in-tree submodule I don't see much value in the
complication of making it only compiled in for some targets...

-- PMM

Re: [Qemu-devel] [RFC] FDT as a git submodule?

[Alexander Graf]

On 01/28/2013 10:28 AM, Peter Maydell wrote:

On 28 January 2013 08:58, Alexander Graf  wrote:

Peter, could you please cook up a patch to

   * build libfdt/dtc from a git submodule if it's not found in the system
and
   * make libfdt mandatory for at least PPC

...with an in-tree submodule I don't see much value in the
complication of making it only compiled in for some targets...


The main value add is that you don't have to fight with submodules :)


Alex

Re: [Qemu-devel] [PATCH for-1.4] block/raw-posix: Build fix for O_ASYNC

[Paolo Bonzini]

Il 26/01/2013 14:38, Andreas Färber ha scritto:
> Commit eeb6b45d48800e96f67ef2a5c80332557fd45ddb (block: raw-posix image
> file reopen) broke the build on OpenIndiana.
> 
> illumos has no O_ASYNC. Exclude it from flags to be compared and
> use I_SETSIG ioctl after newly opening file.
> 
> Cf. e61ab1da7e98357da47c54d8f893b9bd6ff2f7f9 for qemu-ga.
> 
> Cc: qemu-sta...@nongnu.org (1.3.x)
> Cc: Jeff Cody 
> Signed-off-by: Andreas Färber 
> ---
>  block/raw-posix.c |   14 +-
>  1 Datei geändert, 13 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
> 
> diff --git a/block/raw-posix.c b/block/raw-posix.c
> index 657af95..336c938 100644
> --- a/block/raw-posix.c
> +++ b/block/raw-posix.c
> @@ -46,6 +46,7 @@
>  #ifdef __sun__
>  #define _POSIX_PTHREAD_SEMANTICS 1
>  #include 
> +#include 
>  #endif
>  #ifdef __linux__
>  #include 
> @@ -345,7 +346,10 @@ static int raw_reopen_prepare(BDRVReopenState *state,
>  
>  raw_s->fd = -1;
>  
> -int fcntl_flags = O_APPEND | O_ASYNC | O_NONBLOCK;
> +int fcntl_flags = O_APPEND | O_NONBLOCK;
> +#ifndef CONFIG_SOLARIS
> +fcntl_flags |= O_ASYNC;
> +#endif
>  #ifdef O_NOATIME
>  fcntl_flags |= O_NOATIME;
>  #endif
> @@ -376,6 +380,14 @@ static int raw_reopen_prepare(BDRVReopenState *state,
>  raw_s->fd = qemu_open(state->bs->filename, raw_s->open_flags);
>  if (raw_s->fd == -1) {
>  ret = -1;
> +} else {
> +#ifdef CONFIG_SOLARIS
> +ret = ioctl(raw_s->fd, I_SETSIG, S_OUTPUT | S_INPUT | S_HIPRI);
> +if (ret == -1) {
> +qemu_close(raw_s->fd);
> +raw_s->fd = -1;
> +}
> +#endif

The flag is not set unconditionally.  It is only set if it was in
s->open_flags, and it should never be.

I would just add an

#ifdef O_ASYNC
/* Not all operating systems have O_ASYNC, and those that don't
 * will not let us track the state into raw_s->open_flags (typically
 * you achieve the same effect with an ioctl, for example I_SETSIG
 * on Solaris).  But we do not use O_ASYNC, so that's fine.
 */
assert((s->open_flags & O_ASYNC) == 0);
#endif

Paolo

[Qemu-devel] [PATCH v2 0/3] AER-KVM: Error containment of VFIO devices assigned to KVM guests

[Pandarathil, Vijaymohan R]

Add support for error containment when a VFIO device assigned to a KVM
guest encounters an error. This is for PCIe devices/drivers that support AER
functionality. When the host OS is notified of an error in a device either
through the firmware first approach or through an interrupt handled by the AER
root port driver, the error handler registered by the vfio-pci driver gets
invoked. The qemu process is signaled through an eventfd registered per
VFIO device by the qemu process. In the eventfd handler, qemu decides on
what action to take. In this implementation, guest is brought down to
contain the error.

v2:
 - Rebased to latest upstream stable bits
 - Changed the new ioctl to be part of VFIO_SET_IRQs ioctl
 - Added a new patch to get/put reference to a vfio device from struct device
 - Incorporated all other feedback.

---
Vijay Mohan Pandarathil(3):

[PATCH 1/3] VFIO: Wrappers for getting/putting reference to vfio_device
[PATCH 2/3] VFIO-AER: Vfio-pci driver changes for supporting AER
[PATCH 3/3] QEMU-AER: Qemu changes to support AER for VFIO-PCI devices

Kernel files changed

 drivers/vfio/vfio.c  | 47 +--
 include/linux/vfio.h |  3 +++
 2 files changed, 44 insertions(+), 6 deletions(-)

 drivers/vfio/pci/vfio_pci.c | 44 -
 drivers/vfio/pci/vfio_pci_intrs.c   | 32 +++
 drivers/vfio/pci/vfio_pci_private.h |  1 +
 include/uapi/linux/vfio.h   |  3 +++
 4 files changed, 79 insertions(+), 1 deletion(-)


Qemu files changed

 hw/vfio_pci.c  | 106 +
 linux-headers/linux/vfio.h |   3 ++
 2 files changed, 109 insertions(+)

[Qemu-devel] [PATCH v2 1/3] VFIO: Wrappers for getting/putting reference to vfio_device

[Pandarathil, Vijaymohan R]

- Added vfio_device_get_from_vdev(), vfio_device_put_vdev()
  as wrappers to get/put reference to vfio_device from struct device.

- Added vfio_device_data() as a wrapper to get device_data from
  vfio_device.

Signed-off-by: Vijay Mohan Pandarathil 
---
 drivers/vfio/vfio.c  | 47 +--
 include/linux/vfio.h |  3 +++
 2 files changed, 44 insertions(+), 6 deletions(-)

diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 12c264d..c2ff1b2 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -642,8 +642,13 @@ int vfio_add_group_dev(struct device *dev,
 }
 EXPORT_SYMBOL_GPL(vfio_add_group_dev);
 
-/* Test whether a struct device is present in our tracking */
-static bool vfio_dev_present(struct device *dev)
+/**
+ * This does a get on the corresponding iommu_group,
+ * vfio_group and the vfio_device. Callers of this
+ * function will hae to call vfio_put_vdev() to
+ * remove the reference to all objects.
+ */
+void *vfio_device_get_from_dev(struct device *dev)
 {
struct iommu_group *iommu_group;
struct vfio_group *group;
@@ -651,25 +656,55 @@ static bool vfio_dev_present(struct device *dev)
 
iommu_group = iommu_group_get(dev);
if (!iommu_group)
-   return false;
+   return NULL;
 
group = vfio_group_get_from_iommu(iommu_group);
if (!group) {
iommu_group_put(iommu_group);
-   return false;
+   return NULL;
}
 
device = vfio_group_get_device(group, dev);
if (!device) {
vfio_group_put(group);
iommu_group_put(iommu_group);
-   return false;
+   return NULL;
}
+   return device;
+}
+EXPORT_SYMBOL_GPL(vfio_device_get_from_dev);
+
+void *vfio_device_data(void *data)
+{
+   struct vfio_device *device = data;
+   return device->device_data;
+}
+EXPORT_SYMBOL_GPL(vfio_device_data);
+
+void vfio_device_put_vdev(void *data)
+{
+   struct vfio_device *device = data;
+   struct vfio_group *group = device->group;
+   struct iommu_group *iommu_group = group->iommu_group;
 
vfio_device_put(device);
vfio_group_put(group);
iommu_group_put(iommu_group);
-   return true;
+   return;
+}
+EXPORT_SYMBOL_GPL(vfio_device_put_vdev);
+
+/* Test whether a struct device is present in our tracking */
+static bool vfio_dev_present(struct device *dev)
+{
+   struct vfio_device *device;
+
+   device = vfio_device_get_from_dev(dev);
+   if (device) {
+   vfio_device_put_vdev(device);
+   return true;
+   } else
+   return false;
 }
 
 /*
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index ab9e862..e550c09 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -45,6 +45,9 @@ extern int vfio_add_group_dev(struct device *dev,
  void *device_data);
 
 extern void *vfio_del_group_dev(struct device *dev);
+extern void *vfio_device_get_from_dev(struct device *dev);
+extern void vfio_device_put_vdev(void *device);
+extern void *vfio_device_data(void *device);
 
 /**
  * struct vfio_iommu_driver_ops - VFIO IOMMU driver callbacks
-- 
1.7.11.3

[Qemu-devel] [PATCH v2 2/3] VFIO-AER: Vfio-pci driver changes for supporting AER

[Pandarathil, Vijaymohan R]

 
- New VFIO_SET_IRQ ioctl option to pass the eventfd that is signalled 
when
  an error occurs in the vfio_pci_device

- Register pci_error_handler for the vfio_pci driver

- When the device encounters an error, the error handler registered by
  the vfio_pci driver gets invoked by the AER infrastructure

- In the error handler, signal the eventfd registered for the device.

- This results in the qemu eventfd handler getting invoked and
  appropriate action taken for the guest.

Signed-off-by: Vijay Mohan Pandarathil 
---
 drivers/vfio/pci/vfio_pci.c | 44 -
 drivers/vfio/pci/vfio_pci_intrs.c   | 32 +++
 drivers/vfio/pci/vfio_pci_private.h |  1 +
 include/uapi/linux/vfio.h   |  3 +++
 4 files changed, 79 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index b28e66c..ff2a078 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -196,7 +196,9 @@ static int vfio_pci_get_irq_count(struct vfio_pci_device 
*vdev, int irq_type)
 
return (flags & PCI_MSIX_FLAGS_QSIZE) + 1;
}
-   }
+   } else if (irq_type == VFIO_PCI_ERR_IRQ_INDEX)
+   if (pci_is_pcie(vdev->pdev))
+   return 1;
 
return 0;
 }
@@ -223,9 +225,18 @@ static long vfio_pci_ioctl(void *device_data,
if (vdev->reset_works)
info.flags |= VFIO_DEVICE_FLAGS_RESET;
 
+   if (pci_is_pcie(vdev->pdev)) {
+   info.flags |= VFIO_DEVICE_FLAGS_PCI_AER;
+   info.flags |= VFIO_DEVICE_FLAGS_PCI_AER_NOTIFY;
+   }
+
info.num_regions = VFIO_PCI_NUM_REGIONS;
info.num_irqs = VFIO_PCI_NUM_IRQS;
 
+   /* Expose only implemented IRQs */
+   if (!(info.flags & VFIO_DEVICE_FLAGS_PCI_AER_NOTIFY))
+   info.num_irqs--;
+
return copy_to_user((void __user *)arg, &info, minsz);
 
} else if (cmd == VFIO_DEVICE_GET_REGION_INFO) {
@@ -302,6 +313,10 @@ static long vfio_pci_ioctl(void *device_data,
if (info.argsz < minsz || info.index >= VFIO_PCI_NUM_IRQS)
return -EINVAL;
 
+   if ((info.index == VFIO_PCI_ERR_IRQ_INDEX) &&
+!pci_is_pcie(vdev->pdev))
+   return -EINVAL;
+
info.flags = VFIO_IRQ_INFO_EVENTFD;
 
info.count = vfio_pci_get_irq_count(vdev, info.index);
@@ -538,11 +553,38 @@ static void vfio_pci_remove(struct pci_dev *pdev)
kfree(vdev);
 }
 
+static pci_ers_result_t vfio_err_detected(struct pci_dev *pdev,
+   pci_channel_state_t state)
+{
+   struct vfio_pci_device *vpdev;
+   void *vdev;
+
+   vdev = vfio_device_get_from_dev(&pdev->dev);
+   if (vdev == NULL)
+   return PCI_ERS_RESULT_DISCONNECT;
+
+   vpdev = vfio_device_data(vdev);
+   if (vpdev == NULL)
+   return PCI_ERS_RESULT_DISCONNECT;
+
+   if (vpdev->err_trigger)
+   eventfd_signal(vpdev->err_trigger, 1);
+
+   vfio_device_put_vdev(vdev);
+
+   return PCI_ERS_RESULT_CAN_RECOVER;
+}
+
+static const struct pci_error_handlers vfio_err_handlers = {
+   .error_detected = vfio_err_detected,
+};
+
 static struct pci_driver vfio_pci_driver = {
.name   = "vfio-pci",
.id_table   = NULL, /* only dynamic ids */
.probe  = vfio_pci_probe,
.remove = vfio_pci_remove,
+   .err_handler= &vfio_err_handlers,
 };
 
 static void __exit vfio_pci_cleanup(void)
diff --git a/drivers/vfio/pci/vfio_pci_intrs.c 
b/drivers/vfio/pci/vfio_pci_intrs.c
index 3639371..f003e08 100644
--- a/drivers/vfio/pci/vfio_pci_intrs.c
+++ b/drivers/vfio/pci/vfio_pci_intrs.c
@@ -745,6 +745,31 @@ static int vfio_pci_set_msi_trigger(struct vfio_pci_device 
*vdev,
return 0;
 }
 
+static int vfio_pci_set_err_eventfd(struct vfio_pci_device *vdev,
+   unsigned index, unsigned start,
+   unsigned count, uint32_t flags, void *data)
+{
+   if ((index == VFIO_PCI_ERR_IRQ_INDEX) &&
+   (flags & VFIO_IRQ_SET_DATA_EVENTFD)   &&
+   pci_is_pcie(vdev->pdev)) {
+
+   int32_t fd = *(int32_t *)data;
+
+   if (fd == -1) {
+   if (vdev->err_trigger)
+   eventfd_ctx_put(vdev->err_trigger);
+   vdev->err_trigger = NULL;
+   return 0;
+   } else if (fd >= 0) {
+   vdev->err_trigger = eventfd_ctx_fdget(fd);
+   if (IS_ERR(vdev->err_trigger))
+   return PTR_ERR(vdev->err_trigger);
+   return 0;
+

[Qemu-devel] [PATCH v2 3/3] QEMU-AER: Qemu changes to support AER for VFIO-PCI devices

[Pandarathil, Vijaymohan R]

- Create eventfd per vfio device assigned to a guest and register an
  event handler

- This fd is passed to the vfio_pci driver through the SET_IRQ ioctl

- When the device encounters an error, the eventfd is signalled
  and the qemu eventfd handler gets invoked.

- In the handler decide what action to take. Current action taken
  is to terminate the guest.

Signed-off-by: Vijay Mohan Pandarathil 
---
 hw/vfio_pci.c  | 106 +
 linux-headers/linux/vfio.h |   3 ++
 2 files changed, 109 insertions(+)

diff --git a/hw/vfio_pci.c b/hw/vfio_pci.c
index c51ae67..c4a6aec 100644
--- a/hw/vfio_pci.c
+++ b/hw/vfio_pci.c
@@ -130,6 +130,8 @@ typedef struct VFIODevice {
 QLIST_ENTRY(VFIODevice) next;
 struct VFIOGroup *group;
 bool reset_works;
+bool pci_aer_notify_cap;
+EventNotifier err_notifier;
 } VFIODevice;
 
 typedef struct VFIOGroup {
@@ -1837,6 +1839,10 @@ static int vfio_get_device(VFIOGroup *group, const char 
*name, VFIODevice *vdev)
 error_report("Warning, device %s does not support reset\n", name);
 }
 
+vdev->pci_aer_notify_cap = !!(dev_info.flags &
+(VFIO_DEVICE_FLAGS_PCI_AER |
+VFIO_DEVICE_FLAGS_PCI_AER_NOTIFY));
+
 if (dev_info.num_regions < VFIO_PCI_CONFIG_REGION_INDEX + 1) {
 error_report("vfio: unexpected number of io regions %u\n",
  dev_info.num_regions);
@@ -1922,6 +1928,103 @@ static void vfio_put_device(VFIODevice *vdev)
 }
 }
 
+static void vfio_err_notifier_handler(void *opaque)
+{
+VFIODevice *vdev = opaque;
+
+if (!event_notifier_test_and_clear(&vdev->err_notifier)) {
+return;
+}
+
+/*
+ * TBD. Retrieve the error details and decide what action
+ * needs to be taken. One of the actions could be to pass
+ * the error to the guest and have the guest driver recover
+ * from the error. This requires that PCIe capabilities be
+ * exposed to the guest. At present, we just terminate the
+ * guest to contain the error.
+ */
+
+error_report("%s (%04x:%02x:%02x.%x)"
+"Unrecoverable error detected... Terminating guest\n",
+__func__, vdev->host.domain, vdev->host.bus,
+vdev->host.slot, vdev->host.function);
+
+hw_error("(%04x:%02x:%02x.%x) Unrecoverable device error\n",
+vdev->host.domain, vdev->host.bus,
+vdev->host.slot, vdev->host.function);
+
+return;
+}
+
+static void vfio_register_err_notifier(VFIODevice *vdev)
+{
+int ret;
+int argsz;
+struct vfio_irq_set *irq_set;
+int32_t *pfd;
+
+if (!(vdev->pci_aer_notify_cap)) {
+DPRINTF("vfio: Error notification not supported for the device\n");
+return;
+}
+if (event_notifier_init(&vdev->err_notifier, 0)) {
+error_report("vfio: Warning: Unable to init event notifier for error 
detection\n");
+return;
+}
+
+argsz = sizeof(*irq_set) + sizeof(*pfd);
+
+irq_set = g_malloc0(argsz);
+irq_set->argsz = argsz;
+irq_set->flags = VFIO_IRQ_SET_DATA_EVENTFD |
+ VFIO_IRQ_SET_ACTION_TRIGGER;
+irq_set->index = VFIO_PCI_ERR_IRQ_INDEX;
+irq_set->start = 0;
+irq_set->count = 1;
+pfd = (int32_t *)&irq_set->data;
+
+*pfd = event_notifier_get_fd(&vdev->err_notifier);
+qemu_set_fd_handler(*pfd, vfio_err_notifier_handler, NULL, vdev);
+
+ret = ioctl(vdev->fd, VFIO_DEVICE_SET_IRQS, irq_set);
+if (ret) {
+error_report("vfio: Warning: Failed to setup error fd: %d\n", ret);
+qemu_set_fd_handler(*pfd, NULL, NULL, vdev);
+event_notifier_cleanup(&vdev->err_notifier);
+}
+g_free(irq_set);
+return;
+}
+static void vfio_unregister_err_notifier(VFIODevice *vdev)
+{
+int argsz;
+struct vfio_irq_set *irq_set;
+int32_t *pfd;
+int ret;
+
+argsz = sizeof(*irq_set) + sizeof(*pfd);
+
+irq_set = g_malloc0(argsz);
+irq_set->argsz = argsz;
+irq_set->flags = VFIO_IRQ_SET_DATA_EVENTFD |
+ VFIO_IRQ_SET_ACTION_TRIGGER;
+irq_set->index = VFIO_PCI_ERR_IRQ_INDEX;
+irq_set->start = 0;
+irq_set->count = 1;
+pfd = (int32_t *)&irq_set->data;
+*pfd = -1;
+
+ret = ioctl(vdev->fd, VFIO_DEVICE_SET_IRQS, irq_set);
+if (ret) {
+DPRINTF("vfio: Failed to de-assign error fd: %d\n", ret);
+}
+g_free(irq_set);
+qemu_set_fd_handler(event_notifier_get_fd(&vdev->err_notifier),
+NULL, NULL, vdev);
+event_notifier_cleanup(&vdev->err_notifier);
+return;
+}
 static int vfio_initfn(PCIDevice *pdev)
 {
 VFIODevice *pvdev, *vdev = DO_UPCAST(VFIODevice, pdev, pdev);
@@ -2032,6 +2135,8 @@ static int vfio_initfn(PCIDevice *pdev)
 }
 }
 
+vfio_register_err_notifier(vdev);
+
 return 0;
 
 out_teardown:
@@ -2049,6 +2154,7 @@ static void vfio_exitfn(PCIDevice *pdev)

Re: [Qemu-devel] [PATCH] add fd limitations for avoiding a buffer overflow

[Paolo Bonzini]

Il 25/01/2013 15:30, Stefan Hajnoczi ha scritto:
> Anthony, Paolo: Is there an alternative to select(2)?  I think this was
> discussed a bit during the glib event loop integration.
> 
> The two requirements I can think of are:
> 
> 1. Portable so that we don't have to write OS-specific versions (epoll,
> kqueue, etc).
> 
> 2. Sub-millisecond timeouts.
> 
> Maybe we can use timerfd (and emulate it on non-Linux hosts) and then
> fully use the glib event loop?

Switching the alarm timer to a timerfd-based GSource is indeed easy.  We
do not absolutely need sub-millisecond timeouts; non-Linux hosts can
just use poll's millisecond resolution in the GSource.

However, perhaps it would be good also to move the timer mechanism to
AioContext.  Then qemu_new_timer becomes a special case of
aio_new_timer, just like qemu_bh_new.  This would let BlockDriverStates
have timers that fire during a qemu_aio_wait().  It would fix the busy
waiting in bdrv_drain_all(), and it would help threaded device models
too.  But more refactoring is needed for this.

> Internally glib prefers poll(2) but will fall back to select(2) on weird
> OSes.  On Windows it has dedicated code.

The main obstacle for poll() is slirp, which likes to do random accesses
on fd_sets.

Perhaps it's a good topic for tomorrow's call.

Paolo

Re: [Qemu-devel] [PATCH 06/15] s390: Add channel I/O instructions.

[Cornelia Huck]

On Fri, 25 Jan 2013 20:28:31 +0100
Alexander Graf  wrote:

> However, I do agree that this duplicates logic. Cornelia, mind to instead 
> call our map helper in css_do_tpi?

Well, ioinst_handle_tpi() looks like the better place to do this.

Can you put this into the series, or should I re-send?

From a8064d80759e30662b0ac41643a29b41e9015a3f Mon Sep 17 00:00:00 2001
From: Cornelia Huck 
Date: Mon, 28 Jan 2013 10:42:44 +0100
Subject: [PATCH] s390: Use s390_cpu_physical_memory_map for tpi.

Map the I/O interruption code before calling into css.

Signed-off-by: Cornelia Huck 
---
 hw/s390x/css.c|  2 +-
 target-s390x/cpu.h|  4 ++--
 target-s390x/ioinst.c | 19 ++-
 target-s390x/ioinst.h |  7 +++
 4 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index 113ac9a..84efd4a 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -852,7 +852,7 @@ int css_do_stcrw(CRW *crw)
 return ret;
 }
 
-int css_do_tpi(uint64_t addr, int lowcore)
+int css_do_tpi(IOIntCode *int_code, int lowcore)
 {
 /* No pending interrupts for !KVM. */
 return 0;
diff --git a/target-s390x/cpu.h b/target-s390x/cpu.h
index ce12fa4..9be4a47 100644
--- a/target-s390x/cpu.h
+++ b/target-s390x/cpu.h
@@ -413,7 +413,7 @@ int css_do_hsch(SubchDev *sch);
 int css_do_ssch(SubchDev *sch, ORB *orb);
 int css_do_tsch(SubchDev *sch, IRB *irb);
 int css_do_stcrw(CRW *crw);
-int css_do_tpi(uint64_t addr, int lowcore);
+int css_do_tpi(IOIntCode *int_code, int lowcore);
 int css_collect_chp_desc(int m, uint8_t cssid, uint8_t f_chpid, uint8_t 
l_chpid,
  int rfmt, void *buf);
 void css_do_schm(uint8_t mbk, int update, int dct, uint64_t mbo);
@@ -471,7 +471,7 @@ static inline int css_do_stcrw(CRW *crw)
 {
 return 1;
 }
-static inline int css_do_tpi(uint64_t addr, int lowcore)
+static inline int css_do_tpi(IOIntCode *int_code, int lowcore)
 {
 return 0;
 }
diff --git a/target-s390x/ioinst.c b/target-s390x/ioinst.c
index 4ef2d73..e3531f3 100644
--- a/target-s390x/ioinst.c
+++ b/target-s390x/ioinst.c
@@ -619,16 +619,25 @@ int ioinst_handle_tpi(CPUS390XState *env, uint32_t ipb)
 {
 uint64_t addr;
 int lowcore;
+IOIntCode *int_code;
+hwaddr len, orig_len;
+int ret;
 
 trace_ioinst("tpi");
 addr = decode_basedisp_s(env, ipb);
 lowcore = addr ? 0 : 1;
-if (addr < 8192) {
-addr += env->psa;
-} else if ((env->psa <= addr) && (addr < env->psa + 8192)) {
-addr -= env->psa;
+len = lowcore ? 8 /* two words */ : 12 /* three words */;
+orig_len = len;
+int_code = s390_cpu_physical_memory_map(env, addr, &len, 1);
+if (!int_code || (len != orig_len)) {
+program_interrupt(env, PGM_SPECIFICATION, 2);
+ret = -EIO;
+goto out;
 }
-return css_do_tpi(addr, lowcore);
+ret = css_do_tpi(int_code, lowcore);
+out:
+s390_cpu_physical_memory_unmap(env, int_code, len, 1);
+return ret;
 }
 
 #define SCHM_REG1_RES(_reg) (_reg & 0x0ffc)
diff --git a/target-s390x/ioinst.h b/target-s390x/ioinst.h
index a59742c..d5a43f4 100644
--- a/target-s390x/ioinst.h
+++ b/target-s390x/ioinst.h
@@ -195,6 +195,13 @@ typedef struct CRW {
 #define CRW_RSC_SUBCH 0x3
 #define CRW_RSC_CHP   0x4
 
+/* I/O interruption code */
+typedef struct IOIntCode {
+uint32_t subsys_id;
+uint32_t intparm;
+uint32_t interrupt_id;
+} QEMU_PACKED IOIntCode;
+
 /* schid disintegration */
 #define IOINST_SCHID_ONE(_schid)   ((_schid & 0x0001) >> 16)
 #define IOINST_SCHID_M(_schid) ((_schid & 0x0008) >> 19)
-- 
1.7.12.4

Re: [Qemu-devel] [PATCH] Add a disk format named iROW, supporting high-efficiency VM snapshot

[Stefan Hajnoczi]

On Sat, Jan 26, 2013 at 04:15:37PM +0800, zhengjs@gmail.com wrote:
> diff --git a/block/irow.h b/block/irow.h
> new file mode 100644
> index 000..131b741
> --- /dev/null
> +++ b/block/irow.h
> @@ -0,0 +1,135 @@
> +/* IROW（Improved ROW）Disk Format
> + * */
> +/*
> + * iRow (imporved Redirect-on-Write) is a disk format supporting 
> high-efficiency VM disk snapshot.
> + * iROW uses bitmap to reduce the amount of metadata, so that both the VM 
> disk snapshot key operations
> + * performance and the VM disk I/O performance would be enhanced at the same 
> time.
> + *
> + *The iROW VM disk image consists of a meta file and several snapshots.
> + *
> + *A snapshot consists of 2 files: a bitmap file (btmp file) and a VM disk 
> data file (irvd file).
> + *The current state of the iROW VM disk also occupies a snapshot.
> + *
> + *The meta file consists of the meta header and the snapshots information. 
> The meta header is used to
> + *store basic information of VM disk image. The snapshots information 
> sequentially stores every snapshot’s name,
> + *id and others related information.
> + *
> + *The btmp file consists of a bitmap and the VM state data. The bitmap is 
> used to indicate whether the
> + *clusters exist in corresponding irvd file. Each cluster in the VM disk 
> image is mapped to a bit in the bitmap.
> + *
> + *The irvd file is used to store the actual data of the VM disk image. The 
> smallest unit of storage is cluster.
> + *iROW does not decide the address of the data clusters. It just writes the 
> clusters to the same VM disk image
> + *addresses as the virtual addresses of the clusters. Because of host 
> machine’s file system support sparse files,
> + *iROW also achieves the gradual growth of the VM disk image size with the 
> actual disk usage.
> + *
> + */
> +#define IROW_MAGIC (('I' << 24) | ('R' << 16) | ('O' << 8) | 'W')
> +#define IROW_VERSION 1
> +
> +#define IROW_SNAPHEADER_MAGIC (('S' << 24) | ('N' << 16) | ('A' << 8) | 'P')
> +
> +#define MIN_CLUSTER_BITS 9
> +#define MAX_CLUSTER_BITS 21
> +#define MAX_FILE_NAME_LENGTH 256
> +
> +#define IROW_READ 1
> +#define IROW_WRITE 2
> +#define IROW_AIO_READ 3
> +#define IROW_AIO_WRITE 4
> +
> +
> +typedef struct __attribute__((packed)) IRowMeta {
> +uint32_t magic;
> +uint32_t version;
> +uint32_t copy_on_demand;
> +uint32_t nb_snapshots;
> +uint32_t cluster_size;
> +uint32_t cluster_bits;
> +uint32_t sectors_per_cluster;
> +uint64_t total_clusters;
> +uint64_t disk_size;
> +char current_btmp[MAX_FILE_NAME_LENGTH];
> +char backing_file[MAX_FILE_NAME_LENGTH];
> +} IRowMeta;
> +
> +typedef struct __attribute__((packed)) IRowSnapshotHeader {
> + uint32_t snap_magic;
> + char id_str[128];
> + char name[256];
> + char btmp_file[MAX_FILE_NAME_LENGTH];
> + char irvd_file[MAX_FILE_NAME_LENGTH];
> + char father_btmp_file[MAX_FILE_NAME_LENGTH];
> + uint32_t vm_state_size;
> + uint32_t date_sec;
> + uint32_t date_nsec;
> + uint64_t vm_clock_nsec;
> + uint32_t nb_children;
> + uint32_t is_deleted;
> +} IRowSnapshotHeader;

Hi,
This seems to be the code for the following paper:
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6413673&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F6412851%2F6413550%2F06413673.pdf%3Farnumber%3D6413673

I don't have an IEEE subscription so I can't read the paper.

Here is my understanding of the iROW file format:

1. The metafile

The metafile is the main file which contains the basic disk image
information (virtual size, cluster size) in a header structure.

After the header is a list of snapshots.  Each snapshot has an
allocation bitmap file and a data cluster file.  The snapshot also
points to its parent snapshot so that the snapshot chain can be
traversed.

Snapshots are not deleted from disk, instead they are simply marked as
deleted.  This is necessary so that child snapshots continue to function
after a parent is deleted.

The header contains a "copy_on_demand" bit which is similar to QEMU's
built-in copy-on-read feature.  It can be used to populate the leaf
snapshot with image data from its parents.

2. The bitmap file

The bitmap file contains the allocation bitmap of the snapshot.  A bit
is set if the cluster has been written to and clear otherwise.

3. The data file

This is a sparse raw file containing data clusters written to this
snapshot.

---

If this is a new file format (not used in existing hypervisors or tools)
then I'm afraid it is mostly duplicated code:

The core of iROW is a raw image file with an allocation bitmap, this is
the same as Dong Xu Wang's add-cow file format:
http://comments.gmane.org/gmane.comp.emulators.qemu/183210

iROW implements a fake internal snapshots interface.  In other words, it
reimplements backing files inside the block driver and presents it as
internal snapshots.  However, we get none of the benefits of real
internal snapshots:

 * Deleting snapshots is not possible if c

Re: [Qemu-devel] [PULL 00/15] s390 patch queue 2013-01-25

[Cornelia Huck]

On Sat, 26 Jan 2013 14:17:36 +
Blue Swirl  wrote:

> On Fri, Jan 25, 2013 at 12:48 PM, Alexander Graf  wrote:
> > Hi Blue / Aurelien,
> >
> > This is my current patch queue for s390.  Please pull.
> >
> > Alex
> >
> >
> > The following changes since commit 11c29918be32be5b00f367c7da9724a5cddbbb0f:
> >   Anthony Liguori (1):
> > Merge remote-tracking branch 'bonzini/scsi-next' into staging
> >
> > are available in the git repository at:
> >
> >   git://repo.or.cz/qemu/agraf.git s390-for-upstream
> >
> > Alexander Graf (3):
> >   s390: Add default support for SCLP console
> >   s390: Make typeinfo const
> >   s390: Move hw files to hw/s390x
> >
> > Andreas Färber (1):
> >   s390-virtio: Check for NULL device in reset hypercall
> >
> > Cornelia Huck (10):
> >   s390: Lowcore mapping helper.
> >   s390: Add mapping helper functions.
> >   s390: Channel I/O basic definitions.
> >   s390: I/O interrupt and machine check injection.
> >   s390: Add channel I/O instructions.
> >   s390: Virtual channel subsystem support.
> 
> This would break build on mingw32:
>   CCs390x-softmmu/hw/s390x/css.o
> /src/qemu/hw/s390x/css.c: In function 'css_interpret_ccw':
> /src/qemu/hw/s390x/css.c:226:17: error: 'ERESTART' undeclared (first
> use in this function)
> /src/qemu/hw/s390x/css.c:226:17: note: each undeclared identifier is
> reported only once for each function it appears in
> /src/qemu/hw/s390x/css.c:294:20: error: 'EOPNOTSUPP' undeclared (first
> use in this function)
> /src/qemu/hw/s390x/css.c: In function 'sch_handle_start_func':
> /src/qemu/hw/s390x/css.c:350:15: error: 'EOPNOTSUPP' undeclared (first
> use in this function)
> /src/qemu/hw/s390x/css.c:375:15: error: 'ERESTART' undeclared (first
> use in this function)

That's unfortunate :(

Are there some kinds of compatibility headers that define the missing
error codes, or does something need to be fenced off here?

I would appreciate it if somebody could give me a hand here, especially
as I don't have a mingw32 environment around...

> 
> >   s390: Wire up channel I/O in kvm.
> >   s390-virtio: Factor out some initialization code.
> >   s390: Add new channel I/O based virtio transport.
> >   s390: Add s390-ccw-virtio machine.
> >
> > Paolo Bonzini (1):
> >   virtio-s390: add a reset function to virtio-s390 devices
> >
> >  hw/boards.h  |1 +
> >  hw/s390-virtio.h |   22 -
> >  hw/s390x/Makefile.objs   |5 +-
> >  hw/s390x/css.c   | 1277 
> > ++
> >  hw/s390x/css.h   |   99 +++
> >  hw/s390x/ipl.c   |2 +-
> >  hw/{ => s390x}/s390-virtio-bus.c |   16 +-
> >  hw/{ => s390x}/s390-virtio-bus.h |   12 +-
> >  hw/s390x/s390-virtio-ccw.c   |  134 
> >  hw/s390x/s390-virtio-hcall.c |2 +-
> >  hw/{ => s390x}/s390-virtio.c |  131 +++--
> >  hw/s390x/s390-virtio.h   |   28 +
> >  hw/s390x/virtio-ccw.c|  960 
> >  hw/s390x/virtio-ccw.h|   98 +++
> >  target-s390x/Makefile.objs   |2 +-
> >  target-s390x/cpu.h   |  247 -
> >  target-s390x/helper.c|  200 ++-
> >  target-s390x/ioinst.c|  752 ++
> >  target-s390x/ioinst.h|  223 +++
> >  target-s390x/kvm.c   |  239 +++-
> >  trace-events |   18 +
> >  vl.c |   51 ++
> >  22 files changed, 4403 insertions(+), 116 deletions(-)
> >  delete mode 100644 hw/s390-virtio.h
> >  create mode 100644 hw/s390x/css.c
> >  create mode 100644 hw/s390x/css.h
> >  rename hw/{ => s390x}/s390-virtio-bus.c (98%)
> >  rename hw/{ => s390x}/s390-virtio-bus.h (95%)
> >  create mode 100644 hw/s390x/s390-virtio-ccw.c
> >  rename hw/{ => s390x}/s390-virtio.c (85%)
> >  create mode 100644 hw/s390x/s390-virtio.h
> >  create mode 100644 hw/s390x/virtio-ccw.c
> >  create mode 100644 hw/s390x/virtio-ccw.h
> >  create mode 100644 target-s390x/ioinst.c
> >  create mode 100644 target-s390x/ioinst.h
> 

Re: [Qemu-devel] [PATCH 00/57] target-i386 eflags cleanup and bmi/adx extensions

[Jay Foad]

> Checkpatch doesn't work well with the pattern
>
> #ifdef SOMETHING
> if (foo) {
> bar();
> } else
> #endif
> {
> baz1();
> baz2();
> }
>
> Which is exactly the case for all three errors reported in this series.
> I know of no other good way to arrange this pattern.

if (0) {
#ifdef SOMETHING
} else if (foo) {
bar();
#endif
} else {
baz1();
baz2();
}

Jay.

Re: [Qemu-devel] [PATCH 4/5] target-i386: set custom features/properties without intermediate x86_def_t

[Igor Mammedov]

On Sat, 26 Jan 2013 16:26:07 +0100
Andreas Färber  wrote:

> Am 21.01.2013 15:06, schrieb Igor Mammedov:
> > Move custom features parsing after built-in cpu_model defaults are set
> > and set custom features directly on CPU instance. That allows to make
> > clear distinction between built-in cpu model defaults that eventually
> > should go into clas_init() and extra property setting which is done
> > after defaults are set on CPU instance.
> > 
> > Impl. details:
> >* use object_property_parse() property setter so it would be mechanical
> >  change to switch to global properties later.
> >* And after all current features/properties are converted into static
> >  properties, it will take a trivial patch to switch to global 
> > properties.
> >  Which will allow to:
> >  * get CPU instance initialized with all parameters passed on -cpu ...
> >cmd. line from object_new() call.
> >  * call cpu_model/featurestr parsing only once before CPUs are created
> >  * open a road for removing CPUxxxState.cpu_model_str field, when other
> >CPUs are similarly converted to subclasses and static properties.
> >  - re-factor error handling, to use Error instead of fprintf()s, since
> >it is anyway passed in for property setter.
> > 
> > Signed-off-by: Igor Mammedov 
> > ---
> >   v2:
> > - removed temporary list of properties.
> > Suggested-By: Eduardo Habkost 
> > - check if error is set before cpu_x86_parse_featurestr() is called
> >   to avoid assert in error_setg().
> > ---
> >  target-i386/cpu.c |  118 
> > +++--
> >  1 files changed, 51 insertions(+), 67 deletions(-)
> > 
> > diff --git a/target-i386/cpu.c b/target-i386/cpu.c
> > index 768ca69..640cc8f 100644
> > --- a/target-i386/cpu.c
> > +++ b/target-i386/cpu.c
> > @@ -1299,7 +1299,7 @@ static int cpu_x86_find_by_name(x86_def_t 
> > *x86_cpu_def, const char *name)
> >  
> >  /* Parse "+feature,-feature,feature=foo" CPU feature string
> >   */
> > -static int cpu_x86_parse_featurestr(x86_def_t *x86_cpu_def, char *features)
> > +static void cpu_x86_parse_featurestr(X86CPU *cpu, char *features, Error 
> > **errp)
> >  {
> >  char *featurestr; /* Single 'key=value" string being parsed */
> >  /* Features to be added */
> > @@ -1307,6 +1307,7 @@ static int cpu_x86_parse_featurestr(x86_def_t 
> > *x86_cpu_def, char *features)
> >  /* Features to be removed */
> >  FeatureWordArray minus_features = { 0 };
> >  uint32_t numvalue;
> > +CPUX86State *env = &cpu->env;
> >  
> >  featurestr = features ? strtok(features, ",") : NULL;
> >  
> > @@ -1319,77 +1320,57 @@ static int cpu_x86_parse_featurestr(x86_def_t 
> > *x86_cpu_def, char *features)
> >  } else if ((val = strchr(featurestr, '='))) {
> >  *val = 0; val++;
> >  if (!strcmp(featurestr, "family")) {
> > -char *err;
> > -numvalue = strtoul(val, &err, 0);
> > -if (!*val || *err || numvalue > 0xff + 0xf) {
> > -fprintf(stderr, "bad numerical value %s\n", val);
> > -goto error;
> > -}
> > -x86_cpu_def->family = numvalue;
> > +object_property_parse(OBJECT(cpu), val, featurestr, errp);
> >  } else if (!strcmp(featurestr, "model")) {
> > -char *err;
> > -numvalue = strtoul(val, &err, 0);
> > -if (!*val || *err || numvalue > 0xff) {
> > -fprintf(stderr, "bad numerical value %s\n", val);
> > -goto error;
> > -}
> > -x86_cpu_def->model = numvalue;
> > +object_property_parse(OBJECT(cpu), val, featurestr, errp);
> >  } else if (!strcmp(featurestr, "stepping")) {
> > -char *err;
> > -numvalue = strtoul(val, &err, 0);
> > -if (!*val || *err || numvalue > 0xf) {
> > -fprintf(stderr, "bad numerical value %s\n", val);
> > -goto error;
> > -}
> > -x86_cpu_def->stepping = numvalue ;
> > +object_property_parse(OBJECT(cpu), val, featurestr, errp);
> >  } else if (!strcmp(featurestr, "level")) {
> > -char *err;
> > -numvalue = strtoul(val, &err, 0);
> > -if (!*val || *err) {
> > -fprintf(stderr, "bad numerical value %s\n", val);
> > -goto error;
> > -}
> > -x86_cpu_def->level = numvalue;
> > +object_property_parse(OBJECT(cpu), val, featurestr, errp);
> >  } else if (!strcmp(featurestr, "xlevel")) {
> >  char *err;
> > +char num[32];
> > +
> >  numvalue = strtoul(val, &err, 0);
> >  if (!*val || *err) {
> > -  

Re: [Qemu-devel] [PATCH qom-cpu 0/5 v2] x86 CPU cleanup, part 4

[Igor Mammedov]

On Sat, 26 Jan 2013 16:50:12 +0100
Andreas Färber  wrote:

> Am 21.01.2013 15:06, schrieb Igor Mammedov:
> > Igor Mammedov (5):
> >   target-i386: print deprecated warning if xlevel < 0x8000
> >   target-i386: replace uint32_t vendor fields by vendor string in
> > x86_def_t
> >   target-i386: remove vendor_override field from CPUX86State
> >   target-i386: set custom features/properties without intermediate
> > x86_def_t
> >   target-i386: remove setting tsc-frequency from x86_def_t
> 
> I left some comments on 4/5 but applied the remainder of the series to
> qom-cpu queue nontheless, as a good preparation for X86CPU subclasses.
> 
> https://github.com/afaerber/qemu-cpu/commits/qom-cpu
> 
> I'd appreciate if you could double-check spelling of commit messages and
> restrict them to 76 chars (check `git log` on 80-wide terminal).
> Also a reminder that I capitalize the first word of the title after the
> topic for consistency and so that it stands out more. ;)
I'll make extra checks before posting next patches.

> Feel free to complain if I didn't get the difference of the * and -
> bullet points on 4/5 for instance.
It's not of difference to me. I'll use * in follow-ups.

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


-- 
Regards,
  Igor

Re: [Qemu-devel] [PATCH 4/4] qemu/log.h: Fix missing includes

[Igor Mammedov]

On Sat, 26 Jan 2013 12:54:36 -0800
Peter Crosthwaite  wrote:

> qemu/log.h needs a few bits and pieces from qemu-common to compile.
> Fixes the case where qemu/log.h is the first files included.
> 
> Signed-off-by: Peter Crosthwaite 
> ---
>  include/qemu/log.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/qemu/log.h b/include/qemu/log.h
> index 58f69cb..0a1266d 100644
> --- a/include/qemu/log.h
> +++ b/include/qemu/log.h
> @@ -2,6 +2,7 @@
>  #define QEMU_LOG_H
>  
>  #include 
> +#include "qemu-common.h"
Could you try to avoid including it header, and instead of move whatever
definitions it depends on to their proper places?
Reasoning for not including it in other headers, that it often creates circular
header dependencies of header that includes it is included in another header.

>  #ifdef NEED_CPU_H
>  #include "disas/disas.h"
>  #endif
> -- 
> 1.7.12.1.396.g16eed7c
> 
> 
> 


-- 
Regards,
  Igor

Re: [Qemu-devel] Bug with qxl vga memory settings

[Gerd Hoffmann]

On 01/25/13 15:37, Fabio Fantoni wrote:
> Debugging qxl problem with xen I tested first qemu without xen and I
> found that qxl memory mapping problem is not only xen related.
> After some tests with qemu-only I found that -global qxl-vga.vram_size=N
> and -global qxl-vga.ram_size=N (where N is for example 16384 or 65536)
> are bugged.

ram_size + vram_size want bytes not kilobytes.

> Qxl ram regions with these parameters on all test are always:
> 
> qxl-0: ram/pri: 32 MB [region 0]
> qxl-0: vram/32: 0 MB [region 1]

Yep.  You'll get the minimum supported sizes due to the small numbers.

> Qemu crashes when start using qxl.

Oops.  That shouldn't happen of course, I'll have a look.

> With -global qxl-vga.vram_size_mb=N and -global qxl-vga.ram_size_mb=N it
> seems correctly working.

Ah, you've found the more user-friendly versions which accept megabytes
instead of bytes.

> For example I saw that on ALL tests with right qxl memory region 0 and 1
> there is also another unmapped region > 0 mb.

The rom bar maybe?  seabios maps that only temporary to load the vgabios.

> Is it correct or is it wrong and can be the cause of crash with xen if
> qemu search for videoram > region0+region1?
> qxl-0: ram/pri: 32 MB [region 0]
> qxl-0: vram/32: 32 MB [region 1]
> qxl-0: vram/64: 32 MB [unmapped]

vram/64 is a mirror of vram/32, but in a 64bit capable pci bar.  It will
show up if you make vram64_size_mb larger than vram_size_mb and allows
pretty big vram bars for 64bit guests.

> I saw also that qemu 1.3 debian package use vgabios from vgabios 0.7
> package instead of seabios 1.7.2 package.
> Can be a problem with qxl?

Both should work (assuming vgabios is taken from the repo @ qemu.org).

cheers,
  Gerd

Re: [Qemu-devel] Bug with qxl vga memory settings

[Gerd Hoffmann]

>> After some tests with qemu-only I found that -global qxl-vga.vram_size=N
>> and -global qxl-vga.ram_size=N (where N is for example 16384 or 65536)
>> are bugged.

>> qxl-0: ram/pri: 32 MB [region 0]
>> qxl-0: vram/32: 0 MB [region 1]
> 
> Yep.  You'll get the minimum supported sizes due to the small numbers.
> 
>> Qemu crashes when start using qxl.
> 
> Oops.  That shouldn't happen of course, I'll have a look.

Doesn't reproduce (git master).

cheers,
  Gerd

[Qemu-devel] KVM call agenda for 2013-01-29

[Juan Quintela]

Hi

Please send in any agenda topics you are interested in.

Later, Juan.

[Qemu-devel] [PATCH for-1.4 v2] target-i386: kvm: prevent buffer overflow if -cpu foo, [x]level is too big

[Igor Mammedov]

Stack corruption may occur if too big 'level' or 'xlevel' values passed
on command line with KVM enabled, due to limited size of cpuid_data
in kvm_arch_init_vcpu().

reproduces with:
 qemu -enable-kvm -cpu qemu64,level=4294967295
or
 qemu -enable-kvm -cpu qemu64,xlevel=4294967295

Check if there is space in cpuid_data before passing it to cpu_x86_cpuid()
or abort() if there is not space.

Signed-off-by: Igor Mammedov 
---
  * v2:
* use macro instead of const int max_cpuid_entries to fix build breakage
  in C99 mode. Suggested-By: Laszlo Ersek 
* compare with array index instead of address of the last element
  Sugested-By: Marcelo Tosatti 

---
 target-i386/kvm.c |   25 -
 1 files changed, 24 insertions(+), 1 deletions(-)

diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 3acff40..4ecb728 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -411,11 +411,12 @@ static void cpu_update_state(void *opaque, int running, 
RunState state)
 }
 }
 
+#define KVM_MAX_CPUID_ENTRIES  100
 int kvm_arch_init_vcpu(CPUState *cs)
 {
 struct {
 struct kvm_cpuid2 cpuid;
-struct kvm_cpuid_entry2 entries[100];
+struct kvm_cpuid_entry2 entries[KVM_MAX_CPUID_ENTRIES];
 } QEMU_PACKED cpuid_data;
 X86CPU *cpu = X86_CPU(cs);
 CPUX86State *env = &cpu->env;
@@ -502,6 +503,10 @@ int kvm_arch_init_vcpu(CPUState *cs)
 cpu_x86_cpuid(env, 0, 0, &limit, &unused, &unused, &unused);
 
 for (i = 0; i <= limit; i++) {
+if (cpuid_i == KVM_MAX_CPUID_ENTRIES) {
+fprintf(stderr, "unsupported level value: 0x%x\n", limit);
+abort();
+}
 c = &cpuid_data.entries[cpuid_i++];
 
 switch (i) {
@@ -516,6 +521,11 @@ int kvm_arch_init_vcpu(CPUState *cs)
 times = c->eax & 0xff;
 
 for (j = 1; j < times; ++j) {
+if (cpuid_i == KVM_MAX_CPUID_ENTRIES) {
+fprintf(stderr, "cpuid_data is full, no space for "
+"cpuid(eax:2):eax & 0xf = 0x%x\n", times);
+abort();
+}
 c = &cpuid_data.entries[cpuid_i++];
 c->function = i;
 c->flags = KVM_CPUID_FLAG_STATEFUL_FUNC;
@@ -544,6 +554,11 @@ int kvm_arch_init_vcpu(CPUState *cs)
 if (i == 0xd && c->eax == 0) {
 continue;
 }
+if (cpuid_i == KVM_MAX_CPUID_ENTRIES) {
+fprintf(stderr, "cpuid_data is full, no space for "
+"cpuid(eax:0x%x,ecx:0x%x)\n", i, j);
+abort();
+}
 c = &cpuid_data.entries[cpuid_i++];
 }
 break;
@@ -557,6 +572,10 @@ int kvm_arch_init_vcpu(CPUState *cs)
 cpu_x86_cpuid(env, 0x8000, 0, &limit, &unused, &unused, &unused);
 
 for (i = 0x8000; i <= limit; i++) {
+if (cpuid_i == KVM_MAX_CPUID_ENTRIES) {
+fprintf(stderr, "unsupported xlevel value: 0x%x\n", limit);
+abort();
+}
 c = &cpuid_data.entries[cpuid_i++];
 
 c->function = i;
@@ -569,6 +588,10 @@ int kvm_arch_init_vcpu(CPUState *cs)
 cpu_x86_cpuid(env, 0xC000, 0, &limit, &unused, &unused, &unused);
 
 for (i = 0xC000; i <= limit; i++) {
+if (cpuid_i == KVM_MAX_CPUID_ENTRIES) {
+fprintf(stderr, "unsupported xlevel2 value: 0x%x\n", limit);
+abort();
+}
 c = &cpuid_data.entries[cpuid_i++];
 
 c->function = i;
-- 
1.7.1

Re: [Qemu-devel] [PATCH for-1.4 v2] target-i386: kvm: prevent buffer overflow if -cpu foo, [x]level is too big

[Laszlo Ersek]

On 01/28/13 12:49, Igor Mammedov wrote:
> Stack corruption may occur if too big 'level' or 'xlevel' values passed
> on command line with KVM enabled, due to limited size of cpuid_data
> in kvm_arch_init_vcpu().
> 
> reproduces with:
>  qemu -enable-kvm -cpu qemu64,level=4294967295
> or
>  qemu -enable-kvm -cpu qemu64,xlevel=4294967295
> 
> Check if there is space in cpuid_data before passing it to cpu_x86_cpuid()
> or abort() if there is not space.
> 
> Signed-off-by: Igor Mammedov 
> ---
>   * v2:
> * use macro instead of const int max_cpuid_entries to fix build breakage
>   in C99 mode. Suggested-By: Laszlo Ersek 
> * compare with array index instead of address of the last element
>   Sugested-By: Marcelo Tosatti 
> 
> ---
>  target-i386/kvm.c |   25 -
>  1 files changed, 24 insertions(+), 1 deletions(-)

Reviewed-by: Laszlo Ersek 

[Qemu-devel] [PATCHv4 2/2] qemu-img: add json output option to the check command

[Federico Simoncelli]

This option --output=[human|json] makes qemu-img check output a human
or JSON representation at the choice of the user.

Signed-off-by: Federico Simoncelli 
---
 qapi-schema.json |   46 +++
 qemu-img-cmds.hx |4 +-
 qemu-img.c   |  232 +++---
 qemu-img.texi|5 +-
 4 files changed, 220 insertions(+), 67 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index 6d7252b..dc99c28 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -245,6 +245,52 @@
'*backing-filename-format': 'str', '*snapshots': ['SnapshotInfo'] } 
}
 
 ##
+# @ImageCheck:
+#
+# Information about a QEMU image file check
+#
+# @filename: name of the image file checked
+#
+# @format: format of the image file checked
+#
+# @check-errors: number of unexpected errors occurred during check
+#
+# @image-end-offset: #optional offset (in bytes) where the image ends, this
+#field is present if the driver for the image format
+#supports it
+#
+# @corruptions: #optional number of corruptions found during the check if any
+#
+# @leaks: #optional number of leaks found during the check if any
+#
+# @corruptions-fixed: #optional number of corruptions fixed during the check
+# if any
+#
+# @leaks-fixed: #optional number of leaks fixed during the check if any
+#
+# @total-clusters: #optional total number of clusters, this field is present
+#  if the driver for the image format supports it
+#
+# @allocated-clusters: #optional total number of allocated clusters, this
+#  field is present if the driver for the image format
+#  supports it
+#
+# @fragmented-clusters: #optional total number of fragmented clusters, this
+#   field is present if the driver for the image format
+#   supports it
+#
+# Since: 1.4
+#
+##
+
+{ 'type': 'ImageCheck',
+  'data': {'filename': 'str', 'format': 'str', 'check-errors': 'int',
+   '*image-end-offset': 'int', '*corruptions': 'int', '*leaks': 'int',
+   '*corruptions-fixed': 'int', '*leaks-fixed': 'int',
+   '*total-clusters': 'int', '*allocated-clusters': 'int',
+   '*fragmented-clusters': 'int' } }
+
+##
 # @StatusInfo:
 #
 # Information about VCPU run state
diff --git a/qemu-img-cmds.hx b/qemu-img-cmds.hx
index a181363..259fc14 100644
--- a/qemu-img-cmds.hx
+++ b/qemu-img-cmds.hx
@@ -10,9 +10,9 @@ STEXI
 ETEXI
 
 DEF("check", img_check,
-"check [-f fmt] [-r [leaks | all]] filename")
+"check [-f fmt] [--output=ofmt] [-r [leaks | all]] filename")
 STEXI
-@item check [-f @var{fmt}] [-r [leaks | all]] @var{filename}
+@item check [-f @var{fmt}] [--output=@var{ofmt}] [-r [leaks | all]] 
@var{filename}
 ETEXI
 
 DEF("create", img_create,
diff --git a/qemu-img.c b/qemu-img.c
index e80c1c5..34249fe 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -42,6 +42,16 @@ typedef struct img_cmd_t {
 int (*handler)(int argc, char **argv);
 } img_cmd_t;
 
+enum {
+OPTION_OUTPUT = 256,
+OPTION_BACKING_CHAIN = 257,
+};
+
+typedef enum OutputFormat {
+OFORMAT_JSON,
+OFORMAT_HUMAN,
+} OutputFormat;
+
 /* Default to cache=writeback as data integrity is not important for qemu-tcg. 
*/
 #define BDRV_O_FLAGS BDRV_O_CACHE_WB
 #define BDRV_DEFAULT_CACHE "writeback"
@@ -375,6 +385,96 @@ static int img_create(int argc, char **argv)
 return 0;
 }
 
+static void dump_json_image_check(ImageCheck *check)
+{
+Error *errp = NULL;
+QString *str;
+QmpOutputVisitor *ov = qmp_output_visitor_new();
+QObject *obj;
+visit_type_ImageCheck(qmp_output_get_visitor(ov),
+  &check, NULL, &errp);
+obj = qmp_output_get_qobject(ov);
+str = qobject_to_json_pretty(obj);
+assert(str != NULL);
+printf("%s\n", qstring_get_str(str));
+qobject_decref(obj);
+qmp_output_visitor_cleanup(ov);
+QDECREF(str);
+}
+
+static void dump_human_image_check(ImageCheck *check)
+{
+if (!(check->corruptions || check->leaks || check->check_errors)) {
+printf("No errors were found on the image.\n");
+} else {
+if (check->corruptions) {
+printf("\n%" PRId64 " errors were found on the image.\n"
+"Data may be corrupted, or further writes to the image "
+"may corrupt it.\n",
+check->corruptions);
+}
+
+if (check->leaks) {
+printf("\n%" PRId64 " leaked clusters were found on the image.\n"
+"This means waste of disk space, but no harm to data.\n",
+check->leaks);
+}
+
+if (check->check_errors) {
+printf("\n%" PRId64 " internal errors have occurred during the 
check.\n",
+check->check_errors);
+}
+}
+
+if (check->total_clusters != 0 && check->allocated_clusters != 0) {
+printf("%" PRId64 "/%" PRId64 "= %0.2f%% allocated, %0.2f%% 
fr

[Qemu-devel] [PATCHv4 1/2] qemu-img: find the image end offset during check

[Federico Simoncelli]

This patch adds the support for reporting the image end offset (in
bytes). This is particularly useful after a conversion (or a rebase)
where the destination is a block device in order to find the first
unused byte at the end of the image.

Signed-off-by: Federico Simoncelli 
---
 block/qcow2-refcount.c   |   10 --
 include/block/block.h|1 +
 qemu-img.c   |4 
 tests/qemu-iotests/026   |6 +++---
 tests/qemu-iotests/036   |3 ++-
 tests/qemu-iotests/039   |2 +-
 tests/qemu-iotests/044.out   |1 +
 tests/qemu-iotests/common.rc |5 +++--
 8 files changed, 23 insertions(+), 9 deletions(-)

diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c
index 6a95aa6..45ad043 100644
--- a/block/qcow2-refcount.c
+++ b/block/qcow2-refcount.c
@@ -1116,7 +1116,7 @@ int qcow2_check_refcounts(BlockDriverState *bs, 
BdrvCheckResult *res,
   BdrvCheckMode fix)
 {
 BDRVQcowState *s = bs->opaque;
-int64_t size, i;
+int64_t size, i, highest_cluster;
 int nb_clusters, refcount1, refcount2;
 QCowSnapshot *sn;
 uint16_t *refcount_table;
@@ -1187,7 +1187,7 @@ int qcow2_check_refcounts(BlockDriverState *bs, 
BdrvCheckResult *res,
 }
 
 /* compare ref counts */
-for(i = 0; i < nb_clusters; i++) {
+for(i = 0, highest_cluster = 0; i < nb_clusters; i++) {
 refcount1 = get_refcount(bs, i);
 if (refcount1 < 0) {
 fprintf(stderr, "Can't get refcount for cluster %" PRId64 ": %s\n",
@@ -1197,6 +1197,11 @@ int qcow2_check_refcounts(BlockDriverState *bs, 
BdrvCheckResult *res,
 }
 
 refcount2 = refcount_table[i];
+
+if (refcount1 > 0 || refcount2 > 0) {
+highest_cluster = i;
+}
+
 if (refcount1 != refcount2) {
 
 /* Check if we're allowed to fix the mismatch */
@@ -1231,6 +1236,7 @@ int qcow2_check_refcounts(BlockDriverState *bs, 
BdrvCheckResult *res,
 }
 }
 
+res->image_end_offset = (highest_cluster + 1) * s->cluster_size;
 ret = 0;
 
 fail:
diff --git a/include/block/block.h b/include/block/block.h
index ffd1936..85eb3d9 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -213,6 +213,7 @@ typedef struct BdrvCheckResult {
 int check_errors;
 int corruptions_fixed;
 int leaks_fixed;
+int64_t image_end_offset;
 BlockFragInfo bfi;
 } BdrvCheckResult;
 
diff --git a/qemu-img.c b/qemu-img.c
index 85d3740..e80c1c5 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -475,6 +475,10 @@ static int img_check(int argc, char **argv)
 result.bfi.fragmented_clusters * 100.0 / 
result.bfi.allocated_clusters);
 }
 
+if (result.image_end_offset > 0) {
+printf("Image end offset: %" PRId64 "\n", result.image_end_offset);
+}
+
 bdrv_delete(bs);
 
 if (ret < 0 || result.check_errors) {
diff --git a/tests/qemu-iotests/026 b/tests/qemu-iotests/026
index 1602ccd..107a3ff 100755
--- a/tests/qemu-iotests/026
+++ b/tests/qemu-iotests/026
@@ -102,7 +102,7 @@ if [ "$event" == "l2_load" ]; then
 $QEMU_IO -c "read $vmstate 0 128k " $BLKDBG_TEST_IMG | _filter_qemu_io
 fi
 
-$QEMU_IMG check $TEST_IMG 2>&1 | grep -v "refcount=1 reference=0"
+_check_test_img 2>&1 | grep -v "refcount=1 reference=0"
 
 done
 done
@@ -147,7 +147,7 @@ echo
 echo "Event: $event; errno: $errno; imm: $imm; once: $once; write $vmstate"
 $QEMU_IO -c "write $vmstate 0 64M" $BLKDBG_TEST_IMG | _filter_qemu_io
 
-$QEMU_IMG check $TEST_IMG 2>&1 | grep -v "refcount=1 reference=0"
+_check_test_img 2>&1 | grep -v "refcount=1 reference=0"
 
 done
 done
@@ -186,7 +186,7 @@ echo
 echo "Event: $event; errno: $errno; imm: $imm; once: $once"
 $QEMU_IO -c "write -b 0 64k" $BLKDBG_TEST_IMG | _filter_qemu_io
 
-$QEMU_IMG check $TEST_IMG 2>&1 | grep -v "refcount=1 reference=0"
+_check_test_img 2>&1 | grep -v "refcount=1 reference=0"
 
 done
 done
diff --git a/tests/qemu-iotests/036 b/tests/qemu-iotests/036
index 329533e..4dbfc57 100755
--- a/tests/qemu-iotests/036
+++ b/tests/qemu-iotests/036
@@ -59,7 +59,8 @@ _make_test_img 64M
 echo
 echo === Repair image ===
 echo
-$QEMU_IMG check -r all $TEST_IMG
+_check_test_img -r all
+
 ./qcow2.py $TEST_IMG dump-header
 
 # success, all done
diff --git a/tests/qemu-iotests/039 b/tests/qemu-iotests/039
index c5ae806..ae35175 100755
--- a/tests/qemu-iotests/039
+++ b/tests/qemu-iotests/039
@@ -86,7 +86,7 @@ $QEMU_IO -r -c "read -P 0x5a 0 512" $TEST_IMG | 
_filter_qemu_io
 echo
 echo "== Repairing the image file must succeed =="
 
-$QEMU_IMG check -r all $TEST_IMG
+_check_test_img -r all
 
 # The dirty bit must not be set
 ./qcow2.py $TEST_IMG dump-header | grep incompatible_features
diff --git a/tests/qemu-iotests/044.out b/tests/qemu-iotests/044.out
index 7a40071..9c48673 100644
--- a/tests/qemu-iotests/044.out
+++ b/tests/qemu-iotests/044.out
@@ -1,4 +1,5 @@
 No errors were found on the image.
+Image end offset: 4296447488
 .
 --

Re: [Qemu-devel] [PATCH for-1.4] block/raw-posix: Build fix for O_ASYNC

[Stefan Hajnoczi]

On Mon, Jan 28, 2013 at 10:47:28AM +0100, Paolo Bonzini wrote:
> Il 26/01/2013 14:38, Andreas Färber ha scritto:
> > Commit eeb6b45d48800e96f67ef2a5c80332557fd45ddb (block: raw-posix image
> > file reopen) broke the build on OpenIndiana.
> > 
> > illumos has no O_ASYNC. Exclude it from flags to be compared and
> > use I_SETSIG ioctl after newly opening file.
> > 
> > Cf. e61ab1da7e98357da47c54d8f893b9bd6ff2f7f9 for qemu-ga.
> > 
> > Cc: qemu-sta...@nongnu.org (1.3.x)
> > Cc: Jeff Cody 
> > Signed-off-by: Andreas Färber 
> > ---
> >  block/raw-posix.c |   14 +-
> >  1 Datei geändert, 13 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
> > 
> > diff --git a/block/raw-posix.c b/block/raw-posix.c
> > index 657af95..336c938 100644
> > --- a/block/raw-posix.c
> > +++ b/block/raw-posix.c
> > @@ -46,6 +46,7 @@
> >  #ifdef __sun__
> >  #define _POSIX_PTHREAD_SEMANTICS 1
> >  #include 
> > +#include 
> >  #endif
> >  #ifdef __linux__
> >  #include 
> > @@ -345,7 +346,10 @@ static int raw_reopen_prepare(BDRVReopenState *state,
> >  
> >  raw_s->fd = -1;
> >  
> > -int fcntl_flags = O_APPEND | O_ASYNC | O_NONBLOCK;
> > +int fcntl_flags = O_APPEND | O_NONBLOCK;
> > +#ifndef CONFIG_SOLARIS
> > +fcntl_flags |= O_ASYNC;
> > +#endif
> >  #ifdef O_NOATIME
> >  fcntl_flags |= O_NOATIME;
> >  #endif
> > @@ -376,6 +380,14 @@ static int raw_reopen_prepare(BDRVReopenState *state,
> >  raw_s->fd = qemu_open(state->bs->filename, raw_s->open_flags);
> >  if (raw_s->fd == -1) {
> >  ret = -1;
> > +} else {
> > +#ifdef CONFIG_SOLARIS
> > +ret = ioctl(raw_s->fd, I_SETSIG, S_OUTPUT | S_INPUT | S_HIPRI);
> > +if (ret == -1) {
> > +qemu_close(raw_s->fd);
> > +raw_s->fd = -1;
> > +}
> > +#endif
> 
> The flag is not set unconditionally.  It is only set if it was in
> s->open_flags, and it should never be.
> 
> I would just add an
> 
> #ifdef O_ASYNC
> /* Not all operating systems have O_ASYNC, and those that don't
>  * will not let us track the state into raw_s->open_flags (typically
>  * you achieve the same effect with an ioctl, for example I_SETSIG
>  * on Solaris).  But we do not use O_ASYNC, so that's fine.
>  */
> assert((s->open_flags & O_ASYNC) == 0);
> #endif

Good point.

Andreas: Do you want to send a new patch?

Stefan

Re: [Qemu-devel] [PATCH for-1.4] block/raw-posix: Build fix for O_ASYNC

[Andreas Färber]

Am 28.01.2013 13:27, schrieb Stefan Hajnoczi:
> On Mon, Jan 28, 2013 at 10:47:28AM +0100, Paolo Bonzini wrote:
>> Il 26/01/2013 14:38, Andreas Färber ha scritto:
>>> Commit eeb6b45d48800e96f67ef2a5c80332557fd45ddb (block: raw-posix image
>>> file reopen) broke the build on OpenIndiana.
>>>
>>> illumos has no O_ASYNC. Exclude it from flags to be compared and
>>> use I_SETSIG ioctl after newly opening file.
>>>
>>> Cf. e61ab1da7e98357da47c54d8f893b9bd6ff2f7f9 for qemu-ga.
>>>
>>> Cc: qemu-sta...@nongnu.org (1.3.x)
>>> Cc: Jeff Cody 
>>> Signed-off-by: Andreas Färber 
>>> ---
>>>  block/raw-posix.c |   14 +-
>>>  1 Datei geändert, 13 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
>>>
>>> diff --git a/block/raw-posix.c b/block/raw-posix.c
>>> index 657af95..336c938 100644
>>> --- a/block/raw-posix.c
>>> +++ b/block/raw-posix.c
>>> @@ -46,6 +46,7 @@
>>>  #ifdef __sun__
>>>  #define _POSIX_PTHREAD_SEMANTICS 1
>>>  #include 
>>> +#include 
>>>  #endif
>>>  #ifdef __linux__
>>>  #include 
>>> @@ -345,7 +346,10 @@ static int raw_reopen_prepare(BDRVReopenState *state,
>>>  
>>>  raw_s->fd = -1;
>>>  
>>> -int fcntl_flags = O_APPEND | O_ASYNC | O_NONBLOCK;
>>> +int fcntl_flags = O_APPEND | O_NONBLOCK;
>>> +#ifndef CONFIG_SOLARIS
>>> +fcntl_flags |= O_ASYNC;
>>> +#endif
>>>  #ifdef O_NOATIME
>>>  fcntl_flags |= O_NOATIME;
>>>  #endif
>>> @@ -376,6 +380,14 @@ static int raw_reopen_prepare(BDRVReopenState *state,
>>>  raw_s->fd = qemu_open(state->bs->filename, raw_s->open_flags);
>>>  if (raw_s->fd == -1) {
>>>  ret = -1;
>>> +} else {
>>> +#ifdef CONFIG_SOLARIS
>>> +ret = ioctl(raw_s->fd, I_SETSIG, S_OUTPUT | S_INPUT | S_HIPRI);
>>> +if (ret == -1) {
>>> +qemu_close(raw_s->fd);
>>> +raw_s->fd = -1;
>>> +}
>>> +#endif
>>
>> The flag is not set unconditionally.  It is only set if it was in
>> s->open_flags, and it should never be.
>>
>> I would just add an
>>
>> #ifdef O_ASYNC
>> /* Not all operating systems have O_ASYNC, and those that don't
>>  * will not let us track the state into raw_s->open_flags (typically
>>  * you achieve the same effect with an ioctl, for example I_SETSIG
>>  * on Solaris).  But we do not use O_ASYNC, so that's fine.
>>  */
>> assert((s->open_flags & O_ASYNC) == 0);
>> #endif
> 
> Good point.
> 
> Andreas: Do you want to send a new patch?

Yes, please unqueue it, I see that the last hunk is wrong. I won't get
to it immediately though and will have to digest the above suggestion.

Andreas

Re: [Qemu-devel] buildbot failure in qemu on default_x86_64_rhel61

[Luiz Capitulino]

On Sat, 26 Jan 2013 23:25:11 +0100
q...@buildbot.b1-systems.de wrote:

> The Buildbot has detected a new failure on builder default_x86_64_rhel61 
> while building qemu.
> Full details are available at:
>  http://buildbot.b1-systems.de/qemu/builders/default_x86_64_rhel61/builds/509
> 
> Buildbot URL: http://buildbot.b1-systems.de/qemu/
> 
> Buildslave for this Build: kraxel_rhel61
> 
> Build Reason: The Nightly scheduler named 'nightly_default' triggered this 
> build
> Build Source Stamp: [branch master] HEAD
> Blamelist: 
> 
> BUILD FAILED: failed test

  CCtests/test-string-input-visitor.o
  LINK  tests/test-string-input-visitor
GTESTER tests/test-string-input-visitor
GTester: last random seed: R02S5d812c81f012364176697419b43c9bdd
make: *** [check-tests/test-string-input-visitor] Error 1
program finished with exit code 2
elapsedTime=6.389880

gtester bug, maybe? I can't reproduce it here.

Re: [Qemu-devel] [PULL 00/15] s390 patch queue 2013-01-25

[Alexander Graf]

On 01/28/2013 11:06 AM, Cornelia Huck wrote:

On Sat, 26 Jan 2013 14:17:36 +
Blue Swirl  wrote:


On Fri, Jan 25, 2013 at 12:48 PM, Alexander Graf  wrote:

Hi Blue / Aurelien,

This is my current patch queue for s390.  Please pull.

Alex


The following changes since commit 11c29918be32be5b00f367c7da9724a5cddbbb0f:
   Anthony Liguori (1):
 Merge remote-tracking branch 'bonzini/scsi-next' into staging

are available in the git repository at:

   git://repo.or.cz/qemu/agraf.git s390-for-upstream

Alexander Graf (3):
   s390: Add default support for SCLP console
   s390: Make typeinfo const
   s390: Move hw files to hw/s390x

Andreas Färber (1):
   s390-virtio: Check for NULL device in reset hypercall

Cornelia Huck (10):
   s390: Lowcore mapping helper.
   s390: Add mapping helper functions.
   s390: Channel I/O basic definitions.
   s390: I/O interrupt and machine check injection.
   s390: Add channel I/O instructions.
   s390: Virtual channel subsystem support.

This would break build on mingw32:
   CCs390x-softmmu/hw/s390x/css.o
/src/qemu/hw/s390x/css.c: In function 'css_interpret_ccw':
/src/qemu/hw/s390x/css.c:226:17: error: 'ERESTART' undeclared (first
use in this function)
/src/qemu/hw/s390x/css.c:226:17: note: each undeclared identifier is
reported only once for each function it appears in
/src/qemu/hw/s390x/css.c:294:20: error: 'EOPNOTSUPP' undeclared (first
use in this function)
/src/qemu/hw/s390x/css.c: In function 'sch_handle_start_func':
/src/qemu/hw/s390x/css.c:350:15: error: 'EOPNOTSUPP' undeclared (first
use in this function)
/src/qemu/hw/s390x/css.c:375:15: error: 'ERESTART' undeclared (first
use in this function)

That's unfortunate :(

Are there some kinds of compatibility headers that define the missing
error codes, or does something need to be fenced off here?

I would appreciate it if somebody could give me a hand here, especially
as I don't have a mingw32 environment around...


Stefan, could you please help out?


Alex

Re: [Qemu-devel] [PATCH 06/15] s390: Add channel I/O instructions.

[Alexander Graf]

On 01/28/2013 10:59 AM, Cornelia Huck wrote:

On Fri, 25 Jan 2013 20:28:31 +0100
Alexander Graf  wrote:


However, I do agree that this duplicates logic. Cornelia, mind to instead call 
our map helper in css_do_tpi?

Well, ioinst_handle_tpi() looks like the better place to do this.

Can you put this into the series, or should I re-send?

 From a8064d80759e30662b0ac41643a29b41e9015a3f Mon Sep 17 00:00:00 2001
From: Cornelia Huck
Date: Mon, 28 Jan 2013 10:42:44 +0100
Subject: [PATCH] s390: Use s390_cpu_physical_memory_map for tpi.

Map the I/O interruption code before calling into css.

Signed-off-by: Cornelia Huck


Thanks, applied to s390-next.

Alex

Re: [Qemu-devel] [PATCH v2 0/6] bdrv_open() error return fixes

[Markus Armbruster]

You addressed all my comments.

Reviewed-by: Markus Armbruster 

Re: [Qemu-devel] [RFC] qemu snapshot enchancement

[Stefan Hajnoczi]

On Fri, Jan 25, 2013 at 09:34:28AM +, Dietmar Maurer wrote:
> > > Note: The proposed backup patches (already sent to the list) make
> > > backups without creating internal/external snapshot. Consistency is
> > guaranteed by using COW.
> > >
> >I guess this can be implemented, or may already exist in 3rd party
> > components, such as LVM2. 
> 
> We used LVM to provide snapshots for backups for more than 4 years now.
> (in production at many customer sites).
> 
> It is a constant PITA. If interested, you can grab our support forum about 
> problems
> with LVM snapshots (http://forum.proxmox.com).
> 
> The new backup approach is much better an avoids most of the problems we had.
> (the backup patches contains a list of advantages).

Hi Dietmar,
If you've been using it for 4 years then it was without dm-thin, which
is a new snapshot mechanism that solves limitations of classic LVM
snapshot volumes.  So if you're referring to inefficient LVM snapshots
then that should be solvable now.

Or is LVM a pain for other reasons?

Stefan

Re: [Qemu-devel] [PATCH v2 2/5] block: Use error code EMEDIUMTYPE for wrong format in some block drivers

[Markus Armbruster]

Stefan Weil  writes:

> Kevin, Stefan, maybe you can take patches 1, 3, 4 and 5 from
> this series, so I don't have to resend them.
>
> I'll split patch 2 in order to realize Markus' suggestion.
> Or you take it as it is, resulting in half-broken (instead of
> full broken) xxx_open functions, and patches which fix the
> remaining half can be applied on top.

FYI, Kevin applied them all, and cleaned up the mess on top ([PATCH v2
0/6] bdrv_open() error return fixes).

Re: [Qemu-devel] [PATCH v2] target-arm: add Faraday ARMv5TE processors support

[Peter Maydell]

On 25 January 2013 07:18, Kuo-Jung Su  wrote:
> +static const ARMCPRegInfo faraday_cp_reginfo[] = {
> +/*
> + * Auxiliary Control Register
> + * - Bit 4 STM aligned transfer for AXI
> + * - Bit 3 Cache allocation configuration enable
> + * - Bit 2 Static branch prediction enable
> + * - Bit 1 Dynamic branch prediction enable
> + * - Bit 0 Return stack enable
> + */
> +{ .name = "AUXCTR", .cp = 15, .crn = 1, .crm = 0,
> +  .opc1 = 0, .opc2 = 1, .access = PL1_RW, .resetvalue = 0x7,
> +  .fieldoffset = offsetof(CPUARMState, cp15.c15_aux_control) },

This is just an AUXCR in the usual encoding for one;
you should use ARM_FEATURE_AUXCR (and set cpu->reset_auxcr
in the cpu initfns).

> +/*
> + * I/D-Scratchpad Configuration Register
> + * - Bits[31:10] Scratchpad base address
> + * - Bits[5:2]   Scratchpad size
> + * - Bit 1   Scratchpad self-loading capability
> + * - Bit 0   Scratchpad enable
> + */
> +{ .name = "IDSCFG", .cp = 15, .crn = 9, .crm = 1,
> +  .opc1 = 0, .opc2 = CP_ANY, .access = PL1_RW, .resetvalue = 0x0,
> +  .fieldoffset = offsetof(CPUARMState, cp15.c15_ids_config) },

Looking at the documentation you've provided, this encoding
doesn't seem to be used on the FA606TE.

It only seems to be a scratchpad register for the FA626TE.
For the FA616TE and FA726TE it is a TCM config register,
and for the FA606TE it doesn't exist at all. (Possibly
the "scratchpad" on the 626 is actually a TCM under another
name; I didn't look too closely but there seems to be some
similarity...)

The 726TE datasheet also talks about a c9, c1, 0, 1 encoding
for the data TCM config (with c9, c1, 0, 0 being the insn TCM
config). This doesn't fit with a CP_ANY value for opc2.
It also sounds pretty much like the TCM registers for the
ARM926, ARM946 and ARM1026, for instance.

I think you need to check to what extent these registers
are different between the four cores you're trying to
implement, and whether any of them match up with TCM
implementations in the standard ARM cores. Where there's
a register set shared between ARM and Faraday implementations
that probably should have an ARM_FEATURE_TCM flag.

Also you should double check which if any cores really
have a CP_ANY wildcard decode for opc2: I don't want
us to underdecode unless we know the hardware really
underdecodes [ie that working guest code fails unless
we use CP_ANY]. (Some existing code in qemu uses CP_ANY
because we have historically done that and don't have
easy ability to check it won't break currently working
guests; I would prefer us not to let in new examples
without scrutiny, though.)

thanks
-- PMM

Re: [Qemu-devel] [PATCH 0/5] vhost-scsi: Add support for host virtualized target

[Paolo Bonzini]

Il 21/01/2013 09:50, Michael S. Tsirkin ha scritto:
>> Unfortunately, I've not been able to get back to the conversion
>> requested by Paolo for a standalone vhost-scsi PCI device.
> 
> It doesn't have to be a standalone device. A vhost=on frontend
> option is also OK I think. Paolo, any objections?

Sorry, I missed this message.

I asked for a standalone device because the configuration mechanism
(configfs vs. command-line) and the feature set are completely
different.  Unlike virtio-net, it's not possible to switch one to the
other at run time.

Paolo

Re: [Qemu-devel] [PATCH 0/5] vhost-scsi: Add support for host virtualized target

[Michael S. Tsirkin]

On Mon, Jan 28, 2013 at 02:01:41PM +0100, Paolo Bonzini wrote:
> Il 21/01/2013 09:50, Michael S. Tsirkin ha scritto:
> >> Unfortunately, I've not been able to get back to the conversion
> >> requested by Paolo for a standalone vhost-scsi PCI device.
> > 
> > It doesn't have to be a standalone device. A vhost=on frontend
> > option is also OK I think. Paolo, any objections?
> 
> Sorry, I missed this message.
> 
> I asked for a standalone device because the configuration mechanism
> (configfs vs. command-line) and the feature set are completely
> different.  Unlike virtio-net, it's not possible to switch one to the
> other at run time.
> 
> Paolo

Exactly the same applies to any other frontend option.
For example if you have two qemu instances with
different num_queues values you can not migrate one
to the other.
So in this sense it is not different from any other
frontend option, right?

-- 
MST

Re: [Qemu-devel] [RFC] Writeable files in fw_cfg

[David Woodhouse]

On Sun, 2013-01-27 at 18:53 -0600, Anthony Liguori wrote:
> Are you just trying to persist a single blob of a fixed maximum size?

That would suffice.

> Why not just have a second flash device then?

Mostly because flash devices don't actually *work* with KVM.

Should I be looking at fixing *that*, instead?

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature

Re: [Qemu-devel] [PATCH][TRIVIAL] vl: coding style cleanups

[Stefan Hajnoczi]

On Thu, Jan 24, 2013 at 05:04:29PM -0600, Jesse Larrew wrote:
> 
> Reformat the option parsing code in main() and various supporting functions
> to conform to the QEMU coding style.
> 
> Signed-off-by: Jesse Larrew 
> ---
>  vl.c | 476 
> +--
>  1 file changed, 260 insertions(+), 216 deletions(-)

Please CC qemu-triv...@nongnu.org on trivial patches in the future.

There has been discussion about whitespace cleanups recently and it also
applies to this patch.  There is a cost to such patches - they require
code review, can clog up the git-blame(1) output, and make it hard for
stable branch or downstream maintainers to backport fixes.

I'm happy to take this patch but I hope people don't get too
trigger-happy because this isn't free.

Waiting a while longer to merge in case Blue Swirl or anyone else wants
to chime in.

Stefan

Re: [Qemu-devel] [RFC] qemu snapshot enchancement

[Stefan Hajnoczi]

On Fri, Jan 25, 2013 at 05:16:46PM +0800, Wenchao Xia wrote:
> 于 2013-1-24 17:47, Stefan Hajnoczi 写道:
> >
> >>>Case 3:
> >>>
> >>>  * What does "blank data" mean?  Besides that the use case
> >>>makes sense.
> >>>
> >>   Will remove the words.
> >>
> >>>  * When discussing this use case in the past it was suggested that the
> >>>guest doesn't need to be paused during the LVM snapshot.  Instead the
> >>>QEMU block layer might be able to queue I/O requests, allowing the
> >>>guest to run.
> >>>
> >>   That is a good idea, but seems need more work(event, block layer...),
> >>hope it can be added as an enchancement of this case. Now let the
> >>dedicated storage software/hardware take the job by pausing for a while
> >>(<200ms?)
> >
> >Yes, allowing the guest to continue but queuing I/O will require extra
> >block layer work and maybe a QMP command.  There is a also a risk: if
> >the snapshot takes too long to complete, the guest may notice that its
> >I/O request are taking a long time.  It may decide that they have timed
> >out and report an error to the application or in the message logs.
> >
> >In the beginning it's easier to pause the VM but let's keep queuing I/O
> >in mind so it can be added later, if necessary.
> >
>   Yep, the code should leave a room for queuing.
> 
>   I have updated the wiki, which added the step details of the cases
> . Cases 3 are fixed, which have best performance in qemu management
> type. But I am not sure if it is workable in theory to export base
> data of an qcow2 image having internal snapshot, what do you think
> of it?

Yes, it is theoretically possible to access snapshot data while the
guest is running.

Open the qcow2 read-only and use bdrv_snapshot_load_tmp() to activate
the snapshot without modifying the qcow2 file on disk.  This is pretty
easy to implement today by adding options to qemu-nbd or the in-process
NBD server QMP commands.

Stefan

Re: [Qemu-devel] [ANNOUNCE] checkpatch and git-am bots

[Anthony Liguori]

Andreas Färber  writes:

> Am 21.01.2013 19:45, schrieb Anthony Liguori:
>> I've published the code for patches although I've not announced it yet.
>> I'm still making some CLI changes but hope to do a proper announcement
>> in the next week or so.
>> 
>> http://github.com/aliguori/patches.git
>> 
>> If anyone wants to try it out, let me know, and I would be happy to
>> answer questions/help you set it up.
>
> $ patches fetch http://wiki.qemu.org/patches/patches.json

Sorry, that's a bug.  There's an implicit mode where you put the JSON
file location in ~/.patchesrc and that's what I've been using recently.

I pushed a fix so the explicit URL syntax works again.

Regards,

Anthony Liguori

> Traceback (most recent call last):
>   File "/usr/local/bin/patches", line 140, in 
> sys.exit(main(sys.argv[1:]))
>   File "/usr/local/bin/patches", line 136, in main
> return args.func(args)
>   File "/usr/local/bin/patches", line 31, in do_fetch
> return fetch.main(args)
>   File "/usr/local/lib/python2.7/site-packages/patchlib/fetch.py", line
> 22, in main
> fetch(args.url[0])
>   File "/usr/local/lib/python2.7/site-packages/patchlib/fetch.py", line
> 36, in fetch
> fp = urlopen(url)
>   File "/usr/lib64/python2.7/urllib2.py", line 126, in urlopen
> return _opener.open(url, data, timeout)
>   File "/usr/lib64/python2.7/urllib2.py", line 392, in open
> protocol = req.get_type()
>   File "/usr/lib64/python2.7/urllib2.py", line 254, in get_type
> raise ValueError, "unknown url type: %s" % self.__original
> ValueError: unknown url type: h
>
> Am I missing some Python dependency? I can access the URL from my browser.
>
> Regards,
> 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] [RFC qom-cpu v2 00/28] CPUState QOM realizefn support

[Andreas Färber]

Am 20.01.2013 08:22, schrieb Andreas Färber:
> Andreas Färber (28):
>   cpu: Prepare QOM realizefn
>   target-alpha: Update AlphaCPU to QOM realizefn
>   target-arm: Update ARMCPU to QOM realizefn
>   target-i386: Update X86CPU to QOM realizefn
>   target-openrisc: Update OpenRISCCPU to QOM realizefn
>   target-ppc: Update PowerPCCPU to QOM realizefn
>   target-cris: Introduce QOM realizefn for CRISCPU
>   target-lm32: Introduce QOM realizefn for LM32CPU
>   target-m68k: Introduce QOM realizefn for M68kCPU
>   target-microblaze: Introduce QOM realizefn for MicroBlazeCPU
>   target-mips: Introduce QOM realizefn for MIPSCPU
>   target-s390x: Introduce QOM realizefn for S390CPU
>   target-sh4: Introduce QOM realizefn for SuperHCPU
>   target-sparc: Introduce QOM realizefn for SPARCCPU
>   target-unicore32: Introduce QOM realizefn for UniCore32CPU
>   target-xtensa: Introduce QOM realizefn for XtensaCPU
>   target-arm: Move TCG initialization to ARMCPU initfn
>   target-cris: Move TCG initialization to CRISCPU initfn
>   target-lm32: Move TCG initialization to LM32CPU initfn
>   target-m68k: Move TCG initialization to M68kCPU initfn
>   target-microblaze: Move TCG initialization to MicroBlazeCPU initfn
>   target-mips: Move TCG initialization to MIPSCPU initfn
>   target-ppc: Move TCG initialization to PowerPCCPU initfn
>   target-s390x: Move TCG initialization to S390CPU initfn
>   target-sh4: Move TCG initialization to SuperHCPU initfn
>   target-sparc: Move TCG initialization to SPARCCPU initfn
>   target-unicore32: Move TCG initialization to UniCore32CPU initfn
>   target-xtensa: Move TCG initialization to XtensaCPU initfn

Rebased and applied these to qom-cpu-next:
https://github.com/afaerber/qemu-cpu/commits/qom-cpu-next
git://github.com/afaerber/qemu-cpu.git qom-cpu-next

This is my queue for the 1.5 merge window, so if you want to ack or
found bugs, let me know before Feb 15 [1].
All CPU series for 1.5 touching on cpu_init() or main class_init should
be based on that tree please. It rebases on qom-cpu and/or qemu.git.

Regards,
Andreas

[1] http://wiki.qemu.org/Planning/1.4

-- 
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] [RFC V7 02/13] quorum: Create BDRVQuorumState and BlkDriver and do init.

[Benoît Canet]

Signed-off-by: Benoit Canet 
---
 block/quorum.c |   22 ++
 1 file changed, 22 insertions(+)

diff --git a/block/quorum.c b/block/quorum.c
index ce094a1..0524b63 100644
--- a/block/quorum.c
+++ b/block/quorum.c
@@ -15,6 +15,13 @@
 
 #include "block/block_int.h"
 
+typedef struct {
+BlockDriverState **bs;
+unsigned long long threshold;
+unsigned long long total;
+char **filenames;
+} BDRVQuorumState;
+
 typedef struct QuorumAIOCB QuorumAIOCB;
 
 typedef struct QuorumSingleAIOCB {
@@ -26,6 +33,7 @@ typedef struct QuorumSingleAIOCB {
 
 struct QuorumAIOCB {
 BlockDriverAIOCB common;
+BDRVQuorumState *bqs;
 QEMUBH *bh;
 
 /* Request metadata */
@@ -43,3 +51,17 @@ struct QuorumAIOCB {
 void (*vote)(QuorumAIOCB *acb);
 int vote_ret;
 };
+
+static BlockDriver bdrv_quorum = {
+.format_name= "quorum",
+.protocol_name  = "quorum",
+
+.instance_size  = sizeof(BDRVQuorumState),
+};
+
+static void bdrv_quorum_init(void)
+{
+bdrv_register(&bdrv_quorum);
+}
+
+block_init(bdrv_quorum_init);
-- 
1.7.10.4

[Qemu-devel] [RFC V7 03/13] quorum: Add quorum_aio_writev and its dependencies.

[Benoît Canet]

Signed-off-by: Benoit Canet 
---
 block/quorum.c |  113 
 1 file changed, 113 insertions(+)

diff --git a/block/quorum.c b/block/quorum.c
index 0524b63..8fa79db 100644
--- a/block/quorum.c
+++ b/block/quorum.c
@@ -52,11 +52,124 @@ struct QuorumAIOCB {
 int vote_ret;
 };
 
+static void quorum_aio_cancel(BlockDriverAIOCB *blockacb)
+{
+QuorumAIOCB *acb = container_of(blockacb, QuorumAIOCB, common);
+bool finished = false;
+
+/* Wait for the request to finish */
+acb->finished = &finished;
+while (!finished) {
+qemu_aio_wait();
+}
+}
+
+static AIOCBInfo quorum_aiocb_info = {
+.aiocb_size = sizeof(QuorumAIOCB),
+.cancel = quorum_aio_cancel,
+};
+
+static void quorum_aio_bh(void *opaque)
+{
+QuorumAIOCB *acb = opaque;
+BDRVQuorumState *s = acb->bqs;
+int ret;
+
+ret = s->threshold <= acb->success_count ? 0 : -EIO;
+
+qemu_bh_delete(acb->bh);
+acb->common.cb(acb->common.opaque, ret);
+if (acb->finished) {
+*acb->finished = true;
+}
+g_free(acb->aios);
+g_free(acb->qiovs);
+qemu_aio_release(acb);
+}
+
+static QuorumAIOCB *quorum_aio_get(BDRVQuorumState *s,
+   BlockDriverState *bs,
+   QEMUIOVector *qiov,
+   uint64_t sector_num,
+   int nb_sectors,
+   BlockDriverCompletionFunc *cb,
+   void *opaque)
+{
+QuorumAIOCB *acb = qemu_aio_get(&quorum_aiocb_info, bs, cb, opaque);
+int i;
+
+acb->aios = g_new0(QuorumSingleAIOCB, s->total);
+acb->qiovs = g_new0(QEMUIOVector, s->total);
+
+acb->bqs = s;
+acb->qiov = qiov;
+acb->bh = NULL;
+acb->count = 0;
+acb->success_count = 0;
+acb->sector_num = sector_num;
+acb->nb_sectors = nb_sectors;
+acb->vote = NULL;
+acb->vote_ret = 0;
+acb->finished = NULL;
+
+for (i = 0; i < s->total; i++) {
+acb->aios[i].buf = NULL;
+acb->aios[i].ret = 0;
+acb->aios[i].parent = acb;
+}
+
+return acb;
+}
+
+static void quorum_aio_cb(void *opaque, int ret)
+{
+QuorumSingleAIOCB *sacb = opaque;
+QuorumAIOCB *acb = sacb->parent;
+BDRVQuorumState *s = acb->bqs;
+
+sacb->ret = ret;
+acb->count++;
+if (ret == 0) {
+acb->success_count++;
+}
+assert(acb->count <= s->total);
+assert(acb->success_count <= s->total);
+if (acb->count < s->total) {
+return;
+}
+
+acb->bh = qemu_bh_new(quorum_aio_bh, acb);
+qemu_bh_schedule(acb->bh);
+}
+
+static BlockDriverAIOCB *quorum_aio_writev(BlockDriverState *bs,
+  int64_t sector_num,
+  QEMUIOVector *qiov,
+  int nb_sectors,
+  BlockDriverCompletionFunc *cb,
+  void *opaque)
+{
+BDRVQuorumState *s = bs->opaque;
+QuorumAIOCB *acb = quorum_aio_get(s, bs, qiov, sector_num, nb_sectors,
+  cb, opaque);
+int i;
+
+for (i = 0; i < s->total; i++) {
+acb->aios[i].aiocb = bdrv_aio_writev(s->bs[i], sector_num, qiov,
+ nb_sectors, &quorum_aio_cb,
+ &acb->aios[i]);
+}
+
+return &acb->common;
+}
+
 static BlockDriver bdrv_quorum = {
 .format_name= "quorum",
 .protocol_name  = "quorum",
 
 .instance_size  = sizeof(BDRVQuorumState),
+
+.bdrv_aio_writev= quorum_aio_writev,
 };
 
 static void bdrv_quorum_init(void)
-- 
1.7.10.4

[Qemu-devel] [RFC V7 00/13] Quorum block filter

[Benoît Canet]

This patchset is rebased on top of "cutils: unsigned int parsing functions"
by "Eduardo Habkost".

It must be applied on top of "Pave the way for protocol snapshot creation"

This patchset create a block driver implementing a quorum using total qemu disk
images. Writes are mirrored on the $total files.
For the reading part the $total files are read at the same time and a vote is
done to determine if a qiov version is present $threshold or more times. It then
return this majority version to the upper layers.
When i < $threshold versions of the data are returned by the lower layer the
quorum is broken and the read return -EIO.

The goal of this patchset is to be turned in a QEMU block filter living just
above raw-*.c and below qcow2/qed when the required infrastructure will be done.

Main use of this feature will be people using NFS appliances which can be
subjected to bitflip errors.

This patchset can be used to replace blkverify and the out of tree blkmirror.

usage: -drive
file=quorum:threshold/total:image_1.raw:...:image_total.raw,if=virtio,cache=none

in this version:
Allow creation of snapshots
Extract utility functions of quorum_open and quorum_close
reorder patches so quorum_open and quorum_close are added last

v7:
parse total and threshold with parse_uint [Eric]
return proper qerrors in quorum_open [Eric]
Use sha256 for comparing blocks [Eric]
Update the rest of the voting function to the new way of doing [Benoît]

V6:
fix commit message of "quorum: Add quorum_open() and quorum_close()." [Eric]
return error after a vote in quorum_co_flush [Eric]
Fix bitrot caused by headers and structures renaming [Benoît]
initialize finished to NULL to prevent crash [Benoît]
convert internal quorum code to uint64_t instead of int64_t [Benoît]

V5:

Eric Blake: revert back separator to ":"
rewrite quorum_getlength

Benoît Canet: use memcmp to compare iovec excepted for the blkverify case
  use strstart to parse argument in open

Benoît Canet (13):
  quorum: Create quorum.c, add QuorumSingleAIOCB and QuorumAIOCB.
  quorum: Create BDRVQuorumState and BlkDriver and do init.
  quorum: Add quorum_aio_writev and its dependencies.
  blkverify: Extract qemu_iovec_clone() and qemu_iovec_compare() from
blkverify.
  quorum: Add quorum_aio_readv.
  quorum: Add quorum mechanism.
  quorum: Add quorum_getlength().
  quorum: Add quorum_invalidate_cache().
  quorum: Add quorum_co_is_allocated.
  quorum: Add quorum_co_flush().
  quorum: Add quorum_snapshot_img_create.
  quorum: Add quorum_snapshot_reopen.
  quorum: Add quorum_open() and quorum_close().

 block/Makefile.objs   |1 +
 block/blkverify.c |  108 +-
 block/quorum.c|  908 +
 configure |   22 ++
 include/qemu-common.h |2 +
 util/iov.c|  103 ++
 6 files changed, 1038 insertions(+), 106 deletions(-)
 create mode 100644 block/quorum.c

-- 
1.7.10.4

[Qemu-devel] [RFC V7 10/13] quorum: Add quorum_co_flush().

[Benoît Canet]

Makes a vote to select error if any.

Signed-off-by: Benoit Canet 
---
 block/quorum.c |   34 ++
 1 file changed, 34 insertions(+)

diff --git a/block/quorum.c b/block/quorum.c
index ed97a76..ee6bc45 100644
--- a/block/quorum.c
+++ b/block/quorum.c
@@ -579,12 +579,46 @@ static int coroutine_fn 
quorum_co_is_allocated(BlockDriverState *bs,
 return result;
 }
 
+static coroutine_fn int quorum_co_flush(BlockDriverState *bs)
+{
+BDRVQuorumState *s = bs->opaque;
+QuorumVoteVersion *winner = NULL;
+QuorumVotes error_votes;
+QuorumVoteValue result_value;
+int i;
+int result = 0;
+bool error = false;
+
+QLIST_INIT(&error_votes.vote_list);
+error_votes.compare = quorum_long_compare;
+
+for (i = 0; i < s->total; i++) {
+result = bdrv_co_flush(s->bs[i]);
+if (result) {
+error = true;
+result_value.l = result;
+quorum_count_vote(&error_votes, &result_value, i);
+}
+}
+
+if (error) {
+winner = quorum_get_vote_winner(&error_votes);
+result = winner->value.l;
+}
+
+quorum_free_vote_list(&error_votes);
+
+return result;
+}
+
 static BlockDriver bdrv_quorum = {
 .format_name= "quorum",
 .protocol_name  = "quorum",
 
 .instance_size  = sizeof(BDRVQuorumState),
 
+.bdrv_co_flush_to_disk = quorum_co_flush,
+
 .bdrv_getlength = quorum_getlength,
 
 .bdrv_aio_readv = quorum_aio_readv,
-- 
1.7.10.4

[Qemu-devel] [RFC V7 13/13] quorum: Add quorum_open() and quorum_close().

[Benoît Canet]

Valid quorum resources look like
quorum:threshold/total:path/to/image_1: ... :path/to/image_total

':' is used as a separator
'\' is the escaping character for filename containing ':'
'\' escape itself
',' must be escaped with ','

On the command line for quorum files "img:test.raw", "img2,raw"
and "img3.raw" invocation look like:

-drive file=quorum:2/3:img\\:test.raw:img2,,raw:img3.raw
(note the double \\ and the double ,,)

Signed-off-by: Benoit Canet 
---
 block/quorum.c |   65 
 1 file changed, 65 insertions(+)

diff --git a/block/quorum.c b/block/quorum.c
index d6fef58..550fdae 100644
--- a/block/quorum.c
+++ b/block/quorum.c
@@ -816,12 +816,77 @@ static int quorum_snapshot_reopen(BlockDriverState *bs, 
int bdrv_flags,
 return ret;
 }
 
+/* Valid quorum resources look like
+ * quorum:threshold/total:path/to/image_1: ... :path/to/image_total
+ *
+ * ':' is used as a separator
+ * '\' is the escaping character for filename containing ':'
+ */
+static int quorum_open(BlockDriverState *bs, const char *filename, int flags)
+{
+BDRVQuorumState *s = bs->opaque;
+Error *local_err = NULL;
+int ret = 0;
+int i;
+
+ret = quorum_parse_url(s, filename, &local_err);
+if (ret < 0) {
+goto exit;
+}
+
+ret = quorum_validate_url(s, ret, &local_err);
+if (ret < 0) {
+goto free_exit;
+}
+
+/* Open files */
+for (i = 0; i < s->total; i++) {
+s->bs[i] = bdrv_new("");
+ret = bdrv_open(s->bs[i], s->filenames[i], flags, NULL);
+if (ret < 0) {
+goto error_exit;
+}
+}
+
+goto exit;
+
+error_exit:
+for (; i >= 0; i--) {
+bdrv_delete(s->bs[i]);
+s->bs[i] = NULL;
+}
+free_exit:
+quorum_free(s);
+exit:
+if (error_is_set(&local_err)) {
+qerror_report_err(local_err);
+}
+return ret;
+}
+
+static void quorum_close(BlockDriverState *bs)
+{
+BDRVQuorumState *s = bs->opaque;
+int i;
+
+for (i = 0; i < s->total; i++) {
+/* Ensure writes reach stable storage */
+bdrv_flush(s->bs[i]);
+bdrv_delete(s->bs[i]);
+}
+
+quorum_free(s);
+}
+
 static BlockDriver bdrv_quorum = {
 .format_name= "quorum",
 .protocol_name  = "quorum",
 
 .instance_size  = sizeof(BDRVQuorumState),
 
+.bdrv_file_open = quorum_open,
+.bdrv_close = quorum_close,
+
 .bdrv_co_flush_to_disk = quorum_co_flush,
 
 .bdrv_getlength = quorum_getlength,
-- 
1.7.10.4

Re: [Qemu-devel] [ANNOUNCE] checkpatch and git-am bots

[Andreas Färber]

Am 28.01.2013 14:20, schrieb Anthony Liguori:
> Andreas Färber  writes:
> 
>> Am 21.01.2013 19:45, schrieb Anthony Liguori:
>>>
>>> http://github.com/aliguori/patches.git
>>>
>>> If anyone wants to try it out, let me know, and I would be happy to
>>> answer questions/help you set it up.
>>
>> $ patches fetch http://wiki.qemu.org/patches/patches.json
> 
> Sorry, that's a bug.  There's an implicit mode where you put the JSON
> file location in ~/.patchesrc and that's what I've been using recently.
> 
> I pushed a fix so the explicit URL syntax works again.

Thanks, works now.

Regards,
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] buildbot failure in qemu on default_x86_64_rhel61

[Anthony Liguori]

Luiz Capitulino  writes:

> On Sat, 26 Jan 2013 23:25:11 +0100
> q...@buildbot.b1-systems.de wrote:
>
>> The Buildbot has detected a new failure on builder default_x86_64_rhel61 
>> while building qemu.
>> Full details are available at:
>>  http://buildbot.b1-systems.de/qemu/builders/default_x86_64_rhel61/builds/509
>> 
>> Buildbot URL: http://buildbot.b1-systems.de/qemu/
>> 
>> Buildslave for this Build: kraxel_rhel61
>> 
>> Build Reason: The Nightly scheduler named 'nightly_default' triggered this 
>> build
>> Build Source Stamp: [branch master] HEAD
>> Blamelist: 
>> 
>> BUILD FAILED: failed test
>
>   CCtests/test-string-input-visitor.o
>   LINK  tests/test-string-input-visitor
> GTESTER tests/test-string-input-visitor
> GTester: last random seed: R02S5d812c81f012364176697419b43c9bdd
> make: *** [check-tests/test-string-input-visitor] Error 1
> program finished with exit code 2
> elapsedTime=6.389880
>
> gtester bug, maybe? I can't reproduce it here.

I doubt it I'd really like to have a backtrace and the full output from
the test.

I'm running in a loop now in valgrind with that seed hoping I'll trigger
something.

Regards,

Anthony Liguori

Re: [Qemu-devel] [qemu-devel]The problem of QMP command getfd.

[Stefan Hajnoczi]

On Mon, Jan 28, 2013 at 03:27:01PM +0800, Li Zhang wrote:
> Hi all,
> 
> I am trying to executing qmp command getfd according to qmp-commands.hx.
> 
> { "execute": "getfd", "arguments": { "fdname": "fd1" } }
> 
> Every time, it returns the error.
> 
> {
> "error": {
> "class": "GenericError",
> "desc": "No file descriptor supplied via SCM_RIGHTS"
> }
> }
> 
> This error is related with SCM_RIGHTS.
> I don't know about SCM at all.
> 
> Can anyone give some hints about this?

The "getfd" command allows the client to pass a file descriptor to QEMU
and give it a name.  Later that file descriptor can be used by QEMU.

The QMP client must send '{ "execute": "getfd", "arguments": { "fdname":
"fd1" } }' together with SCM_RIGHTS CMSG.  You are getting the error
because you sent the "getfd" command but forgot to include a file
descriptor using SCM_RIGHTS.

SCM_RIGHTS is a feature of UNIX domain sockets.  It allows one process
to pass a file descriptor to another process through the UNIX domain
socket.  See "man 7 unix" and "man 3 cmsg" for details.

Look at monitor.c:qmp_getfd() to understand how this works.  The QEMU
code to receive a passed file descriptor is in
qemu-char.c:unix_process_msgfd().

Stefan

Re: [Qemu-devel] [PATCH 0/5] vhost-scsi: Add support for host virtualized target

[Paolo Bonzini]

Il 28/01/2013 14:11, Michael S. Tsirkin ha scritto:
> > I asked for a standalone device because the configuration mechanism
> > (configfs vs. command-line) and the feature set are completely
> > different.  Unlike virtio-net, it's not possible to switch one to the
> > other at run time.
> 
> Exactly the same applies to any other frontend option.
> For example if you have two qemu instances with
> different num_queues values you can not migrate one
> to the other.
> So in this sense it is not different from any other
> frontend option, right?

Indeed, in this sense it is not.

Actually in this case migrating one to the other could succeed, and make
all disks disappear on the destination (because of the different
configuration mechanism).  That however could be overcome with vhost=on
registering a migration blocker.

I won't really block the patch with the vhost=on/off frontend option if
it is properly done (e.g. the QEMU SCSI bus should not be created for
vhost=on) and minimally invasive to the non-vhost code.

Paolo

Re: [Qemu-devel] KVM call agenda for 2013-01-29

[Stefan Hajnoczi]

On Mon, Jan 28, 2013 at 11:59:40AM +0100, Juan Quintela wrote:
> Please send in any agenda topics you are interested in.

Replacing select(2) so that we will not hit the 1024 fd_set limit in the
future.

Stefan

Re: [Qemu-devel] KVM call agenda for 2013-01-29

[Andreas Färber]

Am 28.01.2013 11:59, schrieb Juan Quintela:
> Please send in any agenda topics you are interested in.

Buildbot situation:
* Trees are not being added/updated in a timely fashion
* Insufficient build test coverage of trees (ppc, s390x, MinGW, BSD)

http://buildbot.b1-systems.de/qemu/builders

Stefan H. has access to some of the build slaves but not to the main
buildbot server for configuration, it seems.

If Daniel does not have sufficient time to administer it, can we maybe
have that set up on qemu.org instead, with more than one person that has
access to it?

Regards,
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] buildbot failure in qemu on default_x86_64_rhel61

[Andreas Färber]

Am 28.01.2013 14:28, schrieb Anthony Liguori:
> Luiz Capitulino  writes:
> 
>> On Sat, 26 Jan 2013 23:25:11 +0100
>> q...@buildbot.b1-systems.de wrote:
>>
>>> The Buildbot has detected a new failure on builder default_x86_64_rhel61 
>>> while building qemu.
>>> Full details are available at:
>>>  
>>> http://buildbot.b1-systems.de/qemu/builders/default_x86_64_rhel61/builds/509
>>>
>>> Buildbot URL: http://buildbot.b1-systems.de/qemu/
>>>
>>> Buildslave for this Build: kraxel_rhel61
>>>
>>> Build Reason: The Nightly scheduler named 'nightly_default' triggered this 
>>> build
>>> Build Source Stamp: [branch master] HEAD
>>> Blamelist: 
>>>
>>> BUILD FAILED: failed test
>>
>>   CCtests/test-string-input-visitor.o
>>   LINK  tests/test-string-input-visitor
>> GTESTER tests/test-string-input-visitor
>> GTester: last random seed: R02S5d812c81f012364176697419b43c9bdd
>> make: *** [check-tests/test-string-input-visitor] Error 1
>> program finished with exit code 2
>> elapsedTime=6.389880
>>
>> gtester bug, maybe? I can't reproduce it here.
> 
> I doubt it I'd really like to have a backtrace and the full output from
> the test.
> 
> I'm running in a loop now in valgrind with that seed hoping I'll trigger
> something.

My guess was this could be the new string fuzzing test Blue added...

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 0/5] vhost-scsi: Add support for host virtualized target

[Michael S. Tsirkin]

On Mon, Jan 28, 2013 at 02:29:23PM +0100, Paolo Bonzini wrote:
> Il 28/01/2013 14:11, Michael S. Tsirkin ha scritto:
> > > I asked for a standalone device because the configuration mechanism
> > > (configfs vs. command-line) and the feature set are completely
> > > different.  Unlike virtio-net, it's not possible to switch one to the
> > > other at run time.
> > 
> > Exactly the same applies to any other frontend option.
> > For example if you have two qemu instances with
> > different num_queues values you can not migrate one
> > to the other.
> > So in this sense it is not different from any other
> > frontend option, right?
> 
> Indeed, in this sense it is not.
> 
> Actually in this case migrating one to the other could succeed, and make
> all disks disappear on the destination (because of the different
> configuration mechanism).  That however could be overcome with vhost=on
> registering a migration blocker.

Or better add a subsection if vhost is set: vhost=on to vhost=on
can migrate, right?

> I won't really block the patch with the vhost=on/off frontend option if
> it is properly done (e.g. the QEMU SCSI bus should not be created for
> vhost=on) and minimally invasive to the non-vhost code.
> 
> Paolo

Re: [Qemu-devel] [PATCH 0/5] vhost-scsi: Add support for host virtualized target

[Paolo Bonzini]

Il 28/01/2013 14:36, Michael S. Tsirkin ha scritto:
> On Mon, Jan 28, 2013 at 02:29:23PM +0100, Paolo Bonzini wrote:
>> Il 28/01/2013 14:11, Michael S. Tsirkin ha scritto:
 I asked for a standalone device because the configuration mechanism
 (configfs vs. command-line) and the feature set are completely
 different.  Unlike virtio-net, it's not possible to switch one to the
 other at run time.
>>>
>>> Exactly the same applies to any other frontend option.
>>> For example if you have two qemu instances with
>>> different num_queues values you can not migrate one
>>> to the other.
>>> So in this sense it is not different from any other
>>> frontend option, right?
>>
>> Indeed, in this sense it is not.
>>
>> Actually in this case migrating one to the other could succeed, and make
>> all disks disappear on the destination (because of the different
>> configuration mechanism).  That however could be overcome with vhost=on
>> registering a migration blocker.
> 
> Or better add a subsection if vhost is set: vhost=on to vhost=on
> can migrate, right?

I think it's not yet supported by the kernel.  You have no guarantee
that I/O is quiescent at the time the VM starts on the destination.
You'd need a ioctl to do the equivalent of bdrv_drain_all().

Once you have that, a subsection would do the job, yes.

Paolo

>> I won't really block the patch with the vhost=on/off frontend option if
>> it is properly done (e.g. the QEMU SCSI bus should not be created for
>> vhost=on) and minimally invasive to the non-vhost code.
>>
>> Paolo

Re: [Qemu-devel] [PATCH 0/5] vhost-scsi: Add support for host virtualized target

[Michael S. Tsirkin]

On Mon, Jan 28, 2013 at 02:33:44PM +0100, Paolo Bonzini wrote:
> Il 28/01/2013 14:36, Michael S. Tsirkin ha scritto:
> > On Mon, Jan 28, 2013 at 02:29:23PM +0100, Paolo Bonzini wrote:
> >> Il 28/01/2013 14:11, Michael S. Tsirkin ha scritto:
>  I asked for a standalone device because the configuration mechanism
>  (configfs vs. command-line) and the feature set are completely
>  different.  Unlike virtio-net, it's not possible to switch one to the
>  other at run time.
> >>>
> >>> Exactly the same applies to any other frontend option.
> >>> For example if you have two qemu instances with
> >>> different num_queues values you can not migrate one
> >>> to the other.
> >>> So in this sense it is not different from any other
> >>> frontend option, right?
> >>
> >> Indeed, in this sense it is not.
> >>
> >> Actually in this case migrating one to the other could succeed, and make
> >> all disks disappear on the destination (because of the different
> >> configuration mechanism).  That however could be overcome with vhost=on
> >> registering a migration blocker.
> > 
> > Or better add a subsection if vhost is set: vhost=on to vhost=on
> > can migrate, right?
> 
> I think it's not yet supported by the kernel.  You have no guarantee
> that I/O is quiescent at the time the VM starts on the destination.
> You'd need a ioctl to do the equivalent of bdrv_drain_all().
> 
> Once you have that, a subsection would do the job, yes.
> 
> Paolo

OK once that's in it would be easy to probe for.

> >> I won't really block the patch with the vhost=on/off frontend option if
> >> it is properly done (e.g. the QEMU SCSI bus should not be created for
> >> vhost=on) and minimally invasive to the non-vhost code.
> >>
> >> Paolo

[Qemu-devel] [RFC V7 08/13] quorum: Add quorum_invalidate_cache().

[Benoît Canet]

Signed-off-by: Benoit Canet 
---
 block/quorum.c |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/block/quorum.c b/block/quorum.c
index 1f0954d..6254f95 100644
--- a/block/quorum.c
+++ b/block/quorum.c
@@ -517,6 +517,16 @@ static int64_t quorum_getlength(BlockDriverState *bs)
 return result;
 }
 
+static void quorum_invalidate_cache(BlockDriverState *bs)
+{
+BDRVQuorumState *s = bs->opaque;
+int i;
+
+for (i = 0; i < s->total; i++) {
+bdrv_invalidate_cache(s->bs[i]);
+}
+}
+
 static BlockDriver bdrv_quorum = {
 .format_name= "quorum",
 .protocol_name  = "quorum",
@@ -527,6 +537,7 @@ static BlockDriver bdrv_quorum = {
 
 .bdrv_aio_readv = quorum_aio_readv,
 .bdrv_aio_writev= quorum_aio_writev,
+.bdrv_invalidate_cache = quorum_invalidate_cache,
 };
 
 static void bdrv_quorum_init(void)
-- 
1.7.10.4

Re: [Qemu-devel] [PATCH for-1.4 v2] target-i386: kvm: prevent buffer overflow if -cpu foo, [x]level is too big

[Andreas Färber]

Am 28.01.2013 12:49, schrieb Igor Mammedov:
> Stack corruption may occur if too big 'level' or 'xlevel' values passed
> on command line with KVM enabled, due to limited size of cpuid_data
> in kvm_arch_init_vcpu().
> 
> reproduces with:
>  qemu -enable-kvm -cpu qemu64,level=4294967295
> or
>  qemu -enable-kvm -cpu qemu64,xlevel=4294967295
> 
> Check if there is space in cpuid_data before passing it to cpu_x86_cpuid()
> or abort() if there is not space.
> 
> Signed-off-by: Igor Mammedov 

Reviewed-by: Andreas Färber 

CC'ing Gleb and KVM list.

Andreas

> ---
>   * v2:
> * use macro instead of const int max_cpuid_entries to fix build breakage
>   in C99 mode. Suggested-By: Laszlo Ersek 
> * compare with array index instead of address of the last element
>   Sugested-By: Marcelo Tosatti 
> 
> ---
>  target-i386/kvm.c |   25 -
>  1 files changed, 24 insertions(+), 1 deletions(-)
> 
> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> index 3acff40..4ecb728 100644
> --- a/target-i386/kvm.c
> +++ b/target-i386/kvm.c
> @@ -411,11 +411,12 @@ static void cpu_update_state(void *opaque, int running, 
> RunState state)
>  }
>  }
>  
> +#define KVM_MAX_CPUID_ENTRIES  100
>  int kvm_arch_init_vcpu(CPUState *cs)
>  {
>  struct {
>  struct kvm_cpuid2 cpuid;
> -struct kvm_cpuid_entry2 entries[100];
> +struct kvm_cpuid_entry2 entries[KVM_MAX_CPUID_ENTRIES];
>  } QEMU_PACKED cpuid_data;
>  X86CPU *cpu = X86_CPU(cs);
>  CPUX86State *env = &cpu->env;
> @@ -502,6 +503,10 @@ int kvm_arch_init_vcpu(CPUState *cs)
>  cpu_x86_cpuid(env, 0, 0, &limit, &unused, &unused, &unused);
>  
>  for (i = 0; i <= limit; i++) {
> +if (cpuid_i == KVM_MAX_CPUID_ENTRIES) {
> +fprintf(stderr, "unsupported level value: 0x%x\n", limit);
> +abort();
> +}
>  c = &cpuid_data.entries[cpuid_i++];
>  
>  switch (i) {
> @@ -516,6 +521,11 @@ int kvm_arch_init_vcpu(CPUState *cs)
>  times = c->eax & 0xff;
>  
>  for (j = 1; j < times; ++j) {
> +if (cpuid_i == KVM_MAX_CPUID_ENTRIES) {
> +fprintf(stderr, "cpuid_data is full, no space for "
> +"cpuid(eax:2):eax & 0xf = 0x%x\n", times);
> +abort();
> +}
>  c = &cpuid_data.entries[cpuid_i++];
>  c->function = i;
>  c->flags = KVM_CPUID_FLAG_STATEFUL_FUNC;
> @@ -544,6 +554,11 @@ int kvm_arch_init_vcpu(CPUState *cs)
>  if (i == 0xd && c->eax == 0) {
>  continue;
>  }
> +if (cpuid_i == KVM_MAX_CPUID_ENTRIES) {
> +fprintf(stderr, "cpuid_data is full, no space for "
> +"cpuid(eax:0x%x,ecx:0x%x)\n", i, j);
> +abort();
> +}
>  c = &cpuid_data.entries[cpuid_i++];
>  }
>  break;
> @@ -557,6 +572,10 @@ int kvm_arch_init_vcpu(CPUState *cs)
>  cpu_x86_cpuid(env, 0x8000, 0, &limit, &unused, &unused, &unused);
>  
>  for (i = 0x8000; i <= limit; i++) {
> +if (cpuid_i == KVM_MAX_CPUID_ENTRIES) {
> +fprintf(stderr, "unsupported xlevel value: 0x%x\n", limit);
> +abort();
> +}
>  c = &cpuid_data.entries[cpuid_i++];
>  
>  c->function = i;
> @@ -569,6 +588,10 @@ int kvm_arch_init_vcpu(CPUState *cs)
>  cpu_x86_cpuid(env, 0xC000, 0, &limit, &unused, &unused, &unused);
>  
>  for (i = 0xC000; i <= limit; i++) {
> +if (cpuid_i == KVM_MAX_CPUID_ENTRIES) {
> +fprintf(stderr, "unsupported xlevel2 value: 0x%x\n", limit);
> +abort();
> +}
>  c = &cpuid_data.entries[cpuid_i++];
>  
>  c->function = i;
> 


-- 
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] [RFC] qemu snapshot enchancement

[Dietmar Maurer]

> If you've been using it for 4 years then it was without dm-thin, which is a 
> new
> snapshot mechanism that solves limitations of classic LVM snapshot
> volumes.  So if you're referring to inefficient LVM snapshots then that should
> be solvable now.

Are you sure this work on shared iSCSI devices (I have my doubts)?

Besides, we use RHEL6.3 kernel, and AFAIK dm-thin is still not marked stable 
there.

> Or is LVM a pain for other reasons?

a.) it only works on LVM (new solution works on any storage type)
b.) You need free space on the VG (almost every user configures LVM without 
leaving
any free space on the VG).
c.) you need to specify snapshot size in advance
d.) performance is bad on writes.

The new solution work perfectly on all storage types, works on shared storage, 
and
does not need any free space on the source storage.

Re: [Qemu-devel] [PATCH qom-cpu for-1.4] target-m68k: Use type_register() instead of type_register_static()

[Andreas Färber]

Am 27.01.2013 19:35, schrieb Andreas Färber:
> According to its documentation, type_register_static()'s TypeInfo
> argument should exist for the life type of the type.
> Therefore use type_register() when registering the list of CPU subtypes.
> 
> No functional change with the current implementation.
> 
> Cf. 918fd0839eeafc83bd4984364321a947d29041fe for arm.
> 
> Signed-off-by: Andreas Färber 

Applied this along with the or32 and uc32 counterparts to qom-cpu:
https://github.com/afaerber/qemu-cpu/commits/qom-cpu

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] qmp-commands.hx: s/tray-open/tray_open/ to match qapi schema

[Luiz Capitulino]

On Fri, 25 Jan 2013 14:27:11 +0100
Michal Privoznik  wrote:

> Currently, we are using 'tray_open' in QMP and 'tray-open' in
> HMP. However, the QMP documentation was mistakenly using the
> HMP version.

It's missing the s-o-b line.

> ---
>  qmp-commands.hx | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/qmp-commands.hx b/qmp-commands.hx
> index cbf1280..870ee54 100644
> --- a/qmp-commands.hx
> +++ b/qmp-commands.hx
> @@ -1585,7 +1585,7 @@ Each json-object contain the following:
>   - Possible values: "unknown"
>  - "removable": true if the device is removable, false otherwise (json-bool)
>  - "locked": true if the device is locked, false otherwise (json-bool)
> -- "tray-open": only present if removable, true if the device has a tray,
> +- "tray_open": only present if removable, true if the device has a tray,
> and it is open (json-bool)
>  - "inserted": only present if the device is inserted, it is a json-object
> containing the following:

Re: [Qemu-devel] [PATCH v2] qemu-pixman.h: Avoid mutual inclusion loop with console.h

[Peter Maydell]

Ping: Stefan, are you going to take this via -trivial
as Gerd suggests?

[patchwork url: http://patchwork.ozlabs.org/patch/214114/ ]

thanks
-- PMM

On 21 January 2013 17:14, Gerd Hoffmann  wrote:
> On 01/21/13 15:19, Gerd Hoffmann wrote:
>>> Stefan: I've made the obvious change to fix the spice compile issue,
>>> but none of my systems have a new enough spice-protocol/spice-server
>>> to allow me to configure with spice enabled. I'd appreciate it if
>>> you could check it does indeed compile OK now...
>>
>> I'll run this through the buildbot ...
>
> All green.
>
> Acked-by: Gerd Hoffmann 
>
> Taking through trivial would be a nice service as I don't have any
> 1.4-ish pixman stuff pending arm.
>
> thanks,
>   Gerd

[Qemu-devel] [RFC V7 01/13] quorum: Create quorum.c, add QuorumSingleAIOCB and QuorumAIOCB.

[Benoît Canet]

Signed-off-by: Benoit Canet 
---
 block/Makefile.objs |1 +
 block/quorum.c  |   45 +
 2 files changed, 46 insertions(+)
 create mode 100644 block/quorum.c

diff --git a/block/Makefile.objs b/block/Makefile.objs
index c067f38..4143e34 100644
--- a/block/Makefile.objs
+++ b/block/Makefile.objs
@@ -2,6 +2,7 @@ block-obj-y += raw.o cow.o qcow.o vdi.o vmdk.o cloop.o dmg.o 
bochs.o vpc.o vvfat
 block-obj-y += qcow2.o qcow2-refcount.o qcow2-cluster.o qcow2-snapshot.o 
qcow2-cache.o
 block-obj-y += qed.o qed-gencb.o qed-l2-cache.o qed-table.o qed-cluster.o
 block-obj-y += qed-check.o
+block-obj-y += quorum.o
 block-obj-y += parallels.o blkdebug.o blkverify.o
 block-obj-$(CONFIG_WIN32) += raw-win32.o win32-aio.o
 block-obj-$(CONFIG_POSIX) += raw-posix.o
diff --git a/block/quorum.c b/block/quorum.c
new file mode 100644
index 000..ce094a1
--- /dev/null
+++ b/block/quorum.c
@@ -0,0 +1,45 @@
+/*
+ * Quorum Block filter
+ *
+ * Copyright (C) 2012-2013 Nodalink, SARL.
+ *
+ * Author:
+ *   Benoît Canet 
+ *
+ * Based on the design and code of blkverify.c (Copyright (C) 2010 IBM, Corp)
+ * and blkmirror.c (Copyright (C) 2011 Red Hat, Inc).
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "block/block_int.h"
+
+typedef struct QuorumAIOCB QuorumAIOCB;
+
+typedef struct QuorumSingleAIOCB {
+BlockDriverAIOCB *aiocb;
+uint8_t *buf;
+int ret;
+QuorumAIOCB *parent;
+} QuorumSingleAIOCB;
+
+struct QuorumAIOCB {
+BlockDriverAIOCB common;
+QEMUBH *bh;
+
+/* Request metadata */
+uint64_t sector_num;
+int nb_sectors;
+
+QEMUIOVector *qiov; /* calling readv IOV */
+
+QuorumSingleAIOCB *aios;/* individual AIOs */
+QEMUIOVector *qiovs;/* individual IOVs */
+int count;  /* number of completed AIOCB */
+int success_count;  /* number of successfully completed AIOCB */
+bool *finished; /* completion signal for cancel */
+
+void (*vote)(QuorumAIOCB *acb);
+int vote_ret;
+};
-- 
1.7.10.4

Re: [Qemu-devel] [PATCH qom-cpu for-1.4?] kvm: Pass CPUState to kvm_on_sigbus_vcpu()

[Gleb Natapov]

On Fri, Jan 25, 2013 at 04:55:29PM +0100, Andreas Färber wrote:
> Since commit 20d695a9254c1b086a456d3b79a3c311236643ba (kvm: Pass
> CPUState to kvm_arch_*) CPUArchState is no longer needed.
> 
> Allows to change qemu_kvm_eat_signals() argument as well.
> 
> Signed-off-by: Andreas Färber 
Reviewed-by: Gleb Natapov 

> ---
>  Extracted from my qom-cpu-8 queue.
> 
>  cpus.c   |8 
>  include/sysemu/kvm.h |2 +-
>  kvm-all.c|3 +--
>  kvm-stub.c   |2 +-
>  4 Dateien geändert, 7 Zeilen hinzugefügt(+), 8 Zeilen entfernt(-)
> 
> diff --git a/cpus.c b/cpus.c
> index a4390c3..41779eb 100644
> --- a/cpus.c
> +++ b/cpus.c
> @@ -517,7 +517,7 @@ static void qemu_init_sigbus(void)
>  prctl(PR_MCE_KILL, PR_MCE_KILL_SET, PR_MCE_KILL_EARLY, 0, 0);
>  }
>  
> -static void qemu_kvm_eat_signals(CPUArchState *env)
> +static void qemu_kvm_eat_signals(CPUState *cpu)
>  {
>  struct timespec ts = { 0, 0 };
>  siginfo_t siginfo;
> @@ -538,7 +538,7 @@ static void qemu_kvm_eat_signals(CPUArchState *env)
>  
>  switch (r) {
>  case SIGBUS:
> -if (kvm_on_sigbus_vcpu(env, siginfo.si_code, siginfo.si_addr)) {
> +if (kvm_on_sigbus_vcpu(cpu, siginfo.si_code, siginfo.si_addr)) {
>  sigbus_reraise();
>  }
>  break;
> @@ -560,7 +560,7 @@ static void qemu_init_sigbus(void)
>  {
>  }
>  
> -static void qemu_kvm_eat_signals(CPUArchState *env)
> +static void qemu_kvm_eat_signals(CPUState *cpu)
>  {
>  }
>  #endif /* !CONFIG_LINUX */
> @@ -727,7 +727,7 @@ static void qemu_kvm_wait_io_event(CPUArchState *env)
>  qemu_cond_wait(cpu->halt_cond, &qemu_global_mutex);
>  }
>  
> -qemu_kvm_eat_signals(env);
> +qemu_kvm_eat_signals(cpu);
>  qemu_wait_io_event_common(cpu);
>  }
>  
> diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
> index 384ee66..6e6dfb3 100644
> --- a/include/sysemu/kvm.h
> +++ b/include/sysemu/kvm.h
> @@ -159,7 +159,7 @@ int kvm_update_guest_debug(CPUArchState *env, unsigned 
> long reinject_trap);
>  int kvm_set_signal_mask(CPUArchState *env, const sigset_t *sigset);
>  #endif
>  
> -int kvm_on_sigbus_vcpu(CPUArchState *env, int code, void *addr);
> +int kvm_on_sigbus_vcpu(CPUState *cpu, int code, void *addr);
>  int kvm_on_sigbus(int code, void *addr);
>  
>  /* internal API */
> diff --git a/kvm-all.c b/kvm-all.c
> index 363a358..04ec2d5 100644
> --- a/kvm-all.c
> +++ b/kvm-all.c
> @@ -2026,9 +2026,8 @@ int kvm_set_ioeventfd_pio_word(int fd, uint16_t addr, 
> uint16_t val, bool assign)
>  return 0;
>  }
>  
> -int kvm_on_sigbus_vcpu(CPUArchState *env, int code, void *addr)
> +int kvm_on_sigbus_vcpu(CPUState *cpu, int code, void *addr)
>  {
> -CPUState *cpu = ENV_GET_CPU(env);
>  return kvm_arch_on_sigbus_vcpu(cpu, code, addr);
>  }
>  
> diff --git a/kvm-stub.c b/kvm-stub.c
> index 47f8dca..760aadc 100644
> --- a/kvm-stub.c
> +++ b/kvm-stub.c
> @@ -112,7 +112,7 @@ int kvm_set_ioeventfd_mmio(int fd, uint32_t adr, uint32_t 
> val, bool assign, uint
>  return -ENOSYS;
>  }
>  
> -int kvm_on_sigbus_vcpu(CPUArchState *env, int code, void *addr)
> +int kvm_on_sigbus_vcpu(CPUState *cpu, int code, void *addr)
>  {
>  return 1;
>  }
> -- 
> 1.7.10.4

--
Gleb.

Re: [Qemu-devel] [PATCH] target-arm: Fix TCG temp leaks for WI and UNDEF VFP sysreg writes

[Peter Maydell]

Blue -- I forgot to put this patch in a target-arm pullreq,
and it's my only outstanding target-arm patch for 1.4.
Do you want to just apply it directly or would you prefer
me to put together a single-patch pullreq?

[patchwork url: http://patchwork.ozlabs.org/patch/205269/ ]

thanks
-- PMM

On 11 December 2012 16:11, Peter Maydell  wrote:
> Fix a leak of a TCG temporary in code paths for VFP system register
> writes for cases which UNDEF or are write-ignored.
>
> Signed-off-by: Peter Maydell 
> ---
>  target-arm/translate.c |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/target-arm/translate.c b/target-arm/translate.c
> index 3cf3604..d6fafa0 100644
> --- a/target-arm/translate.c
> +++ b/target-arm/translate.c
> @@ -2737,7 +2737,6 @@ static int disas_vfp_insn(CPUARMState * env, 
> DisasContext *s, uint32_t insn)
>  }
>  } else {
>  /* arm->vfp */
> -tmp = load_reg(s, rd);
>  if (insn & (1 << 21)) {
>  rn >>= 1;
>  /* system register */
> @@ -2748,6 +2747,7 @@ static int disas_vfp_insn(CPUARMState * env, 
> DisasContext *s, uint32_t insn)
>  /* Writes are ignored.  */
>  break;
>  case ARM_VFP_FPSCR:
> +tmp = load_reg(s, rd);
>  gen_helper_vfp_set_fpscr(cpu_env, tmp);
>  tcg_temp_free_i32(tmp);
>  gen_lookup_tb(s);
> @@ -2757,18 +2757,21 @@ static int disas_vfp_insn(CPUARMState * env, 
> DisasContext *s, uint32_t insn)
>  return 1;
>  /* TODO: VFP subarchitecture support.
>   * For now, keep the EN bit only */
> +tmp = load_reg(s, rd);
>  tcg_gen_andi_i32(tmp, tmp, 1 << 30);
>  store_cpu_field(tmp, vfp.xregs[rn]);
>  gen_lookup_tb(s);
>  break;
>  case ARM_VFP_FPINST:
>  case ARM_VFP_FPINST2:
> +tmp = load_reg(s, rd);
>  store_cpu_field(tmp, vfp.xregs[rn]);
>  break;
>  default:
>  return 1;
>  }
>  } else {
> +tmp = load_reg(s, rd);
>  gen_vfp_msr(tmp);
>  gen_mov_vreg_F0(0, rn);
>  }
> --
> 1.7.9.5
>
>

[Qemu-devel] [PATCH 2/4] block: make path_hash_protocol public.

[Benoît Canet]

Signed-off-by: Benoit Canet 
---
 block.c   |2 +-
 include/block/block.h |1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/block.c b/block.c
index af22ee8..3bebc74 100644
--- a/block.c
+++ b/block.c
@@ -195,7 +195,7 @@ static void bdrv_io_limits_intercept(BlockDriverState *bs,
 }
 
 /* check if the path starts with ":" */
-static int path_has_protocol(const char *path)
+int path_has_protocol(const char *path)
 {
 const char *p;
 
diff --git a/include/block/block.h b/include/block/block.h
index 4d83856..8bb47c4 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -121,6 +121,7 @@ bool bdrv_io_limits_enabled(BlockDriverState *bs);
 void bdrv_init(void);
 void bdrv_init_with_whitelist(void);
 BlockDriver *bdrv_find_protocol(const char *filename);
+int path_has_protocol(const char *path);
 BlockDriver *bdrv_find_format(const char *format_name);
 BlockDriver *bdrv_find_whitelisted_format(const char *format_name);
 int bdrv_create(BlockDriver *drv, const char* filename,
-- 
1.7.10.4

[Qemu-devel] [RFC V7 06/13] quorum: Add quorum mechanism.

[Benoît Canet]

Use gnutls's SHA-256 to compare versions.

Signed-off-by: Benoit Canet 
---
 block/quorum.c |  303 +++-
 configure  |   22 
 2 files changed, 324 insertions(+), 1 deletion(-)

diff --git a/block/quorum.c b/block/quorum.c
index ab3e5f3..307fab4 100644
--- a/block/quorum.c
+++ b/block/quorum.c
@@ -13,8 +13,30 @@
  * See the COPYING file in the top-level directory.
  */
 
+#include 
+#include 
 #include "block/block_int.h"
 
+#define HASH_LENGTH 32
+
+typedef union QuorumVoteValue {
+char h[HASH_LENGTH];   /* SHA-256 hash */
+unsigned long l;  /* simpler hash */
+} QuorumVoteValue;
+
+typedef struct QuorumVoteItem {
+int index;
+QLIST_ENTRY(QuorumVoteItem) next;
+} QuorumVoteItem;
+
+typedef struct QuorumVoteVersion {
+QuorumVoteValue value;
+int index;
+int vote_count;
+QLIST_HEAD(, QuorumVoteItem) items;
+QLIST_ENTRY(QuorumVoteVersion) next;
+} QuorumVoteVersion;
+
 typedef struct {
 BlockDriverState **bs;
 unsigned long long threshold;
@@ -31,6 +53,11 @@ typedef struct QuorumSingleAIOCB {
 QuorumAIOCB *parent;
 } QuorumSingleAIOCB;
 
+typedef struct QuorumVotes {
+QLIST_HEAD(, QuorumVoteVersion) vote_list;
+int (*compare)(QuorumVoteValue *a, QuorumVoteValue *b);
+} QuorumVotes;
+
 struct QuorumAIOCB {
 BlockDriverAIOCB common;
 BDRVQuorumState *bqs;
@@ -48,6 +75,8 @@ struct QuorumAIOCB {
 int success_count;  /* number of successfully completed AIOCB */
 bool *finished; /* completion signal for cancel */
 
+QuorumVotes votes;
+
 void (*vote)(QuorumAIOCB *acb);
 int vote_ret;
 };
@@ -84,6 +113,11 @@ static void quorum_aio_bh(void *opaque)
 }
 
 qemu_bh_delete(acb->bh);
+
+if (acb->vote_ret) {
+ret = acb->vote_ret;
+}
+
 acb->common.cb(acb->common.opaque, ret);
 if (acb->finished) {
 *acb->finished = true;
@@ -96,6 +130,11 @@ static void quorum_aio_bh(void *opaque)
 qemu_aio_release(acb);
 }
 
+static int quorum_sha256_compare(QuorumVoteValue *a, QuorumVoteValue *b)
+{
+return memcmp(a, b, HASH_LENGTH);
+}
+
 static QuorumAIOCB *quorum_aio_get(BDRVQuorumState *s,
BlockDriverState *bs,
QEMUIOVector *qiov,
@@ -120,6 +159,8 @@ static QuorumAIOCB *quorum_aio_get(BDRVQuorumState *s,
 acb->vote = NULL;
 acb->vote_ret = 0;
 acb->finished = NULL;
+acb->votes.compare = quorum_sha256_compare;
+QLIST_INIT(&acb->votes.vote_list);
 
 for (i = 0; i < s->total; i++) {
 acb->aios[i].buf = NULL;
@@ -147,10 +188,268 @@ static void quorum_aio_cb(void *opaque, int ret)
 return;
 }
 
+/* Do the vote */
+if (acb->vote) {
+acb->vote(acb);
+}
+
 acb->bh = qemu_bh_new(quorum_aio_bh, acb);
 qemu_bh_schedule(acb->bh);
 }
 
+static void quorum_print_bad(QuorumAIOCB *acb, const char *filename)
+{
+fprintf(stderr, "quorum: corrected error in quorum file %s: sector_num=%"
+PRId64 " nb_sectors=%i\n", filename, acb->sector_num,
+acb->nb_sectors);
+}
+
+static void quorum_print_failure(QuorumAIOCB *acb)
+{
+fprintf(stderr, "quorum: failure sector_num=%" PRId64 " nb_sectors=%i\n",
+acb->sector_num, acb->nb_sectors);
+}
+
+static void quorum_print_bad_versions(QuorumAIOCB *acb,
+  QuorumVoteValue *value)
+{
+QuorumVoteVersion *version;
+QuorumVoteItem *item;
+BDRVQuorumState *s = acb->bqs;
+
+QLIST_FOREACH(version, &acb->votes.vote_list, next) {
+if (!acb->votes.compare(&version->value, value)) {
+continue;
+}
+QLIST_FOREACH(item, &version->items, next) {
+quorum_print_bad(acb, s->filenames[item->index]);
+}
+}
+}
+
+static void quorum_copy_qiov(QEMUIOVector *dest, QEMUIOVector *source)
+{
+int i;
+assert(dest->niov == source->niov);
+assert(dest->size == source->size);
+for (i = 0; i < source->niov; i++) {
+assert(dest->iov[i].iov_len == source->iov[i].iov_len);
+memcpy(dest->iov[i].iov_base,
+   source->iov[i].iov_base,
+   source->iov[i].iov_len);
+}
+}
+
+static void quorum_count_vote(QuorumVotes *votes,
+  QuorumVoteValue *value,
+  int index)
+{
+QuorumVoteVersion *v = NULL, *version = NULL;
+QuorumVoteItem *item;
+
+/* look if we have something with this hash */
+QLIST_FOREACH(v, &votes->vote_list, next) {
+if (!votes->compare(&v->value, value)) {
+version = v;
+break;
+}
+}
+
+/* It's a version not yet in the list add it */
+if (!version) {
+version = g_new0(QuorumVoteVersion, 1);
+QLIST_INIT(&version->items);
+memcpy(&version->value, value, sizeof(version->value));
+version->index = index;
+version->vote_count

[Qemu-devel] [RFC V7 07/13] quorum: Add quorum_getlength().

[Benoît Canet]

Check that every bs file return the same length.
If not return -EIO to disable the quorum and
avoid length discrepancy.

Signed-off-by: Benoit Canet 
---
 block/quorum.c |   20 
 1 file changed, 20 insertions(+)

diff --git a/block/quorum.c b/block/quorum.c
index 307fab4..1f0954d 100644
--- a/block/quorum.c
+++ b/block/quorum.c
@@ -499,12 +499,32 @@ static BlockDriverAIOCB 
*quorum_aio_writev(BlockDriverState *bs,
 return &acb->common;
 }
 
+static int64_t quorum_getlength(BlockDriverState *bs)
+{
+BDRVQuorumState *s = bs->opaque;
+int64_t result;
+int i;
+
+/* check that every file have the same length */
+result = bdrv_getlength(s->bs[0]);
+for (i = 1; i < s->total; i++) {
+int64_t value = bdrv_getlength(s->bs[i]);
+if (value != result) {
+return -EIO;
+}
+}
+
+return result;
+}
+
 static BlockDriver bdrv_quorum = {
 .format_name= "quorum",
 .protocol_name  = "quorum",
 
 .instance_size  = sizeof(BDRVQuorumState),
 
+.bdrv_getlength = quorum_getlength,
+
 .bdrv_aio_readv = quorum_aio_readv,
 .bdrv_aio_writev= quorum_aio_writev,
 };
-- 
1.7.10.4

Re: [Qemu-devel] [PATCH qom-cpu for-1.4] cpu: Unconditionalize CPUState fields

[Paolo Bonzini]

Il 25/01/2013 16:27, Andreas Färber ha scritto:
> Commits fc8c5b8c41ee5ba69d7a2be63b02a08c7b0b155b (Makefile.user: Define
> CONFIG_USER_ONLY for libuser/) and
> dd83b06ae61cfa2dc4381ab49f365bd0995fc930 (qom: Introduce CPU class)
> specifically prepared the qom/cpu.c file to be compiled differently for
> softmmu and *-user. This broke as part of build system refactorings
> while CPU patches were in flight, adding conditional fields
> kvm_fd (8737c51c0444f832c4e97d7eb7540eae457e08e4) and
> kvm_vcpu_dirty (20d695a9254c1b086a456d3b79a3c311236643ba) for softmmu.
> 
> linux-user and bsd-user would therefore get a CPUState type with
> instance_size ~8 bytes shorter than expected.
> Fix this by unconditionally having the fields in CPUState.
> 
> In practice, target-specific CPU types' instance_size would compensate
> this, and upstream qom/cpu.c does not yet touch any affected field.
> 
> Cc: Paolo Bonzini 
> Signed-off-by: Andreas Färber 
> ---
>  include/qom/cpu.h |2 --
>  1 Datei geändert, 2 Zeilen entfernt(-)
> 
> diff --git a/include/qom/cpu.h b/include/qom/cpu.h
> index 773caf9..2333781 100644
> --- a/include/qom/cpu.h
> +++ b/include/qom/cpu.h
> @@ -89,10 +89,8 @@ struct CPUState {
>  bool stop;
>  bool stopped;
>  
> -#if !defined(CONFIG_USER_ONLY)
>  int kvm_fd;
>  bool kvm_vcpu_dirty;
> -#endif
>  struct KVMState *kvm_state;
>  struct kvm_run *kvm_run;
>  
> 

Reviewed-by: Paolo Bonzini 

[Qemu-devel] [RFC V7 05/13] quorum: Add quorum_aio_readv.

[Benoît Canet]

Signed-off-by: Benoit Canet 
---
 block/quorum.c |   38 +-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/block/quorum.c b/block/quorum.c
index 8fa79db..ab3e5f3 100644
--- a/block/quorum.c
+++ b/block/quorum.c
@@ -73,15 +73,24 @@ static void quorum_aio_bh(void *opaque)
 {
 QuorumAIOCB *acb = opaque;
 BDRVQuorumState *s = acb->bqs;
-int ret;
+int i, ret;
 
 ret = s->threshold <= acb->success_count ? 0 : -EIO;
 
+for (i = 0; i < s->total; i++) {
+qemu_vfree(acb->aios[i].buf);
+acb->aios[i].buf = NULL;
+acb->aios[i].ret = 0;
+}
+
 qemu_bh_delete(acb->bh);
 acb->common.cb(acb->common.opaque, ret);
 if (acb->finished) {
 *acb->finished = true;
 }
+for (i = 0; i < s->total; i++) {
+qemu_iovec_destroy(&acb->qiovs[i]);
+}
 g_free(acb->aios);
 g_free(acb->qiovs);
 qemu_aio_release(acb);
@@ -142,6 +151,32 @@ static void quorum_aio_cb(void *opaque, int ret)
 qemu_bh_schedule(acb->bh);
 }
 
+static BlockDriverAIOCB *quorum_aio_readv(BlockDriverState *bs,
+ int64_t sector_num,
+ QEMUIOVector *qiov,
+ int nb_sectors,
+ BlockDriverCompletionFunc *cb,
+ void *opaque)
+{
+BDRVQuorumState *s = bs->opaque;
+QuorumAIOCB *acb = quorum_aio_get(s, bs, qiov, sector_num,
+  nb_sectors, cb, opaque);
+int i;
+
+for (i = 0; i < s->total; i++) {
+acb->aios[i].buf = qemu_blockalign(bs->file, qiov->size);
+qemu_iovec_init(&acb->qiovs[i], qiov->niov);
+qemu_iovec_clone(&acb->qiovs[i], qiov, acb->aios[i].buf);
+}
+
+for (i = 0; i < s->total; i++) {
+bdrv_aio_readv(s->bs[i], sector_num, qiov, nb_sectors,
+   quorum_aio_cb, &acb->aios[i]);
+}
+
+return &acb->common;
+}
+
 static BlockDriverAIOCB *quorum_aio_writev(BlockDriverState *bs,
   int64_t sector_num,
   QEMUIOVector *qiov,
@@ -169,6 +204,7 @@ static BlockDriver bdrv_quorum = {
 
 .instance_size  = sizeof(BDRVQuorumState),
 
+.bdrv_aio_readv = quorum_aio_readv,
 .bdrv_aio_writev= quorum_aio_writev,
 };
 
-- 
1.7.10.4

[Qemu-devel] [PATCH 3/4] blockdev: Allow snapshoting of protocols.

[Benoît Canet]

Signed-off-by: Benoit Canet 
---
 blockdev.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/blockdev.c b/blockdev.c
index 0ce45c5..b1f388b 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -800,7 +800,8 @@ void qmp_transaction(BlockdevActionList *dev_list, Error 
**errp)
 /* We will manually add the backing_hd field to the bs later */
 states->new_bs = bdrv_new("");
 ret = bdrv_open(states->new_bs, new_image_file,
-flags | BDRV_O_NO_BACKING, drv);
+flags | BDRV_O_NO_BACKING,
+path_has_protocol(new_image_file) ?  NULL : drv);
 if (ret != 0) {
 error_set(errp, QERR_OPEN_FILE_FAILED, new_image_file);
 goto delete_and_fail;
-- 
1.7.10.4

Re: [Qemu-devel] KVM call agenda for 2013-01-29

[Anthony Liguori]

Juan Quintela  writes:

> Hi
>
> Please send in any agenda topics you are interested in.

 - Outstanding virtio work for 1.4
   - Multiqueue virtio-net (Amos/Michael)
   - Refactorings (Fred/Peter)
   - virtio-ccw (Cornelia/Alex)

We need to work out the ordering here and what's reasonable to merge
over the next week.

Regards,

Anthony Liguori

>
> Later, Juan.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Qemu-devel] [PATCH 0/4] Pave the way for protocol snapshot creation

[Benoît Canet]

This patchset add the required block driver operation in order to allow
protocols such as quorum to be able to create snapshots.

Benoît Canet (4):
  block: Move external snapshot image creation in the block drivers.
  block: make path_hash_protocol public.
  blockdev: Allow snapshoting of protocols.
  block: Move reopening of image after snapshot creation into the block
drivers.

 block.c   |   72 -
 block/blkdebug.c  |2 ++
 block/blkverify.c |2 ++
 block/bochs.c |2 ++
 block/cloop.c |2 ++
 block/cow.c   |3 ++
 block/curl.c  |   10 +++
 block/dmg.c   |2 ++
 block/gluster.c   |8 +
 block/iscsi.c |2 ++
 block/nbd.c   |6 
 block/parallels.c |2 ++
 block/qcow.c  |3 ++
 block/qcow2.c |3 ++
 block/qed.c   |3 ++
 block/raw-posix.c |   10 +++
 block/raw-win32.c |6 
 block/raw.c   |2 ++
 block/rbd.c   |2 ++
 block/sheepdog.c  |3 ++
 block/vdi.c   |2 ++
 block/vmdk.c  |3 ++
 block/vpc.c   |2 ++
 block/vvfat.c |3 ++
 blockdev.c|   16 +-
 include/block/block.h |   18 
 include/block/block_int.h |   12 
 27 files changed, 193 insertions(+), 8 deletions(-)

-- 
1.7.10.4

[Qemu-devel] [RFC V7 04/13] blkverify: Extract qemu_iovec_clone() and qemu_iovec_compare() from blkverify.

[Benoît Canet]

Signed-off-by: Benoit Canet 
---
 block/blkverify.c |  108 +
 include/qemu-common.h |2 +
 util/iov.c|  103 ++
 3 files changed, 107 insertions(+), 106 deletions(-)

diff --git a/block/blkverify.c b/block/blkverify.c
index 2726ed0..e5ebecb 100644
--- a/block/blkverify.c
+++ b/block/blkverify.c
@@ -123,110 +123,6 @@ static int64_t blkverify_getlength(BlockDriverState *bs)
 return bdrv_getlength(s->test_file);
 }
 
-/**
- * Check that I/O vector contents are identical
- *
- * @a:  I/O vector
- * @b:  I/O vector
- * @ret:Offset to first mismatching byte or -1 if match
- */
-static ssize_t blkverify_iovec_compare(QEMUIOVector *a, QEMUIOVector *b)
-{
-int i;
-ssize_t offset = 0;
-
-assert(a->niov == b->niov);
-for (i = 0; i < a->niov; i++) {
-size_t len = 0;
-uint8_t *p = (uint8_t *)a->iov[i].iov_base;
-uint8_t *q = (uint8_t *)b->iov[i].iov_base;
-
-assert(a->iov[i].iov_len == b->iov[i].iov_len);
-while (len < a->iov[i].iov_len && *p++ == *q++) {
-len++;
-}
-
-offset += len;
-
-if (len != a->iov[i].iov_len) {
-return offset;
-}
-}
-return -1;
-}
-
-typedef struct {
-int src_index;
-struct iovec *src_iov;
-void *dest_base;
-} IOVectorSortElem;
-
-static int sortelem_cmp_src_base(const void *a, const void *b)
-{
-const IOVectorSortElem *elem_a = a;
-const IOVectorSortElem *elem_b = b;
-
-/* Don't overflow */
-if (elem_a->src_iov->iov_base < elem_b->src_iov->iov_base) {
-return -1;
-} else if (elem_a->src_iov->iov_base > elem_b->src_iov->iov_base) {
-return 1;
-} else {
-return 0;
-}
-}
-
-static int sortelem_cmp_src_index(const void *a, const void *b)
-{
-const IOVectorSortElem *elem_a = a;
-const IOVectorSortElem *elem_b = b;
-
-return elem_a->src_index - elem_b->src_index;
-}
-
-/**
- * Copy contents of I/O vector
- *
- * The relative relationships of overlapping iovecs are preserved.  This is
- * necessary to ensure identical semantics in the cloned I/O vector.
- */
-static void blkverify_iovec_clone(QEMUIOVector *dest, const QEMUIOVector *src,
-  void *buf)
-{
-IOVectorSortElem sortelems[src->niov];
-void *last_end;
-int i;
-
-/* Sort by source iovecs by base address */
-for (i = 0; i < src->niov; i++) {
-sortelems[i].src_index = i;
-sortelems[i].src_iov = &src->iov[i];
-}
-qsort(sortelems, src->niov, sizeof(sortelems[0]), sortelem_cmp_src_base);
-
-/* Allocate buffer space taking into account overlapping iovecs */
-last_end = NULL;
-for (i = 0; i < src->niov; i++) {
-struct iovec *cur = sortelems[i].src_iov;
-ptrdiff_t rewind = 0;
-
-/* Detect overlap */
-if (last_end && last_end > cur->iov_base) {
-rewind = last_end - cur->iov_base;
-}
-
-sortelems[i].dest_base = buf - rewind;
-buf += cur->iov_len - MIN(rewind, cur->iov_len);
-last_end = MAX(cur->iov_base + cur->iov_len, last_end);
-}
-
-/* Sort by source iovec index and build destination iovec */
-qsort(sortelems, src->niov, sizeof(sortelems[0]), sortelem_cmp_src_index);
-for (i = 0; i < src->niov; i++) {
-qemu_iovec_add(dest, sortelems[i].dest_base, src->iov[i].iov_len);
-}
-}
-
 static BlkverifyAIOCB *blkverify_aio_get(BlockDriverState *bs, bool is_write,
  int64_t sector_num, QEMUIOVector 
*qiov,
  int nb_sectors,
@@ -290,7 +186,7 @@ static void blkverify_aio_cb(void *opaque, int ret)
 
 static void blkverify_verify_readv(BlkverifyAIOCB *acb)
 {
-ssize_t offset = blkverify_iovec_compare(acb->qiov, &acb->raw_qiov);
+ssize_t offset = qemu_iovec_compare(acb->qiov, &acb->raw_qiov);
 if (offset != -1) {
 blkverify_err(acb, "contents mismatch in sector %" PRId64,
   acb->sector_num + (int64_t)(offset / BDRV_SECTOR_SIZE));
@@ -308,7 +204,7 @@ static BlockDriverAIOCB 
*blkverify_aio_readv(BlockDriverState *bs,
 acb->verify = blkverify_verify_readv;
 acb->buf = qemu_blockalign(bs->file, qiov->size);
 qemu_iovec_init(&acb->raw_qiov, acb->qiov->niov);
-blkverify_iovec_clone(&acb->raw_qiov, qiov, acb->buf);
+qemu_iovec_clone(&acb->raw_qiov, qiov, acb->buf);
 
 bdrv_aio_readv(s->test_file, sector_num, qiov, nb_sectors,
blkverify_aio_cb, acb);
diff --git a/include/qemu-common.h b/include/qemu-common.h
index f134629..8906285 100644
--- a/include/qemu-common.h
+++ b/include/qemu-common.h
@@ -346,6 +346,8 @@ size_t qemu_iovec_from_buf(QEMUIOVector *qiov, size_t 
offset,
const void *buf, size_t bytes);
 size_t qemu_iovec_memset(QEMUIOVector *qiov, size_t offset,
   

Re: [Qemu-devel] [qemu-devel]The problem of QMP command getfd.

[Li Zhang]

On 2013年01月28日 21:28, Stefan Hajnoczi wrote:

On Mon, Jan 28, 2013 at 03:27:01PM +0800, Li Zhang wrote:

Hi all,

I am trying to executing qmp command getfd according to qmp-commands.hx.

{ "execute": "getfd", "arguments": { "fdname": "fd1" } }

Every time, it returns the error.

{
 "error": {
 "class": "GenericError",
 "desc": "No file descriptor supplied via SCM_RIGHTS"
 }
}

This error is related with SCM_RIGHTS.
I don't know about SCM at all.

Can anyone give some hints about this?

The "getfd" command allows the client to pass a file descriptor to QEMU
and give it a name.  Later that file descriptor can be used by QEMU.

The QMP client must send '{ "execute": "getfd", "arguments": { "fdname":
"fd1" } }' together with SCM_RIGHTS CMSG.  You are getting the error
because you sent the "getfd" command but forgot to include a file
descriptor using SCM_RIGHTS.

SCM_RIGHTS is a feature of UNIX domain sockets.  It allows one process
to pass a file descriptor to another process through the UNIX domain
socket.  See "man 7 unix" and "man 3 cmsg" for details.

Look at monitor.c:qmp_getfd() to understand how this works.  The QEMU
code to receive a passed file descriptor is in
qemu-char.c:unix_process_msgfd().

Thanks a lot for your detailed explanation and suggestions.
I will look into the code to understand how it works.

Thanks
--Li


Stefan

[Qemu-devel] [RFC V7 12/13] quorum: Add quorum_snapshot_reopen.

[Benoît Canet]

Signed-off-by: Benoit Canet 
---
 block/quorum.c |   20 
 1 file changed, 20 insertions(+)

diff --git a/block/quorum.c b/block/quorum.c
index 0217593..d6fef58 100644
--- a/block/quorum.c
+++ b/block/quorum.c
@@ -797,6 +797,25 @@ free_new_s_exit:
 quorum_free(&new_s);
 }
 
+static int quorum_snapshot_reopen(BlockDriverState *bs, int bdrv_flags,
+  Error **errp)
+{
+BDRVQuorumState *s = bs->file->opaque;
+int i, ret = -1;
+Error *local_err = NULL;
+BlockReopenQueue *queue = NULL;
+
+for (i = 0; i < s->total; i++) {
+queue = bdrv_reopen_queue(queue, s->bs[i], bdrv_flags);
+}
+
+ret = bdrv_reopen_multiple(queue, &local_err);
+if (local_err != NULL) {
+error_propagate(errp, local_err);
+}
+return ret;
+}
+
 static BlockDriver bdrv_quorum = {
 .format_name= "quorum",
 .protocol_name  = "quorum",
@@ -813,6 +832,7 @@ static BlockDriver bdrv_quorum = {
 .bdrv_co_is_allocated  = quorum_co_is_allocated,
 
 .bdrv_ext_snapshot_img_create = quorum_snapshot_img_create,
+.bdrv_ext_snapshot_reopen = quorum_snapshot_reopen,
 };
 
 static void bdrv_quorum_init(void)
-- 
1.7.10.4

[Qemu-devel] [PATCH 4/4] block: Move reopening of image after snapshot creation into the block drivers.

[Benoît Canet]

Protocols like quorum will be able to queue multiple reopens.

Signed-off-by: Benoit Canet 
---
 block.c   |   28 
 block/cow.c   |1 +
 block/qcow.c  |1 +
 block/qcow2.c |1 +
 block/qed.c   |1 +
 block/sheepdog.c  |1 +
 block/vmdk.c  |1 +
 block/vvfat.c |1 +
 blockdev.c|5 +++--
 include/block/block.h |2 ++
 include/block/block_int.h |4 
 11 files changed, 44 insertions(+), 2 deletions(-)

diff --git a/block.c b/block.c
index 3bebc74..9205e2d 100644
--- a/block.c
+++ b/block.c
@@ -4668,3 +4668,31 @@ void bdrv_ext_snapshot_img_create(BlockDriverState 
*old_bs,
 options, img_size,
 flags, errp);
 }
+
+int bdrv_ext_snapshot_reopen(BlockDriverState *bs, int bdrv_flags,
+ Error **errp)
+{
+Error *local_err = NULL;
+int ret = -ENOTSUP;
+
+if (!bs->file || !bs->file->drv) {
+error_setg(errp, "Block driver not reachable.");
+return ret;
+}
+
+if (!bs->file->drv->bdrv_ext_snapshot_reopen) {
+error_set(errp, QERR_BLOCK_FORMAT_FEATURE_NOT_SUPPORTED,
+  bdrv_get_format_name(bs->file),
+  bdrv_get_device_name(bs),
+  "external snapshots");
+return ret;
+}
+
+ret = bs->file->drv->bdrv_ext_snapshot_reopen(bs, bdrv_flags, &local_err);
+
+if (error_is_set(&local_err)) {
+error_propagate(errp, local_err);
+}
+
+return ret;
+}
diff --git a/block/cow.c b/block/cow.c
index ba69f35..86db134 100644
--- a/block/cow.c
+++ b/block/cow.c
@@ -348,6 +348,7 @@ static BlockDriver bdrv_cow = {
 .create_options = cow_create_options,
 
 .bdrv_ext_snapshot_img_create = bdrv_generic_ext_snapshot_img_create,
+.bdrv_ext_snapshot_reopen = bdrv_reopen,
 };
 
 static void bdrv_cow_init(void)
diff --git a/block/qcow.c b/block/qcow.c
index 423bf35..d25e7d3 100644
--- a/block/qcow.c
+++ b/block/qcow.c
@@ -892,6 +892,7 @@ static BlockDriver bdrv_qcow = {
 .create_options = qcow_create_options,
 
 .bdrv_ext_snapshot_img_create = bdrv_generic_ext_snapshot_img_create,
+.bdrv_ext_snapshot_reopen = bdrv_reopen,
 };
 
 static void bdrv_qcow_init(void)
diff --git a/block/qcow2.c b/block/qcow2.c
index 0174ae5..6b6c5af 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1719,6 +1719,7 @@ static BlockDriver bdrv_qcow2 = {
 .bdrv_check = qcow2_check,
 
 .bdrv_ext_snapshot_img_create = bdrv_generic_ext_snapshot_img_create,
+.bdrv_ext_snapshot_reopen = bdrv_reopen,
 };
 
 static void bdrv_qcow2_init(void)
diff --git a/block/qed.c b/block/qed.c
index 9857179..8fac2b8 100644
--- a/block/qed.c
+++ b/block/qed.c
@@ -1587,6 +1587,7 @@ static BlockDriver bdrv_qed = {
 .bdrv_check   = bdrv_qed_check,
 
 .bdrv_ext_snapshot_img_create = bdrv_generic_ext_snapshot_img_create,
+.bdrv_ext_snapshot_reopen = bdrv_reopen,
 };
 
 static void bdrv_qed_init(void)
diff --git a/block/sheepdog.c b/block/sheepdog.c
index 4f483b2..f74e789 100644
--- a/block/sheepdog.c
+++ b/block/sheepdog.c
@@ -2087,6 +2087,7 @@ BlockDriver bdrv_sheepdog = {
 .create_options = sd_create_options,
 
 .bdrv_ext_snapshot_img_create = bdrv_generic_ext_snapshot_img_create,
+.bdrv_ext_snapshot_reopen = bdrv_reopen,
 };
 
 static void bdrv_sheepdog_init(void)
diff --git a/block/vmdk.c b/block/vmdk.c
index 2b0acc0..93fe441 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -1697,6 +1697,7 @@ static BlockDriver bdrv_vmdk = {
 .create_options = vmdk_create_options,
 
 .bdrv_ext_snapshot_img_create = bdrv_generic_ext_snapshot_img_create,
+.bdrv_ext_snapshot_reopen = bdrv_reopen,
 };
 
 static void bdrv_vmdk_init(void)
diff --git a/block/vvfat.c b/block/vvfat.c
index 4e5f4fc..a33d08d 100644
--- a/block/vvfat.c
+++ b/block/vvfat.c
@@ -2876,6 +2876,7 @@ static BlockDriver bdrv_vvfat = {
 .protocol_name = "fat",
 
 .bdrv_ext_snapshot_img_create = bdrv_generic_ext_snapshot_img_create,
+.bdrv_ext_snapshot_reopen = bdrv_reopen,
 };
 
 static void bdrv_vvfat_init(void)
diff --git a/blockdev.c b/blockdev.c
index b1f388b..e9d235b 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -817,8 +817,9 @@ void qmp_transaction(BlockdevActionList *dev_list, Error 
**errp)
 /* We don't need (or want) to use the transactional
  * bdrv_reopen_multiple() across all the entries at once, because we
  * don't want to abort all of them if one of them fails the reopen */
-bdrv_reopen(states->new_bs, states->new_bs->open_flags & ~BDRV_O_RDWR,
-NULL);
+bdrv_ext_snapshot_reopen(states->new_bs,
+ states->new_bs->open_flags & ~BDRV_O_RDWR,
+ NULL);
 }
 
 /* success */
diff --git a/include/block

[Qemu-devel] [RFC V7 11/13] quorum: Add quorum_snapshot_img_create.

[Benoît Canet]

Signed-off-by: Benoit Canet 
---
 block/quorum.c |  188 
 1 file changed, 188 insertions(+)

diff --git a/block/quorum.c b/block/quorum.c
index ee6bc45..0217593 100644
--- a/block/quorum.c
+++ b/block/quorum.c
@@ -611,6 +611,192 @@ static coroutine_fn int quorum_co_flush(BlockDriverState 
*bs)
 return result;
 }
 
+static int quorum_parse_uint_step_next(const char *start,
+   const char *name,
+   const char separator,
+   unsigned long long *value,
+   char **next,
+   Error **errp)
+{
+int ret;
+if (start[0] == '\0') {
+error_set(errp, QERR_MISSING_PARAMETER, name);
+return -EINVAL;
+}
+ret = parse_uint(start, value, next, 10);
+if (ret < 0) {
+error_set(errp, QERR_INVALID_PARAMETER_TYPE, name, "int");
+return ret;
+}
+if (**next != separator) {
+error_set(errp, ERROR_CLASS_GENERIC_ERROR,
+  "%c separator required after %s",
+  separator, name);
+return -EINVAL;
+}
+*next += 1;
+return 0;
+}
+
+static int quorum_parse_url(BDRVQuorumState *s, const char *url, Error **errp)
+{
+int i, j, k, len, ret = 0;
+char *a, *b, *names;
+const char *start;
+bool escape;
+
+/* Parse the quorum: prefix */
+if (!strstart(url, "quorum:", &start)) {
+error_set(errp, ERROR_CLASS_GENERIC_ERROR,
+  "Invalid quorum url");
+return -EINVAL;
+}
+
+/* Get threshold */
+ret = quorum_parse_uint_step_next(start, "threshold", '/',
+  &s->threshold, &a, errp);
+if (ret < 0) {
+return ret;
+}
+
+/* Get total */
+ret = quorum_parse_uint_step_next(a, "total", ':',
+  &s->total, &b, errp);
+if (ret < 0) {
+return ret;
+}
+
+if (s->threshold < 1) {
+error_set(errp, QERR_INVALID_PARAMETER_VALUE,
+  "threshold", "value >= 1");
+return -ERANGE;
+}
+
+if (s->total < 2) {
+error_set(errp, QERR_INVALID_PARAMETER_VALUE, "total", "value >= 2");
+return -ERANGE;
+}
+
+if (s->threshold > s->total) {
+error_set(errp, ERROR_CLASS_GENERIC_ERROR,
+  "threshold <= total must be true");
+return -ERANGE;
+}
+
+s->bs = g_malloc0(sizeof(BlockDriverState *) * s->total);
+/* Two allocations for all filenames: simpler to free */
+s->filenames = g_malloc0(sizeof(char *) * s->total);
+names = g_strdup(b);
+
+/* Get the filenames pointers */
+escape = false;
+s->filenames[0] = names;
+len = strlen(names);
+for (i = j = k = 0; i < len && j < s->total; i++) {
+/* separation between two files */
+if (!escape && names[i] == ':') {
+char *prev = s->filenames[j];
+prev[k] = '\0';
+s->filenames[++j] = prev + k + 1;
+k = 0;
+continue;
+}
+
+escape = !escape && names[i] == '\\';
+
+/* if we are not escaping copy */
+if (!escape) {
+s->filenames[j][k++] = names[i];
+}
+}
+/* terminate last string */
+s->filenames[j][k] = '\0';
+
+return j + 1;
+}
+
+static int quorum_validate_url(BDRVQuorumState *s, int ret, Error **errp)
+{
+if (ret == s->total) {
+return 0;
+}
+
+error_set(errp, ERROR_CLASS_GENERIC_ERROR,
+  "Number of provided file must be equal to total");
+return -EINVAL;
+}
+
+static void quorum_free(BDRVQuorumState *s)
+{
+g_free(s->filenames[0]);
+g_free(s->filenames);
+s->filenames = NULL;
+g_free(s->bs);
+}
+
+static bool quorum_are_states_compatibles(BDRVQuorumState *a,
+  BDRVQuorumState *b,
+  Error **errp)
+{
+if (a->threshold != b->threshold) {
+error_set(errp, ERROR_CLASS_GENERIC_ERROR,
+  "Theshold must be the same as previously");
+return false;
+}
+
+if (a->total != b->total) {
+error_set(errp, ERROR_CLASS_GENERIC_ERROR,
+  "Total must be the same as previously");
+return false;
+}
+
+return true;
+
+}
+
+static void quorum_snapshot_img_create(BlockDriverState *bs,
+   const char *filename, const char *fmt,
+   const char *base_filename,
+   const char *base_fmt,
+   char *options, uint64_t img_size,
+   int flags, Error **errp)
+{
+BDRVQuorumState *s = bs->opaque;
+int i;
+int ret = 0;
+bool compatible;
+BDRVQuorumState new_s;
+
+

[Qemu-devel] [PATCH 1/4] block: Move external snapshot image creation in the block drivers.

[Benoît Canet]

This patch will allow protocols to implements snapshots as the image creation
is now delegated to the block driver.

Signed-off-by: Benoit Canet 
---
 block.c   |   42 ++
 block/blkdebug.c  |2 ++
 block/blkverify.c |2 ++
 block/bochs.c |2 ++
 block/cloop.c |2 ++
 block/cow.c   |2 ++
 block/curl.c  |   10 ++
 block/dmg.c   |2 ++
 block/gluster.c   |8 
 block/iscsi.c |2 ++
 block/nbd.c   |6 ++
 block/parallels.c |2 ++
 block/qcow.c  |2 ++
 block/qcow2.c |2 ++
 block/qed.c   |2 ++
 block/raw-posix.c |   10 ++
 block/raw-win32.c |6 ++
 block/raw.c   |2 ++
 block/rbd.c   |2 ++
 block/sheepdog.c  |2 ++
 block/vdi.c   |2 ++
 block/vmdk.c  |2 ++
 block/vpc.c   |2 ++
 block/vvfat.c |2 ++
 blockdev.c|8 
 include/block/block.h |   15 +++
 include/block/block_int.h |8 
 27 files changed, 145 insertions(+), 4 deletions(-)

diff --git a/block.c b/block.c
index 6fa7c90..af22ee8 100644
--- a/block.c
+++ b/block.c
@@ -4626,3 +4626,45 @@ out:
 bdrv_delete(bs);
 }
 }
+
+void bdrv_generic_ext_snapshot_img_create(BlockDriverState *bs,
+  const char *filename,
+  const char *fmt,
+  const char *base_filename,
+  const char *base_fmt,
+  char *options,
+  uint64_t img_size,
+  int flags,
+  Error **errp)
+{
+bdrv_img_create(filename, fmt, base_filename, base_fmt, options, img_size,
+flags, errp);
+}
+
+void bdrv_ext_snapshot_img_create(BlockDriverState *old_bs,
+  const char *filename, const char *fmt,
+  const char *base_filename,
+  const char *base_fmt,
+  char *options, uint64_t img_size,
+  int flags, Error **errp)
+{
+if (!old_bs || !old_bs->file || !old_bs->file->drv) {
+error_setg(errp, "Block driver not reachable.");
+return;
+}
+
+if (!old_bs->file->drv->bdrv_ext_snapshot_img_create) {
+error_set(errp, QERR_BLOCK_FORMAT_FEATURE_NOT_SUPPORTED,
+  bdrv_get_format_name(old_bs->file),
+  bdrv_get_device_name(old_bs),
+  "external snapshots");
+return;
+}
+
+old_bs->file->drv->bdrv_ext_snapshot_img_create(old_bs->file,
+filename, fmt,
+base_filename,
+base_fmt,
+options, img_size,
+flags, errp);
+}
diff --git a/block/blkdebug.c b/block/blkdebug.c
index 6f74637..dc99401 100644
--- a/block/blkdebug.c
+++ b/block/blkdebug.c
@@ -584,6 +584,8 @@ static BlockDriver bdrv_blkdebug = {
 .bdrv_debug_breakpoint  = blkdebug_debug_breakpoint,
 .bdrv_debug_resume  = blkdebug_debug_resume,
 .bdrv_debug_is_suspended= blkdebug_debug_is_suspended,
+
+.bdrv_ext_snapshot_img_create = bdrv_generic_ext_snapshot_img_create,
 };
 
 static void bdrv_blkdebug_init(void)
diff --git a/block/blkverify.c b/block/blkverify.c
index a7dd459..2726ed0 100644
--- a/block/blkverify.c
+++ b/block/blkverify.c
@@ -356,6 +356,8 @@ static BlockDriver bdrv_blkverify = {
 .bdrv_aio_readv = blkverify_aio_readv,
 .bdrv_aio_writev= blkverify_aio_writev,
 .bdrv_aio_flush = blkverify_aio_flush,
+
+.bdrv_ext_snapshot_img_create = bdrv_generic_ext_snapshot_img_create,
 };
 
 static void bdrv_blkverify_init(void)
diff --git a/block/bochs.c b/block/bochs.c
index 1b1d9cd..baea957 100644
--- a/block/bochs.c
+++ b/block/bochs.c
@@ -233,6 +233,8 @@ static BlockDriver bdrv_bochs = {
 .bdrv_open = bochs_open,
 .bdrv_read  = bochs_co_read,
 .bdrv_close= bochs_close,
+
+.bdrv_ext_snapshot_img_create = bdrv_generic_ext_snapshot_img_create,
 };
 
 static void bdrv_bochs_init(void)
diff --git a/block/cloop.c b/block/cloop.c
index 5a0d0d8..a74d9aa 100644
--- a/block/cloop.c
+++ b/block/cloop.c
@@ -185,6 +185,8 @@ static BlockDriver bdrv_cloop = {
 .bdrv_open  = cloop_open,
 .bdrv_read  = cloop_co_read,
 .bdrv_close = cloop_close,
+

[Qemu-devel] [RFC V7 09/13] quorum: Add quorum_co_is_allocated.

[Benoît Canet]

Signed-off-by: Benoit Canet 
---
 block/quorum.c |   53 +
 1 file changed, 53 insertions(+)

diff --git a/block/quorum.c b/block/quorum.c
index 6254f95..ed97a76 100644
--- a/block/quorum.c
+++ b/block/quorum.c
@@ -135,6 +135,22 @@ static int quorum_sha256_compare(QuorumVoteValue *a, 
QuorumVoteValue *b)
 return memcmp(a, b, HASH_LENGTH);
 }
 
+static int quorum_long_compare(QuorumVoteValue *a, QuorumVoteValue *b)
+{
+unsigned long i = a->l;
+unsigned long j = b->l;
+
+if (i < j) {
+return -1;
+}
+
+if (i > j) {
+return 1;
+}
+
+return 0;
+}
+
 static QuorumAIOCB *quorum_aio_get(BDRVQuorumState *s,
BlockDriverState *bs,
QEMUIOVector *qiov,
@@ -527,6 +543,42 @@ static void quorum_invalidate_cache(BlockDriverState *bs)
 }
 }
 
+static int coroutine_fn quorum_co_is_allocated(BlockDriverState *bs,
+   int64_t sector_num,
+   int nb_sectors,
+   int *pnum)
+{
+BDRVQuorumState *s = bs->opaque;
+QuorumVoteVersion *winner = NULL;
+QuorumVotes result_votes, num_votes;
+QuorumVoteValue result_value, num_value;
+int i, result = 0, num;
+
+QLIST_INIT(&result_votes.vote_list);
+QLIST_INIT(&num_votes.vote_list);
+result_votes.compare = quorum_long_compare;
+num_votes.compare = quorum_long_compare;
+
+for (i = 0; i < s->total; i++) {
+result = bdrv_co_is_allocated(s->bs[i], sector_num, nb_sectors, &num);
+result_value.l = result;
+num_value.l = num;
+quorum_count_vote(&result_votes, &result_value, i);
+quorum_count_vote(&num_votes, &num_value, i);
+}
+
+winner = quorum_get_vote_winner(&result_votes);
+result = winner->value.l;
+
+winner = quorum_get_vote_winner(&num_votes);
+*pnum = winner->value.l;
+
+quorum_free_vote_list(&result_votes);
+quorum_free_vote_list(&num_votes);
+
+return result;
+}
+
 static BlockDriver bdrv_quorum = {
 .format_name= "quorum",
 .protocol_name  = "quorum",
@@ -538,6 +590,7 @@ static BlockDriver bdrv_quorum = {
 .bdrv_aio_readv = quorum_aio_readv,
 .bdrv_aio_writev= quorum_aio_writev,
 .bdrv_invalidate_cache = quorum_invalidate_cache,
+.bdrv_co_is_allocated  = quorum_co_is_allocated,
 };
 
 static void bdrv_quorum_init(void)
-- 
1.7.10.4

[Qemu-devel] QEMU buildbot maintenance state (was: Re: KVM call agenda for 2013-01-29)

[Daniel Gollub]

Hi Andreas,

thanks for bringing this topic up.

January was quite busy month for me so far I could only handle minor changes
on the buildbot. I hesitate to make larger changes to avoid I break other
stuff. So I just queued them up once I have more time (beginning in February
or so)

I bounced now all open request from you and the suggestion of Gerd (with
regards to append the log on the mail) to Christian Berendt - who is also
maintaining the buildbot on buildbot.b1-systems.de

On Monday, January 28, 2013 02:02:27 PM Andreas Färber wrote:
> Am 28.01.2013 11:59, schrieb Juan Quintela:
> > Please send in any agenda topics you are interested in.
>
> Buildbot situation:
> * Trees are not being added/updated in a timely fashion

Primary reason why I hesitated to add new trees in the last weeks is pretty
simple:
 - we run out of buildslave power
 - lack of time to setup new buildslaves


If anyone has some spare time and could provide us for a longer period
buildslaves please drop me and Christian a mail for further instruction.



> * Insufficient build test coverage of trees (ppc, s390x, MinGW, BSD)
>
> http://buildbot.b1-systems.de/qemu/builders


With regards to the build test coverage for all trees we would have to
refactor the configuration a lot to make it more easier to add and maintain it
in an easy way.

If you have some time left feel free to come up with a patch for that.
This is on my list - but it requires more time then I have available right now
to make it "right".


(The failing macosx buildslave is known issue on the MacOSX site. The
maintainer has also to investigate that at some later point due to lack of
sufficient time.)


>
> Stefan H. has access to some of the build slaves but not to the main
> buildbot server for configuration, it seems.

JFYI, the main buildbot configuration which controls everything (beside
buildslave credentials) is accessible to everyone:
http://people.b1-systems.de/~gollub/buildbot/

If you are familiar with buildbot feel free to incorporate your suggested
changes directly on a copy and send me or Christian the diff so we just have
to review and apply it.

>
> If Daniel does not have sufficient time to administer it, can we maybe
> have that set up on qemu.org instead, with more than one person that has
> access to it?

JFYI, I just requested if I am allowed to grant Stefan root access to our box.
I would not mind to give him access - but need to check back with our IT
first.

Best Regards,
Daniel

--
Daniel Gollub
Linux Consultant & Developer
Tel.: +49-160 47 73 970
Mail: gol...@b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

signature.asc
Description: This is a digitally signed message part.

Re: [Qemu-devel] [Libvirt][QEMU][HLFS]How to test HLFS driver for Libvirt

[MORITA Kazutaka]

At Mon, 28 Jan 2013 21:18:42 +0800,
harryxiyou wrote:
> 
> Hi Morita and other developers,
> 
> I have programed HLFS(HDFS based Log-structured FileSystem) driver for Libvirt
> according to Morita's patch(commit 036ad5052b43fe9f0d197e89fd16715950408e1d)
> for Libvirt, which my patch is not for Libvirt latest version but the
> version of Morita's
> patch time.I have called back my git tree to
> commit 036ad5052b43fe9f0d197e89fd16715950408e1d, then i develop this patch.
> My patch is now available at
> http://cloudxy.googlecode.com/svn/branches/hlfs/person/harry/hlfs/hlfs_driver_for_libvirt_v1.patch
> 
> Therefore, i am not clear about how to test it. How could i know
> whether it works well for
> libvirt&QEMU? Could Morita (Or other developers) give me some suggestions?

I'm not familiar with HLFS at all.  Sheepdog examples I explained to
you in another mail may help you, but I cannot give you any other
suggestions about HLFS.

Thanks,

Kazutaka

Re: [Qemu-devel] [PATCH v3] PIIX3: reset the VM when the Reset Control Register's RCPU bit gets set

[Michael S. Tsirkin]

On Thu, Jan 24, 2013 at 10:31:20AM +0100, Laszlo Ersek wrote:
> >From :
> 
>   Traditional PCI config space access is achieved by writing a 32 bit
>   value to io port 0xcf8 to identify the bus, device, function and config
>   register. Port 0xcfc then contains the register in question. But if you
>   write the appropriate pair of magic values to 0xcf9, the machine will
>   reboot. Spectacular! And not standardised in any way (certainly not part
>   of the PCI spec), so different chipsets may have different requirements.
>   Booo.
> 
> In the PIIX3 spec, IO port 0xcf9 is specified as the Reset Control
> Register. Bit 1 (System Reset, SRST) would normally differentiate between
> soft reset and hard reset, but we ignore the difference beyond allowing
> the guest to read it back.
> 
> RHBZ reference: 890459
> 
> This patch introduces the following overlap between the preexistent
> "pci-conf-idx" region and the "piix3-reset-control" region just being
> added. Partial output from "info mtree":
> 
>   I/O
>   - (prio 0, RW): io
> 0cf8-0cfb (prio 0, RW): pci-conf-idx
> 0cf9-0cf9 (prio 1, RW): piix3-reset-control
> 
> I sanity-checked the patch by booting a RHEL-6.3 guest and found no
> problems. I summoned gdb and set a breakpoint on rcr_write() in order to
> gather a bit more confidence. Relevant frames of the stack:
> 
>   kvm_handle_io (port=3321, data=0x7f3f5f3de000, direction=1, size=1,
>  count=1) [kvm-all.c:1422]
> cpu_outb (addr=3321, val=6 '\006')  [ioport.c:289]
>   ioport_write (index=0, address=3321, data=6)   [ioport.c:83]
> ioport_writeb_thunk (opaque=0x7f3f622c4680, addr=3321, data=6)
> [ioport.c:212]
>   memory_region_iorange_write (iorange=0x7f3f622c4680, offset=0,
>width=1, data=6) [memory.c:439]
> access_with_adjusted_size (addr=0, value=0x7f3f531fbac0,
>size=1, access_size_min=1,
>access_size_max=4,
>access=0x7f3f5f6e0f90
>,
>opaque=0x7f3f6227b668)
> [memory.c:364]
>   memory_region_write_accessor (opaque=0x7f3f6227b668, addr=0,
> value=0x7f3f531fbac0, size=1,
> shift=0, mask=255)
> [memory.c:334]
> rcr_write (opaque=0x7f3f6227afb0, addr=0, val=6, len=1)
>[hw/piix_pci.c:498]
> 
> The dispatch happens in ioport_write(); "index=0" means byte-wide access:
> 
> static void ioport_write(int index, uint32_t address, uint32_t data)
> {
> static IOPortWriteFunc * const default_func[3] = {
> default_ioport_writeb,
> default_ioport_writew,
> default_ioport_writel
> };
> IOPortWriteFunc *func = ioport_write_table[index][address];
> if (!func)
> func = default_func[index];
> func(ioport_opaque[address], address, data);
> }
> 
> The "ioport_write_table" and "ioport_opaque" arrays describe the flattened
> IO port space. The first array is less interesting (it selects a thunk
> function). The "ioport_opaque" array is interesting because it decides how
> writing to the port is implemented ultimately.
> 
> 4-byte wide access to 0xcf8 (pci-conf-idx):
> 
>   (gdb) print ioport_write_table[2][0xcf8]
>   $1 = (IOPortWriteFunc *) 0x7f3f5f6d99ba 
> 
>   (gdb) print \
> ((struct MemoryRegionIORange*)ioport_opaque[0xcf8])->mr->ops.write
>   $2 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
>0x7f3f5f5575cb 
> 
> 1-byte wide access to 0xcf9 (piix3-reset-control):
> 
>   (gdb) print ioport_write_table[0][0xcf9]
>   $3 = (IOPortWriteFunc *) 0x7f3f5f6d98d0 
> 
>   (gdb) print \
> ((struct MemoryRegionIORange*)ioport_opaque[0xcf9])->mr->ops.write
>   $4 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
>0x7f3f5f6b42f1 
> 
> The higher priority of "piix3-reset-control" ensures that the 0xcf9
> entries in ioport_write_table / ioport_opaque will always belong to it,
> independently of its relative registration order versus "pci-conf-idx".
> 
> Signed-off-by: Laszlo Ersek 

I have tweaked whitespace a bit and applied it in my tree.
Thanks!

> ---
> v2->v3:
> - don't touch piix3_post_load(); take the RCR as it comes (Stefan).
>   Diff against v2:
> 
>   diff --git a/hw/piix_pci.c b/hw/piix_pci.c
>   index 38a1027..4c97a84 100644
>   --- a/hw/piix_pci.c
>   +++ b/hw/pi

Re: [Qemu-devel] [PATCH v3] PIIX3: reset the VM when the Reset Control Register's RCPU bit gets set

[Kevin Wolf]

Am 25.01.2013 18:23, schrieb Peter Maydell:
> On 25 January 2013 17:20, Laszlo Ersek  wrote:
>> The subscript operator [] is used here in the type name of a compound
>> literal which is probably not what the script intends to catch.
>>
>>   1945  # check for spacing round square brackets; allowed:
>>   1946  #  1. with a type on the left -- int [] a;
>>
>> The code in question was copied from "docs/migration.txt" and seems to
>> match existing practice:
>>
>>   git grep -E '(VMStateField|VMStateSubsection) \[]' \
>>   | wc -l
>>
>>   139
> 
> On the other hand the usage without the space is in the
> majority:
> 
> git grep -E '(VMStateField|VMStateSubsection)\[]' | wc -l
>  218

Means that it's about 60:40. Shouldn't we simply allow both variants in
such cases?

Kevin

Re: [Qemu-devel] [Libvirt][QEMU][HLFS]How to test HLFS driver for Libvirt

[harryxiyou]

On Mon, Jan 28, 2013 at 10:44 PM, MORITA Kazutaka
 wrote:
[...]
> I'm not familiar with HLFS at all.  Sheepdog examples I explained to
> you in another mail may help you, but I cannot give you any other
> suggestions about HLFS.
>

Thanks for your reminder, i have found this email.
Therefore, could you please explain how Sheepdog driver for Libvirt
communicate with QEMU?

Thanks for your always help ;-)

-- 
Thanks
Harry Wei

Re: [Qemu-devel] QEMU buildbot maintenance state

[Andreas Färber]

Hi Daniel,

Am 28.01.2013 15:29, schrieb Daniel Gollub:
> thanks for bringing this topic up.
> 
> January was quite busy month for me so far I could only handle minor changes 
> on the buildbot. I hesitate to make larger changes to avoid I break other 
> stuff. So I just queued them up once I have more time (beginning in February 
> or so)
[snip]

Some kind of reply indicating so would've been nice, you were already
CC'ed last year a few times. ;)

Anyway, my point is that we are approaching Hard Freeze and seeing
weekly pulls with recurring breakages on one or another platform (pci on
ppc, s390x on mingw32). Some people have been assuming that if they
don't get mails from the build bots then their tree is okay to merge.

Our shortened release cycle leads to two weeks of Soft Freeze where
everyone pushes their queues before Feb 1 and most breakages occur.
During Hard Freeze we can still try to fix anything the bots report, but
catching errors before they land in master would be better:

At QEMU Summit Anthony requested that each submaintainer's tree be added
to the buildbot system; if there are as you now indicate build power
shortages, I suggest you specify what exactly is needed, maybe someone
in the community can help out. To me it was not clear at least. The
revived ppc slave is hopefully not running into a bottleneck yet. :)

I'll take a look at the config later.

Thanks,
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] [Libvirt][QEMU][HLFS]How to test HLFS driver for Libvirt

[harryxiyou]

On Mon, Jan 28, 2013 at 11:06 PM, harryxiyou  wrote:
> On Mon, Jan 28, 2013 at 10:44 PM, MORITA Kazutaka
>  wrote:
> [...]
>> I'm not familiar with HLFS at all.  Sheepdog examples I explained to
>> you in another mail may help you, but I cannot give you any other
>> suggestions about HLFS.
>>
>
> Thanks for your reminder, i have found this email.
> Therefore, could you please explain how Sheepdog driver for Libvirt
> communicate with QEMU?
>
> Thanks for your always help ;-)
>

After i did the test way you said, i got following errors.

$ ./virsh vol-create -f sheepdog.xml
error： Failed to reconnect to the hypervisor
error： invalid connection
error： internal error Unable to locate libvirtd daemon in $PATH

$ cat sheepdog.xml

myvol
sheep/myvol


53687091200
53687091200

sheepdog:myvol


00
0
0



Any suggestions? Thanks in advance ;-)


-- 
Thanks
Harry Wei

Re: [Qemu-devel] [PATCH qom-cpu for-1.4?] kvm: Pass CPUState to kvm_on_sigbus_vcpu()

[Andreas Färber]

Am 28.01.2013 14:50, schrieb Gleb Natapov:
> On Fri, Jan 25, 2013 at 04:55:29PM +0100, Andreas Färber wrote:
>> Since commit 20d695a9254c1b086a456d3b79a3c311236643ba (kvm: Pass
>> CPUState to kvm_arch_*) CPUArchState is no longer needed.
>>
>> Allows to change qemu_kvm_eat_signals() argument as well.
>>
>> Signed-off-by: Andreas Färber 
> Reviewed-by: Gleb Natapov 

Thanks, applied to qom-cpu:
https://github.com/afaerber/qemu-cpu/commits/qom-cpu

Background was:
https://lists.nongnu.org/archive/html/qemu-devel/2013-01/msg03087.html

<<<
[...] qemu_init_vcpu() still operates on CPUArchState and thus cannot be
moved into CPUClass yet. The reason is that
cpus.c:qemu_kvm_cpu_thread_fn sets cpu_single_env, and I do not see a
solution for that - suggestions or patches welcome.

However, I see that kvm-all.c:kvm_on_sigbus_vcpu() can be switched to
CPUState now, so that cpus.c:qemu_kvm_eat_signals() can be changed to
CPUState, used from cpus.c:qemu_kvm_wait_io_event().
But cpus.c:cpu_thread_is_idle() still uses env->halted, which is blocked
by the search for an acceptable solution to flush the TLB at CPUState
level (exec.c:cpu_common_post_load()).
>>>

A less elegant but working solution is on my qom-cpu-8 branch (based off
qom-cpu-next): I introduced a void *env_ptr CPUState field. While
potentially opening a can of worms I wanted to avoid, it allows us to
defer finding a solution to the target_ulong-dependent TLB some more.

Regards,
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 qom-cpu for-1.4] cpu: Unconditionalize CPUState fields

[Andreas Färber]

Am 28.01.2013 15:00, schrieb Paolo Bonzini:
> Il 25/01/2013 16:27, Andreas Färber ha scritto:
>> Commits fc8c5b8c41ee5ba69d7a2be63b02a08c7b0b155b (Makefile.user: Define
>> CONFIG_USER_ONLY for libuser/) and
>> dd83b06ae61cfa2dc4381ab49f365bd0995fc930 (qom: Introduce CPU class)
>> specifically prepared the qom/cpu.c file to be compiled differently for
>> softmmu and *-user. This broke as part of build system refactorings
>> while CPU patches were in flight, adding conditional fields
>> kvm_fd (8737c51c0444f832c4e97d7eb7540eae457e08e4) and
>> kvm_vcpu_dirty (20d695a9254c1b086a456d3b79a3c311236643ba) for softmmu.
>>
>> linux-user and bsd-user would therefore get a CPUState type with
>> instance_size ~8 bytes shorter than expected.
>> Fix this by unconditionally having the fields in CPUState.
>>
>> In practice, target-specific CPU types' instance_size would compensate
>> this, and upstream qom/cpu.c does not yet touch any affected field.
>>
>> Cc: Paolo Bonzini 
>> Signed-off-by: Andreas Färber 
> 
> Reviewed-by: Paolo Bonzini 

Thanks, applied to qom-cpu:
https://github.com/afaerber/qemu-cpu/commits/qom-cpu

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] Can KVM notify VM to execute some operations?

[独孤败]

I know that the VM can use the VMCALL instruction to notify the KVM to
do some operations.
My question is that if the KVM want to notify the VM to execute some
operations, which instrction should be use?
Or is there any other method to realize this?

--
Best Regards!

[Qemu-devel] Can KVM notify VM to execute some operations?

[独孤败]

I know that the VM can use the VMCALL instruction to notify the KVM to do
some operations.
My question is that if the KVM want to notify the VM to execute some
operations, which instrction should be use?
Or is there any other method to realize this?

-- 
Best Regards!