Re: [Qemu-devel] [PATCH v3 0/7] Kconfig dependencies for MIPS machines (but Malta)

[Philippe Mathieu-Daudé]

> On 5/27/19 8:31 PM, Aleksandar Markovic wrote:
> > What would be the status of this series? I am willing to integrate all
> > this, including all followups, but have hard time sorting out what
> > happend after this submission, what is the most complete version etc.
> > Can you enlighten me please?
>
> Thanks for your interest in this series :)
>
> I was chatting with Thomas about this series earlier today!
> I addressed your comment about the ITU/CPS devices, then wanted to join
> all the Malta patches in the same series, but there are too many for a
> single series so I'll keep them separate.

After some sleep I could remember why I postponed this series:

1/ making the ITU selectable gives:

  /usr/bin/ld: target/mips/op_helper.o: in function `helper_mtc0_saar':
  ./target/mips/op_helper.c:1614: undefined reference to `itc_reconfigure'
  /usr/bin/ld: target/mips/op_helper.o: in function `helper_mthc0_saar':
  ./target/mips/op_helper.c:1631: undefined reference to `itc_reconfigure'
  collect2: error: ld returned 1 exit status

Anyway it is now selectable but has to be always selected.

2/ I thought only the Malta board was deeply mixed with the X86 ACPI
code, but I later noticed the Fulong is too.

  /usr/bin/ld: ../hw/isa/vt82c686.o: in function `vt82c686b_pm_realize':
  ./hw/isa/vt82c686.c:381: undefined reference to `acpi_pm_tmr_init'
  /usr/bin/ld: ./hw/isa/vt82c686.c:382: undefined reference to
