Re: [Qemu-devel] Adding SMP support for Sparc Target

[Mark Cave-Ayland]

On 06/11/14 18:23, Artyom Tarasenko wrote:

>> Could you please explain it with some more details? I don't really know how
>> to do that (yet)...
>> We are really interested in such a support for Sparc64, so I think that it
>> would be for sun4u machines only.
>> Would the changes would be the same or would there be more work?
> 
> Taking into account the overall status of sun4u emulation, it is a bit
> more work.
> AFAIR the SMP-related registers of Ultrasparc CPUs/chipsets are not 
> implemented.
> Additionally there are currently no sun4u SMP boards emulated in QEMU,
> but I think this is a smaller issue.
> 
> Also some support in OpenBIOS might be necessary. Mark can surely tell more.

Hi Damien,

Great to see some interest in sun4u SMP support! I think Artyom's
summary above is about right - as a starting point you'll want to change
the sun4u init function to allow multiple CPUs and pass the details to
OpenBIOS so that more than one CPU node is added to the device tree.

With that in place I would expect multiple CPUs to be visible to the
guest, and so then it's a matter of implementing additional registers
required for CPU operation. As Artyom points out, there are still copies
of the old Sun documentation you can find lying around and I've also had
good support from the NetBSD/OpenBSD projects when trying to debug
low-level kernel issues during boot.

Feel free to CC me on any patches and I look forward to seeing the
results of your work :)


ATB,

Mark.

Re: [Qemu-devel] QEMU trunk now in hardfreeze

[Mark Cave-Ayland]

On 05/11/14 15:32, Peter Maydell wrote:

> Hi; I've just tagged v2.2.0-rc0 in master, so we're now officially
> in hardfreeze, and only accepting bug fixes from here onward.
> Mike Roth should have the rc0 tarballs out sometime later today.
> 
> I've updated http://wiki.qemu.org/Planning/2.2 to list -rc dates;
> as usual, one a week, with the hope that -rc3 will be the final one
> with no changes between that and the release proper.
> 
> Please make sure you update the changelog at
> http://wiki.qemu.org/ChangeLog/2.2 with any interesting/important
> new features that got added in this release.

I don't have a wiki account, but I think it's worth mentioning that
qemu-system-sparc64 will now happily boot NetBSD and OpenBSD in
-nographic mode in addition to Linux.


ATB,

Mark.

Re: [Qemu-devel] [PATCH] esp-pci: fixup deadlock with linux

[Mark Cave-Ayland]

On 07/11/14 12:22, Hannes Reinecke wrote:

> A linux guest will be issuing messages:
> 
> [   32.124042] DC390: Deadlock in DataIn_0: DMA aborted unfinished: 00 
> bytes remain!!
> [   32.126348] DC390: DataIn_0: DMA State: 0
> 
> and the HBA will fail to work properly.
> Reason is the emulation is not setting the 'DMA transfer done'
> status correctly.
> 
> Signed-off-by: Hannes Reinecke 
> ---
>  hw/scsi/esp-pci.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/hw/scsi/esp-pci.c b/hw/scsi/esp-pci.c
> index 82795e6..77b8647 100644
> --- a/hw/scsi/esp-pci.c
> +++ b/hw/scsi/esp-pci.c
> @@ -268,6 +268,8 @@ static void esp_pci_dma_memory_rw(PCIESPState *pci, 
> uint8_t *buf, int len,
>  /* update status registers */
>  pci->dma_regs[DMA_WBC] -= len;
>  pci->dma_regs[DMA_WAC] += len;
> +if (pci->dma_regs[DMA_WBC] == 0)
> +pci->dma_regs[DMA_STAT] |= DMA_STAT_DONE;
>  }

Missing braces on the if statement here?

>  static void esp_pci_dma_memory_read(void *opaque, uint8_t *buf, int len)



ATB,

Mark.

Re: [Qemu-devel] [Consult] microblaze: About running upstream main branch qemu

[Chen Gang]

At present, I use simplified sshd, ssh and scp (dropbear open source
program) to communicate with microblaze qemu successfully, and let gcc
'make check' have real effect. It is just testing (may run a week!!).

So we can say, the related environments construction based on qemu is
finished. This thread can be ended (but the related thread for gcc is
not ended, for it also needs the testing result).

The recent operations is below, it is generated by the latest upstream
microblaze toolchain (need build toolchain firstly, also at last, will
use microblaze qemu and dropbear to test this toolchain):

 - zlib (for dropbear):

   export CHOST=microblaze-gchen-linux
   export PATH=/upstream/release/bin:$PATH
   ./configure --prefix=/upstream/release && make && make install

 - dropbear (it is a simple sshd, ssh and scp):

   export PATH=/upstream/release/bin:$PATH
   ./configure --prefix=/upstream/release \
 --host=microblaze-gchen-linux \
 CC=microblaze-gchen-linux-gcc

   modify /ustream/release/include/stdio.h to avoid redefining sscanf to
   iso99_sscanf

   link libz.a (static lib) to 'dropbear' (sshd) and 'dbclient' (ssh).
   and "make scp" to generate 'scp' command.

   for supporting 'none' username:

 under ramfs, "echo 'none:x:0:0:none:/:/bin/sh' > ./etc/passwd"

   for supporting no passwords (it is temporary fix):

 modify  common-session.c: "ses.authstate.pw_passwd[0] = '\0';"

   put 'dropbear', 'dbclient' and 'scp' to "./sbin" of ramfs and symbol
   links to "./usr/bin" of ramfs.

   for temporary fix its stable issue, need modify code to let it 'fork'
   as soon as startup, and only permit one child connection each time.

   usage:

 in microblaze qemu:

   "/sbin/dropbear -F -E -B -p 192.168.122.2:22"

 in host (x86_64), use system scp and ssh is OK (without password):

   ssh none@192.168.122.2 "cd /test; ./test"
   scp test.c none@192.168.122.2:/test/
   scp none@192.168.122.2:/test/* ./

 - For dejagnu:

   need `echo "192.168.122.2   microblaze-xilinx-gdb" >> /etc/hosts`
   under /usr/local/share/dejagnu/*, use ssh/scp instead of rsh/rcp.
 (need replace all, or will cause failure during make check).
   for "/usr/local/share/dejagnu/baseboards/microblaze-xilinx-gdb.exp",
   need add additional variables:

 set_board_info sockethost "192.168.122.2"
 set_board_info username none
 set timeout 600



Welcome any ideas, suggestions or completions.

Thanks.

On 11/01/2014 01:09 AM, Chen Gang wrote:
> 
> At present, I use telnet (without password), login to microblaze qemu
> successfully! :-)
> 
>  - I compile busy box with the glibc in orginal 'ramfs', so get telnetd:
>use new busybox replace the old one, and add symbol link 'telnetd' to
>busybox in "/bin".
> 
>  - configure qemu with network support (device "xlnx.xps-ethernetlite").
> 
>yum install libvirt
>yum install tunctl
>tunctl -b
>ip link set tap0 up
>brctl addif virbr0 tap0
>./microblaze-softmmu/qemu-system-microblaze -M petalogix-s3adsp1800 \
>  -kernel ../linux-stable.microblaze/arch/microblaze/boot/linux.bin \
>  -no-reboot -append "console=ttyUL0,115200 doreboot" -nographic \
>  -net nic,vlan=0,model=xlnx.xps-ethernetlite,macaddr=00:16:35:AF:94:00 \
>  -net tap,vlan=0,ifname=tap0,script=no,downscript=no
> 
>  - fix a kernel bug: add "xlnx,xps-ethernetlite-2.00.b" for compatible
>with its firmware (can find it under "/sys/firmware/compatible",
>within microblaze qemu bash environments). Related diff:
> 
>diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c 
> b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
>index 28dbbdc..298fad3 100644
>--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
>+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
>@@ -1236,6 +1236,7 @@ static struct of_device_id xemaclite_of_match[] = {
>{ .compatible = "xlnx,opb-ethernetlite-1.01.b", },
>{ .compatible = "xlnx,xps-ethernetlite-1.00.a", },
>{ .compatible = "xlnx,xps-ethernetlite-2.00.a", },
>+   { .compatible = "xlnx,xps-ethernetlite-2.00.b", },
>{ .compatible = "xlnx,xps-ethernetlite-2.01.a", },
>{ .compatible = "xlnx,xps-ethernetlite-3.00.a", },
>{ /* end of list */ },
> 
> Next, I shall send related kernel patch for upstream kernel, and continue
> for microbaze DejaGNU with microbaze qemu, and sorry again, I did not
> finish it within this month.
> 
> 
> Thanks.
> 
> 
> 
> On 10/30/14 22:20, Chen Gang wrote:
>> On 10/27/14 22:47, Chen Gang wrote:
>>>
>>> After a little try, I succeed run microblaze under upstream qemu 2.1.2
>>> and upstream Linux kernel 3.17-rc7, with the xilinux own ramdisk:
>>> "microblaze_complete.cpio.gz". :-)
>>>
>>> Compiler is "gcc version 4.9.1 20140717 (Red Hat Cross 4.9.1-1) (GCC)"
>>> for microblaze, and "gcc version 4.8.3 20140624 (Red Hat 4.8.3-1) (GCC)"
>>> for x86_64 qemu.
>>>
>>> Next I shall try to use virt

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

