Re: [Qemu-devel] [v2] tftp: fake support for netascii protocol

[Thomas Huth]

On 20.11.2016 09:41, Vincent Bernat wrote:
> From: Vincent Bernat 
> 
> Some network equipments are requesting a file using the netascii
> protocol and this is not configurable. Currently, qemu's tftpd only
> supports the octet protocol. This commit makes it accept the netascii
> protocol as well but do not perform the requested transformation (LF ->
> CR,LF) as it would be far more complex. The current implementation is
> good enough. A user has always the choice to preencode the served file
> correctly.
> 
> Signed-off-by: Vincent Bernat 
> ---
>  slirp/tftp.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/slirp/tftp.c b/slirp/tftp.c
> index c1859066ccb2..6907d5b92074 100644
> --- a/slirp/tftp.c
> +++ b/slirp/tftp.c
> @@ -26,6 +26,7 @@
>  #include "slirp.h"
>  #include "qemu-common.h"
>  #include "qemu/cutils.h"
> +#include "qemu/log.h"
>  
>  static inline int tftp_session_in_use(struct tftp_session *spt)
>  {
> @@ -326,13 +327,17 @@ static void tftp_handle_rrq(Slirp *slirp, struct 
> sockaddr_storage *srcsas,
>  return;
>}
>  
> -  if (strcasecmp(>x.tp_buf[k], "octet") != 0) {
> +  if (strcasecmp(>x.tp_buf[k], "octet") == 0) {
> +  k += 6;
> +  } else if (strcasecmp(>x.tp_buf[k], "netascii") == 0) {
> +  qemu_log_mask(LOG_UNIMP, "tftp: netascii protocol not implemented, "
> +"no CR-LF conversion\n");
> +  k += 9;
> +  } else {
>tftp_send_error(spt, 4, "Unsupported transfer mode", tp);
>return;
>}
>  
> -  k += 6; /* skipping octet */
> -
>/* do sanity checks on the filename */
>if (!strncmp(req_fname, "../", 3) ||
>req_fname[strlen(req_fname) - 1] == '/' ||
> 

Reviewed-by: Thomas Huth 

[Qemu-devel] 答复： Re: About vNVDIMM question in TCG

[Lin Ma]

You've been very helpful, haozhong, Thanks for your comments, I appreciate.

>>> Haozhong Zhang  2016/11/21 星期一 上午 10:55 >>>
On 11/20/16 10:58 -0700, Lin Ma wrote:
>Hi Guangrong,
>
>I'm interested in vNVDIMM on qemu. I'd like to give it a try on my laptop.
>Because I dont have skylake server hardware, So I want to expose cpu flags
>clflushopt, clwb and pcommit to guest for NVDIMM drivers on TCG.
>
>I saw clflushopt and clwb feature flags in cpuinfo of guest, but no pcommit.
>Could you please tell me is there anyhing wrong in my qemu CLI or anything
>I misunderstand?

pcommit had been deprecated (see KVM commit
dfa169bbee00671288df25f8ef8a2f6e13fe2581), so it's correct to not have
it in guest.

>
>qemu-system-x86_64 \
>-cpu Skylake-Client,+pcommit,+clflushopt,+clwb \
>-machine pc-i440fx-2.8,nvdimm=on,accel=tcg \
>-m 4G,maxmem=... \
>-object memory-backend-file,... \
>-device nvdimm,... \
>
>BTW, In kvm mode, Even if I used '-cpu qemu64' without flags pcommit,
>clflushopt and clwb, The block device /dev/pmem0 is still there and can
>be used successfully. Does it make sense? Doesn't nvdimm kernel driver
>need pcommit, clflushopt and clwb to work?
>

If my memory is correct, Linux NVDIMM driver will fallback to clflush
when neither clflushopt nor clwb is available.

Haozhong

Re: [Qemu-devel] [PATCH] block/mirror: enable detect zeroes when driving mirror

[Vasiliy Tolstov]

21 Ноя 2016 г. 4:27 пользователь "Yang Wei"  написал:
>
> In order to preserve sparse disk image, detect_zeroes
> should also be enabled when bdrv_get_block_status_above()
> returns BDRV_BLOCK_DATA
>
> Signed-off-by: Yang Wei 
> ---

Hi, does this patch fixes bug
https://bugzilla.redhat.com/show_bug.cgi?id=1219541 ? Or it unrelated to
this issue?

>  block/mirror.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/block/mirror.c b/block/mirror.c
> index b2c1fb8..8b20b7a 100644
> --- a/block/mirror.c
> +++ b/block/mirror.c
> @@ -76,6 +76,7 @@ typedef struct MirrorOp {
>  QEMUIOVector qiov;
>  int64_t sector_num;
>  int nb_sectors;
> +BlockdevDetectZeroesOptions backup_detect_zeroes;
>  } MirrorOp;
>
>  static BlockErrorAction mirror_error_action(MirrorBlockJob *s, bool read,
> @@ -132,6 +133,8 @@ static void mirror_write_complete(void *opaque, int
ret)
>  {
>  MirrorOp *op = opaque;
>  MirrorBlockJob *s = op->s;
> +BlockDriverState *target = s->target;
> +target->detect_zeroes = op->backup_detect_zeroes;
>  if (ret < 0) {
>  BlockErrorAction action;
>
> @@ -148,6 +151,7 @@ static void mirror_read_complete(void *opaque, int
ret)
>  {
>  MirrorOp *op = opaque;
>  MirrorBlockJob *s = op->s;
> +BlockDriverState *target = s->target;
>  if (ret < 0) {
>  BlockErrorAction action;
>
> @@ -160,6 +164,9 @@ static void mirror_read_complete(void *opaque, int
ret)
>  mirror_iteration_done(op, ret);
>  return;
>  }
> +op->backup_detect_zeroes = target->detect_zeroes;
> +target->detect_zeroes = s->unmap ?
BLOCKDEV_DETECT_ZEROES_OPTIONS_UNMAP :
> +BLOCKDEV_DETECT_ZEROES_OPTIONS_ON;
>  blk_aio_pwritev(s->target, op->sector_num * BDRV_SECTOR_SIZE,
>qiov,
>  0, mirror_write_complete, op);
>  }
> --
> 2.10.2
>
>

Re: [Qemu-devel] [PATCH 12/18] migration: add postcopy migration of dirty bitmaps

[Vladimir Sementsov-Ogievskiy]

04.11.2016 16:09, Juan Quintela wrote:

Vladimir Sementsov-Ogievskiy  wrote:

Postcopy migration of dirty bitmaps. Only named dirty bitmaps,
associated with root nodes and non-root named nodes are migrated.

If destination qemu is already containing a dirty bitmap with the same name
as a migrated bitmap (for the same node), than, if their granularities are
the same the migration will be done, otherwise the error will be generated.

If destination qemu doesn't contain such bitmap it will be created.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
diff --git a/migration/block-dirty-bitmap.c b/migration/block-dirty-bitmap.c
new file mode 100644
index 000..c668d02
--- /dev/null
+++ b/migration/block-dirty-bitmap.c
@@ -0,0 +1,699 @@
+/*
+ * QEMU dirty bitmap migration
+ *
+ * Postcopy migration of dirty bitmaps. Only named dirty bitmaps, associated
+ * with root nodes and non-root named nodes are migrated.
+ *
+ * If destination qemu is already containing a dirty bitmap with the same name
+ * as a migrated bitmap (for the same node), than, if their granularities are
+ * the same the migration will be done, otherwise the error will be generated.
+ *
+ * If destination qemu doesn't contain such bitmap it will be created.
+ *
+ * format of migration:
+ *
+ * # Header (shared for different chunk types)
+ * 1, 2 or 4 bytes: flags (see qemu_{put,put}_flags)
+ * [ 1 byte: node name size ] \  flags & DEVICE_NAME
+ * [ n bytes: node name ] /
+ * [ 1 byte: bitmap name size ] \  flags & BITMAP_NAME
+ * [ n bytes: bitmap name ] /
+ *
+ * # Start of bitmap migration (flags & START)
+ * header
+ * be64: granularity
+ * 1 byte: bitmap enabled flag
+ *
+ * # Complete of bitmap migration (flags & COMPLETE)
+ * header
+ *
+ * # Data chunk of bitmap migration
+ * header
+ * be64: start sector
+ * be32: number of sectors
+ * [ be64: buffer size  ] \ ! (flags & ZEROES)
+ * [ n bytes: buffer] /
+ *
+ * The last chunk in stream should contain flags & EOS. The chunk may skip
+ * device and/or bitmap names, assuming them to be the same with the previous
+ * chunk.
+ *
+ *
+ * This file is derived from migration/block.c
+ *
+ * Author:
+ * Vladimir Sementsov-Ogievskiy 
+ *
+ * original copyright message:
+ * =
+ * Copyright IBM, Corp. 2009
+ *
+ * Authors:
+ *  Liran Schour   
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Contributions after 2012-01-13 are licensed under the terms of the
+ * GNU GPL, version 2 or (at your option) any later version.
+ * =
+ */

I think that the normal practice is putting first the copyright and then
the comment of the file.


+static void qemu_put_bitmap_flags(QEMUFile *f, uint32_t flags)
+{
+if (!(flags & 0xff00)) {
+qemu_put_byte(f, flags);
+return;
+}
+
+if (!(flags & 0x)) {
+qemu_put_be16(f, flags | DIRTY_BITMAP_MIG_FLAGS_SIZE_16);
+return;
+}
+
+qemu_put_be32(f, flags | DIRTY_BITMAP_MIG_FLAGS_SIZE_32);
+}

Do need flags so many times to be a good idea to spend two flags and
make the code more complex?  Couldn't just sent always the 32bit word
and call it a day?


I've started with one byte of flags (I don't need more) and I've 
implemented this after proposal by John Snow:
I might recommend reserving the last bit of the second byte to be a 
flag such as DIRTY_BITMAP_EXTRA_FLAGS that indicates the presence of 
additional byte(s) of flags, to be determined later, if we ever need 
them, but two bytes for now should be sufficient.


And I think it is not bad. Code is a bit more complex, yes, but why 
should we send 4 bytes with every chunk when (very likely) we will never 
use more than one?




I have only looked at the stuff quickly from the migration point of
view, not about the bitmap stuff.


+static void send_bitmap_complete(QEMUFile *f, DirtyBitmapMigBitmapState *dbms)
+{
+send_bitmap_header(f, dbms, DIRTY_BITMAP_MIG_FLAG_COMPLETE);
+}
+
+static void send_bitmap_bits(QEMUFile *f, DirtyBitmapMigBitmapState *dbms,
+ uint64_t start_sector, uint32_t nr_sectors)
+{
+/* align for buffer_is_zero() */
+uint64_t align = 4 * sizeof(long);
+uint64_t unaligned_size =
+bdrv_dirty_bitmap_serialization_size(dbms->bitmap,
+ start_sector, nr_sectors);
+uint64_t buf_size = (unaligned_size + align - 1) & ~(align - 1);
+uint8_t *buf = g_malloc0(buf_size);
+uint32_t flags = DIRTY_BITMAP_MIG_FLAG_BITS;
+
+bdrv_dirty_bitmap_serialize_part(dbms->bitmap, buf,
+ start_sector, nr_sectors);
+
+if (buffer_is_zero(buf, buf_size)) {
+g_free(buf);
+buf = NULL;
+

[Qemu-devel] qobject/qjson.c:69: failed assertion `obj != NULL'

[G 3]

When I try to use qemu-system-i386, I see this error message:

qobject/qjson.c:69: failed assertion `obj != NULL'.

This is the function where the assertion fails:

/*
 * IMPORTANT: This function aborts on error, thus it must not
 * be used with untrusted arguments.
 */
QObject *qobject_from_jsonf(const char *string, ...)
{
QObject *obj;
va_list ap;

va_start(ap, string);
obj = qobject_from_jsonv(string, );
va_end(ap);

assert(obj != NULL);
return obj;
}

The string argument is this: { 'seconds': %qd, 'microseconds': %qd }

Would anyone know how to fix this problem?

Re: [Qemu-devel] [PATCH] vfio: avoid adding same iommu mr for notify

[Peter Xu]

On Thu, Nov 17, 2016 at 02:24:54PM +1100, David Gibson wrote:
> On Mon, Nov 14, 2016 at 07:59:28PM -0500, Peter Xu wrote:
> > When one IOMMU memory region is splitted into multiple memory sections,
> > vfio will register multiple same notifiers to a vIOMMU for the same
> > region. That's not sensible. What we need is to register one IOMMU
> > notifier for each IOMMU region, not per section.
> > 
> > Solution is simple - we traverse the container->giommu_list, and skip
> > the registration if memory region is already registered.
> > 
> > To make vfio's region_add() short, vfio_listener_region_add_iommu() is
> > introduced.
> > 
> > Signed-off-by: Peter Xu 
> 
> This is wrong.  It will work on the register side, but when the first
> section attached to the IOMMU is removed, the IOMMU will be removed
> from the list (triggering an unmap of the whole vfio space), rather
> than when the *last* section attached to the MR is removed.
> 
> You'll get away with it in the simple x86 case, because both sections
> will be removed at basically the same time, but it's not correct in
> general.

Hmm, I got your point. Instead of keeping multiple VFIOGuestIOMMU as
you have mentioned previous (and below), IMHO another choice is to
have a reference count for each VFIOGuestIOMMU.

> 
> I really think a better approach is to add the section boundary
> information to the IOMMUNotifier structure within VFIOGuestIOMMU, and
> check that as well as the MR on remove.  That additionally means the
> IOMMU notifier won't get called for portions of the MR outside the
> mapped sections, which the notifier handler probably isn't going to
> expect.

Here, the problem is: what we want to listen to here. IMHO, here what
we are trying to listen to is memory region, not memory region
section. In that case, keeping multiple VFIOGuestIOMMU object is
awkward. I would prefer to have a VFIOGuestIOMMU.refcount field as
mentioned above, then:

- inc() every time the IOMMU memory region is added,
- dec() every time the IOMMU memory region is removed,
- free() when dec() == 0

Thanks,

-- peterx

Re: [Qemu-devel] [PATCH v2] docs: add document to explain the usage of vNVDIMM

[Haozhong Zhang]

On 11/09/16 12:35 +, Stefan Hajnoczi wrote:

On Wed, Nov 09, 2016 at 09:04:48AM +0800, Haozhong Zhang wrote:

Signed-off-by: Haozhong Zhang 
Reviewed-by: Xiao Guangrong 
Reviewed-by: Stefan Hajnoczi 
---
Changes since v1:
* explicitly state the block window mode is not supported (Stefan Hajnoczi)
* typo fix: label_size ==> label-size (David Alan Gilbert)
---
 docs/nvdimm.txt | 124 
 1 file changed, 124 insertions(+)
 create mode 100644 docs/nvdimm.txt


Great.  This patch can go through Michael Tsirkin's tree alongside the
other current nvdimm patches.


Hi Stefan and Michael,

I noticed that Guangrong's patches had all been checked in. Will this
doc patch be included in 2.8?

Thanks,
Haozhong

Re: [Qemu-devel] [PATCH 0/5] Last minute ppc migration fixes

[David Gibson]

On Mon, Nov 21, 2016 at 03:58:31PM +1100, David Gibson wrote:
> Unfortunately, a bug already slipped into the qemu-2.7 release which
> breaks migration of the pseries-2.6 machine type from qemu v2.6.0 to
> qemu v2.7.0.  That bug also breaks migration from v2.6.0 to current
> master.  In addition there have been several more changes which have
> inadvertently broken migration from v2.7.0 to current master for both
> pseries-2.6 and pseries-2.7 machine types.
> 
> One of those was fixed - in a way - by 9b54ca0, however it was done in
> such a way as to break backwards migration from current master to
> v2.7.0.  It turns out that supporting backwards migration is more
> important than I realized at the time.
> 
> So, this series contains several fixes for migration.  Between them,
> they allow migration both forwards and backwards between qemu v2.6.0
> and current master (and therefore, I hope, v2.8.0).
> 
> Unfortunately, because of the already released bug, there's no
> reasonable way to fix migration from current master back to v2.7.0 as
> well, and, obviously, no way at all to fix the existing breakage
> between v2.6.0 and v2.7.0.  However, I'm also hoping to get patch 1/5
> of this series applied to the 2.7 stable branch.  If that happens, it
> should be possible to freely migrate between v2.6.0, v2.7.1 and
> current master / 2.8, which is about the best we can hope for.
> 
> I've done basic testing of these with all the combinations of source
> and destination being either v2.6.0, v2.7.0 + patch 1/5 and
> ppc-for-2.8 + this series, and with all the applicable machine types
> for each of those combinations.  Each test was with just a basic
> default hardware setup, running a RHEL7.3 guest, no fancier
> combinations.
> 
> Dave, could you please sanity check my compatibility sheanningans and
> send an R-b (and an acked-by for patch 2/5, which isn't strictly ppc
> related).
> 
> Michael, if you could test this on any combinations that occur to you,
> that would be most helpful.
> 
> I'm hoping to get some reviews and squeeze this into v2.8.0, which
> will mean a pull request within a couple of days.

Bother, just realised I left a chunk of debug code in there.  Will
resend momentarily.

> 
> David Gibson (5): target-ppc: Fix CPU migration from qemu-2.6 <->
>   later versions migration: Add VMSTATE_UINTTL_TEST() target-ppc:
>   Allow eventual removal of old migration mistakes Revert "spapr: Fix
>   migration of PCI host bridges from qemu-2.7" spapr: Fix 2.7<->2.8
>   migration of PCI host bridge
> 
>  hw/ppc/spapr.c  | 10 +
>  hw/ppc/spapr_pci.c  | 35 +
>  include/hw/pci-host/spapr.h |  6 +
>  include/migration/cpu.h |  4 
>  target-ppc/cpu.h|  7 ++
>  target-ppc/machine.c| 55 
> +
>  target-ppc/translate_init.c |  6 +
>  7 files changed, 110 insertions(+), 13 deletions(-)
> 

-- 
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


signature.asc
Description: PGP signature

[Qemu-devel] [PATCHv2 5/5] spapr: Fix 2.7<->2.8 migration of PCI host bridge

[David Gibson]

daa2369 "spapr_pci: Add a 64-bit MMIO window" subtly broke migration
from qemu-2.7 to the current version.  It split the device's MMIO
window into two pieces for 32-bit and 64-bit MMIO.

The patch included backwards compatibility code to convert the old
property into the new format.  However, the property value was also
transferred in the migration stream and compared with a (probably
unwise) VMSTATE_EQUAL.  So, the "raw" value from 2.7 is compared to
the new style converted value from (pre-)2.8 giving a mismatch and
migration failure.

Along with the actual field that caused the breakage, there are
several other ill-advised VMSTATE_EQUAL()s.  To fix forwards
migration, we read the values in the stream into scratch variables and
ignore them, instead of comparing for equality.  To fix backwards
migration, we populate those scratch variables in pre_save() with
adjusted values to match the old behaviour.

To permit the eventual possibility of removing this cruft from the
stream, we only include these compatibility fields if a new
'pre-2.8-migration' property is set.  We clear it on the pseries-2.8
machine type, which obviously can't be migrated backwards, but set it
on earlier machine type versions.

Signed-off-by: David Gibson 
---
 hw/ppc/spapr.c  |  5 +
 hw/ppc/spapr_pci.c  | 33 -
 include/hw/pci-host/spapr.h |  6 ++
 3 files changed, 39 insertions(+), 5 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 775ad2e..c3269c7 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2772,6 +2772,11 @@ DEFINE_SPAPR_MACHINE(2_8, "2.8", true);
 .driver = TYPE_POWERPC_CPU, \
 .property = "pre-2.8-migration",\
 .value= "on",   \
+},  \
+{   \
+.driver = TYPE_SPAPR_PCI_HOST_BRIDGE,   \
+.property = "pre-2.8-migration",\
+.value= "on",   \
 },
 
 static void phb_placement_2_7(sPAPRMachineState *spapr, uint32_t index,
diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
index e429c94..c62c1cb 100644
--- a/hw/ppc/spapr_pci.c
+++ b/hw/ppc/spapr_pci.c
@@ -1590,6 +1590,8 @@ static Property spapr_phb_properties[] = {
 DEFINE_PROP_UINT64("pgsz", sPAPRPHBState, page_size_mask,
(1ULL << 12) | (1ULL << 16)),
 DEFINE_PROP_UINT32("numa_node", sPAPRPHBState, numa_node, -1),
+DEFINE_PROP_BOOL("pre-2.8-migration", sPAPRPHBState,
+ pre_2_8_migration, false),
 DEFINE_PROP_END_OF_LIST(),
 };
 
@@ -1636,6 +1638,20 @@ static void spapr_pci_pre_save(void *opaque)
 sphb->msi_devs[i].key = *(uint32_t *) key;
 sphb->msi_devs[i].value = *(spapr_pci_msi *) value;
 }
+
+if (sphb->pre_2_8_migration) {
+sphb->mig_liobn = sphb->dma_liobn[0];
+sphb->mig_mem_win_addr = sphb->mem_win_addr;
+sphb->mig_mem_win_size = sphb->mem_win_size;
+sphb->mig_io_win_addr = sphb->io_win_addr;
+sphb->mig_io_win_size = sphb->io_win_size;
+
+if ((sphb->mem64_win_size != 0)
+&& (sphb->mem64_win_addr
+== (sphb->mem_win_addr + sphb->mem_win_size))) {
+sphb->mig_mem_win_size += sphb->mem64_win_size;
+}
+}
 }
 
 /*
@@ -1680,6 +1696,13 @@ static int spapr_pci_post_load(void *opaque, int 
version_id)
 return 0;
 }
 
+static bool pre_2_8_migration(void *opaque, int version_id)
+{
+sPAPRPHBState *sphb = opaque;
+
+return sphb->pre_2_8_migration;
+}
+
 static const VMStateDescription vmstate_spapr_pci = {
 .name = "spapr_pci",
 .version_id = 2,
@@ -1688,11 +1711,11 @@ static const VMStateDescription vmstate_spapr_pci = {
 .post_load = spapr_pci_post_load,
 .fields = (VMStateField[]) {
 VMSTATE_UINT64_EQUAL(buid, sPAPRPHBState),
-VMSTATE_UINT32_EQUAL(dma_liobn[0], sPAPRPHBState),
-VMSTATE_UINT64_EQUAL(mem_win_addr, sPAPRPHBState),
-VMSTATE_UINT64_EQUAL(mem_win_size, sPAPRPHBState),
-VMSTATE_UINT64_EQUAL(io_win_addr, sPAPRPHBState),
-VMSTATE_UINT64_EQUAL(io_win_size, sPAPRPHBState),
+VMSTATE_UINT32_TEST(mig_liobn, sPAPRPHBState, pre_2_8_migration),
+VMSTATE_UINT64_TEST(mig_mem_win_addr, sPAPRPHBState, 
pre_2_8_migration),
+VMSTATE_UINT64_TEST(mig_mem_win_size, sPAPRPHBState, 
pre_2_8_migration),
+VMSTATE_UINT64_TEST(mig_io_win_addr, sPAPRPHBState, pre_2_8_migration),
+VMSTATE_UINT64_TEST(mig_io_win_size, sPAPRPHBState, pre_2_8_migration),
 VMSTATE_STRUCT_ARRAY(lsi_table, sPAPRPHBState, PCI_NUM_PINS, 0,
  vmstate_spapr_pci_lsi, struct spapr_pci_lsi),
 VMSTATE_INT32(msi_devs_num, sPAPRPHBState),
diff --git a/include/hw/pci-host/spapr.h b/include/hw/pci-host/spapr.h
index b92c1b5..092294e 100644
--- 

[Qemu-devel] [PATCHv2 3/5] target-ppc: Allow eventual removal of old migration mistakes

[David Gibson]

Until very recently, the vmstate for ppc cpus included some poorly
thought out VMSTATE_EQUAL() components, that can easily break
migration compatibility, and did so between qemu-2.6 and later
versions.  A hack was recently added which fixes this migration
breakage, but it leaves the unhelpful cruft of these fields in the
migration stream.

dThis patch adds a new cpu property allowing these fields to be
removed from the stream entirely.  This property is enabled by default
for the pseries-2.8 machine type - which comes after the fix - and for
all non-pseries machine types - which aren't mature enough to care
about cross-version migration.

The migration hack remains in place for pseries-2.7 and earlier
machine types, allowing backwards and forwards migration with the
older machine types.

This restricts the migration compatibility cruft to older machine
types, and at least opens the possibility of eventually deprecating
and removing it entirely.

Signed-off-by: David Gibson 
---
 hw/ppc/spapr.c  |  5 +
 target-ppc/cpu.h|  3 ++-
 target-ppc/machine.c| 26 ++
 target-ppc/translate_init.c |  6 ++
 4 files changed, 31 insertions(+), 9 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 54b88d3..775ad2e 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2767,6 +2767,11 @@ DEFINE_SPAPR_MACHINE(2_8, "2.8", true);
 .driver   = TYPE_SPAPR_PCI_HOST_BRIDGE, \
 .property = "mem64_win_size",   \
 .value= "0",\
+},  \
+{   \
+.driver = TYPE_POWERPC_CPU, \
+.property = "pre-2.8-migration",\
+.value= "on",   \
 },
 
 static void phb_placement_2_7(sPAPRMachineState *spapr, uint32_t index,
diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 7798b2e..2a50c43 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -1167,7 +1167,8 @@ struct PowerPCCPU {
 uint32_t max_compat;
 uint32_t cpu_version;
 
-/* fields used only during migration for compatibility hacks */
+/* Fields related to migration compatibility hacks */
+bool pre_2_8_migration;
 target_ulong mig_msr_mask;
 uint64_t mig_insns_flags;
 uint64_t mig_insns_flags2;
diff --git a/target-ppc/machine.c b/target-ppc/machine.c
index fcac263..18c16d2 100644
--- a/target-ppc/machine.c
+++ b/target-ppc/machine.c
@@ -135,6 +135,13 @@ static const VMStateInfo vmstate_info_avr = {
 #define VMSTATE_AVR_ARRAY(_f, _s, _n) \
 VMSTATE_AVR_ARRAY_V(_f, _s, _n, 0)
 
+static bool cpu_pre_2_8_migration(void *opaque, int version_id)
+{
+PowerPCCPU *cpu = opaque;
+
+return cpu->pre_2_8_migration;
+}
+
 static void cpu_pre_save(void *opaque)
 {
 PowerPCCPU *cpu = opaque;
@@ -178,10 +185,12 @@ static void cpu_pre_save(void *opaque)
 }
 
 /* Hacks for migration compatibility between 2.6, 2.7 & 2.8 */
-cpu->mig_msr_mask = env->msr_mask;
-cpu->mig_insns_flags = env->insns_flags & insns_compat_mask;
-cpu->mig_insns_flags2 = env->insns_flags2 & insns_compat_mask2;
-cpu->mig_nb_BATs = env->nb_BATs;
+if (cpu->pre_2_8_migration) {
+cpu->mig_msr_mask = env->msr_mask;
+cpu->mig_insns_flags = env->insns_flags & insns_compat_mask;
+cpu->mig_insns_flags2 = env->insns_flags2 & insns_compat_mask2;
+cpu->mig_nb_BATs = env->nb_BATs;
+}
 }
 
 static int cpu_post_load(void *opaque, int version_id)
@@ -582,10 +591,11 @@ const VMStateDescription vmstate_ppc_cpu = {
 /* FIXME: access_type? */
 
 /* Sanity checking */
-VMSTATE_UINTTL(mig_msr_mask, PowerPCCPU),
-VMSTATE_UINT64(mig_insns_flags, PowerPCCPU),
-VMSTATE_UINT64(mig_insns_flags2, PowerPCCPU),
-VMSTATE_UINT32(mig_nb_BATs, PowerPCCPU),
+VMSTATE_UINTTL_TEST(mig_msr_mask, PowerPCCPU, cpu_pre_2_8_migration),
+VMSTATE_UINT64_TEST(mig_insns_flags, PowerPCCPU, 
cpu_pre_2_8_migration),
+VMSTATE_UINT64_TEST(mig_insns_flags2, PowerPCCPU,
+cpu_pre_2_8_migration),
+VMSTATE_UINT32_TEST(mig_nb_BATs, PowerPCCPU, cpu_pre_2_8_migration),
 VMSTATE_END_OF_LIST()
 },
 .subsections = (const VMStateDescription*[]) {
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 208fa1e..626e031 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -10520,6 +10520,11 @@ static gchar *ppc_gdb_arch_name(CPUState *cs)
 #endif
 }
 
+static Property ppc_cpu_properties[] = {
+DEFINE_PROP_BOOL("pre-2.8-migration", PowerPCCPU, pre_2_8_migration, 
false),
+DEFINE_PROP_END_OF_LIST(),
+};
+
 static void ppc_cpu_class_init(ObjectClass *oc, void *data)
 {
 PowerPCCPUClass *pcc = POWERPC_CPU_CLASS(oc);
@@ -10532,6 +10537,7 @@ static 

[Qemu-devel] [PATCHv2 2/5] migration: Add VMSTATE_UINTTL_TEST()

[David Gibson]

include/migration/cpu.h defines VMSTATE_UINTTL() and several variants
for migrating target_ulong fields.  It's defined in terms of
VMSTATE_UINT32() or VMSTATE_UINT64() as appropriate.

It doesn't, however, include a VMSTATE_UINTTL_TEST() variant, which
I'm going to need shortly.  So, add it.

Signed-off-by: David Gibson 
---
 include/migration/cpu.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/migration/cpu.h b/include/migration/cpu.h
index f3abbab..f3d5dfc 100644
--- a/include/migration/cpu.h
+++ b/include/migration/cpu.h
@@ -18,6 +18,8 @@
 VMSTATE_UINT64_EQUAL_V(_f, _s, _v)
 #define VMSTATE_UINTTL_ARRAY_V(_f, _s, _n, _v)\
 VMSTATE_UINT64_ARRAY_V(_f, _s, _n, _v)
+#define VMSTATE_UINTTL_TEST(_f, _s, _t)   \
+VMSTATE_UINT64_TEST(_f, _s, _t)
 #define vmstate_info_uinttl vmstate_info_uint64
 #else
 #define qemu_put_betl qemu_put_be32
@@ -35,6 +37,8 @@
 VMSTATE_UINT32_EQUAL_V(_f, _s, _v)
 #define VMSTATE_UINTTL_ARRAY_V(_f, _s, _n, _v)\
 VMSTATE_UINT32_ARRAY_V(_f, _s, _n, _v)
+#define VMSTATE_UINTTL_TEST(_f, _s, _t)   \
+VMSTATE_UINT32_TEST(_f, _s, _t)
 #define vmstate_info_uinttl vmstate_info_uint32
 #endif
 
-- 
2.7.4

[Qemu-devel] [PATCHv2 4/5] Revert "spapr: Fix migration of PCI host bridges from qemu-2.7"

[David Gibson]

This reverts commit 9b54ca0ba781012eeea4237b7c4832ba2ea81d89.

The commit above corrected a migration breakage between qemu-2.7 and
qemu-2.8.  However it did so by advancing the migration version for
the PCI host bridge, which obviously breaks migration backwards to
earlier qemu versions.

Although it's not totally essential, we'd like to maintain the
possibility for backwards migration, so revert the change in
preparation for a better fix.

Signed-off-by: David Gibson 
---
 hw/ppc/spapr_pci.c | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
index 661f7d8..e429c94 100644
--- a/hw/ppc/spapr_pci.c
+++ b/hw/ppc/spapr_pci.c
@@ -1680,25 +1680,19 @@ static int spapr_pci_post_load(void *opaque, int 
version_id)
 return 0;
 }
 
-static bool version_before_3(void *opaque, int version_id)
-{
-return version_id < 3;
-}
-
 static const VMStateDescription vmstate_spapr_pci = {
 .name = "spapr_pci",
-.version_id = 3,
+.version_id = 2,
 .minimum_version_id = 2,
 .pre_save = spapr_pci_pre_save,
 .post_load = spapr_pci_post_load,
 .fields = (VMStateField[]) {
 VMSTATE_UINT64_EQUAL(buid, sPAPRPHBState),
-VMSTATE_UNUSED_TEST(version_before_3,
-sizeof(uint32_t) /* dma_liobn[0] */
-+ sizeof(uint64_t) /* mem_win_addr */
-+ sizeof(uint64_t) /* mem_win_size */
-+ sizeof(uint64_t) /* io_win_addr */
-+ sizeof(uint64_t) /* io_win_size */),
+VMSTATE_UINT32_EQUAL(dma_liobn[0], sPAPRPHBState),
+VMSTATE_UINT64_EQUAL(mem_win_addr, sPAPRPHBState),
+VMSTATE_UINT64_EQUAL(mem_win_size, sPAPRPHBState),
+VMSTATE_UINT64_EQUAL(io_win_addr, sPAPRPHBState),
+VMSTATE_UINT64_EQUAL(io_win_size, sPAPRPHBState),
 VMSTATE_STRUCT_ARRAY(lsi_table, sPAPRPHBState, PCI_NUM_PINS, 0,
  vmstate_spapr_pci_lsi, struct spapr_pci_lsi),
 VMSTATE_INT32(msi_devs_num, sPAPRPHBState),
-- 
2.7.4

[Qemu-devel] [PATCHv2 1/5] target-ppc: Fix CPU migration from qemu-2.6 <-> later versions

[David Gibson]

When migration for target-ppc was converted to vmstate, several
VMSTATE_EQUAL() checks were foolishly included of things that really
should be internal state.  Specifically we verified equality of the
insns_flags and insns_flags2 fields, which are used within TCG to
determine which groups of instructions are available on this cpu
model.  Between qemu-2.6 and qemu-2.7 we made some changes to these
classes which broke migration.

This path fixes migration both forwards and backwards.  On migration
from 2.6 to later versions we import the fields into teporary
variables, which we then ignore.  In migration backwards, we populate
the temporary fields from the runtime fields, but mask out the bits
which were added after qemu-2.6, allowing the VMSTATE_EQUAL in
qemu-2.6 to accept the stream.

Signed-off-by: David Gibson 
---
 target-ppc/cpu.h |  6 ++
 target-ppc/machine.c | 29 +
 2 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 1c90adb..7798b2e 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -1166,6 +1166,12 @@ struct PowerPCCPU {
 int cpu_dt_id;
 uint32_t max_compat;
 uint32_t cpu_version;
+
+/* fields used only during migration for compatibility hacks */
+target_ulong mig_msr_mask;
+uint64_t mig_insns_flags;
+uint64_t mig_insns_flags2;
+uint32_t mig_nb_BATs;
 };
 
 static inline PowerPCCPU *ppc_env_get_cpu(CPUPPCState *env)
diff --git a/target-ppc/machine.c b/target-ppc/machine.c
index e43cb6c..fcac263 100644
--- a/target-ppc/machine.c
+++ b/target-ppc/machine.c
@@ -140,6 +140,21 @@ static void cpu_pre_save(void *opaque)
 PowerPCCPU *cpu = opaque;
 CPUPPCState *env = >env;
 int i;
+uint64_t insns_compat_mask =
+PPC_INSNS_BASE | PPC_ISEL | PPC_STRING | PPC_MFTB
+| PPC_FLOAT | PPC_FLOAT_FSEL | PPC_FLOAT_FRES
+| PPC_FLOAT_FSQRT | PPC_FLOAT_FRSQRTE | PPC_FLOAT_FRSQRTES
+| PPC_FLOAT_STFIWX | PPC_FLOAT_EXT
+| PPC_CACHE | PPC_CACHE_ICBI | PPC_CACHE_DCBZ
+| PPC_MEM_SYNC | PPC_MEM_EIEIO | PPC_MEM_TLBIE | PPC_MEM_TLBSYNC
+| PPC_64B | PPC_64BX | PPC_ALTIVEC
+| PPC_SEGMENT_64B | PPC_SLBI | PPC_POPCNTB | PPC_POPCNTWD;
+uint64_t insns_compat_mask2 = PPC2_VSX | PPC2_VSX207 | PPC2_DFP | PPC2_DBRX
+| PPC2_PERM_ISA206 | PPC2_DIVE_ISA206
+| PPC2_ATOMIC_ISA206 | PPC2_FP_CVT_ISA206
+| PPC2_FP_TST_ISA206 | PPC2_BCTAR_ISA207
+| PPC2_LSQ_ISA207 | PPC2_ALTIVEC_207
+| PPC2_ISA205 | PPC2_ISA207S | PPC2_FP_CVT_S64 | PPC2_TM;
 
 env->spr[SPR_LR] = env->lr;
 env->spr[SPR_CTR] = env->ctr;
@@ -161,6 +176,12 @@ static void cpu_pre_save(void *opaque)
 env->spr[SPR_IBAT4U + 2*i] = env->IBAT[0][i+4];
 env->spr[SPR_IBAT4U + 2*i + 1] = env->IBAT[1][i+4];
 }
+
+/* Hacks for migration compatibility between 2.6, 2.7 & 2.8 */
+cpu->mig_msr_mask = env->msr_mask;
+cpu->mig_insns_flags = env->insns_flags & insns_compat_mask;
+cpu->mig_insns_flags2 = env->insns_flags2 & insns_compat_mask2;
+cpu->mig_nb_BATs = env->nb_BATs;
 }
 
 static int cpu_post_load(void *opaque, int version_id)
@@ -561,10 +582,10 @@ const VMStateDescription vmstate_ppc_cpu = {
 /* FIXME: access_type? */
 
 /* Sanity checking */
-VMSTATE_UINTTL_EQUAL(env.msr_mask, PowerPCCPU),
-VMSTATE_UINT64_EQUAL(env.insns_flags, PowerPCCPU),
-VMSTATE_UINT64_EQUAL(env.insns_flags2, PowerPCCPU),
-VMSTATE_UINT32_EQUAL(env.nb_BATs, PowerPCCPU),
+VMSTATE_UINTTL(mig_msr_mask, PowerPCCPU),
+VMSTATE_UINT64(mig_insns_flags, PowerPCCPU),
+VMSTATE_UINT64(mig_insns_flags2, PowerPCCPU),
+VMSTATE_UINT32(mig_nb_BATs, PowerPCCPU),
 VMSTATE_END_OF_LIST()
 },
 .subsections = (const VMStateDescription*[]) {
-- 
2.7.4

[Qemu-devel] [PATCHv2 0/5] Last minute ppc migration fixes

[David Gibson]

Unfortunately, a bug already slipped into the qemu-2.7 release which
breaks migration of the pseries-2.6 machine type from qemu v2.6.0 to
qemu v2.7.0.  That bug also breaks migration from v2.6.0 to current
master.  In addition there have been several more changes which have
inadvertently broken migration from v2.7.0 to current master for both
pseries-2.6 and pseries-2.7 machine types.

One of those was fixed - in a way - by 9b54ca0, however it was done in
such a way as to break backwards migration from current master to
v2.7.0.  It turns out that supporting backwards migration is more
important than I realized at the time.

So, this series contains several fixes for migration.  Between them,
they allow migration both forwards and backwards between qemu v2.6.0
and current master (and therefore, I hope, v2.8.0).

Unfortunately, because of the already released bug, there's no
reasonable way to fix migration from current master back to v2.7.0 as
well, and, obviously, no way at all to fix the existing breakage
between v2.6.0 and v2.7.0.  However, I'm also hoping to get patch 1/5
of this series applied to the 2.7 stable branch.  If that happens, it
should be possible to freely migrate between v2.6.0, v2.7.1 and
current master / 2.8, which is about the best we can hope for.

I've done basic testing of these with all the combinations of source
and destination being either v2.6.0, v2.7.0 + patch 1/5 and
ppc-for-2.8 + this series, and with all the applicable machine types
for each of those combinations.  Each test was with just a basic
default hardware setup, running a RHEL7.3 guest, no fancier
combinations.

Dave, could you please sanity check my compatibility sheanningans and
send an R-b (and an acked-by for patch 2/5, which isn't strictly ppc
related).

Michael, if you could test this on any combinations that occur to you,
that would be most helpful.

I'm hoping to get some reviews and squeeze this into v2.8.0, which
will mean a pull request within a couple of days.

Changes since v1:
  * Removed some debug code from 1/5
  * Fixed some trivial style errors

David Gibson (5):
  target-ppc: Fix CPU migration from qemu-2.6 <-> later versions
  migration: Add VMSTATE_UINTTL_TEST()
  target-ppc: Allow eventual removal of old migration mistakes
  Revert "spapr: Fix migration of PCI host bridges from qemu-2.7"
  spapr: Fix 2.7<->2.8 migration of PCI host bridge

 hw/ppc/spapr.c  | 10 ++
 hw/ppc/spapr_pci.c  | 35 ++-
 include/hw/pci-host/spapr.h |  6 ++
 include/migration/cpu.h |  4 
 target-ppc/cpu.h|  7 +++
 target-ppc/machine.c| 39 +++
 target-ppc/translate_init.c |  6 ++
 7 files changed, 94 insertions(+), 13 deletions(-)

-- 
2.7.4

Re: [Qemu-devel] [PATCH 10/18] migration/qemu-file: add qemu_put_counted_string()

[Vladimir Sementsov-Ogievskiy]

17.08.2016 12:09, Fam Zheng wrote:

On Tue, 08/16 13:26, Vladimir Sementsov-Ogievskiy wrote:

Add function opposite to qemu_get_counted_string.
qemu_put_counted_string puts one-byte length of the string (string
should not be longer than 255 characters), and then it puts the string,
without last zero byte.

Reviewed-by: John Snow 
Signed-off-by: Vladimir Sementsov-Ogievskiy 
---
  include/migration/qemu-file.h |  2 ++
  migration/qemu-file.c | 13 +
  2 files changed, 15 insertions(+)

diff --git a/include/migration/qemu-file.h b/include/migration/qemu-file.h
index abedd46..d860c92 100644
--- a/include/migration/qemu-file.h
+++ b/include/migration/qemu-file.h
@@ -309,4 +309,6 @@ static inline void qemu_get_sbe64s(QEMUFile *f, int64_t *pv)
  
  size_t qemu_get_counted_string(QEMUFile *f, char buf[256]);
  
+void qemu_put_counted_string(QEMUFile *f, const char *name);

+
  #endif
diff --git a/migration/qemu-file.c b/migration/qemu-file.c
index bbc565e..6fcdd68 100644
--- a/migration/qemu-file.c
+++ b/migration/qemu-file.c
@@ -690,6 +690,19 @@ size_t qemu_get_counted_string(QEMUFile *f, char buf[256])
  }
  
  /*

+ * Put a string with one preceding byte containing its length. The length of
+ * the string should be less than 256.
+ */
+void qemu_put_counted_string(QEMUFile *f, const char *name)

"Name" is a poor name. Perhaps call it "buf" like qemu_get_counted_string?


buf is poor too, as it say nothing about 0-ended string. Let it be 'str'.



Fam


+{
+size_t len = strlen(name);
+
+assert(len < 256);
+qemu_put_byte(f, len);
+qemu_put_buffer(f, (const uint8_t *)name, len);
+}
+
+/*
   * Set the blocking state of the QEMUFile.
   * Note: On some transports the OS only keeps a single blocking state for
   *   both directions, and thus changing the blocking on the main
--
1.8.3.1





--
Best regards,
Vladimir

[Qemu-devel] [PATCH v2 1/1] hw/net/spapr_llan: 6 byte mac address device tree entry

[Sam Bobroff]

The spapr-vlan device in QEMU has always presented it's MAC address in
the device tree as an 8 byte value, even though PAPR requires it to be
6 bytes.  This is because, at the time, AIX required the value to be 8
bytes.  However, modern versions of AIX support the (correct) 6
byte value so they no longer require the workaround.

It would be neatest to always provide a 6 byte value but that would
cause a problem with old Linux kernel ibmveth drivers, so the old 8
byte value is still presented when necessary.

Since commit 13f85203e (3.10, May 2013) the driver has been able to
handle 6 or 8 byte addresses so versions after that don't need to be
considered specially.

Drivers from kernels before that can also handle either type of
address, but not always:
* If the first byte's lowest bits are 10, the address must be 6 bytes.
* Otherwise, the address must be 8 bytes.
(The two bits in question are significant in a MAC address: they
indicate a locally-administered unicast address.)

So to maintain compatibility the old 8 byte value is presented when
the lowest two bits of the first byte are not 10.

Signed-off-by: Sam Bobroff 
---

v2:

Re-introduced the old workaround so that old Linux kernel drivers aren't
broken, at the cost of AIX seeing the old value for for non-locally generated
or broadcast addresses (this shouldn't matter because those addresses probably
aren't used on virtual adapters).

Reworded first paragraph of commit message because AIX seems to still support
the old 8 byte value.

 hw/net/spapr_llan.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/hw/net/spapr_llan.c b/hw/net/spapr_llan.c
index 01ecb02..b73be87 100644
--- a/hw/net/spapr_llan.c
+++ b/hw/net/spapr_llan.c
@@ -385,18 +385,24 @@ static int spapr_vlan_devnode(VIOsPAPRDevice *dev, void 
*fdt, int node_off)
 int ret;
 
 /* Some old phyp versions give the mac address in an 8-byte
- * property.  The kernel driver has an insane workaround for this;
+ * property.  The 3.10 kernel driver has an insane workaround;
  * rather than doing the obvious thing and checking the property
  * length, it checks whether the first byte has 0b10 in the low
  * bits.  If a correct 6-byte property has a different first byte
  * the kernel will get the wrong mac address, overrunning its
  * buffer in the process (read only, thank goodness).
  *
- * Here we workaround the kernel workaround by always supplying an
- * 8-byte property, with the mac address in the last six bytes */
-memcpy(_mac[2], >nicconf.macaddr, ETH_ALEN);
-ret = fdt_setprop(fdt, node_off, "local-mac-address",
-  padded_mac, sizeof(padded_mac));
+ * Here we return a 6-byte address unless that would break a 3.10 driver.
+ * In that case we return a padded 8-byte address to allow the old
+ * workaround to succeed. */
+if ((vdev->nicconf.macaddr.a[0] & 0x3) == 0x2) {
+ret = fdt_setprop(fdt, node_off, "local-mac-address",
+  >nicconf.macaddr, ETH_ALEN);
+} else {
+memcpy(_mac[2], >nicconf.macaddr, ETH_ALEN);
+ret = fdt_setprop(fdt, node_off, "local-mac-address",
+  padded_mac, sizeof(padded_mac));
+}
 if (ret < 0) {
 return ret;
 }
-- 
2.10.0.297.gf6727b0

[Qemu-devel] [PATCH 1/3] Split serial-isa into its own config option

[David Gibson]

At present, the core device model code for 8250-like serial ports
(serial.c) and the code for serial ports attached to ISA-style legacy IO
(serial-isa.c) are both controlled by the CONFIG_SERIAL variable.

There are lots and lots of embedded platforms that have 8250-like serial
ports but have never had anything resembling ISA legacy IO.  Therefore,
split serial-isa into its own CONFIG_SERIAL_ISA option so it can be
disabled for platforms where it's not appropriate.

For now, I enabled CONFIG_SERIAL_ISA in every default-config where
CONFIG_SERIAL is enabled, excepting microblaze, or32, and xtensa.  As best
as I can tell, those platforms never used legacy ISA, and also don't
include PCI support (which would allow connection of a PCI->ISA bridge
and/or a southbridge including legacy ISA serial ports).

Signed-off-by: David Gibson 
Reviewed-by: Thomas Huth 
Acked-by: Christian Borntraeger 
Reviewed-by: Markus Armbruster 
Reviewed-by: Edgar E. Iglesias 
Reviewed-by: Michael S. Tsirkin 
---
 default-configs/alpha-softmmu.mak   | 1 +
 default-configs/arm-softmmu.mak | 1 +
 default-configs/i386-softmmu.mak| 1 +
 default-configs/mips-softmmu-common.mak | 1 +
 default-configs/moxie-softmmu.mak   | 1 +
 default-configs/pci.mak | 1 +
 default-configs/ppc-softmmu.mak | 1 +
 default-configs/ppc64-softmmu.mak   | 1 +
 default-configs/ppcemb-softmmu.mak  | 1 +
 default-configs/sh4-softmmu.mak | 1 +
 default-configs/sh4eb-softmmu.mak   | 1 +
 default-configs/sparc64-softmmu.mak | 1 +
 default-configs/x86_64-softmmu.mak  | 1 +
 hw/char/Makefile.objs   | 3 ++-
 14 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/default-configs/alpha-softmmu.mak 
b/default-configs/alpha-softmmu.mak
index 7f6161e..e0d75e3 100644
--- a/default-configs/alpha-softmmu.mak
+++ b/default-configs/alpha-softmmu.mak
@@ -3,6 +3,7 @@
 include pci.mak
 include usb.mak
 CONFIG_SERIAL=y
+CONFIG_SERIAL_ISA=y
 CONFIG_I8254=y
 CONFIG_PCKBD=y
 CONFIG_VGA_CIRRUS=y
diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 6de3e16..dcbcea7 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -6,6 +6,7 @@ CONFIG_VGA=y
 CONFIG_NAND=y
 CONFIG_ECC=y
 CONFIG_SERIAL=y
+CONFIG_SERIAL_ISA=y
 CONFIG_PTIMER=y
 CONFIG_SD=y
 CONFIG_MAX7310=y
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 0b51360..3f2e820 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -15,6 +15,7 @@ CONFIG_IPMI_EXTERN=y
 CONFIG_ISA_IPMI_KCS=y
 CONFIG_ISA_IPMI_BT=y
 CONFIG_SERIAL=y
+CONFIG_SERIAL_ISA=y
 CONFIG_PARALLEL=y
 CONFIG_I8254=y
 CONFIG_PCSPK=y
diff --git a/default-configs/mips-softmmu-common.mak 
b/default-configs/mips-softmmu-common.mak
index f0676f5..7d8f5db 100644
--- a/default-configs/mips-softmmu-common.mak
+++ b/default-configs/mips-softmmu-common.mak
@@ -9,6 +9,7 @@ CONFIG_VGA_ISA_MM=y
 CONFIG_VGA_CIRRUS=y
 CONFIG_VMWARE_VGA=y
 CONFIG_SERIAL=y
+CONFIG_SERIAL_ISA=y
 CONFIG_PARALLEL=y
 CONFIG_I8254=y
 CONFIG_PCSPK=y
diff --git a/default-configs/moxie-softmmu.mak 
b/default-configs/moxie-softmmu.mak
index 1a95476..7e22863 100644
--- a/default-configs/moxie-softmmu.mak
+++ b/default-configs/moxie-softmmu.mak
@@ -2,4 +2,5 @@
 
 CONFIG_MC146818RTC=y
 CONFIG_SERIAL=y
+CONFIG_SERIAL_ISA=y
 CONFIG_VGA=y
diff --git a/default-configs/pci.mak b/default-configs/pci.mak
index fff7ce3..d8d6548 100644
--- a/default-configs/pci.mak
+++ b/default-configs/pci.mak
@@ -27,6 +27,7 @@ CONFIG_AHCI=y
 CONFIG_ESP=y
 CONFIG_ESP_PCI=y
 CONFIG_SERIAL=y
+CONFIG_SERIAL_ISA=y
 CONFIG_SERIAL_PCI=y
 CONFIG_IPACK=y
 CONFIG_WDT_IB6300ESB=y
diff --git a/default-configs/ppc-softmmu.mak b/default-configs/ppc-softmmu.mak
index d4d0f9b..13eb94f 100644
--- a/default-configs/ppc-softmmu.mak
+++ b/default-configs/ppc-softmmu.mak
@@ -45,5 +45,6 @@ CONFIG_PLATFORM_BUS=y
 CONFIG_ETSEC=y
 CONFIG_LIBDECNUMBER=y
 # For PReP
+CONFIG_SERIAL_ISA=y
 CONFIG_MC146818RTC=y
 CONFIG_ISA_TESTDEV=y
diff --git a/default-configs/ppc64-softmmu.mak 
b/default-configs/ppc64-softmmu.mak
index 67a9bca..f607125 100644
--- a/default-configs/ppc64-softmmu.mak
+++ b/default-configs/ppc64-softmmu.mak
@@ -52,6 +52,7 @@ CONFIG_XICS=$(CONFIG_PSERIES)
 CONFIG_XICS_SPAPR=$(CONFIG_PSERIES)
 CONFIG_XICS_KVM=$(and $(CONFIG_PSERIES),$(CONFIG_KVM))
 # For PReP
+CONFIG_SERIAL_ISA=y
 CONFIG_MC146818RTC=y
 CONFIG_ISA_TESTDEV=y
 CONFIG_MEM_HOTPLUG=y
diff --git a/default-configs/ppcemb-softmmu.mak 
b/default-configs/ppcemb-softmmu.mak
index 54acc4d..7f56004 100644
--- a/default-configs/ppcemb-softmmu.mak
+++ b/default-configs/ppcemb-softmmu.mak
@@ -5,6 +5,7 @@ include sound.mak
 include usb.mak
 CONFIG_M48T59=y
 CONFIG_SERIAL=y
+CONFIG_SERIAL_ISA=y
 CONFIG_I8257=y
 CONFIG_OPENPIC=y
 CONFIG_PFLASH_CFI01=y

[Qemu-devel] [PATCH 3/5] target-ppc: Allow eventual removal of old migration mistakes

[David Gibson]

Until very recently, the vmstate for ppc cpus included some poorly
thought out VMSTATE_EQUAL() components, that can easily break
migration compatibility, and did so between qemu-2.6 and later
versions.  A hack was recently added which fixes this migration
breakage, but it leaves the unhelpful cruft of these fields in the
migration stream.

dThis patch adds a new cpu property allowing these fields to be
removed from the stream entirely.  This property is enabled by default
for the pseries-2.8 machine type - which comes after the fix - and for
all non-pseries machine types - which aren't mature enough to care
about cross-version migration.

The migration hack remains in place for pseries-2.7 and earlier
machine types, allowing backwards and forwards migration with the
older machine types.

This restricts the migration compatibility cruft to older machine
types, and at least opens the possibility of eventually deprecating
and removing it entirely.

Signed-off: David Gibson 
---
 hw/ppc/spapr.c  |  5 +
 target-ppc/cpu.h|  3 ++-
 target-ppc/machine.c| 48 +
 target-ppc/translate_init.c |  6 ++
 4 files changed, 44 insertions(+), 18 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 54b88d3..775ad2e 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2767,6 +2767,11 @@ DEFINE_SPAPR_MACHINE(2_8, "2.8", true);
 .driver   = TYPE_SPAPR_PCI_HOST_BRIDGE, \
 .property = "mem64_win_size",   \
 .value= "0",\
+},  \
+{   \
+.driver = TYPE_POWERPC_CPU, \
+.property = "pre-2.8-migration",\
+.value= "on",   \
 },
 
 static void phb_placement_2_7(sPAPRMachineState *spapr, uint32_t index,
diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 7798b2e..2a50c43 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -1167,7 +1167,8 @@ struct PowerPCCPU {
 uint32_t max_compat;
 uint32_t cpu_version;
 
-/* fields used only during migration for compatibility hacks */
+/* Fields related to migration compatibility hacks */
+bool pre_2_8_migration;
 target_ulong mig_msr_mask;
 uint64_t mig_insns_flags;
 uint64_t mig_insns_flags2;
diff --git a/target-ppc/machine.c b/target-ppc/machine.c
index 4e12e13..b8bda47 100644
--- a/target-ppc/machine.c
+++ b/target-ppc/machine.c
@@ -135,6 +135,13 @@ static const VMStateInfo vmstate_info_avr = {
 #define VMSTATE_AVR_ARRAY(_f, _s, _n) \
 VMSTATE_AVR_ARRAY_V(_f, _s, _n, 0)
 
+static bool cpu_pre_2_8_migration(void *opaque, int version_id)
+{
+PowerPCCPU *cpu = opaque;
+
+return cpu->pre_2_8_migration;
+}
+
 static void cpu_pre_save(void *opaque)
 {
 PowerPCCPU *cpu = opaque;
@@ -179,10 +186,12 @@ static void cpu_pre_save(void *opaque)
 }
 
 /* Hacks for migration compatibility between 2.6, 2.7 & 2.8 */
-cpu->mig_msr_mask = env->msr_mask;
-cpu->mig_insns_flags = env->insns_flags & insns_compat_mask;
-cpu->mig_insns_flags2 = env->insns_flags2 & insns_compat_mask2;
-cpu->mig_nb_BATs = env->nb_BATs;
+if (cpu->pre_2_8_migration) {
+cpu->mig_msr_mask = env->msr_mask;
+cpu->mig_insns_flags = env->insns_flags & insns_compat_mask;
+cpu->mig_insns_flags2 = env->insns_flags2 & insns_compat_mask2;
+cpu->mig_nb_BATs = env->nb_BATs;
+}
 }
 
 static int cpu_post_load(void *opaque, int version_id)
@@ -230,15 +239,19 @@ static int cpu_post_load(void *opaque, int version_id)
 
 hreg_compute_mem_idx(env);
 
-if (cpu->mig_insns_flags != env->insns_flags) {
-fprintf(stderr, "INSNS: Added 0x%" PRIx64 " removed  0x%" PRIx64 "\n",
-env->insns_flags & ~cpu->mig_insns_flags,
-cpu->mig_insns_flags & ~env->insns_flags);
-}
-if (cpu->mig_insns_flags2 != env->insns_flags2) {
-fprintf(stderr, "INSNS2: Added 0x%" PRIx64 " removed  0x%" PRIx64 "\n",
-env->insns_flags2 & ~cpu->mig_insns_flags2,
-cpu->mig_insns_flags2 & ~env->insns_flags2);
+if (cpu->pre_2_8_migration) {
+if (cpu->mig_insns_flags != env->insns_flags) {
+fprintf(stderr,
+"INSNS: Added 0x%" PRIx64 " removed  0x%" PRIx64 "\n",
+env->insns_flags & ~cpu->mig_insns_flags,
+cpu->mig_insns_flags & ~env->insns_flags);
+}
+if (cpu->mig_insns_flags2 != env->insns_flags2) {
+fprintf(stderr,
+"INSNS2: Added 0x%" PRIx64 " removed  0x%" PRIx64 "\n",
+env->insns_flags2 & ~cpu->mig_insns_flags2,
+cpu->mig_insns_flags2 & ~env->insns_flags2);
+}
 }
 
 return 0;
@@ -594,10 +607,11 @@ const 

[Qemu-devel] [PATCH 2/3] Allow ISA bus to be configured out

[David Gibson]

Currently, the code to handle the legacy ISA bus is always included in
qemu.  However there are lots of platforms that don't include ISA legacy
devies, and quite a few that have never used ISA legacy devices at all.

This patch allows the ISA bus code to be disabled in the configuration for
platforms where it doesn't make sense.

For now, the default configs are adjusted to include ISA on all platforms
including PCI: anything with PCI can at least in principle add an i82378
PCI->ISA bridge.  Also, CONFIG_IDE_CORE which is already in pci.mak
requires ISA support.

We also explicitly enable ISA on some other non-PCI platforms which include
ISA devices: moxie, sparc and unicore32.  We may want to pare this down in
future.

The platforms that will lose ISA by default are: cris, lm32, microblazeel,
microblaze, openrisc, s390x, tricore, xtensaeb, xtensa.  As far as I can
tell none of these ever used ISA.

Signed-off-by: David Gibson 
Acked-by: Michael S. Tsirkin 
Reviewed-by: Markus Armbruster 
Reviewed-by: Edgar E. Iglesias 
Reviewed-by: Michael S. Tsirkin 
---
 default-configs/moxie-softmmu.mak | 1 +
 default-configs/pci.mak   | 2 ++
 default-configs/sparc-softmmu.mak | 1 +
 default-configs/unicore32-softmmu.mak | 1 +
 hw/isa/Makefile.objs  | 2 +-
 5 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/default-configs/moxie-softmmu.mak 
b/default-configs/moxie-softmmu.mak
index 7e22863..e00d099 100644
--- a/default-configs/moxie-softmmu.mak
+++ b/default-configs/moxie-softmmu.mak
@@ -1,5 +1,6 @@
 # Default configuration for moxie-softmmu
 
+CONFIG_ISA_BUS=y
 CONFIG_MC146818RTC=y
 CONFIG_SERIAL=y
 CONFIG_SERIAL_ISA=y
diff --git a/default-configs/pci.mak b/default-configs/pci.mak
index d8d6548..60dc651 100644
--- a/default-configs/pci.mak
+++ b/default-configs/pci.mak
@@ -1,4 +1,6 @@
 CONFIG_PCI=y
+# For now, CONFIG_IDE_CORE requires ISA, so we enable it here
+CONFIG_ISA_BUS=y
 CONFIG_VIRTIO_PCI=y
 CONFIG_VIRTIO=y
 CONFIG_USB_UHCI=y
diff --git a/default-configs/sparc-softmmu.mak 
b/default-configs/sparc-softmmu.mak
index ab796b3..004b0f4 100644
--- a/default-configs/sparc-softmmu.mak
+++ b/default-configs/sparc-softmmu.mak
@@ -1,5 +1,6 @@
 # Default configuration for sparc-softmmu
 
+CONFIG_ISA_BUS=y
 CONFIG_ECC=y
 CONFIG_ESP=y
 CONFIG_ESCC=y
diff --git a/default-configs/unicore32-softmmu.mak 
b/default-configs/unicore32-softmmu.mak
index de38577..5f6c4a8 100644
--- a/default-configs/unicore32-softmmu.mak
+++ b/default-configs/unicore32-softmmu.mak
@@ -1,4 +1,5 @@
 # Default configuration for unicore32-softmmu
+CONFIG_ISA_BUS=y
 CONFIG_PUV3=y
 CONFIG_PTIMER=y
 CONFIG_PCKBD=y
diff --git a/hw/isa/Makefile.objs b/hw/isa/Makefile.objs
index 9164556..fb37c55 100644
--- a/hw/isa/Makefile.objs
+++ b/hw/isa/Makefile.objs
@@ -1,4 +1,4 @@
-common-obj-y += isa-bus.o
+common-obj-$(CONFIG_ISA_BUS) += isa-bus.o
 common-obj-$(CONFIG_APM) += apm.o
 common-obj-$(CONFIG_I82378) += i82378.o
 common-obj-$(CONFIG_PC87312) += pc87312.o
-- 
2.7.4

[Qemu-devel] [PATCH 0/5] Last minute ppc migration fixes

[David Gibson]

Unfortunately, a bug already slipped into the qemu-2.7 release which
breaks migration of the pseries-2.6 machine type from qemu v2.6.0 to
qemu v2.7.0.  That bug also breaks migration from v2.6.0 to current
master.  In addition there have been several more changes which have
inadvertently broken migration from v2.7.0 to current master for both
pseries-2.6 and pseries-2.7 machine types.

One of those was fixed - in a way - by 9b54ca0, however it was done in
such a way as to break backwards migration from current master to
v2.7.0.  It turns out that supporting backwards migration is more
important than I realized at the time.

So, this series contains several fixes for migration.  Between them,
they allow migration both forwards and backwards between qemu v2.6.0
and current master (and therefore, I hope, v2.8.0).

Unfortunately, because of the already released bug, there's no
reasonable way to fix migration from current master back to v2.7.0 as
well, and, obviously, no way at all to fix the existing breakage
between v2.6.0 and v2.7.0.  However, I'm also hoping to get patch 1/5
of this series applied to the 2.7 stable branch.  If that happens, it
should be possible to freely migrate between v2.6.0, v2.7.1 and
current master / 2.8, which is about the best we can hope for.

I've done basic testing of these with all the combinations of source
and destination being either v2.6.0, v2.7.0 + patch 1/5 and
ppc-for-2.8 + this series, and with all the applicable machine types
for each of those combinations.  Each test was with just a basic
default hardware setup, running a RHEL7.3 guest, no fancier
combinations.

Dave, could you please sanity check my compatibility sheanningans and
send an R-b (and an acked-by for patch 2/5, which isn't strictly ppc
related).

Michael, if you could test this on any combinations that occur to you,
that would be most helpful.

I'm hoping to get some reviews and squeeze this into v2.8.0, which
will mean a pull request within a couple of days.

David Gibson (5): target-ppc: Fix CPU migration from qemu-2.6 <->
  later versions migration: Add VMSTATE_UINTTL_TEST() target-ppc:
  Allow eventual removal of old migration mistakes Revert "spapr: Fix
  migration of PCI host bridges from qemu-2.7" spapr: Fix 2.7<->2.8
  migration of PCI host bridge

 hw/ppc/spapr.c  | 10 +
 hw/ppc/spapr_pci.c  | 35 +
 include/hw/pci-host/spapr.h |  6 +
 include/migration/cpu.h |  4 
 target-ppc/cpu.h|  7 ++
 target-ppc/machine.c| 55 +
 target-ppc/translate_init.c |  6 +
 7 files changed, 110 insertions(+), 13 deletions(-)

-- 
2.7.4

[Qemu-devel] [PATCH 3/3] Split ISA and sysbus versions of m48t59 device

[David Gibson]

The m48t59 device supports both ISA and direct sysbus attached versions of
the device in the one .c file.  This can be awkward for some embedded
machine types which need the sysbus M48T59, but don't want to pull in the
ISA bus code and its other dependencies.

Therefore, this patch splits out the code for the ISA attached M48T59 into
its own C file.  It will be built when both CONFIG_M48T59 and
CONFIG_ISA_BUS are enabled.

Signed-off-by: David Gibson 
Reviewed-by: Edgar E. Iglesias 
Reviewed-by: Michael S. Tsirkin 
---
 hw/timer/Makefile.objs |   3 +
 hw/timer/m48t59-internal.h |  82 
 hw/timer/m48t59-isa.c  | 181 +++
 hw/timer/m48t59.c  | 228 -
 4 files changed, 284 insertions(+), 210 deletions(-)
 create mode 100644 hw/timer/m48t59-internal.h
 create mode 100644 hw/timer/m48t59-isa.c

diff --git a/hw/timer/Makefile.objs b/hw/timer/Makefile.objs
index 7ba8c23..bf3ea3c 100644
--- a/hw/timer/Makefile.objs
+++ b/hw/timer/Makefile.objs
@@ -6,6 +6,9 @@ common-obj-$(CONFIG_DS1338) += ds1338.o
 common-obj-$(CONFIG_HPET) += hpet.o
 common-obj-$(CONFIG_I8254) += i8254_common.o i8254.o
 common-obj-$(CONFIG_M48T59) += m48t59.o
+ifeq ($(CONFIG_ISA_BUS),y)
+common-obj-$(CONFIG_M48T59) += m48t59-isa.o
+endif
 common-obj-$(CONFIG_PL031) += pl031.o
 common-obj-$(CONFIG_PUV3) += puv3_ost.o
 common-obj-$(CONFIG_TWL92230) += twl92230.o
diff --git a/hw/timer/m48t59-internal.h b/hw/timer/m48t59-internal.h
new file mode 100644
index 000..32ae957
--- /dev/null
+++ b/hw/timer/m48t59-internal.h
@@ -0,0 +1,82 @@
+/*
+ * QEMU M48T59 and M48T08 NVRAM emulation (common header)
+ *
+ * Copyright (c) 2003-2005, 2007 Jocelyn Mayer
+ * Copyright (c) 2013 Hervé Poussineau
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#ifndef HW_M48T59_INTERNAL_H
+#define HW_M48T59_INTERNAL_H 1
+
+//#define DEBUG_NVRAM
+
+#if defined(DEBUG_NVRAM)
+#define NVRAM_PRINTF(fmt, ...) do { printf(fmt , ## __VA_ARGS__); } while (0)
+#else
+#define NVRAM_PRINTF(fmt, ...) do { } while (0)
+#endif
+
+/*
+ * The M48T02, M48T08 and M48T59 chips are very similar. The newer '59 has
+ * alarm and a watchdog timer and related control registers. In the
+ * PPC platform there is also a nvram lock function.
+ */
+
+typedef struct M48txxInfo {
+const char *bus_name;
+uint32_t model; /* 2 = m48t02, 8 = m48t08, 59 = m48t59 */
+uint32_t size;
+} M48txxInfo;
+
+typedef struct M48t59State {
+/* Hardware parameters */
+qemu_irq IRQ;
+MemoryRegion iomem;
+uint32_t size;
+int32_t base_year;
+/* RTC management */
+time_t   time_offset;
+time_t   stop_time;
+/* Alarm & watchdog */
+struct tm alarm;
+QEMUTimer *alrm_timer;
+QEMUTimer *wd_timer;
+/* NVRAM storage */
+uint8_t *buffer;
+/* Model parameters */
+uint32_t model; /* 2 = m48t02, 8 = m48t08, 59 = m48t59 */
+/* NVRAM storage */
+uint16_t addr;
+uint8_t  lock;
+} M48t59State;
+
+uint32_t m48t59_read(M48t59State *NVRAM, uint32_t addr);
+void m48t59_write(M48t59State *NVRAM, uint32_t addr, uint32_t val);
+void m48t59_reset_common(M48t59State *NVRAM);
+void m48t59_realize_common(M48t59State *s, Error **errp);
+
+static inline void m48t59_toggle_lock(M48t59State *NVRAM, int lock)
+{
+NVRAM->lock ^= 1 << lock;
+}
+
+extern const MemoryRegionOps m48t59_io_ops;
+
+#endif /* HW_M48T59_INTERNAL_H */
diff --git a/hw/timer/m48t59-isa.c b/hw/timer/m48t59-isa.c
new file mode 100644
index 000..ea1ba70
--- /dev/null
+++ b/hw/timer/m48t59-isa.c
@@ -0,0 +1,181 @@
+/*
+ * QEMU M48T59 and M48T08 NVRAM emulation (ISA bus interface
+ *
+ * Copyright (c) 2003-2005, 2007 Jocelyn Mayer
+ * Copyright (c) 2013 Hervé Poussineau
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated 

[Qemu-devel] [PATCH 5/5] spapr: Fix 2.7<->2.8 migration of PCI host bridge

[David Gibson]

daa2369 "spapr_pci: Add a 64-bit MMIO window" subtly broke migration
from qemu-2.7 to the current version.  It split the device's MMIO
window into two pieces for 32-bit and 64-bit MMIO.

The patch included backwards compatibility code to convert the old
property into the new format.  However, the property value was also
transferred in the migration stream and compared with a (probably
unwise) VMSTATE_EQUAL.  So, the "raw" value from 2.7 is compared to
the new style converted value from (pre-)2.8 giving a mismatch and
migration failure.

Along with the actual field that caused the breakage, there are
several other ill-advised VMSTATE_EQUAL()s.  To fix forwards
migration, we read the values in the stream into scratch variables and
ignore them, instead of comparing for equality.  To fix backwards
migration, we populate those scratch variables in pre_save() with
adjusted values to match the old behaviour.

To permit the eventual possibility of removing this cruft from the
stream, we only include these compatibility fields if a new
'pre-2.8-migration' property is set.  We clear it on the pseries-2.8
machine type, which obviously can't be migrated backwards, but set it
on earlier machine type versions.

Signed-off-by: David Gibson 
---
 hw/ppc/spapr.c  |  5 +
 hw/ppc/spapr_pci.c  | 33 -
 include/hw/pci-host/spapr.h |  6 ++
 3 files changed, 39 insertions(+), 5 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 775ad2e..c3269c7 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2772,6 +2772,11 @@ DEFINE_SPAPR_MACHINE(2_8, "2.8", true);
 .driver = TYPE_POWERPC_CPU, \
 .property = "pre-2.8-migration",\
 .value= "on",   \
+},  \
+{   \
+.driver = TYPE_SPAPR_PCI_HOST_BRIDGE,   \
+.property = "pre-2.8-migration",\
+.value= "on",   \
 },
 
 static void phb_placement_2_7(sPAPRMachineState *spapr, uint32_t index,
diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
index e429c94..c62c1cb 100644
--- a/hw/ppc/spapr_pci.c
+++ b/hw/ppc/spapr_pci.c
@@ -1590,6 +1590,8 @@ static Property spapr_phb_properties[] = {
 DEFINE_PROP_UINT64("pgsz", sPAPRPHBState, page_size_mask,
(1ULL << 12) | (1ULL << 16)),
 DEFINE_PROP_UINT32("numa_node", sPAPRPHBState, numa_node, -1),
+DEFINE_PROP_BOOL("pre-2.8-migration", sPAPRPHBState,
+ pre_2_8_migration, false),
 DEFINE_PROP_END_OF_LIST(),
 };
 
@@ -1636,6 +1638,20 @@ static void spapr_pci_pre_save(void *opaque)
 sphb->msi_devs[i].key = *(uint32_t *) key;
 sphb->msi_devs[i].value = *(spapr_pci_msi *) value;
 }
+
+if (sphb->pre_2_8_migration) {
+sphb->mig_liobn = sphb->dma_liobn[0];
+sphb->mig_mem_win_addr = sphb->mem_win_addr;
+sphb->mig_mem_win_size = sphb->mem_win_size;
+sphb->mig_io_win_addr = sphb->io_win_addr;
+sphb->mig_io_win_size = sphb->io_win_size;
+
+if ((sphb->mem64_win_size != 0)
+&& (sphb->mem64_win_addr
+== (sphb->mem_win_addr + sphb->mem_win_size))) {
+sphb->mig_mem_win_size += sphb->mem64_win_size;
+}
+}
 }
 
 /*
@@ -1680,6 +1696,13 @@ static int spapr_pci_post_load(void *opaque, int 
version_id)
 return 0;
 }
 
+static bool pre_2_8_migration(void *opaque, int version_id)
+{
+sPAPRPHBState *sphb = opaque;
+
+return sphb->pre_2_8_migration;
+}
+
 static const VMStateDescription vmstate_spapr_pci = {
 .name = "spapr_pci",
 .version_id = 2,
@@ -1688,11 +1711,11 @@ static const VMStateDescription vmstate_spapr_pci = {
 .post_load = spapr_pci_post_load,
 .fields = (VMStateField[]) {
 VMSTATE_UINT64_EQUAL(buid, sPAPRPHBState),
-VMSTATE_UINT32_EQUAL(dma_liobn[0], sPAPRPHBState),
-VMSTATE_UINT64_EQUAL(mem_win_addr, sPAPRPHBState),
-VMSTATE_UINT64_EQUAL(mem_win_size, sPAPRPHBState),
-VMSTATE_UINT64_EQUAL(io_win_addr, sPAPRPHBState),
-VMSTATE_UINT64_EQUAL(io_win_size, sPAPRPHBState),
+VMSTATE_UINT32_TEST(mig_liobn, sPAPRPHBState, pre_2_8_migration),
+VMSTATE_UINT64_TEST(mig_mem_win_addr, sPAPRPHBState, 
pre_2_8_migration),
+VMSTATE_UINT64_TEST(mig_mem_win_size, sPAPRPHBState, 
pre_2_8_migration),
+VMSTATE_UINT64_TEST(mig_io_win_addr, sPAPRPHBState, pre_2_8_migration),
+VMSTATE_UINT64_TEST(mig_io_win_size, sPAPRPHBState, pre_2_8_migration),
 VMSTATE_STRUCT_ARRAY(lsi_table, sPAPRPHBState, PCI_NUM_PINS, 0,
  vmstate_spapr_pci_lsi, struct spapr_pci_lsi),
 VMSTATE_INT32(msi_devs_num, sPAPRPHBState),
diff --git a/include/hw/pci-host/spapr.h b/include/hw/pci-host/spapr.h
index b92c1b5..092294e 100644
--- 

[Qemu-devel] [PATCH 4/5] Revert "spapr: Fix migration of PCI host bridges from qemu-2.7"

[David Gibson]

This reverts commit 9b54ca0ba781012eeea4237b7c4832ba2ea81d89.

The commit above corrected a migration breakage between qemu-2.7 and
qemu-2.8.  However it did so by advancing the migration version for
the PCI host bridge, which obviously breaks migration backwards to
earlier qemu versions.

Although it's not totally essential, we'd like to maintain the
possibility for backwards migration, so revert the change in
preparation for a better fix.

Signed-off-by: David Gibson 
---
 hw/ppc/spapr_pci.c | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
index 661f7d8..e429c94 100644
--- a/hw/ppc/spapr_pci.c
+++ b/hw/ppc/spapr_pci.c
@@ -1680,25 +1680,19 @@ static int spapr_pci_post_load(void *opaque, int 
version_id)
 return 0;
 }
 
-static bool version_before_3(void *opaque, int version_id)
-{
-return version_id < 3;
-}
-
 static const VMStateDescription vmstate_spapr_pci = {
 .name = "spapr_pci",
-.version_id = 3,
+.version_id = 2,
 .minimum_version_id = 2,
 .pre_save = spapr_pci_pre_save,
 .post_load = spapr_pci_post_load,
 .fields = (VMStateField[]) {
 VMSTATE_UINT64_EQUAL(buid, sPAPRPHBState),
-VMSTATE_UNUSED_TEST(version_before_3,
-sizeof(uint32_t) /* dma_liobn[0] */
-+ sizeof(uint64_t) /* mem_win_addr */
-+ sizeof(uint64_t) /* mem_win_size */
-+ sizeof(uint64_t) /* io_win_addr */
-+ sizeof(uint64_t) /* io_win_size */),
+VMSTATE_UINT32_EQUAL(dma_liobn[0], sPAPRPHBState),
+VMSTATE_UINT64_EQUAL(mem_win_addr, sPAPRPHBState),
+VMSTATE_UINT64_EQUAL(mem_win_size, sPAPRPHBState),
+VMSTATE_UINT64_EQUAL(io_win_addr, sPAPRPHBState),
+VMSTATE_UINT64_EQUAL(io_win_size, sPAPRPHBState),
 VMSTATE_STRUCT_ARRAY(lsi_table, sPAPRPHBState, PCI_NUM_PINS, 0,
  vmstate_spapr_pci_lsi, struct spapr_pci_lsi),
 VMSTATE_INT32(msi_devs_num, sPAPRPHBState),
-- 
2.7.4

[Qemu-devel] [PATCH 2/5] migration: Add VMSTATE_UINTTL_TEST()

[David Gibson]

include/migration/cpu.h defines VMSTATE_UINTTL() and several variants
for migrating target_ulong fields.  It's defined in terms of
VMSTATE_UINT32() or VMSTATE_UINT64() as appropriate.

It doesn't, however, include a VMSTATE_UINTTL_TEST() variant, which
I'm going to need shortly.  So, add it.

Signed-off-by: David Gibson 
---
 include/migration/cpu.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/migration/cpu.h b/include/migration/cpu.h
index f3abbab..f3d5dfc 100644
--- a/include/migration/cpu.h
+++ b/include/migration/cpu.h
@@ -18,6 +18,8 @@
 VMSTATE_UINT64_EQUAL_V(_f, _s, _v)
 #define VMSTATE_UINTTL_ARRAY_V(_f, _s, _n, _v)\
 VMSTATE_UINT64_ARRAY_V(_f, _s, _n, _v)
+#define VMSTATE_UINTTL_TEST(_f, _s, _t)   \
+VMSTATE_UINT64_TEST(_f, _s, _t)
 #define vmstate_info_uinttl vmstate_info_uint64
 #else
 #define qemu_put_betl qemu_put_be32
@@ -35,6 +37,8 @@
 VMSTATE_UINT32_EQUAL_V(_f, _s, _v)
 #define VMSTATE_UINTTL_ARRAY_V(_f, _s, _n, _v)\
 VMSTATE_UINT32_ARRAY_V(_f, _s, _n, _v)
+#define VMSTATE_UINTTL_TEST(_f, _s, _t)   \
+VMSTATE_UINT32_TEST(_f, _s, _t)
 #define vmstate_info_uinttl vmstate_info_uint32
 #endif
 
-- 
2.7.4

[Qemu-devel] [PATCH 1/5] target-ppc: Fix CPU migration from qemu-2.6 <-> later versions

[David Gibson]

When migration for target-ppc was converted to vmstate, several
VMSTATE_EQUAL() checks were foolishly included of things that really
should be internal state.  Specifically we verified equality of the
insns_flags and insns_flags2 fields, which are used within TCG to
determine which groups of instructions are available on this cpu
model.  Between qemu-2.6 and qemu-2.7 we made some changes to these
classes which broke migration.

This path fixes migration both forwards and backwards.  On migration
from 2.6 to later versions we import the fields into teporary
variables, which we then ignore.  In migration backwards, we populate
the temporary fields from the runtime fields, but mask out the bits
which were added after qemu-2.6, allowing the VMSTATE_EQUAL in
qemu-2.6 to accept the stream.

Signed-off-by: David Gibson 
---
 target-ppc/cpu.h |  6 ++
 target-ppc/machine.c | 41 +
 2 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 1c90adb..7798b2e 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -1166,6 +1166,12 @@ struct PowerPCCPU {
 int cpu_dt_id;
 uint32_t max_compat;
 uint32_t cpu_version;
+
+/* fields used only during migration for compatibility hacks */
+target_ulong mig_msr_mask;
+uint64_t mig_insns_flags;
+uint64_t mig_insns_flags2;
+uint32_t mig_nb_BATs;
 };
 
 static inline PowerPCCPU *ppc_env_get_cpu(CPUPPCState *env)
diff --git a/target-ppc/machine.c b/target-ppc/machine.c
index e43cb6c..4e12e13 100644
--- a/target-ppc/machine.c
+++ b/target-ppc/machine.c
@@ -140,6 +140,22 @@ static void cpu_pre_save(void *opaque)
 PowerPCCPU *cpu = opaque;
 CPUPPCState *env = >env;
 int i;
+uint64_t insns_compat_mask =
+PPC_INSNS_BASE | PPC_ISEL | PPC_STRING | PPC_MFTB
+| PPC_FLOAT | PPC_FLOAT_FSEL | PPC_FLOAT_FRES
+| PPC_FLOAT_FSQRT | PPC_FLOAT_FRSQRTE | PPC_FLOAT_FRSQRTES
+| PPC_FLOAT_STFIWX | PPC_FLOAT_EXT
+| PPC_CACHE | PPC_CACHE_ICBI | PPC_CACHE_DCBZ
+| PPC_MEM_SYNC | PPC_MEM_EIEIO | PPC_MEM_TLBIE | PPC_MEM_TLBSYNC
+| PPC_64B | PPC_64BX | PPC_ALTIVEC
+| PPC_SEGMENT_64B | PPC_SLBI | PPC_POPCNTB | PPC_POPCNTWD;
+uint64_t insns_compat_mask2 = 
+PPC2_VSX | PPC2_VSX207 | PPC2_DFP | PPC2_DBRX
+| PPC2_PERM_ISA206 | PPC2_DIVE_ISA206
+| PPC2_ATOMIC_ISA206 | PPC2_FP_CVT_ISA206
+| PPC2_FP_TST_ISA206 | PPC2_BCTAR_ISA207
+| PPC2_LSQ_ISA207 | PPC2_ALTIVEC_207
+| PPC2_ISA205 | PPC2_ISA207S | PPC2_FP_CVT_S64| PPC2_TM;
 
 env->spr[SPR_LR] = env->lr;
 env->spr[SPR_CTR] = env->ctr;
@@ -161,6 +177,12 @@ static void cpu_pre_save(void *opaque)
 env->spr[SPR_IBAT4U + 2*i] = env->IBAT[0][i+4];
 env->spr[SPR_IBAT4U + 2*i + 1] = env->IBAT[1][i+4];
 }
+
+/* Hacks for migration compatibility between 2.6, 2.7 & 2.8 */
+cpu->mig_msr_mask = env->msr_mask;
+cpu->mig_insns_flags = env->insns_flags & insns_compat_mask;
+cpu->mig_insns_flags2 = env->insns_flags2 & insns_compat_mask2;
+cpu->mig_nb_BATs = env->nb_BATs;
 }
 
 static int cpu_post_load(void *opaque, int version_id)
@@ -208,6 +230,17 @@ static int cpu_post_load(void *opaque, int version_id)
 
 hreg_compute_mem_idx(env);
 
+if (cpu->mig_insns_flags != env->insns_flags) {
+fprintf(stderr, "INSNS: Added 0x%" PRIx64 " removed  0x%" PRIx64 "\n",
+env->insns_flags & ~cpu->mig_insns_flags,
+cpu->mig_insns_flags & ~env->insns_flags);
+}
+if (cpu->mig_insns_flags2 != env->insns_flags2) {
+fprintf(stderr, "INSNS2: Added 0x%" PRIx64 " removed  0x%" PRIx64 "\n",
+env->insns_flags2 & ~cpu->mig_insns_flags2,
+cpu->mig_insns_flags2 & ~env->insns_flags2);
+}
+
 return 0;
 }
 
@@ -561,10 +594,10 @@ const VMStateDescription vmstate_ppc_cpu = {
 /* FIXME: access_type? */
 
 /* Sanity checking */
-VMSTATE_UINTTL_EQUAL(env.msr_mask, PowerPCCPU),
-VMSTATE_UINT64_EQUAL(env.insns_flags, PowerPCCPU),
-VMSTATE_UINT64_EQUAL(env.insns_flags2, PowerPCCPU),
-VMSTATE_UINT32_EQUAL(env.nb_BATs, PowerPCCPU),
+VMSTATE_UINTTL(mig_msr_mask, PowerPCCPU),
+VMSTATE_UINT64(mig_insns_flags, PowerPCCPU),
+VMSTATE_UINT64(mig_insns_flags2, PowerPCCPU),
+VMSTATE_UINT32(mig_nb_BATs, PowerPCCPU),
 VMSTATE_END_OF_LIST()
 },
 .subsections = (const VMStateDescription*[]) {
-- 
2.7.4

Re: [Qemu-devel] [PATCH for-2.8 3/3] spapr: migration support for CAS-negotiated option vectors

[David Gibson]

On Fri, Nov 18, 2016 at 10:08:59AM -0600, Michael Roth wrote:
> Quoting Michael Roth (2016-11-17 19:40:27)
> > With the additional of the OV5_HP_EVT option vector, we now have
> > certain functionality (namely, memory unplug) that checks at run-time
> > for whether or not the guest negotiated the option via CAS. Because
> > we don't currently migrate these negotiated values, we are unable
> > to unplug memory from a guest after it's been migrated until after
> > the guest is rebooted and CAS-negotiation is repeated.
> > 
> > This patch fixes this by adding CAS-negotiated options to the
> > migration stream. We do this using a subsection, since the
> > negotiated value of OV5_HP_EVT is the only option currently needed
> > to maintain proper functionality for a running guest.
> > 
> > Signed-off-by: Michael Roth 
> > ---
> >  hw/ppc/spapr.c  | 68 
> > +
> >  hw/ppc/spapr_ovec.c | 12 
> >  include/hw/ppc/spapr_ovec.h |  4 +++
> >  3 files changed, 84 insertions(+)
> > 
> > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > index 0cbab24..9e08aed 100644
> > --- a/hw/ppc/spapr.c
> > +++ b/hw/ppc/spapr.c
> > @@ -1267,6 +1267,70 @@ static bool version_before_3(void *opaque, int 
> > version_id)
> >  return version_id < 3;
> >  }
> > 
> > +static bool spapr_ov5_cas_needed(void *opaque)
> > +{
> > +sPAPRMachineState *spapr = opaque;
> > +sPAPROptionVector *ov5_mask = spapr_ovec_new();
> > +sPAPROptionVector *ov5_legacy = spapr_ovec_new();
> > +sPAPROptionVector *ov5_removed = spapr_ovec_new();
> > +bool cas_needed;
> > +
> > +/* Prior to the introduction of sPAPROptionVector, we had two option
> > + * vectors we dealt with: OV5_FORM1_AFFINITY, and OV5_DRCONF_MEMORY.
> > + * Both of these options encode machine topology into the device-tree
> > + * in such a way that the now-booted OS should still be able to 
> > interact
> > + * appropriately with QEMU regardless of what options were actually
> > + * negotiatied on the source side.
> > + *
> > + * As such, we can avoid migrating the CAS-negotiated options if these
> > + * are the only options available on the current machine/platform.
> > + * Since these are the only options available for pseries-2.7 and
> > + * earlier, this allows us to maintain old->new/new->old migration
> > + * compatibility.
> > + *
> > + * For QEMU 2.8+, there are additional CAS-negotiatable options 
> > available
> > + * via default pseries-2.8 machines and explicit command-line 
> > parameters.
> > + * Some of these options, like OV5_HP_EVT, *do* require QEMU to be 
> > aware
> > + * of the actual CAS-negotiated values to continue working properly. 
> > For
> > + * example, availability of memory unplug depends on knowing whether
> > + * OV5_HP_EVT was negotiated via CAS.
> > + *
> > + * Thus, for any cases where the set of available CAS-negotiatable
> > + * options extends beyond OV5_FORM1_AFFINITY and OV5_DRCONF_MEMORY, we
> > + * include the CAS-negotiated options in the migration stream.
> > + */
> > +spapr_ovec_set(ov5_mask, OV5_FORM1_AFFINITY);
> > +spapr_ovec_set(ov5_mask, OV5_DRCONF_MEMORY);
> > +
> > +/* spapr_ovec_diff returns true if bits were removed. we avoid using
> > + * the mask itself since in the future it's possible "legacy" bits may 
> > be
> > + * removed via machine options, which could generate a false positive
> > + * that breaks migration.
> > + */
> > +spapr_ovec_intersect(ov5_legacy, spapr->ov5, ov5_mask);
> > +cas_needed = spapr_ovec_diff(ov5_removed, spapr->ov5, ov5_legacy);
> > +
> > +spapr_ovec_cleanup(ov5_mask);
> > +spapr_ovec_cleanup(ov5_legacy);
> > +spapr_ovec_cleanup(ov5_removed);
> > +
> > +error_report("MIGRATION NEEDED: %d", cas_needed);
> 
> Argh, sorry, I just noticed this stray debug comment that slipped in.
> Would you prefer a v2, or just removing it in-tree?

I've fixed it in tree.  Thanks for pointing it out.

-- 
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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH for-2.8] target-*: Fix typos found by codespell

[David Gibson]

On Sat, Nov 19, 2016 at 08:50:55PM +0100, Stefan Weil wrote:
> Signed-off-by: Stefan Weil 

Low risk, but low priority.  Applied to ppc-for-2.9.

> ---
>  target-i386/translate.c   | 2 +-
>  target-m68k/translate.c   | 6 +++---
>  target-ppc/cpu.h  | 2 +-
>  target-ppc/excp_helper.c  | 2 +-
>  target-ppc/int_helper.c   | 2 +-
>  target-ppc/mmu-hash64.c   | 2 +-
>  target-s390x/cpu_models.c | 2 +-
>  target-s390x/cpu_models.h | 2 +-
>  8 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/target-i386/translate.c b/target-i386/translate.c
> index 324103c..d8ca6df 100644
> --- a/target-i386/translate.c
> +++ b/target-i386/translate.c
> @@ -6701,7 +6701,7 @@ static target_ulong disas_insn(CPUX86State *env, 
> DisasContext *s,
>  if (s->prefix & PREFIX_LOCK) {
>  switch (op) {
>  case 0: /* bt */
> -/* Needs no atomic ops; we surpressed the normal
> +/* Needs no atomic ops; we suppressed the normal
> memory load for LOCK above so do it now.  */
>  gen_op_ld_v(s, ot, cpu_T0, cpu_A0);
>  break;
> diff --git a/target-m68k/translate.c b/target-m68k/translate.c
> index 9ad974f..cab2d58 100644
> --- a/target-m68k/translate.c
> +++ b/target-m68k/translate.c
> @@ -1579,7 +1579,7 @@ DISAS_INSN(negx)
>  
>  gen_flush_flags(s); /* compute old Z */
>  
> -/* Perform substract with borrow.
> +/* Perform subtract with borrow.
>   * (X, N) =  -(src + X);
>   */
>  
> @@ -2067,7 +2067,7 @@ static inline void gen_subx(DisasContext *s, TCGv src, 
> TCGv dest, int opsize)
>  
>  gen_flush_flags(s); /* compute old Z */
>  
> -/* Perform substract with borrow.
> +/* Perform subtract with borrow.
>   * (X, N) = dest - (src + X);
>   */
>  
> @@ -2077,7 +2077,7 @@ static inline void gen_subx(DisasContext *s, TCGv src, 
> TCGv dest, int opsize)
>  gen_ext(QREG_CC_N, QREG_CC_N, opsize, 1);
>  tcg_gen_andi_i32(QREG_CC_X, QREG_CC_X, 1);
>  
> -/* Compute signed-overflow for substract.  */
> +/* Compute signed-overflow for subtract.  */
>  
>  tcg_gen_xor_i32(QREG_CC_V, QREG_CC_N, dest);
>  tcg_gen_xor_i32(tmp, dest, src);
> diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
> index 1c90adb..f65d318 100644
> --- a/target-ppc/cpu.h
> +++ b/target-ppc/cpu.h
> @@ -2234,7 +2234,7 @@ enum {
>  PPC_INTERRUPT_CDOORBELL,  /* Critical doorbell interrupt  */
>  PPC_INTERRUPT_DOORBELL,   /* Doorbell interrupt   */
>  PPC_INTERRUPT_PERFM,  /* Performance monitor interrupt*/
> -PPC_INTERRUPT_HMI,/* Hypervisor Maintainance interrupt*/
> +PPC_INTERRUPT_HMI,/* Hypervisor Maintenance interrupt */
>  PPC_INTERRUPT_HDOORBELL,  /* Hypervisor Doorbell interrupt*/
>  };
>  
> diff --git a/target-ppc/excp_helper.c b/target-ppc/excp_helper.c
> index 93369d4..678e125 100644
> --- a/target-ppc/excp_helper.c
> +++ b/target-ppc/excp_helper.c
> @@ -139,7 +139,7 @@ static inline void powerpc_excp(PowerPCCPU *cpu, int 
> excp_model, int excp)
>  }
>  }
>  
> -/* Exception targetting modifiers
> +/* Exception targeting modifiers
>   *
>   * LPES0 is supported on POWER7/8
>   * LPES1 is not supported (old iSeries mode)
> diff --git a/target-ppc/int_helper.c b/target-ppc/int_helper.c
> index 9ac204a..5d4a571 100644
> --- a/target-ppc/int_helper.c
> +++ b/target-ppc/int_helper.c
> @@ -155,7 +155,7 @@ target_ulong helper_cnttzw(target_ulong t)
>  /* if x = 0xab, returns 0xababababababababa */
>  #define pattern(x) (((x) & 0xff) * (~(target_ulong)0 / 0xff))
>  
> -/* substract 1 from each byte, and with inverse, check if MSB is set at each
> +/* subtract 1 from each byte, and with inverse, check if MSB is set at each
>   * byte.
>   * i.e. ((0x00 - 0x01) & ~(0x00)) & 0x80
>   *  (0xFF & 0xFF) & 0x80 = 0x80 (zero found)
> diff --git a/target-ppc/mmu-hash64.c b/target-ppc/mmu-hash64.c
> index fdb7a78..4f5d9f6 100644
> --- a/target-ppc/mmu-hash64.c
> +++ b/target-ppc/mmu-hash64.c
> @@ -691,7 +691,7 @@ int ppc_hash64_handle_mmu_fault(PowerPCCPU *cpu, vaddr 
> eaddr,
>  
>  /* Note on LPCR usage: 970 uses HID4, but our special variant
>   * of store_spr copies relevant fields into env->spr[SPR_LPCR].
> - * Similarily we filter unimplemented bits when storing into
> + * Similarly we filter unimplemented bits when storing into
>   * LPCR depending on the MMU version. This code can thus just
>   * use the LPCR "as-is".
>   */
> diff --git a/target-s390x/cpu_models.c b/target-s390x/cpu_models.c
> index c1e729d..a4d46f3 100644
> --- a/target-s390x/cpu_models.c
> +++ b/target-s390x/cpu_models.c
> @@ -38,7 +38,7 @@
>  }
>  
>  /*
> - * CPU definiton list in order of release. For now, base features of a
> + * CPU definition list in order of release. For now, base features of a
>   * 

Re: [Qemu-devel] [PATCH for-2.8] disas/ppc: Fix indefinite articles in comments

[David Gibson]

On Sat, Nov 19, 2016 at 08:23:03PM +0100, Stefan Weil wrote:
> Signed-off-by: Stefan Weil 

Low risk, but low priority.  Applied to ppc-for-2.9

> ---
>  disas/ppc.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/disas/ppc.c b/disas/ppc.c
> index bd05623..9b5a0e7 100644
> --- a/disas/ppc.c
> +++ b/disas/ppc.c
> @@ -1653,11 +1653,11 @@ extract_tbr (unsigned long insn,
>  #define BBOYBI_MASK (BBOYCB_MASK | BI_MASK)
>  #define BBOATBI_MASK (BBOAT2CB_MASK | BI_MASK)
>  
> -/* An Context form instruction.  */
> +/* A Context form instruction.  */
>  #define CTX(op, xop)   (OP (op) | (((unsigned long)(xop)) & 0x7))
>  #define CTX_MASK CTX(0x3f, 0x7)
>  
> -/* An User Context form instruction.  */
> +/* A User Context form instruction.  */
>  #define UCTX(op, xop)  (OP (op) | (((unsigned long)(xop)) & 0x1f))
>  #define UCTX_MASK UCTX(0x3f, 0x1f)
>  
> @@ -1710,19 +1710,19 @@ extract_tbr (unsigned long insn,
>  #define SC(op, sa, lk) (OP (op) | unsigned long)(sa)) & 1) << 1) | ((lk) 
> & 1))
>  #define SC_MASK (OP_MASK | (((unsigned long)0x3ff) << 16) | (((unsigned 
> long)1) << 1) | 1)
>  
> -/* An VX form instruction.  */
> +/* A VX form instruction.  */
>  #define VX(op, xop) (OP (op) | (((unsigned long)(xop)) & 0x7ff))
>  
>  /* The mask for an VX form instruction.  */
>  #define VX_MASK  VX(0x3f, 0x7ff)
>  
> -/* An VA form instruction.  */
> +/* A VA form instruction.  */
>  #define VXA(op, xop) (OP (op) | (((unsigned long)(xop)) & 0x03f))
>  
> -/* The mask for an VA form instruction.  */
> +/* The mask for a VA form instruction.  */
>  #define VXA_MASK VXA(0x3f, 0x3f)
>  
> -/* An VXR form instruction.  */
> +/* A VXR form instruction.  */
>  #define VXR(op, xop, rc) (OP (op) | (((rc) & 1) << 10) | (((unsigned 
> long)(xop)) & 0x3ff))
>  
>  /* The mask for a VXR form instruction.  */