`acpi_pm1_evt_init'
  /usr/bin/ld: ../hw/isa/vt82c686.o: in function `pm_update_sci':
  ./hw/isa/vt82c686.c:195: undefined reference to `acpi_pm1_evt_get_sts'
  collect2: error: ld returned 1 exit status

Both VT82C686B/PIIX4 southbridges require considerable cleanup.
I think I now have something workable, but I have to sell my patches
correctly to the different subsystem maintainers ;)

Regards,

Phil.

Re: [Qemu-devel] [PATCH v2 2/2] block: avoid recursive block_status call if possible

[Vladimir Sementsov-Ogievskiy]

27.05.2019 18:13, Max Reitz wrote:
> On 08.04.19 18:26, Vladimir Sementsov-Ogievskiy wrote:
>> drv_co_block_status digs bs->file for additional, more accurate search
>> for hole inside region, reported as DATA by bs since 5daa74a6ebc.
>>
>> This accuracy is not free: assume we have qcow2 disk. Actually, qcow2
>> knows, where are holes and where is data. But every block_status
>> request calls lseek additionally. Assume a big disk, full of
>> data, in any iterative copying block job (or img convert) we'll call
>> lseek(HOLE) on every iteration, and each of these lseeks will have to
>> iterate through all metadata up to the end of file. It's obviously
>> ineffective behavior. And for many scenarios we don't need this lseek
>> at all.
>>
>> However, lseek is needed when we have metadata-preallocated image.
>>
>> So, let's detect metadata-preallocation case and don't dig qcow2's
>> protocol file in other cases.
>>
>> The idea is to compare allocation size in POV of filesystem with
>> allocations size in POV of Qcow2 (by refcounts). If allocation in fs is
>> significantly lower, consider it as metadata-preallocation case.
>>
>> 102 iotest changed, as our detector can't detect shrinked file as
>> metadata-preallocation, which don't seem to be wrong, as with metadata
>> preallocation we always have valid file length.
>>
>> Other two iotests tiny changed QMP output sequence, which should be
>> exactly because skipped lseek at mirror beginning.
>>
>> Suggested-by: Denis V. Lunev 
>> Signed-off-by: Vladimir Sementsov-Ogievskiy 
>> ---
>>   block/qcow2.h  |  4 
>>   include/block/block.h  |  8 +++-
>>   block/io.c |  9 -
>>   block/qcow2-refcount.c | 32 
>>   block/qcow2.c  | 11 +++
>>   tests/qemu-iotests/102 |  2 +-
>>   tests/qemu-iotests/102.out |  3 ++-
>>   tests/qemu-iotests/141.out |  2 +-
>>   tests/qemu-iotests/144.out |  2 +-
>>   9 files changed, 67 insertions(+), 6 deletions(-)
> 
> For me, this patch breaks iotests 141 (for qed) and 211 (for vdi):
> 
>> 141 1s ...[17:11:53] [17:11:53] - output mismatch (see 141.out.bad)
>> --- tests/qemu-iotests/141.out 2019-05-27 17:11:43.327664282 +0200
>> +++ build/tests/qemu-iotests/141.out.bad   2019-05-27 17:11:53.949439880 
>> +0200
>> @@ -42,9 +42,9 @@
>>   {"return": {}}
>>   {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, 
>> "event": "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "job0"}}
>>   {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, 
>> "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "job0"}}
>> -{"return": {}}
>>   {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, 
>> "event": "JOB_STATUS_CHANGE", "data": {"status": "ready", "id": "job0"}}
>>   {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, 
>> "event": "BLOCK_JOB_READY", "data": {"device": "job0", "len": 0, "offset": 
>> 0, "speed": 0, "type": "commit"}}
>> +{"return": {}}
>>   {"error": {"class": "GenericError", "desc": "Node 'drv0' is busy: block 
>> device is in use by block job: commit"}}
>>   {"return": {}}
>>   {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, 
>> "event": "JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "job0"}}
> 
> and
> 
>> 211 5s ...[17:11:54] [17:11:58] - output mismatch (see 211.out.bad)
>> --- tests/qemu-iotests/211.out 2019-05-22 19:58:34.870273427 +0200
>> +++ build/tests/qemu-iotests/211.out.bad   2019-05-27 17:11:58.259348827 
>> +0200
>> @@ -55,8 +55,7 @@
>>   virtual size: 32 MiB (33554432 bytes)
>>   cluster_size: 1048576
>>   
>> -[{ "start": 0, "length": 3072, "depth": 0, "zero": false, "data": true, 
>> "offset": 1024},
>> -{ "start": 3072, "length": 33551360, "depth": 0, "zero": true, "data": 
>> true, "offset": 4096}]
>> +[{ "start": 0, "length": 33554432, "depth": 0, "zero": false, "data": true, 
>> "offset": 1024}]
>>   
>>   === Invalid BlockdevRef ===
> 
> Doesn’t look too bad, but still, broken iotests are broken iotests. :/
> 


You are right, thanks for pointing to this! So, here is my investigation:

about 211: aha, looks like I just didn't implement metadata preallocation 
detection for vdi,
and default behavior is changed. I don't know vdi code, but after fast look, it 
seems that
it may be as simple as (and it fixes the test):


diff --git a/block/vdi.c b/block/vdi.c
index d7ef6628e7..a72333dcf4 100644
--- a/block/vdi.c
+++ b/block/vdi.c
@@ -542,7 +542,9 @@ static int coroutine_fn 
vdi_co_block_status(BlockDriverState *bs,
  *map = s->header.offset_data + (uint64_t)bmap_entry * s->block_size +
  index_in_block;
  *file = bs->file->bs;
-return BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID;
+
+return BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID |
+(s->header.image_type == VDI_TYPE_STATIC ? BDRV_BLOCK_RECURSE : 0);
  }



Or, we can rollback vdi behavior to pre-patc

Re: [Qemu-devel] [PULL v2 04/36] virtio: Introduce started flag to VirtioDevice

[Greg Kurz]

On Tue, 28 May 2019 10:08:54 +1000
David Gibson  wrote:

> On Fri, May 24, 2019 at 12:19:09PM +0200, Greg Kurz wrote:
> > On Mon, 20 May 2019 19:10:35 -0400
> > "Michael S. Tsirkin"  wrote:
> >   
> > > From: Xie Yongji 
> > > 
> > > The virtio 1.0 transitional devices support driver uses the device
> > > before setting the DRIVER_OK status bit. So we introduce a started
> > > flag to indicate whether driver has started the device or not.
> > > 
> > > Signed-off-by: Xie Yongji 
> > > Signed-off-by: Zhang Yu 
> > > Message-Id: <20190320112646.3712-2-xieyon...@baidu.com>
> > > Reviewed-by: Michael S. Tsirkin 
> > > Signed-off-by: Michael S. Tsirkin 
> > > ---
> > >  include/hw/virtio/virtio.h |  2 ++
> > >  hw/virtio/virtio.c | 52 --
> > >  2 files changed, 52 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> > > index 7140381e3a..27c0efc3d0 100644
> > > --- a/include/hw/virtio/virtio.h
> > > +++ b/include/hw/virtio/virtio.h
> > > @@ -105,6 +105,8 @@ struct VirtIODevice
> > >  uint16_t device_id;
> > >  bool vm_running;
> > >  bool broken; /* device in invalid state, needs reset */
> > > +bool started;
> > > +bool start_on_kick; /* virtio 1.0 transitional devices support that 
> > > */
> > >  VMChangeStateEntry *vmstate;
> > >  char *bus_name;
> > >  uint8_t device_endian;
> > > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > > index 28056a7ef7..5d533ac74e 100644
> > > --- a/hw/virtio/virtio.c
> > > +++ b/hw/virtio/virtio.c
> > > @@ -1162,10 +1162,16 @@ int virtio_set_status(VirtIODevice *vdev, uint8_t 
> > > val)
> > >  }
> > >  }
> > >  }
> > > +vdev->started = val & VIRTIO_CONFIG_S_DRIVER_OK;
> > > +if (unlikely(vdev->start_on_kick && vdev->started)) {
> > > +vdev->start_on_kick = false;
> > > +}
> > > +
> > >  if (k->set_status) {
> > >  k->set_status(vdev, val);
> > >  }
> > >  vdev->status = val;
> > > +
> > >  return 0;
> > >  }
> > >  
> > > @@ -1208,6 +1214,9 @@ void virtio_reset(void *opaque)
> > >  k->reset(vdev);
> > >  }
> > >  
> > > +vdev->start_on_kick = (virtio_host_has_feature(vdev, 
> > > VIRTIO_F_VERSION_1) &&
> > > +  !virtio_vdev_has_feature(vdev, 
> > > VIRTIO_F_VERSION_1));
> > > +vdev->started = false;
> > >  vdev->broken = false;
> > >  vdev->guest_features = 0;
> > >  vdev->queue_sel = 0;
> > > @@ -1518,14 +1527,21 @@ void virtio_queue_set_align(VirtIODevice *vdev, 
> > > int n, int align)
> > >  
> > >  static bool virtio_queue_notify_aio_vq(VirtQueue *vq)
> > >  {
> > > +bool ret = false;
> > > +
> > >  if (vq->vring.desc && vq->handle_aio_output) {
> > >  VirtIODevice *vdev = vq->vdev;
> > >  
> > >  trace_virtio_queue_notify(vdev, vq - vdev->vq, vq);
> > > -return vq->handle_aio_output(vdev, vq);
> > > +ret = vq->handle_aio_output(vdev, vq);
> > > +
> > > +if (unlikely(vdev->start_on_kick)) {
> > > +vdev->started = true;
> > > +vdev->start_on_kick = false;
> > > +}
> > >  }
> > >  
> > > -return false;
> > > +return ret;
> > >  }
> > >  
> > >  static void virtio_queue_notify_vq(VirtQueue *vq)
> > > @@ -1539,6 +1555,11 @@ static void virtio_queue_notify_vq(VirtQueue *vq)
> > >  
> > >  trace_virtio_queue_notify(vdev, vq - vdev->vq, vq);
> > >  vq->handle_output(vdev, vq);
> > > +
> > > +if (unlikely(vdev->start_on_kick)) {
> > > +vdev->started = true;
> > > +vdev->start_on_kick = false;
> > > +}
> > >  }
> > >  }
> > >  
> > > @@ -1556,6 +1577,11 @@ void virtio_queue_notify(VirtIODevice *vdev, int n)
> > >  } else if (vq->handle_output) {
> > >  vq->handle_output(vdev, vq);
> > >  }
> > > +
> > > +if (unlikely(vdev->start_on_kick)) {
> > > +vdev->started = true;
> > > +vdev->start_on_kick = false;
> > > +}
> > >  }
> > >  
> > >  uint16_t virtio_queue_vector(VirtIODevice *vdev, int n)
> > > @@ -1770,6 +1796,13 @@ static bool virtio_broken_needed(void *opaque)
> > >  return vdev->broken;
> > >  }
> > >  
> > > +static bool virtio_started_needed(void *opaque)
> > > +{
> > > +VirtIODevice *vdev = opaque;
> > > +
> > > +return vdev->started;  
> > 
> > Existing machine types don't know about the "virtio/started" subsection. 
> > This
> > breaks migration to older QEMUs if the driver has started the device, ie. 
> > most
> > probably always when it comes to live migration.
> > 
> > My understanding is that we do try to support backward migration though. It
> > is a regular practice in datacenters to migrate workloads without having to
> > take care of the QEMU version. FWIW I had to fix similar issues downstream
> > many times in the past because customers had filed bugs.
> > 
> > Cc'ing David for his opinion.  
> 

Re: [Qemu-devel] [PATCH v2] nvme: add Get/Set Feature Timestamp support

[Klaus Birkelund]

On Mon, May 20, 2019 at 11:40:30AM -0600, Kenneth Heitke wrote:
> Signed-off-by: Kenneth Heitke 
> ---
>  hw/block/nvme.c   | 106 +-
>  hw/block/nvme.h   |   3 ++
>  hw/block/trace-events |   2 +
>  include/block/nvme.h  |   2 +
>  4 files changed, 111 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/block/nvme.c b/hw/block/nvme.c
> index 7caf92532a..67372e0cd1 100644
> --- a/hw/block/nvme.c
> +++ b/hw/block/nvme.c
> @@ -219,6 +219,30 @@ static uint16_t nvme_map_prp(QEMUSGList *qsg, 
> QEMUIOVector *iov, uint64_t prp1,
>  return NVME_INVALID_FIELD | NVME_DNR;
>  }
>  
> +static uint16_t nvme_dma_write_prp(NvmeCtrl *n, uint8_t *ptr, uint32_t len,
> +   uint64_t prp1, uint64_t prp2)
> +{
> +QEMUSGList qsg;
> +QEMUIOVector iov;
> +uint16_t status = NVME_SUCCESS;
> +
> +if (nvme_map_prp(&qsg, &iov, prp1, prp2, len, n)) {
> +return NVME_INVALID_FIELD | NVME_DNR;
> +}
> +if (qsg.nsg > 0) {
> +if (dma_buf_write(ptr, len, &qsg)) {
> +status = NVME_INVALID_FIELD | NVME_DNR;
> +}
> +qemu_sglist_destroy(&qsg);
> +} else {
> +if (qemu_iovec_to_buf(&iov, 0, ptr, len) != len) {
> +status = NVME_INVALID_FIELD | NVME_DNR;
> +}
> +qemu_iovec_destroy(&iov);
> +}
> +return status;
> +}
> +
>  static uint16_t nvme_dma_read_prp(NvmeCtrl *n, uint8_t *ptr, uint32_t len,
>  uint64_t prp1, uint64_t prp2)
>  {
> @@ -678,7 +702,6 @@ static uint16_t nvme_identify_nslist(NvmeCtrl *n, 
> NvmeIdentify *c)
>  return ret;
>  }
>  
> -
>  static uint16_t nvme_identify(NvmeCtrl *n, NvmeCmd *cmd)
>  {
>  NvmeIdentify *c = (NvmeIdentify *)cmd;
> @@ -696,6 +719,57 @@ static uint16_t nvme_identify(NvmeCtrl *n, NvmeCmd *cmd)
>  }
>  }
>  
> +static inline void nvme_set_timestamp(NvmeCtrl *n, uint64_t ts)
> +{
> +trace_nvme_setfeat_timestamp(ts);
> +
> +n->host_timestamp = le64_to_cpu(ts);
> +n->timestamp_set_qemu_clock_ms = qemu_clock_get_ms(QEMU_CLOCK_REALTIME);
> +}
> +
> +static inline uint64_t nvme_get_timestamp(const NvmeCtrl *n)
> +{
> +uint64_t current_time = qemu_clock_get_ms(QEMU_CLOCK_REALTIME);
> +uint64_t elapsed_time = current_time - n->timestamp_set_qemu_clock_ms;
> +
> +union nvme_timestamp {
> +struct {
> +uint64_t timestamp:48;
> +uint64_t sync:1;
> +uint64_t origin:3;
> +uint64_t rsvd1:12;
> +};
> +uint64_t all;
> +};
> +
> +union nvme_timestamp ts;
> +ts.all = 0;
> +
> +/*
> + * If the sum of the Timestamp value set by the host and the elapsed
> + * time exceeds 2^48, the value returned should be reduced modulo 2^48.
> + */
> +ts.timestamp = (n->host_timestamp + elapsed_time) & 0x;
> +
> +/* If the host timestamp is non-zero, set the timestamp origin */
> +ts.origin = n->host_timestamp ? 0x01 : 0x00;
> +
> +trace_nvme_getfeat_timestamp(ts.all);
> +
> +return cpu_to_le64(ts.all);
> +}
> +
> +static uint16_t nvme_get_feature_timestamp(NvmeCtrl *n, NvmeCmd *cmd)
> +{
> +uint64_t prp1 = le64_to_cpu(cmd->prp1);
> +uint64_t prp2 = le64_to_cpu(cmd->prp2);
> +
> +uint64_t timestamp = nvme_get_timestamp(n);
> +
> +return nvme_dma_read_prp(n, (uint8_t *)×tamp,
> + sizeof(timestamp), prp1, prp2);
> +}
> +
>  static uint16_t nvme_get_feature(NvmeCtrl *n, NvmeCmd *cmd, NvmeRequest *req)
>  {
>  uint32_t dw10 = le32_to_cpu(cmd->cdw10);
> @@ -710,6 +784,9 @@ static uint16_t nvme_get_feature(NvmeCtrl *n, NvmeCmd 
> *cmd, NvmeRequest *req)
>  result = cpu_to_le32((n->num_queues - 2) | ((n->num_queues - 2) << 
> 16));
>  trace_nvme_getfeat_numq(result);
>  break;
> +case NVME_TIMESTAMP:
> +return nvme_get_feature_timestamp(n, cmd);
> +break;
>  default:
>  trace_nvme_err_invalid_getfeat(dw10);
>  return NVME_INVALID_FIELD | NVME_DNR;
> @@ -719,6 +796,24 @@ static uint16_t nvme_get_feature(NvmeCtrl *n, NvmeCmd 
> *cmd, NvmeRequest *req)
>  return NVME_SUCCESS;
>  }
>  
> +static uint16_t nvme_set_feature_timestamp(NvmeCtrl *n, NvmeCmd *cmd)
> +{
> +uint16_t ret;
> +uint64_t timestamp;
> +uint64_t prp1 = le64_to_cpu(cmd->prp1);
> +uint64_t prp2 = le64_to_cpu(cmd->prp2);
> +
> +ret = nvme_dma_write_prp(n, (uint8_t *)×tamp,
> +sizeof(timestamp), prp1, prp2);
> +if (ret != NVME_SUCCESS) {
> +return ret;
> +}
> +
> +nvme_set_timestamp(n, timestamp);
> +
> +return NVME_SUCCESS;
> +}
> +
>  static uint16_t nvme_set_feature(NvmeCtrl *n, NvmeCmd *cmd, NvmeRequest *req)
>  {
>  uint32_t dw10 = le32_to_cpu(cmd->cdw10);
> @@ -735,6 +830,11 @@ static uint16_t nvme_set_feature(NvmeCtrl *n, NvmeCmd 
> *cmd, NvmeRequest *req)
>  req->cqe.result =
>  cpu_to_le32((n->num_queues - 

Re: [Qemu-devel] [PATCH v2 0/3] Update documentation and help related to the preallocation parameter

[Markus Armbruster]

Kevin, Max, this series looks ready to me.  Feel free to ask me to take
it through my tree.

Re: [Qemu-devel] [PATCH v4 00/20] monitor: add asynchronous command type

[Gerd Hoffmann]

  Hi,

> > This is not meant for some long-running job which you have to manage.
> >
> > Allowing commands being asynchronous makes sense for things which (a)
> > typically don't take long, and (b) don't need any management.
> >
> > So, if the connection goes down the job is simply canceled, and after
> > reconnecting the management can simply send the same command again.
> 
> Is this worth its own infrastructure?
> 
> Would you hazard a guess on how many commands can take long enough to
> demand a conversion to asynchronous, yet not need any management?

Required:
  screendump with qxl (needs round-drop to spice-server display thread
  for fully up-to-date screen content, due to lazy rendering).

Nice to have:
  Move anything which needs more than a milisecond to a thread or
  coroutine, so we avoid monitor commands causing guest-visible latency
  spikes due to holding the big qemu lock for too long.

  From a quick scan through monitor help hot candidates are screendump
  and pmemsave because they might write rather large data files.

  Dunno about savevm/loadvm.  I think they stop the guest anyway.  So
  moving them to async probably doesn't buy us much, at least from a
  latency point of view.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH v3] monitor: Fix return type of monitor_fdset_dup_fd_find

[Markus Armbruster]

David, got anything queued for the monitor?  If yes, can you stick this
in?  If not, I can handle it.

Yury Kotov  writes:

> monitor_fdset_dup_fd_find_remove() and monitor_fdset_dup_fd_find()
> return mon_fdset->id which is int64_t. Downcasting from int64_t to int
> leads to a bug with removing fd from fdset with id >= 2^32.
> So, fix return types for these function.
>
> Signed-off-by: Yury Kotov 
> Reviewed-by: Markus Armbruster 
> ---
>  include/monitor/monitor.h | 2 +-
>  monitor.c | 4 ++--
>  stubs/fdset.c | 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h
> index 86656297f1..51f048d61f 100644
> --- a/include/monitor/monitor.h
> +++ b/include/monitor/monitor.h
> @@ -45,6 +45,6 @@ AddfdInfo *monitor_fdset_add_fd(int fd, bool has_fdset_id, 
> int64_t fdset_id,
>  int monitor_fdset_get_fd(int64_t fdset_id, int flags);
>  int monitor_fdset_dup_fd_add(int64_t fdset_id, int dup_fd);
>  void monitor_fdset_dup_fd_remove(int dup_fd);
> -int monitor_fdset_dup_fd_find(int dup_fd);
> +int64_t monitor_fdset_dup_fd_find(int dup_fd);
>  
>  #endif /* MONITOR_H */
> diff --git a/monitor.c b/monitor.c
> index 6428eb3b7e..a0e637f7d6 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -2602,7 +2602,7 @@ err:
>  return -1;
>  }
>  
> -static int monitor_fdset_dup_fd_find_remove(int dup_fd, bool remove)
> +static int64_t monitor_fdset_dup_fd_find_remove(int dup_fd, bool remove)
>  {
>  MonFdset *mon_fdset;
>  MonFdsetFd *mon_fdset_fd_dup;
> @@ -2630,7 +2630,7 @@ err:
>  return -1;
>  }
>  
> -int monitor_fdset_dup_fd_find(int dup_fd)
> +int64_t monitor_fdset_dup_fd_find(int dup_fd)
>  {
>  return monitor_fdset_dup_fd_find_remove(dup_fd, false);
>  }
> diff --git a/stubs/fdset.c b/stubs/fdset.c
> index 4f3edf2ea4..a1b8f41f62 100644
> --- a/stubs/fdset.c
> +++ b/stubs/fdset.c
> @@ -7,7 +7,7 @@ int monitor_fdset_dup_fd_add(int64_t fdset_id, int dup_fd)
>  return -1;
>  }
>  
> -int monitor_fdset_dup_fd_find(int dup_fd)
> +int64_t monitor_fdset_dup_fd_find(int dup_fd)
>  {
>  return -1;
>  }

Re: [Qemu-devel] hw/s390x/ipl: Dubious use of qdev_reset_all_fn

[Markus Armbruster]

Peter Maydell  writes:

> On Mon, 27 May 2019 at 08:52, Markus Armbruster  wrote:
>>
>> Peter Maydell  writes:
>> > Suggestions for how to restructure reset so this doesn't
>> > happen are welcome... "reset follows the bus hierarchy"
>> > works well in some places but is a bit weird in others
>> > (for SoC containers and the like "follow the QOM
>> > hierarchy" would make more sense, but I have no idea
>> > how to usefully transition to a model where you could
>> > say "for these devices, follow QOM tree for reset" or
>> > what an API for that would look like).
>>
>> Here's a QOM composition tree for the ARM virt machine (-nodefaults
>> -device e1000) as visible in qom-fuse under /machine, with irq and
>> qemu:memory-region ommitted for brevity:
>
> virt is a bit of an outlier because as a purely-virtual
> machine it has no "SoC" -- it's just a bag of devices
> at the machine level. It would be interesting to
> also look at a machine that's emulating something
> closer to real hardware (eg one of the aspeed machines,
> or mps2-an521).

Can do.

>> Observations:
>>
>> * Composition tree root machine's containers are not in the qtree.
>>
>> * Composition tree node cortex-a15-arm-cpu is not in the qtree.  That's
>>   because it's not a qdev (in QOM parlance: not a TYPE_DEVICE).
>
> Hmm? The Arm CPUs all subclass CPUClass, which subclasses
> DeviceState. The CPU is a qdev, but it is not in the qtree because
> it does not have a bus it can live on.

You're right.

>> Now let me ramble a bit on reset.
>
> Thanks for this -- I have put this on my list to
> think through in detail next week.

Sounds good.

Re: [Qemu-devel] [RFC v4 09/27] memory: Prepare for different kinds of IOMMU MR notifiers

[Peter Xu]

On Mon, May 27, 2019 at 01:41:45PM +0200, Eric Auger wrote:

[...]

> @@ -3368,8 +3368,9 @@ static void vtd_address_space_unmap(VTDAddressSpace 
> *as, IOMMUNotifier *n)
>  {
>  IOMMUTLBEntry entry;
>  hwaddr size;
> -hwaddr start = n->start;
> -hwaddr end = n->end;
> +

(extra new line)

> +hwaddr start = n->iotlb_notifier.start;
> +hwaddr end = n->iotlb_notifier.end;
>  IntelIOMMUState *s = as->iommu_state;
>  DMAMap map;

[...]

>  typedef void (*IOMMUNotify)(struct IOMMUNotifier *notifier,
>  IOMMUTLBEntry *data);
>  
> -struct IOMMUNotifier {
> +typedef struct IOMMUIOLTBNotifier {
>  IOMMUNotify notify;

Hi, Eric,

I wasn't following the thread much before so sorry to ask this if too
late - have you thought about using the Notifier struct direct?
Because then it'll (1) allow the user to register with both IOTLB |
CONFIG flags in the same notifier while currently we'll need to
register one for each (and this worries me a bit on when we grow the
types of flags further then one register can have quite a few
notifiers) (2) the notifier part can be shared by different events.
Then when notify the (void *) data can be an union:

struct IOMMUEvent {
  int event; // can be one of the notifier flags
  union {
struct IOTLBEvent {
  ...
};
struct PASIDEvent {
  ...
};
  }
}

Then the handler hook would be simple too:

handler (data)
{
  switch (data.event) {
...
  }
}

I would be fine with current patch if this series is close to be
merged because even if we want that we can do that on top when we
introduce even more notifiers, but just to ask loud first.

> -IOMMUNotifierFlag notifier_flags;
>  /* Notify for address space range start <= addr <= end */
>  hwaddr start;
>  hwaddr end;
> +} IOMMUIOLTBNotifier;
> +
> +struct IOMMUNotifier {
> +IOMMUNotifierFlag notifier_flags;
> +union {
> +IOMMUIOLTBNotifier iotlb_notifier;
> +};
>  int iommu_idx;
>  QLIST_ENTRY(IOMMUNotifier) node;
>  };
> @@ -126,15 +132,18 @@ typedef struct IOMMUNotifier IOMMUNotifier;
>  /* RAM is a persistent kind memory */
>  #define RAM_PMEM (1 << 5)
>  
> -static inline void iommu_notifier_init(IOMMUNotifier *n, IOMMUNotify fn,
> -   IOMMUNotifierFlag flags,
> -   hwaddr start, hwaddr end,
> -   int iommu_idx)
> +static inline void iommu_iotlb_notifier_init(IOMMUNotifier *n, IOMMUNotify 
> fn,
> + IOMMUNotifierFlag flags,
> + hwaddr start, hwaddr end,
> + int iommu_idx)
>  {
> -n->notify = fn;
> +assert(flags & IOMMU_NOTIFIER_IOTLB_MAP ||
> +   flags & IOMMU_NOTIFIER_IOTLB_UNMAP);

Can use IOMMU_NOTIFIER_IOTLB_ALL directly?

> +assert(start < end);
>  n->notifier_flags = flags;
> -n->start = start;
> -n->end = end;
> +n->iotlb_notifier.notify = fn;
> +n->iotlb_notifier.start = start;
> +n->iotlb_notifier.end = end;
>  n->iommu_idx = iommu_idx;
>  }

Otherwise the patch looks good to me.

Regards,

-- 
Peter Xu

[Qemu-devel] [Bug 1777777] Re: arm9 clock pending (SP804)

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  arm9 clock pending (SP804)

Status in QEMU:
  Expired

Bug description:
  Hello all,

  I'm using the versatilepb board and the timer Interrupt Mask Status
  register (offset 0x14 of the SP804) does not seem to be working
  properly on the latest qemu-2.12. I tried on the 2.5 (i believe this
  is the mainstream version that comes with Linux) and it works
  perfectly.

  What happens is that the pending bit does not seem to be set in some
  scenarios. In my case, I see the timer value decreasing to 0 and then
  being reset to the reload value and neither does the interrupt is
  triggered nor the pending bit is set.

  I believe this is a matter of timing since in the "long" run the
  system eventually catches up (after a few microseconds).

  Thank you

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

[Qemu-devel] [Bug 1817846] Re: Qemu 3.1 Aarch64 TLBI VAE1, x0

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  Qemu 3.1 Aarch64 TLBI VAE1, x0

Status in QEMU:
  Expired

Bug description:
  Hello,

  In my code I'm trying to remove some permissions to a 4KiB MMU
  descriptor. After that I invalidate the MMU with

  TLBI VAE1, x0

  where x0 is the start of the address of the 4 KiB page.

  In Qemu 2.12 this did not work, but I worked around it with:

  
  /* invalidate the address */
  TLBI VAE1, x0

  
  /*/
  /*/
  /* NOTE: THIS IS A TRICK FOR QEMU 
  */
  /* Apparently we have to change the TTBR0_EL1 when we change a descriptor 
(especially to remove permissions) */
  /* Otherwise qemu (2.12) will continue with the same descriptor with 
permissions!  **/
 /*/
 /*/
   
  /* do a trick (in qemu) */
  mrs x1 , TTBR0_EL1

  ldr x2 , =kernelTable0Table

  msr TTBR0_EL1 , x2

  isb

  msr TTBR0_EL1 , x1

  /* return from function */
  ret

  
  That is, I just replaced the TTBR0_EL1 with a temporary value, and then 
restored it. (guess qemu 2.12 just needed to reload the values again).

  However, even this procedure is not working with qemu 3.1. (I just
  tested again with qemu 2.12 and the code works fine, with qemu 3.1 it
  does not).

  Thanks,
  Pharos team

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

Re: [Qemu-devel] [PULL v2 04/36] virtio: Introduce started flag to VirtioDevice

[Yongji Xie]

On Tue, 28 May 2019 at 02:54, Michael S. Tsirkin  wrote:
>
> On Mon, May 27, 2019 at 12:44:46PM +0200, Greg Kurz wrote:
> > On Fri, 24 May 2019 19:56:06 +0800
> > Yongji Xie  wrote:
> >
> > > On Fri, 24 May 2019 at 18:20, Greg Kurz  wrote:
> > > >
> > > > On Mon, 20 May 2019 19:10:35 -0400
> > > > "Michael S. Tsirkin"  wrote:
> > > >
> > > > > From: Xie Yongji 
> > > > >
> > > > > The virtio 1.0 transitional devices support driver uses the device
> > > > > before setting the DRIVER_OK status bit. So we introduce a started
> > > > > flag to indicate whether driver has started the device or not.
> > > > >
> > > > > Signed-off-by: Xie Yongji 
> > > > > Signed-off-by: Zhang Yu 
> > > > > Message-Id: <20190320112646.3712-2-xieyon...@baidu.com>
> > > > > Reviewed-by: Michael S. Tsirkin 
> > > > > Signed-off-by: Michael S. Tsirkin 
> > > > > ---
> > > > >  include/hw/virtio/virtio.h |  2 ++
> > > > >  hw/virtio/virtio.c | 52 
> > > > > --
> > > > >  2 files changed, 52 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> > > > > index 7140381e3a..27c0efc3d0 100644
> > > > > --- a/include/hw/virtio/virtio.h
> > > > > +++ b/include/hw/virtio/virtio.h
> > > > > @@ -105,6 +105,8 @@ struct VirtIODevice
> > > > >  uint16_t device_id;
> > > > >  bool vm_running;
> > > > >  bool broken; /* device in invalid state, needs reset */
> > > > > +bool started;
> > > > > +bool start_on_kick; /* virtio 1.0 transitional devices support 
> > > > > that */
> > > > >  VMChangeStateEntry *vmstate;
> > > > >  char *bus_name;
> > > > >  uint8_t device_endian;
> > > > > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > > > > index 28056a7ef7..5d533ac74e 100644
> > > > > --- a/hw/virtio/virtio.c
> > > > > +++ b/hw/virtio/virtio.c
> > > > > @@ -1162,10 +1162,16 @@ int virtio_set_status(VirtIODevice *vdev, 
> > > > > uint8_t val)
> > > > >  }
> > > > >  }
> > > > >  }
> > > > > +vdev->started = val & VIRTIO_CONFIG_S_DRIVER_OK;
> > > > > +if (unlikely(vdev->start_on_kick && vdev->started)) {
> > > > > +vdev->start_on_kick = false;
> > > > > +}
> > > > > +
> > > > >  if (k->set_status) {
> > > > >  k->set_status(vdev, val);
> > > > >  }
> > > > >  vdev->status = val;
> > > > > +
> > > > >  return 0;
> > > > >  }
> > > > >
> > > > > @@ -1208,6 +1214,9 @@ void virtio_reset(void *opaque)
> > > > >  k->reset(vdev);
> > > > >  }
> > > > >
> > > > > +vdev->start_on_kick = (virtio_host_has_feature(vdev, 
> > > > > VIRTIO_F_VERSION_1) &&
> > > > > +  !virtio_vdev_has_feature(vdev, 
> > > > > VIRTIO_F_VERSION_1));
> > > > > +vdev->started = false;
> > > > >  vdev->broken = false;
> > > > >  vdev->guest_features = 0;
> > > > >  vdev->queue_sel = 0;
> > > > > @@ -1518,14 +1527,21 @@ void virtio_queue_set_align(VirtIODevice 
> > > > > *vdev, int n, int align)
> > > > >
> > > > >  static bool virtio_queue_notify_aio_vq(VirtQueue *vq)
> > > > >  {
> > > > > +bool ret = false;
> > > > > +
> > > > >  if (vq->vring.desc && vq->handle_aio_output) {
> > > > >  VirtIODevice *vdev = vq->vdev;
> > > > >
> > > > >  trace_virtio_queue_notify(vdev, vq - vdev->vq, vq);
> > > > > -return vq->handle_aio_output(vdev, vq);
> > > > > +ret = vq->handle_aio_output(vdev, vq);
> > > > > +
> > > > > +if (unlikely(vdev->start_on_kick)) {
> > > > > +vdev->started = true;
> > > > > +vdev->start_on_kick = false;
> > > > > +}
> > > > >  }
> > > > >
> > > > > -return false;
> > > > > +return ret;
> > > > >  }
> > > > >
> > > > >  static void virtio_queue_notify_vq(VirtQueue *vq)
> > > > > @@ -1539,6 +1555,11 @@ static void virtio_queue_notify_vq(VirtQueue 
> > > > > *vq)
> > > > >
> > > > >  trace_virtio_queue_notify(vdev, vq - vdev->vq, vq);
> > > > >  vq->handle_output(vdev, vq);
> > > > > +
> > > > > +if (unlikely(vdev->start_on_kick)) {
> > > > > +vdev->started = true;
> > > > > +vdev->start_on_kick = false;
> > > > > +}
> > > > >  }
> > > > >  }
> > > > >
> > > > > @@ -1556,6 +1577,11 @@ void virtio_queue_notify(VirtIODevice *vdev, 
> > > > > int n)
> > > > >  } else if (vq->handle_output) {
> > > > >  vq->handle_output(vdev, vq);
> > > > >  }
> > > > > +
> > > > > +if (unlikely(vdev->start_on_kick)) {
> > > > > +vdev->started = true;
> > > > > +vdev->start_on_kick = false;
> > > > > +}
> > > > >  }
> > > > >
> > > > >  uint16_t virtio_queue_vector(VirtIODevice *vdev, int n)
> > > > > @@ -1770,6 +1796,13 @@ static bool virtio_broken_needed(void *opaque)
> > > > >  return vdev->broken;
> > > > >  }
> > > > >
> > > > > +static bool virtio_started_needed(void *opaque)
> > > > > +{
> > > > > +VirtIODevice *vdev = opa

Re: [Qemu-devel] [RFC v4 08/27] hw/vfio/common: Force nested if iommu requires it

[Peter Xu]

On Mon, May 27, 2019 at 01:41:44PM +0200, Eric Auger wrote:
> In case we detect the address space is translated by
> a virtual IOMMU which requires nested stages, let's set up
> the container with the VFIO_TYPE1_NESTING_IOMMU iommu_type.
> 
> Signed-off-by: Eric Auger 
> 
> ---
> 
> v2 -> v3:
> - add "nested only is selected if requested by @force_nested"
>   comment in this patch
> ---
>  hw/vfio/common.c | 27 +++
>  1 file changed, 23 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index 1f1deff360..99ade21056 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -1136,14 +1136,19 @@ static void vfio_put_address_space(VFIOAddressSpace 
> *space)
>   * vfio_get_iommu_type - selects the richest iommu_type (v2 first)
>   */
>  static int vfio_get_iommu_type(VFIOContainer *container,
> +   bool force_nested,
> Error **errp)
>  {
> -int iommu_types[] = { VFIO_TYPE1v2_IOMMU, VFIO_TYPE1_IOMMU,
> +int iommu_types[] = { VFIO_TYPE1_NESTING_IOMMU,
> +  VFIO_TYPE1v2_IOMMU, VFIO_TYPE1_IOMMU,
>VFIO_SPAPR_TCE_v2_IOMMU, VFIO_SPAPR_TCE_IOMMU };
>  int i;
>  
>  for (i = 0; i < ARRAY_SIZE(iommu_types); i++) {
>  if (ioctl(container->fd, VFIO_CHECK_EXTENSION, iommu_types[i])) {
> +if (iommu_types[i] == VFIO_TYPE1_NESTING_IOMMU && !force_nested) 
> {

If force_nested==true and if the kernel does not support
VFIO_TYPE1_NESTING_IOMMU, we will still return other iommu types?
That seems to not match with what "force" mean here.

What I feel like is that we want an "iommu_nest_types[]" which only
contains VFIO_TYPE1_NESTING_IOMMU.  Then:

if (nested) {
target_types = iommu_nest_types;
} else {
target_types = iommu_types;
}

foreach (target_types)
...

return -EINVAL;

Might be clearer?  Then we can drop [2] below since we'll fail earlier
at [1].

> +continue;
> +}
>  return iommu_types[i];
>  }
>  }
> @@ -1152,11 +1157,11 @@ static int vfio_get_iommu_type(VFIOContainer 
> *container,
>  }
>  
>  static int vfio_init_container(VFIOContainer *container, int group_fd,
> -   Error **errp)
> +   bool force_nested, Error **errp)
>  {
>  int iommu_type, ret;
>  
> -iommu_type = vfio_get_iommu_type(container, errp);
> +iommu_type = vfio_get_iommu_type(container, force_nested, errp);
>  if (iommu_type < 0) {
>  return iommu_type;

[1]

>  }
> @@ -1192,6 +1197,14 @@ static int vfio_connect_container(VFIOGroup *group, 
> AddressSpace *as,
>  VFIOContainer *container;
>  int ret, fd;
>  VFIOAddressSpace *space;
> +IOMMUMemoryRegion *iommu_mr;
> +bool force_nested = false;
> +
> +if (as != &address_space_memory && memory_region_is_iommu(as->root)) {
> +iommu_mr = IOMMU_MEMORY_REGION(as->root);
> +memory_region_iommu_get_attr(iommu_mr, IOMMU_ATTR_VFIO_NESTED,
> + (void *)&force_nested);
> +}
>  
>  space = vfio_get_address_space(as);
>  
> @@ -1252,12 +1265,18 @@ static int vfio_connect_container(VFIOGroup *group, 
> AddressSpace *as,
>  QLIST_INIT(&container->giommu_list);
>  QLIST_INIT(&container->hostwin_list);
>  
> -ret = vfio_init_container(container, group->fd, errp);
> +ret = vfio_init_container(container, group->fd, force_nested, errp);
>  if (ret) {
>  goto free_container_exit;
>  }
>  
> +if (force_nested && container->iommu_type != VFIO_TYPE1_NESTING_IOMMU) {
> +error_setg(errp, "nested mode requested by the virtual IOMMU "
> +   "but not supported by the vfio iommu");
> +}

[2]

> +
>  switch (container->iommu_type) {
> +case VFIO_TYPE1_NESTING_IOMMU:
>  case VFIO_TYPE1v2_IOMMU:
>  case VFIO_TYPE1_IOMMU:
>  {
> -- 
> 2.20.1
> 

Regards,

-- 
Peter Xu

Re: [Qemu-devel] [PATCH v2 2/5] i386/cpu: Consolidate die-id validity in smp context

[Like Xu]

On 2019/5/22 1:12, Dr. David Alan Gilbert wrote:

* Like Xu (like...@linux.intel.com) wrote:

Following the legacy smp check rules, the die_id validity is added to
the same contexts as leagcy smp variables such as hmp_hotpluggable_cpus(),
machine_set_cpu_numa_node(), cpu_slot_to_string() and pc_cpu_pre_plug().

Signed-off-by: Like Xu 
---
  hmp.c |  3 +++
  hw/core/machine.c | 12 
  hw/i386/pc.c  | 11 +++
  3 files changed, 26 insertions(+)

diff --git a/hmp.c b/hmp.c
index 56a3ed7375..7deb7b7226 100644
--- a/hmp.c
+++ b/hmp.c
@@ -3112,6 +3112,9 @@ void hmp_hotpluggable_cpus(Monitor *mon, const QDict 
*qdict)
  if (c->has_socket_id) {
  monitor_printf(mon, "socket-id: \"%" PRIu64 "\"\n", 
c->socket_id);
  }
+if (c->has_die_id) {
+monitor_printf(mon, "die-id: \"%" PRIu64 "\"\n", c->die_id);
+}
  if (c->has_core_id) {
  monitor_printf(mon, "core-id: \"%" PRIu64 "\"\n", c->core_id);
  }
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 5d046a43e3..5116429732 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -659,6 +659,11 @@ void machine_set_cpu_numa_node(MachineState *machine,
  return;
  }
  
+if (props->has_die_id && !slot->props.has_die_id) {

+error_setg(errp, "die-id is not supported");
+return;
+}
+
  /* skip slots with explicit mismatch */
  if (props->has_thread_id && props->thread_id != 
slot->props.thread_id) {
  continue;
@@ -668,6 +673,10 @@ void machine_set_cpu_numa_node(MachineState *machine,
  continue;
  }
  
+if (props->has_die_id && props->die_id != slot->props.die_id) {

+continue;
+}
+
  if (props->has_socket_id && props->socket_id != 
slot->props.socket_id) {
  continue;
  }
@@ -925,6 +934,9 @@ static char *cpu_slot_to_string(const CPUArchId *cpu)
  if (cpu->props.has_socket_id) {
  g_string_append_printf(s, "socket-id: %"PRId64, cpu->props.socket_id);
  }
+if (cpu->props.has_die_id) {
+g_string_append_printf(s, "die-id: %"PRId64, cpu->props.die_id);
+}
  if (cpu->props.has_core_id) {
  if (s->len) {
  g_string_append_printf(s, ", ");
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 83ab53c814..00be2463af 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -2321,6 +2321,10 @@ static void pc_cpu_pre_plug(HotplugHandler *hotplug_dev,
  error_setg(errp, "Invalid CPU socket-id: %u must be in range 
0:%u",
 cpu->socket_id, max_socket);
  return;
+} else if (cpu->die_id > max_socket) {
+error_setg(errp, "Invalid CPU die-id: %u must be in range 0:%u",
+   cpu->die_id, max_socket);
+return;


Can you explain why the die_id is related to max_socket?
I'd assumed you could have a 2 socket system where each socket has 4
dies.


Dr David,thanks for your comments and sorry for the slow reply.

You're right about this and the check rule for cpu->die_id in 
pc_cpu_pre_plug() should be:


"else if (cpu->die_id > (pcms->smp_dies - 1))"



However, for the HMP side of it:


Acked-by: Dr. David Alan Gilbert 


  }
  if (cpu->core_id < 0) {
  error_setg(errp, "CPU core-id is not set");
@@ -2378,6 +2382,13 @@ static void pc_cpu_pre_plug(HotplugHandler *hotplug_dev,
  }
  cpu->socket_id = topo.pkg_id;
  
+if (cpu->die_id != -1 && cpu->die_id != topo.die_id) {

+error_setg(errp, "property die-id: %u doesn't match set apic-id:"
+" 0x%x (die-id: %u)", cpu->die_id, cpu->apic_id, topo.die_id);
+return;
+}
+cpu->die_id = topo.die_id;
+
  if (cpu->core_id != -1 && cpu->core_id != topo.core_id) {
  error_setg(errp, "property core-id: %u doesn't match set apic-id:"
  " 0x%x (core-id: %u)", cpu->core_id, cpu->apic_id, topo.core_id);
--
2.21.0


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

[Qemu-devel] [PATCH 4/4] migration/ram.c: multifd_send_state->count is not really used

[Wei Yang]

Signed-off-by: Wei Yang 
---
 migration/ram.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 5d31f7bd4c..c9a9f7489b 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -892,8 +892,6 @@ static int multifd_recv_unfill_packet(MultiFDRecvParams *p, 
Error **errp)
 
 struct {
 MultiFDSendParams *params;
-/* number of created threads */
-int count;
 /* array of pages to sent */
 MultiFDPages_t *pages;
 /* syncs main thread and channels */
@@ -1171,8 +1169,6 @@ static void multifd_new_send_channel_async(QIOTask *task, 
gpointer opaque)
 p->running = true;
 qemu_thread_create(&p->thread, p->name, multifd_send_thread, p,
QEMU_THREAD_JOINABLE);
-
-atomic_inc(&multifd_send_state->count);
 }
 }
 
@@ -1188,7 +1184,6 @@ int multifd_save_setup(void)
 thread_count = migrate_multifd_channels();
 multifd_send_state = g_malloc0(sizeof(*multifd_send_state));
 multifd_send_state->params = g_new0(MultiFDSendParams, thread_count);
-atomic_set(&multifd_send_state->count, 0);
 multifd_send_state->pages = multifd_pages_init(page_count);
 qemu_sem_init(&multifd_send_state->sem_sync, 0);
 qemu_sem_init(&multifd_send_state->channels_ready, 0);
-- 
2.19.1

[Qemu-devel] [PATCH 3/4] migration/ram.c: MultiFDSendParams.sem_sync is not really used

[Wei Yang]

Besides init and destroy, MultiFDSendParams.sem_sync is not really used.

Signed-off-by: Wei Yang 
---
 migration/ram.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index dcf4c54eb5..5d31f7bd4c 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -661,8 +661,6 @@ typedef struct {
 uint64_t num_packets;
 /* pages sent through this channel */
 uint64_t num_pages;
-/* syncs main thread and channels */
-QemuSemaphore sem_sync;
 }  MultiFDSendParams;
 
 typedef struct {
@@ -1027,7 +1025,6 @@ void multifd_save_cleanup(void)
 p->c = NULL;
 qemu_mutex_destroy(&p->mutex);
 qemu_sem_destroy(&p->sem);
-qemu_sem_destroy(&p->sem_sync);
 g_free(p->name);
 p->name = NULL;
 multifd_pages_clear(p->pages);
@@ -1201,7 +1198,6 @@ int multifd_save_setup(void)
 
 qemu_mutex_init(&p->mutex);
 qemu_sem_init(&p->sem, 0);
-qemu_sem_init(&p->sem_sync, 0);
 p->quit = false;
 p->pending_job = 0;
 p->id = i;
-- 
2.19.1

[Qemu-devel] [PATCH 2/4] migration/ram.c: use same type in MultiFDPages_t to define offsest

[Wei Yang]

MultiFDPacket_t.offset is allocated to store MultiFDPages_t.offset.

It would be better to use the same type.

Signed-off-by: Wei Yang 
---
 migration/ram.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/migration/ram.c b/migration/ram.c
index 4c60869226..dcf4c54eb5 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -607,7 +607,7 @@ typedef struct {
 uint64_t packet_num;
 uint64_t unused[4];/* Reserved for future use */
 char ramblock[256];
-uint64_t offset[];
+ram_addr_t offset[];
 } __attribute__((packed)) MultiFDPacket_t;
 
 typedef struct {
-- 
2.19.1

[Qemu-devel] [PATCH 1/4] migration: multifd_save_setup always return 0

[Wei Yang]

Signed-off-by: Wei Yang 
---
 migration/migration.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/migration/migration.c b/migration/migration.c
index d0a0f68f11..3aae4f2734 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -3336,12 +3336,7 @@ void migrate_fd_connect(MigrationState *s, Error 
*error_in)
 return;
 }
 
-if (multifd_save_setup() != 0) {
-migrate_set_state(&s->state, MIGRATION_STATUS_SETUP,
-  MIGRATION_STATUS_FAILED);
-migrate_fd_cleanup(s);
-return;
-}
+multifd_save_setup();
 qemu_thread_create(&s->thread, "live_migration", migration_thread, s,
QEMU_THREAD_JOINABLE);
 s->migration_thread_running = true;
-- 
2.19.1

[Qemu-devel] [PATCH 0/4] Multifd Cleanup

[Wei Yang]

Just found several small places for unused variables.

Wei Yang (4):
  migration: multifd_save_setup always return 0
  migration/ram.c: use same type in MultiFDPages_t to define offsest
  migration/ram.c: MultiFDSendParams.sem_sync is not really used
  migration/ram.c: multifd_send_state->count is not really used

 migration/migration.c |  7 +--
 migration/ram.c   | 11 +--
 2 files changed, 2 insertions(+), 16 deletions(-)

-- 
2.19.1

Re: [Qemu-devel] [PATCH] hw/i386/pc: check apci hotplug capability before nvdimm's

[Wei Yang]

On Mon, May 27, 2019 at 02:21:14PM +0200, Igor Mammedov wrote:
>On Thu, 11 Apr 2019 15:17:39 +0800
>Wei Yang  wrote:
>
>> pc_memory_pre_plug() is called during hotplug for both pc-dimm and
>> nvdimm. This is more proper to check apci hotplug capability before
>> check nvdimm specific capability.
>not sure what this about.
>Currently we are checking if ACPI is enabled
>  if (!pcms->acpi_dev || !acpi_enabled) { ...
>before nvdimm check and it looks better to me that we cancel
>nvdimm hotplug earlier than passing it to
>hotplug_handler_pre_plug(pcms->acpi_dev, dev, &local_err)
>with this patch ACPI device handler will be called before
>nvdimm check happens, so it's +1 unnecessary call chain in
>the case of nvdimm, which I'd rather not have.
>
>Are there any issues with current call flow?
>(commit message doesn't really explaining why we need this patch)
>

My idea is to check more generic requirement and then specific one.

For example, the call flow looks like this:

pc_memory_pre_plug

piix4_device_pre_plug_cb | ich9_pm_device_pre_plug_cb
if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM) &&
!lpc->pm.acpi_memory_hotplug.is_enabled)

if (is_nvdimm && !ms->nvdimms_state->is_enabled)


In hotplug_handler_pre_plug(), it checks the acpi hotplug capability. And then
if it has memory hotplug capability and is nvdimm, we check whether nvdimm is
enabled.

This is why I suggest to change the order here. No functional issue for
current code.

-- 
Wei Yang
Help you, Help me

Re: [Qemu-devel] [PATCH] ppc/pnv: introduce new skiboot platform properties

[David Gibson]

On Mon, May 27, 2019 at 09:17:49AM +0200, Cédric Le Goater wrote:
> Newer skiboots (after 6.3) support QEMU platforms that have
> characteristics closer to real OpenPOWER systems. The CPU type is used
> to define the BMC drivers: Aspeed AST2400 for POWER8 processors and
> AST2500 for POWER9s.
> 
> Advertise the new platform property names, "qemu,powernv8" and
> "qemu,powernv9", using the CPU type chosen for the QEMU PowerNV
> machine. Also, advertise the original platform name "qemu,powernv" in
> case of POWER8 processors for compatibility with older skiboots.
> 
> Signed-off-by: Cédric Le Goater 

Applied, thanks.

> ---
>  hw/ppc/pnv.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
> index dfb4ea5742c1..1f22cbf833a8 100644
> --- a/hw/ppc/pnv.c
> +++ b/hw/ppc/pnv.c
> @@ -450,7 +450,8 @@ static void pnv_dt_power_mgt(void *fdt)
>  
>  static void *pnv_dt_create(MachineState *machine)
>  {
> -const char plat_compat[] = "qemu,powernv\0ibm,powernv";
> +const char plat_compat8[] = "qemu,powernv8\0qemu,powernv\0ibm,powernv";
> +const char plat_compat9[] = "qemu,powernv9\0ibm,powernv";
>  PnvMachineState *pnv = PNV_MACHINE(machine);
>  void *fdt;
>  char *buf;
> @@ -465,8 +466,14 @@ static void *pnv_dt_create(MachineState *machine)
>  _FDT((fdt_setprop_cell(fdt, 0, "#size-cells", 0x2)));
>  _FDT((fdt_setprop_string(fdt, 0, "model",
>   "IBM PowerNV (emulated by qemu)")));
> -_FDT((fdt_setprop(fdt, 0, "compatible", plat_compat,
> -  sizeof(plat_compat;
> +if (pnv_is_power9(pnv)) {
> +_FDT((fdt_setprop(fdt, 0, "compatible", plat_compat9,
> +  sizeof(plat_compat9;
> +} else {
> +_FDT((fdt_setprop(fdt, 0, "compatible", plat_compat8,
> +  sizeof(plat_compat8;
> +}
> +
>  
>  buf =  qemu_uuid_unparse_strdup(&qemu_uuid);
>  _FDT((fdt_setprop_string(fdt, 0, "vm,uuid", buf)));

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH v2] target/ppc: Fix lxvw4x, lxvh8x and lxvb16x

[David Gibson]

On Fri, May 24, 2019 at 07:53:45AM +0100, Mark Cave-Ayland wrote:
> From: Anton Blanchard 
> 
> During the conversion these instructions were incorrectly treated as
> stores. We need to use set_cpu_vsr* and not get_cpu_vsr*.
> 
> Fixes: 8b3b2d75c7c0 ("introduce get_cpu_vsr{l,h}() and set_cpu_vsr{l,h}() 
> helpers for VSR register access")
> Signed-off-by: Anton Blanchard 
> Reviewed-by: Mark Cave-Ayland 
> Tested-by: Greg Kurz 
> Reviewed-by: Greg Kurz 

Applied, thanks.

> ---
>  target/ppc/translate/vsx-impl.inc.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/target/ppc/translate/vsx-impl.inc.c 
> b/target/ppc/translate/vsx-impl.inc.c
> index 199d22da97..cdb44b8b70 100644
> --- a/target/ppc/translate/vsx-impl.inc.c
> +++ b/target/ppc/translate/vsx-impl.inc.c
> @@ -102,8 +102,7 @@ static void gen_lxvw4x(DisasContext *ctx)
>  }
>  xth = tcg_temp_new_i64();
>  xtl = tcg_temp_new_i64();
> -get_cpu_vsrh(xth, xT(ctx->opcode));
> -get_cpu_vsrl(xtl, xT(ctx->opcode));
> +
>  gen_set_access_type(ctx, ACCESS_INT);
>  EA = tcg_temp_new();
>  
> @@ -126,6 +125,8 @@ static void gen_lxvw4x(DisasContext *ctx)
>  tcg_gen_addi_tl(EA, EA, 8);
>  tcg_gen_qemu_ld_i64(xtl, EA, ctx->mem_idx, MO_BEQ);
>  }
> +set_cpu_vsrh(xT(ctx->opcode), xth);
> +set_cpu_vsrl(xT(ctx->opcode), xtl);
>  tcg_temp_free(EA);
>  tcg_temp_free_i64(xth);
>  tcg_temp_free_i64(xtl);
> @@ -185,8 +186,6 @@ static void gen_lxvh8x(DisasContext *ctx)
>  }
>  xth = tcg_temp_new_i64();
>  xtl = tcg_temp_new_i64();
> -get_cpu_vsrh(xth, xT(ctx->opcode));
> -get_cpu_vsrl(xtl, xT(ctx->opcode));
>  gen_set_access_type(ctx, ACCESS_INT);
>  
>  EA = tcg_temp_new();
> @@ -197,6 +196,8 @@ static void gen_lxvh8x(DisasContext *ctx)
>  if (ctx->le_mode) {
>  gen_bswap16x8(xth, xtl, xth, xtl);
>  }
> +set_cpu_vsrh(xT(ctx->opcode), xth);
> +set_cpu_vsrl(xT(ctx->opcode), xtl);
>  tcg_temp_free(EA);
>  tcg_temp_free_i64(xth);
>  tcg_temp_free_i64(xtl);
> @@ -214,14 +215,14 @@ static void gen_lxvb16x(DisasContext *ctx)
>  }
>  xth = tcg_temp_new_i64();
>  xtl = tcg_temp_new_i64();
> -get_cpu_vsrh(xth, xT(ctx->opcode));
> -get_cpu_vsrl(xtl, xT(ctx->opcode));
>  gen_set_access_type(ctx, ACCESS_INT);
>  EA = tcg_temp_new();
>  gen_addr_reg_index(ctx, EA);
>  tcg_gen_qemu_ld_i64(xth, EA, ctx->mem_idx, MO_BEQ);
>  tcg_gen_addi_tl(EA, EA, 8);
>  tcg_gen_qemu_ld_i64(xtl, EA, ctx->mem_idx, MO_BEQ);
> +set_cpu_vsrh(xT(ctx->opcode), xth);
> +set_cpu_vsrl(xT(ctx->opcode), xtl);
>  tcg_temp_free(EA);
>  tcg_temp_free_i64(xth);
>  tcg_temp_free_i64(xtl);

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH] ppc/pnv: add dummy XSCOM registers for PRD initialization

[David Gibson]

On Mon, May 27, 2019 at 09:17:22AM +0200, Cédric Le Goater wrote:
> PRD (Processor recovery diagnostics) is a service available on
> OpenPower systems. The opal-prd daemon initializes the PowerPC
> Processor through the XSCOM bus and then waits for hardware diagnostic
> events.
> 
> Signed-off-by: Cédric Le Goater 

Applied, thanks.

> ---
>  hw/ppc/pnv_xscom.c | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/hw/ppc/pnv_xscom.c b/hw/ppc/pnv_xscom.c
> index c285ef514e88..f53a6d7a9457 100644
> --- a/hw/ppc/pnv_xscom.c
> +++ b/hw/ppc/pnv_xscom.c
> @@ -29,6 +29,12 @@
>  
>  #include 
>  
> +/* PRD registers */
> +#define PRD_P8_IPOLL_REG_MASK   0x01020013
> +#define PRD_P8_IPOLL_REG_STATUS 0x01020014
> +#define PRD_P9_IPOLL_REG_MASK   0x000F0033
> +#define PRD_P9_IPOLL_REG_STATUS 0x000F0034
> +
>  static void xscom_complete(CPUState *cs, uint64_t hmer_bits)
>  {
>  /*
> @@ -70,6 +76,12 @@ static uint64_t xscom_read_default(PnvChip *chip, uint32_t 
> pcba)
>  case 0x1010c00: /* PIBAM FIR */
>  case 0x1010c03: /* PIBAM FIR MASK */
>  
> +/* PRD registers */
> +case PRD_P8_IPOLL_REG_MASK:
> +case PRD_P8_IPOLL_REG_STATUS:
> +case PRD_P9_IPOLL_REG_MASK:
> +case PRD_P9_IPOLL_REG_STATUS:
> +
>  /* P9 xscom reset */
>  case 0x0090018: /* Receive status reg */
>  case 0x0090012: /* log register */
> @@ -124,6 +136,12 @@ static bool xscom_write_default(PnvChip *chip, uint32_t 
> pcba, uint64_t val)
>  case 0x201302a: /* CAPP stuff */
>  case 0x2013801: /* CAPP stuff */
>  case 0x2013802: /* CAPP stuff */
> +
> +/* P8 PRD registers */
> +case PRD_P8_IPOLL_REG_MASK:
> +case PRD_P8_IPOLL_REG_STATUS:
> +case PRD_P9_IPOLL_REG_MASK:
> +case PRD_P9_IPOLL_REG_STATUS:
>  return true;
>  default:
>  return false;

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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PULL v2 04/36] virtio: Introduce started flag to VirtioDevice

[David Gibson]

On Fri, May 24, 2019 at 12:19:09PM +0200, Greg Kurz wrote:
> On Mon, 20 May 2019 19:10:35 -0400
> "Michael S. Tsirkin"  wrote:
> 
> > From: Xie Yongji 
> > 
> > The virtio 1.0 transitional devices support driver uses the device
> > before setting the DRIVER_OK status bit. So we introduce a started
> > flag to indicate whether driver has started the device or not.
> > 
> > Signed-off-by: Xie Yongji 
> > Signed-off-by: Zhang Yu 
> > Message-Id: <20190320112646.3712-2-xieyon...@baidu.com>
> > Reviewed-by: Michael S. Tsirkin 
> > Signed-off-by: Michael S. Tsirkin 
> > ---
> >  include/hw/virtio/virtio.h |  2 ++
> >  hw/virtio/virtio.c | 52 --
> >  2 files changed, 52 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> > index 7140381e3a..27c0efc3d0 100644
> > --- a/include/hw/virtio/virtio.h
> > +++ b/include/hw/virtio/virtio.h
> > @@ -105,6 +105,8 @@ struct VirtIODevice
> >  uint16_t device_id;
> >  bool vm_running;
> >  bool broken; /* device in invalid state, needs reset */
> > +bool started;
> > +bool start_on_kick; /* virtio 1.0 transitional devices support that */
> >  VMChangeStateEntry *vmstate;
> >  char *bus_name;
> >  uint8_t device_endian;
> > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > index 28056a7ef7..5d533ac74e 100644
> > --- a/hw/virtio/virtio.c
> > +++ b/hw/virtio/virtio.c
> > @@ -1162,10 +1162,16 @@ int virtio_set_status(VirtIODevice *vdev, uint8_t 
> > val)
> >  }
> >  }
> >  }
> > +vdev->started = val & VIRTIO_CONFIG_S_DRIVER_OK;
> > +if (unlikely(vdev->start_on_kick && vdev->started)) {
> > +vdev->start_on_kick = false;
> > +}
> > +
> >  if (k->set_status) {
> >  k->set_status(vdev, val);
> >  }
> >  vdev->status = val;
> > +
> >  return 0;
> >  }
> >  
> > @@ -1208,6 +1214,9 @@ void virtio_reset(void *opaque)
> >  k->reset(vdev);
> >  }
> >  
> > +vdev->start_on_kick = (virtio_host_has_feature(vdev, 
> > VIRTIO_F_VERSION_1) &&
> > +  !virtio_vdev_has_feature(vdev, 
> > VIRTIO_F_VERSION_1));
> > +vdev->started = false;
> >  vdev->broken = false;
> >  vdev->guest_features = 0;
> >  vdev->queue_sel = 0;
> > @@ -1518,14 +1527,21 @@ void virtio_queue_set_align(VirtIODevice *vdev, int 
> > n, int align)
> >  
> >  static bool virtio_queue_notify_aio_vq(VirtQueue *vq)
> >  {
> > +bool ret = false;
> > +
> >  if (vq->vring.desc && vq->handle_aio_output) {
> >  VirtIODevice *vdev = vq->vdev;
> >  
> >  trace_virtio_queue_notify(vdev, vq - vdev->vq, vq);
> > -return vq->handle_aio_output(vdev, vq);
> > +ret = vq->handle_aio_output(vdev, vq);
> > +
> > +if (unlikely(vdev->start_on_kick)) {
> > +vdev->started = true;
> > +vdev->start_on_kick = false;
> > +}
> >  }
> >  
> > -return false;
> > +return ret;
> >  }
> >  
> >  static void virtio_queue_notify_vq(VirtQueue *vq)
> > @@ -1539,6 +1555,11 @@ static void virtio_queue_notify_vq(VirtQueue *vq)
> >  
> >  trace_virtio_queue_notify(vdev, vq - vdev->vq, vq);
> >  vq->handle_output(vdev, vq);
> > +
> > +if (unlikely(vdev->start_on_kick)) {
> > +vdev->started = true;
> > +vdev->start_on_kick = false;
> > +}
> >  }
> >  }
> >  
> > @@ -1556,6 +1577,11 @@ void virtio_queue_notify(VirtIODevice *vdev, int n)
> >  } else if (vq->handle_output) {
> >  vq->handle_output(vdev, vq);
> >  }
> > +
> > +if (unlikely(vdev->start_on_kick)) {
> > +vdev->started = true;
> > +vdev->start_on_kick = false;
> > +}
> >  }
> >  
> >  uint16_t virtio_queue_vector(VirtIODevice *vdev, int n)
> > @@ -1770,6 +1796,13 @@ static bool virtio_broken_needed(void *opaque)
> >  return vdev->broken;
> >  }
> >  
> > +static bool virtio_started_needed(void *opaque)
> > +{
> > +VirtIODevice *vdev = opaque;
> > +
> > +return vdev->started;
> 
> Existing machine types don't know about the "virtio/started" subsection. This
> breaks migration to older QEMUs if the driver has started the device, ie. most
> probably always when it comes to live migration.
> 
> My understanding is that we do try to support backward migration though. It
> is a regular practice in datacenters to migrate workloads without having to
> take care of the QEMU version. FWIW I had to fix similar issues downstream
> many times in the past because customers had filed bugs.
> 
> Cc'ing David for his opinion.

Uh.. did you mean to CC me, or Dave Gilbert?

I mean, I think you're right that we should try to maintain backwards
migration, but this isn't really my area of authority.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
   

Re: [Qemu-devel] [PATCH v3 0/7] Kconfig dependencies for MIPS machines (but Malta)

[Philippe Mathieu-Daudé]

Hi Aleksandar,

On 5/27/19 8:31 PM, Aleksandar Markovic wrote:
> 
> On Mar 11, 2019 1:56 AM, "Philippe Mathieu-Daudé"  > wrote:
>>
>> Express the MIPS machine dependencies with Kconfig.
>>
>> Due to its complexity, the Malta board fill follow in a different
>> series.
>>
> 
> Philippe,
> 
> What would be the status of this series? I am willing to integrate all
> this, including all followups, but have hard time sorting out what
> happend after this submission, what is the most complete version etc.
> Can you enlighten me please?

Thanks for your interest in this series :)

I was chatting with Thomas about this series earlier today!
I addressed your comment about the ITU/CPS devices, then wanted to join
all the Malta patches in the same series, but there are too many for a
single series so I'll keep them separate.
About Malta, I can do it two ways: one quick and dirty, and one clean
but long. Problem with long series is they can take too long before
landing. I'm trying to figure a quick but not that dirty way to solve
this, then we can improve later.

I'll resend during the week.

Regards,

Phil.

Re: [Qemu-devel] [PATCH v6] hw/acpi: extract acpi_add_rom_blob()

[Wei Yang]

On Mon, May 27, 2019 at 10:41:57AM -0400, Michael S. Tsirkin wrote:
>On Mon, May 27, 2019 at 10:34:23AM +0800, Wei Yang wrote:
>> On Tue, Mar 26, 2019 at 10:43:20AM +0800, Wei Yang wrote:
>> >arm and i386 has almost the same function acpi_add_rom_blob(), except
>> >giving different FWCfgCallback function.
>> >
>> >This patch moves acpi_add_rom_blob() to utils.c by passing
>> >FWCfgCallback to it.
>> >
>> >Signed-off-by: Wei Yang 
>> >Reviewed-by: Igor Mammedov 
>> >
>> 
>> Hello~ would this one be picked up?
>
>
>Yes in the next pull. It's a holiday here in states -
>hopefully tomorrow.
>

Ah, thanks~ Happy holiday~

>> >---
>> >v6:
>> >  * change author from Igor to Michael
>> >v5:
>> >  * remove unnecessary header glib/gprintf.h
>> >  * rearrange include header to make it more suitable
>> >v4:
>> >  * extract -> moves
>> >  * adjust comment in source to make checkpatch happy
>> >v3:
>> >  * put acpi_add_rom_blob() to hw/acpi/utils.c
>> >v2:
>> >  * remove unused header in original source file
>> >
>> >author
>> >---
>> > hw/acpi/Makefile.objs|  2 +-
>> > hw/acpi/utils.c  | 36 
>> > hw/arm/virt-acpi-build.c | 26 ++
>> > hw/i386/acpi-build.c | 26 ++
>> > include/hw/acpi/utils.h  |  9 +
>> > 5 files changed, 66 insertions(+), 33 deletions(-)
>> > create mode 100644 hw/acpi/utils.c
>> > create mode 100644 include/hw/acpi/utils.h
>> >
>> >diff --git a/hw/acpi/Makefile.objs b/hw/acpi/Makefile.objs
>> >index 2d46e3789a..ba93c5b64a 100644
>> >--- a/hw/acpi/Makefile.objs
>> >+++ b/hw/acpi/Makefile.objs
>> >@@ -10,7 +10,7 @@ common-obj-$(call lnot,$(CONFIG_ACPI_X86)) += acpi-stub.o
>> > 
>> > common-obj-y += acpi_interface.o
>> > common-obj-y += bios-linker-loader.o
>> >-common-obj-y += aml-build.o
>> >+common-obj-y += aml-build.o utils.o
>> > common-obj-$(CONFIG_TPM) += tpm.o
>> > 
>> > common-obj-$(CONFIG_IPMI) += ipmi.o
>> >diff --git a/hw/acpi/utils.c b/hw/acpi/utils.c
>> >new file mode 100644
>> >index 00..77b9e8148f
>> >--- /dev/null
>> >+++ b/hw/acpi/utils.c
>> >@@ -0,0 +1,36 @@
>> >+/*
>> >+ * Utilities for generating ACPI tables and passing them to Guests
>> >+ *
>> >+ * Copyright (C) 2019 Intel Corporation
>> >+ * Copyright (C) 2019 Red Hat Inc
>> >+ *
>> >+ * Author: Wei Yang 
>> >+ * Author: Michael S. Tsirkin 
>> >+ *
>> >+ * This program 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.
>> >+
>> >+ * This program 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 General Public License for more details.
>> >+
>> >+ * You should have received a copy of the GNU General Public License along
>> >+ * with this program; if not, see .
>> >+ */
>> >+
>> >+#include "qemu/osdep.h"
>> >+#include "hw/acpi/aml-build.h"
>> >+#include "hw/acpi/utils.h"
>> >+#include "hw/loader.h"
>> >+
>> >+MemoryRegion *acpi_add_rom_blob(FWCfgCallback update, void *opaque,
>> >+GArray *blob, const char *name,
>> >+uint64_t max_size)
>> >+{
>> >+return rom_add_blob(name, blob->data, acpi_data_len(blob), max_size, 
>> >-1,
>> >+name, update, opaque, NULL, true);
>> >+}
>> >+
>> >diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
>> >index 57679a89bf..a846f74a14 100644
>> >--- a/hw/arm/virt-acpi-build.c
>> >+++ b/hw/arm/virt-acpi-build.c
>> >@@ -37,9 +37,9 @@
>> > #include "hw/acpi/acpi.h"
>> > #include "hw/nvram/fw_cfg.h"
>> > #include "hw/acpi/bios-linker-loader.h"
>> >-#include "hw/loader.h"
>> > #include "hw/hw.h"
>> > #include "hw/acpi/aml-build.h"
>> >+#include "hw/acpi/utils.h"
>> > #include "hw/pci/pcie_host.h"
>> > #include "hw/pci/pci.h"
>> > #include "hw/arm/virt.h"
>> >@@ -881,14 +881,6 @@ static void virt_acpi_build_reset(void *build_opaque)
>> > build_state->patched = false;
>> > }
>> > 
>> >-static MemoryRegion *acpi_add_rom_blob(AcpiBuildState *build_state,
>> >-   GArray *blob, const char *name,
>> >-   uint64_t max_size)
>> >-{
>> >-return rom_add_blob(name, blob->data, acpi_data_len(blob), max_size, 
>> >-1,
>> >-name, virt_acpi_build_update, build_state, NULL, 
>> >true);
>> >-}
>> >-
>> > static const VMStateDescription vmstate_virt_acpi_build = {
>> > .name = "virt_acpi_build",
>> > .version_id = 1,
>> >@@ -920,20 +912,22 @@ void virt_acpi_setup(VirtMachineState *vms)
>> > virt_acpi_build(vms, &tables);
>> > 
>> > /* Now expose it all to Guest */
>> >-build_state->table_mr = acpi_add_rom_blob(bui

Re: [Qemu-devel] [PATCH] The m68k gdbstub SR reg request doesnt include Condition-Codes

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20190526074527.33632-1-lucienmp_antis...@yahoo.com/



Hi,

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

Subject: [Qemu-devel] [PATCH] The m68k gdbstub SR reg request doesnt include 
Condition-Codes
Message-id: 20190526074527.33632-1-lucienmp_antis...@yahoo.com
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
d12cb52 The m68k gdbstub SR reg request doesnt include Condition-Codes

=== OUTPUT BEGIN ===
ERROR: Author email address is mangled by the mailing list
#2: 
Author: Lucien Murray-Pitts via Qemu-devel 

total: 1 errors, 0 warnings, 12 lines checked

Commit d12cb52d6c7f (The m68k gdbstub SR reg request doesnt include 
Condition-Codes) has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20190526074527.33632-1-lucienmp_antis...@yahoo.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-devel] [PATCH v3 0/8] Add support for io_uring

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20190527080327.10780-1-mehta.aar...@gmail.com/



Hi,

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

Message-id: 20190527080327.10780-1-mehta.aar...@gmail.com
Type: series
Subject: [Qemu-devel] [PATCH v3 0/8] Add support for io_uring

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Switched to a new branch 'test'
625697e block/fileposix: extend to use io_uring
33cf8a8 blockdev: accept io_uring as option
1b7e8c0 util/async: add aio interfaces for io_uring
5656038 stubs: add stubs for io_uring interface
74252d4 block/io_uring: implements interfaces for io_uring
209ccc1 block/block: add BDRV flag for io_uring
c577217 qapi/block-core: add option for io_uring
f4d0501 configure: permit use of io_uring

=== OUTPUT BEGIN ===
1/8 Checking commit f4d0501f0165 (configure: permit use of io_uring)
2/8 Checking commit c5772171ddad (qapi/block-core: add option for io_uring)
3/8 Checking commit 209ccc1aca54 (block/block: add BDRV flag for io_uring)
4/8 Checking commit 74252d4f4849 (block/io_uring: implements interfaces for 
io_uring)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#49: 
new file mode 100644

ERROR: space required before the open parenthesis '('
#196: FILE: block/io_uring.c:143:
+while(!s->io_q.in_queue) {

ERROR: trailing whitespace
#209: FILE: block/io_uring.c:156:
+if (ret <= 0) { $

total: 2 errors, 1 warnings, 387 lines checked

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

5/8 Checking commit 565603840362 (stubs: add stubs for io_uring interface)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#35: 
new file mode 100644

total: 0 errors, 1 warnings, 46 lines checked

Patch 5/8 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
6/8 Checking commit 1b7e8c0b9826 (util/async: add aio interfaces for io_uring)
7/8 Checking commit 33cf8a8d4a0d (blockdev: accept io_uring as option)
8/8 Checking commit 625697ed2891 (block/fileposix: extend to use io_uring)
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20190527080327.10780-1-mehta.aar...@gmail.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-devel] How do we do user input bitmap properties?

[Eduardo Habkost]

On Mon, May 27, 2019 at 06:29:44PM +0200, Andrea Bolognani wrote:
> On Fri, 2019-05-24 at 15:24 -0300, Eduardo Habkost wrote:
> > On Thu, May 23, 2019 at 10:35:24AM +0200, Andrea Bolognani wrote:
> > > [...] the above looks good to
> > > me as a general direction, but note that you'll have to implement at
> > > the very least the query-cpu-model-expansion QMP command for the
> > > introspection to work.
> > 
> > Why is query-cpu-model-expansion needed?  Isn't
> > device-list-properties enough?
> 
> Good question.
> 
> I'll have to check with Jirka, but from playing with both commands
> it looks like the latter returns a superset of what the former does,
> so for the purpose of figuring out which vector lengths the QEMU
> binary recognizes it should be good enough; I suspect, however, that
> query-cpu-model-expansion might be (made to be) smarter and for
> example not report vector lengths that the underlying hardware
> doesn't support, which would be valuable for the purpose of user
> friendly error reporting and allowing applications to decide which
> vector lengths to request when creating guests.

Yes, query-cpu-model-expansion returns additional information, so
it depends on what exactly you are looking for.

If you want to know which properties a given QEMU binary supports
in the command-line, `device-list-properties` is supposed to be
enough.  If you need to know which properties can be really
enabled in a given host (based on QEMU+KVM+hardware
capabilities), you'll need `query-cpu-model-expansion model=max`.

-- 
Eduardo

Re: [Qemu-devel] Running linux on qemu omap

[Peter Maydell]

On Mon, 27 May 2019 at 16:56, Guenter Roeck  wrote:
> I'd be happy to use a different (supported) branch, but the Linaro branch
> was the only one I could find that supports those boards. Unfortunately,
> qemu changed so much since 2.3 that it is all but impossible to merge
> the code into mainline qemu without spending a lot of effort on it.

Even back at 2.3 it wasn't possible to merge the code into mainline
without spending a lot of effort -- that's why it was not merged :-)

thanks
-- PMM

Re: [Qemu-devel] hw/s390x/ipl: Dubious use of qdev_reset_all_fn

[Peter Maydell]

On Mon, 27 May 2019 at 08:52, Markus Armbruster  wrote:
>
> Peter Maydell  writes:
> > Suggestions for how to restructure reset so this doesn't
> > happen are welcome... "reset follows the bus hierarchy"
> > works well in some places but is a bit weird in others
> > (for SoC containers and the like "follow the QOM
> > hierarchy" would make more sense, but I have no idea
> > how to usefully transition to a model where you could
> > say "for these devices, follow QOM tree for reset" or
> > what an API for that would look like).
>
> Here's a QOM composition tree for the ARM virt machine (-nodefaults
> -device e1000) as visible in qom-fuse under /machine, with irq and
> qemu:memory-region ommitted for brevity:

virt is a bit of an outlier because as a purely-virtual
machine it has no "SoC" -- it's just a bag of devices
at the machine level. It would be interesting to
also look at a machine that's emulating something
closer to real hardware (eg one of the aspeed machines,
or mps2-an521).

> Observations:
>
> * Composition tree root machine's containers are not in the qtree.
>
> * Composition tree node cortex-a15-arm-cpu is not in the qtree.  That's
>   because it's not a qdev (in QOM parlance: not a TYPE_DEVICE).

Hmm? The Arm CPUs all subclass CPUClass, which subclasses
DeviceState. The CPU is a qdev, but it is not in the qtree because
it does not have a bus it can live on.

> Now let me ramble a bit on reset.

Thanks for this -- I have put this on my list to
think through in detail next week.

-- PMM

Re: [Qemu-devel] [PULL v2 04/36] virtio: Introduce started flag to VirtioDevice

[Michael S. Tsirkin]

On Mon, May 27, 2019 at 12:44:46PM +0200, Greg Kurz wrote:
> On Fri, 24 May 2019 19:56:06 +0800
> Yongji Xie  wrote:
> 
> > On Fri, 24 May 2019 at 18:20, Greg Kurz  wrote:
> > >
> > > On Mon, 20 May 2019 19:10:35 -0400
> > > "Michael S. Tsirkin"  wrote:
> > >  
> > > > From: Xie Yongji 
> > > >
> > > > The virtio 1.0 transitional devices support driver uses the device
> > > > before setting the DRIVER_OK status bit. So we introduce a started
> > > > flag to indicate whether driver has started the device or not.
> > > >
> > > > Signed-off-by: Xie Yongji 
> > > > Signed-off-by: Zhang Yu 
> > > > Message-Id: <20190320112646.3712-2-xieyon...@baidu.com>
> > > > Reviewed-by: Michael S. Tsirkin 
> > > > Signed-off-by: Michael S. Tsirkin 
> > > > ---
> > > >  include/hw/virtio/virtio.h |  2 ++
> > > >  hw/virtio/virtio.c | 52 --
> > > >  2 files changed, 52 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> > > > index 7140381e3a..27c0efc3d0 100644
> > > > --- a/include/hw/virtio/virtio.h
> > > > +++ b/include/hw/virtio/virtio.h
> > > > @@ -105,6 +105,8 @@ struct VirtIODevice
> > > >  uint16_t device_id;
> > > >  bool vm_running;
> > > >  bool broken; /* device in invalid state, needs reset */
> > > > +bool started;
> > > > +bool start_on_kick; /* virtio 1.0 transitional devices support 
> > > > that */
> > > >  VMChangeStateEntry *vmstate;
> > > >  char *bus_name;
> > > >  uint8_t device_endian;
> > > > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > > > index 28056a7ef7..5d533ac74e 100644
> > > > --- a/hw/virtio/virtio.c
> > > > +++ b/hw/virtio/virtio.c
> > > > @@ -1162,10 +1162,16 @@ int virtio_set_status(VirtIODevice *vdev, 
> > > > uint8_t val)
> > > >  }
> > > >  }
> > > >  }
> > > > +vdev->started = val & VIRTIO_CONFIG_S_DRIVER_OK;
> > > > +if (unlikely(vdev->start_on_kick && vdev->started)) {
> > > > +vdev->start_on_kick = false;
> > > > +}
> > > > +
> > > >  if (k->set_status) {
> > > >  k->set_status(vdev, val);
> > > >  }
> > > >  vdev->status = val;
> > > > +
> > > >  return 0;
> > > >  }
> > > >
> > > > @@ -1208,6 +1214,9 @@ void virtio_reset(void *opaque)
> > > >  k->reset(vdev);
> > > >  }
> > > >
> > > > +vdev->start_on_kick = (virtio_host_has_feature(vdev, 
> > > > VIRTIO_F_VERSION_1) &&
> > > > +  !virtio_vdev_has_feature(vdev, 
> > > > VIRTIO_F_VERSION_1));
> > > > +vdev->started = false;
> > > >  vdev->broken = false;
> > > >  vdev->guest_features = 0;
> > > >  vdev->queue_sel = 0;
> > > > @@ -1518,14 +1527,21 @@ void virtio_queue_set_align(VirtIODevice *vdev, 
> > > > int n, int align)
> > > >
> > > >  static bool virtio_queue_notify_aio_vq(VirtQueue *vq)
> > > >  {
> > > > +bool ret = false;
> > > > +
> > > >  if (vq->vring.desc && vq->handle_aio_output) {
> > > >  VirtIODevice *vdev = vq->vdev;
> > > >
> > > >  trace_virtio_queue_notify(vdev, vq - vdev->vq, vq);
> > > > -return vq->handle_aio_output(vdev, vq);
> > > > +ret = vq->handle_aio_output(vdev, vq);
> > > > +
> > > > +if (unlikely(vdev->start_on_kick)) {
> > > > +vdev->started = true;
> > > > +vdev->start_on_kick = false;
> > > > +}
> > > >  }
> > > >
> > > > -return false;
> > > > +return ret;
> > > >  }
> > > >
> > > >  static void virtio_queue_notify_vq(VirtQueue *vq)
> > > > @@ -1539,6 +1555,11 @@ static void virtio_queue_notify_vq(VirtQueue *vq)
> > > >
> > > >  trace_virtio_queue_notify(vdev, vq - vdev->vq, vq);
> > > >  vq->handle_output(vdev, vq);
> > > > +
> > > > +if (unlikely(vdev->start_on_kick)) {
> > > > +vdev->started = true;
> > > > +vdev->start_on_kick = false;
> > > > +}
> > > >  }
> > > >  }
> > > >
> > > > @@ -1556,6 +1577,11 @@ void virtio_queue_notify(VirtIODevice *vdev, int 
> > > > n)
> > > >  } else if (vq->handle_output) {
> > > >  vq->handle_output(vdev, vq);
> > > >  }
> > > > +
> > > > +if (unlikely(vdev->start_on_kick)) {
> > > > +vdev->started = true;
> > > > +vdev->start_on_kick = false;
> > > > +}
> > > >  }
> > > >
> > > >  uint16_t virtio_queue_vector(VirtIODevice *vdev, int n)
> > > > @@ -1770,6 +1796,13 @@ static bool virtio_broken_needed(void *opaque)
> > > >  return vdev->broken;
> > > >  }
> > > >
> > > > +static bool virtio_started_needed(void *opaque)
> > > > +{
> > > > +VirtIODevice *vdev = opaque;
> > > > +
> > > > +return vdev->started;  
> > >
> > > Existing machine types don't know about the "virtio/started" subsection. 
> > > This
> > > breaks migration to older QEMUs if the driver has started the device, ie. 
> > > most
> > > probably always when it comes to live migration.
> > >
> > > My understanding is that we do

Re: [Qemu-devel] [PATCH v3 4/6] numa: introduce "numa-mem-supported" machine property

[Eduardo Habkost]

On Fri, May 17, 2019 at 09:45:17AM +0200, Igor Mammedov wrote:
> '-numa mem' option has a number of issues and mgmt often defaults
> to it. Unfortunately it's no possible to replace it with an alternative
> '-numa memdev' without breaking migration compatibility. What's possible
> though is to deprecate it, keeping option working with old machine types.
> Once deprecation period expires, QEMU will disable '-numa mem' option,
> usage on new machine types and when the last machine type that supported
> it is removed we would be able to remove '-numa mem' with associated code.
> 
> In order to help mgmt to find out if being deprecated CLI option
> '-numa mem=SZ' is still supported by particular machine type, expose
> this information via "numa-mem-supported" machine property.
> 
> Users can use "qom-list-properties" QMP command to list machine type
> properties including initial proprety values (when probing for supported
> machine types with '-machine none') or at runtime at preconfig time
> before numa mapping is configured and decide if they should used legacy
> '-numa mem' or alternative '-numa memdev' option.
> 
> Signed-off-by: Igor Mammedov 
> ---
>  include/hw/boards.h |  1 +
>  hw/arm/virt.c   |  1 +
>  hw/core/machine.c   | 12 
>  hw/i386/pc.c|  1 +
>  hw/ppc/spapr.c  |  1 +
>  5 files changed, 16 insertions(+)
> 
> diff --git a/include/hw/boards.h b/include/hw/boards.h
> index 6f7916f..9e347cf 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -210,6 +210,7 @@ struct MachineClass {
>  bool ignore_boot_device_suffixes;
>  bool smbus_no_migration_support;
>  bool nvdimm_supported;
> +bool numa_mem_supported;
>  
>  HotplugHandler *(*get_hotplug_handler)(MachineState *machine,
> DeviceState *dev);
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 5331ab7..2e86c78 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -1943,6 +1943,7 @@ static void virt_machine_class_init(ObjectClass *oc, 
> void *data)
>  assert(!mc->get_hotplug_handler);
>  mc->get_hotplug_handler = virt_machine_get_hotplug_handler;
>  hc->plug = virt_machine_device_plug_cb;
> +mc->numa_mem_supported = true;
>  }
>  
>  static void virt_instance_init(Object *obj)
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index 5d046a4..8bc53ba 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -506,6 +506,13 @@ static char *machine_get_nvdimm_persistence(Object *obj, 
> Error **errp)
>  return g_strdup(ms->nvdimms_state->persistence_string);
>  }
>  
> +static bool machine_get_numa_mem_supported(Object *obj, Error **errp)
> +{
> +MachineClass *mc = MACHINE_GET_CLASS(obj);
> +
> +return mc->numa_mem_supported;

I don't remember other cases where a property value is constant
for all instances of a given class, but still requires
instantiating an object just to look at the value of the
property.  Is this really a pattern we want to start using in
QEMU?

Why hiding numa_mem_supported behind qom-list-properties is
better than simply extending the QAPI schema to add a new field
to MachineInfo?  Extending MachineInfo is simple and obvious, and
it makes the new machine class attribute be explicitly documented
in the QAPI schema.


> +}
> +
>  static void machine_set_nvdimm_persistence(Object *obj, const char *value,
> Error **errp)
>  {
> @@ -810,6 +817,11 @@ static void machine_class_init(ObjectClass *oc, void 
> *data)
>  &error_abort);
>  object_class_property_set_description(oc, "memory-encryption",
>  "Set memory encryption object to use", &error_abort);
> +
> +object_class_property_add_bool(oc, "numa-mem-supported",
> +machine_get_numa_mem_supported, NULL, &error_abort);
> +object_class_property_set_description(oc, "numa-mem-supported",
> +"Shows if legacy '-numa mem=SIZE option is supported", &error_abort);
>  }
>  
>  static void machine_class_base_init(ObjectClass *oc, void *data)
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index de91e90..bec0055 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -2756,6 +2756,7 @@ static void pc_machine_class_init(ObjectClass *oc, void 
> *data)
>  nc->nmi_monitor_handler = x86_nmi;
>  mc->default_cpu_type = TARGET_DEFAULT_CPU_TYPE;
>  mc->nvdimm_supported = true;
> +mc->numa_mem_supported = true;
>  
>  object_class_property_add(oc, PC_MACHINE_DEVMEM_REGION_SIZE, "int",
>  pc_machine_get_device_memory_region_size, NULL,
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 2ef3ce4..265ecfb 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -4336,6 +4336,7 @@ static void spapr_machine_class_init(ObjectClass *oc, 
> void *data)
>   * in which LMBs are represented and hot-added
>   */
>  mc->numa_mem_align_shift = 28;
> +mc->numa_mem_supported = true;
>  
>  smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_

Re: [Qemu-devel] [PATCH 0/3] hw/microblaze: Kconfig cleanup

[Paolo Bonzini]

On 27/05/19 18:10, Philippe Mathieu-Daudé wrote:
>>>
>> Queued, thanks.
> I don't see these patches in your queue merged on "Fri 17 May", are
> you planning to include them in your next batch?

Yes, thanks.

Paolo

Re: [Qemu-devel] [PATCH v3 4/6] numa: introduce "numa-mem-supported" machine property

[Markus Armbruster]

Igor Mammedov  writes:

> '-numa mem' option has a number of issues and mgmt often defaults
> to it. Unfortunately it's no possible to replace it with an alternative
> '-numa memdev' without breaking migration compatibility.

To be precise: -numa node,mem=... and -numa node,memdev=...  Correct?

>  What's possible
> though is to deprecate it, keeping option working with old machine types.
> Once deprecation period expires, QEMU will disable '-numa mem' option,
> usage on new machine types and when the last machine type that supported
> it is removed we would be able to remove '-numa mem' with associated code.
>
> In order to help mgmt to find out if being deprecated CLI option
> '-numa mem=SZ' is still supported by particular machine type, expose
> this information via "numa-mem-supported" machine property.
>
> Users can use "qom-list-properties" QMP command to list machine type
> properties including initial proprety values (when probing for supported
> machine types with '-machine none') or at runtime at preconfig time
> before numa mapping is configured and decide if they should used legacy
> '-numa mem' or alternative '-numa memdev' option.

This sentence is impenetrable, I'm afraid :)

If we only want to convey whether a machine type supports -numa
node,mem=..., then adding a flag to query-machines suffices.  Since I'm
pretty sure you'd have figured that out yourself, I suspect I'm missing
something.  Can you give me some examples of intended usage?

Re: [Qemu-devel] [PATCH v3 0/7] Kconfig dependencies for MIPS machines (but Malta)

[Aleksandar Markovic]

On Mar 11, 2019 1:56 AM, "Philippe Mathieu-Daudé"  wrote:
>
> Express the MIPS machine dependencies with Kconfig.
>
> Due to its complexity, the Malta board fill follow in a different
> series.
>

Philippe,

What would be the status of this series? I am willing to integrate all
this, including all followups, but have hard time sorting out what happend
after this submission, what is the most complete version etc. Can you
enlighten me please?

Yours,
Aleksandar

> v3:
> - addressed review comments from Thomas and Aleksandar
>   (noted in each patch)
>
> v2: https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg00887.html
> - Do not remove machines from the default config (Thomas)
> - Corrected comment about CONFIG_PCI_BONITO (Thomas)
>
> v1: https://www.mail-archive.com/qemu-devel@nongnu.org/msg593013.html
>
> $ git backport-diff -u kconfig_mips-v2
> Key:
> [] : patches are identical
> [] : number of functional differences between upstream/downstream
patch
> The flags [FC] indicate (F)unctional and (C)ontextual differences,
respectively
>
> 001/7:[] [--] 'hw/mips: Express dependencies of the MIPSsim machine
with kconfig'
> 002/7:[0001] [FC] 'hw/mips: Express dependencies of the Jazz machine with
kconfig'
> 003/7:[0002] [FC] 'hw/mips: Express dependencies of the r4k platform with
kconfig'
> 004/7:[down] 'hw/mips: Remove the redundant CONFIG_MIPS_ITU Makefile
variable'
> 005/7:[] [-C] 'hw/mips: Express dependencies of the Boston machine
with kconfig'
> 006/7:[] [-C] 'hw/pci-host: Use CONFIG_PCI_BONITO to select the
Bonito North Bridge'
> 007/7:[] [-C] 'hw/mips: Express dependencies of the Fulong 2E machine
with kconfig'
>
> Regards,
>
> Phil.
>
> Philippe Mathieu-Daudé (7):
>   hw/mips: Express dependencies of the MIPSsim machine with Kconfig
>   hw/mips: Express dependencies of the Jazz machine with Kconfig
>   hw/mips: Express dependencies of the r4k platform with Kconfig
>   hw/mips: Remove the redundant CONFIG_MIPS_ITU Makefile variable
>   hw/mips: Express dependencies of the Boston machine with Kconfig
>   hw/pci-host: Use CONFIG_PCI_BONITO to select the Bonito North Bridge
>   hw/mips: Express dependencies of the Fulong 2E machine with Kconfig
>
>  default-configs/mips-softmmu-common.mak |  4 ---
>  default-configs/mips64-softmmu.mak  |  5 ---
>  default-configs/mips64el-softmmu.mak| 11 ---
>  hw/isa/Kconfig  | 13 +---
>  hw/mips/Kconfig | 41 +
>  hw/misc/Kconfig |  3 --
>  hw/misc/Makefile.objs   |  2 +-
>  hw/pci-host/Kconfig |  4 +++
>  hw/pci-host/Makefile.objs   |  2 +-
>  9 files changed, 56 insertions(+), 29 deletions(-)
>
> --
> 2.20.1
>
>

Re: [Qemu-devel] [PATCH v3 3/6] qmp: qmp_qom_list_properties(): ignore empty string options

[Markus Armbruster]

Igor Mammedov  writes:

> Current QAPI semantics return empty "" string in case string property
> value hasn't been set (i.e. NULL). Do not show initial value in this
> case in "qom-list-properties" command output to reduce clutter.
>
> Signed-off-by: Igor Mammedov 
> ---
>  qmp.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/qmp.c b/qmp.c
> index 8415541..463c7d4 100644
> --- a/qmp.c
> +++ b/qmp.c
> @@ -41,6 +41,7 @@
>  #include "qom/object_interfaces.h"
>  #include "hw/mem/memory-device.h"
>  #include "hw/acpi/acpi_dev_interface.h"
> +#include "qapi/qmp/qstring.h"
>  
>  NameInfo *qmp_query_name(Error **errp)
>  {
> @@ -596,7 +597,16 @@ ObjectPropertyInfoList *qmp_qom_list_properties(const 
> char *typename,
>  if (obj) {
>  info->q_default =
>  object_property_get_qobject(obj, info->name, NULL);
> -info->has_q_default = !!info->q_default;
> +if (info->q_default) {
> +   if (qobject_type(info->q_default) == QTYPE_QSTRING) {
> +   QString *value = qobject_to(QString, info->q_default);
> +   if (!strcmp(qstring_get_str(value), "")) {
> +   qobject_unref(info->q_default);
> +   info->q_default = NULL;
> +   }
> +   }
> +   info->has_q_default = !!info->q_default;
> +}
>  }
>  
>  entry = g_malloc0(sizeof(*entry));

The commit message suggests we omit @default when a string-valued
property is null.  We omit it when it's "", too.

Makes me wonder whether we should omit other "default defaults", too,
such as integer zero.  After all, what's so special about strings?

I'm not sure omitting any default defaults is a good idea.  But then I'm
not yet sure @default is a good idea.

Re: [Qemu-devel] [PATCH v3 2/6] qmp: make "qom-list-properties" show initial property values

[Markus Armbruster]

Igor Mammedov  writes:

> Add in the command output object's property values right after creation
> (i.e. state of the object returned by object_new() or equivalent).
>
> Follow up patch will add machine property 'numa-mem-supported', which
> would allow mgmt to introspect which machine types (versions) still
> support legacy "-numa mem=FOO" CLI option and which don't and require
> alternative '-numa memdev' option being used.

I'll have to study that patch to figure out what exactly the use case
is.

> Signed-off-by: Igor Mammedov 
> ---
>  qapi/misc.json | 5 -
>  qmp.c  | 5 +
>  2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/qapi/misc.json b/qapi/misc.json
> index 8b3ca4f..e333285 100644
> --- a/qapi/misc.json
> +++ b/qapi/misc.json
> @@ -1365,10 +1365,13 @@
>  #
>  # @description: if specified, the description of the property.
>  #
> +# @default: initial property value.
> +#
>  # Since: 1.2
>  ##
>  { 'struct': 'ObjectPropertyInfo',
> -  'data': { 'name': 'str', 'type': 'str', '*description': 'str' } }
> +  'data': { 'name': 'str', 'type': 'str', '*description': 'str',
> +'*default': 'any' } }

ObjectPropertyInfo has three users: qom-list, device-list-properties,
qom-list-properties.

>  
>  ##
>  # @qom-list:
> diff --git a/qmp.c b/qmp.c
> index b92d62c..8415541 100644
> --- a/qmp.c
> +++ b/qmp.c
> @@ -593,6 +593,11 @@ ObjectPropertyInfoList *qmp_qom_list_properties(const 
> char *typename,
>  info->type = g_strdup(prop->type);
>  info->has_description = !!prop->description;
>  info->description = g_strdup(prop->description);
> +if (obj) {
> +info->q_default =
> +object_property_get_qobject(obj, info->name, NULL);
> +info->has_q_default = !!info->q_default;
> +}
>  
>  entry = g_malloc0(sizeof(*entry));
>  entry->value = info;

You update only qom-list-properties.

The other two therefore never return objects with a @default member.
But query-qmp-schema can't tell.  Awkward.  The doc comments don't tell.
Doc bug.

You could have qom-list-properties return a new type

{ 'struct': 'ObjectPropertyInfoWithDefault',
  'base': 'ObjectPropertyInfo',
  'data': { '*default': any } }

The default value shown by qom-list-properties is the value found in a
fresh object created with object_new().  object_new() runs
->instance_init(), which can do anything.  When you call object_new()
again, you might find a different value.  In other words, the @default
returned by qom-list-properties is unreliable.

Related to this qom-list-properties caveat:

   # Note: objects can create properties at runtime, for example to describe
   # links between different devices and/or objects. These properties
   # are not included in the output of this command.

Please add a similar one for @default.

This command fights QOM's basic design premises, and it shows.

Re: [Qemu-devel] [PATCH 0/6] target/rx: Improvements to disassembly

[Aleksandar Markovic]

On May 27, 2019 5:44 PM, "Yoshinori Sato" 
wrote:
>
> On Fri, 24 May 2019 00:07:57 +0900,
> Richard Henderson wrote:
> >
> > Here's a sample of the new output, taken from u-boot.bin:
> >
> > IN:
> > 0xfff8000a:  fb 12 00 01 00 00  mov.l   #0x0100, r1
> > 0xfff80010:  fb 32 f0 13 00 00  mov.l   #0x13f0, r3
> > 0xfff80016:  43 13  sub r1, r3
> > 0xfff80018:  fb 22 00 ea f9 ff  mov.l   #-398848, r2
> > 0xfff8001e:  7f 8f  smovf
> > 0xfff80020:  ef 01  mov.l   r0, r1
> > 0xfff80022:  05 1e 32 00bsr.a   fff83240
> >
> > IN:
> > 0xfff83240:  72 11 5c fbadd #-1188, r1
> > 0xfff83244:  75 21 f0   and #-16, r1
> > 0xfff83247:  02 rts
> >
> > Obviously there are still a few inconsistencies in the
> > format strings used for the immediates, but the format
> > is readable and it is easy to look at the opcode to see
> > how our decode compares to the manual.
> >
>
> Hmm.
> The output of the immediate value should be the same as the output of
objdump.
> I do not think that it is the proper format, but I did that because
> it was useful for comparing the results.
>

We in MIPS also use objdump output as the reference and desired output for
QEMU disassembler (not that we are always succeeding in doing that)

Inventing propriatery QEMU output for some instructions is in my view
counterproductive and confusing.

Sincerely,
Aleksandar

> >
> > r~
> >
> >
> > Richard Henderson (6):
> >   target/rx: Disassemble rx_index_addr into a string
> >   target/rx: Replace operand with prt_ldmi in disassembler
> >   target/rx: Use prt_ldmi for XCHG_mr disassembly
> >   target/rx: Emit all disassembly in one prt()
> >   target/rx: Collect all bytes during disassembly
> >   target/rx: Dump bytes for each insn during disassembly
> >
> >  target/rx/disas.c | 366 +-
> >  1 file changed, 166 insertions(+), 200 deletions(-)
> >
> > --
> > 2.17.1
> >
>
> --
> Yosinori Sato
>

Re: [Qemu-devel] [PATCH 2/2] vmdk: Add read-only support for seSparse snapshots

[Max Reitz]

On 24.04.19 09:49, Sam Eiderman wrote:
> Until ESXi 6.5 VMware used the vmfsSparse format for snapshots (VMDK3 in
> QEMU).
> 
> This format was lacking in the following:
> 
> * Grain directory (L1) and grain table (L2) entries were 32-bit,
>   allowing access to only 2TB (slightly less) of data.
> * The grain size (default) was 512 bytes - leading to data
>   fragmentation and many grain tables.
> * For space reclamation purposes, it was necessary to find all the
>   grains which are not pointed to by any grain table - so a reverse
>   mapping of "offset of grain in vmdk" to "grain table" must be
>   constructed - which takes large amounts of CPU/RAM.
> 
> The format specification can be found in VMware's documentation:
> https://www.vmware.com/support/developer/vddk/vmdk_50_technote.pdf
> 
> In ESXi 6.5, to support snapshot files larger than 2TB, a new format was
> introduced: SESparse (Space Efficient).
> 
> This format fixes the above issues:
> 
> * All entries are now 64-bit.
> * The grain size (default) is 4KB.
> * Grain directory and grain tables are now located at the beginning
>   of the file.
>   + seSparse format reserves space for all grain tables.
>   + Grain tables can be addressed using an index.
>   + Grains are located in the end of the file and can also be
> addressed with an index.
>   - seSparse vmdks of large disks (64TB) have huge preallocated
> headers - mainly due to L2 tables, even for empty snapshots.
> * The header contains a reverse mapping ("backmap") of "offset of
>   grain in vmdk" to "grain table" and a bitmap ("free bitmap") which
>   specifies for each grain - whether it is allocated or not.
>   Using these data structures we can implement space reclamation
>   efficiently.
> * Due to the fact that the header now maintains two mappings:
> * The regular one (grain directory & grain tables)
> * A reverse one (backmap and free bitmap)
>   These data structures can lose consistency upon crash and result
>   in a corrupted VMDK.
>   Therefore, a journal is also added to the VMDK and is replayed
>   when the VMware reopens the file after a crash.
> 
> Since ESXi 6.7 - SESparse is the only snapshot format available.
> 
> Unfortunately, VMware does not provide documentation regarding the new
> seSparse format.
> 
> This commit is based on black-box research of the seSparse format.
> Various in-guest block operations and their effect on the snapshot file
> were tested.
> 
> The only VMware provided source of information (regarding the underlying
> implementation) was a log file on the ESXi:
> 
> /var/log/hostd.log
> 
> Whenever an seSparse snapshot is created - the log is being populated
> with seSparse records.
> 
> Relevant log records are of the form:
> 
> [...] Const Header:
> [...]  constMagic = 0xcafebabe
> [...]  version= 2.1
> [...]  capacity   = 204800
> [...]  grainSize  = 8
> [...]  grainTableSize = 64
> [...]  flags  = 0
> [...] Extents:
> [...]  Header : <1 : 1>
> [...]  JournalHdr : <2 : 2>
> [...]  Journal: <2048 : 2048>
> [...]  GrainDirectory : <4096 : 2048>
> [...]  GrainTables: <6144 : 2048>
> [...]  FreeBitmap : <8192 : 2048>
> [...]  BackMap: <10240 : 2048>
> [...]  Grain  : <12288 : 204800>
> [...] Volatile Header:
> [...] volatileMagic = 0xcafecafe
> [...] FreeGTNumber  = 0
> [...] nextTxnSeqNumber  = 0
> [...] replayJournal = 0
> 
> The sizes that are seen in the log file are in sectors.
> Extents are of the following format: 
> 
> This commit is a strict implementation which enforces:
> * magics
> * version number 2.1
> * grain size of 8 sectors  (4KB)
> * grain table size of 64 sectors
> * zero flags
> * extent locations
> 
> Additionally, this commit proivdes only a subset of the functionality
> offered by seSparse's format:
> * Read-only
> * No journal replay
> * No space reclamation
> * No unmap support
> 
> Hence, journal header, journal, free bitmap and backmap extents are
> unused, only the "classic" (L1 -> L2 -> data) grain access is
> implemented.
> 
> However there are several differences in the grain access itself.
> Grain directory (L1):
> * Grain directory entries are indexes (not offsets) to grain
>   tables.
> * Valid grain directory entries have their highest nibble set to
>   0x1.
> * Since grain tables are always located in the beginning of the
>   file - the index can fit into 32 bits - so we can use its low
>   part if it's valid.
> Grain table (L2):
> * Grain table entries are indexes (not offsets) to grains.
> * If the highest nibble of the entry is:
> 0x0:
> The grain in not allocated.
> The rest of the bytes are 0.
> 0x1:
> The grain is unmapped - guest sees a zero grain.
> The

Re: [Qemu-devel] [PATCH v2 27/28] tests/qemu-iotests: re-format output to for make check-block

[Max Reitz]

On 27.05.19 18:20, Alex Bennée wrote:
> 
> Max Reitz  writes:
> 
>> On 23.05.19 12:25, Alex Bennée wrote:
>>> This attempts to clean-up the output to better match the output of the
>>> rest of the QEMU check system when called with -makecheck. This includes:
>>>
>>>   - formatting as "  TESTiotest-FMT: nnn"
>>>   - only dumping config on failure (when -makecheck enabled)
>>>
>>> The non-make check output has been cleaned up as well:
>>>
>>>   - line re-displayed (\r) at the end
>>>   - fancy colours for pass/fail/skip
>>>   - timestamps always printed (option removed)
>>>
>>> Signed-off-by: Alex Bennée 
>>> Message-Id: <20190503143904.31211-1-alex.ben...@linaro.org>
>>> Tested-by: Thomas Huth 
>>>
>>> ---
>>> v3
>>>   - revert echo to printf
>>>   - add _report_test_start
>>> v4
>>>   - -pretty -> -makecheck
>>>   - keep all output together for makecheck
>>> v5
>>>   - merged in kwolf's pretty printing
>>>   - timestamps always printed in non-makecheck mode
>>> ---
>>>  tests/qemu-iotests/check | 179 +--
>>>  1 file changed, 116 insertions(+), 63 deletions(-)
>>
>> Unless I missed something, this breaks ./check:
>>
>> $ ./check -T -qcow2
>> 000 - unknown test, ignored
> 
> Because -T has been dropped (timestamps are always shown). Of course
> removing from the opts passing falls through. Should I just do:

Ah, OK.

> modified   tests/qemu-iotests/check
> @@ -433,6 +433,11 @@ testlist options
>  cachemode=true
>  xpand=false
>  ;;
> +-T)
> +echo "-T no longer needed"
> +exit -1
> +;;
> +
>  -v)
>  verbose=true

Hm, why not just ignore it?

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2 2/9] i386/kvm: add support for KVM_GET_SUPPORTED_HV_CPUID

[Vitaly Kuznetsov]

Roman Kagan  writes:

> On Fri, May 17, 2019 at 04:19:17PM +0200, Vitaly Kuznetsov wrote:
>> KVM now supports reporting supported Hyper-V features through CPUID
>> (KVM_GET_SUPPORTED_HV_CPUID ioctl). Going forward, this is going to be
>> the only way to announce new functionality and this has already happened
>> with Direct Mode stimers.
>> 
>> While we could just support KVM_GET_SUPPORTED_HV_CPUID for new features,
>> it seems to be beneficial to use it for all Hyper-V enlightenments when
>> possible. This way we can implement 'hv-all' pass-through mode giving the
>> guest all supported Hyper-V features even when QEMU knows nothing about
>> them.
>> 
>> Implementation-wise we create a new kvm_hyperv_properties structure
>> defining Hyper-V features, get_supported_hv_cpuid()/
>> get_supported_hv_cpuid_legacy() returning the supported CPUID set and
>> a bit over-engineered hv_cpuid_check_and_set() which we will also be
>> used to set cpu->hyperv_* properties for 'hv-all' mode.
>> 
>> Signed-off-by: Vitaly Kuznetsov 
>> ---
>>  target/i386/kvm.c | 474 ++
>>  1 file changed, 356 insertions(+), 118 deletions(-)
>> 
>> diff --git a/target/i386/kvm.c b/target/i386/kvm.c
>> index 3daac1e4f4..6ead422efa 100644
>> --- a/target/i386/kvm.c
>> +++ b/target/i386/kvm.c
>> @@ -684,156 +684,394 @@ static bool tsc_is_stable_and_known(CPUX86State *env)
>>  || env->user_tsc_khz;
>>  }
>>  
>> -static int hyperv_handle_properties(CPUState *cs)
>> +static struct {
>> +const char *desc;
>> +struct {
>> +uint32_t fw;
>> +uint32_t bits;
>> +} flags[2];
>> +} kvm_hyperv_properties[] = {
>> +[HYPERV_FEAT_RELAXED] = {
>> +.desc = "relaxed timing (hv-relaxed)",
>
> I'd still like to avoid repeating the feature names.

I didn't find a convenient way to extract this from
x86_cpu_properties[]. This can be done but to me it looked like
over-engineering as the only reason we have this here is to have a
somewhat nicer message when something is unsupported.

>
>> +.flags = {
>> +{.fw = FEAT_HYPERV_EAX,
>> + .bits = HV_HYPERCALL_AVAILABLE},
>> +{.fw = FEAT_HV_RECOMM_EAX,
>> + .bits = HV_RELAXED_TIMING_RECOMMENDED}
>> +}
>> +},
>> +[HYPERV_FEAT_VAPIC] = {
>> +.desc = "virtual APIC (hv-vapic)",
>> +.flags = {
>> +{.fw = FEAT_HYPERV_EAX,
>> + .bits = HV_HYPERCALL_AVAILABLE | HV_APIC_ACCESS_AVAILABLE},
>> +{.fw = FEAT_HV_RECOMM_EAX,
>> + .bits = HV_APIC_ACCESS_RECOMMENDED}
>> +}
>> +},
>> +[HYPERV_FEAT_TIME] = {
>> +.desc = "clocksources (hv-time)",
>> +.flags = {
>> +{.fw = FEAT_HYPERV_EAX,
>> + .bits = HV_HYPERCALL_AVAILABLE | HV_TIME_REF_COUNT_AVAILABLE |
>> + HV_REFERENCE_TSC_AVAILABLE}
>> +}
>> +},
>> +[HYPERV_FEAT_CRASH] = {
>> +.desc = "crash MSRs (hv-crash)",
>> +.flags = {
>> +{.fw = FEAT_HYPERV_EDX,
>> + .bits = HV_GUEST_CRASH_MSR_AVAILABLE}
>> +}
>> +},
>> +[HYPERV_FEAT_RESET] = {
>> +.desc = "reset MSR (hv-reset)",
>> +.flags = {
>> +{.fw = FEAT_HYPERV_EAX,
>> + .bits = HV_RESET_AVAILABLE}
>> +}
>> +},
>> +[HYPERV_FEAT_VPINDEX] = {
>> +.desc = "VP_INDEX MSR (hv-vpindex)",
>> +.flags = {
>> +{.fw = FEAT_HYPERV_EAX,
>> + .bits = HV_VP_INDEX_AVAILABLE}
>> +}
>> +},
>> +[HYPERV_FEAT_RUNTIME] = {
>> +.desc = "VP_RUNTIME MSR (hv-runtime)",
>> +.flags = {
>> +{.fw = FEAT_HYPERV_EAX,
>> + .bits = HV_VP_RUNTIME_AVAILABLE}
>> +}
>> +},
>> +[HYPERV_FEAT_SYNIC] = {
>> +.desc = "synthetic interrupt controller (hv-synic)",
>> +.flags = {
>> +{.fw = FEAT_HYPERV_EAX,
>> + .bits = HV_SYNIC_AVAILABLE}
>> +}
>> +},
>> +[HYPERV_FEAT_STIMER] = {
>> +.desc = "synthetic timers (hv-stimer)",
>> +.flags = {
>> +{.fw = FEAT_HYPERV_EAX,
>> + .bits = HV_SYNTIMERS_AVAILABLE}
>> +}
>> +},
>> +[HYPERV_FEAT_FREQUENCIES] = {
>> +.desc = "frequency MSRs (hv-frequencies)",
>> +.flags = {
>> +{.fw = FEAT_HYPERV_EAX,
>> + .bits = HV_ACCESS_FREQUENCY_MSRS},
>> +{.fw = FEAT_HYPERV_EDX,
>> + .bits = HV_FREQUENCY_MSRS_AVAILABLE}
>> +}
>> +},
>> +[HYPERV_FEAT_REENLIGHTENMENT] = {
>> +.desc = "reenlightenment MSRs (hv-reenlightenment)",
>> +.flags = {
>> +{.fw = FEAT_HYPERV_EAX,
>> + .bits = HV_ACCESS_REENLIGHTENMENTS_CONTROL}
>> +}
>> +},
>> +[HYPERV_FEAT_TLBFLUSH] = {
>> +.desc = "paravirtualized TLB flush (hv-tlbflush)",
>> +.flags = {
>> +{.fw = FEAT_HV_RECOMM_EAX,
>> +  

Re: [Qemu-devel] [PATCH v3 1/6] pc: fix possible NULL pointer dereference in pc_machine_get_device_memory_region_size()

[Markus Armbruster]

Igor Mammedov  writes:

> QEMU will crash when device-memory-region-size property is read if 
> ms->device_memory
> wasn't initialized yet (ex: property being inspected during preconfig time).

Reproduced:

$ qemu-system-x86_64 -nodefaults -S -display none -preconfig -qmp stdio
{"QMP": {"version": {"qemu": {"micro": 50, "minor": 0, "major": 4}, 
"package": "v4.0.0-828-ga7b21f6762"}, "capabilities": ["oob"]}}
{"execute": "qmp_capabilities"}
{"return": {}}
{"execute": "qom-get", "arguments": {"path": "/machine", "property": 
"device-memory-region-size"}}
Segmentation fault (core dumped)

First time I started looking at this series, I went "I'll need a
reproducer to fully understand what's up, and I don't feel like finding
one now; next series, please".  Second time, I had to spend a few
minutes on the reproducer.  Wasn't hard, since you provided a clue.
Still: make review easy, include a reproducer whenever you can.

> Instead of crashing return 0 if ms->device_memory hasn't been initialized.
>
> Signed-off-by: Igor Mammedov 
> ---
>  hw/i386/pc.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index d98b737..de91e90 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -2461,7 +2461,11 @@ pc_machine_get_device_memory_region_size(Object *obj, 
> Visitor *v,
>   Error **errp)
>  {
>  MachineState *ms = MACHINE(obj);
> -int64_t value = memory_region_size(&ms->device_memory->mr);
> +int64_t value = 0;
> +
> +if (ms->device_memory) {
> +memory_region_size(&ms->device_memory->mr);
> +}
>  
>  visit_type_int(v, name, &value, errp);
>  }

This makes qom-get return 0 for the size of memory that doesn't exist,
yet.

A possible alternative would be setting an error.

Opinions?

Re: [Qemu-devel] How do we do user input bitmap properties?

[Andrea Bolognani]

On Fri, 2019-05-24 at 15:24 -0300, Eduardo Habkost wrote:
> On Thu, May 23, 2019 at 10:35:24AM +0200, Andrea Bolognani wrote:
> > [...] the above looks good to
> > me as a general direction, but note that you'll have to implement at
> > the very least the query-cpu-model-expansion QMP command for the
> > introspection to work.
> 
> Why is query-cpu-model-expansion needed?  Isn't
> device-list-properties enough?

Good question.

I'll have to check with Jirka, but from playing with both commands
it looks like the latter returns a superset of what the former does,
so for the purpose of figuring out which vector lengths the QEMU
binary recognizes it should be good enough; I suspect, however, that
query-cpu-model-expansion might be (made to be) smarter and for
example not report vector lengths that the underlying hardware
doesn't support, which would be valuable for the purpose of user
friendly error reporting and allowing applications to decide which
vector lengths to request when creating guests.

I'll try to come back with more than theories soon :)

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: [Qemu-devel] [PATCH v2 27/28] tests/qemu-iotests: re-format output to for make check-block

[Alex Bennée]

Max Reitz  writes:

> On 23.05.19 12:25, Alex Bennée wrote:
>> This attempts to clean-up the output to better match the output of the
>> rest of the QEMU check system when called with -makecheck. This includes:
>>
>>   - formatting as "  TESTiotest-FMT: nnn"
>>   - only dumping config on failure (when -makecheck enabled)
>>
>> The non-make check output has been cleaned up as well:
>>
>>   - line re-displayed (\r) at the end
>>   - fancy colours for pass/fail/skip
>>   - timestamps always printed (option removed)
>>
>> Signed-off-by: Alex Bennée 
>> Message-Id: <20190503143904.31211-1-alex.ben...@linaro.org>
>> Tested-by: Thomas Huth 
>>
>> ---
>> v3
>>   - revert echo to printf
>>   - add _report_test_start
>> v4
>>   - -pretty -> -makecheck
>>   - keep all output together for makecheck
>> v5
>>   - merged in kwolf's pretty printing
>>   - timestamps always printed in non-makecheck mode
>> ---
>>  tests/qemu-iotests/check | 179 +--
>>  1 file changed, 116 insertions(+), 63 deletions(-)
>
> Unless I missed something, this breaks ./check:
>
> $ ./check -T -qcow2
> 000 - unknown test, ignored

Because -T has been dropped (timestamps are always shown). Of course
removing from the opts passing falls through. Should I just do:

modified   tests/qemu-iotests/check
@@ -433,6 +433,11 @@ testlist options
 cachemode=true
 xpand=false
 ;;
+-T)
+echo "-T no longer needed"
+exit -1
+;;
+
 -v)
 verbose=true


> QEMU  -- "build/x86_64-softmmu/qemu-system-x86_64" -nodefaults
> -machine accel=qtest
> QEMU_IMG  -- "build/qemu-img"
> QEMU_IO   -- "build/qemu-io"  --cache writeback -f qcow2
> QEMU_NBD  -- "build/qemu-nbd"
> IMGFMT-- qcow2 (compat=1.1)
> IMGPROTO  -- file
> PLATFORM  -- Linux/x86_64 dresden 5.0.14-300.fc30.x86_64
> TEST_DIR  -- build/tests/qemu-iotests/scratch
> SOCKET_SCM_HELPER -- build/tests/qemu-iotests/socket_scm_helper
>
> Passed all 0 tests
>
>
> Max


--
Alex Bennée

[Qemu-devel] Status update on Meson features needed by QEMU

[Paolo Bonzini]

Hi all,

if everything goes according to plan, Meson 0.51.0 (out in a couple of
weeks) should have everything needed for QEMU.  I am not sure whether
I'll have time to attempt a partial conversion to have something to
show, but anyway this is a status update.

On 06/03/19 19:12, Paolo Bonzini wrote:
> - ease of use for test logs and the ability to cut and paste test
> invocations from the logs to the command line.  For this I have started
> "probing" how the Meson developers feel about this kind of change[1],
> and intend to follow up until the meson test driver is comparable in
> usability to QEMU's "make check",

This wasn't accepted, on the other hand Meson has an introspection
mechanism to export test definitions as JSON.  It should be easy to
generate Make rules from it and keep using the current TAP driver.  I
have a pending pull request to fix a bug there, which should be accepted
in 0.51.0.

> - ease of converting Makefile.objs files.  The Makefile.objs files are
> very nice to change for simple modifications, and any replacement should
> have the same feature.  This will require a Meson extension.

This was accepted.  The final syntax looks like

obj.add(when: 'CONFIG_VIRTIO', if_true: files('virtio.c'),
   if_false: files('virtio-stub.c'))

sdl_obj.add(if_true: files('sdl.c'))
sdl_obj.add_all(when: 'CONFIG_OPENGL', if_true: opengl_obj)
common_obj.add_all(when: sdl, if_true: sdl_obj)

> - ability to use the Kconfig declarations for dependencies.
The Kconfig parser was accepted.  It should therefore be possible to
invoke minikconf from Meson (rather than from Make) to process the
dependencies, load the result via the parser and use it as the input to
the source code selection rules.

> - Meson generates a build.ninja file rather than a Makefile

... and requires Ninja to be present when Meson runs, in order to
generate compile_commands.json.  For this I added more functionality to
my ninja lexer/parser so that (in addition to generating a Makefile from
build.ninja) it can also be used to emulate the "ninja -t compdb"
command which generates the file.  The resulting  tool can be found at
https://gist.github.com/bonzini/fd3b69f5682f7e2eca817fb797c2db0f.

Paolo

Re: [Qemu-devel] [PATCH 0/3] hw/microblaze: Kconfig cleanup

[Philippe Mathieu-Daudé]

Hi Paolo,

On Tue, Apr 30, 2019 at 9:55 PM Paolo Bonzini  wrote:
>
> On 27/04/19 16:14, Philippe Mathieu-Daudé wrote:
> > Hi Edgar, Peter,
> >
> > Few fixes while cleaning Kconfig, trying to optimize builds.
> >
> > Regards,
> >
> > Phil.
> >
> > Philippe Mathieu-Daudé (3):
> >   hw/Kconfig: Move the generic XLNX_ZYNQMP to the root hw/Kconfig
> >   hw/intc: Only build the xlnx-iomod-intc device for the MicroBlaze PMU
> >   hw/dma: Do not build the xlnx_dpdma device for the MicroBlaze machines
> >
> >  hw/Kconfig| 3 +++
> >  hw/dma/Makefile.objs  | 1 -
> >  hw/intc/Makefile.objs | 2 +-
> >  hw/timer/Kconfig  | 3 ---
> >  4 files changed, 4 insertions(+), 5 deletions(-)
> >
>
> Queued, thanks.

I don't see these patches in your queue merged on "Fri 17 May", are
you planning to include them in your next batch?

Thanks,

Phil.

Re: [Qemu-devel] [PATCH for-4.1 0/2] hw/alpha: Add the CY82C693UB southbridge in Kconfig

[Philippe Mathieu-Daudé]

On 5/8/19 10:16 PM, Philippe Mathieu-Daudé wrote:
> Paolo, Thomas,
> 
> On 4/29/19 1:29 PM, Philippe Mathieu-Daudé wrote:
>> CC'ing Thomas who is a Kconfig expert.
>>
>> On 3/17/19 12:44 AM, Philippe Mathieu-Daudé wrote:
>>> Explicit the CY82C693UB southbridge used by the 264DP.
>>>
>>> Philippe Mathieu-Daudé (2):
>>>   hw/isa/southbridge: Add the Cypress 82C693UB chipset
>>>   hw/alpha/Kconfig: The 264DP machine use a CY82C693UB southbridge
> 
> This series does not fix anything, but makes the kconfig graph cleaner.

Ping?

Re: [Qemu-devel] Running linux on qemu omap

[Philippe Mathieu-Daudé]

On 5/27/19 5:56 PM, Guenter Roeck wrote:
> On 5/26/19 11:32 PM, Tony Lindgren wrote:
>> Hi,
>>
>> * Philippe Mathieu-Daudé  [190523 12:01]:
>>> What I use as reference for testing ARM boards [*] is the work of
>>> Guenter Roeck:
>>> https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/run-qemu-arm.sh
>>>
>>
>> I think Guenter also has v2.3.50-local-linaro branch in his
>> github repo that has support for few extra boards like Beagleboard.
>> Not sure what's the current branch to use though.
>>
> I'd be happy to use a different (supported) branch, but the Linaro branch
> was the only one I could find that supports those boards. Unfortunately,
> qemu changed so much since 2.3 that it is all but impossible to merge
> the code into mainline qemu without spending a lot of effort on it.

Peter commented on that here:
https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg00137.html

"This is not a trivial job (my estimate was that it would be a couple
of months work to get the complete set sorted out and upstreamed ..."

Re: [Qemu-devel] Running linux on qemu omap

[Guenter Roeck]

On 5/26/19 11:32 PM, Tony Lindgren wrote:

Hi,

* Philippe Mathieu-Daudé  [190523 12:01]:

What I use as reference for testing ARM boards [*] is the work of
Guenter Roeck:
https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/run-qemu-arm.sh


I think Guenter also has v2.3.50-local-linaro branch in his
github repo that has support for few extra boards like Beagleboard.
Not sure what's the current branch to use though.


I'd be happy to use a different (supported) branch, but the Linaro branch
was the only one I could find that supports those boards. Unfortunately,
qemu changed so much since 2.3 that it is all but impossible to merge
the code into mainline qemu without spending a lot of effort on it.

Guenter

Re: [Qemu-devel] [PATCH v2 2/9] i386/kvm: add support for KVM_GET_SUPPORTED_HV_CPUID

[Roman Kagan]

On Fri, May 17, 2019 at 04:19:17PM +0200, Vitaly Kuznetsov wrote:
> KVM now supports reporting supported Hyper-V features through CPUID
> (KVM_GET_SUPPORTED_HV_CPUID ioctl). Going forward, this is going to be
> the only way to announce new functionality and this has already happened
> with Direct Mode stimers.
> 
> While we could just support KVM_GET_SUPPORTED_HV_CPUID for new features,
> it seems to be beneficial to use it for all Hyper-V enlightenments when
> possible. This way we can implement 'hv-all' pass-through mode giving the
> guest all supported Hyper-V features even when QEMU knows nothing about
> them.
> 
> Implementation-wise we create a new kvm_hyperv_properties structure
> defining Hyper-V features, get_supported_hv_cpuid()/
> get_supported_hv_cpuid_legacy() returning the supported CPUID set and
> a bit over-engineered hv_cpuid_check_and_set() which we will also be
> used to set cpu->hyperv_* properties for 'hv-all' mode.
> 
> Signed-off-by: Vitaly Kuznetsov 
> ---
>  target/i386/kvm.c | 474 ++
>  1 file changed, 356 insertions(+), 118 deletions(-)
> 
> diff --git a/target/i386/kvm.c b/target/i386/kvm.c
> index 3daac1e4f4..6ead422efa 100644
> --- a/target/i386/kvm.c
> +++ b/target/i386/kvm.c
> @@ -684,156 +684,394 @@ static bool tsc_is_stable_and_known(CPUX86State *env)
>  || env->user_tsc_khz;
>  }
>  
> -static int hyperv_handle_properties(CPUState *cs)
> +static struct {
> +const char *desc;
> +struct {
> +uint32_t fw;
> +uint32_t bits;
> +} flags[2];
> +} kvm_hyperv_properties[] = {
> +[HYPERV_FEAT_RELAXED] = {
> +.desc = "relaxed timing (hv-relaxed)",

I'd still like to avoid repeating the feature names.

> +.flags = {
> +{.fw = FEAT_HYPERV_EAX,
> + .bits = HV_HYPERCALL_AVAILABLE},
> +{.fw = FEAT_HV_RECOMM_EAX,
> + .bits = HV_RELAXED_TIMING_RECOMMENDED}
> +}
> +},
> +[HYPERV_FEAT_VAPIC] = {
> +.desc = "virtual APIC (hv-vapic)",
> +.flags = {
> +{.fw = FEAT_HYPERV_EAX,
> + .bits = HV_HYPERCALL_AVAILABLE | HV_APIC_ACCESS_AVAILABLE},
> +{.fw = FEAT_HV_RECOMM_EAX,
> + .bits = HV_APIC_ACCESS_RECOMMENDED}
> +}
> +},
> +[HYPERV_FEAT_TIME] = {
> +.desc = "clocksources (hv-time)",
> +.flags = {
> +{.fw = FEAT_HYPERV_EAX,
> + .bits = HV_HYPERCALL_AVAILABLE | HV_TIME_REF_COUNT_AVAILABLE |
> + HV_REFERENCE_TSC_AVAILABLE}
> +}
> +},
> +[HYPERV_FEAT_CRASH] = {
> +.desc = "crash MSRs (hv-crash)",
> +.flags = {
> +{.fw = FEAT_HYPERV_EDX,
> + .bits = HV_GUEST_CRASH_MSR_AVAILABLE}
> +}
> +},
> +[HYPERV_FEAT_RESET] = {
> +.desc = "reset MSR (hv-reset)",
> +.flags = {
> +{.fw = FEAT_HYPERV_EAX,
> + .bits = HV_RESET_AVAILABLE}
> +}
> +},
> +[HYPERV_FEAT_VPINDEX] = {
> +.desc = "VP_INDEX MSR (hv-vpindex)",
> +.flags = {
> +{.fw = FEAT_HYPERV_EAX,
> + .bits = HV_VP_INDEX_AVAILABLE}
> +}
> +},
> +[HYPERV_FEAT_RUNTIME] = {
> +.desc = "VP_RUNTIME MSR (hv-runtime)",
> +.flags = {
> +{.fw = FEAT_HYPERV_EAX,
> + .bits = HV_VP_RUNTIME_AVAILABLE}
> +}
> +},
> +[HYPERV_FEAT_SYNIC] = {
> +.desc = "synthetic interrupt controller (hv-synic)",
> +.flags = {
> +{.fw = FEAT_HYPERV_EAX,
> + .bits = HV_SYNIC_AVAILABLE}
> +}
> +},
> +[HYPERV_FEAT_STIMER] = {
> +.desc = "synthetic timers (hv-stimer)",
> +.flags = {
> +{.fw = FEAT_HYPERV_EAX,
> + .bits = HV_SYNTIMERS_AVAILABLE}
> +}
> +},
> +[HYPERV_FEAT_FREQUENCIES] = {
> +.desc = "frequency MSRs (hv-frequencies)",
> +.flags = {
> +{.fw = FEAT_HYPERV_EAX,
> + .bits = HV_ACCESS_FREQUENCY_MSRS},
> +{.fw = FEAT_HYPERV_EDX,
> + .bits = HV_FREQUENCY_MSRS_AVAILABLE}
> +}
> +},
> +[HYPERV_FEAT_REENLIGHTENMENT] = {
> +.desc = "reenlightenment MSRs (hv-reenlightenment)",
> +.flags = {
> +{.fw = FEAT_HYPERV_EAX,
> + .bits = HV_ACCESS_REENLIGHTENMENTS_CONTROL}
> +}
> +},
> +[HYPERV_FEAT_TLBFLUSH] = {
> +.desc = "paravirtualized TLB flush (hv-tlbflush)",
> +.flags = {
> +{.fw = FEAT_HV_RECOMM_EAX,
> + .bits = HV_REMOTE_TLB_FLUSH_RECOMMENDED |
> + HV_EX_PROCESSOR_MASKS_RECOMMENDED}
> +}
> +},
> +[HYPERV_FEAT_EVMCS] = {
> +.desc = "enlightened VMCS (hv-evmcs)",
> +.flags = {
> +{.fw = FEAT_HV_RECOMM_EAX,
> + .bits = HV_ENLIGHTENED_VMCS_RECOMMENDED}
> +}
> +},
> +[HYPERV_FEAT_IPI] = {
> +.desc 

Re: [Qemu-devel] [PATCH v2 1/9] i386/kvm: convert hyperv enlightenments properties from bools to bits

[Roman Kagan]

On Fri, May 17, 2019 at 04:19:16PM +0200, Vitaly Kuznetsov wrote:
> Representing Hyper-V properties as bits will allow us to check features
> and dependencies between them in a natural way.
> 
> Suggested-by: Roman Kagan 
> Signed-off-by: Vitaly Kuznetsov 
> ---
>  hw/i386/pc.c  |  3 +-
>  target/i386/cpu.c | 44 +++
>  target/i386/cpu.h | 37 +++
>  target/i386/hyperv.c  |  2 +-
>  target/i386/kvm.c | 83 ++-
>  target/i386/machine.c |  2 +-
>  6 files changed, 91 insertions(+), 80 deletions(-)

Reviewed-by: Roman Kagan 

Re: [Qemu-devel] [PULL v2 04/36] virtio: Introduce started flag to VirtioDevice

[Greg Kurz]

On Mon, 27 May 2019 21:04:38 +0800
Yongji Xie  wrote:

> On Mon, 27 May 2019 at 18:44, Greg Kurz  wrote:
> >
> > On Fri, 24 May 2019 19:56:06 +0800
> > Yongji Xie  wrote:
> >  
> > > On Fri, 24 May 2019 at 18:20, Greg Kurz  wrote:  
> > > >
> > > > On Mon, 20 May 2019 19:10:35 -0400
> > > > "Michael S. Tsirkin"  wrote:
> > > >  
> > > > > From: Xie Yongji 
> > > > >
> > > > > The virtio 1.0 transitional devices support driver uses the device
> > > > > before setting the DRIVER_OK status bit. So we introduce a started
> > > > > flag to indicate whether driver has started the device or not.
> > > > >
> > > > > Signed-off-by: Xie Yongji 
> > > > > Signed-off-by: Zhang Yu 
> > > > > Message-Id: <20190320112646.3712-2-xieyon...@baidu.com>
> > > > > Reviewed-by: Michael S. Tsirkin 
> > > > > Signed-off-by: Michael S. Tsirkin 
> > > > > ---
> > > > >  include/hw/virtio/virtio.h |  2 ++
> > > > >  hw/virtio/virtio.c | 52 
> > > > > --
> > > > >  2 files changed, 52 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> > > > > index 7140381e3a..27c0efc3d0 100644
> > > > > --- a/include/hw/virtio/virtio.h
> > > > > +++ b/include/hw/virtio/virtio.h
> > > > > @@ -105,6 +105,8 @@ struct VirtIODevice
> > > > >  uint16_t device_id;
> > > > >  bool vm_running;
> > > > >  bool broken; /* device in invalid state, needs reset */
> > > > > +bool started;
> > > > > +bool start_on_kick; /* virtio 1.0 transitional devices support 
> > > > > that */
> > > > >  VMChangeStateEntry *vmstate;
> > > > >  char *bus_name;
> > > > >  uint8_t device_endian;
> > > > > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > > > > index 28056a7ef7..5d533ac74e 100644
> > > > > --- a/hw/virtio/virtio.c
> > > > > +++ b/hw/virtio/virtio.c
> > > > > @@ -1162,10 +1162,16 @@ int virtio_set_status(VirtIODevice *vdev, 
> > > > > uint8_t val)
> > > > >  }
> > > > >  }
> > > > >  }
> > > > > +vdev->started = val & VIRTIO_CONFIG_S_DRIVER_OK;
> > > > > +if (unlikely(vdev->start_on_kick && vdev->started)) {
> > > > > +vdev->start_on_kick = false;
> > > > > +}
> > > > > +
> > > > >  if (k->set_status) {
> > > > >  k->set_status(vdev, val);
> > > > >  }
> > > > >  vdev->status = val;
> > > > > +
> > > > >  return 0;
> > > > >  }
> > > > >
> > > > > @@ -1208,6 +1214,9 @@ void virtio_reset(void *opaque)
> > > > >  k->reset(vdev);
> > > > >  }
> > > > >
> > > > > +vdev->start_on_kick = (virtio_host_has_feature(vdev, 
> > > > > VIRTIO_F_VERSION_1) &&
> > > > > +  !virtio_vdev_has_feature(vdev, 
> > > > > VIRTIO_F_VERSION_1));
> > > > > +vdev->started = false;
> > > > >  vdev->broken = false;
> > > > >  vdev->guest_features = 0;
> > > > >  vdev->queue_sel = 0;
> > > > > @@ -1518,14 +1527,21 @@ void virtio_queue_set_align(VirtIODevice 
> > > > > *vdev, int n, int align)
> > > > >
> > > > >  static bool virtio_queue_notify_aio_vq(VirtQueue *vq)
> > > > >  {
> > > > > +bool ret = false;
> > > > > +
> > > > >  if (vq->vring.desc && vq->handle_aio_output) {
> > > > >  VirtIODevice *vdev = vq->vdev;
> > > > >
> > > > >  trace_virtio_queue_notify(vdev, vq - vdev->vq, vq);
> > > > > -return vq->handle_aio_output(vdev, vq);
> > > > > +ret = vq->handle_aio_output(vdev, vq);
> > > > > +
> > > > > +if (unlikely(vdev->start_on_kick)) {
> > > > > +vdev->started = true;
> > > > > +vdev->start_on_kick = false;
> > > > > +}
> > > > >  }
> > > > >
> > > > > -return false;
> > > > > +return ret;
> > > > >  }
> > > > >
> > > > >  static void virtio_queue_notify_vq(VirtQueue *vq)
> > > > > @@ -1539,6 +1555,11 @@ static void virtio_queue_notify_vq(VirtQueue 
> > > > > *vq)
> > > > >
> > > > >  trace_virtio_queue_notify(vdev, vq - vdev->vq, vq);
> > > > >  vq->handle_output(vdev, vq);
> > > > > +
> > > > > +if (unlikely(vdev->start_on_kick)) {
> > > > > +vdev->started = true;
> > > > > +vdev->start_on_kick = false;
> > > > > +}
> > > > >  }
> > > > >  }
> > > > >
> > > > > @@ -1556,6 +1577,11 @@ void virtio_queue_notify(VirtIODevice *vdev, 
> > > > > int n)
> > > > >  } else if (vq->handle_output) {
> > > > >  vq->handle_output(vdev, vq);
> > > > >  }
> > > > > +
> > > > > +if (unlikely(vdev->start_on_kick)) {
> > > > > +vdev->started = true;
> > > > > +vdev->start_on_kick = false;
> > > > > +}
> > > > >  }
> > > > >
> > > > >  uint16_t virtio_queue_vector(VirtIODevice *vdev, int n)
> > > > > @@ -1770,6 +1796,13 @@ static bool virtio_broken_needed(void *opaque)
> > > > >  return vdev->broken;
> > > > >  }
> > > > >
> > > > > +static bool virtio_started_needed(void *opaque)
> > > > > +{
> > > > > +VirtIODevice *vdev = opaque;

Re: [Qemu-devel] [PATCH 0/6] target/rx: Improvements to disassembly

[Yoshinori Sato]

On Fri, 24 May 2019 00:07:57 +0900,
Richard Henderson wrote:
> 
> Here's a sample of the new output, taken from u-boot.bin:
> 
> IN:
> 0xfff8000a:  fb 12 00 01 00 00  mov.l   #0x0100, r1
> 0xfff80010:  fb 32 f0 13 00 00  mov.l   #0x13f0, r3
> 0xfff80016:  43 13  sub r1, r3
> 0xfff80018:  fb 22 00 ea f9 ff  mov.l   #-398848, r2
> 0xfff8001e:  7f 8f  smovf
> 0xfff80020:  ef 01  mov.l   r0, r1
> 0xfff80022:  05 1e 32 00bsr.a   fff83240
> 
> IN:
> 0xfff83240:  72 11 5c fbadd #-1188, r1
> 0xfff83244:  75 21 f0   and #-16, r1
> 0xfff83247:  02 rts
> 
> Obviously there are still a few inconsistencies in the
> format strings used for the immediates, but the format
> is readable and it is easy to look at the opcode to see
> how our decode compares to the manual.
>

Hmm.
The output of the immediate value should be the same as the output of objdump.
I do not think that it is the proper format, but I did that because
it was useful for comparing the results.

> 
> r~
> 
> 
> Richard Henderson (6):
>   target/rx: Disassemble rx_index_addr into a string
>   target/rx: Replace operand with prt_ldmi in disassembler
>   target/rx: Use prt_ldmi for XCHG_mr disassembly
>   target/rx: Emit all disassembly in one prt()
>   target/rx: Collect all bytes during disassembly
>   target/rx: Dump bytes for each insn during disassembly
> 
>  target/rx/disas.c | 366 +-
>  1 file changed, 166 insertions(+), 200 deletions(-)
> 
> -- 
> 2.17.1
> 

-- 
Yosinori Sato

Re: [Qemu-devel] [PATCH 5/6] target/rx: Collect all bytes during disassembly

[Yoshinori Sato]

On Fri, 24 May 2019 00:08:02 +0900,
Richard Henderson wrote:
> 
> Collected, to be used in the next patch.
> 
> Signed-off-by: Richard Henderson 
Reviewed-by: Yoshinori Sato 

> ---
>  target/rx/disas.c | 62 ---
>  1 file changed, 42 insertions(+), 20 deletions(-)
> 
> diff --git a/target/rx/disas.c b/target/rx/disas.c
> index ebc1a44249..5a32a87534 100644
> --- a/target/rx/disas.c
> +++ b/target/rx/disas.c
> @@ -25,43 +25,59 @@ typedef struct DisasContext {
>  disassemble_info *dis;
>  uint32_t addr;
>  uint32_t pc;
> +uint8_t len;
> +uint8_t bytes[8];
>  } DisasContext;
>  
>  
>  static uint32_t decode_load_bytes(DisasContext *ctx, uint32_t insn,
> -   int i, int n)
> +  int i, int n)
>  {
> -bfd_byte buf;
> +uint32_t addr = ctx->addr;
> +
> +g_assert(ctx->len == i);
> +g_assert(n <= ARRAY_SIZE(ctx->bytes));
> +
>  while (++i <= n) {
> -ctx->dis->read_memory_func(ctx->addr++, &buf, 1, ctx->dis);
> -insn |= buf << (32 - i * 8);
> +ctx->dis->read_memory_func(addr++, &ctx->bytes[i - 1], 1, ctx->dis);
> +insn |= ctx->bytes[i - 1] << (32 - i * 8);
>  }
> +ctx->addr = addr;
> +ctx->len = n;
> +
>  return insn;
>  }
>  
>  static int32_t li(DisasContext *ctx, int sz)
>  {
> -int32_t addr;
> -bfd_byte buf[4];
> -addr = ctx->addr;
> +uint32_t addr = ctx->addr;
> +uintptr_t len = ctx->len;
>  
>  switch (sz) {
>  case 1:
> +g_assert(len + 1 <= ARRAY_SIZE(ctx->bytes));
>  ctx->addr += 1;
> -ctx->dis->read_memory_func(addr, buf, 1, ctx->dis);
> -return (int8_t)buf[0];
> +ctx->len += 1;
> +ctx->dis->read_memory_func(addr, ctx->bytes + len, 1, ctx->dis);
> +return (int8_t)ctx->bytes[len];
>  case 2:
> +g_assert(len + 2 <= ARRAY_SIZE(ctx->bytes));
>  ctx->addr += 2;
> -ctx->dis->read_memory_func(addr, buf, 2, ctx->dis);
> -return ldsw_le_p(buf);
> +ctx->len += 2;
> +ctx->dis->read_memory_func(addr, ctx->bytes + len, 2, ctx->dis);
> +return ldsw_le_p(ctx->bytes + len);
>  case 3:
> +g_assert(len + 3 <= ARRAY_SIZE(ctx->bytes));
>  ctx->addr += 3;
> -ctx->dis->read_memory_func(addr, buf, 3, ctx->dis);
> -return (int8_t)buf[2] << 16 | lduw_le_p(buf);
> +ctx->len += 3;
> +ctx->dis->read_memory_func(addr, ctx->bytes + len, 3, ctx->dis);
> +return (int8_t)ctx->bytes[len + 2] << 16 | lduw_le_p(ctx->bytes + 
> len);
>  case 0:
> +g_assert(len + 4 <= ARRAY_SIZE(ctx->bytes));
>  ctx->addr += 4;
> -ctx->dis->read_memory_func(addr, buf, 4, ctx->dis);
> -return ldl_le_p(buf);
> +ctx->len += 4;
> +ctx->dis->read_memory_func(addr, ctx->bytes + len, 4, ctx->dis);
> +return ldl_le_p(ctx->bytes + len);
>  default:
>  g_assert_not_reached();
>  }
> @@ -110,7 +126,7 @@ static const char psw[] = {
>  static void rx_index_addr(DisasContext *ctx, char out[8], int ld, int mi)
>  {
>  uint32_t addr = ctx->addr;
> -uint8_t buf[2];
> +uintptr_t len = ctx->len;
>  uint16_t dsp;
>  
>  switch (ld) {
> @@ -119,14 +135,18 @@ static void rx_index_addr(DisasContext *ctx, char 
> out[8], int ld, int mi)
>  out[0] = '\0';
>  return;
>  case 1:
> +g_assert(len + 1 <= ARRAY_SIZE(ctx->bytes));
>  ctx->addr += 1;
> -ctx->dis->read_memory_func(addr, buf, 1, ctx->dis);
> -dsp = buf[0];
> +ctx->len += 1;
> +ctx->dis->read_memory_func(addr, ctx->bytes + len, 1, ctx->dis);
> +dsp = ctx->bytes[len];
>  break;
>  case 2:
> +g_assert(len + 2 <= ARRAY_SIZE(ctx->bytes));
>  ctx->addr += 2;
> -ctx->dis->read_memory_func(addr, buf, 2, ctx->dis);
> -dsp = lduw_le_p(buf);
> +ctx->len += 2;
> +ctx->dis->read_memory_func(addr, ctx->bytes + len, 2, ctx->dis);
> +dsp = lduw_le_p(ctx->bytes + len);
>  break;
>  default:
>  g_assert_not_reached();
> @@ -1392,8 +1412,10 @@ int print_insn_rx(bfd_vma addr, disassemble_info *dis)
>  DisasContext ctx;
>  uint32_t insn;
>  int i;
> +
>  ctx.dis = dis;
>  ctx.pc = ctx.addr = addr;
> +ctx.len = 0;
>  
>  insn = decode_load(&ctx);
>  if (!decode(&ctx, insn)) {
> -- 
> 2.17.1
> 

Re: [Qemu-devel] [PATCH 2/6] target/rx: Replace operand with prt_ldmi in disassembler

[Yoshinori Sato]

On Fri, 24 May 2019 00:07:59 +0900,
Richard Henderson wrote:
> 
> This has consistency with prt_ri().  It loads all data before
> beginning output.  It uses exactly one call to prt() to emit
> the full instruction.
> 
> Signed-off-by: Richard Henderson 
Reviewed-by: Yoshinori Sato 
> ---
>  target/rx/disas.c | 77 +--
>  1 file changed, 27 insertions(+), 50 deletions(-)
> 
> diff --git a/target/rx/disas.c b/target/rx/disas.c
> index 64342537ee..515b365528 100644
> --- a/target/rx/disas.c
> +++ b/target/rx/disas.c
> @@ -135,18 +135,18 @@ static void rx_index_addr(DisasContext *ctx, char 
> out[8], int ld, int mi)
>  sprintf(out, "%u", dsp << (mi < 3 ? mi : 4 - mi));
>  }
>  
> -static void operand(DisasContext *ctx, int ld, int mi, int rs, int rd)
> +static void prt_ldmi(DisasContext *ctx, const char *insn,
> + int ld, int mi, int rs, int rd)
>  {
>  static const char sizes[][4] = {".b", ".w", ".l", ".uw", ".ub"};
>  char dsp[8];
>  
>  if (ld < 3) {
>  rx_index_addr(ctx, dsp, ld, mi);
> -prt("%s[r%d]%s", dsp, rs, sizes[mi]);
> +prt("%s\t%s[r%d]%s, r%d", insn, dsp, rs, sizes[mi], rd);
>  } else {
> -prt("r%d", rs);
> +prt("%s\tr%d, r%d", insn, rs, rd);
>  }
> -prt(", r%d", rd);
>  }
>  
>  static void prt_ir(DisasContext *ctx, const char *insn, int imm, int rd)
> @@ -416,8 +416,7 @@ static bool trans_AND_ir(DisasContext *ctx, arg_AND_ir *a)
>  /* and rs,rd */
>  static bool trans_AND_mr(DisasContext *ctx, arg_AND_mr *a)
>  {
> -prt("and\t");
> -operand(ctx, a->ld, a->mi, a->rs, a->rd);
> +prt_ldmi(ctx, "and", a->ld, a->mi, a->rs, a->rd);
>  return true;
>  }
>  
> @@ -440,8 +439,7 @@ static bool trans_OR_ir(DisasContext *ctx, arg_OR_ir *a)
>  /* or rs,rd */
>  static bool trans_OR_mr(DisasContext *ctx, arg_OR_mr *a)
>  {
> -prt("or\t");
> -operand(ctx, a->ld, a->mi, a->rs, a->rd);
> +prt_ldmi(ctx, "or", a->ld, a->mi, a->rs, a->rd);
>  return true;
>  }
>  
> @@ -463,8 +461,7 @@ static bool trans_XOR_ir(DisasContext *ctx, arg_XOR_ir *a)
>  /* xor rs,rd */
>  static bool trans_XOR_mr(DisasContext *ctx, arg_XOR_mr *a)
>  {
> -prt("xor\t");
> -operand(ctx, a->ld, a->mi, a->rs, a->rd);
> +prt_ldmi(ctx, "xor", a->ld, a->mi, a->rs, a->rd);
>  return true;
>  }
>  
> @@ -479,8 +476,7 @@ static bool trans_TST_ir(DisasContext *ctx, arg_TST_ir *a)
>  /* tst rs, rd */
>  static bool trans_TST_mr(DisasContext *ctx, arg_TST_mr *a)
>  {
> -prt("tst\t");
> -operand(ctx, a->ld, a->mi, a->rs, a->rd);
> +prt_ldmi(ctx, "tst", a->ld, a->mi, a->rs, a->rd);
>  return true;
>  }
>  
> @@ -548,8 +544,7 @@ static bool trans_ADD_irr(DisasContext *ctx, arg_ADD_irr 
> *a)
>  /* add dsp[rs], rd */
>  static bool trans_ADD_mr(DisasContext *ctx, arg_ADD_mr *a)
>  {
> -prt("add\t");
> -operand(ctx, a->ld, a->mi, a->rs, a->rd);
> +prt_ldmi(ctx, "add", a->ld, a->mi, a->rs, a->rd);
>  return true;
>  }
>  
> @@ -573,8 +568,7 @@ static bool trans_CMP_ir(DisasContext *ctx, arg_CMP_ir *a)
>  /* cmp dsp[rs], rs2 */
>  static bool trans_CMP_mr(DisasContext *ctx, arg_CMP_mr *a)
>  {
> -prt("cmp\t");
> -operand(ctx, a->ld, a->mi, a->rs, a->rd);
> +prt_ldmi(ctx, "cmp", a->ld, a->mi, a->rs, a->rd);
>  return true;
>  }
>  
> @@ -589,8 +583,7 @@ static bool trans_SUB_ir(DisasContext *ctx, arg_SUB_ir *a)
>  /* sub dsp[rs], rd */
>  static bool trans_SUB_mr(DisasContext *ctx, arg_SUB_mr *a)
>  {
> -prt("sub\t");
> -operand(ctx, a->ld, a->mi, a->rs, a->rd);
> +prt_ldmi(ctx, "sub", a->ld, a->mi, a->rs, a->rd);
>  return true;
>  }
>  
> @@ -611,8 +604,7 @@ static bool trans_SBB_rr(DisasContext *ctx, arg_SBB_rr *a)
>  /* sbb dsp[rs], rd */
>  static bool trans_SBB_mr(DisasContext *ctx, arg_SBB_mr *a)
>  {
> -prt("sbb\t");
> -operand(ctx, a->ld, RX_IM_LONG, a->rs, a->rd);
> +prt_ldmi(ctx, "sbb", a->ld, RX_IM_LONG, a->rs, a->rd);
>  return true;
>  }
>  
> @@ -640,8 +632,7 @@ static bool trans_MAX_ir(DisasContext *ctx, arg_MAX_ir *a)
>  /* max dsp[rs], rd */
>  static bool trans_MAX_mr(DisasContext *ctx, arg_MAX_mr *a)
>  {
> -prt("max\t");
> -operand(ctx, a->ld, a->mi, a->rs, a->rd);
> +prt_ldmi(ctx, "max", a->ld, a->mi, a->rs, a->rd);
>  return true;
>  }
>  
> @@ -656,8 +647,7 @@ static bool trans_MIN_ir(DisasContext *ctx, arg_MIN_ir *a)
>  /* min dsp[rs], rd */
>  static bool trans_MIN_mr(DisasContext *ctx, arg_MIN_mr *a)
>  {
> -prt("max\t");
> -operand(ctx, a->ld, a->mi, a->rs, a->rd);
> +prt_ldmi(ctx, "min", a->ld, a->mi, a->rs, a->rd);
>  return true;
>  }
>  
> @@ -673,8 +663,7 @@ static bool trans_MUL_ir(DisasContext *ctx, arg_MUL_ir *a)
>  /* mul dsp[rs], rd */
>  static bool trans_MUL_mr(DisasContext *ctx, arg_MUL_mr *a)
>  {
> -prt("mul\t");
> -operand(ctx, a->ld, a->mi, a->rs, a->rd);
> +prt_ldmi(ctx, "mul", a->ld, a->mi, a->rs, a->rd);
>  retu

Re: [Qemu-devel] [PATCH 4/6] target/rx: Emit all disassembly in one prt()

[Yoshinori Sato]

On Fri, 24 May 2019 00:08:01 +0900,
Richard Henderson wrote:
> 
> Many of the multi-part prints have been eliminated by previous
> patches.  Eliminate the rest of them.
> 
> Signed-off-by: Richard Henderson 
Reviewed-by: Yoshinori Sato 

> ---
>  target/rx/disas.c | 75 ---
>  1 file changed, 39 insertions(+), 36 deletions(-)
> 
> diff --git a/target/rx/disas.c b/target/rx/disas.c
> index db10385fd0..ebc1a44249 100644
> --- a/target/rx/disas.c
> +++ b/target/rx/disas.c
> @@ -228,24 +228,21 @@ static bool trans_MOV_ra(DisasContext *ctx, arg_MOV_ra 
> *a)
>  /* mov.[bwl] rs,rd */
>  static bool trans_MOV_mm(DisasContext *ctx, arg_MOV_mm *a)
>  {
> -char dspd[8], dsps[8];
> +char dspd[8], dsps[8], szc = size[a->sz];
>  
> -prt("mov.%c\t", size[a->sz]);
>  if (a->lds == 3 && a->ldd == 3) {
>  /* mov.[bwl] rs,rd */
> -prt("r%d, r%d", a->rs, a->rd);
> -return true;
> -}
> -if (a->lds == 3) {
> +prt("mov.%c\tr%d, r%d", szc, a->rs, a->rd);
> +} else if (a->lds == 3) {
>  rx_index_addr(ctx, dspd, a->ldd, a->sz);
> -prt("r%d, %s[r%d]", a->rs, dspd, a->rd);
> +prt("mov.%c\tr%d, %s[r%d]", szc, a->rs, dspd, a->rd);
>  } else if (a->ldd == 3) {
>  rx_index_addr(ctx, dsps, a->lds, a->sz);
> -prt("%s[r%d], r%d", dsps, a->rs, a->rd);
> +prt("mov.%c\t%s[r%d], r%d", szc, dsps, a->rs, a->rd);
>  } else {
>  rx_index_addr(ctx, dsps, a->lds, a->sz);
>  rx_index_addr(ctx, dspd, a->ldd, a->sz);
> -prt("%s[r%d], %s[r%d]", dsps, a->rs, dspd, a->rd);
> +prt("mov.%c\t%s[r%d], %s[r%d]", szc, dsps, a->rs, dspd, a->rd);
>  }
>  return true;
>  }
> @@ -254,8 +251,11 @@ static bool trans_MOV_mm(DisasContext *ctx, arg_MOV_mm 
> *a)
>  /* mov.[bwl] rs,[-rd] */
>  static bool trans_MOV_rp(DisasContext *ctx, arg_MOV_rp *a)
>  {
> -prt("mov.%c\tr%d, ", size[a->sz], a->rs);
> -prt((a->ad == 0) ? "[r%d+]" : "[-r%d]", a->rd);
> +if (a->ad) {
> +prt("mov.%c\tr%d, [-r%d]", size[a->sz], a->rs, a->rd);
> +} else {
> +prt("mov.%c\tr%d, [r%d+]", size[a->sz], a->rs, a->rd);
> +}
>  return true;
>  }
>  
> @@ -263,9 +263,11 @@ static bool trans_MOV_rp(DisasContext *ctx, arg_MOV_rp 
> *a)
>  /* mov.[bwl] [-rd],rs */
>  static bool trans_MOV_pr(DisasContext *ctx, arg_MOV_pr *a)
>  {
> -prt("mov.%c\t", size[a->sz]);
> -prt((a->ad == 0) ? "[r%d+]" : "[-r%d]", a->rd);
> -prt(", r%d", a->rs);
> +if (a->ad) {
> +prt("mov.%c\t[-r%d], r%d", size[a->sz], a->rd, a->rs);
> +} else {
> +prt("mov.%c\t[r%d+], r%d", size[a->sz], a->rd, a->rs);
> +}
>  return true;
>  }
>  
> @@ -299,9 +301,11 @@ static bool trans_MOVU_ar(DisasContext *ctx, arg_MOVU_ar 
> *a)
>  /* movu.[bw] [-rs],rd */
>  static bool trans_MOVU_pr(DisasContext *ctx, arg_MOVU_pr *a)
>  {
> -prt("movu.%c\t", size[a->sz]);
> -prt((a->ad == 0) ? "[r%d+]" : "[-r%d]", a->rd);
> -prt(", r%d", a->rs);
> +if (a->ad) {
> +prt("movu.%c\t[-r%d], r%d", size[a->sz], a->rd, a->rs);
> +} else {
> +prt("movu.%c\t[r%d+], r%d", size[a->sz], a->rd, a->rs);
> +}
>  return true;
>  }
>  
> @@ -478,11 +482,11 @@ static bool trans_TST_mr(DisasContext *ctx, arg_TST_mr 
> *a)
>  /* not rs, rd */
>  static bool trans_NOT_rr(DisasContext *ctx, arg_NOT_rr *a)
>  {
> -prt("not\t");
>  if (a->rs != a->rd) {
> -prt("r%d, ", a->rs);
> +prt("not\tr%d, r%d", a->rs, a->rd);
> +} else {
> +prt("not\tr%d", a->rs);
>  }
> -prt("r%d", a->rd);
>  return true;
>  }
>  
> @@ -490,11 +494,11 @@ static bool trans_NOT_rr(DisasContext *ctx, arg_NOT_rr 
> *a)
>  /* neg rs, rd */
>  static bool trans_NEG_rr(DisasContext *ctx, arg_NEG_rr *a)
>  {
> -prt("neg\t");
>  if (a->rs != a->rd) {
> -prt("r%d, ", a->rs);
> +prt("neg\tr%d, r%d", a->rs, a->rd);
> +} else {
> +prt("neg\tr%d", a->rs);
>  }
> -prt("r%d", a->rd);
>  return true;
>  }
>  
> @@ -606,11 +610,10 @@ static bool trans_SBB_mr(DisasContext *ctx, arg_SBB_mr 
> *a)
>  /* abs rs, rd */
>  static bool trans_ABS_rr(DisasContext *ctx, arg_ABS_rr *a)
>  {
> -prt("abs\t");
> -if (a->rs == a->rd) {
> -prt("r%d", a->rd);
> +if (a->rs != a->rd) {
> +prt("abs\tr%d, r%d", a->rs, a->rd);
>  } else {
> -prt("r%d, r%d", a->rs, a->rd);
> +prt("abs\tr%d", a->rs);
>  }
>  return true;
>  }
> @@ -733,11 +736,11 @@ static bool trans_DIVU_mr(DisasContext *ctx, 
> arg_DIVU_mr *a)
>  /* shll #imm:5, rs, rd */
>  static bool trans_SHLL_irr(DisasContext *ctx, arg_SHLL_irr *a)
>  {
> -prt("shll\t#%d, ", a->imm);
>  if (a->rs2 != a->rd) {
> -prt("r%d, ", a->rs2);
> +prt("shll\t#%d, r%d, r%d", a->imm, a->rs2, a->rd);
> +} else {
> +prt("shll\t#%d, r%d", a->imm, a->rd);
>  }
> -prt("r%d", a->rd);
>  retur

Re: [Qemu-devel] [PATCH 6/6] target/rx: Dump bytes for each insn during disassembly

[Yoshinori Sato]

On Fri, 24 May 2019 00:08:03 +0900,
Richard Henderson wrote:
> 
> There are so many different forms of each RX instruction
> that it will be very useful to be able to look at the bytes
> to see on which path a bug may lie.
> 
> Signed-off-by: Richard Henderson 
Reviewed-by: Yoshinori Sato 

> ---
>  target/rx/disas.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/target/rx/disas.c b/target/rx/disas.c
> index 5a32a87534..d73b53db44 100644
> --- a/target/rx/disas.c
> +++ b/target/rx/disas.c
> @@ -102,7 +102,21 @@ static int bdsp_s(DisasContext *ctx, int d)
>  /* Include the auto-generated decoder.  */
>  #include "decode.inc.c"
>  
> -#define prt(...) (ctx->dis->fprintf_func)((ctx->dis->stream), __VA_ARGS__)
> +static void dump_bytes(DisasContext *ctx)
> +{
> +int i, len = ctx->len;
> +
> +for (i = 0; i < len; ++i) {
> +ctx->dis->fprintf_func(ctx->dis->stream, "%02x ", ctx->bytes[i]);
> +}
> +ctx->dis->fprintf_func(ctx->dis->stream, "%*c", (8 - i) * 3, '\t');
> +}
> +
> +#define prt(...) \
> +do {\
> +dump_bytes(ctx);\
> +ctx->dis->fprintf_func(ctx->dis->stream, __VA_ARGS__);  \
> +} while (0)
>  
>  #define RX_MEMORY_BYTE 0
>  #define RX_MEMORY_WORD 1
> -- 
> 2.17.1
> 

Re: [Qemu-devel] [PATCH 3/6] target/rx: Use prt_ldmi for XCHG_mr disassembly

[Yoshinori Sato]

On Fri, 24 May 2019 00:08:00 +0900,
Richard Henderson wrote:
> 
> Note that the ld == 3 case handled by prt_ldmi is decoded as
> XCHG_rr and cannot appear here.
> 
> Signed-off-by: Richard Henderson 
Reviewed-by: Yoshinori Sato 

> ---
>  target/rx/disas.c | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/target/rx/disas.c b/target/rx/disas.c
> index 515b365528..db10385fd0 100644
> --- a/target/rx/disas.c
> +++ b/target/rx/disas.c
> @@ -366,13 +366,7 @@ static bool trans_XCHG_rr(DisasContext *ctx, arg_XCHG_rr 
> *a)
>  /* xchg dsp[rs].,rd */
>  static bool trans_XCHG_mr(DisasContext *ctx, arg_XCHG_mr *a)
>  {
> -static const char msize[][4] = {
> -"b", "w", "l", "ub", "uw",
> -};
> -char dsp[8];
> -
> -rx_index_addr(ctx, dsp, a->ld, a->mi);
> -prt("xchg\t%s[r%d].%s, r%d", dsp, a->rs, msize[a->mi], a->rd);
> +prt_ldmi(ctx, "xchg", a->ld, a->mi, a->rs, a->rd);
>  return true;
>  }
>  
> -- 
> 2.17.1
> 

Re: [Qemu-devel] [PATCH 1/6] target/rx: Disassemble rx_index_addr into a string

[Yoshinori Sato]

On Fri, 24 May 2019 00:07:58 +0900,
Richard Henderson wrote:
> 
> We were eliding all zero indexes.  It is only ld==0 that does
> not have an index in the instruction.  This also allows us to
> avoid breaking the final print into multiple pieces.
> 
> Signed-off-by: Richard Henderson 
Reviewed-by: Yoshinori Sato 

> ---
>  target/rx/disas.c | 154 +-
>  1 file changed, 55 insertions(+), 99 deletions(-)
> 
> diff --git a/target/rx/disas.c b/target/rx/disas.c
> index 8cada4825d..64342537ee 100644
> --- a/target/rx/disas.c
> +++ b/target/rx/disas.c
> @@ -107,49 +107,42 @@ static const char psw[] = {
>  'i', 'u', 0, 0, 0, 0, 0, 0,
>  };
>  
> -static uint32_t rx_index_addr(int ld, int size, DisasContext *ctx)
> +static void rx_index_addr(DisasContext *ctx, char out[8], int ld, int mi)
>  {
> -bfd_byte buf[2];
> +uint32_t addr = ctx->addr;
> +uint8_t buf[2];
> +uint16_t dsp;
> +
>  switch (ld) {
>  case 0:
> -return 0;
> +/* No index; return empty string.  */
> +out[0] = '\0';
> +return;
>  case 1:
> -ctx->dis->read_memory_func(ctx->addr, buf, 1, ctx->dis);
>  ctx->addr += 1;
> -return ((uint8_t)buf[0]) << size;
> +ctx->dis->read_memory_func(addr, buf, 1, ctx->dis);
> +dsp = buf[0];
> +break;
>  case 2:
> -ctx->dis->read_memory_func(ctx->addr, buf, 2, ctx->dis);
>  ctx->addr += 2;
> -return lduw_le_p(buf) << size;
> +ctx->dis->read_memory_func(addr, buf, 2, ctx->dis);
> +dsp = lduw_le_p(buf);
> +break;
> +default:
> +g_assert_not_reached();
>  }
> -g_assert_not_reached();
> +
> +sprintf(out, "%u", dsp << (mi < 3 ? mi : 4 - mi));
>  }
>  
>  static void operand(DisasContext *ctx, int ld, int mi, int rs, int rd)
>  {
> -int dsp;
>  static const char sizes[][4] = {".b", ".w", ".l", ".uw", ".ub"};
> +char dsp[8];
> +
>  if (ld < 3) {
> -switch (mi) {
> -case 4:
> -/* dsp[rs].ub */
> -dsp = rx_index_addr(ld, RX_MEMORY_BYTE, ctx);
> -break;
> -case 3:
> -/* dsp[rs].uw */
> -dsp = rx_index_addr(ld, RX_MEMORY_WORD, ctx);
> -break;
> -default:
> -/* dsp[rs].b */
> -/* dsp[rs].w */
> -/* dsp[rs].l */
> -dsp = rx_index_addr(ld, mi, ctx);
> -break;
> -}
> -if (dsp > 0) {
> -prt("%d", dsp);
> -}
> -prt("[r%d]%s", rs, sizes[mi]);
> +rx_index_addr(ctx, dsp, ld, mi);
> +prt("%s[r%d]%s", dsp, rs, sizes[mi]);
>  } else {
>  prt("r%d", rs);
>  }
> @@ -235,7 +228,7 @@ static bool trans_MOV_ra(DisasContext *ctx, arg_MOV_ra *a)
>  /* mov.[bwl] rs,rd */
>  static bool trans_MOV_mm(DisasContext *ctx, arg_MOV_mm *a)
>  {
> -int dsp;
> +char dspd[8], dsps[8];
>  
>  prt("mov.%c\t", size[a->sz]);
>  if (a->lds == 3 && a->ldd == 3) {
> @@ -244,29 +237,15 @@ static bool trans_MOV_mm(DisasContext *ctx, arg_MOV_mm 
> *a)
>  return true;
>  }
>  if (a->lds == 3) {
> -prt("r%d, ", a->rd);
> -dsp = rx_index_addr(a->ldd, a->sz, ctx);
> -if (dsp > 0) {
> -prt("%d", dsp);
> -}
> -prt("[r%d]", a->rs);
> +rx_index_addr(ctx, dspd, a->ldd, a->sz);
> +prt("r%d, %s[r%d]", a->rs, dspd, a->rd);
>  } else if (a->ldd == 3) {
> -dsp = rx_index_addr(a->lds, a->sz, ctx);
> -if (dsp > 0) {
> -prt("%d", dsp);
> -}
> -prt("[r%d], r%d", a->rs, a->rd);
> +rx_index_addr(ctx, dsps, a->lds, a->sz);
> +prt("%s[r%d], r%d", dsps, a->rs, a->rd);
>  } else {
> -dsp = rx_index_addr(a->lds, a->sz, ctx);
> -if (dsp > 0) {
> -prt("%d", dsp);
> -}
> -prt("[r%d], ", a->rs);
> -dsp = rx_index_addr(a->ldd, a->sz, ctx);
> -if (dsp > 0) {
> -prt("%d", dsp);
> -}
> -prt("[r%d]", a->rd);
> +rx_index_addr(ctx, dsps, a->lds, a->sz);
> +rx_index_addr(ctx, dspd, a->ldd, a->sz);
> +prt("%s[r%d], %s[r%d]", dsps, a->rs, dspd, a->rd);
>  }
>  return true;
>  }
> @@ -357,12 +336,10 @@ static bool trans_PUSH_r(DisasContext *ctx, arg_PUSH_r 
> *a)
>  /* push dsp[rs] */
>  static bool trans_PUSH_m(DisasContext *ctx, arg_PUSH_m *a)
>  {
> -prt("push\t");
> -int dsp = rx_index_addr(a->ld, a->sz, ctx);
> -if (dsp > 0) {
> -prt("%d", dsp);
> -}
> -prt("[r%d]", a->rs);
> +char dsp[8];
> +
> +rx_index_addr(ctx, dsp, a->ld, a->sz);
> +prt("push\t%s[r%d]", dsp, a->rs);
>  return true;
>  }
>  
> @@ -389,17 +366,13 @@ static bool trans_XCHG_rr(DisasContext *ctx, 
> arg_XCHG_rr *a)
>  /* xchg dsp[rs].,rd */
>  static bool trans_XCHG_mr(DisasContext *ctx, arg_XCHG_mr *a)
>  {
> -int dsp;
>  stati

Re: [Qemu-devel] [PATCH v4 00/20] monitor: add asynchronous command type

[Marc-André Lureau]

Hi

On Mon, May 27, 2019 at 3:23 PM Markus Armbruster  wrote:
>
> Gerd Hoffmann  writes:
>
> > On Mon, May 27, 2019 at 10:18:42AM +0200, Markus Armbruster wrote:
> >> Marc-André Lureau  writes:
> >>
> >> > Hi
> >> >
> >> > On Thu, May 23, 2019 at 9:52 AM Markus Armbruster  
> >> > wrote:
> >> >> I'm not sure how asynchronous commands could support reconnect and
> >> >> resume.
> >> >
> >> > The same way as current commands, including job commands.
> >>
> >> Consider the following scenario: a management application such as
> >> libvirt starts a long-running task with the intent to monitor it until
> >> it finishes.  Half-way through, the management application needs to
> >> disconnect and reconnect for some reason (systemctl restart, or crash &
> >> recover, or whatever).
> >>
> >> If the long-running task is a job, the management application can resume
> >> after reconnect: the job's ID is as valid as it was before, and the
> >> commands to query and control the job work as before.
> >>
> >> What if it's and asynchronous command?
> >
> > This is not meant for some long-running job which you have to manage.
> >
> > Allowing commands being asynchronous makes sense for things which (a)
> > typically don't take long, and (b) don't need any management.
> >
> > So, if the connection goes down the job is simply canceled, and after
> > reconnecting the management can simply send the same command again.
>
> Is this worth its own infrastructure?

Yes, not having to change/break the client side API is worth some effort.

> Would you hazard a guess on how many commands can take long enough to
> demand a conversion to asynchronous, yet not need any management?

Some of the currently synchronous commands that are doing some
substantial task (many of them are not simply reading values from
memory) could be gradually converted, as needed.

> >> > Whenever we can solve things on qemu side, I would rather not
> >> > deprecate current API.
> >>
> >> Making a synchronous command asynchronous definitely changes API.
> >
> > Inside qemu yes, sure.  But for the QMP client nothing changes.
>
> Command replies can arrive out of order, can't they?

They are returned in order, see "QmpSession: return orderly".


-- 
Marc-André Lureau

[Qemu-devel] [Bug 1829682] Re: QEMU PPC SYSTEM regression - 3.1.0 and GIT - Fail to boot AIX

[Greg Kurz]

** Changed in: qemu
   Status: New => Confirmed

** Changed in: qemu
 Assignee: (unassigned) => Greg Kurz (gkurz)

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

Title:
  QEMU PPC SYSTEM regression - 3.1.0 and GIT - Fail to boot AIX

Status in QEMU:
  Confirmed

Bug description:
  Built from source on a debian system

  Linux db08 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux
  gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)

  Last git commit (from queued gdibson repository)

  starting AIX 7.2 TL 2 SP 2 with the following : (the install was done
  under qemu 3.1.0)

  qemu-system-ppc64 -M pseries \
  -cpu power7 \
  -cdrom AIX_v7.2_Install_7200-02-02-1806_DVD_1_of_2_32018.iso \
  -net nic \
  -net tap,ifname=tap2,script=no \
  -drive file=DISK1.IMG,if=none,id=drive-virtio-disk0 \
  -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=drive-virtio-disk0 \
  -m 4G \
  -serial stdio \
  -monitor unix:ms,server,nowait \
  -accel tcg \
  -k fr \
  -nographic \
  -prom-env input-device=/vdevice/vty@7100 \
  -prom-env output-device=/vdevice/vty@7100 \
  -prom-env diag-switch?=false \
  -prom-env boot-command="boot 
/pci@8002000/scsi@2/disk@100 -s verbose"

  Yields this :

  
  ^M
  SLOF^[[0m^[[?25l 
**^M
  ^[[1mQEMU Starting^M
  ^[[0m Build Date = Jan 14 2019 18:00:39^M
   FW Version = git-a5b428e1c1eae703^M
   Press "s" to enter Open Firmware.^M^M
  ^M^M
  
^[[0m^[[?25hC^MC0100^MC0120^MC0140^MC0200^MC0240^MC0260^MC02E0^MC0300^MC0320^MC0340^MC0360^MC0370^MC0380^MC0371^MC0372^MC0373^MC0374^MC03F0^MC0400^MC0480^MC04C0^MC04D0^MC0500^MPopulating
 /vdevice methods^M
  Populating /vdevice/vty@7100^M
  Populating /vdevice/nvram@7101^M
  Populating /vdevice/l-lan@7102^M
  Populating /vdevice/v-scsi@7103^M
 SCSI: Looking for devices^M
8200 CD-ROM   : "QEMU QEMU CD-ROM  2.5+"^M
  C05A0^MPopulating /pci@8002000^M
   00  (D) : 1234 qemu vga^M
   00 0800 (D) : 1033 0194serial bus [ usb-xhci ]^M
   00 1000 (D) : 1af4 1004virtio [ scsi ]^M
  Populating /pci@8002000/scsi@2^M
 SCSI: Looking for devices^M
100 DISK : "QEMU QEMU HARDDISK2.5+"^M
  C0600^MC06C0^MC0700^MC0800^MC0880^MC0890^MC08A0^MC08A8^MInstalling QEMU fb^M
  ^M
  ^M
  ^M
  C08B0^MScanning USB ^M
XHCI: Initializing^M
  USB Keyboard ^M
  USB mouse ^M
  C08C0^MC08D0^MNo console specified using screen & keyboard^M
  User selected input-device console: /vdevice/vty@7100^M
  User selected output-device console: /vdevice/vty@7100^M
  C08E0^MC08E8^MC08FF^M ^M
Welcome to Open Firmware^M
  ^M
Copyright (c) 2004, 2017 IBM Corporation All rights reserved.^M
This program and the accompanying materials are made available^M
under the terms of the BSD License available at^M
http://www.opensource.org/licenses/bsd-license.php^M
  ^M
  ^M
  Trying to load: -s verbose from: 
/pci@8002000/scsi@2/disk@100 ...   Successfully loaded^M
  ^M
  ---> qemu,pseries detected <---^M
  ^M
  ^M
  ^M
  ^M
  ^M
  ^M
  ^M
  
---^M
  Welcome to AIX.^M
 boot image timestamp: 05:56:13 04/20/2019^M
  processor count: 1;  memory size: 4096MB;  kernel size: 38426884^M
   boot device: /pci@8002000/scsi@2/disk@100^M
  ^M
  8000FFEC bytes of free memory remain at address 7FFF0014^M
  load address: 0x4000   aixmon size: 0x000D2C00   boot image size: 
0x01A6B430^M
  ^LAIX vm,uuid property contains invalid data^Mload address: 0x4000   
aixmon size: 0x000D2C00   boot image size: 0x01A6B430^M
  ^LAIX vm,uuid property contains invalid data^M
  get_ppp return code: 0xFFFE^M
  ^M
  AKVM: hcall-multi-tce detected but overridden, allow with "multce" boot 
argument^M
  The temporary memory region list is at 1 percent capacity.^M
  The temporary IPLCB is at 1 percent capacity.^M
  The IPLCB address is 0x0FFF9000^M
  name offset   size^M
  ipl_cb_and_bit_map  ..5958^M
  bit_map... 0790 ..0006^M
  ipl_info.. 01C8 ..0024^M
  splpar_info... 01EC ..0048^M
  system_info... 0234 ..00C4^M
  processor_info 02F8 ..0148^M
  lpar_id_info.. 0440 ..0088^M
  dr_proc_info.. 04C8 ..0008^M
  dr_mem_info... 04D0 ..0028^M
  lpar_info. 04F8 ..0014^M
  segment page.. 0518 ..0028^M
  p

Re: [Qemu-devel] [PATCH v2 2/2] block: avoid recursive block_status call if possible

[Max Reitz]

On 08.04.19 18:26, Vladimir Sementsov-Ogievskiy wrote:
> drv_co_block_status digs bs->file for additional, more accurate search
> for hole inside region, reported as DATA by bs since 5daa74a6ebc.
> 
> This accuracy is not free: assume we have qcow2 disk. Actually, qcow2
> knows, where are holes and where is data. But every block_status
> request calls lseek additionally. Assume a big disk, full of
> data, in any iterative copying block job (or img convert) we'll call
> lseek(HOLE) on every iteration, and each of these lseeks will have to
> iterate through all metadata up to the end of file. It's obviously
> ineffective behavior. And for many scenarios we don't need this lseek
> at all.
> 
> However, lseek is needed when we have metadata-preallocated image.
> 
> So, let's detect metadata-preallocation case and don't dig qcow2's
> protocol file in other cases.
> 
> The idea is to compare allocation size in POV of filesystem with
> allocations size in POV of Qcow2 (by refcounts). If allocation in fs is
> significantly lower, consider it as metadata-preallocation case.
> 
> 102 iotest changed, as our detector can't detect shrinked file as
> metadata-preallocation, which don't seem to be wrong, as with metadata
> preallocation we always have valid file length.
> 
> Other two iotests tiny changed QMP output sequence, which should be
> exactly because skipped lseek at mirror beginning.
> 
> Suggested-by: Denis V. Lunev 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  block/qcow2.h  |  4 
>  include/block/block.h  |  8 +++-
>  block/io.c |  9 -
>  block/qcow2-refcount.c | 32 
>  block/qcow2.c  | 11 +++
>  tests/qemu-iotests/102 |  2 +-
>  tests/qemu-iotests/102.out |  3 ++-
>  tests/qemu-iotests/141.out |  2 +-
>  tests/qemu-iotests/144.out |  2 +-
>  9 files changed, 67 insertions(+), 6 deletions(-)

For me, this patch breaks iotests 141 (for qed) and 211 (for vdi):

> 141 1s ...[17:11:53] [17:11:53] - output mismatch (see 141.out.bad)
> --- tests/qemu-iotests/141.out 2019-05-27 17:11:43.327664282 +0200
> +++ build/tests/qemu-iotests/141.out.bad   2019-05-27 17:11:53.949439880 
> +0200
> @@ -42,9 +42,9 @@
>  {"return": {}}
>  {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
> "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "job0"}}
>  {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
> "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "job0"}}
> -{"return": {}}
>  {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
> "JOB_STATUS_CHANGE", "data": {"status": "ready", "id": "job0"}}
>  {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
> "BLOCK_JOB_READY", "data": {"device": "job0", "len": 0, "offset": 0, "speed": 
> 0, "type": "commit"}}
> +{"return": {}}
>  {"error": {"class": "GenericError", "desc": "Node 'drv0' is busy: block 
> device is in use by block job: commit"}}
>  {"return": {}}
>  {"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
> "JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "job0"}}

and

> 211 5s ...[17:11:54] [17:11:58] - output mismatch (see 211.out.bad)
> --- tests/qemu-iotests/211.out 2019-05-22 19:58:34.870273427 +0200
> +++ build/tests/qemu-iotests/211.out.bad   2019-05-27 17:11:58.259348827 
> +0200
> @@ -55,8 +55,7 @@
>  virtual size: 32 MiB (33554432 bytes)
>  cluster_size: 1048576
>  
> -[{ "start": 0, "length": 3072, "depth": 0, "zero": false, "data": true, 
> "offset": 1024},
> -{ "start": 3072, "length": 33551360, "depth": 0, "zero": true, "data": true, 
> "offset": 4096}]
> +[{ "start": 0, "length": 33554432, "depth": 0, "zero": false, "data": true, 
> "offset": 1024}]
>  
>  === Invalid BlockdevRef ===

Doesn’t look too bad, but still, broken iotests are broken iotests. :/

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] Failing qemu-iotest 211 with -vdi

[Max Reitz]

On 28.04.19 17:43, Thomas Huth wrote:
> QEMU iotest 211 is failing for me, too, when I run it with -vdi:
> 
> tests/qemu-iotests$ ./check -vdi 211
> QEMU  -- 
> "/home/thuth/tmp/qemu-build/tests/qemu-iotests/../../x86_64-softmmu/qemu-system-x86_64"
>  -nodefaults -machine accel=qtest
> QEMU_IMG  -- 
> "/home/thuth/tmp/qemu-build/tests/qemu-iotests/../../qemu-img" 
> QEMU_IO   -- 
> "/home/thuth/tmp/qemu-build/tests/qemu-iotests/../../qemu-io"  --cache 
> writeback -f vdi
> QEMU_NBD  -- 
> "/home/thuth/tmp/qemu-build/tests/qemu-iotests/../../qemu-nbd" 
> IMGFMT-- vdi
> IMGPROTO  -- file
> PLATFORM  -- Linux/x86_64 thuth 3.10.0-957.10.1.el7.x86_64
> TEST_DIR  -- /home/thuth/tmp/qemu-build/tests/qemu-iotests/scratch
> SOCKET_SCM_HELPER -- 
> /home/thuth/tmp/qemu-build/tests/qemu-iotests/socket_scm_helper
> 
> 211 - output mismatch (see 211.out.bad)
> --- /home/thuth/devel/qemu/tests/qemu-iotests/211.out 2019-04-23 
> 16:43:12.0 +0200
> +++ /home/thuth/tmp/qemu-build/tests/qemu-iotests/211.out.bad 2019-04-28 
> 17:41:19.0 +0200
> @@ -55,8 +55,7 @@
>  virtual size: 32M (33554432 bytes)
>  cluster_size: 1048576
>  
> -[{ "start": 0, "length": 3072, "depth": 0, "zero": false, "data": true, 
> "offset": 1024},
> -{ "start": 3072, "length": 33551360, "depth": 0, "zero": true, "data": true, 
> "offset": 4096}]
> +[{ "start": 0, "length": 33554432, "depth": 0, "zero": true, "data": true, 
> "offset": 1024}]
>  
>  === Invalid BlockdevRef ===
>  
> Failures: 211
> Failed 1 of 1 tests
> 
> Any ideas how to fix this?

...now I see this, too.  Time to investigate.

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v6] hw/acpi: extract acpi_add_rom_blob()

[Michael S. Tsirkin]

On Mon, May 27, 2019 at 10:34:23AM +0800, Wei Yang wrote:
> On Tue, Mar 26, 2019 at 10:43:20AM +0800, Wei Yang wrote:
> >arm and i386 has almost the same function acpi_add_rom_blob(), except
> >giving different FWCfgCallback function.
> >
> >This patch moves acpi_add_rom_blob() to utils.c by passing
> >FWCfgCallback to it.
> >
> >Signed-off-by: Wei Yang 
> >Reviewed-by: Igor Mammedov 
> >
> 
> Hello~ would this one be picked up?


Yes in the next pull. It's a holiday here in states -
hopefully tomorrow.

> >---
> >v6:
> >  * change author from Igor to Michael
> >v5:
> >  * remove unnecessary header glib/gprintf.h
> >  * rearrange include header to make it more suitable
> >v4:
> >  * extract -> moves
> >  * adjust comment in source to make checkpatch happy
> >v3:
> >  * put acpi_add_rom_blob() to hw/acpi/utils.c
> >v2:
> >  * remove unused header in original source file
> >
> >author
> >---
> > hw/acpi/Makefile.objs|  2 +-
> > hw/acpi/utils.c  | 36 
> > hw/arm/virt-acpi-build.c | 26 ++
> > hw/i386/acpi-build.c | 26 ++
> > include/hw/acpi/utils.h  |  9 +
> > 5 files changed, 66 insertions(+), 33 deletions(-)
> > create mode 100644 hw/acpi/utils.c
> > create mode 100644 include/hw/acpi/utils.h
> >
> >diff --git a/hw/acpi/Makefile.objs b/hw/acpi/Makefile.objs
> >index 2d46e3789a..ba93c5b64a 100644
> >--- a/hw/acpi/Makefile.objs
> >+++ b/hw/acpi/Makefile.objs
> >@@ -10,7 +10,7 @@ common-obj-$(call lnot,$(CONFIG_ACPI_X86)) += acpi-stub.o
> > 
> > common-obj-y += acpi_interface.o
> > common-obj-y += bios-linker-loader.o
> >-common-obj-y += aml-build.o
> >+common-obj-y += aml-build.o utils.o
> > common-obj-$(CONFIG_TPM) += tpm.o
> > 
> > common-obj-$(CONFIG_IPMI) += ipmi.o
> >diff --git a/hw/acpi/utils.c b/hw/acpi/utils.c
> >new file mode 100644
> >index 00..77b9e8148f
> >--- /dev/null
> >+++ b/hw/acpi/utils.c
> >@@ -0,0 +1,36 @@
> >+/*
> >+ * Utilities for generating ACPI tables and passing them to Guests
> >+ *
> >+ * Copyright (C) 2019 Intel Corporation
> >+ * Copyright (C) 2019 Red Hat Inc
> >+ *
> >+ * Author: Wei Yang 
> >+ * Author: Michael S. Tsirkin 
> >+ *
> >+ * This program 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.
> >+
> >+ * This program 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 General Public License for more details.
> >+
> >+ * You should have received a copy of the GNU General Public License along
> >+ * with this program; if not, see .
> >+ */
> >+
> >+#include "qemu/osdep.h"
> >+#include "hw/acpi/aml-build.h"
> >+#include "hw/acpi/utils.h"
> >+#include "hw/loader.h"
> >+
> >+MemoryRegion *acpi_add_rom_blob(FWCfgCallback update, void *opaque,
> >+GArray *blob, const char *name,
> >+uint64_t max_size)
> >+{
> >+return rom_add_blob(name, blob->data, acpi_data_len(blob), max_size, -1,
> >+name, update, opaque, NULL, true);
> >+}
> >+
> >diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> >index 57679a89bf..a846f74a14 100644
> >--- a/hw/arm/virt-acpi-build.c
> >+++ b/hw/arm/virt-acpi-build.c
> >@@ -37,9 +37,9 @@
> > #include "hw/acpi/acpi.h"
> > #include "hw/nvram/fw_cfg.h"
> > #include "hw/acpi/bios-linker-loader.h"
> >-#include "hw/loader.h"
> > #include "hw/hw.h"
> > #include "hw/acpi/aml-build.h"
> >+#include "hw/acpi/utils.h"
> > #include "hw/pci/pcie_host.h"
> > #include "hw/pci/pci.h"
> > #include "hw/arm/virt.h"
> >@@ -881,14 +881,6 @@ static void virt_acpi_build_reset(void *build_opaque)
> > build_state->patched = false;
> > }
> > 
> >-static MemoryRegion *acpi_add_rom_blob(AcpiBuildState *build_state,
> >-   GArray *blob, const char *name,
> >-   uint64_t max_size)
> >-{
> >-return rom_add_blob(name, blob->data, acpi_data_len(blob), max_size, -1,
> >-name, virt_acpi_build_update, build_state, NULL, 
> >true);
> >-}
> >-
> > static const VMStateDescription vmstate_virt_acpi_build = {
> > .name = "virt_acpi_build",
> > .version_id = 1,
> >@@ -920,20 +912,22 @@ void virt_acpi_setup(VirtMachineState *vms)
> > virt_acpi_build(vms, &tables);
> > 
> > /* Now expose it all to Guest */
> >-build_state->table_mr = acpi_add_rom_blob(build_state, 
> >tables.table_data,
> >-   ACPI_BUILD_TABLE_FILE,
> >-   ACPI_BUILD_TABLE_MAX_SIZE);
> >+build_state->table_mr = acpi_add_rom_blob(virt_

Re: [Qemu-devel] [PATCH] ui/curses: Fix build with -m32

[Samuel Thibault]

Max Reitz, le lun. 27 mai 2019 16:25:40 +0200, a ecrit:
> wchar_t may resolve to be an unsigned long on 32-bit architectures.
> Using the %x conversion specifier will then give a compiler warning:
> 
> ui/curses.c: In function ‘get_ucs’:
> ui/curses.c:492:49: error: format ‘%x’ expects argument of type ‘unsigned 
> int’, but argument 3 has type ‘wchar_t’ {aka ‘long int’} [-Werror=format=]
>   492 | fprintf(stderr, "Could not convert 0x%04x "
>   |  ~~~^
>   | |
>   | unsigned int
>   |  %04lx
>   493 | "from wchar_t to a multibyte character: %s\n",
>   494 | wch, strerror(errno));
>   | ~~~
>   | |
>   | wchar_t {aka long int}
> ui/curses.c:504:49: error: format ‘%x’ expects argument of type ‘unsigned 
> int’, but argument 3 has type ‘wchar_t’ {aka ‘long int’} [-Werror=format=]
>   504 | fprintf(stderr, "Could not convert 0x%04x "
>   |  ~~~^
>   | |
>   | unsigned int
>   |  %04lx
>   505 | "from a multibyte character to UCS-2 : %s\n",
>   506 | wch, strerror(errno));
>   | ~~~
>   | |
>   | wchar_t {aka long int}
> 
> Fix this by casting the wchar_t value to an unsigned long and using %lx
> as the conversion specifier.
> 
> Fixes: b7b664a4fe9a955338f2e11a0f7433b29c8cbad0
> Signed-off-by: Max Reitz 

Reviewed-by: Samuel Thibault 

> ---
>  ui/curses.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/ui/curses.c b/ui/curses.c
> index 1f3fcabb00..e9319eb8ae 100644
> --- a/ui/curses.c
> +++ b/ui/curses.c
> @@ -489,9 +489,9 @@ static uint16_t get_ucs(wchar_t wch, iconv_t conv)
>  memset(&ps, 0, sizeof(ps));
>  ret = wcrtomb(mbch, wch, &ps);
>  if (ret == -1) {
> -fprintf(stderr, "Could not convert 0x%04x "
> +fprintf(stderr, "Could not convert 0x%04lx "
>  "from wchar_t to a multibyte character: %s\n",
> -wch, strerror(errno));
> +(unsigned long)wch, strerror(errno));
>  return 0xFFFD;
>  }
>  
> @@ -501,9 +501,9 @@ static uint16_t get_ucs(wchar_t wch, iconv_t conv)
>  such = sizeof(uch);
>  
>  if (iconv(conv, &pmbch, &smbch, &puch, &such) == (size_t) -1) {
> -fprintf(stderr, "Could not convert 0x%04x "
> +fprintf(stderr, "Could not convert 0x%04lx "
>  "from a multibyte character to UCS-2 : %s\n",
> -wch, strerror(errno));
> +(unsigned long)wch, strerror(errno));
>  return 0xFFFD;
>  }
>  
> -- 
> 2.21.0
> 
> 

-- 
Samuel
/*
 * [...] Note that 120 sec is defined in the protocol as the maximum
 * possible RTT.  I guess we'll have to use something other than TCP
 * to talk to the University of Mars.
 * PAWS allows us longer timeouts and large windows, so once implemented
 * ftp to mars will work nicely.
 */
(from /usr/src/linux/net/inet/tcp.c, concerning RTT [retransmission timeout])

[Qemu-devel] [PATCH] ui/curses: Fix build with -m32

[Max Reitz]

wchar_t may resolve to be an unsigned long on 32-bit architectures.
Using the %x conversion specifier will then give a compiler warning:

ui/curses.c: In function ‘get_ucs’:
ui/curses.c:492:49: error: format ‘%x’ expects argument of type ‘unsigned int’, 
but argument 3 has type ‘wchar_t’ {aka ‘long int’} [-Werror=format=]
  492 | fprintf(stderr, "Could not convert 0x%04x "
  |  ~~~^
  | |
  | unsigned int
  |  %04lx
  493 | "from wchar_t to a multibyte character: %s\n",
  494 | wch, strerror(errno));
  | ~~~
  | |
  | wchar_t {aka long int}
ui/curses.c:504:49: error: format ‘%x’ expects argument of type ‘unsigned int’, 
but argument 3 has type ‘wchar_t’ {aka ‘long int’} [-Werror=format=]
  504 | fprintf(stderr, "Could not convert 0x%04x "
  |  ~~~^
  | |
  | unsigned int
  |  %04lx
  505 | "from a multibyte character to UCS-2 : %s\n",
  506 | wch, strerror(errno));
  | ~~~
  | |
  | wchar_t {aka long int}

Fix this by casting the wchar_t value to an unsigned long and using %lx
as the conversion specifier.

Fixes: b7b664a4fe9a955338f2e11a0f7433b29c8cbad0
Signed-off-by: Max Reitz 
---
 ui/curses.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/ui/curses.c b/ui/curses.c
index 1f3fcabb00..e9319eb8ae 100644
--- a/ui/curses.c
+++ b/ui/curses.c
@@ -489,9 +489,9 @@ static uint16_t get_ucs(wchar_t wch, iconv_t conv)
 memset(&ps, 0, sizeof(ps));
 ret = wcrtomb(mbch, wch, &ps);
 if (ret == -1) {
-fprintf(stderr, "Could not convert 0x%04x "
+fprintf(stderr, "Could not convert 0x%04lx "
 "from wchar_t to a multibyte character: %s\n",
-wch, strerror(errno));
+(unsigned long)wch, strerror(errno));
 return 0xFFFD;
 }
 
@@ -501,9 +501,9 @@ static uint16_t get_ucs(wchar_t wch, iconv_t conv)
 such = sizeof(uch);
 
 if (iconv(conv, &pmbch, &smbch, &puch, &such) == (size_t) -1) {
-fprintf(stderr, "Could not convert 0x%04x "
+fprintf(stderr, "Could not convert 0x%04lx "
 "from a multibyte character to UCS-2 : %s\n",
-wch, strerror(errno));
+(unsigned long)wch, strerror(errno));
 return 0xFFFD;
 }
 
-- 
2.21.0

Re: [Qemu-devel] [RFC v4 00/27] vSMMUv3/pSMMUv3 2 stage VFIO integration

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20190527114203.2762-1-eric.au...@redhat.com/



Hi,

This series failed build test on s390x host. Please find the details below.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD pointing to a commit that has the patches applied on top of "base"
# branch
set -e
CC=$HOME/bin/cc
INSTALL=$PWD/install
BUILD=$PWD/build
mkdir -p $BUILD $INSTALL
SRC=$PWD
cd $BUILD
$SRC/configure --cc=$CC --prefix=$INSTALL
make -j4
# XXX: we need reliable clean up
# make check -j4 V=1
make install

echo
echo "=== ENV ==="
env

echo
echo "=== PACKAGES ==="
rpm -qa
=== TEST SCRIPT END ===

  CC  ppc-softmmu/hw/display/vga.o
  CC  mips-softmmu/hw/mips/mips_r4k.o
/var/tmp/patchew-tester-tmp-oaqfmxu5/src/hw/ppc/spapr_iommu.c: In function 
‘spapr_tce_replay’:
/var/tmp/patchew-tester-tmp-oaqfmxu5/src/hw/ppc/spapr_iommu.c:161:14: error: 
‘IOMMUNotifier’ {aka ‘struct IOMMUNotifier’} has no member named ‘notify’
  161 | n->notify(n, &iotlb);
  |  ^~
make[1]: *** [/var/tmp/patchew-tester-tmp-oaqfmxu5/src/rules.mak:69: 
hw/ppc/spapr_iommu.o] Error 1


The full log is available at
http://patchew.org/logs/20190527114203.2762-1-eric.au...@redhat.com/testing.s390x/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-devel] [PATCH v7 10/10] hw/m68k: define Macintosh Quadra 800

[Aleksandar Markovic]

On May 27, 2019 3:32 PM, "Aleksandar Markovic" 
wrote:
>
>
> On May 26, 2019 1:07 AM, "Laurent Vivier"  wrote:
> >
> > If you want to test the machine, it doesn't yet boot a MacROM, but you
can
> > boot a linux kernel from the command line.
> >
> > You can install your own disk using debian-installer with:
> >
> > ./qemu-system-m68k \
> > -M q800 \
> > -serial none -serial mon:stdio \
> > -m 1000M -drive file=m68k.qcow2,format=qcow2 \
> > -net nic,model=dp83932,addr=09:00:07:12:34:57 \
> > -append "console=ttyS0 vga=off" \
> > -kernel vmlinux-4.15.0-2-m68k \
> > -initrd initrd.gz \
> > -drive file=debian-9.0-m68k-NETINST-1.iso \
> > -drive file=m68k.qcow2,format=qcow2 \
> > -nographic
> >
>
> Hello Laurent,
>
> How does one obtain vmlinux-4.15.0-2-m68 and init.rd?
>
> Greetings, Aleksandar
>

And the same for Debian iso.

Thanks in advance, Aleksandar

> > If you use a graphic adapter instead of "-nographic", you can use "-g"
to set the
> > size of the display (I use "-g 1600x800x24").
> >
> > Co-developed-by: Mark Cave-Ayland 
> > Signed-off-by: Mark Cave-Ayland 
> > Signed-off-by: Laurent Vivier 
> > ---
> >  MAINTAINERS  |  14 ++
> >  default-configs/m68k-softmmu.mak |   1 +
> >  hw/m68k/Kconfig  |  12 +
> >  hw/m68k/Makefile.objs|   1 +
> >  hw/m68k/bootinfo.h   | 100 +
> >  hw/m68k/q800.c   | 369 +++
> >  6 files changed, 497 insertions(+)
> >  create mode 100644 hw/m68k/bootinfo.h
> >  create mode 100644 hw/m68k/q800.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 3cacd751bf..274dfd6e19 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -906,6 +906,20 @@ F: hw/char/mcf_uart.c
> >  F: hw/net/mcf_fec.c
> >  F: include/hw/m68k/mcf*.h
> >
> > +q800
> > +M: Laurent Vivier 
> > +S: Maintained
> > +F: hw/block/swim.c
> > +F: hw/m68k/bootinfo.h
> > +F: hw/display/macfb.c
> > +F: hw/m68k/q800.c
> > +F: hw/misc/mac_via.c
> > +F: hw/nubus/*
> > +F: include/hw/block/swim.h
> > +F: include/hw/display/macfb.h
> > +F: include/hw/misc/mac_via.h
> > +F: include/hw/nubus/*
> > +
> >  MicroBlaze Machines
> >  ---
> >  petalogix_s3adsp1800
> > diff --git a/default-configs/m68k-softmmu.mak
b/default-configs/m68k-softmmu.mak
> > index e17495e2a0..7e3649c1b8 100644
> > --- a/default-configs/m68k-softmmu.mak
> > +++ b/default-configs/m68k-softmmu.mak
> > @@ -4,3 +4,4 @@
> >  #
> >  CONFIG_AN5206=y
> >  CONFIG_MCF5208=y
> > +CONFIG_Q800=y
> > diff --git a/hw/m68k/Kconfig b/hw/m68k/Kconfig
> > index 49ef0b3f6d..ffa8e48fd8 100644
> > --- a/hw/m68k/Kconfig
> > +++ b/hw/m68k/Kconfig
> > @@ -7,3 +7,15 @@ config MCF5208
> >  bool
> >  select COLDFIRE
> >  select PTIMER
> > +
> > +config Q800
> > +bool
> > +select FRAMEBUFFER
> > +select ADB
> > +select MAC_VIA
> > +select ESCC
> > +select ESP
> > +select MACFB
> > +select NUBUS
> > +select DP8393X
> > +select SWIM
> > diff --git a/hw/m68k/Makefile.objs b/hw/m68k/Makefile.objs
> > index 482f8477b4..cfd13fae53 100644
> > --- a/hw/m68k/Makefile.objs
> > +++ b/hw/m68k/Makefile.objs
> > @@ -1,2 +1,3 @@
> >  obj-$(CONFIG_AN5206) += an5206.o mcf5206.o
> >  obj-$(CONFIG_MCF5208) += mcf5208.o mcf_intc.o
> > +obj-$(CONFIG_Q800) += q800.o
> > diff --git a/hw/m68k/bootinfo.h b/hw/m68k/bootinfo.h
> > new file mode 100644
> > index 00..6584775f6d
> > --- /dev/null
> > +++ b/hw/m68k/bootinfo.h
> > @@ -0,0 +1,100 @@
> > +struct bi_record {
> > +uint16_t tag;/* tag ID */
> > +uint16_t size;   /* size of record */
> > +uint32_t data[0];/* data */
> > +};
> > +
> > +/* machine independent tags */
> > +
> > +#define BI_LAST 0x /* last record */
> > +#define BI_MACHTYPE 0x0001 /* machine type (u_long) */
> > +#define BI_CPUTYPE  0x0002 /* cpu type (u_long) */
> > +#define BI_FPUTYPE  0x0003 /* fpu type (u_long) */
> > +#define BI_MMUTYPE  0x0004 /* mmu type (u_long) */
> > +#define BI_MEMCHUNK 0x0005 /* memory chunk address and size */
> > +   /* (struct mem_info) */
> > +#define BI_RAMDISK  0x0006 /* ramdisk address and size */
> > +   /* (struct mem_info) */
> > +#define BI_COMMAND_LINE 0x0007 /* kernel command line parameters */
> > +   /* (string) */
> > +
> > +/*  Macintosh-specific tags (all u_long) */
> > +
> > +#define BI_MAC_MODEL0x8000  /* Mac Gestalt ID (model type) */
> > +#define BI_MAC_VADDR0x8001  /* Mac video base address */
> > +#define BI_MAC_VDEPTH   0x8002  /* Mac video depth */
> > +#define BI_MAC_VROW 0x8003  /* Mac video rowbytes */
> > +#define BI_MAC_VDIM 0x8004  /* Mac video dimensions */
> > +#define BI_MAC_VLOGICAL 0x8005  /* Mac video logical base */
> > +#define BI_MAC_SCCBASE  0x8006  /* Mac SCC base address */
> > +#define BI_MAC_BTIME0x8007  /* Mac boot time 

Re: [Qemu-devel] [PATCH] qcow2-bitmap: initialize bitmap directory alignment

[Andrey Shinkevich]

On 27/05/2019 16:28, Max Reitz wrote:
> On 27.05.19 14:52, Andrey Shinkevich wrote:
>> Valgrind detects multiple issues in QEMU iotests when the memory is
>> used without being initialized. Valgrind may dump lots of unnecessary
>> reports what makes the memory issue analysis harder. Particularly,
>> that is true for the aligned bitmap directory and can be seen while
>> running the iotest #169. Padding the aligned space with zeros eases
>> the pain.
>>
>> Signed-off-by: Andrey Shinkevich 
>> ---
>>   block/qcow2-bitmap.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Thanks, applied to my block branch:
> 
> https://git.xanclic.moe/XanClic/qemu/commits/branch/block
> 
> Max
> 

Thank you too!
Andrey

Re: [Qemu-devel] [RFC 1/3] block: Add ImageRotationalInfo

[Alberto Garcia]

On Mon 27 May 2019 03:44:59 PM CEST, Anton Nefedov wrote:
>> I think in general optimizing for SSDs should probably be the
>> default.  HDDs are slow anyway, so whoever uses them probably doesn’t
>> care about performance too much anyway...?  Whereas people using SSDs
>> probably do.  But as I said, we can and should always make a separate
>> decision for each case.
>
> Overall it looks good to me but I wonder how do we ensure both
> variants are test covered? Need a blockdev option to enforce the mode?

Max talked about a 30% slowdown on HDDs so I suppose it makes sense to
have an option to change that even if we optimize for SSDs by default.

Berto

Re: [Qemu-devel] [PATCH v3] numa: improve cpu hotplug error message with a wrong node-id

[Laurent Vivier]

On 27/05/2019 14:50, Igor Mammedov wrote:
> On Mon, 27 May 2019 08:55:49 +0200
> Laurent Vivier  wrote:
> 
>> On 24/05/2019 22:14, Eduardo Habkost wrote:
>>> On Fri, May 24, 2019 at 04:39:12PM +0200, Laurent Vivier wrote:
 On 24/05/2019 16:10, Igor Mammedov wrote:
> On Fri, 24 May 2019 12:35:21 +0200
> Laurent Vivier  wrote:
>   
>> On pseries, core-ids are strongly binded to a node-id by the command
>> line option. If an user tries to add a CPU to the wrong node, he has
>> an error but it is not really helpful:
>>
>>  qemu-system-ppc64 ... -smp 1,maxcpus=64,cores=1,threads=1,sockets=1 
>> \
>>-numa node,nodeid=0 -numa node,nodeid=1 ...
>>
>>  (qemu) device_add power9_v2.0-spapr-cpu-core,core-id=30,node-id=1
>>  Error: node-id=1 must match numa node specified with -numa option
>>
>> This patch improves this error message by giving to the user the good
>> topology information (node-id, socket-id and thread-id if they are
>> available) to use with the core-id he's providing:
>>
>>  Error: node-id=1 must match numa node specified with -numa option 
>> 'node-id 0'
>>
>> Signed-off-by: Laurent Vivier 
>> ---
>>
>> Notes:
>>v3: only add the topology to the existing message
>>As suggested by Igor replace
>>  Error: core-id 30 can only be plugged into node-id 0
>>by
>>  Error: node-id=1 must match numa node specified with -numa 
>> option 'node-id 0'
>>v2: display full topology in the error message
> numa.c | 25 -
>> 1 file changed, 24 insertions(+), 1 deletion(-)
>>
>> diff --git a/numa.c b/numa.c
>> index 3875e1efda3a..7882ec294be4 100644
>> --- a/numa.c
>> +++ b/numa.c
>> @@ -458,6 +458,27 @@ void qmp_set_numa_node(NumaOptions *cmd, Error 
>> **errp)
>> set_numa_options(MACHINE(qdev_get_machine()), cmd, errp);
>> }
>> +static char *cpu_topology_to_string(const CPUArchId *cpu)
>> +{
>> +GString *s = g_string_new(NULL);
>> +if (cpu->props.has_socket_id) {
>> +g_string_append_printf(s, "socket-id %"PRId64, 
>> cpu->props.socket_id);
>> +}
>> +if (cpu->props.has_node_id) {
>> +if (s->len) {
>> +g_string_append_printf(s, ", ");
>> +}
>> +g_string_append_printf(s, "node-id %"PRId64, 
>> cpu->props.node_id);
>> +}
>> +if (cpu->props.has_thread_id) {
>> +if (s->len) {
>> +g_string_append_printf(s, ", ");
>> +}
>> +g_string_append_printf(s, "thread-id %"PRId64, 
>> cpu->props.thread_id);
>> +}
>> +return g_string_free(s, false);
>> +}
>
> turns out we already have such helper: cpu_slot_to_string()

 It doesn't display the node-id but the core-id. And node-id is what we need
 to know.
>>>
>>> I'm confused about what you are trying to do here.
>>>
>>> On v1, the message looked like:
>>> Error: core-id 30 can only be plugged into node-id 0
>>>
>>> which is probably good for spapr.
>>>
>>>
>>> Then I suggested you added the other cpu->props fields.  e.g. on
>>> PC the message would look like:
>>> Error: socket-id 20, core-id 30, thread-id 40 can only be plugged into 
>>> node-id 0
>>>
>>>
>>> But you sent a v2 patch that would print this on PC:
>>> Error: core-id 30 can only be plugged into socket-id 20, node-id 0, 
>>> thread-id 40
>>>
>>> which doesn't make sense to me.
>>>
>>>
>>> Then in a reply to v2, Igor suggested:
>>>
>>>error_setg(errp, "node-id=%d must match numa node specified "
>>>  "with -numa option '%s'", node_id, topology);
>>>
>>>
>>> Igor suggest would address the problem above.  I expected it to become:
>>> node-id=0 must match numa node specified with -numa option core-id=30
>>> and on PC:
>>> node-id=0 must match numa node specified with -numa option 
>>> socket-id=20,core-id=30,thread-id=40
>>>
>>> Or maybe it could include the input node-id too:
>>> node-id=0 must match numa node specified with -numa option 
>>> node-id=1,core-id=30
>>> and on PC:
>>> node-id=0 must match numa node specified with -numa option 
>>> node-id=1,socket-id=20,core-id=30,thread-id=40
>>>
>>> Both options would work.
>>>
>>>
>>> But you implemented code that would print:
>>> Error: node-id=0 must match numa node specified with -numa option 
>>> 'node-id 1'
>>> and on PC it would print:
>>> Error: node-id=0 must match numa node specified with -numa option 
>>> 'socket-id 20 node-id 1 thread-id=40'
>>>
>>> which doesn't make sense to me.
>>>
>>>
>>> I was expecting something like:
>>> Error: CPU slot core-id=30 is bound to node-id 0, but node-id 1 was 
>>> specified
>>> and on PC:
>>> Error: CPU slot socket-id=20,co

Re: [Qemu-devel] [RFC 1/3] block: Add ImageRotationalInfo

[Max Reitz]

On 27.05.19 15:44, Anton Nefedov wrote:
> On 27/5/2019 3:57 PM, Max Reitz wrote:
>> On 27.05.19 14:37, Alberto Garcia wrote:
>>> On Mon 27 May 2019 02:16:53 PM CEST, Max Reitz wrote:
 On 26.05.19 17:08, Alberto Garcia wrote:
> On Fri 24 May 2019 07:28:10 PM CEST, Max Reitz  wrote:
>> +##
>> +# @ImageRotationalInfo:
>> +#
>> +# Indicates whether an image is stored on a rotating disk or not.
>> +#
>> +# @solid-state: Image is stored on a solid-state drive
>> +#
>> +# @rotating:Image is stored on a rotating disk
>
> What happens when you cannot tell? You assume it's solid-state?

 When *I* cannot tell?  This field is generally optional, so in that case
 it just will not be present.

 (When Linux cannot tell?  I don’t know :-))

> 
> Linux defaults to rotational == 1 unless the driver sets
> QUEUE_FLAG_NONROT.
> 
> By the way as far as I can tell, qemu does not report this flag unless
> explicitly set in a device property.
> 
>  DEFINE_PROP_UINT16("rotation_rate", IDEDrive, dev.rotation_rate, 0),
> and
>  DEFINE_PROP_UINT16("rotation_rate", SCSIDiskState, rotation_rate, 0),
> 
 Do you think there should be an explicit value for that?
>>>
>>> I'll try to rephrase:
>>>
>>> we have a new optimization that improves performance on SSDs but reduces
>>> performance on HDDs, so this series would detect where an image is
>>> stored in order to enable the faster code path for each case.
>>>
>>> What happens if QEMU cannot detect if we have a solid drive or a
>>> rotational drive? (e.g. a remote storage backend). Will it default to
>>> enabling preallocation using write_zeroes()?
>>
>> In this series, yes.  That is the default I chose.
>>
>> We have to make a separate decision for each case.  In the case of
>> filling newly allocated areas with zeroes, I think the performance gain
>> for SSDs is more important than the performance loss for HDDs.  That is
>> what I wrote in my response to Anton’s series.  So I took the series
>> even without it being able to distinguish both cases at all.
>> Consequentially, I believe it is reasonable for that to be the default
>> behavior if we cannot tell.
>>
>> I think in general optimizing for SSDs should probably be the default.
>> HDDs are slow anyway, so whoever uses them probably doesn’t care about
>> performance too much anyway...?  Whereas people using SSDs probably do.
>>   But as I said, we can and should always make a separate decision for
>> each case.
>>
> 
> Overall it looks good to me but I wonder how do we ensure both variants
> are test covered? Need a blockdev option to enforce the mode?

That’s a good point.  Yes, file-posix should probably take an option to
override the mode.  Actually, that may be a useful option in general (if
the file is on some file system where we cannot query this information
(like glusterfs), the user may want to manually provide it).

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [RFC 1/3] block: Add ImageRotationalInfo

[Anton Nefedov]

On 27/5/2019 3:57 PM, Max Reitz wrote:
> On 27.05.19 14:37, Alberto Garcia wrote:
>> On Mon 27 May 2019 02:16:53 PM CEST, Max Reitz wrote:
>>> On 26.05.19 17:08, Alberto Garcia wrote:
 On Fri 24 May 2019 07:28:10 PM CEST, Max Reitz  wrote:
> +##
> +# @ImageRotationalInfo:
> +#
> +# Indicates whether an image is stored on a rotating disk or not.
> +#
> +# @solid-state: Image is stored on a solid-state drive
> +#
> +# @rotating:Image is stored on a rotating disk

 What happens when you cannot tell? You assume it's solid-state?
>>>
>>> When *I* cannot tell?  This field is generally optional, so in that case
>>> it just will not be present.
>>>
>>> (When Linux cannot tell?  I don’t know :-))
>>>

Linux defaults to rotational == 1 unless the driver sets
QUEUE_FLAG_NONROT.

By the way as far as I can tell, qemu does not report this flag unless
explicitly set in a device property.

 DEFINE_PROP_UINT16("rotation_rate", IDEDrive, dev.rotation_rate, 0),
and
 DEFINE_PROP_UINT16("rotation_rate", SCSIDiskState, rotation_rate, 0),

>>> Do you think there should be an explicit value for that?
>>
>> I'll try to rephrase:
>>
>> we have a new optimization that improves performance on SSDs but reduces
>> performance on HDDs, so this series would detect where an image is
>> stored in order to enable the faster code path for each case.
>>
>> What happens if QEMU cannot detect if we have a solid drive or a
>> rotational drive? (e.g. a remote storage backend). Will it default to
>> enabling preallocation using write_zeroes()?
> 
> In this series, yes.  That is the default I chose.
> 
> We have to make a separate decision for each case.  In the case of
> filling newly allocated areas with zeroes, I think the performance gain
> for SSDs is more important than the performance loss for HDDs.  That is
> what I wrote in my response to Anton’s series.  So I took the series
> even without it being able to distinguish both cases at all.
> Consequentially, I believe it is reasonable for that to be the default
> behavior if we cannot tell.
> 
> I think in general optimizing for SSDs should probably be the default.
> HDDs are slow anyway, so whoever uses them probably doesn’t care about
> performance too much anyway...?  Whereas people using SSDs probably do.
>   But as I said, we can and should always make a separate decision for
> each case.
> 

Overall it looks good to me but I wonder how do we ensure both variants
are test covered? Need a blockdev option to enforce the mode?

/Anton

Re: [Qemu-devel] [PATCH v2 27/28] tests/qemu-iotests: re-format output to for make check-block

[Max Reitz]

On 23.05.19 12:25, Alex Bennée wrote:
> This attempts to clean-up the output to better match the output of the
> rest of the QEMU check system when called with -makecheck. This includes:
> 
>   - formatting as "  TESTiotest-FMT: nnn"
>   - only dumping config on failure (when -makecheck enabled)
> 
> The non-make check output has been cleaned up as well:
> 
>   - line re-displayed (\r) at the end
>   - fancy colours for pass/fail/skip
>   - timestamps always printed (option removed)
> 
> Signed-off-by: Alex Bennée 
> Message-Id: <20190503143904.31211-1-alex.ben...@linaro.org>
> Tested-by: Thomas Huth 
> 
> ---
> v3
>   - revert echo to printf
>   - add _report_test_start
> v4
>   - -pretty -> -makecheck
>   - keep all output together for makecheck
> v5
>   - merged in kwolf's pretty printing
>   - timestamps always printed in non-makecheck mode
> ---
>  tests/qemu-iotests/check | 179 +--
>  1 file changed, 116 insertions(+), 63 deletions(-)

Unless I missed something, this breaks ./check:

$ ./check -T -qcow2
000 - unknown test, ignored
QEMU  -- "build/x86_64-softmmu/qemu-system-x86_64" -nodefaults
-machine accel=qtest
QEMU_IMG  -- "build/qemu-img"
QEMU_IO   -- "build/qemu-io"  --cache writeback -f qcow2
QEMU_NBD  -- "build/qemu-nbd"
IMGFMT-- qcow2 (compat=1.1)
IMGPROTO  -- file
PLATFORM  -- Linux/x86_64 dresden 5.0.14-300.fc30.x86_64
TEST_DIR  -- build/tests/qemu-iotests/scratch
SOCKET_SCM_HELPER -- build/tests/qemu-iotests/socket_scm_helper

Passed all 0 tests


Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v7 10/10] hw/m68k: define Macintosh Quadra 800

[Laurent Vivier]

On 27/05/2019 15:32, Aleksandar Markovic wrote:
> 
> On May 26, 2019 1:07 AM, "Laurent Vivier"  > wrote:
>  >
>  > If you want to test the machine, it doesn't yet boot a MacROM, but 
> you can
>  > boot a linux kernel from the command line.
>  >
>  > You can install your own disk using debian-installer with:
>  >
>  >     ./qemu-system-m68k \
>  >     -M q800 \
>  >     -serial none -serial mon:stdio \
>  >     -m 1000M -drive file=m68k.qcow2,format=qcow2 \
>  >     -net nic,model=dp83932,addr=09:00:07:12:34:57 \
>  >     -append "console=ttyS0 vga=off" \
>  >     -kernel vmlinux-4.15.0-2-m68k \
>  >     -initrd initrd.gz \
>  >     -drive file=debian-9.0-m68k-NETINST-1.iso \
>  >     -drive file=m68k.qcow2,format=qcow2 \
>  >     -nographic
>  >
> 
> Hello Laurent,

Hello Aleksandar,

> How does one obtain vmlinux-4.15.0-2-m68 and init.rd?
> 

you can find more details in the cover letter:

  You can get the ISO from:


https://cdimage.debian.org/cdimage/ports/10.0/m68k/iso-cd/debian-10.0-m68k-NETINST-1.iso

  and extract the kernel and initrd.gz:

guestfish --add debian-10.0-m68k-NETINST-1.iso --ro \
  --mount /dev/sda:/ <<_EOF_
copy-out /install/cdrom/initrd.gz .
copy-out /install/kernels/vmlinux-4.16.0-1-m68k .
_EOF_

  The mirror to use is: http://ftp.ports.debian.org/debian-ports/
  when it fails, continue without boot loader.

  In the same way, you can extract the kernel and the initramfs from the qcow2
  image to use it with "-kernel" and "-initrd":

guestfish --add m68k.qcow2 --mount /dev/sda2:/ <<_EOF_
copy-out /boot/vmlinux-4.16.0-1-m68k .
copy-out /boot/initrd.img-4.16.0-1-m68k .
_EOF_

Thanks,
Laurent

Re: [Qemu-devel] [PATCH v7 10/10] hw/m68k: define Macintosh Quadra 800

[Aleksandar Markovic]

On May 26, 2019 1:07 AM, "Laurent Vivier"  wrote:
>
> If you want to test the machine, it doesn't yet boot a MacROM, but you can
> boot a linux kernel from the command line.
>
> You can install your own disk using debian-installer with:
>
> ./qemu-system-m68k \
> -M q800 \
> -serial none -serial mon:stdio \
> -m 1000M -drive file=m68k.qcow2,format=qcow2 \
> -net nic,model=dp83932,addr=09:00:07:12:34:57 \
> -append "console=ttyS0 vga=off" \
> -kernel vmlinux-4.15.0-2-m68k \
> -initrd initrd.gz \
> -drive file=debian-9.0-m68k-NETINST-1.iso \
> -drive file=m68k.qcow2,format=qcow2 \
> -nographic
>

Hello Laurent,

How does one obtain vmlinux-4.15.0-2-m68 and init.rd?

Greetings, Aleksandar

> If you use a graphic adapter instead of "-nographic", you can use "-g" to
set the
> size of the display (I use "-g 1600x800x24").
>
> Co-developed-by: Mark Cave-Ayland 
> Signed-off-by: Mark Cave-Ayland 
> Signed-off-by: Laurent Vivier 
> ---
>  MAINTAINERS  |  14 ++
>  default-configs/m68k-softmmu.mak |   1 +
>  hw/m68k/Kconfig  |  12 +
>  hw/m68k/Makefile.objs|   1 +
>  hw/m68k/bootinfo.h   | 100 +
>  hw/m68k/q800.c   | 369 +++
>  6 files changed, 497 insertions(+)
>  create mode 100644 hw/m68k/bootinfo.h
>  create mode 100644 hw/m68k/q800.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3cacd751bf..274dfd6e19 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -906,6 +906,20 @@ F: hw/char/mcf_uart.c
>  F: hw/net/mcf_fec.c
>  F: include/hw/m68k/mcf*.h
>
> +q800
> +M: Laurent Vivier 
> +S: Maintained
> +F: hw/block/swim.c
> +F: hw/m68k/bootinfo.h
> +F: hw/display/macfb.c
> +F: hw/m68k/q800.c
> +F: hw/misc/mac_via.c
> +F: hw/nubus/*
> +F: include/hw/block/swim.h
> +F: include/hw/display/macfb.h
> +F: include/hw/misc/mac_via.h
> +F: include/hw/nubus/*
> +
>  MicroBlaze Machines
>  ---
>  petalogix_s3adsp1800
> diff --git a/default-configs/m68k-softmmu.mak
b/default-configs/m68k-softmmu.mak
> index e17495e2a0..7e3649c1b8 100644
> --- a/default-configs/m68k-softmmu.mak
> +++ b/default-configs/m68k-softmmu.mak
> @@ -4,3 +4,4 @@
>  #
>  CONFIG_AN5206=y
>  CONFIG_MCF5208=y
> +CONFIG_Q800=y
> diff --git a/hw/m68k/Kconfig b/hw/m68k/Kconfig
> index 49ef0b3f6d..ffa8e48fd8 100644
> --- a/hw/m68k/Kconfig
> +++ b/hw/m68k/Kconfig
> @@ -7,3 +7,15 @@ config MCF5208
>  bool
>  select COLDFIRE
>  select PTIMER
> +
> +config Q800
> +bool
> +select FRAMEBUFFER
> +select ADB
> +select MAC_VIA
> +select ESCC
> +select ESP
> +select MACFB
> +select NUBUS
> +select DP8393X
> +select SWIM
> diff --git a/hw/m68k/Makefile.objs b/hw/m68k/Makefile.objs
> index 482f8477b4..cfd13fae53 100644
> --- a/hw/m68k/Makefile.objs
> +++ b/hw/m68k/Makefile.objs
> @@ -1,2 +1,3 @@
>  obj-$(CONFIG_AN5206) += an5206.o mcf5206.o
>  obj-$(CONFIG_MCF5208) += mcf5208.o mcf_intc.o
> +obj-$(CONFIG_Q800) += q800.o
> diff --git a/hw/m68k/bootinfo.h b/hw/m68k/bootinfo.h
> new file mode 100644
> index 00..6584775f6d
> --- /dev/null
> +++ b/hw/m68k/bootinfo.h
> @@ -0,0 +1,100 @@
> +struct bi_record {
> +uint16_t tag;/* tag ID */
> +uint16_t size;   /* size of record */
> +uint32_t data[0];/* data */
> +};
> +
> +/* machine independent tags */
> +
> +#define BI_LAST 0x /* last record */
> +#define BI_MACHTYPE 0x0001 /* machine type (u_long) */
> +#define BI_CPUTYPE  0x0002 /* cpu type (u_long) */
> +#define BI_FPUTYPE  0x0003 /* fpu type (u_long) */
> +#define BI_MMUTYPE  0x0004 /* mmu type (u_long) */
> +#define BI_MEMCHUNK 0x0005 /* memory chunk address and size */
> +   /* (struct mem_info) */
> +#define BI_RAMDISK  0x0006 /* ramdisk address and size */
> +   /* (struct mem_info) */
> +#define BI_COMMAND_LINE 0x0007 /* kernel command line parameters */
> +   /* (string) */
> +
> +/*  Macintosh-specific tags (all u_long) */
> +
> +#define BI_MAC_MODEL0x8000  /* Mac Gestalt ID (model type) */
> +#define BI_MAC_VADDR0x8001  /* Mac video base address */
> +#define BI_MAC_VDEPTH   0x8002  /* Mac video depth */
> +#define BI_MAC_VROW 0x8003  /* Mac video rowbytes */
> +#define BI_MAC_VDIM 0x8004  /* Mac video dimensions */
> +#define BI_MAC_VLOGICAL 0x8005  /* Mac video logical base */
> +#define BI_MAC_SCCBASE  0x8006  /* Mac SCC base address */
> +#define BI_MAC_BTIME0x8007  /* Mac boot time */
> +#define BI_MAC_GMTBIAS  0x8008  /* Mac GMT timezone offset */
> +#define BI_MAC_MEMSIZE  0x8009  /* Mac RAM size (sanity check) */
> +#define BI_MAC_CPUID0x800a  /* Mac CPU type (sanity check) */
> +#define BI_MAC_ROMBASE  0x800b  /* Mac system ROM base address */
> +
> +/*  Macintosh hardware profile data */
> +
> +#define BI_MAC_VIA1BASE 0x8010  /* Mac VIA1 base address (always
presen

Re: [Qemu-devel] [PATCH] qcow2-bitmap: initialize bitmap directory alignment

[Max Reitz]

On 27.05.19 14:52, Andrey Shinkevich wrote:
> Valgrind detects multiple issues in QEMU iotests when the memory is
> used without being initialized. Valgrind may dump lots of unnecessary
> reports what makes the memory issue analysis harder. Particularly,
> that is true for the aligned bitmap directory and can be seen while
> running the iotest #169. Padding the aligned space with zeros eases
> the pain.
> 
> Signed-off-by: Andrey Shinkevich 
> ---
>  block/qcow2-bitmap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks, applied to my block branch:

https://git.xanclic.moe/XanClic/qemu/commits/branch/block

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH] event_match: always match on None value

[Max Reitz]

On 24.05.19 20:02, John Snow wrote:
> Before, event_match didn't always recurse if the event value was not a
> dictionary, and would instead check for equality immediately.
> 
> By delaying equality checking to post-recursion, we can allow leaf
> values like "5" to match "None" and take advantage of the generic
> None-returns-True clause.
> 
> This makes the matching a little more obviously consistent at the
> expense of being able to check for explicit None values, which is
> probably not that important given what this function is used for.
> 
> Signed-off-by: John Snow 
> ---
>  python/qemu/__init__.py | 27 +++
>  1 file changed, 15 insertions(+), 12 deletions(-)
> 
> diff --git a/python/qemu/__init__.py b/python/qemu/__init__.py
> index 98ed8a2e28..77d45f88fe 100644
> --- a/python/qemu/__init__.py
> +++ b/python/qemu/__init__.py
> @@ -409,27 +409,30 @@ class QEMUMachine(object):
>  
>  The match criteria takes the form of a matching subdict. The event is
>  checked to be a superset of the subdict, recursively, with matching
> -values whenever those values are not None.
> +values whenever the subdict values are not None.
> +
> +This has a limitation that you cannot explicitly check for None 
> values.
>  
>  Examples, with the subdict queries on the left:
>   - None matches any object.
>   - {"foo": None} matches {"foo": {"bar": 1}}
> - - {"foo": {"baz": None}} does not match {"foo": {"bar": 1}}
> - - {"foo": {"baz": 2}} matches {"foo": {"bar": 1, "baz": 2}}
> + - {"foo": None} matches {"foo": 5}
> + - {"foo": {"abc": None}} does not match {"foo": {"bar": 1}}
> + - {"foo": {"rab": 2}} matches {"foo": {"bar": 1, "rab": 2}}
>  """
>  if match is None:
>  return True
>  
> -for key in match:
> -if key in event:
> -if isinstance(event[key], dict):
> -if not QEMUMachine.event_match(event[key], match[key]):
> -return False
> -elif event[key] != match[key]:
> +try:
> +for key in match:
> +if key in event:
> +return QEMUMachine.event_match(event[key], match[key])

With this change, we only check a single key that is both in @match and
@event.  I think we want to keep the "if not -- return False" pattern,
don’t we?

Max

> +else:
>  return False
> -else:
> -return False
> -return True
> +return True
> +except TypeError:
> +# either match or event wasn't iterable (not a dict)
> +return match == event
>  
>  def event_wait(self, name, timeout=60.0, match=None):
>  """
> 




signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v4 00/20] monitor: add asynchronous command type

[Markus Armbruster]

Gerd Hoffmann  writes:

> On Mon, May 27, 2019 at 10:18:42AM +0200, Markus Armbruster wrote:
>> Marc-André Lureau  writes:
>> 
>> > Hi
>> >
>> > On Thu, May 23, 2019 at 9:52 AM Markus Armbruster  
>> > wrote:
>> >> I'm not sure how asynchronous commands could support reconnect and
>> >> resume.
>> >
>> > The same way as current commands, including job commands.
>> 
>> Consider the following scenario: a management application such as
>> libvirt starts a long-running task with the intent to monitor it until
>> it finishes.  Half-way through, the management application needs to
>> disconnect and reconnect for some reason (systemctl restart, or crash &
>> recover, or whatever).
>> 
>> If the long-running task is a job, the management application can resume
>> after reconnect: the job's ID is as valid as it was before, and the
>> commands to query and control the job work as before.
>> 
>> What if it's and asynchronous command?
>
> This is not meant for some long-running job which you have to manage.
>
> Allowing commands being asynchronous makes sense for things which (a)
> typically don't take long, and (b) don't need any management.
>
> So, if the connection goes down the job is simply canceled, and after
> reconnecting the management can simply send the same command again.

Is this worth its own infrastructure?

Would you hazard a guess on how many commands can take long enough to
demand a conversion to asynchronous, yet not need any management?

>> > Whenever we can solve things on qemu side, I would rather not
>> > deprecate current API.
>> 
>> Making a synchronous command asynchronous definitely changes API.
>
> Inside qemu yes, sure.  But for the QMP client nothing changes.

Command replies can arrive out of order, can't they?

Re: [Qemu-devel] [PATCH v3 0/5] blockdev-backup: don't check aio_context too early

[Max Reitz]

On 23.05.19 19:06, John Snow wrote:
> See patch one's commit message for justification.
> Patches 2-5 are for testing, because that's always how these things go.
> 
> 001/5:[] [--] 'blockdev-backup: don't check aio_context too early'
> 002/5:[0004] [FC] 'iotests.py: do not use infinite waits'
> 003/5:[down]  'QEMUMachine: add events_wait method'
> 004/5:[0022] [FC] 'iotests.py: rewrite run_job to be pickier'
> 005/5:[0017] [FC] 'iotests: add iotest 250 for testing blockdev-backup
>across iothread contexts'
> 
> v3: Rebased on Max's staging branch:
> Rebase patch 2
> added patch 3, to add events_wait.
> Rework patch 4 to make run_job consume legacy events, too
> Minorly edit patch 5 due to the two above.
> v2: added patch 4, with iotest framework adjustments in patches 2/3.

Thanks, applied to my block branch:

https://git.xanclic.moe/XanClic/qemu/commits/branch/block
https://github.com/XanClic/qemu/commits/block

(:-P)

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it

[Markus Armbruster]

It's been three years, let's examine how things have evolved.

I'm using commit db3d11ee3f0, which is a bit behind current master, just
so I can apply my "[PATCH 0/4] Cleanups around qemu-common.h" cleanly.

Markus Armbruster  writes:

[...]
> = The status quo and why I hate it =
>
> I've seen several schools of thought on use of #include.
>
> There's the "no #include in headers" school: every .c file includes
> exactly the headers it needs, and the prerequisites they need.  Cyclic
> inclusion becomes impossible.  You can't sweep cyclic dependencies under
> the rug.  Headers are read just once per compilation unit.  The amount
> of crap you include is clearly visible.  However, maintaining the
> #include directives is a drag, not least because their order matters.
> Especially when headers neglect to spell out their dependencies.  Or
> they do, but it's wrong.
>
> There's the "headers must be self-contained" school: every header
> includes everything it needs.  Headers can be included in any order.
> Sorted #include directives are tidy and easy to navigate.  Headers can
> be read multiple times, which can only hurt compilation time.

Our compilers avoid this for headers with proper header guards.

>You need
> to make an effort to avoid cyclic dependencies and excessive inclusion.
>
> And then there's the school of non-thought: when it doesn't compile,
> sprinkle #include on the mess semi-randomly until it does.
>
> We do a bit of all three, but the result looks awfully close to what the
> school of non-thought produces.
>
> Every .c file includes qemu/osdep.h first.  For me, a .c file that
> includes nothing but that comes out well over half a Megabyte in >23k
> lines preprocessed.  Where does all this crap come from?
>
>   #lines  KiBytes  #files  source
> 5233 102   5   QEMU
> 8035 159  70   system
> 7915 224  73   GLib
> 2458  89   1   # lines
>23641 576 149   total
>
> "# lines" are lines added by the preprocessor so the rest of the
> compiler can keep track of source locations.

#lines  KiBytes  #files  source
   375   8   5   QEMU
  9722 230 113   system
  8212 254  74   GLib
  1517  65 N/A   # lines
 19826 557 192   total

The weight QEMU lost, system + GLib put on.

> Having the compiler wade through almost half a Megabyte of system+GLib
> crap before it begins to consider the code we care about feels wasteful.
> Perhaps we should rethink our approach to including library headers.

No change.

> Of the 102K that are actually our own, just 7K come from include/.  95K
> come from qapi-types.h.

Fixed.

> Judging from the .d files in my build tree, 95% of the .c files include
> qemu-common.h.  That makes things a good deal worse.

Down to 90%.  My "[PATCH 0/4] Cleanups around qemu-common.h" shrinks it
to less than 10%.  Small enough for me not to repeat the measurements
below.

>   Without
> NEED_CPU_H, this adds a modest 44K of our own headers, but almost 100K
> of system headers:
>
>   #lines  KiBytes  #files  source
> 6938 146  16   QEMU
>11426 254  74   system
> 7915 224  73   GLib
> 2658 100   1   # lines
>28937 726 164   total
>
> NEED_CPU_H adds another 120K of our own headers:
>
>   #lines  KiBytes  #files  source
>11534 263  43   QEMU
>11548 256  78   system
> 7915 225  72   GLib
> 3370 138   1   # lines
>34367 883 194   total
>
> The average size of a .c file is just over 15KiB.  To get to the actual
> C code there, the compiler has to wade through at least 550-880KiB of
> headers.  In other words, roughly 2% of the source comes from .c in the
> best case.
>
> But that's not even the worst part.  The worst part by far are our
> "touch this and recompile the world" headers.
>
> I find just short 4000 .d files in my build tree.

Some 6400 now, ignoring the .d that don't contain ".o:".

>Guess how many of our
> headers are listed as prerequisites in more than 90% of them (thus
> touching them will recompile the .c file)?  *Twenty-two*.

Down to 12 before my "[PATCH 0/4] Cleanups around qemu-common.h", and to
10 afterwards.

>Almost fifty
> recompile more half of the world.

No significant change.

> Naturally, touching osdep.h or anything it includes recompiles the
> world.  These are:
>
> config-host.h
> include/glib-compat.h
> include/qapi/error.h
> include/qemu/compiler.h
> include/qemu/osdep.h
> include/qemu/typedefs.h
> include/sysemu/os-posix.h
> qapi-types.h
>
> NEED_CPU_H adds
>
> config-target.h
>
> Fine, except for qapi/error.h and qapi-types.h.  The latter is an itch I
> need to scratc

Re: [Qemu-devel] [PULL v2 04/36] virtio: Introduce started flag to VirtioDevice

[Yongji Xie]

On Mon, 27 May 2019 at 18:44, Greg Kurz  wrote:
>
> On Fri, 24 May 2019 19:56:06 +0800
> Yongji Xie  wrote:
>
> > On Fri, 24 May 2019 at 18:20, Greg Kurz  wrote:
> > >
> > > On Mon, 20 May 2019 19:10:35 -0400
> > > "Michael S. Tsirkin"  wrote:
> > >
> > > > From: Xie Yongji 
> > > >
> > > > The virtio 1.0 transitional devices support driver uses the device
> > > > before setting the DRIVER_OK status bit. So we introduce a started
> > > > flag to indicate whether driver has started the device or not.
> > > >
> > > > Signed-off-by: Xie Yongji 
> > > > Signed-off-by: Zhang Yu 
> > > > Message-Id: <20190320112646.3712-2-xieyon...@baidu.com>
> > > > Reviewed-by: Michael S. Tsirkin 
> > > > Signed-off-by: Michael S. Tsirkin 
> > > > ---
> > > >  include/hw/virtio/virtio.h |  2 ++
> > > >  hw/virtio/virtio.c | 52 --
> > > >  2 files changed, 52 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> > > > index 7140381e3a..27c0efc3d0 100644
> > > > --- a/include/hw/virtio/virtio.h
> > > > +++ b/include/hw/virtio/virtio.h
> > > > @@ -105,6 +105,8 @@ struct VirtIODevice
> > > >  uint16_t device_id;
> > > >  bool vm_running;
> > > >  bool broken; /* device in invalid state, needs reset */
> > > > +bool started;
> > > > +bool start_on_kick; /* virtio 1.0 transitional devices support 
> > > > that */
> > > >  VMChangeStateEntry *vmstate;
> > > >  char *bus_name;
> > > >  uint8_t device_endian;
> > > > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > > > index 28056a7ef7..5d533ac74e 100644
> > > > --- a/hw/virtio/virtio.c
> > > > +++ b/hw/virtio/virtio.c
> > > > @@ -1162,10 +1162,16 @@ int virtio_set_status(VirtIODevice *vdev, 
> > > > uint8_t val)
> > > >  }
> > > >  }
> > > >  }
> > > > +vdev->started = val & VIRTIO_CONFIG_S_DRIVER_OK;
> > > > +if (unlikely(vdev->start_on_kick && vdev->started)) {
> > > > +vdev->start_on_kick = false;
> > > > +}
> > > > +
> > > >  if (k->set_status) {
> > > >  k->set_status(vdev, val);
> > > >  }
> > > >  vdev->status = val;
> > > > +
> > > >  return 0;
> > > >  }
> > > >
> > > > @@ -1208,6 +1214,9 @@ void virtio_reset(void *opaque)
> > > >  k->reset(vdev);
> > > >  }
> > > >
> > > > +vdev->start_on_kick = (virtio_host_has_feature(vdev, 
> > > > VIRTIO_F_VERSION_1) &&
> > > > +  !virtio_vdev_has_feature(vdev, 
> > > > VIRTIO_F_VERSION_1));
> > > > +vdev->started = false;
> > > >  vdev->broken = false;
> > > >  vdev->guest_features = 0;
> > > >  vdev->queue_sel = 0;
> > > > @@ -1518,14 +1527,21 @@ void virtio_queue_set_align(VirtIODevice *vdev, 
> > > > int n, int align)
> > > >
> > > >  static bool virtio_queue_notify_aio_vq(VirtQueue *vq)
> > > >  {
> > > > +bool ret = false;
> > > > +
> > > >  if (vq->vring.desc && vq->handle_aio_output) {
> > > >  VirtIODevice *vdev = vq->vdev;
> > > >
> > > >  trace_virtio_queue_notify(vdev, vq - vdev->vq, vq);
> > > > -return vq->handle_aio_output(vdev, vq);
> > > > +ret = vq->handle_aio_output(vdev, vq);
> > > > +
> > > > +if (unlikely(vdev->start_on_kick)) {
> > > > +vdev->started = true;
> > > > +vdev->start_on_kick = false;
> > > > +}
> > > >  }
> > > >
> > > > -return false;
> > > > +return ret;
> > > >  }
> > > >
> > > >  static void virtio_queue_notify_vq(VirtQueue *vq)
> > > > @@ -1539,6 +1555,11 @@ static void virtio_queue_notify_vq(VirtQueue *vq)
> > > >
> > > >  trace_virtio_queue_notify(vdev, vq - vdev->vq, vq);
> > > >  vq->handle_output(vdev, vq);
> > > > +
> > > > +if (unlikely(vdev->start_on_kick)) {
> > > > +vdev->started = true;
> > > > +vdev->start_on_kick = false;
> > > > +}
> > > >  }
> > > >  }
> > > >
> > > > @@ -1556,6 +1577,11 @@ void virtio_queue_notify(VirtIODevice *vdev, int 
> > > > n)
> > > >  } else if (vq->handle_output) {
> > > >  vq->handle_output(vdev, vq);
> > > >  }
> > > > +
> > > > +if (unlikely(vdev->start_on_kick)) {
> > > > +vdev->started = true;
> > > > +vdev->start_on_kick = false;
> > > > +}
> > > >  }
> > > >
> > > >  uint16_t virtio_queue_vector(VirtIODevice *vdev, int n)
> > > > @@ -1770,6 +1796,13 @@ static bool virtio_broken_needed(void *opaque)
> > > >  return vdev->broken;
> > > >  }
> > > >
> > > > +static bool virtio_started_needed(void *opaque)
> > > > +{
> > > > +VirtIODevice *vdev = opaque;
> > > > +
> > > > +return vdev->started;
> > >
> > > Existing machine types don't know about the "virtio/started" subsection. 
> > > This
> > > breaks migration to older QEMUs if the driver has started the device, ie. 
> > > most
> > > probably always when it comes to live migration.
> > >
> > > My understanding is that we do try to suppor

Re: [Qemu-devel] [RFC 1/3] block: Add ImageRotationalInfo

[Max Reitz]

On 27.05.19 14:37, Alberto Garcia wrote:
> On Mon 27 May 2019 02:16:53 PM CEST, Max Reitz wrote:
>> On 26.05.19 17:08, Alberto Garcia wrote:
>>> On Fri 24 May 2019 07:28:10 PM CEST, Max Reitz  wrote:
 +##
 +# @ImageRotationalInfo:
 +#
 +# Indicates whether an image is stored on a rotating disk or not.
 +#
 +# @solid-state: Image is stored on a solid-state drive
 +#
 +# @rotating:Image is stored on a rotating disk
>>>
>>> What happens when you cannot tell? You assume it's solid-state?
>>
>> When *I* cannot tell?  This field is generally optional, so in that case
>> it just will not be present.
>>
>> (When Linux cannot tell?  I don’t know :-))
>>
>> Do you think there should be an explicit value for that?
> 
> I'll try to rephrase:
> 
> we have a new optimization that improves performance on SSDs but reduces
> performance on HDDs, so this series would detect where an image is
> stored in order to enable the faster code path for each case.
> 
> What happens if QEMU cannot detect if we have a solid drive or a
> rotational drive? (e.g. a remote storage backend). Will it default to
> enabling preallocation using write_zeroes()?

In this series, yes.  That is the default I chose.

We have to make a separate decision for each case.  In the case of
filling newly allocated areas with zeroes, I think the performance gain
for SSDs is more important than the performance loss for HDDs.  That is
what I wrote in my response to Anton’s series.  So I took the series
even without it being able to distinguish both cases at all.
Consequentially, I believe it is reasonable for that to be the default
behavior if we cannot tell.

I think in general optimizing for SSDs should probably be the default.
HDDs are slow anyway, so whoever uses them probably doesn’t care about
performance too much anyway...?  Whereas people using SSDs probably do.
 But as I said, we can and should always make a separate decision for
each case.

Max



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH] qcow2-bitmap: initialize bitmap directory alignment

[Andrey Shinkevich]

Valgrind detects multiple issues in QEMU iotests when the memory is
used without being initialized. Valgrind may dump lots of unnecessary
reports what makes the memory issue analysis harder. Particularly,
that is true for the aligned bitmap directory and can be seen while
running the iotest #169. Padding the aligned space with zeros eases
the pain.

Signed-off-by: Andrey Shinkevich 
---
 block/qcow2-bitmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/qcow2-bitmap.c b/block/qcow2-bitmap.c
index 8a75366..4941764 100644
--- a/block/qcow2-bitmap.c
+++ b/block/qcow2-bitmap.c
@@ -754,7 +754,7 @@ static int bitmap_list_store(BlockDriverState *bs, 
Qcow2BitmapList *bm_list,
 dir_offset = *offset;
 }
 
-dir = g_try_malloc(dir_size);
+dir = g_try_malloc0(dir_size);
 if (dir == NULL) {
 return -ENOMEM;
 }
-- 
1.8.3.1

Re: [Qemu-devel] Question about wrong ram-node0 reference

[liujunjie (A)]

We find only one VM aborted among at least 20 VMs with the same configuration. 
And this problem does not reproduce yet... (Be aware of reproduce is importance 
to figure out the problem, we already tried to add more VMs to reproduce, but 
no results yet.)
The qemu cmdline is as follows:
/usr/bin/qemu-kvm -name guest=instance-00025bf8,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/var/run/libvirt/qemu/domain-118-instance-00025bf8/master-key.aes
 -machine 
pc-i440fx-2.8,accel=kvm,usb=off,dump-guest-core=off,max-ram-below-4g=2G -cpu 
host,host-cache-info=on -m 131072 -realtime min_guarantee=131072,mlock=off -smp 
16,sockets=2,cores=4,threads=2 -object iothread,id=iothread1 -object 
iothread,id=iothread2 -object iothread,id=iothread3 -object 
iothread,id=iothread4 -object iothread,id=iothread5 -object 
iothread,id=iothread6 -object iothread,id=iothread7 -object 
iothread,id=iothread8 -object iothread,id=iothread9 -object 
iothread,id=iothread10 -object iothread,id=iothread11 -object 
iothread,id=iothread12 -object iothread,id=iothread13 -object 
iothread,id=iothread14 -object iothread,id=iothread15 -object 
iothread,id=iothread16 -object iothread,id=iothread17 -object 
iothread,id=iothread18 -object iothread,id=iothread19 -object 
iothread,id=iothread20 -object iothread,id=iothread21 -object 
iothread,id=iothread22 -object iothread,id=iothread23 -object 
iothread,id=iothread24 -object iothread,id=iothread25 -object 
iothread,id=iothread26 -object iothread,id=iothread27 -object 
iothread,id=iothread28 -object iothread,id=iothread29 -object 
memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/dev/hugepages/libvirt/qemu/118-instance-00025bf8,share=yes,size=68719476736,host-nodes=0,policy=bind
 -numa node,nodeid=0,cpus=0-7,memdev=ram-node0 -object 
memory-backend-file,id=ram-node1,prealloc=yes,mem-path=/dev/hugepages/libvirt/qemu/118-instance-00025bf8,share=yes,size=68719476736,host-nodes=1,policy=bind
 -numa node,nodeid=1,cpus=8-15,memdev=ram-node1 -uuid 
6952c043-4e0c-4267-80c1-fac2e302443f -smbios type=1,manufacturer=OpenStack 
Foundation,product=OpenStack 
Nova,version=13.2.1-20181119144459,serial=c5cc21e6-1d3b-4587-8c1e-208a1d19a47e,uuid=6952c043-4e0c-4267-80c1-fac2e302443f,family=Virtual
 Machine -no-user-config -nodefaults -chardev 
socket,id=charmonitor,path=/var/run/libvirt/qemu/domain-118-instance-00025bf8/monitor.sock,server,nowait
 -mon chardev=charmonitor,id=monitor,mode=control -rtc 
base=2019-01-21T06:59:37,clock=vm,driftfix=slew -global 
kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot strict=on -device 
pci-bridge,chassis_nr=1,id=pci.1,bus=pci.0,addr=0x3 -device 
pci-bridge,chassis_nr=2,id=pci.2,bus=pci.0,addr=0x4 -device 
pci-bridge,chassis_nr=3,id=pci.3,bus=pci.0,addr=0x5 -device 
pci-bridge,chassis_nr=4,id=pci.4,bus=pci.0,addr=0x6 -device 
pci-bridge,chassis_nr=5,id=pci.5,bus=pci.0,addr=0x7 -device 
pci-bridge,chassis_nr=6,id=pci.6,bus=pci.0,addr=0x8 -device 
pci-bridge,chassis_nr=7,id=pci.7,bus=pci.0,addr=0x9 -device 
pci-bridge,chassis_nr=8,id=pci.8,bus=pci.0,addr=0xa -device 
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device 
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0xb -drive 
file=/dev/mapper/648d06e72e68404a9401854e21409f3d-dm,format=raw,if=none,id=drive-virtio-disk0,serial=648d06e7-2e68-404a-9401-854e21409f3d,cache=none,aio=native
 -device 
virtio-blk-pci,scsi=off,bus=pci.2,addr=0x1,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
 -chardev socket,id=charnet0,path=/var/run/vhost-user/tap4ba9f4eb-19 -netdev 
vhost-user,chardev=charnet0,queues=4,id=hostnet0 -device 
virtio-net-pci,mq=on,vectors=10,netdev=hostnet0,id=net0,mac=fa:16:3e:0f:ed:94,bus=pci.4,addr=0x3,bootindex=2
 -add-fd set=0,fd=45 -chardev file,id=charserial0,path=/dev/fdset/0,append=on 
-device isa-serial,chardev=charserial0,id=serial0 -chardev 
socket,id=charchannel0,path=/var/run/libvirt/qemu/instance-00025bf8.extend,server,nowait
 -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.1
 -chardev 
socket,id=charchannel1,path=/var/run/libvirt/qemu/instance-00025bf8.agent,server,nowait
 -device 
virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0
 -chardev 
socket,id=charchannel2,path=/var/run/libvirt/qemu/instance-00025bf8.hostd,server,nowait
 -device 
virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,name=org.qemu.guest_agent.2
 -chardev 
socket,id=charchannel3,path=/var/run/libvirt/qemu/instance-00025bf8.upgraded,server,nowait
 -device 
virtserialport,bus=virtio-serial0.0,nr=4,chardev=charchannel3,id=channel3,name=org.qemu.guest_agent.3
 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 172.28.5.246:3,password -k 
en-us -device cirrus-vga,id=video0,vgamem_mb=16,bus=pci.0,addr=0x2 -device 
vfio-pci,host=95:00.0,id=hostdev0,bus=pci.5,addr=0x1 -device 
vfio-pci,host=99:00.0,id=hostdev1,bus=pci.5,addr=0x2 -device 
vfio-pci,host=35:00.0,id=hostdev2,

Re: [Qemu-devel] [PATCH v3] numa: improve cpu hotplug error message with a wrong node-id

[Igor Mammedov]

On Mon, 27 May 2019 08:55:49 +0200
Laurent Vivier  wrote:

> On 24/05/2019 22:14, Eduardo Habkost wrote:
> > On Fri, May 24, 2019 at 04:39:12PM +0200, Laurent Vivier wrote:  
> >> On 24/05/2019 16:10, Igor Mammedov wrote:  
> >>> On Fri, 24 May 2019 12:35:21 +0200
> >>> Laurent Vivier  wrote:
> >>>  
>  On pseries, core-ids are strongly binded to a node-id by the command
>  line option. If an user tries to add a CPU to the wrong node, he has
>  an error but it is not really helpful:
> 
>  qemu-system-ppc64 ... -smp 1,maxcpus=64,cores=1,threads=1,sockets=1 \
>    -numa node,nodeid=0 -numa node,nodeid=1 ...
> 
>  (qemu) device_add power9_v2.0-spapr-cpu-core,core-id=30,node-id=1
>  Error: node-id=1 must match numa node specified with -numa option
> 
>  This patch improves this error message by giving to the user the good
>  topology information (node-id, socket-id and thread-id if they are
>  available) to use with the core-id he's providing:
> 
>  Error: node-id=1 must match numa node specified with -numa option 
>  'node-id 0'
> 
>  Signed-off-by: Laurent Vivier 
>  ---
> 
>  Notes:
>    v3: only add the topology to the existing message
>    As suggested by Igor replace
>  Error: core-id 30 can only be plugged into node-id 0
>    by
>  Error: node-id=1 must match numa node specified with -numa 
>  option 'node-id 0'
>    v2: display full topology in the error message  
> >>>numa.c | 25 -  
> 1 file changed, 24 insertions(+), 1 deletion(-)
> 
>  diff --git a/numa.c b/numa.c
>  index 3875e1efda3a..7882ec294be4 100644
>  --- a/numa.c
>  +++ b/numa.c
>  @@ -458,6 +458,27 @@ void qmp_set_numa_node(NumaOptions *cmd, Error 
>  **errp)
> set_numa_options(MACHINE(qdev_get_machine()), cmd, errp);
> }
>  +static char *cpu_topology_to_string(const CPUArchId *cpu)
>  +{
>  +GString *s = g_string_new(NULL);
>  +if (cpu->props.has_socket_id) {
>  +g_string_append_printf(s, "socket-id %"PRId64, 
>  cpu->props.socket_id);
>  +}
>  +if (cpu->props.has_node_id) {
>  +if (s->len) {
>  +g_string_append_printf(s, ", ");
>  +}
>  +g_string_append_printf(s, "node-id %"PRId64, 
>  cpu->props.node_id);
>  +}
>  +if (cpu->props.has_thread_id) {
>  +if (s->len) {
>  +g_string_append_printf(s, ", ");
>  +}
>  +g_string_append_printf(s, "thread-id %"PRId64, 
>  cpu->props.thread_id);
>  +}
>  +return g_string_free(s, false);
>  +}  
> >>>
> >>> turns out we already have such helper: cpu_slot_to_string()  
> >>
> >> It doesn't display the node-id but the core-id. And node-id is what we need
> >> to know.  
> > 
> > I'm confused about what you are trying to do here.
> > 
> > On v1, the message looked like:
> >Error: core-id 30 can only be plugged into node-id 0
> > 
> > which is probably good for spapr.
> > 
> > 
> > Then I suggested you added the other cpu->props fields.  e.g. on
> > PC the message would look like:
> >Error: socket-id 20, core-id 30, thread-id 40 can only be plugged into 
> > node-id 0
> > 
> > 
> > But you sent a v2 patch that would print this on PC:
> >Error: core-id 30 can only be plugged into socket-id 20, node-id 0, 
> > thread-id 40
> > 
> > which doesn't make sense to me.
> > 
> > 
> > Then in a reply to v2, Igor suggested:
> > 
> >   error_setg(errp, "node-id=%d must match numa node specified "
> > "with -numa option '%s'", node_id, topology);
> > 
> > 
> > Igor suggest would address the problem above.  I expected it to become:
> >node-id=0 must match numa node specified with -numa option core-id=30
> > and on PC:
> >node-id=0 must match numa node specified with -numa option 
> > socket-id=20,core-id=30,thread-id=40
> > 
> > Or maybe it could include the input node-id too:
> >node-id=0 must match numa node specified with -numa option 
> > node-id=1,core-id=30
> > and on PC:
> >node-id=0 must match numa node specified with -numa option 
> > node-id=1,socket-id=20,core-id=30,thread-id=40
> > 
> > Both options would work.
> > 
> > 
> > But you implemented code that would print:
> >Error: node-id=0 must match numa node specified with -numa option 
> > 'node-id 1'
> > and on PC it would print:
> >Error: node-id=0 must match numa node specified with -numa option 
> > 'socket-id 20 node-id 1 thread-id=40'
> > 
> > which doesn't make sense to me.
> > 
> > 
> > I was expecting something like:
> >Error: CPU slot core-id=30 is bound to node-id 0, but node-id 1 was 
> > specified
> > and on PC:
> >Error: CPU slot socket-id=20,core-id=30,thread-id=40 is bound to node-id 
> > 0, bu

Re: [Qemu-devel] Running linux on qemu omap

[Tony Lindgren]

Hi,

* Philippe Mathieu-Daudé  [190523 12:01]:
> What I use as reference for testing ARM boards [*] is the work of
> Guenter Roeck:
> https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/run-qemu-arm.sh

I think Guenter also has v2.3.50-local-linaro branch in his
github repo that has support for few extra boards like Beagleboard.
Not sure what's the current branch to use though.

Regards,

Tony

Re: [Qemu-devel] [RFC 1/3] block: Add ImageRotationalInfo

[Alberto Garcia]

On Mon 27 May 2019 02:16:53 PM CEST, Max Reitz wrote:
> On 26.05.19 17:08, Alberto Garcia wrote:
>> On Fri 24 May 2019 07:28:10 PM CEST, Max Reitz  wrote:
>>> +##
>>> +# @ImageRotationalInfo:
>>> +#
>>> +# Indicates whether an image is stored on a rotating disk or not.
>>> +#
>>> +# @solid-state: Image is stored on a solid-state drive
>>> +#
>>> +# @rotating:Image is stored on a rotating disk
>> 
>> What happens when you cannot tell? You assume it's solid-state?
>
> When *I* cannot tell?  This field is generally optional, so in that case
> it just will not be present.
>
> (When Linux cannot tell?  I don’t know :-))
>
> Do you think there should be an explicit value for that?

I'll try to rephrase:

we have a new optimization that improves performance on SSDs but reduces
performance on HDDs, so this series would detect where an image is
stored in order to enable the faster code path for each case.

What happens if QEMU cannot detect if we have a solid drive or a
rotational drive? (e.g. a remote storage backend). Will it default to
enabling preallocation using write_zeroes()?

Berto

Re: [Qemu-devel] [PATCH v7 10/10] hw/m68k: define Macintosh Quadra 800

[Mark Cave-Ayland]

On 25/05/2019 23:50, Laurent Vivier wrote:

> If you want to test the machine, it doesn't yet boot a MacROM, but you can
> boot a linux kernel from the command line.
> 
> You can install your own disk using debian-installer with:
> 
> ./qemu-system-m68k \
> -M q800 \
> -serial none -serial mon:stdio \
> -m 1000M -drive file=m68k.qcow2,format=qcow2 \
> -net nic,model=dp83932,addr=09:00:07:12:34:57 \
> -append "console=ttyS0 vga=off" \
> -kernel vmlinux-4.15.0-2-m68k \
> -initrd initrd.gz \
> -drive file=debian-9.0-m68k-NETINST-1.iso \
> -drive file=m68k.qcow2,format=qcow2 \
> -nographic
> 
> If you use a graphic adapter instead of "-nographic", you can use "-g" to set 
> the
> size of the display (I use "-g 1600x800x24").
> 
> Co-developed-by: Mark Cave-Ayland 
> Signed-off-by: Mark Cave-Ayland 
> Signed-off-by: Laurent Vivier 
> ---
>  MAINTAINERS  |  14 ++
>  default-configs/m68k-softmmu.mak |   1 +
>  hw/m68k/Kconfig  |  12 +
>  hw/m68k/Makefile.objs|   1 +
>  hw/m68k/bootinfo.h   | 100 +
>  hw/m68k/q800.c   | 369 +++
>  6 files changed, 497 insertions(+)
>  create mode 100644 hw/m68k/bootinfo.h
>  create mode 100644 hw/m68k/q800.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3cacd751bf..274dfd6e19 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -906,6 +906,20 @@ F: hw/char/mcf_uart.c
>  F: hw/net/mcf_fec.c
>  F: include/hw/m68k/mcf*.h
>  
> +q800
> +M: Laurent Vivier 
> +S: Maintained
> +F: hw/block/swim.c
> +F: hw/m68k/bootinfo.h
> +F: hw/display/macfb.c
> +F: hw/m68k/q800.c
> +F: hw/misc/mac_via.c
> +F: hw/nubus/*
> +F: include/hw/block/swim.h
> +F: include/hw/display/macfb.h
> +F: include/hw/misc/mac_via.h
> +F: include/hw/nubus/*
> +
>  MicroBlaze Machines
>  ---
>  petalogix_s3adsp1800
> diff --git a/default-configs/m68k-softmmu.mak 
> b/default-configs/m68k-softmmu.mak
> index e17495e2a0..7e3649c1b8 100644
> --- a/default-configs/m68k-softmmu.mak
> +++ b/default-configs/m68k-softmmu.mak
> @@ -4,3 +4,4 @@
>  #
>  CONFIG_AN5206=y
>  CONFIG_MCF5208=y
> +CONFIG_Q800=y
> diff --git a/hw/m68k/Kconfig b/hw/m68k/Kconfig
> index 49ef0b3f6d..ffa8e48fd8 100644
> --- a/hw/m68k/Kconfig
> +++ b/hw/m68k/Kconfig
> @@ -7,3 +7,15 @@ config MCF5208
>  bool
>  select COLDFIRE
>  select PTIMER
> +
> +config Q800
> +bool
> +select FRAMEBUFFER
> +select ADB
> +select MAC_VIA
> +select ESCC
> +select ESP
> +select MACFB
> +select NUBUS
> +select DP8393X
> +select SWIM
> diff --git a/hw/m68k/Makefile.objs b/hw/m68k/Makefile.objs
> index 482f8477b4..cfd13fae53 100644
> --- a/hw/m68k/Makefile.objs
> +++ b/hw/m68k/Makefile.objs
> @@ -1,2 +1,3 @@
>  obj-$(CONFIG_AN5206) += an5206.o mcf5206.o
>  obj-$(CONFIG_MCF5208) += mcf5208.o mcf_intc.o
> +obj-$(CONFIG_Q800) += q800.o
> diff --git a/hw/m68k/bootinfo.h b/hw/m68k/bootinfo.h
> new file mode 100644
> index 00..6584775f6d
> --- /dev/null
> +++ b/hw/m68k/bootinfo.h
> @@ -0,0 +1,100 @@
> +struct bi_record {
> +uint16_t tag;/* tag ID */
> +uint16_t size;   /* size of record */
> +uint32_t data[0];/* data */
> +};
> +
> +/* machine independent tags */
> +
> +#define BI_LAST 0x /* last record */
> +#define BI_MACHTYPE 0x0001 /* machine type (u_long) */
> +#define BI_CPUTYPE  0x0002 /* cpu type (u_long) */
> +#define BI_FPUTYPE  0x0003 /* fpu type (u_long) */
> +#define BI_MMUTYPE  0x0004 /* mmu type (u_long) */
> +#define BI_MEMCHUNK 0x0005 /* memory chunk address and size */
> +   /* (struct mem_info) */
> +#define BI_RAMDISK  0x0006 /* ramdisk address and size */
> +   /* (struct mem_info) */
> +#define BI_COMMAND_LINE 0x0007 /* kernel command line parameters */
> +   /* (string) */
> +
> +/*  Macintosh-specific tags (all u_long) */
> +
> +#define BI_MAC_MODEL0x8000  /* Mac Gestalt ID (model type) */
> +#define BI_MAC_VADDR0x8001  /* Mac video base address */
> +#define BI_MAC_VDEPTH   0x8002  /* Mac video depth */
> +#define BI_MAC_VROW 0x8003  /* Mac video rowbytes */
> +#define BI_MAC_VDIM 0x8004  /* Mac video dimensions */
> +#define BI_MAC_VLOGICAL 0x8005  /* Mac video logical base */
> +#define BI_MAC_SCCBASE  0x8006  /* Mac SCC base address */
> +#define BI_MAC_BTIME0x8007  /* Mac boot time */
> +#define BI_MAC_GMTBIAS  0x8008  /* Mac GMT timezone offset */
> +#define BI_MAC_MEMSIZE  0x8009  /* Mac RAM size (sanity check) */
> +#define BI_MAC_CPUID0x800a  /* Mac CPU type (sanity check) */
> +#define BI_MAC_ROMBASE  0x800b  /* Mac system ROM base address */
> +
> +/*  Macintosh hardware profile data */
> +
> +#define BI_MAC_VIA1BASE 0x8010  /* Mac VIA1 base address (always present) */
> +#define BI_MAC_VIA2BASE 0x8011  /* Mac VIA2 base address (type varies) */
> +#def

Re: [Qemu-devel] [PATCH] hw/i386/pc: check apci hotplug capability before nvdimm's

[Igor Mammedov]

On Thu, 11 Apr 2019 15:17:39 +0800
Wei Yang  wrote:

> pc_memory_pre_plug() is called during hotplug for both pc-dimm and
> nvdimm. This is more proper to check apci hotplug capability before
> check nvdimm specific capability.
not sure what this about.
Currently we are checking if ACPI is enabled
  if (!pcms->acpi_dev || !acpi_enabled) { ...
before nvdimm check and it looks better to me that we cancel
nvdimm hotplug earlier than passing it to
hotplug_handler_pre_plug(pcms->acpi_dev, dev, &local_err)
with this patch ACPI device handler will be called before
nvdimm check happens, so it's +1 unnecessary call chain in
the case of nvdimm, which I'd rather not have.

Are there any issues with current call flow?
(commit message doesn't really explaining why we need this patch)

> 
> Signed-off-by: Wei Yang 
> ---
>  hw/i386/pc.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index f2c15bf1f2..d48b6f9582 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -2091,17 +2091,17 @@ static void pc_memory_pre_plug(HotplugHandler 
> *hotplug_dev, DeviceState *dev,
>  return;
>  }
>  
> -if (is_nvdimm && !ms->nvdimms_state->is_enabled) {
> -error_setg(errp, "nvdimm is not enabled: missing 'nvdimm' in '-M'");
> -return;
> -}
> -
>  hotplug_handler_pre_plug(pcms->acpi_dev, dev, &local_err);
>  if (local_err) {
>  error_propagate(errp, local_err);
>  return;
>  }
>  
> +if (is_nvdimm && !ms->nvdimms_state->is_enabled) {
> +error_setg(errp, "nvdimm is not enabled: missing 'nvdimm' in '-M'");
> +return;
> +}
> +
>  pc_dimm_pre_plug(PC_DIMM(dev), MACHINE(hotplug_dev),
>   pcmc->enforce_aligned_dimm ? NULL : &legacy_align, 
> errp);
>  }

Re: [Qemu-devel] [RFC 1/3] block: Add ImageRotationalInfo

[Max Reitz]

On 26.05.19 17:08, Alberto Garcia wrote:
> On Fri 24 May 2019 07:28:10 PM CEST, Max Reitz  wrote:
>> +##
>> +# @ImageRotationalInfo:
>> +#
>> +# Indicates whether an image is stored on a rotating disk or not.
>> +#
>> +# @solid-state: Image is stored on a solid-state drive
>> +#
>> +# @rotating:Image is stored on a rotating disk
> 
> What happens when you cannot tell? You assume it's solid-state?

When *I* cannot tell?  This field is generally optional, so in that case
it just will not be present.

(When Linux cannot tell?  I don’t know :-))

Do you think there should be an explicit value for that?

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v14 0/1] qcow2: cluster space preallocation

[Max Reitz]

On 26.05.19 17:01, Alberto Garcia wrote:
> On Fri 24 May 2019 03:56:21 PM CEST, Max Reitz  wrote:
>>> +---+---+--+---+--+--+
>>> |   file|before| after| gain |
>>> +---+---+--+---+--+--+
>>> |ssd|  61.153  |  36.313  |  41% |
>>> |hdd| 112.676  | 122.056  |  -8% |
>>> +---+--+--+--+
>>
>> I’ve done a few more tests, and I’ve seen more slowdown on an HDD.
>> (Like 30 % when doing 64 kB requests that are not aligned to
>> clusters.)  On the other hand, the SSD gain is generally in the same
>> ballpark (38 % when issuing the same kind of requests.)
>   [...]
>> [1] Hm.  We can probably investigate whether the file is stored on a
>> rotational medium or not.  Is there a fundamental reason why this
>> patch seems to degrade performance on an HDD but improves it on an
>> SSD?  If so, we can probably make a choice based on that.
> 
> This is when writing to an unallocated cluster with no existing data on
> the backing image, right? Then it's probably because you need 2
> operations (write zeros + write data) instead of just one.

Hm, yes.  I didn’t test writing tail and head separately, which should
be even worse.

Max



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [RFC v4 27/27] vfio-pci: Implement the DMA fault handler

[Eric Auger]

Whenever the eventfd is triggered, we retrieve the DMA faults
from the mmapped fault region and inject them in the iommu
memory region.

Signed-off-by: Eric Auger 
---
 hw/vfio/pci.c | 53 +++
 hw/vfio/pci.h |  1 +
 2 files changed, 54 insertions(+)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 8208171f92..a07acf98c7 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -2834,10 +2834,63 @@ static void vfio_unregister_req_notifier(VFIOPCIDevice 
*vdev)
 static void vfio_dma_fault_notifier_handler(void *opaque)
 {
 VFIOPCIDevice *vdev = opaque;
+PCIDevice *pdev = &vdev->pdev;
+AddressSpace *as = pci_device_iommu_address_space(pdev);
+IOMMUMemoryRegion *iommu_mr = IOMMU_MEMORY_REGION(as->root);
+struct vfio_region_fault_prod header;
+struct iommu_fault *queue;
+char *queue_buffer = NULL;
+ssize_t bytes;
 
 if (!event_notifier_test_and_clear(&vdev->dma_fault_notifier)) {
 return;
 }
+
+if (!vdev->fault_prod_region.size || !vdev->fault_cons_region.size) {
+return;
+}
+
+bytes = pread(vdev->vbasedev.fd, &header, sizeof(header),
+  vdev->fault_prod_region.fd_offset);
+if (bytes != sizeof(header)) {
+error_report("%s unable to read the fault region header (0x%lx)",
+ __func__, bytes);
+return;
+}
+
+/* Normally the fault queue is mmapped */
+queue = (struct iommu_fault *)vdev->fault_prod_region.mmaps[0].mmap;
+if (!queue) {
+size_t queue_size = header.nb_entries * header.entry_size;
+
+error_report("%s: fault queue not mmapped: slower fault handling",
+ vdev->vbasedev.name);
+
+queue_buffer = g_malloc(queue_size);
+bytes =  pread(vdev->vbasedev.fd, queue_buffer, queue_size,
+   vdev->fault_prod_region.fd_offset + header.offset);
+if (bytes != queue_size) {
+error_report("%s unable to read the fault queue (0x%lx)",
+ __func__, bytes);
+return;
+}
+
+queue = (struct iommu_fault *)queue_buffer;
+}
+
+while (vdev->fault_cons_index != header.prod) {
+memory_region_inject_faults(iommu_mr, 1,
+&queue[vdev->fault_cons_index]);
+vdev->fault_cons_index =
+(vdev->fault_cons_index + 1) % header.nb_entries;
+}
+bytes = pwrite(vdev->vbasedev.fd, &vdev->fault_cons_index, 4,
+   vdev->fault_cons_region.fd_offset + 4);
+if (bytes != 4) {
+error_report("%s unable to write the fault region cons index (0x%lx)",
+ __func__, bytes);
+}
+g_free(queue_buffer);
 }
 
 static void vfio_register_dma_fault_notifier(VFIOPCIDevice *vdev)
diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
index ee64081b47..01737d9372 100644
--- a/hw/vfio/pci.h
+++ b/hw/vfio/pci.h
@@ -138,6 +138,7 @@ typedef struct VFIOPCIDevice {
 EventNotifier dma_fault_notifier;
 VFIORegion fault_prod_region;
 VFIORegion fault_cons_region;
+uint32_t fault_cons_index;
 int (*resetfn)(struct VFIOPCIDevice *);
 uint32_t vendor_id;
 uint32_t device_id;
-- 
2.20.1

[Qemu-devel] [RFC v4 26/27] vfio-pci: Set up fault regions

[Eric Auger]

We setup two fault regions: the producer fault is read-only from the
user space perspective. It is composed of the fault queue (mmappable)
and a header written by the kernel, located in a separate page.

The consumer fault is write-only from the user-space perspective.

Signed-off-by: Eric Auger 

---
---
 hw/vfio/pci.c | 99 +++
 hw/vfio/pci.h |  2 ++
 2 files changed, 101 insertions(+)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 29d4f633b0..8208171f92 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -2505,11 +2505,100 @@ int vfio_populate_vga(VFIOPCIDevice *vdev, Error 
**errp)
 return 0;
 }
 
+static void vfio_init_fault_regions(VFIOPCIDevice *vdev, Error **errp)
+{
+struct vfio_region_info *fault_region_info = NULL;
+struct vfio_region_info_cap_fault *cap_fault;
+VFIODevice *vbasedev = &vdev->vbasedev;
+struct vfio_info_cap_header *hdr;
+char *fault_region_name = NULL;
+uint32_t max_version;
+ssize_t bytes;
+int ret;
+
+/* Producer Fault Region */
+ret = vfio_get_dev_region_info(&vdev->vbasedev,
+   VFIO_REGION_TYPE_NESTED,
+   VFIO_REGION_SUBTYPE_NESTED_FAULT_PROD,
+   &fault_region_info);
+if (!ret) {
+hdr = vfio_get_region_info_cap(fault_region_info,
+   VFIO_REGION_INFO_CAP_PRODUCER_FAULT);
+if (!hdr) {
+error_setg(errp, "failed to retrieve fault ABI max version");
+g_free(fault_region_info);
+return;
+}
+cap_fault = container_of(hdr, struct vfio_region_info_cap_fault,
+ header);
+max_version = cap_fault->version;
+
+fault_region_name = g_strdup_printf("%s FAULT PROD %d",
+vbasedev->name,
+fault_region_info->index);
+
+ret = vfio_region_setup(OBJECT(vdev), vbasedev,
+&vdev->fault_prod_region,
+fault_region_info->index,
+fault_region_name);
+if (ret) {
+error_setg_errno(errp, -ret,
+ "failed to setup the fault prod region %d",
+ fault_region_info->index);
+goto out;
+}
+
+ret = vfio_region_mmap(&vdev->fault_prod_region);
+if (ret) {
+error_report("Failed to mmap fault queue(%d)", ret);
+}
+
+g_free(fault_region_info);
+g_free(fault_region_name);
+} else {
+goto out;
+}
+
+/* Consumer Fault Region */
+ret = vfio_get_dev_region_info(&vdev->vbasedev,
+   VFIO_REGION_TYPE_NESTED,
+   VFIO_REGION_SUBTYPE_NESTED_FAULT_CONS,
+   &fault_region_info);
+if (!ret) {
+fault_region_name = g_strdup_printf("%s FAULT CONS %d",
+vbasedev->name,
+fault_region_info->index);
+
+ret = vfio_region_setup(OBJECT(vdev), vbasedev,
+&vdev->fault_cons_region,
+fault_region_info->index,
+fault_region_name);
+if (ret) {
+error_setg_errno(errp, -ret,
+ "failed to setup the fault cons region %d",
+ fault_region_info->index);
+}
+
+/* Set the chosen fault ABI version in the consume header*/
+bytes = pwrite(vdev->vbasedev.fd, &max_version, 4,
+   vdev->fault_cons_region.fd_offset);
+if (bytes != 4) {
+error_setg(errp,
+   "Unable to set the chosen fault ABI version (%d)",
+   max_version);
+}
+}
+out:
+g_free(fault_region_name);
+g_free(fault_region_info);
+}
+
 static void vfio_populate_device(VFIOPCIDevice *vdev, Error **errp)
 {
 VFIODevice *vbasedev = &vdev->vbasedev;
 struct vfio_region_info *reg_info;
 struct vfio_irq_info irq_info = { .argsz = sizeof(irq_info) };
+Error *err = NULL;
 int i, ret = -1;
 
 /* Sanity check device */
@@ -2573,6 +2662,12 @@ static void vfio_populate_device(VFIOPCIDevice *vdev, 
Error **errp)
 }
 }
 
+vfio_init_fault_regions(vdev, &err);
+if (err) {
+error_propagate(errp, err);
+return;
+}
+
 irq_info.index = VFIO_PCI_ERR_IRQ_INDEX;
 
 ret = ioctl(vdev->vbasedev.fd, VFIO_DEVICE_GET_IRQ_INFO, &irq_info);
@@ -3105,6 +3200,8 @@ static void vfio_instance_finalize(Object *obj)
 
 vfio_display_finalize(vdev);
 vfio_bars_finalize(vdev);
+vfio_region_finalize(&vdev->fault_prod_region);
+vfio_region_finalize(&vdev->fault_cons_regio

[Qemu-devel] [RFC v4 24/27] hw/arm/smmuv3: Implement fault injection

[Eric Auger]

We convert iommu_fault structs received from the kernel
into the data struct used by the emulation code and record
the evnts into the virtual event queue.

Signed-off-by: Eric Auger 

---

v3 -> v4:
- fix compil issue on mingw

Exhaustive mapping remains to be done
---
 hw/arm/smmuv3.c | 71 +
 1 file changed, 71 insertions(+)

diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
index a697968ace..4b6480bec0 100644
--- a/hw/arm/smmuv3.c
+++ b/hw/arm/smmuv3.c
@@ -1549,6 +1549,76 @@ smmuv3_replay(IOMMUMemoryRegion *iommu_mr, IOMMUNotifier 
*n)
 {
 }
 
+struct iommu_fault;
+
+static inline int
+smmuv3_inject_faults(IOMMUMemoryRegion *iommu_mr, int count,
+ struct iommu_fault *buf)
+{
+#ifdef __linux__
+SMMUDevice *sdev = container_of(iommu_mr, SMMUDevice, iommu);
+SMMUv3State *s3 = sdev->smmu;
+uint32_t sid = smmu_get_sid(sdev);
+int i;
+
+for (i = 0; i < count; i++) {
+SMMUEventInfo info = {};
+struct iommu_fault_unrecoverable *record;
+
+if (buf[i].type != IOMMU_FAULT_DMA_UNRECOV) {
+continue;
+}
+
+info.sid = sid;
+record = &buf[i].event;
+
+switch (record->reason) {
+case IOMMU_FAULT_REASON_PASID_INVALID:
+info.type = SMMU_EVT_C_BAD_SUBSTREAMID;
+/* TODO further fill info.u.c_bad_substream */
+break;
+case IOMMU_FAULT_REASON_PASID_FETCH:
+info.type = SMMU_EVT_F_CD_FETCH;
+break;
+case IOMMU_FAULT_REASON_BAD_PASID_ENTRY:
+info.type = SMMU_EVT_C_BAD_CD;
+/* TODO further fill info.u.c_bad_cd */
+break;
+case IOMMU_FAULT_REASON_WALK_EABT:
+info.type = SMMU_EVT_F_WALK_EABT;
+info.u.f_walk_eabt.addr = record->addr;
+info.u.f_walk_eabt.addr2 = record->fetch_addr;
+break;
+case IOMMU_FAULT_REASON_PTE_FETCH:
+info.type = SMMU_EVT_F_TRANSLATION;
+info.u.f_translation.addr = record->addr;
+break;
+case IOMMU_FAULT_REASON_OOR_ADDRESS:
+info.type = SMMU_EVT_F_ADDR_SIZE;
+info.u.f_addr_size.addr = record->addr;
+break;
+case IOMMU_FAULT_REASON_ACCESS:
+info.type = SMMU_EVT_F_ACCESS;
+info.u.f_access.addr = record->addr;
+break;
+case IOMMU_FAULT_REASON_PERMISSION:
+info.type = SMMU_EVT_F_PERMISSION;
+info.u.f_permission.addr = record->addr;
+break;
+default:
+warn_report("%s Unexpected fault reason received from host: %d",
+__func__, record->reason);
+continue;
+}
+
+smmuv3_record_event(s3, &info);
+}
+return 0;
+#else
+return -1;
+#endif
+}
+
 static void smmuv3_iommu_memory_region_class_init(ObjectClass *klass,
   void *data)
 {
@@ -1558,6 +1628,7 @@ static void 
smmuv3_iommu_memory_region_class_init(ObjectClass *klass,
 imrc->notify_flag_changed = smmuv3_notify_flag_changed;
 imrc->get_attr = smmuv3_get_attr;
 imrc->replay = smmuv3_replay;
+imrc->inject_faults = smmuv3_inject_faults;
 }
 
 static const TypeInfo smmuv3_type_info = {
-- 
2.20.1

[Qemu-devel] [Bug 1829682] Re: QEMU PPC SYSTEM regression - 3.1.0 and GIT - Fail to boot AIX

[Ivan Warren via Qemu-devel]

According to git bisect :

 git bisect bad
c24ba3d0a34f68ad2c6bf1a15bc43770005f6cc0 is the first bad commit
commit c24ba3d0a34f68ad2c6bf1a15bc43770005f6cc0
Author: Laurent Vivier 
Date:   Wed Dec 19 17:35:41 2018 +0100

spapr: Add H-Call H_HOME_NODE_ASSOCIATIVITY

H_HOME_NODE_ASSOCIATIVITY H-Call returns the associativity domain
designation associated with the identifier input parameter

This fixes a crash when we try to hotplug a CPU in memory-less and
CPU-less numa node. In this case, the kernel tries to online the
node, but without the information provided by this h-call, the node id,
it cannot and the CPU is started while the node is not onlined.

It also removes the warning message from the kernel:
  VPHN is not supported. Disabling polling..

Signed-off-by: Laurent Vivier 
Reviewed-by: Greg Kurz 
Signed-off-by: David Gibson 

:04 04 97fe7c5db103c5426f25f2741db918e8cbc03b75 
ed55cf6abd483aa01974c18d613461cc9e80e2c3 M  hw
:04 04 4d51166be64bc71a72bd60eaa412aadc2117fc4c 
614be9f9c87d20f7a2c23921a37d771a8956ee7c M  include

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

Title:
  QEMU PPC SYSTEM regression - 3.1.0 and GIT - Fail to boot AIX

Status in QEMU:
  New

Bug description:
  Built from source on a debian system

  Linux db08 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux
  gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)

  Last git commit (from queued gdibson repository)

  starting AIX 7.2 TL 2 SP 2 with the following : (the install was done
  under qemu 3.1.0)

  qemu-system-ppc64 -M pseries \
  -cpu power7 \
  -cdrom AIX_v7.2_Install_7200-02-02-1806_DVD_1_of_2_32018.iso \
  -net nic \
  -net tap,ifname=tap2,script=no \
  -drive file=DISK1.IMG,if=none,id=drive-virtio-disk0 \
  -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=drive-virtio-disk0 \
  -m 4G \
  -serial stdio \
  -monitor unix:ms,server,nowait \
  -accel tcg \
  -k fr \
  -nographic \
  -prom-env input-device=/vdevice/vty@7100 \
  -prom-env output-device=/vdevice/vty@7100 \
  -prom-env diag-switch?=false \
  -prom-env boot-command="boot 
/pci@8002000/scsi@2/disk@100 -s verbose"

  Yields this :

  
  ^M
  SLOF^[[0m^[[?25l 
**^M
  ^[[1mQEMU Starting^M
  ^[[0m Build Date = Jan 14 2019 18:00:39^M
   FW Version = git-a5b428e1c1eae703^M
   Press "s" to enter Open Firmware.^M^M
  ^M^M
  
^[[0m^[[?25hC^MC0100^MC0120^MC0140^MC0200^MC0240^MC0260^MC02E0^MC0300^MC0320^MC0340^MC0360^MC0370^MC0380^MC0371^MC0372^MC0373^MC0374^MC03F0^MC0400^MC0480^MC04C0^MC04D0^MC0500^MPopulating
 /vdevice methods^M
  Populating /vdevice/vty@7100^M
  Populating /vdevice/nvram@7101^M
  Populating /vdevice/l-lan@7102^M
  Populating /vdevice/v-scsi@7103^M
 SCSI: Looking for devices^M
8200 CD-ROM   : "QEMU QEMU CD-ROM  2.5+"^M
  C05A0^MPopulating /pci@8002000^M
   00  (D) : 1234 qemu vga^M
   00 0800 (D) : 1033 0194serial bus [ usb-xhci ]^M
   00 1000 (D) : 1af4 1004virtio [ scsi ]^M
  Populating /pci@8002000/scsi@2^M
 SCSI: Looking for devices^M
100 DISK : "QEMU QEMU HARDDISK2.5+"^M
  C0600^MC06C0^MC0700^MC0800^MC0880^MC0890^MC08A0^MC08A8^MInstalling QEMU fb^M
  ^M
  ^M
  ^M
  C08B0^MScanning USB ^M
XHCI: Initializing^M
  USB Keyboard ^M
  USB mouse ^M
  C08C0^MC08D0^MNo console specified using screen & keyboard^M
  User selected input-device console: /vdevice/vty@7100^M
  User selected output-device console: /vdevice/vty@7100^M
  C08E0^MC08E8^MC08FF^M ^M
Welcome to Open Firmware^M
  ^M
Copyright (c) 2004, 2017 IBM Corporation All rights reserved.^M
This program and the accompanying materials are made available^M
under the terms of the BSD License available at^M
http://www.opensource.org/licenses/bsd-license.php^M
  ^M
  ^M
  Trying to load: -s verbose from: 
/pci@8002000/scsi@2/disk@100 ...   Successfully loaded^M
  ^M
  ---> qemu,pseries detected <---^M
  ^M
  ^M
  ^M
  ^M
  ^M
  ^M
  ^M
  
---^M
  Welcome to AIX.^M
 boot image timestamp: 05:56:13 04/20/2019^M
  processor count: 1;  memory size: 4096MB;  kernel size: 38426884^M
   boot device: /pci@8002000/scsi@2/disk@100^M
  ^M
  8000FFEC bytes of free memory remain at address 7FFF0014^M
  load address: 0x4000   aixmon size: 0x000D2C00   boot image size: 
0x01A6B430^M
  ^LAIX vm,uuid property contains inval

[Qemu-devel] [RFC v4 23/27] memory: Introduce IOMMU Memory Region inject_faults API

[Eric Auger]

This new API allows to inject @count iommu_faults into
the IOMMU memory region.

Signed-off-by: Eric Auger 
---
 include/exec/memory.h | 25 +
 memory.c  | 10 ++
 2 files changed, 35 insertions(+)

diff --git a/include/exec/memory.h b/include/exec/memory.h
index 9f107ebedb..593ee7fc50 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -57,6 +57,8 @@ struct MemoryRegionMmio {
 CPUWriteMemoryFunc *write[3];
 };
 
+struct iommu_fault;
+
 typedef struct IOMMUTLBEntry IOMMUTLBEntry;
 
 /* See address_space_translate: bit 0 is read, bit 1 is write.  */
@@ -400,6 +402,19 @@ typedef struct IOMMUMemoryRegionClass {
  * @iommu: the IOMMUMemoryRegion
  */
 int (*num_indexes)(IOMMUMemoryRegion *iommu);
+
+/*
+ * Inject @count faults into the IOMMU memory region
+ *
+ * Optional method: if this method is not provided, then
+ * memory_region_injection_faults() will return -ENOENT
+ *
+ * @iommu: the IOMMU memory region to inject the faults in
+ * @count: number of faults to inject
+ * @buf: fault buffer
+ */
+int (*inject_faults)(IOMMUMemoryRegion *iommu, int count,
+ struct iommu_fault *buf);
 } IOMMUMemoryRegionClass;
 
 typedef struct CoalescedMemoryRange CoalescedMemoryRange;
@@ -1216,6 +1231,16 @@ int memory_region_iommu_attrs_to_index(IOMMUMemoryRegion 
*iommu_mr,
  */
 int memory_region_iommu_num_indexes(IOMMUMemoryRegion *iommu_mr);
 
+/**
+ * memory_region_inject_faults : inject @count faults stored in @buf
+ *
+ * @iommu_mr: the IOMMU memory region
+ * @count: number of faults to be injected
+ * @buf: buffer containing the faults
+ */
+int memory_region_inject_faults(IOMMUMemoryRegion *iommu_mr, int count,
+struct iommu_fault *buf);
+
 /**
  * memory_region_name: get a memory region's name
  *
diff --git a/memory.c b/memory.c
index d90d8ea67e..16996ef14e 100644
--- a/memory.c
+++ b/memory.c
@@ -2038,6 +2038,16 @@ int memory_region_iommu_num_indexes(IOMMUMemoryRegion 
*iommu_mr)
 return imrc->num_indexes(iommu_mr);
 }
 
+int memory_region_inject_faults(IOMMUMemoryRegion *iommu_mr, int count,
+struct iommu_fault *buf)
+{
+IOMMUMemoryRegionClass *imrc = IOMMU_MEMORY_REGION_GET_CLASS(iommu_mr);
+if (!imrc->inject_faults) {
+return -ENOENT;
+}
+return imrc->inject_faults(iommu_mr, count, buf);
+}
+
 void memory_region_set_log(MemoryRegion *mr, bool log, unsigned client)
 {
 uint8_t mask = 1 << client;
-- 
2.20.1

[Qemu-devel] [RFC v4 19/27] hw/vfio/common: Introduce helpers to DMA map/unmap a RAM section

[Eric Auger]

Let's introduce two helpers that allow to DMA map/unmap a RAM
section. Those helpers will be called for nested stage setup in
another call site. Also the vfio_listener_region_add/del()
structure may be clearer.

Signed-off-by: Eric Auger 
---
 hw/vfio/common.c | 178 ++-
 hw/vfio/trace-events |   4 +-
 2 files changed, 109 insertions(+), 73 deletions(-)

diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 5c4b444f24..26bc2ab19f 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -524,13 +524,116 @@ hostwin_from_range(VFIOContainer *container, hwaddr 
iova, hwaddr end)
 return NULL;
 }
 
+static int vfio_dma_map_ram_section(VFIOContainer *container,
+MemoryRegionSection *section)
+{
+VFIOHostDMAWindow *hostwin;
+Int128 llend, llsize;
+hwaddr iova, end;
+void *vaddr;
+int ret;
+
+assert(memory_region_is_ram(section->mr));
+
+iova = TARGET_PAGE_ALIGN(section->offset_within_address_space);
+llend = int128_make64(section->offset_within_address_space);
+llend = int128_add(llend, section->size);
+llend = int128_and(llend, int128_exts64(TARGET_PAGE_MASK));
+end = int128_get64(int128_sub(llend, int128_one()));
+
+vaddr = memory_region_get_ram_ptr(section->mr) +
+section->offset_within_region +
+(iova - section->offset_within_address_space);
+
+hostwin = hostwin_from_range(container, iova, end);
+if (!hostwin) {
+error_report("vfio: IOMMU container %p can't map guest IOVA region"
+ " 0x%"HWADDR_PRIx"..0x%"HWADDR_PRIx,
+ container, iova, end);
+return -EFAULT;
+}
+
+trace_vfio_dma_map_ram(iova, end, vaddr);
+
+llsize = int128_sub(llend, int128_make64(iova));
+
+if (memory_region_is_ram_device(section->mr)) {
+hwaddr pgmask = (1ULL << ctz64(hostwin->iova_pgsizes)) - 1;
+
+if ((iova & pgmask) || (int128_get64(llsize) & pgmask)) {
+trace_vfio_listener_region_add_no_dma_map(
+memory_region_name(section->mr),
+section->offset_within_address_space,
+int128_getlo(section->size),
+pgmask + 1);
+return 0;
+}
+}
+
+ret = vfio_dma_map(container, iova, int128_get64(llsize),
+   vaddr, section->readonly);
+if (ret) {
+error_report("vfio_dma_map(%p, 0x%"HWADDR_PRIx", "
+ "0x%"HWADDR_PRIx", %p) = %d (%m)",
+ container, iova, int128_get64(llsize), vaddr, ret);
+if (memory_region_is_ram_device(section->mr)) {
+/* Allow unexpected mappings not to be fatal for RAM devices */
+return 0;
+}
+return ret;
+}
+return 0;
+}
+
+static void vfio_dma_unmap_ram_section(VFIOContainer *container,
+   MemoryRegionSection *section)
+{
+Int128 llend, llsize;
+hwaddr iova, end;
+bool try_unmap = true;
+int ret;
+
+iova = TARGET_PAGE_ALIGN(section->offset_within_address_space);
+llend = int128_make64(section->offset_within_address_space);
+llend = int128_add(llend, section->size);
+llend = int128_and(llend, int128_exts64(TARGET_PAGE_MASK));
+
+if (int128_ge(int128_make64(iova), llend)) {
+return;
+}
+end = int128_get64(int128_sub(llend, int128_one()));
+
+llsize = int128_sub(llend, int128_make64(iova));
+
+trace_vfio_dma_unmap_ram(iova, end);
+
+if (memory_region_is_ram_device(section->mr)) {
+hwaddr pgmask;
+VFIOHostDMAWindow *hostwin =
+hostwin_from_range(container, iova, end);
+
+assert(hostwin); /* or region_add() would have failed */
+
+pgmask = (1ULL << ctz64(hostwin->iova_pgsizes)) - 1;
+try_unmap = !((iova & pgmask) || (int128_get64(llsize) & pgmask));
+}
+
+if (try_unmap) {
+ret = vfio_dma_unmap(container, iova, int128_get64(llsize));
+if (ret) {
+error_report("vfio_dma_unmap(%p, 0x%"HWADDR_PRIx", "
+ "0x%"HWADDR_PRIx") = %d (%m)",
+ container, iova, int128_get64(llsize), ret);
+}
+}
+}
+
 static void vfio_listener_region_add(MemoryListener *listener,
  MemoryRegionSection *section)
 {
 VFIOContainer *container = container_of(listener, VFIOContainer, listener);
 hwaddr iova, end;
-Int128 llend, llsize;
-void *vaddr;
+Int128 llend;
 int ret;
 VFIOHostDMAWindow *hostwin;
 
@@ -657,41 +760,10 @@ static void vfio_listener_region_add(MemoryListener 
*listener,
 }
 
 /* Here we assume that memory_region_is_ram(section->mr)==true */
-
-vaddr = memory_region_get_ram_ptr(section->mr) +
-section->offset_within_region +
-(iova - section->offset_within_address_space);
-
-trace_vfio_listener_region_add_ram(iova, end, vaddr);
-
-  

[Qemu-devel] [RFC v4 21/27] hw/vfio/common: Register a MAP notifier for MSI binding

[Eric Auger]

Instantiate a MAP notifier to register the MSI stage 1
binding (gIOVA -> gDB) to the host. This allows the host
to build a nested mapping towards the physical doorbell:
guest IOVA -> guest Doorbell -> physical doorbell.
  Stage1  Stage 2

The unregistration is done on VFIO container deallocation.

Signed-off-by: Eric Auger 

---

v2 -> v3:
- only register the notifier if the IOMMU translates MSIs
- record the msi bindings in a container list and unregister on
  container release
---
 hw/vfio/common.c  | 69 +++
 include/hw/vfio/vfio-common.h |  8 
 2 files changed, 77 insertions(+)

diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 084e3f30e6..532ede0e70 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -510,6 +510,56 @@ static void vfio_iommu_unmap_notify(IOMMUNotifier *n, 
IOMMUTLBEntry *iotlb)
 }
 }
 
+static void vfio_iommu_msi_map_notify(IOMMUNotifier *n, IOMMUTLBEntry *iotlb)
+{
+VFIOGuestIOMMU *giommu = container_of(n, VFIOGuestIOMMU, n);
+VFIOContainer *container = giommu->container;
+int ret;
+
+struct vfio_iommu_type1_bind_msi ustruct;
+VFIOMSIBinding *binding;
+
+QLIST_FOREACH(binding, &container->msibinding_list, next) {
+if (binding->iova == iotlb->iova) {
+return;
+}
+}
+ustruct.argsz = sizeof(struct vfio_iommu_type1_bind_msi);
+ustruct.flags = 0;
+
+ustruct.iova = iotlb->iova;
+ustruct.gpa = iotlb->translated_addr;
+ustruct.size = iotlb->addr_mask + 1;
+ret = ioctl(container->fd, VFIO_IOMMU_BIND_MSI , &ustruct);
+if (ret) {
+error_report("%s: failed to register the stage1 MSI binding (%d)",
+ __func__, ret);
+}
+binding =  g_new0(VFIOMSIBinding, 1);
+binding->iova = ustruct.iova;
+binding->gpa = ustruct.gpa;
+binding->size = ustruct.size;
+
+QLIST_INSERT_HEAD(&container->msibinding_list, binding, next);
+}
+
+static void vfio_container_unbind_msis(VFIOContainer *container)
+{
+VFIOMSIBinding *binding, *tmp;
+
+QLIST_FOREACH_SAFE(binding, &container->msibinding_list, next, tmp) {
+struct vfio_iommu_type1_unbind_msi ustruct;
+
+/* the MSI doorbell is not used anymore, unregister it */
+ustruct.argsz = sizeof(struct vfio_iommu_type1_unbind_msi);
+ustruct.flags = 0;
+ustruct.iova = binding->iova;
+ioctl(container->fd, VFIO_IOMMU_UNBIND_MSI , &ustruct);
+QLIST_REMOVE(binding, next);
+g_free(binding);
+}
+}
+
 static void vfio_iommu_map_notify(IOMMUNotifier *n, IOMMUTLBEntry *iotlb)
 {
 VFIOGuestIOMMU *giommu = container_of(n, VFIOGuestIOMMU, n);
@@ -837,6 +887,8 @@ static void vfio_listener_region_add(MemoryListener 
*listener,
MEMTXATTRS_UNSPECIFIED);
 
 if (container->iommu_type == VFIO_TYPE1_NESTING_IOMMU) {
+bool translate_msi;
+
 /* Config notifier to propagate guest stage 1 config changes */
 giommu = vfio_alloc_guest_iommu(container, iommu_mr, offset);
 iommu_config_notifier_init(&giommu->n, vfio_iommu_nested_notify,
@@ -853,6 +905,21 @@ static void vfio_listener_region_add(MemoryListener 
*listener,
   iommu_idx);
 QLIST_INSERT_HEAD(&container->giommu_list, giommu, giommu_next);
 memory_region_register_iommu_notifier(section->mr, &giommu->n);
+
+memory_region_iommu_get_attr(iommu_mr, IOMMU_ATTR_MSI_TRANSLATE,
+ (void *)&translate_msi);
+if (translate_msi) {
+giommu = vfio_alloc_guest_iommu(container, iommu_mr, offset);
+iommu_iotlb_notifier_init(&giommu->n,
+  vfio_iommu_msi_map_notify,
+  IOMMU_NOTIFIER_IOTLB_MAP,
+  section->offset_within_region,
+  int128_get64(llend),
+  iommu_idx);
+QLIST_INSERT_HEAD(&container->giommu_list, giommu,
+  giommu_next);
+memory_region_register_iommu_notifier(section->mr, &giommu->n);
+}
 } else {
 /* MAP/UNMAP IOTLB notifier */
 giommu = vfio_alloc_guest_iommu(container, iommu_mr, offset);
@@ -1629,6 +1696,8 @@ static void vfio_disconnect_container(VFIOGroup *group)
 g_free(giommu);
 }
 
+vfio_container_unbind_msis(container);
+
 trace_vfio_disconnect_container(container->fd);
 close(container->fd);
 g_free(container);
diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
index 686d99ff8c..c862d87725 100644
--- a/include/hw/vfio/vfio-common.h
+++ b/include/hw/vfio/vfio-common.h
@@ -64,6 +64,13 @@ typedef struct VFIOAddressSpace {