[Peter Tonoli]

Thanks Todd - the recommended fix did work. Thanks Rob, I downloaded and
used your qemu-img binary, and it worked perfectly :-)

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

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

Status in QEMU:
  New

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

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

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

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

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

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

  Host OS: Ubuntu 14.04.1 LTS 64bit

  Guest:
  Ubuntu 14.04 64bit
  Storage Size: 500gb

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

[Qemu-devel] [PATCH 0/2] virtio-scsi-dataplane: one fix and one optimization

[Ming Lei]

The 1st patch fixes an allocation problem.

The 2nd one supresses writing eventfd a lot(~30K/sec in my test).

Thanks,
Ming Lei

[Qemu-devel] [PATCH 1/2] virtio-scsi-dataplane: fix allocation for 'cmd_vrings'

[Ming Lei]

The size of each element should be sizeof(VirtIOSCSIVring *).

Signed-off-by: Ming Lei 
---
 hw/scsi/virtio-scsi-dataplane.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/scsi/virtio-scsi-dataplane.c b/hw/scsi/virtio-scsi-dataplane.c
index 855439e..8a7cd9f 100644
--- a/hw/scsi/virtio-scsi-dataplane.c
+++ b/hw/scsi/virtio-scsi-dataplane.c
@@ -239,7 +239,7 @@ void virtio_scsi_dataplane_start(VirtIOSCSI *s)
 if (!s->event_vring) {
 goto fail_vrings;
 }