-- 
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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH for-2.8 0/3] spapr: fix breakage of memory unplug after migration

[David Gibson]

On Fri, Nov 18, 2016 at 10:39:49AM -0600, Michael Roth wrote:
> Quoting David Gibson (2016-11-17 23:45:05)
> > On Thu, Nov 17, 2016 at 07:40:24PM -0600, Michael Roth wrote:
> > > These patches are based on David's ppc-for-2.8 tree, and are also
> > > available from:
> > > 
> > >   https://github.com/mdroth/qemu/commits/spapr-cas-migration
> > > 
> > > Currently, memory hotplugged to a pseries guest cannot be removed after
> > > the guest has been migrated. This is due to 2 issues:
> > > 
> > > 1) The coldplugged state of memory on the target side is one where the
> > >corresponding DRC's allocation state is:
> > > 
> > >  allocation_state == unallocated,
> > >  awaiting_allocation == true,
> > > 
> > >When the guest attempts to unplug memory on the target side, it first
> > >checks that allocation_state == allocated. If we fix this, the guest
> > >can successfully notify QEMU of completion on it's end, but then the
> > >DRC code sees that awaiting_allocation == true, so it defers the
> > >finalizing of the LMB and corresponding DIMM since it assumes that
> > >the DIMM must have been previously allocated before it can be removed.
> > > 
> > >To address this, we pull in patches 1-2 from Jian Jun's DRC migration
> > >series:
> > > 
> > >  https://lists.gnu.org/archive/html/qemu-ppc/2016-10/msg00048.html
> > > 
> > >with some minor changes relating to prior review comments, and
> > >the addition of migrating the DRC's awaiting_allocation value, which
> > >wasn't part of the original patch. This doesn't address the full scope
> > >of the issues Jian Jun was looking at (involving synchronizing state
> > >when migration occurs during fairly small race windows), just this
> > >particular case, which is more user visible since the time window is
> > >indefinite.
> > > 
> > > 2) The ability to unplug memory is gated on the QEMU side by a check as
> > >to whether or not support for newer-style hotplug events was negotiated
> > >via CAS during boot. The check is performed by checking the 
> > > corresponding
> > >entry in the sPAPROptionVector structure. However, since this value 
> > > isn't
> > >migrated currently, we are unable to unplug until after the guest 
> > > reboots.
> > > 
> > >We address that here by adding migration support for 
> > > sPAPROptionVectors,
> > >and including the CAS-negotiated vector as part of the migration stream
> > >for any cases where we advertise newer-style hotplug event support to
> > >the guest.
> > > 
> > > David,
> > > 
> > > These fixes ended up going out much later than planned. I'm not sure
> > > if you're planning another pull for 2.8 or not, and realize there are
> > > some patches here not specifically pseries-related so it's
> > > understandable if we opt to pursue these for 2.9/2.8.1 instead. But if
> > > possible I'm hoping to get these in so that the memory unplug
> > > support is fully functional for 2.8.
> > 
> > Yeah, I'm still expecting to push a few bugfixes in before 2.8.  So,
> > I've merged these patches into ppc-for-2.8 (fixing a couple of trivial
> > style nits along the way).  I have a couple of comments that I'll make
> > on the patches, but they're not important enough to stop these going
> > in ASAP.
> > 
> > Unfortunately, of course, this is not the only migration breakage we
> > have at the moment.  I'm presently wrestling with both breakage due to
> > changes in the insns_flags masks, and due to the reworking of the mmio
> > windows for the PHB.
> 
> Ok, thanks for the heads up. FYI I'm still hoping to get the insns_flags
> fix in for 2.7.1 (which is a bit behind at this point, should have schedule
> and initial tree posted next week though), so I will keep an eye out for
> those.

