[Qemu-devel] [PATCH 2/4] coroutine-lock: convert CoQueue to use QemuLockable

2018-01-16 Thread Paolo Bonzini
There are cases in which a queued coroutine must be restarted from
non-coroutine context (with qemu_co_enter_next).  In this cases,
qemu_co_enter_next also needs to be thread-safe, but it cannot use
a CoMutex and so cannot qemu_co_queue_wait.  Use QemuLockable so
that the CoQueue can interchangeably use CoMutex or QemuMutex.

Signed-off-by: Paolo Bonzini 
---
 include/qemu/coroutine.h   |  6 +-
 util/qemu-coroutine-lock.c | 12 +++-
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/include/qemu/coroutine.h b/include/qemu/coroutine.h
index 8a5129741c..1e5f0957e6 100644
--- a/include/qemu/coroutine.h
+++ b/include/qemu/coroutine.h
@@ -183,7 +183,9 @@ void qemu_co_queue_init(CoQueue *queue);
  * caller of the coroutine.  The mutex is unlocked during the wait and
  * locked again afterwards.
  */
-void coroutine_fn qemu_co_queue_wait(CoQueue *queue, CoMutex *mutex);
+#define qemu_co_queue_wait(queue, lock) \
+qemu_co_queue_wait_impl(queue, QEMU_MAKE_LOCKABLE(lock))
+void coroutine_fn qemu_co_queue_wait_impl(CoQueue *queue, QemuLockable *lock);
 
 /**
  * Restarts the next coroutine in the CoQueue and removes it from the queue.
@@ -271,4 +273,6 @@ void coroutine_fn qemu_co_sleep_ns(QEMUClockType type, 
int64_t ns);
  */
 void coroutine_fn yield_until_fd_readable(int fd);
 
+#include "qemu/lockable.h"
+
 #endif /* QEMU_COROUTINE_H */
diff --git a/util/qemu-coroutine-lock.c b/util/qemu-coroutine-lock.c
index 846ff9167f..2a66fc1467 100644
--- a/util/qemu-coroutine-lock.c
+++ b/util/qemu-coroutine-lock.c
@@ -40,13 +40,13 @@ void qemu_co_queue_init(CoQueue *queue)
 QSIMPLEQ_INIT(&queue->entries);
 }
 
-void coroutine_fn qemu_co_queue_wait(CoQueue *queue, CoMutex *mutex)
+void coroutine_fn qemu_co_queue_wait_impl(CoQueue *queue, QemuLockable *lock)
 {
 Coroutine *self = qemu_coroutine_self();
 QSIMPLEQ_INSERT_TAIL(&queue->entries, self, co_queue_next);
 
-if (mutex) {
-qemu_co_mutex_unlock(mutex);
+if (lock) {
+qemu_lockable_unlock(lock);
 }
 
 /* There is no race condition here.  Other threads will call
@@ -60,9 +60,11 @@ void coroutine_fn qemu_co_queue_wait(CoQueue *queue, CoMutex 
*mutex)
 /* TODO: OSv implements wait morphing here, where the wakeup
  * primitive automatically places the woken coroutine on the
  * mutex's queue.  This avoids the thundering herd effect.
+ * This could be implemented for CoMutexes, but not really for
+ * other cases of QemuLockable.
  */
-if (mutex) {
-qemu_co_mutex_lock(mutex);
+if (lock) {
+qemu_lockable_lock(lock);
 }
 }
 
-- 
2.14.3





Re: [Qemu-devel] [PATCHv2 1/2] spapr: Allow some cases where we can't set VSMT mode in the kernel

2018-01-16 Thread Greg Kurz
On Tue, 16 Jan 2018 23:24:32 +1100
David Gibson  wrote:

> On Tue, Jan 16, 2018 at 10:20:18AM +0100, Greg Kurz wrote:
> > On Tue, 16 Jan 2018 15:47:13 +1100
> > David Gibson  wrote:
> >   
> > > At present if we require a vsmt mode that's not equal to the kernel's
> > > default, and the kernel doesn't let us change it (e.g. because it's an old
> > > kernel without support) then we always fail.
> > > 
> > > But in fact we can cope with the kernel having a different vsmt as long as
> > >   a) it's >= the actual number of vthreads/vcore (so that guest threads
> > >  that are supposed to be on the same core act like it)
> > >   b) it's a submultiple of the requested vsmt mode (so that guest threads
> > >  spaced by the vsmt value will act like they're on different cores)
> > > 
> > > Allowing this case gives us a bit more freedom to adjust the vsmt 
> > > behaviour
> > > without breaking existing cases.
> > > 
> > > Signed-off-by: David Gibson 
> > > ---  
> > 
> > I could check the following on a POWER9 host:
> > 
> > $ ./ppc64-softmmu/qemu-system-ppc64 -accel kvm -smp threads=1
> > qemu-system-ppc64: warning: Failed to set KVM's VSMT mode to 8 (errno -22)
> > 
> > and the guest boots.
> > 
> > $ ./ppc64-softmmu/qemu-system-ppc64 -accel kvm -smp threads=2
> > qemu-system-ppc64: Failed to set KVM's VSMT mode to 8 (errno -22)
> > On PPC, a VM with 2 threads/core on a host with 1 threads/core requires the
> >  use of VSMT mode 8.
> > This KVM seems to be too old to support VSMT.
> > 
> > and QEMU exits.  
> 
> I assume the above is with an old kernel that doesn't have the ability
> to set the SMT cap?
> 

Yes this was tested with a 4.11 kernel (setting of SMT came with 4.12).

> > 
> > Tested-by: Greg Kurz 
> > 
> > Just one minor remark below but anyway:
> > 
> > Reviewed-by: Greg Kurz 
> >   
> > >  hw/ppc/spapr.c | 26 +++---
> > >  1 file changed, 19 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > > index e35214bfc3..6d3613d934 100644
> > > --- a/hw/ppc/spapr.c
> > > +++ b/hw/ppc/spapr.c
> > > @@ -2314,17 +2314,29 @@ static void spapr_set_vsmt_mode(sPAPRMachineState 
> > > *spapr, Error **errp)
> > >  if (kvm_enabled() && (spapr->vsmt != kvm_smt)) {
> > >  ret = kvmppc_set_smt_threads(spapr->vsmt);
> > >  if (ret) {
> > > +/* Looks like KVM isn't able to change VSMT mode */
> > >  error_setg(&local_err,
> > > "Failed to set KVM's VSMT mode to %d (errno %d)",
> > > spapr->vsmt, ret);
> > > -if (!vsmt_user) {
> > > -error_append_hint(&local_err, "On PPC, a VM with %d 
> > > threads/"
> > > - "core on a host with %d threads/core 
> > > requires "
> > > - " the use of VSMT mode %d.\n",
> > > - smp_threads, kvm_smt, spapr->vsmt);
> > > +/* We can live with that if the default one is big enough
> > > + * for the number of threads, and a submultiple of the one
> > > + * we want.  In this case we'll waste some vcpu ids, but
> > > + * behaviour will be correct */
> > > +if ((kvm_smt >= smp_threads) && (spapr->vsmt % kvm_smt) == 
> > > 0) {  
> > 
> > Inconsistent use of parens in the left and right operands of &&
> >   
> > > +warn_report_err(local_err);
> > > +local_err = NULL;
> > > +goto out;
> > > +} else {
> > > +if (!vsmt_user) {
> > > +error_append_hint(&local_err,
> > > +  "On PPC, a VM with %d threads/core"
> > > +  " on a host with %d threads/core"
> > > +  " requires the use of VSMT mode 
> > > %d.\n",
> > > +  smp_threads, kvm_smt, spapr->vsmt);
> > > +}
> > > +kvmppc_hint_smt_possible(&local_err);
> > > +goto out;
> > >  }
> > > -kvmppc_hint_smt_possible(&local_err);
> > > -goto out;
> > >  }
> > >  }
> > >  /* else TCG: nothing to do currently */  
> >   
> 



pgp2wypl64yPk.pgp
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH] sun4u: implement power device

2018-01-16 Thread Marcel Apfelbaum


Hi Philippe,

On 16/01/2018 2:54, Philippe Mathieu-Daudé wrote:

CC'ing PCI maintainers.

Hi Mark,

On 01/15/2018 05:58 PM, Mark Cave-Ayland wrote:

This inbuilt device contains a single 4-byte register, of which bit 24 is used
to power down the machine on a real Ultra 5.

The power device exists at offset 0x724000 on a real machine, but due to the
current configuration of the BARs in QEMU it must be located lower in PCI IO
space.

Is is some issue in pci_bar_address()?



The QEMU IO layout:

/*
 * QEMU I/O address space usage:
 *    - 0ffflegacy isa, pci config, pci root bus, ...
 *   1000 - 9ffffree
 *   a000 - afffhotplug (cpu, pci via acpi, i440fx/piix only)
 *   b000 - bfffpower management (PORT_ACPI_PM_BASE)
 *  [ qemu 1.4+ implements pci config registers
 *properly so guests can place the registers
 *where they want, on older versions its fixed ]
 *   c000 - free, traditionally used for pci io
 */

As you can see we don't have IO address space over .

Thanks,
Marcel



For the moment we place the power device at offset 0x7240 as a reminder of its
original location and raise the base PCI IO address from 0x4000 to 0x8000.


If we can't fix it, I rather prefer a #define with a comment in the
code, IMHO this is safer and easier to remember than looking in git history.



Signed-off-by: Mark Cave-Ayland 
---
  hw/sparc64/sun4u.c | 64 +-
  1 file changed, 63 insertions(+), 1 deletion(-)

diff --git a/hw/sparc64/sun4u.c b/hw/sparc64/sun4u.c
index ec45ec2801..26ab6e9a9c 100644
--- a/hw/sparc64/sun4u.c
+++ b/hw/sparc64/sun4u.c
@@ -205,6 +205,59 @@ typedef struct ResetData {
  uint64_t prom_addr;
  } ResetData;
  
+#define TYPE_SUN4U_POWER "power"

+#define SUN4U_POWER(obj) OBJECT_CHECK(PowerDevice, (obj), TYPE_SUN4U_POWER)
+
+typedef struct PowerDevice {
+SysBusDevice parent_obj;
+
+MemoryRegion power_mmio;
+} PowerDevice;
+
+/* Power */
+static void power_mem_write(void *opaque, hwaddr addr,
+uint64_t val, unsigned size)
+{
+/* According to a real Ultra 5, bit 24 controls the power */
+if (val & 0x100) {
+qemu_system_shutdown_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN);
+}
+}
+
+static const MemoryRegionOps power_mem_ops = {
+.write = power_mem_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
+.valid = {
+.min_access_size = 4,
+.max_access_size = 4,
+},
+};
+
+static void power_realize(DeviceState *dev, Error **errp)
+{
+PowerDevice *d = SUN4U_POWER(dev);
+SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
+
+memory_region_init_io(&d->power_mmio, OBJECT(dev), &power_mem_ops, d,
+  "power", sizeof(uint32_t));
+
+sysbus_init_mmio(sbd, &d->power_mmio);
+}
+
+static void power_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+
+dc->realize = power_realize;
+}
+
+static const TypeInfo power_info = {
+.name  = TYPE_SUN4U_POWER,
+.parent= TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(PowerDevice),
+.class_init= power_class_init,
+};
+
  static void ebus_isa_irq_handler(void *opaque, int n, int level)
  {
  EbusState *s = EBUS(opaque);
@@ -221,6 +274,7 @@ static void ebus_isa_irq_handler(void *opaque, int n, int 
level)
  static void ebus_realize(PCIDevice *pci_dev, Error **errp)
  {
  EbusState *s = EBUS(pci_dev);
+SysBusDevice *sbd;
  DeviceState *dev;
  qemu_irq *isa_irq;
  DriveInfo *fd[MAX_FD];
@@ -270,6 +324,13 @@ static void ebus_realize(PCIDevice *pci_dev, Error **errp)
  qdev_prop_set_uint32(dev, "dma", -1);
  qdev_init_nofail(dev);
  
+/* Power */

+dev = qdev_create(NULL, TYPE_SUN4U_POWER);
+qdev_init_nofail(dev);
+sbd = SYS_BUS_DEVICE(dev);
+memory_region_add_subregion(pci_address_space_io(pci_dev), 0x7240,
+sysbus_mmio_get_region(sbd, 0));
+
  /* PCI */
  pci_dev->config[0x04] = 0x06; // command = bus master, pci mem
  pci_dev->config[0x05] = 0x00;
@@ -282,7 +343,7 @@ static void ebus_realize(PCIDevice *pci_dev, Error **errp)
   0, 0x100);
  pci_register_bar(pci_dev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY, &s->bar0);
  memory_region_init_alias(&s->bar1, OBJECT(s), "bar1", get_system_io(),
- 0, 0x4000);
+ 0, 0x8000);


What about using 2 MR, bar1_lo/bar1_hi, registering bar1_lo at offset @0
and bar1_hi at @0x724000?


  pci_register_bar(pci_dev, 1, PCI_BASE_ADDRESS_SPACE_IO, &s->bar1);
  }
  
@@ -693,6 +754,7 @@ static const TypeInfo sun4v_type = {
  
  static void sun4u_register_types(void)

  {
+type_register_static(&power_info);
  type_register_static(&ebus_info);
  type_register_static(&prom_info);
  type_register_static

[Qemu-devel] [PATCH 4/4] curl: convert to CoQueue

2018-01-16 Thread Paolo Bonzini
Now that CoQueues can use a QemuMutex for thread-safety, there is no
need for curl to roll its own coroutine queue.  Coroutines can be
placed directly on the queue instead of using a list of CURLAIOCBs.

Signed-off-by: Paolo Bonzini 
---
 block/curl.c | 20 
 1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/block/curl.c b/block/curl.c
index 35cf417f59..cd578d3d14 100644
--- a/block/curl.c
+++ b/block/curl.c
@@ -101,8 +101,6 @@ typedef struct CURLAIOCB {
 
 size_t start;
 size_t end;
-
-QSIMPLEQ_ENTRY(CURLAIOCB) next;
 } CURLAIOCB;
 
 typedef struct CURLSocket {
@@ -138,7 +136,7 @@ typedef struct BDRVCURLState {
 bool accept_range;
 AioContext *aio_context;
 QemuMutex mutex;
-QSIMPLEQ_HEAD(, CURLAIOCB) free_state_waitq;
+CoQueue free_state_waitq;
 char *username;
 char *password;
 char *proxyusername;
@@ -538,7 +536,6 @@ static int curl_init_state(BDRVCURLState *s, CURLState 
*state)
 /* Called with s->mutex held.  */
 static void curl_clean_state(CURLState *s)
 {
-CURLAIOCB *next;
 int j;
 for (j = 0; j < CURL_NUM_ACB; j++) {
 assert(!s->acb[j]);
@@ -556,13 +553,7 @@ static void curl_clean_state(CURLState *s)
 
 s->in_use = 0;
 
-next = QSIMPLEQ_FIRST(&s->s->free_state_waitq);
-if (next) {
-QSIMPLEQ_REMOVE_HEAD(&s->s->free_state_waitq, next);
-qemu_mutex_unlock(&s->s->mutex);
-aio_co_wake(next->co);
-qemu_mutex_lock(&s->s->mutex);
-}
+qemu_co_enter_next(&s->s->free_state_waitq, &s->s->mutex);
 }
 
 static void curl_parse_filename(const char *filename, QDict *options,
@@ -784,7 +775,7 @@ static int curl_open(BlockDriverState *bs, QDict *options, 
int flags,
 }
 
 DPRINTF("CURL: Opening %s\n", file);
-QSIMPLEQ_INIT(&s->free_state_waitq);
+qemu_co_queue_init(&s->free_state_waitq);
 s->aio_context = bdrv_get_aio_context(bs);
 s->url = g_strdup(file);
 qemu_mutex_lock(&s->mutex);
@@ -888,10 +879,7 @@ static void curl_setup_preadv(BlockDriverState *bs, 
CURLAIOCB *acb)
 if (state) {
 break;
 }
-QSIMPLEQ_INSERT_TAIL(&s->free_state_waitq, acb, next);
-qemu_mutex_unlock(&s->mutex);
-qemu_coroutine_yield();
-qemu_mutex_lock(&s->mutex);
+qemu_co_queue_wait(&s->free_state_waitq, &s->mutex);
 }
 
 if (curl_init_state(s, state) < 0) {
-- 
2.14.3




[Qemu-devel] [PULL 42/51] tests: Avoid 'do/while(false); ' in vhost-user-bridge

2018-01-16 Thread Paolo Bonzini
From: Eric Blake 

Use of a do/while(0) loop as a way to allow break statements in
the middle of execute-once code is unusual.  More typical is
the use of goto for early exits, with a label at the end of
the execute-once code, rather than nesting code in a scope;
however, the comment at the end of the existing code makes this
alternative a bit unpractical.

So, to avoid false positives from a future syntax check about
'while (false);', and to keep the loop form (in case someone
ever does add DONTWAIT support, where they can just as easily
manipulate the initial loop condition or add an if around the
final 'break'), I opted to use the form of a while(1) loop (the
break as an early exit is more idiomatic there), coupled with
a final break preserving the original comment.

Signed-off-by: Eric Blake 
Message-Id: <20171201232433.25193-6-ebl...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 tests/vhost-user-bridge.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tests/vhost-user-bridge.c b/tests/vhost-user-bridge.c
index d820033..e0605a5 100644
--- a/tests/vhost-user-bridge.c
+++ b/tests/vhost-user-bridge.c
@@ -283,7 +283,7 @@ vubr_backend_recv_cb(int sock, void *ctx)
 return;
 }
 
-do {
+while (1) {
 struct iovec *sg;
 ssize_t ret, total = 0;
 unsigned int num;
@@ -343,7 +343,9 @@ vubr_backend_recv_cb(int sock, void *ctx)
 
 free(elem);
 elem = NULL;
-} while (false); /* could loop if DONTWAIT worked? */
+
+break;/* could loop if DONTWAIT worked? */
+}
 
 if (mhdr_cnt) {
 mhdr.num_buffers = i;
-- 
1.8.3.1





Re: [Qemu-devel] [PATCH v4 12/14] i.MX: Add i.MX7 SOC implementation.

2018-01-16 Thread Peter Maydell
On 16 January 2018 at 01:37, Andrey Smirnov  wrote:
> The following interfaces are partially or fully emulated:
>
> * up to 2 Cortex A9 cores (SMP works with PSCI)
> * A7 MPCORE (identical to A15 MPCORE)
> * 4 GPTs modules
> * 7 GPIO controllers
> * 2 IOMUXC controllers
> * 1 CCM module
> * 1 SVNS module
> * 1 SRC module
> * 1 GPCv2 controller
> * 4 eCSPI controllers
> * 4 I2C controllers
> * 7 i.MX UART controllers
> * 2 FlexCAN controllers
> * 2 Ethernet controllers (FEC)
> * 3 SD controllers (USDHC)
> * 4 WDT modules
> * 1 SDMA module
> * 1 GPR module
> * 2 USBMISC modules
> * 2 ADC modules
> * 1 PCIe controller
>
> Tested to boot and work with upstream Linux (4.13+) guest.
>
> Cc: Peter Maydell 
> Cc: Jason Wang 
> Cc: Philippe Mathieu-Daudé 
> Cc: qemu-devel@nongnu.org
> Cc: qemu-...@nongnu.org
> Cc: yurov...@gmail.com
> Signed-off-by: Andrey Smirnov 
> ---

Reviewed-by: Peter Maydell 

thanks
-- PMM



[Qemu-devel] [PULL 45/51] cpu_physical_memory_sync_dirty_bitmap: Another alignment fix

2018-01-16 Thread Paolo Bonzini
From: "Dr. David Alan Gilbert" 

This code has an optimised, word aligned version, and a boring
unaligned version. My commit f70d345 fixed one alignment issue, but
there's another.

The optimised version operates on 'longs' dealing with (typically) 64
pages at a time, replacing the whole long by a 0 and counting the bits.
If the Ramblock is less than 64bits in length that long can contain bits
representing two different RAMBlocks, but the code will update the
bmap belinging to the 1st RAMBlock only while having updated the total
dirty page count for both.

This probably didn't matter prior to 6b6712ef which split the dirty
bitmap by RAMBlock, but now they're separate RAMBlocks we end up
with a count that doesn't match the state in the bitmaps.

Symptom:
  Migration showing a few dirty pages left to be sent constantly
  Seen on aarch64 and x86 with x86+ovmf

Signed-off-by: Dr. David Alan Gilbert 
Reported-by: Wei Huang 
Fixes: 6b6712efccd383b48a909bee0b29e079a57601ec
Signed-off-by: Paolo Bonzini 
---
 include/exec/ram_addr.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index 6cbc02a..7633ef6 100644
--- a/include/exec/ram_addr.h
+++ b/include/exec/ram_addr.h
@@ -391,9 +391,10 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock 
*rb,
 uint64_t num_dirty = 0;
 unsigned long *dest = rb->bmap;
 
-/* start address is aligned at the start of a word? */
+/* start address and length is aligned at the start of a word? */
 if (((word * BITS_PER_LONG) << TARGET_PAGE_BITS) ==
- (start + rb->offset)) {
+ (start + rb->offset) &&
+!(length & ((BITS_PER_LONG << TARGET_PAGE_BITS) - 1))) {
 int k;
 int nr = BITS_TO_LONGS(length >> TARGET_PAGE_BITS);
 unsigned long * const *src;
-- 
1.8.3.1





Re: [Qemu-devel] [PATCH v4 07/14] i.MX: Add i.MX7 GPT variant

2018-01-16 Thread Peter Maydell
On 16 January 2018 at 01:37, Andrey Smirnov  wrote:
> Add minimal code needed to allow upstream Linux guest to boot.
>
> Cc: Peter Maydell 
> Cc: Jason Wang 
> Cc: Philippe Mathieu-Daudé 
> Cc: qemu-devel@nongnu.org
> Cc: qemu-...@nongnu.org
> Cc: yurov...@gmail.com
> Signed-off-by: Andrey Smirnov 
> ---

Reviewed-by: Peter Maydell 

thanks
-- PMM



[Qemu-devel] [PULL 49/51] cpu: flush TB cache when loading VMState

2018-01-16 Thread Paolo Bonzini
From: Pavel Dovgalyuk 

Flushing TB cache is required because TBs key in the cache may match
different code which existed in the previous state.

Signed-off-by: Pavel Dovgalyuk 
Signed-off-by: Maria Klimushenkova 
Message-Id: <20180110134846.12940.3.stgit@pasha-VirtualBox>
[Add comment suggested by Peter Maydell. - Paolo]
Signed-off-by: Paolo Bonzini 
Signed-off-by: Pavel Dovgalyuk 
---
 exec.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/exec.c b/exec.c
index 9f4f450..d28fc0c 100644
--- a/exec.c
+++ b/exec.c
@@ -623,6 +623,13 @@ static int cpu_common_post_load(void *opaque, int 
version_id)
 cpu->interrupt_request &= ~0x01;
 tlb_flush(cpu);
 
+/* loadvm has just updated the content of RAM, bypassing the
+ * usual mechanisms that ensure we flush TBs for writes to
+ * memory we've translated code from. So we must flush all TBs,
+ * which will now be stale.
+ */
+tb_flush(cpu);
+
 return 0;
 }
 
-- 
1.8.3.1





Re: [Qemu-devel] [PATCH v4 03/14] i.MX: Add code to emulate i.MX7 CCM, PMU and ANALOG IP blocks

2018-01-16 Thread Peter Maydell
On 16 January 2018 at 01:36, Andrey Smirnov  wrote:
> Add minimal code needed to allow upstream Linux guest to boot.
>
> Cc: Peter Maydell 
> Cc: Jason Wang 
> Cc: Philippe Mathieu-Daudé 
> Cc: qemu-devel@nongnu.org
> Cc: qemu-...@nongnu.org
> Cc: yurov...@gmail.com
> Signed-off-by: Andrey Smirnov 
> ---
>  hw/misc/Makefile.objs  |   1 +
>  hw/misc/imx7_ccm.c | 277 
> +
>  include/hw/misc/imx7_ccm.h | 139 +++
>  3 files changed, 417 insertions(+)
>  create mode 100644 hw/misc/imx7_ccm.c
>  create mode 100644 include/hw/misc/imx7_ccm.h
>

Reviewed-by: Peter Maydell 

thanks
-- PMM



Re: [Qemu-devel] [PULL 08/51] chardev: introduce qemu_chr_timeout_add_ms()

2018-01-16 Thread Daniel P. Berrange
On Tue, Jan 16, 2018 at 03:16:50PM +0100, Paolo Bonzini wrote:
> From: Peter Xu 
> 
> It's a replacement of g_timeout_add[_seconds]() for chardevs.  Chardevs
> now can have dedicated gcontext, we should always bind chardev tasks
> onto those gcontext rather than the default main context.  Since there
> are quite a few of g_timeout_add[_seconds]() callers, a new function
> qemu_chr_timeout_add_ms() is introduced.

FYI the point of using g_timeout_add_seconds() is that it allow the
glib event loop to be more efficient. It ensures that all timers
which second granularity are dispatched on the same iteration of
the main loop. IOW, if you have 10 timers registered with
g_timeout_add_seconds() the main loop wakes up once a second and
runs all 10 of them. If you have 10 timers registered with g_timeout_add
the main loop wakes up 10 times a second, at a different time for each
timer.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|



Re: [Qemu-devel] [PATCH v4 10/14] usb: Add basic code to emulate Chipidea USB IP

2018-01-16 Thread Peter Maydell
On 16 January 2018 at 01:37, Andrey Smirnov  wrote:
> Add code to emulate Chipidea USB IP (used in i.MX SoCs). Tested to
> work against:
>
> -usb -drive if=none,id=stick,file=usb.img,format=raw -device \
>  usb-storage,bus=usb-bus.0,drive=stick
>
> Cc: Peter Maydell 
> Cc: Jason Wang 
> Cc: Philippe Mathieu-Daudé 
> Cc: qemu-devel@nongnu.org
> Cc: qemu-...@nongnu.org
> Cc: yurov...@gmail.com
> Signed-off-by: Andrey Smirnov 
> ---

This looked a little odd at first but I see it's how we're
implementing TYPE_FUSBH200_EHCI, so I guess it's ok.

Reviewed-by: Peter Maydell 

thanks
-- PMM



[Qemu-devel] [PULL 47/51] find_ram_offset: Align ram_addr_t allocation on long boundaries

2018-01-16 Thread Paolo Bonzini
From: "Dr. David Alan Gilbert" 

The dirty bitmaps are built from 'long's and there is fast-path code
for synchronising the case where the RAMBlock is aligned to the start
of a long boundary.  Align the allocation to this boundary
to cause the fast path to be used.

Offsets before change:
11398@1515169675.018566:find_ram_offset size: 0x1e @ 0x800
11398@1515169675.020064:find_ram_offset size: 0x2 @ 0x81e
11398@1515169675.020244:find_ram_offset size: 0x2 @ 0x820
11398@1515169675.024343:find_ram_offset size: 0x100 @ 0x822
11398@1515169675.025154:find_ram_offset size: 0x1 @ 0x922
11398@1515169675.027682:find_ram_offset size: 0x4 @ 0x923
11398@1515169675.032921:find_ram_offset size: 0x20 @ 0x927
11398@1515169675.033307:find_ram_offset size: 0x1000 @ 0x947
11398@1515169675.033601:find_ram_offset size: 0x1000 @ 0x9471000

after change:
10923@1515169108.818245:find_ram_offset size: 0x1e @ 0x800
10923@1515169108.819410:find_ram_offset size: 0x2 @ 0x820
10923@1515169108.819587:find_ram_offset size: 0x2 @ 0x824
10923@1515169108.823708:find_ram_offset size: 0x100 @ 0x828
10923@1515169108.824503:find_ram_offset size: 0x1 @ 0x928
10923@1515169108.827093:find_ram_offset size: 0x4 @ 0x92c
10923@1515169108.833045:find_ram_offset size: 0x20 @ 0x930
10923@1515169108.833504:find_ram_offset size: 0x1000 @ 0x950
10923@1515169108.833787:find_ram_offset size: 0x1000 @ 0x954

Suggested-by: Paolo Bonzini 
Signed-off-by: Dr. David Alan Gilbert 
Message-Id: <20180105170138.23357-3-dgilb...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 exec.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/exec.c b/exec.c
index 5e2fb55..9f4f450 100644
--- a/exec.c
+++ b/exec.c
@@ -1678,7 +1678,11 @@ static ram_addr_t find_ram_offset(ram_addr_t size)
 RAMBLOCK_FOREACH(block) {
 ram_addr_t candidate, next = RAM_ADDR_MAX;
 
+/* Align blocks to start on a 'long' in the bitmap
+ * which makes the bitmap sync'ing take the fast path.
+ */
 candidate = block->offset + block->max_length;
+candidate = ROUND_UP(candidate, BITS_PER_LONG << TARGET_PAGE_BITS);
 
 /* Search for the closest following block
  * and find the gap.
-- 
1.8.3.1





Re: [Qemu-devel] [PATCH v5 08/14] qapi: force a UTF-8 locale for running Python

2018-01-16 Thread Eric Blake
On 01/16/2018 07:42 AM, Daniel P. Berrange wrote:
> Python2 did not validate locale correctness when reading input data, so
> would happily read UTF-8 data in non-UTF-8 locales. Python3 is strict so
> if you try to read UTF-8 data in the C locale, it will raise an error
> for any UTF-8 bytes that aren't representable in 7-bit ascii encoding.
> e.g.
> 

> 
> Many distros support a new C.UTF-8 locale that is like the C locale,
> but with UTF-8 instead of 7-bit ASCII. That is not entirely portable
> though. This patch thus sets the LANG to "C", but overrides LC_CTYPE
> to be en_US.UTF-8 locale. This gets us pretty close to C.UTF-8, but
> in a way that should be portable to everywhere QEMU builds.
> 
> This patch only forces UTF-8 for QAPI scripts, since that is the one
> showing the immediate error under Python3 with C locale, but potentially
> we ought to force this for all python scripts used in the build process.
> 
> Signed-off-by: Daniel P. Berrange 
> ---
>  Makefile | 22 --
>  1 file changed, 12 insertions(+), 10 deletions(-)

Reviewed-by: Eric Blake 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PULL v3 00/53] Misc changes for 2017-01-12

2018-01-16 Thread Paolo Bonzini
On 16/01/2018 14:50, Marc-André Lureau wrote:
> Hi
> 
> On Tue, Jan 16, 2018 at 1:06 PM, Peter Maydell  
> wrote:
>> On 16 January 2018 at 11:58, Marc-André Lureau
>>  wrote:
>>> Hi
>>>
>>> On Tue, Jan 16, 2018 at 12:25 PM, Peter Maydell
>>>  wrote:
 On 15 January 2018 at 23:35, Paolo Bonzini  wrote:
> The following changes since commit 
> 997eba28a3ed5400a80f754bf3a1c8044b75b9ff:
>
>   Merge remote-tracking branch 
> 'remotes/pmaydell/tags/pull-target-arm-20180111' into staging (2018-01-11 
> 14:34:41 +)
>
> are available in the git repository at:
>
>
>   git://github.com/bonzini/qemu.git tags/for-upstream
>
> for you to fetch changes up to ff9adba50bf8a4c080b8aee9be2314ef179a7b5f:
>
>   ucontext: annotate coroutine stack for ASAN (2018-01-12 15:21:14 +0100)
>
> 
> * QemuMutex tracing improvements (Alex)
> * ram_addr_t optimization (David)
> * SCSI fixes (Fam, Stefan, me)
> * do {} while (0) fixes (Eric)
> * KVM fix for PMU (Jan)
> * memory leak fixes from ASAN (Marc-André)
> * migration fix for HPET, icount, loadvm (Maria, Pavel)
> * hflags fixes (me, Tao)
> * block/iscsi uninitialized variable (Peter L.)
> * full support for GMainContexts in character devices (Peter Xu)
> * more boot-serial-test (Thomas)
> * Memory leak fix (Zhecheng)

 Various build failures, I'm afraid:

>>>
>>> damn, sorry..
>>>
 x86-64/Linux/gcc:

 configure produces an error message:

 ERROR: ASAN build enabled, but ASAN header is too old.
Without code annotation, the report may be inferior.

 even though this configure did not explicitly request ASAN.
 Then configure seems to exit successfully anyway, since the
 build proceeds.
>>>
>>> ASAN is enabled by default if available when --enable-debug. We could
>>> add more flags if that helps.
>>
>> Configure switches should work like this:
>>  * default: use feature if present, but don't complain if not present
>>or not usable
>>  * --enable-foo: use feature. if feature not present, complain and
>>fail configure
>>  * --disable-foo: don't test for or use feature
> 
> Would that be enough to drop the "ERROR:" prefix ?
> 
 For some reason the build creates config-target.h a lot:
>>
>>> One per target no? (the build should be more silent than before)
>>
>> Oh, I guess that makes sense. It's a bit odd that the message neither
>> gives the target part of the filename nor has those entering/leaving
>> directory messages...
>>

 Then it runs configure again, this time without the ERROR message,
 and eventually fails with:

   CC  hw/display/exynos4210_fimd.o
 /home/petmay01/linaro/qemu-for-merges/hw/display/exynos4210_fimd.c: In
 function ‘fimd_get_buffer_id’:
 /home/petmay01/linaro/qemu-for-merges/hw/display/exynos4210_fimd.c:1105:5:
 error: case label does not reduce to an integer constant
  case FIMD_WINCON_BUF2_STAT:
>>>
>>> never saw that error, hmm interesting. This is related to
>>> -fsanitize=address ? Is this on Debian stable?
> 
> Interesting, looks like a bug in gcc ubsan that doesn't happen with
> recent versions (related to
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80550 but probably a
> different bug). Adding a cast is enough:
> 
> -#define FIMD_WINCON_BUF2_STAT   ((0 << 21) | (1 << 31))
> +#define FIMD_WINCON_BUF2_STAT   (uint32_t)((0 << 21) | (1 << 31))
> 
> It looks like there are no other cases like this
> 
> 
> 
>>
>> Ubuntu xenial (16.04.3 LTS). No idea if it's related to the
>> sanitizer or not.
>>
>>>
  ^

 On sparc64 host configure fails:
>>
>>> Hmm, I guess the check -fsanitize=address doesn't return an error
>>> unless -Werror is given. Perhaps it needs:
>>>
>>> diff --git a/configure b/configure
>>> index f5550f3289..ba68c550c9 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -5190,7 +5190,7 @@ fi
>>>
>>>  have_asan=no
>>>  write_c_skeleton
>>> -if compile_prog "-fsanitize=address" ""; then
>>> +if compile_prog "-Werror -fsanitize=address" ""; then
>>>  have_asan=yes
>>>  fi
>>>
>>> @@ -5207,7 +5207,7 @@ int main(void) {
>>>return 0;
>>>  }
>>>  EOF
>>> -if compile_prog "-fsanitize=address" "" ; then
>>> +if compile_prog "-Werror -fsanitize=address" "" ; then
>>>  have_asan_iface_fiber=yes
>>>  fi
>>>
>>
>> Looks plausible.
> 
> Actually, it probably needs also $CPU_CFLAGS
> 
> Paolo, would you drop "build-sys: add some sanitizers when
> --enable-debug if possible" & "ucontext: annotate coroutine stack for
> ASAN" from the series? I'll send a new version for those 2.

Yes, that was already my plan.  Thanks for confirming!

Paolo



[Qemu-devel] [PATCH 1/4] lockable: add QemuLockable

2018-01-16 Thread Paolo Bonzini
QemuLockable is a polymorphic lock type that takes an object and
knows which function to use for locking and unlocking.  The
implementation could use C11 _Generic, but since the support is
not very widespread I am instead using __builtin_choose_expr and
__builtin_types_compatible_p, which are already used by
include/qemu/atomic.h.

QemuLockable can be used to implement lock guards (in which case the
indirect function calls should be inlined and devirtualized), or to
pass around a lock in such a way that a function can release it and
re-acquire it.  The next patch will do this for CoQueue.

Signed-off-by: Paolo Bonzini 
---
 include/qemu/compiler.h  | 40 ++
 include/qemu/coroutine.h |  4 +--
 include/qemu/lockable.h  | 75 
 include/qemu/thread.h|  5 ++--
 include/qemu/typedefs.h  |  4 +++
 5 files changed, 123 insertions(+), 5 deletions(-)
 create mode 100644 include/qemu/lockable.h

diff --git a/include/qemu/compiler.h b/include/qemu/compiler.h
index 340e5fdc09..5179bedb1e 100644
--- a/include/qemu/compiler.h
+++ b/include/qemu/compiler.h
@@ -111,4 +111,44 @@
 #define GCC_FMT_ATTR(n, m)
 #endif
 
+/* Implement C11 _Generic via GCC builtins.  Example:
+ *
+ *QEMU_GENERIC(x, (float, sinf), (long double, sinl), sin) (x)
+ *
+ * The first argument is the discriminator.  The last is the default value.
+ * The middle ones are tuples in "(type, expansion)" format.
+ */
+
+/* First, find out the number of generic cases.  */
+#define QEMU_GENERIC(x, ...) \
+QEMU_GENERIC_(typeof(x), __VA_ARGS__, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0)
+
+/* There will be extra arguments, but they are not used.  */
+#define QEMU_GENERIC_(x, a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, count, ...) \
+QEMU_GENERIC##count(x, a0, a1, a2, a3, a4, a5, a6, a7, a8, a9)
+
+/* Two more helper macros, this time to extract items from a parenthesized
+ * list.
+ */
+#define QEMU_FIRST_(a, b) a
+#define QEMU_SECOND_(a, b) b
+
+/* ... and a final one for the common part of the "recursion".  */
+#define QEMU_GENERIC_IF(x, type_then, else_)   
\
+__builtin_choose_expr(__builtin_types_compatible_p(x,  
\
+   QEMU_FIRST_ type_then), 
\
+  QEMU_SECOND_ type_then, else_)
+
+/* CPP poor man's "recursion".  */
+#define QEMU_GENERIC1(x, a0, ...) (a0)
+#define QEMU_GENERIC2(x, a0, ...) QEMU_GENERIC_IF(x, a0, QEMU_GENERIC1(x, 
__VA_ARGS__))
+#define QEMU_GENERIC3(x, a0, ...) QEMU_GENERIC_IF(x, a0, QEMU_GENERIC2(x, 
__VA_ARGS__))
+#define QEMU_GENERIC4(x, a0, ...) QEMU_GENERIC_IF(x, a0, QEMU_GENERIC3(x, 
__VA_ARGS__))
+#define QEMU_GENERIC5(x, a0, ...) QEMU_GENERIC_IF(x, a0, QEMU_GENERIC4(x, 
__VA_ARGS__))
+#define QEMU_GENERIC6(x, a0, ...) QEMU_GENERIC_IF(x, a0, QEMU_GENERIC5(x, 
__VA_ARGS__))
+#define QEMU_GENERIC7(x, a0, ...) QEMU_GENERIC_IF(x, a0, QEMU_GENERIC6(x, 
__VA_ARGS__))
+#define QEMU_GENERIC8(x, a0, ...) QEMU_GENERIC_IF(x, a0, QEMU_GENERIC7(x, 
__VA_ARGS__))
+#define QEMU_GENERIC9(x, a0, ...) QEMU_GENERIC_IF(x, a0, QEMU_GENERIC8(x, 
__VA_ARGS__))
+#define QEMU_GENERIC10(x, a0, ...) QEMU_GENERIC_IF(x, a0, QEMU_GENERIC9(x, 
__VA_ARGS__))
+
 #endif /* COMPILER_H */