-s->cmd_vrings = g_malloc0(sizeof(VirtIOSCSIVring) * vs->conf.num_queues);
+s->cmd_vrings = g_malloc0(sizeof(VirtIOSCSIVring *) * vs->conf.num_queues);
 for (i = 0; i < vs->conf.num_queues; i++) {
 s->cmd_vrings[i] =
 virtio_scsi_vring_init(s, vs->cmd_vqs[i],
-- 
1.7.9.5

[Qemu-devel] [PATCH 2/2] virtio-scsi-dataplane: notify guest as batch

[Ming Lei]

It isn't necessery to notify guest each time when one request
is completed, and it should be enough to just notify one time
for each running of virtio_scsi_iothread_handle_cmd().

This patch supresses about 30K/sec write on eventfd.

Signed-off-by: Ming Lei 
---
 hw/scsi/virtio-scsi-dataplane.c |4 +++-
 hw/scsi/virtio-scsi.c   |   22 ++
 include/hw/virtio/virtio-scsi.h |4 
 3 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/hw/scsi/virtio-scsi-dataplane.c b/hw/scsi/virtio-scsi-dataplane.c
index 8a7cd9f..1fb83de 100644
--- a/hw/scsi/virtio-scsi-dataplane.c
+++ b/hw/scsi/virtio-scsi-dataplane.c
@@ -62,6 +62,7 @@ static VirtIOSCSIVring *virtio_scsi_vring_init(VirtIOSCSI *s,
 aio_set_event_notifier(s->ctx, &r->host_notifier, handler);
 
 r->parent = s;
+r->qid = n;
 
 if (!vring_setup(&r->vring, VIRTIO_DEVICE(s), n)) {
 fprintf(stderr, "virtio-scsi: VRing setup failed\n");
@@ -95,7 +96,8 @@ void virtio_scsi_vring_push_notify(VirtIOSCSIReq *req)
 {
 vring_push(&req->vring->vring, &req->elem,
req->qsgl.size + req->resp_iov.size);
-event_notifier_set(&req->vring->guest_notifier);
+req->dev->pending_guest_notify |= 1 << (req->vring->qid - 2);
+qemu_bh_schedule(req->dev->guest_notify_bh);
 }
 
 static void virtio_scsi_iothread_handle_ctrl(EventNotifier *notifier)
diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
index 6e34a2c..1b9c35c 100644
--- a/hw/scsi/virtio-scsi.c
+++ b/hw/scsi/virtio-scsi.c
@@ -86,6 +86,21 @@ static void virtio_scsi_complete_req(VirtIOSCSIReq *req)
 virtio_scsi_free_req(req);
 }
 
+static void notify_guest_bh(void *opaque)
+{
+VirtIOSCSI *s = opaque;
+unsigned int qid;
+uint64_t pending = s->pending_guest_notify;
+
+s->pending_guest_notify = 0;
+
+while ((qid = ffsl(pending))) {
+qid--;
+event_notifier_set(&s->cmd_vrings[qid]->guest_notifier);
+pending &= ~(1 << qid);
+}
+}
+
 static void virtio_scsi_bad_req(void)
 {
 error_report("wrong size for virtio-scsi headers");
@@ -825,6 +840,10 @@ void virtio_scsi_common_realize(DeviceState *dev, Error 
**errp,
 
 if (s->conf.iothread) {
 virtio_scsi_set_iothread(VIRTIO_SCSI(s), s->conf.iothread);
+VIRTIO_SCSI(s)->pending_guest_notify = 0;
+VIRTIO_SCSI(s)->guest_notify_bh = aio_bh_new(VIRTIO_SCSI(s)->ctx,
+ notify_guest_bh,
+ VIRTIO_SCSI(s));
 }
 }
 
@@ -902,6 +921,9 @@ void virtio_scsi_common_unrealize(DeviceState *dev, Error 
**errp)
 VirtIODevice *vdev = VIRTIO_DEVICE(dev);
 VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(dev);
 
+if (vs->conf.iothread) {
+qemu_bh_delete(VIRTIO_SCSI(vs)->guest_notify_bh);
+}
 g_free(vs->cmd_vqs);
 virtio_cleanup(vdev);
 }
diff --git a/include/hw/virtio/virtio-scsi.h b/include/hw/virtio/virtio-scsi.h
index 9e1a49c..5e6c57e 100644
--- a/include/hw/virtio/virtio-scsi.h
+++ b/include/hw/virtio/virtio-scsi.h
@@ -163,6 +163,7 @@ typedef struct {
 Vring vring;
 EventNotifier host_notifier;
 EventNotifier guest_notifier;
+uint32_t qid;
 } VirtIOSCSIVring;
 
 typedef struct VirtIOSCSICommon {
@@ -198,6 +199,9 @@ typedef struct VirtIOSCSI {
 bool dataplane_fenced;
 Error *blocker;
 Notifier migration_state_notifier;
+
+QEMUBH *guest_notify_bh;
+uint64_t pending_guest_notify;
 } VirtIOSCSI;
 
 typedef struct VirtIOSCSIReq {
-- 
1.7.9.5

Re: [Qemu-devel] QEMU trunk now in hardfreeze

[Peter Maydell]

On 9 November 2014 09:43, Mark Cave-Ayland
 wrote:
> On 05/11/14 15:32, Peter Maydell wrote:
>> Please make sure you update the changelog at
>> http://wiki.qemu.org/ChangeLog/2.2 with any interesting/important
>> new features that got added in this release.
>
> I don't have a wiki account, but I think it's worth mentioning that
> qemu-system-sparc64 will now happily boot NetBSD and OpenBSD in
> -nographic mode in addition to Linux.

I've created you a wiki account so you can add it yourself now :-)

-- PMM

Re: [Qemu-devel] QEMU trunk now in hardfreeze

[Mark Cave-Ayland]

On 09/11/14 16:42, Peter Maydell wrote:

> On 9 November 2014 09:43, Mark Cave-Ayland
>  wrote:
>> On 05/11/14 15:32, Peter Maydell wrote:
>>> Please make sure you update the changelog at
>>> http://wiki.qemu.org/ChangeLog/2.2 with any interesting/important
>>> new features that got added in this release.
>>
>> I don't have a wiki account, but I think it's worth mentioning that
>> qemu-system-sparc64 will now happily boot NetBSD and OpenBSD in
>> -nographic mode in addition to Linux.
> 
> I've created you a wiki account so you can add it yourself now :-)

Great - thanks!


ATB,

Mark.

[Qemu-devel] Is there a way for passing parameter directly to a module

[Lior Nahmanson]

Hi,

Is there a way for passing a parameter directly to a module (i.e. device driver 
within QEMU), for example file path (when I am working at Full system 
emulation)?
My goal is to have a device emulation which will be able to read a 
configuration file that its name is provided in runtime.

Thanks,
Lior Nahmanson

Re: [Qemu-devel] Add CMP2 instruction

[Guo, Lei]

Hi Laurent
This pagraph exactly is a cut&paste of the Motorola "Programmer's 
reference manual".
I didn't mean to add it as commits to the patch.I just want to introduce this 
instruction to the reviewer. 
So don't worry about the copyrights.

Best Regards
Guo Lei

> 
> 
> 
> > Le 7 novembre 2014 à 11:14, "Guo, Lei"  a écrit :
> >
> >
> >  This patch aims to add CMP2 instruction for m68k family.
> >
> >
> >
> >  Description: Compares the value in Rn to each bound. The effective 
> > address contains the
> >
> >  bounds pair: upper bound following the lower bound. For signed 
> > comparisons, the
> >
> >  arithmetically smaller value should be used as the lower bound. For 
> > unsigned
> >
> >  comparisons, the logically smaller value should be the lower bound.
> >
> >  The size of the data and the bounds can be specified as byte, word, or 
> > long.
> > If Rn is a
> >
> >  data register and the operation size is byte or word, only the 
> > appropriate low-order part
> >
> >  of Rn is checked. If Rn is an address register and the operation 
> > size is byte or word,
> >
> >  the bounds operands are sign-extended to 32 bits, and the resultant 
> > operands are
> >
> >  compared to the full 32 bits of An.
> >
> >  If the upper bound equals the lower bound, the valid range is a single 
> > value.
> >
> 
> Moreover, this seems a cut&paste of the Motorola "Programmer's 
> reference manual".
> It should be copyrighted : have we the right to copy this part in a 
> commit message ?
> 
> Regards,
> Laurent

[Qemu-devel] (no subject)

[xubin yan]

hello

[Qemu-devel] when to bdrv_co_flush()?

[lihuiba]

Hi, all


bdrv_co_flush() will flush all cached data to persistent storage, and I'm
wondering whether guest sync() will eventually trigger bdrv_co_flush() be
called. 

Intuitively, guest sync() should trigger bdrv_co_flush() in qemu. But simple

grep gave me a negative answer. So I'm wondering why it's not like what I

suspected.




Thanks!

[Qemu-devel] 答复: Add CMP2 instruction

[Guo, Lei]

Hi Andreas
Thanks a lot for your patients. Because I'm a newer to this , I'll 
follow your advices and pay much more attention to these details.
Besides ,I have replied to Thomas' question on my previous submission.
Thanks again for your help.

Best regards 
Guo lei

 Re: [Qemu-devel] Add CMP2 instruction
> 
> Hi,
> 
> Am 07.11.2014 um 11:14 schrieb Guo, Lei:
> > This patch aims to add CMP2 instruction for m68k family.
> >
> >
> >
> > *Description: *Compares the value in Rn to each bound. The effective
> > address contains the
> >
> > bounds pair: upper bound following the lower bound. For signed
> > comparisons, the
> >
> > arithmetically smaller value should be used as the lower bound. For
> > unsigned
> >
> > comparisons, the logically smaller value should be the lower bound.
> >
> > The size of the data and the bounds can be specified as byte, word, or
> > long. If Rn is a
> >
> > data register and the operation size is byte or word, only the
> > appropriate low-order part
> >
> > of Rn is checked. If Rn is an address register and the operation size
> > is byte or word,
> >
> > the bounds operands are sign-extended to 32 bits, and the resultant
> > operands are
> >
> > compared to the full 32 bits of An.
> >
> > If the upper bound equals the lower bound, the valid range is a single
> > value.
> >
> >
> >
> > signed-off-by: Guolei  > >
> >
> >
> >
> > ---
> 
> Please talk to your Fujitsu colleagues for how to correctly submit patches to 
> our
> mailing list. As you can see above, it arrives rather "funny" due to your use 
> of
> HTML. As a sanity check, you can mail the patch to yourself, save it from your
> inbox to disk and try to apply it via "git am yourmailfilename".
> 
> Why do you write "Description:" in the patch description? Is that a verbatim
> copy from the manual? In that case you should name the source.
> Otherwise please drop "Description:" and just describe it.
> 
> Also, Signed-off-by with a capital S please, and no space after your email. 
> If you
> use git commit -s you can avoid such issues from the start.
> 
> Please also use a meaningful topic in the subject, "target-m68k: Add
> CMP2 instruction" tells us that this is not for x86 or ARM etc.
> 
> More information here:
> http://wiki.qemu-project.org/Contribute/SubmitAPatch
> 
> As for the contents, you should be aware that QEMU currently emulates
> ColdFire only and not the full 68k instruction set. So you may need to limit 
> your
> new instruction to certain CPU types. CC'ing Laurent+Andreas.
> 
> You haven't replied to Thomas' question on your previous submission either. If
> you resubmit, please either mark as [PATCH RESEND], or if things changed
> (such as adding the s ;)) as [PATCH v2] and include a summary of changes below
> ---.
> 
> Note that there is currently no dedicated maintainer to review m68k patches,
> so only obviously correct bug fixes are likely to get accepted unless someone
> (you?) steps up for reviewing, testing and queuing such patches on a Git
> branch.
> 
> Finally a minor nit: Please add a space between ) and {.
> scripts/checkpatch.pl may help you find such style issues.
> http://blog.vmsplice.net/2011/03/how-to-automatically-run-checkpatchpl.html
> 
> Looking forward to seeing the m68k target improved.
> 
> Regards,
> Andreas
> 
> --
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 21284 AG Nürnberg

Re: [Qemu-devel] [PATCH] pc: piix4_pm: init legacy PCI hotplug when running on Xen

[Zhang, Yang Z]

Igor Mammedov wrote on 2014-05-23:
> if user starts QEMU with "-machine pc,accel=xen", then compat property
> in xenfv won't work and it would cause error:
> "Unsupported bus. Bus doesn't have property 'acpi-pcihp-bsel' set"
> when PCI device is added with -device on QEMU CLI.
> 
> In case of Xen instead of using compat property, just use the fact
> that xen doesn't use QEMU's fw_cfg/acpi tables to switch piix4_pm into
> legacy PCI hotplug mode when Xen is enabled.

I am wondering why Xen cannot use new mechanism to do the hotplug.

> 
> Signed-off-by: Igor Mammedov 
> ---
>  hw/acpi/piix4.c   |  3 +++
>  hw/i386/pc_piix.c | 11 ---
>  2 files changed, 3 insertions(+), 11 deletions(-)
> diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c index 227ea30..12542c3
> 100644 --- a/hw/acpi/piix4.c +++ b/hw/acpi/piix4.c @@ -501,6 +501,9 @@
> I2CBus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
>  s->irq = sci_irq;
>  s->smi_irq = smi_irq;
>  s->kvm_enabled = kvm_enabled;
> +if (!fw_cfg) {
> +s->use_acpi_pci_hotplug = false;
> +}
> 
>  qdev_init_nofail(dev);
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index
> a13e8d6..067ff0c 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c
> @@ -840,17 +840,6 @@ static QEMUMachine xenfv_machine = {
>  .max_cpus = HVM_MAX_VCPUS,
>  .default_machine_opts = "accel=xen",
>  .hot_add_cpu = pc_hot_add_cpu,
> -.compat_props = (GlobalProperty[]) {
> -/* xenfv has no fwcfg and so does not load acpi from QEMU.
> - * as such new acpi features don't work.
> - */
> -{
> -.driver   = "PIIX4_PM",
> -.property = "acpi-pci-hotplug-with-bridge-support",
> -.value= "off",
> -},
> -{ /* end of list */ }
> -},
>  };
>  #endif


Best regards,
Yang

[Qemu-devel] when to bdrv_co_flush()?

[lihuiba]

Hi, all


bdrv_co_flush() will flush all cached data to persistent storage, and I'm
wondering whether guest sync() will eventually trigger bdrv_co_flush() be
called. 

Intuitively, guest sync() should trigger bdrv_co_flush() in qemu. But simple

grep gave me a negative answer. So I'm wondering why it's not like what I

suspected.




Thanks!

[Qemu-devel] when to bdrv_co_flush()?

[lihuiba]

Hi, all


bdrv_co_flush() will flush all cached data to persistent storage, and I'm
wondering whether guest sync() will eventually trigger bdrv_co_flush() be
called. 

Intuitively, guest sync() should trigger bdrv_co_flush() in qemu. But simple

grep gave me a negative answer. So I'm wondering why it's not like what I

suspected.




Thanks!

[Qemu-devel] [PATCH v3] error: passing a negative value to an os_errno is wrong

[SeokYeon Hwang]

Added 'assert(os_errno > 0)' in 'error_set_errno()'.
Fixed errno since it passes wrong value to 'error_set_errno()'.

Signed-off-by: SeokYeon Hwang 
---
 hw/pci/pcie.c | 2 +-
 util/error.c  | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index 58455bd..2902f7d 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -229,7 +229,7 @@ static void pcie_cap_slot_hotplug_common(PCIDevice 
*hotplug_dev,
 /* the slot is electromechanically locked.
  * This error is propagated up to qdev and then to HMP/QMP.
  */
-error_setg_errno(errp, -EBUSY, "slot is electromechanically locked");
+error_setg_errno(errp, EBUSY, "slot is electromechanically locked");
 }
 }
 
diff --git a/util/error.c b/util/error.c
index 2ace0d8..6c9d995 100644
--- a/util/error.c
+++ b/util/error.c
@@ -62,6 +62,7 @@ void error_set_errno(Error **errp, int os_errno, ErrorClass 
err_class,
 return;
 }
 assert(*errp == NULL);
+assert(os_errno >= 0);
 
 err = g_malloc0(sizeof(*err));
 
-- 
2.1.0

Re: [Qemu-devel] [PATCH v2] error: passing a negative value to an os_errno is wrong

[SeokYeon Hwang]

> -Original Message-
> From: Markus Armbruster [mailto:arm...@redhat.com]
> Sent: Friday, November 07, 2014 4:41 PM
> To: Amos Kong
> Cc: SeokYeon Hwang; mre...@redhat.com; paolo.bonz...@gmail.com; qemu-
> de...@nongnu.org
> Subject: Re: [Qemu-devel] [PATCH v2] error: passing a negative value to an
> os_errno is wrong
> 
> Amos Kong  writes:
> 
> > On Fri, Nov 07, 2014 at 11:24:55AM +0900, SeokYeon Hwang wrote:
> >> Added 'assert(os_errno > 0)' in 'error_set_errno()'.
> >> Fixed errno since it passes wrong value to 'error_set_errno()'.
> >>
> >> Signed-off-by: SeokYeon Hwang 
> >> ---
> >>  hw/pci/pcie.c | 2 +-
> >>  util/error.c  | 1 +
> >>  2 files changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c index 58455bd..2902f7d
> >> 100644
> >> --- a/hw/pci/pcie.c
> >> +++ b/hw/pci/pcie.c
> >> @@ -229,7 +229,7 @@ static void pcie_cap_slot_hotplug_common(PCIDevice
> *hotplug_dev,
> >>  /* the slot is electromechanically locked.
> >>   * This error is propagated up to qdev and then to HMP/QMP.
> >>   */
> >> -error_setg_errno(errp, -EBUSY, "slot is electromechanically
> locked");
> >> +error_setg_errno(errp, EBUSY, "slot is electromechanically
> >> + locked");
> >>  }
> >>  }
> >>
> >> diff --git a/util/error.c b/util/error.c index 2ace0d8..4ce22cc
> >> 100644
> >> --- a/util/error.c
> >> +++ b/util/error.c
> >> @@ -62,6 +62,7 @@ void error_set_errno(Error **errp, int os_errno,
> ErrorClass err_class,
> >>  return;
> >>  }
> >>  assert(*errp == NULL);
> >> +assert(os_errno > 0);
> >
> > strerror(0) will return string 'Success', do we need to reserve zero
> here?
> >
> >   assert(os_errno >= 0);
> 
> Yes, because...
> 
> >>  err = g_malloc0(sizeof(*err));
> >>
> va_start(ap, fmt);
> msg1 = g_strdup_vprintf(fmt, ap);
> --->if (os_errno != 0) {
> err->msg = g_strdup_printf("%s: %s", msg1,
strerror(os_errno));
> g_free(msg1);
> } else {
> err->msg = msg1;
> }
> 
> Please fix.

You're right. I posted patch v3.
Thank you for your advice.

Re: [Qemu-devel] [Bug 1385934] Re: USB with passthrougth guest cannot enumerate USB host

[Gonglei]

On 2014/11/9 2:47, MikeFrysinger wrote:

> the problem is this commit:
> http://git.qemu.org/?p=qemu.git;a=commit;h=b791c3b38c7969cb9f4acda8229e19fd865a1c08
> 
> it's easy to reproduce -- plug in a USB flash drive and try to pass it
> through
> 

What's your USB flash drive's version? USB1.1 or USB2.0 or 3.0?
Please post the value:

1.cat /sys/bus/usb/device/xx-xx/speed[xx-xx: hostbus-hostport]
2.And your exact command line launched Qemu .

Best regards,
-Gonglei

> on the host:
> $ lsusb
> Bus 003 Device 004: ID 1307:0163 Transcend Information, Inc. 256MB/512MB/1GB 
> Flash Drive
> 
> so launch qemu with that:
>   -usbdevice host:1307:0163
> 
> and then in the VM, if it fails, you get those errors in dmesg, and the
> device doesn't show up in `lsusb`.  if it passes, `lsusb` reports it
> fine.
> 

Re: [Qemu-devel] [PATCH v3] error: passing a negative value to an os_errno is wrong

[Amos Kong]

On Mon, Nov 10, 2014 at 02:54:49PM +0900, SeokYeon Hwang wrote:
> Added 'assert(os_errno > 0)' in 'error_set_errno()'.
> Fixed errno since it passes wrong value to 'error_set_errno()'.
> 
> Signed-off-by: SeokYeon Hwang 

Reviewed-by: Amos Kong 

> ---
>  hw/pci/pcie.c | 2 +-
>  util/error.c  | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
> index 58455bd..2902f7d 100644
> --- a/hw/pci/pcie.c
> +++ b/hw/pci/pcie.c
> @@ -229,7 +229,7 @@ static void pcie_cap_slot_hotplug_common(PCIDevice 
> *hotplug_dev,
>  /* the slot is electromechanically locked.
>   * This error is propagated up to qdev and then to HMP/QMP.
>   */
> -error_setg_errno(errp, -EBUSY, "slot is electromechanically locked");
> +error_setg_errno(errp, EBUSY, "slot is electromechanically locked");
>  }
>  }
>  
> diff --git a/util/error.c b/util/error.c
> index 2ace0d8..6c9d995 100644
> --- a/util/error.c
> +++ b/util/error.c
> @@ -62,6 +62,7 @@ void error_set_errno(Error **errp, int os_errno, ErrorClass 
> err_class,
>  return;
>  }
>  assert(*errp == NULL);
> +assert(os_errno >= 0);
>  
>  err = g_malloc0(sizeof(*err));
>  
> -- 
> 2.1.0
> 

-- 
Amos.


signature.asc
Description: Digital signature

[Qemu-devel] [PATCH] Add VT-d Posted-Interrupts support in QEMU

[Feng Wu]

VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.

This patch is used together with the patches in KVM side.

You can find the VT-d Posted-Interrtups Spec. in the following URL:
http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/vt-directed-io-spec.html

Feng Wu (1):
  x86: Update VT-d Posted-Interrupts related information

 hw/i386/kvm/pci-assign.c  |   24 
 linux-headers/linux/kvm.h |2 ++
 target-i386/kvm.c |5 +
 target-i386/kvm_i386.h|1 +
 4 files changed, 32 insertions(+), 0 deletions(-)

[Qemu-devel] [PATCH] x86: Update VT-d Posted-Interrupts related information

[Feng Wu]

VT-d Posted-Interrupts(PI) is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
involvement when guest is running in non-root mode.

If VT-d PI is supported by KVM, we need to update the IRTE with
the new guest interrtup configuration.

Signed-off-by: Feng Wu 
---
 hw/i386/kvm/pci-assign.c  |   24 
 linux-headers/linux/kvm.h |2 ++
 target-i386/kvm.c |5 +
 target-i386/kvm_i386.h|1 +
 4 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/hw/i386/kvm/pci-assign.c b/hw/i386/kvm/pci-assign.c
index bb206da..e55a99b 100644
--- a/hw/i386/kvm/pci-assign.c
+++ b/hw/i386/kvm/pci-assign.c
@@ -1005,6 +1005,12 @@ static void assigned_dev_update_msi(PCIDevice *pci_dev)
 assigned_dev->intx_route.mode = PCI_INTX_DISABLED;
 assigned_dev->intx_route.irq = -1;
 assigned_dev->assigned_irq_type = ASSIGNED_IRQ_MSI;
+
+if (kvm_check_extension(kvm_state, KVM_CAP_PI)) {
+if (kvm_device_pi_update(kvm_state, assigned_dev->dev_id) < 0) {
+perror("assigned_dev_update_msi: kvm_device_pi_update");
+}
+}
 } else {
 Error *local_err = NULL;
 
@@ -1029,6 +1035,12 @@ static void assigned_dev_update_msi_msg(PCIDevice 
*pci_dev)
 
 kvm_irqchip_update_msi_route(kvm_state, assigned_dev->msi_virq[0],
  msi_get_message(pci_dev, 0));
+
+if (kvm_check_extension(kvm_state, KVM_CAP_PI)) {
+if (kvm_device_pi_update(kvm_state, assigned_dev->dev_id) < 0) {
+perror("assigned_dev_update_msi_msg: kvm_device_pi_update");
+}
+}
 }
 
 static bool assigned_dev_msix_masked(MSIXTableEntry *entry)
@@ -1149,6 +1161,12 @@ static void assigned_dev_update_msix(PCIDevice *pci_dev)
 perror("assigned_dev_enable_msix: assign irq");
 return;
 }
+
+if (kvm_check_extension(kvm_state, KVM_CAP_PI)) {
+if (kvm_device_pi_update(kvm_state, assigned_dev->dev_id) < 0) 
{
+perror("assigned_dev_update_msix: kvm_device_pi_update");
+}
+}
 }
 assigned_dev->intx_route.mode = PCI_INTX_DISABLED;
 assigned_dev->intx_route.irq = -1;