Yeah, in addition to being sick, I've had to rethink how to fix these
migration problems, including how to address this for 2.7.1.  I'm
working on it right now.

-- 
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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH] hw/char/spapr_vty: Return amount of free buffer entries in vty_can_receive()

[David Gibson]

On Fri, Nov 18, 2016 at 10:09:37AM +0100, Thomas Huth wrote:
> The can_receive() callbacks of the character devices should return
> the amount of characters that can be accepted at once, not just a
> boolean value (which rather means only one character at a time).
> 
> Signed-off-by: Thomas Huth 

Applied to ppc-for-2.8, thanks.

> ---
>  hw/char/spapr_vty.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/char/spapr_vty.c b/hw/char/spapr_vty.c
> index 06b9b39..7c22b8b 100644
> --- a/hw/char/spapr_vty.c
> +++ b/hw/char/spapr_vty.c
> @@ -25,7 +25,7 @@ static int vty_can_receive(void *opaque)
>  {
>  VIOsPAPRVTYDevice *dev = VIO_SPAPR_VTY_DEVICE(opaque);
>  
> -return (dev->in - dev->out) < VTERM_BUFSIZE;
> +return VTERM_BUFSIZE - (dev->in - dev->out);
>  }
>  
>  static void vty_receive(void *opaque, const uint8_t *buf, int size)

