Re: [Qemu-devel] oprofile on qemu

2011-11-23 Thread 陳韋任
On Tue, Nov 22, 2011 at 08:23:32AM -0500, Xin Tong wrote:
 Is there a way to profile QEMU's code cache ?

  What do you try to profile? The execution time in the code
cache?

P.S. The subject is a little misleading. Oprofile is a tool.
 Do you specify you want use Oprofile only?

Regards,
chenwj

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



Re: [Qemu-devel] [PATCH] vdi: Fix memory leak

2011-11-23 Thread Kevin Wolf
Am 22.11.2011 19:37, schrieb Stefan Weil:
 Am 22.11.2011 17:16, schrieb Kevin Wolf:
 The block map is allocated in vdi_open, but was never freed.

 Signed-off-by: Kevin Wolfkw...@redhat.com
 ---
 Applies on top if the migration blocker series.

   block/vdi.c |3 +++
   1 files changed, 3 insertions(+), 0 deletions(-)

 diff --git a/block/vdi.c b/block/vdi.c
 index 7dda522..02da6b4 100644
 --- a/block/vdi.c
 +++ b/block/vdi.c
 @@ -949,6 +949,9 @@ static int vdi_create(const char *filename, 
 QEMUOptionParameter *options)
   static void vdi_close(BlockDriverState *bs)
   {
   BDRVVdiState *s = bs-opaque;
 +
 +g_free(s-bmap);
 +
   migrate_del_blocker(s-migration_blocker);
   error_free(s-migration_blocker);
   }
 
 If vdi_close is called after a jump to label fail_free_bmap,
 g_free(s-bmap) will be called twice.

bdrv_close() may only ever be called on a successfully opened image.

In fact, block.c already ensures this. The BDRVVdiState would already be
freed in the failing bdrv_open_common() and bs-drv would be set to
NULL, so that an invalid bdrv_close() would end up doing nothing.

 Setting s-bmap = NULL after g_free in fail_free_bmap
 would be safer.
 
 Otherwise your patch is fine. If you send an update, you
 can add
 
 Reviewed-by: Stefan Weil s...@weilnetz.de

Thanks.

Kevin



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

2011-11-23 Thread Stefan Hajnoczi
On Wed, Nov 23, 2011 at 3:20 AM,  q...@buildbot.b1-systems.de wrote:
 The Buildbot has detected a new failure on builder block_x86_64_debian_6_0 
 while building qemu.
 Full details are available at:
  http://buildbot.b1-systems.de/qemu/builders/block_x86_64_debian_6_0/builds/100

Perhaps you were part-way through merging a series?  Just wanted to
let you know that buildbot noticed your block tree fails to build.

Stefan



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

2011-11-23 Thread Stefan Hajnoczi
On Wed, Nov 23, 2011 at 1:41 AM, Alexander Graf ag...@suse.de wrote:

 On 23.11.2011, at 03:04, q...@buildbot.b1-systems.de wrote:

 The Buildbot has detected a new failure on builder block_openbsd_current 
 while building qemu.
 Full details are available at:
 http://buildbot.b1-systems.de/qemu/builders/block_openbsd_current/builds/61

 Buildbot URL: http://buildbot.b1-systems.de/qemu/

 Buildslave for this Build: brad_openbsd_current

 Build Reason: The Nightly scheduler named 'nightly_block' triggered this 
 build

 I just realized that this is the block branch. Shouldn't Kevin be CC'ed on 
 mails there?

Hey, I just responded to another buildbot email and addressed it to Kevin.

Yes, it would be useful to CC kwolf on block, mst on PCI/virtio, and so on.

Daniel: Is it possible to CC the subsystem maintainers on their
respective trees?  If you need a list of tree - maintainer/email I
can send it to you.

Stefan



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