@@ -1618,6 +1636,12 @@ static void assigned_dev_msix_mmio_write(void *opaque, 
hwaddr addr,
 if (ret) {
 error_report("Error updating irq routing entry (%d)", ret);
 }
+if (kvm_check_extension(kvm_state, KVM_CAP_PI)) {
+if (kvm_device_pi_update(kvm_state, adev->dev_id) < 0) {
+perror("assigned_dev_update_msi_msg: "
+"kvm_device_pi_update");
+}
+}
 }
 }
 }
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index 2669938..b34f3c4 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -765,6 +765,7 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_PPC_FIXUP_HCALL 103
 #define KVM_CAP_PPC_ENABLE_HCALL 104
 #define KVM_CAP_CHECK_EXTENSION_VM 105
+#define KVM_CAP_PI 106
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
@@ -1020,6 +1021,7 @@ struct kvm_s390_ucas_mapping {
 #define KVM_XEN_HVM_CONFIG_IOW(KVMIO,  0x7a, struct kvm_xen_hvm_config)
 #define KVM_SET_CLOCK _IOW(KVMIO,  0x7b, struct kvm_clock_data)
 #define KVM_GET_CLOCK _IOR(KVMIO,  0x7c, struct kvm_clock_data)
+#define KVM_ASSIGN_DEV_PI_UPDATE  _IOR(KVMIO,  0x7d, __u32)
 /* Available with KVM_CAP_PIT_STATE2 */
 #define KVM_GET_PIT2  _IOR(KVMIO,  0x9f, struct kvm_pit_state2)
 #define KVM_SET_PIT2  _IOW(KVMIO,  0xa0, struct kvm_pit_state2)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index ccf36e8..3dd8e5e 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -2660,6 +2660,11 @@ int kvm_device_msi_assign(KVMState *s, uint32_t dev_id, 
int virq)
   KVM_DEV_IRQ_GUEST_MSI, virq);
 }
 