-- 
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


signature.asc
Description: PGP signature

Re: [Qemu-devel] About vNVDIMM question in TCG

[Haozhong Zhang]

On 11/20/16 10:58 -0700, Lin Ma wrote:

Hi Guangrong,

I'm interested in vNVDIMM on qemu. I'd like to give it a try on my laptop.
Because I dont have skylake server hardware, So I want to expose cpu flags
clflushopt, clwb and pcommit to guest for NVDIMM drivers on TCG.

I saw clflushopt and clwb feature flags in cpuinfo of guest, but no pcommit.
Could you please tell me is there anyhing wrong in my qemu CLI or anything
I misunderstand?


pcommit had been deprecated (see KVM commit
dfa169bbee00671288df25f8ef8a2f6e13fe2581), so it's correct to not have
it in guest.



qemu-system-x86_64 \
-cpu Skylake-Client,+pcommit,+clflushopt,+clwb \
-machine pc-i440fx-2.8,nvdimm=on,accel=tcg \
-m 4G,maxmem=... \
-object memory-backend-file,... \
-device nvdimm,... \

BTW, In kvm mode, Even if I used '-cpu qemu64' without flags pcommit,
clflushopt and clwb, The block device /dev/pmem0 is still there and can
be used successfully. Does it make sense? Doesn't nvdimm kernel driver
need pcommit, clflushopt and clwb to work?