diff --git a/include/qemu/coroutine.h b/include/qemu/coroutine.h
index ce2eb73670..8a5129741c 100644
--- a/include/qemu/coroutine.h
+++ b/include/qemu/coroutine.h
@@ -121,7 +121,7 @@ bool qemu_coroutine_entered(Coroutine *co);
  * Provides a mutex that can be used to synchronise coroutines
  */
 struct CoWaitRecord;
-typedef struct CoMutex {
+struct CoMutex {
 /* Count of pending lockers; 0 for a free mutex, 1 for an
  * uncontended mutex.
  */
@@ -142,7 +142,7 @@ typedef struct CoMutex {
 unsigned handoff, sequence;
 
 Coroutine *holder;
-} CoMutex;
+};
 
 /**
  * Initialises a CoMutex. This must be called before any other operation is 
used
diff --git a/include/qemu/lockable.h b/include/qemu/lockable.h
new file mode 100644
index 00..e280431290
--- /dev/null
+++ b/include/qemu/lockable.h
@@ -0,0 +1,75 @@
+/*
+ * Polymorphic locking functions (aka poor man templates)
+ *
+ * Copyright Red Hat, Inc. 2017-2018
+ *
+ * Author: Paolo Bonzini 
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ *
+ */
+
+#ifndef QEMU_LOCKABLE_H
+#define QEMU_LOCKABLE_H
+
+#include "qemu/coroutine.h"
+#include "qemu/thread.h"
+
+typedef void QemuLockUnlockFunc(void *);
+
+struct QemuLockable {
+void *object;
+QemuLockUnlockFunc *lock;
+QemuLockUnlockFunc *unlock;
+};
+
+/* This function gives link-time errors if an invalid, non-NULL
+ * pointer type is passed to QEMU_MAKE_LOCKABLE.
+ */
+void unknown_lock_type(void *);
+
+/* Auxiliary macros to simplify QEMU_MAKE_LOCKABLE.  */
+#define QEMU_LOCK_FUNC(x) ((QemuLockUnlockFunc *)\
+QEMU_GENERIC(x,

Re: [Qemu-devel] [PULL v1 0/8] Xilinx queue

2018-01-16 Thread Edgar E. Iglesias
On Tue, Jan 16, 2018 at 02:17:04PM +, Peter Maydell wrote:
> On 16 January 2018 at 11:50, Edgar E. Iglesias  
> wrote:
> > From: "Edgar E. Iglesias" 
> >
> > The following changes since commit f5213bd060b460c99e605472b7e03967db43:
> >
> >   Merge remote-tracking branch 
> > 'remotes/juanquintela/tags/migration/20180115' into staging (2018-01-15 
> > 13:17:47 +)
> >
> > are available in the git repository at:
> >
> >   g...@github.com:edgarigl/qemu.git 
> > tags/edgar/xilinx-next-2018-01.for-upstream
> >
> > for you to fetch changes up to e451272ac191cd3ac408bc89ea63a401e84d4224:
> >
> >   xlnx-zynqmp: Connect the IPI device to the ZynqMP SoC (2018-01-16 
> > 11:44:49 +0100)
> >
> > 
> > Xilinx queue
> >
> > 
> > Alistair Francis (8):
> >   xlnx-zynqmp-pmu: Initial commit of the ZynqMP PMU
> >   xlnx-zynqmp-pmu: Add the CPU and memory
> >   aarch64-softmmu.mak: Use an ARM specific config
> >   xlnx-pmu-iomod-intc: Add the PMU Interrupt controller
> >   xlnx-zynqmp-pmu: Connect the PMU interrupt controller
> >   xlnx-zynqmp-ipi: Initial version of the Xilinx IPI device
> >   xlnx-zynqmp-pmu: Connect the IPI device to the PMU
> >   xlnx-zynqmp: Connect the IPI device to the ZynqMP SoC
> >
> 
> Hi -- this trips some new runtime sanitizer warnings:


Hi Peter,

This didn't show up on my clang testing, do you mind sharing configure line and 
clang version you use?

@Alistair, it does seem like the call to microblaze_load_kernel is passing 
wrong arguments.
Can you have a look?

Cheers,
Edgar



> 
>   GTESTER check-qtest-microblaze
> /home/petmay01/linaro/qemu-for-merges/vl.c:2279:16: runtime error:
> null pointer passed as argument 1, which is declared to never be null
> /usr/include/unistd.h:290:60: note: nonnull attribute specified here
> /home/petmay01/linaro/qemu-for-merges/vl.c:2279:16: runtime error:
> null pointer passed as argument 1, which is declared to never be null
> /usr/include/unistd.h:290:60: note: nonnull attribute specified here
> make: Leaving directory '/home/petmay01/linaro/qemu-for-merges/build/clang'
> make: Entering directory '/home/petmay01/linaro/qemu-for-merges/build/clang'
>   GTESTER check-qtest-microblazeel
> /home/petmay01/linaro/qemu-for-merges/vl.c:2279:16: runtime error:
> null pointer passed as argument 1, which is declared to never be null
> /usr/include/unistd.h:290:60: note: nonnull attribute specified here
> /home/petmay01/linaro/qemu-for-merges/vl.c:2279:16: runtime error:
> null pointer passed as argument 1, which is declared to never be null
> /usr/include/unistd.h:290:60: note: nonnull attribute specified here
> 
> This is because you've called qemu_find_file() with a NULL pointer
> (which it then passes to access(), which it isn't valid to call with
> a NULL pathname argument). Backtrace:
> 
> #0  0x55e446c1 in qemu_find_file (type=0, name=0x0)
> at /home/petmay01/linaro/qemu-for-merges/vl.c:2279
> #1  0x55dfd693 in microblaze_load_kernel (cpu=0x5824da28,
> ddr_base=, ramsize=0, initrd_filename=,
> dtb_filename=0x0, machine_cpu_reset=0x0)
> at /home/petmay01/linaro/qemu-for-merges/hw/microblaze/boot.c:128
> #2  0x55dfd519 in xlnx_zynqmp_pmu_init (machine=)
> at 
> /home/petmay01/linaro/qemu-for-merges/hw/microblaze/xlnx-zynqmp-pmu.c:190
> #3  0x55f2fd5d in machine_run_board_init (machine=)
> at /home/petmay01/linaro/qemu-for-merges/hw/core/machine.c:792
> #4  0x55e4a357 in main (argc=, argv= out>, envp=)
> at /home/petmay01/linaro/qemu-for-merges/vl.c:4622
> 
> thanks
> -- PMM



Re: [Qemu-devel] [PATCH v4 11/14] ARM: Add basic code to emulate A7MPCore DAP block

2018-01-16 Thread Peter Maydell
On 16 January 2018 at 04:32, Philippe Mathieu-Daudé  wrote:
> You can just use add this in fsl_imx7_realize():
>
>   create_unimplemented_device("a7mpcore-dap-container",
>   FSL_IMX7_A7MPCORE_DAP_ADDR,
>   0x10);
>
> to register a background region for the DAP (see "hw/misc/unimp.h")
>
> as a bonus, running with "-d unimp" you can trace the DAP access.
>
> So this model and those files are not necessary.

Yes, I think this is the best approach.

thanks
-- PMM



[Qemu-devel] [PATCH 3/4] coroutine-lock: make qemu_co_enter_next thread-safe

2018-01-16 Thread Paolo Bonzini
qemu_co_queue_next does not need to release and re-acquire the mutex,
because the queued coroutine does not run immediately.  However, this
does not hold for qemu_co_enter_next.  Now that qemu_co_queue_wait
can synchronize (via QemuLockable) with code that is not running in
coroutine context, it's important that code using qemu_co_enter_next
can easily use a standardized locking idiom.

First of all, qemu_co_enter_next must use aio_co_wake to restart the
coroutine.  Second, the function gains a second argument, a QemuLockable*,
and the comments of qemu_co_queue_next and qemu_co_queue_restart_all
are adjusted to clarify the difference.

Signed-off-by: Paolo Bonzini 
---
 fsdev/qemu-fsdev-throttle.c |  4 ++--
 include/qemu/coroutine.h| 15 ++-
 util/qemu-coroutine-lock.c  | 10 --
 3 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/fsdev/qemu-fsdev-throttle.c b/fsdev/qemu-fsdev-throttle.c
index 49eebb5412..1dc07fbc12 100644
--- a/fsdev/qemu-fsdev-throttle.c
+++ b/fsdev/qemu-fsdev-throttle.c
@@ -20,13 +20,13 @@
 static void fsdev_throttle_read_timer_cb(void *opaque)
 {
 FsThrottle *fst = opaque;
-qemu_co_enter_next(&fst->throttled_reqs[false]);
+qemu_co_enter_next(&fst->throttled_reqs[false], NULL);
 }
 
 static void fsdev_throttle_write_timer_cb(void *opaque)
 {
 FsThrottle *fst = opaque;
-qemu_co_enter_next(&fst->throttled_reqs[true]);
+qemu_co_enter_next(&fst->throttled_reqs[true], NULL);
 }
 
 void fsdev_throttle_parse_opts(QemuOpts *opts, FsThrottle *fst, Error **errp)
diff --git a/include/qemu/coroutine.h b/include/qemu/coroutine.h
index 1e5f0957e6..6fdbc837c0 100644
--- a/include/qemu/coroutine.h
+++ b/include/qemu/coroutine.h
@@ -188,21 +188,26 @@ void qemu_co_queue_init(CoQueue *queue);
 void coroutine_fn qemu_co_queue_wait_impl(CoQueue *queue, QemuLockable *lock);
 
 /**
- * Restarts the next coroutine in the CoQueue and removes it from the queue.
+ * Removes the next coroutine from the CoQueue; it will run as soon as the
+ * current one yields.
  *
- * Returns true if a coroutine was restarted, false if the queue is empty.
+ * Returns true if a coroutine was removed, false if the queue is empty.
  */
 bool coroutine_fn qemu_co_queue_next(CoQueue *queue);
 
 /**
- * Restarts all coroutines in the CoQueue and leaves the queue empty.
+ * Empties the CoQueue; all coroutines in it will run in FIFO orer as soon
+ * as the current one yields.
  */
 void coroutine_fn qemu_co_queue_restart_all(CoQueue *queue);
 
 /**
- * Enter the next coroutine in the queue
+ * Immediately enter the next coroutine in the queue.  Release the mutex
+ * while it runs.
  */
-bool qemu_co_enter_next(CoQueue *queue);
+#define qemu_co_enter_next(queue, lock) \
+qemu_co_enter_next_impl(queue, QEMU_MAKE_LOCKABLE(lock))
+bool qemu_co_enter_next_impl(CoQueue *queue, QemuLockable *lock);
 
 /**
  * Checks if the CoQueue is empty.
diff --git a/util/qemu-coroutine-lock.c b/util/qemu-coroutine-lock.c
index 2a66fc1467..78fb79acf8 100644
--- a/util/qemu-coroutine-lock.c
+++ b/util/qemu-coroutine-lock.c
@@ -132,7 +132,7 @@ void coroutine_fn qemu_co_queue_restart_all(CoQueue *queue)
 qemu_co_queue_do_restart(queue, false);
 }
 
-bool qemu_co_enter_next(CoQueue *queue)
+bool qemu_co_enter_next_impl(CoQueue *queue, QemuLockable *lock)
 {
 Coroutine *next;
 
@@ -142,7 +142,13 @@ bool qemu_co_enter_next(CoQueue *queue)
 }
 
 QSIMPLEQ_REMOVE_HEAD(&queue->entries, co_queue_next);
-qemu_coroutine_enter(next);
+if (lock) {
+qemu_lockable_unlock(lock);
+}
+aio_co_wake(next);
+if (lock) {
+qemu_lockable_lock(lock);
+}
 return true;
 }
 
-- 
2.14.3





Re: [Qemu-devel] [PATCH 3/7] i386: Add spec-ctrl CPUID bit

2018-01-16 Thread Gonglei (Arei)

> -Original Message-
> From: Eduardo Habkost [mailto:ehabk...@redhat.com]
> Sent: Monday, January 15, 2018 8:23 PM
> To: Gonglei (Arei)
> Cc: qemu-devel@nongnu.org; Paolo Bonzini
> Subject: Re: [Qemu-devel] [PATCH 3/7] i386: Add spec-ctrl CPUID bit
> 
> On Sat, Jan 13, 2018 at 03:04:44AM +, Gonglei (Arei) wrote:
> >
> > > -Original Message-
> > > From: Qemu-devel
> > > [mailto:qemu-devel-bounces+arei.gonglei=huawei@nongnu.org] On
> > > Behalf Of Eduardo Habkost
> > > Sent: Tuesday, January 09, 2018 11:45 PM
> > > To: qemu-devel@nongnu.org
> > > Cc: Paolo Bonzini
> > > Subject: [Qemu-devel] [PATCH 3/7] i386: Add spec-ctrl CPUID bit
> > >
> > > Add the feature name and a CPUID_7_0_EDX_SPEC_CTRL macro.
> > >
> > > Signed-off-by: Eduardo Habkost 
> > > ---
> > >  target/i386/cpu.h | 1 +
> > >  target/i386/cpu.c | 2 +-
> > >  2 files changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> > > index 07f47997d6..de387c1311 100644
> > > --- a/target/i386/cpu.h
> > > +++ b/target/i386/cpu.h
> > > @@ -667,6 +667,7 @@ typedef uint32_t
> > > FeatureWordArray[FEATURE_WORDS];
> > >
> > >  #define CPUID_7_0_EDX_AVX512_4VNNIW (1U << 2) /* AVX512 Neural
> > > Network Instructions */
> > >  #define CPUID_7_0_EDX_AVX512_4FMAPS (1U << 3) /* AVX512 Multiply
> > > Accumulation Single Precision */
> > > +#define CPUID_7_0_EDX_SPEC_CTRL (1U << 26) /* Speculation
> Control
> > > */
> > >
> > >  #define CPUID_XSAVE_XSAVEOPT   (1U << 0)
> > >  #define CPUID_XSAVE_XSAVEC (1U << 1)
> > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > > index 9f4f949899..1be1642eb2 100644
> > > --- a/target/i386/cpu.c
> > > +++ b/target/i386/cpu.c
> > > @@ -459,7 +459,7 @@ static FeatureWordInfo
> > > feature_word_info[FEATURE_WORDS] = {
> > >  NULL, NULL, NULL, NULL,
> > >  NULL, NULL, NULL, NULL,
> > >  NULL, NULL, NULL, NULL,
> > > -NULL, NULL, NULL, NULL,
> > > +NULL, NULL, "spec-ctrl", NULL,
> > >  NULL, NULL, NULL, NULL,
> > >  },
> > >  .cpuid_eax = 7,
> > > --
> > > 2.14.3
> > >
> > Don't we need to pass-through cupid_7_edx to guest when configuring '-cpu
> host'?
> > Otherwise how guests use IBPB/IBRS/STIPB capabilities?
> 
> We already do.  See the check for cpu->max_features at
> x86_cpu_expand_features().
> 
> Do you see something else missing?
> 
No, thank you. My bad. :(

Thanks,
-Gonglei




Re: [Qemu-devel] [PATCH v5 10/14] configure: allow use of python 3

2018-01-16 Thread Eric Blake
On 01/16/2018 07:42 AM, Daniel P. Berrange wrote:
> Signed-off-by: Daniel P. Berrange 
> ---
>  configure | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 

Reviewed-by: Eric Blake 

Presumably, you tested with this patch first in the series to come up
with patches 1-9 ;)

> diff --git a/configure b/configure
> index b272a0336b..60b99f45f6 100755
> --- a/configure
> +++ b/configure
> @@ -1598,9 +1598,8 @@ fi
>  
>  # Note that if the Python conditional here evaluates True we will exit
>  # with status 1 which is a shell 'false' value.
> -if ! $python -c 'import sys; sys.exit(sys.version_info < (2,6) or 
> sys.version_info >= (3,))'; then
> -  error_exit "Cannot use '$python', Python 2.6 or later is required." \
> -  "Note that Python 3 or later is not yet supported." \
> +if ! $python -c 'import sys; sys.exit(sys.version_info < (2,6))'; then
> +  error_exit "Cannot use '$python', Python 2 >= 2.6 or Python 3 is 
> required." \
>"Use --python=/path/to/python to specify a supported Python."
>  fi
>  
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PULL v1 0/8] Xilinx queue

2018-01-16 Thread Peter Maydell
On 16 January 2018 at 14:49, Edgar E. Iglesias
 wrote:
> This didn't show up on my clang testing, do you mind sharing configure line 
> and clang version you use?
>
> @Alistair, it does seem like the call to microblaze_load_kernel is passing 
> wrong arguments.
> Can you have a look?

exec '../../configure' '--cc=clang' '--cxx=clang++' '--enable-gtk'
'--extra-cflags=-fsanitize=undefined  -fno-sanitize=shift-base
-Werror' "$@"

with clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
on ubuntu xenial.

thanks
-- PMM



Re: [Qemu-devel] [PULL v3 00/53] Misc changes for 2017-01-12

2018-01-16 Thread Paolo Bonzini
On 16/01/2018 15:22, Marc-André Lureau wrote:
> Hi
> 
> On Tue, Jan 16, 2018 at 2:54 PM, Paolo Bonzini  wrote:
>> On 16/01/2018 14:47, Peter Maydell wrote:
>>> On 16 January 2018 at 13:41, Paolo Bonzini  wrote:
 On 16/01/2018 13:06, Peter Maydell wrote:
>> ASAN is enabled by default if available when --enable-debug. We could
>> add more flags if that helps.
> Configure switches should work like this:
>  * default: use feature if present, but don't complain if not present
>or not usable
>  * --enable-foo: use feature. if feature not present, complain and
>fail configure
>  * --disable-foo: don't test for or use feature
>

 However, --enable-debug has never worked like this (the "default" part)...
>>>
>>> True, but -g, no optimization isn't really something we want to
>>> default to :-)
>>
>> Same for ASAN. :-)
>>
>>> I think the general principle that unless the user
>>> specifically said they cared about the address sanitizer we shouldn't
>>> complain if it happens not to work on this host is still a good one.
>>
>> Yes, I agree.
>>
>> So we need two options:
>>
>> * --enable-asan defaults to not used, but also fails configure if ASAN
>> is not available/usable.
> 
> and --enable-ubsan etc ...
> 
> I wish we would avoid the multiplication of configure options, and use
> good default values instead for --enable-debug. But if it's not
> possible, let's add more options. However, it would be great if ASAN
> can be enabled by default, it seems too few developers care, even
> though it should be strongly recommended.

We can add --enable-sanitizer then instead of being specific to ASAN.
It could also support --enable-sanitizer=asan,ubsan but that's for later.

>>
>> * if we want to have --enable-debug enable ASAN, it should however _not_
>> fail configure if ASAN is not available/usable.  (I am not sure anymore
>> it's a good idea).
>>
>> The questions are:
>>
>> * should fiber support be required for --enable-asan?  What is the
>> difference in the quality of the reports?
> 
> It's not required, but helps to detect more leaks. It also removes
> some warnings in some cases:

Ok, if it's not a flood of warnings it's okay.

> 
>> * if not, and assuming --enable-debug tries to enable ASAN, should
>> --enable-debug complain if fiber support is not required?  Should
>> --enable-debug enable ASAN if fiber support is not available?
> 
> I propose to simply print a warning during configure

Yes, it could do the same as --enable-asan.

>> * if --enable-debug does *not* try to enable ASAN, should test-debug add
>> --enable-asn?  (I think so).
> 
> The other way around?

I mean - IMO, test-debug should enable sanitizers even if
--enable-sanitizer and --enable-debug are completely separate.

Paolo



Re: [Qemu-devel] [PATCH v5 12/14] ui: update keycodemapdb to get py3 fixes

2018-01-16 Thread Eric Blake
On 01/16/2018 07:42 AM, Daniel P. Berrange wrote:
> Signed-off-by: Daniel P. Berrange 
> ---
>  ui/keycodemapdb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

When posting submodule diffs, you can do:

$ git submodule summary ui/keycodemapdb HEAD^

to come up with what the change actually represents. (It's annoying that
git submodules aren't more user-friendly)

> diff --git a/ui/keycodemapdb b/ui/keycodemapdb
> index 05dad417e9..6b3d716e2b 16
> --- a/ui/keycodemapdb
> +++ b/ui/keycodemapdb
> @@ -1 +1 @@
> -Subproject commit 05dad417e9d0b37ee1fba33056d91a6b734b3357
> +Subproject commit 6b3d716e2b6472eb7189d3220552280ef3d832ce
> 

* ui/keycodemapdb 05dad41...6b3d716 (1):
  > Fix compat with py3 dict keys/values data types

Reviewed-by: Eric Blake 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH v5 11/14] input: add missing JIS keys to virtio input

2018-01-16 Thread Eric Blake
On 01/16/2018 07:42 AM, Daniel P. Berrange wrote:
> From: Miika S 
> 
> keycodemapdb updated to add the QKeyCodes muhenkan and katakanahiragana
> 
> Signed-off-by: Miika S 

Not a typical legal name (since a Signed-off-by is a legal statement for
tracing copyright restrictions, using an actual name instead of a
pseudonym is preferable; however, we have examples of commits in the
past that did not do so, so I'm not going to insist on this one).

> ---
>  hw/input/virtio-input-hid.c | 7 +++
>  qapi/ui.json| 5 -
>  ui/keycodemapdb | 2 +-
>  3 files changed, 12 insertions(+), 2 deletions(-)
> 

Reviewed-by: Eric Blake 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH 2/4] vhost-user: specify and implement VHOST_USER_SET_QUEUE_NUM request

2018-01-16 Thread Maxime Coquelin



On 01/16/2018 04:05 AM, Michael S. Tsirkin wrote:

On Fri, Jan 12, 2018 at 03:56:56PM +0100, Maxime Coquelin wrote:

When the slave cannot add queues dynamically,



Could you please clarify the motivation a bit
Why is it such a big deal to resize the queue array?
We know no queues are used before all of them are initialized,
so you don't need to worry about synchronizing with threads
processing the queues at the same time.


The problem is to know how many queues to wait for being initialized.
We need this information in DPDK to start the "vhost device".

Before the guest driver is initialized, the slave receives from QEMU
VHOST_USER_SET_VRING_CALL and VHOST_USER_SET_VRING_ENABLE for all queues
declared in QEMU. In DPDK, queues metadata is allocated each time a
message targets a new vring index, and vring count is incremented
accordingly.

Currently, it seems to work, because QEMU calls vhost_virtqueue_start()
for all queues, even ones not configured by the guest.

But with patch "[PATCH] vhost: fix corrupting GPA 0 when using
uninitialized queues" from Zheng Xiang, QEMU will not more send
_SET_VRING_ADDR and _SET_VRING_KICK for un-configured queues, but
the backend will wait forever for these messages to start the device.

I pasted below a log of messages received by the slave, so you can make
an idea of the sequence.


it needs to know for
how many queues to wait to be initialized.

This patch introduce new vhost-user protocol feature & request for
the master to send the number of queue pairs allocated by the
driver.


Assuming we can fix the previous message, I think specifying
the # of queues would be better.


Thanks,
Maxime


EAL: Detected 4 lcore(s)
EAL: No free hugepages reported in hugepages-1048576kB
EAL: Probing VFIO support...
EAL: PCI device :00:1f.6 on NUMA socket -1
EAL:   Invalid NUMA socket, default to 0
EAL:   probe driver: 8086:156f net_e1000_em
PMD: Initializing pmd_vhost for net_vhost0
PMD: Creating VHOST-USER backend on numa socket 0
VHOST_CONFIG: vhost-user server: socket created, fd: 13
VHOST_CONFIG: bind to /tmp/vhost-user2
Interactive-mode selected
testpmd: create a new mbuf pool : n=155456, 
size=2176, socket=0


Warning! Cannot handle an odd number of ports with the current port 
topology. Configuration must be changed to have an even number of ports, 
or relaunch application with --port-topology=chained


Configuring Port 0 (socket 0)
Port 0: 56:48:4F:53:54:00
Checking link statuses...
Done
testpmd> VHOST_CONFIG: new vhost user connection is 15
VHOST_CONFIG: new device, handle is 0
VHOST_CONFIG: read message VHOST_USER_GET_FEATURES
VHOST_CONFIG: read message VHOST_USER_GET_PROTOCOL_FEATURES
VHOST_CONFIG: read message VHOST_USER_SET_PROTOCOL_FEATURES
VHOST_CONFIG: read message VHOST_USER_GET_QUEUE_NUM
VHOST_CONFIG: read message VHOST_USER_SET_SLAVE_REQ_FD
VHOST_CONFIG: read message VHOST_USER_SET_OWNER
VHOST_CONFIG: read message VHOST_USER_GET_FEATURES
VHOST_CONFIG: read message VHOST_USER_SET_VRING_CALL
VHOST_CONFIG: vring call idx:0 file:17
VHOST_CONFIG: read message VHOST_USER_SET_VRING_CALL
VHOST_CONFIG: vring call idx:1 file:18
VHOST_CONFIG: read message VHOST_USER_GET_FEATURES
VHOST_CONFIG: read message VHOST_USER_GET_PROTOCOL_FEATURES
VHOST_CONFIG: read message VHOST_USER_SET_PROTOCOL_FEATURES
VHOST_CONFIG: read message VHOST_USER_SET_SLAVE_REQ_FD
VHOST_CONFIG: read message VHOST_USER_GET_FEATURES
VHOST_CONFIG: read message VHOST_USER_SET_VRING_CALL
VHOST_CONFIG: vring call idx:2 file:20
VHOST_CONFIG: read message VHOST_USER_SET_VRING_CALL
VHOST_CONFIG: vring call idx:3 file:21
VHOST_CONFIG: read message VHOST_USER_SET_VRING_ENABLE
VHOST_CONFIG: set queue enable: 1 to qp idx: 0
PMD: vring0 is enabled

Port 0: Queue state event
VHOST_CONFIG: read message VHOST_USER_SET_VRING_ENABLE
VHOST_CONFIG: set queue enable: 1 to qp idx: 1
PMD: vring1 is enabled

Port 0: Queue state event
VHOST_CONFIG: read message VHOST_USER_SET_VRING_ENABLE
VHOST_CONFIG: set queue enable: 0 to qp idx: 2
PMD: vring2 is disabled

Port 0: Queue state event
VHOST_CONFIG: read message VHOST_USER_SET_VRING_ENABLE
VHOST_CONFIG: set queue enable: 0 to qp idx: 3
PMD: vring3 is disabled

Port 0: Queue state event
VHOST_CONFIG: read message VHOST_USER_SET_VRING_ENABLE
VHOST_CONFIG: set queue enable: 1 to qp idx: 0
PMD: vring0 is enabled

Port 0: Queue state event
VHOST_CONFIG: read message VHOST_USER_SET_VRING_ENABLE
VHOST_CONFIG: set queue enable: 1 to qp idx: 1
PMD: vring1 is enabled

Port 0: Queue state event
VHOST_CONFIG: read message VHOST_USER_SET_VRING_ENABLE
VHOST_CONFIG: set queue enable: 0 to qp idx: 2
PMD: vring2 is disabled

Port 0: Queue state event
VHOST_CONFIG: read message VHOST_USER_SET_VRING_ENABLE
VHOST_CONFIG: set queue enable: 0 to qp idx: 3
PMD: vring3 is disabled

Port 0: Queue state event
VHOST_CONFIG: read message VHOST_USER_SET_FEATURES
VHOST_CONFIG: read message VHOST_USER_SET_MEM_TABLE
VHOST_CONFIG: guest memory region 0, size: 0x8000
 guest physical addr: 0x1000

Re: [Qemu-devel] [PATCH v4 08/14] i.MX: Add implementation of i.MX7 GPR IP block

2018-01-16 Thread Peter Maydell
On 16 January 2018 at 01:37, Andrey Smirnov  wrote:
> Add minimal code needed to allow upstream Linux guest to boot.
>
> Cc: Peter Maydell 
> Cc: Jason Wang 
> Cc: Philippe Mathieu-Daudé 
> Cc: qemu-devel@nongnu.org
> Cc: qemu-...@nongnu.org
> Cc: yurov...@gmail.com
> Signed-off-by: Andrey Smirnov 
> ---

Reviewed-by: Peter Maydell 

thanks
-- PMM



Re: [Qemu-devel] [PATCH v4 11/14] ARM: Add basic code to emulate A7MPCore DAP block

2018-01-16 Thread Andrey Smirnov
On Mon, Jan 15, 2018 at 8:32 PM, Philippe Mathieu-Daudé  wrote:
> Hi Andrey,
>
> On 01/15/2018 10:37 PM, Andrey Smirnov wrote:
>> Add minimal code to emulate A7MPCore DAP block needed to boot Linux
>> guest.
>
> I was not aware the DAP is accessed by upstream Linux...
>
> You sure this isn't rather part of some bootloader built-in self-test?
>

Yes, I am positive:

a) I don't run any bootloader and boot directly into Linux, so it's
just physically impossible
b) Here's the code:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/hwtracing/coresight?h=v4.15-rc8