2011-11-23 Thread Stefan Hajnoczi
On Tue, Nov 22, 2011 at 11:53 PM, Alexander Graf ag...@suse.de wrote:

 On 23.11.2011, at 01:09, q...@buildbot.b1-systems.de wrote:

 The Buildbot has detected a new failure on builder default_x86_64_rhel5 
 while building qemu.
 Full details are available at:
 http://buildbot.b1-systems.de/qemu/builders/default_x86_64_rhel5/builds/78

 Buildbot URL: http://buildbot.b1-systems.de/qemu/

 Buildslave for this Build: kraxel_rhel5

 Build Reason: The Nightly scheduler named 'nightly_default' triggered this 
 build
 Build Source Stamp: [branch master] HEAD
 Blamelist:

 BUILD FAILED: failed compile

  LINK  i386-softmmu/qemu-system-i386

 /usr/bin/ld: exec.o: relocation R_X86_64_TPOFF32 against 
 `tls__cpu_single_env' can not be used when making a shared object; recompile 
 with -fPIC
 exec.o: could not read symbols: Bad value
 collect2: ld returned 1 exit status
 make[1]: *** [qemu-system-i386] Error 1
 make: *** [subdir-i386-softmmu] Error 2

This is the PIE issue that has been mentioned on the list.

Stefan



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

2011-11-23 Thread Stefan Hajnoczi
On Wed, Nov 23, 2011 at 8:34 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
 On Wed, Nov 23, 2011 at 3:20 AM,  q...@buildbot.b1-systems.de wrote:
 The Buildbot has detected a new failure on builder block_x86_64_debian_6_0 
 while building qemu.
 Full details are available at:
  http://buildbot.b1-systems.de/qemu/builders/block_x86_64_debian_6_0/builds/100

 Perhaps you were part-way through merging a series?  Just wanted to
 let you know that buildbot noticed your block tree fails to build.

Your reply to the copy-on-read series mentions that
bdrv_co_is_allocated is not merged yet.  That explains this temporary
build failure.

Stefan



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

2011-11-23 Thread Kevin Wolf
Am 23.11.2011 09:34, schrieb Stefan Hajnoczi:
 On Wed, Nov 23, 2011 at 3:20 AM,  q...@buildbot.b1-systems.de wrote:
 The Buildbot has detected a new failure on builder block_x86_64_debian_6_0 
 while building qemu.
 Full details are available at:
  
 http://buildbot.b1-systems.de/qemu/builders/block_x86_64_debian_6_0/builds/100
 
 Perhaps you were part-way through merging a series?  Just wanted to
 let you know that buildbot noticed your block tree fails to build.

I started merging with the wrong series, so a dependency is missing.

Kevin



Re: [Qemu-devel] [Bug 887883] Re: Coverity scan revealed defects

2011-11-23 Thread Alex Jia
Markus, I think it will silence Coverity complain, 
that sounds good to me, thanks.

Regards,
Alex

- Original Message -
From: Markus Armbruster arm...@redhat.com
To: Bug 887883 887...@bugs.launchpad.net
Cc: qemu-devel@nongnu.org
Sent: Wednesday, November 23, 2011 3:51:10 PM
Subject: Re: [Qemu-devel] [Bug 887883] Re: Coverity scan revealed defects

Alex Jia 887...@bugs.launchpad.net writes:

 This is latest result on qemu-1.0-rc3, and I notice that 'RESOURCE_LEAK'
 is 10 now:

RESOURCE_LEAK is crippled right now, because Coverity knows nothing
about glib.  I started teaching it, and I intend to share when ready.




Re: [Qemu-devel] [Android-virt] plans for QEMU support for KVM on ARM

2011-11-23 Thread Paolo Bonzini

On 11/22/2011 04:19 PM, Peter Maydell wrote:

  * coroutine implementation doesn't cope if libc provides a makecontext()
that returns ENOSYS (so we abort on startup)


I have a patch that replaces makecontext() with sigaltstack(), i.e. 
going from nice code that does not work to hideous code that works.


I had not submitted it yet because it does not help for OpenBSD so we 
would need anyway coroutine-gthread.c, and because I would like to test 
it more thoroughly on non-Linux hosts.  If anyone can help with the 
testing, it is at git://github.com/bonzini/qemu.git branch coroutine-fix.



 * the MAP_FIXED static codegen buffer is put at an address which overlaps
   the glibc heap so we crash about 50% of the time


For 1.1 we can just use USE_STATIC_CODE_GEN_BUFFER.  It should not have 
major problems on Linux, since it is already tested for linux-user. 
That leaves out Windows of course.


Paolo




Re: [Qemu-devel] linux-user crashing in multi-threaded programs

2011-11-23 Thread 陳韋任
On Mon, Nov 21, 2011 at 10:11:37AM +, Peter Maydell wrote:
 On 21 November 2011 10:07, Alexander Graf ag...@suse.de wrote:
  On 21.11.2011, at 10:59, Peter Maydell wrote:
  You can hit this bug even single-threaded or in system mode:
  it's just that aggressively multi-threaded user apps are the
  easiest way to trigger it. So I don't think we can ever use
  the tb-unlinking code safely.
 
  Not sure I understand. I thought it's a race between multiple
 threads trying to chain/unchain TBs at the same time? How can
  that happen in system or single-threaded mode?
 
 It's a race between (a) a thread executing code and (b) any
 other thread or signal handler that calls cpu_exit(). So (b)
 can be the IO thread, or the linux-user host_signal_handler().

  Would it be a good idea to write this as a comment about
cpu_unlink_tb? 

Regards,
chenwj

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



Re: [Qemu-devel] [Android-virt] plans for QEMU support for KVM on ARM

2011-11-23 Thread Peter Maydell
On 23 November 2011 08:45, Paolo Bonzini pbonz...@redhat.com wrote:
 On 11/22/2011 04:19 PM, Peter Maydell wrote:
  * the MAP_FIXED static codegen buffer is put at an address which overlaps
   the glibc heap so we crash about 50% of the time

 For 1.1 we can just use USE_STATIC_CODE_GEN_BUFFER.  It should not have
 major problems on Linux, since it is already tested for linux-user. That
 leaves out Windows of course.

This raises the question of why we don't use the static buffer everywhere.
Presumably there was a disadvantage that caused us to move to the dynamic
mmap for system mode...

(I don't actually think it should be very hard to make the ARM code
cope with the idea that jumps into host code might be long range.)

-- PMM



Re: [Qemu-devel] [PATCH v2 7/8] block: core copy-on-read logic

2011-11-23 Thread Stefan Hajnoczi
On Wed, Nov 23, 2011 at 4:42 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote:
 On Thu, Nov 17, 2011 at 9:40 PM, Stefan Hajnoczi
 stefa...@linux.vnet.ibm.com wrote:
 +    /* Cover entire cluster so no additional backing file I/O is required 
 when
 +     * allocating cluster in the image file.
 +     */
 +    round_to_clusters(bs, sector_num, nb_sectors,
 +                      cluster_sector_num, cluster_nb_sectors);
 Why need to round down/up sector_num/nb_sectors in this function? The
 detection of race condition for write request has been done before
 this function.

If we write less than a cluster then the image format will have to
perform additional to populate the regions of the cluster that we did
not touch.  So we touch entire clusters and therefore no extra I/O is
generated.

The comment right above the line you are asking about explains this.

Stefan



Re: [Qemu-devel] About hotplug multifunction

2011-11-23 Thread Amos Kong

On 09/09/11 15:08, Amos Kong wrote:

Hello all,

I'm working on hotplug pci multifunction.

1. qemu cmdline:
./x86_64-softmmu/qemu-system-x86_64 -snapshot -m 2000 
/home/kvm_autotest_root/images/rhel61-64-virtio.qcow2 -vnc :0 -monitor 
unix:/tmp/a,server,nowait --enable-kvm -net none

2. script to add virtio-blk devices:
for i in `seq 1 7` 0;do
qemu-img create /tmp/resize$i.qcow2 1G -f qcow2
echo drive_add 0x6.$i id=drv$i,if=none,file=/tmp/resize$i.qcow2 | nc -U /tmp/a
echo device_add 
virtio-blk-pci,id=dev$i,drive=drv$i,addr=0x6.$i,multifunction=on | nc -U /tmp/a
done

3. script to add virio-nic devices:
for i in `seq 1 7` 0;do
echo netdev_add tap,id=drv$i | nc -U /tmp/a
echo device_add 
virtio-net-pci,id=dev$i,netdev=drv$i,addr=0x6.$i,multifunction=on | nc -U /tmp/a
done

4. current qemu behaviors
4.1. add func 1~7 one by one, then add func 0
virtio-nic : success, all funcs are added
virtio-blk : success

4.2. add func 0~7 one by one
virtio-nic : failed, only func 0 is added
virtio-blk : success

4.3. removing any single func in monitor
virtio-nic: func 0 are not found in 'lspci', func 1~7 also exist. eth1~eth7 
also exist.
virtio-blk: func 0 are not found in 'lspci', func 1~7 also exist. the device. 
/dev/vda disappears,
   vdb,vdc,vde,vdf,vdg,vdh,vdi,vdj also exist. If I re-add 8 funcs 
to guest, they all works.
   # lspci (00:06.1 ~ 00:06.7 exist, 00:06.0 doesn't exit)
   00:06.1 SCSI storage controller: Red Hat, Inc Virtio block 
device (rev ff)

qemu sends an acpi event to guest, then guest will remove all funcs in the slot.
linux-2.6/drivers/pci/hotplug/acpiphp_glue.c:
static int disable_device(struct acpiphp_slot *slot) {
 list_for_each_entry(func,slot-funcs, sibling) {
 ...


Hello all,

I re-tested the multifunction hotplug of winxp,rhel6,win7 guest. 
(upstream qemu-kvm)


For all the guests, func0 needs to be added, otherwise no func can be 
found in guest.
RHEL6 needs to add fun0 in the end, otherwise, the funcs added after 
hot-adding func0 could not be found in guest.

For winxp,win7, add func0 in any time, all the funcs can be found in guest.

This is the test result( hogplug order of funcs  funcs can be found in 
guest):

hotplug order   xp  win7rhel6
--  -
func 0~70~7 0~7 0~7
func 0~50~6 0~6 0~6
func 1~4,0,50~5 0~5 0~4
func 1~4no  no  no

It looks like the 'problem' of linux guest, or could we accept to add 
func0 after adding other funcs for linux guest?


Thanks,
Amos


Questions:
1. why func1~7 still can be found after hot-remove? is it same as real hardware?
2. why the func 1~7 could not be added to guest (addingfunc 0~7 one by one)?
3. how about this interface to hotplug/hot-unplug multifunction:
1) Add func 1-7 by monitor, add func 0, then send an acpi event to notice 
guest
2) Remove func0, send an acpi event to guest. (all funcs can be removed)
4. what does reversion 0xff stand for?

Thanks in advance,
Amos





Re: [Qemu-devel] plans for QEMU support for KVM on ARM

2011-11-23 Thread Peter Maydell
On 23 November 2011 07:50, Jubi Taneja jubitan...@gmail.com wrote:
 Thanks for sharing this information. When is QEMU support for ARM Cortex A15
 (with LPAE) expected?

Depends what you mean. LPAE is on the list of bits we currently
hope we won't have to implement for KVM's benefit, but which we
might have to. (Basically if we start with a guest kernel not
compiled for LPAE then there's no need.) So adding LPAE on top
of the A15-without-virtualization QEMU system model isn't in
this planned work. If we need it it'll probably be done some time
in the first quarter of next year.

A full QEMU system emulation including the virtualization extensions
(ie what you would need to run a hypervisor inside QEMU) is not
currently planned.

-- PMM



Re: [Qemu-devel] [PATCH v2 7/8] block: core copy-on-read logic

2011-11-23 Thread Stefan Hajnoczi
On Wed, Nov 23, 2011 at 8:58 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
 On Wed, Nov 23, 2011 at 4:42 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote:
 On Thu, Nov 17, 2011 at 9:40 PM, Stefan Hajnoczi
 stefa...@linux.vnet.ibm.com wrote:
 +    /* Cover entire cluster so no additional backing file I/O is required 
 when
 +     * allocating cluster in the image file.
 +     */
 +    round_to_clusters(bs, sector_num, nb_sectors,
 +                      cluster_sector_num, cluster_nb_sectors);
 Why need to round down/up sector_num/nb_sectors in this function? The
 detection of race condition for write request has been done before
 this function.

 If we write less than a cluster then the image format will have to
 perform additional to populate the regions of the cluster that we did

perform additional I/O



Re: [Qemu-devel] [PATCH v2 7/8] block: core copy-on-read logic

2011-11-23 Thread Stefan Hajnoczi
On Wed, Nov 23, 2011 at 3:42 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote:
 On Thu, Nov 17, 2011 at 9:40 PM, Stefan Hajnoczi
 stefa...@linux.vnet.ibm.com wrote:
     tracked_request_begin(req, bs, sector_num, nb_sectors, false);
 +
 +    if (bs-copy_on_read) {
 Why is  tracked_request_begin/end() not put inside the brace around
 bs-copy_on_read?
 If this COR function is not enabled, i guess that request tracing
 function should not be need.

It's not safe to put the calls inside the if (bs-copy_on_read) {
body because turning off copy_on_read while a request is pending would
leave the request in the tracked list forever!

In a previous version of the series there was a flag to turn request
tracking on/off.  Pending requests would still remove themselves from
the list even after request tracking was disabled.

But request tracking is cheap - it involves filling in fields on the
stack and adding them to a linked list.  So to keep things simple we
always maintain this list.

Stefan



[Qemu-devel] [PATCH v3 1.0] configure: tighten pie toolchain support test for tls variables

2011-11-23 Thread Avi Kivity
Some toolchains don't support pie properly when tls variables are
in use.  Disallow pie when such toolchains are detected.

Signed-off-by: Avi Kivity a...@redhat.com
---

v3: only check __thread on Linux, where we require it, and where the
toolchain fails

v2: give tls_var a type; avoids invisible warning

 configure |   12 +++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/configure b/configure
index 75e1f10..1a2c55f 100755
--- a/configure
+++ b/configure
@@ -1120,7 +1120,17 @@ fi
 
 if test $pie != no ; then
   cat  $TMPC  EOF
-int main(void) { return 0; }
+
+#ifdef __linux__
+#  define THREAD __thread
+#else
+#  define THREAD
+#endif
+
+static THREAD int tls_var;
+
+int main(void) { return tls_var; }
+
 EOF
   if compile_prog -fPIE -DPIE -pie; then
 QEMU_CFLAGS=-fPIE -DPIE $QEMU_CFLAGS
-- 
1.7.7.1




Re: [Qemu-devel] [Qemu-trivial] [PATCH 01/11] fix spelling in darwin-user sub directory

2011-11-23 Thread Stefan Hajnoczi
On Tue, Nov 22, 2011 at 06:06:16PM +0800, Dong Xu Wang wrote:
 From: Dong Xu Wang wdon...@linux.vnet.ibm.com
 
 
 Signed-off-by: Dong Xu Wang wdon...@linux.vnet.ibm.com
 ---
  darwin-user/machload.c |6 +++---
  darwin-user/main.c |2 +-
  darwin-user/syscall.c  |2 +-
  3 files changed, 5 insertions(+), 5 deletions(-)

These fixes are mostly for comments, some user-visible strings.  I have
reviewed them and because they are really trivial am not waiting for all
CCed people to reply.

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

Stefan



Re: [Qemu-devel] [Qemu-trivial] [PATCH 0/2] Trivial console_putchar() fixes

2011-11-23 Thread Stefan Hajnoczi
On Tue, Nov 22, 2011 at 11:59:05AM +0100, Markus Armbruster wrote:
 Markus Armbruster (2):
   console: Clean up confusing indentation in console_putchar()
   console: Fix console_putchar() for CSI J
 
  console.c |   19 ++-
  1 files changed, 10 insertions(+), 9 deletions(-)
 
 -- 

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

Stefan



Re: [Qemu-devel] [Qemu-trivial] [PATCH] console: Fix qemu_default_pixelformat() for 24 bpp

2011-11-23 Thread Stefan Hajnoczi
On Tue, Nov 22, 2011 at 12:56:10PM +0100, Markus Armbruster wrote:
 Falls through to 32 bpp.  Harmless, because the only difference is the
 alpha component, and we're not using that.  Spotted by Coverity.
 
 Signed-off-by: Markus Armbruster arm...@redhat.com
 ---
  console.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

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

Stefan



Re: [Qemu-devel] [Qemu-trivial] [PATCH] fix out of tree build

2011-11-23 Thread Stefan Hajnoczi
On Tue, Nov 22, 2011 at 05:27:15PM +, Stefano Stabellini wrote:
 
 Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com

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

Stefan



Re: [Qemu-devel] [PATCH v2 7/8] block: core copy-on-read logic

2011-11-23 Thread Zhi Yong Wu
On Wed, Nov 23, 2011 at 5:05 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
 On Wed, Nov 23, 2011 at 3:42 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote:
 On Thu, Nov 17, 2011 at 9:40 PM, Stefan Hajnoczi
 stefa...@linux.vnet.ibm.com wrote:
     tracked_request_begin(req, bs, sector_num, nb_sectors, false);
 +
 +    if (bs-copy_on_read) {
 Why is  tracked_request_begin/end() not put inside the brace around
 bs-copy_on_read?
 If this COR function is not enabled, i guess that request tracing
 function should not be need.

 It's not safe to put the calls inside the if (bs-copy_on_read) {
 body because turning off copy_on_read while a request is pending would
 leave the request in the tracked list forever!
GOT IT, thanks.

 In a previous version of the series there was a flag to turn request
 tracking on/off.  Pending requests would still remove themselves from
 the list even after request tracking was disabled.

 But request tracking is cheap - it involves filling in fields on the
 stack and adding them to a linked list.  So to keep things simple we
 always maintain this list.

 Stefan




-- 
Regards,

Zhi Yong Wu



[Qemu-devel] [PATCH V3 1/2] Update ioctl order in nbd_init to detect -EBUSY

2011-11-23 Thread Chunyan Liu
Remove NBD_CLEAR_SOCK from nbd_init and adjust NBD_SET_SOCK ioctl before other
ioctl(s) in nbd_init so that it can detect -EBUSY properly.
 
Signed-off-by: Chunyan Liu cy...@suse.com
---
 nbd.c |   27 +--
 1 files changed, 9 insertions(+), 18 deletions(-)

diff --git a/nbd.c b/nbd.c
index e6c931c..4184614 100644
--- a/nbd.c
+++ b/nbd.c
@@ -348,6 +348,15 @@ int nbd_receive_negotiate(int csock, const char *name, 
uint32_t *flags,
 #ifdef __linux__
 int nbd_init(int fd, int csock, uint32_t flags, off_t size, size_t blocksize)
 {
+TRACE(Setting NBD socket);
+
+if (ioctl(fd, NBD_SET_SOCK, csock) == -1) {
+int serrno = errno;
+LOG(Failed to set NBD socket);
+errno = serrno;
+return -1;
+}
+
 TRACE(Setting block size to %lu, (unsigned long)blocksize);
 
 if (ioctl(fd, NBD_SET_BLKSIZE, blocksize) == -1) {
@@ -386,24 +395,6 @@ int nbd_init(int fd, int csock, uint32_t flags, off_t 
size, size_t blocksize)
 return -1;
 }
 
-TRACE(Clearing NBD socket);
-
-if (ioctl(fd, NBD_CLEAR_SOCK) == -1) {
-int serrno = errno;
-LOG(Failed clearing NBD socket);
-errno = serrno;
-return -1;
-}
-
-TRACE(Setting NBD socket);
-
-if (ioctl(fd, NBD_SET_SOCK, csock) == -1) {
-int serrno = errno;
-LOG(Failed to set NBD socket);
-errno = serrno;
-return -1;
-}
-
 TRACE(Negotiation ended);
 
 return 0;
-- 
1.7.3.4




[Qemu-devel] [PATCH V3 2/2] Add -f option to qemu-nbd

2011-11-23 Thread Chunyan Liu
V3:
Remove file lock in main(). 
Try to find new free nbd device and connect to it if connecting to the first
first found free nbd device failed.

Signed-off-by: Chunyan Liu cy...@suse.com
---
 qemu-nbd.c |   80 +++-
 1 files changed, 79 insertions(+), 1 deletions(-)

diff --git a/qemu-nbd.c b/qemu-nbd.c
index 291cba2..fcaaf50 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -32,6 +32,7 @@
 #include signal.h
 #include libgen.h
 #include pthread.h
+#include fcntl.h
 
 #define SOCKET_PATH/var/lock/qemu-nbd-%s
 
@@ -244,6 +245,60 @@ out:
 return (void *) EXIT_FAILURE;
 }
 
+static int is_nbd_used(int minor)
+{
+FILE *proc;
+int NBDMAJOR = 43;
+char buf[BUFSIZ];
+int find = 0;
+
+proc = fopen(/proc/partitions, r);
+if (proc != NULL) {
+while (fgets(buf, sizeof(buf), proc)) {
+int m, n;
+unsigned long long sz;
+char name[16];
+char *pname = name;
+char *end;
+
+if (sscanf(buf,  %d %d %llu %128[^\n ],
+m, n, sz, name) != 4)
+continue;
+if (m != NBDMAJOR)
+continue;
+if (strncmp(name, nbd, 3))
+continue;
+pname += 3;
+n = strtol(pname, end, 10);
+if (end  end != pname  *end == '\0'  n == minor) {
+find = 1;
+break;
+}
+}
+fclose(proc);
+}
+
+return find;
+}
+
+static char *find_free_nbd_device(void)
+{
+int i;
+int nbds_max = 16;
+char name[16];
+char *devname = NULL;
+
+for (i = 0; i  nbds_max; i++) {
+if (!is_nbd_used(i)) {
+snprintf(name, sizeof(name), /dev/nbd%d, i);
+devname = strdup(name);
+break;
+}
+}
+
+return devname;
+}
+
 int main(int argc, char **argv)
 {
 BlockDriverState *bs;
@@ -256,7 +311,7 @@ int main(int argc, char **argv)
 struct sockaddr_in addr;
 socklen_t addr_len = sizeof(addr);
 off_t fd_size;
-const char *sopt = hVb:o:p:rsnP:c:dvk:e:t;
+const char *sopt = hVb:o:p:rsnP:c:dvk:e:tf;
 struct option lopt[] = {
 { help, 0, NULL, 'h' },
 { version, 0, NULL, 'V' },
@@ -273,6 +328,7 @@ int main(int argc, char **argv)
 { shared, 1, NULL, 'e' },
 { persistent, 0, NULL, 't' },
 { verbose, 0, NULL, 'v' },
+{ find, 0, NULL, 'f' },
 { NULL, 0, NULL, 0 }
 };
 int ch;
@@ -292,6 +348,8 @@ int main(int argc, char **argv)
 int max_fd;
 int persistent = 0;
 pthread_t client_thread;
+char *devname = NULL;
+int find = 0;
 
 /* The client thread uses SIGTERM to interrupt the server.  A signal
  * handler ensures that qemu-nbd -v -c exits with a nice status code.
@@ -374,6 +432,18 @@ int main(int argc, char **argv)
 case 'v':
 verbose = 1;
 break;
+case 'f':
+find = 1;
+devname = find_free_nbd_device();
+if (devname == NULL)
+exit(1);
+if (argc == optind) {
+printf(%s\n, devname);
+free(devname);
+exit(0);
+}
+device = devname;
+break;
 case 'V':
 version(argv[0]);
 exit(0);
@@ -464,6 +534,7 @@ int main(int argc, char **argv)
 /* Open before spawning new threads.  In the future, we may
  * drop privileges after opening.
  */
+retry:
 fd = open(device, O_RDWR);
 if (fd == -1) {
 err(EXIT_FAILURE, Failed to open %s, device);
@@ -577,6 +648,13 @@ int main(int argc, char **argv)
 if (device) {
 void *ret;
 pthread_join(client_thread, ret);
+if (ret != EXIT_SUCCESS  find) {
+free(device);
+device = find_free_nbd_device();
+if (!device)
+err(EXIT_FAILURE, Could not find free nbd device);
+goto retry;
+}
 exit(ret != NULL);
 } else {
 exit(EXIT_SUCCESS);
-- 
1.7.3.4




Re: [Qemu-devel] [PATCH 01/11] fix spelling in darwin-user sub directory

2011-11-23 Thread Andreas Färber
Am 22.11.2011 11:06, schrieb Dong Xu Wang:
 From: Dong Xu Wang wdon...@linux.vnet.ibm.com
 
 
 Signed-off-by: Dong Xu Wang wdon...@linux.vnet.ibm.com

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

 diff --git a/darwin-user/machload.c b/darwin-user/machload.c
 index 0aa8282..26dd293 100644
 --- a/darwin-user/machload.c
 +++ b/darwin-user/machload.c

 @@ -809,7 +809,7 @@ unsigned long setup_arg_pages(void * mh, char ** argv, 
 char ** env)
  page_set_flags((int)env[i], (int)(env[i]+strlen(env[i])), PROT_READ 
 | PAGE_VALID);
  }
  
 -/* Add on the stack the interp_prefix choosen if so */
 +/* Add on the stack the interp_prefix chosen if so */
  if(interp_prefix[0])
  {
  char *dyld_root;

Don't really understand this comment either way... ;)

Andreas

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



[Qemu-devel] [PATCH] vpc: Add missing error handling in alloc_block

2011-11-23 Thread Kevin Wolf
Signed-off-by: Kevin Wolf kw...@redhat.com
---
 block/vpc.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/block/vpc.c b/block/vpc.c
index 75d7d4a..89a5ee2 100644
--- a/block/vpc.c
+++ b/block/vpc.c
@@ -362,8 +362,11 @@ static int64_t alloc_block(BlockDriverState* bs, int64_t 
sector_num)
 
 // Initialize the block's bitmap
 memset(bitmap, 0xff, s-bitmap_size);
-bdrv_pwrite_sync(bs-file, s-free_data_block_offset, bitmap,
+ret = bdrv_pwrite_sync(bs-file, s-free_data_block_offset, bitmap,
 s-bitmap_size);
+if (ret  0) {
+return ret;
+}
 
 // Write new footer (the old one will be overwritten)
 s-free_data_block_offset += s-block_size + s-bitmap_size;
-- 
1.7.6.4




Re: [Qemu-devel] Memory sync algorithm during migration

2011-11-23 Thread Oliver Hookins
On Tue, Nov 22, 2011 at 02:04:17PM +0100, Oliver Hookins wrote:
 On Tue, Nov 22, 2011 at 10:31:58AM +0100, ext Juan Quintela wrote:
  Oliver Hookins oliver.hook...@nokia.com wrote:
   On Tue, Nov 15, 2011 at 11:47:58AM +0100, ext Juan Quintela wrote:
   Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp wrote:
Adding qemu-devel ML to CC.
   
Your question should have been sent to qemu-devel ML because the logic
is implemented in QEMU, not KVM.
   
(2011/11/11 1:35), Oliver Hookins wrote:
Hi,
   
I am performing some benchmarks on KVM migration on two different 
types of VM.
One has 4GB RAM and the other 32GB. More or less idle, the 4GB VM 
takes about 20
seconds to migrate on our hardware while the 32GB VM takes about a 
minute.
   
With a reasonable amount of memory activity going on (in the hundreds 
of MB per
second) the 32GB VM takes 3.5 minutes to migrate, but the 4GB VM never
completes. Intuitively this tells me there is some watermarking of 
dirty pages
going on that is not particularly efficient when the dirty pages 
ratio is high
compared to total memory, but I may be completely incorrect.
   
You can change the ratio IIRC.
Hopefully, someone who knows well about QEMU will tell you better ways.
   
   Takuya
   
   
Could anybody fill me in on what might be going on here? We're using 
libvirt
0.8.2 and kvm-83-224.el5.centos.1
   
   This is pretty old qemu/kvm code base.
   In principle, it makes no sense that with 32GB RAM migration finishes,
   and with 4GB RAM it is unable (intuitively it should be, if ever, the
   other way around).
   
   Do you have an easy test that makes the problem easily reproducible?
   Have you tried ustream qemu.git? (some improvements on that department).
  
   I've just tried the qemu-kvm 0.14.1 tag which seems to be the latest that 
   builds
   on my platform. For some strange reason migrations always seem to fail in 
   one
   direction with Unknown savevm section or instance 'hpet' 0 messages.
  
  What is your platform?  This seems like you are running with hpet in one
  side, but without it in the other.  What command line are you using?
 
 Yes, my mistake. We were also testing later kernels and my test machines 
 managed
 to get out of sync. One had support for hpet clocksource but the other one
 didn't.
 
  
   This seems to point to different migration protocols on either end but 
   they are
   both running the same version of qemu-kvm I built. Does this ring any 
   bells for
   anyone?
  
  Command line mismatch.  But, what is your platform?
 
 CentOS5.6. Now running the VMs through qemu-kvm 0.14.1, unloaded migrations 
 take
 about half the time but with memory I/O load now both VMs never complete the
 migration. In practical terms I'm writing about 50MB/s into memory and we 
 have a
 10Gbps network (and I've seen real speeds up to 8-9Gbps on the wire) so there
 should be enough capacity to sync up the dirty pages.
 
 So now the 32GB and 4GB VMs have matching behaviour (which makes more sense) 
 but
 I'm not any closer to figuring out what is going on.

Resending as it got rejected the first time:

I have not set the maximum permissible migration time but that default
certainly points to a possibility of a solution. As for the writing semantics
it was a straight dd from disk to /dev/shm so I can't speak for the kernel but
naively I would think it may be contiguous space.



[Qemu-devel] [PULL 0/3] Trivial patches for 18 to 23 November 2011

2011-11-23 Thread Stefan Hajnoczi
Please add these fixes to QEMU 1.0, if possible.

The following changes since commit 40897c9c160393df922dfdb59cfa210048d3071d:

  Update version for 1.0-rc3 release (2011-11-21 15:05:59 -0600)

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

Julian Pidancet (1):
  rtl8139: Fix invalid IO access alignment

Markus Armbruster (1):
  slirp: Clean up net_slirp_hostfwd_remove()'s use of get_str_sep()

Stefano Stabellini (1):
  fix out of tree build

 Makefile |2 +-
 hw/rtl8139.c |   14 +-
 net/slirp.c  |9 -
 3 files changed, 6 insertions(+), 19 deletions(-)

-- 
1.7.7.1




[Qemu-devel] [PATCH 1/3] slirp: Clean up net_slirp_hostfwd_remove()'s use of get_str_sep()

2011-11-23 Thread Stefan Hajnoczi
From: Markus Armbruster arm...@redhat.com

get_str_sep() can fail, but net_slirp_hostfwd_remove() doesn't check.
Works, because it initializes buf[] to , which get_str_sep() doesn't
touch when it fails.  Coverity doesn't like it, and neither do I.

Change it to work exactly like slirp_hostfwd().

Acked-by: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Markus Armbruster arm...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 net/slirp.c |9 -
 1 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/net/slirp.c b/net/slirp.c
index c6cda5d..6646ecb 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -305,7 +305,7 @@ void net_slirp_hostfwd_remove(Monitor *mon, const QDict 
*qdict)
 {
 struct in_addr host_addr = { .s_addr = INADDR_ANY };
 int host_port;
-char buf[256] = ;
+char buf[256];
 const char *src_str, *p;
 SlirpState *s;
 int is_udp = 0;
@@ -325,11 +325,10 @@ void net_slirp_hostfwd_remove(Monitor *mon, const QDict 
*qdict)
 return;
 }
 
-if (!src_str || !src_str[0])
-goto fail_syntax;
-
 p = src_str;
-get_str_sep(buf, sizeof(buf), p, ':');
+if (!p || get_str_sep(buf, sizeof(buf), p, ':')  0) {
+goto fail_syntax;
+}
 
 if (!strcmp(buf, tcp) || buf[0] == '\0') {
 is_udp = 0;
-- 
1.7.7.1




[Qemu-devel] [PATCH 2/3] rtl8139: Fix invalid IO access alignment

2011-11-23 Thread Stefan Hajnoczi
From: Julian Pidancet julian.pidan...@gmail.com

This patch makes iPXE work with the rtl8139 emulation. The rtl8139
driver in iPXE issues a 16bit access on the ChipCmd register
(offset 0x37) to check the status of the rx buffer. The offset of the
ioport access was getting fixed up to 0x36 in qemu, causing the value
read in iPXE to be invalid.

This fixes an issue with iPXE reporting timeouts during TFTP transfers.

Reposting this here because it is trivial enough and the original post
on qemu-devel didn't attract much attention.

Also, the inw() which was causing the issue has been replaced with an
inb() in upstream iPXE:
https://git.ipxe.org/ipxe.git/commit/91dd64ad25baa27954a7518e73df4fca8a2d0c93

Signed-off-by: Julian Pidancet julian.pidan...@gmail.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 hw/rtl8139.c |   14 +-
 1 files changed, 1 insertions(+), 13 deletions(-)

diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index 4c37993..aa8ed0a 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -1971,7 +1971,7 @@ static int rtl8139_cplus_transmit_one(RTL8139State *s)
 cplus_tx_ring_desc += 16 * descriptor;
 
 DPRINTF(+++ C+ mode reading TX descriptor %d from host memory at 
-%08x0x%08x = 0xDMA_ADDR_FMT\n, descriptor, s-TxAddr[1],
+%08x %08x = 0xDMA_ADDR_FMT\n, descriptor, s-TxAddr[1],
 s-TxAddr[0], cplus_tx_ring_desc);
 
 uint32_t val, txdw0,txdw1,txbufLO,txbufHI;
@@ -2713,8 +2713,6 @@ static void rtl8139_io_writeb(void *opaque, uint8_t addr, 
uint32_t val)
 {
 RTL8139State *s = opaque;
 
-addr = 0xff;
-
 switch (addr)
 {
 case MAC0 ... MAC0+5:
@@ -2800,8 +2798,6 @@ static void rtl8139_io_writew(void *opaque, uint8_t addr, 
uint32_t val)
 {
 RTL8139State *s = opaque;
 
-addr = 0xfe;
-
 switch (addr)
 {
 case IntrMask:
@@ -2900,8 +2896,6 @@ static void rtl8139_io_writel(void *opaque, uint8_t addr, 
uint32_t val)
 {
 RTL8139State *s = opaque;
 
-addr = 0xfc;
-
 switch (addr)
 {
 case RxMissed:
@@ -2969,8 +2963,6 @@ static uint32_t rtl8139_io_readb(void *opaque, uint8_t 
addr)
 RTL8139State *s = opaque;
 int ret;
 
-addr = 0xff;
-
 switch (addr)
 {
 case MAC0 ... MAC0+5:
@@ -3043,8 +3035,6 @@ static uint32_t rtl8139_io_readw(void *opaque, uint8_t 
addr)
 RTL8139State *s = opaque;
 uint32_t ret;
 
-addr = 0xfe; /* mask lower bit */
-
 switch (addr)
 {
 case IntrMask:
@@ -3120,8 +3110,6 @@ static uint32_t rtl8139_io_readl(void *opaque, uint8_t 
addr)
 RTL8139State *s = opaque;
 uint32_t ret;
 
-addr = 0xfc; /* also mask low 2 bits */
-
 switch (addr)
 {
 case RxMissed:
-- 
1.7.7.1




[Qemu-devel] [PATCH 3/3] fix out of tree build

2011-11-23 Thread Stefan Hajnoczi
From: Stefano Stabellini stefano.stabell...@eu.citrix.com

Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 Makefile |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 7c93739..b06599c 100644
--- a/Makefile
+++ b/Makefile
@@ -168,7 +168,7 @@ check-qjson: check-qjson.o $(qobject-obj-y) $(tools-obj-y)
 test-coroutine: test-coroutine.o qemu-timer-common.o async.o 
$(coroutine-obj-y) $(tools-obj-y)
 
 $(qapi-obj-y): $(GENERATED_HEADERS)
-qapi-dir := qapi-generated
+qapi-dir := $(SRC_PATH)/qapi-generated
 test-visitor.o test-qmp-commands.o qemu-ga$(EXESUF): QEMU_CFLAGS += -I 
$(qapi-dir)
 qemu-ga$(EXESUF): LIBS = $(LIBS_QGA)
 
-- 
1.7.7.1




Re: [Qemu-devel] [PATCH V3 2/2] Add -f option to qemu-nbd

2011-11-23 Thread Stefan Hajnoczi
On Wed, Nov 23, 2011 at 10:14 AM, Chunyan Liu cy...@suse.com wrote:
 V3:
 Remove file lock in main().
 Try to find new free nbd device and connect to it if connecting to the first
 first found free nbd device failed.

 Signed-off-by: Chunyan Liu cy...@suse.com
 ---
  qemu-nbd.c |   80 
 +++-
  1 files changed, 79 insertions(+), 1 deletions(-)

I not seeing the part where you adjusted the ioctl order.

The /proc/partitions scanning is unnecessary since we can just loop
over /dev/ndb%d and try to initialize.  If a device is in use then
init will fail and we need to try the next one.  If a device is free
we can continue with normal operation.  I guess I'm saying that once
you fix the ioctl order then there's no need for another mechanism to
test whether or not a device is in use.

Also please use QEMU coding style, you can run
qemu/scripts/checkpatch.pl on your patches.

Stefan



Re: [Qemu-devel] [PATCH V3 2/2] Add -f option to qemu-nbd

2011-11-23 Thread Stefan Hajnoczi
On Wed, Nov 23, 2011 at 10:56 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
 On Wed, Nov 23, 2011 at 10:14 AM, Chunyan Liu cy...@suse.com wrote:
 V3:
 Remove file lock in main().
 Try to find new free nbd device and connect to it if connecting to the first
 first found free nbd device failed.

 Signed-off-by: Chunyan Liu cy...@suse.com
 ---
  qemu-nbd.c |   80 
 +++-
  1 files changed, 79 insertions(+), 1 deletions(-)

 I not seeing the part where you adjusted the ioctl order.

I see the other patch on the qemu-devel list now, sorry.  Looked at
this mail first because it was CCed to me.

Stefan



Re: [Qemu-devel] [PATCH] vpc: Add missing error handling in alloc_block

2011-11-23 Thread Stefan Hajnoczi
On Wed, Nov 23, 2011 at 10:40 AM, Kevin Wolf kw...@redhat.com wrote:
 Signed-off-by: Kevin Wolf kw...@redhat.com
 ---
  block/vpc.c |    5 -
  1 files changed, 4 insertions(+), 1 deletions(-)

 diff --git a/block/vpc.c b/block/vpc.c
 index 75d7d4a..89a5ee2 100644
 --- a/block/vpc.c
 +++ b/block/vpc.c
 @@ -362,8 +362,11 @@ static int64_t alloc_block(BlockDriverState* bs, int64_t 
 sector_num)

     // Initialize the block's bitmap
     memset(bitmap, 0xff, s-bitmap_size);
 -    bdrv_pwrite_sync(bs-file, s-free_data_block_offset, bitmap,
 +    ret = bdrv_pwrite_sync(bs-file, s-free_data_block_offset, bitmap,
         s-bitmap_size);
 +    if (ret  0) {
 +        return ret;
 +    }

I notice that s-pagetable[index] is left modified when the function
fails.  But this is a larger issue and could be addressed in a later
patch which also looks at the other failure cases in this function.

Reviewed-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com

Stefan



Re: [Qemu-devel] [PATCH] vpc: Add missing error handling in alloc_block

2011-11-23 Thread Kevin Wolf
Am 23.11.2011 12:01, schrieb Stefan Hajnoczi:
 On Wed, Nov 23, 2011 at 10:40 AM, Kevin Wolf kw...@redhat.com wrote:
 Signed-off-by: Kevin Wolf kw...@redhat.com
 ---
  block/vpc.c |5 -
  1 files changed, 4 insertions(+), 1 deletions(-)

 diff --git a/block/vpc.c b/block/vpc.c
 index 75d7d4a..89a5ee2 100644
 --- a/block/vpc.c
 +++ b/block/vpc.c
 @@ -362,8 +362,11 @@ static int64_t alloc_block(BlockDriverState* bs, 
 int64_t sector_num)

 // Initialize the block's bitmap
 memset(bitmap, 0xff, s-bitmap_size);
 -bdrv_pwrite_sync(bs-file, s-free_data_block_offset, bitmap,
 +ret = bdrv_pwrite_sync(bs-file, s-free_data_block_offset, bitmap,
 s-bitmap_size);
 +if (ret  0) {
 +return ret;
 +}
 
 I notice that s-pagetable[index] is left modified when the function
 fails.  But this is a larger issue and could be addressed in a later
 patch which also looks at the other failure cases in this function.

Error handling in vpc needs some work anyway. For example, almost all
places return -1 instead of the real error number. Probably even the
order of operations is unsafe, didn't check that yet.

Kevin



[Qemu-devel] [PATCH v3 02/38] scsi: fix fw path

2011-11-23 Thread Stefan Hajnoczi
From: Paolo Bonzini pbonz...@redhat.com

The pre-1.0 firmware path for SCSI devices already included the LUN
using the suffix argument to add_boot_device_path.  I missed that when
making channel and LUN customizable.  Avoid that it is included twice, and
convert the colons to commas for consistency with other kinds of devices

Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
 hw/scsi-bus.c  |2 +-
 hw/scsi-disk.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c
index e6ebbd5..07419b8 100644
--- a/hw/scsi-bus.c
+++ b/hw/scsi-bus.c
@@ -1279,7 +1279,7 @@ static char *scsibus_get_fw_dev_path(DeviceState *dev)
 SCSIDevice *d = DO_UPCAST(SCSIDevice, qdev, dev);
 char path[100];
 
-snprintf(path, sizeof(path), %s@%d:%d:%d, qdev_fw_name(dev),
+snprintf(path, sizeof(path), %s@%d,%d,%d, qdev_fw_name(dev),
  d-channel, d-id, d-lun);
 
 return strdup(path);
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 62f538f..cc4f9ef 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -1553,7 +1553,7 @@ static int scsi_initfn(SCSIDevice *dev)
 bdrv_set_buffer_alignment(s-qdev.conf.bs, s-qdev.blocksize);
 
 bdrv_iostatus_enable(s-qdev.conf.bs);
-add_boot_device_path(s-qdev.conf.bootindex, dev-qdev, ,0);
+add_boot_device_path(s-qdev.conf.bootindex, dev-qdev, NULL);
 return 0;
 }
 
-- 
1.7.7.1




[Qemu-devel] [PATCH v3 01/38] Documentation: Add section about iSCSI LUNS to qemu-doc

2011-11-23 Thread Stefan Hajnoczi
From: Ronnie Sahlberg ronniesahlb...@gmail.com

Add a new section about using iSCSI LUNs with qemu
and provide a short example on how to set up a target and access it
using the built-in initiator

Signed-off-by: Ronnie Sahlberg ronniesahlb...@gmail.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
 qemu-doc.texi |   56 
 1 files changed, 56 insertions(+), 0 deletions(-)

diff --git a/qemu-doc.texi b/qemu-doc.texi
index 149e9bd..1abba98 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -421,6 +421,7 @@ snapshots.
 * disk_images_fat_images::Virtual FAT disk images
 * disk_images_nbd::   NBD access
 * disk_images_sheepdog::  Sheepdog disk images
+* disk_images_iscsi:: iSCSI LUNs
 @end menu
 
 @node disk_images_quickstart
@@ -695,6 +696,61 @@ qemu-img create 
sheepdog:@var{hostname}:@var{port}:@var{image} @var{size}
 qemu sheepdog:@var{hostname}:@var{port}:@var{image}
 @end example
 
+@node disk_images_iscsi
+@subsection iSCSI LUNs
+
+iSCSI is a popular protocol used to access SCSI devices across a computer
+network.
+
+There are two different ways iSCSI devices can be used by QEMU.
+
+The first method is to mount the iSCSI LUN on the host, and make it appear as
+any other ordinary SCSI device on the host and then to access this device as a
+/dev/sd device from QEMU. How to do this differs between host OSes.
+
+The second method involves using the iSCSI initiator that is built into
+QEMU. This provides a mechanism that works the same way regardless of which
+host OS you are running QEMU on. This section will describe this second method
+of using iSCSI together with QEMU.
+
+In QEMU, iSCSI devices are described using special iSCSI URLs
+
+@example
+URL syntax:
+iscsi://[username[%password]@@]host[:port]/target-iqn-name/lun
+@end example
+
+Username and password are optional and only used if your target is set up
+using CHAP authentication for access control.
+Alternatively the username and password can also be set via environment
+variables to have these not show up in the process list
+
+@example
+export LIBISCSI_CHAP_USERNAME=username
+export LIBISCSI_CHAP_PASSWORD=password
+iscsi://host/target-iqn-name/lun
+@end example
+
+Howto set up a simple iSCSI target on loopback and accessing it via QEMU:
+@example
+This example shows how to set up an iSCSI target with one CDROM and one DISK
+using the Linux STGT software target. This target is available on Red Hat based
+systems as the package 'scsi-target-utils'.
+
+tgtd --iscsi portal=127.0.0.1:3260
+tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.qemu.test
+tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 1 \
+-b /IMAGES/disk.img --device-type=disk
+tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 2 \
+-b /IMAGES/cd.iso --device-type=cd
+tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL
+
+qemu-system-i386 -boot d -drive file=iscsi://127.0.0.1/iqn.qemu.test/1 \
+-cdrom iscsi://127.0.0.1/iqn.qemu.test/2
+@end example
+
+
+
 @node pcsys_network
 @section Network emulation
 
-- 
1.7.7.1




[Qemu-devel] [PATCH v3 00/38] block: generic copy-on-read

2011-11-23 Thread Stefan Hajnoczi
The new -drive copy-on-read=on|off feature populates the image file with data
from the backing file on read.  This is useful when accessing images backed
over a slow medium (e.g. http over internet).  All read data will be stored in
the local image file so it does not need to be fetched again in the future.

This series is a prerequisite for the image streaming feature, which uses
copy-on-read to populate the image file in the background while the VM is
running.  However, the copy-on-read feature is useful on its own.

Copy-on-read is implemented by checking whether or not data is allocated in the
image file before reading it.  If data is not allocated then it needs to be
read and written back to the image file.

The tricky bit is avoiding races with other I/O requests.  These patches add
request tracking to BlockDriverState so that the list of pending requests is
available.  Copy-on-read prevents races by serializing overlapping requests.

Finally, there is a performance impact when enabling this feature since an
additional write is performed.  Serializing overlapping requests also means
that I/O patterns where multiple requests access the same cluster will see a
loss in parallelism.  Perhaps we can be smarter about preventing corruption in
the future and win back some performance.

v3:
 * Improve wait_for_overlapping_requests() comment [Kevin]

v2:
 * Based on bdrv_co_is_allocated patch series - now safe in coroutine context
 * Use QEMU_ALIGN_DOWN/UP() macros for copy-on-read cluster calculations [Zhi 
Yong]
 * Reset bs-copy_on_read on bdrv_close() [Kevin]
 * Refcount bs-copy_on_read so it doesn't get clobbered by multiple users 
[Marcelo]
 * Use bool instead of int where appropriate [Kevin]
 * Use compound literal assignment to ensure BdrvTrackedRequest fields always 
get zeroed [Kevin]
 * Comment rationale for copy-on-read bounce buffer [Kevin]

Dong Xu Wang (1):
  block:add coroutine_fn marker to coroutine functions

Li Zhi Hui (1):
  block: Use bdrv functions to replace file operation in cow.c

Paolo Bonzini (13):
  scsi: fix fw path
  scsi-disk: guess geometry
  atapi: kill MODE SENSE(6), fix MODE SENSE(10)
  scsi: update list of commands
  scsi: fix parsing of allocation length field
  scsi: remove block descriptors from CDs
  scsi: pass down REQUEST SENSE to the device when there is no stored
sense
  scsi-block: always use SG_IO for MMC devices
  virtio-blk: fix cross-endian config space
  usb-msd: do not register twice in the boot order
  scsi: fix fw path
  scsi-generic: add as boot device
  xen_disk: remove dead code

Ronnie Sahlberg (1):
  Documentation: Add section about iSCSI LUNS to qemu-doc

Stefan Hajnoczi (17):
  block: use public bdrv_is_allocated() interface
  block: add .bdrv_co_is_allocated()
  qed: convert to .bdrv_co_is_allocated()
  block: convert qcow2, qcow2, and vmdk to .bdrv_co_is_allocated()
  vvfat: convert to .bdrv_co_is_allocated()
  vdi: convert to .bdrv_co_is_allocated()
  cow: convert to .bdrv_co_is_allocated()
  block: drop .bdrv_is_allocated() interface
  block: add bdrv_co_is_allocated() interface
  qemu-common: add QEMU_ALIGN_DOWN() and QEMU_ALIGN_UP() macros
  coroutine: add qemu_co_queue_restart_all()
  block: add request tracking
  block: add bdrv_set_copy_on_read()
  block: wait for overlapping requests
  block: request overlap detection
  block: core copy-on-read logic
  block: add -drive copy-on-read=on|off

Zhi Yong Wu (5):
  qed: adjust the way to get nb_sectors
  block: add the blockio limits command line support
  CoQueue: introduce qemu_co_queue_wait_insert_head
  block: add I/O throttling algorithm
  hmp/qmp: add block_set_io_throttle

 block.c   |  564 -
 block.h   |   10 +
 block/cow.c   |   42 ++--
 block/qcow.c  |   12 +-
 block/qcow2.c |   23 ++-
 block/qed-table.c |6 +-
 block/qed.c   |   15 +-
 block/sheepdog.c  |4 +-
 block/vdi.c   |6 +-
 block/vmdk.c  |8 +-
 block/vvfat.c |4 +-
 block_int.h   |   40 -
 blockdev.c|  109 ++
 blockdev.h|2 +
 hmp-commands.hx   |   20 ++-
 hmp.c |   10 +
 hw/ide/atapi.c|   20 +-
 hw/pci-hotplug.c  |3 +-
 hw/scsi-bus.c |  137 ++--
 hw/scsi-defs.h|   10 +-
 hw/scsi-disk.c|   37 +++-
 hw/scsi-generic.c |5 +
 hw/scsi.h |4 +-
 hw/usb-msd.c  |4 +-
 hw/virtio-blk.c   |7 +-
 hw/xen_disk.c |   86 +
 qapi-schema.json  |   16 ++-
 qemu-common.h |6 +
 qemu-config.c |   28 +++
 qemu-coroutine-lock.c |   23 ++-
 qemu-coroutine.h  |   11 +
 qemu-doc.texi |   56 +
 qemu-options.hx   |   10 +-
 qerror.c  |4 +
 qerror.h  |3 +
 qmp-commands.hx   |   53 +-
 trace-events  |1 +
 37 files changed, 1186 

[Qemu-devel] [PATCH v3 07/38] scsi: remove block descriptors from CDs

2011-11-23 Thread Stefan Hajnoczi
From: Paolo Bonzini pbonz...@redhat.com

Reported-by: Thomas Schmitt scdbac...@gmx.net
Tested-by: Thomas Schmitt scdbac...@gmx.net
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
 hw/scsi-disk.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 0b06fef..9dd2be8 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -956,8 +956,9 @@ static int scsi_disk_emulate_mode_sense(SCSIDiskReq *r, 
uint8_t *outbuf)
 p += 8;
 }
 
+/* MMC prescribes that CD/DVD drives have no block descriptors.  */
 bdrv_get_geometry(s-qdev.conf.bs, nb_sectors);
-if (!dbd  nb_sectors) {
+if (!dbd  s-qdev.type == TYPE_DISK  nb_sectors) {
 if (r-req.cmd.buf[0] == MODE_SENSE) {
 outbuf[3] = 8; /* Block descriptor length  */
 } else { /* MODE_SENSE_10 */
-- 
1.7.7.1




[Qemu-devel] [PATCH v3 13/38] scsi-generic: add as boot device

2011-11-23 Thread Stefan Hajnoczi
From: Paolo Bonzini pbonz...@redhat.com

There is no reason why a scsi-generic device cannot boot if it has
the right type, and indeed it provides already a bootindex property.
So register those devices too.

Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
 hw/scsi-generic.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/hw/scsi-generic.c b/hw/scsi-generic.c
index 9594cc1..e62044f 100644
--- a/hw/scsi-generic.c
+++ b/hw/scsi-generic.c
@@ -413,6 +413,10 @@ static int scsi_generic_initfn(SCSIDevice *s)
 /* define device state */
 s-type = scsiid.scsi_type;
 DPRINTF(device type %d\n, s-type);
+if (s-type == TYPE_DISK || s-type == TYPE_ROM) {
+add_boot_device_path(s-conf.bootindex, s-qdev, NULL);
+}
+
 switch (s-type) {
 case TYPE_TAPE:
 s-blocksize = get_stream_blocksize(s-conf.bs);
@@ -459,6 +463,7 @@ static SCSIRequest *scsi_new_request(SCSIDevice *d, 
uint32_t tag, uint32_t lun,
 
 static SCSIDeviceInfo scsi_generic_info = {
 .qdev.name= scsi-generic,
+.qdev.fw_name = disk,
 .qdev.desc= pass through generic scsi device (/dev/sg*),
 .qdev.size= sizeof(SCSIDevice),
 .qdev.reset   = scsi_generic_reset,
-- 
1.7.7.1




[Qemu-devel] [PATCH v3 05/38] scsi: update list of commands

2011-11-23 Thread Stefan Hajnoczi
From: Paolo Bonzini pbonz...@redhat.com

Add more commands and their names, and remove SEEK(6) which is obsolete.
Instead, use SET_CAPACITY which is still in SSC.

Tested-by: Thomas Schmitt scdbac...@gmx.net
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
 hw/scsi-bus.c  |   25 +++--
 hw/scsi-defs.h |   10 +-
 hw/scsi-disk.c |4 +---
 3 files changed, 29 insertions(+), 10 deletions(-)

diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c
index 07419b8..7efcbd8 100644
--- a/hw/scsi-bus.c
+++ b/hw/scsi-bus.c
@@ -681,7 +681,7 @@ static int scsi_req_length(SCSICommand *cmd, SCSIDevice 
*dev, uint8_t *buf)
 case TEST_UNIT_READY:
 case REWIND:
 case START_STOP:
-case SEEK_6:
+case SET_CAPACITY:
 case WRITE_FILEMARKS:
 case SPACE:
 case RESERVE:
@@ -1036,7 +1036,7 @@ static const char *scsi_command_name(uint8_t cmd)
 [ REASSIGN_BLOCKS  ] = REASSIGN_BLOCKS,
 [ READ_6   ] = READ_6,
 [ WRITE_6  ] = WRITE_6,
-[ SEEK_6   ] = SEEK_6,
+[ SET_CAPACITY ] = SET_CAPACITY,
 [ READ_REVERSE ] = READ_REVERSE,
 [ WRITE_FILEMARKS  ] = WRITE_FILEMARKS,
 [ SPACE] = SPACE,
@@ -1064,7 +1064,7 @@ static const char *scsi_command_name(uint8_t cmd)
 [ SEARCH_EQUAL ] = SEARCH_EQUAL,
 [ SEARCH_LOW   ] = SEARCH_LOW,
 [ SET_LIMITS   ] = SET_LIMITS,
-[ PRE_FETCH] = PRE_FETCH,
+[ PRE_FETCH] = PRE_FETCH/READ_POSITION,
 /* READ_POSITION and PRE_FETCH use the same operation code */
 [ SYNCHRONIZE_CACHE] = SYNCHRONIZE_CACHE,
 [ LOCK_UNLOCK_CACHE] = LOCK_UNLOCK_CACHE,
@@ -1101,9 +1101,11 @@ static const char *scsi_command_name(uint8_t cmd)
 [ WRITE_16 ] = WRITE_16,
 [ WRITE_VERIFY_16  ] = WRITE_VERIFY_16,
 [ VERIFY_16] = VERIFY_16,
-[ SYNCHRONIZE_CACHE_16 ] = SYNCHRONIZE_CACHE_16,
+[ PRE_FETCH_16 ] = PRE_FETCH_16,
+[ SYNCHRONIZE_CACHE_16 ] = SPACE_16/SYNCHRONIZE_CACHE_16,
+/* SPACE_16 and SYNCHRONIZE_CACHE_16 use the same operation code */
 [ LOCATE_16] = LOCATE_16,
-[ WRITE_SAME_16] = WRITE_SAME_16,
+[ WRITE_SAME_16] = ERASE_16/WRITE_SAME_16,
 /* ERASE_16 and WRITE_SAME_16 use the same operation code */
 [ SERVICE_ACTION_IN_16 ] = SERVICE_ACTION_IN_16,
 [ WRITE_LONG_16] = WRITE_LONG_16,
@@ -1113,6 +1115,8 @@ static const char *scsi_command_name(uint8_t cmd)
 [ LOAD_UNLOAD  ] = LOAD_UNLOAD,
 [ READ_12  ] = READ_12,
 [ WRITE_12 ] = WRITE_12,
+[ ERASE_12 ] = ERASE_12/GET_PERFORMANCE,
+/* ERASE_12 and GET_PERFORMANCE use the same operation code */
 [ SERVICE_ACTION_IN_12 ] = SERVICE_ACTION_IN_12,
 [ WRITE_VERIFY_12  ] = WRITE_VERIFY_12,
 [ VERIFY_12] = VERIFY_12,
@@ -1120,9 +1124,18 @@ static const char *scsi_command_name(uint8_t cmd)
 [ SEARCH_EQUAL_12  ] = SEARCH_EQUAL_12,
 [ SEARCH_LOW_12] = SEARCH_LOW_12,
 [ READ_ELEMENT_STATUS  ] = READ_ELEMENT_STATUS,
-[ SEND_VOLUME_TAG  ] = SEND_VOLUME_TAG,
+[ SEND_VOLUME_TAG  ] = SEND_VOLUME_TAG/SET_STREAMING,
+/* SEND_VOLUME_TAG and SET_STREAMING use the same operation code */
+[ READ_CD  ] = READ_CD,
 [ READ_DEFECT_DATA_12  ] = READ_DEFECT_DATA_12,
+[ READ_DVD_STRUCTURE   ] = READ_DVD_STRUCTURE,
+[ RESERVE_TRACK] = RESERVE_TRACK,
+[ SEND_CUE_SHEET   ] = SEND_CUE_SHEET,
+[ SEND_DVD_STRUCTURE   ] = SEND_DVD_STRUCTURE,
 [ SET_CD_SPEED ] = SET_CD_SPEED,
+[ SET_READ_AHEAD   ] = SET_READ_AHEAD,
+[ ALLOW_OVERWRITE  ] = ALLOW_OVERWRITE,
+[ MECHANISM_STATUS ] = MECHANISM_STATUS,
 };
 
 if (cmd = ARRAY_SIZE(names) || names[cmd] == NULL)
diff --git a/hw/scsi-defs.h b/hw/scsi-defs.h
index d0a467a..354ed7b 100644
--- a/hw/scsi-defs.h
+++ b/hw/scsi-defs.h
@@ -32,7 +32,7 @@
 #define REASSIGN_BLOCKS   0x07
 #define READ_60x08
 #define WRITE_6   0x0a
-#define SEEK_60x0b
+#define SET_CAPACITY  0x0b
 #define READ_REVERSE  0x0f
 #define WRITE_FILEMARKS   0x10
 #define SPACE 0x11
@@ -81,14 +81,17 @@
 #define GET_EVENT_STATUS_NOTIFICATION 0x4a
 #define LOG_SELECT0x4c
 #define LOG_SENSE 0x4d
+#define RESERVE_TRACK 0x53
 #define MODE_SELECT_100x55
 #define RESERVE_10   

[Qemu-devel] [PATCH v3 03/38] scsi-disk: guess geometry

2011-11-23 Thread Stefan Hajnoczi
From: Paolo Bonzini pbonz...@redhat.com

Old operating systems rely on correct geometry to convert from CHS
addresses to LBA.  Providing correct data is necessary for them to boot.

Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
 hw/scsi-disk.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index cc4f9ef..73de0f6 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -797,7 +797,7 @@ static int mode_sense_page(SCSIDiskState *s, int page, 
uint8_t **p_outbuf,
 break;
 }
 /* if a geometry hint is available, use it */
-bdrv_get_geometry_hint(bdrv, cylinders, heads, secs);
+bdrv_guess_geometry(bdrv, cylinders, heads, secs);
 p[2] = (cylinders  16)  0xff;
 p[3] = (cylinders  8)  0xff;
 p[4] = cylinders  0xff;
@@ -831,7 +831,7 @@ static int mode_sense_page(SCSIDiskState *s, int page, 
uint8_t **p_outbuf,
 p[2] = 5000  8;
 p[3] = 5000  0xff;
 /* if a geometry hint is available, use it */
-bdrv_get_geometry_hint(bdrv, cylinders, heads, secs);
+bdrv_guess_geometry(bdrv, cylinders, heads, secs);
 p[4] = heads  0xff;
 p[5] = secs  0xff;
 p[6] = s-qdev.blocksize  8;
-- 
1.7.7.1




[Qemu-devel] [PATCH v3 14/38] qed: adjust the way to get nb_sectors

2011-11-23 Thread Stefan Hajnoczi
From: Zhi Yong Wu wu...@linux.vnet.ibm.com

This patch is only to refactor some lines of codes to get better and more 
robust codes.

As you have seen, in qed_read_table_cb() it's nice to
use qiov-size because that function doesn't obviously use a single
struct iovec.

In other two functions, if qiov use more than one struct iovec, the existing 
way will get wrong nb_sectors.
To make the code more robust, it will be nicer to refactor the existing way as 
below.

Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
Acked-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
 block/qed-table.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/block/qed-table.c b/block/qed-table.c
index f31f9ff..8ee8443 100644
--- a/block/qed-table.c
+++ b/block/qed-table.c
@@ -29,7 +29,7 @@ static void qed_read_table_cb(void *opaque, int ret)
 {
 QEDReadTableCB *read_table_cb = opaque;
 QEDTable *table = read_table_cb-table;
-int noffsets = read_table_cb-iov.iov_len / sizeof(uint64_t);
+int noffsets = read_table_cb-qiov.size / sizeof(uint64_t);
 int i;
 
 /* Handle I/O error */
@@ -65,7 +65,7 @@ static void qed_read_table(BDRVQEDState *s, uint64_t offset, 
QEDTable *table,
 
 qemu_iovec_init_external(qiov, read_table_cb-iov, 1);
 aiocb = bdrv_aio_readv(s-bs-file, offset / BDRV_SECTOR_SIZE, qiov,
-   read_table_cb-iov.iov_len / BDRV_SECTOR_SIZE,
+   qiov-size / BDRV_SECTOR_SIZE,
qed_read_table_cb, read_table_cb);
 if (!aiocb) {
 qed_read_table_cb(read_table_cb, -EIO);
@@ -160,7 +160,7 @@ static void qed_write_table(BDRVQEDState *s, uint64_t 
offset, QEDTable *table,
 
 aiocb = bdrv_aio_writev(s-bs-file, offset / BDRV_SECTOR_SIZE,
 write_table_cb-qiov,
-write_table_cb-iov.iov_len / BDRV_SECTOR_SIZE,
+write_table_cb-qiov.size / BDRV_SECTOR_SIZE,
 qed_write_table_cb, write_table_cb);
 if (!aiocb) {
 qed_write_table_cb(write_table_cb, -EIO);
-- 
1.7.7.1




[Qemu-devel] [PATCH v3 08/38] scsi: pass down REQUEST SENSE to the device when there is no stored sense

2011-11-23 Thread Stefan Hajnoczi
From: Paolo Bonzini pbonz...@redhat.com

This will let scsi-block/scsi-generic report progress on long
operations.

Reported-by: Thomas Schmitt scdbac...@gmxbackup.net
Tested-by: Thomas Schmitt scdbac...@gmxbackup.net
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
 hw/scsi-bus.c  |4 +---
 hw/scsi-disk.c |8 ++--
 hw/scsi.h  |2 ++
 3 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c
index 4d9ff35..3a2a7bb 100644
--- a/hw/scsi-bus.c
+++ b/hw/scsi-bus.c
@@ -9,8 +9,6 @@
 static char *scsibus_get_fw_dev_path(DeviceState *dev);
 static int scsi_req_parse(SCSICommand *cmd, SCSIDevice *dev, uint8_t *buf);
 static void scsi_req_dequeue(SCSIRequest *req);
-static int scsi_build_sense(uint8_t *in_buf, int in_len,
-uint8_t *buf, int len, bool fixed);
 
 static struct BusInfo scsi_bus_info = {
 .name  = SCSI,
@@ -502,7 +500,7 @@ SCSIRequest *scsi_req_new(SCSIDevice *d, uint32_t tag, 
uint32_t lun,
  hba_private);
 } else if (lun != d-lun ||
 buf[0] == REPORT_LUNS ||
-buf[0] == REQUEST_SENSE) {
+(buf[0] == REQUEST_SENSE  (d-sense_len || cmd.xfer  4))) {
 req = scsi_req_alloc(reqops_target_command, d, tag, lun,
  hba_private);
 } else {
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 9dd2be8..e3690ec 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -1179,6 +1179,11 @@ static int scsi_disk_emulate_command(SCSIDiskReq *r)
 outbuf[7] = 0;
 buflen = 8;
 break;
+case REQUEST_SENSE:
+/* Just return NO SENSE.  */
+buflen = scsi_build_sense(NULL, 0, outbuf, r-buflen,
+  (req-cmd.buf[1]  1) == 0);
+break;
 case MECHANISM_STATUS:
 buflen = scsi_emulate_mechanism_status(s, outbuf);
 if (buflen  0) {
@@ -1313,6 +1318,7 @@ static int32_t scsi_send_command(SCSIRequest *req, 
uint8_t *buf)
 case GET_EVENT_STATUS_NOTIFICATION:
 case MECHANISM_STATUS:
 case SERVICE_ACTION_IN_16:
+case REQUEST_SENSE:
 case VERIFY_10:
 rc = scsi_disk_emulate_command(r);
 if (rc  0) {
@@ -1407,8 +1413,6 @@ static int32_t scsi_send_command(SCSIRequest *req, 
uint8_t *buf)
 }
 
 break;
-case REQUEST_SENSE:
-abort();
 default:
 DPRINTF(Unknown SCSI command (%2.2x)\n, buf[0]);
 scsi_check_condition(r, SENSE_CODE(INVALID_OPCODE));
diff --git a/hw/scsi.h b/hw/scsi.h
index ff8fdd0..61c64d5 100644
--- a/hw/scsi.h
+++ b/hw/scsi.h
@@ -179,6 +179,8 @@ extern const struct SCSISense 
sense_code_DEVICE_INTERNAL_RESET;
 #define SENSE_CODE(x) sense_code_ ## x
 
 int scsi_sense_valid(SCSISense sense);
+int scsi_build_sense(uint8_t *in_buf, int in_len,
+ uint8_t *buf, int len, bool fixed);
 
 SCSIRequest *scsi_req_alloc(const SCSIReqOps *reqops, SCSIDevice *d,
 uint32_t tag, uint32_t lun, void *hba_private);
-- 
1.7.7.1




[Qemu-devel] [PATCH v3 09/38] scsi-block: always use SG_IO for MMC devices

2011-11-23 Thread Stefan Hajnoczi
From: Paolo Bonzini pbonz...@redhat.com

CD burning messes up the state of the host page cache and host block
device.  Just pass all operations down to the device, even though that
might have slightly worse performance.  Everything else just is not
reliable in combination with burning.

Reported-by: Thomas Schmitt scdbac...@gmx.net
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
 hw/scsi-disk.c |   16 ++--
 1 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index e3690ec..673948c 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -1703,8 +1703,20 @@ static SCSIRequest *scsi_block_new_request(SCSIDevice 
*d, uint32_t tag,
 case WRITE_VERIFY_10:
 case WRITE_VERIFY_12:
 case WRITE_VERIFY_16:
-return scsi_req_alloc(scsi_disk_reqops, s-qdev, tag, lun,
-  hba_private);
+/* MMC writing cannot be done via pread/pwrite, because it sometimes
+ * involves writing beyond the maximum LBA or to negative LBA 
(lead-in).
+ * And once you do these writes, reading from the block device is
+ * unreliable, too.  It is even possible that reads deliver random data
+ * from the host page cache (this is probably a Linux bug).
+ *
+ * We might use scsi_disk_reqops as long as no writing commands are
+ * seen, but performance usually isn't paramount on optical media.  So,
+ * just make scsi-block operate the same as scsi-generic for them.
+ */
+if (s-qdev.type != TYPE_ROM) {
+return scsi_req_alloc(scsi_disk_reqops, s-qdev, tag, lun,
+  hba_private);
+}
 }
 
 return scsi_req_alloc(scsi_generic_req_ops, s-qdev, tag, lun,
-- 
1.7.7.1




[Qemu-devel] [PATCH v3 10/38] virtio-blk: fix cross-endian config space

2011-11-23 Thread Stefan Hajnoczi
From: Paolo Bonzini pbonz...@redhat.com

Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
 hw/virtio-blk.c |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index 19e89e7..d6d1f87 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -485,6 +485,7 @@ static void virtio_blk_update_config(VirtIODevice *vdev, 
uint8_t *config)
 struct virtio_blk_config blkcfg;
 uint64_t capacity;
 int cylinders, heads, secs;
+int blk_size = s-conf-logical_block_size;
 
 bdrv_get_geometry(s-bs, capacity);
 bdrv_get_geometry_hint(s-bs, cylinders, heads, secs);
@@ -492,14 +493,14 @@ static void virtio_blk_update_config(VirtIODevice *vdev, 
uint8_t *config)
 stq_raw(blkcfg.capacity, capacity);
 stl_raw(blkcfg.seg_max, 128 - 2);
 stw_raw(blkcfg.cylinders, cylinders);
+stl_raw(blkcfg.blk_size, blk_size);
+stw_raw(blkcfg.min_io_size, s-conf-min_io_size / blk_size);
+stw_raw(blkcfg.opt_io_size, s-conf-opt_io_size / blk_size);
 blkcfg.heads = heads;
 blkcfg.sectors = secs  ~s-sector_mask;
-blkcfg.blk_size = s-conf-logical_block_size;
 blkcfg.size_max = 0;
 blkcfg.physical_block_exp = get_physical_block_exp(s-conf);
 blkcfg.alignment_offset = 0;
-blkcfg.min_io_size = s-conf-min_io_size / blkcfg.blk_size;
-blkcfg.opt_io_size = s-conf-opt_io_size / blkcfg.blk_size;
 memcpy(config, blkcfg, sizeof(struct virtio_blk_config));
 }
 
-- 
1.7.7.1




[Qemu-devel] [PATCH v3 11/38] usb-msd: do not register twice in the boot order

2011-11-23 Thread Stefan Hajnoczi
From: Paolo Bonzini pbonz...@redhat.com

USB mass storage devices are registered twice in the boot order.
To avoid having to keep the two paths in sync, pass the bootindex
property down to the scsi-disk device and let it register itself.

Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
 hw/pci-hotplug.c |3 ++-
 hw/scsi-bus.c|7 +--
 hw/scsi.h|2 +-
 hw/usb-msd.c |4 ++--
 4 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/hw/pci-hotplug.c b/hw/pci-hotplug.c
index b59be2a..12f61fe 100644
--- a/hw/pci-hotplug.c
+++ b/hw/pci-hotplug.c
@@ -91,7 +91,8 @@ static int scsi_hot_add(Monitor *mon, DeviceState *adapter,
  */
 dinfo-unit = qemu_opt_get_number(dinfo-opts, unit, -1);
 dinfo-bus = scsibus-busnr;
-scsidev = scsi_bus_legacy_add_drive(scsibus, dinfo-bdrv, dinfo-unit, 
false);
+scsidev = scsi_bus_legacy_add_drive(scsibus, dinfo-bdrv, dinfo-unit,
+false, -1);
 if (!scsidev) {
 return -1;
 }
diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c
index 3a2a7bb..2feeaa2 100644
--- a/hw/scsi-bus.c
+++ b/hw/scsi-bus.c
@@ -162,7 +162,7 @@ void scsi_qdev_register(SCSIDeviceInfo *info)
 
 /* handle legacy '-drive if=scsi,...' cmd line args */
 SCSIDevice *scsi_bus_legacy_add_drive(SCSIBus *bus, BlockDriverState *bdrv,
-  int unit, bool removable)
+  int unit, bool removable, int bootindex)
 {
 const char *driver;
 DeviceState *dev;
@@ -170,6 +170,9 @@ SCSIDevice *scsi_bus_legacy_add_drive(SCSIBus *bus, 
BlockDriverState *bdrv,
 driver = bdrv_is_sg(bdrv) ? scsi-generic : scsi-disk;
 dev = qdev_create(bus-qbus, driver);
 qdev_prop_set_uint32(dev, scsi-id, unit);
+if (bootindex = 0) {
+qdev_prop_set_int32(dev, bootindex, bootindex);
+}
 if (qdev_prop_exists(dev, removable)) {
 qdev_prop_set_bit(dev, removable, removable);
 }
@@ -195,7 +198,7 @@ int scsi_bus_legacy_handle_cmdline(SCSIBus *bus)
 continue;
 }
 qemu_opts_loc_restore(dinfo-opts);
-if (!scsi_bus_legacy_add_drive(bus, dinfo-bdrv, unit, false)) {
+if (!scsi_bus_legacy_add_drive(bus, dinfo-bdrv, unit, false, -1)) {
 res = -1;
 break;
 }
diff --git a/hw/scsi.h b/hw/scsi.h
index 61c64d5..ab6e952 100644
--- a/hw/scsi.h
+++ b/hw/scsi.h
@@ -128,7 +128,7 @@ static inline SCSIBus *scsi_bus_from_device(SCSIDevice *d)
 }
 
 SCSIDevice *scsi_bus_legacy_add_drive(SCSIBus *bus, BlockDriverState *bdrv,
-  int unit, bool removable);
+  int unit, bool removable, int bootindex);
 int scsi_bus_legacy_handle_cmdline(SCSIBus *bus);
 
 /*
diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index b734177..e97736b 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -541,7 +541,8 @@ static int usb_msd_initfn(USBDevice *dev)
 
 usb_desc_init(dev);
 scsi_bus_new(s-bus, s-dev.qdev, usb_msd_scsi_info);
-s-scsi_dev = scsi_bus_legacy_add_drive(s-bus, bs, 0, !!s-removable);
+s-scsi_dev = scsi_bus_legacy_add_drive(s-bus, bs, 0, !!s-removable,
+s-conf.bootindex);
 if (!s-scsi_dev) {
 return -1;
 }
@@ -557,7 +558,6 @@ static int usb_msd_initfn(USBDevice *dev)
 }
 }
 
-add_boot_device_path(s-conf.bootindex, dev-qdev, /disk@0,0);
 return 0;
 }
 
-- 
1.7.7.1




[Qemu-devel] [PATCH v3 06/38] scsi: fix parsing of allocation length field

2011-11-23 Thread Stefan Hajnoczi
From: Paolo Bonzini pbonz...@redhat.com

- several MMC commands were parsed wrong by QEMU because their allocation
length/parameter list length is placed in a non-standard position in
the CDB (i.e. it is different from most commands with the same value in
bits 5-7).

- SEND VOLUME TAG length was multiplied by 40 which is not in SMC.  The
parameter list length is between 32 and 40 bytes.  Same for MEDIUM SCAN
(spec found at http://ldkelley.com/SCSI2/SCSI2-16.html but not in any of
the PDFs I have here).

- READ_POSITION (SSC) conflicts with PRE_FETCH (SBC).  READ_POSITION's
transfer length is not hardcoded to 20 in SSC; for PRE_FETCH cmd-xfer
should be 0.  Both fixed.

- FORMAT MEDIUM (the SSC name for FORMAT UNIT) was missing.  The FORMAT
UNIT command is still somewhat broken for block devices because its
parameter list length is not in the CDB.  However it works for CD/DVD
drives, which mandate the length of the payload.

- fixed wrong sign-extensions for 32-bit fields (for the LBA field,
this affects disks 1 TB).

- several other SBC or SSC commands were missing or parsed wrong.

- some commands were not in the list of write commands.

Reported-by: Thomas Schmitt scdbac...@gmx.net
Tested-by: Thomas Schmitt scdbac...@gmx.net (MMC bits only)
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
 hw/scsi-bus.c |   97 +++--
 1 files changed, 87 insertions(+), 10 deletions(-)

diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c
index 7efcbd8..4d9ff35 100644
--- a/hw/scsi-bus.c
+++ b/hw/scsi-bus.c
@@ -649,6 +649,31 @@ static void scsi_req_dequeue(SCSIRequest *req)
 }
 }
 
+static int scsi_get_performance_length(int num_desc, int type, int data_type)
+{
+/* MMC-6, paragraph 6.7.  */
+switch (type) {
+case 0:
+if ((data_type  3) == 0) {
+/* Each descriptor is as in Table 295 - Nominal performance.  */
+return 16 * num_desc + 8;
+} else {
+/* Each descriptor is as in Table 296 - Exceptions.  */
+return 6 * num_desc + 8;
+}
+case 1:
+case 4:
+case 5:
+return 8 * num_desc + 8;
+case 2:
+return 2048 * num_desc + 8;
+case 3:
+return 16 * num_desc + 8;
+default:
+return 8;
+}
+}
+
 static int scsi_req_length(SCSICommand *cmd, SCSIDevice *dev, uint8_t *buf)
 {
 switch (buf[0]  5) {
@@ -666,11 +691,11 @@ static int scsi_req_length(SCSICommand *cmd, SCSIDevice 
*dev, uint8_t *buf)
 cmd-len = 10;
 break;
 case 4:
-cmd-xfer = ldl_be_p(buf[10]);
+cmd-xfer = ldl_be_p(buf[10])  0xULL;
 cmd-len = 16;
 break;
 case 5:
-cmd-xfer = ldl_be_p(buf[6]);
+cmd-xfer = ldl_be_p(buf[6])  0xULL;
 cmd-len = 12;
 break;
 default:
@@ -683,6 +708,7 @@ static int scsi_req_length(SCSICommand *cmd, SCSIDevice 
*dev, uint8_t *buf)
 case START_STOP:
 case SET_CAPACITY:
 case WRITE_FILEMARKS:
+case WRITE_FILEMARKS_16:
 case SPACE:
 case RESERVE:
 case RELEASE:
@@ -691,6 +717,8 @@ static int scsi_req_length(SCSICommand *cmd, SCSIDevice 
*dev, uint8_t *buf)
 case VERIFY_10:
 case SEEK_10:
 case SYNCHRONIZE_CACHE:
+case SYNCHRONIZE_CACHE_16:
+case LOCATE_16:
 case LOCK_UNLOCK_CACHE:
 case LOAD_UNLOAD:
 case SET_CD_SPEED:
@@ -698,6 +726,11 @@ static int scsi_req_length(SCSICommand *cmd, SCSIDevice 
*dev, uint8_t *buf)
 case WRITE_LONG_10:
 case MOVE_MEDIUM:
 case UPDATE_BLOCK:
+case RESERVE_TRACK:
+case SET_READ_AHEAD:
+case PRE_FETCH:
+case PRE_FETCH_16:
+case ALLOW_OVERWRITE:
 cmd-xfer = 0;
 break;
 case MODE_SENSE:
@@ -711,14 +744,13 @@ static int scsi_req_length(SCSICommand *cmd, SCSIDevice 
*dev, uint8_t *buf)
 case READ_BLOCK_LIMITS:
 cmd-xfer = 6;
 break;
-case READ_POSITION:
-cmd-xfer = 20;
-break;
 case SEND_VOLUME_TAG:
-cmd-xfer *= 40;
-break;
-case MEDIUM_SCAN:
-cmd-xfer *= 8;
+/* GPCMD_SET_STREAMING from multimedia commands.  */
+if (dev-type == TYPE_ROM) {
+cmd-xfer = buf[10] | (buf[9]  8);
+} else {
+cmd-xfer = buf[9] | (buf[8]  8);
+}
 break;
 case WRITE_10:
 case WRITE_VERIFY_10:
@@ -737,9 +769,39 @@ static int scsi_req_length(SCSICommand *cmd, SCSIDevice 
*dev, uint8_t *buf)
 case READ_16:
 cmd-xfer *= dev-blocksize;
 break;
+case FORMAT_UNIT:
+/* MMC mandates the parameter list to be 12-bytes long.  Parameters
+ * for block devices are restricted to the header right now.  */
+if (dev-type == TYPE_ROM  (buf[1]  16)) {
+cmd-xfer = 12;
+} else {
+cmd-xfer = (buf[1]  16) == 0 ? 0 : (buf[1]  32 ? 8 : 4);
+}
+break;
 case INQUIRY:
+case 

[Qemu-devel] planet-ltc.com

2011-11-23 Thread Alex


 



Preferred Domain Availability Notice:


planet-ltc.com will be listed for auction in a few days.  This domain might be 
useful for you, since you own a domain similar to this domain.


To confirm interest in owning this domain, fill out the simple form here: 
planet-ltc.com


 
Sincerely,Alexander
330 Franklin Road #135A

Suite 186

Brentwood, TN  37027
 


If you do not want more of these messages, please click the link above and 
follow instructions at the bottom of the page


 





 


Advice to consider: Never work just for money or for power. They won't save 
your soul or help you sleep at night. -- Marian Wright Edelman


 







[Qemu-devel] [Bug 893956] [NEW] qemu-img bug with dynamic vhd

2011-11-23 Thread z22lad
Public bug reported:

Hye, i found a problem with qemu-img when trying to get info of a
dynamic vhd. I made imgae of my 60GB computer hard drive with disk2vhd.
The dynamic vhd is 21gb size.

With 1.0-rc3 version :
running command: qemu-img info 60_GB.VHD
qemu-img:  Could not open '60_GB.VHD' : File too large

0.14.1 version give me wrong information :
image: 60_GB.VHD
file format: vpc
virtual size: 127G (13683600 bytes)
disk size: 21G

Thanks for reply.

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  qemu-img bug with dynamic vhd

Status in QEMU:
  New

Bug description:
  Hye, i found a problem with qemu-img when trying to get info of a
  dynamic vhd. I made imgae of my 60GB computer hard drive with
  disk2vhd. The dynamic vhd is 21gb size.

  With 1.0-rc3 version :
  running command: qemu-img info 60_GB.VHD
  qemu-img:  Could not open '60_GB.VHD' : File too large

  0.14.1 version give me wrong information :
  image: 60_GB.VHD
  file format: vpc
  virtual size: 127G (13683600 bytes)
  disk size: 21G

  Thanks for reply.

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



[Qemu-devel] [PATCH v4 2/8] coroutine: add qemu_co_queue_restart_all()

2011-11-23 Thread Stefan Hajnoczi
It's common to wake up all waiting coroutines.  Introduce the
qemu_co_queue_restart_all() function to do this instead of looping over
qemu_co_queue_next() in every caller.

Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 block/qcow2.c |2 +-
 qemu-coroutine-lock.c |   15 ---
 qemu-coroutine.h  |5 +
 3 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/block/qcow2.c b/block/qcow2.c
index eab35d1..195e1b1 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -514,7 +514,7 @@ static void run_dependent_requests(BDRVQcowState *s, 
QCowL2Meta *m)
 /* Restart all dependent requests */
 if (!qemu_co_queue_empty(m-dependent_requests)) {
 qemu_co_mutex_unlock(s-lock);
-while(qemu_co_queue_next(m-dependent_requests));
+qemu_co_queue_restart_all(m-dependent_requests);
 qemu_co_mutex_lock(s-lock);
 }
 }
diff --git a/qemu-coroutine-lock.c b/qemu-coroutine-lock.c
index 9549c07..26ad76b 100644
--- a/qemu-coroutine-lock.c
+++ b/qemu-coroutine-lock.c
@@ -84,6 +84,13 @@ bool qemu_co_queue_next(CoQueue *queue)
 return (next != NULL);
 }
 
+void qemu_co_queue_restart_all(CoQueue *queue)
+{
+while (qemu_co_queue_next(queue)) {
+/* Do nothing */
+}
+}
+
 bool qemu_co_queue_empty(CoQueue *queue)
 {
 return (QTAILQ_FIRST(queue-entries) == NULL);
@@ -144,13 +151,7 @@ void qemu_co_rwlock_unlock(CoRwlock *lock)
 assert(qemu_in_coroutine());
 if (lock-writer) {
 lock-writer = false;
-while (!qemu_co_queue_empty(lock-queue)) {
-/*
- * Wakeup every body. This will include some
- * writers too.
- */
-qemu_co_queue_next(lock-queue);
-}
+qemu_co_queue_restart_all(lock-queue);
 } else {
 lock-reader--;
 assert(lock-reader = 0);
diff --git a/qemu-coroutine.h b/qemu-coroutine.h
index 8a2e5d2..8a55fe1 100644
--- a/qemu-coroutine.h
+++ b/qemu-coroutine.h
@@ -131,6 +131,11 @@ void coroutine_fn qemu_co_queue_wait_insert_head(CoQueue 
*queue);
 bool qemu_co_queue_next(CoQueue *queue);
 
 /**
+ * Restarts all coroutines in the CoQueue and leaves the queue empty.
+ */
+void qemu_co_queue_restart_all(CoQueue *queue);
+
+/**
  * Checks if the CoQueue is empty.
  */
 bool qemu_co_queue_empty(CoQueue *queue);
-- 
1.7.7.1




[Qemu-devel] [PATCH v4 4/8] block: add bdrv_set_copy_on_read()

2011-11-23 Thread Stefan Hajnoczi
The bdrv_set_copy_on_read() function can be used to programmatically
enable or disable copy-on-read for a block device.  Later patches add
the actual copy-on-read logic.

Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 block.c |   22 ++
 block.h |3 +++
 block_int.h |2 ++
 3 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/block.c b/block.c
index 27c4e84..c90880b 100644
--- a/block.c
+++ b/block.c
@@ -538,6 +538,22 @@ int bdrv_parse_cache_flags(const char *mode, int *flags)
 return 0;
 }
 
+/**
+ * Enable/disable copy-on-read
+ *
+ * This is based on a reference count so multiple users may call this function
+ * without worrying about clobbering the previous state.  Copy-on-read stays
+ * enabled until all users have called to disable it.
+ */
+void bdrv_set_copy_on_read(BlockDriverState *bs, bool enable)
+{
+if (enable) {
+bs-copy_on_read++;
+} else {
+bs-copy_on_read--;
+}
+}
+
 /*
  * Common part for opening disk images and files
  */
@@ -559,6 +575,11 @@ static int bdrv_open_common(BlockDriverState *bs, const 
char *filename,
 bs-growable = 0;
 bs-buffer_alignment = 512;
 
+assert(bs-copy_on_read == 0); /* bdrv_new() and bdrv_close() make it so */
+if (flags  BDRV_O_RDWR) {
+bdrv_set_copy_on_read(bs, !!(flags  BDRV_O_COPY_ON_READ));
+}
+
 pstrcpy(bs-filename, sizeof(bs-filename), filename);
 bs-backing_file[0] = '\0';
 
@@ -801,6 +822,7 @@ void bdrv_close(BlockDriverState *bs)
 #endif
 bs-opaque = NULL;
 bs-drv = NULL;
+bs-copy_on_read = 0;
 
 if (bs-file != NULL) {
 bdrv_close(bs-file);
diff --git a/block.h b/block.h
index ad8dd48..68b4b14 100644
--- a/block.h
+++ b/block.h
@@ -70,6 +70,7 @@ typedef struct BlockDevOps {
 #define BDRV_O_NATIVE_AIO  0x0080 /* use native AIO instead of the thread pool 
*/
 #define BDRV_O_NO_BACKING  0x0100 /* don't open the backing file */
 #define BDRV_O_NO_FLUSH0x0200 /* disable flushing on this disk */
+#define BDRV_O_COPY_ON_READ 0x0400 /* copy read backing sectors into image */
 
 #define BDRV_O_CACHE_MASK  (BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NO_FLUSH)
 
@@ -308,6 +309,8 @@ void bdrv_reset_dirty(BlockDriverState *bs, int64_t 
cur_sector,
   int nr_sectors);
 int64_t bdrv_get_dirty_count(BlockDriverState *bs);
 
+void bdrv_set_copy_on_read(BlockDriverState *bs, bool enable);
+
 void bdrv_set_in_use(BlockDriverState *bs, int in_use);
 int bdrv_in_use(BlockDriverState *bs);
 
diff --git a/block_int.h b/block_int.h
index 788fde9..3c5bacb 100644
--- a/block_int.h
+++ b/block_int.h
@@ -193,6 +193,8 @@ struct BlockDriverState {
 int encrypted; /* if true, the media is encrypted */
 int valid_key; /* if true, a valid encryption key has been set */
 int sg;/* if true, the device is a /dev/sg* */
+int copy_on_read; /* if true, copy read backing sectors into image
+ note this is a reference count */
 
 BlockDriver *drv; /* NULL means no media */
 void *opaque;
-- 
1.7.7.1




Re: [Qemu-devel] [Bug 887883] Re: Coverity scan revealed defects

2011-11-23 Thread Markus Armbruster
Alex Jia a...@redhat.com writes:

 Markus, I think it will silence Coverity complain, 
 that sounds good to me, thanks.

It'll unveil even more complaints, actually :)



[Qemu-devel] [PATCH v3 04/38] atapi: kill MODE SENSE(6), fix MODE SENSE(10)

2011-11-23 Thread Stefan Hajnoczi
From: Paolo Bonzini pbonz...@redhat.com

Mode page 2A of emulated ATAPI DVD-ROM should have page length 0x14
like SCSI CD-ROM, rather than 0x12.

Mode page length is off by 8, as it should contain the length of the
payload after the first two bytes.

MODE SENSE(6) should be thrown out of ATAPI DVD-ROM emulation.  It is
not specified in the ATAPI list of MMC-2, and MMC-5 prescribes to use
MODE SENSE(10).  Anyway, its implementation is wrong.

Reported-by: Thomas Schmitt scdbac...@gmx.net
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
 hw/ide/atapi.c |   20 
 1 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/hw/ide/atapi.c b/hw/ide/atapi.c
index 1fed359..8af1cfd 100644
--- a/hw/ide/atapi.c
+++ b/hw/ide/atapi.c
@@ -695,12 +695,7 @@ static void cmd_mode_sense(IDEState *s, uint8_t *buf)
 int action, code;
 int max_len;
 
-if (buf[0] == GPCMD_MODE_SENSE_10) {
-max_len = ube16_to_cpu(buf + 7);
-} else {
-max_len = buf[4];
-}
-
+max_len = ube16_to_cpu(buf + 7);
 action = buf[2]  6;
 code = buf[2]  0x3f;
 
@@ -708,7 +703,7 @@ static void cmd_mode_sense(IDEState *s, uint8_t *buf)
 case 0: /* current values */
 switch(code) {
 case MODE_PAGE_R_W_ERROR: /* error recovery */
-cpu_to_ube16(buf[0], 16 + 6);
+cpu_to_ube16(buf[0], 16 - 2);
 buf[2] = 0x70;
 buf[3] = 0;
 buf[4] = 0;
@@ -727,7 +722,7 @@ static void cmd_mode_sense(IDEState *s, uint8_t *buf)
 ide_atapi_cmd_reply(s, 16, max_len);
 break;
 case MODE_PAGE_AUDIO_CTL:
-cpu_to_ube16(buf[0], 24 + 6);
+cpu_to_ube16(buf[0], 24 - 2);
 buf[2] = 0x70;
 buf[3] = 0;
 buf[4] = 0;
@@ -746,7 +741,7 @@ static void cmd_mode_sense(IDEState *s, uint8_t *buf)
 ide_atapi_cmd_reply(s, 24, max_len);
 break;
 case MODE_PAGE_CAPABILITIES:
-cpu_to_ube16(buf[0], 28 + 6);
+cpu_to_ube16(buf[0], 30 - 2);
 buf[2] = 0x70;
 buf[3] = 0;
 buf[4] = 0;
@@ -755,7 +750,7 @@ static void cmd_mode_sense(IDEState *s, uint8_t *buf)
 buf[7] = 0;
 
 buf[8] = MODE_PAGE_CAPABILITIES;
-buf[9] = 28 - 10;
+buf[9] = 30 - 10;
 buf[10] = 0x3b; /* read CDR/CDRW/DVDROM/DVDR/DVDRAM */
 buf[11] = 0x00;
 
@@ -777,7 +772,9 @@ static void cmd_mode_sense(IDEState *s, uint8_t *buf)
 buf[25] = 0;
 buf[26] = 0;
 buf[27] = 0;
-ide_atapi_cmd_reply(s, 28, max_len);
+buf[28] = 0;
+buf[29] = 0;
+ide_atapi_cmd_reply(s, 30, max_len);
 break;
 default:
 goto error_cmd;
@@ -1043,7 +1040,6 @@ static const struct {
 [ 0x00 ] = { cmd_test_unit_ready,   CHECK_READY },
 [ 0x03 ] = { cmd_request_sense, ALLOW_UA },
 [ 0x12 ] = { cmd_inquiry,   ALLOW_UA },
-[ 0x1a ] = { cmd_mode_sense, /* (6) */  0 },
 [ 0x1b ] = { cmd_start_stop_unit,   0 }, /* [1] */
 [ 0x1e ] = { cmd_prevent_allow_medium_removal,  0 },
 [ 0x25 ] = { cmd_read_cdvd_capacity,CHECK_READY },
-- 
1.7.7.1




[Qemu-devel] [PATCH v3 12/38] scsi: fix fw path

2011-11-23 Thread Stefan Hajnoczi
From: Paolo Bonzini pbonz...@redhat.com

The pre-1.0 firmware path for SCSI devices already included the LUN
using the suffix argument to add_boot_device_path.  Avoid that it is
included twice, and convert the colons to commas for consistency with
other kinds of devices

Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
 hw/scsi-bus.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c
index 2feeaa2..64e709e 100644
--- a/hw/scsi-bus.c
+++ b/hw/scsi-bus.c
@@ -1370,8 +1370,8 @@ static char *scsibus_get_fw_dev_path(DeviceState *dev)
 SCSIDevice *d = DO_UPCAST(SCSIDevice, qdev, dev);
 char path[100];
 
-snprintf(path, sizeof(path), %s@%d,%d,%d, qdev_fw_name(dev),
- d-channel, d-id, d-lun);
+snprintf(path, sizeof(path), channel@%x/%s@%x,%x, d-channel,
+ qdev_fw_name(dev), d-id, d-lun);
 
 return strdup(path);
 }
-- 
1.7.7.1




[Qemu-devel] [PATCH v4 0/8] block: generic copy-on-read

2011-11-23 Thread Stefan Hajnoczi
The new -drive copy-on-read=on|off feature populates the image file with data
from the backing file on read.  This is useful when accessing images backed
over a slow medium (e.g. http over internet).  All read data will be stored in
the local image file so it does not need to be fetched again in the future.

This series is a prerequisite for the image streaming feature, which uses
copy-on-read to populate the image file in the background while the VM is
running.  However, the copy-on-read feature is useful on its own.

Copy-on-read is implemented by checking whether or not data is allocated in the
image file before reading it.  If data is not allocated then it needs to be
read and written back to the image file.

The tricky bit is avoiding races with other I/O requests.  These patches add
request tracking to BlockDriverState so that the list of pending requests is
available.  Copy-on-read prevents races by serializing overlapping requests.

Finally, there is a performance impact when enabling this feature since an
additional write is performed.  Serializing overlapping requests also means
that I/O patterns where multiple requests access the same cluster will see a
loss in parallelism.  Perhaps we can be smarter about preventing corruption in
the future and win back some performance.

v4:
 * No changes, sorry for the spam v3 emails that were sent out

v3:
 * Improve wait_for_overlapping_requests() comment [Kevin]

v2:
 * Based on bdrv_co_is_allocated patch series - now safe in coroutine context
 * Use QEMU_ALIGN_DOWN/UP() macros for copy-on-read cluster calculations [Zhi 
Yong]
 * Reset bs-copy_on_read on bdrv_close() [Kevin]
 * Refcount bs-copy_on_read so it doesn't get clobbered by multiple users 
[Marcelo]
 * Use bool instead of int where appropriate [Kevin]
 * Use compound literal assignment to ensure BdrvTrackedRequest fields always 
get zeroed [Kevin]
 * Comment rationale for copy-on-read bounce buffer [Kevin]

Stefan Hajnoczi (8):
  qemu-common: add QEMU_ALIGN_DOWN() and QEMU_ALIGN_UP() macros
  coroutine: add qemu_co_queue_restart_all()
  block: add request tracking
  block: add bdrv_set_copy_on_read()
  block: wait for overlapping requests
  block: request overlap detection
  block: core copy-on-read logic
  block: add -drive copy-on-read=on|off

 block.c   |  218 -
 block.h   |3 +
 block/qcow2.c |2 +-
 block_int.h   |6 ++
 blockdev.c|6 ++
 hmp-commands.hx   |5 +-
 qemu-common.h |6 ++
 qemu-config.c |4 +
 qemu-coroutine-lock.c |   15 ++--
 qemu-coroutine.h  |5 +
 qemu-options.hx   |9 ++-
 trace-events  |1 +
 12 files changed, 268 insertions(+), 12 deletions(-)

-- 
1.7.7.1




[Qemu-devel] [PATCH v4 3/8] block: add request tracking

2011-11-23 Thread Stefan Hajnoczi
The block layer does not know about pending requests.  This information
is necessary for copy-on-read since overlapping requests must be
serialized to prevent races that corrupt the image.

The BlockDriverState gets a new tracked_request list field which
contains all pending requests.  Each request is a BdrvTrackedRequest
record with sector_num, nb_sectors, and is_write fields.

Note that request tracking is always enabled but hopefully this extra
work is so small that it doesn't justify adding an enable/disable flag.

Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 block.c |   48 +++-
 block_int.h |4 
 2 files changed, 51 insertions(+), 1 deletions(-)

diff --git a/block.c b/block.c
index 0df7eb9..27c4e84 100644
--- a/block.c
+++ b/block.c
@@ -1071,6 +1071,42 @@ void bdrv_commit_all(void)
 }
 }
 
+struct BdrvTrackedRequest {
+BlockDriverState *bs;
+int64_t sector_num;
+int nb_sectors;
+bool is_write;
+QLIST_ENTRY(BdrvTrackedRequest) list;
+};
+
+/**
+ * Remove an active request from the tracked requests list
+ *
+ * This function should be called when a tracked request is completing.
+ */
+static void tracked_request_end(BdrvTrackedRequest *req)
+{
+QLIST_REMOVE(req, list);
+}
+
+/**
+ * Add an active request to the tracked requests list
+ */
+static void tracked_request_begin(BdrvTrackedRequest *req,
+  BlockDriverState *bs,
+  int64_t sector_num,
+  int nb_sectors, bool is_write)
+{
+*req = (BdrvTrackedRequest){
+.bs = bs,
+.sector_num = sector_num,
+.nb_sectors = nb_sectors,
+.is_write = is_write,
+};
+
+QLIST_INSERT_HEAD(bs-tracked_requests, req, list);
+}
+
 /*
  * Return values:
  * 0- success
@@ -1350,6 +1386,8 @@ static int coroutine_fn bdrv_co_do_readv(BlockDriverState 
*bs,
 int64_t sector_num, int nb_sectors, QEMUIOVector *qiov)
 {
 BlockDriver *drv = bs-drv;
+BdrvTrackedRequest req;
+int ret;
 
 if (!drv) {
 return -ENOMEDIUM;
@@ -1363,7 +1401,10 @@ static int coroutine_fn 
bdrv_co_do_readv(BlockDriverState *bs,
 bdrv_io_limits_intercept(bs, false, nb_sectors);
 }
 
-return drv-bdrv_co_readv(bs, sector_num, nb_sectors, qiov);
+tracked_request_begin(req, bs, sector_num, nb_sectors, false);
+ret = drv-bdrv_co_readv(bs, sector_num, nb_sectors, qiov);
+tracked_request_end(req);
+return ret;
 }
 
 int coroutine_fn bdrv_co_readv(BlockDriverState *bs, int64_t sector_num,
@@ -1381,6 +1422,7 @@ static int coroutine_fn 
bdrv_co_do_writev(BlockDriverState *bs,
 int64_t sector_num, int nb_sectors, QEMUIOVector *qiov)
 {
 BlockDriver *drv = bs-drv;
+BdrvTrackedRequest req;
 int ret;
 
 if (!bs-drv) {
@@ -1398,6 +1440,8 @@ static int coroutine_fn 
bdrv_co_do_writev(BlockDriverState *bs,
 bdrv_io_limits_intercept(bs, true, nb_sectors);
 }
 
+tracked_request_begin(req, bs, sector_num, nb_sectors, true);
+
 ret = drv-bdrv_co_writev(bs, sector_num, nb_sectors, qiov);
 
 if (bs-dirty_bitmap) {
@@ -1408,6 +1452,8 @@ static int coroutine_fn 
bdrv_co_do_writev(BlockDriverState *bs,
 bs-wr_highest_sector = sector_num + nb_sectors - 1;
 }
 
+tracked_request_end(req);
+
 return ret;
 }
 
diff --git a/block_int.h b/block_int.h
index f9e2c9a..788fde9 100644
--- a/block_int.h
+++ b/block_int.h
@@ -51,6 +51,8 @@
 #define BLOCK_OPT_PREALLOC  preallocation
 #define BLOCK_OPT_SUBFMTsubformat
 
+typedef struct BdrvTrackedRequest BdrvTrackedRequest;
+
 typedef struct AIOPool {
 void (*cancel)(BlockDriverAIOCB *acb);
 int aiocb_size;
@@ -250,6 +252,8 @@ struct BlockDriverState {
 int in_use; /* users other than guest access, eg. block migration */
 QTAILQ_ENTRY(BlockDriverState) list;
 void *private;
+
+QLIST_HEAD(, BdrvTrackedRequest) tracked_requests;
 };
 
 struct BlockDriverAIOCB {
-- 
1.7.7.1




Re: [Qemu-devel] [PATCH v3 00/38] block: generic copy-on-read

2011-11-23 Thread Stefan Hajnoczi
Please ignore v3.  Things went horribly wrong and git selected many
unrelated commits because I made a mistake :D.

Stefan



[Qemu-devel] cannot build qemu with --static configure option

2011-11-23 Thread Mr Dash Four
I am trying to build a static version of the qemu-[arch] executables to 
be used in chrooted environment for the target arch (which is different 
from the host). My configure is:


./configure --target-list=x86_64-softmmu arm-softmmu x86_64-linux-user 
arm-linux-user armeb-linux-user --disable-kvm --disable-strip 
--disable-xen --disable-spice --disable-werror --static


then make V=1. It fails with the following error:

gcc -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef 
-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing 
-fstack-protector-all -Wendif-labels -Wmissing-include-dirs -Wempty-body 
-Wnested-externs -Wformat-security -Wformat-y2k -Winit-self 
-Wignored-qualifiers -Wold-style-declaration -Wold-style-definition 
-Wtype-limits -I/home/gogo/rpmbuild/BUILD/qemu-kvm-0.15.1/libcacard 
-I/usr/include/nss3 -I/usr/include/nspr4  -I/usr/include/glib-2.0 
-I/usr/lib64/glib-2.0/include   -I qapi-generated -O2 -g  
-Wl,--warn-common -m64 -static -g  -o qemu-ga qemu-ga.o 
qga/guest-agent-command-state.o qga/guest-agent-commands.o qemu-tool.o 
qemu-error.o error.o osdep.o oslib-posix.o qemu-thread-posix.o trace.o 
cutils.o cache-utils.o qemu-malloc.o qemu-option.o module.o async.o 
nbd.o block.o aio.o aes.o qemu-config.o qemu-progress.o qemu-sockets.o 
posix-aio-compat.o compatfd.o block/raw.o block/cow.o block/qcow.o 
block/vdi.o block/vmdk.o block/cloop.o block/dmg.o block/bochs.o 
block/vpc.o block/vvfat.o block/qcow2.o block/qcow2-refcount.o 
block/qcow2-cluster.o block/qcow2-snapshot.o block/qcow2-cache.o 
block/qed.o block/qed-gencb.o block/qed-l2-cache.o block/qed-table.o 
block/qed-cluster.o block/qed-check.o block/parallels.o block/nbd.o 
block/blkdebug.o block/sheepdog.o block/blkverify.o block/raw-posix.o 
qint.o qstring.o qdict.o qlist.o qfloat.o qbool.o qjson.o json-lexer.o 
json-streamer.o json-parser.o qerror.o qapi/qapi-visit-core.o 
qapi/qmp-input-visitor.o qapi/qmp-output-visitor.o 
qapi/qapi-dealloc-visitor.o qapi/qmp-registry.o qapi/qmp-dispatch.o 
qemu-timer-common.o qapi-generated/qga-qapi-visit.o 
qapi-generated/qga-qapi-types.o qapi-generated/qga-qmp-marshal.o -lssl3 
-lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl   -lrt 
-pthread  -lusbredirparser   -lz -lglib-2.0

/usr/bin/ld: cannot find -lssl3
collect2: ld returned 1 exit status
make: *** [qemu-ga] Error 1

It would indicate a missing libssl3, but the library, as far as I can 
see, is there! When I try building this without the --static option 
all is well - the build succeeds without any hitches. What could be the 
problem with this, what am I missing?




[Qemu-devel] [PATCH v4 5/8] block: wait for overlapping requests

2011-11-23 Thread Stefan Hajnoczi
When copy-on-read is enabled it is necessary to wait for overlapping
requests before issuing new requests.  This prevents races between the
copy-on-read and a write request.

Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 block.c |   35 +++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/block.c b/block.c
index c90880b..da7aaa2 100644
--- a/block.c
+++ b/block.c
@@ -1099,6 +1099,7 @@ struct BdrvTrackedRequest {
 int nb_sectors;
 bool is_write;
 QLIST_ENTRY(BdrvTrackedRequest) list;
+CoQueue wait_queue; /* coroutines blocked on this request */
 };
 
 /**
@@ -1109,6 +1110,7 @@ struct BdrvTrackedRequest {
 static void tracked_request_end(BdrvTrackedRequest *req)
 {
 QLIST_REMOVE(req, list);
+qemu_co_queue_restart_all(req-wait_queue);
 }
 
 /**
@@ -1126,9 +1128,34 @@ static void tracked_request_begin(BdrvTrackedRequest 
*req,
 .is_write = is_write,
 };
 
+qemu_co_queue_init(req-wait_queue);
+
 QLIST_INSERT_HEAD(bs-tracked_requests, req, list);
 }
 
+static bool tracked_request_overlaps(BdrvTrackedRequest *req,
+ int64_t sector_num, int nb_sectors) {
+return false; /* not yet implemented */
+}
+
+static void coroutine_fn wait_for_overlapping_requests(BlockDriverState *bs,
+int64_t sector_num, int nb_sectors)
+{
+BdrvTrackedRequest *req;
+bool retry;
+
+do {
+retry = false;
+QLIST_FOREACH(req, bs-tracked_requests, list) {
+if (tracked_request_overlaps(req, sector_num, nb_sectors)) {
+qemu_co_queue_wait(req-wait_queue);
+retry = true;
+break;
+}
+}
+} while (retry);
+}
+
 /*
  * Return values:
  * 0- success
@@ -1423,6 +1450,10 @@ static int coroutine_fn 
bdrv_co_do_readv(BlockDriverState *bs,
 bdrv_io_limits_intercept(bs, false, nb_sectors);
 }
 
+if (bs-copy_on_read) {
+wait_for_overlapping_requests(bs, sector_num, nb_sectors);
+}
+
 tracked_request_begin(req, bs, sector_num, nb_sectors, false);
 ret = drv-bdrv_co_readv(bs, sector_num, nb_sectors, qiov);
 tracked_request_end(req);
@@ -1462,6 +1493,10 @@ static int coroutine_fn 
bdrv_co_do_writev(BlockDriverState *bs,
 bdrv_io_limits_intercept(bs, true, nb_sectors);
 }
 
+if (bs-copy_on_read) {
+wait_for_overlapping_requests(bs, sector_num, nb_sectors);
+}
+
 tracked_request_begin(req, bs, sector_num, nb_sectors, true);
 
 ret = drv-bdrv_co_writev(bs, sector_num, nb_sectors, qiov);
-- 
1.7.7.1




[Qemu-devel] [PATCH v4 6/8] block: request overlap detection

2011-11-23 Thread Stefan Hajnoczi
Detect overlapping requests and remember to align to cluster boundaries
if the image format uses them.  This assumes that allocating I/O is
performed in cluster granularity - which is true for qcow2, qed, etc.

Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 block.c |   45 +++--
 1 files changed, 43 insertions(+), 2 deletions(-)

diff --git a/block.c b/block.c
index da7aaa2..c30c8f2 100644
--- a/block.c
+++ b/block.c
@@ -1133,21 +1133,62 @@ static void tracked_request_begin(BdrvTrackedRequest 
*req,
 QLIST_INSERT_HEAD(bs-tracked_requests, req, list);
 }
 
+/**
+ * Round a region to cluster boundaries
+ */
+static void round_to_clusters(BlockDriverState *bs,
+  int64_t sector_num, int nb_sectors,
+  int64_t *cluster_sector_num,
+  int *cluster_nb_sectors)
+{
+BlockDriverInfo bdi;
+
+if (bdrv_get_info(bs, bdi)  0 || bdi.cluster_size == 0) {
+*cluster_sector_num = sector_num;
+*cluster_nb_sectors = nb_sectors;
+} else {
+int64_t c = bdi.cluster_size / BDRV_SECTOR_SIZE;
+*cluster_sector_num = QEMU_ALIGN_DOWN(sector_num, c);
+*cluster_nb_sectors = QEMU_ALIGN_UP(sector_num - *cluster_sector_num +
+nb_sectors, c);
+}
+}
+
 static bool tracked_request_overlaps(BdrvTrackedRequest *req,
  int64_t sector_num, int nb_sectors) {
-return false; /* not yet implemented */
+/*    */
+if (sector_num = req-sector_num + req-nb_sectors) {
+return false;
+}
+/*    */
+if (req-sector_num = sector_num + nb_sectors) {
+return false;
+}
+return true;
 }
 
 static void coroutine_fn wait_for_overlapping_requests(BlockDriverState *bs,
 int64_t sector_num, int nb_sectors)
 {
 BdrvTrackedRequest *req;
+int64_t cluster_sector_num;
+int cluster_nb_sectors;
 bool retry;
 
+/* If we touch the same cluster it counts as an overlap.  This guarantees
+ * that allocating writes will be serialized and not race with each other
+ * for the same cluster.  For example, in copy-on-read it ensures that the
+ * CoR read and write operations are atomic and guest writes cannot
+ * interleave between them.
+ */
+round_to_clusters(bs, sector_num, nb_sectors,
+  cluster_sector_num, cluster_nb_sectors);
+
 do {
 retry = false;
 QLIST_FOREACH(req, bs-tracked_requests, list) {
-if (tracked_request_overlaps(req, sector_num, nb_sectors)) {
+if (tracked_request_overlaps(req, cluster_sector_num,
+ cluster_nb_sectors)) {
 qemu_co_queue_wait(req-wait_queue);
 retry = true;
 break;
-- 
1.7.7.1




[Qemu-devel] [PATCH v4 8/8] block: add -drive copy-on-read=on|off

2011-11-23 Thread Stefan Hajnoczi
This patch adds the -drive copy-on-read=on|off command-line option:

  copy-on-read=on|off
  copy-on-read is on or off and enables whether to copy read backing
  file sectors into the image file.  Copy-on-read avoids accessing the
  same backing file sectors repeatedly and is useful when the backing
  file is over a slow network.  By default copy-on-read is off.

Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 blockdev.c  |6 ++
 hmp-commands.hx |5 +++--
 qemu-config.c   |4 
 qemu-options.hx |9 -
 4 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 9068c5b..af4e239 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -257,6 +257,7 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
 DriveInfo *dinfo;
 BlockIOLimit io_limits;
 int snapshot = 0;
+bool copy_on_read;
 int ret;
 
 translation = BIOS_ATA_TRANSLATION_AUTO;
@@ -273,6 +274,7 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
 
 snapshot = qemu_opt_get_bool(opts, snapshot, 0);
 ro = qemu_opt_get_bool(opts, readonly, 0);
+copy_on_read = qemu_opt_get_bool(opts, copy-on-read, false);
 
 file = qemu_opt_get(opts, file);
 serial = qemu_opt_get(opts, serial);
@@ -546,6 +548,10 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
 bdrv_flags |= (BDRV_O_SNAPSHOT|BDRV_O_CACHE_WB|BDRV_O_NO_FLUSH);
 }
 
+if (copy_on_read) {
+bdrv_flags |= BDRV_O_COPY_ON_READ;
+}
+
 if (media == MEDIA_CDROM) {
 /* CDROM is fine for any interface, don't check.  */
 ro = 1;
diff --git a/hmp-commands.hx b/hmp-commands.hx
index f8d855e..79a9195 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -860,9 +860,10 @@ ETEXI
 .args_type  = pci_addr:s,opts:s,
 .params = [[domain:]bus:]slot\n
   [file=file][,if=type][,bus=n]\n
-  [,unit=m][,media=d][index=i]\n
+  [,unit=m][,media=d][,index=i]\n
   [,cyls=c,heads=h,secs=s[,trans=t]]\n
-  [snapshot=on|off][,cache=on|off],
+  [,snapshot=on|off][,cache=on|off]\n
+  [,readonly=on|off][,copy-on-read=on|off],
 .help   = add drive to PCI storage controller,
 .mhandler.cmd = drive_hot_add,
 },
diff --git a/qemu-config.c b/qemu-config.c
index 1aa080f..18f3020 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -109,6 +109,10 @@ static QemuOptsList qemu_drive_opts = {
 .name = bps_wr,
 .type = QEMU_OPT_NUMBER,
 .help = limit write bytes per second,
+},{
+.name = copy-on-read,
+.type = QEMU_OPT_BOOL,
+.help = copy read data from backing file into image file,
 },
 { /* end of list */ }
 },
diff --git a/qemu-options.hx b/qemu-options.hx
index 25a7be7..b3db10c 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -135,7 +135,7 @@ DEF(drive, HAS_ARG, QEMU_OPTION_drive,
[,cyls=c,heads=h,secs=s[,trans=t]][,snapshot=on|off]\n

[,cache=writethrough|writeback|none|directsync|unsafe][,format=f]\n
[,serial=s][,addr=A][,id=name][,aio=threads|native]\n
-   [,readonly=on|off]\n
+   [,readonly=on|off][,copy-on-read=on|off]\n

[[,bps=b]|[[,bps_rd=r][,bps_wr=w]]][[,iops=i]|[[,iops_rd=r][,iops_wr=w]]\n
 use 'file' as a drive image\n, QEMU_ARCH_ALL)
 STEXI
@@ -187,6 +187,9 @@ host disk is full; report the error to the guest otherwise).
 The default setting is @option{werror=enospc} and @option{rerror=report}.
 @item readonly
 Open drive @option{file} as read-only. Guest write attempts will fail.
+@item copy-on-read=@var{copy-on-read}
+@var{copy-on-read} is on or off and enables whether to copy read backing
+file sectors into the image file.
 @end table
 
 By default, writethrough caching is used for all block device.  This means that
@@ -218,6 +221,10 @@ like your host losing power, the disk storage getting 
disconnected accidently,
 etc. you're image will most probably be rendered unusable.   When using
 the @option{-snapshot} option, unsafe caching is always used.
 
+Copy-on-read avoids accessing the same backing file sectors repeatedly and is
+useful when the backing file is over a slow network.  By default copy-on-read
+is off.
+
 Instead of @option{-cdrom} you can use:
 @example
 qemu -drive file=file,index=2,media=cdrom
-- 
1.7.7.1




[Qemu-devel] [PATCH v4 7/8] block: core copy-on-read logic

2011-11-23 Thread Stefan Hajnoczi
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 block.c  |   72 ++
 trace-events |1 +
 2 files changed, 73 insertions(+), 0 deletions(-)

diff --git a/block.c b/block.c
index c30c8f2..a598a19 100644
--- a/block.c
+++ b/block.c
@@ -1469,6 +1469,61 @@ int bdrv_pwrite_sync(BlockDriverState *bs, int64_t 
offset,
 return 0;
 }
 
+static int coroutine_fn bdrv_co_copy_on_readv(BlockDriverState *bs,
+int64_t sector_num, int nb_sectors, QEMUIOVector *qiov)
+{
+/* Perform I/O through a temporary buffer so that users who scribble over
+ * their read buffer while the operation is in progress do not end up
+ * modifying the image file.  This is critical for zero-copy guest I/O
+ * where anything might happen inside guest memory.
+ */
+void *bounce_buffer;
+
+struct iovec iov;
+QEMUIOVector bounce_qiov;
+int64_t cluster_sector_num;
+int cluster_nb_sectors;
+size_t skip_bytes;
+int ret;
+
+/* Cover entire cluster so no additional backing file I/O is required when
+ * allocating cluster in the image file.
+ */
+round_to_clusters(bs, sector_num, nb_sectors,
+  cluster_sector_num, cluster_nb_sectors);
+
+trace_bdrv_co_copy_on_readv(bs, sector_num, nb_sectors,
+cluster_sector_num, cluster_nb_sectors);
+
+iov.iov_len = cluster_nb_sectors * BDRV_SECTOR_SIZE;
+iov.iov_base = bounce_buffer = qemu_blockalign(bs, iov.iov_len);
+qemu_iovec_init_external(bounce_qiov, iov, 1);
+
+ret = bs-drv-bdrv_co_readv(bs, cluster_sector_num, cluster_nb_sectors,
+ bounce_qiov);
+if (ret  0) {
+goto err;
+}
+
+ret = bs-drv-bdrv_co_writev(bs, cluster_sector_num, cluster_nb_sectors,
+  bounce_qiov);
+if (ret  0) {
+/* It might be okay to ignore write errors for guest requests.  If this
+ * is a deliberate copy-on-read then we don't want to ignore the error.
+ * Simply report it in all cases.
+ */
+goto err;
+}
+
+skip_bytes = (sector_num - cluster_sector_num) * BDRV_SECTOR_SIZE;
+qemu_iovec_from_buffer(qiov, bounce_buffer + skip_bytes,
+   nb_sectors * BDRV_SECTOR_SIZE);
+
+err:
+qemu_vfree(bounce_buffer);
+return ret;
+}
+
 /*
  * Handle a read request in coroutine context
  */
@@ -1496,7 +1551,24 @@ static int coroutine_fn 
bdrv_co_do_readv(BlockDriverState *bs,
 }
 
 tracked_request_begin(req, bs, sector_num, nb_sectors, false);
+
+if (bs-copy_on_read) {
+int pnum;
+
+ret = bdrv_co_is_allocated(bs, sector_num, nb_sectors, pnum);
+if (ret  0) {
+goto out;
+}
+
+if (!ret || pnum != nb_sectors) {
+ret = bdrv_co_copy_on_readv(bs, sector_num, nb_sectors, qiov);
+goto out;
+}
+}
+
 ret = drv-bdrv_co_readv(bs, sector_num, nb_sectors, qiov);
+
+out:
 tracked_request_end(req);
 return ret;
 }
diff --git a/trace-events b/trace-events
index 962caca..518b76b 100644
--- a/trace-events
+++ b/trace-events
@@ -69,6 +69,7 @@ bdrv_lock_medium(void *bs, bool locked) bs %p locked %d
 bdrv_co_readv(void *bs, int64_t sector_num, int nb_sector) bs %p sector_num 
%PRId64 nb_sectors %d
 bdrv_co_writev(void *bs, int64_t sector_num, int nb_sector) bs %p sector_num 
%PRId64 nb_sectors %d
 bdrv_co_io_em(void *bs, int64_t sector_num, int nb_sectors, int is_write, void 
*acb) bs %p sector_num %PRId64 nb_sectors %d is_write %d acb %p
+bdrv_co_copy_on_readv(void *bs, int64_t sector_num, int nb_sectors, int64_t 
cluster_sector_num, int cluster_nb_sectors) bs %p sector_num %PRId64 
nb_sectors %d cluster_sector_num %PRId64 cluster_nb_sectors %d
 
 # hw/virtio-blk.c
 virtio_blk_req_complete(void *req, int status) req %p status %d
-- 
1.7.7.1




[Qemu-devel] [PATCH v4 1/8] qemu-common: add QEMU_ALIGN_DOWN() and QEMU_ALIGN_UP() macros

2011-11-23 Thread Stefan Hajnoczi
Add macros for aligning a number to a multiple, for example:

QEMU_ALIGN_DOWN(500, 2000) = 0
QEMU_ALIGN_UP(500, 2000) = 2000

Since ALIGN_UP() is a common macro name use the QEMU_* namespace prefix.
Hopefully this will protect us from included headers that leak something
with a similar name.

Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 qemu-common.h |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/qemu-common.h b/qemu-common.h
index 2ce47aa..44870fe 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -341,6 +341,12 @@ static inline uint64_t muldiv64(uint64_t a, uint32_t b, 
uint32_t c)
 return res.ll;
 }
 
+/* Round number down to multiple */
+#define QEMU_ALIGN_DOWN(n, m) ((n) / (m) * (m))
+
+/* Round number up to multiple */
+#define QEMU_ALIGN_UP(n, m) QEMU_ALIGN_DOWN((n) + (m) - 1, (m))
+
 #include module.h
 
 #endif
-- 
1.7.7.1




Re: [Qemu-devel] [PATCH] linux-user/strace.c: Correct errno printing for mmap etc

2011-11-23 Thread Riku Voipio
On Mon, Nov 21, 2011 at 12:21:19PM +, Peter Maydell wrote:
 Correct the printing of errnos for syscalls which are handled
 via print_syscall_ret_addr (mmap, mmap2, brk, shmat): errnos
 are returned as negative returned values at this level, not
 via the host 'errno' variable.
 
 Signed-off-by: Peter Maydell peter.mayd...@linaro.org
 ---
 This applies on top of Alex's [v3] linux-user: fix QEMU_STRACE=1 segfault
 patch. It is fixing a separate bug to that patch, but OTOH it does touch
 only four lines of actual code, all of which were added in that patch.
 Keep it separate or fold it in with that one, I don't mind.

I think in general it is recommended to squash patches that only change lines
added in the previous patch. Otoh it muddies the authorship of the change.
Thus, unless someone objects, I'll que these as separate patches so both
of you get clear credit.

Riku

  linux-user/strace.c |9 -
  1 files changed, 4 insertions(+), 5 deletions(-)
 
 diff --git a/linux-user/strace.c b/linux-user/strace.c
 index 269481e..05a0d3e 100644
 --- a/linux-user/strace.c
 +++ b/linux-user/strace.c
 @@ -1,5 +1,4 @@
  #include stdio.h
 -#include errno.h
  #include sys/ipc.h
  #include sys/msg.h
  #include sys/sem.h
 @@ -286,11 +285,11 @@ print_syscall_ret_addr(const struct syscallname *name, 
 abi_long ret)
  {
  char *errstr = NULL;
  
 -if (ret == -1) {
 -errstr = target_strerror(errno);
 +if (ret  0) {
 +errstr = target_strerror(-ret);
  }
 -if ((ret == -1)  errstr) {
 -gemu_log( = -1 errno=%d (%s)\n, errno, errstr);
 +if (errstr) {
 +gemu_log( = -1 errno=%d (%s)\n, (int)-ret, errstr);
  } else {
  gemu_log( = 0x TARGET_ABI_FMT_lx \n, ret);
  }
 -- 
 1.7.1



Re: [Qemu-devel] [PATCH] linux-user/strace.c: Correct errno printing for mmap etc

2011-11-23 Thread Alexander Graf

On 11/23/2011 02:15 PM, Riku Voipio wrote:

On Mon, Nov 21, 2011 at 12:21:19PM +, Peter Maydell wrote:

Correct the printing of errnos for syscalls which are handled
via print_syscall_ret_addr (mmap, mmap2, brk, shmat): errnos
are returned as negative returned values at this level, not
via the host 'errno' variable.



Signed-off-by: Peter Maydellpeter.mayd...@linaro.org
---
This applies on top of Alex's [v3] linux-user: fix QEMU_STRACE=1 segfault
patch. It is fixing a separate bug to that patch, but OTOH it does touch
only four lines of actual code, all of which were added in that patch.
Keep it separate or fold it in with that one, I don't mind.

I think in general it is recommended to squash patches that only change lines
added in the previous patch. Otoh it muddies the authorship of the change.
Thus, unless someone objects, I'll que these as separate patches so both
of you get clear credit.


I am completely indifferent :).


Alex




Re: [Qemu-devel] [Bug 893956] [NEW] qemu-img bug with dynamic vhd

2011-11-23 Thread Stefan Hajnoczi
On Wed, Nov 23, 2011 at 11:33 AM, z22lad 893...@bugs.launchpad.net wrote:
 Hye, i found a problem with qemu-img when trying to get info of a
 dynamic vhd. I made imgae of my 60GB computer hard drive with disk2vhd.
 The dynamic vhd is 21gb size.

 With 1.0-rc3 version :
 running command: qemu-img info 60_GB.VHD
 qemu-img:  Could not open '60_GB.VHD' : File too large

 0.14.1 version give me wrong information :
 image: 60_GB.VHD
 file format: vpc
 virtual size: 127G (13683600 bytes)
 disk size: 21G

Which host OS are you running qemu-img on?  Is it 32- or 64-bit?

I wonder if you get the same behavior when using qemu-img convert
instead of disk2vhd to create a vhd file.

Stefan



Re: [Qemu-devel] cannot build qemu with --static configure option

2011-11-23 Thread Paolo Bonzini

On 11/23/2011 01:58 PM, Mr Dash Four wrote:

It would indicate a missing libssl3, but the library, as far as I can
see, is there! When I try building this without the --static option
all is well - the build succeeds without any hitches. What could be the
problem with this, what am I missing?


Perhaps you lack a static version of the library.

Paolo




Re: [Qemu-devel] cannot build qemu with --static configure option

2011-11-23 Thread Mr Dash Four



It would indicate a missing libssl3, but the library, as far as I can
see, is there! When I try building this without the --static option
all is well - the build succeeds without any hitches. What could be the
problem with this, what am I missing?


Perhaps you lack a static version of the library.
What do you mean by that? The *.la files? I wasn't aware that there are 
any...




Re: [Qemu-devel] cannot build qemu with --static configure option

2011-11-23 Thread Peter Maydell
On 23 November 2011 12:58, Mr Dash Four mr.dash.f...@googlemail.com wrote:
 I am trying to build a static version of the qemu-[arch] executables to be
 used in chrooted environment for the target arch (which is different from
 the host). My configure is:

 ./configure --target-list=x86_64-softmmu arm-softmmu x86_64-linux-user
 arm-linux-user armeb-linux-user --disable-kvm --disable-strip --disable-xen
 --disable-spice --disable-werror --static

 then make V=1. It fails with the following error:

You're trying to build the -softmmu targets with --static here too
(which means we try to compile a bunch of things that were never intended
to be run as static executables that way).
You're probably better off doing two separate configure and build
runs, one with just the -linux-user targets and --static, and the other
with just the -softmmu targets (and no --static).

Having said that, building arm-softmmu with --static works for me:
which version of QEMU are you trying to build? (we might have fixed
this in the 1.0 release candidate, so that's worth testing.)

-- PMM



Re: [Qemu-devel] [PATCH v2 0/9] block: replace .bdrv_is_allocated() with .bdrv_co_is_allocated()

2011-11-23 Thread Kevin Wolf
Am 14.11.2011 13:44, schrieb Stefan Hajnoczi:
 The bdrv_is_allocated() interface is not suitable for use while the VM is
 running.  It is a synchronous interface so it may block the running VM for
 arbitrary amounts of time.  It also assumes it is the only block driver
 operation and there is a risk that internal state could be corrupted if
 asynchronous I/O is currently pending.
 
 This patch series refactors the block layer so that the bdrv_is_allocated()
 operation is performed internally in coroutine context.  We can then introduce
 a new public bdrv_co_is_allocated() function that is suitable for use when the
 VM is running.
 
 Making these changes without breaking git bisect means we need to first
 introduce BlockDriver .bdrv_co_is_allocated() and add wrapper code into
 bdrv_is_allocated() so existing callers can use converted BlockDrivers.
 
 After converting all block drivers there are no .bdrv_is_allocated() functions
 left and the interface can be removed from BlockDriver.
 
 Finally, we can add the new public bdrv_co_is_allocated() public interface and
 turn the old bdrv_is_allocated() into a wrapper.
 
 This series is a prerequisite for copy-on-read, which needs to check whether
 sectors are allocated while the VM is running.
 
 v2:
  * Rebased on kevin/block and resolved conflicts
 
 Stefan Hajnoczi (9):
   block: use public bdrv_is_allocated() interface
   block: add .bdrv_co_is_allocated()
   qed: convert to .bdrv_co_is_allocated()
   block: convert qcow2, qcow2, and vmdk to .bdrv_co_is_allocated()
   vvfat: convert to .bdrv_co_is_allocated()
   vdi: convert to .bdrv_co_is_allocated()
   cow: convert to .bdrv_co_is_allocated()
   block: drop .bdrv_is_allocated() interface
   block: add bdrv_co_is_allocated() interface
 
  block.c   |   58 +++-
  block.h   |2 +
  block/cow.c   |8 +++---
  block/qcow.c  |8 --
  block/qcow2.c |   13 +++
  block/qed.c   |   15 ++---
  block/vdi.c   |6 ++--
  block/vmdk.c  |8 --
  block/vvfat.c |4 +-
  block_int.h   |4 +-
  10 files changed, 94 insertions(+), 32 deletions(-)

Thanks, applied all to the block branch (for 1.1)

Kevin



Re: [Qemu-devel] [PATCH] Add basic read, write and create support for AMD SimNow HDD images.

2011-11-23 Thread François Revol
Hi,

Le 01/12/2010 11:38, Stefan Hajnoczi a écrit :
 This block driver does not implement the asynchronous APIs
 (bdrv_aio_writev, bdrv_aio_readv, bdrv_aio_flush) which are necessary
 for running a VM properly.  Some block drivers are currently written
 without async support and that limits them to being used as qemu-img
 formats.  It's a bad idea to run a VM with these block drivers because
 I/O will block the VM from making progress (it is synchronous).

I'm digging old stuff at the moment...
It seems to be the coroutine calls recently introduced makes aio
optional, does it ?

I added co versions of the calls in the code and it seems to work.
It passes the qemu-iotests:
Not run: 006 007 013 014 015 016 017 018 019 020 022 023 024 025 026 027 028
Passed all 11 tests

But before I submit the patch again I'll rather have it written correctly.

 +typedef struct BDRVHddState {
 +uint8_t identify_data[SECTOR_SIZE];
 
 Perhaps identify_data[] should be uint16_t since it gets casted on every use.

I tried doing so but you end up adding many other casts everywhere
and another #define to ...SIZE/sizeof(uint16_t) which doesn't look
better though.

 +static void padstr(char *str, const char *src, int len)
 +{
 +int i, v;
 +for(i = 0; i  len; i++) {
 +if (*src)
 +v = *src++;
 +else
 +v = ' ';
 +str[i^1] = v;
 +}
 +}
 
 This function is confusing, it uses int v instead of char.  The name
 padstr() doesn't hint that it also byteswaps the string.

Well it was copied verbatim from another file.
I now added a comment mentioning it.

 QEMU coding style uses {} even for one-line if statement bodies
 (Section 4 in the CODING_STYLE file).

Well it was copied verbatim from another file. :P

 +static int hdd_probe(const uint8_t *buf, int buf_size, const char *filename)
 
 HDD has no magic by which to identify valid files.  We need to avoid
 false positives because existing image files could be corrupted or VMs
 at least made unbootable.  Although using filename extensions to test
 for formats is lame, in this case I don't think we have another
 choice.

I suppose so, I didn't look any further but apart from checking the
geometry validity at several places in the header there is not much to
check for.

 +if (bdrv_read(bs-file, 0, s-identify_data, 1)  0) {
 +goto fail;
 +}
 
 We're assuming that BDRV_SECTOR_SIZE == SECTOR_SIZE == 512 throughout
 the code.  It would be safer to explicitly calculate against
 BDRV_SECTOR_SIZE.  It would be clearer to rename SECTOR_SIZE to
 ATA_IDENTIFY_SIZE.

Right, though the code would not work for SECTOR_SIZE != 512 since it's
the size of the header, so having it defined to something else would
make blocks unaligned anyway.
I'll use other defines but also an #error if SECTOR_SIZE doesn't fit to
make sure people don't try things without noticing.

 +/* TODO: specs says it can grow, so no need to always do this */
 +if (static_image) {
 +if (ftruncate(fd, sizeof(header) + blocks * SECTOR_SIZE)) {
 +result = -errno;
 +}
 +}
 
 Is there an issue with leaving ftruncate() out?  I don't see a reason
 to truncate.  If we want to preallocate then ftruncate() isn't
 appropriate anyway.

Right, it doesn't write zeroes on ext2 anyway.
I'd have to test without it first.

François.



Re: [Qemu-devel] [PATCH] imx.31 and KZM board support

2011-11-23 Thread Juan Quintela
Peter Maydell peter.mayd...@linaro.org wrote:
 On 22 November 2011 11:06, Juan Quintela quint...@redhat.com wrote:
 Peter Chubb pet...@gelato.unsw.edu.au wrote:


       vmstate_register(dev-qdev, -1, vmstate_imxg_timer, s);
 ???

 Any particular reason to prefer a vmstate_register() call
 over just having a SysBusDeviceInfo struct with the .qdev.vmsd
 field set? I tend to prefer the latter myself.

I didn't saw a .qdev to hijack into on the patch O:-)
I also preffer to put it inside .qdev, we get
registration/unregistration working for free.

Later, Juan.



Re: [Qemu-devel] cannot build qemu with --static configure option

2011-11-23 Thread Mr Dash Four



./configure --target-list=x86_64-softmmu arm-softmmu x86_64-linux-user
arm-linux-user armeb-linux-user --disable-kvm --disable-strip --disable-xen
--disable-spice --disable-werror --static

then make V=1. It fails with the following error:



You're trying to build the -softmmu targets with --static here too
(which means we try to compile a bunch of things that were never intended
to be run as static executables that way).
  

I see, noted!


You're probably better off doing two separate configure and build
runs, one with just the -linux-user targets and --static, and the other
with just the -softmmu targets (and no --static).
  

In other words:

1. ./configure --target-list=x86_64-linux-user arm-linux-user 
armeb-linux-user --disable-kvm --disable-strip --disable-xen 
--disable-spice --disable-werror --static  make V=1
2. ./configure --target-list=x86_64-softmmu arm-softmmu 
x86_64-linux-user arm-linux-user armeb-linux-user --disable-kvm 
--disable-strip --disable-xen --disable-spice --disable-werror  make V=1



Having said that, building arm-softmmu with --static works for me:
which version of QEMU are you trying to build? (we might have fixed
this in the 1.0 release candidate, so that's worth testing.)
  
OK, this is the problem I am facing: I have quad core machine with 
Fedora Core on it. I am using debootstrap (Fedora's own package!) to 
build chrooted environment for arm using binfmt_misc's unique 
capabilities to point to a statically-built qemu-arm to be used when 
debootstrap executes various arm-based binaries in the chrooted environment.


Now, in *all* Fedora-supplied QEMU packages there are no 
statically-built executables, just qemu-[arch] and qemu-[arch]-system - 
both of which are dynamically linked. That is of no use to me whatsoever 
because when deboostrap chroots to the arm-based root the libraries qemu 
needs in order to run won't be there!


So, what I am trying to do is build static qemu - qemu-arm-static, 
which is self-contained and by placing it in my arm-based chroot and 
configuring binfmt_misc (via /proc/sys) to point to it, this would allow 
debootstrap to do its work without problems.


It is worth noting that Debian have such statically-linked qemu package 
already (the package is called qemu-user-static if I am not mistaken), 
but when I use Debian's own qemu-arm-static for my host arch - x86_64, I 
get a very weird errors during debootstrap, so I am trying to build a 
native (i.e. Fedora-based) qemu static to see if I get the same error 
in order to isolate the problem.


I have tried to build/implement this by tweaking the source rpm (the 
.spec file in particular) which comes with the latest QEMU version 
distributed by Fedora (0.15-2 if I am not mistaken), but there are so 
many ugly hacks in there, that I soon abandoned this idea and thought it 
would be easier if I just unpack the source archive, apply the 
Fedora-supplied patches and manually execute my custom ./configure and 
then make so that I end up with qem-arm-static (or similarly-named 
executable file) and use this instead.


The problem I am having, as evident from my initial post, is that ld is 
going mad about missing libraries, even though the build succeeds if I 
remove the --static option. I will try what you have suggested to see 
if it works, but I wanted to know whether I am doing something 
fundamentally wrong here... I appreciate your input Peter!





Re: [Qemu-devel] [PATCH] Add basic read, write and create support for AMD SimNow HDD images.

2011-11-23 Thread Kevin Wolf
Am 23.11.2011 15:20, schrieb François Revol:
 Hi,
 
 Le 01/12/2010 11:38, Stefan Hajnoczi a écrit :
 This block driver does not implement the asynchronous APIs
 (bdrv_aio_writev, bdrv_aio_readv, bdrv_aio_flush) which are necessary
 for running a VM properly.  Some block drivers are currently written
 without async support and that limits them to being used as qemu-img
 formats.  It's a bad idea to run a VM with these block drivers because
 I/O will block the VM from making progress (it is synchronous).
 
 I'm digging old stuff at the moment...
 It seems to be the coroutine calls recently introduced makes aio
 optional, does it ?

Yes. In fact, if you have co_* functions, aio_* will never be called
because the coroutine ones are always preferred.

 I added co versions of the calls in the code and it seems to work.
 It passes the qemu-iotests:
 Not run: 006 007 013 014 015 016 017 018 019 020 022 023 024 025 026 027 028
 Passed all 11 tests
 
 But before I submit the patch again I'll rather have it written correctly.
 
 +typedef struct BDRVHddState {
 +uint8_t identify_data[SECTOR_SIZE];

 Perhaps identify_data[] should be uint16_t since it gets casted on every use.
 
 I tried doing so but you end up adding many other casts everywhere
 and another #define to ...SIZE/sizeof(uint16_t) which doesn't look
 better though.

Yeah, I can see that there are many byte accesses as well. Probably best
to leave it as it is.

 
 +static void padstr(char *str, const char *src, int len)
 +{
 +int i, v;
 +for(i = 0; i  len; i++) {
 +if (*src)
 +v = *src++;
 +else
 +v = ' ';
 +str[i^1] = v;
 +}
 +}

 This function is confusing, it uses int v instead of char.  The name
 padstr() doesn't hint that it also byteswaps the string.
 
 Well it was copied verbatim from another file.
 I now added a comment mentioning it.

Should be a common helper function somewhere then. Duplicating code is
always bad.

 QEMU coding style uses {} even for one-line if statement bodies
 (Section 4 in the CODING_STYLE file).
 
 Well it was copied verbatim from another file. :P

While moving it to a common place, fix the code style. ;-)

 +static int hdd_probe(const uint8_t *buf, int buf_size, const char 
 *filename)

 HDD has no magic by which to identify valid files.  We need to avoid
 false positives because existing image files could be corrupted or VMs
 at least made unbootable.  Although using filename extensions to test
 for formats is lame, in this case I don't think we have another
 choice.
 
 I suppose so, I didn't look any further but apart from checking the
 geometry validity at several places in the header there is not much to
 check for.

We should make sure to return a very low value so that any other
matching format will take precedence.

Or we could consider hdd_probe() { return 0; } and require the user to
specify the format explicitly. Would be a bit nasty to use, though.

 
 +if (bdrv_read(bs-file, 0, s-identify_data, 1)  0) {
 +goto fail;
 +}

 We're assuming that BDRV_SECTOR_SIZE == SECTOR_SIZE == 512 throughout
 the code.  It would be safer to explicitly calculate against
 BDRV_SECTOR_SIZE.  It would be clearer to rename SECTOR_SIZE to
 ATA_IDENTIFY_SIZE.
 
 Right, though the code would not work for SECTOR_SIZE != 512 since it's
 the size of the header, so having it defined to something else would
 make blocks unaligned anyway.
 I'll use other defines but also an #error if SECTOR_SIZE doesn't fit to
 make sure people don't try things without noticing.

I think QEMU_BUILD_BUG_ON() is what you're looking for.

 +/* TODO: specs says it can grow, so no need to always do this */
 +if (static_image) {
 +if (ftruncate(fd, sizeof(header) + blocks * SECTOR_SIZE)) {
 +result = -errno;
 +}
 +}

 Is there an issue with leaving ftruncate() out?  I don't see a reason
 to truncate.  If we want to preallocate then ftruncate() isn't
 appropriate anyway.
 
 Right, it doesn't write zeroes on ext2 anyway.
 I'd have to test without it first.

Please use bdrv_* functions instead of POSIX ones to create the image.

Kevin



[Qemu-devel] virDomainBlockJobAbort and block_job_cancel

2011-11-23 Thread Stefan Hajnoczi
Block job cancellation waits until the job has been cancelled before
returning.  This allows clients to know that the operation has been
cancelled successfully.  Unfortunately, these semantics are not really
possible with today's QEMU and libvirt code.

A command that waits for block I/O completion may wait for many
minutes.  During this time the monitor is unavailable.  While the QMP
protocol may in theory support multiple in-flight commands, both QEMU
and libvirt's implemenations are geared towards one command at a time.
 So in practice a hung cancellation command would make the monitor
unavailable - we need to avoid this.

This means block_job_cancel cannot wait until the job is cancelled or
it risks hanging the monitor if there is a block I/O timeout.  We need
a solution that reflects this in QEMU and libvirt, here is what I
propose:

block_job_cancel returns immediately upon marking the job cancelled.
The job may still be finishing block I/O but will cancel itself at
some point in the future.  When the job actually completes it raises
the new BLOCK_JOB_CANCELLED event.

This means that virDomainBlockJobAbort() returns to the client without
a guarantee that the job has completed.  If the client enumerates jobs
it may still see a job that has not finished cancelling.  The client
must register a handler for the BLOCK_JOB_CANCELLED event if it wants
to know when the job really goes away.  The BLOCK_JOB_CANCELLED event
has the same fields as the BLOCK_JOB_COMPLETED event, except it lacks
the optional error message field.

The impact on clients is that they need to add a BLOCK_JOB_CANCELLED
handler if they really want to wait.  Most clients today (not many
exist) will be fine without waiting for cancellation.

Any objections or thoughts on this?

Stefan



[Qemu-devel] [PATCH v2] cow: use bdrv_co_is_allocated()

2011-11-23 Thread Stefan Hajnoczi
Now that bdrv_co_is_allocated() is available we can use it instead of
the synchronous bdrv_is_allocated() interface.  This is a follow-up that
Kevin Wolf kw...@redhat.com pointed out after applying the series that
introduces bdrv_co_is_allocated().

It is safe to make cow_read() a coroutine_fn because its only caller is
a coroutine_fn.

Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
 block/cow.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/block/cow.c b/block/cow.c
index 7ae887b..586493c 100644
--- a/block/cow.c
+++ b/block/cow.c
@@ -171,14 +171,14 @@ static int cow_update_bitmap(BlockDriverState *bs, 
int64_t sector_num,
 return error;
 }
 
-static int cow_read(BlockDriverState *bs, int64_t sector_num,
-uint8_t *buf, int nb_sectors)
+static int coroutine_fn cow_read(BlockDriverState *bs, int64_t sector_num,
+ uint8_t *buf, int nb_sectors)
 {
 BDRVCowState *s = bs-opaque;
 int ret, n;
 
 while (nb_sectors  0) {
-if (bdrv_is_allocated(bs, sector_num, nb_sectors, n)) {
+if (bdrv_co_is_allocated(bs, sector_num, nb_sectors, n)) {
 ret = bdrv_pread(bs-file,
 s-cow_sectors_offset + sector_num * 512,
 buf, n * 512);
-- 
1.7.7.1




Re: [Qemu-devel] [RFC PATCH] Exporting Guest RAM information for NUMA binding

2011-11-23 Thread Andrea Arcangeli
Hi!

On Mon, Nov 21, 2011 at 07:51:21PM -0600, Anthony Liguori wrote:
 Fundamentally, the entity that should be deciding what memory should be 
 present 
 and where it should located is the kernel.  I'm fundamentally opposed to 
 trying 
 to make QEMU override the scheduler/mm by using cpu or memory pinning in QEMU.
 
  From what I can tell about ms_mbind(), it just uses process knowledge to 
 bind 
 specific areas of memory to a memsched group and let's the kernel decide what 
 to 
 do with that knowledge.  This is exactly the type of interface that QEMU 
 should 
 be using.
 
 QEMU should tell the kernel enough information such that the kernel can make 
 good decisions.  QEMU should not be the one making the decisions.

True, QEMU won't have to decide where the memory and vcpus should be
located (but hey it wouldn't need to decide that even if you use
cpusets, you can use relative mbind with cpusets, the admin or a
cpuset job scheduler could decide) but it's still QEMU making the
decision of what memory and which vcpus threads to
ms_mbind/ms_tbind. Think how you're going to create the input of those
syscalls...

If it wasn't qemu to decide that, qemu wouldn't be required to scan
the whole host physical numa (cpu/memory) topology in order to create
the input arguments of ms_mbind/ms_tbind. And when you migrate the
VM to another host, the whole vtopology may be counter-productive
because the kernel isn't automatically detecting the numa affinity
between threads and the guest vtopology will stick to whatever numa
_physical_ topology that was seen on the first node where the VM was
created.

I doubt that the assumption that all cloud nodes will have the same
physical numa topology is reasonable.

Furthermore to get the same benefits that qemu gets on host by using
ms_mbind/ms_tbind, every single guest application should be modified
to scan the guest vtopology and call ms_mbind/ms_tbind too (or use the
hard bindings which is what we try to avoid).

I think it's unreasonable to expect all applications to use
ms_mbind/ms_tbind in the guest, at best guest apps will use cpusets or
wrappers, few apps will be modified for sys_ms_tbind/mbind.

You can always have the supercomputer case with just one app that is
optimized and a single VM spanning over the whole host, but in that
scenarios hard bindings would work perfectly too.

In my view the trouble of the numa hard bindings is not the fact
they're hard and qemu has to also decide the location (in fact it
doesn't need to decide the location if you use cpusets and relative
mbinds). The bigger problem is the fact either the admin or the app
developer has to explicitly scan the numa physical topology (both cpus
and memory) and tell the kernel how much memory to bind to each
thread. ms_mbind/ms_tbind only partially solve that problem. They're
similar to the mbind MPOL_F_RELATIVE_NODES with cpusets, except you
don't need an admin or a cpuset-job-scheduler (or a perl script) to
redistribute the hardware resources.

Now dealing with bindings isn't big deal for qemu, in fact this API is
pretty much ideal for qemu, but it won't make life substantially
easier than if compared to hard bindings. Simply the management code
that is now done with a perl script will have to be moved in the
kernel. It looks an incremental improvement compared to the relative
mbind+cpuset, but I'm unsure if it's the best we could aim for and
what we really need in virt considering we deal with VM migration too.

The real long term design to me is not to add more syscalls, and
initially handling the case of a process/VM spanning not more than one
node in thread number and amount of memory. That's not too hard an in
fact I've benchmarks for the scheduler already showing it to work
pretty well (it's creating a too strict affinity but it can be relaxed
to be more useful). Then later add some mechanism (simplest is the
page fault at low frequency) to create a
guest_vcpu_thread-host_memory affinity and have a parvirtualized
interface that tells the guest scheduler to group CPUs.

If the guest scheduler runs free and is allowed to move threads
randomly without any paravirtualized interface that controls the CPU
thread migration in the guest scheduler, the thread-memory affinity
on host will be hopeless. But with a parvirtualized interface to make
a guest thread stick to vcpu0/1/2/3 and not going into vcpu4/5/6/7,
will allow to create a more meaningful guest_thread-physical_ram
affinity on host through KVM page faults. And then this will work also
with VM migration and without having to create a vtopology in guest.

And for apps running in guest no paravirt will be needed of course.

The reason paravirt would be needed for qemu-kvm with a full automatic
thread-memory affinity is that the vcpu threads are magic. What runs
in the vcpu thread are guest threads. And those can move through the
guest CPU scheduler from vcpu0 to vcpu7. If that happens and we've 4
physical cpu for each physical node, any affinity 

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

2011-11-23 Thread Aneesh Kumar K.V
On Wed, 23 Nov 2011 08:24:53 +0100, Paolo Bonzini pbonz...@redhat.com wrote:
 On 11/23/2011 07:16 AM, Aneesh Kumar K.V wrote:
  We would also require same changes for virtio-9p-handle.c right ?
 
 virtio-9p-handle.c is only for recent Linux and you can assume the ioctl 
 is defined there.

But the file gets build by default right ? ie, we would build
virtio-9p-handle.c and if FS_IOC_GETVERSION is not defined, build will
fail right ?

-aneesh




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

2011-11-23 Thread Paolo Bonzini

On 11/23/2011 04:11 PM, Aneesh Kumar K.V wrote:


  virtio-9p-handle.c is only for recent Linux and you can assume the ioctl
  is defined there.

But the file gets build by default right ? ie, we would build
virtio-9p-handle.c and if FS_IOC_GETVERSION is not defined, build will
fail right ?


I think you're right.  Strange that Erik did not see it.

Paolo



Re: [Qemu-devel] cannot build qemu with --static configure option

2011-11-23 Thread Paolo Bonzini

On 11/23/2011 03:15 PM, Mr Dash Four wrote:

It would indicate a missing libssl3, but the library, as far as I can
see, is there! When I try building this without the --static option
all is well - the build succeeds without any hitches. What could be the
problem with this, what am I missing?


Perhaps you lack a static version of the library.

What do you mean by that? The *.la files? I wasn't aware that there are
any...


I mean lib*.a files.  They are needed if you specify static, by definition.

Paolo



[Qemu-devel] MMU address collision.

2011-11-23 Thread Michael Rolnik
Hi all,


I have a question regarding MMU.
I've built SPARC based small embedded system.
at this system addresses *0x-0x8000*  (32KB) belong to ROM
and *0x8000
- 0x80001000* to HW devices.
the problem is that when a code from first ROM page accesses a HW device
register there is an infinite loop.



-- 
Best Regards,
Michael Rolnik


Re: [Qemu-devel] MMU address collision.

2011-11-23 Thread Michael Rolnik
Hi all,


I have a question regarding MMU.
I've built SPARC based small embedded system.
at this system addresses *0x-0x8000*  (32KB) belong to ROM
and *0x8000
- 0x80001000* to HW devices.
the problem is that when a code from first ROM page accesses a HW device
register there is an infinite loop.
   - cpu_sparc_handle_mmu_fault is called to bring page 0
   - cpu_sparc_handle_mmu_fault is called to bring 0x8000 and flushes
0x
   - cpu_sparc_handle_mmu_fault is called to bring 0x and flushes
0x8000
 ...

this can be fixed if I set CPU_TLB_BITS to be 20 bits.

is there a better solution?

Michael


Re: [Qemu-devel] cannot build qemu with --static configure option

2011-11-23 Thread Mr Dash Four



Perhaps you lack a static version of the library.

What do you mean by that? The *.la files? I wasn't aware that there are
any...


I mean lib*.a files.  They are needed if you specify static, by 
definition.
Hmm, this opens a huge Pandora's box for me - in my own distribution 
(Fedora) the nss package (which I have installed) provides 
/usr/lib64/libssl3.so, but not libssl3.a. nss-devel (which I also have 
installed) provides all the relevant /include files (headers and the 
like), but there is no libssl3.a there either! There is no package 
called nss-devel-static distributed by Fedora and the only .a files 
produced by compiling the nss source are libcrmf.a libnssb.a and 
libnssckfw.a - no libssl3.a at all. So, where do I get this?


Also, assuming libssl3 is not the only one, ld will probably complain 
that there are other .a files missing from various other packages 
which are probably not present in my host machine. If that is the case, 
this is an absolute nightmare to have to deal with! Where do I get these 
files? Thanks for your input Paolo.




[Qemu-devel] [PATCH v2 0/8] [RFC] vmstate: Add copyrights for all cpus

2011-11-23 Thread Juan Quintela
Hi

[ Resnd this time also ading fabrice address, sorry ]

v2:
- split patches by file, make easier to add acked-by notices.
- cc'd fabrice
- everybody (except for Thiemo for ovbious reasons) answered.
- move ppc/sparc/i386 to BSD like license from vl.c at Blue
  suggestion. 

- move all other licenses to GPL v2 or later (notice that I had forget
  the later part on the 1st submission).  Notice this change for the
  people that acked previous version.

Any other comments?

v1:

This patch adds copyrights to all the machine description files for
all architectures supported. (this is done on top of my vmstate-cpus
series patches) The problem?

- What should we put as copyirght owners.

Althought I modified almost every line of the files, mostly of the
changes are a conversion, so claiming myself as the only copyright
owner sounds at least pretentious, and more than probably false.

I tried to dig into the git logs and tried to came with whoever
commit the initial cpu_save/load foar each architecture.  I have put
them as:

 * Based on qemu-file support done by:
 *   Richard Henderson r...@twiddle.net

But I would preffer that the persons involved state what copyright
notice they want, name, address, year(s), etc.  (Some architectures
already have a propper copyright notice, I didn't touch them), and
others had an empty file (I put mine there on the previosu series).

Several of the logs are from the svn days, and then I don't know if
the person was the committer, or the author.  If anyone contributed
to the functionality and want to add its copyright, please told me.

To make things more complicated, when machine.c files were split from
vl.c, they didn't carry any copyright notice at all, should we copy
back everything from vl.c?

To make things more complicated, it looks like Thiemo Seufer did the
original mips support, and he passed away.  So he can't obviously
comment.

Anthony asked me to send a patch to the list, asking form comments.

alpha:
CC: Richard Henderson r...@twiddle.net

arm:
CC: Andrzej Zaborowski andrew.zaborow...@intel.com

  (it appears as balrog, but on irc channel peter told me that balrog
  has him)

cris:
CC: Edgar E. Iglesias edgar.igles...@gmail.com

i386:

Fabrice Bellard?

 * Copyright (c) 2003-2008 Fabrice Bellard

Didn't cc'd him because he left project/didn't have email address on
MAINTAINERS/vl.c.  If you think that I should cc'd to him, just let me
know.

lm32:

CC: Michael Walle mich...@walle.cc

mips:

Thiemo Seufer?

ppc  sparc:

CC: Blue Swirl blauwir...@gmail.com


What do you think, what should we do?  Juan.



*** BLURB HERE ***

Juan Quintela (8):
  vmstate: Add copyright info for alpha processor
  vmstate: Add copyright info for lm32 processor
  vmstate: Add copyright info for cris processor
  vmstate: Add copyright info for arm processor
  vmstate: Add copyright info for i386 processor
  vmstate: Add copyright info for mips processor
  vmstate: Add copyright info for ppc processor
  vmstate: Add copyright info for sparc processor

 target-alpha/vmstate-cpu.c |   15 +++
 target-arm/vmstate-cpu.c   |   15 +++
 target-cris/vmstate-cpu.c  |   15 +++
 target-i386/vmstate-cpu.c  |   28 
 target-lm32/vmstate-cpu.c  |   15 +++
 target-mips/vmstate-cpu.c  |   29 +
 target-ppc/vmstate-cpu.c   |   28 
 target-sparc/vmstate-cpu.c |   29 +
 8 files changed, 174 insertions(+), 0 deletions(-)

-- 
1.7.7.1




[Qemu-devel] [PATCH 3/8] vmstate: Add copyright info for cris processor

2011-11-23 Thread Juan Quintela
Signed-off-by: Juan Quintela quint...@redhat.com
Acked-by: Edgar E. Iglesias edgar.igles...@gmail.com
---
 target-cris/vmstate-cpu.c |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/target-cris/vmstate-cpu.c b/target-cris/vmstate-cpu.c
index 0f732d3..f062272 100644
--- a/target-cris/vmstate-cpu.c
+++ b/target-cris/vmstate-cpu.c
@@ -1,3 +1,18 @@
+/*
+ * Migration support for cris cpus
+ *
+ * Copyright (C) 2011 Red Hat, Inc.
+ *
+ * Author(s):
+ *  Juan Quintela quint...@redhat.com
+ *
+ * Based on qemu-file support done by:
+ *  Edgar E. Iglesias edgar.igles...@gmail.com
+ *
+ * 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 hw/hw.h

 static const VMStateDescription vmstate_tlbset = {
-- 
1.7.7.1




[Qemu-devel] [PATCH 1/8] vmstate: Add copyright info for alpha processor

2011-11-23 Thread Juan Quintela
Signed-off-by: Juan Quintela quint...@redhat.com
Acked-by: Richard Henderson r...@twiddle.net
---
 target-alpha/vmstate-cpu.c |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/target-alpha/vmstate-cpu.c b/target-alpha/vmstate-cpu.c
index 156cb74..9d4b065 100644
--- a/target-alpha/vmstate-cpu.c
+++ b/target-alpha/vmstate-cpu.c
@@ -1,3 +1,18 @@
+/*
+ * Migration support for alpha cpus
+ *
+ * Copyright (C) 2011 Red Hat, Inc.
+ *
+ * Author(s):
+ *  Juan Quintela quint...@redhat.com
+ *
+ * Based on qemu-file support done by:
+ *   Richard Henderson r...@twiddle.net
+ *
+ * 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 hw/hw.h

 static int get_fpcr(QEMUFile *f, void *opaque, size_t size)
-- 
1.7.7.1




[Qemu-devel] [PATCH 4/8] vmstate: Add copyright info for arm processor

2011-11-23 Thread Juan Quintela
Signed-off-by: Juan Quintela quint...@redhat.com
Acked-by: Andrzej Zaborowski andrew.zaborow...@intel.com
---
 target-arm/vmstate-cpu.c |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/target-arm/vmstate-cpu.c b/target-arm/vmstate-cpu.c
index 836d9ed..bc48434 100644
--- a/target-arm/vmstate-cpu.c
+++ b/target-arm/vmstate-cpu.c
@@ -1,3 +1,18 @@
+/*
+ * Migration support for arm cpus
+ *
+ * Copyright (C) 2011 Red Hat, Inc.
+ *
+ * Author(s):
+ *  Juan Quintela quint...@redhat.com
+ *
+ * Based on qemu-file support done by:
+ *  Andrzej Zaborowski andrew.zaborow...@intel.com
+ *
+ * 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 hw/hw.h

 static bool feature_vfp_needed(void *opaque)
-- 
1.7.7.1




[Qemu-devel] [PATCH 6/8] vmstate: Add copyright info for mips processor

2011-11-23 Thread Juan Quintela
v2: Move license to BSD-like as in vl.c

Signed-off-by: Juan Quintela quint...@redhat.com
---
 target-mips/vmstate-cpu.c |   29 +
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/target-mips/vmstate-cpu.c b/target-mips/vmstate-cpu.c
index d6d7830..f709cf2 100644
--- a/target-mips/vmstate-cpu.c
+++ b/target-mips/vmstate-cpu.c
@@ -1,3 +1,32 @@
+/*
+ * Migration support for mips cpu
+ *
+ * Copyright (c) 2003-2008 Fabrice Bellard
+ * Copyright (c) 2003-2008 Thiemo Seufer
+ * Copyright (c) 2011 Red Hat, Inc.
+ *
+ * Author(s):
+ *  Juan Quintela quint...@redhat.com
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
 #include hw/hw.h

 static const VMStateDescription vmstate_tc = {
-- 
1.7.7.1




[Qemu-devel] [PATCH 5/8] vmstate: Add copyright info for i386 processor

2011-11-23 Thread Juan Quintela
v2: Move license to BSD-like as in vl.c
Add Fabrice copyright from vl.c

Signed-off-by: Juan Quintela quint...@redhat.com
---
 target-i386/vmstate-cpu.c |   28 
 1 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/target-i386/vmstate-cpu.c b/target-i386/vmstate-cpu.c
index 838983e..442a1f0 100644
--- a/target-i386/vmstate-cpu.c
+++ b/target-i386/vmstate-cpu.c
@@ -1,3 +1,31 @@
+/*
+ * Migration support for x86 cpu
+ *
+ * Copyright (c) 2003-2008 Fabrice Bellard
+ * Copyright (c) 2011 Red Hat, Inc.
+ *
+ * Author(s):
+ *  Juan Quintela quint...@redhat.com
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
 #include hw/hw.h

 static const VMStateDescription vmstate_segment = {
-- 
1.7.7.1




[Qemu-devel] [PATCH 7/8] vmstate: Add copyright info for ppc processor

2011-11-23 Thread Juan Quintela
v2: Move license to BSD-like as in vl.c

Signed-off-by: Juan Quintela quint...@redhat.com
---
 target-ppc/vmstate-cpu.c |   28 
 1 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/target-ppc/vmstate-cpu.c b/target-ppc/vmstate-cpu.c
index 1664d32..9e36a18 100644
--- a/target-ppc/vmstate-cpu.c
+++ b/target-ppc/vmstate-cpu.c
@@ -1,3 +1,31 @@
+/*
+ * Migration support for ppc cpu
+ *
+ * Copyright (c) 2003-2011 Blue Swirl blauwir...@gmail.com
+ * Copyright (c) 2011 Red Hat, Inc.
+ *
+ * Author(s):
+ *  Juan Quintela quint...@redhat.com
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
 #include hw/hw.h

 static const VMStateDescription vmstate_tlb = {
-- 
1.7.7.1




Re: [Qemu-devel] [RFC PATCH 0/2] Fix migration with NFS iscsi/Fiber channel

2011-11-23 Thread Juan Quintela
Juan Quintela quint...@redhat.com wrote:

snip

Hi

I did the stupid thing, and send the wrong directory of patches, sorry
for any inconveniences.

/me writes 100 times: I have to re-read the whole command line before
sending patches

/me writes another 100 times

Later, Juan.



[Qemu-devel] [Bug 894037] [NEW] With VNC, -usbdevice tablet no longer makes mouse pointers line up

2011-11-23 Thread Timothy Miller
Public bug reported:

I use qemu in VNC mode.  In order to get the client and server mouse
pointers to line up, I've had to use the -usbdevice tablet option.
This no longer works, and it behaves the same as if the option is not
there.  This makes my VMs unusable to me.

Here's how I'm booting WinXP:

qemu-system-x86_64 -vga std -drive
cache=writeback,index=0,media=disk,file=winxp.img -k en-us -m 2048 -smp
2 -vnc :3101 -usbdevice tablet -boot c -enable-kvm 

The Windows install hasn't changed, only qemu.

I'm running this version of QEMU:

QEMU emulator version 0.15.0 (qemu-kvm-0.15.0), Copyright (c) 2003-2008
Fabrice Bellard

I'll see about upgrading to 0.15.1, but since I haven't seen other
reports of this particular problem in your DB, I'm assuming that this
problem has not been fixed between 0.15.0 and 0.15.1.

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  With VNC, -usbdevice tablet no longer makes mouse pointers line up

Status in QEMU:
  New

Bug description:
  I use qemu in VNC mode.  In order to get the client and server mouse
  pointers to line up, I've had to use the -usbdevice tablet option.
  This no longer works, and it behaves the same as if the option is not
  there.  This makes my VMs unusable to me.

  Here's how I'm booting WinXP:

  qemu-system-x86_64 -vga std -drive
  cache=writeback,index=0,media=disk,file=winxp.img -k en-us -m 2048
  -smp 2 -vnc :3101 -usbdevice tablet -boot c -enable-kvm 

  The Windows install hasn't changed, only qemu.

  I'm running this version of QEMU:

  QEMU emulator version 0.15.0 (qemu-kvm-0.15.0), Copyright (c)
  2003-2008 Fabrice Bellard

  I'll see about upgrading to 0.15.1, but since I haven't seen other
  reports of this particular problem in your DB, I'm assuming that this
  problem has not been fixed between 0.15.0 and 0.15.1.

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



Re: [Qemu-devel] husb: out of buffers for iso stream

2011-11-23 Thread Gerd Hoffmann
On 11/19/11 20:40, Stefan Hajnoczi wrote:
 I have a Windows 7 VM running a sound driver for a passthrough USB
 host device.  The driver submits iso in and out urbs to do audio
 capture and playback at the same time.
 
 Audacity running inside the guest freezes and does not record audio
 unless I move the mouse.  Somehow it seems USB iso urbs aren't being
 pumped unless I keep moving the mouse.  The VM is using VNC.

I have no idea how moving the mouse could possibly help here.

 Checking the QEMU stderr logs I see many occurrences of husb: out of
 buffers for iso stream.  Perhaps this message is enough to pinpoint
 the problem?

It means the number of buffers in flight (on the host side) went down to
zero, i.e. the stream is interrupted.

usb-host maintains a set of buffers (four by default) per iso endpoint
to keep the constant data flow up, i.e. pass one buffer to the guest
while the host fills the next one.  Now the host has no more buffers to
fill.  Most likely usb-host sits on a bunch of full buffers which it
hasn't passed to the guest yet.

For starter try a higher number of buffers (isobufs property).
Also make sure you enable the vnc thread (unless you have already).

cheers,
  Gerd




Re: [Qemu-devel] [PATCH v2] Support for UDP unicast network backend

2011-11-23 Thread Benjamin


Signed-off-by: Benjamin MARSILI marsi...@epitech.eu
---
 net.c   |6 -
 net/socket.c|   71 
+-

 qemu-options.hx |2 +
 3 files changed, 76 insertions(+), 3 deletions(-)

diff --git a/net.c b/net.c
index cb52050..8e957b2 100644
--- a/net.c
+++ b/net.c
@@ -999,7 +999,11 @@ static const struct {
 }, {
 .name = localaddr,
 .type = QEMU_OPT_STRING,
-.help = source address for multicast packets,
+.help = source address and port for multicast and udp 
packets,

+}, {
+.name = udp,
+.type = QEMU_OPT_STRING,
+.help = UDP unicast address and port number,
 },
 { /* end of list */ }
 },
diff --git a/net/socket.c b/net/socket.c
index e9ef128..ca183f2 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -524,6 +524,55 @@ static int net_socket_mcast_init(VLANState *vlan,

 }

+static int net_socket_udp_init(VLANState *vlan,
+ const char *model,
+ const char *name,
+ const char *rhost,
+ const char *lhost)
+{
+NetSocketState *s;
+int fd, val, ret;
+struct sockaddr_in laddr, raddr;
+
+if (parse_host_port(laddr, lhost)  0) {
+return -1;
+}
+
+if (parse_host_port(raddr, rhost)  0) {
+return -1;
+}
+
+fd = qemu_socket(PF_INET, SOCK_DGRAM, 0);
+if (fd  0) {
+perror(socket(PF_INET, SOCK_DGRAM));
+return -1;
+}
+val = 1;
+ret = setsockopt(fd, SOL_SOCKET, SO_REUSEADDR,
+   (const char *)val, sizeof(val));
+if (ret  0) {
+perror(setsockopt(SOL_SOCKET, SO_REUSEADDR));
+return -1;
+}
+ret = bind(fd, (struct sockaddr *)laddr, sizeof(laddr));
+if (ret  0) {
+perror(bind);
+return -1;
+}
+
+s = net_socket_fd_init(vlan, model, name, fd, 0);
+if (!s) {
+return -1;
+}
+
+s-dgram_dst = raddr;
+
+snprintf(s-nc.info_str, sizeof(s-nc.info_str),
+ socket: udp=%s:%d,
+ inet_ntoa(raddr.sin_addr), ntohs(raddr.sin_port));
+return 0;
+}
+
 int net_init_socket(QemuOpts *opts,
 Monitor *mon,
 const char *name,
@@ -597,10 +646,28 @@ int net_init_socket(QemuOpts *opts,
 if (net_socket_mcast_init(vlan, socket, name, mcast, 
localaddr) == -1) {

 return -1;
 }
+} else if (qemu_opt_get(opts, udp)) {
+const char *udp, *localaddr;
+
+if (qemu_opt_get(opts, fd) ||
+qemu_opt_get(opts, connect) ||
+qemu_opt_get(opts, listen) ||
+qemu_opt_get(opts, mcast)) {
+error_report(fd=, connect=, listen=\
+ and mcast= is invalid with udp=);
+return -1;
+}
+
+udp = qemu_opt_get(opts, udp);
+localaddr = qemu_opt_get(opts, localaddr);
+
+if (net_socket_udp_init(vlan, udp, name, udp, localaddr) == -1) {
+return -1;
+}
 } else {
-error_report(-socket requires fd=, listen=, connect= or mcast=);
+error_report(-socket requires fd=, listen=, \
+ connect=, mcast= or udp=);
 return -1;
 }
-
 return 0;
 }
diff --git a/qemu-options.hx b/qemu-options.hx
index 681eaf1..5495368 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1217,6 +1217,8 @@ DEF(net, HAS_ARG, QEMU_OPTION_net,
 -net 
socket[,vlan=n][,name=str][,fd=h][,mcast=maddr:port[,localaddr=addr]]\n

 connect the vlan 'n' to multicast maddr and port\n
 use 'localaddr=addr' to specify the host address 
to send packets from\n
+-net 
socket[,vlan=n][,name=str][,fd=h][,udp=host:port][,localaddr=host:port]\n
+connect the vlan 'n' to another VLAN using an UDP 
tunnel\n

 #ifdef CONFIG_VDE
 -net 
vde[,vlan=n][,name=str][,sock=socketpath][,port=n][,group=groupname][,mode=octalmode]\n
 connect the vlan 'n' to port 'n' of a vde switch 
running\n

--
1.7.3.5

Is this better? Sent the patch by hand since I didn't configure my mail
client yet. Will do for the next patches.

Thanks for your help,

Benjamin



Re: [Qemu-devel] [libvirt] virDomainBlockJobAbort and block_job_cancel

2011-11-23 Thread Eric Blake
On 11/23/2011 07:48 AM, Stefan Hajnoczi wrote:
 This means that virDomainBlockJobAbort() returns to the client without
 a guarantee that the job has completed.  If the client enumerates jobs
 it may still see a job that has not finished cancelling.  The client
 must register a handler for the BLOCK_JOB_CANCELLED event if it wants
 to know when the job really goes away.  The BLOCK_JOB_CANCELLED event
 has the same fields as the BLOCK_JOB_COMPLETED event, except it lacks
 the optional error message field.
 
 The impact on clients is that they need to add a BLOCK_JOB_CANCELLED
 handler if they really want to wait.  Most clients today (not many
 exist) will be fine without waiting for cancellation.
 
 Any objections or thoughts on this?

virDomainBlockJobAbort() thankfully has an 'unsigned int flags'
argument.  For backwards-compatibility, I suggest we use it:

calling virDomainBlockJobAbort(,0) maintains old blocking behavior, and
we document that blocking until things abort may render the rest of
interactions with the domain unresponsive.

The new virDomainBlockJobAbort(,VIR_DOMAIN_BLOCK_JOB_ABORT_ASYNC) would
then implement your new proposed semantics of returning immediately once
the cancellation has been requested, even if it hasn't been acted on yet.

Maybe you could convince me to swap the flags: have 0 change semantics
to non-blocking, and a new flag to request blocking, where callers that
care have to try the flag, and if the flag is unsupported then they know
they are talking to older libvirtd where the behavior is blocking by
default, but that's a bit riskier.

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



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH v2] cow: use bdrv_co_is_allocated()

2011-11-23 Thread Kevin Wolf
Am 23.11.2011 16:00, schrieb Stefan Hajnoczi:
 Now that bdrv_co_is_allocated() is available we can use it instead of
 the synchronous bdrv_is_allocated() interface.  This is a follow-up that
 Kevin Wolf kw...@redhat.com pointed out after applying the series that
 introduces bdrv_co_is_allocated().
 
 It is safe to make cow_read() a coroutine_fn because its only caller is
 a coroutine_fn.
 
 Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com

Thanks, applied to the block branch (for 1.1)

Kevin



[Qemu-devel] [PATCH 2/8] vmstate: Add copyright info for lm32 processor

2011-11-23 Thread Juan Quintela
Signed-off-by: Juan Quintela quint...@redhat.com
Acked-By: Michael Walle mich...@walle.cc
---
 target-lm32/vmstate-cpu.c |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/target-lm32/vmstate-cpu.c b/target-lm32/vmstate-cpu.c
index 60b4b29..27e09d2 100644
--- a/target-lm32/vmstate-cpu.c
+++ b/target-lm32/vmstate-cpu.c
@@ -1,3 +1,18 @@
+/*
+ * Migration support for lm32 cpus
+ *
+ * Copyright (C) 2011 Red Hat, Inc.
+ *
+ * Author(s):
+ *  Juan Quintela quint...@redhat.com
+ *
+ * Based on qemu-file support done by:
+ *  Michael Walle mich...@walle.cc
+ *
+ * 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 hw/hw.h

 const VMStateDescription vmstate_cpu = {
-- 
1.7.7.1




Re: [Qemu-devel] oprofile on qemu

2011-11-23 Thread Xin Tong
I oprofiled QEMU with some workloads, i.e. SPECjbb on Ubuntu Linux, i
see QEMU spent about 60 - 70% of the time in the code cache ( code
cache size is 256MB ). but I want to know which TB takes the most
amount of time.

Thanks

Xin


On Wed, Nov 23, 2011 at 3:10 AM, 陳韋任 che...@iis.sinica.edu.tw wrote:
 On Tue, Nov 22, 2011 at 08:23:32AM -0500, Xin Tong wrote:
 Is there a way to profile QEMU's code cache ?

  What do you try to profile? The execution time in the code
 cache?

 P.S. The subject is a little misleading. Oprofile is a tool.
 Do you specify you want use Oprofile only?

 Regards,
 chenwj

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




[Qemu-devel] [PATCH 8/8] vmstate: Add copyright info for sparc processor

2011-11-23 Thread Juan Quintela
v2: Move license to BSD-like as in vl.c

Signed-off-by: Juan Quintela quint...@redhat.com
---
 target-sparc/vmstate-cpu.c |   29 +
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/target-sparc/vmstate-cpu.c b/target-sparc/vmstate-cpu.c
index 259db19..c74ea9a 100644
--- a/target-sparc/vmstate-cpu.c
+++ b/target-sparc/vmstate-cpu.c
@@ -1,3 +1,32 @@
+/*
+ * Migration support for sparc cpu
+ *
+ * Copyright (c) 2003-2008 Fabrice Bellard
+ * Copyright (c) 2003-2011 Blue Swirl blauwir...@gmail.com
+ * Copyright (c) 2011 Red Hat, Inc.
+ *
+ * Author(s):
+ *  Juan Quintela quint...@redhat.com
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
 #include hw/hw.h

 static const VMStateDescription vmstate_cpu_timer = {
-- 
1.7.7.1




  1   2   >