If my memory is correct, Linux NVDIMM driver will fallback to clflush
when neither clflushopt nor clwb is available.

Haozhong

Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default

[Alexey Kardashevskiy]

On 18/11/16 19:17, Andrea Bolognani wrote:
> On Thu, 2016-11-17 at 13:02 +1100, Alexey Kardashevskiy wrote:
>>> That said, considering that a big part of the PCI address
>>> allocation logic is based off whether the specific machine
>>> type exposes a legay PCI Root Bus or a PCI Express Root Bus,
>>> libvirt will need a way to be able to tell which one is which.
>>>  
>>> Version checks are pretty much out of the question, as they
>>> fail as soon as downstream releases enter the picture. A
>>> few ways we could deal with the situation:
>>>  
>>>1) switch to PCI Express on newer machine types, and
>>>   expose some sort of capability through QMP so that
>>>   libvirt can know about the switch
> 
> [...]
>>> Option 1) would break horribly with existing libvirt
>>> versions, and so would Option 2) if we default to using
>>  
>> How exactly 1) will break libvirt? Migrating from pseries-2.7 to
>> pseries-2.8 does not work anyway, and machines are allowed to behave
>> different from version to version, what distinct difference will using
>> "pseries-pcie-X.Y" make?
> 
> Existing libvirt versions assume that pseries guests have

