Re: [Qemu-devel] [RFC] ATAPI-SCSI bridge GSoC project

[Thomas Huth]

On 18/07/15 20:49, Alexander Bezzubikov wrote:
> atapi: ATAPI-SCSI bridge device created
>private SCSI bus added to bridge
>ATAPI inquiry command can use a bridge

 Hi!

Not everybody is familiar with your GSoC project, so it would be great
if you could be a little bit more verbose in your patch description.

Unfortunately, your patch also has some style issues, please make sure
to read http://qemu-project.org/Contribute/SubmitAPatch first.
Especially:
- Your patch lacks a Signed-off-by line
- scripts/checkpatch.pl reports quite a bunch of errors
- Make sure to CC the right maintainers

Hope that helps,
 Thomas

Re: [Qemu-devel] [PATCH v9 0/4] remove icc bus/bridge

[Igor Mammedov]

On Mon, 20 Jul 2015 09:00:06 +0800
Zhu Guihua  wrote:

> 
> On 07/16/2015 05:52 PM, Igor Mammedov wrote:
> > On Thu, 16 Jul 2015 10:45:41 +0800
> > Zhu Guihua  wrote:
> >
> >> ping...
> > I'll look at it once 2.4 is released.
> 
> Got it, thanks.
> 
> By the way, do you know what state of qemu socket topology ?
There were no changes/progress as far as I remember.

> 
> Regards,
> Zhu
> 
> >
> >> On 07/03/2015 05:38 PM, Zhu Guihua wrote:
> >>> ICC Bus was used for providing a hotpluggable bus for APIC and CPU,
> >>> but now we use HotplugHandler to make hotplug. So ICC Bus is
> >>> unnecessary.
> >>>
> >>> This code has passed the new pc-cpu-test.
> >>> And I have tested with kvm along with kernel_irqchip=on/off,
> >>> it works fine.
> >>>
> >>> This patch series is based on the latest master.
> >>>
> >>> v9:
> >>>-use a callback to correct reset sequence for x86
> >>>-update apic mmio mapping
> >>>
> >>> v8:
> >>>-add a wrapper to specify reset order
> >>>
> >>> v7:
> >>>-update to register reset handler for main_system_bus when created
> >>>-register reset handler for apic after all devices are initialized
> >>>
> >>> Chen Fan (2):
> >>> apic: map APIC's MMIO region at each CPU's address space
> >>> cpu/apic: drop icc bus/bridge
> >>>
> >>> Zhu Guihua (2):
> >>> x86: use new method to correct reset sequence
> >>> icc_bus: drop the unused files
> >>>
> >>>default-configs/i386-softmmu.mak   |   1 -
> >>>default-configs/x86_64-softmmu.mak |   1 -
> >>>hw/cpu/Makefile.objs   |   1 -
> >>>hw/cpu/icc_bus.c   | 118 
> >>> -
> >>>hw/i386/pc.c   |  43 +++---
> >>>hw/i386/pc_piix.c  |   9 +--
> >>>hw/i386/pc_q35.c   |   9 +--
> >>>hw/intc/apic_common.c  |  11 +---
> >>>include/hw/cpu/icc_bus.h   |  82 --
> >>>include/hw/i386/apic_internal.h|   7 ++-
> >>>include/hw/i386/pc.h   |   2 +-
> >>>target-i386/cpu.c  |  30 +++---
> >>>12 files changed, 52 insertions(+), 262 deletions(-)
> >>>delete mode 100644 hw/cpu/icc_bus.c
> >>>delete mode 100644 include/hw/cpu/icc_bus.h
> >>>
> >>
> > .
> >
> 

Re: [Qemu-devel] [RFC PATCH 3/4] ppc: Use split I/D mmu modes to avoid flushes on interrupts

[Aurelien Jarno]

On 2015-07-20 09:33, Benjamin Herrenschmidt wrote:
> On Mon, 2015-07-20 at 01:01 +0200, Aurelien Jarno wrote:
> > One way to improve this would be to reduce the size of a TLB entry.
> > Currently we store the page address separately for read, write and
> > code. The information is therefore quite redundant.
> > 
> > We might want to have only one page address entry and encode if it is
> > allowed for read, write or code in the low bits just like we do for
> > invalid, mmio or dirty. This means the TLB entry can be checked with
> > 
> >   env->tlb_table[mmu_idx][page_index].ADDR == 
> >   (addr & (TARGET_PAGE_MASK | (DATA_SIZE - 1))) | READ/WRITE/CODE) 
> > 
> > with READ/WRITE/CODE each being a different bit (they can probably even
> > replace invalid). In practice it means one more instruction in the fast
> > path (one or with a 8-bit immediate), but it allows to divide the size
> > of a TLB entry by two on a 64-bit machine. It might be worth a try.
> 
> It might but that means "fixing" all tcg backends which I'm not necessarily
> looking forward to :-) The cost of that one or might be minimum on some
> processor but I wouldn't bet on it as we have basically all dependent
> instructions.

Understood. I did some tests showing that the number of instructions in
the fast path doesn't not have a big performance impact. In that case,
there is dependency between instructions, but anyway the CPU is likely
to be stalled by the TLB entry to the memory access, so we can add one
instruction before with very little impact.

I'll keep this idea in my todo list for another day.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Re: [Qemu-devel] [PATCH] hostmem: Fix qemu_opt_get_bool() crash in host_memory_backend_init()

[Igor Mammedov]

On Fri, 17 Jul 2015 17:33:55 -0300
Eduardo Habkost  wrote:

> On Thu, Jul 16, 2015 at 11:02:14PM +0200, Igor Mammedov wrote:
> > On Thu, 16 Jul 2015 17:39:17 -0300
> > Eduardo Habkost  wrote:
> > 
> > > This fixes the following crash, introduced by commit
> > > 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6:
> > > 
> > >   $ gdb --args qemu-system-x86_64 -machine pc,mem-merge=off -object
> > > memory-backend-ram,id=ram-node0,size=1024 [...]
> > >   Program received signal SIGABRT, Aborted.
> > >   (gdb) bt
> > >   #0  0x7253b8c7 in raise () at /lib64/libc.so.6
> > >   #1  0x7253d52a in abort () at /lib64/libc.so.6
> > >   #2  0x7253446d in __assert_fail_base () at /lib64/libc.so.6
> > >   #3  0x72534522 in  () at /lib64/libc.so.6
> > >   #4  0x558bb80a in qemu_opt_get_bool_helper
> > > (opts=0x5621b650, name=name@entry=0x558ec922 "mem-merge",
> > > defval=defval@entry=true, del=del@entry=false) at
> > > qemu/util/qemu-option.c:388 #5  0x558bbb5a in
> > > qemu_opt_get_bool (opts=,
> > > name=name@entry=0x558ec922 "mem-merge", defval=defval@entry=true)
> > > at qemu/util/qemu-option.c:398 #6  0x55720a24 in
> > > host_memory_backend_init (obj=0x562ac970) at
> > > qemu/backends/hostmem.c:226
> > > 
> > > Instead of using qemu_opt_get_bool(), that didn't work with
> > > qemu_machine_opts for a long time, we can use the machine QOM
> > > properties directly.
> > > 
> > > Signed-off-by: Eduardo Habkost 
> > > ---
> > >  backends/hostmem.c | 9 +
> > >  1 file changed, 5 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/backends/hostmem.c b/backends/hostmem.c
> > > index 61c1ac0..38a32ed 100644
> > > --- a/backends/hostmem.c
> > > +++ b/backends/hostmem.c
> > > @@ -10,6 +10,7 @@
> > >   * See the COPYING file in the top-level directory.
> > >   */
> > >  #include "sysemu/hostmem.h"
> > > +#include "hw/boards.h"
> > >  #include "qapi/visitor.h"
> > >  #include "qapi-types.h"
> > >  #include "qapi-visit.h"
> > > @@ -223,10 +224,10 @@ static void host_memory_backend_init(Object
> > > *obj) {
> > >  HostMemoryBackend *backend = MEMORY_BACKEND(obj);
> > >  
> > > -backend->merge = qemu_opt_get_bool(qemu_get_machine_opts(),
> > > -   "mem-merge", true);
> > > -backend->dump = qemu_opt_get_bool(qemu_get_machine_opts(),
> > > -  "dump-guest-core", true);
> > > +backend->merge =
> > > object_property_get_bool(OBJECT(current_machine),
> > maybe use qdev_get_machine() instead of OBJECT(current_machine)
> 
> What are the advantages you see in the extra layers of indirection of
> qdev_get_machine()? (I am not against your proposal, but I would like to
> understand the point of qdev_get_machine() yet.)
current_machine might be NULL where as qdev_get_machine() always returns
/machine object.

> 
> I'd prefer to use something that is guaranteed to be MachineState*,
> qdev_get_machine() returns Object*. I am even considering using
> current_machine->mem_merge and current_machine->dump_guest_core directly
> instead of object_property_get_bool(). That would mean extra
> compile-time checks, instead of runtime ones.
Check difference 'git grep qdev_get_machine' vs 'git grep current_machine'.
I was under impression that policy was trying no to use globals unless one has 
to,
and not introduce new usage in presence of other means to get object.

Re: [Qemu-devel] [FIX PATCH] pc-dimm: Fail pc-dimm realization for invalid nodes in non-NUMA configuration

[Igor Mammedov]

On Fri, 17 Jul 2015 18:19:40 +0530
Bharata B Rao  wrote:

> pc_dimm_realize() validates the NUMA node to which memory hotplug is
> being performed only in case of NUMA configuration. Include a check
> to fail invalid nodes in case of non-NUMA configuration too.
> 
> Signed-off-by: Bharata B Rao 
Reviewed-by: Igor Mammedov 

> ---
>  hw/mem/pc-dimm.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c
> index bb04862..099025e 100644
> --- a/hw/mem/pc-dimm.c
> +++ b/hw/mem/pc-dimm.c
> @@ -414,10 +414,11 @@ static void pc_dimm_realize(DeviceState *dev, Error 
> **errp)
>  error_setg(errp, "'" PC_DIMM_MEMDEV_PROP "' property is not set");
>  return;
>  }
> -if ((nb_numa_nodes > 0) && (dimm->node >= nb_numa_nodes)) {
> +if (((nb_numa_nodes > 0) && (dimm->node >= nb_numa_nodes)) ||
> +(!nb_numa_nodes && dimm->node)) {
>  error_setg(errp, "'DIMM property " PC_DIMM_NODE_PROP " has value %"
> PRIu32 "' which exceeds the number of numa nodes: %d",
> -   dimm->node, nb_numa_nodes);
> +   dimm->node, nb_numa_nodes ? nb_numa_nodes : 1);
>  return;
>  }
>  }

Re: [Qemu-devel] [PATCH v2] AioContext: fix broken placement of event_notifier_test_and_clear

[Fam Zheng]

On Mon, 07/20 07:27, Paolo Bonzini wrote:
> diff --git a/aio-win32.c b/aio-win32.c
> index ea655b0..7afc999 100644
> --- a/aio-win32.c
> +++ b/aio-win32.c
> @@ -337,10 +337,11 @@ bool aio_poll(AioContext *ctx, bool blocking)
>  aio_context_acquire(ctx);
>  }
>  
> -if (first && aio_bh_poll(ctx)) {
> -progress = true;
> +if (first) {
> +event_notifier_test_and_clear(&ctx->notifier);

I'm looking at optimizing it but I don't fully understand the relationship
between aio_prepare and WaitForMultipleObjects. Do they get the same set of
events? What if a new event comes in between, for example, thread worker calls
aio_notify()?

Fam

> +progress |= aio_bh_poll(ctx);
> +first = false;
>  }
> -first = false;
>  
>  /* if we have any signaled events, dispatch event */
>  event = NULL;

[Qemu-devel] [RFC PATCH qemu 2/4] vfio: Generalize IOMMU memory listener

[Alexey Kardashevskiy]

At the moment VFIOContainer has an union for per IOMMU type data which
is now an IOMMU memory listener and setup flags. The listener listens
on PCI address space for both Type1 and sPAPR IOMMUs. The setup flags
(@initialized and @error) are only used by Type1 now but the next patch
will use it on sPAPR too.

This introduces VFIOMemoryListener which is wrapper for MemoryListener
and stores a pointer to the container. This allows having multiple
memory listeners for the same container. This replaces Type1 listener
with @iommu_listener.

This moves @initialized and @error out of @iommu_data as these will be
used soon for memory pre-registration.

As there is only release() left in @iommu_data, this moves it to
VFIOContainer and removes @iommu_data and VFIOType1.

This stores @iommu_type in VFIOContainer. The prereg patch will use it
to know whether or not to do proper cleanup.

This should cause no change in behavior.

Signed-off-by: Alexey Kardashevskiy 
---
Changes:
v4:
* used to be "vfio: Store IOMMU type in container"
* moved VFIOType1 content to container as it is not IOMMU type specific
---
 hw/vfio/common.c  | 74 +++
 include/hw/vfio/vfio-common.h | 25 +++
 2 files changed, 59 insertions(+), 40 deletions(-)

diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 85ee9b0..6eb85c7 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -312,11 +312,10 @@ out:
 rcu_read_unlock();
 }
 