>> Cc: Peter Maydell 
>> Cc: Jason Wang 
>> Cc: Philippe Mathieu-Daudé 
>> Cc: qemu-devel@nongnu.org
>> Cc: qemu-...@nongnu.org
>> Cc: yurov...@gmail.com
>> Signed-off-by: Andrey Smirnov 
>> ---
>>  hw/arm/Makefile.objs   |   2 +-
>>  hw/arm/coresight.c | 120 
>> +
>>  include/hw/arm/coresight.h |  24 +
>>  3 files changed, 145 insertions(+), 1 deletion(-)
>>  create mode 100644 hw/arm/coresight.c
>>  create mode 100644 include/hw/arm/coresight.h
>>
>> diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
>> index 2794e086d6..692216e0cf 100644
>> --- a/hw/arm/Makefile.objs
>> +++ b/hw/arm/Makefile.objs
>> @@ -1,4 +1,4 @@
>> -obj-y += boot.o collie.o exynos4_boards.o gumstix.o highbank.o
>> +obj-y += boot.o collie.o exynos4_boards.o gumstix.o highbank.o coresight.o
>>  obj-$(CONFIG_DIGIC) += digic_boards.o
>>  obj-y += integratorcp.o mainstone.o musicpal.o nseries.o
>>  obj-y += omap_sx1.o palm.o realview.o spitz.o stellaris.o
>> diff --git a/hw/arm/coresight.c b/hw/arm/coresight.c
>> new file mode 100644
>> index 00..d0a8c1b005
>> --- /dev/null
>> +++ b/hw/arm/coresight.c
>> @@ -0,0 +1,120 @@
>> +/*
>> + * Copyright (c) 2017, Impinj, Inc.
>> + *
>> + * CoreSight block emulation code
>> + *
>> + * Author: Andrey Smirnov 
>> + *
>> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
>> + * See the COPYING file in the top-level directory.
>> + */
>> +
>> +#include "qemu/osdep.h"
>> +#include "hw/arm/coresight.h"
>> +#include "qemu/log.h"
>> +
>> +static uint64_t coresight_read(void *opaque, hwaddr offset,
>> +   unsigned size)
>> +{
>> +return 0;
>> +}
>> +
>> +static void coresight_write(void *opaque, hwaddr offset,
>> +uint64_t value, unsigned size)
>> +{
>> +}
>
> I assume you had to add this to bypass the memory_transaction_failures
> check.
>
>> +
>> +static const struct MemoryRegionOps coresight_ops = {
>> +.read = coresight_read,
>> +.write = coresight_write,
>> +.endianness = DEVICE_NATIVE_ENDIAN,
>> +.impl = {
>> +/*
>> + * Our device would not work correctly if the guest was doing
>> + * unaligned access. This might not be a limitation on the real
>> + * device but in practice there is no reason for a guest to access
>> + * this device unaligned.
>> + */
>> +.min_access_size = 4,
>> +.max_access_size = 4,
>> +.unaligned = false,
>> +},
>> +};
>> +
>> +static void a7mpcore_dap_init(Object *obj)
>> +{
>> +SysBusDevice *sd = SYS_BUS_DEVICE(obj);
>> +A7MPCoreDAPState *s = A7MPCORE_DAP(obj);
>> +
>> +memory_region_init(&s->container, obj, "a7mpcore-dap-container", 
>> 0x10);
>
> You can just use add this in fsl_imx7_realize():
>
>   create_unimplemented_device("a7mpcore-dap-container",
>   FSL_IMX7_A7MPCORE_DAP_ADDR,
>   0x10);
>
> to register a background region for the DAP (see "hw/misc/unimp.h")
>
> as a bonus, running with "-d unimp" you can trace the DAP access.
>
> So this model and those files are not necessary.
>

I am aware of create_unimplemented_device(), my reasoning for keeping
this code as a standalone class was to make it reusable for other
systems while providing more granular mapping (not just covering the
whole 0x10 bytes of memory). I'll convert the code to use
create_unimplemented_device() since we now have two votes in favor of
it.

Thanks,
Andrey Smirnov



Re: [Qemu-devel] [PATCH v4 09/14] pci: Add support for Designware IP block

2018-01-16 Thread Peter Maydell
On 16 January 2018 at 01:37, Andrey Smirnov  wrote:
> Add code needed to get a functional PCI subsytem when using in
> conjunction with upstream Linux guest (4.13+). Tested to work against
> "e1000e" (network adapter, using MSI interrupts) as well as
> "usb-ehci" (USB controller, using legacy PCI interrupts).
>
> Cc: Peter Maydell 
> Cc: Jason Wang 
> Cc: Philippe Mathieu-Daudé 
> Cc: qemu-devel@nongnu.org
> Cc: qemu-...@nongnu.org
> Cc: yurov...@gmail.com
> Signed-off-by: Andrey Smirnov 
> ---
>  default-configs/arm-softmmu.mak  |   2 +
>  hw/pci-host/Makefile.objs|   2 +
>  hw/pci-host/designware.c | 618 
> +++
>  include/hw/pci-host/designware.h |  93 ++
>  include/hw/pci/pci_ids.h |   2 +
>  5 files changed, 717 insertions(+)
>  create mode 100644 hw/pci-host/designware.c
>  create mode 100644 include/hw/pci-host/designware.h

I'm not familiar enough with our PCI code to be able to review
this, I'm afraid. MST and Marcel are our PCI subsystem maintainers --
could one of you have a look at whether this seems to be a correct
implementation of a pcie host controller ?

I did notice it seems to be missing device state save/load support.

thanks
-- PMM



[Qemu-devel] [PATCH v2] tests: acpi: fix FADT not being compared to reference table

2018-01-16 Thread Igor Mammedov
It turns out that FADT isn't actually tested for changes
against reference table, since it happens to be the 1st
table in RSDT which is currently ignored.
Fix it by making sure that all tables from RSDT are added
to test list.

NOTE: FADT contains guest allocated pointers to FACS/DSDT,
zero them out so that possible FACS/DSDT address change
won't affect test results.

Signed-off-by: Igor Mammedov 
---
v2:
  - fixup FACS/DSDT pointers in FADT to avoid false test
failure if pointers change ("Michael S. Tsirkin" )
---
 tests/bios-tables-test.c | 35 +--
 1 file changed, 33 insertions(+), 2 deletions(-)

diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
index 81c558e..3a66f66 100644
--- a/tests/bios-tables-test.c
+++ b/tests/bios-tables-test.c
@@ -194,6 +194,35 @@ static void test_acpi_fadt_table(test_data *data)
  le32_to_cpu(fadt_table->length)));
 }
 