If libvirt is using just "pseries" (without a version), then having a
virtual PCIe-PCI bridge (and "pci.0" always available by default) will do it.

If libvirt is using a specific version of pseries, then it already knows
that <=2.7 has pci.0 as a root, pcie.0 otherwise. libvirt has a knowledge
what QEMU version has what, right?

In what scenario will an additional machine type help?

> a legacy PCI root bus, and will base their PCI address
> allocation / PCI topology decisions on that fact: they
> will, for example, use legacy PCI bridges.
> 
> So if you used a new QEMU binary with a libvirt version
> that doesn't know about the change, new guests would end up
> using the wrong controllers. Existing guests would not be
> affected as they would stick with the older machine types,
> of course.
> 
>> I believe after we introduced the very first
>> pseries-pcie-X.Y, we will just stop adding new pseries-X.Y.
> 
> Isn't i440fx still being updated despite the fact that q35
> exists? Granted, there are a lot more differences between
> those two machine types than just the root bus type.

I do not know about i440<->q35 but in pseries the difference is going to be
very simple.

For example, we did not change the machine type when we switched from
default OHCI to XHCI, switching from PCI to PCIe does not sound like we
need a whole new machine type for this either.

> Even if no newer pseries-x.y were to be added after
> introducing pseries-pcie, you could still easily create
> guests that use either root bus, so no loss in functionality.