-static void vfio_listener_region_add(MemoryListener *listener,
+static void vfio_listener_region_add(VFIOMemoryListener *vlistener,
  MemoryRegionSection *section)
 {
-VFIOContainer *container = container_of(listener, VFIOContainer,
-iommu_data.type1.listener);
+VFIOContainer *container = vlistener->container;
 hwaddr iova, end;
 Int128 llend;
 void *vaddr;
@@ -406,9 +405,9 @@ static void vfio_listener_region_add(MemoryListener 
*listener,
  * can gracefully fail.  Runtime, there's not much we can do other
  * than throw a hardware error.
  */
-if (!container->iommu_data.type1.initialized) {
-if (!container->iommu_data.type1.error) {
-container->iommu_data.type1.error = ret;
+if (!container->initialized) {
+if (!container->error) {
+container->error = ret;
 }
 } else {
 hw_error("vfio: DMA mapping failed, unable to continue");
@@ -416,11 +415,10 @@ static void vfio_listener_region_add(MemoryListener 
*listener,
 }
 }
 
-static void vfio_listener_region_del(MemoryListener *listener,
+static void vfio_listener_region_del(VFIOMemoryListener *vlistener,
  MemoryRegionSection *section)
 {
-VFIOContainer *container = container_of(listener, VFIOContainer,
-iommu_data.type1.listener);
+VFIOContainer *container = vlistener->container;
 hwaddr iova, end;
 int ret;
 
@@ -478,14 +476,33 @@ static void vfio_listener_region_del(MemoryListener 
*listener,
 }
 }
 
-static const MemoryListener vfio_memory_listener = {
-.region_add = vfio_listener_region_add,
-.region_del = vfio_listener_region_del,
+static void vfio_iommu_listener_region_add(MemoryListener *listener,
+   MemoryRegionSection *section)
+{
+VFIOMemoryListener *vlistener = container_of(listener, VFIOMemoryListener,
+ listener);
+
+vfio_listener_region_add(vlistener, section);
+}
+
+
+static void vfio_iommu_listener_region_del(MemoryListener *listener,
+   MemoryRegionSection *section)
+{
+VFIOMemoryListener *vlistener = container_of(listener, VFIOMemoryListener,
+ listener);
+
+vfio_listener_region_del(vlistener, section);
+}
+
+static const MemoryListener vfio_iommu_listener = {
+.region_add = vfio_iommu_listener_region_add,
+.region_del = vfio_iommu_listener_region_del,
 };
 
 static void vfio_listener_release(VFIOContainer *container)
 {
-memory_listener_unregister(&container->iommu_data.type1.listener);
+memory_listener_unregister(&container->iommu_listener.listener);
 }
 
 int vfio_mmap_region(Object *obj, VFIORegion *region,
@@ -676,27 +693,28 @@ static int vfio_connect_container(VFIOGroup *group, 
AddressSpace *as)
 goto free_container_exit;
 }
 
-ret = ioctl(fd, VFIO_SET_IOMMU,
-v2 ? VFIO_TYPE1v2_IOMMU : VFIO_TYPE1_IOMMU);
+container->iommu_type = v2 ? VFIO_TYPE1v2_IOMMU : VFIO_TYPE1_IOMMU;
+ret = ioctl(fd, VFIO_SET_IOMMU, container->iommu_type);
 if (ret) {
 error_report("vfio: failed to set iommu for container: %m");
 ret = -errno;
 goto free_container_exit;

[Qemu-devel] [RFC PATCH qemu 4/4] vfio: spapr: Add SPAPR IOMMU v2 support (DMA memory preregistering)

[Alexey Kardashevskiy]

This makes use of the new "memory registering" feature. The idea is
to provide the userspace ability to notify the host kernel about pages
which are going to be used for DMA. Having this information, the host
kernel can pin them all once per user process, do locked pages
accounting (once) and not spent time on doing that in real time with
possible failures which cannot be handled nicely in some cases.

This adds a prereg memory listener which listens on address_space_memory
and notifies a VFIO container about memory which needs to be
pinned/unpinned. VFIO MMIO regions (i.e. "skip dump" regions) are skipped.

The feature is only enabled for SPAPR IOMMU v2. The host kernel changes
are required. Since v2 does not need/support VFIO_IOMMU_ENABLE, this does
not call it when v2 is detected and enabled.

This does not change the guest visible interface.

Signed-off-by: Alexey Kardashevskiy 
---
Changes:
v4:
* s/ram_listener/prereg_listener/ - listener names suggest what they do,
not what they listen on
* put prereg_listener registeration first

v3:
* new RAM listener skips BARs (i.e. "skip dump" regions)

v2:
* added another listener for RAM
---
 hw/vfio/common.c  | 117 +-
 include/hw/vfio/vfio-common.h |   1 +
 trace-events  |   2 +
 3 files changed, 108 insertions(+), 12 deletions(-)

diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 171c6ad..6d2ee2d 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -326,13 +326,15 @@ static void vfio_listener_region_add(VFIOMemoryListener 
*vlistener,
  MemoryRegionSection *section)
 {
 VFIOContainer *container = vlistener->container;
+bool is_prereg = (vlistener == &container->prereg_listener);
 hwaddr iova, end;
 Int128 llend;
 void *vaddr;
 int ret;
 hwaddr page_mask = vfio_iommu_page_mask(section->mr);
 
-if (vfio_listener_skipped_section(section)) {
+if (vfio_listener_skipped_section(section) ||
+(is_prereg && memory_region_is_skip_dump(section->mr))) {
 trace_vfio_listener_region_add_skip(
 section->offset_within_address_space,
 section->offset_within_address_space +
@@ -357,7 +359,7 @@ static void vfio_listener_region_add(VFIOMemoryListener 
*vlistener,
 
 memory_region_ref(section->mr);
 
-if (memory_region_is_iommu(section->mr)) {
+if (!is_prereg && memory_region_is_iommu(section->mr)) {
 VFIOGuestIOMMU *giommu;
 
 trace_vfio_listener_region_add_iommu(iova,
@@ -405,6 +407,33 @@ static void vfio_listener_region_add(VFIOMemoryListener 
*vlistener,
 
 trace_vfio_listener_region_add_ram(iova, end - 1, vaddr);
 
+if (is_prereg) {
+struct vfio_iommu_spapr_register_memory reg = {
+.argsz = sizeof(reg),
+.flags = 0,
+.vaddr = (uint64_t) vaddr,
+.size = end - iova
+};
+
+ret = ioctl(container->fd, VFIO_IOMMU_SPAPR_REGISTER_MEMORY, ®);
+trace_vfio_ram_register(reg.vaddr, reg.size, ret ? -errno : 0);
+if (ret) {
+/*
+ * On the initfn path, store the first error in the container so we
+ * can gracefully fail.  Runtime, there's not much we can do other
+ * than throw a hardware error.
+ */
+if (!container->initialized) {
+if (!container->error) {
+container->error = ret;
+}
+} else {
+hw_error("vfio: DMA mapping failed, unable to continue");
+}
+}
+return;
+}
+
 ret = vfio_dma_map(container, iova, end - iova, vaddr, section->readonly);
 if (ret) {
 error_report("vfio_dma_map(%p, 0x%"HWADDR_PRIx", "
@@ -430,11 +459,13 @@ static void vfio_listener_region_del(VFIOMemoryListener 
*vlistener,
  MemoryRegionSection *section)
 {
 VFIOContainer *container = vlistener->container;
+bool is_prereg = (vlistener == &container->prereg_listener);
 hwaddr iova, end;
 int ret;
 hwaddr page_mask = vfio_iommu_page_mask(section->mr);
 
-if (vfio_listener_skipped_section(section)) {
+if (vfio_listener_skipped_section(section) ||
+(is_prereg && memory_region_is_skip_dump(section->mr))) {
 trace_vfio_listener_region_del_skip(
 section->offset_within_address_space,
 section->offset_within_address_space +
@@ -448,7 +479,7 @@ static void vfio_listener_region_del(VFIOMemoryListener 
*vlistener,
 return;
 }
 
-if (memory_region_is_iommu(section->mr)) {
+if (!is_prereg && memory_region_is_iommu(section->mr)) {
 VFIOGuestIOMMU *giommu;
 
 QLIST_FOREACH(giommu, &container->giommu_list, giommu_next) {
@@ -477,8 +508,24 @@ static void vfio_listener_region_del(VFIOMemoryListener 
*vlistener,
 return;
 }
 
+if (is_prereg) {
+void *vad

[Qemu-devel] [RFC PATCH qemu 0/4] vfio: SPAPR IOMMU v2 (memory preregistration support)

[Alexey Kardashevskiy]

Yet another try, reworked the whole patchset.

Here are few patches to prepare an existing listener for handling memory
preregistration for SPAPR guests running on POWER8.

This used to be a part of DDW patchset but now is separated as requested.


Please comment. Thanks!


Changes:
v4:
* have 2 listeners now - "iommu" and "prereg"
* removed iommu_data
* many smaller changes

v3:
* removed incorrect "vfio: Skip PCI BARs in memory listener"
* removed page size changes from quirks as they did not completely fix
the crashes happening on POWER8 (only total removal helps there)
* added "memory: Add reporting of supported page sizes"


Alexey Kardashevskiy (4):
  memory: Add reporting of supported page sizes
  vfio: Generalize IOMMU memory listener
  vfio: Use different page size for different IOMMU types
  vfio: spapr: Add SPAPR IOMMU v2 support (DMA memory preregistering)

 hw/ppc/spapr_iommu.c  |   8 ++
 hw/vfio/common.c  | 217 +-
 include/exec/memory.h |  11 +++
 include/hw/vfio/vfio-common.h |  26 ++---
 memory.c  |   9 ++
 trace-events  |   2 +
 6 files changed, 214 insertions(+), 59 deletions(-)

-- 
2.4.0.rc3.8.gfb3e7d5

[Qemu-devel] [RFC PATCH qemu 3/4] vfio: Use different page size for different IOMMU types

[Alexey Kardashevskiy]

The existing memory listener is called on RAM or PCI address space
which implies potentially different page size.

This uses new memory_region_iommu_get_page_sizes() for IOMMU regions
or falls back to qemu_real_host_page_size if RAM.

Signed-off-by: Alexey Kardashevskiy 
---
Changes:
* uses the smallest page size for mask as IOMMU MR can support multple
page sizes
---
 hw/vfio/common.c | 28 
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 6eb85c7..171c6ad 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -312,6 +312,16 @@ out:
 rcu_read_unlock();
 }
 
+static hwaddr vfio_iommu_page_mask(MemoryRegion *mr)
+{
+if (memory_region_is_iommu(mr)) {
+int smallest = ffs(memory_region_iommu_get_page_sizes(mr)) - 1;
+
+return ~((1ULL << smallest) - 1);
+}
+return qemu_real_host_page_mask;
+}
+
 static void vfio_listener_region_add(VFIOMemoryListener *vlistener,
  MemoryRegionSection *section)
 {
@@ -320,6 +330,7 @@ static void vfio_listener_region_add(VFIOMemoryListener 
*vlistener,
 Int128 llend;
 void *vaddr;
 int ret;
+hwaddr page_mask = vfio_iommu_page_mask(section->mr);
 
 if (vfio_listener_skipped_section(section)) {
 trace_vfio_listener_region_add_skip(
@@ -329,16 +340,16 @@ static void vfio_listener_region_add(VFIOMemoryListener 
*vlistener,
 return;
 }
 
-if (unlikely((section->offset_within_address_space & ~TARGET_PAGE_MASK) !=
- (section->offset_within_region & ~TARGET_PAGE_MASK))) {
+if (unlikely((section->offset_within_address_space & ~page_mask) !=
+ (section->offset_within_region & ~page_mask))) {
 error_report("%s received unaligned region", __func__);
 return;
 }
 
-iova = TARGET_PAGE_ALIGN(section->offset_within_address_space);
+iova = ROUND_UP(section->offset_within_address_space, ~page_mask + 1);
 llend = int128_make64(section->offset_within_address_space);
 llend = int128_add(llend, section->size);
-llend = int128_and(llend, int128_exts64(TARGET_PAGE_MASK));
+llend = int128_and(llend, int128_exts64(page_mask));
 
 if (int128_ge(int128_make64(iova), llend)) {
 return;
@@ -421,6 +432,7 @@ static void vfio_listener_region_del(VFIOMemoryListener 
*vlistener,
 VFIOContainer *container = vlistener->container;
 hwaddr iova, end;
 int ret;
+hwaddr page_mask = vfio_iommu_page_mask(section->mr);
 
 if (vfio_listener_skipped_section(section)) {
 trace_vfio_listener_region_del_skip(
@@ -430,8 +442,8 @@ static void vfio_listener_region_del(VFIOMemoryListener 
*vlistener,
 return;
 }
 
-if (unlikely((section->offset_within_address_space & ~TARGET_PAGE_MASK) !=
- (section->offset_within_region & ~TARGET_PAGE_MASK))) {
+if (unlikely((section->offset_within_address_space & ~page_mask) !=
+ (section->offset_within_region & ~page_mask))) {
 error_report("%s received unaligned region", __func__);
 return;
 }
@@ -457,9 +469,9 @@ static void vfio_listener_region_del(VFIOMemoryListener 
*vlistener,
  */
 }
 
-iova = TARGET_PAGE_ALIGN(section->offset_within_address_space);
+iova = ROUND_UP(section->offset_within_address_space, ~page_mask + 1);
 end = (section->offset_within_address_space + int128_get64(section->size)) 
&
-  TARGET_PAGE_MASK;
+  page_mask;
 
 if (iova >= end) {
 return;
-- 
2.4.0.rc3.8.gfb3e7d5

[Qemu-devel] [RFC PATCH qemu 1/4] memory: Add reporting of supported page sizes

[Alexey Kardashevskiy]

Every IOMMU has some granularity which MemoryRegionIOMMUOps::translate
uses when translating, however this information is not available outside
the translate context for various checks.

This adds a get_page_sizes callback to MemoryRegionIOMMUOps and
a wrapper for it so IOMMU users (such as VFIO) can know the actual
page size(s) used by an IOMMU.

The qemu_real_host_page_mask is used as fallback.

Signed-off-by: Alexey Kardashevskiy 
---
Changes:
v4:
* s/1iommu_ops;
 }
 
+uint64_t memory_region_iommu_get_page_sizes(MemoryRegion *mr)
+{
+assert(memory_region_is_iommu(mr));
+if (mr->iommu_ops && mr->iommu_ops->get_page_sizes) {
+return mr->iommu_ops->get_page_sizes(mr);
+}
+return qemu_real_host_page_size;
+}
+
 void memory_region_register_iommu_notifier(MemoryRegion *mr, Notifier *n)
 {
 notifier_list_add(&mr->iommu_notify, n);
-- 
2.4.0.rc3.8.gfb3e7d5

[Qemu-devel] [Bug 1469946] Re: guest can't get IP when create guest with bridge.

[chao zhou]

Does the bug's patch has merged in qemu.git?
I test the latest qemu.git(commit:5b5e8cdd7da7a2214dd062afff5b866234aab228), 
the bug still can reproduce.

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

Title:
  guest can't get IP when create guest with bridge.

Status in QEMU:
  New

Bug description:
  Environment:
  
  Host OS (ia32/ia32e/IA64):ia32e
  Guest OS (ia32/ia32e/IA64):ia32e
  Guest OS Type (Linux/Windows):linux
  kvm.git Commit:aefbef10e3ae6e2c6e3c54f906f10b34c73a2c66
  qemu.git Commit:dc1e1350f8061021df765b396295329797d66933
  Host Kernel Version:4.1.0
  Hardware:Ivytown_EP, Haswell_EP

  
  Bug detailed description:
  --
  when create guest with bridge, the guest can not get ip.

  note:
  1. fail rate: 3/5
  2. this is a qemu bug:
  kvm  + qemu   =  result
  aefbef10 + dc1e1350=  bad 
  aefbef10 + a4ef02fd   =  good

  Reproduce steps:
  
  1. create guest:
  qemu-system-x86_64 -enable-kvm -m 2G -smp 4 -device 
virtio-net-pci,netdev=net0,mac=$random_mac -netdev 
tap,id=net0,script=/etc/kvm/qemu-ifup rhel6u5.qcow

  Current result:
  
  guest can't get IP

  Expected result:
  
  guest can get ip

  Basic root-causing log:
  --

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

Re: [Qemu-devel] [RFC PATCH 3/4] ppc: Use split I/D mmu modes to avoid flushes on interrupts

[Benjamin Herrenschmidt]

On Mon, 2015-07-20 at 09:11 +0200, Aurelien Jarno wrote:
> 
> Understood. I did some tests showing that the number of instructions
> in
> the fast path doesn't not have a big performance impact. In that case,
> there is dependency between instructions, but anyway the CPU is likely
> to be stalled by the TLB entry to the memory access, so we can add one
> instruction before with very little impact.

Possibly, though I would expect the TLB to be pretty hot in the cache.
The likelihood of successive accesses being close to each other (or even
in the same page) is also quite high. It might be something worth
instrumenting some day.

The one thing that might prove a gain for some workloads would be to add
TCG primitives for simple vector load/stores... with gcc being more and
more aggressive these days at using them for moving things around (and
glibc memcpy), it might be a measurable gain.
 
> I'll keep this idea in my todo list for another day.

My todo list tend to be a O_WRONLY file sadly :-)

Cheers,
Ben.

Re: [Qemu-devel] [PATCH COLO-Frame v7 04/34] colo-comm/migration: skip colo info section for special cases

[zhanghailiang]

On 2015/7/18 1:07, Dr. David Alan Gilbert wrote:

* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:

For older machine types, we skip the colo info section when do
migration, in this way, we can migrate successfully between older mainchine and
the new one.

We also skip this section if colo is not enabled (i.e.
migrate_set_capability colo on), so that, It not break compatibility with 
migration
however the --enable-colo/disable-colo on the source/destination;

Signed-off-by: zhanghailiang 
---
  hw/i386/pc_piix.c |  1 +
  hw/i386/pc_q35.c  |  1 +
  hw/ppc/spapr.c|  1 +
  include/migration/migration.h |  1 +
  migration/colo-comm.c | 13 +
  5 files changed, 17 insertions(+)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 8167b12..926b0d8 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -313,6 +313,7 @@ static void pc_compat_2_3(MachineState *machine)
  }
  global_state_set_optional();
  savevm_skip_configuration();
+savevm_skip_colo_state();
  }

  static void pc_compat_2_2(MachineState *machine)
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 974aead..b5c6c85 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -296,6 +296,7 @@ static void pc_compat_2_3(MachineState *machine)
  }
  global_state_set_optional();
  savevm_skip_configuration();
+savevm_skip_colo_state();
  }

  static void pc_compat_2_2(MachineState *machine)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index a6f1947..568de93 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -1880,6 +1880,7 @@ static void spapr_compat_2_3(Object *obj)
  {
  savevm_skip_section_footers();
  global_state_set_optional();
+savevm_skip_colo_state();
  }

  static void spapr_compat_2_2(Object *obj)
diff --git a/include/migration/migration.h b/include/migration/migration.h
index 5c797d4..1b23517 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -203,4 +203,5 @@ void savevm_skip_section_footers(void);
  void register_global_state(void);
  void global_state_set_optional(void);
  void savevm_skip_configuration(void);
+void savevm_skip_colo_state(void);
  #endif
diff --git a/migration/colo-comm.c b/migration/colo-comm.c
index 0a93672..3c8e361 100644
--- a/migration/colo-comm.c
+++ b/migration/colo-comm.c
@@ -21,6 +21,11 @@ typedef struct {

  static COLOInfo colo_info;

+void savevm_skip_colo_state(void)
+{
+colo_info.skip = true;
+}
+
  static void colo_info_pre_save(void *opaque)
  {
  COLOInfo *s = opaque;
@@ -32,12 +37,20 @@ static void colo_info_pre_save(void *opaque)
  }
  }

+static bool colo_info_need(void *opaque)
+{
+if (migrate_enable_colo() && !colo_info.skip) {
+return true;
+ }
+return false;
+}


That will work, but I think (untested) this can just be:

+static bool colo_info_need(void *opaque)
+{
+return migrate_enable_colo();
+}

and then you can get rid of the skip stuff (and merge it
back to the previous patch).

Old qemu's will never sent the section so we're safe.
New qemu's with that flag unset won't send the section, so
   they're still migration compatible on the machine type.
New qemu's with the flag set will use it.



Yes, you are right, the 'skip stuff' is redundant, will fix it in next version, 
thanks.





  static const VMStateDescription colo_state = {
   .name = "COLOState",
   .version_id = 1,
   .minimum_version_id = 1,
   .pre_save = colo_info_pre_save,
+ .needed = colo_info_need,
   .fields = (VMStateField[]) {
   VMSTATE_UINT32(colo_requested, COLOInfo),
   VMSTATE_END_OF_LIST()
--
1.7.12.4



--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

.

[Qemu-devel] [PATCH] qxl: Fix new function name for spice-server library

[Frediano Ziglio]

The new spice-server function to limit the number of monitors (0.12.6)
changed while development from spice_qxl_set_monitors_config_limit to
spice_qxl_max_monitors (accepted upstream).
By mistake I post patch with former name.
This patch fix the function name.

Signed-off-by: Frediano Ziglio 

---
 hw/display/qxl.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

I tested again doing a clean build, unfortunately I did some mistake
and my tests worked.

diff --git a/hw/display/qxl.c b/hw/display/qxl.c
index 4e5ff69..2288238 100644
--- a/hw/display/qxl.c
+++ b/hw/display/qxl.c
@@ -273,8 +273,7 @@ static void qxl_spice_monitors_config_async(PCIQXLDevice 
*qxl, int replay)
 } else {
 #if SPICE_SERVER_VERSION >= 0x000c06 /* release 0.12.6 */
 if (qxl->max_outputs) {
-spice_qxl_set_monitors_config_limit(&qxl->ssd.qxl,
-qxl->max_outputs);
+spice_qxl_set_max_monitors(&qxl->ssd.qxl, qxl->max_outputs);
 }
 #endif
 qxl->guest_monitors_config = qxl->ram->monitors_config;
-- 
2.1.0

Re: [Qemu-devel] [PATCH] qxl: Fix new function name for spice-server library

[Christophe Fergeau]

On Mon, Jul 20, 2015 at 09:43:23AM +0100, Frediano Ziglio wrote:
> The new spice-server function to limit the number of monitors (0.12.6)
> changed while development from spice_qxl_set_monitors_config_limit to
> spice_qxl_max_monitors (accepted upstream).
> By mistake I post patch with former name.
> This patch fix the function name.
> 
> Signed-off-by: Frediano Ziglio 
> 
> ---
>  hw/display/qxl.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> I tested again doing a clean build, unfortunately I did some mistake
> and my tests worked.
> 
> diff --git a/hw/display/qxl.c b/hw/display/qxl.c
> index 4e5ff69..2288238 100644
> --- a/hw/display/qxl.c
> +++ b/hw/display/qxl.c
> @@ -273,8 +273,7 @@ static void qxl_spice_monitors_config_async(PCIQXLDevice 
> *qxl, int replay)
>  } else {
>  #if SPICE_SERVER_VERSION >= 0x000c06 /* release 0.12.6 */
>  if (qxl->max_outputs) {
> -spice_qxl_set_monitors_config_limit(&qxl->ssd.qxl,
> -qxl->max_outputs);
> +spice_qxl_set_max_monitors(&qxl->ssd.qxl, qxl->max_outputs);
>  }
>  #endif
>  qxl->guest_monitors_config = qxl->ram->monitors_config;

ACK from me,

Christophe


pgpmeQQ6uSTL7.pgp
Description: PGP signature

[Qemu-devel] [RFC] Virt machine memory map

[Pavel Fedin]

 Hello!

 In our project we work on a very fast paravirtualized network I/O drivers, 
based  on ivshmem. We
successfully got ivshmem working on ARM, however with one hack.
Currently we have:
--- cut ---
[VIRT_PCIE_MMIO] =  { 0x1000, 0x2eff },
[VIRT_PCIE_PIO] =   { 0x3eff, 0x0001 },
[VIRT_PCIE_ECAM] =  { 0x3f00, 0x0100 },
[VIRT_MEM] ={ 0x4000, 30ULL * 1024 * 1024 * 1024 },
--- cut ---
 And MMIO region is not enough for us because we want to have 1GB mapping for 
PCI device. In order
to make it working, we modify the map as follows:
--- cut ---
[VIRT_PCIE_MMIO] ={ 0x1000, 0x7eff },
[VIRT_PCIE_PIO] =   { 0x8eff, 0x0001 },
[VIRT_PCIE_ECAM] =  { 0x8f00, 0x0100 },
[VIRT_MEM] = { 0x9000, 30ULL * 1024 * 1024 * 1024 },
--- cut ---
 The question is - how could we upstream this? I believe modifying 32-bit virt 
memory map this way
is not good. Will it be OK to have different memory map for 64-bit virt ?
 Another possible approach is not to use PCI, but MMIO instead, and just 
specify our region in the
device tree. This way we work around the limitation of having only a single PCI 
MMIO region, and we
could happily place our 1GB device after system RAM.
 Any opinions ?

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia

Re: [Qemu-devel] [RFC] Virt machine memory map

[Peter Maydell]

On 20 July 2015 at 09:55, Pavel Fedin  wrote:
>  Hello!
>
>  In our project we work on a very fast paravirtualized network I/O drivers, 
> based  on ivshmem. We
> successfully got ivshmem working on ARM, however with one hack.
> Currently we have:
> --- cut ---
> [VIRT_PCIE_MMIO] =  { 0x1000, 0x2eff },
> [VIRT_PCIE_PIO] =   { 0x3eff, 0x0001 },
> [VIRT_PCIE_ECAM] =  { 0x3f00, 0x0100 },
> [VIRT_MEM] ={ 0x4000, 30ULL * 1024 * 1024 * 1024 },
> --- cut ---
>  And MMIO region is not enough for us because we want to have 1GB mapping for 
> PCI device. In order
> to make it working, we modify the map as follows:
> --- cut ---
> [VIRT_PCIE_MMIO] ={ 0x1000, 0x7eff },
> [VIRT_PCIE_PIO] =   { 0x8eff, 0x0001 },
> [VIRT_PCIE_ECAM] =  { 0x8f00, 0x0100 },
> [VIRT_MEM] = { 0x9000, 30ULL * 1024 * 1024 * 1024 },
> --- cut ---
>  The question is - how could we upstream this? I believe modifying 32-bit 
> virt memory map this way
> is not good. Will it be OK to have different memory map for 64-bit virt ?

I think the theory we discussed at the time of putting in the PCIe
device was that if we wanted this we'd add support for the other
PCIe memory window (which would then live at somewhere above 4GB).
Alex, can you remember what the idea was?

But to be honest I think we weren't expecting anybody to need
1GB of PCI MMIO space unless it was a video card...

thanks
-- PMM

Re: [Qemu-devel] [libvirt] [PATCH] qxl: Fix new function name for spice-server library

[Martin Kletzander]

On Mon, Jul 20, 2015 at 09:43:23AM +0100, Frediano Ziglio wrote:

The new spice-server function to limit the number of monitors (0.12.6)
changed while development from spice_qxl_set_monitors_config_limit to
spice_qxl_max_monitors (accepted upstream).
By mistake I post patch with former name.
This patch fix the function name.

Signed-off-by: Frediano Ziglio 

---
hw/display/qxl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

I tested again doing a clean build, unfortunately I did some mistake
and my tests worked.

diff --git a/hw/display/qxl.c b/hw/display/qxl.c
index 4e5ff69..2288238 100644
--- a/hw/display/qxl.c
+++ b/hw/display/qxl.c
@@ -273,8 +273,7 @@ static void qxl_spice_monitors_config_async(PCIQXLDevice 
*qxl, int replay)
} else {
#if SPICE_SERVER_VERSION >= 0x000c06 /* release 0.12.6 */
if (qxl->max_outputs) {
-spice_qxl_set_monitors_config_limit(&qxl->ssd.qxl,
-qxl->max_outputs);
+spice_qxl_set_max_monitors(&qxl->ssd.qxl, qxl->max_outputs);
}
#endif
qxl->guest_monitors_config = qxl->ram->monitors_config;
--
2.1.0



Same as the fix I did in order for this to work with upstream spice.

ACK.  Weak, though, as I'm not a privileged one.

Martin


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PULL for-2.4 0/1] virtio-rng: reduce wakeups

[Peter Maydell]

On 17 July 2015 at 14:49, Amit Shah  wrote:
> The following changes since commit 5b5e8cdd7da7a2214dd062afff5b866234aab228:
>
>   Merge remote-tracking branch 'remotes/kraxel/tags/pull-usb-20150717-1' into 
> staging (2015-07-17 12:39:12 +0100)
>
> are available in the git repository at:
>
>   https://git.kernel.org/pub/scm/virt/qemu/amit/virtio-rng.git tags/vrng-2.4
>
> for you to fetch changes up to 621a20e08155179b1902c428361e80f41429f50d:
>
>   virtio-rng: trigger timer only when guest requests for entropy (2015-07-17 
> 19:05:16 +0530)
>
> 
> Fire timer only when required.  Brings down wakeups by a big number.

Applied, thanks.

-- PMM

Re: [Qemu-devel] [PULL for-2.4 0/7] update ipxe roms, fix efi support

[Peter Maydell]

On 17 July 2015 at 15:37, Gerd Hoffmann  wrote:
>   Hi,
>
> This pull finally fixes the efi boot support.  ipxe is updated to the
> latest master, two non-upstream commits needed to make efi work are
> added on top, and the build process is tweaked a bit.
>
> The ipxe changes are pushed to git://git.kraxel.org/ipxe (branch qemu,
> tag qemu-2.4).  They should be mirrored to git://git.qemu.org/ipxe.git
> before merging this pull request.

Is this supposed to happen automatically, or does somebody
need to manually do something for that to happen?

thanks
-- PMM

Re: [Qemu-devel] [PATCH v7 18/42] Add wrappers and handlers for sending/receiving the postcopy-ram migration messages.

[Amit Shah]

On (Tue) 16 Jun 2015 [11:26:31], Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" 
> 
> The state of the postcopy process is managed via a series of messages;
>* Add wrappers and handlers for sending/receiving these messages
>* Add state variable that track the current state of postcopy
> 
> Signed-off-by: Dr. David Alan Gilbert 

Reviewed-by: Amit Shah 

But:

> +void qemu_savevm_send_postcopy_ram_discard(QEMUFile *f, const char *name,
> +   uint16_t len,
> +   uint64_t *start_list,
> +   uint64_t *end_list)
> +{
> +uint8_t *buf;
> +uint16_t tmplen;
> +uint16_t t;
> +size_t name_len = strlen(name);
> +
> +trace_qemu_savevm_send_postcopy_ram_discard(name, len);
> +buf = g_malloc0(len*16 + name_len + 3);
> +buf[0] = 0; /* Version */
> +assert(name_len < 256);
> +buf[1] = name_len;
> +memcpy(buf+2, name, name_len);
> +tmplen = 2+name_len;
> +buf[tmplen++] = '\0';

whitespace around operators missing

> +static int loadvm_postcopy_ram_handle_discard(MigrationIncomingState *mis,
> +  uint16_t len)

> +len -= 3+strlen(ramid);

ditto

Amit

Re: [Qemu-devel] [PATCH v2] AioContext: fix broken placement of event_notifier_test_and_clear

[Fam Zheng]

On Mon, 07/20 15:46, Fam Zheng wrote:
> On Mon, 07/20 07:27, Paolo Bonzini wrote:
> > diff --git a/aio-win32.c b/aio-win32.c
> > index ea655b0..7afc999 100644
> > --- a/aio-win32.c
> > +++ b/aio-win32.c
> > @@ -337,10 +337,11 @@ bool aio_poll(AioContext *ctx, bool blocking)
> >  aio_context_acquire(ctx);
> >  }
> >  
> > -if (first && aio_bh_poll(ctx)) {
> > -progress = true;
> > +if (first) {
> > +event_notifier_test_and_clear(&ctx->notifier);
> 
> I'm looking at optimizing it but I don't fully understand the relationship
> between aio_prepare and WaitForMultipleObjects. Do they get the same set of
> events? What if a new event comes in between, for example, thread worker calls
> aio_notify()?
> 

After some reading I think WaitForMultipleObjects is for event notifiers and
aio_prepare is for select() on fd events.

It's a bit trickier than aio-posix, in the first iteration there could be
another event masking ctx->notifier so we don't know if we need to clear it.
But since MSDN says:

"""
... the return value minus WAIT_OBJECT_0 indicates the lpHandles array index of
the object that satisfied the wait. If more than one object became signaled
during the call, this is the array index of the signaled object with the
smallest index value of all the signaled objects.
"""

Maybe we can reverse events[] so that ctx->notifier will be the 0th one. And I
think we can always remove it after first iteration, am I right?

Fam

Re: [Qemu-devel] [PATCH v7 18/42] Add wrappers and handlers for sending/receiving the postcopy-ram migration messages.

[Amit Shah]

On (Mon) 13 Jul 2015 [13:02:09], Juan Quintela wrote:

> > +/* We're expecting a
> > + *Version (0)
> > + *a RAM ID string (length byte, name, 0 term)
> > + *then at least 1 16 byte chunk
> > +*/
> > +if (len < 20) { 1 +
> 
>1+1+1+1+2*8
> 
> Humm, thinking about it,  why are we not needing a length field of
> number of entries?

hm, yea.

> > +error_report("CMD_POSTCOPY_RAM_DISCARD invalid length (%d)", len);
> > +return -1;
> > +}
> > +
> > +tmp = qemu_get_byte(mis->file);
> > +if (tmp != 0) {
> 
> I think that a constant telling POSTCOPY_VERSION0 or whatever?

agreed.

Amit

[Qemu-devel] [Bug 1476183] [NEW] can not create 4 serial port on window (guest os)

[feihu]

Public bug reported:

qemu ver: 2.1.2-Latest

guest os: window 7 64bit with 2 cpu

problem: when qemu start with 4 serial port, on linux(rhel 7) guest os,
/dev/ttyS0-4 is work fine.  but on window 7 guest os, only show
com1,com2 in device manager, how to get com3 & com4 ?

qemu cmd:
 -chardev spiceport,id=charserial0,name=org.qemu.console.serial.0
 -device isa-serial,chardev=charserial0,id=serial0
 -chardev spiceport,id=charserial1,name=org.qemu.console.serial.1
 -device isa-serial,chardev=charserial1,id=serial1
 -chardev spiceport,id=charserial2,name=org.qemu.console.serial.2
 -device isa-serial,chardev=charserial2,id=serial2
 -chardev spiceport,id=charserial3,name=org.qemu.console.serial.3
 -device isa-serial,chardev=charserial3,id=serial3

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

Title:
  can not create 4 serial port on window (guest os)

Status in QEMU:
  New

Bug description:
  qemu ver: 2.1.2-Latest

  guest os: window 7 64bit with 2 cpu

  problem: when qemu start with 4 serial port, on linux(rhel 7) guest
  os, /dev/ttyS0-4 is work fine.  but on window 7 guest os, only show
  com1,com2 in device manager, how to get com3 & com4 ?

  qemu cmd:
   -chardev spiceport,id=charserial0,name=org.qemu.console.serial.0
   -device isa-serial,chardev=charserial0,id=serial0
   -chardev spiceport,id=charserial1,name=org.qemu.console.serial.1
   -device isa-serial,chardev=charserial1,id=serial1
   -chardev spiceport,id=charserial2,name=org.qemu.console.serial.2
   -device isa-serial,chardev=charserial2,id=serial2
   -chardev spiceport,id=charserial3,name=org.qemu.console.serial.3
   -device isa-serial,chardev=charserial3,id=serial3

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

Re: [Qemu-devel] [POC] colo-proxy in qemu

[Stefan Hajnoczi]

On Mon, Jul 20, 2015 at 02:42:33PM +0800, Li Zhijian wrote:
> We are planning to implement colo-proxy in qemu to cache and compare packets.

I thought there is a kernel module to do that?

Why does the proxy need to be part of the QEMU process?  -netdev socket
or host network stack features allow you to process packets in a
separate process.

Without details on what the proxy does it's hard to discuss this.  What
happens in the non-TCP case?  What happens in the TCP case?

Does the proxy need to perform privileged operations, create sockets,
open files, etc?

The slirp code is not actively developed or used much in production.  It
might be a good idea to audit the code for bugs if you want to use it.

Stefan


pgp9feTj3BlPV.pgp
Description: PGP signature

[Qemu-devel] Accessing guest kernel thread_info struct

[Igor R]

Hello,

I need to access thread_info (linux kernel struct) of the guest from within
qemu, when the guest is in kernel mode.
To do this, I read the stack pointer and mask it with ~(stack_size - 1).
This works with x86 and ARM, but doesn't seem to work with MIPS - the
pointer points to something that doesn't look like thread_info.
I get sp as follows: env->active_tc.gpr[29]
Is it correct? What could be the reason of failure?

Thanks.

Re: [Qemu-devel] [PATCH for-2.4] disas/arm-a64: Add missing compiler attribute GCC_FMT_ATTR

[Peter Maydell]

On 18 July 2015 at 10:13, Peter Maydell  wrote:
> On 18 July 2015 at 09:27, Stefan Weil  wrote:
>> Type fprintf_function which fits here was defined with this attribute.
>>
>> Signed-off-by: Stefan Weil 
>> ---
>>
>> This is an optional trivial patch for 2.4 which fixes compiler warnings
>> in my build environment (with -Wextra).
>
> Reviewed-by: Peter Maydell 
>
> No objection if you want to put it in 2.4, though I'm a bit
> surprised that missing GCC_FMT_ATTR provokes warnings.
> The cleanup is nice anyway.

I've applied this to target-arm.next. Thanks.

-- PMM

Re: [Qemu-devel] [PATCH v2] raw-posix.c: Make physical devices usable in QEMU under Mac OS X host

[Stefan Hajnoczi]

On Fri, Jul 17, 2015 at 03:24:34PM -0400, Programmingkid wrote:
> 
> On Jul 17, 2015, at 9:41 AM, Stefan Hajnoczi wrote:
> 
> > On Thu, Jul 16, 2015 at 04:46:07PM -0400, Programmingkid wrote:
> >> @@ -2014,7 +2015,9 @@ kern_return_t GetBSDPath( io_iterator_t 
> >> mediaIterator, char *bsdPath, CFIndex ma
> >> if ( bsdPathAsCFString ) {
> >> size_t devPathLength;
> >> strcpy( bsdPath, _PATH_DEV );
> >> -strcat( bsdPath, "r" );
> >> +if (flags & BDRV_O_NOCACHE) {
> >> +strcat(bsdPath, "r");
> >> +}
> >> devPathLength = strlen( bsdPath );
> >> if ( CFStringGetCString( bsdPathAsCFString, bsdPath + 
> >> devPathLength, maxPathSize - devPathLength, kCFStringEncodingASCII ) ) {
> >> kernResult = KERN_SUCCESS;
> > 
> > Is this the fix that makes CD-ROM passthrough work for you?
> > 
> > Does the guest boot successfully when you do:
> > 
> >  -drive if=ide,media=cdrom,cache=none,file=/dev/cdrom
> 
> The guest fails during the boot process with the above command line. 

That means the issue you originally hit hasn't been solved yet.

Take a look at s->needs_alignment and raw_probe_alignment().  In the -drive
cache=none case raw-posix needs to detect the correct alignment (probably 2 KB
for CD-ROMs).

Stefan


pgpbn8sQuAqGZ.pgp
Description: PGP signature

Re: [Qemu-devel] [PATCH v2] pci_add_capability: remove duplicate comments

[Chen, Hanxiao]

> -Original Message-
> From: qemu-devel-bounces+chenhanxiao=cn.fujitsu@nongnu.org
> [mailto:qemu-devel-bounces+chenhanxiao=cn.fujitsu@nongnu.org] On Behalf Of
> Chen Hanxiao
> Sent: Tuesday, July 14, 2015 4:16 PM
> To: Michael S. Tsirkin; qemu-devel@nongnu.org
> Subject: [Qemu-devel] [PATCH v2] pci_add_capability: remove duplicate comments
> 
> Signed-off-by: Chen Hanxiao 
> ---
>  hw/pci/pci.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index 442f822..a017614 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -2101,12 +2101,10 @@ static void pci_del_option_rom(PCIDevice *pdev)
>  }
> 
>  /*
> - * if !offset
> - * Reserve space and add capability to the linked list in pci config space
> - *
>   * if offset = 0,
>   * Find and reserve space and add capability to the linked list
> - * in pci config space */
> + * in pci config space
> + */
>  int pci_add_capability(PCIDevice *pdev, uint8_t cap_id,
> uint8_t offset, uint8_t size)
>  {
> --
> 2.1.0
> 

ping

Regards,
- Chen

[Qemu-devel] [PATCH v2] PAM: make PAM emulation closer to documentation

[Efimov Vasily]

This patch improves PAM emulation.

PAM defines 4 memory access redirection modes. In mode 1 reads are directed to
RAM and writes are directed to PCI. In mode 2 it is contrary. In mode 0 all
access is directed to PCI. In mode 3 it is directed to RAM. Currently all modes
are emulated using aliases. It is good for modes 0 and 3 but modes 1 and 2
require more complicated logic. Present API has not needed region type.

The patch uses ROM-like regions for modes 1 and 2. Each region has I/O callbacks
to redirect access to destination defined by current mode. Write access is
always redirected by callback. If actual read source is RAM or ROM (it is
common case) then ram_addr of PAM region is set to ram_addr of source region
with offset. Otherwise, when source region is an I/O region, reading is
redirected to source region read callback by PAM region one.

The reasons of ram_addr modification for read redirection are:
- QEMU cannot execute code outside RAM or ROM (while BIOS tries exactly that);
- it is faster because of TLB is used.

Redirection is based on address spaces: for PCI and for RAM. QEMU has no ones so
PAM creates private address spaces with root regions that alias to actual PCI
and RAM regions.

The memory commit callbacks are used to keep read source and write destination
address spaces and ram_addr up to date.

Signed-off-by: Efimov Vasily 
---
v2 change:
 - use address spaces for access redirection

Qemu distribution includes SeaBIOS which has hacks to work around incorrect
modes 1 and 2 emulation.

This patch series is tested using modified SeaBIOS. It is forced to use mode 2
for copying its data. BIOS reads a value from memory and immediately writes it
to same address. According to PAM definition, reads are directed to PCI (i.e. to
BIOS ROM) and writes are directed to RAM.

The patch for SeaBIOS is listed below.

Both SeaBIOS versions works with new PAM but the modified one does not work with
old PAM.

==
 Whitespaces are added to prevent attempt to apply SeaBIOS patch to QEMU.
 
 diff --git a/src/fw/shadow.c b/src/fw/shadow.c
 index 4f6..7249aa2 100644
 --- a/src/fw/shadow.c
 +++ b/src/fw/shadow.c
 @@ -26,32 +26,62 @@ static void
 __make_bios_writable_intel(u16 bdf, u32 pam0)
 {
 // Make ram from 0xc-0xf writable
-int clear = 0;
+dprintf(1, "PAM mode 1 test begin\n");
+unsigned *m = (unsigned *) BUILD_ROM_START;
+
+pci_config_writeb(bdf, pam0 + 1, 0x33);
+*m = 0xdeafbeef;
+
+pci_config_writeb(bdf, pam0 + 1, 0x11);
+volatile unsigned t = *m;
+*m = t;
+
+pci_config_writeb(bdf, pam0 + 1, 0x33);
+t = *m;
+
+pci_config_writeb(bdf, pam0 + 1, 0x00);
+unsigned t2 = *m;
+
+dprintf(1, "t = 0x%x, t2 = 0x%x\n", t, t2);
+
+dprintf(1, "PAM mode 1 test end\n");
 int i;
+unsigned *mem, *mem_limit;
 for (i=0; i<6; i++) {
 u32 pam = pam0 + 1 + i;
 int reg = pci_config_readb(bdf, pam);
-if (CONFIG_OPTIONROMS_DEPLOYED && (reg & 0x11) != 0x11) {
-// Need to copy optionroms to work around qemu implementation
-void *mem = (void*)(BUILD_ROM_START + i * 32*1024);
-memcpy((void*)BUILD_BIOS_TMP_ADDR, mem, 32*1024);
+if ((reg & 0x11) != 0x11) {
+mem = (unsigned *)(BUILD_ROM_START + i * 32 * 1024);
+pci_config_writeb(bdf, pam, 0x22);
+mem_limit = mem + 32 * 1024 / sizeof(unsigned);
+
+while (mem < mem_limit) {
+volatile unsigned tmp = *mem;
+*mem = tmp;
+mem++;
+}
 pci_config_writeb(bdf, pam, 0x33);
-memcpy(mem, (void*)BUILD_BIOS_TMP_ADDR, 32*1024);
-clear = 1;
 } else {
 pci_config_writeb(bdf, pam, 0x33);
 }
 }
-if (clear)
-memset((void*)BUILD_BIOS_TMP_ADDR, 0, 32*1024);
 
 // Make ram from 0xf-0x10 writable
 int reg = pci_config_readb(bdf, pam0);
-pci_config_writeb(bdf, pam0, 0x30);
 if (reg & 0x10)
 // Ram already present.
 return;
 
+pci_config_writeb(bdf, pam0, 0x22);
+mem = (unsigned *)BUILD_BIOS_ADDR;
+mem_limit = mem + 32 * 1024 / sizeof(unsigned);
+while (mem < mem_limit) {
+volatile unsigned tmp = *mem;
+*mem = tmp;
+mem++;
+}
+pci_config_writeb(bdf, pam0, 0x33);
+
 // Copy bios.
 extern u8 code32flat_start[], code32flat_end[];
 memcpy(code32flat_start, code32flat_start + BIOS_SRC_OFFSET
 @@ -61,17 +91,6 @@ __make_bios_writable_intel(u16 bdf, u32 pam0)
 static void
 make_bios_writable_intel(u16 bdf, u32 pam0)
 {
-int reg = pci_config_readb(bdf, pam0);
-if (!(reg & 0x10)) {
-// QEMU doesn't fully implement the piix shadow capabilities -
-// if ram isn't backing the bios segment when shadowing is
-// disabled, the code itself wont be in memory.  So, run the
-// code from the high-memory flash location.
-u32 pos = (u32)__make_bios_writ

Re: [Qemu-devel] Accessing guest kernel thread_info struct

[Peter Maydell]

On 20 July 2015 at 11:43, Igor R  wrote:
> I need to access thread_info (linux kernel struct) of the guest from within
> qemu, when the guest is in kernel mode.
> To do this, I read the stack pointer and mask it with ~(stack_size - 1).
> This works with x86 and ARM, but doesn't seem to work with MIPS - the
> pointer points to something that doesn't look like thread_info.
> I get sp as follows: env->active_tc.gpr[29]

MIPS keeps the thread info pointer in a dedicated register.
To get this right for each architecture you need to look
at how the kernel implements current_thread_info().

For instance on ARM:
http://lxr.free-electrons.com/source/arch/arm/include/asm/thread_info.h#L95

   return (struct thread_info *)
   (current_stack_pointer & ~(THREAD_SIZE - 1));

but on MIPS:
http://lxr.free-electrons.com/source/arch/mips/include/asm/thread_info.h#L55
   return __current_thread_info;
where
   register struct thread_info *__current_thread_info __asm__("$28");

x86 doesn't use 'mask the stack pointer' either:
static inline struct thread_info *current_thread_info(void)
{
return (struct thread_info *)(current_top_of_stack() - THREAD_SIZE);
}

where current_top_of_stack() is different for x86_64 and i386
but in both cases is reading a value from a per-CPU kernel variable.

If you're trying to do something the kernel does, it's usually
the case that the kernel has some kind of cross-platform
abstraction, and you can just search the kernel sources to find
out what the actual implementations for each architecture are.

thanks
-- PMM

Re: [Qemu-devel] [RFC] ATAPI-SCSI bridge GSoC project

[Stefan Hajnoczi]

On Sat, Jul 18, 2015 at 09:49:26PM +0300, Alexander Bezzubikov wrote:
> atapi: ATAPI-SCSI bridge device created
>private SCSI bus added to bridge
>ATAPI inquiry command can use a bridge

Multiple items is a clue that this patch should be split up into patches
with smaller logical changes.

That will also allow you to write commit descriptions that give the
rationale for the changes.


pgp38YGWfXOyy.pgp
Description: PGP signature

Re: [Qemu-devel] [PATCH 1/1] virtio-mmio: return the max queue num of virtio-mmio with initial value

[Peter Maydell]

On 16 July 2015 at 19:38, Wei Huang  wrote:
> Recently we found that virtio-console devices consumes lots AArch64 guest
> memory, roughly 1GB with 8 devices. After debugging, it turns out that lots
> of factors contribute to this problem: i) guest PAGE_SIZE=64KB, ii)
> virtio-mmio based devices, and iii) virtio-console device. Here is the
> detailed analysis:
>
> 1. First, during initialization, virtio-mmio driver in guest pokes vq
>size by reading VIRTIO_MMIO_QUEUE_NUM_MAX (see virtio_mmio.c file).
> 2. QEMU returns VIRTQUEUE_MAX_SIZE (1024) to guest VM; And virtio-mmio uses
>it as the default vq size.
> 3. virtio-console driver allocates vring buffers based on this value (see
>add_inbuf() function of virtio_console.c file). Because PAGE_SIZE=64KB,
>~64MB is allocated for each virtio-console vq.
>
> This patch addresses the problem by returning the iniatlized vring size
> when VM queries QEMU about VIRTIO_MMIO_QUEUE_NUM_MAX. This is similar to
> virtio-pci's approach. By doing this, the vq memory consumption is reduced
> substantially.

I don't know if this patch is sensible to apply anyway, but from
this description this really sounds like a guest kernel bug.
QEMU tells the kernel the maximum queue size it can cope with,
and if the guest kernel cares about not using insane amounts of
RAM on queues then it should not blindly use the maximum size
but restrict it itself...

thanks
-- PMM

Re: [Qemu-devel] [RFC] Virt machine memory map

[Alexander Graf]

On 07/20/15 11:41, Peter Maydell wrote:

On 20 July 2015 at 09:55, Pavel Fedin  wrote:

  Hello!

  In our project we work on a very fast paravirtualized network I/O drivers, 
based  on ivshmem. We
successfully got ivshmem working on ARM, however with one hack.
Currently we have:
--- cut ---
 [VIRT_PCIE_MMIO] =  { 0x1000, 0x2eff },
 [VIRT_PCIE_PIO] =   { 0x3eff, 0x0001 },
 [VIRT_PCIE_ECAM] =  { 0x3f00, 0x0100 },
 [VIRT_MEM] ={ 0x4000, 30ULL * 1024 * 1024 * 1024 },
--- cut ---
  And MMIO region is not enough for us because we want to have 1GB mapping for 
PCI device. In order
to make it working, we modify the map as follows:
--- cut ---
 [VIRT_PCIE_MMIO] ={ 0x1000, 0x7eff },
 [VIRT_PCIE_PIO] =   { 0x8eff, 0x0001 },
 [VIRT_PCIE_ECAM] =  { 0x8f00, 0x0100 },
 [VIRT_MEM] = { 0x9000, 30ULL * 1024 * 1024 * 1024 },
--- cut ---
  The question is - how could we upstream this? I believe modifying 32-bit virt 
memory map this way
is not good. Will it be OK to have different memory map for 64-bit virt ?

I think the theory we discussed at the time of putting in the PCIe
device was that if we wanted this we'd add support for the other
PCIe memory window (which would then live at somewhere above 4GB).
Alex, can you remember what the idea was?


Yes, pretty much. It would give us an upper bound to the amount of RAM 
that we're able to support, but at least we would be able to support big 
MMIO regions like for ivshmem.


I'm not really sure where to put it though. Depending on your kernel 
config Linux supports somewhere between 39 and 48 or so bits of phys 
address space. And I'd rather not crawl into the PCI hole rat hole that 
we have on x86 ;).


We could of course also put it just above RAM - but then our device tree 
becomes really dynamic and heavily dependent on -m.




But to be honest I think we weren't expecting anybody to need
1GB of PCI MMIO space unless it was a video card...


Ivshmem was actually the most likely target that I could've thought of 
to require big MMIO regions ;).



Alex

[Qemu-devel] [PATCH] exec.c: Use atomic_rcu_read() to access dispatch in memory_region_section_get_iotlb()

[Peter Maydell]

When accessing the dispatch pointer in an AddressSpace within an RCU
critical section we should always use atomic_rcu_read(). Fix an
access within memory_region_section_get_iotlb() which was incorrectly
doing a direct pointer access.

Signed-off-by: Peter Maydell 
---
I discussed this on IRC with Paolo a while back, and IIRC he said
that although this is a bug it's not one that can currently have
any ill effects, though I forget why (probably because this code
path is TCG only and TCG is single-threaded right now).

 exec.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/exec.c b/exec.c
index 7d60e15..0a4a0c5 100644
--- a/exec.c
+++ b/exec.c
@@ -954,7 +954,10 @@ hwaddr memory_region_section_get_iotlb(CPUState *cpu,
 iotlb |= PHYS_SECTION_ROM;
 }
 } else {
-iotlb = section - section->address_space->dispatch->map.sections;
+AddressSpaceDispatch *d;
+
+d = atomic_rcu_read(§ion->address_space->dispatch);
+iotlb = section - d->map.sections;
 iotlb += xlat;
 }
 
-- 
1.9.1

Re: [Qemu-devel] Accessing guest kernel thread_info struct

[Igor R]

Thanks for the useful info!

(Actually, my approach works as well - it was just endianness issue...)

Re: [Qemu-devel] [POC] colo-proxy in qemu

[zhanghailiang]

On 2015/7/20 18:32, Stefan Hajnoczi wrote:

On Mon, Jul 20, 2015 at 02:42:33PM +0800, Li Zhijian wrote:

We are planning to implement colo-proxy in qemu to cache and compare packets.


I thought there is a kernel module to do that?



Yes, but we decided to re-implement it in userspace (Here is in qemu),
there are mainly two reasons that we made this change. One is the colo-proxy in 
kernel is
narrowly used, which can only be used for COLO FT, besides, we have to modify 
iptables and nftables
to support this capability. IMHO, it is hardly been accepted by the kernel 
community.
The other reason is that the kernel proxy scenario can't been used in all 
situations, for example,
evs + vhost-user + dpdk, it can't work if VM's network packets don't go through 
host's network
stack. (For the new userspace colo proxy scheme, we also can't use it with 
vhost-net,
we have to use virtio-net instead).


Why does the proxy need to be part of the QEMU process?  -netdev socket
or host network stack features allow you to process packets in a
separate process.

Without details on what the proxy does it's hard to discuss this.  What
happens in the non-TCP case?  What happens in the TCP case?

Does the proxy need to perform privileged operations, create sockets,
open files, etc?

The slirp code is not actively developed or used much in production.  It
might be a good idea to audit the code for bugs if you want to use it.



Agreed, besides, it is seemed that slirp is not supporting ipv6, we also
have to supplement it.

Thanks,
zhanghailiang

[Qemu-devel] [PATCH] qcow2: Remove forward declaration of QCowAIOCB

[Kevin Wolf]

This struct doesn't exist any more since commit 3fc48d09 in August 2011,
it's about time to remove its forward declaration.

Signed-off-by: Kevin Wolf 
---
 block/qcow2.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/block/qcow2.h b/block/qcow2.h
index 72e1328..46e1e80 100644
--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -292,8 +292,6 @@ typedef struct BDRVQcowState {
 char *image_backing_format;
 } BDRVQcowState;
 
-struct QCowAIOCB;
-
 typedef struct Qcow2COWRegion {
 /**
  * Offset of the COW region in bytes from the start of the first cluster
-- 
1.8.3.1

Re: [Qemu-devel] [POC] colo-proxy in qemu

[Li Zhijian]

CC Wen Congyang

On 07/20/2015 06:32 PM, Stefan Hajnoczi wrote:

On Mon, Jul 20, 2015 at 02:42:33PM +0800, Li Zhijian wrote:

We are planning to implement colo-proxy in qemu to cache and compare packets.

I thought there is a kernel module to do that?

Why does the proxy need to be part of the QEMU process?  -netdev socket
or host network stack features allow you to process packets in a
separate process.

yes, it used to be a kernel module.
we plan to re-implement a QEMU space colo-proxy by the following reasons:
1. colo-proxy in kernel was based on netfilter, it was
impletmented by add a new nf_ct_ext_id, but this will
touch the existed kernel code and we must re-build the kernel before
we install the colo-proxy modules. For this reason, less people
is like to test colo-proxy and it become harder to post to kenel
2. COLO is the only scene of colo-proxy in kernel
3. colo-proxy in kernel only works on the case where packet will deliver to
kernel tcp/ip stack.

COLO project is mainly including 3 components, COLO-Frame COLO-Block and 
COLO-Proxy.
The first tow components is being post to QEMU, if we integrate proxy 
into QEMU,

it will become convenienter to manage the whole COLO project.
further more, COLO will become easier to configure without depending on 
kernel




Without details on what the proxy does it's hard to discuss this.  What
happens in the non-TCP case?  What happens in the TCP case?

more details will be post soon



Does the proxy need to perform privileged operations, create sockets,
open files, etc?

IMO, we just need to create a new socket like the migration socket to
forward packet between PVM and SVM.

Best regards.
Li Zhijian


The slirp code is not actively developed or used much in production.  It
might be a good idea to audit the code for bugs if you want to use it.

Stefan

[Qemu-devel] [PULL 1/6] ich9: fix skipped vmstate_memhp_state subsection

[Michael S. Tsirkin]

From: Paulo Alcantara 

By declaring another .subsections array for vmstate_tco_io_state made
vmstate_memhp_state not registered anymore. There must be only one
.subsections array for all subsections.

Cc: Michael S. Tsirkin 
Cc: Amit Shah 
Reported-by: Amit Shah 
Signed-off-by: Paulo Alcantara 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Amit Shah 
---
 hw/acpi/ich9.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index 5fb7a87..f04f6dc 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -206,9 +206,6 @@ const VMStateDescription vmstate_ich9_pm = {
 },
 .subsections = (const VMStateDescription*[]) {
 &vmstate_memhp_state,
-NULL
-},
-.subsections = (const VMStateDescription*[]) {
 &vmstate_tco_io_state,
 NULL
 }
-- 
MST

[Qemu-devel] [PULL 0/6] virtio, vhost, pc fixes for 2.4

[Michael S. Tsirkin]

The following changes since commit b4329bf41c86bac8b56cadb097081960cc4839a0:

  Update version for v2.4.0-rc1 release (2015-07-16 20:32:20 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream

for you to fetch changes up to f9d6dbf0bf6e91b8ed896369ab1b7e91e5a1a4df:

  virtio-net: remove virtio queues if the guest doesn't support multiqueue 
(2015-07-20 14:19:42 +0300)


virtio, vhost, pc fixes for 2.4

The only notable thing here is vhost-user multiqueue
revert. We'll work on making it stable in 2.5,
reverting now means we won't have to maintain
bug for bug compability forever.

Signed-off-by: Michael S. Tsirkin 


Chen Hanxiao (1):
  pci_add_capability: remove duplicate comments

Fam Zheng (1):
  virtio-net: Flush incoming queues when DRIVER_OK is being set

Jason Wang (1):
  virtio-net: unbreak any layout

Michael S. Tsirkin (1):
  Revert "vhost-user: add multi queue support"

Paulo Alcantara (1):
  ich9: fix skipped vmstate_memhp_state subsection

Wen Congyang (1):
  virtio-net: remove virtio queues if the guest doesn't support multiqueue

 qapi-schema.json  |   6 +-
 include/hw/virtio/virtio-access.h |   9 +++
 hw/acpi/ich9.c|   3 -
 hw/net/vhost_net.c|   3 +-
 hw/net/virtio-net.c   | 143 +-
 hw/pci/pci.c  |   6 +-
 hw/virtio/vhost-user.c|  11 +--
 net/vhost-user.c  |  37 --
 docs/specs/vhost-user.txt |   5 --
 qemu-options.hx   |   5 +-
 10 files changed, 138 insertions(+), 90 deletions(-)

[Qemu-devel] [PULL 2/6] Revert "vhost-user: add multi queue support"

[Michael S. Tsirkin]

This reverts commit 830d70db692e374b5f4407f96a1ceefdcc97.

The interface isn't fully backwards-compatible, which is bad.
Let's redo this properly after 2.4.

Signed-off-by: Michael S. Tsirkin 
---
 qapi-schema.json  |  6 +-
 hw/net/vhost_net.c|  3 +--
 hw/virtio/vhost-user.c| 11 +--
 net/vhost-user.c  | 37 +
 docs/specs/vhost-user.txt |  5 -
 qemu-options.hx   |  5 ++---
 6 files changed, 18 insertions(+), 49 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index 1285b8c..a0a45f7 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2466,16 +2466,12 @@
 #
 # @vhostforce: #optional vhost on for non-MSIX virtio guests (default: false).
 #
-# @queues: #optional number of queues to be created for multiqueue vhost-user
-#  (default: 1) (Since 2.4)
-#
 # Since 2.1
 ##
 { 'struct': 'NetdevVhostUserOptions',
   'data': {
 'chardev':'str',
-'*vhostforce':'bool',
-'*queues':'uint32' } }
+'*vhostforce':'bool' } }
 
 ##
 # @NetClientOptions
diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c
index 9bd360b..5c1d11f 100644
--- a/hw/net/vhost_net.c
+++ b/hw/net/vhost_net.c
@@ -160,7 +160,6 @@ struct vhost_net *vhost_net_init(VhostNetOptions *options)
 
 net->dev.nvqs = 2;
 net->dev.vqs = net->vqs;
-net->dev.vq_index = net->nc->queue_index;
 
 r = vhost_dev_init(&net->dev, options->opaque,
options->backend_type);
@@ -287,7 +286,7 @@ static void vhost_net_stop_one(struct vhost_net *net,
 for (file.index = 0; file.index < net->dev.nvqs; ++file.index) {
 const VhostOps *vhost_ops = net->dev.vhost_ops;
 int r = vhost_ops->vhost_call(&net->dev, VHOST_RESET_OWNER,
-  &file);
+  NULL);
 assert(r >= 0);
 }
 }
diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
index d6f2163..e7ab829 100644
--- a/hw/virtio/vhost-user.c
+++ b/hw/virtio/vhost-user.c
@@ -210,12 +210,7 @@ static int vhost_user_call(struct vhost_dev *dev, unsigned 
long int request,
 break;
 
 case VHOST_SET_OWNER:
-break;
-
 case VHOST_RESET_OWNER:
-memcpy(&msg.state, arg, sizeof(struct vhost_vring_state));
-msg.state.index += dev->vq_index;
-msg.size = sizeof(m.state);
 break;
 
 case VHOST_SET_MEM_TABLE:
@@ -258,20 +253,17 @@ static int vhost_user_call(struct vhost_dev *dev, 
unsigned long int request,
 case VHOST_SET_VRING_NUM:
 case VHOST_SET_VRING_BASE:
 memcpy(&msg.state, arg, sizeof(struct vhost_vring_state));
-msg.state.index += dev->vq_index;
 msg.size = sizeof(m.state);
 break;
 
 case VHOST_GET_VRING_BASE:
 memcpy(&msg.state, arg, sizeof(struct vhost_vring_state));
-msg.state.index += dev->vq_index;
 msg.size = sizeof(m.state);
 need_reply = 1;
 break;
 
 case VHOST_SET_VRING_ADDR:
 memcpy(&msg.addr, arg, sizeof(struct vhost_vring_addr));
-msg.addr.index += dev->vq_index;
 msg.size = sizeof(m.addr);
 break;
 
@@ -279,7 +271,7 @@ static int vhost_user_call(struct vhost_dev *dev, unsigned 
long int request,
 case VHOST_SET_VRING_CALL:
 case VHOST_SET_VRING_ERR:
 file = arg;
-msg.u64 = (file->index + dev->vq_index) & VHOST_USER_VRING_IDX_MASK;
+msg.u64 = file->index & VHOST_USER_VRING_IDX_MASK;
 msg.size = sizeof(m.u64);
 if (ioeventfd_enabled() && file->fd > 0) {
 fds[fd_num++] = file->fd;
@@ -321,7 +313,6 @@ static int vhost_user_call(struct vhost_dev *dev, unsigned 
long int request,
 error_report("Received bad msg size.");
 return -1;
 }
-msg.state.index -= dev->vq_index;
 memcpy(arg, &msg.state, sizeof(struct vhost_vring_state));
 break;
 default:
diff --git a/net/vhost-user.c b/net/vhost-user.c
index b51bc04..93dcecd 100644
--- a/net/vhost-user.c
+++ b/net/vhost-user.c
@@ -120,39 +120,35 @@ static void net_vhost_user_event(void *opaque, int event)
 case CHR_EVENT_OPENED:
 vhost_user_start(s);
 net_vhost_link_down(s, false);
-error_report("chardev \"%s\" went up", s->nc.info_str);
+error_report("chardev \"%s\" went up", s->chr->label);
 break;
 case CHR_EVENT_CLOSED:
 net_vhost_link_down(s, true);
 vhost_user_stop(s);
-error_report("chardev \"%s\" went down", s->nc.info_str);
+error_report("chardev \"%s\" went down", s->chr->label);
 break;
 }
 }
 
 static int net_vhost_user_init(NetClientState *peer, const char *device,
-   const char *name, CharDriverState *chr,
-   uint32_t queues)
+   const char *name, CharDriverState *c

[Qemu-devel] [PULL 3/6] virtio-net: unbreak any layout

[Michael S. Tsirkin]

From: Jason Wang 

Commit 032a74a1c0fcdd5fd1c69e56126b4c857ee36611
("virtio-net: byteswap virtio-net header") breaks any layout by
requiring out_sg[0].iov_len >= n->guest_hdr_len. Fixing this by
copying header to temporary buffer if swap is needed, and then use
this buffer as part of out_sg.

Fixes 032a74a1c0fcdd5fd1c69e56126b4c857ee36611
("virtio-net: byteswap virtio-net header")
Cc: qemu-sta...@nongnu.org
Cc: c...@fr.ibm.com
Signed-off-by: Jason Wang 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Eric Blake 
---
 include/hw/virtio/virtio-access.h |  9 +
 hw/net/virtio-net.c   | 23 ++-
 2 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/include/hw/virtio/virtio-access.h 
b/include/hw/virtio/virtio-access.h
index cee5dd7..1ec1dfd 100644
--- a/include/hw/virtio/virtio-access.h
+++ b/include/hw/virtio/virtio-access.h
@@ -143,6 +143,15 @@ static inline uint64_t virtio_ldq_p(VirtIODevice *vdev, 
const void *ptr)
 }
 }
 
+static inline bool virtio_needs_swap(VirtIODevice *vdev)
+{
+#ifdef HOST_WORDS_BIGENDIAN
+return virtio_access_is_big_endian(vdev) ? false : true;
+#else
+return virtio_access_is_big_endian(vdev) ? true : false;
+#endif
+}
+
 static inline uint16_t virtio_tswap16(VirtIODevice *vdev, uint16_t s)
 {
 #ifdef HOST_WORDS_BIGENDIAN
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index e3c2db3..9f7e91d 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1142,7 +1142,8 @@ static int32_t virtio_net_flush_tx(VirtIONetQueue *q)
 ssize_t ret, len;
 unsigned int out_num = elem.out_num;
 struct iovec *out_sg = &elem.out_sg[0];
-struct iovec sg[VIRTQUEUE_MAX_SIZE];
+struct iovec sg[VIRTQUEUE_MAX_SIZE], sg2[VIRTQUEUE_MAX_SIZE + 1];
+struct virtio_net_hdr_mrg_rxbuf mhdr;
 
 if (out_num < 1) {
 error_report("virtio-net header not in first element");
@@ -1150,13 +1151,25 @@ static int32_t virtio_net_flush_tx(VirtIONetQueue *q)
 }
 
 if (n->has_vnet_hdr) {
-if (out_sg[0].iov_len < n->guest_hdr_len) {
+if (iov_to_buf(out_sg, out_num, 0, &mhdr, n->guest_hdr_len) <
+n->guest_hdr_len) {
 error_report("virtio-net header incorrect");
 exit(1);
 }
-virtio_net_hdr_swap(vdev, (void *) out_sg[0].iov_base);
+if (virtio_needs_swap(vdev)) {
+virtio_net_hdr_swap(vdev, (void *) &mhdr);
+sg2[0].iov_base = &mhdr;
+sg2[0].iov_len = n->guest_hdr_len;
+out_num = iov_copy(&sg2[1], ARRAY_SIZE(sg2) - 1,
+   out_sg, out_num,
+   n->guest_hdr_len, -1);
+if (out_num == VIRTQUEUE_MAX_SIZE) {
+goto drop;
+   }
+out_num += 1;
+out_sg = sg2;
+   }
 }
-
 /*
  * If host wants to see the guest header as is, we can
  * pass it on unchanged. Otherwise, copy just the parts
@@ -1186,7 +1199,7 @@ static int32_t virtio_net_flush_tx(VirtIONetQueue *q)
 }
 
 len += ret;
-
+drop:
 virtqueue_push(q->tx_vq, &elem, 0);
 virtio_notify(vdev, q->tx_vq);
 
-- 
MST

[Qemu-devel] [PULL 5/6] virtio-net: Flush incoming queues when DRIVER_OK is being set

[Michael S. Tsirkin]

From: Fam Zheng 

This patch fixes network hang after "stop" then "cont", while network
packets keep arriving.

Tested both manually (tap, host pinging guest) and with Jason's qtest
series (plus his "[PATCH 2.4] socket: pass correct size in
net_socket_send()" fix).

As virtio_net_set_status is called when guest driver is setting status
byte and when vm state is changing, it is a good opportunity to flush
queued packets.

This is necessary because during vm stop the backend (e.g. tap) would
stop rx processing after .can_receive returns false, until the queue is
explicitly flushed or purged.

The other interesting condition in .can_receive, virtio_queue_ready(),
is handled by virtio_net_handle_rx() when guest kicks; the 3rd condition
is invalid queue index which doesn't need flushing.

Signed-off-by: Fam Zheng 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/net/virtio-net.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 9f7e91d..e1d9cbf 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -162,6 +162,8 @@ static void virtio_net_set_status(struct VirtIODevice 
*vdev, uint8_t status)
 virtio_net_vhost_status(n, status);
 
 for (i = 0; i < n->max_queues; i++) {
+NetClientState *ncs = qemu_get_subqueue(n->nic, i);
+bool queue_started;
 q = &n->vqs[i];
 
 if ((!n->multiqueue && i != 0) || i >= n->curr_queues) {
@@ -169,12 +171,18 @@ static void virtio_net_set_status(struct VirtIODevice 
*vdev, uint8_t status)
 } else {
 queue_status = status;
 }
+queue_started =
+virtio_net_started(n, queue_status) && !n->vhost_started;
+
+if (queue_started) {
+qemu_flush_queued_packets(ncs);
+}
 
 if (!q->tx_waiting) {
 continue;
 }
 
-if (virtio_net_started(n, queue_status) && !n->vhost_started) {
+if (queue_started) {
 if (q->tx_timer) {
 timer_mod(q->tx_timer,
qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + 
n->tx_timeout);
-- 
MST

[Qemu-devel] [PULL 6/6] virtio-net: remove virtio queues if the guest doesn't support multiqueue

[Michael S. Tsirkin]

From: Wen Congyang 

commit da51a335 adds all queues in .realize(). But if the
guest doesn't support multiqueue, we forget to remove them. And
we cannot handle the ctrl vq corretly. The guest will hang.

Signed-off-by: Wen Congyang 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
Acked-by: Jason Wang 
---
 hw/net/virtio-net.c | 110 +++-
 1 file changed, 82 insertions(+), 28 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index e1d9cbf..304d3dd 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1327,9 +1327,86 @@ static void virtio_net_tx_bh(void *opaque)
 }
 }
 
+static void virtio_net_add_queue(VirtIONet *n, int index)
+{
+VirtIODevice *vdev = VIRTIO_DEVICE(n);
+
+n->vqs[index].rx_vq = virtio_add_queue(vdev, 256, virtio_net_handle_rx);
+if (n->net_conf.tx && !strcmp(n->net_conf.tx, "timer")) {
+n->vqs[index].tx_vq =
+virtio_add_queue(vdev, 256, virtio_net_handle_tx_timer);
+n->vqs[index].tx_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL,
+  virtio_net_tx_timer,
+  &n->vqs[index]);
+} else {
+n->vqs[index].tx_vq =
+virtio_add_queue(vdev, 256, virtio_net_handle_tx_bh);
+n->vqs[index].tx_bh = qemu_bh_new(virtio_net_tx_bh, &n->vqs[index]);
+}
+
+n->vqs[index].tx_waiting = 0;
+n->vqs[index].n = n;
+}
+
+static void virtio_net_del_queue(VirtIONet *n, int index)
+{
+VirtIODevice *vdev = VIRTIO_DEVICE(n);
+VirtIONetQueue *q = &n->vqs[index];
+NetClientState *nc = qemu_get_subqueue(n->nic, index);
+
+qemu_purge_queued_packets(nc);
+
+virtio_del_queue(vdev, index * 2);
+if (q->tx_timer) {
+timer_del(q->tx_timer);
+timer_free(q->tx_timer);
+} else {
+qemu_bh_delete(q->tx_bh);
+}
+virtio_del_queue(vdev, index * 2 + 1);
+}
+
+static void virtio_net_change_num_queues(VirtIONet *n, int new_max_queues)
+{
+VirtIODevice *vdev = VIRTIO_DEVICE(n);
+int old_num_queues = virtio_get_num_queues(vdev);
+int new_num_queues = new_max_queues * 2 + 1;
+int i;
+
+assert(old_num_queues >= 3);
+assert(old_num_queues % 2 == 1);
+
+if (old_num_queues == new_num_queues) {
+return;
+}
+
+/*
+ * We always need to remove and add ctrl vq if
+ * old_num_queues != new_num_queues. Remove ctrl_vq first,
+ * and then we only enter one of the following too loops.
+ */
+virtio_del_queue(vdev, old_num_queues - 1);
+
+for (i = new_num_queues - 1; i < old_num_queues - 1; i += 2) {
+/* new_num_queues < old_num_queues */
+virtio_net_del_queue(n, i / 2);
+}
+
+for (i = old_num_queues - 1; i < new_num_queues - 1; i += 2) {
+/* new_num_queues > old_num_queues */
+virtio_net_add_queue(n, i / 2);
+}
+
+/* add ctrl_vq last */
+n->ctrl_vq = virtio_add_queue(vdev, 64, virtio_net_handle_ctrl);
+}
+
 static void virtio_net_set_multiqueue(VirtIONet *n, int multiqueue)
 {
+int max = multiqueue ? n->max_queues : 1;
+
 n->multiqueue = multiqueue;
+virtio_net_change_num_queues(n, max);
 
 virtio_net_set_queues(n);
 }
@@ -1604,21 +1681,7 @@ static void virtio_net_device_realize(DeviceState *dev, 
Error **errp)
 }
 
 for (i = 0; i < n->max_queues; i++) {
-n->vqs[i].rx_vq = virtio_add_queue(vdev, 256, virtio_net_handle_rx);
-if (n->net_conf.tx && !strcmp(n->net_conf.tx, "timer")) {
-n->vqs[i].tx_vq =
-virtio_add_queue(vdev, 256, virtio_net_handle_tx_timer);
-n->vqs[i].tx_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL,
-  virtio_net_tx_timer,
-  &n->vqs[i]);
-} else {
-n->vqs[i].tx_vq =
-virtio_add_queue(vdev, 256, virtio_net_handle_tx_bh);
-n->vqs[i].tx_bh = qemu_bh_new(virtio_net_tx_bh, &n->vqs[i]);
-}
-
-n->vqs[i].tx_waiting = 0;
-n->vqs[i].n = n;
+virtio_net_add_queue(n, i);
 }
 
 n->ctrl_vq = virtio_add_queue(vdev, 64, virtio_net_handle_ctrl);
@@ -1672,7 +1735,7 @@ static void virtio_net_device_unrealize(DeviceState *dev, 
Error **errp)
 {
 VirtIODevice *vdev = VIRTIO_DEVICE(dev);
 VirtIONet *n = VIRTIO_NET(dev);
-int i;
+int i, max_queues;
 
 /* This will stop vhost backend if appropriate. */
 virtio_net_set_status(vdev, 0);
@@ -1687,18 +1750,9 @@ static void virtio_net_device_unrealize(DeviceState 
*dev, Error **errp)
 g_free(n->mac_table.macs);
 g_free(n->vlans);
 
-for (i = 0; i < n->max_queues; i++) {
-VirtIONetQueue *q = &n->vqs[i];
-NetClientState *nc = qemu_get_subqueue(n->nic, i);
-
-qemu_purge_queued_packets(nc);
-
-if (q->tx_timer) {
-timer_del(q->tx_timer);
-timer_free(q->tx_timer

[Qemu-devel] R: Re: [PATCH v2] AioContext: fix broken placement of event_notifier_test_and_clear

[Paolo Bonzini]

> > I'm looking at optimizing it but I don't fully understand the relationship
> > between aio_prepare and WaitForMultipleObjects. Do they get the same set of
> > events?
> 
> After some reading I think WaitForMultipleObjects is for event notifiers and
> aio_prepare is for select() on fd events.
> It's a bit trickier than aio-posix, in the first iteration there could be
> another event masking ctx->notifier so we don't know if we need to clear it.
> Maybe we can reverse events[] so that ctx->notifier will be the 0th one. And I
> think we can always remove it after first iteration, am I right?

Yes, that would work. I am not sure how complex it would be. You would also need
a solution for the GSource and one (probably similar to aio-posix) for your
epoll implementation. With ctx->notified at least you can encapsulate it in
aio_notify_accept...

Stefan, any preferences?

Paolo

Re: [Qemu-devel] [PATCH v2] raw-posix.c: Make physical devices usable in QEMU under Mac OS X host

[Laurent Vivier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 20/07/2015 12:48, Stefan Hajnoczi wrote:
> On Fri, Jul 17, 2015 at 03:24:34PM -0400, Programmingkid wrote:
>> 
>> On Jul 17, 2015, at 9:41 AM, Stefan Hajnoczi wrote:
>> 
>>> On Thu, Jul 16, 2015 at 04:46:07PM -0400, Programmingkid
>>> wrote:
 @@ -2014,7 +2015,9 @@ kern_return_t GetBSDPath( io_iterator_t
 mediaIterator, char *bsdPath, CFIndex ma if (
 bsdPathAsCFString ) { size_t devPathLength; strcpy( bsdPath,
 _PATH_DEV ); -strcat( bsdPath, "r" ); +
 if (flags & BDRV_O_NOCACHE) { +
 strcat(bsdPath, "r"); +} devPathLength = strlen(
 bsdPath ); if ( CFStringGetCString( bsdPathAsCFString,
 bsdPath + devPathLength, maxPathSize - devPathLength,
 kCFStringEncodingASCII ) ) { kernResult = KERN_SUCCESS;
>>> 
>>> Is this the fix that makes CD-ROM passthrough work for you?
>>> 
>>> Does the guest boot successfully when you do:
>>> 
>>> -drive if=ide,media=cdrom,cache=none,file=/dev/cdrom
>> 
>> The guest fails during the boot process with the above command
>> line.
> 
> That means the issue you originally hit hasn't been solved yet.
> 
> Take a look at s->needs_alignment and raw_probe_alignment().  In
> the -drive cache=none case raw-posix needs to detect the correct
> alignment (probably 2 KB for CD-ROMs).

As raw_open_common() sets needs_alignment to true on BDRV_O_NOCACHE
(cache="none") and raw_probe_alignment() detects alignment if
needs_alignment is true, I don't understand why it doesn't work.

Could you explain ?

Laurent
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlWs7bcACgkQNKT2yavzbFMxIwCcCPYXvcSZTnjp7UVQBUVLAj6K
iY0An2l1ttpVEb9bZP+VEakuU75X/Zd7
=S83F
-END PGP SIGNATURE-

[Qemu-devel] [PULL 4/6] pci_add_capability: remove duplicate comments

[Michael S. Tsirkin]

From: Chen Hanxiao 

Signed-off-by: Chen Hanxiao 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 hw/pci/pci.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 442f822..a017614 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -2101,12 +2101,10 @@ static void pci_del_option_rom(PCIDevice *pdev)
 }
 
 /*
- * if !offset
- * Reserve space and add capability to the linked list in pci config space
- *
  * if offset = 0,
  * Find and reserve space and add capability to the linked list
- * in pci config space */
+ * in pci config space
+ */
 int pci_add_capability(PCIDevice *pdev, uint8_t cap_id,
uint8_t offset, uint8_t size)
 {
-- 
MST

Re: [Qemu-devel] [PATCH for-2.4] timer: rename NSEC_PER_SEC due to Mac OS X header clash

[Peter Maydell]

On 8 July 2015 at 15:10, Stefan Hajnoczi  wrote:
> Commit e0cf11f31c24cfb17f44ed46c254d84c78e7f6e9 ("timer: Use a single
> definition of NSEC_PER_SEC for the whole codebase") renamed
> NANOSECONDS_PER_SECOND to NSEC_PER_SEC.
>
> On Mac OS X there is a  system header which also
> defines NSEC_PER_SEC.  This causes compiler warnings.
>
> Let's use the old name instead.  It's longer but it doesn't clash.
>
> Signed-off-by: Stefan Hajnoczi 

Do you have a plan for putting this into 2.4 or should I just
apply it to master directly?

thanks
-- PMM

Re: [Qemu-devel] [RFC PATCH 2/2] spapr: -kernel: allow linking with specified addr

[Andrew Jones]

On Mon, Jul 20, 2015 at 08:47:53AM +0200, Thomas Huth wrote:
> On 20/07/15 07:01, David Gibson wrote:
> > On Fri, Jul 17, 2015 at 01:56:40PM +0200, Andrew Jones wrote:
> >> I've started playing with adding ppc support to kvm-unit-tests,
> >> using spapr for the machine model. I wanted to link the unit test
> >> at 0x40 to match qemu's load address, making the unit test
> >> startup code simpler, but ended up with 0x80 instead, due to
> >> how translate_kernel_address works. The translation makes sense
> >> for how Linux kernels are linked (always at 0xc000 or
> >> 0xc000), but for the unit test case we need to avoid
> >> adding the offset.
> >>
> >> Signed-off-by: Andrew Jones 
> >> ---
> >> Big RFC because I don't know if the "always at 0xc..." statement
> >> is 100% true for Linux, nor if this patch would break other stuff...
> > 
> > Yeah, I'm pretty dubious about this too, especially since I don't
> > entirely grasp what the load_elf() translation function is all about
> > anyway.
> 
> Well, AFAIK it's used to modify the addresses before the ELF loader uses
> the address for loading. For example if your ELF binary is linked at
> address 0x1000, the translate function would move your binary to
> 0x401000 instead so that it does not interfere with the SLOF firmware
> (which is loaded to address 0 IIRC).

This is correct, but the move isn't just to make sure we don't interfere
with SLOF, it's also to make sure we can load the kernel into main
memory. When the link address is 0xc...,  then we can't use vaddr ==
paddr. The Linux ppc64 kernel, for example, is linked at 0xc000.
So it gets pulled down with the mask, and then the 0x40 offset is added
to get it above SLOF.

> 
> So I also think your fix here is wrong, Andrew. E.g. when you have a
> binary that is linked to address 0x1000, you don't want to bypass the
> translation step here since it then would clash with the firmware.

I set the unit test's text segment start at 0x40, so QEMU still
loads it there with this patch, and thus it wouldn't clash with SLOF.
But, anyway, there's no need for SLOF in kvm-unit-tests, and I've
replaced it with a four byte boot loader, b 0x40.

> 
> > That said, I suspect making your unit test assume a fixed load address
> > may not be the best idea - qemu or SLOF could change in future to move
> > things about, so it might be more robust to have your test copy itself
> > to address it wants to be at before executing.
> 

Well, the reason I want vaddr == paddr is to be able to run C code
without the MMU enabled, not to mention to avoid needing to do any sort
of reloc dance in what's supposed to be super simple code. I don't need
to worry about SLOF changing things, since I don't use it. If QEMU changes
the load address, then things will indeed break, but it would be a one line
Makefile fix in kvm-unit-tests to point the text segment to the new offset.

> +1
> 
> ... or you could try to get the elf_reloc code working for POWER, too
> (see include/hw/elf_ops.h). That way QEMU would take care of relocating
> your program. (you can peek at elf_apply_rela64() in
>  https://github.com/aik/SLOF/blob/master/lib/libelf/elf64.c
> if you want to know what basically has to be done for POWER relocations).
> 
>  Thomas
> 
> 

kvm-unit-tests doesn't load the unit test elf itself. It relies on QEMU's
-kernel parameter to get the "kernel" (the unit test) into memory.

Thanks,
drew

Re: [Qemu-devel] [POC] colo-proxy in qemu

[Vasiliy Tolstov]

2015-07-20 14:55 GMT+03:00 zhanghailiang :
> Agreed, besides, it is seemed that slirp is not supporting ipv6, we also
> have to supplement it.


patch for ipv6 slirp support some times ago sended to qemu list, but i
don't know why in not accepted.

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru

[Qemu-devel] [PATCH] spapr: add dumpdtb support

[Andrew Jones]

dumpdtb (-machine dumpdtb=) allows one to inspect the generated
device tree of machine types that generate device trees. This is
useful for a) seeing what's there b) debugging/testing device tree
generator patches. It can be used as follows

$QEMU_CMDLINE -machine dumpdtb=dtb
dtc -I dtb -O dts dtb

Signed-off-by: Andrew Jones 
---
 hw/ppc/spapr.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index a6f19473cf278..c1cbf3387ae0c 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -30,6 +30,7 @@
 #include "hw/fw-path-provider.h"
 #include "elf.h"
 #include "net/net.h"
+#include "sysemu/device_tree.h"
 #include "sysemu/block-backend.h"
 #include "sysemu/cpus.h"
 #include "sysemu/kvm.h"
@@ -822,6 +823,7 @@ static void spapr_finalize_fdt(sPAPRMachineState *spapr,
 exit(1);
 }
 
+qemu_fdt_dumpdtb(fdt, fdt_totalsize(fdt));
 cpu_physical_memory_write(fdt_addr, fdt, fdt_totalsize(fdt));
 
 g_free(bootlist);
-- 
2.4.3

Re: [Qemu-devel] [RFC PATCH 1/2] spapr: add dumpdtb support

[Andrew Jones]

On Mon, Jul 20, 2015 at 02:02:33PM +1000, David Gibson wrote:
> On Fri, Jul 17, 2015 at 01:56:39PM +0200, Andrew Jones wrote:
> > Signed-off-by: Andrew Jones 
> 
> Looks good to me, but I'd like an actual commit message: what's
> dumpdtb, how and why would you use it.

Ok, just sent it separately with a commit message and the RFC dropped.

Thanks,
drew
> 
> > ---
> >  hw/ppc/spapr.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > index a6f19473cf278..c1cbf3387ae0c 100644
> > --- a/hw/ppc/spapr.c
> > +++ b/hw/ppc/spapr.c
> > @@ -30,6 +30,7 @@
> >  #include "hw/fw-path-provider.h"
> >  #include "elf.h"
> >  #include "net/net.h"
> > +#include "sysemu/device_tree.h"
> >  #include "sysemu/block-backend.h"
> >  #include "sysemu/cpus.h"
> >  #include "sysemu/kvm.h"
> > @@ -822,6 +823,7 @@ static void spapr_finalize_fdt(sPAPRMachineState *spapr,
> >  exit(1);
> >  }
> >  
> > +qemu_fdt_dumpdtb(fdt, fdt_totalsize(fdt));
> >  cpu_physical_memory_write(fdt_addr, fdt, fdt_totalsize(fdt));
> >  
> >  g_free(bootlist);
> 
> -- 
> David Gibson  | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au| minimalist, thank you.  NOT _the_ 
> _other_
>   | _way_ _around_!
> http://www.ozlabs.org/~dgibson

Re: [Qemu-devel] Creating a VM from an E01 file

[Peter Maydell]

On 20 July 2015 at 14:03, Cervellone, Adam  wrote:
> My name is Adam Cervellone. I am a digital evidence intern at the North
> Carolina State Crime Laboratory.  As part of my time here, I am conducting a
> research project using the SIFT workstation to make a virtual machine of an
> E01 file.  I’ve previously used this series of commands to attempt to create
> a VM
>
> 1.Sudo su
>
> o SIFT password entered
>
> 2.Mkdir /mnt/ewf1
>
> 3.Mount_ewf.py  /mnt/ewf1
>
> 4.qemu-img convert /mnt/ewf1/ -O vmdk
> .vmdk
>
> I found these steps on Forensics wiki, however they have not worked.  I may
> have misinterpreted a section of the command and entered it incorrectly.  Do
> you know of the correct way to do this or of someone who may be able to help
> me?

You've said what you were trying to do, but not what actually happened.
"It didn't work" provides no information at all. Did it give an
error message (if so, what?), did it do nothing, did it just hang?
Giving an exact transcript of the commands you typed and the output
might be useful.

Identifying problems with computing has some similarities with
detecting crime -- we need evidence to be able to draw good
conclusions :-)

thanks
-- PMM

Re: [Qemu-devel] [RFC] Virt machine memory map

[Igor Mammedov]

On Mon, 20 Jul 2015 13:23:45 +0200
Alexander Graf  wrote:

> On 07/20/15 11:41, Peter Maydell wrote:
> > On 20 July 2015 at 09:55, Pavel Fedin  wrote:
> >>   Hello!
> >>
> >>   In our project we work on a very fast paravirtualized network I/O 
> >> drivers, based  on ivshmem. We
> >> successfully got ivshmem working on ARM, however with one hack.
> >> Currently we have:
> >> --- cut ---
> >>  [VIRT_PCIE_MMIO] =  { 0x1000, 0x2eff },
> >>  [VIRT_PCIE_PIO] =   { 0x3eff, 0x0001 },
> >>  [VIRT_PCIE_ECAM] =  { 0x3f00, 0x0100 },
> >>  [VIRT_MEM] ={ 0x4000, 30ULL * 1024 * 1024 * 1024 
> >> },
> >> --- cut ---
> >>   And MMIO region is not enough for us because we want to have 1GB mapping 
> >> for PCI device. In order
> >> to make it working, we modify the map as follows:
> >> --- cut ---
> >>  [VIRT_PCIE_MMIO] ={ 0x1000, 0x7eff },
> >>  [VIRT_PCIE_PIO] =   { 0x8eff, 0x0001 },
> >>  [VIRT_PCIE_ECAM] =  { 0x8f00, 0x0100 },
> >>  [VIRT_MEM] = { 0x9000, 30ULL * 1024 * 1024 * 1024 },
> >> --- cut ---
> >>   The question is - how could we upstream this? I believe modifying 32-bit 
> >> virt memory map this way
> >> is not good. Will it be OK to have different memory map for 64-bit virt ?
> > I think the theory we discussed at the time of putting in the PCIe
> > device was that if we wanted this we'd add support for the other
> > PCIe memory window (which would then live at somewhere above 4GB).
> > Alex, can you remember what the idea was?
> 
> Yes, pretty much. It would give us an upper bound to the amount of RAM 
> that we're able to support, but at least we would be able to support big 
> MMIO regions like for ivshmem.
> 
> I'm not really sure where to put it though. Depending on your kernel 
> config Linux supports somewhere between 39 and 48 or so bits of phys 
> address space. And I'd rather not crawl into the PCI hole rat hole that 
> we have on x86 ;).
> 
> We could of course also put it just above RAM - but then our device tree 
> becomes really dynamic and heavily dependent on -m.
on x86 we've made everything that is not mapped to ram/mmio fall down to
PCI address space, see pc_pci_as_mapping_init().

So we don't have explicitly mapped PCI regions anymore there, but
we still thinking in terms of PCI hole/PCI ranges when it comes to ACPI
PCI bus description where one need to specify ranges available for bus
in its _CRS.

> 
> >
> > But to be honest I think we weren't expecting anybody to need
> > 1GB of PCI MMIO space unless it was a video card...
> 
> Ivshmem was actually the most likely target that I could've thought of 
> to require big MMIO regions ;).
> 
> 
> Alex
> 
> 

[Qemu-devel] Creating a VM from an E01 file

[Cervellone, Adam]

To whom it may concern,

My name is Adam Cervellone. I am a digital evidence intern at the North 
Carolina State Crime Laboratory.  As part of my time here, I am conducting a 
research project using the SIFT workstation to make a virtual machine of an E01 
file.  I've previously used this series of commands to attempt to create a VM
1.Sudo su
o SIFT password entered
2.Mkdir /mnt/ewf1
3.Mount_ewf.py  /mnt/ewf1
4.qemu-img convert /mnt/ewf1/ -O vmdk 
.vmdk
I found these steps on Forensics wiki, however they have not worked.  I may 
have misinterpreted a section of the command and entered it incorrectly.  Do 
you know of the correct way to do this or of someone who may be able to help me?

Thank you,
Adam Cervellone

Re: [Qemu-devel] [RFC] Virt machine memory map

[Alexander Graf]

On 07/20/15 15:30, Igor Mammedov wrote:

On Mon, 20 Jul 2015 13:23:45 +0200
Alexander Graf  wrote:


On 07/20/15 11:41, Peter Maydell wrote:

On 20 July 2015 at 09:55, Pavel Fedin  wrote:

   Hello!

   In our project we work on a very fast paravirtualized network I/O drivers, 
based  on ivshmem. We
successfully got ivshmem working on ARM, however with one hack.
Currently we have:
--- cut ---
  [VIRT_PCIE_MMIO] =  { 0x1000, 0x2eff },
  [VIRT_PCIE_PIO] =   { 0x3eff, 0x0001 },
  [VIRT_PCIE_ECAM] =  { 0x3f00, 0x0100 },
  [VIRT_MEM] ={ 0x4000, 30ULL * 1024 * 1024 * 1024 },
--- cut ---
   And MMIO region is not enough for us because we want to have 1GB mapping for 
PCI device. In order
to make it working, we modify the map as follows:
--- cut ---
  [VIRT_PCIE_MMIO] ={ 0x1000, 0x7eff },
  [VIRT_PCIE_PIO] =   { 0x8eff, 0x0001 },
  [VIRT_PCIE_ECAM] =  { 0x8f00, 0x0100 },
  [VIRT_MEM] = { 0x9000, 30ULL * 1024 * 1024 * 1024 },
--- cut ---
   The question is - how could we upstream this? I believe modifying 32-bit 
virt memory map this way
is not good. Will it be OK to have different memory map for 64-bit virt ?

I think the theory we discussed at the time of putting in the PCIe
device was that if we wanted this we'd add support for the other
PCIe memory window (which would then live at somewhere above 4GB).
Alex, can you remember what the idea was?

Yes, pretty much. It would give us an upper bound to the amount of RAM
that we're able to support, but at least we would be able to support big
MMIO regions like for ivshmem.

I'm not really sure where to put it though. Depending on your kernel
config Linux supports somewhere between 39 and 48 or so bits of phys
address space. And I'd rather not crawl into the PCI hole rat hole that
we have on x86 ;).

We could of course also put it just above RAM - but then our device tree
becomes really dynamic and heavily dependent on -m.

on x86 we've made everything that is not mapped to ram/mmio fall down to
PCI address space, see pc_pci_as_mapping_init().

So we don't have explicitly mapped PCI regions anymore there, but
we still thinking in terms of PCI hole/PCI ranges when it comes to ACPI
PCI bus description where one need to specify ranges available for bus
in its _CRS.


Yes, and in the ARM case we pass those in as a region in device tree 
which gets generated from QEMU :).



Alex

Re: [Qemu-devel] [PATCH] spapr: add dumpdtb support

[Alexander Graf]

On 07/20/15 15:19, Andrew Jones wrote:

dumpdtb (-machine dumpdtb=) allows one to inspect the generated
device tree of machine types that generate device trees. This is
useful for a) seeing what's there b) debugging/testing device tree
generator patches. It can be used as follows

$QEMU_CMDLINE -machine dumpdtb=dtb
dtc -I dtb -O dts dtb

Signed-off-by: Andrew Jones 


Glad to see that it's useful for others too :).

Reviewed-by: Alexander Graf 


Alex

[Qemu-devel] [PATCH 2/2] pc-dimm: add vhost slots limit check before commiting to hotplug

[Igor Mammedov]

it allows safely cancel memory hotplug if vhost backend
doesn't support necessary amount of memory slots and prevents
QEMU crashing in vhost due to hitting vhost limit on amount
of supported memory ranges.

Signed-off-by: Igor Mammedov 
---
 hw/mem/pc-dimm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c
index bb04862..901bdbf 100644
--- a/hw/mem/pc-dimm.c
+++ b/hw/mem/pc-dimm.c
@@ -25,6 +25,7 @@
 #include "sysemu/numa.h"
 #include "sysemu/kvm.h"
 #include "trace.h"
+#include "hw/virtio/vhost.h"
 
 typedef struct pc_dimms_capacity {
  uint64_t size;
@@ -95,6 +96,12 @@ void pc_dimm_memory_plug(DeviceState *dev, 
MemoryHotplugState *hpms,
 goto out;
 }
 
+if (!vhost_has_free_slot()) {
+error_setg(&local_err, "a used vhost backend has no free"
+   " memory slots left");
+goto out;
+}
+
 memory_region_add_subregion(&hpms->mr, addr - hpms->base, mr);
 vmstate_register_ram(mr, dev);
 numa_set_mem_node_id(addr, memory_region_size(mr), dimm->node);
-- 
1.8.3.1

[Qemu-devel] [PATCH 0/2] vhost: check if vhost has capacity for hotplugged memory

[Igor Mammedov]

it's defensive patchset which helps to avoid QEMU crashing
at memory hotplug time by checking that vhost has free capacity
for an additional memory slot.

Igor Mammedov (2):
  vhost: add vhost_has_free_slot() interface
  pc-dimm: add vhost slots limit check before commiting to hotplug

 hw/mem/pc-dimm.c  |  7 +++
 hw/virtio/vhost-backend.c | 23 ++-
 hw/virtio/vhost-user.c|  8 +++-
 hw/virtio/vhost.c | 21 +
 include/hw/virtio/vhost-backend.h |  2 ++
 include/hw/virtio/vhost.h |  1 +
 stubs/Makefile.objs   |  1 +
 stubs/vhost.c |  6 ++
 8 files changed, 67 insertions(+), 2 deletions(-)
 create mode 100644 stubs/vhost.c

-- 
1.8.3.1

[Qemu-devel] [PATCH 1/2] vhost: add vhost_has_free_slot() interface

[Igor Mammedov]

it will allow for other parts of QEMU check if it's safe
to map memory region during hotplug/runtime.
That way hotplug path will have a chance to cancel
hotplug operation instead of crashing in vhost_commit().

Signed-off-by: Igor Mammedov 
---
 hw/virtio/vhost-backend.c | 23 ++-
 hw/virtio/vhost-user.c|  8 +++-
 hw/virtio/vhost.c | 21 +
 include/hw/virtio/vhost-backend.h |  2 ++
 include/hw/virtio/vhost.h |  1 +
 stubs/Makefile.objs   |  1 +
 stubs/vhost.c |  6 ++
 7 files changed, 60 insertions(+), 2 deletions(-)
 create mode 100644 stubs/vhost.c

diff --git a/hw/virtio/vhost-backend.c b/hw/virtio/vhost-backend.c
index 4d68a27..46fa707 100644
--- a/hw/virtio/vhost-backend.c
+++ b/hw/virtio/vhost-backend.c
@@ -11,6 +11,7 @@
 #include "hw/virtio/vhost.h"
 #include "hw/virtio/vhost-backend.h"
 #include "qemu/error-report.h"
+#include "linux/vhost.h"
 
 #include 
 
@@ -42,11 +43,31 @@ static int vhost_kernel_cleanup(struct vhost_dev *dev)
 return close(fd);
 }
 
+static int vhost_kernel_memslots_limit(struct vhost_dev *dev)
+{
+int limit;
+int s = offsetof(struct vhost_memory, regions);
+struct vhost_memory *mem = g_malloc0(s);
+
+assert(dev->mem->nregions);
+do {
+s += sizeof mem->regions[0];
+mem = g_realloc(mem, s);
+mem->regions[mem->nregions] = dev->mem->regions[0];
+mem->nregions++;
+} while (vhost_kernel_call(dev, VHOST_SET_MEM_TABLE, mem) != -1);
+limit = mem->nregions - 1 > 0 ? mem->nregions - 1 : 0;
+g_free(mem);
+
+return limit;
+}
+
 static const VhostOps kernel_ops = {
 .backend_type = VHOST_BACKEND_TYPE_KERNEL,
 .vhost_call = vhost_kernel_call,
 .vhost_backend_init = vhost_kernel_init,
-.vhost_backend_cleanup = vhost_kernel_cleanup
+.vhost_backend_cleanup = vhost_kernel_cleanup,
+.vhost_backend_memslots_limit = vhost_kernel_memslots_limit
 };
 
 int vhost_set_backend_type(struct vhost_dev *dev, VhostBackendType 
backend_type)
diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
index d6f2163..0487809 100644
--- a/hw/virtio/vhost-user.c
+++ b/hw/virtio/vhost-user.c
@@ -352,9 +352,15 @@ static int vhost_user_cleanup(struct vhost_dev *dev)
 return 0;
 }
 
+static int vhost_user_memslots_limit(struct vhost_dev *dev)
+{
+return VHOST_MEMORY_MAX_NREGIONS;
+}
+
 const VhostOps user_ops = {
 .backend_type = VHOST_BACKEND_TYPE_USER,
 .vhost_call = vhost_user_call,
 .vhost_backend_init = vhost_user_init,
-.vhost_backend_cleanup = vhost_user_cleanup
+.vhost_backend_cleanup = vhost_user_cleanup,
+.vhost_backend_memslots_limit = vhost_user_memslots_limit
 };
diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index 2712c6f..e964004 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -26,6 +26,18 @@
 
 static struct vhost_log *vhost_log;
 
+static int used_memslots;
+static int memslots_limit = -1;
+
+bool vhost_has_free_slot(void)
+{
+if (memslots_limit >= 0) {
+return memslots_limit > used_memslots;
+}
+
+return true;
+}
+
 static void vhost_dev_sync_region(struct vhost_dev *dev,
   MemoryRegionSection *section,
   uint64_t mfirst, uint64_t mlast,
@@ -457,6 +469,7 @@ static void vhost_set_memory(MemoryListener *listener,
 dev->mem_changed_start_addr = MIN(dev->mem_changed_start_addr, start_addr);
 dev->mem_changed_end_addr = MAX(dev->mem_changed_end_addr, start_addr + 
size - 1);
 dev->memory_changed = true;
+used_memslots = dev->mem->nregions;
 }
 
 static bool vhost_section(MemoryRegionSection *section)
@@ -1119,6 +1132,14 @@ int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice 
*vdev)
 if (r < 0) {
 goto fail_features;
 }
+
+r = hdev->vhost_ops->vhost_backend_memslots_limit(hdev);
+if (memslots_limit > 0) {
+memslots_limit = MIN(memslots_limit, r);
+} else {
+memslots_limit = r;
+}
+
 r = hdev->vhost_ops->vhost_call(hdev, VHOST_SET_MEM_TABLE, hdev->mem);
 if (r < 0) {
 r = -errno;
diff --git a/include/hw/virtio/vhost-backend.h 
b/include/hw/virtio/vhost-backend.h
index e472f29..28b6714 100644
--- a/include/hw/virtio/vhost-backend.h
+++ b/include/hw/virtio/vhost-backend.h
@@ -24,12 +24,14 @@ typedef int (*vhost_call)(struct vhost_dev *dev, unsigned 
long int request,
  void *arg);
 typedef int (*vhost_backend_init)(struct vhost_dev *dev, void *opaque);
 typedef int (*vhost_backend_cleanup)(struct vhost_dev *dev);
+typedef int (*vhost_backend_memslots_limit)(struct vhost_dev *dev);
 
 typedef struct VhostOps {
 VhostBackendType backend_type;
 vhost_call vhost_call;
 vhost_backend_init vhost_backend_init;
 vhost_backend_cleanup vhost_backend_cleanup;
+vhost_backend_memslots_limit vhost_backend_m

[Qemu-devel] [PATCH for-2.5 1/8] s390x: add 2.5 compat s390-ccw-virtio machine

[Cornelia Huck]

Reviewed-by: Jason J. Herne 
Signed-off-by: Cornelia Huck 
---
 hw/s390x/s390-virtio-ccw.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 4c51d1a..708763e 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -289,7 +289,6 @@ static void ccw_machine_2_4_class_init(ObjectClass *oc, 
void *data)
 mc->name = "s390-ccw-virtio-2.4";
 mc->alias = "s390-ccw-virtio";
 mc->desc = "VirtIO-ccw based S390 machine v2.4";
-mc->is_default = 1;
 }
 
 static const TypeInfo ccw_machine_2_4_info = {
@@ -298,10 +297,27 @@ static const TypeInfo ccw_machine_2_4_info = {
 .class_init= ccw_machine_2_4_class_init,
 };
 
+static void ccw_machine_2_5_class_init(ObjectClass *oc, void *data)
+{
+MachineClass *mc = MACHINE_CLASS(oc);
+
+mc->name = "s390-ccw-virtio-2.5";
+mc->alias = "s390-ccw-virtio";
+mc->desc = "VirtIO-ccw based S390 machine v2.5";
+mc->is_default = 1;
+}
+
+static const TypeInfo ccw_machine_2_5_info = {
+.name  = TYPE_S390_CCW_MACHINE "2.5",
+.parent= TYPE_S390_CCW_MACHINE,
+.class_init= ccw_machine_2_5_class_init,
+};
+
 static void ccw_machine_register_types(void)
 {
 type_register_static(&ccw_machine_info);
 type_register_static(&ccw_machine_2_4_info);
+type_register_static(&ccw_machine_2_5_info);
 }
 
 type_init(ccw_machine_register_types)
-- 
2.4.6

[Qemu-devel] [PATCH for-2.5 5/8] s390x: Dump-skeys hmp support

[Cornelia Huck]

From: "Jason J. Herne" 

Add dump-skeys command to the human monitor.

Reviewed-by: Thomas Huth 
Reviewed-by: David Hildenbrand 
Signed-off-by: Jason J. Herne 
Signed-off-by: Cornelia Huck 
---
 hmp-commands.hx | 16 
 hw/s390x/s390-skeys.c   | 12 
 include/hw/s390x/storage-keys.h |  2 ++
 monitor.c   |  4 
 4 files changed, 34 insertions(+)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index d3b7932..803ff91 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1053,6 +1053,22 @@ gdb. Without -z|-l|-s, the dump format is ELF.
 together with begin.
 ETEXI
 
+#if defined(TARGET_S390X)
+{
+.name   = "dump-skeys",
+.args_type  = "filename:F",
+.params = "",
+.help   = "Save guest storage keys into file 'filename'.\n",
+.mhandler.cmd = hmp_dump_skeys,
+},
+#endif
+
+STEXI
+@item dump-skeys @var{filename}
+@findex dump-skeys
+Save guest storage keys to a file.
+ETEXI
+
 {
 .name   = "snapshot_blkdev",
 .args_type  = "reuse:-n,device:B,snapshot-file:s?,format:s?",
diff --git a/hw/s390x/s390-skeys.c b/hw/s390x/s390-skeys.c
index a7b7a01..5e2948d 100644
--- a/hw/s390x/s390-skeys.c
+++ b/hw/s390x/s390-skeys.c
@@ -66,6 +66,18 @@ static void write_keys(FILE *f, uint8_t *keys, uint64_t 
startgfn,
 }
 }
 
+void hmp_dump_skeys(Monitor *mon, const QDict *qdict)
+{
+const char *filename = qdict_get_str(qdict, "filename");
+Error *err = NULL;
+
+qmp_dump_skeys(filename, &err);
+if (err) {
+monitor_printf(mon, "%s\n", error_get_pretty(err));
+error_free(err);
+}
+}
+
 void qmp_dump_skeys(const char *filename, Error **errp)
 {
 S390SKeysState *ss = s390_get_skeys_device();
diff --git a/include/hw/s390x/storage-keys.h b/include/hw/s390x/storage-keys.h
index cfd7da7..0d04f19 100644
--- a/include/hw/s390x/storage-keys.h
+++ b/include/hw/s390x/storage-keys.h
@@ -13,6 +13,7 @@
 #define __S390_STORAGE_KEYS_H
 
 #include 
+#include "monitor/monitor.h"
 
 #define TYPE_S390_SKEYS "s390-skeys"
 #define S390_SKEYS(obj) \
@@ -52,4 +53,5 @@ void s390_skeys_init(void);
 
 S390SKeysState *s390_get_skeys_device(void);
 
+void hmp_dump_skeys(Monitor *mon, const QDict *qdict);
 #endif /* __S390_STORAGE_KEYS_H */
diff --git a/monitor.c b/monitor.c
index f1501cd..cfe31a4 100644
--- a/monitor.c
+++ b/monitor.c
@@ -82,6 +82,10 @@
 #endif
 #include "hw/lm32/lm32_pic.h"
 
+#if defined(TARGET_S390X)
+#include "hw/s390x/storage-keys.h"
+#endif
+
 /*
  * Supported types:
  *
-- 
2.4.6

[Qemu-devel] [PATCH for-2.5 0/8] s390x: storage key migration

[Cornelia Huck]

Here's the first batch of s390x patches I plan to send for 2.5.

This one deals with storage keys, which may be set by guests and
lacked a proper resting place so far. Introducing a device (that
is backed by the KVM_S390_{SET,GET}_SKEYS ioctls in the kvm case)
allows us to migrate them properly.

Also available as a branch on

git://github.com/cohuck/qemu s390-skey

Cornelia Huck (1):
  s390x: add 2.5 compat s390-ccw-virtio machine

Jason J. Herne (7):
  s390x: Create QOM device for s390 storage keys
  s390x: Enable new s390-storage-keys device
  s390x: Dump storage keys qmp command
  s390x: Dump-skeys hmp support
  s390x: Info skeys sub-command
  s390x: Migrate guest storage keys (initial memory only)
  s390x: Disable storage key migration on old machine type

 MAINTAINERS |   1 +
 hmp-commands.hx |  18 ++
 hw/s390x/Makefile.objs  |   2 +
 hw/s390x/s390-skeys-kvm.c   |  75 
 hw/s390x/s390-skeys.c   | 402 
 hw/s390x/s390-virtio-ccw.c  |  38 +++-
 hw/s390x/s390-virtio.c  |  11 +-
 hw/s390x/s390-virtio.h  |   2 +-
 include/hw/s390x/storage-keys.h |  60 ++
 monitor.c   |  20 ++
 qapi-schema.json|  13 ++
 qmp-commands.hx |  25 +++
 target-s390x/cpu.h  |   2 -
 target-s390x/mem_helper.c   |  46 -
 target-s390x/mmu_helper.c   |  28 ++-
 trace-events|   4 +
 16 files changed, 722 insertions(+), 25 deletions(-)
 create mode 100644 hw/s390x/s390-skeys-kvm.c
 create mode 100644 hw/s390x/s390-skeys.c
 create mode 100644 include/hw/s390x/storage-keys.h

-- 
2.4.6

[Qemu-devel] [PATCH for-2.5 3/8] s390x: Enable new s390-storage-keys device

[Cornelia Huck]

From: "Jason J. Herne" 

s390 guest initialization is modified to make use of new s390-storage-keys
device. Old code that globally allocated storage key array is removed.
The new device enables storage key access for kvm guests.

Cache storage key QOM objects in frequently used helper functions to avoid a
performance hit every time we use one of these functions.

Reviewed-by: Cornelia Huck 
Reviewed-by: Thomas Huth 
Reviewed-by: David Hildenbrand 
Signed-off-by: Jason J. Herne 
Signed-off-by: Cornelia Huck 
---
 hw/s390x/s390-virtio-ccw.c |  8 
 hw/s390x/s390-virtio.c | 11 +--
 hw/s390x/s390-virtio.h |  2 +-
 target-s390x/cpu.h |  2 --
 target-s390x/mem_helper.c  | 46 --
 target-s390x/mmu_helper.c  | 28 +++-
 trace-events   |  4 
 7 files changed, 77 insertions(+), 24 deletions(-)

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 708763e..8f1b1fc 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -19,6 +19,7 @@
 #include "virtio-ccw.h"
 #include "qemu/config-file.h"
 #include "s390-pci-bus.h"
+#include "hw/s390x/storage-keys.h"
 
 #define TYPE_S390_CCW_MACHINE   "s390-ccw-machine"
 
@@ -105,7 +106,6 @@ static void ccw_init(MachineState *machine)
 MemoryRegion *sysmem = get_system_memory();
 MemoryRegion *ram = g_new(MemoryRegion, 1);
 sclpMemoryHotplugDev *mhd = init_sclp_memory_hotplug_dev();
-uint8_t *storage_keys;
 int ret;
 VirtualCssBus *css_bus;
 DeviceState *dev;
@@ -179,11 +179,11 @@ static void ccw_init(MachineState *machine)
 mhd->standby_mem_size = standby_mem_size;
 }
 
-/* allocate storage keys */
-storage_keys = g_malloc0(my_ram_size / TARGET_PAGE_SIZE);
+/* Initialize storage key device */
+s390_skeys_init();
 
 /* init CPUs */
-s390_init_cpus(machine->cpu_model, storage_keys);
+s390_init_cpus(machine->cpu_model);
 
 if (kvm_enabled()) {
 kvm_s390_enable_css_support(s390_cpu_addr2state(0));
diff --git a/hw/s390x/s390-virtio.c b/hw/s390x/s390-virtio.c
index 1284e77..6cc6b5d 100644
--- a/hw/s390x/s390-virtio.c
+++ b/hw/s390x/s390-virtio.c
@@ -38,6 +38,7 @@
 #include "hw/s390x/sclp.h"
 #include "hw/s390x/s390_flic.h"
 #include "hw/s390x/s390-virtio.h"
+#include "hw/s390x/storage-keys.h"
 #include "cpu.h"
 
 //#define DEBUG_S390
@@ -164,7 +165,7 @@ void s390_init_ipl_dev(const char *kernel_filename,
 qdev_init_nofail(dev);
 }
 
-void s390_init_cpus(const char *cpu_model, uint8_t *storage_keys)
+void s390_init_cpus(const char *cpu_model)
 {
 int i;
 
@@ -184,7 +185,6 @@ void s390_init_cpus(const char *cpu_model, uint8_t 
*storage_keys)
 ipi_states[i] = cpu;
 cs->halted = 1;
 cs->exception_index = EXCP_HLT;
-cpu->env.storage_keys = storage_keys;
 }
 }
 
@@ -264,7 +264,6 @@ static void s390_init(MachineState *machine)
 MemoryRegion *sysmem = get_system_memory();
 MemoryRegion *ram = g_new(MemoryRegion, 1);
 int increment_size = 20;
-uint8_t *storage_keys;
 void *virtio_region;
 hwaddr virtio_region_len;
 hwaddr virtio_region_start;
@@ -306,11 +305,11 @@ static void s390_init(MachineState *machine)
 cpu_physical_memory_unmap(virtio_region, virtio_region_len, 1,
   virtio_region_len);
 
-/* allocate storage keys */
-storage_keys = g_malloc0(my_ram_size / TARGET_PAGE_SIZE);
+/* Initialize storage key device */
+s390_skeys_init();
 
 /* init CPUs */
-s390_init_cpus(machine->cpu_model, storage_keys);
+s390_init_cpus(machine->cpu_model);
 
 /* Create VirtIO network adapters */
 s390_create_virtio_net((BusState *)s390_bus, "virtio-net-s390");
diff --git a/hw/s390x/s390-virtio.h b/hw/s390x/s390-virtio.h
index c847853..cf68796 100644
--- a/hw/s390x/s390-virtio.h
+++ b/hw/s390x/s390-virtio.h
@@ -19,7 +19,7 @@
 typedef int (*s390_virtio_fn)(const uint64_t *args);
 void s390_register_virtio_hypercall(uint64_t code, s390_virtio_fn fn);
 
-void s390_init_cpus(const char *cpu_model, uint8_t *storage_keys);
+void s390_init_cpus(const char *cpu_model);
 void s390_init_ipl_dev(const char *kernel_filename,
const char *kernel_cmdline,
const char *initrd_filename,
diff --git a/target-s390x/cpu.h b/target-s390x/cpu.h
index 63aebf4..b650890 100644
--- a/target-s390x/cpu.h
+++ b/target-s390x/cpu.h
@@ -143,8 +143,6 @@ typedef struct CPUS390XState {
 uint32_t cpu_num;
 uint32_t machine_type;
 
-uint8_t *storage_keys;
-
 uint64_t tod_offset;
 uint64_t tod_basetime;
 QEMUTimer *tod_timer;
diff --git a/target-s390x/mem_helper.c b/target-s390x/mem_helper.c
index 6f8bd79..84bf198 100644
--- a/target-s390x/mem_helper.c
+++ b/target-s390x/mem_helper.c
@@ -21,6 +21,7 @@
 #include "cpu.h"
 #include "exec/helper-proto.h"
 #include "exec/cpu_ldst.h"
+#include "hw/s390x/sto

[Qemu-devel] [PATCH for-2.5 2/8] s390x: Create QOM device for s390 storage keys

[Cornelia Huck]

From: "Jason J. Herne" 

A new QOM style device is provided to back guest storage keys. A special
version for KVM is created, which handles the storage key access via
KVM_S390_GET_SKEYS and KVM_S390_SET_SKEYS ioctl.

Reviewed-by: David Hildenbrand 
Signed-off-by: Jason J. Herne 
Signed-off-by: Cornelia Huck 
---
 MAINTAINERS |   1 +
 hw/s390x/Makefile.objs  |   2 +
 hw/s390x/s390-skeys-kvm.c   |  75 +
 hw/s390x/s390-skeys.c   | 141 
 include/hw/s390x/storage-keys.h |  55 
 5 files changed, 274 insertions(+)
 create mode 100644 hw/s390x/s390-skeys-kvm.c
 create mode 100644 hw/s390x/s390-skeys.c
 create mode 100644 include/hw/s390x/storage-keys.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 978b717..1387537 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -560,6 +560,7 @@ F: hw/s390x/css.[hc]
 F: hw/s390x/sclp*.[hc]
 F: hw/s390x/ipl*.[hc]
 F: hw/s390x/*pci*.[hc]
+F: hw/s390x/s390-skeys*.c
 F: include/hw/s390x/
 F: pc-bios/s390-ccw/
 T: git git://github.com/cohuck/qemu virtio-ccw-upstr
diff --git a/hw/s390x/Makefile.objs b/hw/s390x/Makefile.objs
index 27cd75a..527d754 100644
--- a/hw/s390x/Makefile.objs
+++ b/hw/s390x/Makefile.objs
@@ -9,3 +9,5 @@ obj-y += css.o
 obj-y += s390-virtio-ccw.o
 obj-y += virtio-ccw.o
 obj-y += s390-pci-bus.o s390-pci-inst.o
+obj-y += s390-skeys.o
+obj-$(CONFIG_KVM) += s390-skeys-kvm.o
diff --git a/hw/s390x/s390-skeys-kvm.c b/hw/s390x/s390-skeys-kvm.c
new file mode 100644
index 000..682949a
--- /dev/null
+++ b/hw/s390x/s390-skeys-kvm.c
@@ -0,0 +1,75 @@
+/*
+ * s390 storage key device
+ *
+ * Copyright 2015 IBM Corp.
+ * Author(s): Jason J. Herne 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or (at
+ * your option) any later version. See the COPYING file in the top-level
+ * directory.
+ */
+
+#include "hw/s390x/storage-keys.h"
+#include "sysemu/kvm.h"
+#include "qemu/error-report.h"
+
+static int kvm_s390_skeys_enabled(S390SKeysState *ss)
+{
+S390SKeysClass *skeyclass = S390_SKEYS_GET_CLASS(ss);
+uint8_t single_key;
+int r;
+
+r = skeyclass->get_skeys(ss, 0, 1, &single_key);
+if (r != 0 && r != KVM_S390_GET_SKEYS_NONE) {
+error_report("S390_GET_KEYS error %d\n", r);
+}
+return (r == 0);
+}
+
+static int kvm_s390_skeys_get(S390SKeysState *ss, uint64_t start_gfn,
+  uint64_t count, uint8_t *keys)
+{
+struct kvm_s390_skeys args = {
+.start_gfn = start_gfn,
+.count = count,
+.skeydata_addr = (__u64)keys
+};
+
+return kvm_vm_ioctl(kvm_state, KVM_S390_GET_SKEYS, &args);
+}
+
+static int kvm_s390_skeys_set(S390SKeysState *ss, uint64_t start_gfn,
+  uint64_t count, uint8_t *keys)
+{
+struct kvm_s390_skeys args = {
+.start_gfn = start_gfn,
+.count = count,
+.skeydata_addr = (__u64)keys
+};
+
+return kvm_vm_ioctl(kvm_state, KVM_S390_SET_SKEYS, &args);
+}
+
+static void kvm_s390_skeys_class_init(ObjectClass *oc, void *data)
+{
+S390SKeysClass *skeyclass = S390_SKEYS_CLASS(oc);
+
+skeyclass->skeys_enabled = kvm_s390_skeys_enabled;
+skeyclass->get_skeys = kvm_s390_skeys_get;
+skeyclass->set_skeys = kvm_s390_skeys_set;
+}
+
+static const TypeInfo kvm_s390_skeys_info = {
+.name  = TYPE_KVM_S390_SKEYS,
+.parent= TYPE_S390_SKEYS,
+.instance_size = sizeof(S390SKeysState),
+.class_init= kvm_s390_skeys_class_init,
+.class_size= sizeof(S390SKeysClass),
+};
+
+static void kvm_s390_skeys_register_types(void)
+{
+type_register_static(&kvm_s390_skeys_info);
+}
+
+type_init(kvm_s390_skeys_register_types)
diff --git a/hw/s390x/s390-skeys.c b/hw/s390x/s390-skeys.c
new file mode 100644
index 000..77c42ff
--- /dev/null
+++ b/hw/s390x/s390-skeys.c
@@ -0,0 +1,141 @@
+/*
+ * s390 storage key device
+ *
+ * Copyright 2015 IBM Corp.
+ * Author(s): Jason J. Herne 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or (at
+ * your option) any later version. See the COPYING file in the top-level
+ * directory.
+ */
+
+#include "hw/boards.h"
+#include "hw/s390x/storage-keys.h"
+#include "qemu/error-report.h"
+
+S390SKeysState *s390_get_skeys_device(void)
+{
+S390SKeysState *ss;
+
+ss = S390_SKEYS(object_resolve_path_type("", TYPE_S390_SKEYS, NULL));
+assert(ss);
+return ss;
+}
+
+void s390_skeys_init(void)
+{
+Object *obj;
+
+if (kvm_enabled()) {
+obj = object_new(TYPE_KVM_S390_SKEYS);
+} else {
+obj = object_new(TYPE_QEMU_S390_SKEYS);
+}
+object_property_add_child(qdev_get_machine(), TYPE_S390_SKEYS,
+  obj, NULL);
+object_unref(obj);
+
+qdev_init_nofail(DEVICE(obj));
+}
+
+static void qemu_s390_skeys_init(Object *obj)
+{
+QEMUS390SKeysState *skeys = QEMU_S390_SKEYS(obj);
+MachineState *machine = MACHINE(qdev_get_machine());
+
+sk

[Qemu-devel] [PATCH for-2.5 7/8] s390x: Migrate guest storage keys (initial memory only)

[Cornelia Huck]

From: "Jason J. Herne" 

Routines to save/load guest storage keys are provided. register_savevm is
called to register them as migration handlers.

We prepare the protocol to support more complex parameters. So we will
later be able to support standby memory (having empty holes), compression
and "state live migration" like done for ram.

Reviewed-by: David Hildenbrand 
Signed-off-by: Jason J. Herne 
Signed-off-by: Cornelia Huck 
---
 hw/s390x/s390-skeys.c | 113 ++
 1 file changed, 113 insertions(+)

diff --git a/hw/s390x/s390-skeys.c b/hw/s390x/s390-skeys.c
index d355c8f..a927c98 100644
--- a/hw/s390x/s390-skeys.c
+++ b/hw/s390x/s390-skeys.c
@@ -11,10 +11,13 @@
 
 #include "hw/boards.h"
 #include "qmp-commands.h"
+#include "migration/qemu-file.h"
 #include "hw/s390x/storage-keys.h"
 #include "qemu/error-report.h"
 
 #define S390_SKEYS_BUFFER_SIZE 131072  /* Room for 128k storage keys */
+#define S390_SKEYS_SAVE_FLAG_EOS 0x01
+#define S390_SKEYS_SAVE_FLAG_SKEYS 0x02
 
 S390SKeysState *s390_get_skeys_device(void)
 {
@@ -241,6 +244,115 @@ static const TypeInfo qemu_s390_skeys_info = {
 .instance_size = sizeof(S390SKeysClass),
 };
 
+static void s390_storage_keys_save(QEMUFile *f, void *opaque)
+{
+S390SKeysState *ss = S390_SKEYS(opaque);
+S390SKeysClass *skeyclass = S390_SKEYS_GET_CLASS(ss);
+const uint64_t total_count = ram_size / TARGET_PAGE_SIZE;
+uint64_t cur_count, handled_count = 0;
+vaddr cur_gfn = 0;
+uint8_t *buf;
+int ret;
+
+if (!skeyclass->skeys_enabled(ss)) {
+goto end_stream;
+}
+
+buf = g_try_malloc(S390_SKEYS_BUFFER_SIZE);
+if (!buf) {
+error_report("storage key save could not allocate memory\n");
+goto end_stream;
+}
+
+/* We only support initital memory. Standby memory is not handled yet. */
+qemu_put_be64(f, (cur_gfn * TARGET_PAGE_SIZE) |
+ S390_SKEYS_SAVE_FLAG_SKEYS);
+qemu_put_be64(f, total_count);
+
+while (handled_count < total_count) {
+cur_count = MIN(total_count - handled_count, S390_SKEYS_BUFFER_SIZE);
+
+ret = skeyclass->get_skeys(ss, cur_gfn, cur_count, buf);
+if (ret < 0) {
+error_report("S390_GET_KEYS error %d\n", ret);
+break;
+}
+
+/* write keys to stream */
+qemu_put_buffer(f, buf, cur_count);
+
+cur_gfn += cur_count;
+handled_count += cur_count;
+}
+
+g_free(buf);
+end_stream:
+qemu_put_be64(f, S390_SKEYS_SAVE_FLAG_EOS);
+}
+
+static int s390_storage_keys_load(QEMUFile *f, void *opaque, int version_id)
+{
+S390SKeysState *ss = S390_SKEYS(opaque);
+S390SKeysClass *skeyclass = S390_SKEYS_GET_CLASS(ss);
+int ret = 0;
+
+while (!ret) {
+ram_addr_t addr;
+int flags;
+
+addr = qemu_get_be64(f);
+flags = addr & ~TARGET_PAGE_MASK;
+addr &= TARGET_PAGE_MASK;
+
+switch (flags) {
+case S390_SKEYS_SAVE_FLAG_SKEYS: {
+const uint64_t total_count = qemu_get_be64(f);
+uint64_t handled_count = 0, cur_count;
+uint64_t cur_gfn = addr / TARGET_PAGE_SIZE;
+uint8_t *buf = g_try_malloc(S390_SKEYS_BUFFER_SIZE);
+
+if (!buf) {
+error_report("storage key load could not allocate memory\n");
+ret = -ENOMEM;
+break;
+}
+
+while (handled_count < total_count) {
+cur_count = MIN(total_count - handled_count,
+S390_SKEYS_BUFFER_SIZE);
+qemu_get_buffer(f, buf, cur_count);
+
+ret = skeyclass->set_skeys(ss, cur_gfn, cur_count, buf);
+if (ret < 0) {
+error_report("S390_SET_KEYS error %d\n", ret);
+break;
+}
+handled_count += cur_count;
+cur_gfn += cur_count;
+}
+g_free(buf);
+break;
+}
+case S390_SKEYS_SAVE_FLAG_EOS:
+/* normal exit */
+return 0;
+default:
+error_report("Unexpected storage key flag data: %#x", flags);
+ret = -EINVAL;
+}
+}
+
+return ret;
+}
+
+static void s390_skeys_instance_init(Object *obj)
+{
+S390SKeysState *ss = S390_SKEYS(obj);
+
+register_savevm(NULL, TYPE_S390_SKEYS, 0, 1, s390_storage_keys_save,
+s390_storage_keys_load, ss);
+}
+
 static void s390_skeys_class_init(ObjectClass *oc, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(oc);
@@ -252,6 +364,7 @@ static void s390_skeys_class_init(ObjectClass *oc, void 
*data)
 static const TypeInfo s390_skeys_info = {
 .name  = TYPE_S390_SKEYS,
 .parent= TYPE_DEVICE,
+.instance_init = s390_skeys_instance_init,
 .instance_size = sizeof(S390SKeysState),
 .class_init= s390_skeys_class_init,
 .class_size= sizeof(S390S

[Qemu-devel] [PATCH for-2.5 6/8] s390x: Info skeys sub-command

[Cornelia Huck]

From: "Jason J. Herne" 

Provide an  info skeys hmp sub-command to allow the end user to dump a storage
key for a given address. This is useful for guest operating system developers.

Reviewed-by: Thomas Huth 
Reviewed-by: David Hildenbrand 
Signed-off-by: Jason J. Herne 
Signed-off-by: Cornelia Huck 
---
 hmp-commands.hx |  2 ++
 hw/s390x/s390-skeys.c   | 23 +++
 include/hw/s390x/storage-keys.h |  2 ++
 monitor.c   |  9 +
 4 files changed, 36 insertions(+)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index 803ff91..c61468e 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1806,6 +1806,8 @@ show roms
 show the TPM device
 @item info memory-devices
 show the memory devices
+@item info skeys
+Display the value of a storage key (s390 only)
 @end table
 ETEXI
 
diff --git a/hw/s390x/s390-skeys.c b/hw/s390x/s390-skeys.c
index 5e2948d..d355c8f 100644
--- a/hw/s390x/s390-skeys.c
+++ b/hw/s390x/s390-skeys.c
@@ -66,6 +66,29 @@ static void write_keys(FILE *f, uint8_t *keys, uint64_t 
startgfn,
 }
 }
 
+void hmp_info_skeys(Monitor *mon, const QDict *qdict)
+{
+S390SKeysState *ss = s390_get_skeys_device();
+S390SKeysClass *skeyclass = S390_SKEYS_GET_CLASS(ss);
+uint64_t addr = qdict_get_int(qdict, "addr");
+uint8_t key;
+int r;
+
+/* Quick check to see if guest is using storage keys*/
+if (!skeyclass->skeys_enabled(ss)) {
+monitor_printf(mon, "Error: This guest is not using storage keys.\n");
+return;
+}
+
+r = skeyclass->get_skeys(ss, addr / TARGET_PAGE_SIZE, 1, &key);
+if (r < 0) {
+monitor_printf(mon, "Error: %s\n", strerror(-r));
+return;
+}
+
+monitor_printf(mon, "  key: 0x%X\n", key);
+}
+
 void hmp_dump_skeys(Monitor *mon, const QDict *qdict)
 {
 const char *filename = qdict_get_str(qdict, "filename");
diff --git a/include/hw/s390x/storage-keys.h b/include/hw/s390x/storage-keys.h
index 0d04f19..18e08d2 100644
--- a/include/hw/s390x/storage-keys.h
+++ b/include/hw/s390x/storage-keys.h
@@ -54,4 +54,6 @@ void s390_skeys_init(void);
 S390SKeysState *s390_get_skeys_device(void);
 
 void hmp_dump_skeys(Monitor *mon, const QDict *qdict);
+void hmp_info_skeys(Monitor *mon, const QDict *qdict);
+
 #endif /* __S390_STORAGE_KEYS_H */
diff --git a/monitor.c b/monitor.c
index cfe31a4..d2153fa 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2881,6 +2881,15 @@ static mon_cmd_t info_cmds[] = {
 .help   = "Show rocker OF-DPA groups",
 .mhandler.cmd = hmp_rocker_of_dpa_groups,
 },
+#if defined(TARGET_S390X)
+{
+.name   = "skeys",
+.args_type  = "addr:l",
+.params = "address",
+.help   = "Display the value of a storage key",
+.mhandler.cmd = hmp_info_skeys,
+},
+#endif
 {
 .name   = NULL,
 },
-- 
2.4.6

[Qemu-devel] [PATCH for-2.5 4/8] s390x: Dump storage keys qmp command

[Cornelia Huck]

From: "Jason J. Herne" 

Provide a dump-skeys qmp command to allow the end user to dump storage
keys. This is useful for debugging problems with guest storage key support
within Qemu and for guest operating system developers.

Reviewed-by: Thomas Huth 
Reviewed-by: David Hildenbrand 
Signed-off-by: Jason J. Herne 
Signed-off-by: Cornelia Huck 
---
 hw/s390x/s390-skeys.c | 91 +++
 monitor.c |  7 
 qapi-schema.json  | 13 
 qmp-commands.hx   | 25 ++
 4 files changed, 136 insertions(+)

diff --git a/hw/s390x/s390-skeys.c b/hw/s390x/s390-skeys.c
index 77c42ff..a7b7a01 100644
--- a/hw/s390x/s390-skeys.c
+++ b/hw/s390x/s390-skeys.c
@@ -10,9 +10,12 @@
  */
 
 #include "hw/boards.h"
+#include "qmp-commands.h"
 #include "hw/s390x/storage-keys.h"
 #include "qemu/error-report.h"
 
+#define S390_SKEYS_BUFFER_SIZE 131072  /* Room for 128k storage keys */
+
 S390SKeysState *s390_get_skeys_device(void)
 {
 S390SKeysState *ss;
@@ -38,6 +41,94 @@ void s390_skeys_init(void)
 qdev_init_nofail(DEVICE(obj));
 }
 
+static void write_keys(FILE *f, uint8_t *keys, uint64_t startgfn,
+   uint64_t count, Error **errp)
+{
+uint64_t curpage = startgfn;
+uint64_t maxpage = curpage + count - 1;
+int r;
+
+for (; curpage <= maxpage; curpage++) {
+uint8_t acc = (*keys & 0xF0) >> 4;
+int fp =  (*keys & 0x08);
+int ref = (*keys & 0x04);
+int ch = (*keys & 0x02);
+int reserved = (*keys & 0x01);
+
+r = fprintf(f, "page=%03" PRIx64 ": key(%d) => ACC=%X, FP=%d, REF=%d,"
+   " ch=%d, reserved=%d\n", curpage, *keys, acc, fp, ref,
+   ch, reserved);
+if (r < 0) {
+error_setg(errp, "I/O error");
+return;
+}
+keys++;
+}
+}
+
+void qmp_dump_skeys(const char *filename, Error **errp)
+{
+S390SKeysState *ss = s390_get_skeys_device();
+S390SKeysClass *skeyclass = S390_SKEYS_GET_CLASS(ss);
+const uint64_t total_count = ram_size / TARGET_PAGE_SIZE;
+uint64_t handled_count = 0, cur_count;
+Error *lerr = NULL;
+vaddr cur_gfn = 0;
+uint8_t *buf;
+int ret;
+FILE *f;
+
+/* Quick check to see if guest is using storage keys*/
+if (!skeyclass->skeys_enabled(ss)) {
+error_setg(&lerr, "This guest is not using storage keys. "
+ "Nothing to dump.");
+error_propagate(errp, lerr);
+return;
+}
+
+f = fopen(filename, "wb");
+if (!f) {
+error_setg(&lerr, "Could not open file");
+error_propagate(errp, lerr);
+return;
+}
+
+buf = g_try_malloc(S390_SKEYS_BUFFER_SIZE);
+if (!buf) {
+error_setg(&lerr, "Could not allocate memory");
+error_propagate(errp, lerr);
+goto out;
+}
+
+/* we'll only dump initial memory for now */
+while (handled_count < total_count) {
+/* Calculate how many keys to ask for & handle overflow case */
+cur_count = MIN(total_count - handled_count, S390_SKEYS_BUFFER_SIZE);
+
+ret = skeyclass->get_skeys(ss, cur_gfn, cur_count, buf);
+if (ret < 0) {
+error_setg(&lerr, "get_keys error %d", ret);
+error_propagate(errp, lerr);
+goto out_free;
+}
+
+/* write keys to stream */
+write_keys(f, buf, cur_gfn, cur_count, &lerr);
+if (lerr) {
+error_propagate(errp, lerr);
+goto out_free;
+}
+
+cur_gfn += cur_count;
+handled_count += cur_count;
+}
+
+out_free:
+g_free(buf);
+out:
+fclose(f);
+}
+
 static void qemu_s390_skeys_init(Object *obj)
 {
 QEMUS390SKeysState *skeys = QEMU_S390_SKEYS(obj);
diff --git a/monitor.c b/monitor.c
index aeea2b5..f1501cd 100644
--- a/monitor.c
+++ b/monitor.c
@@ -5361,3 +5361,10 @@ void qmp_rtc_reset_reinjection(Error **errp)
 error_setg(errp, QERR_FEATURE_DISABLED, "rtc-reset-reinjection");
 }
 #endif
+
+#ifndef TARGET_S390X
+void qmp_dump_skeys(const char *filename, Error **errp)
+{
+error_setg(errp, QERR_FEATURE_DISABLED, "dump-skeys");
+}
+#endif
diff --git a/qapi-schema.json b/qapi-schema.json
index 1285b8c..d1c1c25 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2058,6 +2058,19 @@
   'returns': 'DumpGuestMemoryCapability' }
 
 ##
+# @dump-skeys
+#
+# Dump guest's storage keys.  @filename: the path to the file to dump to.
+# This command is only supported on s390 architecture.
+#
+# Returns: nothing on success
+#
+# Since: 2.5
+##
+{ 'command': 'dump-skeys',
+  'data': { 'filename': 'str' } }
+
+##
 # @netdev_add:
 #
 # Add a network backend.
diff --git a/qmp-commands.hx b/qmp-commands.hx
index ba630b1..9848fd8 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -872,6 +872,31 @@ Example:
 
 EQMP
 
+#if defined TARGET_S390X
+{
+.name   = "dump-skeys",
+.args_type  = "filename:F",
+.

[Qemu-devel] [PATCH for-2.5 8/8] s390x: Disable storage key migration on old machine type

[Cornelia Huck]

From: "Jason J. Herne" 

This code disables storage key migration when an older machine type is
specified.

Reviewed-by: David Hildenbrand 
Signed-off-by: Jason J. Herne 
Signed-off-by: Cornelia Huck 
---
 hw/s390x/s390-skeys.c   | 28 +---
 hw/s390x/s390-virtio-ccw.c  | 12 
 include/hw/s390x/storage-keys.h |  1 +
 3 files changed, 38 insertions(+), 3 deletions(-)

diff --git a/hw/s390x/s390-skeys.c b/hw/s390x/s390-skeys.c
index a927c98..2f23600 100644
--- a/hw/s390x/s390-skeys.c
+++ b/hw/s390x/s390-skeys.c
@@ -345,12 +345,34 @@ static int s390_storage_keys_load(QEMUFile *f, void 
*opaque, int version_id)
 return ret;
 }
 
-static void s390_skeys_instance_init(Object *obj)
+static inline bool s390_skeys_get_migration_enabled(Object *obj, Error **errp)
 {
 S390SKeysState *ss = S390_SKEYS(obj);
 
-register_savevm(NULL, TYPE_S390_SKEYS, 0, 1, s390_storage_keys_save,
-s390_storage_keys_load, ss);
+return ss->migration_enabled;
+}
+
+static inline void s390_skeys_set_migration_enabled(Object *obj, bool value,
+Error **errp)
+{
+S390SKeysState *ss = S390_SKEYS(obj);
+
+ss->migration_enabled = value;
+
+if (ss->migration_enabled) {
+register_savevm(NULL, TYPE_S390_SKEYS, 0, 1, s390_storage_keys_save,
+s390_storage_keys_load, ss);
+} else {
+unregister_savevm(DEVICE(ss), TYPE_S390_SKEYS, ss);
+}
+}
+
+static void s390_skeys_instance_init(Object *obj)
+{
+object_property_add_bool(obj, "migration-enabled",
+ s390_skeys_get_migration_enabled,
+ s390_skeys_set_migration_enabled, NULL);
+object_property_set_bool(obj, true, "migration-enabled", NULL);
 }
 
 static void s390_skeys_class_init(ObjectClass *oc, void *data)
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 8f1b1fc..80d4714 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -282,13 +282,25 @@ static const TypeInfo ccw_machine_info = {
 },
 };
 
+#define CCW_COMPAT_2_4 \
+{\
+.driver   = TYPE_S390_SKEYS,\
+.property = "migration-enabled",\
+.value= "off",\
+},
+
 static void ccw_machine_2_4_class_init(ObjectClass *oc, void *data)
 {
 MachineClass *mc = MACHINE_CLASS(oc);
+static GlobalProperty compat_props[] = {
+CCW_COMPAT_2_4
+{ /* end of list */ }
+};
 
 mc->name = "s390-ccw-virtio-2.4";
 mc->alias = "s390-ccw-virtio";
 mc->desc = "VirtIO-ccw based S390 machine v2.4";
+mc->compat_props = compat_props;
 }
 
 static const TypeInfo ccw_machine_2_4_info = {
diff --git a/include/hw/s390x/storage-keys.h b/include/hw/s390x/storage-keys.h
index 18e08d2..72b850c 100644
--- a/include/hw/s390x/storage-keys.h
+++ b/include/hw/s390x/storage-keys.h
@@ -21,6 +21,7 @@
 
 typedef struct S390SKeysState {
 DeviceState parent_obj;
+bool migration_enabled;
 
 } S390SKeysState;
 
-- 
2.4.6

Re: [Qemu-devel] Creating a VM from an E01 file

[Cervellone, Adam]

I apologize for my error.  I have now re-run all the commands in the same order 
and attached a screen shot of the terminal window.  I have selected desktop as 
the location for the VMDK file to be stored and it is included in the command 
after -O vmdk.  

Thank you,
Adam Cervellone

-Original Message-
From: Peter Maydell [mailto:peter.mayd...@linaro.org] 
Sent: Monday, July 20, 2015 9:21 AM
To: Cervellone, Adam
Cc: qemu-devel@nongnu.org
Subject: Re: Creating a VM from an E01 file

On 20 July 2015 at 14:03, Cervellone, Adam  wrote:
> My name is Adam Cervellone. I am a digital evidence intern at the 
> North Carolina State Crime Laboratory.  As part of my time here, I am 
> conducting a research project using the SIFT workstation to make a 
> virtual machine of an
> E01 file.  I’ve previously used this series of commands to attempt to 
> create a VM
>
> 1.Sudo su
>
> o SIFT password entered
>
> 2.Mkdir /mnt/ewf1
>
> 3.Mount_ewf.py  /mnt/ewf1
>
> 4.qemu-img convert /mnt/ewf1/ -O vmdk
> .vmdk
>
> I found these steps on Forensics wiki, however they have not worked.  
> I may have misinterpreted a section of the command and entered it 
> incorrectly.  Do you know of the correct way to do this or of someone 
> who may be able to help me?

You've said what you were trying to do, but not what actually happened.
"It didn't work" provides no information at all. Did it give an error message 
(if so, what?), did it do nothing, did it just hang?
Giving an exact transcript of the commands you typed and the output might be 
useful.

Identifying problems with computing has some similarities with detecting crime 
-- we need evidence to be able to draw good conclusions :-)

thanks
-- PMM

Re: [Qemu-devel] [PATCH for-2.5 1/8] s390x: add 2.5 compat s390-ccw-virtio machine

[Christian Borntraeger]

Am 20.07.2015 um 15:49 schrieb Cornelia Huck:
> Reviewed-by: Jason J. Herne 
> Signed-off-by: Cornelia Huck 

for post 2.4
Acked-by: Christian Borntraeger 

> ---
>  hw/s390x/s390-virtio-ccw.c | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index 4c51d1a..708763e 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -289,7 +289,6 @@ static void ccw_machine_2_4_class_init(ObjectClass *oc, 
> void *data)
>  mc->name = "s390-ccw-virtio-2.4";
>  mc->alias = "s390-ccw-virtio";
>  mc->desc = "VirtIO-ccw based S390 machine v2.4";
> -mc->is_default = 1;
>  }
> 
>  static const TypeInfo ccw_machine_2_4_info = {
> @@ -298,10 +297,27 @@ static const TypeInfo ccw_machine_2_4_info = {
>  .class_init= ccw_machine_2_4_class_init,
>  };
> 
> +static void ccw_machine_2_5_class_init(ObjectClass *oc, void *data)
> +{
> +MachineClass *mc = MACHINE_CLASS(oc);
> +
> +mc->name = "s390-ccw-virtio-2.5";
> +mc->alias = "s390-ccw-virtio";
> +mc->desc = "VirtIO-ccw based S390 machine v2.5";
> +mc->is_default = 1;
> +}
> +
> +static const TypeInfo ccw_machine_2_5_info = {
> +.name  = TYPE_S390_CCW_MACHINE "2.5",
> +.parent= TYPE_S390_CCW_MACHINE,
> +.class_init= ccw_machine_2_5_class_init,
> +};
> +
>  static void ccw_machine_register_types(void)
>  {
>  type_register_static(&ccw_machine_info);
>  type_register_static(&ccw_machine_2_4_info);
> +type_register_static(&ccw_machine_2_5_info);
>  }
> 
>  type_init(ccw_machine_register_types)
> 

Re: [Qemu-devel] Creating a VM from an E01 file

[Peter Maydell]

On 20 July 2015 at 14:57, Cervellone, Adam  wrote:

Your instructions say:

>> 4.qemu-img convert /mnt/ewf1/ -O vmdk
>> .vmdk


but in your screenshot the command you run is:
 qemu-img convert /mnt/ewf1 -O vmdk /home/sansforensics/Desktop/Item1.vmdk

and you haven't filled in the 'E01 image file name' part.

qemu-img seems to give this slightly unhelpful error message
if you pass it a directory name rather than a filename for
the input file.

thanks
-- PMM

Re: [Qemu-devel] Creating a VM from an E01 file

[Cervellone, Adam]

I have now changed the command to qemu-img convert /mnt/ewf1/ewf1 -O vmdk 
/home/sansforensics/Desktop/Item1.vmdk and two things have happened.  1. An 
Item1.vmdk file is now on the desktop.  Terminal just hangs after running the 
command. The cursor is blinking and the shell prompt has not returned.  The 
SIFT Workstation is running in VMware Player 7, should I try exporting the 
newly made vmdk to the windows host and running it in VirtualBox or VMware 
player?

Thank you,
Adam Cervellone

-Original Message-
From: Peter Maydell [mailto:peter.mayd...@linaro.org] 
Sent: Monday, July 20, 2015 10:06 AM
To: Cervellone, Adam
Cc: qemu-devel@nongnu.org
Subject: Re: Creating a VM from an E01 file

On 20 July 2015 at 14:57, Cervellone, Adam  wrote:

Your instructions say:

>> 4.qemu-img convert /mnt/ewf1/ -O vmdk
>> .vmdk


but in your screenshot the command you run is:
 qemu-img convert /mnt/ewf1 -O vmdk /home/sansforensics/Desktop/Item1.vmdk

and you haven't filled in the 'E01 image file name' part.

qemu-img seems to give this slightly unhelpful error message if you pass it a 
directory name rather than a filename for the input file.

thanks
-- PMM

Re: [Qemu-devel] [PATCH] qcow2: Remove forward declaration of QCowAIOCB

[Eric Blake]

On 07/20/2015 05:55 AM, Kevin Wolf wrote:
> This struct doesn't exist any more since commit 3fc48d09 in August 2011,
> it's about time to remove its forward declaration.
> 
> Signed-off-by: Kevin Wolf 
> ---
>  block/qcow2.h | 2 --
>  1 file changed, 2 deletions(-)

Reviewed-by: Eric Blake 


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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PULL 3/6] virtio-net: unbreak any layout

[Eric Blake]

On 07/20/2015 06:12 AM, Michael S. Tsirkin wrote:
> From: Jason Wang 
> 
> Commit 032a74a1c0fcdd5fd1c69e56126b4c857ee36611
> ("virtio-net: byteswap virtio-net header") breaks any layout by
> requiring out_sg[0].iov_len >= n->guest_hdr_len. Fixing this by
> copying header to temporary buffer if swap is needed, and then use
> this buffer as part of out_sg.
> 
> Fixes 032a74a1c0fcdd5fd1c69e56126b4c857ee36611
> ("virtio-net: byteswap virtio-net header")
> Cc: qemu-sta...@nongnu.org
> Cc: c...@fr.ibm.com
> Signed-off-by: Jason Wang 
> Reviewed-by: Michael S. Tsirkin 
> Signed-off-by: Michael S. Tsirkin 
> Reviewed-by: Eric Blake 

I think my R-b was intended for 2/6, not this one. But if this has
already been pulled, it's not a show-stopper.

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH for-2.5 4/8] s390x: Dump storage keys qmp command

[Eric Blake]

On 07/20/2015 07:49 AM, Cornelia Huck wrote:
> From: "Jason J. Herne" 
> 
> Provide a dump-skeys qmp command to allow the end user to dump storage
> keys. This is useful for debugging problems with guest storage key support
> within Qemu and for guest operating system developers.
> 
> Reviewed-by: Thomas Huth 
> Reviewed-by: David Hildenbrand 
> Signed-off-by: Jason J. Herne 
> Signed-off-by: Cornelia Huck 
> ---

> +void qmp_dump_skeys(const char *filename, Error **errp)
> +{

> +
> +f = fopen(filename, "wb");

If you'll use qemu_fopen() here...


> +++ b/qapi-schema.json
> @@ -2058,6 +2058,19 @@
>'returns': 'DumpGuestMemoryCapability' }
>  
>  ##
> +# @dump-skeys
> +#
> +# Dump guest's storage keys.  @filename: the path to the file to dump to.
> +# This command is only supported on s390 architecture.
> +#
> +# Returns: nothing on success
> +#
> +# Since: 2.5
> +##
> +{ 'command': 'dump-skeys',
> +  'data': { 'filename': 'str' } }

then this command will automatically accept /dev/fdset/NNN notation for
allowing the user to pass in a file descriptor with add-fd then tying
that fd to this command (useful for when qemu is restricted from
directly calling open() for security reasons).

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



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PULL 1/1] crypto: Fix aes_decrypt_wrapper()

[Kevin Wolf]

Commit d3462e3 broke qcow2's encryption functionality by using encrypt
instead of decrypt in the wrapper function it introduces. This was found
by qemu-iotests case 134.

Signed-off-by: Kevin Wolf 
Reviewed-by: Daniel P. Berrange 
---
 crypto/cipher-nettle.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/cipher-nettle.c b/crypto/cipher-nettle.c
index a55a8e8..b01cb1c 100644
--- a/crypto/cipher-nettle.c
+++ b/crypto/cipher-nettle.c
@@ -47,7 +47,7 @@ static void aes_encrypt_wrapper(cipher_ctx_t ctx, 
cipher_length_t length,
 static void aes_decrypt_wrapper(cipher_ctx_t ctx, cipher_length_t length,
 uint8_t *dst, const uint8_t *src)
 {
-aes_encrypt(ctx, length, dst, src);
+aes_decrypt(ctx, length, dst, src);
 }
 
 static void des_encrypt_wrapper(cipher_ctx_t ctx, cipher_length_t length,
-- 
1.8.3.1

[Qemu-devel] [PULL 0/1] Block layer patches for 2.4.0-rc2

[Kevin Wolf]

The following changes since commit 71358470eec668f5dc53def25e585ce250cea9bf:

  Merge remote-tracking branch 'remotes/amit-virtio-rng/tags/vrng-2.4' into 
staging (2015-07-17 15:22:45 +0100)

are available in the git repository at:


  git://repo.or.cz/qemu/kevin.git tags/for-upstream

for you to fetch changes up to bd09594603f1498e7623f0030988b62e2052f7da:

  crypto: Fix aes_decrypt_wrapper() (2015-07-20 13:35:45 +0200)


Block layer patches for 2.4.0-rc2


Kevin Wolf (1):
  crypto: Fix aes_decrypt_wrapper()

 crypto/cipher-nettle.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [Qemu-devel] [PULL 0/6] virtio, vhost, pc fixes for 2.4

[Peter Maydell]

On 20 July 2015 at 13:12, Michael S. Tsirkin  wrote:
> The following changes since commit b4329bf41c86bac8b56cadb097081960cc4839a0:
>
>   Update version for v2.4.0-rc1 release (2015-07-16 20:32:20 +0100)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream
>
> for you to fetch changes up to f9d6dbf0bf6e91b8ed896369ab1b7e91e5a1a4df:
>
>   virtio-net: remove virtio queues if the guest doesn't support multiqueue 
> (2015-07-20 14:19:42 +0300)
>
> 
> virtio, vhost, pc fixes for 2.4
>
> The only notable thing here is vhost-user multiqueue
> revert. We'll work on making it stable in 2.5,
> reverting now means we won't have to maintain
> bug for bug compability forever.
>
> Signed-off-by: Michael S. Tsirkin 

Applied, thanks.

-- PMM

Re: [Qemu-devel] [POC] colo-proxy in qemu

[Stefan Hajnoczi]

On Mon, Jul 20, 2015 at 2:12 PM, Vasiliy Tolstov  wrote:
> 2015-07-20 14:55 GMT+03:00 zhanghailiang :
>> Agreed, besides, it is seemed that slirp is not supporting ipv6, we also
>> have to supplement it.
>
>
> patch for ipv6 slirp support some times ago sended to qemu list, but i
> don't know why in not accepted.

I think no one reviewed it but there was no objection against IPv6
support in principle.

Jan: Can we merge slirp IPv6 support for QEMU 2.5?

Stefan

Re: [Qemu-devel] [Qemu-block] [PATCH 1/2] ignore bdrv_flush operation when no qcow2 cache item is dirty

[Eric Blake]

[patches should always be sent to qemu-devel, even if qemu-block is also
in the to/cc list]

On 07/08/2015 01:26 AM, Qingshu Chen wrote:
> qcow2_cache_flush() writes dirty cache to the disk and invokes bdrv_flush()
> to make the data durable. But even if there is no dirty cache,
> qcow2_cache_flush() would invoke bdrv_flush().  In fact, bdrv_flush() will
> invoke fdatasync(), and it is an expensive operation. The patch will not
> invoke bdrv_flush if there is not dirty cache. The reason that I modify the
> return value of qcow2_cache_flush()  is qcow2_co_flush_to_os needs to know
> whether flush operation is called. Following is the patch:
> 
>>From 23f9f83da4178e8fbb53d2cffe128f5a2d3a239a Mon Sep 17 00:00:00 2001
> From: Qingshu Chen 
> Date: Wed, 1 Jul 2015 14:45:23 +0800
> Subject: [PATCH 1/2] ignore bdrv_flush operation when no qcow2 cache item is
>  dirty
> Signed-off-by: Qingshu Chen 

I didn't quickly find an associated 2/2 patch; are you sure you sent the
series correctly?

> 
> ---
>  block/qcow2-cache.c | 9 -
>  block/qcow2.c   | 2 ++
>  2 files changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/block/qcow2-cache.c b/block/qcow2-cache.c
> index ed92a09..57c0601 100644
> --- a/block/qcow2-cache.c
> +++ b/block/qcow2-cache.c
> @@ -174,6 +174,7 @@ int qcow2_cache_flush(BlockDriverState *bs, Qcow2Cache
> *c)
>  int result = 0;
>  int ret;
>  int i;
> +int flag = 0;

This is used as a bool, so declare it as such (bool flag = false;).

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 09/10] qga: added bus type and disk location path

[Eric Blake]

On 07/06/2015 10:40 PM, Michael Roth wrote:
> From: Olga Krishtal 
> 
> According to Microsoft disk location path can be obtained via
> IOCTL_SCSI_GET_ADDRESS. Unfortunately this ioctl can not be used for all
> devices. There are certain bus types which could be obtained with this
> API. Please, refer to the following link for more details
> https://technet.microsoft.com/en-us/library/ee851589(v=ws.10).aspx
> 
> Bus type could be obtained using IOCTL_STORAGE_QUERY_PROPERTY. Enum
> STORAGE_BUS_TYPE describes all buses supported by OS.
> 
> Windows defines more bus types than Linux. Thus some values have been added
> to GuestDiskBusType.
> 
> Signed-off-by: Olga Krishtal 
> Signed-off-by: Denis V. Lunev 
> CC: Eric Blake 
> CC: Michael Roth 
> * fixed warning in CreateFile due to use of NULL instead of 0
> Signed-off-by: Michael Roth 
> ---

> +++ b/qga/qapi-schema.json
> @@ -703,12 +703,24 @@
>  # @uml: UML disks
>  # @sata: SATA disks
>  # @sd: SD cards
> +# @unknown: Unknown bus type
> +# @ieee1394: Win IEEE 1394 bus type
> +# @ssa: Win SSA bus type
> +# @fibre: Win fiber channel bus type
> +# @raid: Win RAID bus type
> +# @iscsi: Win iScsi bus type
> +# @sas: Win serial-attaches SCSI bus type
> +# @mmc: Win multimedia card (MMC) bus type
> +# @virtual: Win virtual bus type
> +# @file-backed virtual: Win file-backed bus type
>  #
>  # Since: 2.2

It would be nice to have a followup patch (since it is doc-only, it
could still make 2.4) that mentions that all these new enum members were
added in 2.4.

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 1/6] block: Add blocker on mirror target

[Max Reitz]

On 25.06.2015 05:22, Fam Zheng wrote:

In block/backup.c, we already check and add blocker on the target bs,
which is necessary so that it won't be intervened with other operations.

In block/mirror.c we should also protect the mirror target bs, because it
could have a node-name (drive-mirror ... node-name=XXX), and on top of
that it's safe to add blockdev-mirror.

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


Reviewed-by: Max Reitz 

[Qemu-devel] [RFC PATCH] Fix hotplug/hotunplug issue about virtio 1.0 devices

[Lin Ma]

Hi Michael and Gerd,

I found an hotplug/hotunplug issue about virtio 1.0 devices and trying 
to fix it.

The bug description is:
(qemu) device_add virtio-gpu-pci,id=gpu0
(qemu) device_del gpu0
(qemu) device_add virtio-gpu-pci,id=gpu0
Duplicate ID 'gpu0' for device
Try "help device_add" for more information

My fix looks like this:
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 283401a..098fc83 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1413,6 +1413,12 @@ static void 
virtio_pci_modern_region_map(VirtIOPCIProxy *proxy,

 virtio_pci_add_mem_cap(proxy, cap);
 }

+static void virtio_pci_modern_region_unmap(VirtIOPCIProxy *proxy,
+   VirtIOPCIRegion *region)
+{
+memory_region_del_subregion(&proxy->modern_bar, ®ion->mr);
+}
+
 /* This is called by virtio-bus just after the device is plugged. */
 static void virtio_pci_device_plugged(DeviceState *d, Error **errp)
 {
@@ -1584,6 +1590,16 @@ static void virtio_pci_exit(PCIDevice *pci_dev)

 msix_uninit_exclusive_bar(pci_dev);
 address_space_destroy(&proxy->modern_as);
+object_unparent(OBJECT(&proxy->modern_cfg));
+
+bool modern = !(proxy->flags & VIRTIO_PCI_FLAG_DISABLE_MODERN);
+if (modern) {
+virtio_pci_modern_region_unmap(proxy, &proxy->common);
+virtio_pci_modern_region_unmap(proxy, &proxy->isr);
+virtio_pci_modern_region_unmap(proxy, &proxy->device);
+virtio_pci_modern_region_unmap(proxy, &proxy->notify);
+}
+memory_region_unref(&proxy->modern_bar);
 }

 static void virtio_pci_reset(DeviceState *qdev)



But after applying the fix, I got the following errors:
(qemu) device_add virtio-gpu-pci,id=gpu0
(qemu) device_del gpu0
(qemu) **
ERROR:qom/object.c:825:object_unref: assertion failed: (obj->ref > 0)
..


I think because of the grace period of rcu, the function 
memory_region_unref(as->root) in do_address_space_destroy isn't 
performed immediately,
The do_address_space_destroy is always performed after virtio_pci_exit, 
That caused 'assertion failed: (obj->ref > 0)'.
I have no idea whether my guess is correct or in correct, and don't know 
how to avoid this assertion failure in this situation.

Does my fix make sense ? May I have your ideas or suggestions?

Thanks!
Lin

Re: [Qemu-devel] [PATCH RFC v2 01/47] qapi: Clarify docs on including the same file multiple times

[Eric Blake]

On 07/01/2015 02:21 PM, Markus Armbruster wrote:
> It's idempotent.
> 
> Signed-off-by: Markus Armbruster 
> ---
>  docs/qapi-code-gen.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 09/10] qga: added bus type and disk location path

[Denis V. Lunev]

On 07/20/2015 06:06 PM, Eric Blake wrote:

On 07/06/2015 10:40 PM, Michael Roth wrote:

From: Olga Krishtal 

According to Microsoft disk location path can be obtained via
IOCTL_SCSI_GET_ADDRESS. Unfortunately this ioctl can not be used for all
devices. There are certain bus types which could be obtained with this
API. Please, refer to the following link for more details
https://technet.microsoft.com/en-us/library/ee851589(v=ws.10).aspx

Bus type could be obtained using IOCTL_STORAGE_QUERY_PROPERTY. Enum
STORAGE_BUS_TYPE describes all buses supported by OS.

Windows defines more bus types than Linux. Thus some values have been added
to GuestDiskBusType.

Signed-off-by: Olga Krishtal 
Signed-off-by: Denis V. Lunev 
CC: Eric Blake 
CC: Michael Roth 
* fixed warning in CreateFile due to use of NULL instead of 0
Signed-off-by: Michael Roth 
---
+++ b/qga/qapi-schema.json
@@ -703,12 +703,24 @@
  # @uml: UML disks
  # @sata: SATA disks
  # @sd: SD cards
+# @unknown: Unknown bus type
+# @ieee1394: Win IEEE 1394 bus type
+# @ssa: Win SSA bus type
+# @fibre: Win fiber channel bus type
+# @raid: Win RAID bus type
+# @iscsi: Win iScsi bus type
+# @sas: Win serial-attaches SCSI bus type
+# @mmc: Win multimedia card (MMC) bus type
+# @virtual: Win virtual bus type
+# @file-backed virtual: Win file-backed bus type
  #
  # Since: 2.2

It would be nice to have a followup patch (since it is doc-only, it
could still make 2.4) that mentions that all these new enum members were
added in 2.4.


sure!

Re: [Qemu-devel] [PATCH for-2.4 2/2] qom: Fix invalid error check in property_get_str()

[Eric Blake]

On 07/01/2015 09:47 AM, Markus Armbruster wrote:
> When a function returns a null pointer on error and only on error, you
> can do
> 
> if (!foo(foos, errp)) {
> ... handle error ...
> }
> 
> instead of the more cumbersome
> 
> Error *err = NULL;
> 
> if (!foo(foos, &err)) {
> error_propagate(errp, err);
> ... handle error ...
> }
> 
> A StringProperty's getter, however, may return null on success!  We
> then fail to call visit_type_str().
> 
> Screwed up in 6a146eb, v1.1.
> 
> Fails tests/qom-test in my current, heavily hacked QAPI branch.  No
> reproducer for master known (but I didn't look hard).
> 
> Cc: Andreas Färber 
> Cc: Anthony Liguori 
> Signed-off-by: Markus Armbruster 
> ---
>  qom/object.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 

Reviewed-by: Eric Blake 

> diff --git a/qom/object.c b/qom/object.c
> index 6173da8..4c4df55 100644
> --- a/qom/object.c
> +++ b/qom/object.c
> @@ -1591,14 +1591,18 @@ typedef struct StringProperty
>  static void property_get_str(Object *obj, Visitor *v, void *opaque,
>   const char *name, Error **errp)
>  {
> +Error *err = NULL;
>  StringProperty *prop = opaque;
>  char *value;
>  
> -value = prop->get(obj, errp);
> -if (value) {
> -visit_type_str(v, &value, name, errp);
> -g_free(value);
> +value = prop->get(obj, &err);
> +if (err) {
> +error_propagate(errp, err);
> +return;
>  }
> +
> +visit_type_str(v, &value, name, errp);
> +g_free(value);
>  }
>  
>  static void property_set_str(Object *obj, Visitor *v, void *opaque,
> 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 3/6] block: Extract blockdev part of qmp_drive_mirror

[Max Reitz]

On 25.06.2015 05:22, Fam Zheng wrote:

This is the part that will be reused by blockdev-mirror.

Signed-off-by: Fam Zheng 
---
  blockdev.c | 155 -
  1 file changed, 92 insertions(+), 63 deletions(-)


As you probably know (since you introduced it), this needs fixup due to 
0fc9f8ea28.
(And the changes are not trivial, unfortunately, so I had to give up 
fixing it locally.)


Generally, the set of changes looks good to me, though.

Max

Re: [Qemu-devel] [PATCH v2 5/6] qmp: Add blockdev-mirror command

[Max Reitz]

On 25.06.2015 05:22, Fam Zheng wrote:

This will start a mirror job from a named device to another named
device, its relation with drive-mirror is similar with blockdev-backup
to drive-backup.

In blockdev-mirror, the target node should be prepared by blockdev-add,
which will be responsible for assigning a name to the new node, so
'node-name' in drive-mirror is dropped.

Signed-off-by: Fam Zheng 
---
  blockdev.c   | 61 
  qapi/block-core.json | 47 
  qmp-commands.hx  | 48 +
  3 files changed, 156 insertions(+)

diff --git a/blockdev.c b/blockdev.c
index de6383f..e0dba07 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -2932,6 +2932,10 @@ static void blockdev_mirror_common(BlockDriverState *bs,
  if (bdrv_op_is_blocked(target, BLOCK_OP_TYPE_MIRROR_TARGET, errp)) {
  return;
  }
+if (target->blk) {
+error_setg(errp, "Cannot mirror to an attached block device");
+return;
+}


1) Why?

2) I think this should be noted in the QMP interface documentation. "the 
name of the device to mirror to" sounds like it is actually meant to be 
an attached block device.


Max

Re: [Qemu-devel] [RFC PATCH] Fix hotplug/hotunplug issue about virtio 1.0 devices

[Michael S. Tsirkin]

On Mon, Jul 20, 2015 at 11:14:58PM +0800, Lin Ma wrote:
> Hi Michael and Gerd,
> 
> I found an hotplug/hotunplug issue about virtio 1.0 devices and trying to
> fix it.
> The bug description is:
> (qemu) device_add virtio-gpu-pci,id=gpu0
> (qemu) device_del gpu0

At this point, you must wait for guest to ack device removal.


> (qemu) device_add virtio-gpu-pci,id=gpu0
> Duplicate ID 'gpu0' for device
> Try "help device_add" for more information
> 
> My fix looks like this:
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index 283401a..098fc83 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -1413,6 +1413,12 @@ static void
> virtio_pci_modern_region_map(VirtIOPCIProxy *proxy,
>  virtio_pci_add_mem_cap(proxy, cap);
>  }
> 
> +static void virtio_pci_modern_region_unmap(VirtIOPCIProxy *proxy,
> +   VirtIOPCIRegion *region)
> +{
> +memory_region_del_subregion(&proxy->modern_bar, ®ion->mr);
> +}
> +
>  /* This is called by virtio-bus just after the device is plugged. */
>  static void virtio_pci_device_plugged(DeviceState *d, Error **errp)
>  {
> @@ -1584,6 +1590,16 @@ static void virtio_pci_exit(PCIDevice *pci_dev)
> 
>  msix_uninit_exclusive_bar(pci_dev);
>  address_space_destroy(&proxy->modern_as);
> +object_unparent(OBJECT(&proxy->modern_cfg));
> +
> +bool modern = !(proxy->flags & VIRTIO_PCI_FLAG_DISABLE_MODERN);
> +if (modern) {
> +virtio_pci_modern_region_unmap(proxy, &proxy->common);
> +virtio_pci_modern_region_unmap(proxy, &proxy->isr);
> +virtio_pci_modern_region_unmap(proxy, &proxy->device);
> +virtio_pci_modern_region_unmap(proxy, &proxy->notify);
> +}
> +memory_region_unref(&proxy->modern_bar);
>  }
> 
>  static void virtio_pci_reset(DeviceState *qdev)
> 
> 
> 
> But after applying the fix, I got the following errors:
> (qemu) device_add virtio-gpu-pci,id=gpu0
> (qemu) device_del gpu0
> (qemu) **
> ERROR:qom/object.c:825:object_unref: assertion failed: (obj->ref > 0)
> ..
> 
> 
> I think because of the grace period of rcu, the function
> memory_region_unref(as->root) in do_address_space_destroy isn't performed
> immediately,
> The do_address_space_destroy is always performed after virtio_pci_exit, That
> caused 'assertion failed: (obj->ref > 0)'.
> I have no idea whether my guess is correct or in correct, and don't know how
> to avoid this assertion failure in this situation.
> Does my fix make sense ? May I have your ideas or suggestions?
> 
> Thanks!
> Lin

Re: [Qemu-devel] [PATCH 1/1] virtio-mmio: return the max queue num of virtio-mmio with initial value

[Wei Huang]

On 07/20/2015 06:07 AM, Peter Maydell wrote:
> On 16 July 2015 at 19:38, Wei Huang  wrote:
>> Recently we found that virtio-console devices consumes lots AArch64 guest
>> memory, roughly 1GB with 8 devices. After debugging, it turns out that lots
>> of factors contribute to this problem: i) guest PAGE_SIZE=64KB, ii)
>> virtio-mmio based devices, and iii) virtio-console device. Here is the
>> detailed analysis:
>>
>> 1. First, during initialization, virtio-mmio driver in guest pokes vq
>>size by reading VIRTIO_MMIO_QUEUE_NUM_MAX (see virtio_mmio.c file).
>> 2. QEMU returns VIRTQUEUE_MAX_SIZE (1024) to guest VM; And virtio-mmio uses
>>it as the default vq size.
>> 3. virtio-console driver allocates vring buffers based on this value (see
>>add_inbuf() function of virtio_console.c file). Because PAGE_SIZE=64KB,
>>~64MB is allocated for each virtio-console vq.
>>
>> This patch addresses the problem by returning the iniatlized vring size
>> when VM queries QEMU about VIRTIO_MMIO_QUEUE_NUM_MAX. This is similar to
>> virtio-pci's approach. By doing this, the vq memory consumption is reduced
>> substantially.
> 
> I don't know if this patch is sensible to apply anyway, but from
> this description this really sounds like a guest kernel bug.
> QEMU tells the kernel the maximum queue size it can cope with,
> and if the guest kernel cares about not using insane amounts of
> RAM on queues then it should not blindly use the maximum size
> but restrict it itself...
Yes, this is another way of solving the problem. I think there are three
alternatives:

1. Fix the return value of MMIO_QUEUE_NUM_MAX in QEMU (my patch);
2. In guest VM, virtio-mmio shouldn't query MMIO_QUEUE_NUM_MAX. Instead,
it should behave similarly to virtio-pci driver which queries
VIRTIO_PCI_QUEUE_NUM instead. However this approach requires
modification of VIRTIO Specification as VIRTIO_PCI_QUEUE_NUM is
WRITE-ONLY in virtio-mmio.
3. Fix virtio_console driver in guest VM. This driver currently takes in
info->num and allocates memory based on its value. Apparently we can put
a upper-limit on it.

Your suggestion could fall in to (2) or (3). Any preference?

Thanks,
-Wei



> 
> thanks
> -- PMM
> 

Re: [Qemu-devel] Poor disk I/O performance

[Gleb Stepanov]

Also, i want to say that qcow2 that was mounted on nb0 is placed on /dev/sda.

Kind regards, Gleb Stepanov.

Re: [Qemu-devel] [PATCH] sheepdog: serialize requests to overwrapping area

[Stefan Hajnoczi]

On Sat, Jul 18, 2015 at 01:44:24AM +0900, Hitoshi Mitake wrote:
> Current sheepdog driver only serializes create requests in oid
> unit. This mechanism isn't enough for handling requests to
> overwrapping area spanning multiple oids, so it can result bugs like
> below:
> https://bugs.launchpad.net/sheepdog-project/+bug/1456421
> 
> This patch adds a new serialization mechanism for the problem. The
> difference from the old one is:
> 1. serialize entire aiocb if their targetting areas overwrap
> 2. serialize all requests (read, write, and discard), not only creates
> 
> This patch also removes the old mechanism because the new one can be
> an alternative.
> 
> Cc: Kevin Wolf 
> Cc: Stefan Hajnoczi 
> Cc: Teruaki Ishizaki 
> Cc: Vasiliy Tolstov 
> Signed-off-by: Hitoshi Mitake 
> ---
>  block/sheepdog.c | 152 
> ++-
>  1 file changed, 71 insertions(+), 81 deletions(-)

CCing Jeff Cody who now handles pull requests for network protocols.


pgpUfhxoJfE80.pgp
Description: PGP signature

[Qemu-devel] [PATCH] virtio-blk: use blk_io_plug/unplug for Linux AIO batching

[Stefan Hajnoczi]

The raw-posix block driver implements Linux AIO batching so multiple
requests can be submitted with a single io_submit(2) system call.
Batching is currently only used by virtio-scsi and
virtio-blk-data-plane.

Enable batching for regular virtio-blk so the number of io_submit(2)
system calls is reduced for workloads with queue depth > 1.

In 4KB random read performance tests with queue depth 32, the CPU
utilization on the host is reduced by 9.4%.  The fio job is as follows:

  [global]
  bs=4k
  ioengine=libaio
  iodepth=32
  direct=1
  sync=0
  time_based=1
  runtime=30
  clocksource=gettimeofday
  ramp_time=5

  [job1]
  rw=randread
  filename=/dev/vdb
  size=4096M
  write_bw_log=fio
  write_iops_log=fio
  write_lat_log=fio
  log_avg_msec=1000

This benchmark was run on an raw image on LVM.  The disk was an SSD
drive and -drive cache=none,aio=native was used.

Tested-by: Pradeep Surisetty 
Signed-off-by: Stefan Hajnoczi 
---
 hw/block/virtio-blk.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 6aefda4..a2137c8 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -600,6 +600,8 @@ static void virtio_blk_handle_output(VirtIODevice *vdev, 
VirtQueue *vq)
 return;
 }
 
+blk_io_plug(s->blk);
+
 while ((req = virtio_blk_get_request(s))) {
 virtio_blk_handle_request(req, &mrb);
 }
@@ -607,6 +609,8 @@ static void virtio_blk_handle_output(VirtIODevice *vdev, 
VirtQueue *vq)
 if (mrb.num_reqs) {
 virtio_blk_submit_multireq(s->blk, &mrb);
 }
+
+blk_io_unplug(s->blk);
 }
 
 static void virtio_blk_dma_restart_bh(void *opaque)
-- 
2.4.3

Re: [Qemu-devel] [PULL 0/1] Block layer patches for 2.4.0-rc2

[Peter Maydell]

On 20 July 2015 at 15:54, Kevin Wolf  wrote:
> The following changes since commit 71358470eec668f5dc53def25e585ce250cea9bf:
>
>   Merge remote-tracking branch 'remotes/amit-virtio-rng/tags/vrng-2.4' into 
> staging (2015-07-17 15:22:45 +0100)
>
> are available in the git repository at:
>
>
>   git://repo.or.cz/qemu/kevin.git tags/for-upstream
>
> for you to fetch changes up to bd09594603f1498e7623f0030988b62e2052f7da:
>
>   crypto: Fix aes_decrypt_wrapper() (2015-07-20 13:35:45 +0200)
>
> 
> Block layer patches for 2.4.0-rc2
>
> 

Applied, thanks.

-- PMM

Re: [Qemu-devel] [PATCH] qemu-common.h: Document cutils.c string functions

[Eric Blake]

On 07/19/2015 02:34 PM, Peter Maydell wrote:
> Add documentation comments for various utility string functions
> which we have implemented in util/cutils.c:
>  pstrcpy()
>  strpadcpy()
>  pstrcat()
>  strstart()
>  stristart()
>  qemu_strnlen()
>  qemu_strsep()
> 
> Signed-off-by: Peter Maydell 
> ---
> We recommend pstrcpy() &c in HACKING but that's not very helpful
> if we don't actually document their behaviour...

Don't know if we care about US vs. UK spelling in doc comments, so I'll
ignore it, and give:

Reviewed-by: Eric Blake 

> 
>  include/qemu-common.h | 114 
> +-
>  1 file changed, 113 insertions(+), 1 deletion(-)
> 

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



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] Summary MTTCG related patch sets

[Alex Bennée]

Hi,

Following this afternoons call I thought I'd summarise the state of the
various patch series and their relative dependencies. We re-stated the
aim should be to get what is up-streamable through the review process
and heading for merge so the delta for a full working MTTCG can be as
low as possible. There was some concern about the practicality of
submitting patches where the full benefit will not be seen until MTTCG
is finally merged.

On the patch submission note could I encourage posting public git trees
along with the patches for ease of review?

BQL lock breaking patches, Paolo/Jan
  - required for working virt-io in MTTCG
  - supersedes some of Fred's patches
  - merged upstream as of -rc0

TCG async_safe_work, Fred
  - http://git.greensocs.com/fkonrad/mttcg.git async_work_v3
  - [1437144337-21442-1-git-send-email-fred.kon...@greensocs.com]
  - split from earlier MTTCG patch series
  - needed for cross-cpu sync mechanism for main series and slow-path
  - candidate for upstreaming, but only MTTCG uses for now?

Slow-path for atomic instruction translation, Alvise
  - [1436516626-8322-1-git-send-email-a.r...@virtualopensystems.com]
  - Needs re-basing to use TCG async_safe_work
  - Earlier part of series (pre MTTCG) could be upstreamed as is
  - Concern about performance impact in non-MTTCG scenarios
  - Single CPU thread impact may be minimal with latest version, needs
  benchmarking
  - Also incomplete backend support, would BACKEND_HAS_LLSC_OPS be
  acceptable to maintainers while support added by more knowledgable
  backend people for non-x86/arm backends?
  
Multi-threaded TCG V6, Fred
  - g...@git.greensocs.com:fkonrad/mttcg.git branch multi_tcg_v6
  - [1435330053-18733-1-git-send-email-fred.kon...@greensocs.com]
  - Needs re-basing on top of latest -rc (BQL breaking)
  - Contains the rest of the MTTCG work (tb locking, tlb stuff etc)
  - Currently target-arm only, other builds broken

As far as balancing the desire to get things upstreamed versus having a
stable base for testing I suggest we try an approach like this:

  - select the current upstream -rc as the common base point
  - create a branch from -rc with:
- stuff submitted for upstream (reviewed, not nacked)
- doesn't break any tree
- has minimal performance impact 

Then both Fred and Alvise could base their trees of this point and we
aim to rebase onto a new branch each time the patches get merged into a
new upstream RC. The question then become how to deal with any
cross-dependencies between the slow-path and the main MTTCG branches?

I suspect the initial common branch point would just be
2.4.0-rc1+safe_async.

Does that sound workable?

-- 
Alex Bennée

Re: [Qemu-devel] [PATCH v2] raw-posix.c: Make physical devices usable in QEMU under Mac OS X host

[Programmingkid]

On Jul 20, 2015, at 8:46 AM, Laurent Vivier wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 
> 
> On 20/07/2015 12:48, Stefan Hajnoczi wrote:
>> On Fri, Jul 17, 2015 at 03:24:34PM -0400, Programmingkid wrote:
>>> 
>>> On Jul 17, 2015, at 9:41 AM, Stefan Hajnoczi wrote:
>>> 
 On Thu, Jul 16, 2015 at 04:46:07PM -0400, Programmingkid
 wrote:
> @@ -2014,7 +2015,9 @@ kern_return_t GetBSDPath( io_iterator_t
> mediaIterator, char *bsdPath, CFIndex ma if (
> bsdPathAsCFString ) { size_t devPathLength; strcpy( bsdPath,
> _PATH_DEV ); -strcat( bsdPath, "r" ); +
> if (flags & BDRV_O_NOCACHE) { +
> strcat(bsdPath, "r"); +} devPathLength = strlen(
> bsdPath ); if ( CFStringGetCString( bsdPathAsCFString,
> bsdPath + devPathLength, maxPathSize - devPathLength,
> kCFStringEncodingASCII ) ) { kernResult = KERN_SUCCESS;
 
 Is this the fix that makes CD-ROM passthrough work for you?
 
 Does the guest boot successfully when you do:
 
 -drive if=ide,media=cdrom,cache=none,file=/dev/cdrom
>>> 
>>> The guest fails during the boot process with the above command
>>> line.
>> 
>> That means the issue you originally hit hasn't been solved yet.
>> 
>> Take a look at s->needs_alignment and raw_probe_alignment().  In
>> the -drive cache=none case raw-posix needs to detect the correct
>> alignment (probably 2 KB for CD-ROMs).
> 
> As raw_open_common() sets needs_alignment to true on BDRV_O_NOCACHE
> (cache="none") and raw_probe_alignment() detects alignment if
> needs_alignment is true, I don't understand why it doesn't work.
> 
> Could you explain ?


I just did several tests with real CD-ROM discs and it does work. I first 
booted up Mac OS 10.2 with Stefan's command options using a professionally made 
CD, and it worked. I then did the same test again using a burned CD-R disc and 
it also worked. The last test I did was just listing the files from OpenBIOS 
using this: qemu-system-ppc -drive 
if=ide,media=cdrom,cache=none,file=/dev/cdrom. All tests were a success. 

Mac OS 10.2 panicked while booting in the original test using Stefan's command. 
I remember the panic happened about a minute into the boot process, so it could 
have been a guest issue rather than a QEMU issue. Either way everything is 
working now.