+static void sanitize_fadt_ptrs(test_data *data)
+{
+/* fixup pointers in FADT */
+int i;
+
+for (i = 0; i < data->tables->len; i++) {
+AcpiSdtTable *sdt = &g_array_index(data->tables, AcpiSdtTable, i);
+
+if (memcmp(&sdt->header.signature, "FACP", 4)) {
+continue;
+}
+
+/* sdt->aml field offset := spec offset - header size */
+memset(sdt->aml + 0, 0, 4); /* sanitize FIRMWARE_CTRL(36) ptr */
+memset(sdt->aml + 4, 0, 4); /* sanitize DSDT(40) ptr */
+if (sdt->header.revision >= 3) {
+memset(sdt->aml + 96, 0, 8); /* sanitize X_FIRMWARE_CTRL(132) ptr 
*/
+memset(sdt->aml + 104, 0, 8); /* sanitize X_DSDT(140) ptr */
+}
+
+/* update checksum */
+sdt->header.checksum = 0;
+sdt->header.checksum -=
+acpi_calc_checksum((uint8_t *)sdt, sizeof(AcpiTableHeader)) +
+acpi_calc_checksum((uint8_t *)sdt->aml, sdt->aml_len);
+break;
+}
+}
+
 static void test_acpi_facs_table(test_data *data)
 {
 AcpiFacsDescriptorRev1 *facs_table = &data->facs_table;
@@ -248,14 +277,14 @@ static void test_acpi_dsdt_table(test_data *data)
 /* Load all tables and add to test list directly RSDT referenced tables */
 static void fetch_rsdt_referenced_tables(test_data *data)
 {
-int tables_nr = data->rsdt_tables_nr - 1; /* fadt is first */
+int tables_nr = data->rsdt_tables_nr;
 int i;
 
 for (i = 0; i < tables_nr; i++) {
 AcpiSdtTable ssdt_table;
 uint32_t addr;
 
-addr = le32_to_cpu(data->rsdt_tables_addr[i + 1]); /* fadt is first */
+addr = le32_to_cpu(data->rsdt_tables_addr[i]);
 fetch_table(&ssdt_table, addr);
 
 /* Add table to ASL test tables list */
@@ -650,6 +679,8 @@ static void test_acpi_one(const char *params, test_data 
*data)
 test_acpi_dsdt_table(data);
 fetch_rsdt_referenced_tables(data);
 
+sanitize_fadt_ptrs(data);
+
 if (iasl) {
 if (getenv(ACPI_REBUILD_EXPECTED_AML)) {
 dump_aml_files(data, true);
-- 
2.7.4




Re: [Qemu-devel] [PATCH v4 08/14] i.MX: Add implementation of i.MX7 GPR IP block

2018-01-16 Thread Andrey Smirnov
On Mon, Jan 15, 2018 at 8:45 PM, Philippe Mathieu-Daudé  wrote:
> On 01/15/2018 10:37 PM, Andrey Smirnov wrote:
>> Add minimal code needed to allow upstream Linux guest to boot.
>>
>> Cc: Peter Maydell 
>> Cc: Jason Wang 
>> Cc: Philippe Mathieu-Daudé 
>> Cc: qemu-devel@nongnu.org
>> Cc: qemu-...@nongnu.org
>> Cc: yurov...@gmail.com
>> Signed-off-by: Andrey Smirnov 
>> ---
>>  hw/misc/Makefile.objs  |   1 +
>>  hw/misc/imx7_gpr.c | 119 
>> +
>>  include/hw/misc/imx7_gpr.h |  28 +++
>>  3 files changed, 148 insertions(+)
>>  create mode 100644 hw/misc/imx7_gpr.c
>>  create mode 100644 include/hw/misc/imx7_gpr.h
>>
>> diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
>> index 019886912c..fce426eb75 100644
>> --- a/hw/misc/Makefile.objs
>> +++ b/hw/misc/Makefile.objs
>> @@ -36,6 +36,7 @@ obj-$(CONFIG_IMX) += imx6_src.o
>>  obj-$(CONFIG_IMX) += imx7_ccm.o
>>  obj-$(CONFIG_IMX) += imx2_wdt.o
>>  obj-$(CONFIG_IMX) += imx7_snvs.o
>> +obj-$(CONFIG_IMX) += imx7_gpr.o
>>  obj-$(CONFIG_MILKYMIST) += milkymist-hpdmc.o
>>  obj-$(CONFIG_MILKYMIST) += milkymist-pfpu.o
>>  obj-$(CONFIG_MAINSTONE) += mst_fpga.o
>> diff --git a/hw/misc/imx7_gpr.c b/hw/misc/imx7_gpr.c
>> new file mode 100644
>> index 00..9e8ccea9e8
>> --- /dev/null
>> +++ b/hw/misc/imx7_gpr.c
>> @@ -0,0 +1,119 @@
>> +/*
>> + * Copyright (c) 2017, Impinj, Inc.
>> + *
>> + * i.MX7 GPR IP block emulation code
>> + *
>> + * Author: Andrey Smirnov 
>> + *
>> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
>> + * See the COPYING file in the top-level directory.
>> + *
>> + * Bare minimum emulation code needed to support being able to shut
>> + * down linux guest gracefully.
>> + */
>> +
>> +#include "qemu/osdep.h"
>> +#include "hw/misc/imx7_gpr.h"
>> +#include "qemu/log.h"
>> +#include "sysemu/sysemu.h"
>> +
>> +enum IMX7GPRRegisters {
>> +IOMUXC_GPR0  = 0x00,
>> +IOMUXC_GPR1  = 0x04,
>> +IOMUXC_GPR2  = 0x08,
>> +IOMUXC_GPR3  = 0x0c,
>> +IOMUXC_GPR4  = 0x10,
>> +IOMUXC_GPR5  = 0x14,
>> +IOMUXC_GPR6  = 0x18,
>> +IOMUXC_GPR7  = 0x1c,
>> +IOMUXC_GPR8  = 0x20,
>> +IOMUXC_GPR9  = 0x24,
>> +IOMUXC_GPR10 = 0x28,
>> +IOMUXC_GPR11 = 0x2c,
>> +IOMUXC_GPR12 = 0x30,
>> +IOMUXC_GPR13 = 0x34,
>> +IOMUXC_GPR14 = 0x38,
>> +IOMUXC_GPR15 = 0x3c,
>> +IOMUXC_GPR16 = 0x40,
>> +IOMUXC_GPR17 = 0x44,
>> +IOMUXC_GPR18 = 0x48,
>> +IOMUXC_GPR19 = 0x4c,
>> +IOMUXC_GPR20 = 0x50,
>> +IOMUXC_GPR21 = 0x54,
>> +IOMUXC_GPR22 = 0x58,
>> +};
>> +
>> +#define IMX7D_GPR1_IRQ_MASK BIT(12)
>> +#define IMX7D_GPR1_ENET1_TX_CLK_SEL_MASKBIT(13)
>> +#define IMX7D_GPR1_ENET2_TX_CLK_SEL_MASKBIT(14)
>> +#define IMX7D_GPR1_ENET_TX_CLK_SEL_MASK (0x3 << 13)
>> +#define IMX7D_GPR1_ENET1_CLK_DIR_MASK   BIT(17)
>> +#define IMX7D_GPR1_ENET2_CLK_DIR_MASK   BIT(18)
>> +#define IMX7D_GPR1_ENET_CLK_DIR_MASK(0x3 << 17)
>> +
>> +#define IMX7D_GPR5_CSI_MUX_CONTROL_MIPI BIT(4)
>> +#define IMX7D_GPR12_PCIE_PHY_REFCLK_SEL BIT(5)
>> +#define IMX7D_GPR22_PCIE_PHY_PLL_LOCKED BIT(31)
>> +
>> +
>> +static uint64_t imx7_gpr_read(void *opaque, hwaddr offset, unsigned size)
>> +{
>> +if (offset == IOMUXC_GPR22) {
>> +return IMX7D_GPR22_PCIE_PHY_PLL_LOCKED;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static void imx7_gpr_write(void *opaque, hwaddr offset,
>> +   uint64_t v, unsigned size)
>> +{
>
> If you ever respin, please add a trace point here (just copy/paste from
> another file from the same directory), and in the read() function.
>
> Linux will evolve and use more registers from this device (and the other
> devices you are modelling), and a Linux driver busy loop is likely to
> hang QEMU. A trace event will ease your board next user soon :)
>

Sure, will do.

Thanks,
Andrey Smirnov



Re: [Qemu-devel] [PATCH] memory: update comments and fix some typos

2018-01-16 Thread Paolo Bonzini
On 16/01/2018 09:32, Zhoujian (jay) wrote:
> Hi Paolo,
> Maybe it is a little boring to review updated comments, but I think it is the
> right thing to do, so could you have a look when you're free?

On the contrary, it's useful!  I just missed it among the email after
new year's break.

I queued it now.

Paolo

> Regards,
> Jay
> 
>> -Original Message-
>> From: Zhoujian (jay)
>> Sent: Thursday, January 04, 2018 1:30 PM
>> To: qemu-devel@nongnu.org
>> Cc: pbonz...@redhat.com; Huangweidong (C) ; wangxin
>> (U) ; Zhoujian (jay) 
>> Subject: [PATCH] memory: update comments and fix some typos
>>
>> Signed-off-by: Jay Zhou 
>> ---
>>  include/exec/memory.h | 27 +++
>>  1 file changed, 15 insertions(+), 12 deletions(-)
>>
>> diff --git a/include/exec/memory.h b/include/exec/memory.h index
>> a4cabdf..6e5684d 100644
>> --- a/include/exec/memory.h
>> +++ b/include/exec/memory.h
>> @@ -324,7 +324,7 @@ FlatView *address_space_to_flatview(AddressSpace *as);
>>   * MemoryRegionSection: describes a fragment of a #MemoryRegion
>>   *
>>   * @mr: the region, or %NULL if empty
>> - * @address_space: the address space the region is mapped in
>> + * @fv: the flat view of the address space the region is mapped in
>>   * @offset_within_region: the beginning of the section, relative to @mr's
>> start
>>   * @size: the size of the section; will not exceed @mr's boundaries
>>   * @offset_within_address_space: the address of the first byte of the
>> section @@ -607,6 +607,7 @@ void
>> memory_region_init_rom_nomigrate(MemoryRegion *mr,
>>   * @mr: the #MemoryRegion to be initialized.
>>   * @owner: the object that tracks the region's reference count
>>   * @ops: callbacks for write access handling (must not be NULL).
>> + * @opaque: passed to the read and write callbacks of the @ops structure.
>>   * @name: Region name, becomes part of RAMBlock name used in migration
>> stream
>>   *must be unique within any device
>>   * @size: size of the region.
>> @@ -650,11 +651,10 @@ static inline void
>> memory_region_init_reservation(MemoryRegion *mr,
>>   * An IOMMU region translates addresses and forwards accesses to a target
>>   * memory region.
>>   *
>> - * @typename: QOM class name
>>   * @_iommu_mr: the #IOMMUMemoryRegion to be initialized
>>   * @instance_size: the IOMMUMemoryRegion subclass instance size
>> + * @mrtypename: the type name of the #IOMMUMemoryRegion
>>   * @owner: the object that tracks the region's reference count
>> - * @ops: a function that translates addresses into the @target region
>>   * @name: used for debugging; not visible to the user or ABI
>>   * @size: size of the region.
>>   */
>> @@ -824,8 +824,8 @@ static inline IOMMUMemoryRegion
>> *memory_region_get_iommu(MemoryRegion *mr)
>>   * memory_region_get_iommu_class_nocheck: returns iommu memory region class
>>   *   if an iommu or NULL if not
>>   *
>> - * Returns pointer to IOMMUMemoryRegioniClass if a memory region is an 
>> iommu,
>> - * otherwise NULL. This is fast path avoinding QOM checking, use with
>> caution.
>> + * Returns pointer to IOMMUMemoryRegionClass if a memory region is an
>> + iommu,
>> + * otherwise NULL. This is fast path avoiding QOM checking, use with 
>> caution.
>>   *
>>   * @mr: the memory region being queried
>>   */
>> @@ -990,7 +990,8 @@ int memory_region_get_fd(MemoryRegion *mr);
>>   * protecting the pointer, such as a reference to the region that includes
>>   * the incoming ram_addr_t.
>>   *
>> - * @mr: the memory region being queried.
>> + * @ptr: the host pointer to be converted
>> + * @offset: the offset within memory region
>>   */
>>  MemoryRegion *memory_region_from_host(void *ptr, ram_addr_t *offset);
>>
>> @@ -1267,7 +1268,7 @@ void memory_region_clear_global_locking(MemoryRegion
>> *mr);
>>   * @size: the size of the access to trigger the eventfd
>>   * @match_data: whether to match against @data, instead of just @addr
>>   * @data: the data to match against the guest write
>> - * @fd: the eventfd to be triggered when @addr, @size, and @data all match.
>> + * @e: event notifier to be triggered when @addr, @size, and @data all 
>> match.
>>   **/
>>  void memory_region_add_eventfd(MemoryRegion *mr,
>> hwaddr addr, @@ -1287,7 +1288,7 @@ void
>> memory_region_add_eventfd(MemoryRegion *mr,
>>   * @size: the size of the access to trigger the eventfd
>>   * @match_data: whether to match against @data, instead of just @addr
>>   * @data: the data to match against the guest write
>> - * @fd: the eventfd to be triggered when @addr, @size, and @data all match.
>> + * @e: event notifier to be triggered when @addr, @size, and @data all 
>> match.
>>   */
>>  void memory_region_del_eventfd(MemoryRegion *mr,
>> hwaddr addr, @@ -1523,7 +1524,7 @@ bool
>> memory_region_request_mmio_ptr(MemoryRegion *mr, hwaddr addr);
>>   * will need to request the pointer again.
>>   *
>>   * @mr: #MemoryRegion associated to the pointer.
>

Re: [Qemu-devel] [qemu-s390x] [PATCH v3 1/8] s390-ccw: update libc

2018-01-16 Thread Collin L. Walling

On 01/16/2018 06:07 AM, Christian Borntraeger wrote:


On 01/15/2018 06:23 PM, Collin L. Walling wrote:

On 01/15/2018 12:05 PM, Eric Blake wrote:

On 01/15/2018 10:44 AM, Collin L. Walling wrote:

Moved:
    memcmp from bootmap.h to libc.h (renamed from _memcmp)
    strlen from sclp.c to libc.h (renamed from _strlen)

Added C standard functions:
    isdigit
    atoi

Added non-C standard function:
    itostr

Signed-off-by: Collin L. Walling 
Acked-by: Christian Borntraeger 
Reviewed-by: Janosch Frank 
---
+++ b/pc-bios/s390-ccw/libc.c
@@ -0,0 +1,83 @@
+/*
+ * libc-style definitions and functions
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.

I'm not a lawyer, but generically, the GPL and its variants depend on a
copyright owner to actually work.  You may want to add a copyright line.


I'll have to check on that.  I was not the original author of the libc.h file.

I think you can add the normal IBM Copyright statement. (I think all authors 
could add theirs as well)




"Copyright 2018 IBM Corp."

@Thomas, git shows you as the initial creator of libc.h.  Shall I add
"Copyright 2018 Thomas Huth, Red Hat Inc." in there as well?

--
- Collin L Walling




Re: [Qemu-devel] [PULL 00/24] target-arm queue

2018-01-16 Thread Peter Maydell
On 16 January 2018 at 13:33, Peter Maydell  wrote:
> More arm patches (mostly the SDHCI ones from Philippe)
>
> thanks
> -- PMM
>
> The following changes since commit f5213bd060b460c99e605472b7e03967db43:
>
>   Merge remote-tracking branch 'remotes/juanquintela/tags/migration/20180115' 
> into staging (2018-01-15 13:17:47 +)
>
> are available in the git repository at:
>
>   git://git.linaro.org/people/pmaydell/qemu-arm.git 
> tags/pull-target-arm-20180116
>
> for you to fetch changes up to 60765b6ceeb4998a0d4220b3a53f1f185061da77:
>
>   sdhci: add a 'dma' property to the sysbus devices (2018-01-16 13:28:21 
> +)
>
> 
> target-arm queue:
>  * SDHCI: cleanups and minor bug fixes
>  * target/arm: minor refactor preparatory to fp16 support
>  * omap_ssd, ssi-sd, pl181, milkymist-memcard: reset the SD
>card on controller reset (fixes migration failures)
>  * target/arm: Handle page table walk load failures correctly
>  * hw/arm/virt: Add virt-2.12 machine type
>  * get_phys_addr_pmsav7: Support AP=0b111 for v7M
>  * hw/intc/armv7m: Support byte and halfword accesses to CFSR
>

Applied, thanks.

-- PMM



[Qemu-devel] QEMU virt board: extending various limits

2018-01-16 Thread Peter Maydell
We've had discussions before about the various limits in the virt
board imposed by its current address space layout:
 * number of CPUs limited to 123 (not enough space for more redistributors)
 * number of PCIe devices limited by size of ECAM space
 * max memory size limits
 * (anything else?)

If we want to try to fix these this release cycle now would be a good
point to figure out our approach so that we have plenty of time to do
it in.

(Relatedly, I notice patches on list for kvm that allow userspace to
set the guest physical address size, which may affect how we want
to do this.)

I'm not going to have time to look at this but am happy to provide
my opinions on whatever proposals other people would like to suggest.

Probably the first thing to do is figure out whether we can
raise these limits without having to have a flag day (ie just
with changing the device tree we provide the guest), or if we
really have a hard compat break here. We should also try to
fix all these things at once rather than potentially breaking
guests several times...

thanks
-- PMM



Re: [Qemu-devel] [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps

2018-01-16 Thread Andrea Bolognani
On Wed, 2018-01-17 at 00:54 +1100, David Gibson wrote:
> > Correct me if I'm wrong, but it seems to me like there's no way
> > to figure out through QMP whether these new machine options can be
> > used for a given QEMU binary.
> 
> Uh, I don't think so.  These are machine options like any other (just
> constructed a bit differently).  So they'll appear in qemu -machine
> pseries,? and I believe that info can also be retrieved with QMP.

Yes, they will indeed show up in the output of -machine pseries,?
but there's AFAICT no way to retrieve them via QMP. And libvirt
can't afford to spawn a QEMU process for each machine type
implemented by each QEMU binary installed on the system just to
figure out what properties they support; in fact, we've been
pushing away from that approach - which was used initially - for
years and we're now at the point where we only fall back to it
for positively ancient QEMU versions. So the information needs
to be available through QMP for libvirt to consume it.

-- 
Andrea Bolognani / Red Hat / Virtualization



Re: [Qemu-devel] [PULL v3 00/53] Misc changes for 2017-01-12

2018-01-16 Thread Peter Maydell
On 16 January 2018 at 14:26, Paolo Bonzini  wrote:
> On 16/01/2018 15:22, Marc-André Lureau wrote:
>>> * if not, and assuming --enable-debug tries to enable ASAN, should
>>> --enable-debug complain if fiber support is not required?  Should
>>> --enable-debug enable ASAN if fiber support is not available?
>>
>> I propose to simply print a warning during configure
>
> Yes, it could do the same as --enable-asan.

The thing you want to avoid here is having one of my standard
build configs produce new text saying 'warning' or 'error',
because that will flag up to me as a build failure and I'll
bounce the pullreq...

thanks
-- PMM



[Qemu-devel] [PATCH 0/3] Sanitizers configuration

2018-01-16 Thread Marc-André Lureau
Hi,

This is a few reworked patches from "[PATCH v3 00/18] Various
build-sys and sanitizer related fixes" series.

It enables sanitizers by default with --enable-debug. But sanitizers
can be also enabled/disabled independently with a configure option.

If ASAN is detected but coroutine annotations are not available, then
a simple message is printed during configure.

Marc-André Lureau (3):
  exynos4210: workaround UBSAN compilation error
  build-sys: add --enable-sanitizers
  ucontext: annotate coroutine stack for ASAN

 include/qemu/compiler.h  |  4 +++
 hw/display/exynos4210_fimd.c |  2 +-
 util/coroutine-ucontext.c| 48 
 .travis.yml  |  3 +-
 configure| 65 
 5 files changed, 120 insertions(+), 2 deletions(-)

-- 
2.16.0.rc1.1.gef27df75a1




Re: [Qemu-devel] [PATCH v9 00/26] tcg: generic vector operations

2018-01-16 Thread Richard Henderson
On 01/16/2018 03:59 AM, Peter Maydell wrote:
> /var/tmp/patchew-tester-tmp-r7vd2rsz/src/accel/tcg/tcg-runtime-gvec.c:533:26:
> internal compiler error: in emit_move_insn, at expr.c:3495

Bah.  I remember seeing this myself on the gcc 4.8.x that is the system
compiler on the gcc compile farm machines.  I forgot about it because I
immediately changed my path to select gcc 7.x.  ;-P

> We need to either work around that or update the compiler in patchew's
> setup or disable that build before we can merge this, or patchew will
> start mailing complaints about every series that's sent to the list...

I can work around it in configure, but it might be worth updating the compiler
as well -- this bug has been fixed for years.


r~




Re: [Qemu-devel] [PATCH v4 14/14] Implement support for i.MX7 Sabre board

2018-01-16 Thread Peter Maydell
On 16 January 2018 at 01:37, Andrey Smirnov  wrote:
> Implement code needed to set up emulation of MCIMX7SABRE board from
> NXP. For more info about the HW see:
>
> https://www.nxp.com/support/developer-resources/hardware-development-tools/sabre-development-system/sabre-board-for-smart-devices-based-on-the-i.mx-7dual-applications-processors:MCIMX7SABRE
>
> Cc: Peter Maydell 
> Cc: Jason Wang 
> Cc: Philippe Mathieu-Daudé 
> Cc: qemu-devel@nongnu.org
> Cc: qemu-...@nongnu.org
> Cc: yurov...@gmail.com
> Signed-off-by: Andrey Smirnov 

Reviewed-by: Peter Maydell 

thanks
-- PMM



Re: [Qemu-devel] [qemu-s390x] [PATCH v3 1/8] s390-ccw: update libc

2018-01-16 Thread Thomas Huth
On 16.01.2018 16:32, Collin L. Walling wrote:
> On 01/16/2018 06:07 AM, Christian Borntraeger wrote:
>>
>> On 01/15/2018 06:23 PM, Collin L. Walling wrote:
>>> On 01/15/2018 12:05 PM, Eric Blake wrote:
[...]
 I'm not a lawyer, but generically, the GPL and its variants depend on a
 copyright owner to actually work.  You may want to add a copyright
 line.
>>>
>>> I'll have to check on that.  I was not the original author of the
>>> libc.h file.
>> I think you can add the normal IBM Copyright statement. (I think all
>> authors could add theirs as well)
> 
> "Copyright 2018 IBM Corp."
> 
> @Thomas, git shows you as the initial creator of libc.h.  Shall I add
> "Copyright 2018 Thomas Huth, Red Hat Inc." in there as well?

Actually, I only moved the functions from s390-ccw.h and sclp.c into
that header file. I just tried to trace who introduced them first, and
it seems like it was Alex who added them. So I guess you should add:

 Copyright (c) 2013 Alexander Graf 

to libc.h for that. Sorry that I did not do that right from the start.

 Thomas



[Qemu-devel] [PATCH 1/3] exynos4210: workaround UBSAN compilation error

2018-01-16 Thread Marc-André Lureau
gcc 5.4.0-6ubuntu1~16.04.5 build with UBSAN enabled error:

  CC  hw/display/exynos4210_fimd.o
/home/petmay01/linaro/qemu-for-merges/hw/display/exynos4210_fimd.c: In
function ‘fimd_get_buffer_id’:
/home/petmay01/linaro/qemu-for-merges/hw/display/exynos4210_fimd.c:1105:5:
error: case label does not reduce to an integer constant
 case FIMD_WINCON_BUF2_STAT:

Because FIMD_WINCON_BUF2_STAT case contains an integer
overflow, use U suffix to get the unsigned type.

Signed-off-by: Marc-André Lureau 
---
 hw/display/exynos4210_fimd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/display/exynos4210_fimd.c b/hw/display/exynos4210_fimd.c
index fd0b2bec65..86e37e93e9 100644
--- a/hw/display/exynos4210_fimd.c
+++ b/hw/display/exynos4210_fimd.c
@@ -98,7 +98,7 @@
 #define FIMD_WINCON_BUFSTATUS   ((1 << 21) | (1 << 31))
 #define FIMD_WINCON_BUF0_STAT   ((0 << 21) | (0 << 31))
 #define FIMD_WINCON_BUF1_STAT   ((1 << 21) | (0 << 31))
-#define FIMD_WINCON_BUF2_STAT   ((0 << 21) | (1 << 31))
+#define FIMD_WINCON_BUF2_STAT   ((0 << 21) | (1U << 31))
 #define FIMD_WINCON_BUFSELECT   ((1 << 20) | (1 << 30))
 #define FIMD_WINCON_BUF0_SEL((0 << 20) | (0 << 30))
 #define FIMD_WINCON_BUF1_SEL((1 << 20) | (0 << 30))
-- 
2.16.0.rc1.1.gef27df75a1




[Qemu-devel] [PATCH v2 2/4] acpi: build QEMU table for PPI virtual memory device

2018-01-16 Thread Stefan Berger
To avoid having to hard code the base address of the PPI virtual memory
device we introduce a QEMU ACPI table that holds the base address, if a
TPM 1.2 or 2 is used. This table gives us flexibility to move the base
address later on.

Signed-off-by: Stefan Berger 
---
 hw/i386/acpi-build.c| 19 +++
 include/hw/acpi/acpi-defs.h |  8 
 2 files changed, 27 insertions(+)

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 18b939e..522d6d2 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2628,6 +2628,20 @@ static bool acpi_get_mcfg(AcpiMcfgInfo *mcfg)
 return true;
 }
 
+static void build_qemu(GArray *table_data, BIOSLinker *linker,
+   TPMVersion tpm_version)
+{
+AcpiTableQemu *qemu = acpi_data_push(table_data, sizeof(*qemu));
+
+if (tpm_version != TPM_VERSION_UNSPEC) {
+qemu->tpmppi_addr = TPM_PPI_ADDR_BASE;
+qemu->tpm_version = tpm_version;
+}
+
+build_header(linker, table_data,
+ (void *)qemu, "QEMU", sizeof(*qemu), 1, "QEMU", "CONF");
+}
+
 static
 void acpi_build(AcpiBuildTables *tables, MachineState *machine)
 {
@@ -2734,6 +2748,11 @@ void acpi_build(AcpiBuildTables *tables, MachineState 
*machine)
   &pcms->acpi_nvdimm_state, machine->ram_slots);
 }
 
+if (misc.tpm_version != TPM_VERSION_UNSPEC) {
+acpi_add_table(table_offsets, tables_blob);
+build_qemu(tables_blob, tables->linker, misc.tpm_version);
+}
+
 /* Add tables supplied by user (if any) */
 for (u = acpi_table_first(); u; u = acpi_table_next(u)) {
 unsigned len = acpi_table_len(u);
diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
index 80c8099..98764c1 100644
--- a/include/hw/acpi/acpi-defs.h
+++ b/include/hw/acpi/acpi-defs.h
@@ -573,6 +573,14 @@ struct Acpi20TPM2 {
 } QEMU_PACKED;
 typedef struct Acpi20TPM2 Acpi20TPM2;
 
+/* QEMU - Custom QEMU table */
+struct AcpiTableQemu {
+ACPI_TABLE_HEADER_DEF
+uint32_t tpmppi_addr;
+uint8_t tpm_version; /* 1 = 1.2, 2 = 2 */
+};
+typedef struct AcpiTableQemu AcpiTableQemu;
+
 /* DMAR - DMA Remapping table r2.2 */
 struct AcpiTableDmar {
 ACPI_TABLE_HEADER_DEF
-- 
2.5.5




[Qemu-devel] [PATCH v2 0/4] Implement Physical Presence interface for TPM 1.2 and 2

2018-01-16 Thread Stefan Berger
The following patches implement the TPM Physical Presence Interface that
allows a user to set a command via ACPI (sysfs entry in Linux) that, upon
the next reboot, the firmware (BIOS, UEFI) looks for an acts upon by sending
sequences of commands to the TPM 1.2 or 2.

My first goal is to get the virtual memory device accepted since it extends
the TPM TIS (and TPM CRB) interface's internal data structure with another
256 bytes that would have to be written out when suspending the VM. So this
patch would have to come before we support VM with TPM suspend and resume.
The device supports 256 bytes at address 0x. This is the address that
EDK2 uses and that I have patches for for SeaBIOS support.

Regards,
   Stefan


Stefan Berger (4):
  tpm: implement virtual memory device for TPM PPI
  acpi: build QEMU table for PPI virtual memory device
  acpi: implement aml_lless_equal
  acpi: build TPM Physical Presence interface

 hw/acpi/aml-build.c |  11 ++
 hw/i386/acpi-build.c| 292 
 hw/tpm/Makefile.objs|   2 +-
 hw/tpm/tpm_ppi.c|  67 ++
 hw/tpm/tpm_ppi.h|  26 
 hw/tpm/tpm_tis.c|   5 +
 include/hw/acpi/acpi-defs.h |  10 ++
 include/hw/acpi/aml-build.h |   1 +
 include/hw/acpi/tpm.h   |  37 ++
 9 files changed, 450 insertions(+), 1 deletion(-)
 create mode 100644 hw/tpm/tpm_ppi.c
 create mode 100644 hw/tpm/tpm_ppi.h

-- 
2.5.5




Re: [Qemu-devel] [PATCH v4 13/14] hw/arm: Move virt's PSCI DT fixup code to arm/boot.c

2018-01-16 Thread Peter Maydell
On 16 January 2018 at 01:37, Andrey Smirnov  wrote:
> Move virt's PSCI DT fixup code to arm/boot.c and set this fixup to
> happen automatically for every board that doesn't mark "psci-conduit"
> as disabled. This way emulated boards other than "virt" that rely on
> PSIC for SMP could benefit from that code.
>
> Cc: Peter Maydell 
> Cc: Jason Wang 
> Cc: Philippe Mathieu-Daudé 
> Cc: qemu-devel@nongnu.org
> Cc: qemu-...@nongnu.org
> Cc: yurov...@gmail.com
> Signed-off-by: Andrey Smirnov 
> ---
>  hw/arm/boot.c | 65 
> +++
>  hw/arm/virt.c | 61 ---
>  2 files changed, 65 insertions(+), 61 deletions(-)
>

Reviewed-by: Peter Maydell 

thanks
-- PMM



[Qemu-devel] [PATCH 2/3] build-sys: add --enable-sanitizers

2018-01-16 Thread Marc-André Lureau
Typical slowdown introduced by AddressSanitizer is 2x.
UBSan shouldn't have much impact on runtime cost.

Enable it by default when --enable-debug, unless --disable-sanitizers.

Signed-off-by: Marc-André Lureau 
---
 configure | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/configure b/configure
index 6d8c996c62..9a435917cc 100755
--- a/configure
+++ b/configure
@@ -342,6 +342,7 @@ rdma=""
 gprof="no"
 debug_tcg="no"
 debug="no"
+sanitizers=""
 fortify_source=""
 strip_opt="yes"
 tcg_interpreter="no"
@@ -994,6 +995,10 @@ for opt do
   strip_opt="no"
   fortify_source="no"
   ;;
+  --enable-sanitizers) sanitizers="yes"
+  ;;
+  --disable-sanitizers) sanitizers="no"
+  ;;
   --enable-sparse) sparse="yes"
   ;;
   --disable-sparse) sparse="no"
@@ -1471,6 +1476,7 @@ Advanced options (experts only):
   --firmwarepath=PATH  search PATH for firmware files
   --with-confsuffix=SUFFIX suffix for QEMU data inside 
datadir/libdir/sysconfdir [$confsuffix]
   --enable-debug   enable common debug build options
+  --enable-sanitizers  enable default sanitizers
   --disable-strip  disable stripping binaries
   --disable-werror disable compilation abort on warning
   --disable-stack-protector disable compiler-provided stack protection
@@ -5185,6 +5191,28 @@ if compile_prog "" "" ; then
 have_utmpx=yes
 fi
 
+##
+# checks for sanitizers
+
+write_c_skeleton
+
+have_asan=no
+have_ubsan=no
+
+# enable sanitizers by default if --enable-debug
+if test "$sanitizers" = "" -a "$debug" = "yes"; then
+  sanitizers=yes
+fi
+
+if test "$sanitizers" = "yes" ; then
+  if compile_prog "$CPU_CFLAGS -Werror -fsanitize=address" ""; then
+  have_asan=yes
+  fi
+  if compile_prog "$CPU_CFLAGS -Werror -fsanitize=undefined" ""; then
+  have_ubsan=yes
+  fi
+fi
+
 ##
 # End of CC checks
 # After here, no more $cc or $ld runs
@@ -5209,6 +5237,13 @@ else
 CFLAGS="-O2 $CFLAGS"
 fi
 
+if test "$have_asan" = "yes"; then
+  CFLAGS="-fsanitize=address $CFLAGS"
+fi
+if test "$have_ubsan" = "yes"; then
+  CFLAGS="-fsanitize=undefined $CFLAGS"
+fi
+
 ##
 # Do we have libnfs
 if test "$libnfs" != "no" ; then
-- 
2.16.0.rc1.1.gef27df75a1




[Qemu-devel] [PATCH v2 4/4] acpi: build TPM Physical Presence interface

2018-01-16 Thread Stefan Berger
The TPM Physical Presence interface consists of an ACPI part, a shared
memory part, and code in the firmware. Users can send messages to the
firmware by writing a code into the shared memory through invoking the
ACPI code. When a reboot happens, the firmware looks for the code and
acts on it by sending sequences of commands to the TPM.

This patch adds the ACPI code. It is similar to the one in EDK2 but doesn't
assume that SMIs are necessary to use. It uses a similar datastructure for
the shared memory as EDK2 does so that EDK2 and SeaBIOS could both make use
of it. I extended the shared memory data structure with an array of 256
bytes, one for each code that could be implemented. The array contains
flags describing the individual codes. This decouples the ACPI implementation
from the firmware implementation.

The underlying TCG specification is accessible from the following page.

https://trustedcomputinggroup.org/tcg-physical-presence-interface-specification/

This patch implements version 1.30.

Signed-off-by: Stefan Berger 

---
 v1->v2:
   - get rid of FAIL variable; function 5 was using it and always
 returns 0; the value is related to the ACPI function call not
 a possible failure of the TPM function call.
   - extend shared memory data structure with per-opcode entries
 holding flags and use those flags to determine what to return
 to caller
   - implement interface version 1.3
---
 hw/i386/acpi-build.c| 273 
 include/hw/acpi/acpi-defs.h |   2 +
 include/hw/acpi/tpm.h   |  31 +
 3 files changed, 306 insertions(+)

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 522d6d2..f8c2d01 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -42,6 +42,7 @@
 #include "hw/acpi/memory_hotplug.h"
 #include "sysemu/tpm.h"
 #include "hw/acpi/tpm.h"
+#include "hw/tpm/tpm_ppi.h"
 #include "hw/acpi/vmgenid.h"
 #include "sysemu/tpm_backend.h"
 #include "hw/timer/mc146818rtc_regs.h"
@@ -1860,6 +1861,276 @@ static Aml *build_q35_osc_method(void)
 }
 
 static void
+build_tpm_ppi(Aml *dev, TPMVersion tpm_version)
+{
+Aml *method, *field, *ifctx, *ifctx2, *ifctx3, *pak;
+
+aml_append(dev,
+   aml_operation_region("TPPI", AML_SYSTEM_MEMORY,
+aml_int(TPM_PPI_ADDR_BASE),
+TPM_PPI_STRUCT_SIZE));
+
+field = aml_field("TPPI", AML_ANY_ACC, AML_NOLOCK, AML_PRESERVE);
+aml_append(field, aml_named_field("PPIN",
+   sizeof(uint8_t) * BITS_PER_BYTE));
+aml_append(field, aml_named_field("PPIP",
+   sizeof(uint32_t) * BITS_PER_BYTE));
+aml_append(field, aml_named_field("PPRP",
+   sizeof(uint32_t) * BITS_PER_BYTE));
+aml_append(field, aml_named_field("PPRQ",
+   sizeof(uint32_t) * BITS_PER_BYTE));
+aml_append(field, aml_named_field("PPRM",
+   sizeof(uint32_t) * BITS_PER_BYTE));
+aml_append(field, aml_named_field("LPPR",
+   sizeof(uint32_t) * BITS_PER_BYTE));
+aml_append(field, aml_reserved_field(
+   sizeof(uint32_t) * BITS_PER_BYTE /* FRET */ +
+   sizeof(uint8_t) * BITS_PER_BYTE /* MCIN */ +
+   sizeof(uint32_t) * BITS_PER_BYTE * 4 /* MCIP .. UCRQ */ +
+   sizeof(uint8_t) * BITS_PER_BYTE * 214));
+aml_append(field, aml_named_field("FUNC",
+   sizeof(uint8_t) * BITS_PER_BYTE * 256));
+aml_append(dev, field);
+
+method = aml_method("_DSM", 4, AML_SERIALIZED);
+{
+uint8_t zerobyte[1] = { 0 };
+
+ifctx = aml_if(
+  aml_equal(aml_arg(0),
+aml_touuid("3DDDFAA6-361B-4EB4-A424-8D10089D1653"))
+);
+{
+aml_append(ifctx,
+   aml_store(aml_to_integer(aml_arg(2)), aml_local(0)));
+
+/* standard DSM query function */
+ifctx2 = aml_if(aml_equal(aml_local(0), aml_int(0)));
+{
+uint8_t byte_list[2] = { 0xff, 0x01 };
+aml_append(ifctx2, aml_return(aml_buffer(2, byte_list)));
+}
+aml_append(ifctx, ifctx2);
+
+/* interface version: 1.3 */
+ifctx2 = aml_if(aml_equal(aml_local(0), aml_int(1)));
+{
+aml_append(ifctx2, aml_return(aml_string("1.3")));
+}
+aml_append(ifctx, ifctx2);
+
+/* submit TPM operation */
+ifctx2 = aml_if(aml_equal(aml_local(0), aml_int(2)));
+{
+/* get opcode */
+aml_append(ifctx2,
+   aml_store(aml_derefof(aml_index(aml_arg(3),
+   aml_int(0))),
+ aml_local(0)));
+/* get opcode flags */
+aml_append(ifctx2,
+   aml_store(aml_derefof(aml_index(aml_name("FU

[Qemu-devel] [PATCH v2 1/4] tpm: implement virtual memory device for TPM PPI

2018-01-16 Thread Stefan Berger
Implement a virtual memory device for the TPM Physical Presence interface.
The memory is located at 0xfffef000 and used by ACPI to send messages to the
firmware (BIOS) and by the firmware to provide parameters for each one of
the supported codes.

This device should be used by all TPM interfaces on x86 and can be added
by calling tpm_ppi_init_io().

Signed-off-by: Stefan Berger 

---

v1->v2:
 - moved to byte access since an infrequently used device;
   this simplifies code
 - increase size of device to 0x400
 - move device to 0xfffef000 since SeaBIOS has some code at 0x:
   'On the emulators, the bios at 0xf is also at 0x'
---
 hw/tpm/Makefile.objs  |  2 +-
 hw/tpm/tpm_ppi.c  | 67 +++
 hw/tpm/tpm_ppi.h  | 26 
 hw/tpm/tpm_tis.c  |  5 
 include/hw/acpi/tpm.h |  6 +
 5 files changed, 105 insertions(+), 1 deletion(-)
 create mode 100644 hw/tpm/tpm_ppi.c
 create mode 100644 hw/tpm/tpm_ppi.h

diff --git a/hw/tpm/Makefile.objs b/hw/tpm/Makefile.objs
index 7a93b24..3eb0558 100644
--- a/hw/tpm/Makefile.objs
+++ b/hw/tpm/Makefile.objs
@@ -1,4 +1,4 @@
-common-obj-y += tpm_util.o
+common-obj-y += tpm_util.o tpm_ppi.o
 common-obj-$(CONFIG_TPM_TIS) += tpm_tis.o
 common-obj-$(CONFIG_TPM_PASSTHROUGH) += tpm_passthrough.o
 common-obj-$(CONFIG_TPM_EMULATOR) += tpm_emulator.o
diff --git a/hw/tpm/tpm_ppi.c b/hw/tpm/tpm_ppi.c
new file mode 100644
index 000..98e8318
--- /dev/null
+++ b/hw/tpm/tpm_ppi.c
@@ -0,0 +1,67 @@
+/*
+ * tpm_ppi.c - TPM Physical Presence Interface
+ *
+ * Copyright (C) 2018 IBM Corporation
+ *
+ * Authors:
+ *  Stefan Berger 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "exec/memory.h"
+#include "exec/address-spaces.h"
+
+#include "tpm_ppi.h"
+
+#define DEBUG_PPI 0
+
+#define DPRINTF(fmt, ...) do { \
+if (DEBUG_PPI) { \
+printf(fmt, ## __VA_ARGS__); \
+} \
+} while (0)
+
+static uint64_t tpm_ppi_mmio_read(void *opaque, hwaddr addr,
+  unsigned size)
+{
+TPMPPI *s = opaque;
+
+DPRINTF("tpm_ppi:  read(%04x) = %02x\n",
+(unsigned int)addr, (unsigned int)s->ram[addr]);
+
+return s->ram[addr];
+}
+
+static void tpm_ppi_mmio_write(void *opaque, hwaddr addr,
+   uint64_t val, unsigned size)
+{
+TPMPPI *s = opaque;
+
+DPRINTF("tpm_ppi: write(%04x) = %02x\n",
+(unsigned int)addr, (unsigned int)val);
+
+s->ram[addr] = val;
+}
+
+static const MemoryRegionOps tpm_ppi_memory_ops = {
+.read = tpm_ppi_mmio_read,
+.write = tpm_ppi_mmio_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
+.valid = {
+.min_access_size = 1,
+.max_access_size = 1,
+},
+};
+
+void tpm_ppi_init_io(TPMPPI *tpmppi, struct MemoryRegion *m, Object *obj)
+{
+memory_region_init_io(&tpmppi->mmio, obj, &tpm_ppi_memory_ops,
+  tpmppi, "tpm-ppi-mmio",
+  TPM_PPI_ADDR_SIZE);
+
+memory_region_add_subregion(m, TPM_PPI_ADDR_BASE, &tpmppi->mmio);
+}
diff --git a/hw/tpm/tpm_ppi.h b/hw/tpm/tpm_ppi.h
new file mode 100644
index 000..17030bd
--- /dev/null
+++ b/hw/tpm/tpm_ppi.h
@@ -0,0 +1,26 @@
+/*
+ * TPM Physical Presence Interface
+ *
+ * Copyright (C) 2018 IBM Corporation
+ *
+ * Authors:
+ *  Stefan Berger
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+#ifndef TPM_TPM_PPI_H
+#define TPM_TPM_PPI_H
+
+#include "hw/acpi/tpm.h"
+#include "exec/address-spaces.h"
+
+typedef struct TPMPPI {
+MemoryRegion mmio;
+
+uint8_t ram[TPM_PPI_ADDR_SIZE];
+} TPMPPI;
+
+void tpm_ppi_init_io(TPMPPI *tpmppi, struct MemoryRegion *m, Object *obj);
+
+#endif /* TPM_TPM_PPI_H */
diff --git a/hw/tpm/tpm_tis.c b/hw/tpm/tpm_tis.c
index 561384c..13e7dd3 100644
--- a/hw/tpm/tpm_tis.c
+++ b/hw/tpm/tpm_tis.c
@@ -31,6 +31,7 @@
 #include "sysemu/tpm_backend.h"
 #include "tpm_int.h"
 #include "tpm_util.h"
+#include "tpm_ppi.h"
 
 #define TPM_TIS_NUM_LOCALITIES  5 /* per spec */
 #define TPM_TIS_LOCALITY_SHIFT  12
@@ -80,6 +81,8 @@ typedef struct TPMState {
 TPMVersion be_tpm_version;
 
 size_t be_buffer_size;
+
+TPMPPI ppi;
 } TPMState;
 
 #define TPM(obj) OBJECT_CHECK(TPMState, (obj), TYPE_TPM_TIS)
@@ -1041,6 +1044,8 @@ static void tpm_tis_realizefn(DeviceState *dev, Error 
**errp)
 
 memory_region_add_subregion(isa_address_space(ISA_DEVICE(dev)),
 TPM_TIS_ADDR_BASE, &s->mmio);
+
+tpm_ppi_init_io(&s->ppi, isa_address_space(ISA_DEVICE(dev)), OBJECT(s));
 }
 
 static void tpm_tis_initfn(Object *obj)
diff --git a/include/hw/acpi/tpm.h b/include/hw/acpi/tpm.h
index 6d516c6..16227bc 100644
--- a/include/hw/acpi/tpm.h
+++ b/include/hw/acpi/tpm.h
@@ -31,4 +31,10 @@
 
 #define TPM

Re: [Qemu-devel] [PATCH v4 00/14] Initial i.MX7 support

2018-01-16 Thread Andrey Smirnov
On Tue, Jan 16, 2018 at 7:08 AM, Peter Maydell  wrote:
> On 16 January 2018 at 01:36, Andrey Smirnov  wrote:
>> Hi everyone,
>>
>> This v4 of the patch series containing the work that I've done in
>> order to enable support for i.MX7 emulation in QEMU.
>>
>> *NOTE*: Patches 1 and 2 are provided for the sake of completness and
>> are going to have to be adapted once Philippe's SD changes
>> land in master. As such, they are NOT ready to be
>> accepted/merged.
>
> I've just pushed a pullreq including Philippe's SD changes to master,
> so you should be able to do the final versions of these i.MX SD patches
> now. I've also I think now reviewed everything except the pci patch,
> which is a bit out of my competence area.

That's great news! I'll rebase on top of that as soon as I get a chance.

Thanks,
Andrey Smirnov



Re: [Qemu-devel] [RFC PATCH 0/3] vfio: ccw: basic channel path event handling

2018-01-16 Thread Cornelia Huck
On Tue, 16 Jan 2018 11:16:27 +0800
Dong Jia Shi  wrote:

> * Pierre Morel  [2018-01-15 11:21:47 +0100]:
> 
> > On 15/01/2018 09:57, Dong Jia Shi wrote:  
> > >* Cornelia Huck  [2018-01-11 11:54:22 +0100]:
> > >  
> > >>On Thu, 11 Jan 2018 04:04:18 +0100
> > >>Dong Jia Shi  wrote:
> > >>  
> > >>>Hi Folks,
> > >>>
> > >>>Background
> > >>>==
> > >>>
> > >>>Some days ago, we had a discussion on the topic of channel path 
> > >>>virtualization.
> > >>>Ref:
> > >>>Subject: [PATCH 0/3] Channel Path realted CRW generation
> > >>>Message-Id: <20170727015418.85407-1-bjsdj...@linux.vnet.ibm.com>
> > >>>URL: 
> > >>>https://lists.nongnu.org/archive/html/qemu-devel/2017-07/msg08414.html
> > >>>
> > >>>Indeed that thread is not short and discussed many aspects in a
> > >>>non-concentrated manner. The parts those are most valuable to me are:
> > >>>1. a re-modelling for channel path is surely the best offer, but is not
> > >>>possible to have in the near future.
> > >>>2. to enhance the path related functionalities, using PNO and PNOM might
> > >>>be something we can do for now. This may be something that I could 
> > >>> improve
> > >>>without model related arguments.
> > >>>
> > >>>So here I have this series targeting to add basic channel path event 
> > >>>handling
> > >>>for vfio-ccw -- no touch of the channel path modelling in both the 
> > >>>kernel and
> > >>>the QEMU side, but find a way to sync path status change to guest lazily 
> > >>>using
> > >>>SCSW_FLAGS_MASK_PNO and pmcw->pnom.  In short, I want to enhance path 
> > >>>related
> > >>>stuff (to be more specific: sync up path status to the guest) on a best 
> > >>>effort
> > >>>basis, which means in a way that won't get us invloed to do channel path
> > >>>re-modelling.  
> > >>The guest should also get the updated PIM/PAM/POM, shouldn't it?
> > >>  
> > >Yes. The following values will be updated for the guest:
> > >PMCW:
> > >   - PIM/PAM/POM
> > >   - PNOM
> > >   - CHPIDs
> > >SCSW
> > >   - PNOM bit
> > >
> > >See vfio_ccw_update_schib in patch #4 of the QEMU series.
> > >  
> > >>>What benifit can we get from this? The administrator of a virtual 
> > >>>machine can
> > >>>get uptodate (in some extent) status of the current using channel paths, 
> > >>>so
> > >>>he/she can monitor paths status and get path problem noticed timely (see 
> > >>>the
> > >>>example below).
> > >>>
> > >>>I think we can start a new round discussion based on this series. So 
> > >>>reviewers
> > >>>can give their comments based on some code, and then we can decide if 
> > >>>this is
> > >>>we want or not.
> > >>>
> > >>>As flagged with RFC, the intention of this series is to show what I have 
> > >>>for
> > >>>now, and what could the code look like in general. Thus I can get some 
> > >>>early
> > >>>feedbacks. I would expect to see opinions on:
> > >>>- is the target (mentioned above) of this series welcomed or not.  
> > >>It certainly makes sense to have a way to get an updated schib.
> > >>  
> > >:)  
> > 
> > I think so too, if the guest's administrator wants to be able to do
> > something.
> > 
> > But I would like to see something about path virtualization.  
> Me too... As pointed in the discussion thread (URL listed above), this
> is something that really hard to have in the near future. The question
> is do we want some enhancements like this without channel path
> re-modelling, or we want nothing until we have the re-modelling firstly?

I consider the ability to grab an updated schib useful not only for
path-related stuff, but for getting the whole content of it updated;
this makes the interface interesting even in the future.

And I think everybody wants more path virtualization, but that's not
going to be easy.

> 
> > Having more accurate information on hardware without virtualization is a
> > big handicap for migration and hotplug.
> >   
> vfio-ccw does not support migration. What could be the handicap for
> that? :^)
> 

Heh :)

Actually, thinking about migration has been on my to-do list for a
while; unfortunately, it's not alone there. (I fully expect the items
on my to-do list to hold tea parties so they don't get bored.)



Re: [Qemu-devel] [PATCH 1/3] linux-user: introduce functions to detect CPU type

2018-01-16 Thread Richard Henderson
On 01/16/2018 06:13 AM, Laurent Vivier wrote:
>> There is no reason to read the elf header twice -- e_flags has already been
>> stored in the struct image_info.
> 
> When we set cpu_model, image_info is not initialized.
> Do you propose to move cpu_init() after loader_exec()?

Sure.


r~



Re: [Qemu-devel] [qemu-s390x] [PATCH v3 3/8] s390-ccw: parse and set boot menu options

2018-01-16 Thread Collin L. Walling

On 01/16/2018 07:44 AM, Thomas Huth wrote:

On 15.01.2018 17:44, Collin L. Walling wrote:

Set boot menu options for an s390 guest and store them in
the iplb. These options are set via the QEMU command line
option:

 -boot menu=on|off[,splash-time=X]

or via the libvirt domain xml:

 
   
 

Where X represents some positive integer representing
milliseconds.

A loadparm other than 'prompt' will disable the menu and
just boot the specified entry.

Signed-off-by: Collin L. Walling 
Reviewed-by: Janosch Frank 
---
  hw/s390x/ipl.c  | 54 +
  hw/s390x/ipl.h  | 11 --
  pc-bios/s390-ccw/iplb.h |  8 ++--
  3 files changed, 69 insertions(+), 4 deletions(-)

diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c
index 0d06fc1..81ba9ed 100644
--- a/hw/s390x/ipl.c
+++ b/hw/s390x/ipl.c
@@ -23,6 +23,8 @@
  #include "hw/s390x/ebcdic.h"
  #include "ipl.h"
  #include "qemu/error-report.h"
+#include "qemu/config-file.h"
+#include "qemu/cutils.h"
  
  #define KERN_IMAGE_START0x01UL

  #define KERN_PARM_AREA  0x010480UL
@@ -219,6 +221,55 @@ static Property s390_ipl_properties[] = {
  DEFINE_PROP_END_OF_LIST(),
  };
  
+static void s390_ipl_set_boot_menu(IplParameterBlock *iplb)

+{
+QemuOptsList *plist = qemu_find_opts("boot-opts");
+QemuOpts *opts = QTAILQ_FIRST(&plist->head);
+uint8_t *flags;
+uint16_t *timeout;
+const char *tmp;
+unsigned long result = 0;
+
+switch (iplb->pbt) {
+case S390_IPL_TYPE_CCW:
+flags = &iplb->ccw.boot_menu_flags;
+timeout = &iplb->ccw.boot_menu_timeout;
+break;
+case S390_IPL_TYPE_QEMU_SCSI:
+flags = &iplb->scsi.boot_menu_flags;
+timeout = &iplb->scsi.boot_menu_timeout;
+break;
+default:
+error_report("boot menu is not supported for this device type.");
+return;
+}
+
+/* In the absence of -boot menu, use zipl parameters */
+if (!qemu_opt_get(opts, "menu")) {
+*flags = BOOT_MENU_FLAG_ZIPL_OPTS;
+} else if (boot_menu) {
+*flags = BOOT_MENU_FLAG_BOOT_OPTS;
+
+tmp = qemu_opt_get(opts, "splash-time");
+
+if (tmp && qemu_strtoul(tmp, NULL, 10, &result)) {
+error_report("splash-time value is invalid, forcing it to 0.");

It's likely not needed, but an explicit "*timeout = 0" would be fine
here, I think.



It is not needed, but it might assist with readability.





+return;
+}
+
+result /= 1000; /* Store timeout value as seconds */

Maybe rather do proper rounding:

 result = (result + 500) / 1000;

?


Makes sense.




+if (result > 0x) {
+error_report("splash-time value is greater than 65535000,"
+ " forcing it to 65535000.");
+*timeout = 0x;
+return;
+}
+
+*timeout = cpu_to_be16(result);
+}
+}
+

I've found just some nits ... patch looks fine in general, so feel free
to add:

Reviewed-by: Thomas Huth 



Thanks for the review, Thomas.

--
- Collin L Walling




Re: [Qemu-devel] [PULL 08/51] chardev: introduce qemu_chr_timeout_add_ms()

2018-01-16 Thread Paolo Bonzini
On 16/01/2018 15:43, Daniel P. Berrange wrote:
>>
>> It's a replacement of g_timeout_add[_seconds]() for chardevs.  Chardevs
>> now can have dedicated gcontext, we should always bind chardev tasks
>> onto those gcontext rather than the default main context.  Since there
>> are quite a few of g_timeout_add[_seconds]() callers, a new function
>> qemu_chr_timeout_add_ms() is introduced.
> FYI the point of using g_timeout_add_seconds() is that it allow the
> glib event loop to be more efficient. It ensures that all timers
> which second granularity are dispatched on the same iteration of
> the main loop. IOW, if you have 10 timers registered with
> g_timeout_add_seconds() the main loop wakes up once a second and
> runs all 10 of them. If you have 10 timers registered with g_timeout_add
> the main loop wakes up 10 times a second, at a different time for each
> timer.

Yes, that can be added back later.  In our case, it may even hurt to
synchronize all timeouts at the same time (if there are many of them)
because the BQL can introduce jitter.  But it is difficult to say
without measuring.

Paolo



Re: [Qemu-devel] [RFC PATCH 0/3] vfio: ccw: basic channel path event handling

2018-01-16 Thread Halil Pasic


On 01/15/2018 09:59 AM, Dong Jia Shi wrote:
> * Halil Pasic  [2018-01-12 19:10:20 +0100]:
> 
>>
>>
>> On 01/11/2018 04:04 AM, Dong Jia Shi wrote:
>>> What are still missing, thus need to be offered in the next version are:
>>> - I/O termination and FSM state handling if currently we have I/O on the 
>>> status
>>>   switched path.
>>> - Vary on/off event is not sensible to a guest.
>>
>> I don't see a doc update. We do have documentation (in
>> Documentation/s390/vfio-ccw.txt) in which the uapi interface with the
>> regions and their purpose/usage  is at least kind of explained. You are
>> changing this interface without updating the doc.
>>
>> I would like to see documentation on this because I'm under the
>> impression either the design is pretty convoluted or I did not
>> get it at all.
> Ah, I missed the documentation part. Thanks for pointing out. I will add
> it in the next cycle.
> 

I would have preferred having a doc update in this cycle. E.g. as
an answer to the cover letter.

As previously pointed out I don't really understand your design.
I wanted to avoid summarizing the design myself (that is my understanding
of it), to then question the design.

To give you a feeling of what I mean here some bullet points:
* Channel paths are css level resources (simplified).
* When a channel path malfunctions a CRW is generated and a machine
check channel report pending is generated. Same goes for
channel paths popping up (on HW level). Should not these get
propagated?
* Kind of instead of the CRW you introduce a per device interrupt
for channel path events on the qemu/kvm boundary. AFAIU for a chp
event you do an STSCH for each (affected?) subchannel and generate
an irq. Right? Why is this a good idea.
* SCHIB.PMCW provides path information relevant for a given device.
This information is retrieved using store subchannel. Is your series
sufficient for making store subchannel work properly (correct and
reasonably up to date)? Regarding PMCW it's supposed to get updated
when io functions are preformed by the css, AFAIR. Is that right?
If yes what are the implications? Are the manipulations you do
on some PMCW fields architecturally correct?
* The one thing I would very much appreciate as an user of vfio,
and should in my understanding be the user story of this series
(and the qemu counterpart of course) is the following. If my device
(that is IO operation) failed because no path could be found on
which the device is accessible, I would like to be able to identify
that. Preferably the same way I would do for an LPAR guest. Is this
series accomplishing that? 
* Why not just do proper STSCH for vfio-ccw?
* Shouldn't we virtualize CHPIDs? What if we have a clash? Lets
say my dasd is only accessible via chp  0.00 in the host. Currently
we have a problem there, or (as the only path would end up being
ignored)? Note: this is another unpleasant effect of not having
MCSSE in the guest. The original design was to have a separate
css for vfio, and then we would not have this kind of a problem.
(Virtualization of chps would still be good for migration.)

Regards,
Halil




Re: [Qemu-devel] [PATCH v4 00/14] Initial i.MX7 support

2018-01-16 Thread Peter Maydell
On 16 January 2018 at 01:36, Andrey Smirnov  wrote:
> Hi everyone,
>
> This v4 of the patch series containing the work that I've done in
> order to enable support for i.MX7 emulation in QEMU.
>
> *NOTE*: Patches 1 and 2 are provided for the sake of completness and
> are going to have to be adapted once Philippe's SD changes
> land in master. As such, they are NOT ready to be
> accepted/merged.

I've just pushed a pullreq including Philippe's SD changes to master,
so you should be able to do the final versions of these i.MX SD patches
now. I've also I think now reviewed everything except the pci patch,
which is a bit out of my competence area.

thanks
-- PMM



Re: [Qemu-devel] [qemu-s390x] [PATCH v3 2/8] s390-ccw: ipl structs for eckd cdl/ldl

2018-01-16 Thread Collin L. Walling

On 01/16/2018 07:32 AM, Thomas Huth wrote:

On 15.01.2018 17:44, Collin L. Walling wrote:

ECKD DASDs have different IPL structures for CDL and LDL
formats. The current Ipl1 and Ipl2 structs follow the CDL
format, so we prepend "EckdCdl" to them. Boot info for LDL
has been moved to a new struct: EckdLdlIpl1.

Also introduce structs for IPL stages 1 and 1b and for
disk geometry.

Signed-off-by: Collin L. Walling 
Acked-by: Janosch Frank 
---
  pc-bios/s390-ccw/bootmap.c | 29 +---
  pc-bios/s390-ccw/bootmap.h | 55 +-
  2 files changed, 56 insertions(+), 28 deletions(-)

diff --git a/pc-bios/s390-ccw/bootmap.c b/pc-bios/s390-ccw/bootmap.c
index 6f8e30f..29915e4 100644
--- a/pc-bios/s390-ccw/bootmap.c
+++ b/pc-bios/s390-ccw/bootmap.c
@@ -221,9 +221,9 @@ static void run_eckd_boot_script(block_number_t 
mbr_block_nr)
  static void ipl_eckd_cdl(void)
  {
  XEckdMbr *mbr;
-Ipl2 *ipl2 = (void *)sec;
+EckdCdlIpl2 *ipl2 = (void *)sec;
  IplVolumeLabel *vlbl = (void *)sec;
-block_number_t block_nr;
+block_number_t mbr_block_nr;
  
  /* we have just read the block #0 and recognized it as "IPL1" */

  sclp_print("CDL\n");
@@ -231,16 +231,13 @@ static void ipl_eckd_cdl(void)
  memset(sec, FREE_SPACE_FILLER, sizeof(sec));
  read_block(1, ipl2, "Cannot read IPL2 record at block 1");
  
-mbr = &ipl2->u.x.mbr;

+mbr = &ipl2->mbr;
  IPL_assert(magic_match(mbr, ZIPL_MAGIC), "No zIPL section in IPL2 
record.");
  IPL_assert(block_size_ok(mbr->blockptr.xeckd.bptr.size),
 "Bad block size in zIPL section of IPL2 record.");
  IPL_assert(mbr->dev_type == DEV_TYPE_ECKD,
 "Non-ECKD device type in zIPL section of IPL2 record.");
  
-/* save pointer to Boot Script */

-block_nr = eckd_block_num((void *)&(mbr->blockptr));
-
  memset(sec, FREE_SPACE_FILLER, sizeof(sec));
  read_block(2, vlbl, "Cannot read Volume Label at block 2");

Why did you move the block_nr = eckd_block_num(...) behind the
read_block() ? That sounds like you could different values here now. If
that has been done on purpose and is not a mistake, please add a proper
sentence about this to the patch description.



Yes you are definitely correct... a guest running cdl formatted dasd should
fail to IPL with this.  I must've made this error somewhere along the way
when cleaning up the commits.  Thank you for catching this.





  IPL_assert(magic_match(vlbl->key, VOL1_MAGIC),
@@ -249,7 +246,10 @@ static void ipl_eckd_cdl(void)
 "Invalid magic of volser block");
  print_volser(vlbl->f.volser);
  
-run_eckd_boot_script(block_nr);

+/* save pointer to Boot Script */
+mbr_block_nr = eckd_block_num((void *)&mbr->blockptr);
+
+run_eckd_boot_script(mbr_block_nr);
  /* no return */
  }
  
@@ -280,8 +280,8 @@ static void print_eckd_ldl_msg(ECKD_IPL_mode_t mode)
  
  static void ipl_eckd_ldl(ECKD_IPL_mode_t mode)

  {
-block_number_t block_nr;
-BootInfo *bip = (void *)(sec + 0x70); /* BootInfo is MBR for LDL */
+block_number_t mbr_block_nr;
+EckdLdlIpl1 *ipl1 = (void *)sec;
  
  if (mode != ECKD_LDL_UNLABELED) {

  print_eckd_ldl_msg(mode);
@@ -292,15 +292,18 @@ static void ipl_eckd_ldl(ECKD_IPL_mode_t mode)
  memset(sec, FREE_SPACE_FILLER, sizeof(sec));
  read_block(0, sec, "Cannot read block 0 to grab boot info.");
  if (mode == ECKD_LDL_UNLABELED) {
-if (!magic_match(bip->magic, ZIPL_MAGIC)) {
+if (!magic_match(ipl1->boot_info.magic, ZIPL_MAGIC)) {
  return; /* not applicable layout */
  }
  sclp_print("unlabeled LDL.\n");
  }
-verify_boot_info(bip);
+verify_boot_info(&ipl1->boot_info);
+
+/* save pointer to Boot Script */
+mbr_block_nr =
+eckd_block_num((void *)&ipl1->boot_info.bp.ipl.bm_ptr.eckd.bptr);

Well, the original code fitted nicely in one line ... thus maybe better
keep the original variable name? (or use mbr_blk_nr or something similar
shorter?)



Maybe a voidptr to ipl1->boot_info... and pass that to eckd_block_num?
(or something along those lines?)

or

EckdBlockPtr bptr = ipl1->bptr

I'll play with the options.





-block_nr = eckd_block_num((void *)&(bip->bp.ipl.bm_ptr.eckd.bptr));
-run_eckd_boot_script(block_nr);
+run_eckd_boot_script(mbr_block_nr);
  /* no return */
  }

  Thomas




--
- Collin L Walling




[Qemu-devel] [PATCH 3/3] ucontext: annotate coroutine stack for ASAN

2018-01-16 Thread Marc-André Lureau
It helps ASAN to detect more leaks on coroutine stacks, and to get rid
of some extra warnings.

Before:

tests/test-coroutine -p
/basic/lifecycle
/basic/lifecycle: ==20781==WARNING: ASan doesn't fully support
makecontext/swapcontext functions and may produce false positives in
some cases!
==20781==WARNING: ASan is ignoring requested __asan_handle_no_return:
stack top: 0x7ffcb184d000; bottom 0x7ff6c4cfd000; size: 0x0005ecb5
(25446121472)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
OK

After:

tests/test-coroutine -p /basic/lifecycle
/basic/lifecycle: ==21110==WARNING: ASan doesn't fully support
makecontext/swapcontext functions and may produce false positives in
some cases!
OK

A similar work would need to be done for sigaltstack & windows fibers
to have similar coverage. Since ucontext is preferred, I didn't bother
checking the other coroutine implementations for now.

Update travis to fix the build with ASAN annotations.

Signed-off-by: Marc-André Lureau 
---
 include/qemu/compiler.h   |  4 
 util/coroutine-ucontext.c | 48 +++
 .travis.yml   |  3 ++-
 configure | 30 +
 4 files changed, 84 insertions(+), 1 deletion(-)

diff --git a/include/qemu/compiler.h b/include/qemu/compiler.h
index 340e5fdc09..5fcc4f7ec7 100644
--- a/include/qemu/compiler.h
+++ b/include/qemu/compiler.h
@@ -111,4 +111,8 @@
 #define GCC_FMT_ATTR(n, m)
 #endif
 
+#ifndef __has_feature
+#define __has_feature(x) 0 /* compatibility with non-clang compilers */
+#endif
+
 #endif /* COMPILER_H */
diff --git a/util/coroutine-ucontext.c b/util/coroutine-ucontext.c
index 6621f3f692..96af7f5aad 100644
--- a/util/coroutine-ucontext.c
+++ b/util/coroutine-ucontext.c
@@ -31,6 +31,13 @@
 #include 
 #endif
 
+#if defined(__SANITIZE_ADDRESS__) || __has_feature(address_sanitizer)
+#ifdef HAVE_ASAN_IFACE_FIBER
+#define CONFIG_ASAN 1
+#include 
+#endif
+#endif
+
 typedef struct {
 Coroutine base;
 void *stack;
@@ -59,11 +66,37 @@ union cc_arg {
 int i[2];
 };
 
+static void finish_switch_fiber(void *fake_stack_save)
+{
+#ifdef CONFIG_ASAN
+const void *bottom_old;
+size_t size_old;
+
+__sanitizer_finish_switch_fiber(fake_stack_save, &bottom_old, &size_old);
+
+if (!leader.stack) {
+leader.stack = (void *)bottom_old;
+leader.stack_size = size_old;
+}
+#endif
+}
+
+static void start_switch_fiber(void **fake_stack_save,
+   const void *bottom, size_t size)
+{
+#ifdef CONFIG_ASAN
+__sanitizer_start_switch_fiber(fake_stack_save, bottom, size);
+#endif
+}
+
 static void coroutine_trampoline(int i0, int i1)
 {
 union cc_arg arg;
 CoroutineUContext *self;
 Coroutine *co;
+void *fake_stack_save = NULL;
+
+finish_switch_fiber(NULL);
 
 arg.i[0] = i0;
 arg.i[1] = i1;
@@ -72,9 +105,13 @@ static void coroutine_trampoline(int i0, int i1)
 
 /* Initialize longjmp environment and switch back the caller */
 if (!sigsetjmp(self->env, 0)) {
+start_switch_fiber(&fake_stack_save,
+   leader.stack, leader.stack_size);
 siglongjmp(*(sigjmp_buf *)co->entry_arg, 1);
 }
 
+finish_switch_fiber(fake_stack_save);
+
 while (true) {
 co->entry(co->entry_arg);
 qemu_coroutine_switch(co, co->caller, COROUTINE_TERMINATE);
@@ -87,6 +124,7 @@ Coroutine *qemu_coroutine_new(void)
 ucontext_t old_uc, uc;
 sigjmp_buf old_env;
 union cc_arg arg = {0};
+void *fake_stack_save = NULL;
 
 /* The ucontext functions preserve signal masks which incurs a
  * system call overhead.  sigsetjmp(buf, 0)/siglongjmp() does not
@@ -122,8 +160,12 @@ Coroutine *qemu_coroutine_new(void)
 
 /* swapcontext() in, siglongjmp() back out */
 if (!sigsetjmp(old_env, 0)) {
+start_switch_fiber(&fake_stack_save, co->stack, co->stack_size);
 swapcontext(&old_uc, &uc);
 }
+
+finish_switch_fiber(fake_stack_save);
+
 return &co->base;
 }
 
@@ -169,13 +211,19 @@ qemu_coroutine_switch(Coroutine *from_, Coroutine *to_,
 CoroutineUContext *from = DO_UPCAST(CoroutineUContext, base, from_);
 CoroutineUContext *to = DO_UPCAST(CoroutineUContext, base, to_);
 int ret;
+void *fake_stack_save = NULL;
 
 current = to_;
 
 ret = sigsetjmp(from->env, 0);
 if (ret == 0) {
+start_switch_fiber(action == COROUTINE_TERMINATE ?
+   NULL : &fake_stack_save, to->stack, to->stack_size);
 siglongjmp(to->env, action);
 }
+
+finish_switch_fiber(fake_stack_save);
+
 return ret;
 }
 
diff --git a/.travis.yml b/.travis.yml
index f583839755..f2291e87a6 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -13,12 +13,13 @@ addons:
   - libattr1-dev
   - libbrlapi-dev
   - libcap-ng-dev
+  - libgcc-6-dev
   - libgnutls-dev
   - libgtk-3-dev
   - libiscsi-dev

Re: [Qemu-devel] [PATCH 05/11] virtio-ccw: convert VirtIOCCWDeviceClass::init -> realize

2018-01-16 Thread Farhan Ali



On 01/16/2018 09:07 AM, Philippe Mathieu-Daudé wrote:

On 01/16/2018 10:41 AM, Farhan Ali wrote:

shouldn't the commit message say exit -> unrealize?


Oops, indeed :|

Thanks :)

Phil.


Sure, you are welcome :)

With the change in commit message, the patch looks good to me:

Reviewed-by: Farhan Ali 








Thanks
Farhan

On 01/16/2018 08:15 AM, Philippe Mathieu-Daudé wrote:

Signed-off-by: Philippe Mathieu-Daudé 
---
   hw/s390x/virtio-ccw.h |  2 +-
   hw/s390x/virtio-ccw.c | 35 +--
   2 files changed, 18 insertions(+), 19 deletions(-)

diff --git a/hw/s390x/virtio-ccw.h b/hw/s390x/virtio-ccw.h
index 3905f3a3d6..2fc513001e 100644
--- a/hw/s390x/virtio-ccw.h
+++ b/hw/s390x/virtio-ccw.h
@@ -76,7 +76,7 @@ typedef struct VirtioCcwDevice VirtioCcwDevice;
   typedef struct VirtIOCCWDeviceClass {
   CCWDeviceClass parent_class;
   void (*realize)(VirtioCcwDevice *dev, Error **errp);
-    int (*exit)(VirtioCcwDevice *dev);
+    void (*unrealize)(VirtioCcwDevice *dev, Error **errp);
   } VirtIOCCWDeviceClass;

   /* Performance improves when virtqueue kick processing is decoupled
from the
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index 38f6a8afc9..a71c3feeb5 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -751,7 +751,7 @@ out_err:
   g_free(sch);
   }

-static int virtio_ccw_exit(VirtioCcwDevice *dev)
+static void virtio_ccw_unrealize(VirtioCcwDevice *dev, Error **errp)
   {
   CcwDevice *ccw_dev = CCW_DEVICE(dev);
   SubchDev *sch = ccw_dev->sch;
@@ -764,7 +764,6 @@ static int virtio_ccw_exit(VirtioCcwDevice *dev)
   release_indicator(&dev->routes.adapter, dev->indicators);
   dev->indicators = NULL;
   }
-    return 0;
   }

   static void virtio_ccw_net_realize(VirtioCcwDevice *ccw_dev, Error
**errp)
@@ -1343,7 +1342,7 @@ static void
virtio_ccw_net_class_init(ObjectClass *klass, void *data)
   VirtIOCCWDeviceClass *k = VIRTIO_CCW_DEVICE_CLASS(klass);

   k->realize = virtio_ccw_net_realize;
-    k->exit = virtio_ccw_exit;
+    k->unrealize = virtio_ccw_unrealize;
   dc->reset = virtio_ccw_reset;
   dc->props = virtio_ccw_net_properties;
   set_bit(DEVICE_CATEGORY_NETWORK, dc->categories);
@@ -1371,7 +1370,7 @@ static void
virtio_ccw_blk_class_init(ObjectClass *klass, void *data)
   VirtIOCCWDeviceClass *k = VIRTIO_CCW_DEVICE_CLASS(klass);

   k->realize = virtio_ccw_blk_realize;
-    k->exit = virtio_ccw_exit;
+    k->unrealize = virtio_ccw_unrealize;
   dc->reset = virtio_ccw_reset;
   dc->props = virtio_ccw_blk_properties;
   set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
@@ -1399,7 +1398,7 @@ static void
virtio_ccw_serial_class_init(ObjectClass *klass, void *data)
   VirtIOCCWDeviceClass *k = VIRTIO_CCW_DEVICE_CLASS(klass);

   k->realize = virtio_ccw_serial_realize;
-    k->exit = virtio_ccw_exit;
+    k->unrealize = virtio_ccw_unrealize;
   dc->reset = virtio_ccw_reset;
   dc->props = virtio_ccw_serial_properties;
   set_bit(DEVICE_CATEGORY_INPUT, dc->categories);
@@ -1427,7 +1426,7 @@ static void
virtio_ccw_balloon_class_init(ObjectClass *klass, void *data)
   VirtIOCCWDeviceClass *k = VIRTIO_CCW_DEVICE_CLASS(klass);

   k->realize = virtio_ccw_balloon_realize;
-    k->exit = virtio_ccw_exit;
+    k->unrealize = virtio_ccw_unrealize;
   dc->reset = virtio_ccw_reset;
   dc->props = virtio_ccw_balloon_properties;
   set_bit(DEVICE_CATEGORY_MISC, dc->categories);
@@ -1455,7 +1454,7 @@ static void
virtio_ccw_scsi_class_init(ObjectClass *klass, void *data)
   VirtIOCCWDeviceClass *k = VIRTIO_CCW_DEVICE_CLASS(klass);

   k->realize = virtio_ccw_scsi_realize;
-    k->exit = virtio_ccw_exit;
+    k->unrealize = virtio_ccw_unrealize;
   dc->reset = virtio_ccw_reset;
   dc->props = virtio_ccw_scsi_properties;
   set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
@@ -1482,7 +1481,7 @@ static void
vhost_ccw_scsi_class_init(ObjectClass *klass, void *data)
   VirtIOCCWDeviceClass *k = VIRTIO_CCW_DEVICE_CLASS(klass);

   k->realize = vhost_ccw_scsi_realize;
-    k->exit = virtio_ccw_exit;
+    k->unrealize = virtio_ccw_unrealize;
   dc->reset = virtio_ccw_reset;
   dc->props = vhost_ccw_scsi_properties;
   set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
@@ -1519,7 +1518,7 @@ static void
virtio_ccw_rng_class_init(ObjectClass *klass, void *data)
   VirtIOCCWDeviceClass *k = VIRTIO_CCW_DEVICE_CLASS(klass);

   k->realize = virtio_ccw_rng_realize;
-    k->exit = virtio_ccw_exit;
+    k->unrealize = virtio_ccw_unrealize;
   dc->reset = virtio_ccw_reset;
   dc->props = virtio_ccw_rng_properties;
   set_bit(DEVICE_CATEGORY_MISC, dc->categories);
@@ -1557,7 +1556,7 @@ static void
virtio_ccw_crypto_class_init(ObjectClass *klass, void *data)
   VirtIOCCWDeviceClass *k = VIRTIO_CCW_DEVICE_CLASS(klass);

   k->realize = virtio_ccw_crypto_realize;
-    k->exit = virtio_ccw_

Re: [Qemu-devel] [PATCH 1/3] exynos4210: workaround UBSAN compilation error

2018-01-16 Thread Peter Maydell
On 16 January 2018 at 15:11, Marc-André Lureau
 wrote:
> gcc 5.4.0-6ubuntu1~16.04.5 build with UBSAN enabled error:
>
>   CC  hw/display/exynos4210_fimd.o
> /home/petmay01/linaro/qemu-for-merges/hw/display/exynos4210_fimd.c: In
> function ‘fimd_get_buffer_id’:
> /home/petmay01/linaro/qemu-for-merges/hw/display/exynos4210_fimd.c:1105:5:
> error: case label does not reduce to an integer constant
>  case FIMD_WINCON_BUF2_STAT:
>
> Because FIMD_WINCON_BUF2_STAT case contains an integer
> overflow, use U suffix to get the unsigned type.

We should note that this is a gcc bug here (we compile with
-fwrapv so integer overflows like this are well-defined)
which we are working around.

> Signed-off-by: Marc-André Lureau 
> ---
>  hw/display/exynos4210_fimd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/display/exynos4210_fimd.c b/hw/display/exynos4210_fimd.c
> index fd0b2bec65..86e37e93e9 100644
> --- a/hw/display/exynos4210_fimd.c
> +++ b/hw/display/exynos4210_fimd.c
> @@ -98,7 +98,7 @@
>  #define FIMD_WINCON_BUFSTATUS   ((1 << 21) | (1 << 31))
>  #define FIMD_WINCON_BUF0_STAT   ((0 << 21) | (0 << 31))
>  #define FIMD_WINCON_BUF1_STAT   ((1 << 21) | (0 << 31))
> -#define FIMD_WINCON_BUF2_STAT   ((0 << 21) | (1 << 31))
> +#define FIMD_WINCON_BUF2_STAT   ((0 << 21) | (1U << 31))
>  #define FIMD_WINCON_BUFSELECT   ((1 << 20) | (1 << 30))
>  #define FIMD_WINCON_BUF0_SEL((0 << 20) | (0 << 30))
>  #define FIMD_WINCON_BUF1_SEL((1 << 20) | (0 << 30))
> --
> 2.16.0.rc1.1.gef27df75a1
>

thanks
-- PMM



Re: [Qemu-devel] [PULL v4 00/51] Misc patches for 2018-01-12

2018-01-16 Thread no-reply
Hi,

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

Type: series
Message-id: 1516112253-14480-1-git-send-email-pbonz...@redhat.com
Subject: [Qemu-devel] [PULL v4 00/51] Misc patches for 2018-01-12

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

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

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
   f5213b..aae39d24a3  master -> master
 * [new tag]   
patchew/1516112253-14480-1-git-send-email-pbonz...@redhat.com -> 
patchew/1516112253-14480-1-git-send-email-pbonz...@redhat.com
 t [tag update]patchew/20180116134217.8725-1-berra...@redhat.com -> 
patchew/20180116134217.8725-1-berra...@redhat.com
Switched to a new branch 'test'
8d5c19ee59 scripts/analyse-locks-simpletrace.py: script to analyse lock times
028b489871 util/qemu-thread-*: add qemu_lock, locked and unlock trace events
9ce469b8d3 cpu: flush TB cache when loading VMState
4592c6fc6d block/iscsi: fix initialization of iTask in iscsi_co_get_block_status
a7a80362bd find_ram_offset: Align ram_addr_t allocation on long boundaries
c266ee51cb find_ram_offset: Add comments and tracing
5a28d83034 cpu_physical_memory_sync_dirty_bitmap: Another alignment fix
20c5869514 checkpatch: Enforce proper do/while (0) style
dba6450c75 maint: Fix macros with broken 'do/while(0); ' usage
f72687a888 tests: Avoid 'do/while(false); ' in vhost-user-bridge
67da9bdd04 chardev: Clean up previous patch indentation
0b44cbe552 chardev: Use goto/label instead of do/break/while(0)
ea2267eedc mips: Tweak location of ';' in macros
b5c31718fd net: Drop unusual use of do { } while (0);
6d4c84238c irq: fix memory leak
9d097a6f41 cpus: unify qemu_*_wait_io_event
3ad828c271 icount: fixed saving/restoring of icount warp timers
d27d206657 scripts/qemu-gdb/timers.py: new helper to dump timer state
021b13fc18 scripts/qemu-gdb: add simple tcg lock status helper
788d5b6c8e target-i386: update hflags on Hypervisor.framework
2fe60e00e4 target/i386: hax: Move x86_update_hflags.
8bcf5f332d target/i386: hax: change to use x86_update_hflags
abe8ba0b29 target/i386: move hflags update code to a function
d10c944178 tests/boot-serial-test: Add support for the raspi2 machine
88b6c83db5 tests/boot-serial-test: Add a test for the moxiesim machine
1d6145e7dc tests/boot-serial-test: Add tests for microblaze boards
e71edbe725 scsi-disk: release AioContext in unaligned WRITE SAME case
566948dd91 disas/s390: fix global-buffer-overflow
ae42cef294 mips: fix potential fopen(NULL,...)
ca10a2cbd7 tests: fix coroutine leak in /basic/entered
788c04ecb8 tests: fix qmp-test leak
57b28cdb84 qemu-config: fix leak in query-command-line-options
773fc2f2ae crypto: fix stack-buffer-overflow error
4bb5d62a8b readline: add a free function
0b7ad27179 vl: fix direct firmware directories leak
81af850214 tests: fix check-qobject leak
a528620674 tests/docker: add test-debug
ff0f14b5f3 tests/docker: add some sanitizers to fedora dockerfile
1a4bbc821a build-sys: compile with -Og or -O1 when --enable-debug
51296ac14a build-sys: add a rule to print a variable
d632afdb14 build-sys: silence make by default or V=0
5921b3610c build-sys: fix qemu-ga -pthread linking
e8c1a6984a chardev: introduce qemu_chr_timeout_add_ms()
78b11ee7fd chardev: let g_idle_add() be with chardev gcontext
72841e0936 chardev: use backend chr context when watch for fe
6513afa645 i386/cpu/kvm: look at PMU's CPUID before setting MSRs
f21a1e10fc hpet: recover timer offset correctly
9cf6f5f07f pc: fail memory hot-plug/unplug with -no-acpi and Q35 machine type
7fa434aec1 scsi: fix scsi_convert_sense crash when in_buf == NULL && in_len == 0
cdae3dd6aa scsi-generic: Add share-rw option

=== OUTPUT BEGIN ===
Checking PATCH 1/50: scsi-generic: Add share-rw option...
Checking PATCH 2/50: scsi: fix scsi_convert_sense crash when in_buf == NULL && 
in_len == 0...
Checking PATCH 3/50: pc: fail memory hot-plug/unplug with -no-acpi and Q35 
machine type...
Checking PATCH 4/50: hpet: recover timer offset correctly...
Checking PATCH 5/50: i386/cpu/kvm: look at PMU's CPUID before setting MSRs...
Checking PATCH 6/50: chardev: use backend chr context when watch for fe...
Checking PATCH 7/50: chardev: let g_idle_add() be with chardev gcontext...
Checking PATCH 8/50: chardev: introduce qemu_chr_timeout_add_ms()...
Checking PATCH 9/50: build-sys: fix qemu-ga -pthread linking...
Checking PATCH 10/50: build-sys: silence make by default or V=0...
Checking PATCH 11/50: build-sys: add a rule to print a variable...
Checking PATCH 12/5

[Qemu-devel] [PATCH v2 3/4] acpi: implement aml_lless_equal

2018-01-16 Thread Stefan Berger
LLessEqualOp = LNotOp LGreaterOp

Signed-off-by: Stefan Berger 
Reviewed-by: Marc-André Lureau 
Reviewed-by: Igor Mammedov 
---
 hw/acpi/aml-build.c | 11 +++
 include/hw/acpi/aml-build.h |  1 +
 2 files changed, 12 insertions(+)

diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
index 36a6cc4..c475f56 100644
--- a/hw/acpi/aml-build.c
+++ b/hw/acpi/aml-build.c
@@ -568,6 +568,17 @@ Aml *aml_lless(Aml *arg1, Aml *arg2)
 return var;
 }
 
+/* ACPI 1.0b: 16.2.5.4 Type 2 Opcodes Encoding: DefLLessEqual */
+Aml *aml_lless_equal(Aml *arg1, Aml *arg2)
+{
+/* LLessEqualOp := LNotOp LGreaterOp */
+Aml *var = aml_opcode(0x92 /* LNotOp */);
+build_append_byte(var->buf, 0x94 /* LGreaterOp */);
+aml_append(var, arg1);
+aml_append(var, arg2);
+return var;
+}
+
 /* ACPI 1.0b: 16.2.5.4 Type 2 Opcodes Encoding: DefAdd */
 Aml *aml_add(Aml *arg1, Aml *arg2, Aml *dst)
 {
diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
index 88d0738..c4398cc 100644
--- a/include/hw/acpi/aml-build.h
+++ b/include/hw/acpi/aml-build.h
@@ -267,6 +267,7 @@ Aml *aml_lor(Aml *arg1, Aml *arg2);
 Aml *aml_shiftleft(Aml *arg1, Aml *count);
 Aml *aml_shiftright(Aml *arg1, Aml *count, Aml *dst);
 Aml *aml_lless(Aml *arg1, Aml *arg2);
+Aml *aml_lless_equal(Aml *arg1, Aml *arg2);
 Aml *aml_add(Aml *arg1, Aml *arg2, Aml *dst);
 Aml *aml_subtract(Aml *arg1, Aml *arg2, Aml *dst);
 Aml *aml_increment(Aml *arg);
-- 
2.5.5




Re: [Qemu-devel] [PATCH x86-next v2] target-i386: add PCID flag to Westmere, Sandy Bridge and Ivy Bridge

2018-01-16 Thread Kashyap Chamarthy
On Tue, Jan 16, 2018 at 01:55:22PM +0100, Vincent Bernat wrote:
>  ❦ 16 janvier 2018 10:41 -0200, Eduardo Habkost  :
> 
> >> > Adding Westmere-PCID would require adding a Westmere-PCID-IBRS
> >> > CPU model too, so this is starting to look a bit ridiculous.
> >> > Sane VM management systems would know how to use
> >> > "-cpu Westmere,+pcid" without requiring new CPU model entries in
> >> > QEMU.  What's missing in existing management stacks to allow that
> >> > to happen?
> >> 
> >> That's what I actually do. So, I am fine with the solution of doing
> >> nothing. However, it would be nice for unaware people to get the speedup
> >> of pcid without knowing about it. Maybe we can just forget about
> >> Westmere and still apply it to Sandy Bridge and Ivy Bridge.
> >
> > If management stacks today don't let the user choose
> > "Westmere,+pcid", we probably have no other choice than adding a
> > Westmere-PCID CPU model.  But our management stacks need to be
> > fixed so we won't need similar hacks in the future.

True;  I'm aware of the limitation here in Nova.

> With libvirt:
> 
>   
> Westmere
> 
>   

Yep, libvirt upstream allows it.

> We are using CloudStack on top of that and it's also an available
> option. However, looking at OpenStack, it doesn't seem possible:
>  
> https://github.com/openstack/nova/blob/6b248518da794a4c82665c22abf7bee5aa527a47/nova/conf/libvirt.py#L506

That's correct, upstream OpenStack Nova doesn't yet have facility to
specify granular CPU feature names.  Nova just ought to wire up the
facility libvirt already provides.

-- 
/kashyap



Re: [Qemu-devel] [PATCH v6 8/9] qcow2: skip writing zero buffers to empty COW areas

2018-01-16 Thread Alberto Garcia
On Tue 16 Jan 2018 02:04:29 PM CET, Anton Nefedov wrote:

> iotest 060:
> write to the discarded cluster does not trigger COW anymore.
> so, break on write_aio event instead, will work for the test
> (but write won't fail anymore, so update reference output)

I'm wondering about this. The reason why the write doesn't fail anymore
is because after this patch we're breaking in write_aio as you say:

   BLKDBG_EVENT(bs->file, BLKDBG_WRITE_AIO);
   trace_qcow2_writev_data(qemu_coroutine_self(),
   cluster_offset + offset_in_cluster);
   ret = bdrv_co_pwritev(bs->file,
 cluster_offset + offset_in_cluster,
 cur_bytes, &hd_qiov, 0);

When the image is marked as corrupted then bs->drv is set to NULL, but
bs->file->drv is still valid. So QEMU goes forward and writes into the
image.

Should we check bs->drv after BLKDBG_EVENT() or perhaps set
bs->file->bs->drv = NULL when an image is corrupted?

> +static bool is_zero_cow(BlockDriverState *bs, QCowL2Meta *m)
> +{
> +if (bs->encrypted) {
> +return false;
> +}

I found this a bit confusing because is_zero_cow() can be interpreted as
"the region we're going to copy only contains zeroes" or "we're only
going to write zeroes".

In the first case the bs->encrypted test does not belong there, because
that region may perfectly well contain only zeroes and bs->encrypted
tells us nothing about it.

In the second case the test is fine because bs->encrypted means that
we're definitely going to write something other than zeroes.

I think it's worth adding a comment clarifying this in order to avoid
confusion, or perhaps renaming the function to make it more explicit
(cow_writes_as_zeroes() or something like that).

> +static void handle_alloc_space(BlockDriverState *bs, QCowL2Meta *l2meta)
> +{
> +BDRVQcow2State *s = bs->opaque;
> +QCowL2Meta *m;
> +
> +for (m = l2meta; m != NULL; m = m->next) {
> +int ret;
> +
> +if (!m->cow_start.nb_bytes && !m->cow_end.nb_bytes) {
> +continue;
> +}
> +
> +if (!is_zero_cow(bs, m)) {
> +continue;
> +}
> +
> +/* instead of writing zero COW buffers,
> +   efficiently zero out the whole clusters */
> +ret = bdrv_co_pwrite_zeroes(bs->file, m->alloc_offset,
> +m->nb_clusters * s->cluster_size,
> +BDRV_REQ_ALLOCATE);
> +if (ret < 0) {
> +continue;
> +}

Is it always fine to simply ignore the error and go on?

> --- a/tests/qemu-iotests/060
> +++ b/tests/qemu-iotests/060
> @@ -160,7 +160,7 @@ poke_file "$TEST_IMG" '131084' "\x00\x00" # 0x2000c
>  # any unallocated cluster, leading to an attempt to overwrite the second L2
>  # table. Finally, resume the COW write and see it fail (but not crash).
>  echo "open -o file.driver=blkdebug $TEST_IMG
> -break cow_read 0
> +break write_aio 0
>  aio_write 0k 1k
>  wait_break 0
>  write 64k 64k

Apart from what I wrote in the beginning of the e-mail, if you're
changing the semantics of this test you should also update the
comment. With your patch the COW no longer stops before doing the read,
and after being resumed it no longer crashes.

Berto



Re: [Qemu-devel] [PATCH v2 3/4] acpi: implement aml_lless_equal

2018-01-16 Thread Michael S. Tsirkin
On Tue, Jan 16, 2018 at 10:51:39AM -0500, Stefan Berger wrote:
> LLessEqualOp = LNotOp LGreaterOp
> 
> Signed-off-by: Stefan Berger 
> Reviewed-by: Marc-André Lureau 
> Reviewed-by: Igor Mammedov 

Reviewed-by: Michael S. Tsirkin 

> ---
>  hw/acpi/aml-build.c | 11 +++
>  include/hw/acpi/aml-build.h |  1 +
>  2 files changed, 12 insertions(+)
> 
> diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
> index 36a6cc4..c475f56 100644
> --- a/hw/acpi/aml-build.c
> +++ b/hw/acpi/aml-build.c
> @@ -568,6 +568,17 @@ Aml *aml_lless(Aml *arg1, Aml *arg2)
>  return var;
>  }
>  
> +/* ACPI 1.0b: 16.2.5.4 Type 2 Opcodes Encoding: DefLLessEqual */
> +Aml *aml_lless_equal(Aml *arg1, Aml *arg2)
> +{
> +/* LLessEqualOp := LNotOp LGreaterOp */
> +Aml *var = aml_opcode(0x92 /* LNotOp */);
> +build_append_byte(var->buf, 0x94 /* LGreaterOp */);
> +aml_append(var, arg1);
> +aml_append(var, arg2);
> +return var;
> +}
> +
>  /* ACPI 1.0b: 16.2.5.4 Type 2 Opcodes Encoding: DefAdd */
>  Aml *aml_add(Aml *arg1, Aml *arg2, Aml *dst)
>  {
> diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
> index 88d0738..c4398cc 100644
> --- a/include/hw/acpi/aml-build.h
> +++ b/include/hw/acpi/aml-build.h
> @@ -267,6 +267,7 @@ Aml *aml_lor(Aml *arg1, Aml *arg2);
>  Aml *aml_shiftleft(Aml *arg1, Aml *count);
>  Aml *aml_shiftright(Aml *arg1, Aml *count, Aml *dst);
>  Aml *aml_lless(Aml *arg1, Aml *arg2);
> +Aml *aml_lless_equal(Aml *arg1, Aml *arg2);
>  Aml *aml_add(Aml *arg1, Aml *arg2, Aml *dst);
>  Aml *aml_subtract(Aml *arg1, Aml *arg2, Aml *dst);
>  Aml *aml_increment(Aml *arg);
> -- 
> 2.5.5



Re: [Qemu-devel] [PATCH 0/3 v2] virtio: improve virtio devices initialization time

2018-01-16 Thread Kinsella, Ray

Hi Gal,

Brilliant - will test this in the next day or two.
Hopefully this will help resolve the issues I reported last summer.

http://lists.nongnu.org/archive/html/qemu-devel/2017-07/msg05268.html

Ray K

On 14/01/2018 10:06, Gal Hammer wrote:

A bug was reported about a very slow boot time and a 100% CPU usage of
both Windows and Linux guests when running a VM with multiple
virtio-serial devices (https://bugzilla.redhat.com/1528588).

For example, running a VM with 25 virtio-serial devices, each one with
max_ports=511, could have a boot time of around 30 minutes. With this
patch (and another patch to kvm) the boot time is reduced to
approximately 3 minutes.

The patch wraps all the changes made to the Memory Regions during the
eventfd registrations in a memory regions transaction. I had to add a
cleanup callback function to the EventNotifier struct, so it will be
possible to use a transaction in the shutdown code path as well.

Gal Hammer (3):
   qemu: add a cleanup callback function to EventNotifier
   virtio: postpone the execution of event_notifier_cleanup function
   virtio: improve virtio devices initialization time

  accel/kvm/kvm-all.c   |  4 
  hw/virtio/virtio-bus.c| 19 +++
  hw/virtio/virtio.c|  5 +
  include/qemu/event_notifier.h |  1 +
  util/event_notifier-posix.c   |  5 -
  util/event_notifier-win32.c   |  2 ++
  6 files changed, 27 insertions(+), 9 deletions(-)






Re: [Qemu-devel] [PATCH v2 2/4] acpi: build QEMU table for PPI virtual memory device

2018-01-16 Thread Michael S. Tsirkin
On Tue, Jan 16, 2018 at 10:51:38AM -0500, Stefan Berger wrote:
> To avoid having to hard code the base address of the PPI virtual memory
> device we introduce a QEMU ACPI table that holds the base address, if a
> TPM 1.2 or 2 is used. This table gives us flexibility to move the base
> address later on.
> 
> Signed-off-by: Stefan Berger 
> ---
>  hw/i386/acpi-build.c| 19 +++
>  include/hw/acpi/acpi-defs.h |  8 
>  2 files changed, 27 insertions(+)
> 
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index 18b939e..522d6d2 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -2628,6 +2628,20 @@ static bool acpi_get_mcfg(AcpiMcfgInfo *mcfg)
>  return true;
>  }
>  
> +static void build_qemu(GArray *table_data, BIOSLinker *linker,
> +   TPMVersion tpm_version)
> +{
> +AcpiTableQemu *qemu = acpi_data_push(table_data, sizeof(*qemu));
> +
> +if (tpm_version != TPM_VERSION_UNSPEC) {
> +qemu->tpmppi_addr = TPM_PPI_ADDR_BASE;
> +qemu->tpm_version = tpm_version;
> +}
> +
> +build_header(linker, table_data,
> + (void *)qemu, "QEMU", sizeof(*qemu), 1, "QEMU", "CONF");
> +}
> +
>  static
>  void acpi_build(AcpiBuildTables *tables, MachineState *machine)
>  {
> @@ -2734,6 +2748,11 @@ void acpi_build(AcpiBuildTables *tables, MachineState 
> *machine)
>&pcms->acpi_nvdimm_state, machine->ram_slots);
>  }
>  
> +if (misc.tpm_version != TPM_VERSION_UNSPEC) {
> +acpi_add_table(table_offsets, tables_blob);
> +build_qemu(tables_blob, tables->linker, misc.tpm_version);
> +}
> +
>  /* Add tables supplied by user (if any) */
>  for (u = acpi_table_first(); u; u = acpi_table_next(u)) {
>  unsigned len = acpi_table_len(u);
> diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
> index 80c8099..98764c1 100644
> --- a/include/hw/acpi/acpi-defs.h
> +++ b/include/hw/acpi/acpi-defs.h
> @@ -573,6 +573,14 @@ struct Acpi20TPM2 {
>  } QEMU_PACKED;
>  typedef struct Acpi20TPM2 Acpi20TPM2;
>  
> +/* QEMU - Custom QEMU table */
> +struct AcpiTableQemu {
> +ACPI_TABLE_HEADER_DEF

Since we already have an 8 byte QEMU table due to patching of MCFG
(which we should drop eventually I think) I think it's a good idea to
reserve the first 8 bytes here after the header.


> +uint32_t tpmppi_addr;
> +uint8_t tpm_version; /* 1 = 1.2, 2 = 2 */

There are 3 bytes of padding here. Pls make them explicit
as a reserved field.

> +};
> +typedef struct AcpiTableQemu AcpiTableQemu;
> +

>  /* DMAR - DMA Remapping table r2.2 */
>  struct AcpiTableDmar {
>  ACPI_TABLE_HEADER_DEF
> -- 
> 2.5.5



Re: [Qemu-devel] [PATCH v3 0/4] cryptodev: add vhost support

2018-01-16 Thread Michael S. Tsirkin
On Tue, Jan 16, 2018 at 02:21:32PM +, Zhoujian (jay) wrote:
> VHOST_USER_CREATE_CRYPTO_SESSION and VHOST_USER_CLOSE_CRYPTO_SESSION are new
> added messages, they should be sent only when
> VHOST_USER_PROTOCOL_F_CRYPTO_SESSION feature has been successfully negotiated.
> 
> The differs between v2 and v3 are listed below, pls review, thanks!
> 
> ---
> diff --git a/docs/interop/vhost-user.txt b/docs/interop/vhost-user.txt
> index f43c63d..3aec685 100644
> --- a/docs/interop/vhost-user.txt
> +++ b/docs/interop/vhost-user.txt
> @@ -327,6 +327,7 @@ Protocol features
>  #define VHOST_USER_PROTOCOL_F_MTU4
>  #define VHOST_USER_PROTOCOL_F_SLAVE_REQ  5
>  #define VHOST_USER_PROTOCOL_F_CROSS_ENDIAN   6
> +#define VHOST_USER_PROTOCOL_F_CRYPTO_SESSION 7
>  
>  Master message types
>  
> @@ -605,6 +606,9 @@ Master message types
>  
>Create a session for crypto operation. The server side must return the
>session id, 0 or positive for success, negative for failure.
> +  This request should be sent only when 
> VHOST_USER_PROTOCOL_F_CRYPTO_SESSION
> +  feature has been successfully negotiated.
> +  It's a required feature for crypto devices.
>  
>   * VHOST_USER_CLOSE_CRYPTO_SESSION
>  
> @@ -614,6 +618,9 @@ Master message types
>  
>Close a session for crypto operation which was previously
>created by VHOST_USER_CREATE_CRYPTO_SESSION.
> +  This request should be sent only when 
> VHOST_USER_PROTOCOL_F_CRYPTO_SESSION
> +  feature has been successfully negotiated.
> +  It's a required feature for crypto devices.
>  
>  Slave message types
>  ---
> diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
> index 7865c6d..f779512 100644
> --- a/hw/virtio/vhost-user.c
> +++ b/hw/virtio/vhost-user.c
> @@ -35,6 +35,7 @@ enum VhostUserProtocolFeature {
>  VHOST_USER_PROTOCOL_F_NET_MTU = 4,
>  VHOST_USER_PROTOCOL_F_SLAVE_REQ = 5,
>  VHOST_USER_PROTOCOL_F_CROSS_ENDIAN = 6,
> +VHOST_USER_PROTOCOL_F_CRYPTO_SESSION = 7,
>  
>  VHOST_USER_PROTOCOL_F_MAX
>  };
> @@ -941,6 +942,8 @@ static int vhost_user_crypto_create_session(struct 
> vhost_dev *dev,
>void *session_info,
>uint64_t *session_id)
>  {
> +bool crypto_session = virtio_has_feature(dev->protocol_features,
> +   VHOST_USER_PROTOCOL_F_CRYPTO_SESSION);
>  CryptoDevBackendSymSessionInfo *sess_info = session_info;
>  VhostUserMsg msg = {
>  .request = VHOST_USER_CREATE_CRYPTO_SESSION,
> @@ -950,6 +953,11 @@ static int vhost_user_crypto_create_session(struct 
> vhost_dev *dev,
>  
>  assert(dev->vhost_ops->backend_type == VHOST_BACKEND_TYPE_USER);
>  
> +if (!crypto_session) {
> +error_report("vhost-user trying to send unhandled ioctl");
> +return -1;
> +}
> +
>  memcpy(&msg.payload.session.session_setup_data, sess_info,
>sizeof(CryptoDevBackendSymSessionInfo));
>  if (sess_info->key_len) {
> @@ -994,6 +1002,8 @@ static int vhost_user_crypto_create_session(struct 
> vhost_dev *dev,
>  static int
>  vhost_user_crypto_close_session(struct vhost_dev *dev, uint64_t session_id)
>  {
> +bool crypto_session = virtio_has_feature(dev->protocol_features,
> +   VHOST_USER_PROTOCOL_F_CRYPTO_SESSION);
>  VhostUserMsg msg = {
>  .request = VHOST_USER_CLOSE_CRYPTO_SESSION,
>  .flags = VHOST_USER_VERSION,
> @@ -1001,6 +1011,11 @@ vhost_user_crypto_close_session(struct vhost_dev *dev, 
> uint64_t session_id)
>  };
>  msg.payload.u64 = session_id;
>  
> +if (!crypto_session) {
> +error_report("vhost-user trying to send unhandled ioctl");
> +return -1;
> +}
> +
>  if (vhost_user_write(dev, &msg, NULL, 0) < 0) {
>  error_report("vhost_user_write() return -1, close session failed");
>  return -1;
> 

Documentation and error messages could be improved, but I think this
is reasonable enough to put upstream and improve on top.


> > -Original Message-
> > From: Zhoujian (jay)
> > Sent: Tuesday, January 16, 2018 10:07 PM
> > To: qemu-devel@nongnu.org
> > Cc: m...@redhat.com; pbonz...@redhat.com; Huangweidong (C)
> > ; stefa...@redhat.com; Zhoujian (jay)
> > ; pa...@linux.vnet.ibm.com; longpeng
> > ; xin.z...@intel.com; roy.fan.zh...@intel.com; Gonglei
> > (Arei) 
> > Subject: [PATCH v3 0/4] cryptodev: add vhost support
> > 
> > From: Gonglei 
> > 
> > I posted the RFC verion a few months ago for DPDK vhost-crypto implmention,
> > and now it's time to send the formal version. Because we need an user space
> > scheme for better performance.
> > 
> > The vhost user crypto server side patches had been sent to DPDK community,
> > pls see
> > 
> > [RFC PATCH 0/6] lib/librte_vhost: introduce new vhost_user crypto backend
> > support http://dpdk.org/ml/archives/dev/2017-November/081048.html
> > 

Re: [Qemu-devel] [PATCH v3 1/4] cryptodev: add vhost-user as a new cryptodev backend

2018-01-16 Thread Michael S. Tsirkin
On Tue, Jan 16, 2018 at 10:06:50PM +0800, Jay Zhou wrote:
> From: Gonglei 
> 
> Usage:
>  -chardev socket,id=charcrypto0,path=/path/to/your/socket
>  -object cryptodev-vhost-user,id=cryptodev0,chardev=charcrypto0
>  -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0
> 
> Signed-off-by: Gonglei 
> Signed-off-by: Longpeng(Mike) 
> Signed-off-by: Jay Zhou 
> ---
>  backends/Makefile.objs   |   4 +
>  backends/cryptodev-vhost-user.c  | 333 
> +++
>  backends/cryptodev-vhost.c   |  73 +
>  include/sysemu/cryptodev-vhost.h | 154 ++
>  qemu-options.hx  |  21 +++
>  vl.c |   4 +
>  6 files changed, 589 insertions(+)
>  create mode 100644 backends/cryptodev-vhost-user.c
>  create mode 100644 backends/cryptodev-vhost.c
>  create mode 100644 include/sysemu/cryptodev-vhost.h
> 
> diff --git a/backends/Makefile.objs b/backends/Makefile.objs
> index 0400799..9e1fb76 100644
> --- a/backends/Makefile.objs
> +++ b/backends/Makefile.objs
> @@ -8,3 +8,7 @@ common-obj-$(CONFIG_LINUX) += hostmem-file.o
>  
>  common-obj-y += cryptodev.o
>  common-obj-y += cryptodev-builtin.o
> +
> +ifeq ($(CONFIG_VIRTIO),y)
> +common-obj-$(CONFIG_LINUX) += cryptodev-vhost.o cryptodev-vhost-user.o
> +endif

Shouldn't this depend on CONFIG_VHOST_USER?


> diff --git a/backends/cryptodev-vhost-user.c b/backends/cryptodev-vhost-user.c
> new file mode 100644
> index 000..4e63ece
> --- /dev/null
> +++ b/backends/cryptodev-vhost-user.c
> @@ -0,0 +1,333 @@
> +/*
> + * QEMU Cryptodev backend for QEMU cipher APIs
> + *
> + * Copyright (c) 2016 HUAWEI TECHNOLOGIES CO., LTD.
> + *
> + * Authors:
> + *Gonglei 
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, see 
> .
> + *
> + */
> +
> +#include "qemu/osdep.h"
> +#include "hw/boards.h"
> +#include "qapi/error.h"
> +#include "qapi/qmp/qerror.h"
> +#include "qemu/error-report.h"
> +#include "standard-headers/linux/virtio_crypto.h"
> +#include "sysemu/cryptodev-vhost.h"
> +#include "chardev/char-fe.h"
> +
> +
> +/**
> + * @TYPE_CRYPTODEV_BACKEND_VHOST_USER:
> + * name of backend that uses vhost user server
> + */
> +#define TYPE_CRYPTODEV_BACKEND_VHOST_USER "cryptodev-vhost-user"
> +
> +#define CRYPTODEV_BACKEND_VHOST_USER(obj) \
> +OBJECT_CHECK(CryptoDevBackendVhostUser, \
> + (obj), TYPE_CRYPTODEV_BACKEND_VHOST_USER)
> +
> +
> +typedef struct CryptoDevBackendVhostUser {
> +CryptoDevBackend parent_obj;
> +
> +CharBackend chr;
> +char *chr_name;
> +bool opened;
> +CryptoDevBackendVhost *vhost_crypto[MAX_CRYPTO_QUEUE_NUM];
> +} CryptoDevBackendVhostUser;
> +
> +static int
> +cryptodev_vhost_user_running(
> + CryptoDevBackendVhost *crypto)
> +{
> +return crypto ? 1 : 0;
> +}
> +
> +static void cryptodev_vhost_user_stop(int queues,
> +  CryptoDevBackendVhostUser *s)
> +{
> +size_t i;
> +
> +for (i = 0; i < queues; i++) {
> +if (!cryptodev_vhost_user_running(s->vhost_crypto[i])) {
> +continue;
> +}
> +
> +if (s->vhost_crypto) {
> +cryptodev_vhost_cleanup(s->vhost_crypto[i]);
> +s->vhost_crypto[i] = NULL;
> +}
> +}
> +}
> +
> +static int
> +cryptodev_vhost_user_start(int queues,
> + CryptoDevBackendVhostUser *s)
> +{
> +CryptoDevBackendVhostOptions options;
> +CryptoDevBackend *b = CRYPTODEV_BACKEND(s);
> +int max_queues;
> +size_t i;
> +
> +for (i = 0; i < queues; i++) {
> +if (cryptodev_vhost_user_running(s->vhost_crypto[i])) {
> +continue;
> +}
> +
> +options.opaque = &s->chr;
> +options.backend_type = VHOST_BACKEND_TYPE_USER;
> +options.cc = b->conf.peers.ccs[i];
> +s->vhost_crypto[i] = cryptodev_vhost_init(&options);
> +if (!s->vhost_crypto[i]) {
> +error_report("failed to init vhost_crypto for queue %lu", i);
> +goto err;
> +}
> +
> +if (i == 0) {
> +max_queues =
> +  cryptodev_vhost_get_max_queues(s->vhost_crypto[i]);
> +if (queues > max_queues) {
> +error_report("you are asking more queues than supported: %d",
> + max_queues);
> +goto er

[Qemu-devel] [PULL v2 3/4] tcg/ppc: Support tlb offsets larger than 64k

2018-01-16 Thread Richard Henderson
AArch64 with SVE has an offset of 80k to the 8th TLB.

Signed-off-by: Richard Henderson 
---
 tcg/ppc/tcg-target.inc.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/tcg/ppc/tcg-target.inc.c b/tcg/ppc/tcg-target.inc.c
index 879885b68b..74f9b4aa34 100644
--- a/tcg/ppc/tcg-target.inc.c
+++ b/tcg/ppc/tcg-target.inc.c
@@ -1524,16 +1524,15 @@ static TCGReg tcg_out_tlb_read(TCGContext *s, TCGMemOp 
opc,
 
 /* Compensate for very large offsets.  */
 if (add_off >= 0x8000) {
-/* Most target env are smaller than 32k; none are larger than 64k.
-   Simplify the logic here merely to offset by 0x7ff0, giving us a
-   range just shy of 64k.  Check this assumption.  */
-QEMU_BUILD_BUG_ON(offsetof(CPUArchState,
-   tlb_table[NB_MMU_MODES - 1][1])
-  > 0x7ff0 + 0x7fff);
-tcg_out32(s, ADDI | TAI(TCG_REG_TMP1, base, 0x7ff0));
+int low = (int16_t)cmp_off;
+int high = cmp_off - low;
+assert((high & 0x) == 0);
+assert(cmp_off - high == (int16_t)(cmp_off - high));
+assert(add_off - high == (int16_t)(add_off - high));
+tcg_out32(s, ADDIS | TAI(TCG_REG_TMP1, base, high >> 16));
 base = TCG_REG_TMP1;
-cmp_off -= 0x7ff0;
-add_off -= 0x7ff0;
+cmp_off -= high;
+add_off -= high;
 }
 
 /* Extraction and shifting, part 2.  */
-- 
2.14.3




[Qemu-devel] [PULL v2 1/4] tcg/arm: Fix double-word comparisons

2018-01-16 Thread Richard Henderson
The code sequence we were generating was only good for unsigned
comparisons.  For signed comparisions, use the sequence from gcc.

Fixes booting of ppc64 firmware, with a patch changing the code
sequence for ppc comparisons.

Tested-by: Michael Roth 
Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 tcg/arm/tcg-target.inc.c | 86 +---
 1 file changed, 60 insertions(+), 26 deletions(-)

diff --git a/tcg/arm/tcg-target.inc.c b/tcg/arm/tcg-target.inc.c
index 98a12535a5..d7b09e8e0c 100644
--- a/tcg/arm/tcg-target.inc.c
+++ b/tcg/arm/tcg-target.inc.c
@@ -1103,6 +1103,56 @@ static inline void tcg_out_mb(TCGContext *s, TCGArg a0)
 }
 }
 
+static TCGCond tcg_out_cmp2(TCGContext *s, const TCGArg *args,
+const int *const_args)
+{
+TCGReg al = args[0];
+TCGReg ah = args[1];
+TCGArg bl = args[2];
+TCGArg bh = args[3];
+TCGCond cond = args[4];
+int const_bl = const_args[2];
+int const_bh = const_args[3];
+
+switch (cond) {
+case TCG_COND_EQ:
+case TCG_COND_NE:
+case TCG_COND_LTU:
+case TCG_COND_LEU:
+case TCG_COND_GTU:
+case TCG_COND_GEU:
+/* We perform a conditional comparision.  If the high half is
+   equal, then overwrite the flags with the comparison of the
+   low half.  The resulting flags cover the whole.  */
+tcg_out_dat_rI(s, COND_AL, ARITH_CMP, 0, ah, bh, const_bh);
+tcg_out_dat_rI(s, COND_EQ, ARITH_CMP, 0, al, bl, const_bl);
+return cond;
+
+case TCG_COND_LT:
+case TCG_COND_GE:
+/* We perform a double-word subtraction and examine the result.
+   We do not actually need the result of the subtract, so the
+   low part "subtract" is a compare.  For the high half we have
+   no choice but to compute into a temporary.  */
+tcg_out_dat_rI(s, COND_AL, ARITH_CMP, 0, al, bl, const_bl);
+tcg_out_dat_rI(s, COND_AL, ARITH_SBC | TO_CPSR,
+   TCG_REG_TMP, ah, bh, const_bh);
+return cond;
+
+case TCG_COND_LE:
+case TCG_COND_GT:
+/* Similar, but with swapped arguments, via reversed subtract.  */
+tcg_out_dat_rI(s, COND_AL, ARITH_RSB | TO_CPSR,
+   TCG_REG_TMP, al, bl, const_bl);
+tcg_out_dat_rI(s, COND_AL, ARITH_RSC | TO_CPSR,
+   TCG_REG_TMP, ah, bh, const_bh);
+return tcg_swap_cond(cond);
+
+default:
+g_assert_not_reached();
+}
+}
+
 #ifdef CONFIG_SOFTMMU
 #include "tcg-ldst.inc.c"
 
@@ -1964,22 +2014,6 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode 
opc,
 tcg_out_goto_label(s, tcg_cond_to_arm_cond[args[2]],
arg_label(args[3]));
 break;
-case INDEX_op_brcond2_i32:
-/* The resulting conditions are:
- * TCG_COND_EQ-->  a0 == a2 && a1 == a3,
- * TCG_COND_NE--> (a0 != a2 && a1 == a3) ||  a1 != a3,
- * TCG_COND_LT(U) --> (a0 <  a2 && a1 == a3) ||  a1 <  a3,
- * TCG_COND_GE(U) --> (a0 >= a2 && a1 == a3) || (a1 >= a3 && a1 != a3),
- * TCG_COND_LE(U) --> (a0 <= a2 && a1 == a3) || (a1 <= a3 && a1 != a3),
- * TCG_COND_GT(U) --> (a0 >  a2 && a1 == a3) ||  a1 >  a3,
- */
-tcg_out_dat_rIN(s, COND_AL, ARITH_CMP, ARITH_CMN, 0,
-args[1], args[3], const_args[3]);
-tcg_out_dat_rIN(s, COND_EQ, ARITH_CMP, ARITH_CMN, 0,
-args[0], args[2], const_args[2]);
-tcg_out_goto_label(s, tcg_cond_to_arm_cond[args[4]],
-   arg_label(args[5]));
-break;
 case INDEX_op_setcond_i32:
 tcg_out_dat_rIN(s, COND_AL, ARITH_CMP, ARITH_CMN, 0,
 args[1], args[2], const_args[2]);
@@ -1988,15 +2022,15 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode 
opc,
 tcg_out_dat_imm(s, tcg_cond_to_arm_cond[tcg_invert_cond(args[3])],
 ARITH_MOV, args[0], 0, 0);
 break;
+
+case INDEX_op_brcond2_i32:
+c = tcg_out_cmp2(s, args, const_args);
+tcg_out_goto_label(s, tcg_cond_to_arm_cond[c], arg_label(args[5]));
+break;
 case INDEX_op_setcond2_i32:
-/* See brcond2_i32 comment */
-tcg_out_dat_rIN(s, COND_AL, ARITH_CMP, ARITH_CMN, 0,
-args[2], args[4], const_args[4]);
-tcg_out_dat_rIN(s, COND_EQ, ARITH_CMP, ARITH_CMN, 0,
-args[1], args[3], const_args[3]);
-tcg_out_dat_imm(s, tcg_cond_to_arm_cond[args[5]],
-ARITH_MOV, args[0], 0, 1);
-tcg_out_dat_imm(s, tcg_cond_to_arm_cond[tcg_invert_cond(args[5])],
+c = tcg_out_cmp2(s, args + 1, const_args + 1);
+tcg_out_dat_imm(s, tcg_cond_to_arm_cond[c], ARITH_MOV, args[0], 0, 1);
+tcg_out_dat_imm(s, tcg_cond_to_arm_cond[tcg_invert_cond(c)],
 ARITH_MOV, args[0], 0, 0);
 bre

[Qemu-devel] [PULL v2 2/4] tcg/arm: Support tlb offsets larger than 64k

2018-01-16 Thread Richard Henderson
AArch64 with SVE has an offset of 80k to the 8th TLB.

Signed-off-by: Richard Henderson 
---
 tcg/arm/tcg-target.inc.c | 30 +-
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/tcg/arm/tcg-target.inc.c b/tcg/arm/tcg-target.inc.c
index d7b09e8e0c..dc83f3e5be 100644
--- a/tcg/arm/tcg-target.inc.c
+++ b/tcg/arm/tcg-target.inc.c
@@ -1247,12 +1247,6 @@ static TCGReg tcg_out_arg_reg64(TCGContext *s, TCGReg 
argreg,
 /* We're expecting to use an 8-bit immediate and to mask.  */
 QEMU_BUILD_BUG_ON(CPU_TLB_BITS > 8);
 
-/* We're expecting to use an 8-bit immediate add + 8-bit ldrd offset.
-   Using the offset of the second entry in the last tlb table ensures
-   that we can index all of the elements of the first entry.  */
-QEMU_BUILD_BUG_ON(offsetof(CPUArchState, tlb_table[NB_MMU_MODES - 1][1])
-  > 0x);
-
 /* Load and compare a TLB entry, leaving the flags set.  Returns the register
containing the addend of the tlb entry.  Clobbers R0, R1, R2, TMP.  */
 
@@ -1265,6 +1259,7 @@ static TCGReg tcg_out_tlb_read(TCGContext *s, TCGReg 
addrlo, TCGReg addrhi,
  ? offsetof(CPUArchState, tlb_table[mem_index][0].addr_read)
  : offsetof(CPUArchState, tlb_table[mem_index][0].addr_write));
 int add_off = offsetof(CPUArchState, tlb_table[mem_index][0].addend);
+int mask_off;
 unsigned s_bits = opc & MO_SIZE;
 unsigned a_bits = get_alignment_bits(opc);
 
@@ -1296,16 +1291,25 @@ static TCGReg tcg_out_tlb_read(TCGContext *s, TCGReg 
addrlo, TCGReg addrhi,
 0, addrlo, SHIFT_IMM_LSR(TARGET_PAGE_BITS));
 }
 
-/* We checked that the offset is contained within 16 bits above.  */
-if (add_off > 0xfff
-|| (use_armv6_instructions && TARGET_LONG_BITS == 64
-&& cmp_off > 0xff)) {
+/* Add portions of the offset until the memory access is in range.
+ * If we plan on using ldrd, reduce to an 8-bit offset; otherwise
+ * we can use a 12-bit offset.  */
+if (use_armv6_instructions && TARGET_LONG_BITS == 64) {
+mask_off = 0xff;
+} else {
+mask_off = 0xfff;
+}
+while (cmp_off > mask_off) {
+int shift = ctz32(cmp_off & ~mask_off) & ~1;
+int rot = ((32 - shift) << 7) & 0xf00;
+int addend = cmp_off & (0xff << shift);
 tcg_out_dat_imm(s, COND_AL, ARITH_ADD, TCG_REG_R2, base,
-(24 << 7) | (cmp_off >> 8));
+rot | ((cmp_off >> shift) & 0xff));
 base = TCG_REG_R2;
-add_off -= cmp_off & 0xff00;
-cmp_off &= 0xff;
+add_off -= addend;
+cmp_off -= addend;
 }
+
 if (!use_armv7_instructions) {
 tcg_out_dat_imm(s, COND_AL, ARITH_AND,
 TCG_REG_R0, TCG_REG_TMP, CPU_TLB_SIZE - 1);
-- 
2.14.3




[Qemu-devel] [PULL v2 4/4] tcg/ppc: Allow a 32-bit offset to the constant pool

2018-01-16 Thread Richard Henderson
We recently relaxed the limit of the number of opcodes that can
appear in a TranslationBlock.  In certain cases this has resulted
in relocation overflow.

Signed-off-by: Richard Henderson 
---
 tcg/ppc/tcg-target.inc.c | 67 
 1 file changed, 39 insertions(+), 28 deletions(-)

diff --git a/tcg/ppc/tcg-target.inc.c b/tcg/ppc/tcg-target.inc.c
index 74f9b4aa34..86f7de5f7e 100644
--- a/tcg/ppc/tcg-target.inc.c
+++ b/tcg/ppc/tcg-target.inc.c
@@ -222,33 +222,6 @@ static inline void tcg_out_bc_noaddr(TCGContext *s, int 
insn)
 tcg_out32(s, insn | retrans);
 }
 
-static void patch_reloc(tcg_insn_unit *code_ptr, int type,
-intptr_t value, intptr_t addend)
-{
-tcg_insn_unit *target;
-tcg_insn_unit old;
-
-value += addend;
-target = (tcg_insn_unit *)value;
-
-switch (type) {
-case R_PPC_REL14:
-reloc_pc14(code_ptr, target);
-break;
-case R_PPC_REL24:
-reloc_pc24(code_ptr, target);
-break;
-case R_PPC_ADDR16:
-assert(value == (int16_t)value);
-old = *code_ptr;
-old = deposit32(old, 0, 16, value);
-*code_ptr = old;
-break;
-default:
-tcg_abort();
-}
-}
-
 /* parse target specific constraints */
 static const char *target_parse_constraint(TCGArgConstraint *ct,
const char *ct_str, TCGType type)
@@ -552,6 +525,43 @@ static const uint32_t tcg_to_isel[] = {
 [TCG_COND_GTU] = ISEL | BC_(7, CR_GT),
 };
 
+static void patch_reloc(tcg_insn_unit *code_ptr, int type,
+intptr_t value, intptr_t addend)
+{
+tcg_insn_unit *target;
+tcg_insn_unit old;
+
+value += addend;
+target = (tcg_insn_unit *)value;
+
+switch (type) {
+case R_PPC_REL14:
+reloc_pc14(code_ptr, target);
+break;
+case R_PPC_REL24:
+reloc_pc24(code_ptr, target);
+break;
+case R_PPC_ADDR16:
+/* We are abusing this relocation type.  This points to a pair
+   of insns, addis + load.  If the displacement is small, we
+   can nop out the addis.  */
+if (value == (int16_t)value) {
+code_ptr[0] = NOP;
+old = deposit32(code_ptr[1], 0, 16, value);
+code_ptr[1] = deposit32(old, 16, 5, TCG_REG_TB);
+} else {
+int16_t lo = value;
+int hi = value - lo;
+assert(hi + lo == value);
+code_ptr[0] = deposit32(code_ptr[0], 0, 16, hi >> 16);
+code_ptr[1] = deposit32(code_ptr[1], 0, 16, lo);
+}
+break;
+default:
+g_assert_not_reached();
+}
+}
+
 static void tcg_out_mem_long(TCGContext *s, int opi, int opx, TCGReg rt,
  TCGReg base, tcg_target_long offset);
 
@@ -690,7 +700,8 @@ static void tcg_out_movi_int(TCGContext *s, TCGType type, 
TCGReg ret,
 if (!in_prologue && USE_REG_TB) {
 new_pool_label(s, arg, R_PPC_ADDR16, s->code_ptr,
-(intptr_t)s->code_gen_ptr);
-tcg_out32(s, LD | TAI(ret, TCG_REG_TB, 0));
+tcg_out32(s, ADDIS | TAI(ret, TCG_REG_TB, 0));
+tcg_out32(s, LD | TAI(ret, ret, 0));
 return;
 }
 
-- 
2.14.3




[Qemu-devel] [PULL v2 0/4] tcg queued patches

2018-01-16 Thread Richard Henderson
With comments addressed from v1.


r~



The following changes since commit aae39d24a387a273deab3eb930dbf730aa379e22:

  Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20180116' 
into staging (2018-01-16 14:18:20 +)

are available in the Git repository at:

  git://github.com/rth7680/qemu.git tags/pull-tcg-20180116

for you to fetch changes up to 030ffe39dd4128eb90483af82a5b23b23054a466:

  tcg/ppc: Allow a 32-bit offset to the constant pool (2018-01-16 08:21:56 
-0800)


Queued TCG patches


Richard Henderson (4):
  tcg/arm: Fix double-word comparisons
  tcg/arm: Support tlb offsets larger than 64k
  tcg/ppc: Support tlb offsets larger than 64k
  tcg/ppc: Allow a 32-bit offset to the constant pool

 tcg/arm/tcg-target.inc.c | 116 +++
 tcg/ppc/tcg-target.inc.c |  84 +++---
 2 files changed, 124 insertions(+), 76 deletions(-)



Re: [Qemu-devel] [PATCH v5 3/7] vhost: Simplify ring verification checks

2018-01-16 Thread Dr. David Alan Gilbert
* Igor Mammedov (imamm...@redhat.com) wrote:
> On Mon, 18 Dec 2017 20:13:36 +
> "Dr. David Alan Gilbert (git)"  wrote:
> 
> > From: "Dr. David Alan Gilbert" 
> > 
> > vhost_verify_ring_mappings() were used to verify that
> > rings are still accessible and related memory hasn't
> > been moved after flatview is updated.
> > 
> > It was doing checks by mapping ring's GPA+len and
> > checking that HVA hadn't changed with new memory map.
> > To avoid maybe expensive mapping call, we were
> > identifying address range that changed and were doing
> > mapping only if ring was in changed range.
> > 
> > However it's not neccessary to perform ring's GPA
> > mapping as we already have its current HVA and all
> > we need is to verify that ring's GPA translates to
> > the same HVA in updated flatview.
> > 
> > This will allow the following patches to simplify the range
> > comparison that was previously needed to avoid expensive
> > verify_ring_mapping calls.
> > 
> > Signed-off-by: Igor Mammedov 
> > with modifications by:
> > Signed-off-by: Dr. David Alan Gilbert 
> 
> an additional question,
> 
> in iommu case ring_hva == ring_gpa if we look in to vhost_memory_map()
> have you check if iommu case is working with new code?

It seems to be; I've tested a simple dpdk test that Maxime gave me.

Dave

> 
> > ---
> >  hw/virtio/vhost.c | 75 
> > +--
> >  1 file changed, 40 insertions(+), 35 deletions(-)
> > 
> > diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
> > index d4710fc05c..18611f0d40 100644
> > --- a/hw/virtio/vhost.c
> > +++ b/hw/virtio/vhost.c
> > @@ -450,35 +450,37 @@ static void vhost_memory_unmap(struct vhost_dev *dev, 
> > void *buffer,
> >  }
> >  }
> >  
> > -static int vhost_verify_ring_part_mapping(struct vhost_dev *dev,
> > -  void *part,
> > -  uint64_t part_addr,
> > -  uint64_t part_size,
> > -  uint64_t start_addr,
> > -  uint64_t size)
> > +static int vhost_verify_ring_part_mapping(void *ring_hva,
> > +  uint64_t ring_gpa,
> > +  uint64_t ring_size,
> > +  void *reg_hva,
> > +  uint64_t reg_gpa,
> > +  uint64_t reg_size)
> >  {
> > -hwaddr l;
> > -void *p;
> > -int r = 0;
> > +uint64_t hva_ring_offset;
> > +uint64_t ring_last = range_get_last(ring_gpa, ring_size);
> > +uint64_t reg_last = range_get_last(reg_gpa, reg_size);
> >  
> > -if (!ranges_overlap(start_addr, size, part_addr, part_size)) {
> > +if (ring_last < reg_gpa || ring_gpa > reg_last) {
> >  return 0;
> >  }
> > -l = part_size;
> > -p = vhost_memory_map(dev, part_addr, &l, 1);
> > -if (!p || l != part_size) {
> > -r = -ENOMEM;
> > +/* check that whole ring's is mapped */
> > +if (ring_last > reg_last) {
> > +return -ENOMEM;
> >  }
> > -if (p != part) {
> > -r = -EBUSY;
> > +/* check that ring's MemoryRegion wasn't replaced */
> > +hva_ring_offset = ring_gpa - reg_gpa;
> > +if (ring_hva != reg_hva + hva_ring_offset) {
> > +return -EBUSY;
> >  }
> > -vhost_memory_unmap(dev, p, l, 0, 0);
> > -return r;
> > +
> > +return 0;
> >  }
> >  
> >  static int vhost_verify_ring_mappings(struct vhost_dev *dev,
> > -  uint64_t start_addr,
> > -  uint64_t size)
> > +  void *reg_hva,
> > +  uint64_t reg_gpa,
> > +  uint64_t reg_size)
> >  {
> >  int i, j;
> >  int r = 0;
> > @@ -492,22 +494,25 @@ static int vhost_verify_ring_mappings(struct 
> > vhost_dev *dev,
> >  struct vhost_virtqueue *vq = dev->vqs + i;
> >  
> >  j = 0;
> > -r = vhost_verify_ring_part_mapping(dev, vq->desc, vq->desc_phys,
> > -   vq->desc_size, start_addr, 
> > size);
> > +r = vhost_verify_ring_part_mapping(
> > +vq->desc, vq->desc_phys, vq->desc_size,
> > +reg_hva, reg_gpa, reg_size);
> >  if (r) {
> >  break;
> >  }
> >  
> >  j++;
> > -r = vhost_verify_ring_part_mapping(dev, vq->avail, vq->avail_phys,
> > -   vq->avail_size, start_addr, 
> > size);
> > +r = vhost_verify_ring_part_mapping(
> > +vq->desc, vq->desc_phys, vq->desc_size,
> > +reg_hva, reg_gpa, reg_size);
> >  if (r) {
> >  break;
> >  }
> >  
> >  j++;
> > -r = vhost_verify_ring_

Re: [Qemu-devel] [PATCH v4 11/14] ARM: Add basic code to emulate A7MPCore DAP block

2018-01-16 Thread Philippe Mathieu-Daudé
On 01/16/2018 12:04 PM, Andrey Smirnov wrote:
> On Mon, Jan 15, 2018 at 8:32 PM, Philippe Mathieu-Daudé  
> wrote:
>> Hi Andrey,
>>
>> On 01/15/2018 10:37 PM, Andrey Smirnov wrote:
>>> Add minimal code to emulate A7MPCore DAP block needed to boot Linux
>>> guest.
>>
>> I was not aware the DAP is accessed by upstream Linux...
>>
>> You sure this isn't rather part of some bootloader built-in self-test?
>>
> 
> Yes, I am positive:
> 
> a) I don't run any bootloader and boot directly into Linux, so it's
> just physically impossible
> b) Here's the code:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/hwtracing/coresight?h=v4.15-rc8

Wow :) pretty interesting!

Alistair:
Some features might be interesting to add to the multicore-gdb project idea.

Thanks Andrey for updating me :)

Phil.



Re: [Qemu-devel] [PATCH 05/11] virtio-ccw: convert VirtIOCCWDeviceClass::init -> realize

2018-01-16 Thread Cornelia Huck
On Tue, 16 Jan 2018 10:15:49 -0300
Philippe Mathieu-Daudé  wrote:

> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/s390x/virtio-ccw.h |  2 +-
>  hw/s390x/virtio-ccw.c | 35 +--
>  2 files changed, 18 insertions(+), 19 deletions(-)

I assume someone(tm) will merge that series as a whole?

If so (and with the commit message fixed),

Reviewed-by: Cornelia Huck 



Re: [Qemu-devel] [PATCH v2 16/32] qcow2: Update l2_allocate() to support L2 slices

2018-01-16 Thread Anton Nefedov



On 15/12/2017 3:53 PM, Alberto Garcia wrote:

This patch updates l2_allocate() to support the qcow2 cache returning
L2 slices instead of full L2 tables.

The old code simply gets an L2 table from the cache and initializes it
with zeroes or with the contents of an existing table. With a cache
that returns slices instead of tables the idea remains the same, but
the code must now iterate over all the slices that are contained in an
L2 table.

Since now we're operating with slices the function can no longer
return the newly-allocated table, so it's up to the caller to retrieve
the appropriate L2 slice after calling l2_allocate() (note that with
this patch the caller is still loading full L2 tables, but we'll deal
with that in a separate patch).

Signed-off-by: Alberto Garcia 
---
  block/qcow2-cluster.c | 86 +++
  1 file changed, 52 insertions(+), 34 deletions(-)

diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 8d92d623d8..ecb75b6be6 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -264,11 +264,12 @@ int qcow2_write_l1_entry(BlockDriverState *bs, int 
l1_index)
   *
   */
  
-static int l2_allocate(BlockDriverState *bs, int l1_index, uint64_t **table)

+static int l2_allocate(BlockDriverState *bs, int l1_index)
  {
  BDRVQcow2State *s = bs->opaque;
  uint64_t old_l2_offset;
-uint64_t *l2_table = NULL;
+uint64_t *l2_slice = NULL;
+unsigned slice, slice_size, n_slices;
  int64_t l2_offset;
  int ret;
  
@@ -299,42 +300,50 @@ static int l2_allocate(BlockDriverState *bs, int l1_index, uint64_t **table)
  

[..]>

-/* write the l2 table to the file */
-BLKDBG_EVENT(bs->file, BLKDBG_L2_ALLOC_WRITE);
+trace_qcow2_l2_allocate_write_l2(bs, l1_index);
+qcow2_cache_entry_mark_dirty(s->l2_table_cache, l2_slice);
+ret = qcow2_cache_flush(bs, s->l2_table_cache);
+if (ret < 0) {
+goto fail;
+}
  


Might be an overoptimization but do we really have to flush each slice
separately?
Otherwise a number of write ops will remain the same but at least we
would bdrv_flush() just once.



-trace_qcow2_l2_allocate_write_l2(bs, l1_index);
-qcow2_cache_entry_mark_dirty(s->l2_table_cache, l2_table);
-ret = qcow2_cache_flush(bs, s->l2_table_cache);
-if (ret < 0) {
-goto fail;
+qcow2_cache_put(s->l2_table_cache, (void **) &l2_slice);
  }
  
  /* update the L1 entry */

@@ -345,14 +354,13 @@ static int l2_allocate(BlockDriverState *bs, int 
l1_index, uint64_t **table)
  goto fail;
  }
  
-*table = l2_table;

  trace_qcow2_l2_allocate_done(bs, l1_index, 0);
  return 0;
  
  fail:

  trace_qcow2_l2_allocate_done(bs, l1_index, ret);
-if (l2_table != NULL) {
-qcow2_cache_put(s->l2_table_cache, (void **) table);
+if (l2_slice != NULL) {
+qcow2_cache_put(s->l2_table_cache, (void **) &l2_slice);
  }
  s->l1_table[l1_index] = old_l2_offset;
  if (l2_offset > 0) {
@@ -696,8 +704,18 @@ static int get_cluster_table(BlockDriverState *bs, 
uint64_t offset,
  return ret;
  }
  } else {
+uint64_t new_l2_offset;
  /* First allocate a new L2 table (and do COW if needed) */
-ret = l2_allocate(bs, l1_index, &l2_table);
+ret = l2_allocate(bs, l1_index);
+if (ret < 0) {
+return ret;
+}
+
+/* Get the offset of the newly-allocated l2 table */
+new_l2_offset = s->l1_table[l1_index] & L1E_OFFSET_MASK;
+assert(offset_into_cluster(s, new_l2_offset) == 0);
+/* Load the l2 table in memory */
+ret = l2_load(bs, offset, new_l2_offset, &l2_table);


Cosmetic: maybe this l2_load() better be merged with the copied L2 case?
e.g.

  if (!(l1_table[l1_index] & COPIED))
l2_allocate();
  l2_load();



  if (ret < 0) {
  return ret;
  }





Re: [Qemu-devel] [PATCH v2 25/32] qcow2: Update expand_zero_clusters_in_l1() to support L2 slices

2018-01-16 Thread Anton Nefedov



On 15/12/2017 3:53 PM, Alberto Garcia wrote:

diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 8f7a04ba7d..ab840a449f 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c

[..]

@@ -1907,124 +1911,133 @@ static int 
expand_zero_clusters_in_l1(BlockDriverState *bs, uint64_t *l1_table,
  goto fail;
  }
  
-if (is_active_l1) {

-/* get active L2 tables from cache */
-ret = qcow2_cache_get(bs, s->l2_table_cache, l2_offset,
-(void **)&l2_table);
-} else {
-/* load inactive L2 tables from disk */
-ret = bdrv_read(bs->file, l2_offset / BDRV_SECTOR_SIZE,
-(void *)l2_table, s->cluster_sectors);
-}
-if (ret < 0) {
-goto fail;
-}
-
  ret = qcow2_get_refcount(bs, l2_offset >> s->cluster_bits,
   &l2_refcount);
  if (ret < 0) {
  goto fail;
  }
  
-for (j = 0; j < s->l2_size; j++) {

-uint64_t l2_entry = be64_to_cpu(l2_table[j]);
-int64_t offset = l2_entry & L2E_OFFSET_MASK;
-QCow2ClusterType cluster_type = qcow2_get_cluster_type(l2_entry);
-
-if (cluster_type != QCOW2_CLUSTER_ZERO_PLAIN &&
-cluster_type != QCOW2_CLUSTER_ZERO_ALLOC) {
-continue;
+for (slice = 0; slice < n_slices; slice++) {
+uint64_t slice_offset = l2_offset + slice * slice_size;


Seems like 'bool l2_dirty = false;' needs to be moved here.



Re: [Qemu-devel] [PATCH 1/3] linux-user: introduce functions to detect CPU type

2018-01-16 Thread Laurent Vivier
Le 16/01/2018 à 16:54, Richard Henderson a écrit :
> On 01/16/2018 06:13 AM, Laurent Vivier wrote:
>>> There is no reason to read the elf header twice -- e_flags has already been
>>> stored in the struct image_info.
>>
>> When we set cpu_model, image_info is not initialized.
>> Do you propose to move cpu_init() after loader_exec()?
> 
> Sure.

After checking, I think we can't move cpu_init() after loader_exec():

load_elf_binary() needs to fill AT_HWCAP and in the case of i386 it
depends on cpu->env.features[FEAT_1_EDX] that comes from the cpu model.

Thanks,
Laurent



Re: [Qemu-devel] [PATCH v2 31/32] qcow2: Allow configuring the L2 slice size

2018-01-16 Thread Anton Nefedov



On 15/12/2017 3:53 PM, Alberto Garcia wrote:

diff --git a/block/qcow2-cache.c b/block/qcow2-cache.c
index 2fcecbd7a8..fe58d1ec70 100644
--- a/block/qcow2-cache.c
+++ b/block/qcow2-cache.c

[..]

@@ -879,9 +896,13 @@ static int qcow2_update_options_prepare(BlockDriverState 
*bs,
  }
  }
  
-r->l2_slice_size = s->cluster_size / sizeof(uint64_t);

-r->l2_table_cache = qcow2_cache_create(bs, l2_cache_size);
-r->refcount_block_cache = qcow2_cache_create(bs, refcount_cache_size);
+l2_cache_size *= s->cluster_size / l2_cache_entry_size;
+


A bit confusing; l2_cache_size first means the size in bytes, then the
size in clusters and now the size in entries.

Maybe in the comparison with MIN_L2_CACHE_SIZE, we should multiply
MIN_L2_CACHE_SIZE to cluster_size instead.
And perhaps MIN_L2_CACHE_CLUSTERS is a better name. Or should it even be
MIN_L2_CACHE_ENTRIES instead, taking into account its motivation to make
it possible to handle COW.

Also, I guess the final size-in-entries needs to be compared with
INT_MAX, not the size-in-clusters.


+r->l2_slice_size = l2_cache_entry_size / sizeof(uint64_t);
+r->l2_table_cache = qcow2_cache_create(bs, l2_cache_size,
+   l2_cache_entry_size);


my gcc thinks l2_cache_entry_size may be used uninitialized here.
can't quite see how that may happen though..



Re: [Qemu-devel] [PATCH v2 16/20] fpu/softfloat: re-factor float to int/uint

2018-01-16 Thread Alex Bennée

Alex Bennée  writes:

> We share the common int64/uint64_pack_decomposed function across all
> the helpers and simply limit the final result depending on the final
> size.
>
> Signed-off-by: Alex Bennée 
>
> --
> v2
>   - apply float_flg_invalid fixes next patch
> ---
>  fpu/softfloat.c | 1011 
> +++
>  include/fpu/softfloat.h |   13 +
>  2 files changed, 235 insertions(+), 789 deletions(-)
>
> diff --git a/fpu/softfloat.c b/fpu/softfloat.c
> index edc35300d1..514f43c065 100644
> --- a/fpu/softfloat.c
> +++ b/fpu/softfloat.c
> @@ -1312,6 +1312,194 @@ float64 float64_trunc_to_int(float64 a, float_status 
> *s)
>  return float64_round_pack_canonical(pr, s);
>  }
>
> +/*
> +| Returns the result of converting the floating-point value
> +| `a' to the two's complement integer format.  The conversion is
> +| performed according to the IEC/IEEE Standard for Binary Floating-Point
> +| Arithmetic---which means in particular that the conversion is rounded
> +| according to the current rounding mode.  If `a' is a NaN, the largest
> +| positive integer is returned.  Otherwise, if the conversion overflows, the
> +| largest integer with the same sign as `a' is returned.
> +**/
> +
> +static int64_t int64_pack_decomposed(decomposed_parts p, float_status *s)
> +{
> +uint64_t r;
> +
> +switch (p.cls) {
> +case float_class_snan:
> +case float_class_qnan:
> +return INT64_MAX;
> +case float_class_inf:
> +return p.sign ? INT64_MIN : INT64_MAX;
> +case float_class_zero:
> +return 0;
> +case float_class_normal:
> +if (p.exp < DECOMPOSED_BINARY_POINT) {
> +r = p.frac >> (DECOMPOSED_BINARY_POINT - p.exp);
> +} else if (p.exp < 64) {
> +r = p.frac << (p.exp - DECOMPOSED_BINARY_POINT);
> +} else {
> +s->float_exception_flags |= float_flag_invalid;
> +r = UINT64_MAX;
> +}
> +if (p.sign) {
> +return r < - (uint64_t) INT64_MIN ? -r : INT64_MIN;
> +} else {
> +return r < INT64_MAX ? r : INT64_MAX;
> +}
> +default:
> +g_assert_not_reached();
> +}
> +}
> +
> +static int16_t int16_pack_decomposed(decomposed_parts p, float_status *s)
> +{
> +int64_t r = int64_pack_decomposed(p, s);
> +if (r < INT16_MIN) {
> +s->float_exception_flags |= float_flag_invalid;
> +return INT16_MIN;
> +} else if (r > INT16_MAX) {
> +s->float_exception_flags |= float_flag_invalid;
> +return INT16_MAX;
> +}
> +return r;
> +}
> +
> +static int32_t int32_pack_decomposed(decomposed_parts p, float_status *s)
> +{
> +int64_t r = int64_pack_decomposed(p, s);
> +if (r < INT32_MIN) {
> +s->float_exception_flags |= float_flag_invalid;
> +return INT32_MIN;
> +} else if (r > INT32_MAX) {
> +s->float_exception_flags |= float_flag_invalid;
> +return INT32_MAX;
> +}
> +return r;
> +}
> +
> +#define FLOAT_TO_INT(fsz, isz) \
> +int ## isz ## _t float ## fsz ## _to_int ## isz(float ## fsz a, float_status 
> *s) \
> +{   \
> +decomposed_parts pa = float ## fsz ## _unpack_canonical(a, s);  \
> +decomposed_parts pr = round_decomposed(pa,
> s->float_rounding_mode, s); \

Note to self: round_decomposed may set inexact here which may be
over-ridden by invalid if the number is out of range.

> +return int ## isz ## _pack_decomposed(pr, s);   \
> +}   \
> +\
> +int ## isz ## _t float ## fsz ## _to_int ## isz ## _round_to_zero   \
> + (float ## fsz a, float_status *s)  \
> +{   \
> +decomposed_parts pa = float ## fsz ## _unpack_canonical(a, s);  \
> +decomposed_parts pr = round_decomposed(pa, float_round_to_zero, s); \
> +return int ## isz ## _pack_decomposed(pr, s);   \
> +}
> +
> +FLOAT_TO_INT(16, 16)
> +FLOAT_TO_INT(16, 32)
> +FLOAT_TO_INT(16, 64)
> +
> +FLOAT_TO_INT(32, 16)
> +FLOAT_TO_INT(32, 32)
> +FLOAT_TO_INT(32, 64)
> +
> +FLOAT_TO_INT(64, 16)
> +FLOAT_TO_INT(64, 32)
> +FLOAT_TO_INT(64, 64)
> +
> +#undef FLOAT_TO_INT
> +
> +/*
> + *  Returns the result of converting the floating-point value `a' to
> + *  the unsigned integer format. The conversion is performed according
> + *  to the IEC/IEEE Standard for Binary Floating-Point
> + *  Arithmetic---which means in particular that the conversion is
> + *  rounded according to the current rounding mode. If `a' is a NaN,
> + *  the largest unsigned integer is 

Re: [Qemu-devel] [RFC v1] block/NVMe: introduce a new vhost NVMe host device to QEMU

2018-01-16 Thread Paolo Bonzini
On 15/01/2018 09:01, Changpeng Liu wrote:
> NVMe 1.3 specification introduces a new NVMe ADMIN command:
> doorbell buffer config, which can write shadow doorbell buffer
> instead of MMIO registers, so it can improve the Guest performance
> a lot for emulated NVMe devices inside VM.
> 
> Similar with existing vhost-user-scsi solution, this commit builds a
> new vhost_user_nvme host device to VM and the I/O is processed at
> the slave I/O target, so users can implement a user space NVMe driver
> in the slave I/O target.
> 
> Users can start QEMU with: -chardev socket,id=char0,path=/path/vhost.0 \
> -device vhost-user-nvme,chardev=char0,num_io_queues=2.

Hi Changpeng,

I have two comments on this series.

First, the new command in NVMe 1.3 is great.  However, please first add
support for the doorbell buffer config in hw/block/nvme.c.  There is no
need to tie support for the new command to a completely new external
server architecture.  Emulated NVMe can be enhanced to use iothreads and
(when the doorbell buffer is configured) ioeventfd, and that should come
before enhancements for external vhost-like servers.

Second, virtio-based vhost-user remains QEMU's preferred method for
high-performance I/O in guests.  Discard support is missing and that is
important for SSDs; that should be fixed in the virtio spec.  Are there
any other features where virtio-blk is lagging behind NVMe?

Thanks,

Paolo



Re: [Qemu-devel] [PATCH x86-next v2] target-i386: add PCID flag to Westmere, Sandy Bridge and Ivy Bridge

2018-01-16 Thread Eduardo Habkost
[CCing Daniel]

On Tue, Jan 16, 2018 at 04:33:00PM +0100, Kashyap Chamarthy wrote:
> On Tue, Jan 16, 2018 at 01:55:22PM +0100, Vincent Bernat wrote:
> >  ❦ 16 janvier 2018 10:41 -0200, Eduardo Habkost  :
> > 
> > >> > Adding Westmere-PCID would require adding a Westmere-PCID-IBRS
> > >> > CPU model too, so this is starting to look a bit ridiculous.
> > >> > Sane VM management systems would know how to use
> > >> > "-cpu Westmere,+pcid" without requiring new CPU model entries in
> > >> > QEMU.  What's missing in existing management stacks to allow that
> > >> > to happen?
> > >> 
> > >> That's what I actually do. So, I am fine with the solution of doing
> > >> nothing. However, it would be nice for unaware people to get the speedup
> > >> of pcid without knowing about it. Maybe we can just forget about
> > >> Westmere and still apply it to Sandy Bridge and Ivy Bridge.
> > >
> > > If management stacks today don't let the user choose
> > > "Westmere,+pcid", we probably have no other choice than adding a
> > > Westmere-PCID CPU model.  But our management stacks need to be
> > > fixed so we won't need similar hacks in the future.
> 
> True;  I'm aware of the limitation here in Nova.
> 
> > With libvirt:
> > 
> >   
> > Westmere
> > 
> >   
> 
> Yep, libvirt upstream allows it.
> 
> > We are using CloudStack on top of that and it's also an available
> > option. However, looking at OpenStack, it doesn't seem possible:
> >  
> > https://github.com/openstack/nova/blob/6b248518da794a4c82665c22abf7bee5aa527a47/nova/conf/libvirt.py#L506
> 
> That's correct, upstream OpenStack Nova doesn't yet have facility to
> specify granular CPU feature names.  Nova just ought to wire up the
> facility libvirt already provides.

I still don't understand why OpenStack doesn't let users add or
modify elements on the domain XML.  This isn't the first time I
see this preventing users from fixing problems or optimizing
their systems.

Is there a summary of the reasons behind this limitation
somewhere?

-- 
Eduardo



Re: [Qemu-devel] [qemu-s390x] [PATCH v3 1/8] s390-ccw: update libc

2018-01-16 Thread Collin L. Walling

On 01/16/2018 05:00 AM, Thomas Huth wrote:

On 15.01.2018 18:23, Collin L. Walling wrote:

On 01/15/2018 12:05 PM, Eric Blake wrote:

On 01/15/2018 10:44 AM, Collin L. Walling wrote:

[...]

+/**
+ * atoi:
+ * @str: the string to be converted.
+ *
+ * Given a string @str, convert it to an integer. Any non-numerical
value
+ * will terminate the conversion.
+ *
+ * Returns: an integer converted from the string @str.
+ */
+int atoi(const char *str)
+{
+    int i;
+    int val = 0;
+
+    for (i = 0; str[i]; i++) {
+    char c = str[i];
+    if (!isdigit(c)) {
+    break;
+    }
+    val *= 10;
+    val += c - '0';

Silently gives garbage on integer overflow, but matches the fact that
POSIX atoi() can't flag errors.  However, it does not handle leading
whitespace nor '-', which means it is NOT doing a POSIX-compatible
atoi() implementation; naming it atoi() is perhaps thus a disservice to
end users.

Fair enough. Perhaps the "strtoi" convention suits this better.

Or maybe simply add an assert(str[0] != '-') for now. If we ever hit the
assert, we can still add the support for negative numbers if necessary.



Eh... honestly it's easy enough to just add a flag for the negative sign
and handle it at the end.  We don't need it for this patch series, but at
least the support will be there. :)

[...]

--
- Collin L Walling




Re: [Qemu-devel] [RFC 3/3] vhost-user: add VFIO based accelerators support

2018-01-16 Thread Alex Williamson
On Fri, 22 Dec 2017 14:41:51 +0800
Tiwei Bie  wrote:

> Signed-off-by: Tiwei Bie 
> ---
>  docs/interop/vhost-user.txt|  57 ++
>  hw/vfio/common.c   |   2 +-
>  hw/virtio/vhost-user.c | 381 
> -
>  hw/virtio/vhost.c  |   3 +-
>  hw/virtio/virtio-pci.c |   8 -
>  hw/virtio/virtio-pci.h |   8 +
>  include/hw/vfio/vfio.h |   2 +
>  include/hw/virtio/vhost-user.h |  26 +++
>  8 files changed, 476 insertions(+), 11 deletions(-)
> 
> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index 7b2924c0ef..53d8700581 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -49,7 +49,7 @@ struct vfio_as_head vfio_address_spaces =
>   * initialized, this file descriptor is only released on QEMU exit and
>   * we'll re-use it should another vfio device be attached before then.
>   */
> -static int vfio_kvm_device_fd = -1;
> +int vfio_kvm_device_fd = -1;
>  #endif

It seems troublesome for vhost to maintain it's own list of groups and
register them with the vfio-kvm device.  These should likely be made
into services provided by vfio/common.c such that we can have a single
group list and interfaces for adding and deleting them.  Thanks,

Alex



[Qemu-devel] [PATCH v2 2/4] linux-user: introduce functions to detect CPU type

2018-01-16 Thread Laurent Vivier
From: YunQiang Su 

Add a function to return ELF e_flags and use it
to select the CPU model.

[lv: split the patch and some cleanup in get_elf_eflags()]
Signed-off-by: Laurent Vivier 
---

Notes:
YunQiang Su, please add your Signed-off-by that was
missing in your original patch.

v2: call cpu_get_model() with the result of get_elf_eflags()

 linux-user/elfload.c | 35 +++
 linux-user/main.c| 20 ++--
 linux-user/qemu.h|  1 +
 3 files changed, 46 insertions(+), 10 deletions(-)

diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 20f3d8c2c3..67e2425ac6 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -2376,6 +2376,41 @@ give_up:
 g_free(syms);
 }
 
+uint32_t get_elf_eflags(int fd)
+{
+struct elfhdr ehdr;
+off_t offset;
+int ret;
+
+/* Read ELF header */
+offset = lseek(fd, 0, SEEK_SET);
+if (offset == (off_t) -1) {
+return 0;
+}
+ret = read(fd, &ehdr, sizeof(ehdr));
+if (ret < sizeof(ehdr)) {
+return 0;
+}
+offset = lseek(fd, offset, SEEK_SET);
+if (offset == (off_t) -1) {
+return 0;
+}
+
+/* Check ELF signature */
+if (!elf_check_ident(&ehdr)) {
+return 0;
+}
+
+/* check header */
+bswap_ehdr(&ehdr);
+if (!elf_check_ehdr(&ehdr)) {
+return 0;
+}
+
+/* return architecture id */
+return ehdr.e_flags;
+}
+
 int load_elf_binary(struct linux_binprm *bprm, struct image_info *info)
 {
 struct image_info interp_info;
diff --git a/linux-user/main.c b/linux-user/main.c
index 3954e8996b..6845b56030 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -4319,8 +4319,17 @@ int main(int argc, char **argv, char **envp)
 
 init_qemu_uname_release();
 
+execfd = qemu_getauxval(AT_EXECFD);
+if (execfd == 0) {
+execfd = open(filename, O_RDONLY);
+if (execfd < 0) {
+printf("Error while loading %s: %s\n", filename, strerror(errno));
+_exit(EXIT_FAILURE);
+}
+}
+
 if (cpu_model == NULL) {
-cpu_model = cpu_get_model(0);
+cpu_model = cpu_get_model(get_elf_eflags(execfd));
 }
 tcg_exec_init(0);
 /* NOTE: we need to init the CPU at this stage to get
@@ -4413,15 +4422,6 @@ int main(int argc, char **argv, char **envp)
 cpu->opaque = ts;
 task_settid(ts);
 
-execfd = qemu_getauxval(AT_EXECFD);
-if (execfd == 0) {
-execfd = open(filename, O_RDONLY);
-if (execfd < 0) {
-printf("Error while loading %s: %s\n", filename, strerror(errno));
-_exit(EXIT_FAILURE);
-}
-}
-
 ret = loader_exec(execfd, filename, target_argv, target_environ, regs,
 info, &bprm);
 if (ret != 0) {
diff --git a/linux-user/qemu.h b/linux-user/qemu.h
index 4edd7d0c08..47ca71159c 100644
--- a/linux-user/qemu.h
+++ b/linux-user/qemu.h
@@ -188,6 +188,7 @@ int loader_exec(int fdexec, const char *filename, char 
**argv, char **envp,
  struct target_pt_regs * regs, struct image_info *infop,
  struct linux_binprm *);
 
+uint32_t get_elf_eflags(int fd);
 int load_elf_binary(struct linux_binprm *bprm, struct image_info *info);
 int load_flt_binary(struct linux_binprm *bprm, struct image_info *info);
 
-- 
2.14.3




[Qemu-devel] [PATCH v2 3/4] linux-user, m68k: select CPU according to ELF header values

2018-01-16 Thread Laurent Vivier
M680x0 doesn't support the same set of instructions
as ColdFire, so we can't use "any" CPU type to execute
m68020 instructions.
We select CPU type ("m68020" or "any" for ColdFire)
according to the ELF header. If we can't, we
use by default the value used until now: "any".

Signed-off-by: Laurent Vivier 
---

Notes:
v2: call cpu_get_model() with the result of get_elf_eflags()

 linux-user/m68k/target_elf.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/linux-user/m68k/target_elf.h b/linux-user/m68k/target_elf.h
index df375ad5d3..946b90f342 100644
--- a/linux-user/m68k/target_elf.h
+++ b/linux-user/m68k/target_elf.h
@@ -9,6 +9,12 @@
 #define M68K_TARGET_ELF_H
 static inline const char *cpu_get_model(uint32_t eflags)
 {
+if (eflags == 0) {
+/* 680x0 */
+return "m68020";
+}
+
+/* Coldfire */
 return "any";
 }
 #endif
-- 
2.14.3




Re: [Qemu-devel] [PATCH] chardev/char-socket: add POLLHUP handler

2018-01-16 Thread Paolo Bonzini
On 10/01/2018 14:18, Klim Kireev wrote:
> The following behavior was observed for QEMU configured by libvirt
> to use guest agent as usual for the guests without virtio-serial
> driver (Windows or the guest remaining in BIOS stage).
> 
> In QEMU on first connect to listen character device socket
> the listen socket is removed from poll just after the accept().
> virtio_serial_guest_ready() returns 0 and the descriptor
> of the connected Unix socket is removed from poll and it will
> not be present in poll() until the guest will initialize the driver
> and change the state of the serial to "guest connected".
> 
> In libvirt connect() to guest agent is performed on restart and
> is run under VM state lock. Connect() is blocking and can
> wait forever.
> In this case libvirt can not perform ANY operation on that VM.
> 
> The bug can be easily reproduced this way:
> 
> Terminal 1:
> qemu-system-x86_64 -m 512 -device pci-serial,chardev=serial1 -chardev 
> socket,id=serial1,path=/tmp/console.sock,server,nowait
> (virtio-serial and isa-serial also fit)
> 
> Terminal 2:
> minicom -D unix\#/tmp/console.sock
> (type something and pres enter)
> C-a x (to exit)
> 
> Do 3 times:
> minicom -D unix\#/tmp/console.sock
> C-a x
> 
> It needs 4 connections, because the first one is accepted by QEMU, then two 
> are queued by
> the kernel, and the 4th blocks.
> 
> The problem is that QEMU doesn't add a read watcher after succesful read
> until the guest device wants to acquire recieved data, so
> I propose to install a separate pullhup watcher regardless of
> whether the device waits for data or not. After closing the connection,
> the guest has a capability to read the data within timeout.

I don't understand the timeout part.

Apart from that, maybe the bug is in io_watch_poll_prepare, which needs 
to _always_ set up a "G_IO_ERR | G_IO_HUP | G_IO_NVAL" watch.  Only 
G_IO_IN depends on iwp->fd_can_read(...) > 0.

So the change would start with something like this:

diff --git a/chardev/char-io.c b/chardev/char-io.c
index f81052481a..a5e65d4e7c 100644
--- a/chardev/char-io.c
+++ b/chardev/char-io.c
@@ -29,6 +29,7 @@ typedef struct IOWatchPoll {
 
 QIOChannel *ioc;
 GSource *src;
+GIOCondition cond;
 
 IOCanReadHandler *fd_can_read;
 GSourceFunc fd_read;
@@ -41,25 +42,32 @@ static IOWatchPoll *io_watch_poll_from_source(GSource 
*source)
 return container_of(source, IOWatchPoll, parent);
 }
 
+static void io_watch_poll_destroy_source(IOWatchPoll *iwp)
+{
+if (iwp->src) {
+g_source_destroy(iwp->src);
+g_source_unref(iwp->src);
+iwp->src = NULL;
+iwp->cond = 0;
+}
+}
+
 static gboolean io_watch_poll_prepare(GSource *source,
   gint *timeout)
 {
 IOWatchPoll *iwp = io_watch_poll_from_source(source);
 bool now_active = iwp->fd_can_read(iwp->opaque) > 0;
-bool was_active = iwp->src != NULL;
-if (was_active == now_active) {
-return FALSE;
+GIOCondition cond = G_IO_ERR | G_IO_HUP | G_IO_NVAL;
+if (now_active) {
+cond |= G_IO_IN;
 }
 
-if (now_active) {
-iwp->src = qio_channel_create_watch(
-iwp->ioc, G_IO_IN | G_IO_ERR | G_IO_HUP | G_IO_NVAL);
+if (iwp->cond != cond) {
+io_watch_poll_destroy_source(iwp);
+iwp->cond = cond;
+iwp->src = qio_channel_create_watch(iwp->ioc, cond);
 g_source_set_callback(iwp->src, iwp->fd_read, iwp->opaque, NULL);
 g_source_attach(iwp->src, iwp->context);
-} else {
-g_source_destroy(iwp->src);
-g_source_unref(iwp->src);
-iwp->src = NULL;
 }
 return FALSE;
 }
@@ -131,11 +139,7 @@ static void io_remove_watch_poll(GSource *source)
 IOWatchPoll *iwp;
 
 iwp = io_watch_poll_from_source(source);
-if (iwp->src) {
-g_source_destroy(iwp->src);
-g_source_unref(iwp->src);
-iwp->src = NULL;
-}
+io_watch_poll_destroy_source(iwp);
 g_source_destroy(&iwp->parent);
 }
 


Thanks,

Paolo



[Qemu-devel] [PATCH v2 0/4] linux-user: select CPU type according ELF header values

2018-01-16 Thread Laurent Vivier
This idea has been suggested to me before by Philippe
Mathieu-Daudé, and recently YunQiang Su has proposed a
patch to manage the MIPS r6 case.

Based on this, this series tries to clean-up the original
patch, and introduces the use for m68k architecture and
port the patch from YunQiang Su.

v2: move cpu_model selection to linux-user/*/target_elf.h
   provide eflags to cpu_get_model() instead of fd
   (and modify other patches accordingly)

Laurent Vivier (2):
  linux-user: Move CPU type name selection to a function
  linux-user,m68k: select CPU according to ELF header values

YunQiang Su (2):
  linux-user: introduce functions to detect CPU type
  linux-user: MIPS set cpu to r6 CPU if binary is R6

 include/elf.h  |  4 +++
 linux-user/aarch64/target_elf.h| 14 +
 linux-user/alpha/target_elf.h  | 14 +
 linux-user/arm/target_elf.h| 14 +
 linux-user/cris/target_elf.h   | 14 +
 linux-user/elfload.c   | 35 ++
 linux-user/hppa/target_elf.h   | 14 +
 linux-user/i386/target_elf.h   | 14 +
 linux-user/m68k/target_elf.h   | 20 +
 linux-user/main.c  | 59 +++---
 linux-user/microblaze/target_elf.h | 14 +
 linux-user/mips/target_elf.h   | 17 +++
 linux-user/mips64/target_elf.h | 17 +++
 linux-user/nios2/target_elf.h  | 14 +
 linux-user/openrisc/target_elf.h   | 14 +
 linux-user/ppc/target_elf.h| 21 ++
 linux-user/qemu.h  |  1 +
 linux-user/s390x/target_elf.h  | 14 +
 linux-user/sh4/target_elf.h| 14 +
 linux-user/sparc/target_elf.h  | 14 +
 linux-user/sparc64/target_elf.h| 14 +
 linux-user/tilegx/target_elf.h | 14 +
 linux-user/unicore32/target_elf.h  | 14 +
 linux-user/x86_64/target_elf.h | 14 +
 24 files changed, 350 insertions(+), 48 deletions(-)
 create mode 100644 linux-user/aarch64/target_elf.h
 create mode 100644 linux-user/alpha/target_elf.h
 create mode 100644 linux-user/arm/target_elf.h
 create mode 100644 linux-user/cris/target_elf.h
 create mode 100644 linux-user/hppa/target_elf.h
 create mode 100644 linux-user/i386/target_elf.h
 create mode 100644 linux-user/m68k/target_elf.h
 create mode 100644 linux-user/microblaze/target_elf.h
 create mode 100644 linux-user/mips/target_elf.h
 create mode 100644 linux-user/mips64/target_elf.h
 create mode 100644 linux-user/nios2/target_elf.h
 create mode 100644 linux-user/openrisc/target_elf.h
 create mode 100644 linux-user/ppc/target_elf.h
 create mode 100644 linux-user/s390x/target_elf.h
 create mode 100644 linux-user/sh4/target_elf.h
 create mode 100644 linux-user/sparc/target_elf.h
 create mode 100644 linux-user/sparc64/target_elf.h
 create mode 100644 linux-user/tilegx/target_elf.h
 create mode 100644 linux-user/unicore32/target_elf.h
 create mode 100644 linux-user/x86_64/target_elf.h

-- 
2.14.3




[Qemu-devel] [PATCH v2 4/4] linux-user: MIPS set cpu to r6 CPU if binary is R6

2018-01-16 Thread Laurent Vivier
From: YunQiang Su 

So here we need to detect the version of binaries and set
cpu_model for it.

[lv: original patch modified to move code into cpu_get_model()]
Signed-off-by: Laurent Vivier 
---

Notes:
YunQiang Su, please add your Signed-off-by that was
missing in your original patch.

v2: call cpu_get_model() with the result of get_elf_eflags()

 include/elf.h  | 4 
 linux-user/mips/target_elf.h   | 3 +++
 linux-user/mips64/target_elf.h | 3 +++
 3 files changed, 10 insertions(+)

diff --git a/include/elf.h b/include/elf.h
index e8a515ce3d..f2104809b1 100644
--- a/include/elf.h
+++ b/include/elf.h
@@ -40,6 +40,10 @@ typedef int64_t  Elf64_Sxword;
 #define EF_MIPS_ARCH_5 0x4000  /* -mips5 code.  */
 #define EF_MIPS_ARCH_320x5000  /* MIPS32 code.  */
 #define EF_MIPS_ARCH_640x6000  /* MIPS64 code.  */
+#define EF_MIPS_ARCH_32R2   0x7000  /* MIPS32r2 code.  */
+#define EF_MIPS_ARCH_64R2   0x8000  /* MIPS64r2 code.  */
+#define EF_MIPS_ARCH_32R6   0x9000  /* MIPS32r6 code.  */
+#define EF_MIPS_ARCH_64R6   0xa000  /* MIPS64r6 code.  */
 
 /* The ABI of a file. */
 #define EF_MIPS_ABI_O320x1000  /* O32 ABI.  */
diff --git a/linux-user/mips/target_elf.h b/linux-user/mips/target_elf.h
index bed0b43259..ac14f99ac5 100644
--- a/linux-user/mips/target_elf.h
+++ b/linux-user/mips/target_elf.h
@@ -9,6 +9,9 @@
 #define MIPS_TARGET_ELF_H
 static inline const char *cpu_get_model(uint32_t eflags)
 {
+ if ((eflags & EF_MIPS_ARCH_32R6) != 0) {
+ return "mips32r6-generic";
+ }
 return "24Kf";
 }
 #endif
diff --git a/linux-user/mips64/target_elf.h b/linux-user/mips64/target_elf.h
index 5b6f4692e0..6cda7ae435 100644
--- a/linux-user/mips64/target_elf.h
+++ b/linux-user/mips64/target_elf.h
@@ -9,6 +9,9 @@
 #define MIPS64_TARGET_ELF_H
 static inline const char *cpu_get_model(uint32_t eflags)
 {
+ if ((eflags & EF_MIPS_ARCH_64R6) != 0) {
+ return "I6400";
+ }
 return "5KEf";
 }
 #endif
-- 
2.14.3




[Qemu-devel] [PATCH v2 1/4] linux-user: Move CPU type name selection to a function

2018-01-16 Thread Laurent Vivier
Instead of a sequence of "#if ... #endif" move the
selection to a function in linux-user/*/target_elf.h

We can't add them in linux-user/*/target_cpu.h
because we will need to include "elf.h" to
use ELF flags with eflags, and including
"elf.h" in "target_cpu.h" introduces some
conflic in elfload.c

Suggested-by: Richard Henderson 
Signed-off-by: Laurent Vivier 
---

Notes:
v2: new patch in the series

 linux-user/aarch64/target_elf.h| 14 +
 linux-user/alpha/target_elf.h  | 14 +
 linux-user/arm/target_elf.h| 14 +
 linux-user/cris/target_elf.h   | 14 +
 linux-user/hppa/target_elf.h   | 14 +
 linux-user/i386/target_elf.h   | 14 +
 linux-user/m68k/target_elf.h   | 14 +
 linux-user/main.c  | 41 ++
 linux-user/microblaze/target_elf.h | 14 +
 linux-user/mips/target_elf.h   | 14 +
 linux-user/mips64/target_elf.h | 14 +
 linux-user/nios2/target_elf.h  | 14 +
 linux-user/openrisc/target_elf.h   | 14 +
 linux-user/ppc/target_elf.h| 21 +++
 linux-user/s390x/target_elf.h  | 14 +
 linux-user/sh4/target_elf.h| 14 +
 linux-user/sparc/target_elf.h  | 14 +
 linux-user/sparc64/target_elf.h| 14 +
 linux-user/tilegx/target_elf.h | 14 +
 linux-user/unicore32/target_elf.h  | 14 +
 linux-user/x86_64/target_elf.h | 14 +
 21 files changed, 289 insertions(+), 39 deletions(-)
 create mode 100644 linux-user/aarch64/target_elf.h
 create mode 100644 linux-user/alpha/target_elf.h
 create mode 100644 linux-user/arm/target_elf.h
 create mode 100644 linux-user/cris/target_elf.h
 create mode 100644 linux-user/hppa/target_elf.h
 create mode 100644 linux-user/i386/target_elf.h
 create mode 100644 linux-user/m68k/target_elf.h
 create mode 100644 linux-user/microblaze/target_elf.h
 create mode 100644 linux-user/mips/target_elf.h
 create mode 100644 linux-user/mips64/target_elf.h
 create mode 100644 linux-user/nios2/target_elf.h
 create mode 100644 linux-user/openrisc/target_elf.h
 create mode 100644 linux-user/ppc/target_elf.h
 create mode 100644 linux-user/s390x/target_elf.h
 create mode 100644 linux-user/sh4/target_elf.h
 create mode 100644 linux-user/sparc/target_elf.h
 create mode 100644 linux-user/sparc64/target_elf.h
 create mode 100644 linux-user/tilegx/target_elf.h
 create mode 100644 linux-user/unicore32/target_elf.h
 create mode 100644 linux-user/x86_64/target_elf.h

diff --git a/linux-user/aarch64/target_elf.h b/linux-user/aarch64/target_elf.h
new file mode 100644
index 00..a7eb962fba
--- /dev/null
+++ b/linux-user/aarch64/target_elf.h
@@ -0,0 +1,14 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation, or (at your option) any
+ * later version. See the COPYING file in the top-level directory.
+ */
+
+#ifndef AARCH64_TARGET_ELF_H
+#define AARCH64_TARGET_ELF_H
+static inline const char *cpu_get_model(uint32_t eflags)
+{
+return "any";
+}
+#endif
diff --git a/linux-user/alpha/target_elf.h b/linux-user/alpha/target_elf.h
new file mode 100644
index 00..344e9f4d39
--- /dev/null
+++ b/linux-user/alpha/target_elf.h
@@ -0,0 +1,14 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation, or (at your option) any
+ * later version. See the COPYING file in the top-level directory.
+ */
+
+#ifndef ALPHA_TARGET_ELF_H
+#define ALPHA_TARGET_ELF_H
+static inline const char *cpu_get_model(uint32_t eflags)
+{
+return "any";
+}
+#endif
diff --git a/linux-user/arm/target_elf.h b/linux-user/arm/target_elf.h
new file mode 100644
index 00..58ff6a0986
--- /dev/null
+++ b/linux-user/arm/target_elf.h
@@ -0,0 +1,14 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation, or (at your option) any
+ * later version. See the COPYING file in the top-level directory.
+ */
+
+#ifndef ARM_TARGET_ELF_H
+#define ARM_TARGET_ELF_H
+static inline const char *cpu_get_model(uint32_t eflags)
+{
+return "any";
+}
+#endif
diff --git a/linux-user/cris/target_elf.h b/linux-user/cris/target_elf.h
new file mode 100644
index 00..99eb4ec704
--- /dev/null
+++ b/linux-user/cris/target_elf.h
@@ -0,0 +1,14 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation, or (at your option) any
+ * later version. See the COPYING fil

Re: [Qemu-devel] [PULL v4 00/51] Misc patches for 2018-01-12

2018-01-16 Thread Peter Maydell
On 16 January 2018 at 14:16, Paolo Bonzini  wrote:
> The following changes since commit 997eba28a3ed5400a80f754bf3a1c8044b75b9ff:
>
>   Merge remote-tracking branch 
> 'remotes/pmaydell/tags/pull-target-arm-20180111' into staging (2018-01-11 
> 14:34:41 +)
>
> are available in the git repository at:
>
>
>   git://github.com/bonzini/qemu.git tags/for-upstream
>
> for you to fetch changes up to b5976c2e46e86b36b01d8ac380a182e22209a7cd:
>
>   scripts/analyse-locks-simpletrace.py: script to analyse lock times 
> (2018-01-16 14:54:52 +0100)
>
> 
> * QemuMutex tracing improvements (Alex)
> * ram_addr_t optimization (David)
> * SCSI fixes (Fam, Stefan, me)
> * do {} while (0) fixes (Eric)
> * KVM fix for PMU (Jan)
> * memory leak fixes from ASAN (Marc-André)
> * migration fix for HPET, icount, loadvm (Maria, Pavel)
> * hflags fixes (me, Tao)
> * block/iscsi uninitialized variable (Peter L.)
> * full support for GMainContexts in character devices (Peter Xu)
> * more boot-serial-test (Thomas)
> * Memory leak fix (Zhecheng)
>

Applied, thanks.

-- PMM



Re: [Qemu-devel] [PATCH x86-next v2] target-i386: add PCID flag to Westmere, Sandy Bridge and Ivy Bridge

2018-01-16 Thread Daniel P. Berrange
On Tue, Jan 16, 2018 at 03:08:15PM -0200, Eduardo Habkost wrote:
> [CCing Daniel]
> 
> On Tue, Jan 16, 2018 at 04:33:00PM +0100, Kashyap Chamarthy wrote:
> > On Tue, Jan 16, 2018 at 01:55:22PM +0100, Vincent Bernat wrote:
> > >  ❦ 16 janvier 2018 10:41 -0200, Eduardo Habkost  :
> > > 
> > > >> > Adding Westmere-PCID would require adding a Westmere-PCID-IBRS
> > > >> > CPU model too, so this is starting to look a bit ridiculous.
> > > >> > Sane VM management systems would know how to use
> > > >> > "-cpu Westmere,+pcid" without requiring new CPU model entries in
> > > >> > QEMU.  What's missing in existing management stacks to allow that
> > > >> > to happen?
> > > >> 
> > > >> That's what I actually do. So, I am fine with the solution of doing
> > > >> nothing. However, it would be nice for unaware people to get the 
> > > >> speedup
> > > >> of pcid without knowing about it. Maybe we can just forget about
> > > >> Westmere and still apply it to Sandy Bridge and Ivy Bridge.
> > > >
> > > > If management stacks today don't let the user choose
> > > > "Westmere,+pcid", we probably have no other choice than adding a
> > > > Westmere-PCID CPU model.  But our management stacks need to be
> > > > fixed so we won't need similar hacks in the future.
> > 
> > True;  I'm aware of the limitation here in Nova.
> > 
> > > With libvirt:
> > > 
> > >   
> > > Westmere
> > > 
> > >   
> > 
> > Yep, libvirt upstream allows it.
> > 
> > > We are using CloudStack on top of that and it's also an available
> > > option. However, looking at OpenStack, it doesn't seem possible:
> > >  
> > > https://github.com/openstack/nova/blob/6b248518da794a4c82665c22abf7bee5aa527a47/nova/conf/libvirt.py#L506
> > 
> > That's correct, upstream OpenStack Nova doesn't yet have facility to
> > specify granular CPU feature names.  Nova just ought to wire up the
> > facility libvirt already provides.
> 
> I still don't understand why OpenStack doesn't let users add or
> modify elements on the domain XML.  This isn't the first time I
> see this preventing users from fixing problems or optimizing
> their systems.
> 
> Is there a summary of the reasons behind this limitation
> somewhere?

Exposing ability to control every aspect of Libvirt XML is a non-goal of
Nova. A great many of the features require different modelling and/or
explicit handling by Nova to work well in the context of OpenStack's
architecture. The domain XML is automatically generated on the fly by
Nova based on the info it gets from various inputs, so there's nothing
that can be editted directly to add custom elements. The only way that
would allow modification is for Nova to send the XML it generates to
an external plugin script and read back modified XML. Historically Nova
did have alot of plugin points that allowed arbitrary admin hacks like
this, but they end up being a support burden in themselves, as they
end up being black boxes which change Nova behaviour in unpredictable
ways. Thus Nova has actually worked to remove as many of the plugins
as possible.

In this case there is a clear benefit to being able to add extra CPU
features, over the base named model. It is easy for Nova to wire this
up and it should do so as a priority.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|



Re: [Qemu-devel] [PULL 09/27] migration: calculate vCPU blocktime on dst side

2018-01-16 Thread Dr. David Alan Gilbert
* Max Reitz (mre...@redhat.com) wrote:
> On 2018-01-15 12:52, Juan Quintela wrote:
> > From: Alexey Perevalov 
> > 
> > This patch provides blocktime calculation per vCPU,
> > as a summary and as a overlapped value for all vCPUs.
> > 
> > This approach was suggested by Peter Xu, as an improvements of
> > previous approch where QEMU kept tree with faulted page address and cpus 
> > bitmask
> > in it. Now QEMU is keeping array with faulted page address as value and vCPU
> > as index. It helps to find proper vCPU at UFFD_COPY time. Also it keeps
> > list for blocktime per vCPU (could be traced with page_fault_addr)
> > 
> > Blocktime will not calculated if postcopy_blocktime field of
> > MigrationIncomingState wasn't initialized.
> > 
> > Signed-off-by: Alexey Perevalov 
> > Reviewed-by: Dr. David Alan Gilbert 
> > Reviewed-by: Juan Quintela 
> > Signed-off-by: Juan Quintela 
> > ---
> >  migration/postcopy-ram.c | 143 
> > ++-
> >  migration/trace-events   |   5 +-
> >  2 files changed, 146 insertions(+), 2 deletions(-)
> 
> For me, this breaks compilation with clang -m32:
> 
>   LINKx86_64-softmmu/qemu-system-x86_64
> ../migration/postcopy-ram.o: In function `mark_postcopy_blocktime_begin':
> /home/maxx/projects/qemu/migration/postcopy-ram.c:599: undefined
> reference to `__atomic_exchange_8'
> /home/maxx/projects/qemu/migration/postcopy-ram.c:600: undefined
> reference to `__atomic_exchange_8'
> /home/maxx/projects/qemu/migration/postcopy-ram.c:609: undefined
> reference to `__atomic_exchange_8'
> ../migration/postcopy-ram.o: In function `mark_postcopy_blocktime_end':
> /home/maxx/projects/qemu/migration/postcopy-ram.c:665: undefined
> reference to `__atomic_fetch_add_8'
> /home/maxx/projects/qemu/migration/postcopy-ram.c:686: undefined
> reference to `__atomic_fetch_add_8'
> 
> Am I doing something wrong?

Hmm I also see that with clang on 32bit (gcc is fine);
the problem is the postcopy blocktime stuff is doing some 64bit
atomics, which you can never be sure 32bit will support.

Dave

> Max
> 



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



[Qemu-devel] [PULL v2 00/34] pc, pci, virtio: features, fixes, cleanups

2018-01-16 Thread Michael S. Tsirkin

Changes from v1:
32 build fix
vhost-user-blk build fix
s390 qom fix
include mem slot limit fix

The following changes since commit f5213bd060b460c99e605472b7e03967db43:

  Merge remote-tracking branch 'remotes/juanquintela/tags/migration/20180115' 
into staging (2018-01-15 13:17:47 +)

are available in the git repository at:

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

for you to fetch changes up to 1d9dc60062ae05375c080bbe2db5a5c3c4f495bc:

  vhost: used_memslots refactoring (2018-01-16 18:52:03 +0200)


pc, pci, virtio: features, fixes, cleanups

A bunch of fixes, cleanus and new features all over the place.

Signed-off-by: Michael S. Tsirkin 


Changpeng Liu (4):
  vhost-user: add new vhost user messages to support virtio config space
  vhost-user-blk: introduce a new vhost-user-blk host device
  contrib/libvhost-user: enable virtio config space messages
  contrib/vhost-user-blk: introduce a vhost-user-blk sample application

Dou Liyang (2):
  ACPI/unit-test: Add a testcase for RAM allocation in numa node
  hw/acpi-build: Make next_base easy to follow

Dr. David Alan Gilbert (3):
  vhost: Build temporary section list and deref after commit
  vhost: Simplify ring verification checks
  vhost: Merge sections added to temporary list

Gal Hammer (3):
  qemu: add a cleanup callback function to EventNotifier
  virtio: postpone the execution of event_notifier_cleanup function
  virtio: improve virtio devices initialization time

Igor Mammedov (4):
  tests: acpi: move tested tables array allocation outside of 
test_acpi_dsdt_table()
  tests: acpi: init table descriptor in test_dst_table()
  tests: acpi: rename test_acpi_tables()/test_dst_table() to reflect its 
usage
  tests: acpi: add comments to fetch_rsdt_referenced_tables/data->tables 
usage

Jay Zhou (3):
  vhost: remove assertion to prevent crash
  vhost: fix memslot limit check
  vhost: used_memslots refactoring

Marcel Apfelbaum (2):
  MAINTAINERS: Add myself as maintainer to X86 machines
  hw/pci-bridge: fix QEMU crash because of pcie-root-port

Maxime Coquelin (6):
  vhost-user: fix multiple queue specification
  vhost-user-test: fix features mask
  vhost-user-test: extract read-guest-mem test from main loop
  vhost-user-test: setup virtqueues in all tests
  vhost-user-test: make features mask an init_virtio_dev() argument
  vhost-user-test: use init_virtio_dev in multiqueue test

Michael S. Tsirkin (2):
  vhost-user: factor out msg head and payload
  vhost-user: fix misaligned access to payload

Mohammed Gamal (2):
  x86_iommu: Move machine check to x86_iommu_realize()
  x86_iommu: check if machine has PCI bus

Prasad Singamsetty (2):
  intel-iommu: Redefine macros to enable supporting 48 bit address width
  intel-iommu: Extend address width to 48 bits

Yuval Shaia (1):
  pci/shpc: Move function to generic header file

 docs/interop/vhost-user.txt |  61 +++-
 Makefile|   3 +
 default-configs/pci.mak |   1 +
 default-configs/s390x-softmmu.mak   |   1 +
 contrib/libvhost-user/libvhost-user.h   |  33 ++
 hw/i386/intel_iommu_internal.h  |  43 ++-
 hw/virtio/virtio-pci.h  |  18 ++
 include/hw/i386/intel_iommu.h   |   7 +-
 include/hw/virtio/vhost-backend.h   |  18 +-
 include/hw/virtio/vhost-user-blk.h  |  41 +++
 include/hw/virtio/vhost.h   |  17 +
 include/qemu/event_notifier.h   |   1 +
 include/qemu/host-utils.h   |  10 +
 accel/kvm/kvm-all.c |   4 +
 contrib/libvhost-user/libvhost-user.c   |  42 +++
 contrib/vhost-user-blk/vhost-user-blk.c | 545 
 hw/block/vhost-user-blk.c   | 359 +
 hw/i386/acpi-build.c|   5 +-
 hw/i386/amd_iommu.c |  13 +-
 hw/i386/intel_iommu.c   | 136 
 hw/i386/x86-iommu.c |  13 +
 hw/pci-bridge/gen_pcie_root_port.c  |   7 +-
 hw/pci/shpc.c   |  13 +-
 hw/virtio/vhost-backend.c   |  15 +-
 hw/virtio/vhost-user.c  | 387 ---
 hw/virtio/vhost.c   | 261 ++-
 hw/virtio/virtio-bus.c  |  19 +-
 hw/virtio/virtio-pci.c  |  55 
 hw/virtio/virtio.c  |   5 +
 tests/bios-tables-test.c|  50 ++-
 tests/vhost-user-test.c | 171 +-
 util/event_notifier-posix.c |   5 +-
 util/event_notifier-win32.c |   2 +
 .gitignore  |   1 +
 MAINTAINERS |   1 +
 Makefile.objs

[Qemu-devel] [PULL v2 01/34] MAINTAINERS: Add myself as maintainer to X86 machines

2018-01-16 Thread Michael S. Tsirkin
From: Marcel Apfelbaum 

Signed-off-by: Marcel Apfelbaum 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4770f10..753e799 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -852,6 +852,7 @@ X86 Machines
 
 PC
 M: Michael S. Tsirkin 
+M: Marcel Apfelbaum 
 S: Supported
 F: include/hw/i386/
 F: hw/i386/
-- 
MST




Re: [Qemu-devel] [PATCH v2 5/7] target/m68k: add moves

2018-01-16 Thread Laurent Vivier
Le 15/01/2018 à 19:37, Richard Henderson a écrit :
> On 01/12/2018 04:43 PM, Laurent Vivier wrote:
...
>> -dc->user = (env->sr & SR_S) == 0;
>> +#if defined(CONFIG_SOFTMMU)
>> +dc->user = (env->sr & SR_S) == 0 ? M68K_USER_FROM_MSR : 0;
>> +dc->user |= (env->sfc & 4) == 0 ? M68K_USER_FROM_SFC : 0;
>> +dc->user |= (env->dfc & 4) == 0 ? M68K_USER_FROM_DFC : 0;
>> +#endif
> 
> Really you should be extracting these from tb->flags.

Do I need to keep the dc->user variable?

> You also need to end the TB when assigning to SFC and DFC.  Otherwise the
> generated code is not in sync with the register contents.

I checked that and SFC and DFC are assigned by movec, and movec ends
with gen_lookup_tb() that set s->is_jmp to DISAS_UPDATE, and this forces
an exit from the loop and tcg_gen_exit_tb() (like move_to_sr()).

Thanks,
Laurent



[Qemu-devel] [PULL v2 02/34] vhost-user: add new vhost user messages to support virtio config space

2018-01-16 Thread Michael S. Tsirkin
From: Changpeng Liu 

Add VHOST_USER_GET_CONFIG/VHOST_USER_SET_CONFIG messages which can be
used for live migration of vhost user devices, also vhost user devices
can benefit from the messages to get/set virtio config space from/to the
I/O target. For the purpose to support virtio config space change,
VHOST_USER_SLAVE_CONFIG_CHANGE_MSG message is added as the event notifier
in case virtio config space change in the slave I/O target.

Signed-off-by: Changpeng Liu 
Reviewed-by: Marc-André Lureau 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 docs/interop/vhost-user.txt   |  55 ++
 include/hw/virtio/vhost-backend.h |  12 
 include/hw/virtio/vhost.h |  15 +
 hw/virtio/vhost-user.c| 118 ++
 hw/virtio/vhost.c |  32 +++
 5 files changed, 232 insertions(+)

diff --git a/docs/interop/vhost-user.txt b/docs/interop/vhost-user.txt
index d49444e..0875ef4 100644
--- a/docs/interop/vhost-user.txt
+++ b/docs/interop/vhost-user.txt
@@ -119,6 +119,19 @@ Depending on the request type, payload can be:
 - 3: IOTLB invalidate
 - 4: IOTLB access fail
 
+ * Virtio device config space
+   ---
+   | offset | size | flags | payload |
+   ---
+
+   Offset: a 32-bit offset of virtio device's configuration space
+   Size: a 32-bit configuration space access size in bytes
+   Flags: a 32-bit value:
+- 0: Vhost master messages used for writeable fields
+- 1: Vhost master messages used for live migration
+   Payload: Size bytes array holding the contents of the virtio
+   device's configuration space
+
 In QEMU the vhost-user message is implemented with the following struct:
 
 typedef struct VhostUserMsg {
@@ -132,6 +145,7 @@ typedef struct VhostUserMsg {
 VhostUserMemory memory;
 VhostUserLog log;
 struct vhost_iotlb_msg iotlb;
+VhostUserConfig config;
 };
 } QEMU_PACKED VhostUserMsg;
 
@@ -623,6 +637,32 @@ Master message types
   and expect this message once (per VQ) during device configuration
   (ie. before the master starts the VQ).
 
+ * VHOST_USER_GET_CONFIG
+
+  Id: 24
+  Equivalent ioctl: N/A
+  Master payload: virtio device config space
+  Slave payload: virtio device config space
+
+  Submitted by the vhost-user master to fetch the contents of the virtio
+  device configuration space, vhost-user slave's payload size MUST match
+  master's request, vhost-user slave uses zero length of payload to
+  indicate an error to vhost-user master. The vhost-user master may
+  cache the contents to avoid repeated VHOST_USER_GET_CONFIG calls.
+
+* VHOST_USER_SET_CONFIG
+
+  Id: 25
+  Equivalent ioctl: N/A
+  Master payload: virtio device config space
+  Slave payload: N/A
+
+  Submitted by the vhost-user master when the Guest changes the virtio
+  device configuration space and also can be used for live migration
+  on the destination host. The vhost-user slave must check the flags
+  field, and slaves MUST NOT accept SET_CONFIG for read-only
+  configuration space fields unless the live migration bit is set.
+
 Slave message types
 ---
 
@@ -641,6 +681,21 @@ Slave message types
   This request should be send only when VIRTIO_F_IOMMU_PLATFORM feature
   has been successfully negotiated.
 
+* VHOST_USER_SLAVE_CONFIG_CHANGE_MSG
+
+ Id: 2
+ Equivalent ioctl: N/A
+ Slave payload: N/A
+ Master payload: N/A
+
+ Vhost-user slave sends such messages to notify that the virtio device's
+ configuration space has changed, for those host devices which can support
+ such feature, host driver can send VHOST_USER_GET_CONFIG message to slave
+ to get the latest content. If VHOST_USER_PROTOCOL_F_REPLY_ACK is
+ negotiated, and slave set the VHOST_USER_NEED_REPLY flag, master must
+ respond with zero when operation is successfully completed, or non-zero
+ otherwise.
+
 VHOST_USER_PROTOCOL_F_REPLY_ACK:
 ---
 The original vhost-user specification only demands replies for certain
diff --git a/include/hw/virtio/vhost-backend.h 
b/include/hw/virtio/vhost-backend.h
index a7a5f22..592254f 100644
--- a/include/hw/virtio/vhost-backend.h
+++ b/include/hw/virtio/vhost-backend.h
@@ -20,6 +20,11 @@ typedef enum VhostBackendType {
 VHOST_BACKEND_TYPE_MAX = 3,
 } VhostBackendType;
 
+typedef enum VhostSetConfigType {
+VHOST_SET_CONFIG_TYPE_MASTER = 0,
+VHOST_SET_CONFIG_TYPE_MIGRATION = 1,
+} VhostSetConfigType;
+
 struct vhost_dev;
 struct vhost_log;
 struct vhost_memory;
@@ -84,6 +89,11 @@ typedef void (*vhost_set_iotlb_callback_op)(struct vhost_dev 
*dev,
int enabled);
 typedef int (*vhost_send_device_iotlb_msg_op)(struct vhost_dev *dev,
   struct vho

[Qemu-devel] [PULL v2 10/34] vhost-user: fix multiple queue specification

2018-01-16 Thread Michael S. Tsirkin
From: Maxime Coquelin 

The number of queues supported by the slave is queried with
message VHOST_USER_GET_QUEUE_NUM, not with message
VHOST_USER_GET_PROTOCOL_FEATURES.

Signed-off-by: Maxime Coquelin 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 docs/interop/vhost-user.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/interop/vhost-user.txt b/docs/interop/vhost-user.txt
index 0875ef4..9fcf48d 100644
--- a/docs/interop/vhost-user.txt
+++ b/docs/interop/vhost-user.txt
@@ -228,8 +228,8 @@ Multiple queue is treated as a protocol extension, hence 
the slave has to
 implement protocol features first. The multiple queues feature is supported
 only when the protocol feature VHOST_USER_PROTOCOL_F_MQ (bit 0) is set.
 
-The max number of queues the slave supports can be queried with message
-VHOST_USER_GET_PROTOCOL_FEATURES. Master should stop when the number of
+The max number of queue pairs the slave supports can be queried with message
+VHOST_USER_GET_QUEUE_NUM. Master should stop when the number of
 requested queues is bigger than that.
 
 As all queues share one connection, the master uses a unique index for each
-- 
MST




[Qemu-devel] [PULL v2 09/34] pci/shpc: Move function to generic header file

2018-01-16 Thread Michael S. Tsirkin
From: Yuval Shaia 

This function should be declared in generic header file so we can
utilize it.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Yuval Shaia 
Signed-off-by: Marcel Apfelbaum 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
---
 include/qemu/host-utils.h | 10 ++
 hw/pci/shpc.c | 13 ++---
 2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/include/qemu/host-utils.h b/include/qemu/host-utils.h
index 5ac621c..38da849 100644
--- a/include/qemu/host-utils.h
+++ b/include/qemu/host-utils.h
@@ -400,6 +400,16 @@ static inline uint64_t pow2ceil(uint64_t value)
 return 0x8000ull >> (n - 1);
 }
 
+static inline uint32_t pow2roundup32(uint32_t x)
+{
+x |= (x >> 1);
+x |= (x >> 2);
+x |= (x >> 4);
+x |= (x >> 8);
+x |= (x >> 16);
+return x + 1;
+}
+
 /**
  * urshift - 128-bit Unsigned Right Shift.
  * @plow: in/out - lower 64-bit integer.
diff --git a/hw/pci/shpc.c b/hw/pci/shpc.c
index 69fc14b..a8462d4 100644
--- a/hw/pci/shpc.c
+++ b/hw/pci/shpc.c
@@ -1,6 +1,7 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
 #include "qemu-common.h"
+#include "qemu/host-utils.h"
 #include "qemu/range.h"
 #include "qemu/error-report.h"
 #include "hw/pci/shpc.h"
@@ -122,16 +123,6 @@
 #define SHPC_PCI_TO_IDX(pci_slot) ((pci_slot) - 1)
 #define SHPC_IDX_TO_PHYSICAL(slot) ((slot) + 1)
 
-static int roundup_pow_of_two(int x)
-{
-x |= (x >> 1);
-x |= (x >> 2);
-x |= (x >> 4);
-x |= (x >> 8);
-x |= (x >> 16);
-return x + 1;
-}
-
 static uint16_t shpc_get_status(SHPCDevice *shpc, int slot, uint16_t msk)
 {
 uint8_t *status = shpc->config + SHPC_SLOT_STATUS(slot);
@@ -656,7 +647,7 @@ int shpc_init(PCIDevice *d, PCIBus *sec_bus, MemoryRegion 
*bar,
 
 int shpc_bar_size(PCIDevice *d)
 {
-return roundup_pow_of_two(SHPC_SLOT_REG(SHPC_MAX_SLOTS));
+return pow2roundup32(SHPC_SLOT_REG(SHPC_MAX_SLOTS));
 }
 
 void shpc_cleanup(PCIDevice *d, MemoryRegion *bar)
-- 
MST




<    1   2   3   4   5   >