I could do this with the existing pseries if the machine had a "root but
type" property.


-- 
Alexey

Re: [Qemu-devel] [PATCH] block/mirror: enable detect zeroes when driving mirror

[no-reply]

Hi,

Your series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.

Subject: [Qemu-devel] [PATCH] block/mirror: enable detect zeroes when driving 
mirror
Type: series
Message-id: 20161121012439.2394-1-w90p...@gmail.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash
set -e
git submodule update --init dtc
# Let docker tests dump environment info
export SHOW_ENV=1
export J=16
make docker-test-quick@centos6
make docker-test-mingw@fedora
make docker-test-build@min-glib
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
83eb22f block/mirror: enable detect zeroes when driving mirror

=== OUTPUT BEGIN ===
Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc'
Cloning into 'dtc'...
Submodule path 'dtc': checked out '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf'
  BUILD   centos6
make[1]: Entering directory `/var/tmp/patchew-tester-tmp-gbbbj9be/src'
  ARCHIVE qemu.tgz
  ARCHIVE dtc.tgz
  COPYRUNNER
RUN test-quick in qemu:centos6 
Packages installed:
SDL-devel-1.2.14-7.el6_7.1.x86_64
ccache-3.1.6-2.el6.x86_64
epel-release-6-8.noarch
gcc-4.4.7-17.el6.x86_64
git-1.7.1-4.el6_7.1.x86_64
glib2-devel-2.28.8-5.el6.x86_64
libfdt-devel-1.4.0-1.el6.x86_64
make-3.81-23.el6.x86_64
package g++ is not installed
pixman-devel-0.32.8-1.el6.x86_64
tar-1.23-15.el6_8.x86_64
zlib-devel-1.2.3-29.el6.x86_64

Environment variables:
PACKAGES=libfdt-devel ccache tar git make gcc g++ zlib-devel 
glib2-devel SDL-devel pixman-devel epel-release
HOSTNAME=5ea0aac17e6c
TERM=xterm
MAKEFLAGS= -j16
HISTSIZE=1000
J=16
USER=root
CCACHE_DIR=/var/tmp/ccache
EXTRA_CONFIGURE_OPTS=
V=
SHOW_ENV=1
MAIL=/var/spool/mail/root
PATH=/usr/lib/ccache:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
LANG=en_US.UTF-8
TARGET_LIST=
HISTCONTROL=ignoredups
SHLVL=1
HOME=/root
TEST_DIR=/tmp/qemu-test
LOGNAME=root
LESSOPEN=||/usr/bin/lesspipe.sh %s
FEATURES= dtc
DEBUG=
G_BROKEN_FILENAMES=1
CCACHE_HASHDIR=
_=/usr/bin/env

Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/var/tmp/qemu-build/install
No C++ compiler available; disabling C++ specific optional code
Install prefix/var/tmp/qemu-build/install
BIOS directory/var/tmp/qemu-build/install/share/qemu
binary directory  /var/tmp/qemu-build/install/bin
library directory /var/tmp/qemu-build/install/lib
module directory  /var/tmp/qemu-build/install/lib/qemu
libexec directory /var/tmp/qemu-build/install/libexec
include directory /var/tmp/qemu-build/install/include
config directory  /var/tmp/qemu-build/install/etc
local state directory   /var/tmp/qemu-build/install/var
Manual directory  /var/tmp/qemu-build/install/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path   /tmp/qemu-test/src
C compilercc
Host C compiler   cc
C++ compiler  
Objective-C compiler cc
ARFLAGS   rv
CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
QEMU_CFLAGS   -I/usr/include/pixman-1-pthread -I/usr/include/glib-2.0 
-I/usr/lib64/glib-2.0/include   -fPIE -DPIE -m64 -mcx16 -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes 
-fno-strict-aliasing -fno-common -fwrapv  -Wendif-labels -Wmissing-include-dirs 
-Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self 
-Wignored-qualifiers -Wold-style-declaration -Wold-style-definition 
-Wtype-limits -fstack-protector-all
LDFLAGS   -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g 
make  make
install   install
pythonpython -B
smbd  /usr/sbin/smbd
module supportno
host CPU  x86_64
host big endian   no
target list   x86_64-softmmu aarch64-softmmu
tcg debug enabled no
gprof enabled no
sparse enabledno
strip binariesyes
profiler  no
static build  no
pixmansystem
SDL support   yes (1.2.14)
GTK support   no 
GTK GL supportno
VTE support   no 
TLS priority  NORMAL
GNUTLS supportno
GNUTLS rndno
libgcrypt no
libgcrypt kdf no
nettleno 
nettle kdfno
libtasn1  no
curses supportno
virgl support no
curl support  no
mingw32 support   no
Audio drivers oss
Block whitelist (rw) 
Block whitelist (ro) 
VirtFS supportno
VNC support   yes
VNC SASL support  no
VNC JPEG support  no
VNC PNG support   no
xen support   no
brlapi supportno
bluez  supportno
Documentation no
PIE   yes
vde support   no
netmap supportno
Linux AIO support no
ATTR/XATTR support yes
Install blobs yes
KVM support   yes
COLO support  yes
RDMA support  no
TCG interpreter   no
fdt support   yes
preadv supportyes
fdatasync yes
madvise   yes
posix_madvise yes

[Qemu-devel] [PATCH] block/mirror: enable detect zeroes when driving mirror

[Yang Wei]

In order to preserve sparse disk image, detect_zeroes
should also be enabled when bdrv_get_block_status_above()
returns BDRV_BLOCK_DATA

Signed-off-by: Yang Wei 
---
 block/mirror.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/block/mirror.c b/block/mirror.c
index b2c1fb8..8b20b7a 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -76,6 +76,7 @@ typedef struct MirrorOp {
 QEMUIOVector qiov;
 int64_t sector_num;
 int nb_sectors;
+BlockdevDetectZeroesOptions backup_detect_zeroes;
 } MirrorOp;
 
 static BlockErrorAction mirror_error_action(MirrorBlockJob *s, bool read,
@@ -132,6 +133,8 @@ static void mirror_write_complete(void *opaque, int ret)
 {
 MirrorOp *op = opaque;
 MirrorBlockJob *s = op->s;
+BlockDriverState *target = s->target;
+target->detect_zeroes = op->backup_detect_zeroes;
 if (ret < 0) {
 BlockErrorAction action;
 
@@ -148,6 +151,7 @@ static void mirror_read_complete(void *opaque, int ret)
 {
 MirrorOp *op = opaque;
 MirrorBlockJob *s = op->s;
+BlockDriverState *target = s->target;
 if (ret < 0) {
 BlockErrorAction action;
 
@@ -160,6 +164,9 @@ static void mirror_read_complete(void *opaque, int ret)
 mirror_iteration_done(op, ret);
 return;
 }
+op->backup_detect_zeroes = target->detect_zeroes;
+target->detect_zeroes = s->unmap ? BLOCKDEV_DETECT_ZEROES_OPTIONS_UNMAP :
+BLOCKDEV_DETECT_ZEROES_OPTIONS_ON;
 blk_aio_pwritev(s->target, op->sector_num * BDRV_SECTOR_SIZE, >qiov,
 0, mirror_write_complete, op);
 }
-- 
2.10.2

Re: [Qemu-devel] [Qemu-ppc] Testing PowerPC floating point instructions

[joserz]

On Thu, Nov 17, 2016 at 10:57:41AM -0500, G 3 wrote:
> Is there an official way to test any of the PowerPC floating point
> instructions in QEMU?
> 

Hello!

it's not an "official way" but I've been working on Risu tool for PPC64le 
(https://wiki.linaro.org/PeterMaydell/Risu). I think the hardest part is done 
(implement the insns. file 
https://git.linaro.org/people/peter.maydell/risu.git/commit/?id=57b64ca433b95b6482ec92702fe473d6e684c20a)
 but I still have improvements to do. It could helps.

Regards,

Ziviani

[Qemu-devel] [PATCH] ppc: Make uninorth interrupt swizzling identical to Grackle

[BALATON Zoltan]

From: Benjamin Herrenschmidt 

It's currently broken as it uses an incorrect shift, it tries
to use the slot number but uses the top bits of the bus number
instead.

Note: Neither implementation matches what OpenBIOS ends up putting
in the device-tree either, which will have to be fixed separately.

This is not quite correct for modelling a real Mac since Apple
tend to tie all 4 interrupt lines of a slot together and have
separate interrupts for every slot and every motherboard devices
going straight to the PIC but we'll sort that out later.

Signed-off-by: Benjamin Herrenschmidt 
---
 hw/pci-host/uninorth.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

This needs a corresponding fix in OpenBIOS but this has to be
committed first for that. As this is already broken making this change
should not make things worse as they are now. Could we get this in now
as a bugfix commit?

diff --git a/hw/pci-host/uninorth.c b/hw/pci-host/uninorth.c
index 7aac4d6..df342ac 100644
--- a/hw/pci-host/uninorth.c
+++ b/hw/pci-host/uninorth.c
@@ -62,9 +62,7 @@ typedef struct UNINState {
 
 static int pci_unin_map_irq(PCIDevice *pci_dev, int irq_num)
 {
-int devfn = pci_dev->devfn & 0x00FF;
-
-return (((devfn >> 11) & 0x1F) + irq_num) & 3;
+return (irq_num + (pci_dev->devfn >> 3)) & 3;
 }
 
 static void pci_unin_set_irq(void *opaque, int irq_num, int level)
-- 
2.7.4

[Qemu-devel] About vNVDIMM question in TCG

[Lin Ma]

Hi Guangrong,
 
I'm interested in vNVDIMM on qemu. I'd like to give it a try on my laptop.
Because I dont have skylake server hardware, So I want to expose cpu flags
clflushopt, clwb and pcommit to guest for NVDIMM drivers on TCG.
 
I saw clflushopt and clwb feature flags in cpuinfo of guest, but no pcommit.
Could you please tell me is there anyhing wrong in my qemu CLI or anything
I misunderstand?
 
qemu-system-x86_64 \
-cpu Skylake-Client,+pcommit,+clflushopt,+clwb \
-machine pc-i440fx-2.8,nvdimm=on,accel=tcg \
-m 4G,maxmem=... \
-object memory-backend-file,... \
-device nvdimm,... \
 
BTW, In kvm mode, Even if I used '-cpu qemu64' without flags pcommit,
clflushopt and clwb, The block device /dev/pmem0 is still there and can 
be used successfully. Does it make sense? Doesn't nvdimm kernel driver
need pcommit, clflushopt and clwb to work?
 
Thanks,
Lin

[Qemu-devel] [Bug 1643342] Re: not able to passthrough mouse / keyboard

[marius]

** Description changed:

  After upgrading from qemu version 2.6.2 to 2.7.9 I can't boot my vm
  anymore. I get this error:
  
  qemu-system-x86_64: -usbdevice host:046d:c227: could not add USB device
  'host:046d:c227'
  
  This happens with every usb-device I tried. Works 2.6.2 without any errors. 
(also tried in 2.7.0, same error)
  I use the following script:
- 
  
  qemu-system-x86_64 \
  -enable-kvm \
  -m 16392 \
  -cpu host,kvm=off \
  -smp 4,sockets=1,cores=2,threads=2,maxcpus=4 \
  -usb -usbdevice host:046d:c227 -usbdevice host:046d:c226 \
  -vga none \
  -device vfio-pci,host=01:00.0,multifunction=on \
  -device vfio-pci,host=01:00.1 \
  -drive 
if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd
 \
  -drive if=pflash,format=raw,file=/tmp/my_vars.fd \
  -device virtio-scsi-pci,id=scsi \
  -drive file=/var/iso/win10.iso,id=isocd,format=raw,if=none -device 
scsi-cd,drive=isocd \
  -drive 
file=/home/marius/images/windows10.img,id=disk,format=raw,if=none,cache=writeback
 -device scsi-hd,drive=disk \
  -drive file=/var/iso/virtio-win-0.1.126.iso,id=virtiocd,if=none,format=raw 
-device ide-cd,bus=ide.1,drive=virtiocd
+ 
+ 
+ lsusb output:
+ Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
+ Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
+ Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
+ Bus 001 Device 009: ID 046d:c227 Logitech, Inc. G15 Refresh Keyboard
+ Bus 001 Device 008: ID 046d:c226 Logitech, Inc. G15 Refresh Keyboard
+ Bus 001 Device 007: ID 046d:c223 Logitech, Inc. G11/G15 Keyboard / USB Hub
+ Bus 001 Device 005: ID 8087:0a2b Intel Corp. 
+ Bus 001 Device 003: ID 1038:1384 SteelSeries ApS 
+ Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

** Description changed:

  After upgrading from qemu version 2.6.2 to 2.7.9 I can't boot my vm
  anymore. I get this error:
  
  qemu-system-x86_64: -usbdevice host:046d:c227: could not add USB device
  'host:046d:c227'
  
- This happens with every usb-device I tried. Works 2.6.2 without any errors. 
(also tried in 2.7.0, same error)
+ This happens with every usb-device I tried. Works in 2.6.2 without any 
errors. (also tried in 2.7.0, same error)
  I use the following script:
  
  qemu-system-x86_64 \
  -enable-kvm \
  -m 16392 \
  -cpu host,kvm=off \
  -smp 4,sockets=1,cores=2,threads=2,maxcpus=4 \
  -usb -usbdevice host:046d:c227 -usbdevice host:046d:c226 \
  -vga none \
  -device vfio-pci,host=01:00.0,multifunction=on \
  -device vfio-pci,host=01:00.1 \
  -drive 
if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd
 \
  -drive if=pflash,format=raw,file=/tmp/my_vars.fd \
  -device virtio-scsi-pci,id=scsi \
  -drive file=/var/iso/win10.iso,id=isocd,format=raw,if=none -device 
scsi-cd,drive=isocd \
  -drive 
file=/home/marius/images/windows10.img,id=disk,format=raw,if=none,cache=writeback
 -device scsi-hd,drive=disk \
  -drive file=/var/iso/virtio-win-0.1.126.iso,id=virtiocd,if=none,format=raw 
-device ide-cd,bus=ide.1,drive=virtiocd
  
- 
  lsusb output:
  Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
  Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
  Bus 001 Device 009: ID 046d:c227 Logitech, Inc. G15 Refresh Keyboard
  Bus 001 Device 008: ID 046d:c226 Logitech, Inc. G15 Refresh Keyboard
  Bus 001 Device 007: ID 046d:c223 Logitech, Inc. G11/G15 Keyboard / USB Hub
- Bus 001 Device 005: ID 8087:0a2b Intel Corp. 
- Bus 001 Device 003: ID 1038:1384 SteelSeries ApS 
+ Bus 001 Device 005: ID 8087:0a2b Intel Corp.
+ Bus 001 Device 003: ID 1038:1384 SteelSeries ApS
  Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

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

Title:
  not able to passthrough mouse / keyboard

Status in QEMU:
  New

Bug description:
  After upgrading from qemu version 2.6.2 to 2.7.9 I can't boot my vm
  anymore. I get this error:

  qemu-system-x86_64: -usbdevice host:046d:c227: could not add USB
  device 'host:046d:c227'

  This happens with every usb-device I tried. Works in 2.6.2 without any 
errors. (also tried in 2.7.0, same error)
  I use the following script:

  qemu-system-x86_64 \
  -enable-kvm \
  -m 16392 \
  -cpu host,kvm=off \
  -smp 4,sockets=1,cores=2,threads=2,maxcpus=4 \
  -usb -usbdevice host:046d:c227 -usbdevice host:046d:c226 \
  -vga none \
  -device vfio-pci,host=01:00.0,multifunction=on \
  -device vfio-pci,host=01:00.1 \
  -drive 
if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd
 \
  -drive if=pflash,format=raw,file=/tmp/my_vars.fd \
  -device virtio-scsi-pci,id=scsi \
  -drive file=/var/iso/win10.iso,id=isocd,format=raw,if=none -device 
scsi-cd,drive=isocd \
  -drive 

Re: [Qemu-devel] [PULL] tftp: fake support for netascii protocol

[no-reply]

Hi,

Your series seems to have some coding style problems. See output below for
more information:

Subject: [Qemu-devel] [PULL] tftp: fake support for netascii protocol
Type: series
Message-id: 20161120170517.9181-2-samuel.thiba...@ens-lyon.org

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] patchew/20161120170517.9181-2-samuel.thiba...@ens-lyon.org 
-> patchew/20161120170517.9181-2-samuel.thiba...@ens-lyon.org
Switched to a new branch 'test'
e9a07af tftp: fake support for netascii protocol

=== OUTPUT BEGIN ===
Checking PATCH 1/1: tftp: fake support for netascii protocol...
ERROR: suspect code indent for conditional statements (2, 6)
#35: FILE: slirp/tftp.c:330:
+  if (strcasecmp(>x.tp_buf[k], "octet") == 0) {
+  k += 6;

ERROR: suspect code indent for conditional statements (2, 6)
#37: FILE: slirp/tftp.c:332:
+  } else if (strcasecmp(>x.tp_buf[k], "netascii") == 0) {
+  qemu_log_mask(LOG_UNIMP, "tftp: netascii protocol not implemented, "

total: 2 errors, 0 warnings, 27 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@freelists.org

[Qemu-devel] [PULL] tftp: fake support for netascii protocol

[Samuel Thibault]

From: Vincent Bernat 

Some network equipments are requesting a file using the netascii
protocol and this is not configurable. Currently, qemu's tftpd only
supports the octet protocol. This commit makes it accept the netascii
protocol as well but do not perform the requested transformation (LF ->
CR,LF) as it would be far more complex. The current implementation is
good enough. A user has always the choice to preencode the served file
correctly.

Signed-off-by: Vincent Bernat 
Signed-off-by: Samuel Thibault 
---
 slirp/tftp.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/slirp/tftp.c b/slirp/tftp.c
index c185906..6907d5b 100644
--- a/slirp/tftp.c
+++ b/slirp/tftp.c
@@ -26,6 +26,7 @@
 #include "slirp.h"
 #include "qemu-common.h"
 #include "qemu/cutils.h"
+#include "qemu/log.h"
 
 static inline int tftp_session_in_use(struct tftp_session *spt)
 {
@@ -326,13 +327,17 @@ static void tftp_handle_rrq(Slirp *slirp, struct 
sockaddr_storage *srcsas,
 return;
   }
 
-  if (strcasecmp(>x.tp_buf[k], "octet") != 0) {
+  if (strcasecmp(>x.tp_buf[k], "octet") == 0) {
+  k += 6;
+  } else if (strcasecmp(>x.tp_buf[k], "netascii") == 0) {
+  qemu_log_mask(LOG_UNIMP, "tftp: netascii protocol not implemented, "
+"no CR-LF conversion\n");
+  k += 9;
+  } else {
   tftp_send_error(spt, 4, "Unsupported transfer mode", tp);
   return;
   }
 
-  k += 6; /* skipping octet */
-
   /* do sanity checks on the filename */
   if (!strncmp(req_fname, "../", 3) ||
   req_fname[strlen(req_fname) - 1] == '/' ||
-- 
2.10.2

[Qemu-devel] [PULL] tftp: fake support for netascii protocol

[Samuel Thibault]

The following changes since commit b0bcc86d2a87456f5a276f941dc775b265b309cf:

  Update version for v2.8.0-rc0 release (2016-11-15 20:55:12 +)

are available in the git repository at:

  http://people.debian.org/~sthibault/qemu.git tags/samuel-thibault

for you to fetch changes up to b4a952793033e322f9ab0a3661b3faeee17ba4e6:

  tftp: fake support for netascii protocol (2016-11-20 18:02:38 +0100)


slirp updates


Vincent Bernat (1):
  tftp: fake support for netascii protocol

 slirp/tftp.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

[Qemu-devel] [Bug 1643342] [NEW] not able to passthrough mouse / keyboard

[marius]

Public bug reported:

After upgrading from qemu version 2.6.2 to 2.7.9 I can't boot my vm
anymore. I get this error:

qemu-system-x86_64: -usbdevice host:046d:c227: could not add USB device
'host:046d:c227'

This happens with every usb-device I tried. Works 2.6.2 without any errors. 
(also tried in 2.7.0, same error)
I use the following script:


qemu-system-x86_64 \
-enable-kvm \
-m 16392 \
-cpu host,kvm=off \
-smp 4,sockets=1,cores=2,threads=2,maxcpus=4 \
-usb -usbdevice host:046d:c227 -usbdevice host:046d:c226 \
-vga none \
-device vfio-pci,host=01:00.0,multifunction=on \
-device vfio-pci,host=01:00.1 \
-drive 
if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd
 \
-drive if=pflash,format=raw,file=/tmp/my_vars.fd \
-device virtio-scsi-pci,id=scsi \
-drive file=/var/iso/win10.iso,id=isocd,format=raw,if=none -device 
scsi-cd,drive=isocd \
-drive 
file=/home/marius/images/windows10.img,id=disk,format=raw,if=none,cache=writeback
 -device scsi-hd,drive=disk \
-drive file=/var/iso/virtio-win-0.1.126.iso,id=virtiocd,if=none,format=raw 
-device ide-cd,bus=ide.1,drive=virtiocd

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: usb

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

Title:
  not able to passthrough mouse / keyboard

Status in QEMU:
  New

Bug description:
  After upgrading from qemu version 2.6.2 to 2.7.9 I can't boot my vm
  anymore. I get this error:

  qemu-system-x86_64: -usbdevice host:046d:c227: could not add USB
  device 'host:046d:c227'

  This happens with every usb-device I tried. Works 2.6.2 without any errors. 
(also tried in 2.7.0, same error)
  I use the following script:

  
  qemu-system-x86_64 \
  -enable-kvm \
  -m 16392 \
  -cpu host,kvm=off \
  -smp 4,sockets=1,cores=2,threads=2,maxcpus=4 \
  -usb -usbdevice host:046d:c227 -usbdevice host:046d:c226 \
  -vga none \
  -device vfio-pci,host=01:00.0,multifunction=on \
  -device vfio-pci,host=01:00.1 \
  -drive 
if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd
 \
  -drive if=pflash,format=raw,file=/tmp/my_vars.fd \
  -device virtio-scsi-pci,id=scsi \
  -drive file=/var/iso/win10.iso,id=isocd,format=raw,if=none -device 
scsi-cd,drive=isocd \
  -drive 
file=/home/marius/images/windows10.img,id=disk,format=raw,if=none,cache=writeback
 -device scsi-hd,drive=disk \
  -drive file=/var/iso/virtio-win-0.1.126.iso,id=virtiocd,if=none,format=raw 
-device ide-cd,bus=ide.1,drive=virtiocd

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

Re: [Qemu-devel] [Bug?] Guest pause because VMPTRLD failed in KVM

[gong lei]

On 2016/11/17 20:39, Paolo Bonzini wrote:
>
> On 10/11/2016 15:10, gong lei wrote:
>> 4) The isssue can't be reporduced. I search the Intel VMX sepc about 
>> reaseons
>> of vmptrld failure:
>> The instruction fails if its operand is not properly aligned, sets
>> unsupported physical-address bits, or is equal to the VMXON
>> pointer. In addition, the instruction fails if the 32 bits in memory
>> referenced by the operand do not match the VMCS
>> revision identifier supported by this processor.
>>
>> But I can't find any cues from the KVM source code. It seems each
>> error conditions is impossible in theory. :(
> Yes, it should not happen. :(
>
> If it's not reproducible, it's really hard to say what it was, except a
> random memory corruption elsewhere or even a bit flip (!).
>
> Paolo
Thanks for your reply, Paolo :)

-- 
Regards,
-Gonglei

Re: [Qemu-devel] [v2] tftp: fake support for netascii protocol

[no-reply]

Hi,

Your series seems to have some coding style problems. See output below for
more information:

Subject: [Qemu-devel] [v2] tftp: fake support for netascii protocol
Type: series
Message-id: 20161120084136.721-1-vincent.ber...@exoscale.ch

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] patchew/20161120084136.721-1-vincent.ber...@exoscale.ch -> 
patchew/20161120084136.721-1-vincent.ber...@exoscale.ch
Switched to a new branch 'test'
f8f1b3e tftp: fake support for netascii protocol

=== OUTPUT BEGIN ===
Checking PATCH 1/1: tftp: fake support for netascii protocol...
ERROR: suspect code indent for conditional statements (2, 6)
#34: FILE: slirp/tftp.c:330:
+  if (strcasecmp(>x.tp_buf[k], "octet") == 0) {
+  k += 6;

ERROR: suspect code indent for conditional statements (2, 6)
#36: FILE: slirp/tftp.c:332:
+  } else if (strcasecmp(>x.tp_buf[k], "netascii") == 0) {
+  qemu_log_mask(LOG_UNIMP, "tftp: netascii protocol not implemented, "

total: 2 errors, 0 warnings, 27 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@freelists.org

Re: [Qemu-devel] [PATCH v14 1/2] virtio-crypto: Add virtio crypto device specification

[gong lei]

On 2016/11/17 2:11, Halil Pasic wrote:
> On 11/11/2016 10:23 AM, Gonglei wrote:
>> The virtio crypto device is a virtual crypto device (ie. hardware
>> crypto accelerator card). Currently, the virtio crypto device provides
>> the following crypto services: CIPHER, MAC, HASH, and AEAD.
>>
>> In this patch, CIPHER, MAC, HASH, AEAD services are introduced.
>>
>> VIRTIO-153
>>
>> Signed-off-by: Gonglei
>> CC: Michael S. Tsirkin
>> CC: Cornelia Huck
>> CC: Stefan Hajnoczi
>> CC: Lingli Deng
>> CC: Jani Kokkonen
>> CC: Ola Liljedahl
>> CC: Varun Sethi
>> CC: Zeng Xin
>> CC: Keating Brian
>> CC: Ma Liang J
>> CC: Griffin John
>> CC: Hanweidong
>> CC: Mihai Claudiu Caraman
>> ---
>>   content.tex   |   2 +
>>   virtio-crypto.tex | 945 
>> ++
>>   2 files changed, 947 insertions(+)
>>   create mode 100644 virtio-crypto.tex
>>
>> diff --git a/content.tex b/content.tex
>> index 4b45678..ab75f78 100644
>> --- a/content.tex
>> +++ b/content.tex
>> @@ -5750,6 +5750,8 @@ descriptor for the \field{sense_len}, \field{residual},
>>   \field{status_qualifier}, \field{status}, \field{response} and
>>   \field{sense} fields.
>>
>> +\input{virtio-crypto.tex}
>> +
>>   \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
>>
>>   Currently there are three device-independent feature bits defined:
>> diff --git a/virtio-crypto.tex b/virtio-crypto.tex
>> new file mode 100644
>> index 000..9f7faf0
>> --- /dev/null
>> +++ b/virtio-crypto.tex
>> @@ -0,0 +1,945 @@
>> +\section{Crypto Device}\label{sec:Device Types / Crypto Device}
>> +
>> +The virtio crypto device is a virtual cryptography device as well as a kind 
>> of
>> +virtual hardware accelerator for virtual machines. The encryption and
>> +decryption requests are placed in the data queue and are ultimately handled 
>> by the
>   ~~
> The data queue can be misleading since its rather any of the data active
> queues.
Ok.

>> +backend crypto accelerators. The second queue is the control queue used to 
>> create
>  
> This could be confusing since it is a second type or kind of queue but
> not necessarily the queue with index 1.
Will change it.

>   
>> +or destroy sessions for symmetric algorithms and will control some advanced
>> +features in the future. The virtio crypto device provides the following 
>> crypto
> Promising future advanced features seems to be out of scope for this
> specification.
That's true, but I'd like to keep this statement so that people can know 
extend functions for controlq.

>> +services: CIPHER, MAC, HASH, and AEAD.
>> +
>> +
>> +\subsection{Device ID}\label{sec:Device Types / Crypto Device / Device ID}
>> +
>> +20
>> +
>> +\subsection{Virtqueues}\label{sec:Device Types / Crypto Device / Virtqueues}
>> +
>> +\begin{description}
>> +\item[0] dataq1
>> +\item[\ldots]
>> +\item[N-1] dataqN
>> +\item[N] controlq
>> +\end{description}
>> +
>> +N is set by \field{max_dataqueues}.
>> +
>> +\subsection{Feature bits}\label{sec:Device Types / Crypto Device / Feature 
>> bits}
>> +
>> +Undefined currently.
> Could use "None currently defined." like entropy device.
OK.

>> +
>> +\subsection{Device configuration layout}\label{sec:Device Types / Crypto 
>> Device / Device configuration layout}
>> +
>> +The following driver-read-only configuration fields are defined:
>> +
>> +\begin{lstlisting}
>> +struct virtio_crypto_config {
>> +le32 status;
>> +le32 max_dataqueues;
>> +le32 crypto_services;
>> +/* Detailed algorithms mask */
>> +le32 cipher_algo_l;
>> +le32 cipher_algo_h;
>> +le32 hash_algo;
>> +le32 mac_algo_l;
>> +le32 mac_algo_h;
>> +le32 aead_algo;
>> +/* Maximum length of cipher key */
>> +le32 max_cipher_key_len;
>> +/* Maximum length of authenticated key */
>> +le32 max_auth_key_len;
>> +le32 reserve;
>> +/* Maximum size of each crypto request's content */
>> +le64 max_size;
>> +};
>> +\end{lstlisting}
>> +
>> +The value of the \field{status} field is VIRTIO_CRYPTO_S_HW_READY or 
>> VIRTIO_CRYPTO_S_STARTED.
>> +
>> +\begin{lstlisting}
>> +#define VIRTIO_CRYPTO_S_HW_READY  (1 << 0)
>> +#define VIRTIO_CRYPTO_S_STARTED  (1 << 1)
>> +\end{lstlisting}
>> +
> Could not really figure out what this status actually does and how does
> it relate to the device status field if at all.
>
> Furthermore I see no mention of VIRTIO_CRYPTO_S_STARTED except for this
> one, so the only thing I can think of is that it's the initial value and
> means hardware not ready (you state these are the only two values).
Good 

Re: [Qemu-devel] [v2] tftp: fake support for netascii protocol

[no-reply]

Hi,

Your series seems to have some coding style problems. See output below for
more information:

Subject: [Qemu-devel] [v2] tftp: fake support for netascii protocol
Message-id: 20161120084136.721-1-vincent.ber...@exoscale.ch
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

# Useful git options
git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20161119185318.10564-1...@weilnetz.de -> 
patchew/20161119185318.10564-1...@weilnetz.de
 * [new tag] patchew/20161120084136.721-1-vincent.ber...@exoscale.ch -> 
patchew/20161120084136.721-1-vincent.ber...@exoscale.ch
Switched to a new branch 'test'
f8f1b3e tftp: fake support for netascii protocol

=== OUTPUT BEGIN ===
Checking PATCH 1/1: tftp: fake support for netascii protocol...
ERROR: suspect code indent for conditional statements (2, 6)
#34: FILE: slirp/tftp.c:330:
+  if (strcasecmp(>x.tp_buf[k], "octet") == 0) {
+  k += 6;

ERROR: suspect code indent for conditional statements (2, 6)
#36: FILE: slirp/tftp.c:332:
+  } else if (strcasecmp(>x.tp_buf[k], "netascii") == 0) {
+  qemu_log_mask(LOG_UNIMP, "tftp: netascii protocol not implemented, "

total: 2 errors, 0 warnings, 27 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@freelists.org

Re: [Qemu-devel] [PULL] tftp: fake support for netascii protocol

[Vincent Bernat]

 ❦ 19 novembre 2016 23:30 +0100, Samuel Thibault  :

>> > I think you should at least issue a qemu_log_mask(LOG_UNIMP, "...")
>> > call in that case.
>> 
>> I can do that if needed.
>
> That'd be better indeed. Otherwise people might wonder why things are
> not working. Warning that they have to do the LF -> CR,LF conversion by
> hand is important here.

I have sent an updated patch for that.

Totally unrelated, but on Debian, I have to use -r instead of -Wl,r for
LD_REL. This is explained here:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837574

I don't think the patch has been forwarded to you yet.
-- 
Don't patch bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)

[Qemu-devel] [v2] tftp: fake support for netascii protocol

[Vincent Bernat]

From: Vincent Bernat 

Some network equipments are requesting a file using the netascii
protocol and this is not configurable. Currently, qemu's tftpd only
supports the octet protocol. This commit makes it accept the netascii
protocol as well but do not perform the requested transformation (LF ->
CR,LF) as it would be far more complex. The current implementation is
good enough. A user has always the choice to preencode the served file
correctly.

Signed-off-by: Vincent Bernat 
---
 slirp/tftp.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/slirp/tftp.c b/slirp/tftp.c
index c1859066ccb2..6907d5b92074 100644
--- a/slirp/tftp.c
+++ b/slirp/tftp.c
@@ -26,6 +26,7 @@
 #include "slirp.h"
 #include "qemu-common.h"
 #include "qemu/cutils.h"
+#include "qemu/log.h"
 
 static inline int tftp_session_in_use(struct tftp_session *spt)
 {
@@ -326,13 +327,17 @@ static void tftp_handle_rrq(Slirp *slirp, struct 
sockaddr_storage *srcsas,
 return;
   }
 
-  if (strcasecmp(>x.tp_buf[k], "octet") != 0) {
+  if (strcasecmp(>x.tp_buf[k], "octet") == 0) {
+  k += 6;
+  } else if (strcasecmp(>x.tp_buf[k], "netascii") == 0) {
+  qemu_log_mask(LOG_UNIMP, "tftp: netascii protocol not implemented, "
+"no CR-LF conversion\n");
+  k += 9;
+  } else {
   tftp_send_error(spt, 4, "Unsupported transfer mode", tp);
   return;
   }
 
-  k += 6; /* skipping octet */
-
   /* do sanity checks on the filename */
   if (!strncmp(req_fname, "../", 3) ||
   req_fname[strlen(req_fname) - 1] == '/' ||
-- 
2.10.2