+int kvm_device_pi_update(KVMState *s, uint32_t dev_id)
+{
+return kvm_vm_ioctl(s, KVM_ASSIGN_DEV_PI_UPDATE, &dev_id);
+}
+
 int kvm_device_msi_deassign(KVMState *s, uint32_t dev_id)
 {
 return kvm_deassign_irq_internal(s, dev_id, KVM_DEV_IRQ_GUEST_MSI |
diff --git a/target-i386/kvm_i386.h b/target-i386/kvm_i386.h
index cac30fd..c119b3e 100644
--- a/target-i386/kvm_i386.h
+++ b/target-i386/kvm_i386.h
@@ -37,4 +37,5 @@ int kvm_device_msix_set_vector(KVMState *s, uint32_t dev_id, 
uint32_t vector,
 int kvm_device_msix_assign(KVMState *s, uint32_t dev_id);
 int kvm_device_msix_deassign(KVMState *s, uint32_t dev_id);
 
+int kvm_device_pi_update(KVMState *s, uint32_t dev_id);
 #endif
-- 
1.7.1

Re: [Qemu-devel] [PATCH v4 35/47] Page request: Add MIG_RPCOMM_REQPAGES reverse command

[David Gibson]

On Fri, Oct 03, 2014 at 06:47:41PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" 
> 
> Add MIG_RPCOMM_REQPAGES command on Return path for the postcopy
> destination to request a page from the source.
> 
> Signed-off-by: Dr. David Alan Gilbert 
> ---
>  include/migration/migration.h |  3 ++
>  migration.c   | 74 
> +++
>  2 files changed, 77 insertions(+)
> 
> diff --git a/include/migration/migration.h b/include/migration/migration.h
> index cdd0e56..5e0d30d 100644
> --- a/include/migration/migration.h
> +++ b/include/migration/migration.h
> @@ -45,6 +45,7 @@ enum mig_rpcomm_cmd {
>  MIG_RPCOMM_INVALID = 0,  /* Must be 0 */
>  MIG_RPCOMM_SHUT, /* sibling will not send any more RP messages */
>  MIG_RPCOMM_ACK,  /* data (seq: be32 ) */
> +MIG_RPCOMM_REQPAGES, /* data (start: be64, len: be64) */
>  MIG_RPCOMM_AFTERLASTVALID
>  };
>  
> @@ -250,6 +251,8 @@ void migrate_send_rp_shut(MigrationIncomingState *mis,
>uint32_t value);
>  void migrate_send_rp_ack(MigrationIncomingState *mis,
>   uint32_t value);
> +void migrate_send_rp_reqpages(MigrationIncomingState *mis, const char* 
> rbname,
> +  ram_addr_t start, ram_addr_t len);
>  
>  
>  void ram_control_before_iterate(QEMUFile *f, uint64_t flags);
> diff --git a/migration.c b/migration.c
> index 1731017..cfdaa52 100644
> --- a/migration.c
> +++ b/migration.c
> @@ -144,6 +144,38 @@ void migrate_send_rp_ack(MigrationIncomingState *mis,
>  migrate_send_rp_message(mis, MIG_RPCOMM_ACK, 4, (uint8_t *)&buf);
>  }
>  
> +/* Request a range of pages from the source VM at the given
> + * start address.
> + *   rbname: Name of the RAMBlock to request the page in, if NULL it's the 
> same
> + *   as the last request (a name must have been given previously)
> + *   Start: Address offset within the RB
> + *   Len: Length in bytes required - must be a multiple of pagesize
> + */
> +void migrate_send_rp_reqpages(MigrationIncomingState *mis, const char 
> *rbname,
> +  ram_addr_t start, ram_addr_t len)
> +{
> +uint8_t bufc[16+1+255]; /* start (8 byte), len (8 byte), rbname upto 256 
> */
> +uint64_t *buf64 = (uint64_t *)bufc;
> +size_t msglen = 16; /* start + len */
> +
> +assert(!(len & 1));
> +if (rbname) {
> +int rbname_len = strlen(rbname);
> +assert(rbname_len < 256);
> +
> +len |= 1; /* Flag to say we've got a name */
> +bufc[msglen++] = rbname_len;
> +memcpy(bufc + msglen, rbname, rbname_len);
> +msglen += rbname_len;
> +}
> +
> +buf64[0] = (uint64_t)start;
> +buf64[0] = cpu_to_be64(buf64[0]);

I think this would be clearer as well as less verbose, as just:
buf64[0] = cpu_to_be64(start);

> +buf64[1] = (uint64_t)len;
> +buf64[1] = cpu_to_be64(buf64[1]);
> +migrate_send_rp_message(mis, MIG_RPCOMM_REQPAGES, msglen, bufc);
> +}
> +
>  void qemu_start_incoming_migration(const char *uri, Error **errp)
>  {
>  const char *p;
> @@ -784,6 +816,17 @@ static void source_return_path_bad(MigrationState *s)
>  }
>  
>  /*
> + * Process a request for pages received on the return path,
> + * We're allowed to send more than requested (e.g. to round to our page size)
> + * and we don't need to send pages that have already been sent.
> + */
> +static void migrate_handle_rp_reqpages(MigrationState *ms, const char* 
> rbname,
> +   ram_addr_t start, ram_addr_t len)
> +{
> +DPRINTF("migrate_handle_rp_reqpages: at %zx for len %zx", start, len);
> +}
> +
> +/*
>   * Handles messages sent on the return path towards the source VM
>   *
>   */
> @@ -795,6 +838,8 @@ static void *source_return_path_thread(void *opaque)
>  const int max_len = 512;
>  uint8_t buf[max_len];
>  uint32_t tmp32;
> +uint64_t tmp64a, tmp64b;

Hrm.. calling everything "tmp*" doesn't help readability.

> +char *tmpstr;
>  int res;
>  
>  DPRINTF("RP: %s entry", __func__);
> @@ -810,6 +855,11 @@ static void *source_return_path_thread(void *opaque)
>  expected_len = 4;
>  break;
>  
> +case MIG_RPCOMM_REQPAGES:
> +/* 16 byte start/len _possibly_ plus an id str */
> +expected_len = 16 + 256;
> +break;
> +
>  default:
>  error_report("RP: Received invalid cmd 0x%04x length 0x%04x",
>  header_com, header_len);
> @@ -857,6 +907,30 @@ static void *source_return_path_thread(void *opaque)
>  atomic_xchg(&ms->rp_state.latest_ack, tmp32);
>  break;
>  
> +case MIG_RPCOMM_REQPAGES:
> +tmp64a = be64_to_cpup((uint64_t *)buf);  /* Start */
> +tmp64b = be64_to_cpup(((uint64_t *)buf)+1); /* Len */
> +tmpstr = NULL;
> +if (tmp64b & 1) {
> +  

Re: [Qemu-devel] [PATCH v4 34/47] Postcopy: Create a fault handler thread before marking the ram as userfault

[David Gibson]

On Fri, Oct 03, 2014 at 06:47:40PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" 

This could do with a bit more rationale in the commit message.

Also is there a reason not to fold this with the patch originally
marking the RAM as userfault?  IIRC that one wasn't partocularly long
either.

Otherwise

Reviewed-by: David Gibson 

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


pgp9FphIgEbmk.pgp
Description: PGP signature

Re: [Qemu-devel] [PATCH v4 33/47] Postcopy: Postcopy startup in migration thread

[David Gibson]

On Fri, Oct 03, 2014 at 06:47:39PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" 
> 
> Rework the migration thread to setup and start postcopy.
> 
> Signed-off-by: Dr. David Alan Gilbert 
> ---
>  include/migration/migration.h |   3 +
>  migration.c   | 201 
> ++
>  2 files changed, 185 insertions(+), 19 deletions(-)
> 
> diff --git a/include/migration/migration.h b/include/migration/migration.h
> index b01cc17..f401775 100644
> --- a/include/migration/migration.h
> +++ b/include/migration/migration.h
> @@ -125,6 +125,9 @@ struct MigrationState
>  /* Flag set once the migration has been asked to enter postcopy */
>  volatile bool start_postcopy;
>  
> +/* Flag set once the migration thread is running (and needs joining) */
> +volatile bool started_migration_thread;
> +
>  /* bitmap of pages that have been sent at least once
>   * only maintained and used in postcopy at the moment
>   * where it's used to send the dirtymap at the start
> diff --git a/migration.c b/migration.c
> index 63d70b6..1731017 100644
> --- a/migration.c
> +++ b/migration.c
> @@ -475,7 +475,10 @@ static void migrate_fd_cleanup(void *opaque)
>  if (s->file) {
>  trace_migrate_fd_cleanup();
>  qemu_mutex_unlock_iothread();
> -qemu_thread_join(&s->thread);
> +if (s->started_migration_thread) {
> +qemu_thread_join(&s->thread);
> +s->started_migration_thread = false;
> +}
>  qemu_mutex_lock_iothread();
>  
>  qemu_fclose(s->file);
> @@ -872,7 +875,6 @@ out:
>  return NULL;
>  }
>  
> -__attribute__ (( unused )) /* Until later in patch series */
>  static int open_outgoing_return_path(MigrationState *ms)
>  {
>  
> @@ -890,7 +892,6 @@ static int open_outgoing_return_path(MigrationState *ms)
>  return 0;
>  }
>  
> -__attribute__ (( unused )) /* Until later in patch series */
>  static void await_outgoing_return_path_close(MigrationState *ms)
>  {
>  /*
> @@ -908,6 +909,97 @@ static void 
> await_outgoing_return_path_close(MigrationState *ms)
>  DPRINTF("%s: Exit", __func__);
>  }
>  
> +/* Switch from normal iteration to postcopy
> + * Returns non-0 on error
> + */
> +static int postcopy_start(MigrationState *ms)
> +{
> +int ret;
> +const QEMUSizedBuffer *qsb;
> +migrate_set_state(ms, MIG_STATE_ACTIVE, MIG_STATE_POSTCOPY_ACTIVE);
> +
> +DPRINTF("postcopy_start\n");
> +qemu_mutex_lock_iothread();
> +DPRINTF("postcopy_start: setting run state\n");
> +ret = vm_stop_force_state(RUN_STATE_FINISH_MIGRATE);
> +
> +if (ret < 0) {
> +migrate_set_state(ms, MIG_STATE_POSTCOPY_ACTIVE, MIG_STATE_ERROR);
> +qemu_mutex_unlock_iothread();
> +return -1;
> +}
> +
> +/*
> + * in Finish migrate and with the io-lock held everything should
> + * be quiet, but we've potentially still got dirty pages and we
> + * need to tell the destination to throw any pages it's already received
> + * that are dirty
> + */
> +if (ram_postcopy_send_discard_bitmap(ms)) {
> +DPRINTF("postcopy send discard bitmap failed\n");
> +migrate_set_state(ms, MIG_STATE_POSTCOPY_ACTIVE, MIG_STATE_ERROR);
> +qemu_mutex_unlock_iothread();
> +return -1;
> +}
> +
> +DPRINTF("postcopy_start: sending req 2\n");
> +qemu_savevm_send_reqack(ms->file, 2);

Are these reqacks just for debugging, or do they affect the protocol?

> +/*
> + * send rest of state - note things that are doing postcopy
> + * will notice we're in MIG_STATE_POSTCOPY_ACTIVE and not actually
> + * wrap their state up here
> + */
> +qemu_file_set_rate_limit(ms->file, INT64_MAX);
> +DPRINTF("postcopy_start: do state_complete\n");
> +
> +/*
> + * We need to leave the fd free for page transfers during the
> + * loading of the device state, so wrap all the remaining
> + * commands and state into a package that gets sent in one go
> + */
> +QEMUFile *fb = qemu_bufopen("w", NULL);
> +if (!fb) {
> +error_report("Failed to create buffered file");
> +migrate_set_state(ms, MIG_STATE_POSTCOPY_ACTIVE, MIG_STATE_ERROR);
> +qemu_mutex_unlock_iothread();
> +return -1;
> +}
> +
> +qemu_savevm_state_complete(fb);
> +DPRINTF("postcopy_start: sending req 3\n");
> +qemu_savevm_send_reqack(fb, 3);
> +
> +qemu_savevm_send_postcopy_ram_run(fb);
> +
> +/* <><> end of stuff going into the package */
> +qsb = qemu_buf_get(fb);
> +
> +/* Now send that blob */
> +if (qsb_get_length(qsb) > MAX_VM_CMD_PACKAGED_SIZE) {
> +DPRINTF("postcopy_start: Unreasonably large packaged state: %lu\n",
> +(unsigned long)(qsb_get_length(qsb)));
> +migrate_set_state(ms, MIG_STATE_POSTCOPY_ACTIVE, MIG_STATE_ERROR);
> +qemu_mutex_unlock_iothread();
> +qemu_fclose(fb);
> + 

Re: [Qemu-devel] [PATCH v4 36/47] Page request: Process incoming page request

[David Gibson]

On Fri, Oct 03, 2014 at 06:47:42PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" 
> 
> On receiving MIG_RPCOMM_REQPAGES look up the address and
> queue the page.
> 
> Signed-off-by: Dr. David Alan Gilbert 
> ---
>  arch_init.c   | 52 
> +++
>  include/migration/migration.h | 21 +
>  include/qemu/typedefs.h   |  3 ++-
>  migration.c   | 34 +++-
>  4 files changed, 108 insertions(+), 2 deletions(-)
> 
> diff --git a/arch_init.c b/arch_init.c
> index 4a03171..72f9e17 100644
> --- a/arch_init.c
> +++ b/arch_init.c
> @@ -660,6 +660,58 @@ static int ram_save_page(QEMUFile *f, RAMBlock* block, 
> ram_addr_t offset,
>  }
>  
>  /*
> + * Queue the pages for transmission, e.g. a request from postcopy destination
> + *   ms: MigrationStatus in which the queue is held
> + *   rbname: The RAMBlock the request is for - may be NULL (to mean reuse 
> last)
> + *   start: Offset from the start of the RAMBlock
> + *   len: Length (in bytes) to send
> + *   Return: 0 on success
> + */
> +int ram_save_queue_pages(MigrationState *ms, const char *rbname,
> + ram_addr_t start, ram_addr_t len)
> +{
> +RAMBlock *ramblock;
> +
> +if (!rbname) {
> +/* Reuse last RAMBlock */
> +ramblock = ms->last_req_rb;
> +
> +if (!ramblock) {
> +error_report("ram_save_queue_pages no previous block");
> +return -1;

This should be an assert() shouldn't it?

> +}
> +} else {
> +ramblock = ram_find_block(rbname);
> +
> +if (!ramblock) {
> +error_report("ram_save_queue_pages no block '%s'", rbname);
> +return -1;
> +}

And maybe this one too - I would have expected the rb names to have
already been validated on the source machine at this stage.

> +}
> +DPRINTF("ram_save_queue_pages: Block %s start %zx len %zx",
> +ramblock->idstr, start, len);
> +
> +if (start+len > ramblock->length) {
> +error_report("%s request overrun start=%zx len=%zx blocklen=%zx",
> + __func__, start, len, ramblock->length);
> +return -1;
> +}
> +
> +struct MigrationSrcPageRequest *new_entry =
> +g_malloc0(sizeof(struct MigrationSrcPageRequest));
> +new_entry->rb = ramblock;
> +new_entry->offset = start;
> +new_entry->len = len;
> +ms->last_req_rb = ramblock;
> +
> +qemu_mutex_lock(&ms->src_page_req_mutex);
> +QSIMPLEQ_INSERT_TAIL(&ms->src_page_requests, new_entry, next_req);
> +qemu_mutex_unlock(&ms->src_page_req_mutex);
> +
> +return 0;
> +}
> +
> +/*
>   * ram_find_and_save_block: Finds a page to send and sends it to f
>   *
>   * Returns:  The number of bytes written.
> diff --git a/include/migration/migration.h b/include/migration/migration.h
> index 5e0d30d..5bc01d5 100644
> --- a/include/migration/migration.h
> +++ b/include/migration/migration.h
> @@ -102,6 +102,18 @@ MigrationIncomingState 
> *migration_incoming_get_current(void);
>  MigrationIncomingState *migration_incoming_state_init(QEMUFile *f);
>  void migration_incoming_state_destroy(void);
>  
> +/*
> + * An outstanding page request, on the source, having been received
> + * and queued
> + */
> +struct MigrationSrcPageRequest {
> +RAMBlock *rb;
> +hwaddroffset;
> +hwaddrlen;
> +
> +QSIMPLEQ_ENTRY(MigrationSrcPageRequest) next_req;
> +};
> +
>  struct MigrationState
>  {
>  int64_t bandwidth_limit;
> @@ -138,6 +150,12 @@ struct MigrationState
>   * of the postcopy phase
>   */
>  unsigned long *sentmap;
> +
> +/* Queue of outstanding page requests from the destination */
> +QemuMutex src_page_req_mutex;
> +QSIMPLEQ_HEAD(src_page_requests, MigrationSrcPageRequest) 
> src_page_requests;
> +/* The RAMBlock used in the last src_page_request */
> +RAMBlock *last_req_rb;
>  };
>  
>  void process_incoming_migration(QEMUFile *f);
> @@ -273,4 +291,7 @@ size_t ram_control_save_page(QEMUFile *f, ram_addr_t 
> block_offset,
>   ram_addr_t offset, size_t size,
>   int *bytes_sent);
>  
> +int ram_save_queue_pages(MigrationState *ms, const char *rbname,
> + ram_addr_t start, ram_addr_t len);
> +
>  #endif
> diff --git a/include/qemu/typedefs.h b/include/qemu/typedefs.h
> index 79f57c0..24c2207 100644
> --- a/include/qemu/typedefs.h
> +++ b/include/qemu/typedefs.h
> @@ -8,6 +8,7 @@ typedef struct QEMUTimerListGroup QEMUTimerListGroup;
>  typedef struct QEMUFile QEMUFile;
>  typedef struct QEMUBH QEMUBH;
>  
> +typedef struct AdapterInfo AdapterInfo;
>  typedef struct AioContext AioContext;
>  
>  typedef struct Visitor Visitor;
> @@ -80,6 +81,6 @@ typedef struct FWCfgState FWCfgState;
>  typedef struct PcGuestInfo PcGuestInfo;
>  typedef struct PostcopyPMI PostcopyPMI;
>  typedef struct Range R

Re: [Qemu-devel] [PATCH] esp-pci: fixup deadlock with linux

[Hannes Reinecke]

On 11/09/2014 10:44 AM, Mark Cave-Ayland wrote:
> On 07/11/14 12:22, Hannes Reinecke wrote:
> 
>> A linux guest will be issuing messages:
>>
>> [   32.124042] DC390: Deadlock in DataIn_0: DMA aborted unfinished: 00 
>> bytes remain!!
>> [   32.126348] DC390: DataIn_0: DMA State: 0
>>
>> and the HBA will fail to work properly.
>> Reason is the emulation is not setting the 'DMA transfer done'
>> status correctly.
>>
>> Signed-off-by: Hannes Reinecke 
>> ---
>>  hw/scsi/esp-pci.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/hw/scsi/esp-pci.c b/hw/scsi/esp-pci.c
>> index 82795e6..77b8647 100644
>> --- a/hw/scsi/esp-pci.c
>> +++ b/hw/scsi/esp-pci.c
>> @@ -268,6 +268,8 @@ static void esp_pci_dma_memory_rw(PCIESPState *pci, 
>> uint8_t *buf, int len,
>>  /* update status registers */
>>  pci->dma_regs[DMA_WBC] -= len;
>>  pci->dma_regs[DMA_WAC] += len;
>> +if (pci->dma_regs[DMA_WBC] == 0)
>> +pci->dma_regs[DMA_STAT] |= DMA_STAT_DONE;
>>  }
> 
> Missing braces on the if statement here?
> 
Sigh.

If you insist ...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke   zSeries & Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 21284 (AG Nürnberg)

[Qemu-devel] [PATCH] block: Fix max nb_sectors in bdrv_make_zero

[Fam Zheng]

In bdrv_rw_co we report -EINVAL for nb_sectors > INT_MAX /
BDRV_SECTOR_SIZE, so a caller shouldn't exceed it.

Signed-off-by: Fam Zheng 
---
 block.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/block.c b/block.c
index dacd881..5513379 100644
--- a/block.c
+++ b/block.c
@@ -2790,8 +2790,8 @@ int bdrv_make_zero(BlockDriverState *bs, BdrvRequestFlags 
flags)
 if (nb_sectors <= 0) {
 return 0;
 }
-if (nb_sectors > INT_MAX) {
-nb_sectors = INT_MAX;
+if (nb_sectors > INT_MAX / BDRV_SECTOR_SIZE) {
+nb_sectors = INT_MAX / BDRV_SECTOR_SIZE;
 }
 ret = bdrv_get_block_status(bs, sector_num, nb_sectors, &n);
 if (ret < 0) {
-- 
1.9.3

Re: [Qemu-devel] What "opaque" stand for?

[Kaiyuan]

> -Origin email-
> From: Peter Maydell 
> Sent Time: Friday, November 7, 2014
> To: Kaiyuan 
> Cc: QEMU Developers 
> Subject: Re: [Qemu-devel] What "opaque" stand for?
> 
> On 7 November 2014 14:42, Kaiyuan  wrote:
> >
> > Hello, all
> >
> > I am reviewing source of Qemu. I can see parameter called "opaque" from a 
> > lot of function like this:
> > //@hw/timer/xilinx_timer.c
> > static uint64_t timer_read(void *opaque, hwaddr addr, unsigned int size)
> >
> > {
> > ...
> > }
> >
> >
> > , and its meaning confuse me. What does "opaque" stand for?
> 
> It's a general term (not specific to QEMU) that means "this is some
> data (structure) which we cannot see into". (The word 'opaque' means
> "not able to be seen through"; it's the opposite of 'transparent'.)
> Usually there is an API layer involved which lets you register a
> callback function together with some data to be passed to it
> (in this case that API is memory_region_init_io()). The memory
> region code does not know or care what the data pointer is and
> cannot see inside it (because it's typed as a void*) -- the data
> is opaque to that code. When the callback function timer_read()
> is called, it is passed the opaque data, and the first thing it
> has to do is cast that pointer to the correct type so it can be used.
> 
> -- PMM
Thanks for your explanation, Peter. In this case of timer_read(void *opaque, 
hwaddr addr, unsigned int size), could I think that opaque is a pointer to a 
register located in mmio address? If I cast opaque pointer to corresponding 
structure, the beginning address of structure == hwaddr addr and the size of 
structure == parameter size?

Re: [Qemu-devel] [PATCH] esp-pci: fixup deadlock with linux

[Gonglei]

On 2014/11/10 15:02, Hannes Reinecke wrote:

> On 11/09/2014 10:44 AM, Mark Cave-Ayland wrote:
>> On 07/11/14 12:22, Hannes Reinecke wrote:
>>
>>> A linux guest will be issuing messages:
>>>
>>> [   32.124042] DC390: Deadlock in DataIn_0: DMA aborted unfinished: 00 
>>> bytes remain!!
>>> [   32.126348] DC390: DataIn_0: DMA State: 0
>>>
>>> and the HBA will fail to work properly.
>>> Reason is the emulation is not setting the 'DMA transfer done'
>>> status correctly.
>>>
>>> Signed-off-by: Hannes Reinecke 
>>> ---
>>>  hw/scsi/esp-pci.c | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/hw/scsi/esp-pci.c b/hw/scsi/esp-pci.c
>>> index 82795e6..77b8647 100644
>>> --- a/hw/scsi/esp-pci.c
>>> +++ b/hw/scsi/esp-pci.c
>>> @@ -268,6 +268,8 @@ static void esp_pci_dma_memory_rw(PCIESPState *pci, 
>>> uint8_t *buf, int len,
>>>  /* update status registers */
>>>  pci->dma_regs[DMA_WBC] -= len;
>>>  pci->dma_regs[DMA_WAC] += len;
>>> +if (pci->dma_regs[DMA_WBC] == 0)
>>> +pci->dma_regs[DMA_STAT] |= DMA_STAT_DONE;
>>>  }
>>
>> Missing braces on the if statement here?
>>
> Sigh.
> 
> If you insist ...
> 
> Cheers,
> 
> Hannes

That's the Qemu coding style.
And you will fail ./script/checkpatch.pl.

Best regards,
-Gonglei

Re: [Qemu-devel] [PATCH] esp-pci: fixup deadlock with linux

[Hannes Reinecke]

On 11/10/2014 08:39 AM, Gonglei wrote:
> On 2014/11/10 15:02, Hannes Reinecke wrote:
> 
>> On 11/09/2014 10:44 AM, Mark Cave-Ayland wrote:
>>> On 07/11/14 12:22, Hannes Reinecke wrote:
>>>
 A linux guest will be issuing messages:

 [   32.124042] DC390: Deadlock in DataIn_0: DMA aborted unfinished: 00 
 bytes remain!!
 [   32.126348] DC390: DataIn_0: DMA State: 0

 and the HBA will fail to work properly.
 Reason is the emulation is not setting the 'DMA transfer done'
 status correctly.

 Signed-off-by: Hannes Reinecke 
 ---
  hw/scsi/esp-pci.c | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/hw/scsi/esp-pci.c b/hw/scsi/esp-pci.c
 index 82795e6..77b8647 100644
 --- a/hw/scsi/esp-pci.c
 +++ b/hw/scsi/esp-pci.c
 @@ -268,6 +268,8 @@ static void esp_pci_dma_memory_rw(PCIESPState *pci, 
 uint8_t *buf, int len,
  /* update status registers */
  pci->dma_regs[DMA_WBC] -= len;
  pci->dma_regs[DMA_WAC] += len;
 +if (pci->dma_regs[DMA_WBC] == 0)
 +pci->dma_regs[DMA_STAT] |= DMA_STAT_DONE;
  }
>>>
>>> Missing braces on the if statement here?
>>>
>> Sigh.
>>
>> If you insist ...
>>
>> Cheers,
>>
>> Hannes
> 
> That's the Qemu coding style.
> And you will fail ./script/checkpatch.pl.
> 
I know. After all, it's not the first patch I've sent.

But I always get the various codingstyle thingies
mixed up.

Cheers,

Hannes

-- 
Dr. Hannes Reinecke   zSeries & Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 21284 (AG Nürnberg)

Re: [Qemu-devel] [PATCH] esp-pci: fixup deadlock with linux

[Gonglei]

On 2014/11/10 15:50, Hannes Reinecke wrote:

> On 11/10/2014 08:39 AM, Gonglei wrote:
>> On 2014/11/10 15:02, Hannes Reinecke wrote:
>>
>>> On 11/09/2014 10:44 AM, Mark Cave-Ayland wrote:
 On 07/11/14 12:22, Hannes Reinecke wrote:

> A linux guest will be issuing messages:
>
> [   32.124042] DC390: Deadlock in DataIn_0: DMA aborted unfinished: 
> 00 bytes remain!!
> [   32.126348] DC390: DataIn_0: DMA State: 0
>
> and the HBA will fail to work properly.
> Reason is the emulation is not setting the 'DMA transfer done'
> status correctly.
>
> Signed-off-by: Hannes Reinecke 
> ---
>  hw/scsi/esp-pci.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/hw/scsi/esp-pci.c b/hw/scsi/esp-pci.c
> index 82795e6..77b8647 100644
> --- a/hw/scsi/esp-pci.c
> +++ b/hw/scsi/esp-pci.c
> @@ -268,6 +268,8 @@ static void esp_pci_dma_memory_rw(PCIESPState *pci, 
> uint8_t *buf, int len,
>  /* update status registers */
>  pci->dma_regs[DMA_WBC] -= len;
>  pci->dma_regs[DMA_WAC] += len;
> +if (pci->dma_regs[DMA_WBC] == 0)
> +pci->dma_regs[DMA_STAT] |= DMA_STAT_DONE;
>  }

 Missing braces on the if statement here?

>>> Sigh.
>>>
>>> If you insist ...
>>>
>>> Cheers,
>>>
>>> Hannes
>>
>> That's the Qemu coding style.
>> And you will fail ./script/checkpatch.pl.
>>
> I know. After all, it's not the first patch I've sent.
> 
> But I always get the various codingstyle thingies
> mixed up.
> 
Hum. Each community has its own rules :)


Best regards,
-Gonglei